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

　　主題五：過度使用技術

　　Test automation is based on a simple economic proposition:

　　測試自動化基于一個簡單的經濟觀點：

　　· If a manual test costs $X to run the first time, it will cost just about $X to run each time thereafter, whereas:

　　· 如果第一次手工測試的成本是$X，則其后每次測試的成本大致都是$X，然而：

　　· If an automated test costs $Y to create, it will cost almost nothing to run from then on.

　　· 如果創建自動化測試的成本是$Y，則其后的運行成本幾乎為零。

　　$Y is bigger than $X. I've heard estimates ranging from 3 to 30 times as big, with the most commonly cited number seeming to be 10. Suppose 10 is correct for your application and your automation tools. Then you should automate any test that will be run more than 10 times.

　　$Y比$X大。我了解到的估計范圍是從3至30倍，而常常被引用的數值似乎是10。假設10對于應用程序和自動化工具是正確的。這樣應當將運行10次以上的測試都進行自動化。

　　A classic mistake is to ignore these economics, attempting to automate all tests, even those that won't be run often enough to justify it. What tests clearly justify automation?

　　一個典型錯誤是忽略這些經濟上的考慮，試圖自動化所有的測試，甚至包括那些不常運行的測試以至不能證明自動化是必要的。哪些測試能明顯地證明自動化是必要的?

　　· Stress or load tests may be impossible to implement manually. Would you have a tester execute and check a function 1000 times? Are you going to sit 100 people down at 100 terminals?

　　· 壓力或負載測試可能無法手工實現。你會讓測試員執行并檢查一個函數1000次嗎?你會找100個人坐在100個終端前面嗎?

　　· Nightly builds are becoming increasingly common. (See [McConnell96] or [Cusumano95] for descriptions of the procedure.) If you build the product nightly, you must have an automated "smoke test suite". Smoke tests are those that are run after every build to check for grievous errors.

　　· 夜間構建變得越來越普遍了。(參見[McConnell96]或[Cusumano95]可以了解這個過程的描述)。如果在夜間構建產品，就必須有一個自動化的“冒煙測試套件”。 冒煙測試指的是那些在每次構建之后都去檢查嚴重錯誤的測試。

　　· Configuration tests may be run on dozens of configurations.

　　· 配置測試可能要在數十種配置上運行。

　　The other kinds of tests are less clear-cut. Think hard about whether you'd rather have automated tests that are run often or ten times as many manual tests, each run once. Beware of irrational, emotional reasons for automating, such as testers who find programming automated tests more fun, a perception that automated tests will lead to higher status (everything else is "monkey testing"), or a fear of not rerunning a test that would have found a bug (thus leading you to automate it, leaving you without enough time to write a test that would have found a different bug).

　　其他種類的測試不是這個明顯。仔細想一下，對于那些多次運行或者運行次數是手工運行次數10倍的自動化測試，你是否只運行一次。要當心實現自動化的不理性的、感情的原因，例如測試員發現程序自動化測試更有趣，認為自動化測試將帶來更高的地位(其他測試都是“猴子測試”)，或者是害怕不能重新運行一個會發現 bug 的測試(這導致你將它自動化，使你沒有足夠的時間編寫一個會發現其他 bug 的測試)。

　　You will likely end up in a compromise position, where you have:

　　你可能在最后有一個折中的方式，你將有：

　　1. a set of automated tests that are run often.

　　一套經常運行的自動化測試。

　　2. a well-documented set of manual tests. Subsets of these can be rerun as necessary. For example, when a critical area of the system has been extensively changed, you might rerun its manual tests. You might run different samples of this suite after each major build.

　　一套文檔齊備的手工測試。這些測試的子集合可以在需要的時候重新運行。例如，當一個系統的關鍵領域被大規模地改變時，可能會重新運行手工測試。在每一次主要構建之后，都可能會運行這個套件的不同樣例。

　　3. a set of undocumented tests that were run once (including exploratory "bug bash" tests).

　　一套沒有文檔的、只運行一次的測試(包括探索性的“bug 大清除”測試)。

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