开发自测-经验交流总结

接触过的很多项目都有自测环节，但什么样的自测才是有用的？在这些项目实践经验中，有哪些共通的痛点、有效经验？

通过对有项目测试经验的人发起问卷（https://wj.qq.com/s2/3210970/0b92/），对收到的问卷数据进行分析，做出如下统计总结：

1、  自测规范、流程、效果的实际情况：

• 只有少数的项目有明确的自测规范和流程
• 没有自测规范的项目往往对自测环节不重视，这需要有人站出来去推进和改善。
• 有明确的规范不等于有好的自测效果。好的自测效果=明确规范+合理的自测内容&时间+真实的执行+及时监控&效果反馈&持续改进
• 有些项目的自测效果不稳定，受不同开发的个人自测意识影响限制，这可能需要让自测效果好的开发发起一些自测经验分享、培训，减少不同开发间自测效果的差异性。或者增加自测的执行者，不仅局限在单个开发。

2、不自测或不好好自测会带来的问题：

• 需求遗漏、部分代码合并提交遗漏，这些问题需要按照需求来制定明确的自测内容并记录执行，防止遗漏
• 项目延期：如果不自测，测试花大量的时间沟通低级bug，甚至测试主流程都进行不下去，这样无疑需要更多的开发返工、重复测试、耗时，最终导致项目延期。如果在项目初期就能计划、预期合理的开发自测时间，保证一定的自测效果，这样其实是更高效省时间的选择。

3、自测进行的环境：

• 在未自测导致的问题中，测试环境配置问题排第三。但实际上能保证自测在测试环境下进行的项目仅占36.8%。
• “在我本地好好的，怎么你那里有问题”这种环境问题，如果在自测的最后、联调后、验收或送测前能在测试环境下进行自测，就可以避免送测时还存在环境配置上的问题
• 联调可以用开发环境，但是送测前最后一轮自测希望能在测试环境，真的是利大于弊。

4、自测的方法和方式：既然自测这么重要且能避免这么多不必要的问题，那么如何实践呢？

• 自测依据：测试&自测用例、测试&自测点、主流程、需求
• 自测依据提供人：测试&开发&双方共同评审后决定（用例、点、主流程）；产品（需求、交互、视觉）
• 自测执行人：开发；产品&交互&设计（验收）；自测巡查小组（监督）；负责不同模块的其他开发（交叉自测、代码审查）；
• 自测方式：公开演示；自动化执行；接口正常用例跑通；单元测试；功能测试
• 自测执行结果记录：验收kb记录；自测报告

5、自测效果好的项目经验分享：

• 持续监督自测效果（制定低级bug率月目标并监控达成率），定期反馈自测流程问题、不断改进，让自测符合项目特点
• 软件开发完成打包后，在送测前一天，开发集中花半个小时，开发中每个模块功能由对应主要开发和非该模块的开发过一遍自测用例
• 制定明确的自测规定、自测用例设计规范。记录自测模块及负责人。推行走查发现bug的模式。
• 测试写好用例给到开发评审，ok后 整理完主流程给到开发自测。
• 尽早提供可执行的测试用例，用线上页面或任务的方式，来确保某个人已自测某功能。
• 开发评审测试用例并与测试共同制定主流程用例（自测用例）；送测前建立自测测试计划，模块交叉分配；将环境部署到送测环境上，在送测环境上执行自测用例。

6、若送测内容涉及多个开发、模块、端，如何保证集成自测效果（整体功能的正常）：

• 引入第三方监督机制，比如建立开发自测巡查小组，让非本项目的开发人员看着开发人员演示功能并接受检查。
• 新需求送测前，由交互、视觉对产品进行一轮验收；然后送测时由一到两个开发负责人负责产品所有模块的自测。
• 交叉自测，功能开发负责人自测自己开发的功能通过后，交由其他开发执行用例
  跨端、跨模块 Android/iOS互测：同一端跨功能互测。 互测过程中尽量减小被代码编写人员的逻辑影响，局外人身份参与。
• 开发自测个人开发模块，还有测试联动点，查看数据之间交互是否正确
• 每周固定一天，所有开发对产品进行走查，提出优化、缺陷，提交后由产品、交互决定该问题如何修改，何时安排送测

7、自测中需要注意的内容：

• 思维模式：开发自测时需要走出具体技术实现时用的开发思维，需要站在产品用户、需求的角度上去衡量自测是否通过。
• 工作量：自测工作量需平衡适中。自测效果满足一般要求即可：主流程无明显报错，无阻碍性bug引起的中断。
  开发拿到的自测用例如果太重了，就很难去执行。轻量级的冒烟测试用例（仅针对未改动/小改动模块，新增模块需详细点）比较适用，开发执行效率快且容易发现严重问题，可以提高开发的积极性。
• 积极意义：与其让开发把自测当做任务完成，建议倡导走查模式，鼓励发现问题，给予奖励
• 兼容性：若产品有兼容性需求，开发就最好别每次都用同一台机型或浏览器去自测，可以在不同送测时尝试换测不同的浏览器或机型
• 执行力：有流程有用例，如果没有执行力都无效
• 自测不仅仅在A1需要，修复bug后的自测也需要执行，否则存在问题被多次打回的可能
• 时间：提前合理计划预留自测时间，而不是压缩测试人员的测试时间
• 环境：开发经常会使用虚拟机进行自测，会因为物理环境与虚拟环境的差异而导致一些低级问题。

8、对于自测，测试人员能做些什么：

• 输出对外部门测试相关的分享，培训，启发开发的测试思维。
• 持续关注、监控自测效果、改进
• 及时更新自测用例