目标：在成本可控范围内，将Bug扼杀在摇篮里
一、测试在项目管理中的工作流程
二、测试工作流程产出说明
项目测试计划：包含测试系统概述、测试目标和方法、沟通策略、测试环境与工具
- 测试系统概述：介绍测试的系统体系结构、组件、集成测试相关的系统分解或者组装情况，如：PANGU系统可以分解成资源模块、项目模块、客户项目资源模块等，这几个模块又可以怎么关联
- 测试目标和方法：测试到何种程度，测试的方法有哪些（手工、自动）等
- 沟通策略：根据开发的情况，说明测试和开发或测试间工作的协调关系，如开发和测试人员如何协同工作？项目的发布周期?多名测试间的协作工作问题等
- 测试环境与工具：测试环境有哪些，如果web测试要考虑浏览器类型和版本的兼容（也可包含电脑型号等），若是app测试则考虑手机品牌和型号等问题。测试工具如postman等，但要讲述其用途
做好前期工作，减少后期测试工作中发现的问题，提高测试效率
测试框架：界面（UT）、功能、流程（场景）、接口、性能、冒烟测试、系统测试
项目验收单：即项目上线评审，包含开发的上线验证点（如数据库的迁移，功能脚本等）、产品的需求验收点，测试人员对项目的注意点
三、测试工作流程目前存在的问题
1、新的项目启动，测试人员目前不太会制定测试计划，遇到具体的需求在考虑问题。这要的话，这些方案是不是在一个问题点的能够得以解决，扩展到整个系统就有点束手无策了呢？
2、测试框架方面，目前公司常用的是手工测试和接口测试。现在针对前端回归测试的薄弱点，我们已经在考虑展开UI自动化测试，这样就可以避免后期开发人员在前端的代码变更而产生修改引入的Bug
3、测试用例方面，测试人员是否只是针对需求写测试用例？扩展的功能是否有包含呢？本季度我们开始执行场景测试，那么场景测试用例就可以很好的做功能扩展
4、场景测试用例重点需要产品，产品最为接近业务方，可以更好的提供我们测试用例中缺失的业务方操作流程
5、功能上线后，开发、产品、测试要加强新功能的验证，测试人员可以执行简单的手工回归测试，保证相关功能OK
6、场景、UI测试加强回归。测试人员需要定期查阅售后Bug，归纳总结问题点，补充测试用例
7、缺少上线评审环节。每个需求可以有个confluence，里面记录三方针对需求的验收点和上线的注意事项。开发需要记录需求的数据库的迁移，功能脚本，避免上线后因忘记迁移或漏跑脚本而造成的功能问题；产品和测试人员则记录需求的功能注意点，上线验证。若confluence中任意环节出问题可立即回滚代码。
四、测试改进点
1、测试用例设计中不能只考虑一个需求的覆盖率，还要考虑测试执行的效率。多多采用因果图、等价类划分等测试用例设计方法，用较为少量的测试用例做全面的测试工作
2、测试过程中测试人员在发现一个Bug时，要进一步思考Bug的产生原因并考虑相关的步骤是否也可能存在原因。在验证Bug过程中要思考修正可该Bug会不会引起其他缺陷
3、定期反馈我们在测试过程中发现的问题和建议或分享自己学到的好的发现Bug的方法
4、半个月或一个月做Bug统计工作，看测试人员和业务人员提了多少Bug。关注测试人员所提的非编码问题的Bug，总结原因，避免下次出现类似的非编码问题的Bug；对于业务方提出的Bug，分析是否有我们测试过的变更在业务那里被发现的问题，如果有，分析下我们没有发现的原因（可以体现在周报里面）
5、学学新的技术，提升测试质量和覆盖度，准确定位Bug
6、测试间系统互查活动
7、督促开发给出代码变动会造成的影响范围
8、每个需求在项目验收（评审）单中记录需求注意功能点
9、每天关注自己项目接口的report情况
10、针对售后Bug对测试用例经行补充
五、对于其他职能团队的期待
开发部门
1、开发在文档上的变更及时通知测试人员
2、开发人员做好UT工作，不要为了减少开发时间，将未自测或未跑UT的功能提给测试人员
3、开发在发布变更时同时，先走下接口测试脚本
4、在Bug修复的效率上有所提高
5、良好的编码习惯，如新增修改接口不要时同一个
6、每次代码变动，需要和测试说明代码的影响范围
7、每个需求在项目验收（评审）单中记录需求的数据库迁移、跑脚本等事项
8、上线前将测试Bug过一遍，解决必要Bug
产品部门
1、需求分析充分，减少开发或测试阶段的需求变更
2、加强线上的验证工作，可以是项目验收的功能点
3、完善产品文档，系统已有功能和规则在文档中详细的描述清楚
4、减少找开发的次数，让开发人员留有更多精力在开发的工作上（开发+自测+UT）
5、每个需求在项目验收（评审）单中记录需求的验收点