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

　　在這樣的情況中，有時候測試員單獨依賴于程序員(“單元”) 測試。在這不夠充足的情況下，僅從用戶可見的界面測試是一個錯誤。如果使程序員加上“可測試性鉤子”或“測試點”以揭示所選擇的內部狀態的話，會好得多。本質上，他們將一個產品：

　　to one like this:

　　轉化為：

　　It is often difficult to convince programmers to add test support code to the product. (Actual quote: "I don't want to clutter up my code with testing crud.") Persevere, start modestly, and take advantage of these facts:

　　說服程序員向產品中添加測試支持代碼常常是很困難的(一個真實引語：“我不想讓測試代碼弄亂我的程序。”)堅持下去，適時開始，并利用以下事實：

　　1. The test support code is often a simple extension of the debugging support code programmers write anyway.

　　測試支持代碼常常只是程序員隨便編寫的調試支持程序的簡單延伸。

　　2. A small amount of test support code often goes a long way.

　　少量的測試支持代碼常常就會帶來很大幫助。

　　A common objection to this approach is that the test support code must be compiled out of the final product (to avoid slowing it down). If so, tests that use the testing interface "aren't testing what we ship". It is true that some of the tests won't run on the final version, so you may miss bugs. But, without testability code, you'll miss bugs that don't reveal themselves through the user interface. It's a risk tradeoff, and I believe that adding test support code usually wins. See [Marick95], chapter 13, for more details.

　　對這種方法的普遍的反對意見是測試支持代碼必須編譯在最終產品之外(以避免顯示)。如果是這樣的，測試員使用的測試界面“不是我們交付的產品”。誠然，某些測試不會運行在最終版本中，所以可能會漏掉一些 bug 。但是，沒有可測試的代碼，你會漏掉一些通過用戶界面無法揭示的 bug 。這是一個風險的權衡，我相信添加測試代碼通常會占上風。參見[Marick95]的第13章以獲取更多詳細內容。

　　In one case, there's an alternative to having the programmer add code to the product: have a tool do it. Commercial tools like Purify, Boundschecker, and Sentinel automatically add code that checks for certain classes of failures (such as memory leaks). They provide a narrow, specialized testing interface. For marketing reasons, these tools are sold as programmer debugging tools, but they're equally test support tools, and I'm amazed that testing groups don't use them as a matter of course.

　　有一種情況是，有一個方案替代程序遠向產品添加代碼：用工具來完成。一些商用工具如Purify、Boundschecker和Sentinel可以自動添加代碼以檢查某種類型的錯誤(比如內存泄露)。它們提供一個狹小的、專用的測試界面。因為市場營銷的原因，這些工具是作為程序員調試工具出售的，但它們等同于測試支持工具，測試小組沒有把它們當成常規工具來使用，讓我覺得很吃驚。

　　Testability problems are exacerbated in distributed systems like conventional client/server systems, multi-tiered client/server systems, Java applets that provide smart front-ends to web sites, and so forth. Too often, tests of such systems amount to shallow tests of the user interface component because that's the only component that the tester can easily control.

　　測試問題在分布式系統中，比如傳統的客戶/服務器系統、多層的客戶/服務器系統、向站點提供靈巧的前端應用的Java小程序等，可測試性問題更為嚴重。常常地，測試這類系統等同于用戶界面部件的淺顯測試，因為它們是測試員能夠容易控制的唯一部件。

　　Finding failures is only the start

　　發現錯誤僅僅是開始

　　It's not enough to find a failure; you must also report it. Unfortunately, poor bug reporting is a classic mistake. Tester bug reports suffer from five major problems:

　　發現錯誤是不夠的，還必須報告它。不幸的是，低劣的 bug 報告是一個典型錯誤。測試員的錯誤報告存在五個主要問題：

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