捕捉回放傷害了功能測試自動化
總結
作為功能測試自動化過程中的輔助手段——捕捉回放，被當做功能測試的主要方法，導致我們認為，自動化測試工作就是簡單的通過捕捉回放，實現高效重複人為操作，沒有留意功能測試自動化的實現，需要我們對人工測試方法重新的審視和改變，而不是隻是簡單的重複而已。（感覺上，即便是隻在各類具體的實現層面，捕捉回放的幫助，也只涉及到30%左右的工作量。）功能測試自動化的實現，需要我們從以下角度，重新思考人工測試的工作：
l 測試邏輯和測試資料的分離和整理，實現資料驅動相同的測試邏輯模組。簡單說就是，在大的人工測試工作中，發現不能重複，反覆做的的小單元。
l 測試行為模式化，提取和抽象實現底層技術模組化。簡單說就是將手工測試中，某些反覆點選的操作序列指令碼化，輔助手工測試
l 軟體質量要求適當的資料覆蓋，而不是停留在人為資料抽樣。實現高質量的軟體產品，測試行為就必然出現不同操作資料下，相同操作的序列的重複，需要自動化技術來實現。
l 業務行為模組化，模型化，可實現基於機器自我學習的業務流程自動編排各類測試邏輯，包括自動生成異常行為邏輯，提高功能測試覆蓋率，高效發現缺陷，提高產品質量。
思考停止於“沒有重複就無需自動化”，使我們流失了一些本可提高工作效率，提高產品質量的機會。在本文，我們主要探討在各類組織中，自動化功能測試面臨的問題和改進的可能。
捕捉回放傷害了軟體功能測試自動化！
想到這個標題，難免有點標題黨的味道，即使我們自己。
因為作為功能測試領域的後來者，之前的十幾年中，捕捉回放功能，都是當我們尋求什麼是功能測試這一問題的答案時，必然會聽到的名詞。久而久之，我們自然也把捕捉回放作為軟體功能測試自動化工作主要的方式來看待。捕捉就是為了可以記錄測試人員的手工測試工作，以通過回放提高在日後重複時的效率。
這樣，引出了一個測試領域似乎放之四海而皆準“真理”。
“重複的工作，是測試自動化最有價值的地方。”
沒有重複就無需自動化?
“真理”的壞處，是他阻止了我們繼續思考！經驗告訴我們，止步於“真理”，也會使我們失去新知。
“沒有重複就無需自動化”！
當我們將功能測試理解為捕捉回放；進而認為只有重複性的工作，才有捕捉回放的價值；更進一步，只有整個測試工作需要反覆做，才需要自動化功能測試。這成為我們現在大量手工測試一直延續，而無法變革的強大阻礙和支柱。這使我們很多單位和人員，痛並快樂的埋頭工作著。即便是我們，也生活在這個“幸福圈”中。近年來開始做功能測試技術工作時。發現這個“真理”在功能測試，黑盒測試領域，比白盒測試領域更具影響力。幾乎黑盒測試領域的每一個客戶都會和我說：
“我們不像其他單位，我們的功能測試，系統測試，驗收測試工作，沒有重複性，自動化測試幫不到我們。xx單位需要，但我們不需要。”
和大家透露一個祕密：“常有客戶都這麼說！”
或許職業帶來生存動力，再包裹上專業上謀求真相的好奇心，促使我們來探求，自動化功能測試方法和價值到底是什麼？
首先，讓我們回顧“沒有重複就無需自動化”這句話的本源，它本來是體現了軟體測試的經濟性問題的結果之一。
自動化測試的經濟性
沒有絕對正確的測試方案，就像沒有不存在缺陷的產品一樣。具體選擇的測試方法，是在投入和產出之間的一種平衡。“沒有重複就無需自動化”這句話的實質，同樣是來源於一個投入產出比的考量。而這種考量得到的，本不是這一簡單化的結論。
也就是，我們可以把自動化技術的採用，迴歸到對其所帶來的收益和所支付的費用之間的權衡這一個關鍵的決策點上來考量。
自然是一種權衡，我們就可以本質投入和產出的比較，更廣泛的考慮各種自動化工作可能的投入和收益，以及相關的影響因素，使我們的工作從重複開始而不必止步，逐步探討重複範圍和定義，重複投入和產出的關係。影響這個投入產出的其他因素。這些因素和組織的工作性質，工作方式，承擔責任相關。所以，我們按照不同的組織，來描述我們看到的可能性。
不同組織中的自動化功能測試
迭代化開發團隊中
這些單位，往往是大家認為的xx單位。
實施迭代開發做產品的單位，似乎是大家公認，應該使用自動化功能測試的單位。但事實上，這類單位的各級測試人員，也會有不同的看法，考慮自動化功能測試的開展。
１. 編碼階段應關注白盒測試，而不是系統測試，影響了功能測試自動化的使用。
迭代化開發組織中，我們本可有機會重新審視這個可能性。白盒測試是重要的，但當我們在流程上實施Agile和DevOps變革，成為一個更加重視使用者體驗，擁抱需求變更，以使用者需求為導向的組織時，我們更應該及早的關注使用者面對的最終產品的功能介面的測試。
２. 基於介面的功能測試在編碼階段由於沒有介面原型，影響了功能測試自動化的使用。
迭代開發，導致系統介面更早的被髮布；設計團隊可以提供快速原型，不但可以服務於使用者需求溝通，而且可以作為功能測試開發的起點，實現系統測試和開發並行，測試驅動開發；著力於測試用例中測試邏輯和測試資料的分離，保證了測試邏輯的重用性。
３. 功能測試的技術限制帶來的測試可用性問題，影響了功能測試自動化的使用。
新的測試技術，保證了測試可以實現和應用開發技術無關，和軟體的技術架構無關，和裝置的應用架構無關。系統測試自動化工作無需等待被測應用的開發，可以簡單的基於可能的介面元素開展系統測試自動化的開發。
４. 功能測試的技術限制帶來的測試維護問題，影響了功能測試自動化的使用。
相關專案顯示，在新的基於介面影象的功能測試自動化技術支撐下，功能測試自動化開發工作中，控制介面互動的工作量，最多佔用了整個測試自動化準備工作30%精力和時間；而且，編寫的測試邏輯可以在不同裝置上的相同應用測試中複用。
５. 功能測試的易用性涉及到測試成本和可維護性，影響了功能測試自動化的使用。
當我們在測試開發中，說到某個測試點無法實現時，更準確的內涵，實際是實現的代價高昂。現在的測試組織，往往具備軟體開發背景良好的測試開發人員，對他們來說，熟悉開發技術並擅長指令碼開發，使我們反而有時會忽略測試工具自身易用性的價值。實際上，工作中，我們往往需要面對的不是能不能做到的問題，而是值不值得做的問題，對於熟練的測試開發人員，一樣需要易用的測試開發手段，降低測試開發成本，實現更大範圍的自動化測試。
第三方評測中心中
這些單位，由於作為獨立的第三方評測中心，主要的工作職責是對即將釋出的應用，代表甲方提供專業的產品質量評估。所以，他們最經常做的工作就是功能測試。但是也正是他們的獨特位置和職責，以及現有的工作方式，會影響自動化功能測試的開展。
１. 測試軟體通常通過率較高，反覆迴歸測試的可能性小。
建立測試指令碼庫，對於有升級等反覆測試的專案，形成可複用的資產，也是未來新版本釋出時再次獲得測試在成本，技術和時間方面的優勢。
２. 不同單位待測系統業務不同，指令碼可重用的可能性不大。
測試行為模式化，提取和抽象不同應用中，類似的測試操作，實現底層技術模組化。簡單說就是將手工測試中，某些反覆點選的操作系列指令碼化，輔助手工測試，提高測試效率，降低測試成本。
３. 測試邏輯和測試資料的分離和整理，實現資料驅動相同的測試邏輯模組。
簡單說就是發現可以複用的小的重複的工作單元。著力於被測系統中業務需重複操作業務邏輯的抽取和模組化，建立基於業務關鍵字的“半自動化”的測試流程，提高測試效率，降低測試成本。
４. 軟體質量要求適當的資料覆蓋，而不是停留在人為資料抽樣。
實現高質量的軟體產品，需要設計合理的資料覆蓋，而不是僅僅有人工任意抽取一兩組資料即可完成測試。將設計好的測試資料放置在檔案或資料庫中，通過模組化的測試邏輯讀取這些資料來源，高效的完成自動化測試，提高功能測試覆蓋率，提高產品質量。高質量的測試不可能沒有重複，小顆粒度的功能模組。業務邏輯級別的的重複，需要自動化來實現。
５. 軟體測試不但要測試軟體應有的功能，還應該測試可能的異常操作。
軟體驗收測試，除了完成按照軟體功能要求下的測試之外，還應考慮操作邏輯異常時被測系統的應對能力。軟體測試邏輯自動化，指令碼化，模組化後，可以利用人工智慧，機器學習的演算法，對可能的各類其他業務流程自動編排，快速提高功能測試覆蓋率，儘可能多的發現缺陷，減少排程、時序、資料組合等型別指令碼的編寫量。
第三方驗收測試工作，經常在軟體開發結束即將釋出時才介入，面對的測試物件業務上紛繁複雜，留給組織的測試時間是有限的，應用的業務學習時間也是有限的。上訴的自動化測試設計技術，可以幫助第三方軟體評測中心單位時間內，提高產品質量。當然，結合細緻的前期準備，重新梳理日程的測試工作，組織上的配合，實現會更加順暢。
６. 對被測軟體沒有介面的快速原型和功能需求，沒有時間開發自動化測試。
像開發單位一樣，有這些需求文件，可以幫助第三方軟體評測中心實現測試和開發並行，這是提高測試效率，提高產品質量的重要手段。應在組織和溝通上設法改善，是自動化測試更能發揮作用。
７. 被測試軟體質量要求不高，對測試資料的覆蓋沒有要求。
像之前談到的，作為手工測試的輔助手段，基於影象的自動化功能測試工具可以做到簡便易用，在較小的耗費之下，可以幫助手工測試人員自動化某些需要反覆手工操作的環節，提高手工測試的效率，例如，測試環境的批量搭建，反覆的應用登入行為，應用的開啟和基本的輸入，測試行為的無人值守的操作，例如批量截圖等輔助工作。
高質量要求的產品系統測試中
這些單位，由於他們的軟體或系統，往往涉及人的生命，大量的金錢或社會影響，所以，對軟體的質量提出較高的要求。被測軟體往往測試邏輯複雜，測試資料海量，甚至關鍵輸入要求遍歷。大量的人工的，不可重複的，難以審計的的局面應該著力改觀；沒有可重用的自動化模組，使測試本身的質量依賴於人員和團隊的能力，而得不到穩步的積累和提高。系統測試，或工程現場部署測試的工作往往只做一兩次有限的迭代，只是記錄認為操作的錄製回放成為沒有價值的額外負擔。
這些單位對於功能自動化測試技術的採用，除了可以繼承以上兩種型別單位的使用場景之外，還可以更進一步的考慮，
- 測試行為的模組化。
測試邏輯和測試資料的分離和整理，實現資料驅動相同的測試邏輯模組。即抽取測試中反覆執行的業務邏輯，模組化，重複輸入測試資料，高效實現遍歷。
應著力於被測系統中業務可重複操作序列的抽取和模組化，可以考慮以功能選單和子選單為單位總結業務邏輯形成模組，為第一層的業務模組,例如登入，訂酒店，搜尋酒店，功能模組往往可劃分為選單上顯示的功能，和這些功能實現時，一些有公用價值的子功能；在其下層，建立和資料或介面進行互動和驗證的技術模組，完成抽取和封裝，為第二層的技術模組，例如，滾動到上面的特定文字，選擇檢查框，切換視窗等。 - 測試資料和測試邏輯的遍歷。
將可能合理的測試資料記錄整理在檔案或資料庫中，可以有自動化工具逐行讀取和整理，對輸入沒有限制的介面，應該考慮各類異常資料也要加入到測試資料中。
使用人工智慧，機器學習的演算法，發現可能的各類正常和異常的業務流程自動編排，測試應用的異常處理能力，快速提高功能測試覆蓋率，儘可能多的發現缺陷，減少排程、時序、資料組合等型別指令碼的編寫量。 - 關鍵字驅動技術。
實現測試設計和測試執行的組織人員的分離，實現測試邏輯和測試資料的分離，做“半自動化”測試。
後記
已知缺陷的來源分析，也很重要，因為不是這裡談論的重點，我們附一張圖，作為提要吧。
作為一個從業幾十年的軟體工程諮詢人員，開始涉及功能測試也才幾年，同時實踐工作的經驗也不能和大家相比，一直不敢貿然在各位同仁面前談自己的感覺。後來一想，工作中的點滴感受，與其說是拿來和大家分享，不如說，是請大家指正。也不隱晦工作職責的原因，位置決定思想的嫌疑，是一定有可能的，所以更應把這些想法拿出來請教大家，也就貿然發表了。
聽說我們東邊的鄰國，天性有崇尚“自動化”的習慣，常常做出自動售賣機，自動拉麵機，模擬機器人此類的產品。還手機上，看到德國的大型打雞蛋的流水線。他們真的自動的可以了。相比之下，我們日常工作中，常常和客戶解釋如何應對工具引入後，可以解決人工測試也難得一見的難題，其實也有可能代表了我們嚴謹細密的工作態度，這一切都是和風細雨之前的小考驗啦。
好了，完工。 ：-）