本文要点

我们需要评估测试的价值，评估就是观察人们的行为、与人们交谈、从根本上测试测试过程的过程。
测试用例不是一个测量单位。
图表并没有告诉我们它本身的意思，我们必须自己弄清楚这个图表是什么意思。你不可能从项目之外了解到。
这是自动化的问题，因为自动化会以特定的方式查看非常具体的东西。人类能以更广泛的方式查看更广泛的东西。人类甚至可以看到我们甚至没有意识到自己正在寻找的东西。
“散焦（Defocusing）”是解决农药悖论的办法。散焦意味着不断地改变你的测试、技术，甚至测试策略。

在此次采访中，James Bach探讨了如何使软件测试变得清晰易懂，以及如何评估测试工作的价值和软件产品中的风险。他谈到了如何克服测试自动化农药悖论，以及我们在测试中应该如何利用AI和ML。Bach拥有超过30年的软件测试经验，他为软件测试初学者提供了三条建议。

Xiaoqian Geng：谢谢您接受我的采访邀请。您周游世界，为软件公司提供软件测试服务，并在会议上发表演讲。您是否可以与我们分享下，您为何在1999年辞掉工作，成为一名独立顾问？我知道这个领域的很多专家都想从事类似的工作，您对他们有什么建议？

Bach： 作为一名软件测试人员，我想毫不妥协地追求我的技艺。这就是我辞职的原因。我当时非常生气，因为我被要求为我工作的咨询公司的一个大客户制作虚假和欺诈性的测试文档。当我拒绝这么做时，客户很不高兴，我的老板也很不高兴，因为我没有尽力去取悦我们的这个付费客户。但是，你知道，那些只要你付钱他们就什么都给的人被称为毒品贩子。我想成为一名医生，而不是毒贩。医生提供尊贵的服务；医生不会给你开你想要的药，也不会对你说你想听的谎话。

所以我决定成立自己的咨询公司。这可能很难，因为事实证明，并没有多少人愿意为你认为对他们有利的工作付费。在我看来，这就是许多咨询公司装模作样的原因。他们必须追求金钱才能保住生意。这和追求卓越是不一样的。

另一种解释是，我真的是一个很难相处的人——从长远来看，我只能为一个完全理解我的人工作，那就是我的妻子Lenore。她知道如何保持我维持创造力所需的环境。她永远不会期望我和一个不太合适的客户一起工作。所以，当我创办Satisfice公司时，我几乎立刻就把它给了她，这样她就会和我一样对它感兴趣。在过去的18年里，我们做得很好。她做所有的后台工作，我做所有的咨询工作。

Geng：如果有一些专家想找和您一样的工作，您对他们有什么建议？

Bach：世界各地都有艺术家、哲学家和科技公司，他们是独立的，他们愿意做出牺牲，为了能够追求自己的技艺而不做大的妥协。但这是非常艰难的生活，如果你就是这样的话，会很难谋生。所以我并不建议人们这样做。在公司里，你必须和有钱人相处。而那些拥有金钱和权力的人往往通过牺牲和妥协来让他们的老板感觉更好。他们往往期望他们雇佣的人也会为他们做同样的事情。

对于测试服务而言，这尤其如此，因为当有钱人想到测试人员时，他们通常不希望有人制造麻烦。他们需要安静的测试人员，或者仅仅告诉他们产品已经足够好了。他们想要好消息。就像这样：如果他们没有任何测试，他们就会因为不负责任而陷入麻烦。如果他们有真诚的、强有力的测试专家，他们就会陷入麻烦，因为测试人员不断地发现问题。但是，如果这些高管雇佣了假的测试人员，这些测试人员通过了ISTQB认证，编写了大量文档，但实际上并没有在产品中发现多少问题，那么，当产品不好时，他们可以责怪这些测试人员，没有人会责怪雇佣他们的高管。我想这就是为什么世界上有那么多的测试咨询公司。有很多人愿意别人出钱让他们马虎做事，使他们看起来很忙，而实际上只要他们安静、有礼貌。

我的意思是，我的工作很辛苦，因为我寻找的客户都希望被告知真相，即使真相很残酷、很不方便。我的客户是那些不想被愚弄或奉承的人。最难的是找到这些客户。

Geng：但是，您很出名，而且有很好的名声。

