从测试的艺术到测试的科学

引子

三星，曾经的Android手机厂商霸主，在推出Note7的时候，一场始料未及的电池爆炸事件，在全球各个市场掀起一次次的冲击波，加上应对不宜，导致大量的产品召回，丢失了2016年手机的高端市场，商誉的极大损失更是无法估计。问题出在电池的品质上，供应商的质量没过关，自己的品管没做好。为什么现代科学管理理论已经诞生100多年了，还会发生这么严重的质量事故呢？三星的品管和检测部门为什么没有在产品上市前发现这个问题呢？解决这种问题是不是需要很聪明、很智慧的头脑？

让我们温习下测试的发展历程，看看测试人怎么做。

测试涵盖的领域很广，我们感兴趣的领域是软件测试，所以本文只讨论软件测试。无论软件测试，还是其他测试，在方法的本质上是一样的。

测试的艺术

1979年测试界诞生了一本经典的开山之作《软件测试的艺术》，现代软件测试的奠基人之一Glenford J. Myers，在书中总结归纳了当今依然常见的白盒测试和黑盒测试的各种方法技巧。方法虽多，做好测试还需要测试人结合心理和测试目标来完成。

测试是一种很难言说的艺术，多年实践，才能略窥门径。前人的测试经验看似寻常，却不易标准化，后人难以掌握。唯有真知灼见，后人细细寻味，才得精髓。

测试的工艺

Paul C.Jorgensen在1995年说软件测试已经从一门艺术走向一种工艺，但是在成为一门科学之前，还有一段路要走。在工业革命引发的大规模机械化生产以前，制成品主要依赖手工业。一个国家的经济是否兴旺发达，除了在贸易上的体现外，还要看手工业是否繁荣、手工艺人是否众多。手工艺人根据产品和身边的原材料选用最趁手的工具，其工作的实质是通过熟练运用工具、掌握原材料的特性，靠人的努力，制作精美的产品。精美的产品饱含工匠精神，手工艺人的劳动不是机械化大规模生产下繁琐的苦差，而是充满了人的创造性和积极性的身心之旅。

软件测试既然进化到一种工艺，测试工艺师（测试人）就必须了解各种基本工具，才能对自己的产品（工作任务）精雕细琢。这些工具包括数学描述工具——集合、函数、关系、命题逻辑、概率论、程序图、有限状态机、状态图、Petri网等，能够用来精确表示被测软件；白盒测试技术——路径测试法、数据流测试法；黑盒测试技术——边界值分析、等价类测试法、决策表等。

测试工艺是大部分测试人员常用的策略和手段。工具再好，要靠人来使用。充分发挥人性的光辉，正是工艺的魅力所在。

测试的技术

艺术和工艺时期，基本的测试技术已经悄悄出现，集中体现在白盒测试和黑盒测试上。测试人员自觉不自觉都会使用这些技术方法来改善测试。地球古生物在寒武纪时期出现了生命大爆发，物种繁盛，生态演进日新月异。同样地，在信息技术的发展史上，大概在21世纪初开始，互联网加速扩张，.COM泡沫破灭后，Web 2.0又带来了互联网的重生，此后iPhone和Android智能手机出现，移动互联爆发性增长，世界从此紧密地联系在一起。

互联网革命带来了技术变革和商业模式变革，软件测试也发生了巨大的改变。在测试的组织方式上，出现了离岸测试、众包测试、云测试（测试即服务）；和测试相关的技术，随着软件工程模式的进化，向开发和最终用户两端渗透，出现了测试驱动开发、持续集成、自动化测试、持续交付，灰度发布、A/B测试，公测，敏捷测试等新形态。

这一时期，最引人瞩目的就是自动化测试的成熟和大面积流行，成熟的框架大量出现，无论是单元测试、接口测试还是UI测试，桌面系统、Web 还是移动，工具应用尽有，令人眼花缭乱。软件测试从此真正可以工程化，依赖各种各样的技术，注重过程管理。只要过程成熟、工具先进、人员合格，就能做好软件测试，在某种程度上能够“保证”软件的质量。

测试技术是开发人员、自动化测试人员和工具爱好者热衷的策略和手段。测试工作分工细致，有人专门分析、设计，有人执行。又有大量的测试开发人员，根据测试的设计，编写自动化测试脚本，开发新的测试工具。可以选择的技术种类、平台框架和测试工具越来越多，但测试人却陷入了单调的日常工作，经验碎片化，人的主观能动性被割裂，对测试的职业发展前景迷茫。很多测试人追逐测试自动化，也有人想着转岗做开发、做需求。

测试的科学

在互联网如火如荼的同时，这个虚拟世界的后台——互联网上的主机也改变了联结方式，融合成云。云计算架构的出现，改变了虚拟世界计算的方式。后台强劲的计算能力加上便宜的存储价格，使得大量数据的存储成为可能，加速了数据的产生。物联网的加入，从桌面、移动到物联网，海量的终端设备日夜不停，分分秒秒都在采集、生成、发送数据到云上。当大数据成为金矿，为了从中获得价值，算法也繁盛起来。曾经冷门的人工智能，在深度机器学习领域取得了突破，开始在某些领域颠覆传统的技术模式，颠覆人类的认知。

