为何互联公司不开除测试？
快，
好了，扯淡终了。让我们抛开各种私心杂念，客观冷静的看看这个问题。题主这个问题问得很好，我很早以前也这样想过。但是后来发现，这个问法本身就是有问题的。
我尝试从几个角度来分析，在正式分析开始前，我们先把范围划定在软件开发这个圈子里头，再来看题主的问题有哪些问题，并且对这些问题进行解释。01这部份包括这几点误解：
将开发阶段、测试阶段完全剥离。
对测试的理解有些偏差，误认为测试只是在产品做出来以后，使用它，然后挑毛病，找bug。
误认为测试只有功能性的校验。下头对这3点逐一解释：
1.将开发阶段、测试阶段完全剥离。
让我们来看看题主的问题：
为何互联公司不开除测试，转而让大众来测，找到一个bug给元？
这个问题有个假定，就是开发阶段、测试阶段完全剥离开了。开发阶段单纯地就是开发人员敲代码，然后出来的东西交给测试人员去做测试。我不否认，现在仍然存在这样的实践方式。但是，这不是一个好的方式。由于这类流程，把发现bug的时间点推迟了。而发现bug的时间点越靠后，修复它所要付出的代价就越大。
这点应当很容易理解，比如你敲钉子，如果一口气敲完了才发现，敲歪了，那就得拔出来重新来，可是东西上已有一个很深的洞了。所以，好的方式是敲一敲，检查一下，随时纠正方向，确保前进的大方向是正确的。
软件更是如此，某个bug可能是在最底层的地方产生的，如果初期发现，定位也容易，修复起来被牵扯到的地方也少，付出的代价可以接受。由于bug的产生可能是多个缘由，有可能是功能性的，也有可能是对业务理解的偏差致使开始就做错了。
如果在产品做出来，发布给最终用户以后才发现。那个时候再排查到底哪里出了问题，就不是一时半会能做到的了，代价很大。
所以比较好的实践方式，是由专业的业务人员把要做的东西切割成足够小的、彼此独立的、可单独交付的模块，开发、测试和业务人员及时沟通、及时反馈，一个一个小模块完成，随时做随时测。把发现bug的时间点尽可能往前推，这样就可以把修复它的代价降得尽量小。
固然，小模块都通过测试，其实不意味着所有小模块拼装起来组成的系统一定正确，还需要进行层次高一点的集成测试。这就引出了第2点。2.测试就是找bug的？ 对测试的理解有些偏差，误认为测试只是在产品做出来以后，使用它，然后挑毛病，找bug。
有这样的偏差其实不奇怪，由于执这样想法的人太多了，乃至包括一些软件行业的从业人员。比如有这样的说法：
开发就是敲代码的，测试就是找bug的
如果是业外人士，我觉得有这样的误解没什么。毕竟，隔行如隔山，但业内人士这样理解的话，真的不知道该说甚么好了。开发是否是只管敲代码，这里不谈。这里我们要谈的，是，测试不是单纯的找bug。
现在我们承接第1点，来说说为何测试不是在产品做出来以后，单纯的找bug。
先科普的一个东西，就是测试金字塔。看不懂这个图没关系，我来渐渐解释。
测试是分层的，它真的不是只有在产品做出来后才开始的，并且也不能那个时候才开始。缘由在第1点里已解释过了。一个工程级别的软件产品，它的测试大致覆盖了代码级别的单元测试，模块级别的API测试，还有端到端的集成测试。这其实不全面，还有很多其他类型，这里我们只是大概分成这3种，便于解释、理解。
底部那层，就是代码级别的单元测试。它是发现bug的最前沿阵地，能在这个层级捉住的bug，修复起来的代价，会小很多。而且这部份测试数量很大，验证的东西也不是最终用户所能理解的，通常都是自动化运行，有很多种框架可供选择。只有这层的测试全部通过，才会运行后面更上层的测试。 中间那层，是service级别的测试，大概可以理解成模块间的API测试。到这一层，基本每一个模块的功能都得到了保障，但是他们彼此的协作不一定正常，所以这层集中要测的就是不同模块间的协作、通讯了。这部份测试数量第二多，也是自动化运行。通过以后，就可以开始最上面那层的测试了。
顶部那层，这部份测试的数量最少，是UI级别的测试。测试的进程大致可以认为是，摹拟使用产品的进程，最终用户也能理解了。比如从注册用户开始，到注册成功，登录成功，页面正确加载。这类校验最基本功能的测试，叫冒烟测试，确保产品可以正确运行，没有没法启动之类的重大缺点。除此之外，还有部份不便自动化的测试，需要手动测试，同时还会校验一些边角的情形。
即使上面说的测试全部通过，也不能确保产品万无一失没有bug，这是不可能的。只能说，通过了那末多层的测试，产品处在一个稳定状态了，最终用户的使用体验良好，绝大部分需求都可以满足。主编
主编4
邮箱：wuxinqian
-
址：
白癜风原因百癜风