從零鑄造測試技術壁壘

前言

相信全部從事着軟件測試或相關工做的同窗都會思考一個問題: 如何在持續且部分重複的測試活動中有效的進行測試技術積累？

這個有趣的問題我先不予回答，咱們先談談如何有效保證軟件質量。 做爲團隊中的質量保證者，須要深入的意識到，驗證系統原有功能是否高可用 (迴歸測試) 每每比驗證新功能 要重要得多 ( 固然新功能有問題產品小姐姐也是會捶你的 )。這一點在 敏捷開發中更是尤其重要 (不能由於新功能而忽視舊功能) 。

敏捷開發以用戶的需求進化爲核心，採用迭代、按部就班的方法進行軟件開發。在敏捷開發中，軟件項目在構建初期被切分紅多個子項目，各個子項目的成果都通過測試，具有可視、可集成和可運行使用的特徵。換言之，就是把一個大項目分爲多個相互聯繫，但也可獨立運行的小項目，並分別完成，在此過程當中軟件一直處於可以使用狀態。 --百度百科

關於敏捷開發這裏不過多介紹，其中的一個特性我比較看好，那就是 持續交付 。

整個業務市場確定是持續在變化的，支撐業務的軟件若是跟不上市場的節奏，則頗有可能致使業務受到影響甚至直接被市場淘汰。 --筆者

持續交付聽起來高大上，說白了就是保證軟件隨時處於一種可上線的狀態， 而這個時候，測試自動化就顯得格外重要了。

舉個栗子(比較極端):

一次系統迭代到達了既定的上線日，這時仍然存在着數個不嚴重 (核心功能可用) 但也會影響部分支線業務的缺陷。

這時測試問開發:  "你丫的這幾個Bug還能不能修了啊，不修就上了啊" 。

開發回答: "修修修, 我修好這一個Bug你再測一下沒問題就上線" 。

當測試驗證完開發修的Bug而且花了幾個小時手動回測了系統原有功能，剛準備上線時， 
開發急急忙忙跑過來講 : "另一個Bug我也修了, 你再看看沒問題就上線吧" 

這時，相信測試內心是至關難受的， 
先不考慮修復一個Bug致使千千萬萬個新Bug的狀況出現， 光是回測的工程量就不是通常的大。
因而測試幻想着全部測試都交給機器去作，這樣就能夠帶薪發呆了 ...... 
複製代碼

衆所周知，機器在某些方面是優於人類的，因此說一些 重複性 的測試工做徹底能夠交給機器去作，而不該該是堆人數去瘋狂的點點點 ( 雖然該點的時候仍是要點 )。 這時候你可能會問，那自動化測試能徹底代替手工測試嗎？ 答案是 : 不能，由於人類特有的創造性和探索性是目前機器難以模擬的。 雖說徹底用自動化測試代替手工測試是不太現實的， 可是將系統穩定且核心的功能實現測試自動化仍是很是可行的。

只有穩定的功能纔有資格擁有自動化測試。 --筆者

再聊一點題外話，測試人員做爲軟件質量守衛者，系統每一次細微的改動 （包括改Bug），都應該當成一個 全新的版本 去進行測試。可是當 測試 - > 修復缺陷 -> 驗證缺陷 -> 回測 的循環次數逐漸增多時，測試人員的測試熱情確定已經不如第一次測試時那麼高昂了，內心也是處於一種得過且過的心態。(只要不爆炸，你就給我上)

測試人員對缺陷的容忍度會隨着工做時長而增長。 --筆者

每一次迭代到後期，測試人員更應關注核心功能是否高可用(條件容許的話，系統原有核心功能的測試交給自動化，新核心功能測試則根據實際狀況部分自動化部分人工)，否則的話項目可能會將無限延期下去。 因此這也就是爲何軟件上線後不可避免的會出現一些新問題或者是老問題復現。在每一次迭代中，想要徹底實現100%自動化測試那是不太可能的，除非有許多專業且精通業務的測試開發人員，然而咱們知道這是不現實的(不只是公司成本問題，市場上也沒那麼多人才)。同時，自動化測試的實現也是開發的一個過程，自動化測試自己也可能會有缺陷，開發自動化測試的難度甚至比被測軟件開發自己還要高，隨着被測軟件不斷迭代，自動化測試也必然要緊跟着被測軟件的腳步進行迭代，測試框架也須要測試人員花精力與時間去維護。 --來自筆者的吐槽

