和也是做软件测试的朋友聊了下软件测试的一些话题，有感所以写了点东西。

关于bug漏测：

       非测试人员最喜欢问的就是，为什么会有漏测？其实这和开发写的代码中有bug是一个道理。开发不能保证自己的思路一定正确，也无法保证程序各种路径、环境、状态下都工作正常。测试人员也一样。有了测试人员只是增加了一层扑捉bug的网，但是总有漏网的。因为测试人员是最后一道防线，所以任何漏了的，测试人员都有责任。要分析遗漏的原因，思考改进的方法。虽然漏测总是有，但是只有这样，才能让测试人员有足够的质量意识，不断减少漏测。减少漏测是一个系统的工程。

       首先要测试要清楚开发所有的修改（由于沟通的问题，或者开发偷偷修改，测试不清楚有些特性被修改了，这种事情并不少见），接下来测试点的全面性、测试方法的有效性、测试用例的正确性，再之后还有执行测试时策略的合理性。但是只做好上面的工作仍然不够。最终执行测试者的作用是不可替代的，包括结果检查的充分性、尽量变化的取值、顺序与组合（这方面主要看执行者个人意识和经验），另外更重要的就是要做探索测试。

关于探索测试：

       探索测试是无法通过前面的工作完全替代的。之所以探索测试很有价值，是因为前面的内容主要是通过对需求和设计的分析，得到需要测试的内容和对应的测试方法、步骤。但是软件测试的目标不是验证软件应该做的事情，而是发现bug。上面关注的是正确性，而探索测试更多的关注的是错误，关注软件在什么情况下可能会发生什么样的错误。

       正确的事情是可预期的，错误的事情却不可预期，可以出现各种出乎意料的错误。比如基本的有效等价类、无效等价类这些会列入案例测试点。但是无效到有效的切换呢？有效到无效的切换呢？甚至无意义的无效到无效的切换是否要测试？是否有效A、B、C，无效A、B、C之间的切换是否要进行组合呢？另外切换的行为组成一个事件流组合成不同的路径，可以切换无限次，也就有无限种路径，需要如何进行路径覆盖呢？这些不是单纯的设计能够回答的问题。

关于测试设计：

       概念上讲测试设计是比测试执行要更有难度。但这并不是绝对的。测试执行也是很有价值和挑战性的。

       因为杀虫剂效应，优秀的测试设计，也会很快失去效力。如果测试执行者主要的bug来源都不是源自测试设计，那么测试设计也就失去了作用。所以要不断的重新设计，但是最佳的理念在第一次优秀设计中已经都体现了。重新设计无法是本质性的变化。如果有很多项目，那么可以独立出单独的测试设计职位。但是一个测试设计师长期在一个项目中，恐怕这个职位将难以专职。开发的架构和设计则不同，设计的好，使得软件长期来看都是稳定的状态。外人长期看来这设计都很有价值。

能测出好软件吗？

       好的软件是写出来的，不是测出来的。差的软件，再怎么测，再怎么改，也是不可能成为好软件的。因为架构和编码的质量不仅决定了软件的质量，还决定了会有哪种类型的bug。如果是架构和编码风格好的软件就不容易出现那么多奇奇怪怪匪夷所思难以发现的bug。

       比如架构时各模块耦合性太大，那么就会出现各种难以预期的影响传递。最常见的恐怖编码方式就是复制、粘贴大法，这种代码可能忘记修改任何地方，所以会产生各种匪夷所思的bug。比如两段代码逻辑类似，但是在被复制的另一段代码中8972是特殊值，新逻辑中忘记修改了，结果突然有一天发现8972竟然被特殊处理了。比如变量名缺乏意义，结果用错变量。如果从需求覆盖上就可以暴露，那就好说。如果是需求覆盖时覆盖不到，那只能听天由命了，因为错误猜测也猜不到呀。错误猜测也要讲逻辑呀。比如密码是123456，那么我输入12345，输入1234567，这叫错误猜测。如果密码是123456，输入877aa认为密码错误，但是如果输入877ab，软件也认为是密码正确，这种bug，测试人员也无能为力。另外差的软件，因为耦合性大，修改一个bug，往往引入更多bug。Bug永远无法收敛。

再说探索测试：

       上面的密码的例子比较极端。更多的其实是顺序和组合类、还有环境变化的问题。如果能够提取出有限的因素数目，即使全组合排列，自动化几千种情况也不是什么大问题。虽然几千种全覆盖，通常没有什么意义。但是问题域的边界是可以变化的，问题域又相互交叉，覆盖率很难保证。更致命的是因素总数是惊人的。这导致数字上的不可能。但是其实有经验、意识好的测试执行人员，可以做有效的探索测试来发现这些问题。如果发现这方面的问题，他就会继续加强探索。好的开发人员也会好好去检查相关代码。如果用户填一个订单有五个步骤，每个步骤有5项内容需要填写，每项要填写的内容有2个有效等价类，这样有效等价类是50个。很容易覆盖。但是有效等价类的全组合是2的25次方，显然不能完全覆盖。另外考虑回退操作，第二个页面可以回退到第一个页面...第五个页面可以回退到第四、三、二、一个页面。每回退到一个页面，可以修改任何项内容的值，可以修改为同一有效等价类的另一个值，也可以修改为另一个有效等价类。

       这个路径还可以很长，操作到第四个页面，回退到第三个页面，修改两项内容，然后回退到第二个页面修改一项内容，然后前进到第五个页面修改3项内容，然后退回到第二个页面再次修改刚刚被修改过的内容，然后修改另一项内容...。这些路径怎么覆盖？所以有经验的测试人员他会考虑项目之间的可能的耦合性，比如有几项内容都和地址有关系，那么这几项内容是否会有相互干扰，尝试让这几项有出现相同、不同、重叠、包含、相似等等关系。至于回退可以使用一些有思路的探索，比如最后一步再回退、第二步就会退、回退一步、回退多步、回退后修改所有内容、回退后只修改一项内容、只回退不修改内容、逐页回退并且修改、一直回退到第一步然后前进着修改每一步的内容等等。

       但是如果代码写的很乱，平铺直续，结构化很差，各种特殊情况满天飞，各种逻辑交叉。存在第四步退回到第二步修改第二项和第三项内容，之后提交出现故障。这种毫无征兆的，毫无逻辑耦合预示的bug，是只能偶遇不能相请的。常见可见的耦合性有后面某一项的可选内容，由前面的某一项的值决定。更复杂一些的，就是由前面几项内容的值共同决定。围绕这种耦合性来做探索才是有价值的。

作者：jxzdsw

原文链接：https://blog.csdn.net/jxzdsw/article/details/113546909#comments_14936400