ACM通信
Kode恶性
编写测试计划
来源:Maksim M
亲爱的KV,
我们正在为一个项目发布做准备，因为我们是一个小型的初创公司，所有的开发人员都被要求测试其他开发人员的代码。我们用抽签的方式，每个人从帽子中抽一个名字(我们不允许抽自己的名字)。这是一种选择测试人员的奇怪方式，但似乎并不比我在大型公司看到的过程更糟糕。对我来说，问题不是我必须写测试，而是我还必须写测试计划，这是我们的CEO强加给我的要求之一，他也是工程副总裁，也就是我的老板。我从来没有写过一个实际的测试计划，只是测试的集合。当然，我测试我自己的代码，但因为是我写的代码，所以我知道我在测试什么，这一直是一个简单的过程。我是否应该只编写测试，然后将它们列在计划中?不知何故，这似乎不是我老板想要的。
一个没有计划的人
亲爱的无计划的,
啊，一个测试计划，它可以是一个非常有用的文档，也可以是一个巨大的时间消耗和分心。大多数好的测试计划都是从一页文档开始的，因为您必须避免一次测试所有内容。不要只是试图戳戳您认为需要测试的各种东西，您需要有一个关于测试同事的代码的目标和方法的计划。
一个好的测试计划很像我们中的一些人必须为高中科学课写的实验报告。你不会用这个词的假设，但每个测试基本上都是在测试一个。该计划应该从一个大纲开始，这样您就知道自己覆盖了代码的基本内容和主要内容。在假设的地方，你有一个关于你期望代码做什么的声明:“给定输入X，我们期望看到输出y。”当然，仅仅有一个假设是不够的;你必须说明你将如何证明或推翻这个假设。你的测试方法是什么?不要用“运行代码”来回答。
既然您知道您需要做的不仅仅是“运行代码”，那么让我们看看一些更有用的有效测试方法。描述您打算使用的测试输入是一个好的开始。您不需要列出每一个可能的输入，但您应该描述输入可能的范围或形状。对于一个网络系统，您可以描述您将在您的测试中使用的消息类型:“我们将发送64到1500字节之间的数据包，大多数消息的大小是2次方的字节，并且在其有效载荷部分包含随机的位模式。”这是测试输入，但是您还必须描述测试输出。再次，以一个网络系统为例，您可能会说，“正确的测试结果是所有消息都被转发，而没有任何消息被丢弃、丢失或损坏。”
如果您的测试有特殊的设置需求，例如软件或硬件的特殊配置，那么这些也必须包含在计划中，可能在它们自己的标有“配置”的部分中。目前，您是编写计划和测试并可能执行它们的人，但在将来，运行测试的人可能不是您。在编写测试计划时，必须找出您头脑中的所有假设，然后将其记录下来。如果一个测试计划遗漏了一个重要但明显的需求(无论如何，对您来说)，那么下一个尝试使用它的人将会感到非常沮丧。
在测试计划中需要注意的另外两项是您正在使用的框架以及它将在哪里存储结果。与实验室报告不同，您的测试计划不需要包含运行测试的结果，事实上，我希望结果存储在您正在使用的测试框架的某个地方。
如果您可以将您的每个测试看作是一个假设、一个测试方法和一个测试结果的实验，那么它应该都很到位，而不是从裂缝中消失。
KV
相关文章
在queue.acm.org
在活动系统上调试
Kode恶性
https://queue.acm.org/detail.cfm?id=2031677
质量保证:远远超过测试
斯图亚特·费尔德曼
https://queue.acm.org/detail.cfm?id=1046943
清晰地思考绩效
卡里-米尔萨普
https://queue.acm.org/detail.cfm?id=1854041
数字图书馆是由计算机协会出版的。版权所有©2019 ACM, Inc.
没有找到条目