然而吐槽事後，該作的仍是要作。言歸正傳, 測試技術積累 無非有幾個大方向: 自動化測試、 性能測試、 安全測試，(其實性能、安全測試均可以包括在自動化測試內)。每一項測試對於一個系統來講都十分重要，可是其中偏功能的自動化測試相對來講更直觀更易上手。以目前主流的Web項目來講，先不考慮單元測試(基本由開發人員負責) ,測試人員能把接口測試以及UI自動化測試作好的話，軟件就基本達到可快速持續交付的標準了， 而接口測試對比UI自動化測試來講環境更 封閉 ，測試覆蓋率也比較容易獲得保障。因此說大方向上先把接口測試作起來是沒有任何毛病的。 (但請注意接口測試全經過了軟件也可能存在嚴重的UI界面上的缺陷，筆者吃過虧，別問都是淚)

筆者接口測試學習並實踐了一段時間後，以爲一直堆測試代碼並非很優雅，基於這一點，決定本身從零搭建一套 易用輕便(最後估計會變得很臃腫) 的自動化測試平臺 。雖然如今測試開源平臺多如牛毛，可是俗話說的好，只有本身作出來的東西纔是最合適、用起來纔是最爽的。 作人若是沒夢想，和鹹魚有什麼區別 (筆者但是要將人工智能與測試結合的人)。因而說幹就幹，雖然過程很艱辛 (從零開始摸爬滾打了 小半年)，但勉強算是搭建出了一個簡易可用的測試平臺。

正文將圍繞測試技術壁壘以及筆者正在構建的測試平臺不斷地進行總結與分享，筆者也不是什麼大牛，但願能在持續分享中同讀者共同成長。

以爲這篇東西有點意思的朋友請點個贊哦~

有任何問題或想法歡迎隨時溝通 :)

--2019-5-7
複製代碼

正文

"智能"測試平臺初體驗

---

整個測試平臺技術架構爲: Python-Flask + Vue + MongoDB， 其中整個後端代碼由筆者獨立完成，前端則借鑑了某開源項目，在此感謝該開源項目提供的靈感。

本章將不敘述任何實現思路以及細節，僅僅展現一下平臺目前的一個使用流程。

---

首先咱們經過【登陸頁面】進入【平臺首頁】而且在【接口測試】下新建一個名爲【測試項目】的項目:

而後進入【測試項目】並 新增一條 【測試用例】

接着進入【測試用例】並 新增一條 【接口測試用例】(筆者的想法是一條測試用例下可對多個接口進行測試):

好的這個時候咱們進入【修改】頁面，填入接口測試用例信息並點擊【保存】:

如今咱們須要先去【Host配置】設置測試的host地址(選取當前本機的平臺項目後端做爲演示地址):

好的如今回到【測試列表】選取測試用例以及測試環境後點擊【執行測試】:

這個時候頁面會自動跳轉至【自動化測試報告】頁面，咱們能夠點擊【查看詳情】查看詳細內容:

咦？ 怎麼飄紅了？，喔原來是協議選錯了，本機並無配置CA證書，並不支持HTTPS訪問。

那麼咱們這個時候回到接口用例修改頁面，將HTTPS換成HTTP:

再一次進行測試，這個時候能夠看到測試終於經過咯:

下面咱們來演示一下【定時任務】功能，首先先新增一個定時任務:

新增完畢後，可自由 編輯/停用/啓用 且 當即生效！:

過一段時間後，咱們能夠進入【自動化測試報告】查看定時任務是否正常工做,

在下方動圖能夠看到列表中新增了不少執行方式被標記爲【定時執行】的測試報告:

有沒有以爲測試都是全經過，一點意思都沒有，好的那咱們去修改一下用例的測試結果校驗，讓他成爲永遠都經過不了的測試用例:

過一段時間後咱們回到【自動化測試報告】頁面，發現多出了不少經過率爲0%的測試報告:

同時，系統會向定時任務中設置的告警郵箱發送警告，相關人員收到告警郵件後，進入系統內搜索郵件中的報告編號，便可找到存在失敗用例的測試報告:

至此，筆者目前構建的 "智能"測試平臺 使用主流程就介紹完畢啦，後續將會分享其中一些小細節以及不斷的進行功能迭代。

熱烈祝賀本次介紹圓滿結束 :)

歡迎你們掃碼關注個人公衆號「智能測試開發」，

回覆：優質教程， 便可免費得到 泰斯特平臺完整使用教程

回覆：測試進階教程，便可免費得到 進階教程 ~