需求阶段
-
用户需求说明（用户故事）
- 此内容无，建议给出相关文档，使大家明白产品设计初衷。
-
需求文档
- 目前只产出简单功能原型图，无详细产品设计文档，仅定义了该模块主要功能，模块间的关联未定义或者无细节说明，存在不确定性，影响测试计划的准确性；原型图阅读后无法明确用户需求，描述无序且功能散乱。建议花更多时间完善需求文档（内容及形式）。
- 上下游系统交互功能，产品之间未有效积极沟通，测试时才发现设计问题，后期返工再设计影响项目进度。
-
需求评审
- 目前无评审环节，产品直接把需求给到开发，开发过程遇到问题再改需求；无产品--测试--开发三方共同沟通评审环节，无法提前发现及避免产品设计的缺陷，以致后期返工且质量不可控。建议不要忽视评审工作。
- 评审后对需求文档变更部分进行整理总结经验，提高以后的产品设计质量。
- 需求定稿后，不得随意更改。
-
需求版本控制
- 目前无版本控制处理，也无需求变更流程（需求随时更改，想起来就QQ私发下），需求管理过于混乱。建议增加版本控制（通过SVN等工具管理），需求更新后对更新内容进行明确并且及时通知到测试。
-
工时评估
- 对于需求按功能点统计，估算各功能开发用时，产出开发计划书，以供测试计划参考。
开发阶段
- 开发依据需求文档，产出开发文档，开发经理/产品经理评审通过。
- 开发文档/数据库设计文档同步测试。
- 开发完成后，开发经理评审，抑或是单元测试通过后再评审。
- 开发环境自测通过，一般就转交测试了，个人觉得可以由产品经理进行冒烟测试，验证下开发的主要实现是否与自己设计想法一致。
- 对于测试测出的bug进行分析归类，形成规范文档，避免以后再犯。
- 对于bug处理按照优先级进行，不清晰或无法重现的问题找测试沟通；对于bug闭环流程与测试达成一致。
- 代码版本控制需要加强，开发修复bug提交新代码，需要提供变更代码的差异文件，以供开发经理评审。
- PS：目前项目组无技术/开发经理，开发较为随意，并无代码评审及单元测试环节，也无规范文档，质量无法保证。
测试阶段
-
测试计划
- 依据需求文档及开发计划书，合理安排测试人员用例设计/评审及执行时间，产出测试计划文档。
-
测试用例
- 测试人员依据评审并修改后的需求文档编写测试用例，依据内部标准规范（通用设计方法、Checklist等）编写。
- 内部进行用例评审及对应。
- 外部评审（产品、开发参与）及对应。
- 用例定稿。
- 用例管理及更新（需求变更以及测试过程中发现用例遗漏或错误及时更新）。
-
测试执行
- 冒烟测试，依据内部标准评定，不通过则拒绝测试，可以避免无效测试以及提升开发质量意识。
- 测试人员依据测试用例执行并标记执行结果，统计测试结果并进行分析总结，对于多发性问题形成文档，给至开发负责人。
- bug记录，依据内部规范记录bug至管理系统上。
- bug沟通及回归，统计bug数据，对于经常出现低级bug的开发人员进行提醒。
- 依据内部规范对bug进行闭环。
- 一轮测试完成后，进行组内交叉测试以及随机测试（猜错法）。
- 产出测试报告。
-
测试发版
- 系统发版应严格有效控制，勿随意过多发布，任意发布严重影响测试结果的有效性，增加了测试风险。
-
联调测试
- 目前联调测试执行混乱，各方未有效协调，建议协调好，产出联调测试计划。
- 产出联调测试场景及验证点而后开始测试。
-
测试总结
- 依据统计的bug分析需求及开发方面存在的问题，周知相关人员。发现测试流程中存在的问题，与各方讨论并优化流程，提升项目质量及效率。
- 编写操作手册，也是对系统的再次验证。