开发提测？

前言

开发提测是正式开始测试的重要关卡，提测质量的好坏会直接影响测试阶段的效率，进而影响项目进度。较好的提测质量，对提高测试效率和优化项目进度有着事半功倍的作用。如何更好的推进开发提高提测质量呢？下面小编结合自己项目中遇到的问题（举例如下），和大家分享下开发自测case相关的优化方案。
Q：

开发验证自测case通过提测后，测试验证自测case不通过；
各端开发配合需求中，开发在实际联调成功前回复自测case；
开发与产品两方沟通调整需求，未同步给测试；
……
开发自测case

推进提测质量的提高，可以有多种方式，每个项目组都会有各自的特点及相应适用匹配的方法流程。小编结合在项目中采坑积累的经验，现总结落实在实际项目中的方法有如下几种。

在正式提测前开发实现中，可以通过方案讲解会、code review来提高实现质量及预期结果；正式提测阶段，可以通过自测case、交互走查、视觉走查等方式把关质量；提测后，可以有产品验收等方式。在这里，主要和大家一起沟通下正式提测阶段的自测case。

提到开发自测case，相信很多测试小伙伴都不陌生，甚至很熟悉，小编结合自己所在项目的实际应用，简单介绍下自测case。

1、自测case介绍

开发自测case就是开发同学以邮件形式提测功能前，需要测试人员在最短的时间内提供一份用于验证提测模块主流程上的功能是否已开发完成，是否覆盖了需求以及交互明确规定的主路径细节，从而确保产品在初始形态时满足产品的预期结果。

2、自测case选取

测试同学依据产品的需求/交互文档、开发实现流程（工程主导需求），整理功能主路径case（包含埋点需求）。

3、自测case流程

质量保障之开发提测

开发自测case配合

基于上述自测case的流程规范，还不能很好的解决实际项目中遇到的问题（前言中）。本部分将结合实际项目自测case的执行和配合问题的已落实的解决方案，进一步对开发自测case的配合细节进行补充。
1、自测case发送时机

至少在开发提测排期提前1天发出自测case邮件，按照需求类型，可分类细化如下。

项目版本计划中的产品需求：
在需求评审会后，项目测试开始时，优先发送自测case；

项目版本间的插入/需变：
在三方沟通评审过需变/插入任务的细节及逻辑后，由测试同学在产品需变/插入邮件的基础上，回复自测case邮件；

工程优化类需求：
在三方沟通需求细节及对应版本计划后，测试同学与开发沟通具体逻辑，然后在对应的工程优化邮件基础上，回复自测case邮件。

2、自测case测试准备说明

多端多人配合需求自测case划分：
多端配合的需求，测试需给对应开发同学发送对应功能逻辑的自测case邮件，在无法确定具体的逻辑划分时，可以提前与开发沟通，统一发给无法分辨的所有配合端开发同学一封自测case邮件，由开发之间自行沟通划分自测case验证，并分别回复邮件提测。

较复杂模块自测case邮件形式：
复杂模块对应的自测case相对较多，为方便开发标记结果同步，可以在邮件中将自测case文档添加为附件。

3、自测case配合方规范

开发验证自测case的规范（重点强调）
三方约定，开发需以build系统中的release版本验证通过自测case后方可提测，不可以用本地debug包验证自测case提测。这样，一方面可防止因实际多端开发未联调完成，影响测试进度的问题，另一方面避免因debug包和build包不同造成的阻塞bug进行二次提测的问题。

重要的事情说三遍：

开发必须用build包验证自测case提测！！开发必须用build包验证自测case提测！！开发必须用build包验证自测case提测！！

开发自测case提测邮件规范
开发在提测邮件中需说明build系统的开发分支，注意，还同时涉及多个SDK的交互功能，需要同时说明对应的开发分支；（若已在工程优化邮件中说明，可不再备注）
若涉及测试环境，需在提测邮件中说明测试环境的host，同步给测试同学；
若存在后期需求变动或开发实现逻辑的变动点（已与产品同步），与某些case不匹配，需在邮件正文备注说明；
自测case提测的同步提测准备
开发在发送自测case邮件的同时，需给视觉同学发送视觉走查通知邮件，以及交互同学走查通知邮件。

视觉走查

为避免后期视觉走查不通过或者视觉稿变更，引发的重复兼容性测试工作量的问题，小编所在项目中将视觉走查的时机提前到开发提测阶段，保证在兼容性测试之前，UI达到可提测标准，测试同学开始UI层的兼容性测试的依据是视觉走查通过邮件。

具体的配合流程如下：

质量保障之开发提测