一
目前的现状。
bug 太多，懒得写 bug 单，很多需求合理性的验证都放到测试阶段，比如文案的测试，逻辑实现的健壮性也是留在了测试阶段，稍微一点异常就容易挂掉，然后就是各种改，提测次数频繁。
从我目前面试的经验看，不管是社招还是校招，有不少人选择测试的原因都是测试门槛低，不会的能很快学会，稍微好点的是因为够不上开发的标准，所以才选择做测试。
在这样的大环境下，导致很多测试人，自己都觉得测试的技术含量不高，开发更是觉得自己理解的测试没技术含量是正确的了，然后大家就进入了这个恶性循环的怪圈。
而且从测试这个 title 来看，也容易让人误解为所有需要验证的东西都是测试人员的职责，
二
为什么要前移？
如果不前移，测试人员就算忙死，对整个团队的质量保证的贡献也是有限的。
因为很多的测试验证工作都是一次性的，不可复用的，做自动化吧，不值当，不做自动化吧，很繁琐。
同时因为质量保证时间点后移，导致测试人员的时间开销特别大，能分配到做一下随机测试和深入逻辑验证上的时间非常少。
这样导致的问题就是，每次填坑的同时也在不停的埋坑，很多当前不会发生的问题，以及很长一段时间没人触发的问题，在之后的某个时间点，突然爆发，然后就需要重新花时间填坑，同时又会埋一个新坑，最后谁也不知道到底有多少坑，到底什么时候会把什么坑给暴露出来，这也是一个恶性循环。
如果测试前移了，很多基本的质量问题都可以在前期得到保障，就算提测时间晚，但是提测质量高，测试可以花更多的精力做更深入的测试，发现的 bug 肯定也都是质量比较高的了，同时这样的项目发布，埋坑的可能性就小，我们只需要关注本次修改内容及其影响范围即可，这才是良性循环。
三
如何前移？
我的答案是，测试即服务。
作为质量保证部门，我们的职责是保证产品的质量，但并不是说一定要我们去做具体保证质量的事情，所以换个角度，我们可以把我们保证质量的能力输出给真正能影响产品质量的人。
比如我们给产品人员提供服务。加强需求评审阶段的投入，把我们对于用户角度的思考，把我们对于需求合理性的思考，把我们对于产品质量预防的经验，在需求评审阶段就进行输出，把我们已知的问题在需求评审阶段都消灭掉。
比如我们给开发人员提供服务。给开发提供完备的编译环境支持，环境中可以包含必要的白盒检查、自测环境、冒烟测试用例，甚至是提测前的代码 review，把我们对于代码质量的基本要求和规范，都在代码编写阶段进行解决，从而把我们已知的编码中可能出现的问题尽可能的消灭在提测前。
产品和开发是和我们质量保证联系最紧密的两个角色，如果能把这两个角色的服务做好，基本可以保证提测质量了，也就能满足我们最低的测试前移的要求了。
当然，如果要达到这样的效果，更多的是对我们测试人员能力的更高要求，所以，为了可预见的美好未来，一起加油吧。
标签：浅谈,测试人员,bug,测试,提测,我们,前移 来源： https://blog.51cto.com/sylan215/2919772
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。