按测试员的方式思考

9,619次阅读

测试员有很多不同的背景，测试团队是多元化的集体，但是大多数人都同意：测试员的思考方式是不同的。怎么不同？有人说测试员是“消极”思维者。测试员会抱怨这种说法，认为自己喜欢征服，他们在报告坏消息时有一种特别的兴奋感。这是一种普遍观点。我们提出另一种观点。测试员并不抱怨，他们提供的是证据。测试员并不喜欢征服，他们喜欢打破产品没有问题的幻觉。测试员并不喜欢发布坏消息，他们喜欢把客户从虚假信念中解放出来。我们的观点是，按测试员的方式思考意味着实践认识论。测试运用的是认识论，不是靠傲慢或谦卑。

测试运用的是认识论

认识论研究如何认识所了解的东西：研究证据和推理。这是科学实践的基础。研究认识论的人有科学家、教育家和哲学家，当然还有精英级的软件测试员。学习认识论的学生研究科学、哲学和心理学，目标是了解怎样才能改进我们的思维。我们使用的术语比经典定义要宽，以便能够更多地利用批判性思维的最新成果。将认识论运用于软件测试，要问与以下类似的问题：

怎么知道软件足够好？
如果软件并不是足够好，怎样才能知道？
怎么知道已经完成了足够的测试？

研究认识论有助于更好测试

直接与软件测试有关的认识论问题包括：

如何收集和评估证据。
如何进行有效的推论。
如何使用不同逻辑形式。
拥有合理的信念意味着什么。
形式和非形式推理之间的差别。
非形式推理的常见谬误。
自然语言的含义与模糊性。
如何做出好的决策。

研究认识论可帮助测试员设计有效的测试策略，更好地意识到自己工作中的错误，理解自己的测试能够证明什么、不能证明什么，并编写出无懈可击的测试报告。

认知心理学是测试的基础

如果说认识论告诉我们的是应该怎样思考，那么认知心理学告诉我们的是我们是怎样思考的。与测试有关的一些问题包括：

人的感觉和记忆可靠性。
信念从哪里来。
信念如何影响人的行为。
做出决策所使用的偏见和捷径。
如何了解并分享所知道的信息。
如何考虑复杂事情。
如何识别模式。
如何把想法和实物分类。
如何注意事物之间的差别。
记忆事件中的失真。
如何重新构建部分记忆的事件（例如不可再现的程序错误）。

研究认知心理学有助于理解影响测试员工作成绩的因素，以及影响人们解释自己工作方式的因素。测试应该使用因果关系理论进行系统推理，而不只是查看外部行为，并对照简单的预期描述进行检查。

测试需要推断，并不只是做输出与预期结果的比较

流行的观点认为，测试员只是执行测试用例，并对照预期结果比较执行结果。这种观点把测试看做是简单的比较活动，没有看到一些聪明人必须设计测试，并确定预期输出。想想看，测试设计人员几乎从来没有得到过应该测试什么的权威指导，更不要说应该期望什么了。可以得到的指导是要解释的主体。在现实生活中，大多数测试设计都是基于推断，或基于与测试员的推断有关的经验。不仅如此，这些推断还要随时间发生变化。像测试员那样思考，就是要掌握探索式推断的艺术。

探索式推断听起来可能像是奇怪的想法，这意味着要以一种不能事先预测的方式，通过一种思想引出另一种思想，然后再引出下一种思想。

优秀测试员会进行技术性、创造性、批判性和实用性地思考

各种类型的思考都要考虑测试的实施。但是我们认为需要提出四种主要思考：

技术性思考。对技术建模并理解因果关系的能力。这包括诸如相关技术事实的知识和使用工具并预测系统行为的能力。
创造性思考。产生思想并看到可能性的能力。测试员只能以能够想象得到的方式进行测试，只能寻找猜想会存在的问题。
批判性思考。评估思想并进行推断的能力。这包括在自己的思考中发现并消除错误的能力，将产品观察与质量准则关联起来的能力，以及针对特定信念或所建议的行动过程构建有说服力的测试用例的能力。
实用性思考。把想法付诸实践的能力。这种能力包括诸如运用测试工具，并使测试手段和力量与项目范围适应的技能。

