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

　　Some believe that programmers can't test their own code. On the face of it, this is false: programmers test their code all the time, and they do find bugs. Just not enough of them, which is why we need independent testers.

　　有些人相信程序員不能測試他們自己的代碼。這顯然不對：程序員一直都在測試他們的代碼，而且他們也的確能夠發現 bug 。只是發現的 bug 還不夠多，這也是為什么我們需要獨立的測試員。

　　But if independent testers are testing, and programmers are testing (and inspecting), isn't there a potential duplication of effort? And isn't that wasteful? I think the answer is yes. Ideally, programmers would concentrate on the types of bugs they can find adequately well, and independent testers would concentrate on the rest.

　　但是如果獨立測試員也在測試，程序員也在測試(并且也在走查代碼)，其中不存在潛在的重復工作嗎?這不是一種浪費嗎?我想答案是肯定的。理想情況中，程序員應當集中于他們能夠充分發現的 bug 類型，而獨立測試員應集中于其他部分。

　　The bugs programmers can find well are those where their code does not do what they intended. For example, a reasonably trained, reasonably motivated programmer can do a perfectly fine job finding boundary conditions and checking whether each known equivalence class is handled. What programmers do poorly is discovering overlooked special cases (especially error cases), bugs due to the interaction of their code with other people's code (including system-wide properties like deadlocks and performance problems), and usability problems.

　　程序員能夠較好地發現的 bug 是那些與他們預期不符的代碼。例如，一個接受過一定培訓、有一定積極性的程序員可以很好地找到邊界條件，并且檢查每一個等價類是否都處理了。程序員做的不好的地方是不能發現被忽略的某些情況(尤其是錯誤情況)，不能發現由于他們的代碼與其他人的代碼交互作用而產生的 bug ，以及易用性問題。

　　Crudely put, good programmers do functional testing, and testers should do everything else. Recall that I earlier claimed an over-concentration on functional testing is a classic mistake. Decent programmer testing magnifies the damage it does.

　　大致來說，好的程序員進行功能測試，測試員應該完成其他所有工作?；貞浺幌挛仪懊嬖f過，過分集中于功能測試是一個典型錯誤。合格的程序員測試夸大了它產生的破壞。

　　Of course, decent programmer testing is relatively rare, because programmers are neither trained nor motivated to test. This is changing, gradually, as companies realize it's cheaper to have bugs found and fixed quickly by one person, instead of more slowly by two. Until then, testers must do both the testing that programmers can do and the testing only testers can do, but must take care not to let functional testing squeeze out the rest.

　　當然，合格的程序員測試相對較少，因為程序員既沒有接受過培訓，對測試也沒有熱情。但是隨著各個公司意識到由一個人發現并修復 bug 成本較低，這種情況也在逐步改變。在此之前，測試員不但必須完成程序員可以完成的測試，還要完成只有測試員才能完成的工作，還必須小心不要讓功能測試擠占了其他測試。

　　主題四：工作中的測試員

　　When testing, you must decide how to exercise the program, then do it. The doing is ever so much more interesting than the deciding. A tester's itch to start breaking the program is as strong as a programmer's itch to start writing code - and it has the same effect: design work is skimped, and quality suffers. Paying more attention to running tests than to designing them is a classic mistake. A tester who is not systematic, who does not spend time laying out the possibilities in advance, will overlook special cases. They may be the same subtle ones that the programmers overlooked.

　　在測試的時候，必須決定如何執行程序，然后完成它們。完成它們比決定它們要有趣的多。測試員渴望的是開始破壞程序，程序員渴望的是開始寫代碼——這導致相同結果：設計工作被忽略了，產品質量受到損害。將更多的注意力集中于運行測試而不是設計它們是一個典型錯誤。

　　Concentration on execution also results in unreviewed test designs. Just like programmers, testers can benefit from a second pair of eyes. Reviews of test designs needn't be as elaborate as product design reviews, but a short check of the testing approach and the resulting tests can find significant omissions at low cost.

　　集中于執行測試也導致未經審核的測試設計。就像程序員一樣，測試員也得益于第二雙眼睛的檢查。測試設計的審核不必像產品審核那樣嚴格，但是對測試方法和結果測試的快速檢查可以低成本地找到重要的疏忽。

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