自動化測試最佳實踐：來自全球的經典自動化測試案例解析.jpg

第0章 案例研究反思

2017-01-13
對這些問題沒有簡單而通用的答案，但存在一些公共的要素。我們認為最重要的兩個要素是管理問題和測試件架構：
注: 這兩個問題需要重點關注，但是又有些寬泛，需后續章節細分析。 但是除此之外還有其它冷門的問題也需關注

0.1.1 自動化測試目標

2017-02-15
自動化測試目標
注: 并非測試的目標，后續學習如何制定出有效的自動化測試目標

0.1.3 ROI和度量標準

2017-02-15
第9章有一個用來評判投資的基于模型測試的ROI計算器的范例。
注: 分析自動化測試案例的ROI，分析案例是否適合做自動化

0.1.5 技能

2017-02-15
自動化測試人員的角色可以看做測試人員和工具之間的橋梁（參見0.2.1節）。
注: 測試架構師：設計自動化測試的整體結構，或將現有框架進行改進以適應新的需求
測試工程師：設計、編寫、維護自動化測試的軟件、腳本、數據、期望結果以及額外的實用工具

0.1.8 促進項目改變并啟動自動化測試的觸發器

2017-02-15
試點項目（pilot project）是個好主意，在將自動化測試擴展到更廣的范圍之前先在小范圍內嘗試不同的方法，來判斷哪種方法最好。
注: 常用技巧，小范圍試點驗證

0.1.9 工具和培訓

2017-02-15
擁有好的工具不能保證在測試自動化中取得成功——必須對整個測試框架進行良好地計劃、定制和維護，工具僅僅是一小部分。
注: 工具沒有標準的，尋找適合自己項目的，其實就是能夠實現自動化需求的就行。
重點還是管理和計劃

0.2.1 抽象、抽象、再抽象：測試件架構

2017-02-15
技術因素
注: 使用的工具，語言要接地氣，要標準化，要能生成報告，編寫的案例要避免過度依賴工具，失敗分析要明確

1.2 整個團隊的承諾

2017-02-15
敏捷開發團隊中的每個人都進行手動測試，所以他們更能體會到自動化測試的好處。

1.3.1 一個可測試的架構

2017-02-15
解決問題的最直接途徑未必是最佳途徑。

1.3.3 獲取測試的基準：GUI冒煙測試

2017-02-15
我們首先追求的是“快贏”，針對系統中每個用戶角色的基本功能實現自動測試。
2017-02-15
首先，CI構建過程只運行了少量單元測試和一些覆蓋系統高得分點的GUI冒煙測試。隨著在這兩個級別引入更多測試，我們將GUI測試移到單獨的構建過程中并只在晚上運行，這樣，我們可以更快得到的反饋信息。

1.11 總結

2017-02-16
總結
注: 核心團隊成員穩定，不斷嘗試新工具，測試和開發互相學習；在使用新工具上一定先做培訓，試點時小范圍實施，有好的反饋后，大面積推廣使用； 該敏捷項目案例支持單元測試覆蓋率，GUI功能覆蓋率，歷時1年過度完成全部回歸測試案例的自動化測試案例編寫。

2.1 本案例研究的背景

2017-02-16
不要嘗試對設計很差的測試實施自動化，先完善測試，再進行自動化。

2.3 自動化測試的目標

2017-02-16
剛開始不要設定太多目標，最初先重點完成某些目標，再逐步添加新的目標。

2.6 管理自動化測試

2017-02-16
我們的測試過程在持續改進，并且我們為測試設計了一個可記錄的生命周期，如圖2-2所示。

2.10 如何使用自動化測試書中的建議

2017-02-16
所有的測試人員參加國際軟件測試認證委員會（International Software Testiing QualificationsBoard, ISTQB）的基礎認證課程，這樣有助于術語的統一使用和理解，從而有助于增進測試人員間的交流。

第3章 移動到云端：TiP的演化——在線的持續回歸測試

2017-02-17
移動到云端：TiP的演化——在線的持續回歸測試
注: 通過在云端實施自動化測試，從而將基于產品的自動化測試變更為基于服務的自動化測
在線測試：Testing in Production, TiP

3.3 如何實施TiP

2017-02-17
不要僅僅通過一種途徑來實施自動化，盡可能使用多種有用的方法。不同方法之間可以互補并且往往比單獨使用一個方法更有效。

3.6.5 易犯的錯誤

2017-02-17
易犯的錯誤
注: 1 自動化提示的錯誤可能是個臨時性的錯誤，如網絡斷開，解決方案提供重試的機制
2 假的“安全感”比如看起來都沒問題其實是分支覆蓋不全，要階段性的做探索性的測試。從整體看結果。 多出現在橫向擴展產品的時候

5.4.1 試著用原先的方法來使用新工具

2017-02-17
測試工具與UI構建環境的交互能力是最重要的。

