【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面會刷很多人）
我們主要來說技術面，技術面的話主要是考察專業技術知識和水平，上面也是我整理好的精選面試題，

加油吧，測驗人！如果你需要提升規劃，那就行動吧，在路上總比在起點觀望的要好，事必有法，然后有成，

資源不錯就給個推薦吧~