| 小 类 | 关 注 点 |
| 测试需求 | 测试人员要参与需求文档的评审，需求人员要参与测试用例的评审。 |
| 可以先通过思维导图识别测试要点，再设计测试用例。 |
| 测试计划 | 如果有测试有关的性能模型与性能基线，在测试之前应该用性能模型或性能基线对测试过程的输出结果做预测，比如测试工作量、用例个数、缺陷个数等。 |
| 测试策略中对于测试轮次、每轮的测试方法、测试重点要有定义。 |
| 要重视随机测试或探索式测试的作用，它们的效率可能高于基于用例的测试，组织级可以对此进行定量的对比分析，看看发现缺陷的效率是否有所不同。 |
| 针对测试环境与实际环境的不一致要识别相关风险，并有对应的措施。 |
| 测试过程的入口准则与退出准则应该量化。 |
| 测试投入 | 要定义测试投入充分性的定量标准，如测试工作量的占比，测试用例的密度，单位规模的测试工作量等。 |
| 测试人员的比例或测试投入工作量的比例不能太低，比如低于10%。 |
| 静态扫描 | 静态扫描的告警应该定义修改准则，即哪些告警应该修改，哪些可以不用修改。 |
| 测试设计 | 测试用例的关注点有正常、异常、边界、等价类、猜错等多种，在设计测试用例时，应该明确注明，便于评审测试用例的完备性。 |
| 非功能性需求要有对应的测试方案，测试用例。 |
| 测试用例评审时，要对照需求进行评审，以需求为主线评审测试用例，这样便于发现测试用例的缺失。 |
| 测试结束 | 应该在测试投入的前提下，看看测试缺陷的收敛程度来判断是否可以发布产品了。在测试出口准则中要判断测试投入的充分性。 |
| 原因分析 | 要对上线后发现缺陷的原因进行分析。 |
测试 数据 分析 | 测试报告中的统计数据要先排序再画图，要有数据、有图形、有结论 。 |
| 对测试缺陷可以按模块、按现象、按原因、按注入阶段等进行分析。 |
| 要定量分析各种测试手段的有效性，如单位时间内发现的缺陷个数、缺陷清除率、缺陷密度等。 |
| 建议采用Gompertz模型分析缺陷的收敛趋势。 |
| 测试过程的单位投入与缺陷密度之间可以尝试建立性能模型。 |
| 单元测试、集成测试、系统测试发现缺陷的数量应该逐步降低，否则要分析前期测试的有效性。 |