软件测试理论

优点：
有利于大型软件研发过程中人员的组织和管理
有利于开发方法和工具的使用
提高了软件的质量和开发效率
每个阶段认真完成每个阶段的工作，不需要管其他的事情，时间充足，可以测试的非常细致。
缺点：
不灵活
当需求发生改变的时候，需要返工，工作量巨大，因为瀑布式开发到了项目的最后阶段才能看到结果
不适合需求变化比较频繁的项目。----适合政府项目

2.2 V模型

用户需求-->需求分析-->概要设计-->详细设计-->编码-->单元测试-->集成测试-->系统测试-->验收测
试
优点：
软件测试分为若干个级别，更能提高软件的质量
软件测试和开发级别一一对应
缺点：
忽略了软件测试的对象不只是程序，还包括文档
验收测试是最后阶段，需求阶段的问题只能到验收测试才能发现

2.3 W模型

优点：
W模型，又称双V模型，测试活动和开发活动同步进行
软件测试的对象不仅仅是程序，还包括文档
尽早测试可以降低开发成本
缺点：
无法迭代（相对的，不是绝对的）

2.4 X模型

最早引入探索性测试的模型
软件分为几个片区，然后集成在一起形成最终的软件

2.5 螺旋模型

非线性化的研发模型
引入了风险管理，进行评估

2.6 快速原型

又称原型定义，非线性的研发模型，主要是适用于小公司，客户到了最后才知道软件的最终模样。先做成一个demo（模型或者样本），给客户进行产品的预演。

2.7 迭代开发

每次只设计和实现产品的一部分，通过逐步完成的方法叫做迭代开发，每次设计和实现一个阶段叫做迭代。
优点：
降低需求变更的成本
得到早期的用户反馈
持续的集成和测试

2.8 敏捷开发

前提条件：这个项目大部分的功能已经完成的。
概念：以人为本（客户）以沟通反馈为主
优点：
敏捷开发确实是项目进入实质开发的阶段，用户很快可以看到一个基线架构版的产品，敏捷注重市场快速反应能力。适合需求变化比较频繁的项目。
缺点：
对开发和测试人员的技能较高
时间比较紧张，测试可能没有那么深入

2.9 软件的生命周期

需求->设计-->编码-->测试-->维护-->升级-->废弃

2.10 软件的测试流程

需求分析-->测试计划-->测试方案-->测试用例-->测试执行-->测试报告

3. 软件测试的分类

3.1 按照阶段划分

单元测试--集成测试--系统测试--验收测试

1.单元测试
       对于软件中的最小可测单元进行检查和验证：如java中的类，C语言中的函数，UI页面中的窗口等
       单元测试的依据：详细设计
       谁测试：90%是开发人员测试，因为必须有代码的阅读能力
       单元测试能够发现80%左右的缺陷
       单元测试工具：java中的junit，python语言中的pytest，unittest
       单元测试侧重检查程序内部结构，逻辑控制和异常处理
   2.集成测试
       在单元测试的基础上，把模块组装成系统或者子系统，然后进行测试，又称联合测试，组装测试
       集成测试的依据：概要设计
       谁来做：软件测试工程师
       侧重检查模块与模块之间及接口传递数据的正确性
   分类：
       非增量式集成：又称一次性集成
       增量式集成：
       自顶向下增量式集成需要编写：测试桩
       自底向上增量式集成需要编写：驱动程序
   3.系统测试
       将软件，硬件，网络等设备连接系统进行测试
       依据：需求规格说明书（产品经理编写的需求文档）
       分类（或范围）：
       功能测试：测试软件的功能是否正常实现
       性能测试：测试系统所消耗的时间和资源
       压力测试：测试系统在什么情况下会达到极限
       容量测试：测试系统最大的访问用户数
       安全测试：验证系统是否容易被攻击
       可用性测试：验证系统是否使用方便
       安装测试：安装和卸载
       配置测试：测试系统软件和硬件的最优配置
       异常测试：检查系统对于异常情况下的处理
       备份测试：系统的数据备份
       健壮性测试：用于测试系统出现故障时，能否自动恢复或者忽略故障继续运行
       文档测试：测试帮助文档
       在线帮助测试：联系产品的售后客服
       网络测试：不同网络下的使用情况，5G，4G，3G，2G，WIFI
       稳定性测试：软件长时间运行，系统能否正常运行
       GUI测试：界面测试
   4.验收测试
       依据：用户需求，需要用户参与
       分类：
       正式验收测试
       非正式验收测试

3.2 按照技术划分

   黑盒测试：不关注软件内部逻辑结构，只关注输入和输出，关注功能和性能，适用于系统测试和验收测试
   白盒测试：与黑盒测试相反，适用于单元测试
   灰盒测试：介于白盒和黑盒之间，适用于集成测试、接口测试