Bach：你在谷歌上搜一下我。你会发现我有和人争论的名声；他们生气是因为我会对我认为行为糟糕的人大声叫唤。有些人叫我恶霸。我不认为为正确的事情挺身而出是恃强凌弱，我认为好人有责任站出来。但话又说回来，也许那些认为我是恶霸的人都不相信我所代表的是正确的。我想，他们认为我认为对优秀工程而言至关重要的事情，只是我自己的主观臆断。

如何让非测试人员清楚地理解测试工作？

Geng：您说，对于测试，不同的人有不同的观点，有不同的短期和长期期望。在2017年10月PNSQC发布的视频中，您提到的一个非常关键的、困扰很多测试工程师的点，“如果我们要拯救我们的工作和方法，我们需要让非测试人员清楚地理解测试工作”，请给我们简要地介绍下，您认为测量测试价值的最佳方法是什么？

Bach：我不喜欢“测量”这个词。这不是一个有用的词。任何时候你想说“测量”，我建议你使用“评估”这个词。评估是一个比测量更广泛的概念。评估包括测量，也包括人们通常不认为是测量的其他东西。

我们需要评估测试的价值，评估是观察人的过程，是与人交谈的过程，本质上是测试测试过程。我们需要帮助我们的客户理解我们的测试以及为什么它是有价值的。这就是“易读性”这个词的由来。易读性是指某物被阅读的能力。手写是我们所说的易读或难读的东西的一个典型的例子。但易读性的概念不仅仅可以应用于手写。你可以将其应用于任何流程或系统。如果一个系统，你能看着它，说出它正在做什么，那么它就具备易读性。结婚27年了，妻子的情绪对我来说就具备易读性。我几秒钟就能看出她的感受。

遗憾的是，测试往往不像手写或人那样容易阅读。这就是为什么测试人员必须使他们的测试清晰易读。他们使用白板或电子表格来显示有用的信息。他们也通过学习讲述一个测试故事来做到这一点。当测试人员不知道如何讲述一个测试故事时，为使测试看起来清晰，典型的方法是数一下测试用例的数量，或者指着故事卡说“我测试了那个。”但我认为，这是一个可怕的想法。测试用例就是文件。数它们说明不了什么。除非你知道其中包含的内容，否则你就不知道这500个测试用例是符合要求的。也许它只是一个被复制了499次的测试用例。

我没有使用测试用例，而是将测试分解为不同的活动，并为每个活动命名。我可能会提到服务测试、完整性测试、性能测试、功能测试或这些东西的变体。我将给每个测试活动命名。每个活动的名称都是描述性的。非测试人员可能可以借此理解我在说什么。如果我需要解释特定活动中发生了什么，我会谈覆盖（我验证了什么东西，包括我在测试中用了什么数据）、判断（当我看到它们时我如何识别出Bug）和方法（在活动期间我对软件做了什么具体的试验）。我也准备谈谈这种活动的具体动机——可疑的产品风险。

Geng：您如何知道某个软件应用程序中的风险是什么？

Bach：同样，这是一个评估的过程，而不是测量的过程。我们通过结合不同类型的分析来了解风险是什么。

我们可以进行黑盒分析：这意味着我们可以研究一下产品的功能以及它在用户世界中扮演的角色。我们问自己，如果产品表现不好，会对用户产生怎样的影响？你知道，Twitter刚出现的时候，它只是一个不实用的小平台，人们互相发送无用的短信息。如果Twitter宕机，也没有什么风险。不会有人太在意。后来，人们开始使用Twitter来及时通知重要事件。Twitter成为了一个传播灾难新闻的系统。如今，如果Twitter宕机，它真的能伤到人。

我们还可以打开黑盒子，查看系统内部：这意味着我们可以查看系统是如何编码并链接在一起的。我们设想部件失败，并跟踪接下来会发生什么。

我们也可以查看历史：我们可以找出那个产品或类似产品以前出过什么问题。以前发生的事情可能会再次发生。

当我说“找出可能的风险”时，我真正的意思是讨论它。我们要作为一个团队讨论系统及其潜在的故障。我们可能是独自一人，但一般来说，你周围会有具有不同专业知识和经验的人。因此，分析风险的过程不是进行数学计算的过程。这不是计算风险的过程，也不是直接在某种“风险测量仪”上测量的过程，我们就像盖革计数器一样晃来晃去。事情不是这样的。相反，这是一个社会化过程，通关学习来明确我们要担心什么。

