| 分类 |
清单 |
说明 |
需求
| 产品片的业务需求、用户需求、功能需求和系统需求是否完整、清晰 |
检查需求的质量，确保需求能够有效知道开发和测试 |
| 开发人员在进行产品设计之前是否充分理解了产品的需求 |
在项目种非常容易出现开发人员并没有完全理解产品的需求，就开始设计编码，直到系统测试阶段才发现和需求不符的问题。一旦出现这样的问题，产品很有可能就会返工，对产品来说是致命的打击。 |
设计
| 是否使用了“新技术” |
包括产品之前未使用的新构架、新平台、新算法等 |
| 系统中是否会存在一些设计“瓶颈”？如果存在，是否有应对措施 |
例如，产品的老架构能否满足产品新增的特性的性能、可靠性方面的要求 |
| 产品是否设计得过于复杂，难以理解？ |
再项目种，难以理解的设计，问题往往也是比较多的。所以需要重点关注。 |
| 开发人员是否能够讲清楚产品设计 |
一般来说，开发人员是可以讲清楚自己的设计。如果开发人员无法讲清楚自己的设计，说明设计本身就存着一些问题。这部分设计的可维护性，可移植性就可能不会太好 |
| 开发人员对异常、非功能方面的内容是否考虑得足够全面 |
例如，如果数据被损坏，会发生什么？如何处理？这个功能的使用的资源或者组件有没有可能被其他功能修改或者影响。有没有考虑过最大负载，容灾，灾备。 |
| 开发人员在设计中是否存在一些比较担心的地方？ |
测试人员可以适当关注开发人员的主观感受，而不仅仅是设计文档 |
| 开发人员是否会考虑和设计一些测试性或者易于定位的功能 |
由“不易于验证的设计”可以推测出开发人员在设计编码时的自检可能也是不充分的，这部分代码质量可能并不高，相对风险较高 |
| 对于一个需要多人（或者多组）才能配合完成的功能，是否有人会进行整体的设计，协调和把关？ |
当开发人员的设计会依赖于其他设计时，开发人员一般会假设接口能够满足需求，而忽视彼此的沟通和确认的环节，使得产品再集成开发时候出现问题，影响产品质量和项目进度 |
| 对有依赖或约束的内容，是否有充分的考虑 |
例如，与产品配套的日志、审计类产品是否能够满足产品的发布周期？与产品相关的平台是否稳定？ |
流程
| 项目是否使用了新的流程，开发方法等 |
例如，从传统瀑布开发模式到开始使用敏捷开发的模式 |
| 开发人员是否会进行自测？是如何进行自测的？测试的深度和发现问题的情况如何 |
开发自测是产品代码质量的重要保证活动。测试需要关注开发人员的自测方法和发现问题的清空。一般来说，自测充分的模块，代码质量可能会相对较好，反之就可能会比较差。 |
| 开发人员如何进行代码修改，是如何保证修改的正确性 |
例如，开发人员是否会对修改方案进行评审？是否会对修改的代码进行检视和评估？是否会对修改进行测试验证？是否会进行回归测试等 |
| 开发人员是如何进行版本管理的？ |
例如，开发人员是否存在版本分支管理混乱的问题？是否会随意修改、合入代码，而不对变动做记录和控制。 |
变更
| 新版本在旧功能方面做了哪些修改？修改后的主要影响是什么？ |
|
| 在项目过程中，需求是否总是在变更？ |
|
组织和人
| 那些模块是由其他组织开发的？他们在哪里开发？开发流程、能力如何？ |
|
| 产品的研发团队（包括需求、开发和测试）是否存在于不同的地方？彼此分工如何？沟通是否顺畅？ |
|
| 团队人员能力如何？经验如何（包括需求、开发和测试团队）？ |
|
| 团队是否稳定（包括需求、开发和测试团队）？ |
|
| 团队的人手是否充足（包括需求、开发和测试团队）？ |
|
| 测试环境是否具备（包括必备的工具、硬件设备）？ |
|
历史
| 哪些特性在产品测试时就存在很多bug？
|
根据“bug聚集性”的力量，历史上的bug重灾区，当前版本可能继续需要重点关注 |
| 哪些特性存在较多的客户反馈问题？ |
客户反馈的问题比较多，说明之前可能存在一些测试不充分的地方，在当前版本需要重点关注 |
| 历史上哪些情况曾经导致过阻塞测试活动的问题？ |
需要对这些问题进行根因分析和总结，防止同意的问题在新的项目中再度发生，历史悲剧再度重演 |
