项目测试总结

需求阶段
开发阶段
测试阶段

需求阶段

• 用户需求说明（用户故事）

  • 此内容无，建议给出相关文档，使大家明白产品设计初衷。

• 需求文档

  • 目前只产出简单功能原型图，无详细产品设计文档，仅定义了该模块主要功能，模块间的关联未定义或者无细节说明，存在不确定性，影响测试计划的准确性；原型图阅读后无法明确用户需求，描述无序且功能散乱。建议花更多时间完善需求文档（内容及形式）。
  • 上下游系统交互功能，产品之间未有效积极沟通，测试时才发现设计问题，后期返工再设计影响项目进度。

• 需求评审

  • 目前无评审环节，产品直接把需求给到开发，开发过程遇到问题再改需求；无产品--测试--开发三方共同沟通评审环节，无法提前发现及避免产品设计的缺陷，以致后期返工且质量不可控。建议不要忽视评审工作。
  • 评审后对需求文档变更部分进行整理总结经验，提高以后的产品设计质量。
  • 需求定稿后，不得随意更改。

• 需求版本控制

  • 目前无版本控制处理，也无需求变更流程（需求随时更改，想起来就QQ私发下），需求管理过于混乱。建议增加版本控制（通过SVN等工具管理），需求更新后对更新内容进行明确并且及时通知到测试。

• 工时评估

  • 对于需求按功能点统计，估算各功能开发用时，产出开发计划书，以供测试计划参考。

---

开发阶段

• 开发依据需求文档，产出开发文档，开发经理/产品经理评审通过。
• 开发文档/数据库设计文档同步测试。
• 开发完成后，开发经理评审，抑或是单元测试通过后再评审。
• 开发环境自测通过，一般就转交测试了，个人觉得可以由产品经理进行冒烟测试，验证下开发的主要实现是否与自己设计想法一致。
• 对于测试测出的bug进行分析归类，形成规范文档，避免以后再犯。
• 对于bug处理按照优先级进行，不清晰或无法重现的问题找测试沟通；对于bug闭环流程与测试达成一致。
• 代码版本控制需要加强，开发修复bug提交新代码，需要提供变更代码的差异文件，以供开发经理评审。
• PS：目前项目组无技术/开发经理，开发较为随意，并无代码评审及单元测试环节，也无规范文档，质量无法保证。

---

测试阶段

• 测试计划

  • 依据需求文档及开发计划书，合理安排测试人员用例设计/评审及执行时间，产出测试计划文档。

• 测试用例

  • 测试人员依据评审并修改后的需求文档编写测试用例，依据内部标准规范（通用设计方法、Checklist等）编写。
  • 内部进行用例评审及对应。
  • 外部评审（产品、开发参与）及对应。
  • 用例定稿。
  • 用例管理及更新（需求变更以及测试过程中发现用例遗漏或错误及时更新）。

• 测试执行

  • 冒烟测试，依据内部标准评定，不通过则拒绝测试，可以避免无效测试以及提升开发质量意识。
  • 测试人员依据测试用例执行并标记执行结果，统计测试结果并进行分析总结，对于多发性问题形成文档，给至开发负责人。
  • bug记录，依据内部规范记录bug至管理系统上。
  • bug沟通及回归，统计bug数据，对于经常出现低级bug的开发人员进行提醒。
  • 依据内部规范对bug进行闭环。
  • 一轮测试完成后，进行组内交叉测试以及随机测试（猜错法）。
  • 产出测试报告。

• 测试发版

  • 系统发版应严格有效控制，勿随意过多发布，任意发布严重影响测试结果的有效性，增加了测试风险。

• 联调测试

  • 目前联调测试执行混乱，各方未有效协调，建议协调好，产出联调测试计划。
  • 产出联调测试场景及验证点而后开始测试。

• 测试总结

  • 依据统计的bug分析需求及开发方面存在的问题，周知相关人员。发现测试流程中存在的问题，与各方讨论并优化流程，提升项目质量及效率。
  • 编写操作手册，也是对系统的再次验证。

转载于:https://www.cnblogs.com/kusy/p/9243431.html