1.需求评审，测试对业务熟悉（领域内专家），敢于合理地挑战产品经理；
2.技术方案评审，测试读懂和理解技术方案，凭敏锐的嗅觉，挖掘技术方案不足之处。例：方案中补偿场景是否合理充分、业务场景不断增加后的可扩展性、业务量大幅增加后的性能问题、可测试性等；
3.测试用例和业务编码并行，包括接口测试用例、功能测试用例的编写；
a.提供接口服务的，要求开发人员在编写业务代码之前，先给出接口设计文档；
b.引入Swagger等自动生成工具的，先定义好接口（request和response的参数、参数类型、必填项、取值范围、其他约束等），编写业务代码前，先编译生成文档；
4.单元测试的质量，除了保障代码覆盖率等硬性指标，从测试角度检查UT代码的有效性；
5.代码静态分析，测试可拉取代码进行检测，协同开发一起保障代码质量；
6.代码审查，有问题代码不能带病入库，测试协同开发一起把好代码入库前的最后一道关；
7.测试用例评审，版本提测前组织产品、研发、测试一起完成，提测后可直接使用。
标签：代码,左移,业务,接口,评审,测试用例,测试,清单 来源： https://www.cnblogs.com/yulia/p/10346659.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。