Some of the Conclusions Reached by LAWST Participants [10]
附錄
LAWST會議上得到的若干結論
During the last third of each day, we copied several statements made during the discussion onto whiteboards and voted on them. We didn’t attempt to reach consensus. The goal was to gauge the degree to which each statement matched the experience of several experienced testers. In some cases, some of us chose not to vote, either because we lacked the specific experience relevant to this vote, or because we considered the statement ill-framed. (I’ve skipped most of those statements.)
在會議每天日程的后三分之一，我們把在討論中得到的一些論述抄寫到寫字版上并進行投票。我們并非想獲得一致意見。這樣做的目的，是想看看每條論述與這些經驗豐富的測試工程師的經驗符合的程度。在有些情況下，我們中的一些人并沒有投票，可能是因為我們缺乏對要投票的論述的具體經驗，也可能是因為我們認為該論述不夠合理。(這里我已經省略了大多數論述。)
If you’re trying to educate an executive into costs and risks of automation, these vote tallies might be useful data for your discussions.
如果你正試圖把自動化的成本和風險告訴給你的一位經理，那么以下這些投票結果或許是你們討論的有用數據。
General principles
一般原則
1. These statements are not ultimate truths. In automation planning, as in so many other endeavors, you must keep in mind what problem are you trying to solve, and what context are you trying to solve it in. (Consensus)
這些論述并非終極真理。在規劃自動化時，由于投入了這么多的努力，你必須時刻記住哪個問題是你試圖要解決的，以及在何種環境下解決它。(一致同意)
2. GUI test automation is a significant software development effort that requires architecture, standards, and discipline. The general principles that apply to software design and implementation apply to automation design and implementation. (Consensus)
GUI級自動化測試是軟件開發中的一項重大工作。它需要架構、標準和紀律。適用于軟件設計和實現的一般原則同樣適用于自動化設計和實現。(一致同意)
3. For efficiency and maintainability, we need first to develop an automation structure that is invariant across feature changes; we should develop GUI-based automation content only as features stabilize. (Consensus)
為了效率和可維護性，我們需要首先開發一個不隨特性改變的自動化結構。我們應該開發像特性一樣穩定的基于GUI的自動化。(一致同意)
4. Several of us had a sense of patterns of evolution of a company’s automation efforts over time:
我們中的一些人認為一個公司的自動化工作可以采用演化模式來進行。
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.
一旦一個程序通過了測試，那么以后就不太可能不通過該測試了。這種說法導出了一些論述(沒有一個被明確贊成)，即自動化測試有危險，因為它給我們一種很舒服的錯覺，認為程序沒有問題。即使程序今天沒有出現昨天出現的問題，但是依然還有很多情況可以使程序出問題。而如果你總是在沒有bug的地方尋找，你就永遠找不到它們。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