科学是严谨的，数学对世界的抽象、建模和推理环环相扣，不允许存在半点错误。软件测试在某种程度上相似，当我们对软件使用度量工具进行度量的时候，我们获得精密的度量值而且误差被严格控制在很小的范围内。Bill Hetzel 在1980年代就下过一个经典的定义——“测试是以评价一个程序或者系统属性为目标的任何一种活动。测试是对软件质量的度量。”对于事物，如果你不能度量它，你就不能掌握它。

从计算数学到计算机科学，再到软件工程的勃兴，软件测试分工的出现，刚开始不被认为是一种科学。然而，几十年来，软件测试人员在测试过程中大量使用了探索、推测、演绎和归纳等经验手段和科学方法，通过观察和试验，了解软件的结构和行为，从而认知被测软件，度量软件。技术的进步和大数据的出现，使得这些方法的依据和基础更加坚实，结果越来越准确。

观察和试验，讲究的是实事求是。我们可以认为测试是一种实证的科学，通过试验、度量来获得对软件质量的认知。有趣的是，在检测计量行业，测试科学的英文来源是Measurement Science，而不是Testing Science，国外的软件测试同行中则有Software Testing as Science的说法。

下图是一种经典的科学方法定义，来自维基百科：

软件测试可以使用经典的科学方法来完成吗？

1)        我们的问题是，软件的质量可以通过测试有效度量吗？

2)        把软件整体看成是一个集合（N），软件行为（处理逻辑）的结果（正确或者错误）是随机变量，它服从某种分布。我们要通过测试这些行为，观察测试结果来度量软件的质量。

3)        我们的假设是，软件的质量可以通过采样的方法来观测，根据大数定律，当采样的次数（n）很大的时候，样本均值将充分接近于总体均值。

4)        尽量把软件的行为（处理逻辑）划分到最小，每一个行为作为一个测试用例，执行这些测试用例（n），获得测试结果。作为实验，这些测试用例是可以重复执行的。

5)        统计所有的测试结果，找出它的分布规律。

6)        按照统计推断的原理，依据样本均值估计总体均值，从而得到被测软件的质量水平，依概率（或者必然）收敛（接近）于某处，或者落在某个区间。

迭代的做法：如果实验结果和假设不符，回到第一步重新开始，修正问题和假设，继续做实验。

上述方法的关键点在实验这一步：

1)        样本n怎样才算足够大？现在软件的复杂度非常高，我们无法测量每一个细节。在设计测试用例的时候，可遵循从上至下，从粗到细的原则不断细化。假设得到的用例样本数是n，取m1<m2<m3<n，依次执行m1，m2，m3和n个测试用例，看测试结果的收敛程度。当测试结果依概率的收敛程度或者说置信区间达到期望（组织的质量目标规定）的时候，n就是合适的；否则继续细化，增加n的数量。另外一个对n赋初值的办法是通过先验概率，如果我们已经具有某些被测软件质量的概率分布经验，我们可以直接以这个先验的n来作为测试用例的样本数，再通过执行结果来修正n。这是贝叶斯推断的方法。

2)        当样本n很大的时候，采样怎样在有限的时间内完成？如果采样（设计测试用例并测试）需要的时间超出预算，那结果和穷尽测试法没有什么本质不同。一是从测试用例的设计上改进，比如建模生成用例。二是在测试的执行上加速，比如利用云的计算力结合智能算法来解决。

测试的科学时代将不可避免地到来，测试人应该大胆地拥抱科学方法，结合新技术提高生产力。在大数据和人工智能的场景下，统计推断会越来越准，对软件质量的度量和把握会越来越可靠，软件测试将有非常迷人的前景。

结论

软件测试从诞生到现在，走过了几十年的春秋，经历了四个时期。那么，软件测试的初衷是什么？是为了验证需求、发现缺陷、排除风险，还是其它？作为软件测试的从业者，必须明了我们的初心，念念不忘，才不至于在日常工作中迷失。目标明确，软件测试就成功了一半。根据软件测试的目标，清楚软件测试方法的局限性和能力边界，认真地完成软件测试工作，我们才能够成功另一半。

四个时期以来，测试人的精神薪火相传，长江后浪推前浪，不断地推进软件质量水平的提升。

质量就是生命，测试人要做质量生命的守护者，这就是测试人的初心。这具有崇高的意义，也会给测试人的职业生涯带来无穷的动力。测试无论是艺术、工艺、技术还是科学，它的初心，从来没有改变。只是，在科学浪潮下的冲击下，测试人面临更多的挑战，也有更多的机会。

参考文献

[1] 梅耶(Myers G.J.)等著，张晓明，黄琳译.软件测试的艺术（原书第3版）[M].北京：机械工业出版社，2012

[2] Bill Hetzel.The Complete Guide to Software Testing[M].美国：AWiley-QED Publication，1988

[3] Paul C.Jorgensen著，韩柯、杜旭涛译.软件测试（原书第2版）[M].北京：机械工业出版社，2006

[4] Wikipedia. Scientific method. https://en.wikipedia.org/wiki/Scientific_method