原链接

http://www.satisfice.com/articles/how_much.shtml

翻译内容

Testing as Storytelling(测试像讲故事)

by James Bach

This first appeared on www.StickyMinds.com as a column feature

这篇文章首次作为专栏文章出现在www.StickyMinds.com上

A classic question asked about test strategy is "How much testing is enough?" If you're doing testing strictly from pre-scripted procedures, the answer may seem obvious: You've done enough testing when you've performed all the test procedures. But that answer is not worthy of a thoughtful tester. A thoughtful tester needs a way to answer the question that addresses the mission of testing, not merely its tactics. All the test procedures that currently exist might not be enough to satisfy the mission…or they may be more than needed.

关于测试策略的一个经典问题是“测试多少就足够了？” 如果您正在严格按照预先编写的程序进行测试，答案可能显而易见：当您已经执行了所有测试程序时，您已经完成了足够的测试。但这个答案不是一个有思想的测试人员的答案。一个有思想的测试人员需要一种方法来回答解决测试任务的问题，而不仅仅是其策略。目前存在的所有测试程序可能不足以满足这个任务......或者它们可能超出需要。

Our mission is not to run a certain set of tests. For most of us, our mission is to learn enough important information about the product so that our clients (developers and managers, mainly) can make informed decisions about it.

我们的任务不是运行一系列测试。对于我们大多数人来说，我们的使命是学习有关产品的足够多的重要信息，以便我们的客户（主要是开发人员和管理人员）能够做出明智的决策。

Testing as Storytelling(测试像讲故事)

When you test, you are doing something much like composing an investigative news story. It's a story about what you know about the product, why you think you know it, and what implications that knowledge has for the project. Everything you do in testing either comprises the story or helps you discover the story. You've done enough testing when you can tell a compelling story about your product that addresses the things that matter to your clients. Since your compelling story amounts to a prediction about how the product will be valued by its users, another way of saying this is that your testing is finished when you believe you can make a test report that will hold true over time—so try to write a classic.

当你进行测试时，你正在做的事情与撰写调查性新闻报道非常类似。这是一个故事，它是关于您对产品的了解，您认为自己知道它的原因以及知识对项目的影响。您在测试中所做的一切要么组成了这个故事或帮助您发现这个故事。当您能够讲述有关您的产品的引人入胜的故事时，您已经做了足够的测试，这个产品解决了对您的客户至关重要的事情。由于您的引人入胜的故事相当于用户评价产品的一种预测，另一种说法是，当您认为可以制作随时间变化的测试报告时，您的测试就完成了 - 所以尝试写经典的测试报告吧。

For instance, I recently tested the install process of a complex product. My mission was to assess and catalog all the changes that this product made to systems on which it is installed. So my first step was to analyze the install process. Then I diagrammed it, chose test cases corresponding to important parts of that process, and found ways to perform those test cases under controlled and repeatable conditions. I came to a conclusion about this product that flowed logically from the tests, and then I checked the conclusion to be sure that each aspect of it was indeed corroborated and supported by the tests I performed. I needed this to be a good, compelling story, so I tried to anticipate how it could be criticized by “the reader.” Where is my story weak? How might my story turn out to be false? I ran additional tests to rule out other sources of system change. I ran tests multiple times to improve my confidence that the results I was seeing were related to the processes and variables I was controlling, and not coincidental events.

例如，我最近测试了复杂产品的安装过程。我的任务是评估和编目该产品对安装它的系统所做的所有更改。所以我的第一步是分析安装过程。然后我绘制了图表，选择了与该过程的重要部分相对应的测试用例，并找到了在受控和可重复条件下执行这些测试用例的方法。从测试的执行中，我得出了关于这个产品的结论，然后我检查了结论，以确保它的每个方面都得到了我所执行的测试的确认和支持。我需要这个结论是一个好的，令人信服的故事，所以我试着预测它如何被“用户”批评。我的故事的弱点在哪里？我的故事什么情况下会变成假的？我运行了额外的测试来排除系统变化的其他来源。我多次运行测试以提高我的信心，即我看到的结果与我控制的过程和变量有关，而不是巧合事件。

When I exhausted the concerns of my internal critic (and external critics I asked to review my work), I decided it was good enough.

当我对内部批评（以及我要求审查我的工作的外部批评）的担忧感觉“筋疲力尽”时，我觉得它已经足够好了。

A Short Story Can Be Just as Complete as a Novel短篇小说可以像小说一样完整

Testing is potentially an infinite process. If complete testing means you have to run all possible tests, you will never finish. But you can say you're done when you have a testing story with all the major plot points, and you can make the case that additional tests will not significantly change your story. Here's the thing: Although you never know for sure if you have reached that point of diminishing returns, you don't need to know for sure! All that's required, all that anyone can expect of you, is that you have a compelling story for why a thoughtful and responsible tester like you might come to the judgment that you know enough about the product under test. In some situations, that will be months of testing; in other situations, only hours.

测试可能是一个无限的过程。如果完整测试意味着您必须运行所有可能的测试，那么您永远不会完成。但是当你有一个包含所有主要情节点的测试故事时，你可以说你已经完成了，你可以证明额外的测试不会显着改变你的故事。事情就是这样：虽然你永远不知道你是否达到了收益递减的程度，但你无需确切地知道！所有人期待的和需要的，就是你有一个令人信服的故事，即一个像你这样有思想和负责任的测试人员，为什么会判断你对被测产品已经有了足够的了解。在某些情况下，这将是几个月的测试; 在其他情况下，只需要几个小时。

Plot Points for a Testing Story绘制测试故事的点

