说说之前的测试工作流程吧：
1.产品整理需求，需求确定后开需求评审会议
2.测试根据需求梳理测试点
3.测试执行
4.bug回归验证
5.每周测试工作汇报
6.上线前核心功能验证
问题：
1.评审中技术提出问题后，产品需再整理需求时，后续需求变动没有再次确认的过程
可跟进需求变动，产品修改完之后再次评审
2.测试经常发现实现与需求不一致（开发遗漏、需求理解不同、产品所提需求实现不了、开发觉得需求不合逻辑、不合实际项目经验）
经过今天下午小组讨论，才知道原来是少了用例评审这一步。用例评审过程也是对需求的再次确认，保证开发测试理解需求同产品一致。
3.测试用例评审，没有这个环节
之前编写测试用例有些形势化，有些用例还是测试完后补的，没有价值。
以后对于比较核心重要复杂的模块，可以开展用例评审，技术对用例进行把关，以防测试遗漏或者需求理解不一致
4.测试执行之前没有设定准测入口，效率低
开发提测后，测试会对基本功能验证，通不过打回。有些开发代码质量低，导致一轮轮复测，效率太低。
感觉这一块得从推动开发自测和通过冒烟测试来改进。
5.测试完成后没有写测试报告
每周会对测试工作进行汇报，主要是统计bug数量、修复数量、未解决数量以及当前测试进展。所有测试完成后，并没有对该轮上线功能进行测试总结，写测试报告。
