典型的測試錯誤有哪些？(14)

　　一個重要的忽略 bug的特例情況是檢查產品完成預期操作，但不檢查它是否沒有完成不應該完成的操作。舉個例子，假設你有一個更新醫療機構的家庭記錄數據庫的程序。一個測試是在Dawn Marick的記錄中添加第二個小孩。幾乎所有的測試員都將在更新之后檢查Dawn Marick現在有兩個小孩了。部分測試員——那些聰明的、有經驗的專家——將會檢查Dawn Marick的配偶——Brian Marick，現在也有兩個小孩了。相對較少的測試員將檢查數據庫中沒有其他人添加了小孩。如果程序員將規則過分擴展，認為應當對所有的既是病人又是她的家庭成員的人都更新 “家庭信息”，給了Paul Marick(2歲)一個小孩，則這個 bug 就被忽略了。

　　Ideally, every test should check that all data that should be modified has been modified and that all other data has been unchanged. With forethought, that can be built into automated tests. Complete checking may be impractical for manual tests, but occasional quick scans for data that might be corrupted can be valuable.

　　理想情況中，每個測試都應檢查需要修改的數據都被修改了，其他數據都沒有。在經過仔細考慮后，可以將這個過程構建到自動化測試中。完全檢查可能對于手工測試來說不切合實際的，但是偶爾地快速檢查數據是否破壞可能是很有價值的。

　　Testing should not be isolated work

　　測試不應當是孤立的工作

　　Here's another version of the test we've been discussing:

　　這里是我們討論過的另一個版本：

　　Design 3

　　設計3

　　Withdraw all with confirmation and normal check for 0.

　　取出所有錢，需要確認，并檢查余額為0。

　　That means the same thing as Design 2 - but only to the original author. Test suites that are understandable only by their owners are ubiquitous. They cause many problems when their owners leave the company; sometimes many month's worth of work has to be thrown out.

　　除了最初的作者，這與設計2是相同的。測試套件只有它們的作者才能理解是常見情況。當它們的擁有者離開公司后，會帶來許多問題;有時候很多個月的工作就白費了。

　　I should note that designs as detailed as Designs 1 or 2 often suffer a similar problem. Although they can be run by anyone, not everyone can update them when the product's interface changes. Because the tests do not list their purposes explicitly, updates can easily make them test a little less than they used to. (Consider, for example, a suite of tests in the Design 1 style: how hard will it be to make sure that all the user interface controls are touched in the revised tests? Will the tester even know that's a goal of the suite?) Over time, this leads to what I call "test suite decay," in which a suite full of tests runs but no longer tests much of anything at all.

　　我需要說明的是像設計1和2那樣詳細的設計也存在同樣的問題。雖然他們可能由任何人運行，但不是每個人都能在產品界面變化后更新它們。因為測試不會顯式地列出它們的目的，更新它們可能很容易使得比以前測試的少一點點。(例如，考慮一下，設計1風格中的測試套件：要確保所有用戶界面控件在更改后的測試中被涉及是一件多么困難的事情?)長期以來，這導致了我稱為“測試套件變質”的問題，完整的測試套件仍舊在運行，但什么也測試不了。

　　Another classic mistake involves the boundary between the tester and programmer. Some products are mostly user interface; everything they do is visible on the screen. Other products are mostly internals; the user interface is a "thin pipe" that shows little of what happens inside. The problem is that testing has to use that thin pipe to discover failures. What if complicated internal processing produces only a "yes or no" answer? Any given test case could trigger many internal faults that, through sheer bad luck, don't produce the wrong answer.

　　另一個典型錯誤是測試員與程序員的邊界。某些產品主要是用戶界面;他們做的所有操作在屏幕上都是可見的。其他產品主要是內部的;用戶界面是一個“細管道”，很少顯示內部發生什么。問題是測試必須使用那個細管道來發現錯誤。如果一個復雜的內部處理產生的只是“是或否”的答案，結果會怎么樣呢?任何給定的測試用例都能觸發很多內部錯誤，僅僅通過不壞的運氣，才不會產生錯誤的答案。

　　In such situations, testers sometimes rely solely on programmer ("unit") testing. In cases where that's not enough, testing only through the user-visible interface is a mistake. It is far better to get the programmers to add "testability hooks" or "testpoints" that reveal selected internal state. In essence, they convert a product like this:

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