典型的測試錯誤有哪些？(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.

　　詳細的預期結果比詳細的測試過程問題要少，但是過多的細節可能是測試員的注意力過多集中于檢查他所依照的腳本。這可能也導致另一個典型錯誤：不能注意和探索“不相關的”奇怪現象。好的測試員善于注意到“有趣的東西”并對其進行操作?？赡茉诠ぞ邨l的一個短暫的閃動，經過調查后，揭示了一個失效錯誤。也許一個操作任務奇怪地花費了很長時間，可能使專注的程序員感到增加“不相關”的數據集合的大小可能使程序慢如蝸牛。好的測試是既遵循腳本，又能將它作為探索產品的出發點。

　　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