三、基于“运行期缺陷密度”的规则

　　把软件运行一个CPU小时发现的缺陷数称为“运行期缺陷密度”。绘制“运行时间－缺陷数”的关系图，如果在相邻n个CPU小时内“运行期缺陷密度”全部低于某个值m时，则允许正常结束测试。例如n大于100，m小于等于1。该规则比较适用于验收测试阶段，即客户试运行软件期间。

　　需求经常变更怎么办

　　需求变更可能会让项目所有成员遭殃，如何“预防变更”以及“降低变更的代价”是软件工程的经典问题。本节仅论述需求变更对测试的影响。

　　需求变更将导致软件设计和实现的变更，也导致了测试变更。让人难过的是上一次测试有可能白做了，如果软件变更比较大的话。

　　测试人员不要只是自认倒霉，应当主动作些应变：

　　（1）及时了解需求变更的详细情况，尽早调整测试计划，不要闷头按原计划测试。

　　（2）将软件中稳定的部分与易变的部分区别对待，前者先测试，后者后测试。

　　（3）向领导反映需求变更对测试造成的影响，为自己争取余地。

　　（4）设计一些比较灵活的测试用例，能适应某些变更（不过技术难度比较高）。

　　引申问题：如果在系统测试时，对照需求文档，发现软件多了功能或少了功能，该怎么办？

　　如果发现软件少了功能，测试人员不可为了少干些活而隐瞒事实。如果发现软件多了功能，测试人员不可认为这些功能反正是“锦上添花”，便自作主张地测试了事。两种情况都要报告给项目经理，有可能导致一系列的变更。

　　测试规范

　　测试流程

　　第一步：制定测试计划。该计划被批准后转向第二步。

　　第二步：设计测试用例。该用例被批准后转向第三步。

　　第三步：如果满足“启动准则”，那么执行测试。

　　第四步：撰写测试报告。

　　第五步：消除软件缺陷。如果满足“完成准则”，那么正常结束测试。

　　测试信息流