软件测试之道

测试技术来了

       市场上充斥了许多介绍软件测试技术的书籍，例如 Paul C.Jorgensen著的《软件测试》，但任何测试技术的出现定有其背景，而打开不少这些测试书籍，扑面而来的就是黑盒测试、白盒测试、路径覆盖等等技术定义。为什么要区分黑盒白盒，难道真的是因为测试时有没有代码吗？为什么又要区分路径覆盖、语句覆盖等等，他们有何异同？本文限于篇幅，不展开介绍。但是我想指出的是，只有搞清楚这些技术根源，才有可能正确的运用这些技术，而技术定义根本不重要，大家不要陷在里面，只见树木，不见森林。本文的题目是测试之道，显得有点唬人，更准确的说就是谈谈测试的深层次根本问题，而不是在我看来的肤浅的技术问题。

测试是什么

       软件测试本质上和其他测试没有区别，通俗的说法，就是试试软件产品好不好使，具体的说来就是选择输入到软件，看看输出结果是否达到预期，就这么简单，所谓各个级别的测试、各色测试技术，只要是测试，都是选择输入，判断结果。

测试的局限性

       绝大多数情况下，仅仅通过测试，无法确保被测的软件没有缺陷，这种局限性是由测试本身天然注定，因为测试不是证明。这就如同想表明勾股定理是正确的，即使举了不计其数的服从勾股定理的例子也不能否定存在意外的情况，这里的例子就如同软件测试的测试用例，因此对于软件测试，即使执行通过了不计其数的测试用例也不能否定存在意外的情况，而存在这种意外情况就表明软件存在缺陷。这种局限性如此简单以至于很少有测试书籍直接指出来，倒是有不少书说测试是门艺术，显得高端大气上档次，但是我觉得跟中文字面上的艺术没有半毛钱关系。正是由于测试的局限性，不得不采取一些启发式技术来确保测试的充分性，例如测试要达到95%的分支覆盖就可以给人足够的信心。也正是因为启发式技术，达到同样的95%分支覆盖，有的测试人员能够给人测试充分的信心，有的却不能，这就取决于测试人员的能力、责任心等等。而这因人而异的部分就被认为是艺术，真会往自己脸上贴金。

等价类仅仅是个概念

       现如今，每次我听到有人在黑盒测试时，划分测试输入的等价类，我就头疼，不管实现有多么不同，他们划分的等价类总是相同的，对于这种所谓的等价类划分我向来表示怀疑，在某个实现里面这个等价类的所有输入可能走的是相同的执行路径，在另外的实现里面，这个等价类的所有输入可能各走各的路了，因此这种等价类划分不具备科学性。如果根据分支覆盖或者语句覆盖进行输入的等价类划分，具有合理性，但又丧失必要性，并且等价类就是起源于黑盒测试而非白盒测试，因此我觉得等价类划分，于黑盒测试来说不科学，于白盒测试来说没必要，因此就让它永远存在于概念中吧。

自动化随机测试是个好想法

       既然等价类划分不好使，我的意见就是把所有的输入全测试一遍，显然，所有人都会认为这是不可能的。那怎么办？编写自动测试框架，有效自动随机选择测试输入，自动判断测试结果，持续不断的反复运行并记录结果。现在无论是个人PC还是机群，价格不贵，性能很好，完全有能力执行自动测试。问题的关键在于编写自动测试框架，而这不亚于一般的软件开发，不过如果你希望得到高质量的软件，这绝对是不二选择，看看微软的windows操作系统系列，现在为何漏洞越来越少，高效的自动化随机测试肯定功劳不小，其他的如Adobe Reader，软件测试也采用了这个技术，软件质量也明显提升。因此如果你想从事软件测试，了解一下自动化随机测试，很有必要。

你的软件你最懂

       当前，国内流行第三方测评，尤其军用软件，军方一般会指定第三方测评机构对软件测评。其初衷是好的，但是就我了解的情况，效果并不理想。如果第三方测评仅仅是对软件进行评价，我觉得这个可以操作，即使很难。而现实情况却是要求测评机构去发现软件缺陷，或者说证明软件没有缺陷，我觉得这个难以实现，很多人会反驳我，认为测总比不测的强，但是我想说的是测试成本可是真金白银，花了很大的力气却说明不了问题，因此还是需要讲求性价比的。

       那么这个与懂不懂软件有什么关系呢？我认为最最关键的软件测试人员就是开发人员自己，因为只有他才最了解自己软件实现的弱点，前提当然他必须认真负责。而其他测试人员只能作为补充，这种补充是需要的，智者千虑，必有一失。但是将其他测试人员尤其是那些根本不了解具体实现的测试人员作为关键测试人员，是极不明智的。

       是不是不可以将软件测试的任务完全交给第三方呢？也不是。有些重要场合是可以完全交给第三方测试，但必须有详细的各种文档，从需求到设计到实现，当然这种成本高了去，谁能承受？

测试测的就是责任心

       很多情况下，测试用例多写一个少写一个，测试情况多考虑一点或者少考虑一点，都没有明确的指标来衡量，这与软件功能不一样，一般情况下要么实现了，要么没有实现，还是可以衡量的。既然测试好坏不容易衡量，从事软件测试工作的心理压力就可以少很多，而不管现在还是未来的软件缺陷都是开发人员造成的。问题的危险性也就在此，如果压力都在开发人员那里，那要你测试人员干什么？因此我想说的是，如果开发人员自己测试，你要相信，现在多花1分钟测试，以后可以少花1小时去定位莫名其妙的缺陷，如果测试人员从事测试，认认真真，于人于己，功莫大焉！

结束语

       软件测试追求的不是覆盖率，不是花哨测试技术，终极追求还是软件质量，永远不要把手段当成目的。