软件测试过程_软件开发中有哪些测试环节-CSDN博客

作为软件生命周期中的一个环节，测试可以进一步细分为不同的测试阶段和测试活动。只有完成不同测试阶段的各项测试工作，才能真正做好测试。

软件测试阶段

软件测试可以分为4个阶段—单元测试、集成测试、系统测试和验收测试，其中单元测试、集成测试和系统测试又称为研发测试。

单元测试

单元测试是针对软件基本组成单元（软件设计的最小单位）来进行正确性检验的测试工作。

单元测试的目的是检测软件模块与详细设计说明书的符合程度。

集成测试

集成测试是在单元测试的基础上，将所有模块按照概要设计说明书组装成子系统或系统，验证组装后功能及模块间接口是否正确的测试工作。

集成测试的目的是检测软件模块与概要设计说明书的符合程度。

系统测试

系统测试是将已经集成的软件系统作为整个基于计算机系统的一个元素，与计算机硬件、外部设备、支持软件、数据和人员等其他系统元素结合在一起，在实际运行（使用）环境下，对计算机系统进行的一系列的测试工作。

系统测试的目的在于通过与需求说明书作比较，发现软件与系统需求定义不符合的地方。

单元测试、集成测试和系统测试的比较

测试方法不同

●单元测试属于白盒测试。

●集成测试属于灰盒测试。

●系统测试属于黑盒测试。

考察范围不同

●单元测试主要测试单元内部的数据结构、逻辑控制、异常处理等。

●集成测试主要测试模块之间的接口和接口数据传递关系，以及模块组合后的整体功能。

●系统测试主要测试整个系统与需求的符合程度。

评估基准不同

●单元测试的评估基准主要是逻辑覆盖率。

●集成测试的评估基准主要是接口覆盖率。

●系统测试的评估基准主要是测试用例对需求规格的覆盖率。

回归测试

在测试或其他活动中发现的缺陷经过修改后，应该对软件进行回归测试（regression testing），如图2-1所示。回归测试的目的是验证缺陷得到了正确的修复，同时对系统的变更没有影响以前的功能。回归测试可以发生在任何一个阶段，包括单元测试、集成测试和系统测试。

图2-1 回归测试

回归测试的策略

如果回归测试需要考虑如何选择重新执行的测试用例，就要确定回归测试的策略。常见的回归测试策略如下。

●完全重复测试：重新执行所有在前期测试阶段建立的测试用例，以确认问题修改的正确性和修改的局部影响性。

●选择性重复测试：选择性地重新执行部分在前期测试阶段建立的测试用例，以测试被修改的程序。具体细分如下。

■覆盖修改法：针对被修改的部分，选取或重新构造测试用例以验证没有错误再次发生的用例选择方法。也就是说，这类回归测试仅根据修改的内容来选择测试用例，这部分测试用例仅保证修改的缺陷或新增的功能实现了。这种方法的效率是最高的，但风险是最大的，因为它无法保证这个修改是否影响了其他功能。在进度压力很大或者系统结构设计耦合性很小的状态下，可以使用该方法。

■周边影响法：不但要包含覆盖修改法确定的用例，还需要分析修改的扩散影响，对于那些受到修改间接影响的部分，选择测试用例以验证它没有受到不良影响。该方法比覆盖修改法更充分。这类回归测试需要分析当前的修改可能影响到哪部分代码或功能，对于所有受影响的功能和代码，对应的所有测试用例都将被回归。如何判断哪些功能或代码受影响依赖于开发过程的规范性和测试分析人员（或开发人员）的经验。对于开发过程有详细的需求跟踪矩阵的项目而言，在矩阵中分析修改功能所波及的代码区域或其他功能是比较简单的，同时有经验的开发人员和测试人员能够有效地找出受影响的功能或代码；对于单元测试而言，修改代码之后，还需要考虑对一些公共内容的影响，如全局变量、输入/输出接口、配置文件等。该方法是业界推荐的方法，适合于一般项目。

■指标达成方法：一种类似于单元测试的方法，在重新执行测试前，先确定一个要达成的指标，如完全覆盖修改部分的代码、覆盖与修改有关的60%的接口等，基于这种要求，选择一个最小的测试用例集合。

回归测试流程

回归测试也需要有流程，可参考如下流程。

（1）在测试策略制定阶段，制定回归测试策略。

（2）确定需要回归测试的版本。

（3）发布回归测试版本，按照回归测试策略执行回归测试。

（4）若回归测试通过，关闭缺陷跟踪单（问题单）。

（5）若回归测试不通过，把缺陷跟踪单返回开发人员，开发人员重新修改问题，再次提交测试人员，进行回归测试。

回归测试的自动化

回归测试是一个重用以前成果的测试，很难预料到要经过多少次回归系统才能达到满意的水平，因此，回归测试将可能演变成一种重复的、令人心烦意乱的工作，效果与人员的积极性将大打折扣。于是，回归测试的自动化非常重要。

回归测试的自动化包括测试程序的自动运行、自动配置，测试用例的管理和自动输入，测试的自动执行，测试信息与结果的自动采集，测试结果的自动比较和结论（尤其前面提到的各类数据的共享决策）的自动输出。

对于系统测试功能比较简单、测试界面相对稳定并且测试用例良好的测试来说，采用“捕捉回放”工具是比较合适的，这类工具有QTP、Robot Framework、Selenium等。为了实现测试用例的自动化并实现测试结果的自动判断，脚本化的并且包含控制结构和内部实现结果判断的测试用例是唯一的选择，此类脚本语言有Python、Ruby、Java等。

对于特定系统中复杂的测试来说，如果没有通用的商用工具可供选择，可以尝试开发专用的自动化测试工具。

回归测试的自动化（或者说工具化）是一个需要尽早考虑的问题，在确定测试方案时就要考虑这种可能性，必要时应投入资源进行开发，形成可供继承与推广的工具则是最终目的。

验收测试

当软件产品是为了特定用户开发的时候，需要进行一系列的验收，让用户验证软件产品是否满足了所有的需求。

如果软件产品是为多个用户开发的，让用户逐个进行验收测试是不切合实际的，因此往往采用α测试和β测试，以发现可能只有最终用户才能发现的问题。

在通过了内部系统测试及软件配置审查之后，就可以开始验收测试。验收测试是以用户为主的测试。软件开发人员和QA人员也应参加。由用户参与设计测试用例，使用用户界面输入测试数据，并分析测试的输出结果，一般使用生产实践中的实际数据进行测试。在测试过程中，除了考虑软件的功能和性能外，还应对软件的可移植性、兼容性、可维护性、错误的恢复功能进行确认。验收测试原则上在用户所在地进行，但如经用户同意也可以在公司内模拟的用户环境中进行。

根据合同、需求规格说明书或验收测试计划对产品进行验收测试。

验收测试的结果有两种情况。

●软件功能、性能等质量特性与用户的要求一致，可以接受。

●软件功能、性能等质量特性与用户的要求有差距，无法接受。

α测试

α测试是用户在开发环境下进行的测试，也可以是开发机构内部的用户在模拟环境下进行的测试。α测试中，软件在一个自然状态下使用。开发者坐在用户旁，随时记下错误和使用中的问题。这是在受控制的环境下进行的测试。α测试的目的主要是评价软件产品的功能、局域化、可用性、可靠性、性能、支持性（Function，Localization，Usability，Reliability，Performance，Support，FLURPS），尤其注重产品的界面和特色。α测试人员是除产品研发人员之外最早见到产品的人，他们提出的功能和修改建议是很有价值的。