全部，
我是一名开发人员，但想了解更多关于测试过程和方法的信息。我相信这有助于我编写更可靠的代码，因为它改进了我可以在将产品交付给测试团队之前使用我的单元测试进行测试的案例。我最近开始研究软件项目的测试驱动开发和探索性测试方法。
现在我更容易为我编写的代码找到测试用例。但是当我不是被测功能的开发人员时，我很想知道如何发现测试用例。比如说，让我们有一个我们在各种网站上看到的基本用户注册表单。假设测试它的人不是表单的开发人员，应该如何测试表单上的输入字段，你的策略是什么？您将如何发现测试用例？我相信这种测试受益于探索性测试方法，但我可能在这里错了。
我会很感激你对此的看法。
谢谢，字节
虫子！在添加新测试用例的项目中，我最喜欢的起点之一是查看错误跟踪系统。现有的错误本身就是测试用例，但它们也可以引导您走向新的测试用例。如果一个特定的模块有问题，它可以引导你在那个领域开发更多的测试用例。如果某个特定的开发人员似乎引入了某类错误，它可以指导该开发人员对未来项目的测试。
另一个有用的考虑是更多地关注测试技术，而不是测试用例。在您的注册表示例中，您将如何从业务需求的角度对其进行攻击？安全？并发？有效/无效输入？
测试计算机软件是一本关于如何进行各种不同类型测试的好书；黑盒、白盒、测试用例设计、规划、管理测试项目，可能还有很多我错过的。
对于你给出的例子，我会做这样的事情：
从不同的角度确定您的假设：
此外，使用此处提到的任何助记符和测试列表：
问问题。保留问题词列表，并强迫自己提出有关产品或功能的问题。像这样的列表可以帮助您摆脱俗话说的框框或车辙。如果没有任何问题，请不要在疑问词上花费太多时间。
然后，当你回答他们时，问“其他”问题。这迫使你至少暂时不相信你最初的结论。
然后，问“不是”的问题——否定或反驳你的假设，并挑战它们。
问题的其他修饰符可能是：
在表单的情况下，我会看看我可以输入什么并在那里测试各种边界条件，例如如果没有提供用户名会发生什么？我想起了有几种不同形式的测试：
黑盒测试 - 这是您在不查看正在测试的内容的情况下进行测试的地方。这里的挑战是无法看到内部可能会导致限制什么是有用的测试以及有多少不同的测试是值得的。这当然是一些默认测试的样子。
白盒测试 - 在这里您可以查看代码并获得代码覆盖率等指标，以确保您覆盖了代码库的百分比。这通常会更好，因为在这种情况下，您对正在做的事情了解得更多。
与逻辑测试相比，还有一些性能测试在某处也值得注意，例如表单验证我的速度有多快，而不仅仅是表单这样做。
集体头脑风暴会议。（或必要时成对非正式地）
与他人讨论测试想法。当你向别人解释你的想法时，你往往会找到改进或扩展它们的方法。
制作具有在顶部和侧面列出的主要特征的数据表，并考虑每对之间可能的交互。在三个维度上执行此操作可能会变得笨拙。
为不同类型的任务（例如整数验证和工作流程步骤等）保留包含常见问题和问题类型的测试目录。
利用James Bach的探索性测试动态和满足启发式测试策略模型。两者都提供了开始更广泛或不同地思考产品的一般方法，这可以帮助您在测试中在盒子和启发式之间切换。