测试代码的测试用例......什么范围？
因此，我最近被一家打印机公司聘用为质量保证/固件开发人员，我的很多工作涉及编写小型小部件/测试应用程序以放置在打印机本身上进行测试，以确保一切正常运行。 在您将其转移到职业交换和程序员等之前...我实际上在这里谈论源代码...
但是，由于我刚刚大学毕业并获得计算机科学学士学位，所以我对专业领域相当陌生...尤其是 QA。
无论如何，我很难掌握一个真正好的“方法”来给出良好的测试用例结果。
就像让我们说你从键盘输入数字（0-9）......所以为了测试你会测试可接受的范围（如1-100），但然后我问自己我应该在该范围内测试多少（保持记住其中一些是不可能自动化的，因为我们必须偶尔手动按下它们）
然后您显然会测试超出范围（但多少次？）
，例如输入不属于的 ASCII 字符，如 * $ % 或字符。 我对如何为有界/无界案例提供一个好的测试用例感到有点困惑？
有什么想法吗？
So I have been recently hired on as a QA/Firmware Developer for a Printer Company, and alot of my work involves writing Small widgets/test apps to place on the printers themselves to test to make sure everything functions correctly.
Before you move this to careerexchance and programmers etc....im actually talking about the source code here...
However since I just graduated college with my B.S. in CS Im pretty new to the professional world...and QA especially.
Anyways im having a hard time grasping a really good "method" for giving a good test case result.
Like lets say Your Inputting Numbers from a keypad (0-9).....So to test you'd test the accepted range (like 1-100) but then I ask myself how many should I test in that range (keep in mind some of these are impossible to automate since we have to hand press them occasionally)
Then you would test outside range obviously (but how many times?)
And for instance Inputting ASCII characters that dont belong like * $ %, or characters.
Im a bit confused at how to go about giving a good test case for bounded/unbounded cases?
Any ideas?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果它有帮助，那么您现在遇到了一个真正困难的问题 - 任何告诉您从几乎无限的数量中选择正确的测试用例很容易或微不足道的人要么是无知，要么是试图向您出售一个非常昂贵的工具！
正如另一个答案所建议的那样，将您的输入分组为族（也称为等价分区）可能会有所帮助。我建议阅读有关测试设计的内容 - 我喜欢 Lee Copeland 的书“A Practitioner's Guide to Software Test Design”，但您可能还会发现 Tobbe Ryber 的“Essential Test Design”一书很有用 - 可以在此处免费下载 pdf 版本：< a href="http://www.ryber.se/?p=213" rel="nofollow noreferrer">http://www.ryber.se/?p=213 - 查看章节10 开始。
Glowcoder 关于查看错误报告寻找线索以及查看代码以获得进一步想法的建议都非常值得跟进。还要注意可能存在“隐形”边界的可能性 - 即您不知道的限制，仅通过查看代码或要求并不明显 - 例如低于某个值的数字就可以正常工作，并且然后在某个明显完全任意的值下，它们会突然开始失败。看一下这个例子：
最奇怪的语言功能（是的，我在野外遇到过这个功能）。
这就是为什么值得撒上奇怪的高值的一个很好的理由，尽可能地改变你的测试数据（在合理范围内）——你增加了遇到你无法预测的事情的机会。 （这也是反对一遍又一遍地运行完全相同的测试用例的一个重要论点 - 如果它们是自动化的，那么成本会更低并且它们充当变更指示器。但是如果您必须手动键入值 - 您可能会也可以将它们稍微切换一下并每次覆盖更多的搜索空间）。
这是有关边界测试的视频，以及一些有关更多资源的指示：
http://www.testingreflections.com/node/view/4292
If it helps, you're now hitting a genuinely difficult problem - anyone who tells you it's easy or trivial to pick the right test cases out of an almost infinite number is either ignorant, or trying to sell you a very expensive tool!
Grouping your input into families (aka equivalence partitions) as another answer suggests can be helpful. I'd suggest reading up on test design - I like Lee Copeland's book "A Practitioner's Guide to Software Test Design", but you might also find Tobbe Ryber's "Essential Test Design" book useful - it's available as a free pdf download here: http://www.ryber.se/?p=213 - take a look at chapter 10 to start with.
Glowcoder's suggestions for looking at bug reports for clues, and looking at the code for further ideas are both very worth following up. Also be aware of the possibility that there may be "invisible" boundaries - i.e. limits that you aren't aware of that aren't obvious just from looking at the code or requirements - for instance numbers below a certain value work just fine, and then at some apparently totally arbitrary value they'll suddenly start to fail. Take a look at this for an example:
Strangest language feature (and yes, I have met that one in the wild).
This is one good reason why it's worth sprinkling in the odd high value, varying your test data as much as possible (within reason) - you increase your chances of coming across something you just would not have predicted. (This is also a big argument against running exactly the same test cases over and over - if they're automated, then the cost is lower and they act as change indicators. But if you're having to key in values manually - you might as well switch them up a bit and cover a bit more of the search space each time).
Here's a video on boundary testing, and some pointers to further resources:
http://www.testingreflections.com/node/view/4292
寻找输入族。
负数、非负数、0、非正数、正数、0 位、1 位、2 位、3 位...
这些是输入系列的示例。
在代码中查找可能导致您将某些内容分解为新的测试用例系列的内容。
查找类似但不同操作的错误报告 - 它们可能会为您提供如何闯入系列的线索。
Look for input-families.
negative, non-negative, 0, non-positive, positive, 0 digit, 1 digit, 2 digit, 3 digit...
These are examples of input-families.
Look for things in the code that would cause you to break something into a new family of test cases.
Look for bug reports for similar but different operations - they might give you clues how to break into families.
我建议您浏览 Google 测试博客，了解有关测试策略的信息。 James Whittaker 还写了几本关于测试的书。我自己还没有读过这些书，但我确实希望有一天能读到。
另外，与您工作的其他开发人员、测试人员和 QA 人员交谈。询问他们过去的战争故事，他们发现、修复或听说过的最喜欢的错误。许多错误都属于常见类别，学习识别和预测这些错误很大程度上取决于经验。
I would recommend browsing the Google Testing Blog for information on testing strategies. James Whittaker has also written a couple of books on testing. I haven't read the books myself, but I do hope to at some point.
Also, talk to other developers, testers, and QA people where you work. Ask them for their old war stories, favorite bugs they found, fixed, or heard about. A lot of bugs fall into common categories and learning to recognize and anticipate those errors is largely a matter of experience.