讨论告诉我们产品中存在哪些风险。测试告诉我们产品中实际存在的风险。然后，我们发布产品，看看我们是否正确。也许我们是对的，也许还有另一个风险没有被测试发现。随着时间的推移，通过研究任何因为我们未能发现而进入生产环境的问题，我们能够更好地理解真正的风险是什么，对它们做出预测，并针对这些问题进行重点测试。

如何让自动化测试更有效？

Geng：自动化测试是当今大多数软件公司的普遍行为，但是有一个非常著名的争论，叫做“农药悖论”，您能谈谈您的看法吗，如何让自动化测试更有效？

Bach：简单来说，“农药悖论”是指，如果你有一种方法用来发现一种特殊的Bug，那么你就会发现这种Bug，而不是其他种类的。如果这种Bug已经没有了，就什么也找不到了。与此同时，任何其他种类的Bug都会漏掉。你会认为自己测试得很好，因为再也发现不了Bug了，但是你错了。这是自动化的一个问题，因为自动化以特定的方式看待非常具体的事情。人类有能力以更广泛的方式看待更广泛的事物。人类甚至可以看到我们甚至没有意识到自己正在寻找的东西。所以，农药悖论对于自动化测试的影响比对于人类测试人员的影响更大。

但它也会影响人类测试人员，因为人类测试人员也有偏见。一个非常常见的例子是，人类测试人员往往专注于边界测试。在我的测试人员教学中，边界测试是最常用的技术。问题是：并没有很多Bug是边界Bug。如果你只使用边界测试，并且没有发现问题，你就会认为产品良好。

因此，给测试人员授课很大一部分是教他们如何散焦。散焦是解决农药悖论的方法。散焦意味着不断地改变你的测试、你的技术，甚至你的测试策略。你也可以使用工具来实现这一点。

你知道，我不使用术语“测试自动化”，因为我不相信测试可以自动化。当人们说测试自动化时，他们的意思通常是使事实检查自动化。他们在查看特定的东西，查看那些特定的东西是通过还是失败。这是自动检查，但肯定不是自动化任何懂测试的人所做的一切测试。当我作为一个人进行测试时，我不会孤立地看待具体的事情，我同时也在寻找线索。我在寻找奇怪的东西。一旦我发现了一些奇怪的东西，我就会调查它。然后，当然，通过这个调查，我可能会发现一种新的Bug，在开始的时候，我甚至都没有往这个方向想。机器永远不会那样做。只有人类。

如果我使用的是自动化方法，我通常会随机化测试数据。这样，我使我的自动化可以自我更新。我也使用数据驱动的自动化，所以我所要做的就是从上面更改数据文件。我不必更改工具可能使用的代码。我不需要重写自动化。自动化可以始终运行相同的代码，但是使用不同的数据库或不同的环境。

Geng：这是与上下文驱动测试类似的概念吗？

Bach：不。那完全是另一回事。简单地说，上下文驱动测试意味着你抛弃了测试的“最佳实践”，而是在上下文中看待测试问题并简单地解决它。测试人员是技能型人才，技能型人才会使用不同的实践，会使用不同的技术，会使用不同的方法和不同的工具，这取决于他们所处的特定情况。你获得自己的测试技能，做任何需要做的事情，而不是记住一种正确的测试方法。你可以说上下文驱动测试是基于人类技能的测试哲学。换句话说，它是工程学。因为这就是工程。一个熟练的工程师，一个训练有素的工程师，会仔细了解情况，解决那个情况下需要解决的问题。

这与工厂学校的测试形成了鲜明对比。工厂学校的测试会认为技能不是很重要。关键不在于技能，而在于遵循流程。在工厂学校，他们希望你写下测试用例，写下测试脚本，然后他们希望你自动化它。就像工业革命时期的工厂一样，他们想把人完全剔除掉。在上下文驱动领域，我们认为这是一个非常糟糕的想法。首先，它甚至无效！这导致了农药悖论。它会导致测试质量低下，成本高昂，而且缺乏人性化。

上下文驱动者是人文主义者。