总之，像测试员那样思考，会最终导致相信事物可能不像外表看起来那样。不管事物是怎样的，都可能有差别。我们发现，当测试过程以最具破坏性的方式失败时，根本原因最有可能是视野狭窄。换句话说，这不是运行了一万个测试，而本来应该运行一万零一个的问题；问题是没有想象出测试的总体大纲，没有做就算有两倍时间和资源也不会做的测试。

黑盒测试并不是基于无知的测试

黑盒测试意味着产品内部知识在测试中不起重要作用。大多数测试员都是黑盒测试员。为了做好黑盒测试就要了解用户，了解他们的期望和需要，了解技术，了解软件运行环境的配置，了解这个软件要与之交互的其他软件，了解软件必须管理的数据，了解开发过程，等等。黑盒测试的优势在于测试员可能与程序员的思考不同，因此有可能预测出程序员所遗漏的风险。

黑盒测试强调有关软件的用户和环境知识，这一点并不是所有人都喜欢的。我们甚至把黑盒测试描述为基于无知的测试，因为测试员自始至终都不了解软件内部代码。我们认为这反映出对测试团队角色的根本误解。我们不反对测试员了解产品的工作原理。测试员对产品的了解得越多，了解产品的方式越多，越能够更好地测试它。但是，如果测试员主要关注的是源代码，以及能够从源代码导出的测试，则测试员所做的工作也许就是程序员已经做过的，并且测试员关于这些代码的知识要少于程序员。制造问题的思路，无法解决问题。

测试员不只是游客

测试员对产品做的大量不是测试的事，有助于测试员对产品的了解。测试员可以浏览产品，看看产品由什么组成，怎么工作。这样做有很高的价值，但这不能算是测试。测试员和游客之间的差别在于，测试员把精力放在评估产品上，而不只是见证产品。虽然不必事先预测产品应该表现出的行为，但是试验产品能力的活动还没有成为测试，除非而且直到测试员运用某种如果问题存在就能标识的原理或过程时，这种活动才能成为测试。

探索要求大量思索

探索就是侦查，是没有边界的搜索。可把探索看作是在太空中遨游，需要前向、后向和侧向思索。

前向思索。根据已知探索未知，从看到的探索还没有看到的，注意支流和副作用。例如，看到一个打印菜单项，点击看看会发生什么。
后向思索。从怀疑或想象的东西返回到已知，尝试证实或否定自己的推测。例如：怀疑是否有打印这个文档的方法，于是打开菜单并检查是否有打印菜单项。
侧向思索。让自己的工作由于新冒出的想法而转移，然后再将探索主题返回到主线索上。例如：这个图很有意思。嘿！我想该打印一些更复杂的图，看看会怎么样。

即使没有要测试的产品，也可以探索。可以使用同样的思索过程探索一组文档，或与程序员面谈。通过构建更丰富、更具想象力的产品模型，探索也会不断取得进展。这些模型以后会使测试员设计出有效的测试。

运用试探法快速产生测试思路

试探法是一种经验规则，是一种基于经验做出猜测的方法。由于可能的测试用例数量是无限的，因此肯定要选出在所面临的时间和预算约束条件下有效的少量测试用例。有经验的测试员会收集并共享能够改进其猜测质量的测试试探方法。一组好的试探方法有助于很快地生成测试。以下是采用试探测试的一些例子：

测试边界。边界更有可能暴露规格说明的模糊问题。
测试所有错误信息。错误处理代码与主流功能代码相比，一般比较弱。
测试与程序员的配置不同的配置。程序员已经偏信自己的配置没有问题。
运行比较难设置的测试。在其他条件相同的情况下，易于设置的测试更有可能已经被执行过。
避免冗余测试。如果某个测试实际上是重复其他测试，就不会产生新价值。

