软件测试流程中的致命缺陷

缺陷一：软件测试成了开发的拐杖。

本来质量是所有人的事，但是因为有了测试部门的存在，开发人员越来越少的考虑质量问题，越来越不会去测试，因为他们认为质量是测试人员的责任。

关于这点，应该是有共识的，有反馈找测试，漏出 bug 找测试，所有问题都可以归结为一个终极问题「为啥测试没有测出来？」

如果继续目前的做法，这个问题是没法得到解决的，但是可以借助之前「测试即服务」的方法间接解决。

我们服务于产品，在需求阶段解决需求问题。

我们服务于开发，在编码阶段解决架构和技术实现的问题。

我们服务于用户，从用户角度解决体验性问题。

我们服务于质量，深层次挖掘逻辑问题。

缺陷二：开发和软件测试的隔离，阻碍了测试人员对产品的关注。

James 要表达的是 Google 独立的测试部门，导致他们更注重测试工作本身的事情，从而忽略了我们是为业务服务的大目标。

这个在国内目前的环境，基本不是问题，甚至部分公司会出现测试过于依赖业务，进而失去了自己作为测试应该具有的独特视角，仅仅成为一个工具。

我理解只要记住两点就够了：

测试是为保障质量服务的；

质量保证是为业务目标服务的；

缺陷三：测试人员往往过于崇拜测试产物。

这点主要强调的还是测试太过于关注测试本身，比如测试流程、计划、用例、工具、系统、bug 等等，所有这些都是测试过程的产物，所有这些产出的目标都应该是为了保证产品质量。

这其实牵涉到另一个比较大的话题「如何进行软件测试人员的绩效考核」，考核目标不一样，对应的就是大家的关注点的不一样，所以这个方面每个公司根据自己现状不同，都是有一些差异。

总体来说，James 表达的这个意思是没问题的，确实业务是最终的目标，测试人员应该把产品放在第一位，目前剩下的就是怎么去制定合理的考核指标，让我们的目标和业务目标能够保持一致。

缺陷四：产品经过测试后并仍然会遗漏问题。

这点确实没法完全保证，James 指出的原因是 TE 只是想象自己是用户，而试用者是真实的用户，所以才会漏出问题。

从我的经验看，其实可以分为两种情况考虑。

一种是功能问题的漏出，比如逻辑分支缺少用例覆盖。

这种肯定就是测试人员的问题了，有可能是需求没有搞透彻，有可能是实现逻辑没有弄清楚，有可能是自己用例设计的方法不熟练，解决办法当然是对症下药。

另一种是用户场景的遗漏，比如真实用户使用产品的操作方式没有覆盖到。

这种情况，产品、开发、测试和运营部门都是应该参与试用的，特别是作为产品的第一批用户，我们应该在我们的生活场景中去使用我们的产品，而不仅仅是想象我们的角色，一定要作为真正的真实用户去使用产品。

当然，内部试用、灰度发布和快速迭代也可以解决这个问题，但是这时候漏出的问题应该是符合预期的，因为本来就是期望他们来发现这些体验性问题。

今日福利

【Java11期开课啦】

8大实战案例模块，历时三年沉淀，Java4.0震撼发布！

偷偷告诉你前50名，还可获得价值300元的京东购物卡呦~

如有疑问，请留言告知，或者咨询柠檬班软件测试培训机构：www.ceshiren.com官网客服哦