A complete testing story answers the questions: What was tested (coverage)? In what ways was it tested (techniques)? If problems occurred, how were they detected (evaluation)?

一个完整的测试故事回答了这些问题：测试的内容（覆盖范围）？它以何种方式进行测试（技术）？如果出现问题，他们是如何被检测到的（评估）？

Whether my test strategy is sturdily scripted, or flowingly exploratory, the plot for my test reports has the same basic structure. It goes like this: Tester meets product. Tester learns product. Product wanders and changes; tester follows it. Tester is worried that product might fail. Tester checks product for possibility of anticipated failures using risk-oriented tests. Tester checks product for unanticipated failures using diversified and coverage-oriented tests. Tester has questions and notices problems and issues. Then, one day, the product settles down, no questions remain, issues are resolved, all known risks have been examined, and all important aspects of the product have been examined. Known problems are either fixed or accepted. Tester has a reasonably clear idea how users will react to the product. Tester lives happily ever after (and so, hopefully, does the product).

无论我的测试策略是固定的脚本，还是流行的探索测试，我的测试报告的图都应该具有相同的基本结构。它是这样的：测试人员满足产品。测试人员学习产品。产品迭代和变化; 测试者跟着它。测试员担心产品可能会失败。测试人员使用风险导向测试检查产品是否存在预期故障的可能性。测试人员使用多样化和面向覆盖的测试来检查产品是否存在意外故障。测试人员有疑问并注意到问题和要点。然后，有一天，产品稳定下来，没有问题了，问题得到解决，所有已知风险都已经过检查，产品的所有重要方面都已经过检查。已知问题被修复了或被接受了。 测试人员对用户如何使用产品有了一个相当清晰的认识。测试者从此过上幸福的生活（希望产品也是如此）。

Writing a good testing story takes skill and 当心. You'll get it wrong, sometimes. Don't worry too much about being wrong. The main thing is that your story is thoughtful and well researched. Oh, and if you can make it a taut thriller, that won't hurt.

编写一个好的测试故事需要技巧和关怀。你有时会弄错。不要过分担心错误。最重要的是你的故事很全面，研究得很好。哦，如果你能把它变成一个“紧张的惊悚片”，那就不会受到伤害。

How Much Is Enough?(测试多少就足够了)相关推荐

1. 训练集、开发集、测试集（Train/Dev/Test sets）
1.在以往的机器学习中如上图所示,以往机器学习中,对训练集.开发集.测试集的划分比例为60/20/20,如此划分通常可以获得较好的效果. 训练集(training set):训练算法. 开发集(de ...
您不是专业测试人员的10个理由！
为什么测试人员在某些组织中没有得到专业治疗. 你是专业测试员吗? 如果您在空闲时间阅读与质量保证相关的文章以提高您的测试技能,那么您将成为确定为专业测试人员的小型(并且希望增长)工程师. 在镜子里寻找 ...
测试框架如何测试私有方法_高效的企业测试–测试框架（5/6）
测试框架如何测试私有方法本系列文章的这一部分将介绍测试框架以及我在何时以及是否应用它们方面的想法和经验. 关于测试框架的想法我对大多数测试框架不太满意的原因是,按照我的观点,它们大多增加了语法上 ...
高效的企业测试–测试框架（5/6）
本系列文章的这一部分将介绍测试框架以及我在何时以及是否应用它们方面的想法和经验. 关于测试框架的思考我对大多数测试框架不太满意的原因是,按照我的观点,它们大多增加了一些语法上的便利性和便利性,但本质 ...
junit编写测试代码_编写数据访问代码测试-不测试框架
junit编写测试代码当我们向数据访问代码编写测试时,是否应该测试其公共API的每种方法? 一开始听起来很自然. 毕竟,如果我们不测试所有内容,那么如何知道我们的代码可以按预期工作? 这个问题为我们 ...
为数据访问代码编写测试–不测试框架
当我们向数据访问代码编写测试时,是否应该测试其公共API的每种方法? 一开始听起来很自然. 毕竟,如果我们不对所有内容进行测试,那么如何知道我们的代码可以按预期工作呢? 这个问题为我们提供了重要的线索 ...
敏捷自动化测试（1）—— 我们的测试为什么不够敏捷？
测试是为了保证软件的质量,敏捷测试关键是保证可以持续.及时的对软件质量情况进行全面的反馈.由于在敏捷开发过程中每个迭代都会增加功能.修复缺陷或重构代码,所以在完成当前迭代新增特性测试工作的同时,还要通 ...
测试之道--阿里巴巴八年测试专家倾情奉献
摘要: 我从事测试工作将近八年了,从起初的不懂测试,怀疑测试,到相信测试,再到坚定测试,其中经历的辛酸.煎熬无法言表.在从事测试工作的这八年里,有人质疑,也有人追捧,唇枪舌剑,没完没了,貌似测试永远都 ...
[转载]每日构造与冒烟测试
[--- 资料是从免费网站上获取的,上载在这里,只为交流学习目的,文章原作者保留所有权力, 如本博客的内容侵犯了你的权益,请与以下地址联系,本人获知后,马上删除.同时本人深表歉意,并致以崇高的谢意! ...

How Much Is Enough?(测试多少就足够了)

原链接

翻译内容

Testing as Storytelling(测试像讲故事)

Testing as Storytelling(测试像讲故事)

A Short Story Can Be Just as Complete as a Novel短篇小说可以像小说一样完整

Plot Points for a Testing Story绘制测试故事的点

How Much Is Enough?(测试多少就足够了)相关推荐

最新文章

热门文章