我們中的一些人認為一個公司的自動化工作可以采用演化模式來進行。
First generalization (7 yes, 1 no): In the absence of previous automation experience, most automation efforts evolve through:
第一代(7票贊成，1票反對)：在缺乏以前的自動化經驗時，大多數自動化工作將經歷以下三個過程：
a. Failure in capture /playback. It doesn’t matter whether we’re capturing bits or widgets (object oriented capture/replay);
截取/回放失敗。我們截取的是比特還是窗口部件都無關緊要(面向對象的截取/重放)
b. Failure in using individually programmed test cases. (Individuals code test cases on their own, without following common standards and without building shared libraries.)
使用個人編程的測試用例失敗。(個人編碼的測試用例是按他自己的標準編寫的，沒有遵循一般標準以及構建共享庫)
c. Development of libraries that are maintained on an ongoing basis. The libraries might contain scripted test cases or data-driven tests.
開發維護在正在進行的基礎之上的函數庫。這個庫可以包括腳本測試用例或數據驅動測試。
Second generalization (10 yes, 1 no): Common automation initiatives failures are due to:
第二代(10票贊成，1票反對)：一般自動化的主動失敗源于以下幾點：
a. Using capture/playback as the principle means of creating test cases;
把截取/回放作為創建測試用例的原則性方法。
b. Using individually scripted tested cases (i.e. test cases that individuals code on their own, without following common standards and without building shared libraries);
使用個人編寫腳本測試用例 (個人編碼的測試用例是按他自己的標準編寫的，沒有遵循一般標準以及構建共享庫)
c. Using poorly designed frameworks. This is a common problem.
使用設計不好的框架。這是一個普遍問題。
5. Straight replay of test cases yields a low percentage of defects. (Consensus)
測試用例的直接重放會帶來低缺陷(一致同意)
Once the program passes a test, it is unlikely to fail that test again in the future. This led to several statements (none cleanly voted on) that automated testing can be dangerous because it can gives us a falsely warm and fuzzy feeling that the program is not broken. Even if the program isn’t broken today in the ways that it wasn’t broken yesterday, there are probably many ways in which the program is broken. But you won’t find them if you keep looking where the bugs aren’t.
文章來源于領測軟件測試網 http://www.kjueaiud.com/
