有些软件的功能非常简单，比如简单的数学运算，或者统计用户输入字符的数量；有些软件的功能非常复杂，比如操作系统，或者汽车的自动驾驶算法等等。
对于复杂的软件，因为它们极高的复杂度，我们很容易理解它们为什么很难“完美”，所以，强如微软，也会发生比尔·盖茨演示Windows 98时蓝屏的尴尬；强如特斯拉，也会发生自动驾驶状态的汽车径直撞向大货车的悲剧。
那么，对于特别简单的软件，我们是不是可以进行"彻底"的测试，保证它们是完美的呢？
这是不可能的！即使拥有无限的预算，我们也无法做到这一点。
我们来分析一个简单的程序：它接受用户输入的字符串，统计其中的字符数量。比如，对于输入字符串"Python", 统计结果为6, 对于"test", 统计结果为4，等等。
要确保这个程序是"完美"的，我们就需要验证所有可能的输入。用户可能输入一个简单的字符，也可能输入整部《三国演义》，或者更多，我们无法预知用户的输入，用户输入的字符的数量在理论上可以是任意一个自然数，而自然数的数量是无穷大的，我们无法把所有的情况都覆盖到。
如果把问题简化，限定用户最多只能输入10个字符，超过10个字符的情况就告知用户无法处理，这种情况下，我们能否进行"彻底"的测试？
这也是不可能的！
在用户输入超过10个字符的情况下，程序真的会告知用户无法处理吗？为了确认这一点，我们需要把所有超过10个字符的输入都覆盖到，确保程序会告知无法处理，而不是意外地返回一个错误的统计值。大于10的自然数仍然是无穷多的，我们还是无法把所有的情况都覆盖到。
如果我们把问题再度简化，只测试字符数量在10以内的"有效"输入呢？
世界上有许许多多的语言和文字，unicode编码可以涵盖世界上所有语言的字符，它包含的字符的数量级大概是一百万。粗略地估算下来，用户输入字符数量为1的情况，我们有100万个测试要验证；用户输入字符数量为10的情况，我们有100万的10次方个测试要验证,只要有一个测试没有被覆盖到，我们就不能打包票说在那种情况下程序可以正常工作，也就不敢打包票说程序是没有bug的。
就像发财“捷径”买彩票一样，每一组号码要买都是要钱的，买下的号码很可能都打了水票，但是你总觉得你没买的号码里可能有”惊喜”。
在现实世界中，绝大部分的软件程序比这个字符统计的程序要复杂得多，它们一定或多或少有bug没有被发现，或者有bug被发现了却没有被修复，它们肯定称不上完美，却仍然达到了较高的软件质量，这当然不是因为它们把测试做得非常彻底，而是因为放弃追求不切实际的"完美"，在预算范围内采用了合适的测试策略，得到较高的投资回报率。
其中的一个策略，是关注核心功能。
我们在买新车的时候，会对车进行非常细心的检查，刹车灯不亮，雨刮器有异响，或者轮毂有轻微刮擦，都可能导致我们拒绝收车。
在买二手车的时候，情况就不一样了，因为我们会有充足的心理准备来接受不完美。面对一辆标价5万的二手轿车，我们在验车的时候一定会重点验证发动机、变速箱、车架、转向机；至于空调是不是能制冷，我们可能会关注，但是不会过多影响我们的决定；至于车门上的车漆是否有色差，我们根本就不会花时间去看！
为什么买二手车的时候，我们变得不那么挑剔了？
是因为"穷"！
其实，我们还是挑剔的，只是，因为预算有限，我们深知无法买到完美的车，所以我们会做妥协。软件测试的思路也是这样的。我们无法保证软件产品的"完美"，在预算和资源有限的情况下，我们需要专注于软件的核心功能，尽量保证核心功能得到良好的测试。
以字符统计的程序为例，如果它的主要用户是中国用户，我们可以重点测试中文和英文字符，而不需要花精力去测试程序对于亚美尼亚语字符的表现，在非核心功能的测试成本比较高的情况下更应该如此，否则，我们花费了宝贵的人力和时间，只是收获了用户可能并不太在乎的完美度，就像是架起高射炮只是为了打蚊子，成本很高，收益很小，不值得。
合理的软件测试思路是把钱花在刀刃上，重点关注核心功能的测试，预算有限时应该如此，预算充足时同样应该如此。
本文内容节选改编自码农徐西宁写的《软件自动化测试实战解析_基于Python3编程语言》一书，更多关于软件自动化测试的内容，请戳这里下单：
友情提示：出版社特别提供了额外的粉丝限时福利（2021年8月有效），有更多优惠哦：
* 本书的范例代码提供免费下载, 请关注公众号，发送消息“代码”，即可得到下载地址 *