3.3 其他测试

   1. 兼容性测试：将软件运行在不同的设备上，保证软件在各种设备上都能够提供正常的服务，如：web测
   试不同的浏览器，app测试不同型号的手机。
   2 .冒烟测试：又称BVT测试或者预测试，在正式测试之前，抽取项目中基本流程用例（占总用例数 10% 左
   右），全部执行通过。如果冒烟测试不通过，项目直接打回。冒烟测试之前需要搭建环境，测试时间半天
   至一天。
3. 回归测试：执行上个版本的测试用例，查看bug是否修复，或者修复的bug是否引入新的问题。

4. 需求分析

4.1 什么是需求分析

主要是解决测试什么的问题，明确测试的内容
以需求规格说明书为基础，进行细化和分解

5. 测试计划

5.1 编写人和时间

编写人：测试经理或者测试组长
编写时间：需求分析完成后，时间2-5天，在整个过程中处于不断修改的状态，保证测试计划满足实际需求

5.2 参考依据和读者对象

   参考依据：需求分析结果，项目计划
   读者对象：
   1.项目经理
   2.开发经理，产品经理
   3.组内的软件测试工程师，组外其他测试经理

5.3 如何制定测试计划

   认真做好资料的收集工作，主要收集人和设备
   明确测试目标，主要是时间目标和质量目标
   坚持5W原则，明确内容和过程
   why：测试的目的
   what：测试的范围
   when：测试的时间
   who：测试的参与人
   where：项目中输出的文档、软件包存放的位置

5.4 测试计划包含哪些内容

   项目概述，目的和范围，测试通过准则，读者对象，测试的参考资料，测试策略，硬件环境，软件环境，
   启动条件，结束条件，测试周期，人力投入，任务分配及进度，测试风险
5.4.1 测试策略
   又称测试类型，主要指的是冒烟测试、功能测试、回归测试、兼容性测试、性能测试、接口测试、安全测
   试等
5.4.2 测试的启动条件和结束条件
启动条件：
   1.测试用例编写完成，并通过评审
   2.开发编码完成，并通过自测
   3.开发提交了转测试申请单及相关配置
   4.测试环境搭建完成，冒烟测试通过
   结束条件：
   1.测试任务全部完成，人力投入充分
   2.需求覆盖率一般达到100%，测试通过率一般达到100%
   3.缺陷密度达到预定标准
   a) 预定标准： a) 预定标准：
   高验收标准：3-5个，一般验收标准：6-10个
   b) 缺陷密度的计算方式：缺陷密度=bug总数/总代码量，代码量单位：KLOC，千行 b) 缺陷密度的计算方式：缺陷密度=bug总数/总代码量，代码量单位：KLOC，千行
   4.bug趋势呈正态分布或者收敛趋势
   5.需求规格说明书所有功能全部实现
   6.交付件齐全，系统测试通过

6. 测试用例

6.1 测试用例的概念

       测试方案和测试用例均属于测试的设计文档，测试用例描述了一个输入动作和一个期望结果，目的是确定程序的某个功能是否正常工作。
6.2 参考依据
       需求规格说明书，需求分析结果，测试方案
6.3 编写人和时间
       编写人：具有丰富经验的软件测试工程师
       编写时间：测试方案编写完成并通过评审，编写时间占整个项目周期30% 左右
6.4 编写的工具和输出的文档
       输出文档：测试用例
       编写工具：Excel 、Word、Zentao（禅道）、Bugfree...
6.5 评审人
       组内的软件测试工程师、产品经理、开发代表、测试经理、项目经理、QA
6.6 用例组成
       用例编号、功能模块、标题、优先级、预置条件、操作步骤、预期结果、设计人、设计日期、备注

7. 黑盒测试用例的设计方法

7.1等价类

有效等价类：指对程序的规格说明书来说是合理的，这些数据构成的集合称为有效等价类
无效等价类：指对程序的规格说明书来说是不合理无意义的输入的数据构成的集合，称为无效等价类

7.2边界值

   边界值是对等价类方法的补充
   上点：取范围的端点，不用关注端点的取值到底是有效还是无效
   离点：取值范围端点左右两边的值
   内点：取值范围大概中间的值

7.3错误推测法

基于经验和直觉，推测程序中所有可能存在的各种错误，从而针对性地设计测试用例，如：
   1.日历控件中需要考虑闰年的2月29日和平年的2月28日
   2.对于多条相同的数据怎么排序
   3.密码中加入空格
   4.密码不支持拷贝，但是可以在密码输入框中粘贴内容
   5.两个用户同时删除同一条数据，一个成功，一个失败
   6.不勾选数据，删除数据，应有相应的提示

7.4场景法

   场景法又称流程分析法，是将软件系统的某个流程看成路径，使用路径分析的方法来设计测试用例，根据
   用例的顺序依次进行组合，使得流程的各个分支都能覆盖
   基本流：主场景，流程的主干
   备选流：可选场景，流程的分支

7.5用例设计方法选择策略

   1.对于业务系统清晰的系统，可以采用场景法贯穿整个测试流程（主要用于冒烟测试和回归测试）
   2.进行等价类划分，将无限的测试变为有限
   3.然后结合边界值分析方法进行补充
   4.然后使用错误推测法追加一些异常场景的测试用例

