大家好，我是十一。

前情回顾

上篇我们讲了常见测试误区，我们先来回顾下：

常见测试误区

1.测试和开发是对头

   正确打开方式：开发和测试是合作伙伴的关系，在日常生活中要注意沟通技巧和方式，如意见不一致且不能说服对方的问题，上报给负责人去决定。

2.测试少报bug开发就会高兴点，报告也会好看点

   正确打开方式：遇到缺陷一定要上报，即使他不能稳定复现（当然测试要尽可能的再现缺陷，并且找出再现问题的具体步骤）。但是一定不要不负责任的乱报。

3.软件测试很简单,就是点点点

   正确打开方式：任何一个工作，想要做好，都是学无止境。

4.自动化测试终会取代手工测试

   正确打开方式：我们在选择用哪种方法的测试的时候，坚持“效率最高化，利益最大化”的原则来选择用最适合的方法。我们工作的目的是为了利益，而不是显得高端。

常见测试误区：

1.软件开发完成后才进行测试

测试初期发展时，大家认为软件测试只是软件编码后的一个阶段，也就是编码完成后测试才能进行工作。但随之大家发现这种方式会有很多问题：

测试的时间很有限，总会因为各种各样的延迟而压缩测试时间。这样就直接导致测试的覆盖率和质量很难达标。

最最重要的问题：往往在编码完成后测试时才发现软件需求、设计的错误或者问题，那么修复这类型的缺陷成本高的惊人。比如：测试时才发现软件需求与用户需求有出入，那么开发返工重做这部分，相当于是从头开始了。再比如测试时才发现没有做浏览器兼容，而开发修复时发现另外一个浏览器不支持已选择的框架或者控件，那么这些问题对软件项目来说就是灾难了。有资料表明：平均而言，如果在需求阶段修正一个错误的代价是1，那么，在设计阶段就是它的3-6倍，在编程阶段是它的10倍，在内 部测试阶段是它的20-40倍，在外部测试阶段是它的30-70倍，而到了产品发布出去，这个数字就是40-1000倍。修正错误的代价不是随着时间线性 增长的，而几乎是呈指数增长的。

由于上述问题的影响，于是大家越来越认识到：软件测试工作不应只在编码完成后，而是贯穿于整个软件开发生命周期的各个阶段，由需求分析、测试计划、测试方案、测试用例设计、测试执行、缺陷管理、测试报告以及其他的 一些测试相关的活动等等组成。

正确打开方式：

   综上所述，在软件项目工作中应尽早地不断地进行软件测试，发现错误并加以修正，才是软件测试工作的正确打开方式。

2.规范化软件测试是增加项目成本

大家常说“磨刀不误砍柴工”，但是真正用时又拿“能省则省”的理论来操作，殊不知此时省了相当于埋了颗雷，就算没这么严重，至少也是会很麻烦。

比如很多公司还是测试把缺陷直接口述告诉开发修正就可以了，无需记录缺陷，这个直接导致后续其他开发看这块代码会不明白为什么加这么一段？于是去掉，那么去掉后又遇到相同的问题，开发再去修订，因为没有之前的缺陷，也就不会有缺陷修订记录，那么又重新思考，设计，修订。如此反复操作，效率大打折扣不说，软件质量也堪忧。

再比如：测试用例不评审，测试模块分发到个人，每人负责一个模块，那么因为个人水平层次不平且知识水平有限导致测试覆盖率低或者测试用例本身错误的问题，直接导致软件质量不过关。

正确打开方式：

   我们不仅要规范化软件测试，更要规范化整个软件过程。

3.bug越多测试越有效

测试过程中bug的数量并不能说明测试的有效性，只能说明开发人员的技术水平高低。项目上线后/产品卖出后现场反馈回来的线上bug数量才能反应测试的有效性。

正确打开方式：

   线上bug反应测试的有效性。

4.软件测试工作只负责项目上线/产品发布之前的部分

很多人认为项目上线/产品发布后测试的工作就算完成了，其实不然。在其后我们还需要对现场反馈回来的线上bug做复现、回归测试，并且每隔一段时间对这些线上bug做归纳总结，总结我们没有发现这些缺陷的原因：是因为我们模拟环境数据量太小？知识面不全面就没有测试到？还是硬件环境导致的我们这边无法复现只有用户现场那样的环境才有问题（测试不全面导致）。如上种种都是我们需要去总结，去整理然后把这些变成我们的经验，知识，从而更好的服务于项目和公司（用以上数据为依据来分析软件过程是否有问题，并且对问题作出合理的改进计划）。

正确打开方式：

   测试活动贯穿整个软件生命周期。

好了，今天到此结束。如有任何问题请留言及时与我沟通，我会尽快回复大家！谢谢大家~我们下次再见！