全程软件测试（四十八）：软件测试过程管理实践—读书笔记

本篇以一个实际项目的系统测试过程（不分析单元测试和集成测试过程）的几个关键过程管理行为为例，来阐述上篇《全程软件测试（四十七）：软件测试过程管理理念—读书笔记》中提出的测试理念。

在一个协同办公系统项目中，前期需求不明确导致开发周期相对较长，为了对项目进行更好的跟踪和管理，项目采用增量和迭代两种过程模型进行开发。整个项目开发共分为三个阶段完成：

第一阶段，实现企业资源计划（Enterprise Resource Planning,ERP）部分的简单功能和工作流；

第二阶段，实现固定资产管理、财务管理，并完善第一阶段的ERP系统功能；

第三阶段，增加办公自动化（Office Automation,OA）系统。

该项目每一阶段工作都是对上一阶段成果的一次迭代完善，同时叠加新功能。

策划测试过程

依据传统的方法，将系统测试看作软件开发的一个阶段，系统测试执行工作将在三个阶段全部完成后开展。很明显，这样做不利于及时发现缺陷。有些缺陷可能会到项目后期才被发现，届时缺陷修复成本将大大提高。

依据“独立的、迭代的测试”理念，在本系统中，应对测试过程进行独立的策划，并找出测试准备就绪点，在就绪点及时开展测试。故而，在该系统开发过程中，软件测试团队计划开展三个阶段的系统测试，每个阶段系统测试都有不同的侧重点，其目的在于更好地配合开发工作并尽早发现软件缺陷，降低软件成本。软件开发与系统测试过程的关系如下图1所示。

图1 软件开发与系统测试过程关系图

实践证明，这种做法达到了预期的效果。与开发过程紧密结合而又相对独立的测试过程，有效地在早期发现了许多系统缺陷，从而降低了开发成本，同时也使基于复杂开发模型的测试管理工作变得更加清晰。

把握需求

在本系统开发过程中，需求的获取和完善贯穿于每个阶段。对需求的把握在很大程度上决定了软件测试工作是否能取得成功。

系统测试不仅要确认软件是否正确实现功能，还要确认软件是否满足用户的需求。根据“尽早测试”和“全面测试”的原则，在需求的获取阶段，测试人员参与到了对需求的讨论之中。测试人员与开发人员及用户一起讨论需求的正确性与完善性，同时还从可测试性角度对需求文档提出建议性意见。

这些意见对开发人员来说，是从一个全新的思维角度提出的约束。同时，测试团队基于前期对项目的了解，能够很轻松地制订出完善的测试计划和方案，对各阶段产品的测试方法及进度、人员安排进行策划，使整个项目的进展有条不紊。

大量实践证明，测试人员在早期就参与需求的获取和分析，有利于测试人员对需求的理解和掌握，同时也极大地提高了需求文档的质量。在把握需求的同时，测试人员在早期就将项目计划和方案制订完毕，测试活动也准备就绪，这将大大提高测试工作的效率。

变更控制

变更控制体现的是“全过程测试”理念。在软件开发过程中，需求的变更往往是不可避免的，也是造成软件风险的重要因素。

在本系统的一系列测试中，仅第一阶段就发生了9次需求变更，进而调整了2次进度计划。根据“全过程测试”理念，测试团队密切关注开发过程，跟随进度计划的变更调整测试策略，依据需求的变更及时补充或修改测试用例。

在测试执行过程中，测试用例达到了高效的复用与高质量的覆盖，测试的进度也并没有因为需求的变更而受到过多影响。

度量与分析

对测试过程的度量与分析同样体现了“全过程测试”理念。对测试过程的度量有利于及时把握项目情况；对过程数据进行详细分析有利于发现优劣势，进而找出需要改进的地方，及时调整测试策略。

在协同办公系统项目的测试过程中，测试人员对不同阶段的缺陷数量进行度量，并分析测试执行是否充分。如下图2所示，若单位时间内发现的缺陷数量呈收敛状态，则测试是充分的。在缺陷数量收敛的状态下结束细测是恰当的。

测试过程中，对不同功能点的测试数据覆盖率和发现问题数进行度量，是为了分析测试用例的充分度与缺陷发现率之间的关系。如下表所示，将类似模块进行对比发现：每一功能点上被覆盖的测试数据组越多，该用例缺陷发现率越高。

如果再结合工作量、用例执行时间等因素进行统计分析，便可以找到适合实际情况的测试用例书写粒度，从而帮助测试人员判断测试成本与收益间的最佳平衡点。

图2 不同测试阶段缺陷数量

表11.1 测试数据覆盖率与缺陷发现率对应表

通过统计可以得出测试数据与缺陷发现率之间的关系，便于及时调整测试用例编写策略。

所有这些度量都是对测试全过程进行跟踪的结果，是及时调整测试策略的依据。对测试过程的度量与分析能有效提高测试效率，降低测试风险。同时，度量与分析也是软件测试过程可持续改进的基础。