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

第0章 案例研究反思

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

0.1.1 自動化測試目標(biāo)

2017-02-15
自動化測試目標(biāo)
注: 并非測試的目標(biāo)，后續(xù)學(xué)習(xí)如何制定出有效的自動化測試目標(biāo)

0.1.3 ROI和度量標(biāo)準(zhǔn)

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

0.1.5 技能

2017-02-15
自動化測試人員的角色可以看做測試人員和工具之間的橋梁（參見0.2.1節(jié)）。
注: 測試架構(gòu)師：設(shè)計自動化測試的整體結(jié)構(gòu)，或?qū)F(xiàn)有框架進行改進以適應(yīng)新的需求
測試工程師：設(shè)計、編寫、維護自動化測試的軟件、腳本、數(shù)據(jù)、期望結(jié)果以及額外的實用工具

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

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

0.1.9 工具和培訓(xùn)

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

0.2.1 抽象、抽象、再抽象：測試件架構(gòu)

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

1.2 整個團隊的承諾

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

1.3.1 一個可測試的架構(gòu)

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

1.3.3 獲取測試的基準(zhǔn)：GUI冒煙測試

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

1.11 總結(jié)

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

2.1 本案例研究的背景

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

2.3 自動化測試的目標(biāo)

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

2.6 管理自動化測試

2017-02-16
我們的測試過程在持續(xù)改進，并且我們?yōu)闇y試設(shè)計了一個可記錄的生命周期，如圖2-2所示。

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

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

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

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

3.3 如何實施TiP

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

3.6.5 易犯的錯誤

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

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

2017-02-17
測試工具與UI構(gòu)建環(huán)境的交互能力是最重要的。

6.3.4 第一個月：了解任務(wù)和工具

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

6.3.6 敏捷測試方法

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

6.3.7 第一階段的結(jié)果

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

6.4.3 統(tǒng)一解決方案

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

6.4.4 應(yīng)用程序結(jié)構(gòu)和QC中的測試用例結(jié)構(gòu)

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

6.4.7 實際產(chǎn)品發(fā)布版本中使用的第一個自動化測試

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

6.5 總結(jié)

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

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

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

10.2.8 我們遇到的其他問題

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

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

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

10.4.2 管理層的期望

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

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

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

11.5.1 關(guān)注知識分享

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

11.5.3 設(shè)計時考慮速度和易用性

2017-02-21
可以運行可變數(shù)量的測試
注: 項目中可以研究testng通過網(wǎng)頁選擇執(zhí)行的測試案例

12.2.2 健康檢查和“吸煙者”

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

12.2.3 面臨的挑戰(zhàn)和汲取的經(jīng)驗教訓(xùn)

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

12.3.5 銷售自動化

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

12.5.1 概念：腳本開發(fā)與業(yè)務(wù)知識相結(jié)合

2017-02-22
自動化服務(wù)（包括腳本開發(fā)、維護、執(zhí)行、報告，以及工具的內(nèi)部結(jié)構(gòu)）。
注: 定義清楚崗位職責(zé)很重要

15.2.4 代碼審查

2017-02-23
對于自動化測試代碼、腳本和文檔進行審查和復(fù)審是非常有效的。
注: 讓相近領(lǐng)域的同事提前審查代碼，評審會上再談?wù)?/p>

15.2.6 “Checkman for eCATT”工具

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

16.4.2 編碼規(guī)約和文檔化

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

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

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

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

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

17.6.2 一般的自動化測試：我們汲取的經(jīng)驗教訓(xùn)

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

18.2 自動化測試框架

2017-02-24
自動化測試框架
注: 看架構(gòu)圖

18.4 抽象層

2017-02-24
挑選最優(yōu)的抽象層厚度和它的技術(shù)。
注: 面向?qū)ο蟮睦砟钸M行抽象，定義抽象的厚度。【重要】考慮電商商品錄入的抽象

18.5 配置

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

18.6 成本和投資回報率

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

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

2017-02-25
一次性的腳本可以有實際的短期收益。
注: 自動化測試實現(xiàn)多用戶并發(fā)操作一個業(yè)務(wù)的實現(xiàn)，考慮公共構(gòu)建

19.6 通過組合簡單的工具模擬現(xiàn)實世界的負載

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

20.8 結(jié)果報告

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

21.4.2 缺點

2017-02-25
自動化測試不僅僅是執(zhí)行測試——記錄缺陷日志、調(diào)試和狀態(tài)報告同樣需要支持。

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

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

24.3 測試猴子

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

27.2.3 對QA授權(quán)

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

29.6 探索性測試自動化：數(shù)據(jù)庫記錄鎖定

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

29.8.4 學(xué)到的經(jīng)驗教訓(xùn)

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

29.13.2 最終成功的關(guān)鍵：自動化過程

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