为了明智地运用试验法，请注意：试探法中并没有智慧，智慧来自测试员。试探法所能够做的，只不过就是为测试员的思考提出建议。盲目使用自己并不了解的试探法并不是好的测试实践。在收集测试方法时，要了解每个方法背后的原理，以及更适用和不太适用的条件。

测试员不能避免偏向，但是可以管理偏向

测试员是有偏向的，这使得测试员选择一部分测试的可能性要比其他测试大。如果有一个很长的编辑字段，测试员也许更可能输入诸如111111111111，而不是32432874238，因为输入字符重复的字符串，要比从0到9随机选择数字更容易。也许这是一种很小的偏向，但仍是一种偏向。更糟的偏向是，大多数测试员倾向于测试最可视的功能，不管是不是最重要的功能。此外，大多数测试员还倾向于考虑认为与自己类似的用户，倾向于使用非常简单、非常荒谬的输入，而不是具有中等复杂度的现实输入。

以下是一些常见偏向：

同化偏向。更有可能把未来的测试结果解释为总体上证实自己对产品的看法。
证实偏向。更有可能关注确实会证实自己对产品看法的测试结果。
可用性偏向。如果头脑中已经想到一种用户以某种方式操作的场景，则更有可能认为这种操作更常出现。
最初印象偏见。更信任所做的第一次观察。
最新印象偏见。更信任所做的最近一次观察。
框架效应。对错误报告的反应与措辞有很大关系，不管其真正含义如何。
知名偏向。把碰巧认识的用户意见放在更重要的地位。
表达偏向。期望较小的问题也许有较小的原因，而严重问题会有大原因。

测试员不能避免这些偏向，因为这些偏向在很大程度上已经固化在头脑中。测试员能够做的是管理偏向。例如，只需通过研究偏向并在实践中注意，这样在思考时就可以更好地进行补偿。多样化也可以抵御过强偏向。如果测试员集体谈论测试问题，可以将一个测试员的偏向降低到最低限度。

如果遗漏一个问题，检查这种遗漏是意外还是策略的必然结果

如果猜硬币，猜的是正面，出现的却是反面，这是否意味着做出了差的决策？以任何理性的观点看都不是这样。除非在硬币上做了手脚，否则出现任何一面的机会都是50%。出现反面没有什么可奇怪的，只是不够幸运罢了。决策策略没有问题。

在测试过程中没有发现程序错误时也存在同样问题，同样也会困扰客户。在研究测试策略出现了什么问题之前，先不要自责。出现遗漏，是否因为忠实地执行了好的测试策略，并只是碰巧没有发现那个特定的问题？如果是这样，可保持原有方针不变。确实有这种情况。但是，如果遗漏程序错误是因为测试策略关注了错的问题类型，可利用这个机会改进测试策略。

所有测试都视图回答某些问题

所执行的所有测试，都是要回答有关现实的产品和应该得到的产品之间关系的某个问题。有时测试员完全没有意识到自己在回答问题。如果测试员只是在寻找明显的问题可能还好，但是在很多情况下，问题并不会闪烁着“请报告我”的提示自己跳出来。产品的有些错误行为用户可能一眼就会看出，尽管测试员可能没有注意到。在任何测试活动中，都要问自己什么样的问题应该推动自己评估测试策略，否则就会更像是游客，而不是测试员。

困惑是一种测试工具

当测试员感到困惑时，这可能是某种重要的预示。

规格说明不清楚吗？规格说明中的模糊点，常常是为了掩盖有影响力的项目相关人员之间的重要分歧。
产品不清楚吗？产品可能有严重问题。
用户文档不清楚吗？产品的这个部分可能太复杂，有太多的特例和不一致性要描述。
内部问题只是难以理解吗？我们试图自动化的有些系统具有内在的复杂性，或包含复杂的技术问题。程序员也认为它们复杂、困难，并导致自己犯遗漏、误解和过于简化的错误。

