三、基于“运行期缺陷密度”的规则
把软件运行一个CPU小时发现的缺陷数称为“运行期缺陷密度”。绘制“运行时间－缺陷数”的关系图，如果在相邻n个CPU小时内“运行期缺陷密度”全部低于某个值m时，则允许正常结束测试。例如n大于100，m小于等于1。该规则比较适用于验收测试阶段，即客户试运行软件期间。
需求经常变更怎么办
需求变更可能会让项目所有成员遭殃，如何“预防变更”以及“降低变更的代价”是软件工程的经典问题。本节仅论述需求变更对测试的影响。
需求变更将导致软件设计和实现的变更，也导致了测试变更。最让人难过的是上一次测试有可能白做了，如果软件变更比较大的话。
测试人员不要只是自认倒霉，应当主动作些应变：
（1）及时了解需求变更的详细情况，尽早调整测试计划，不要闷头按原计划测试。
（2）将软件中稳定的部分与易变的部分区别对待，前者先测试，后者后测试。
（3）向领导反映需求变更对测试造成的影响，为自己争取余地。
（4）设计一些比较灵活的测试用例，能适应某些变更（不过技术难度比较高）。
引申问题：如果在系统测试时，对照需求文档，发现软件多了功能或少了功能，该怎么办？
如果发现软件少了功能，测试人员不可为了少干些活而隐瞒事实。如果发现软件多了功能，测试人员不可认为这些功能反正是“锦上添花”，便自作主张地测试了事。两种情况都要报告给项目经理，有可能导致一系列的变更。
测试规范
测试流程
第一步：制定测试计划。该计划被批准后转向第二步。
第二步：设计测试用例。该用例被批准后转向第三步。
第三步：如果满足“启动准则” ，那么执行测试。
第四步：撰写测试报告。
第五步：消除软件缺陷。如果满足“完成准则”，那么正常结束测试。
测试信息流