Geng：您刚才提到工厂学校测试。但是，大多数公司仍然使用这种方法，因为它很容易可视化测试的数量？

Bach：什么叫很容易可视化测试的数量？

Geng：比如，多少测试用例，覆盖了多少测试场景。

Bach：但那是谎言！他们说这很容易可视化，但这根本不是可视化测试的数量。他们不知道测试的数量是多少。如果你说你有500个测试用例，你只是有个数字500。你不知道这500个测试用例是什么。我这么说吧。如果你说你要走500英里，你可以将其可视化。因为英里是一个标准的测量单位。但是，如果你说你要旅行500段，没有人能将其可视化。比如饼干。你可以拿一块饼干，放在手里。那是一块饼干。然后你握紧手，它就碎了。现在，你张开手。你手里只有几块饼干，却有一万个碎屑。同样的饼干，以前是一块，现在变成了1万个碎屑。只是打包方式不同而已。你改变了饼干的打包方式，但它还是那块饼干。测试也是如此：在某些打包方式中，你可以称之为一种情况，但是这种测试的价值可能与这里的500个测试用例相同。测试用例不是测量单位。

让我这么说吧，我已经52岁了，一旦你老了，公司就会由比你年轻的人经营。突然间，公司经营不善的原因就讲得通了：这是因为孩子们在经营公司。他们是小孩子，但他们现在在经营公司。在20岁的时候，我想，也许那些年长的人知道一些我不知道的事情。也许他们有一些秘密，使得其管理行为变得明智。现在，我已经在这个社区生活了30年。我知道他们没有什么秘密。

人们仍然计算测试用例数量的唯一原因，要么是他们拒绝学习如何管理测试过程，要么是他们信任那些拒绝学习的人。他们从来没有长大。的确，在我很小的时候，我也计算过测试用例数量。但后来我长大了。

Geng：测试用例的数量并不能显示测试的有效性，它是一种测量人们工作有多努力的方法。这并不意味着工作是否有价值，这是另一种角度。这是完全不同的。也许我们可以使用测试发现的Bug数量来评估它们所创造的价值。

Bach：您使用Bug的数量来测量测试的价值吗？

Geng：很难说，例如系统测试，你发现了一个Bug，但是这个Bug可能非常关键、非常复杂、非常有价值。

Bach：完全正确。我用过Bug指标。你可以使用Bug指标来做一些有趣的事情，特别是在项目中报告了大量Bug时。你可以画图表。根据图表，你可以问一些有趣的问题。不过，话虽如此，我认为重要的是讨论测量；看看这些图表，想想这意味着什么，我们应该怎么做？这是这个过程中很重要的一部分。这个图表并没有告诉我们它本身是什么意思：我们必须弄清楚这个图表是什么意思。你不可能从项目外知道这些。所以我们用Bug计数作为提出问题的一种方式，然后我们会去调查，并通过与人交谈来得到这些问题的答案。

有时，人们会给你一些图表，而这些图表代表着一个虚假的故事。当人们对真相感到尴尬时，他们可以伪造或掩盖数据。人们可以躲在数字后面。你需要意识到这一点，任何从事管理和使用指标的人都应该知道这一点。管理人员应该做的是降低对数字的重视程度，这样人们就不会有那么大的动力去撒谎或隐瞒数字。

对于人为过程的测量从来都是不客观的。Bug报告是一个人类社会过程，它不是一个物理系统。它不像测量火山。想象一下，如果火山对地面温度在情感上存在自我意识，并有意识地在地质学家放置温度计的地方抑制其岩浆活动。那测量将是错误的。但这种想法太愚蠢了。火山不在乎被测量，但人在乎。

新技术对测试方法会产生怎样的影响？

Geng：您认为新技术将对测试方法产生什么样的影响？例如，AI/ML如何帮助提高测试效率和充分性？

Bach：使用任何工具都要面临的问题是，你必须了解该工具的功能，以便你作为测试人员可以正确地使用它。如果你不了解这个工具的功能，那么你就不能依赖它。你仍然可以使用它，但不能依赖它。举个可以使用但不能依赖的例子：一个孩子。我可以让一个十岁的孩子在我的产品中寻找Bug。我可以让一整个教室的孩子检查这个产品，他们可能会发现一些Bug。如果他们这样做了，你不会放过那些Bug；你不会说，我不能接受这个Bug报告，因为你还是个孩子。你可以接受这些Bug，但是还不能说产品已经经过了适当的测试。

