在项目中，是否经常会遇到这样的问题：

1、前端后端开发完也不联调，直接甩给测试，测试同学一点按钮，系统就炸了（冒烟了）；

2、开始测试了，测试同学冒烟时发现某个重点功能不能走通，开发要再花一天时间进行修复；

3、终于提交了代码，测试同学一走主流程发现跟另一个模块的交互出了问题，开发继续回去修复；

4、终于测了一半，发现本次需求的一个重要的功能未能正确实现，需要重新设计，开发完需要全部重新执行测试。

这是因为研发环节少了一个开发自测环节。

开发自测是指在编码完成后提测前，开发同学通过在本地或者开发环境进行接口调试、前后端联调、走全流程验证等，确认本次新增功能都已实现，以及对原来主要功能没有影响，确保提交给测试的产品是可以正常使用的（不会阻塞测试流程）。

开发自测在很大程度上决定了产品的质量和项目的进度，如果不重视自测甚至没有自测，测试同学将花费宝贵的测试时间进行主流程确认，开发来回提交代码，严重影响项目研发进度。

有同学可能会好奇为什么不是测试同学直接进行测试的效率会更高呢，专业的人做专业的事不是更好吗。

首先，我们知道在不同阶段发现问题和解决问题的成本是不一样的，在coding阶段解决问题的成本较低，测试阶段解决问题的成本相对高，因为这时候开发同学对那块代码已经没有这么熟悉了，熟悉代码结构和回忆需求导致改动代码的风险会大一些；并且如果是比较严重的问题，意味着需要对代码设计做一些重构，不仅又消耗了时间，还需要重新进行回归测试。

其次，项目时间往往不是这么充足，如果开发同学提交测试的版本是比较稳定的，主要流程和主功能是能确保的，那么测试同学就有更多的时间精力对产品进行充分的测试，有时间进行探索去发现隐藏的问题，而如果提交的版本不稳定，那么测试阶段的大部分时间就会在确认主功能上。

我们来看看测试同学的工作，假设我们的产品是一个风扇，我们要对他进行什么测试和确认呢？

1、使用说明书指引正确

2、在高温低温环境下，都能正常工作

3、开一整天，可以正常工作

4、不断开-关-开-关-开-3档-1档-2档-关之后，可以正常使用

5、和一部空调公用一个排插，可以正常工作

6、不停摇晃下，可以正常工作

7、可以用手抬起风扇，可移动到不同位置

8、将风扇打包，通过航空/铁路运输到哈尔滨，可以正常使用

换成你是用户，当你满心欢喜地拿到这个风扇，你一定相信研发人员交付给你的是足够安全、稳定、健壮的产品。就像这个风扇，我们对任何产品的测试，都要从多方面多角度进行测试设计，确保交付物是满足用户需求的。然后，因为开发同学未进行自测，测试同学接到这个风扇，一插上电源，风扇就炸了。这样交付到测试的产品有什么好测的呢！完全没有意义啊。

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

1、项目延期：提测质量不高，测试花大量的时间沟通低级bug，甚至测试主流程都进行不下去，这样无疑需要更多的开发返工、重复测试、耗时，最终导致项目延期。如果在项目初期就能计划、预期合理的开发自测时间，保证一定的自测效果，这样其实是更高效省时间的选择。

2、质量问题：由于项目时间有限，测试同学不能将时间花在有意义的测试场景中，只能确保主流程及正常功能，一些重要的缺陷没有及时发现和处理，甚至导致严重线上问题，给公司造成经济及名誉损失。

所以提高研发质量和效率，从开发自测做起。