测试

放假宅家，在我陈旧的文科生记忆中翻出一句话，貌似是 社会主义在资本主义并不发达的国家中国取得了胜利，从世界资本主义链条上打开了一个缺口，所谓哪里有压迫，哪里就有反抗。

上班这几个月，实在比我想象的要累，不由得开始意淫：软件的革命性发展势必从并不发达的测试领域开始。应用驱动在互联网、移动通信、消费电子这样一些领域促进了软件技术的推广和拓展，软件性能似乎遇到了并行的瓶颈，软件开发本身在方法学的硝烟已经模糊不清了，相对而言，开发的测试环节却是一个相当落后的领域，也就成了一个相对有发展机会的领域。

测试的基础是软件能够实现基本的需求，而不是一个一无是处的软件。这就意味着，测试的对象本身就是一个极具学习价值的实验对象、极具实践价值的理论研究对象。

测试直接关乎软件能够完成应用规定的任务。

测试人员的专业水平决定了通过测试的软件的品质。

所以说，测试非常必要，然而又总是比想象的难办。如果说软件开发超期是常事，那么测试压力超出预期也是常事。可以说，测试并不是测试，高水平的测试背后必然是一个高水平的开发能力。

这给了我一种启示：当我们面对参差不齐的需求文档，面临五花八门的编程方式，作为一个计算机科班的人，实在无法接受“质量保证只能依赖于人工手动测试”的事实。教科书上的“软件测试”的概念被现实中国家关键性领域的软件测试现状残酷的打败了。测试的艺术性、科学性被项目的压力和开发人员的编程水平沉重的打败了。那么，为了质量，我们真的需要这种测试吗？或者说，为了那个“certified”的章，我们除了寄希望于开发人员水平的提高之外没有别的选择吗？

有，那就是把测试当作开发来做。

这有两层含义：1.开发测试工具；2. 把开发作为一种测试手段，作为测试的一部分。（形而上学者可以看出，这就是两个概念的复合组合和平坦组合）。第一层含义很好理解，第二层含义实际上说的是如何做测试的“预期”部分，理论上应当由需求得出，但是现实中，需求文档还远没有达到能够让测试人员在项目进度安排时间内迅速掌握的完善程度，因此，往往是结合被测程序得到的。也就是说，“预期结果”本身，在现实的压力下，通过测试人员的脑袋，间接就受到了被测程序中缺陷的影响。而缺陷的发现，依据的就是“预期结果”与实际结果的偏差，如果“预期结果”不对，那么就可能对实际结果的正确性做出错误的判断；如果“预期结果”不全面，那么就可能遗漏某些实际结果的细节。这两种“预期结果”的问题都会直接影响到测试的有效性。因此，为了得到一个可靠的“预期结果”，可以考虑建立完全独立于被测程序的基准，相当于测试人员要依据需求独立编写一个预期正确的程序。

这其实并没有想象中的难。理由来自于现有测评实践中发现的缺陷数据。这些缺陷中有绝大部分属于简单的实现分歧——比如计算顺序不对，使用的参数不对，计算的条件不对，等等一些低级的功能性、编程错误。排名第二的缺陷相对要高级一些，涉及到一些计算平台的问题，如寄存器长度、编译器的特殊处理等；极少数缺陷涉及到数值计算方法、并发系统理论、实时系统理论等理论性较强，需要借助于模型、或者数学符号进行分析。这意味着，如果采用模型-代码自动生成技术，绝大部分缺陷完全可以规避！当然，实际编程可能会涉及到许多细节性的操作，引入大量的复杂性和可测性问题。分而治之～～～～ 《这个还需要大量实践，尚缺乏可信结论》