浅谈测试前移

阅读本文大概需要 4.1 分钟。

一

目前的现状。

bug 太多，懒得写 bug 单，很多需求合理性的验证都放到测试阶段，比如文案的测试，逻辑实现的健壮性也是留在了测试阶段，稍微一点异常就容易挂掉，然后就是各种改，提测次数频繁。

从我目前面试的经验看，不管是社招还是校招，有不少人选择测试的原因都是测试门槛低，不会的能很快学会，稍微好点的是因为够不上开发的标准，所以才选择做测试。

在这样的大环境下，导致很多测试人，自己都觉得测试的技术含量不高，开发更是觉得自己理解的测试没技术含量是正确的了，然后大家就进入了这个恶性循环的怪圈。

而且从测试这个 title 来看，也容易让人误解为所有需要验证的东西都是测试人员的职责，

二

为什么要前移？

如果不前移，测试人员就算忙死，对整个团队的质量保证的贡献也是有限的。

因为很多的测试验证工作都是一次性的，不可复用的，做自动化吧，不值当，不做自动化吧，很繁琐。

同时因为质量保证时间点后移，导致测试人员的时间开销特别大，能分配到做一下随机测试和深入逻辑验证上的时间非常少。

这样导致的问题就是，每次填坑的同时也在不停的埋坑，很多当前不会发生的问题，以及很长一段时间没人触发的问题，在之后的某个时间点，突然爆发，然后就需要重新花时间填坑，同时又会埋一个新坑，最后谁也不知道到底有多少坑，到底什么时候会把什么坑给暴露出来，这也是一个恶性循环。

如果测试前移了，很多基本的质量问题都可以在前期得到保障，就算提测时间晚，但是提测质量高，测试可以花更多的精力做更深入的测试，发现的 bug 肯定也都是质量比较高的了，同时这样的项目发布，埋坑的可能性就小，我们只需要关注本次修改内容及其影响范围即可，这才是良性循环。

三

如何前移？

我的答案是，测试即服务。

作为质量保证部门，我们的职责是保证产品的质量，但并不是说一定要我们去做具体保证质量的事情，所以换个角度，我们可以把我们保证质量的能力输出给真正能影响产品质量的人。

比如我们给产品人员提供服务。加强需求评审阶段的投入，把我们对于用户角度的思考，把我们对于需求合理性的思考，把我们对于产品质量预防的经验，在需求评审阶段就进行输出，把我们已知的问题在需求评审阶段都消灭掉。

比如我们给开发人员提供服务。给开发提供完备的编译环境支持，环境中可以包含必要的白盒检查、自测环境、冒烟测试用例，甚至是提测前的代码 review，把我们对于代码质量的基本要求和规范，都在代码编写阶段进行解决，从而把我们已知的编码中可能出现的问题尽可能的消灭在提测前。

产品和开发是和我们质量保证联系最紧密的两个角色，如果能把这两个角色的服务做好，基本可以保证提测质量了，也就能满足我们最低的测试前移的要求了。

当然，如果要达到这样的效果，更多的是对我们测试人员能力的更高要求，所以，为了可预见的美好未来，一起加油吧。