【Python】自動化測試的7個步驟
我們對自動化測試充滿了希望，然而，自動化測試卻經常帶給我們沮喪和失望。雖然，自動化測試可以把我們從困難的環境中解放出來，在實施自動化測試解決問題的同時，又帶來同樣多的問題。在開展自動化測試的工作中，關鍵問題是遵循軟體開發的基本規則。本文介紹自動化測試的 7 個步驟：改進自動化測試過程，定義需求，驗證概念，支援產品的可測試性，具有可延續性的設計（ design for sustainability ），有計劃的部署和麵對成功的挑戰。按照以上 7 個步驟，安排你的人員、工具和制定你的自動化測試專案計劃，你將會通往一條成功之路。
一個故事：
我在很多軟體公司工作過，公司規模有大有小，也和來自其他公司的人員交流，因此經歷過或者聽說過影響自動化測試效果的各種各樣的的問題。本文將提供若干方法規避可能在自動化測試中出現的問題。我先給大家講一個故事，以便各位瞭解自動化測試會出現哪些問題。
以前，我們有一個軟體專案，開發小組內所有的人都認為應該在專案中採用自動化測試。軟體專案的經理是 Anita Delegate 。她評估了所有可能採用的自動化測試工具，最後選擇了一種，並且購買了幾份拷貝。她委派一位員工 ——Jerry Overworked 負責自動化測試工作。 Jerry 除了負責自動化測試工作，還有其他的很多工。他嘗試使用剛剛購買的自動化測試工具。當把測試工具應用到軟體產品測試中的時候，遇到了問題。這個測試工具太複雜，難於設定。他不得不給測試工具的客戶支援熱線打了幾個電話。最後， Jerry 認識到，他需要測試工具的技術支援人員到現場幫助安裝測試工具，並找出其中的問題。在打過幾個電話後，測試工具廠商派過來一位技術專家。技術專家到達後，找出問題所在，測試工具可以正常工作了。這還算是順利了。但是，幾個月後，他們還是沒有真正實現測試自動化， Jerry 拒絕繼續從事這個專案的工作，他害怕自動化測試會一事無成，只是浪費時間而已。
專案經理 Anita 把專案重新指派給 Kevin Shorttimer ，一位剛剛被僱傭來做軟體測試的人員。 Kevin 剛剛獲得電腦科學的學位，希望通過這份工作邁向更有挑戰性的、值得去做的工作。 Anita 送 Kevin 參加工具培訓，避免 Kevin 步 Jerry 的後塵 —— 由於使用測試工具遇到困難而變得沮喪，導致放棄負責的專案。 Kevin 非常興奮。這個專案的測試需要重複測試，有點令人討厭，因此，他非常願意採用自動化測試。一個主要的版本釋出後， Kevin 準備開始全天的自動化測試，他非常渴望得到一個機會證明自己可以寫非常複雜的，有難度的程式碼。他建立了一個測試庫，使用了一些技巧的方法，可以支援大部分的測試，這比原計劃多花費了很多時間，不過， Kevin 使整個測試工作開展的很順利。他用已有的測試套測試新的產品版本，並且確實發現了 bug 。接下來， Kevin 得到一個從事軟體開發職位的機會，離開了自動化的崗位。
Ahmed Hardluck 接手 Kevin 的工作，從事自動化測試執行工作。他發現 Kevin 留下的檔案不僅少，並且沒有太多的價值。 Ahmed 花費不少時間去弄清楚已有的測試設計和研究如何開展測試執行工作。這個過程中， Ahmed 經歷了很多失敗，並且不能確信測試執行的方法是否正確。測試執行中，執行失敗後的錯誤的提示資訊也沒有太多的參考價值，他不得不更深的鑽研。一些測試執行看起來彷彿永遠沒有結束。另外一些測試執行需要一些特定的測試環境搭建要求，他更新測試環境搭建檔案，堅持不懈地工作。後來，在自動化測試執行中，它發現幾個執行失敗的結果，經過分析，是迴歸測試的軟體版本中有 BUG ，導致測試執行失敗，發現產品的 BUG 後，每個人都很高興。接下來，他仔細分析測試套中的內容，希望通過優化測試套使測試變得更可靠，但是，這個工作一直沒有完成，預期的優化結果也沒有達到。按照計劃，產品的下一個釋出版本有幾個主要的改動， Ahmed 立刻意識到產品的改動會破壞已有的自動化測試設計。接下來，在測試產品的新版本中，絕大多數測試用例執行失敗了， Ahmed 對執行失敗的測試研究了很長時間，然後，從其他人那裡尋求幫助。經過商討，自動化測試應該根據產品的新介面做修改，自動化測試才能運轉起來。最後，大家根據新介面修改自動化測試，測試都通過了。產品釋出到了市場上。接下來，使用者立刻打來投訴電話，投訴軟體無法運作。大家才發現自己改寫了一些自動化測試指令碼，導致一些錯誤提示資訊被忽略了。雖然，實際上測試執行是失敗的，但是，由於改寫指令碼時的一個程式設計錯誤導致失敗的測試執行結果被忽略了。這個產品終於失敗了。
這是我的故事。或許您曾經親身經歷了故事當中某些情節。不過，我希望你沒有這樣的相似結局。本文將給出一些建議，避免出現這樣的結局。
問題
這個故事闡明瞭幾個使自動化測試專案陷入困境的原因：
自動化測試時間不充足：根據專案計劃的安排，測試人員往往被安排利用自己的個人時間或者專案後期介入自動化測試。這使得自動化測試無法得到充分的時間，無法得到真正的關注。
缺乏清晰的目標：有很多好的理由去開展自動化測試工作，諸如自動化測試可以節省時間，使測試更加簡單，提高測試的覆蓋率，可以讓測試人員保持更好的測試主動性。但是，自動化測試不可能同時滿足上述的目標。不同的人員對自動化測試有不同的希望，這些希望應該提出來，否則很可能面對的是失望。
缺乏經驗：嘗試測試自己的程式的初級的程式設計師經常採用自動化自動化測試。由於缺乏經驗，很難保證自動化測試的順利開展。
更新換代頻繁（ High turnover ）：測試自動化往往需要花費很多時間學習的，當自動化測試更新換代頻繁的時候，你就喪失了剛剛學習到的自動化測試經驗。
對於絕望的反應：在測試還遠沒有開始的時候，問題就已經潛伏在軟體中了。軟體測試不過是發現了這些潛伏的問題而已。就測試本身而言，測試是一件很困難的工作。當在修改過的軟體上一遍接一遍的測試時，測試人員變得疲勞起來。測試什麼時候後結束？當按照計劃的安排，軟體應該交付的時候，測試人員的絕望變得尤其強烈。如果不需要測試，那該有多好呀！在這種環境中，自動化測試可能是個可以選擇的解決方法。但是，自動化測試卻未必是最好的選擇，他不是一個現實的解決方法，更像是一個希望。
不願思考軟體測試：很多人發現實現產品的自動化測試比測試本身更有趣。在很多軟體專案發生這樣的情況，自動化工程師不參與到軟體測試的具體活動中。由於測試的自動化與測試的人為割裂，導致很多自動化對軟體測試並沒有太大的幫助。
關注於技術：如何實現軟體的自動化測試是一個很吸引人的技術問題。不過，過多的關注如何實現自動化測試，導致忽略了自動化測試方案是否符合測試需要。
遵守軟體開發的規則
你可能瞭解 SEI （軟體工程研究所）提出的 CMM （能力成熟度模型）。 CMM 分為 5 個界別，該模型用來對軟體開發組織劃分等級。 Jerry Weinberg （美國著名軟體工程專家）也建立了自己的一套軟體組織模型，在他的組織模型中增加了一個額外的級別，他稱之為零級別。很顯然，一個零模式的組織實際上也是開發軟體；零模式組織中，在開發人員和使用者之間沒有差別 [Weinberg 1992] 。恰恰在這類組織環境中，經常採用自動化測試方法。因此，把資源用於自動化測試，並且把自動化測試當作一個軟體開發活動對待，把軟體測試自動化提升到一級。這是解決測試自動化的核心的方案。我們應該像運作其他的開發專案一樣來運作軟體自動化測試專案。
像其他軟體開發專案一樣，我們需要軟體開發人員專注於測試自動化的開發任務；像其他軟體開發專案一樣，自動化測試可以自動完成具體的測試任務，對於具體的測試任務來說，自動化開發人員可能不是這方面的專家，因此，軟體測試專家應該提供具體測試任務相關的諮詢，並且提供測試自動化的需求；像其他軟體開發專案一樣，如果在開發編碼之前，對測試自動化作了整體設計有助於測試自動化開發的順利開展。像其他軟體開發專案一樣，自動化測試程式碼需要跟蹤和維護，因此，需要採用原始碼管理。像其他軟體開發專案一樣，測試自動化也會出現 BUG ，因此，需要有計劃的跟蹤 BUG ，並且對修改後的 BUG 進行測試。像其他軟體開發專案一樣，使用者需要知道如何使用軟體，因此，需要提供使用者使用手冊。
本文中不對軟體開發做過多講述。我假定您屬於某個軟體組織，該組織已經知道採用何種合理的、有效的方法開發軟體。我僅僅是推動您在自動化測試開發過程中遵守已經建立的軟體開發規則而已。本文按照在軟體開發專案中採用的標準步驟組織的，重點關注測試自動化相關的事宜和挑戰。
● 改進軟體測試過程
● 定義需求
● 驗證概念
● 支援產品的可測試性
● 可延續性的設計（ design for sustainability ）
● 有計劃的部署
● 面對成功的挑戰
步驟一：改進軟體測試過程
如果你負責提高一個商業交易操作的效率，首先，你應該確認已經很好的定義了這個操作的具體過程。然後，在你投入時間和金錢採用計算機提供一套自動化的商業交易作業系統之前，你想知道是否可以採用更簡單、成本更低的的方法。同樣的，上述過程也是用於自動化測試。我更願意把 「 測試自動化 」 這個詞解釋成能夠使測試過程簡單並有效率，使測試過程更為快捷，沒有延誤。執行在計算機上的自動化測試指令碼只是自動化測試的一個方面而已。
例如，很多測試小組都是在迴歸測試環節開始採用測試自動化的方法。迴歸測試需要頻繁的執行，再執行，去檢查曾經執行過的有效的測試用例沒有因為軟體的變動而執行失敗。迴歸測試需要反覆執行，並且單調乏味。怎樣才能做好迴歸測試檔案化的工作呢？通常的做法是採用列有產品特性的列表，然後對照列表檢查。這是個很好的開始，迴歸測試檢查列表可以告訴你應該測試哪些方面。不過，迴歸測試檢查列表只是合於那些瞭解產品，並且知道需要採用哪種測試方法的人。
在你開始測試自動化之前，你需要完善上面提到的迴歸測試檢查表，並且，確保你已經採用了確定的的測試方法，指明測試中需要什麼樣的資料，並給出設計資料的完整方法。如果測試掌握了基本的產品知識，這會更好。確認可以提供上面提到的檔案後，需要明確測試設計的細節描述，還應該描述測試的預期結果，這些通常被忽略，建議測試人員知道。太多的測試人員沒有意識到他們缺少什麼，並且由於害怕尷尬而不敢去求助。這樣一份詳細的檔案給測試小組帶來立竿見影的效果，因為，現在任何一個具有基本產品知識的人根據檔案可以開展測試執行工作了。在開始更為完全意義上的測試自動化之前，必須已經完成了測試設計檔案。測試設計是測試自動化最主要的測試需求說明。不過，這時候千萬不要走極端去過分細緻地說明測試執行的每一個步驟，只要確保那些有軟體基本操作常識的人員可以根據檔案完成測試執行工作既可。但是，不要假定他們理解那些存留在你頭腦中的軟體測試執行的想法，把這些測試設計的思路描述清楚就可以了。
我以前負責過一個軟體模組的自動化測試工作。這個模組的一些特性導致實現自動化非常困難。當我瞭解到這項工作無需在很短的時間內完成後，決客製化定一個詳細迴歸測試設計方案。我仔細地檢查了缺陷跟蹤庫中與該模組相關的每個已經關閉的缺陷，針對每個缺陷，我寫了一個能夠發現該問題的測試執行操作。我計劃採用這種方法提供一個詳細的自動化需求列表，這可以告訴我模組的那一部分最適合自動化測試。在完成上述工作後，我沒有機會完成測試自動化的實現工作。不過，當我們需要對這個模組做完整迴歸測試的時候，我將上面提到的檔案提供給若干只瞭解被測試產品但是沒有測試經驗的測試人員。依照檔案的指導，幾乎不需要任何指導的情況下，各自完成了迴歸測試，並且發現了 BUG 。從某種角度看，這實際上是一次很成功的自動化測試。在這個專案中，我們與其開發自動化測試指令碼，還不如把測試執行步驟檔案化。後來，在其它專案中，我們開發了自動化測試指令碼，發現相關人員只有接受相關培訓才能理解並執行自動化測試指令碼，如果測試自動化設計的很好，可能會好一些。不過，經過實踐我們總結出完成一份設計的比較好的測試檔案，比完成一份設計良好的測試指令碼簡單的多。
另外一個提高測試效率的簡單方法是採用更多的計算機。很多測試人員動輒動用幾臺計算機，這一點顯而易見。我之所以強調採用更多的計算機是因為，我曾經看到一些測試人員被誤導在單機上努力的完成某些大容量的自動化測試執行工作，這種情況下由於錯誤的使用了測試裝置、測試環境，導致測試沒有效果。因此，自動化測試需要集中考慮所需要的支撐裝置。
針對改進軟體測試過程，我的最後一個建議是改進被測試的產品，使它更容易被測試，有很多改進措施既可以幫助使用者更好的使用產品，也可以幫助測試人員更好的測試產品。稍後，我將討論自動化測試的可測試需求。這裡，我只是建議給出產品的改進點，這樣對手工測試大有幫助。
一些產品非常難安裝，測試人員在安裝和解除安裝軟體上花費大量的時間。這種情況下，與其實現產品安裝的自動化測試，還不如改進產品的安裝功能。採用這種解決辦法，最終的使用者會受益的。另外的一個處理方法是考慮開發一套自動安裝程式，該程式可以和產品一同釋出。事實上，現在有很多專門製作安裝程式的商用工具。
另一些產品改進需要利用工具在測試執行的紀錄檔中查詢錯誤。採用人工方法，在紀錄檔中一頁一頁的查詢報錯資訊很容易會讓人感到乏味。那麼，趕快採用自動化方法吧。如果你瞭解紀錄檔中記錄的錯誤資訊格式，寫出一個錯誤掃描程式是很容易的事情。如果，你不能確定紀錄檔中的錯誤資訊格式，就開始動手寫錯誤掃描程式，很可能面臨的是一場災難。不要忘記本文開篇講的那個故事中提到的測試套無法判斷測試用例是否執行失敗的例子。終端使用者也不願意採用通過搜尋紀錄檔的方法查詢錯誤資訊。修改錯誤資訊的格式，使其適合紀錄檔掃描程式，便於掃描工具能夠準確的掃描到所有的錯誤資訊。這樣，在測試中就可以使用掃描工具了。
通過改進產品的效能對測試也是大有幫助的。很顯然的，如果產品的效能影響了測試速度，鑑別出效能比較差的產品功能，並度量該產品功能的效能，把它作為影響測試進度的缺陷，提交缺陷報告。
上面所述的幾個方面可以在無需構建自動化測試系統的情況下，大幅度的提高測試效率。改進軟體測試過程會花費你構建自動化測試系統的時間，不過改進測試過程無疑可以使你的自動化測試專案更為順利開展起來。
上面是我收集的一些視訊資源，在這個過程中幫到了我很多。如果你不想再體驗一次自學時找不到資料，沒人解答問題，堅持幾天便放棄的感受的話，可以加入我們扣扣群【313782132 】，裡面有各種軟體測試資源和技術討論。
當然還有面試，面試一般分為技術面和hr面，形式的話很少有群面，少部分企業可能會有一個交叉面，不過總的來說，技術面基本就是考察你的專業技術水平的，hr面的話主要是看這個人的綜合素質以及家庭情況符不符合公司要求，一般來講，技術的話只要通過了技術面hr面基本上是沒有問題（也有少數企業hr面會刷很多人）
我們主要來說技術面，技術面的話主要是考察專業技術知識和水平，上面也是我整理好的精選面試題。
加油吧，測試人！如果你需要提升規劃，那就行動吧，在路上總比在起點觀望的要好。事必有法，然後有成。
資源不錯就給個推薦吧~