有哪些方法可以发现测试用例

Question

所有

我是开发人员，但想了解有关测试过程和方法的更多信息。我相信这有助于我编写更加可靠的代码，因为它改进了我可以在将产品交付给测试团队之前使用我的单元测试进行测试的情况。我最近开始研究软件项目的测试驱动开发和探索性测试方法。

现在我更容易找到我编写的代码的测试用例。但是，当我不是测试功能的开发人员时，我很高兴知道如何发现测试用例。 比如说让我们有一个基本的用户注册表单，我们在各种网站上看到。假设测试它的人不是表单的开发人员，那么应该如何测试表单上的输入字段，您的策略是什么？你会如何发现测试用例？我相信这种测试可以从探索性测试方法中获益，但我可能在这里错了。

我很感激你对此的看法。

谢谢， 字节

Answer 1

错误！在我添加新测试用例的项目中，我最喜欢的起点之一是查看错误跟踪系统。现有的错误本身就是测试用例，但它们也可以引导您进入新的测试用例。如果某个特定模块有问题，它可能会导致您在该区域开发更多测试用例。如果某个特定开发人员似乎引入了某类错误，它可以指导该开发人员对未来项目的测试。

另一个有用的考虑因素是比测试用例更多地关注测试技术。在您的注册表单示例中，您将如何从业务需求角度对其进行攻击？安全？并发？有效/无效输入？

Answer 2

Testing Computer Software是一本关于如何进行各种不同类型测试的好书;黑盒子，白盒子，测试用例设计，计划，管理测试项目，可能还有很多我错过了。

对于你给出的例子，我会做这样的事情：

1. 对于每个字段，我会考虑您可以输入的有效值，包括有效值和无效值。我会寻找边界案件;如果一个字段是数字，如果我输入一个小于下限的值会发生什么？如果我输入下限作为值会发生什么？等
2. 然后我会使用像Microsoft Pairwise Independent Combinatorial Testing (PICT) Tool这样的工具生成尽可能少的测试场景，以便在所有输入字段的情况下生成。
3. 我还会编写一个自动化测试，使用随机输入在表格上捣乱，捕获结果并查看响应是否有意义（键盘上的虚拟猴子）。

Answer 3

从不同角度确定您的假设：

• 用户怎么可能误解这个？
• 为什么我认为它的行为或应该采取这种行动？
• 我对这个软件应该如何运作有什么偏见？
• 我如何知道需求/设计/实施是否需要？
• 此软件的优先级，重要性，目标等可能存在哪些其他观点（用户，管理员，经理，开发人员，法律人员）？
• 是否正在构建正确的软件？
• 我真的知道有效的姓名/电话号码/身份证号码/地址/等是什么样的吗？
• 我缺少什么？
• 我怎么会误解（在这里插入名词）？

此外，请使用此处提到的任何助记符和测试列表：

• http://www.qualityperspectives.ca/resources_mnemonics.html

Answer 4

提问。保留问题单词列表并强迫自己提出有关产品或功能的问题。这样的列表可以帮助你摆脱众所周知的盒子或车辙。如果没有任何问题，请不要在问题词上花太多时间。

• 谁
• 谁的
• 什么
• 其中
• 当
• 为什么
• 如何
• 多少

然后，当你回答它们时，问“别的”问题。这迫使你至少暂时不信任你的初步结论。

• 还有谁
• 其他人
• 等。

然后，问“不”问题 - 否定或驳斥你的假设，并挑战他们。

• 谁不（例如，谁可能不需要访问此安全功能，为什么？）
• 什么不是（用户不关心什么数据？用户不会在这个文本框中放什么？你确定吗？）
• 等...

qustions的其他修饰符可能是：

• W else
• W不
• W risk
• W不同
• 结合两个问题词，例如，Who和when。

Answer 5

在表格的情况下，我会看看我可以进入它并测试那里的各种边界条件，例如。如果没有提供用户名会怎么样？我想起了一些不同形式的测试：

1. 黑盒测试 - 这是您在不查看测试内容的情况下进行测试的地方。这里的挑战是无法看到内部可能导致限制什么是有用的测试以及有多少不同的测试是值得的问题。这当然是一些默认测试的样子。

2. 白盒测试 - 您可以在此处查看代码并获取代码覆盖率等指标，以确保覆盖一定比例的代码库。这通常更好，因为在这种情况下，您更了解正在做什么。

还有一些性能测试与逻辑测试相比，这些测试也值得注意，例如。表单验证我的速度有多快，而不仅仅是表单执行此操作。

Answer 6

小组头脑风暴会议。 （或在必要时非正式成对）

• 请参阅这些brainstorming techniques

Answer 7

与他人讨论测试想法。当您向其他人解释您的想法时，您倾向于看到改进或扩展它们的方法。

Answer 8

制作具有列在顶部和侧面的主要功能的数据表，并考虑每对之间可能的交互。在三个维度上执行此操作可能会变得难以处理。

Answer 9

为不同类型的任务保留测试目录以及常见问题和问题类型，例如整数验证和工作流程步骤等。

Answer 10

利用James Bach的Exploratory Testing Dynamics和Satisfice Heuristic Test Strategy Model。两者都提供了开始更广泛或不同地思考产品的一般方法，这可以帮助您在测试中切换盒子和启发式方法。