8. 测试执行

   概念：根据编写的测试用例，按照用例步骤进行测试，查看预期结果和实际结果是否一致，如果不一致则为bug（缺陷）
   参考依据：测试用例
   执行人：软件测试工程师
   开始时间：测试用例编写完成并且通过评审，且达到测试执行的启动条件
   时间周期：占整个项目周期40% 左右的时间

9. 测试用例的执行结果状态

   new：用例编写完成后，未开始执行的状态
   pass：执行用例预期结果和实际结果一致
   fail：执行用例的预期结果和实际结果不一致
   block：当因为软件有缺陷妨碍了用例的执行，并且该缺陷不是该用例关注的重点
   investigate：当用例在执行过程中需要消耗较多的时间来观察期间的结果

10.测试过程中的注意事项

   搭建测试环境
   测试用例需要全部执行
   不要忽视任何偶现bug
   加强测试过程中的记录
   提交缺陷和开发关系处理恰当
   提交一份优秀的问题报告单
   及时更新测试用例
10.1提交的缺陷开发不认可，怎么处理？
   1.首先进行自我检查，依据需求确定该缺陷是否有问题
   2.确认是问题，拿出依据与开发人员有理有据地沟通
   3.沟通无效，告知测试经理，将问题升级到项目变更控制委员会CCB进行裁决是否为问题
10.2测试执行的过程中发现bug太多，你会怎么处理？
   1.冒烟测试进行的不充分，不彻底
   2.发现bug越多的模块，残留的bug也越多，同时说明开发编码质量太差，会影响到测试的质量和效率
   3.我们需要把版本打回，要求开发人员自测，自测通过之后再提交代码
10.3 幽灵（偶现）bug的处理方式
   1.截图，保留证据，必要时录制视频，抓包，查看日志文件
   2.在本机进行多次尝试该问题，若是能够重现该问题，则记录
   3.若是本机不能复现，在其他电脑上尝试能否重现
   4.在其他电脑上也无法重现，但是问题比较严重，找到开发人员进行协助定位
   5.对于难以重现的问题，需要将问题单挂起，看后续版本是否存在，后续版本如果不存在，则关闭

11.缺陷的组成

缺陷ID，缺陷标题，缺陷状态，缺陷级别，缺陷的优先级，测试版本，测试阶段，缺陷类型，重现步骤
（缺陷描述），实际结果，预期结果，缺陷所属模块，提交人，提交时间，修改人，修改时间，关闭时间

11.1.bug的优先级

1（致命）2（严重）3（一般）4（轻微）

11.2缺陷的生命周期

提交-->确认-->分配-->修改-->验证-->关闭

11.3 常用的bug管理工具

禅道（zentao）、bugfree、mantis、DTS（华为）

12. 测试报告

   概念：主要是对测试结果、测试过程中的质量和产品进行度量，总结和描述
   参考依据：测试计划，测试用例执行结果，缺陷数量
   负责人：测试组长或者测试经理
   时间：测试用例执行完成达到测试结束标准，时间为1-2天
   评审人：组内的软件测试工程师，开发代表，产品经理，测试经理，项目经理，QA
   测试报告组成：
   项目背景，测试目的，测试范围，测试策略，测试环境，测试工具，人员构成，人力资源和工作量的数据
   统计，用例数，缺陷数，遗留问题，测试风险
   测试用例的数据统计：
如：三个月的项目测试用例在1200-1500 左右
   一个月迭代一次项目用例在200 左右
   缺陷数据统计：
   三个月项目缺陷在270-300 左右
   一个月迭代一次的项目缺陷在80-100 左右
   测试时间安排：项目的时间安排、需求分析、用例、执行、报告的时间安排

13. 测试流程

   1.产品经理进行需求调研，搜索用户需求，整理出一份需求规格说明书
   2.产品经理组织开发和测试，召开需求讲解会议，会议结束后，开发和测试均得到需求规格说明书
   3.开发和测试深入了解需求文档，提出对需求文档有疑问的地方
   4.产品经理召开会议给开发和测试澄清疑问
   5.软件测试工程师对自己负责的模块进行需求分析，完成后组织项目组内部测试人员和开发人员进行评审
   6.评审后根据评审意见修改需求分析文档，测试经理开始编写测试计划，安排后期测试过程中的人力投入
   和各阶段的时间安排
   7.软件测试工程师开始编写测试用例，完成后进行评审
   8.开发编码完成后，从SVN上获取安装包，搭建测试环境
   9.软件测试工程师开始执行冒烟测试，通过后，进行正式的测试，如果不通过，版本打回
   10. 正式的测试分为三轮，达到测试结束标准，终止测试
   11.测试经理开始编写测试报告，软件提交预发布流程，审核通过后，开始安排上线时间点
   12.上线后对主功能进行测试，成功上线后，开始下一轮的需求迭代