Testing 发现测试用例的各种方法有哪些

全部,

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

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

我希望你能就此发表意见

谢谢， Byte

是一本关于如何进行各种不同类型测试的好书；黑盒、白盒、测试用例设计、规划、管理测试项目，可能还有很多我错过的东西

对于您给出的示例，我会这样做：

对于每个字段，我会考虑您可以输入的可能值，包括有效值和无效值。我会寻找边界情况；如果字段是数字字段，如果输入的值小于下限值1，会发生什么情况？如果输入下限作为值，会发生什么？等等

然后，我将使用类似Microsoft的工具为所有输入字段生成尽可能少的测试场景

我还将编写一个自动测试，使用随机输入敲打表单，捕获结果并查看响应是否有意义（虚拟猴子在键盘上）

---

虫子！在添加新测试用例的项目中，我最喜欢的开始位置之一是查看bug跟踪系统。现有的bug本身就是测试用例，但它们也可以引导您使用新的测试用例。如果某个特定模块有缺陷，它会导致您在该领域开发更多的测试用例。如果某个特定的开发人员似乎引入了某种类型的bug，那么它可以指导该开发人员对未来项目的测试

---

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

集体头脑风暴会议。（必要时，非正式地两人一组）

• 看到这些了吗

---

与他人讨论测试想法。当你向其他人解释你的想法时，你往往会看到改进或扩展想法的方法。

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

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

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

---

使具有主要特征的数据表跨越顶部和侧面，并考虑每一对之间可能的交互。在三个维度中执行此操作可能会变得笨拙。

为不同类型的任务（如整数验证和工作流步骤等）保留包含常见问题和问题类型的测试目录。

提问。保留一张疑问词列表，强迫自己提出有关产品或功能的问题。像这样的列表可以帮助你摆脱俗套。如果你什么都没想到，不要在一个疑问词上花费太多时间

• 谁
• 谁的
• 什么
• 在哪里
• 什么时候
• 为什么
• 怎么
• 多少钱

然后，当你回答他们时，问“其他”问题。这迫使你不相信，至少在一瞬间，你最初的结论

• 还有谁
• 还有谁
• 等等

然后，提出“不是”的问题——否定或反驳你的假设，并挑战它们

• 谁不需要（例如，谁可能不需要访问此安全功能，为什么？）
• 什么不是（用户不关心哪些数据？用户不在此文本框中输入哪些数据？您确定吗？）
• 等等

问题的其他修改器可以是：

• W其他
• W不是
• W风险
• W不同
• 组合两个疑问词，如“谁”和“何时”

---

对于表单，我将查看可以输入的内容，并在其中测试各种边界条件，例如，如果没有提供用户名，会发生什么？我想起了有几种不同形式的测试：

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

白盒测试——在这里，您可以查看代码，并获得代码覆盖率等指标，以确保覆盖了一定比例的代码库。这通常更好，因为在本例中，您对正在进行的操作了解更多

与逻辑测试相比，还有一些性能测试也值得注意，例如表单验证速度有多快