五、软件测试阶段（单元、集成、系统、验收、回归）

五、软件测试阶段（单元测试、集成测试、系统测试、用户验收测试、回归测试）

1.单元测试

（1）完成对最小的软件设计单元—模块的验证工作；

　　目标是确保模块被正确地编码；

　　使用过程设计描述作为指南，对重要的控制路径进行测试以发现模块内的错误；

　　通常情况下是面向白盒的；

　　对代码风格和规则、程序设计和结构、业务逻辑等进行静态测试，及早地发现和解决不易显现的错误；

（2）单元测试的内容：接口测试、内部数据结构、全局数据结构、边界、语句覆盖、错误路径；

（3）单元测试的工具：OpenSource: xUnit、Junit -- Java、NUnit -- C#、DevPartner… 

（4）使用的方法技术：白盒、自动、静态；

2.集成测试

（1）通过测试发现与模块接口有关的问题；

　　目标是把通过了单元测试的模块拿来，构造一个在设计中所描述的程序结构；

　　应当避免一次性的集成（除非软件规模很小），而采用增量集成；

（2）集成测试主要内容：API、API/参数组合…

（3）使用的方法技术：白盒、黑盒、自动、静态；

3.系统测试

（1）根据软件需求规范的要求进行系统测试，确认系统满足需求的要求；

　　系统测试人员相当于用户代言人；

　　在需求分析阶段要确定软件的可测性，保证有效完成系统测试工作；

（2）系统测试主要内容：

　　所有功能需求得到满足；

　　所有性能需求得到满足；

　　其他需求（例如安全性、容错性、兼容性等）得到满足；

（3）使用的方法技术：黑盒、自动、手工；

4.用户验收/确认测试

（1）配置审查：

　　确保已开发软件的所有文件资料均已编写齐全，并分类编目；

（2）Alpha测试：

　　是由用户在开发者的场所来进行的，Alpha测试是在一个受控的环境中进行的；

（3）Beta测试：

　　由软件的最终用户在一个或多个用户场所来进行的；

　　开发者通常不在现场，用户记录测试中遇到的问题并报告给开发者；

　　开发者对系统进行最后的修改，并开始准备发布最终的软件；

（4）使用的方法技术：黑盒、自动、手工；

5.回归测试

（1）定义：

　　回归测试是对之前已测试过、经过修改的程序进行的重新测试，以保证该修改没有引入新的错误或者由于更改而发现之前未发现的错误；

　　回归测试要保证增强型或改正型修改使软件正常进行并且不影响已有的功能。

（2）回归测试方式：

　　再测试全部用例；

　　选择基线测试用例库中的全部测试用例组成回归测试包，测试成本最高；

　　基于风险选择测试；

　　可以基于一定的风险标准来从基线测试用例库中选择回归测试包；

（3）回归测试引入时机：系统测试；

（4）引入原则：开发过程发生修改或维护，就有必要进行回归测试；

（5）回归测试的用例选择：

　　项目新需求功能模块的相关模块（寻找相关模块的依据是：依赖）（调用修改模块的模块、被修改模块调用的模块、通过函数调用、与开发详细沟通修改的函数以及相关函数）；

　　产品全功能主干用例（分析主干用例，通常指冒烟用例）；

　　版本兼容、系统兼容等兼容性用例（手机端测试、APP）；

　　遗留Bug的相关用例（新需求测试遗留的bug）；

（6）回归测试完成标准：

　　开发完全停止后进行一轮回归测试；

　　回归测试完成后要求基本没有bug；

（7）回归测试理想状态：

　　执行一轮：不理想：bug没有收敛，执行多轮；

（8）回归测试可以通过人工重新执行测试用例，也可以使用自动化的捕获回放工具来进行；

 

----------------------------------------------------------------------------------------------------

一个版本结束，一般还会有迭代，那接下来就要继续新需求测试

6.新需求测试（功能需求、兼容性需求、性能需求）

（1）选择新需求测试用例：就是选择新增，或者修改的需求的测试用例；

（2）执行第一轮新需求测试：执行测试、提交bug；

（3）与项目组同步测试进度：测试日报/日志、测试完成度、多少bug；

（4）新需求测试完成标准：

　　新需求开发全部完成；

　　Bug收敛到一定的标准（无严重级别的bug、bug呈现收敛趋势）；

 

----------------------------------------------------------------------------------------------------

 一个项目在开始时，一般会先进行冒烟测试（在进行正式测试之前，先把待测试系统的主要功能测试一遍）

7.冒烟测试

（1）什么是冒烟测试：

　　冒烟测试，是对软件基本的功能进行测试，测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本的功能正常，保证软件系统能跑的起来,可以进行后续的正式测试工作，如果最基本的测试都有问题，就直接打回开发部了，所以正式交付测试的版本必须首先通过冒烟测试的考验。

　　不做冒烟测试的问题：测试人员直接测的话,测试执行一半或者刚开头，就出现基本功能有问题，无法继续测试下去的情况，这时只能中断测试，返回给开发部进行修改,这样会浪费测试部门的时间和资源。

　　冒烟测试，只是一个测试活动，并不是一个测试阶段。也就是说，冒烟测试贯穿于测试的任何一个阶段，单元测试里会有冒烟测试、集成测试里会有冒烟测试、系统测试里也会有冒烟测试。

（2）冒烟测试的原则：冒烟用例通过率100%；

（3）冒烟测试的意义：减少重复时间，提高效率、测试与开发的质量一致；

7-1.冒烟测试的流程

（1）测试人员选择冒烟测试用例：

　　选择主干流程的正向用例：从P1，P2中选择，建议在版本测试的10%—20%左右；

　　用例要尽快的执行完毕：一般在半天内执行完毕；

（2）测试人员与开发人员沟通冒烟测试用例：公司内部会有冒烟测试用例通知（通常以邮件通知）；

（3）开发人员完成开发和自测（基于冒烟测试用例）：开发完成自测后会对测试进行通知；

（4）测试人员进行正式的冒烟测试：

　　A 通过：测试人员接受版本，正式进行测试（第二次冒烟测试成功：邮件通知项目组，测试正式开始进行项目测试）；

　　B 不通过：返回步骤（3）继续执行（冒烟测试不通过：测试邮件通知开发、将测试的bug提交、判断缺陷几个，通过几个、测试通过率多少、开发修复完毕后，再进行测试）；