6.3.4 第一個月：了解任務和工具

2017-02-19
分享對工具和策略的理解。
■了解工具，這樣就可以根據任務來使用工具。較為完整的文檔有助于從文檔中找到每項任務的標準實踐和最佳實踐是什么。
2017-02-19
我們按照自己使用工具的方式，為QC和QTP編寫了一個快速指南。同時還一直維護著關于最佳實踐及項目中所使用標準的日志，每當有一個新的好方法的時候就補充進去。

6.3.6 敏捷測試方法

2017-02-19
通過頻繁地報告自動化進展來獲得利益相關者持續的興趣和支持。

6.3.7 第一階段的結果

2017-02-19
管理層的支持；
■清晰的目標；
■同樣的知識水平；
■對工具的了解；
■在GUI上的實際應用知識；
■對任務的處理策略；
注: 初期達到的目標清單，值得借鑒
2017-02-19
■可用方法，包括描述最佳實踐；
■一個符合實際的計劃；
■一個符合實際的時間安排表。

6.4.3 統一解決方案

2017-02-19
描述最佳實踐以及整個項目階段應遵循標準的文檔。如果我們選擇不采用最佳實踐，我們必須要有充分的理由，并將其寫進最佳實踐文檔里面，這樣我們就能知道哪些地方有差異
注: 定義標準，但是在必要的時候也要允許例外情況。

6.4.4 應用程序結構和QC中的測試用例結構

2017-02-19
組件和測試用例的命名標準是采用面向業務的方法，這樣就比較方便找到相應的用例并進行整體的維護。
■測試用例由公共組件和特定組件構成，這就保證了對于同一功能不會出現冗余的組件。
注: 自動化測試組件的劃分標準及理念：測試件架構采用標準的方法具有易用性，并有助于長期的維護。

6.4.7 實際產品發布版本中使用的第一個自動化測試

2017-02-19
開發人員必須在變更管理系統中對GUI中的功能和變更進行詳細的記錄和描述，這樣自動化測試團隊就知道應該對哪些部分進行維護。

6.5 總結

2017-02-19
總結
注: 1 要掌握對工具的學習使用，制作快速指南及培訓
2 最佳實踐跟蹤記錄并做分享
3 業務組件劃分為公共組件和特定組件
4 小步快跑，小范圍試點，要梳理好自動化功能清單
5 制定GUI開發規范，讓開發人員主動反饋修改內容
6 自動生成測試報告(讓領導看到成果)
2017-02-19
5個成功的準則
注: ■公司人員必須知曉任務和責任，并達成一致意見。
■進行一個試點項目并定義明確的目標。
■確保整個項目成員對項目有共同的了解和認識，記錄最佳實踐和標準。
■了解整個業務應用，以確保測試用例的結構和規模是合適的。
■“使它盡量保持簡單”

第10章 10年過去了，項目還在進行

2017-02-20
測試文檔化
注: 可以長時間使用

10.2.8 我們遇到的其他問題

2017-02-20
維護是很重要的，需要盡早進行良好的設計使得維護工作量最小化。
注: 項目實踐需要考慮

10.4.1 將測試人員和自動化人員分離開來

2017-02-20
自動化不能帶來好的測試。僅僅對那些有價值的測試進行自動

10.4.2 管理層的期望

2017-02-20
需要很好地理解質量管理、測試策略過程、系統規格說明、測試計劃、待測系統和測試自動化工具集的相對成熟度。
注: 成熟度

10.4.3 從特定的工具和工具提供商中獨立出來

2017-02-20
對自動化進行良好的設計，以便能夠在需要時轉向使用不同的工具——保持工具獨立性。

11.5.1 關注知識分享

2017-02-21
關注知識分享，對自動化框架中測試運行的結果進行跟蹤，設計時考慮速度和易用性。
注: 實現鳳凰重生的幾點內容

11.5.3 設計時考慮速度和易用性

2017-02-21
可以運行可變數量的測試
注: 項目中可以研究testng通過網頁選擇執行的測試案例

12.2.2 健康檢查和“吸煙者”

2017-02-22
冒煙測試是開始使用自動化的一個好地方，因為它們經常被運行，比較乏味，并且手動測試容易出錯。
注: 項目中實現健康檢查，最好每天都有這個健康檢查的報告呈現，也可單獨執行

12.2.3 面臨的挑戰和汲取的經驗教訓

2017-02-22
高價值的測試環境健康檢查和“吸煙者”的套件已經開發出來，并且仍在使用。
2017-02-22
設定的目標為：減少人工勞動力成本，提高產品質量，增加測試的靈活性，使手動測試資源能夠自由變化（具有較高的bug發現率），由于需要較少的臨時測試人員而降低了網絡資源的緊張程度。

12.3.5 銷售自動化

