发现测试用例的方法有哪些
总之，
我是一名开发人员，但想了解更多关于测试流程和方法。我相信这有助于我编写更可靠的代码，因为它改进了我可以在将产品交付给测试团队之前使用单元测试进行测试的案例。我最近开始研究软件项目的测试驱动开发和探索性测试方法。
现在我可以更轻松地找到我编写的代码的测试用例。但我很想知道当我不是被测功能的开发人员时如何发现测试用例。 例如，我们有一个在各种网站上看到的基本用户注册表。假设测试它的人不是表单的开发人员，应该如何测试表单上的输入字段，您的策略是什么？您将如何发现测试用例？我相信这种测试受益于探索性测试方法，但我在这里可能是错的。
我将不胜感激您对此的看法。
谢谢， 字节
All,
I am a developer but like to know more about testing process and methods. I believe this helps me write more solid code as it improves the cases I can test using my unit tests before delivering product to the test team. I have recently started looking at Test Driven Development and Exploratory testing approach to software projects.
Now it's easier for me to find test cases for the code that I have written. But I am curios to know how to discover test cases when I am not the developer for the functionality under test.
Say for e.g. let's have a basic user registration form that we see on various websites. Assuming the person testing it is not the developer of the form, how should one go about testing the input fields on the form, what would be your strategy? How would you discover test cases? I believe this kind of testing benefits from exploratory testing approach, i may be wrong here though.
I would appreciate your views on this.
Thanks,
Byte
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（10）
虫子！在添加新测试用例的项目中，我最喜欢的起始位置之一是查看错误跟踪系统。现有的错误本身就是测试用例，但它们也可以引导您使用新的测试用例。如果某个特定模块有错误，它可能会导致您在该领域开发更多测试用例。如果某个特定的开发人员似乎引入了某类错误，它可以指导该开发人员对未来项目的测试。
另一个有用的考虑因素是更多地关注测试技术而不是测试用例。在您的注册表单示例中，您将如何从业务需求的角度对其进行攻击？安全？并发？输入有效/无效？
Bugs! One of my favorite starting places on a project for adding new test cases is to take a look at the bug tracking system. The existing bugs are test cases in their own right, but they also can steer you towards new test cases. If a particular module is buggy, it can lead you to develop more test cases in that area. If a particular developer seems to introduce a certain class of bugs, it can guide testing of future projects by that developer.
Another useful consideration is to look more at testing techniques, than test cases. In your example of a registration form, how would you attack it from a business requirements perspective? Security? Concurrency? Valid/invalid input?
测试计算机软件是一本关于如何进行各种不同类型的好书测试；黑盒、白盒、测试用例设计、规划、管理测试项目，可能还有很多我错过的东西。
对于您给出的示例，我会执行以下操作：
Testing Computer Software is a good book on how to do all kinds of different types of testing; black box, white box, test case design, planning, managing a testing project, and probably a lot more I missed.
For the example you give, I would do something like this:
提出问题。保留一个疑问词列表，并强迫自己提出有关产品或功能的问题。像这样的列表可以帮助您摆脱众所周知的框框或陈规。如果你什么也没想到，就不要在疑问词上花太多时间。
，当你回答他们时，问“其他”问题。这迫使你至少暂时不相信你的初步结论。
然后，问“不是”的问题——否定或反驳你的假设，并挑战它们。
对问题的其他修饰语可以是：
Ask questions. Keep a list of question words and force yourself to come up with questions about the product or a feature. Lists like this can help you get out of the proverbial box or rut. Don't spend too much time on a question word if nothing comes to you.
Then, when you answer them, ask "else" questions. This forces you to distrust, for a moment at least, your initial conclusions.
Then, ask the "not" questions--negate or refute your assumptions, and challenge them.
Other modifiers to the qustions could be:
就表单而言，我会查看可以输入的内容并测试其中的各种边界条件，例如，如果未提供用户名会发生什么？我想起有几种不同形式的测试：
黑盒测试 - 这是您无需查看正在测试的内容即可进行测试的地方。这里的挑战是无法看到内部可能会导致限制什么是有用的测试以及有多少不同的测试值得的问题。这当然是一些默认测试的样子。
白盒测试 - 在这里您可以查看代码并获得代码覆盖率等指标，以确保您覆盖了一定比例的代码库。这通常会更好，因为在这种情况下，您可以更多地了解正在做什么。
与逻辑测试相比，还有一些性能测试也值得注意，例如表单验证我的速度有多快，而不仅仅是表单执行此操作。
In the case of the form, I'd look at what I can enter into it and test various boundary conditions there,e.g. what happens if no username is supplied? I'm reminded of there being a few different forms of testing:
Black box testing - This is where you test without looking inside what is being tested. The challenge here is not being able to see inside can cause issues with limiting what are useful tests and how many different tests are worthwhile. This is of course what some default testing can look like though.
White box testing - This is where you can look at the code and have metrics like code coverage to ensure that you are covering a percentage of the code base. This is generally better as in this case you know more about what is being done.
There are also performance tests compared to logic tests that are also worth noting somewhere,e.g. how fast does the form validate me rather than just does the form do this.
从不同的角度确定你的假设：
另外，请使用此处注明的任何助记符和测试列表：
Identify your assumptions from different perspectives:
Also, use any of the mnemonics and testing lists noted here:
与他人讨论测试想法。当你向别人解释你的想法时，你往往会找到改进或扩展它们的方法。
Discussing test ideas with others. When you explain your ideas to someone else, you tend to see ways to refine or expand on them.
小组头脑风暴会议。 （或必要时非正式地成对）
Group brainstorming sessions. (or informally in pairs when necessary)
制作数据表，在顶部和侧面列出主要特征，并考虑每对之间可能的相互作用。在三个维度上执行此操作可能会变得笨拙。
Make data tables with major features listed across the top and side, and consider possible interactions between each pair. Doing this in three dimensions can get unwieldy.
保留包含不同类型任务的常见问题和问题类型的测试目录，例如整数验证和工作流程步骤等。
Keep test catalogs with common questions and problem types for different kinds of tasks such as integer validation and workflow steps etc.
利用探索性测试动态和满意度启发式测试策略模型，作者：James Bach。两者都提供了开始更广泛或不同地思考产品的通用方法，这可以帮助您在测试中在盒子和启发式之间切换。
Make use of Exploratory Testing Dynamics and Satisfice Heuristic Test Strategy Model by James Bach. Both offer general ways to start thinking more broadly or differently about the product, which can help you switch between boxes and heuristics in testing.