项目先前定义的测试范围在后续的计划、方案中是否有遗漏?

　　在测试初始期我们一直强调测试范围的必要性，在测试实施阶段还需要检查前期规划的测试范围是否在后续的计划活动中覆盖完全了，只有计划中完全的覆盖了所列的测试范围，才能保证系统的质量。

　　项目的测试过程是否按照公司预计的测试过程执行?

　　在测试实施阶段，还需要了解测试人员是否按照公司要求在执行所有的测试活动，但是要在短时间内了解，手段只能是听测试经理陈述他们的测试过程，再加以判断。如果公司有SQA人员，工作就相对简单了，只需要到配置管理库中找到SQA的检查报告，这些疑问就一目了然了。

　　测试结项期

　　在这个阶段，主要的测试工作已经进行完毕，最终的发布版本也已经准备出来。测试经理开始书写最终的测试报告，申请发货。

　　作为测试的监控者，这个阶段的主要任务就是评估软件产品的质量，依据已有的数据评估测试工作是否做到位，产品是否可以发布。

　　在这个阶段，应该如何进行监控，问些什么问题?

　　测试中发现的缺陷趋势曲线是否处于收敛状态?各个分模块的缺陷趋势曲线是否基本一致?

　　测试完成后，判断产品是否能够发货的一个重要条件就是：缺陷趋势曲线处于收敛状态，并且持续一段时间，表示系统处于稳定状态，满足发货条件。

　　那为什么还要看各个分模块的曲线是否一致?因为，有的系统比较庞大，有可能某一个局部的缺陷曲线还没有处于收敛状态，但是整个系统的缺陷趋势图已经把这个信息掩盖掉了。所以，还需要分别看一下各个模块的趋势曲线，确保系统的每一个部分都处于稳定状态，这样发货的风险才能降到最低。

　　是否有评判产品能否发货的文字性材料?

　　发货前，测试经理或者项目经理必须提交一份整个系统的整体质量说明，以文档的形式证明整个系统质量稳定，达到用户要求，可以发货。

　　在这个过程中，如果和客户有关于质量的约定，还需加入，如：用户签字认可的验收报告，用户签字认可的性能测试报告等。

　　是否召开了正式的最终评审会议?会议的参与评审人员是否有公司主管的高层?是否有用户或者能体现用户方意见的人员参与?所有的遗留问题是否都有了明确的解决方案，并且有相关的责任人负责问题的解决和跟踪?

　　在发货前，还需要召开正式的评审会议，而且会议必须有项目组以外，主管该项目的公司高层和能体现用户方意见的人员参加。因为，一般系统中或多或少都会遗留一些缺陷，这些缺陷到底应该如何处理，会给公司和客户带来多大的麻烦，都应该在这个阶段做一个评估，以决定该产品是否能够发货。

　　当一个问题确定遗留在系统中后，还需要对这个遗留问题有个明确的解决办法，如：在升级版本中修改，建议用户用以下方式绕过，或者干脆不再进行修改，都应该有一个明确的答复，而且还需要指派专门的人员跟踪问题的解决情况，并进行报告。

　　在测试初始期确定的结项条件是否都得到了满足?

　　为了能保证系统的正常交付，在前期和用户做了一些交付的约定条件，在这个阶段，需要确定这些条件是否都得到了满足，并有相关的证明。

　　如：性能指标是否满足用户要求，用户是否签字确认。验收测试是否完成，用户是否签字确认。后续的试运行期的方案是否完成，用户是否同意，是否有明确的截至条件等。

　　以上以一个测试监控者的角度，探讨了如何对软件测试工作进行监控。

本站技术原创栏目文章均为中睿原创或编译，转载请注明：文章来自中睿，本站保留追究责任的权利。