2017-02-22
將自動化的好處傳遞到高級管理層是必不可少的。比較自動化和手動測試是有效的
注: 整理自動化測試對比手動測試的分析，主要是自動化的開發驗證時間，手動測試的人工驗證時間，不能單從一個版本看，最好有累計的信息

12.5.1 概念：腳本開發與業務知識相結合

2017-02-22
自動化服務（包括腳本開發、維護、執行、報告，以及工具的內部結構）。
注: 定義清楚崗位職責很重要

15.2.4 代碼審查

2017-02-23
對于自動化測試代碼、腳本和文檔進行審查和復審是非常有效的。
注: 讓相近領域的同事提前審查代碼，評審會上再談論

15.2.6 “Checkman for eCATT”工具

2017-02-23
在你的自動化測試套件中謹防“無用”測試用例。
注: 【重要】通過靜態檢查或案例代碼執行覆蓋率檢查“無用”的案例腳本

16.4.2 編碼規約和文檔化

2017-02-23
TwinText工具為我們的框架產生一個完整的HTML幫助文件，它可以作為一個參考文檔被任何使用該框架的人使用。
注: 框架說明文檔

17.3.1 已有的測試工具以及改變的原因

2017-02-23
unit，自動化單元測試
注: 谷歌內部工具TAU（test automation

17.4.6 提交隊列該為我們做什么

2017-02-23
提供給開發人員立即反饋的測試用例對于他們來說是最有用的
注: 自動化后期需考慮

17.6.2 一般的自動化測試：我們汲取的經驗教訓

2017-02-23
建立穩定、可維護的測試用例還是非常困難的
注: 所有的基于瀏覽器的自動化測試工具都有的問題

18.2 自動化測試框架

2017-02-24
自動化測試框架
注: 看架構圖

18.4 抽象層

2017-02-24
挑選最優的抽象層厚度和它的技術。
注: 面向對象的理念進行抽象，定義抽象的厚度?！局匾靠紤]電商商品錄入的抽象

18.5 配置

2017-02-24
自動地檢測一個測試的前置條件，如果它們不滿足，就不執行該測試。
注: 除了健康體檢，單個案例還需要有前置條件檢查

18.6 成本和投資回報率

2017-02-24
自動化測試的節約成本
注: 產出物
2017-02-24
每個測試套件映射了一個功能域（一系列的需

19.3 自動化測試用來支持手動探索式測試

2017-02-25
一次性的腳本可以有實際的短期收益。
注: 自動化測試實現多用戶并發操作一個業務的實現，考慮公共構建

19.6 通過組合簡單的工具模擬現實世界的負載

2017-02-25
使用一種工具的組合能夠做到一些單個工具很難或者不可能辦到的事情。

20.8 結果報告

2017-02-25
測試結果的分層報告能夠節省很多失效分析時間。我們只報告一些測試目標所需要的信息。

21.4.2 缺點

2017-02-25
自動化測試不僅僅是執行測試——記錄缺陷日志、調試和狀態報告同樣需要支持。

21.5.2 框架中目前還不可用的特性

2017-02-25
特性
注: 見文中下圖。收集整理好

24.3 測試猴子

2017-02-25
為了真正利用自動化的力量，要跳出自動化回歸測試的框框。
注: 猴子測試，隨機測試

27.2.3 對QA授權

2017-02-27
清晰的和可測量的目標是自動化的最好起點。

29.6 探索性測試自動化：數據庫記錄鎖定

2017-03-01
好的自動化的候選方案是那些難以手動實現的測試以及那些對手動測試來說過于復雜的測試

29.8.4 學到的經驗教訓

2017-03-01
對外部的依賴進行封裝
注: 作為設計的原則

29.13.2 最終成功的關鍵：自動化過程

2017-03-01
自動化過程
注: 示意圖
分析和設計：理解客戶的需求，并確認是否可能在我們當前的技術條件下滿足每項需求。
■編寫腳本和配置：通過自動化的解決方案來實現客戶需求。這可能包含重新編碼、編碼和創建一些特定的實用工具。
參數定義：在系統中使用用戶定義的場景對腳本進行評估，目的在于找出那些需要參數化的元素。
■參數管理：在定制的電子表格中管理大量的數據。
■場景收集：根據系統利益相關人員提供的測試場景來生成電子表格。
■確認：檢查電子表格和參數，在電子表格中創建標準去決定測試通過或是失敗，并且允許自動化腳本確認已執行測試的結果。
對腳本進行測試：保證測試以期望的方式運行，移除腳本中的任何bug。
■腳本執行：使用已定義的場景和參數運行腳本。
■對結果的評審：在內部對腳本執行的結果進行評審，包括哪些測試通過或者失敗，以及任何常見的問題，如環境不可用等。
■對結果進行交流：對結果進行總結，并發送給經理、開發人員、利益相關人員和其他相關人員。