初创团队需要自动化测试吗？

大家好，我是陈哥。

有个读者朋友给我留言，问了一个问题：

我们是一个初创团队，产品还不是特别稳定，这种情况有必要开始自动化测试吗？

很多人都有一个误区，认为只有大公司才能搭建自动化测试。初创团队的首要目标是快速把产品推向市场，先活下去才是第一位，自动化测试可以等到后期业务稳定之后再考虑。

其实，初创团队是需要自动化测试的，甚至应该在项目早期就把自动化测试纳入研发流程设计当中。

一、初创团队常见的三大问题

在初创团队中，开发和测试的区别没有那么明显，通常是一人身兼数职。所以，在下面的内容我将会用“开发”一词指代。

接下来，我会针对一些初创团队最常遇到的几个问题进行分析。

问题一：自动化测试增加开发成本，会影响市场验证速度

这是绝大多数初创团队最大的顾虑。

创业阶段人手紧张，大家的时间都十分宝贵。负责人会认为写测试代码属于非业务产出，把宝贵的时间消耗在测试脚本编写上，会压缩开发功能时间，打乱市场验证的节奏。

放长远来看其实不然，假设团队规模保持不变，完全依靠人工手动测试的模式，成本会随着产品功能不断叠加持续攀升。

每迭代一轮新功能，开发都要把全部旧功能重新完整走一遍测试。随着功能模块越来越多，测试需要的时间会越来越长。

手动测试还有一个无法回避的短板，就是很难做到覆盖全部边界场景，很多潜藏的Bug只有在特定操作组合下才会触发。

这些Bug在测试时没办法被及时发现，往往是产品上线后，由真实用户反馈才暴露出来。

线上故障的修复成本远高于开发阶段，不仅要定位问题、紧急修复、重新发布版本，还要处理用户投诉，修复一个上线后Bug所消耗的时间是不可预估的。

一旦出现严重线上问题，甚至会直接打乱整体市场验证计划，错失市场窗口期。

反观在开发阶段同步引入适度的自动化测试，虽然前期会产生一定的时间投入，但整体研发工时是可预估的。

自动化脚本能反复执行回归校验，团队在进行版本迭代过程中，自动化测试就可以校验原有功能是否正常。

团队把大量重复的回归工作交给程序完成，可以将人力释放出来投入到新的业务开发中，省时又省力。

问题二：市场验证刻不容缓，待市场验证后再来补自动化测试

这种想法一般很难落地。

一旦产品市场验证取得初步成功，PO接收到市场正向反馈，接踵而至的会是源源不断的新需求。

市场竞争不会停下脚步，为了抢占用户，团队会持续迭代新功能，业务压力只增不减，几乎不会出现停下新功能开发、专门补自动化测试的空档期。

还有就是自动化测试的落地高度依赖可测试性设计。

可测试性是在代码设计、架构设计之初就要考量的特性，如果在开发初期完全不考虑测试，代码耦合严重、业务逻辑和第三方强绑定、模块之间纠缠在一起，等到后期想要补充自动化测试时就会处处受阻。

想要写测试，就要大规模重构历史代码，重构又有引入新Bug的风险。

问题三：MVP 产品规格经常变动，不易维护自动化测试

MVP 阶段产品需求反复调整是初创团队的常态。市场反馈、用户调研和竞品变化，都可能让产品规格被推翻、修改。

高频的需求变更，必然会带来测试脚本的维护成本。我之前在一个初创公司工作的时候，也经历过几次规格变动，当时真的天天加班。

所以，我们要分清是彻底舍弃旧功能，还是在原有业务基础之上迭代修改。如果大部分需求迭代都是在原有功能之上调整，自动化测试反而可以降低规格变动带来的风险。

当我们迭代产品功能时，最怕改动一处代码，无意间破坏其他已经稳定的旧业务。没有自动化测试保护的情况下，每一次改需求，都要靠人工全部回归一遍，很容易出现改A功能，弄坏B功能的情况。

如果做好基础的自动化测试，每次代码改动后自动执行测试，一旦原有业务逻辑被破坏，脚本就会直接报错，开发人员可以立刻发现问题。

哪怕产品规格持续迭代，我们只需要针对性更新受影响的测试用例，就可以保证原有稳定功能持续受到保护，让团队更有信心快速迭代上线，持续验证市场需求。

二、初创团队如何搭建自己的自动化测试体系？

初创团队资源有限，不可能直接照搬大企业的测试体系。

那么如何把握尺度，才能做到既不耽误产品推向市场，又能发挥自动化测试的价值？

首先，善用成熟框架与第三方开源套件。

不要从零开发整套自动化测试基础设施，根据自身技术栈选用业界成熟的单元测试和集成测试框架，可以选用现成的mock和断言工具。

把开发有限的精力集中在项目上，减少底层工具搭建的时间，从而提升整体研发效率。

其次，优先落地单元测试与集成测试。

不必追求全场景自动化，优先针对核心业务逻辑、边界条件、异常错误处理编写Unit单元测试、Integration集成测试。

团队要聚焦在产品的核心链路，也就是用户最常使用或者一旦出错损失最大的流程。面对QA 测试反馈、线上用户反馈回来的Bug，及时使用TDD思路，针对Bug补充对应的测试案例，保证同类问题不会重复出现。

同时，不要过度测试，对于一些非核心的临时逻辑就不需要投入大量精力编写测试，避免开发阶段做过多无用的测试工作，消耗迭代时间。

最后，建立团队关于自动化测试的认知

自动化测试是要随产品迭代的。测试代码也是项目代码的一部分，需要和业务代码同步维护。产品需求变更时，同步更新对应的测试用例，把测试变成日常开发流程的一环，而不是一个独立的额外项目。

三、这条铁律不会改变

自动化测试是提升研发效率的工具，而技术债是拖累迭代效率的包袱，这条规律并不会因为你是初创团队就有所改变。

很多初创团队会抱有侥幸心理，当下为了赶进度跳过自动化测试，可欠下的技术债终究需要偿还。