1.软件测试背景
引言：
软件测试在软件生命周期中占据重要的地位，软件测试慢慢的独立发展成为一个行业，并且在迅猛发展。
1.1. 软件缺陷与软件故障
一、软件缺陷与软件故障案例
1.美国迪斯尼公司的狮子王游戏软件BUG
2.火星登陆事故
3.跨世纪“千年虫”问题
4.其他一些例子
二、软件缺陷的定义
对于软件缺陷的精确定义，通常有下列5条描述：
1.软件未达到产品说明书的功能 《需求文档》
2.软件出现了产品说明书指明不会出现的错误
3.软件功能超出产品说明书指明范围
4.软件未达到产品说明书虽未指出但应达到的目标
5.软件测试员认为难以理解、不易使用、运行速度缓慢、或者最终用户认为不好
三、软件缺陷的特征
1.软件的特殊性决定了缺陷不易看到,即“看不到”；
2.发现了缺陷,但不易找到问题发生的原因所在,即“看到但是抓不到”。
1.如果你碰到不能复现的bug你改怎么办？
将bug的操作步骤进行记录，然后进行在不同的测试环境中多次的调试，如果还是不能复现bug将根据bug的登记进行上报测试组长，根据需求文档对bug进行评级，看是否需要修改，
如果不能修改的则记录在测试报告中防止后期出现同一bug进行解释说明。
2.测试流程？
1.2.软件缺陷产生的原因
软件缺陷从哪来？第一大原因就是软件产品规格说明书，很多情况下，说明书没有写，或写的不够全面，经常更改，或者开发小组没有很好的沟通，造成对说明书理解的不一致。第二大原因是软件设计，没有做设计或设计不好，经常变动等和产品规格说明书一样的问题，第三个原因才是编写代码和其它原因；前两个原因至少占了 80%以上。如图1-1所示
通过大量的测试理论研究及测试实践经验的积累，典型的软件缺陷产生的原因被归纳为以下几种类型：
(1)需求解释有错误；
(2)用户需求定义错误；
(3)需求记录错误；
(4)设计说明有误；
(5)编码说明有误；
(6)程序代码有误；
(7)数据输入有误；
(8)测试错误；
(9)问题修改不正确；
(10)不正确的结果是由于其他的缺陷而产生。
1.3.软件测试和缺陷修复的代价
缺陷发现的越早，则修复这个缺陷的代价就越小，在需求、设计、编码、测试、发布等不同的阶段，发现缺陷后修复的代价都会比在前一个阶段修复的代价提高10倍（参见图1-2）。
2.软件测试基础理论
引言：
软件测试是保证软件质量的一种手段，那么，什么叫软件测试？
2.1.软件测试定乂
狭义：测试的定义：“程序测试是为了发现错误而执行程序的过程”。这个定义，被业界所认可，经常被引用。
广义：为了更早地发现问题，所以将测试延伸到需求评审、设计审查活动中去，也就是将“软件质量保证”的部分活动归为测试活动。实际上，在软件开发实际操作中，常常将软件测试和质量保证——这两种努力（efforts）合并起来。延伸后的软件测试，被认为是一种软件测试的广义概念。
软件测试的定义：软件测试是贯穿整个软件开发生命周期、对软件产品（包括阶段性产品）进行验证和确认的活动过程，其目的是尽快尽早地发现在软件产品中所存在的各种问题——与用户需求、预先定义的不一致性。
2.2.软件测试的现状
现状：初期、不成熟、浮躁
公司越来越注重，开发与测试比例越来越接近
越来越紧缺-跳槽，待遇
毕业生、想转行
导致浮躁、但真正静下心来学习的不多
基础知识不扎实：知道基本方法但不深入理解
专业技术不够精通：写着精通某某工具，实际上只会皮毛
没有建立器相对完整的测试体系概念：对自己的工作职责理解不到位
在中国必然会经过一个不成熟的阶段，但最终会趋于平静，平稳的发展阶段。
2.3.软件测试的前景
2.4.新人如何融入一个项目团队
2.5.优秀的测试人员的基本素质
1、参与需求讨论，制订测试计划，确保测试能顺利执行并完成。 2、负责项目的功能性测试、用户体验测试、兼容性测试以及性能测试 3、负责测试用例的编写；编写测试报告和对测试结果分析， 4、与开发人员、产品经理沟通和协作，推动整个项目的顺利进行； 5、负责软件开发团队项目进度管理工作，6.熟悉Linux常用命令，熟悉常用数据库，熟练使用基本的SQL语句； 7.熟练使用Loadrunner，Jmeter等至少一种性能测试工具
2.6.软件工程的目的
成本：项目的开销，人工成本，工具成本，设备成本，错误成本（BUG）
进度：时间，计划
质量：软件对顾客需求的满意程度，一个低质量的软件，即使生产成本很低，进度控制良好，顾客也难以接受。
2.7.程序测试包含哪些内容
程序测试包括程序逻辑功能，界面，性能，易用性，兼容性，安装等测试，当然文档测试也算，排版，字体大小，也算程序测试的内容
2.8.测试环境
测试环境=硬件+软件+网络
硬件环境：pc机还是笔记本
软件环境：不同的操作系统windows10 windows8 windows7 Linux Mac ，
不同浏览器firefox chrom
网络:局域网还是互联网
2.9.测试流程
面试题：
从产品立项开始，我们(项目经理 产品经理 开发人员 测试等)内部会开立项会，在立项会中进行对需求进行评审，制定需求文档，前端进行设计页面,开发人员根据需求文档进行编码,测试需要制定测试计划，已经对需求进行颗粒划分，不同的测试人员根据自己的任务编写测试用例，然后对用例进行评审，开发提交代码后执行冒烟测试，如果冒烟测试结束后执行用例如果发现bug则提交bug，让开发人员进行修改，修改后进行二次验收，bug修改正确后关闭该bug，如果没有重新打开并进行跟踪bug，项目结束后需要进行编写测试报告。
开发不认为是bug的时候你怎么办理？
1.尝试多种测试环境和测试步骤来验证bug是真实存在，详细记录bug的复现步骤(可以是文字，图片，视频等)
2.需要根据bug的严重程度找项目经理或者是测试主管进行验证来确定是否为bug
3.可以找产品根据需求文档进行对bug进行认证
4.需要将bug在测试报告中进行解释说明留下备份防止后期在功能/版本迭代的时候产生问题
《需求文档》
测试人员
《测试计划书》
《测试用例》
《测试报告》
3.软件测试分类
3.1.黑盒测试和白盒测试
黑盒测试(Black Box -Test)指的是把被测试的软件看做一个黑盒子，我们不去关心盒子里边的结构是什么样子，只关心软件的输入数据和输出结果
有人把黑盒测试比作中医，通过“望闻问切”来判断是否有问题。
“望”：观察软件的行为是否正常。
“闻”：检查输出的结果是否正确。
“问”：输入各种信息，结合“望”，“闻”来观察软件的响应。
“切”：像中医一样给软件“把把脉”，敲击一下软件的某些“关节”
白盒测试(White Box Testing),指的是把盒子盖打开，去研究里边源代码和程序结构。
3.2.静态测试和动态测试
静态测试，是指不实际运行被测试软件，而只是静态的检查程序代码、界面或者文档中可能存在的错误的过程。
动态测试:是指实际运行被测程序，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程。
3.3.功能测试和性能测试
1.1.1.功能测试
是黑盒测试的一部分，它检查实际软件的功能是否符合用户的需求。
功能测试可以细分逻辑功能测试，界面测试，易用性测试，安装测试和兼容性测试。
逻辑功能测试:测试应用是否符合逻辑，比如应该先注册账号之后，才能进行登录,登录之后才能看我的购物车
界面测试:窗口大小，按钮大小，点击按钮弹出什么样的提示框，是否有滚动条，下拉菜单是否有展示内容…
易用性测试:从软件使用的合理性和方便性等角度对软件系统进行检查,比如，软件窗口长宽比例是否合适，颜色色彩是否赏心悦目，字体大小是否合适
安装测试:
兼容性测试:硬件兼容性测试和软件兼容性测试
硬件兼容性:比如一款软件在pc机，笔记本上是否兼容
软件兼容性测试:比如一款软件在windows8和windows10上是否兼容
1.1.2.性能测试
时间性能:软件的一个具体事务的响应时间。比如点击一个登陆按钮，到登录成功(失败)的反应时间，浏览器非常常见，ANR（Application not responding 应用程序无响应）
空间性能:软件运行时所消耗的系统资源，比如对内存和cpu的消耗
一般性能测试:软件正常运行，不向其施加任何压力的测试
稳定性测试:也叫可靠性测试，是指连续运行被测系统，检查系统运行时的稳定成都。
负载测试:让被测系统在其能够忍受的压力范围之内连续运行，来测试系统的稳定性。（测试载重）
压力测试:持续不断的给被测试的系统增加压力，直到被测试的系统压垮为止，用来测试系统所承受的最大压力。（测试强度）
3.4.回归测试、冒烟测试、随机测试
1.1.3.回归测试
是指对软件的新版本进行测试时，重复执行上一个版本测试时的用例，比如在1.0版本中，有一个bug，到了2.0版本中,再重新测试1.0中这个bug
1.1.4.冒烟测试
指对一个软件进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。
测试小组在正式测试一个新版本之前，先指派一两个测试人员测试一下软件的主要功能，如果没有实现，则打回开发组重新开发，这样做可以节省大量的时间成本和人力成本。
1.1.5.随机测试
是指测试中所有的输入数据都是随机生成的，其目的是模拟用户的真实操作，并发现一些边缘性的错误。
3.5.单元测试、集成测试、系统测试和验收测试
1.1.6.单元测试
单元测试（unit testing），是指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。
总的来说，单元就是人为规定的最小的被测功能模块。
单元测试当一段代码完成之后，是由白盒测试工程师或者开发人员自行测试，比如java中执行单元测试叫做junit测试。
目前大部分公司单元测试由开发人员简单编译和调试一下自己的程序，没有相应的单元测试计划。
单元测试方式:先静态地观察代码是否符合规范，然后动态地运行一下代码,检查运行的结果。
例如：模块接口测试
?应对通过所测模块的数据流进行测试
?调用所测模块时的输入参数与模块的形式参数的个数、属性和顺序是否匹配
?所测模块调用子模块时，输入子模块的参数与子模块的形式参数在个数、属性和顺序上是否匹配。
?输出给标准函数的参数的个数、属性和顺序是否正确。
?全局变量的定义在各个模块中是否一致。
?当模块通过外部设备进行输入/输出操作，文件属性是否正确、open和close语句是否正确，规定的I/O格式说明与I/O语句是否匹配；缓冲区容量是否与记录长度匹配，在读写之前是否打开了文件，读写之后是否关闭了文件，对I/O错误是否做了处理。
驱动模块：相当于所测模块的主程序，它接收测试数据，把这些数据传送给所测模块，最后再输出实际结果
桩模块：用以代替所测模块调用的子模块。
1.1.7.集成测试
集成测试是单元测试的下一个阶段，是指将通过测试单元模块组装成系统或者子系统，再进行测试，重点测试不同模块的接口部分。
?在把各个模块连接起来的时候，穿越各个模块的接口的数据时候会丢失
?一个模块的功能是否会对另一个模块的功能产生不利的影响
?各个子功能组装完成后，能否达到预期的父功能
?全局数据结构是否有问题
?单个模块产生的误差累计起来是否会放大
1.1.8.系统测试和验收测试
集成测试完成之后，就是系统测试和验收测试。
系统测试:指的是将整个软件系统看做一个1个整体进行测试，包括对功能、性能，以及软件所运行的软硬件环境进行测试。
系统测试由黑盒测试人员在整个系统集成完毕后进行测试，前期主要测试系统的功能是否满足需求，后期主要测试系统运行的性能是否满足需求，以及系统在不同的软硬件环境的兼容性等。
验收测试：以用户为主的测试，软件开发人员和质量保证人员参加，
3.6.测试案例
1.1.9.需求：
测试一个带广告图案的花纸杯
1.1.10.功能测试
能否装水，
除了装水， 能否装其他液体。比如可乐，酒精
能装多少ML的水
杯子是否有刻度表
杯子能否泡茶，泡咖啡
杯子是否能放冰箱，做冰块
杯子的材质是什么（玻璃，塑料,黄金做的）
1.1.11.界面测试
外观好不好看。
什么颜色
杯子的形状是怎么样的。
杯子的重量是多少
杯子的图案是否合理
1.1.12.性能测试
能否装100度的开水 (泡茶)
能否装0度冰水
装满水，放几天后，是否会漏水
杯子内壁上的涂料是否容易脱落。
杯子上的颜色是否容易褪色或者脱落
风吹是否会倒，摔一次是否会摔坏，摔多次是否会摔坏
1.1.13.安全性测试
制作杯子的材料，是否有毒
放微波炉里转的时候，是否会熔化。
从桌子上掉到水泥地上是否会摔碎。
杯子是否容易长细菌
杯子内壁上的材料，是否会溶解到水中
装进不同液体，是否会有化学反应。
1.1.14.易用性测试
杯子是否容易烫手
杯子是否好端，好拿
杯子的水是否容易喝到
杯子是否有防滑措施
是否能接受杯子的广告内容与图案
4.测试分类占比
5.软件测试的原则
1.尽早原则
2.边界和极端原则
3.28原则
4.确认原则
5.回归关联
1.应当把“尽早和不断地测试”作为开发者的座右铭。
2.设计测试用例时，应该考虑到合法的输入和不合法的输入，以及各种边界条件，特殊情况下要制造极端状态和意外状态，比如网络异常中断、电源断电等情况。
3.一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系。
4.对测试错误结果一定要有一个确认的过程。一般有A测试出来的错误，一定要有一个B来确认，严重的错误可以召开评审会进行讨论和分析。
5.制定严格的测试计划，并把测试时间安排得尽量宽松，不要希望在极短的时间内完成一个高水平的测试。
6.回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多错误出现的现象并不少见。
7.妥善保存一切测试过程文档，意义是不言而喻的，测试的重现性往往要靠测试文档。
6.软件的开发模式
6.1.线性模型与渐进式模型
线性模型：最常见的“瀑布模型”，基础框架，但缺点在于“集成之日就是爆炸之日”。（立项分析-需求分析-设计-编码-测试-维护）很多企业使用后使用迭代进行修改。
渐进式模型：最常见的“螺旋模型”，（需求分析-风险分析-设计、编码-测试、评审），迭代开发和增量开发模式。
注意：每一次迭代原型出来后，测试人员都需要从原型界面，系统主要功能，性能等方面对原型进行评审。
6.2.迭代和增量的理解
7.软件生命周期模型
软件生命周期 同任何事物一样，一个软件产品或软件系统也要经历孕育、诞生、成长、成熟、衰亡等阶段，一般称为软件生命周期（软件生存周期）[1] 。软件生命周期模型是指人们为开发更好的软件而归纳总结的软件生命周期的典型实践参考。
7.1.边做边改模型
许多产品都是使用“边做边改”模型来开发的。在这种模型中，既没有规格说明，也没有经过设计，软件随着客户的需要一次又一次地不断被修改。
在这个模型中，开发人员拿到项目立即根据需求编写程序，调试通过后生成软件的第一个版本。在提供给用户使用后，如果程序出现错误，或者用户提出新的要求，开发人员重新修改代码，直到用户满意为止。
这是一种类似作坊的开发方式，对编写几百行的小程序来说还不错，但这种方法对任何规模的开发来说都是不能令人满意的，其主要问题在于：
（1） 缺少规划和设计环节，软件的结构随着不断的修改越来越糟，导致无法继续修改；
（2） 忽略需求环节，给软件开发带来很大的风险；
（3） 没有考虑测试和程序的可维护性，也没有任何文档，软件的维护十分困难。
7.2.瀑布模型
瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。其过程是从上一项活动接收该项活动的工作对象作为输入，利用这一输入实施该项活动应完成的内容给出该项活动的工作成果，并作为输出传给下一项活动。同时评审该项活动的实施，若确认，则继续下一项活动；否则返回前面，甚至更前面的活动。对于经常变化的项目而言，瀑布模型毫无价值。
瀑布型简单地说就是按照需求、设计、编码、测试、软件维护这个基本的顺序来研发软件，前面一个步骤不完成，后面的步骤不能开始，否则问题会滚到下个阶段，带来更多的问题
优点：
- 为项目提供了按阶段划分的检查点
- 当前一阶段完成后，只需要去关注后续阶段。
缺点：
1）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
2）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。
3）通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
4）瀑布模型的突出缺点是不适应用户需求的变化。
7.3.原型化模型
原型化模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，经过和用户针对原型的讨论和交流，弄清需求以便真正把握用户需要的软件产品是什么样子的。充分了解后，再在原型基础上开发出用户满意的产品。
如图所示：原型严格来说不算一种软件生命周期模型，它只是一种获取需求的方法，在实际工作中该方法是相当重要的方法。
模型要点：瀑布和原型模型相结合，强调版本升级。
该模式的特点是一次性地获取全部的需求，然后做出分版本实现各需求的计划，每个版本只实现一部分需求，通过多个版本逐步实现全部需求，而每个版本可以认为是一个“小瀑布”。
该模型的好处是可以尽快让系统上线，让客户先使用部分功能，尽早实现系统的价值。
该模型比较能符合实际的情况，我们往往也是通过多个版本来逐步实现全部需求，但需求是不可能在一开始就完全确定的，实际情况是往往只能确定80%，而后期通过各版本我们还会获取更多的新需求以及需求调整。将此模型稍微调整后，可以适用于大部分的实际项目。
7.4.增量模型
增量模型也是原型化开发方法。如图所示
7.5.螺旋模型
螺旋模型是一个演化软件过程模型，将原型实现的迭代特征与线性顺序（瀑布）模型中控制的和系统化的方面结合起来。使得软件的增量版本的快速开发成为可能。在螺旋模型中，软件开发是一系列的增量发布。螺旋模型的整个开发过程如图所示。
图中的螺旋线代表随着时间推进的工作进展；开发过程具有周期性重复的螺旋线形状。4个象限分别标志每个周期所划分的4 个阶段：制定计划、风险分析、实施工程和客户评估。螺旋模型要点：统一了瀑布模型与原型模型，与增量模型相似，更强调风险分析。
1.软件分多个版本开发，每个版本就是一次螺旋。
2.每个版本按照这样的顺序进行：
1）确定软件目标，选取定实施方案，弄清项目开发的限制条件；（图中左上象限）
2）分析所选取方案，考虑如何识别和消除风险；（图中右上象限）
3）实施软件开发；（图中右下象限）
4）评价开发工作，提出修正建议，调整计划。（图中右下象限、左下象限）
3.需求不是一次获取和实现的，通过多个螺旋来完善。
4.计划也不是一次成型的，每次螺旋都需要调整。
优点：
1）设计上很灵活，可以在项目的各个阶段进行变更；
2）以小的分段来构建大型系统，使成本计算变得简单容易；(国企项目)
3）客户始终参与每个阶段的开发，保证了项目不偏离正确方向以及项目的可控性；
4）随着项目推进，客户始终掌握项目的最新信息 , 从而能够和管理层有效地交互；
5）客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品。
缺点：
螺旋模型强调风险分析，但要求许多客户接受和相信这种分析，并做出相关反应是不容易的。
因此，这种模型往往适应于内部的大规模软件开发。该模型建设周期长，而软件技术发展比较快，所以经常出现软件开发完毕后，和当前的技术水平有了较大的差距，无法满足当前用户需求。
7.6.Ｖ模型
V 模型的左边下降的是开发过程各阶段，与此相对应的是右边上升的部分，即各测试过程的各个阶段。
V 模型的优点在于它非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发各阶段的对应关系。
测试接入比较晚，不利于前期bug发现
1、需求分析阶段对应生成需求规格说明书，对应测试生成系统测试方案，即为系统测试准备的，该阶段已经完成了单元测试和集成测试，主要是对软件产品的功能与非功能进行测试，几乎不测试代码，所以测试方法以黑盒为主；
2、概要设计阶段对应生成概要设计说明书，对应测试生成集成测试方案，该阶段已完成单元测试，是将各个功能模块组装起来进行的测试，所以也叫组装测试。主要看模块调用是否正常，接口是否可用，数据传输是否正确等，所以用到的测试方法几乎是白盒的方法，如路径覆盖，条件组合覆盖等；
3、详细设计阶段对应生成详细设计说明书，对应测试生成单元测试方案，该阶段是开发人员编码后的第一个测试阶段，是对开发出来的单独模块进行测试，以确保每一个功能模块的功能正常，可以构建桩模块和驱动模块来回调用，方法也是以白盒为主。
4、白盒测试的准则是尽可能覆盖程序内部的逻辑结构，黑盒则是尽可能覆盖所有的输入输出接口，包括文档等一些静态的测试。除常用的测试方法外，仍需补充大范围的随机测试，尽可能达到覆盖率100%。
V模型的缺陷及解决思路
V模型仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段，忽视了测试对需求分析,系统设计的验证，需求的满足情况一直到后期的验收测试才被验证。
解决的思路是，当一个软件开发的时候，研发人员和测试人员需要同时工作，测试在软件做需求分析的同时就会有测试用例的跟踪，这样，可以尽快找出程序错误和需求偏离，从而更高效的提高程序质量，最大可能的减少成本，同时满足用户的实际软件需求。
7.7.Ｗ模型
相对于V模型，W模型更科学。W模型是V模型的发展，强调的s是测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样要测试。测试与开发是同步进行的，从而有利于尽早地发现问题。
对有些项目，开发过程中没有文档产生，无法使用。对于需求和设计的技术要求高，很难实践起来
8.敏捷开发和测试
敏捷开发
敏捷开发是针对传统的瀑布开发模式的弊端而产生的一种新的开发模式，目标是提高开发效率和响应能力。敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。
由于版本节奏比较快，开发与测试几乎并行，一个版本周期内会有两版在推动，也就是上图中提到的波次发布，波次发布用于尝试新加入的功能，做小范围快速的开发，验证和发布，为下个大版本的功能做实验和调研。快速发版的需求要求测试快速响应，敏捷测试模式适应项目需求。
模型优势：
工作任务划分清晰，工作效率较高
与开发和产品沟通紧密，团队协作性强
测试介入到整个项目的所有会议中，对整体版本信息情况把控全面
迅速占有市场，添加新的功能，吸引更多用户使用，提升用户体验度
模型的缺陷：
模块提交较快，测试时较有压迫感
项目规划要合理，不然测试时会出现复测的现象，加大工作量
9.软件质量模型
9.1.软件的功能性
1.1.15.适用性：
所提供的功能是用户所需要的，
用户所需要的功能软件系统是否已提供。
1.1.16.准确性：
软件系统提供给用户的功能是否满足用户对该功能的精确度要求。
1.1.17.互操作性：
软件系统和一个或多个周边系统进行信息交互的能力。
例如
不同型号的打印机与word之间的协议可能不一致，导致消息传递过程中发生错误。
▲应该将被测软件系统和周边系统的各种主流型号进行互操作性测试。
1.1.18.保密安全性：
软件系统保护信息和数据的能力。
Ⅰ、防止未得到授权的人或系统访问相关的信息或数据
Ⅱ、保证得到授权的人或系统能正常访问相关的信息或数据。
不同的系统对于安全性的需求差别很大
常见的安全性测试：
⑴用户验证：登录密码验证、IP地址访问限制等 sql注入
用户超时:登录超过30分钟，重新登录(安全设置，cookie过期时间30分钟)
⑵用户权限管理:验证低级别用户是否具有了高级别用户的权限，各级别用户权限都得到了实现。
⑶系统数据的保护:对例如系统文件、用户密码文件等进行隐藏、密码验证、内容加密、备份。
1.1.19.加密、解密：
在计算机通讯中，采用密码技术将信息隐蔽起来，再将隐蔽后的信息传输出去，使信息在传输过程中即使被窃取或截获，窃取者也不能了解信息的内容，从而保证信息传输的安全
token
Cookie 与session的区别：
1.cookie是明文传输 session的是隐藏专属
2.Cookie是存在与本机 session是存在与服务器
3.Cookie的大小是限制在4K session大小限制在5M
9.2.软件可靠性
1.1.20.成熟性
软件系统防止内部错误扩散而导致失效的能力。
▲子系统、模块、单元模块的设计人员应该仔细分析和自身有接口关系的子系统、模块、单元模块，识别出这些接口上可能会传递过来的错误，然后在自己子系统、模块、单元模块内部对这些可能的错误预先进行防范，规避这些错误传递到自身而引起自身的失效。
1.1.21.容错性
软件系统防止外部接口错误扩散而导致系统失效的能力。
▲设计人员应该充分分析外部接口可能产生的错误，然后在设计上对这些错误一一予以防范，防止这些外部传入的错误波及自身而失效。
1.1.22.易恢复性
系统失效后重新恢复原有功能、性能的能力
①原有能力恢复的程度
②原有能力恢复的速度
1.1.23.可靠性依从性
遵循相关的标准（国际标准、国家标准、行业标准、企业内部规范等)约定或法规以及类似规定的能力。
9.3.软件易用性
1.1.24.易理解性
用户在使用软件系统的过程中，系统交互给用户的信息是否准确、清晰、易懂，能帮助用户准确理解系统当前真实的状态，指导其进一步的操作。
1.1.25.易学性
软件系统提供相关的辅助手段，帮助用户学习使用它
的能力。
例如：是否有用户手册，用户手册是否有中文版，是否有在
线帮助，界面上控件是否有回显功能等。
1.1.26.易操作性
例如：
①Nokia手机和Moto手机在编辑短消息时的方便性差异。
②GUI界面，菜单层次不要太深
③安装软件的过程
错误：给用户大量的安装步骤，每步又有大量分支选项
（把用户当成本软件的专家）
▲测试时应该以非专业的角度来测试过程，往往需要α、
β测试。
1.1.27.吸引性
美观：GUI界面、手机外观等
新颖：如夏新手机来电跳舞功能
5、易用性的依从性
遵循相关的标准（国际标准、国家标准、行业标准、企业内部规范等)约定或法规以及类似规定的能力。
问：性能测试的标准：
吞吐量
响应时间
资源使用率 内存使用率 cpu的使用率 电量的损耗 流量使用
成功率
9.4.软件效率（性能测试）
1.1.28.时间效率(2-5-10) 358
系统在各业务场景下完成用户指定的业务请求所需的响应时间。
1.1.29.资源效率
系统在各业务场景下完成用户指定的业务请求所消耗的系统资源，如CPU占有率 75%内存占有率80%、通信带宽占有率、软件内部消息包资源占有率等。
1.1.30.效率依从性
遵循相关的标准（国际标准、国家标准、行业标准、企业内部规范等)约定或法规以及类似规定的能力。
9.5.软件可维护性
1.1.31.易分析性
软件系统提供辅助手段帮助开发人员分析识别缺陷、失效产生的原因，找出待修复部分的能力。（降低缺陷定位的成本）
1.1.32.易改变性
对软件缺陷的修复容易被实施（降低修复缺陷成本）
▲设计上封装性好、高内聚（同层次设计时，一个实体只完成一个功能）、低耦合，为未来可能的变化留有扩充余地。
1.1.33.稳定性
例如：代码中的有物理含义的数字，一定用宏代替。
1.1.34.易测试性
（降低发现缺陷的成本）
①软件可控制：
软件系统提供辅助手段帮助测试工程师控制该系统的运行，实现其测试执行步骤的能力（通过打点、改变内部状态、值等手段）
②可观察：
软件系统提供辅助手段帮助测试工程师获得充分的系统运行信息，以正确判断系统运行状态和测试执行结果的力。
a、设计单独的测试模式
b、提供单独的测试版本
▲测试部（一般指测试系统工程师）应该在需求分析阶段就提出可测试性需求，可测试性需求和软件产品其他需求一起纳入需求包被分析设计并实现。
5、维护性的依从性
遵循相关的标准（国际标准、国家标准、行业标准、企业内部规范等)约定或法规以及类似规定的能力。
9.6.软件可移植性
1.1.35.适应性
软件系统无需做任何相应变动就能适应不同运行环境（操作系统平台、数据库平台、硬件平台等）的能力。
▲解决平台无关、可移植性问题的一个常用思路是构造出一个虚拟层，虚拟层将下层细节屏蔽，对上层提供统一口。
1.1.36.易安装性
主流平台 全部测试用例
非主流平台 10%测试用例
1.1.37.共存性
软件系统和在公共环境与其共享资源的其他系统共存的能力。
▲测试不仅需要关注自身特性的实现，还要关注本软件是否影响了其他软件的正常功能。
9.7.易替换性
软件系统升级能力（在线升级、打补丁升级等）
可移植性的依从性
遵循相关的标准（国际标准、国家标准、行业标准、企业内部规范等)约定或法规以及类似规定的能力。
10.软件测试的常识知识
10.1.测试部门的组织结构
5个开发（java） 1个测试 2个移动（AND IOS） 1 个前端 1个产品/项目
按需求来分类： 1个组长： 制定测试计划 和 对测试用例的评审 编写测试报告和测试总结
1个功能测试： 按照测试用例进行点点的人
1个性能测试/接口测试： 满足需求文档上的性能指标
1个自动化测试 python uI自动化 接口自动化 单元自动化
Java
按项目模块划分： pc 移动
具体一级菜单栏 按底部导航栏
QA 测试 RA 研发 PM 项目经理
10.2.软件测试和SQA的关系
1.1.38.什么是SQA
1.1.39.SQA与测试
测试工具的种类：
文档工具： word excel xmind( 测试用例 测试计划 测试报告)
Bug管理工具： 禅道 jira
抓包工具： charles fiddler wineshark
a.抓包 b.模拟弱网测试c.断点替换 d.过滤 e：压力测试
性能工具： jmeter Loadrunner 11/12（对业务场景测试）
命令： Linux adb Monkey
编程语言： python
自动化 ; selenium appnium （ui自动化） Framwork
unittest pytest (测试用例 单元测试)
requests 接口自动化
innerHtmlTestrunner （发送测试报告） alluer
WinautoUI (桌面自动化)
数据库 mysql
GIT + JENKINS (持续化集成)
Ant+jenkins+jmeter 的集成
11.软件测试工具
软件测试工具是通过一些工具能够使软件的一些简单问题直观的显示，使测试人员更好的找出软件错误所在。
软件测试工具分为自动化软件测试工具和测试管理(禅道)工具。
软件测试工具存在的价值是为了提高测试效率，用软件来代替一些人工输入。
测试管理工具是为了复用测试用例，提高软件测试的价值。
一个好的软件测试工具和测试管理工具结合起来使用将会使软件测试效率大大的提高。
11.1.WinRunner
Winrunner 最主要的功能是自动重复执行某一固定的测试过程，它以脚本的形式记录下手工测试的一系列操作，在环境相同的情况下重放，检查其在相同的环境中有无异常的现象或与预期结果不符的地方。可以减少由于人为因素造成结果错误，同时也可以节省测试人员大量测试时间和精力来做别的事情。功能模块主要包括：GUI map、检查点、TSL 脚本编程、批量测试、数据驱动等几部分
11.2.LoadRunner
商业化-挣钱 性能测试工具 响应时间，CPU，内存，吞吐量…
LoadRunner? 是一种预测系统行为和性能的工业标准级负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner 能够对整个企业架构进行测试。通过使LoadRunner ，企业能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。LoadRunner 是一种适用于各种体系架构的自动负载测试工具，它能预测系统行为并优化系统性能。LoadRunner 的测试对象是整个企业的系统，它通过模拟实际用户的操作行为和实行实时性能监测，来帮助您更快的查找和发现问题。此外，还能支持广范的协议和技术，为您的特殊环境提供特殊的解决方案
11.3.QTP
QTP是一个B/S系统的自动化功能测试的利器,软件程序测试工具。Mercury的自动化功能测试软件QuickTest Professional ，可以覆盖绝大多数的软件开发技术，简单高效，并具备测试用例可重用的特点。Mercury QuickTest Pro 是一款先进的自动化测试解决方案，用于创建功能和回归测试。它自动捕获、验证和重放用户的交互行为。 Mercury QuickTest Pro为每一个重要软件应用和环境提供功能和回归测试自动化的行业最佳解决方案。
11.4.TestDirector
测试管理工具
基于WEB的测试管理工具，他能够让你系统地控制整个测试过程，并创建整个测试工作流的框架和基础，使整个测试管理过程变得更为简单和有组织。他能够帮助你维护一个测试工程数据库，并且能够覆盖你的应用程序功能性的各个方面。T并且还为你提供了直观和有效的方式来计划和执行测试集、收集测试结果并分析数据。还专门提供了一个完善的缺陷跟踪系统。并可以同Mercury公司的测试工具、第三方或者自主开发的测试工具、需求和配置管理工具、建模工具的整合功能。你可以通过他进行需求定义、测试计划、测试执行和缺陷跟踪，即整个测试过程的各个阶段
11.5.Selenium
自动化测试工具 支持java python的脚本 python
自动化–写好脚本，运行脚本，自己执行，自己出测试报告，自己发送到测试和开发邮箱
80%bug 手动测试出来
Selenium是为正在蓬勃发展的web应用开发的一套完整的测试系统。Selenium测试直接运行在浏览器中，就像真正的用户在操作一样。它的主要功能包括：测试与浏览器的兼容性——测试你的应用程序看是否能够很好得工作在不同浏览器和操作系统之上。测试系统功能——创建衰退测试检验软件功能和用户需求。支持自动录制动作和自动生成。Selenium的核心Selenium Core基于JsUnit，完全由JavaScript编写，因此可运行于任何支持JavaScript的浏览器上，包括IE、Mozilla Firefox、Chrome、Safari等
11.6.Appium
自动化测试工具，android和ios软件 手机App app
Appium是一个开源、跨平台的，适用于原生或混合移动应用(hybrid mobile apps)的自动化测试平台。Appium使用WebDriver（JSON wire protocol）驱动安卓和iOS移动应用.Appium的设计哲学是不要为了移动端的自动化测试而重新发明轮子，重新写一套惊天动地的api，也就是说webdriver协议里的api已经够好了，拿来改进一下就可以了另外Appium可以把server放在任意机器上，哪怕是云服务器都可以，所以Appium和WebDriver天生适合做云测试。
11.7.Jmeter
开源，免费，简单，易操作。 开源组织，支持脚本录制，支持抓包测试，支持测试移动端软件
压力和负载测试
11.8.PostMan
接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。
接口测试的目的是测试接口，尤其是那些与系统相关联的外部接口，测试的重点是要检查数据的交换，传递和控制管理过程，还包括处理的次数。外部接口测试一般是作为系统测试来看待的。
接口自动化
接口上传参数的正确性，和服务器返回值的正确性，容错性验证(滴滴)，以及安全性检测。
11.9.抓包测试
包是指数据包.目的是分析包的内容与相关协议,然后衡量是否符合当初的设计或排除故障.
在被测接口并没有明确的接口文档给出时，我们需要借助抓包工具来帮助测试，利用抓包工具我们几乎可以获得接口文档中能给你的一切
Charles，fiddler 抓包工具
抓浏览器，抓手机APP请求