典型的测试错误有哪些？(13)

　　· By spelling out all inputs, the first style prevents testers from carelessly overusing simple values. For example, a tester might always test accounts with $100, rather than using a variety of small and large balances. (Either style should include explicit tests for boundary and special values.)

　　· 通过写出所有的输入，第一种风格防止程序员无意间过度使用简单的值。例如，一个测试员可能总是用$100测试帐户，而不是使用一些小的和大的余额的组合。(这两种风格都应显式地包含边界值和特殊值测试。)

　　However, there are also some disadvantages:

　　但是，也有一些缺点：

　　· The first style is more expensive to create.

　　· 创建第一种风格的测试成本较高。

　　· The inevitable minor changes to the user interface will break it, so it's more expensive to maintain.

　　· 对用户界面的一些不可避免的更改将中断它，因此维护成本也就更高。

　　· Because each run of the test is exactly the same, there's no chance that a variation in procedure will stumble across a bug.

　　· 因为每一轮测试都完全相同，所以也就没有机会因为过程不同而偶然发现 bug 。

　　· It's hard for testers to follow a procedure exactly. When one makes a mistake - pushes the wrong button, for example - will she really start over?

　　· 测试员难于遵循测试过程。如果一个人出现错误——比如说按错按钮——她需要重新开始吗?

　　On balance, I believe the negatives often outweigh the positives, provided there is a separate testing task to check that all the menu items and toolbar buttons are hooked up. (Not only is a separate task more efficient, it's less error-prone. You're less likely to accidentally omit some buttons.)

　　如果能有一个独立的测试任务来检查所有的菜单项和工具条按钮都连接了代码(一个单独的测试不但更有效，而且不易出错。你不大会偶然地忽略掉一些按钮。)，那么权衡利弊，我相信第一种设计的负面影响超过正面影响。

　　I do not mean to suggest that test cases should not be rigorous, only that they should be no more rigorous than is justified, and that we testers sometimes error on the side of uneconomical detail.

　　我不是认为测试用例不应当严格，只是说它们过分严格，而且我们测试员有时在不经济的细节中犯错误。

　　Detail in the expected results is less problematic than in the test procedure, but too much detail can focus the tester's attention too much on checking against the script he's following. That might encourage another classic mistake: not noticing and exploring "irrelevant" oddities. Good testers are masters at noticing "something funny" and acting on it. Perhaps there's a brief flicker in some toolbar button which, when investigated, reveals a crash. Perhaps an operation takes an oddly long time, which suggests to the attentive tester that increasing the size of an "irrelevant" dataset might cause the program to slow to a crawl. Good testing is a combination of following a script and using it as a jumping-off point for an exploration of the product.

　　详细的预期结果比详细的测试过程问题要少，但是过多的细节可能是测试员的注意力过多集中于检查他所依照的脚本。这可能也导致另一个典型错误：不能注意和探索“不相关的”奇怪现象。好的测试员善于注意到“有趣的东西”并对其进行操作。可能在工具条的一个短暂的闪动，经过调查后，揭示了一个失效错误。也许一个操作任务奇怪地花费了很长时间，可能使专注的程序员感到增加“不相关”的数据集合的大小可能使程序慢如蜗牛。好的测试是既遵循脚本，又能将它作为探索产品的出发点。

　　An important special case of overlooking bugs is checking that the product does what it's supposed to do, but not that it doesn't do what it isn't supposed to do. As an example, suppose you have a program that updates a health care service's database of family records. A test adds a second child to Dawn Marick's record. Almost all testers would check that, after the update, Dawn now has two children. Some testers - those who are clever, experienced, or subject matter experts - would check that Dawn Marick's spouse, Brian Marick, also now has two children. Relatively few testers would check that no one else in the database has had a child added. They would miss a bug where the programmer over-generalized and assumed that all "family information" updates should be applied both to a patient and to all members of her family, giving Paul Marick (aged 2) a child.

原文转自：http://www.uml.org.cn/Test/200709289.asp