4）统计错误在子系统中的分布
根据错误易集聚的特征，在哪里发现的错误越多，此部分应进一步发现更多的错误。但质量风险的规则是要求尽早排除最具影响力的错误，而不是错误的个数。因此实际过程中要着眼大局、统筹兼顾，个别测试者可能因为自己发布的错误未修改而烦恼，因为这些讯而未决问题可能影响他/她开展进一步的工作，或者开展其他工作，所以管理者要注意到这种不同步问题，合理安排这些测试人员的工作。
5）统计缺陷发现比例
DDP＝bugstesters/（bugstesters+bugscustomers）×100%
所有错误指真正的错误。不包括重复错误、不成问题的问题，顾客、用户、配置错误，以及其他假现场问题报告，包括延迟或因优先权决定没有修复的错误。不重复计算测试人员发现但未修复又被客户发现的错误。
对于膝上电脑，发布3～6月后，几乎不会再发现新问题。
6）合理使用度量和图表
避免将度量表用于对个别人员的指责或者作为考核指标，这样不利于下一步的合作及团队建设。
8、管理错误跟踪
当项目进行到测试执行阶段时，发现和解决错误大约占10％～20％工作量。错误报告是测试工作最重要的“产品”。主要的工作量在测试系统及用例设计上。
1）错误数据的误用和策略
当错误数据的被误用时，容易形成敌对关系，不利于以后开展，因而要慎重使用统计数据。
（1）要建立信任感
错误不应针对个人，不杂个人情感。
只提交质量错误报告：简要、清晰再现故障步骤，隔离证据，精确分类，对优先级和严重性的保守估计。
开放的心态讨论错误报告，与开发人员做好沟通。不要想当然，避免误解，认真听取开发人员的辩解：有些被测试人员认为错误的东西，可能实际上是正确的行为。有些内容可能需要改变表达方式。
（2）分清责任
识别、再现、隔离错误，报告、跟踪、重新测试以及总结错误是测试人员的责任，是否修复、如何修复、何时修复是其他人应考虑的事情。
（3）不应针对个人，不适合按开发人员分类统计，至少这一信息不应传递给测试团队之外的人员。
2）避免陷入困境
（1）错误还是特性
项目材料可能只有非形式化的规格说明、电子邮件式需求分析、产品路线图、销售资料等。
如果在征询各部门意见后，开发人员依然不接受错误，只好暂时关闭，记录测试人员的不同意关闭的说明。
（2）无法再现的错误
有些错误不能连续的再现，可能需要复杂的条件组合。不管是否再现都应当记录下来。特别是一些对客户至关重要的故障。
错误意外修复，最好能确认错误真实消失。
（3）延迟次要的错误，还是遗漏测试？
延迟修复的被认为次要的错误，可能回来捣乱，优先级的分配可能需要讨论。被确认延迟的次要的错误，不属于遗漏测试，但可能在客户那里表现为严重错误。
出现以上问题，要及时与有关方面协商如何解决，记录讨论结果，避免在后来出现问题时互相指责。从测试角度分析后来发现问题是否曾经测试出来，如果没有测试出来，进一步弄清出现问题的程序是否是已测试通过且批准发布的程序，有可能是新修改未经测试的程序，或者真是由于测试不全导致的测试遗漏问题。如果是测试遗漏问题，测试团队应检讨自己的各项工作，建议用逆向反推法查找测试团队问题的根本原因：工作方法问题？测试规程问题？执行过程问题？人员问题其他资源问题？等等，然后针对问题原因制订改进措施，跟踪验证改进效果。
相关链接：