另一件你不能做的事情是问10岁的孩子，“你是怎么发现这个Bug的？说明你的方法以及如何才能做得更好。”这个儿童测试人员的例子完全等同于一个人工智能工具。如果你有某种深度学习工具可以会为你做测试。你说，“好的，超级工具，测试这个产品”。它就会发出嘟嘟声……并说，“发现了三个Bug。“这就像一个孩子为你发现了三个Bug。

当我作为测试人员与你交谈时，我可以询问你的技术。你给我的答案让我开始信任你。你说，"我在用这个技术，或者那个技术。”我问你能否演示一下你的技术，你说：“好吧，我可以演示一下。”然后，我问你关于你的判断和你的覆盖率的问题，你可以回答我的问题。你的回答让我越来越相信，你正在处理它。

我认为，对于人工智能，人们想要一种神奇的工具，他们会信任它，就像儿童读物里虚构的朋友一样。我把人工智能称为“自动不负责”，它实际上就是那样。

我没有看到任何AI工具是透明的。我认为他们没有赢得信任。但如果你想要这样的工具。如果你想相信它，你必须测试它。这个测试过程将非常广泛。而且，这个工具的范围会非常狭窄。因为机器学习是建立在训练数据的基础上，而训练数据是非常具体的。如果某样东西是专门针对某个东西以某种方式训练出来的，那么它可能就不擅长测试稍微不同的东西。我们应该问这个系统是如何训练的，我们如何知道训练数据是恰当的、没有偏见的数据。因为数据中的任何偏差都会成为机器中的偏差。我们必须问自己，我们是否要依赖这个？
给希望从事测试工作的人的三条建议

Geng：谢谢您！如果请您给新晋测试人员提三条建议，您会提什么？

Bach：1.安全测试现在非常热门。如果你对安全测试人员需要知道的所有细节感兴趣，我建议你进入网络安全测试专业。

2.我想说，如果你想学习编程，那你绝对应该学习编程。如果你不想学习编程，那么，如果你为一名优秀的测试经理工作，你仍然可以作为一名测试人员做得很好。但是，如果你对自动化不熟悉，就很难找到一份测试的工作，因为有太多的测试经理认为自动化是很好的测试。就我个人而言，我认为在测试领域，如果我们让每个人都成为程序员，情况会更糟。我是一名程序员。我并不反对程序员。问题是，作为一名程序员，我倾向于在测试时编写一个工具。我想写一个软件来帮助我测试。这常常使我无法进行测试。我需要那些对代码不那么感兴趣的人让我专注于实际的测试过程。

3.这是我的最后一条建议：“找一位导师。”找一个不一定在公司和你一起工作的人，你可以向他咨询，可以向他吐槽。或者加入一个测试论坛。

Geng：这听起来很不错！谢谢您和我分享这个。我们已经完成了今天所有的问题，非常感谢您今天抽出时间，也非常感谢您能给我讲测试故事和测试经验。我相信所有的测试人员都能从中学到东西。谢谢您！

关于受访者

James Bach一直是一名测试人员、测试经理或测试顾问。他从事测试工作已有31年，著有《软件测试经验与教训》和《学习要像加勒比海盗》。他是快速软件测试方法的创建者，也是代理或算法的坚定捍卫者。

关于采访者

Xiaoqian Geng从事软件测试工作12年多。她在测试大会上做过题为“软件测试自动化的六大演进”和“大数据测试的挑战”的公开演讲。她拥有美国专利“基于手势的应用程序自动化测试”。现在，她是美国旧金山Splunk公司的QA/测试总监。

英文原文：https://www.infoq.com/articles/james-bach-testing-career

活动推荐

12 月 7 日北京 ArchSummit 全球架构师峰会上，来自爱奇艺、美团、蔚来汽车、京东的讲师齐聚一堂，共同分享“基于AI移动化测试”、“质量保障实践”和“搜索系统质量保障”等技术相关经验与实践。详情点击 https://bj2018.archsummit.com/schedule

创作场景

深度解读：如何评估软件测试工作的价值？