测试员对产品、技术和一般测试问题了解得越多，自己的困惑就会成为更有力的指南针，指出重要问题所在。

在测试过程中，如果对产品一无所知，那么至少知道自己在困惑。在这种情况下，困惑可以成为最佳交付内容，即提出也许其他人没有勇气提出的问题。

清新的眼光会发现失效

理解事物，是把新信息吸收到已知信息中，同时修改已知的信息以适应新信息的高智力过程。测试员在理解了产品或功能部件之后，会在头脑中形成映射，并且头脑不再那么努力工作。对于测试员来说这可能是个问题。当非常了解产品后，会对产品做出更多的假设，并更少检查这些假设。

这种情况对于测试至少有三点提示：

第一次接触产品或功能时，要特别注意使自己困惑和烦恼的地方。这可能说明用户也会有类似反应。
当与团队的新成员一起工作时，与他们一起测试。观察他们在了解产品时的反应。
警惕陷入测试惯例。即使没有遵循严格的测试脚本，也可能对特定功能太熟悉，以至于以越来越窄的方式进行测试。在任何可能的地方引入多样性，或改由其他测试员负责。

测试过程的一个重要成果，是更好、更聪明的测试员

我们经常听到反对产生很少或不产生文档的测试的理由，好像测试的唯一价值就是通过测试产生的文档。这种观点忽略了测试的一种意义深远的重要产品：测试员本身。

好的测试员永远都在学习，随着项目的进展，他们不断加深对产品的了解，逐渐从各个方面提高对产品的反应能力和敏感性。了解产品并已经经历过一两次产品发布的有经验的测试员，即使没有任何指示，但与有一套如何测试产品的书面指示的没有经验的测试员相比，他们测试的有效性也要高得多。

软件测试领域内的一些顾问和论文作者看起来相信，只要提供测试过程，测试效果差的测试员就可以变成测试效果好的测试员。在我们看来，这是一种差的实践，这反映出他们对测试和进行有效测试的人的根本误解。

在评估测试过程时，首先要看项目测试员的素质，要看他们怎么思考，以及这种思考怎样对其行为产生影响。只有掌握了这些信息才能评估他们的工作产品。

除非重新发明测试，否则不能精通测试

不要彻底改造轮子。请稍等一下，难道轮子不是历史上被重新发明次数最多的吗？这不是好事情吗？毕竟我们的汽车是装在充气轮胎上，而不是花岗岩圆盘上。轮子如果说不是数以百万计的话，也有数以千计的变种。也许我们可以从中得到启发。在我们看来，重新发明东西至少有两个原因：通过改造使其适应新条件，了解其工作原理。而要掌握它，这两个方面都需要。

我们有的同事忠告测试专业的学生不要重新发明测试，也不要重新发明测试思想。我们不同意这种观点。这就像是学习科学又不想做实验一样。通过其他思想家进行学习是没有错的，我们认为这样学习是很重要的。但是如果这是学习的唯一方式，那永远也不会成为测试技艺的行家。这样的人将是技术员，但不会再进一步了。按照指示做不会掌握任何东西，就像要沿高速路上火星一样。我们提倡要伟大的机械师和伟大的程序员那样地学习测试：把东西分解，琢磨其工作原理，再以新的方式组装到一起。不要把自己限制为只是接受智慧的服务者，而应该使自己成为智慧的创造者。

在学习过程初期，要重新发明不是非常好的测试、想法、手段和文档。这是正常的。要永远使头脑运转，观察其他测试员，研究和不断评估如何筛选自己的思想。如果要善于做到这一点，就必须实践。

我们这样做已经有很多年了，我们仍然在重新发明，仍然在反思老的想法。我们所尊敬的每个同事都是这样走向精通之路的。