前言
武讓是極狐(GitLab)公司 高階解決方案架構師，具備 10 年產業網際網路從業經驗。先後在創業公司和上市公司擔任架構師和技術總監。阿里雲 MVP、AWS SAP、CSM、TOGAF 認證架構師。近幾年致力於企業數字化轉型。現負責極狐(GitLab)公司解決方案的設計與推廣。
本文基於武讓在「聲網開發者創業講堂 • 第三期丨創業初期如何保障產品質量」活動中分享內容二次整理。關注公眾號「聲網開發者」，回覆關鍵詞「JT0611」即可下載活動相關 PPT 資料。
01 理論篇
1、水星計劃與軟體測試
說到軟體測試，據說最早有記載的軟體測試是在人類的第一次載人航天計劃，也就是水星計劃中提到的，我不確定是不是最早，但是我確實查到是有一些記載，因為載人航天涉及生命安全以及政治因素（ 1958 年美國跟前蘇聯的冷戰太空競賽），所以美國非常重視，就引入了軟體測試，所以也可以看到為什麼現在非常多的企業不太注重測試，其實就是因為產品不涉及生命安全或者政治，大家沒有碰到這些所謂的紅線，也就對這部分沒有那麼重視了。
2、軟體測試發展歷程
圖 1 展示了軟體測試的發展史，初步可以分成五個階段，最早從20世紀 50 年代開始，此時沒有測試一說，更多的是叫作除錯。到 1957 年，Charles baker 才提出了測試的概念。
所謂的測試和除錯的區別是，除錯的目的是使程式符合開發人員的預期，而對於測試來說，就要確認程式是不是符合產品功能需求的預期。第三階段就是不光要做測試，還要對程式進行一些探索性的測試，確認有沒有做不該做的事情。第四個階段就是測試人員都比較熟悉的V&V理論，對應軟體測試中的V模型，這個模型的話目前在整個工業領域中還在廣泛地應用，它第一次提出軟體測試要被應用在整個軟體的生命週期當中。我認為截止到今天，整個軟體測試還在第五個階段，就是要去做一些探索性的測試、敏捷測試，以及 TDD、BDD 這些新的概念的興起帶來的所謂自動化工具持續整合這類技術的應用。所以在整個第五階段，我們的目的是在程式碼級別防止缺陷，而不僅僅是侷限測試。這五個階段不是完全獨立的，更多的是繼承。
■圖 1
3、軟體測試分類
圖 2 左上角是傳統的軟體分類，做測試的人員可能比較熟悉，它其實就是按照不同的維度對軟體測試的方法進行了分類。但是這種所謂的傳統分類容易出現概念的交叉，存在邊界模糊的問題，這導致這一套分類理論會比較複雜。
■圖 2
對於初創型企業來說，如果企業內部有這麼一套複雜的、模糊的概念體系存在，則不利於傳播，也不易提升認知上的統一，或者說直接影響到了效率。為了解決這樣的問題，就有了右上角的測試金字塔，這個金字塔把各種模糊不清的測試方法全部都進行了整合，形成了三段式或者多段式的，從底往上、從大變小的過程。這裡的分層包括單元層、服務層和 UI 層，越往下，獨立性越高；越往上，整合性越高。所以應該在下層寫更多的測試用例，在上層做更少的測試，這才是一個健康的測試狀態。
無獨有偶，Google在《Google軟體測試之道》中也對測試進行了重新的分類，它的分類方法是按照大、中、小型測試來做劃分，這個劃分從某種意義上來說，跟測試金字塔是相匹配的，小型測試對應金字塔測試中的單元層，就是說可以測一些單獨的模組，在小型測試中可以處理獨立的函式。同時它也給出了一個佔比，Google 認為所謂的小型測試應該佔七成，中型測試佔兩成（模組之間的整合性測試佔兩成），最後全面的系統性測試只需佔 10%。圖 2 下方是 Google 給出的分類。對於初創型企業來說，建議選擇測試金字塔模型，分層的層數和名稱企業可以自定義，但是對於這樣的模型，首先要統一概念，否則如果測試人員和開發人員的語言不統一，那麼在開展工作的時候會遇到很多的問題。
4、自動化測試工具
自動化測試伴隨著敏捷開發、敏捷測試等概念得到了蓬勃的發展，通過圖 3 大家可以看到主流的自動化測試工具，早期主要是線性測試，就是通過錄制的方式生成指令碼、巨集，這種是比較常見的形式，後期測試工具有了更多的型別變化，比如支援結構化的、資料驅動的以及關鍵字驅動的測試。形式上來說主要有兩種，一種是基於 UI，一種是基於 API，基於 API 的形式就是呼叫 API，更多的是在介面層面進行操作。基於 UI 的形式就是模擬使用者的操作，比如在介面上移動滑鼠、點選滑鼠、按鍵等。
■圖 3
5、自動化測試開展條件
自動化測試的優勢我認為主要有兩點，第一點就是它可以代替一些重複但必要的測試工作，解決重複勞動問題。第二點也很重要，因為重複性工作容易引入人為的差錯，此時就應該通過工具來輔助。雖然自動化測試優勢明顯，但是它的劣勢同樣不可小覷，很多人認為自動化測試是萬金油，在任何情況下都可以開展，其實並不是，它的劣勢也包含兩點，第一點就是成本較高，尤其是短期的開銷比較大，如果要進行自動化測試，需要人才培養或者人才招聘、流程建立以及指令碼編寫和維護，這些都需要一個成本比較大的開銷。此外，前面說了自動化測試的優勢是可以代替做重複性勞動，相對應的劣勢就是不容易發現新的 bug，因為它只能做重複的任務，想讓它發現新的 bug 是比較難的，雖然說現在有模糊測試、混沌工程，但它始終不像人一樣擅長或者能夠發現新的 bug。
那在什麼樣的情況下，初創企業可以開展自動化測試，主要有三點：第一點就是產品週期比較長，這裡指的是穩定的產品，如果是 demo 型產品，就沒有必要進行自動化了。第二點是頻繁的迭代，這一點是它的價值所在。第三點是產品相對穩定，這一點其實從某種意義上來說與第一點是捆綁的，因為產品穩定，才能有穩定的收益，才可以做投入。
所以對於自動化測試來說，更多的是與傳統的手動測試的互補，而不是替代。互補是兩方面的，第一個方面就是如果不具備自動化測試所需的條件，就可以做手動測試；另一方面就是針對自動化測試不容易發現新 bug 的特點，需要人先做探索性測試，然後再把這部分內容轉變成自動化的指令碼。
6、敏捷與軟體測試
敏捷測試與敏捷開發一樣，就是敏捷開發的一部分，它是一個思想，而不是一種方法。那麼這個思想跟傳統測試的區別是什麼呢？我認為主要包括以下幾點：
首先最主要的是溝通，要開展敏捷測試，最主要的是面向客戶需求的全員測試，從產品、專案、開發到測試，要清楚地理解使用者的需求，如果依靠傳統的文件方式，訊息的傳遞效率是比較低的，而且不及時，這是傳統測試的侷限所在。所以對於初創型的企業來說，即便一開始不採用敏捷測試，也可以借鑑它的思想來幫助解決測試人員不瞭解需求的現象。
第二點是說敏捷擁抱變化，但擁抱變化不是讓大家肆無忌憚地頻繁變更需求。因為敏捷始終強調慢思考，快行動，一拍腦門就往前衝不是敏捷，所以一旦把測試前置，那麼又將是一筆不小的投入，此時公司管理層要思考和把控需求的變化，不能朝令夕改，否則非常容易傷害整個團隊。
7、敏捷測試最佳實踐
前面提到敏捷是一種思想，而不是具體的實踐。雖然市面上有非常多的廠商（包括資金機構）提到最佳實踐，但我認為它是一種通用的模型，每個企業的情況不一樣，套用統一的方式去可能會形成反向的效果。
這裡有幾點跟大家分享，在標準模型中提到了測試前移，測試要參與到需求的評估過程當中，如圖 4 左上角所示，這裡顯示在迭代開始之前，測試人員就要參與迭代的測試分析，這個分析主要指的是需求的拆解、細化，然後編寫 AC 之類的內容。圖中還提到全量的迴歸測試，這才是敏捷測試以及自動化測試的特點，就是進行全量的迴歸測試。每個迭代週期都要做測試，將之前測過的內容重新再測一遍，這就需要不斷地完善和積累自動化測試的指令碼。這對於敏捷和自動化測試來說，都是其充分發揮價值的地方。
■圖 4
從圖中下方可以看到，企業開展敏捷測試一定要按需實踐，逐步提升。對於小的團隊來說，比如團隊小於五人這種初創的不穩定階段，還是不要一開始就全部應用自動化測試，我們的目的還是簡單高效，內容太多反而會拖後腿。但還是需要具備這樣的能力，因為要隨時準備做規模化、正規化的業務。
8、DevOps 與軟體測試
現在很多企業在做 DevOps 轉型，那麼 DevOps 與軟體測試又有怎樣的關係呢？首先可以看圖 5 左下角，這裡的 DevOps 這個詞用得不好，它只是把開發人員和運維人員的單詞拆進去了，但實際上 DevOps 是軟體開發、測試跟運維三方面的，這個詞只是體現了兩個方面。測試是 DevOps 中的重要一環，如圖中右下角所示，其中提到 DevOps 跟敏捷開發的區別，最主要的是反饋的週期更快了，如果此時仍然用傳統的方式做測試，那麼其能力、頻率都不足以滿足這麼快的交付頻率，這對測試是一個非常大的挑戰，同時也是其重要性的體現。
■圖 5
在 DevOps 中的測試扮演著怎樣的角色呢？它其實更多的是扮演牽制和協同的角色。舉一個簡單的例子，我們的軟體要釋出上線，這個時候應該是開發人員提交程式碼，然後QA測試無誤，才允許把製品交給 Ops 做部署。如果線上出了問題，Ops 會通過監控平臺第一時間先反饋給 QA 來驗證，驗證通過之後再反饋給開發，而並不是直接反饋給開發。所以在這個過程中它更多的是扮演牽制和協同的角色。
DevOps，這裡 Dev 開發對應著 CI/CD 工具中的 CI（持續整合），Ops 對應的是 CD（持續部署）。對測試來說對應的是 CT（持續測試）。持續測試的概念介紹在圖中左上角。
02 實踐篇
1、極狐 GitLab 持續測試最佳實踐
圖 6 主要表達的思想是要把軟體測試融入到整個軟體開發的工作流當中，具體分成兩個重要的部分：第一個就是要通過極狐 GitLab 的 CI/CD（或者其他平臺也可以）把自動化測試工具整合起來。將 CI/CD 和自動化測試工具整合的目的是要實現的是全面的自動化。這樣開發人員程式碼提交或者測試指令碼更新之後，就可以通過 CI/CD 立刻觸發一次全面的測試，才能徹底解決效率問題。CI/CD 整合自動化測試工具，這一點類似於我們所說的空間站的概念，極狐 GitLab 或者各公司採用的 DevOps 平臺，本質上就是一個核心倉，測試工具可以通過模組化的方式與其進行對接，最後拼接成一個完整的空間站。
■圖 6
第二個重要的內容就是測試左移、測試右移和質量門禁，測試左移就是測試前置，測試人員參與到需求的評審環節中，解決大家對於需求的理解問題。而測試右移就是在程式釋出到線上之後，需要 Ops 監控，遇到問題之後發出報警。這兩部分很重要，但都沒有中間程式碼評審部分那麼重要，因為很多公司都在建立所謂的質量門禁。這裡會遇到兩種問題：第一個問題就是如何管理這麼多測試工具的報告，很多團隊直接把報告發到郵件或者聊天工具中，但是這樣程式碼、版本怎麼跟報告匹配呢？另一個問題就是時機問題，就是怎麼關聯測試跟程式碼的評審，如果評審通過了，程式碼也合到主幹分支中了，但是測試報告不通過，也是不行的，這相當於測試跟程式碼評審沒有形成關聯。測試門禁就失去了它的意義和價值。
2、極狐 GitLab 軟體測試基座
對於 極狐GitLab 來說，我們要解決的問題，就是將測試跟程式碼的評審結合起來，傳統的測試報告都是離散的，現在需要對這些資料進行整理，將所有測試工具的報告整合到程式碼評審的頁面中，這樣在評審的時候就能夠第一時間清晰地看到這些報告，並且確保是跟這一次提到的程式碼關聯的報告。程式碼評審人員參考這些報告後，只需要簽字即可。
對於極狐 GitLab 來說，我們一直認為一定是要把這些資料統一地彙總起來去做程式碼稽核，這對落實程式碼門禁和程式碼質量是非常重要的。
3、準備工作
接下來將介紹企業內部，尤其是初創性企業，如何在什麼都沒有的情況下開展測試工作？如圖 7 所示，首先是關於前置條件，這裡我列了三點，最主要的就是你先得有版本控制，意味著有程式碼管理的平臺，這是測試的前提。然後就是 CI/CD，它主要解決效率的問題，並且它可以作為剛才所說的整合平臺，也就是核心艙，跟測試工具來做對接。第三點就是，在企業內部沒有專業的測試人員或者規模還沒完成的情況下，如果我們仍想做一些基本的測試（簡單的測試大多數也是以手動為主），那麼可以採用程式碼的掃描工具，比如程式碼質量的掃描、程式碼安全的掃描來一定程度地彌補手工測試的不足，比如變數名稱命名、註釋不全這類的問題。
■圖 7
在滿足這些條件之後，如果有能力開展自動化測試，結合剛才所說的測試金字塔理論，一般認為最底下的最重要，正常來說應該是單元測試最重要，但實際上這裡我把單元測試排在第二位了，把介面測試放到了前面。這是因為對於國內的企業和開發人員來說，大家普遍沒有做單元測試的文化，大部分開發人員都是處於工作飽和的狀態，此時如果再去寫單元測試，會引起更大的牴觸情緒。而做介面測試的話，可以使用到一些視覺化工具，這些工具不需要程式設計能力，就可以去實現介面的自動化測試。
4、介面測試
圖 8 展示了介面測試的優勢，最主要的是第 4 點和第 5 點，第 4 點是說，介面測試可以通過視覺化工具來進行，此時門檻是比較低的，測試人員比較容易掌握，不需要增加太多的負擔。第 5 點說的是，介面相對來說會比 UI 層面更穩定一些，那麼你自動化後他的價值是可以更多的體現出來。流程上來說，一般是測試人員利用這些視覺化工具編寫測試用例，然後匯出為測試指令碼，再用這些工具的無 UI 的實現（如 Docker 容器）把指令碼載入進去，就可以實現自動化介面測試。這兩點在實操層面（落地層面）是比較容易實施的，所以說介面測試對初創性的企業來說，是應該最早被推行的。
■圖 8
對於怎麼做介面測試，這裡沒有講得那麼具體，我在圖的下方簡單概括了一下，介面測試涉及的工具很多，比如介面文件的管理、介面測試的工具、mock 工具、效能測試工具等，對於初創性企業來說，我推薦大家用一體化工具，其實國內現在有很多一體化工具，它可以去幫我們管理介面文件，也可以做介面測試，甚至可以做效能測試等。對於初創企業來說簡化了工作，進而提升了效率。
5、效能測試
接下來就可以開展效能測試，因為大部分的效能測試幾乎都是基於介面的，所以在做完介面測試之後，可以順帶進行效能測試。效能測試的型別如圖 9 所示，比如負載、壓力、浸泡、衝擊測試等了。在開展效能測試之前，一定要明確到底要做什麼型別的效能測試。效能測試不是強需求，而是非功能性的需求，不同型別決定了目的不同，所以要帶著明確的目的去做。圖9 中間是微軟給出的效能測試的核心流程，可以參考它去做。
■圖 9
6、單元測試
下面就可以做單元測試了，其實也可以把它提前到第一個階段去做，我沒把它放到最前面是因為，國內關於單元測試分成兩派，有的人支援，有的人反對，對於企業來說，只要重視產品的質量，並且人員的能力是滿足的，就可以先嚐試去做。可以從三個方面考慮，如圖 10 所示，就是“誰做、咋測、效果”。
■圖 10
“誰做”這一點毋庸置疑，單元測試不是測試人員去做，一定是開發人員自己來做，國外開展敏捷測試，比如極限程式設計中提到的結對程式設計、結對開發，是大家相互做單元測試，但是在國內較難推行。“咋測”就是要驗證單個程式、單個函式方法的變數、條件、路徑、資源是否正確。實際上在正常的開發過程中，開發人員都會做自測，這個自測可能是開發人員自己打好包，從 API 層面或者 UI 層面呼叫到所寫的程式方法的步驟（從外側呼叫到內側），檢視是否正確，這樣效率比較低。也可能是開發人員寫一些馬甲程式來實現函式正確性的驗證。從某種意義上來說，這是在做單元測試的工作，只是不夠專業，不妨將其按照單元測試的正規流程來寫。“效果”主要包含兩個方面，直接指標包括單元測試的通過率、覆蓋率、用例的情況，間接指標是單元測試之後 bug 的總體趨勢，以及 bug 率是否降低。國內企業非常看重指標，甚至到了一種畸形的地步，特別申明一下。如果要做單元測試，千萬不要把單元測試的覆蓋率當作最重要的指標，或者要求單元測試的覆蓋率一定要達到 80% 或者90%，這絕對不行。這麼做單元測試就成了一個走流程、走形式的過場了。另外單元測試目的是驗證功能模組的正確性。尤其是對於複雜功能驗證，特別簡單的功能沒有必要去覆蓋，所以不要去追求高覆蓋率。
7、UI 測試
最後是 UI 測試，它分為如圖 11 所示的幾個平臺，從平臺上來說，分為 App 平臺、web（比如 BS 架構的 web 平臺）、桌面平臺（不光包括 PC 機，硬體終端、上位機其實都屬於桌面端）。另外的，UI 測試在類別上主要分為兩類，一類是邏輯，指的就是介面上的操作流程順序和功能是否正確。這一類建議大家一定要自動化大於手動，因為很多傳統企業在沒有開展自動化測試工具的時候都是靠手工，那麼自動化就可以發揮它的優勢，代替大量的重複操作。另一個類別就是視覺，很多企業在驗證這類 UI 的時候會去看字型、字號、文案、效果等，我反而覺得這部分最好手動，不用大張旗鼓地自動化，因為自動化的成本較大，收益比較低。我認為完全沒必要做 OCR 、摳文字、識別、判斷文案，掃一眼即可。把 UI 測試放在最後也是因為它的條件，這裡我列舉了十個條件，這也是業內廣泛認可的條件，在這十個條件滿足的情況下，就可以開展 UI 測試，如果這十個條件不是特別滿足，就沒有必要做了。
■圖 11
從這個流程上來說，UI 測試跟其他的測試其實沒有大的區別，執行的時候會有兩種模式：第一種是以 GUI 模式執行，就是帶 UI 的模式去做自動化測試。這種情況要專機專用，比如有一個上位機，將這個上位機帶著硬體一起搬過來作為測試的專用機，然後自動化測試指令碼在這臺專用的機器上執行，這樣執行的時候就不可以做其他的操作，因為 GUI 獨佔了。大部分 app 和桌面平臺的自動化UI 測試可能都是採用這樣的方式。
另一種模式就是 headless，headless 是通過無 UI 的模式執行軟體的測試，它主要是在 web 的 UI 測試中使用，比如基於 Chrome 瀏覽器的能力。像 selenium，它可以實現 headless 的無 UI 的模式，在容器執行，優點是可以併發，並且效率、效能都比專機專用要高得多。UI 測試的流程方式與剛才提到的介面測試、效能測試都差不多。
03問答環節
1、創業公司如何配置專門的測試團隊？
首先還是看產品，在開始的孵化階段，基本上沒有專業的測試人員或者由開發人員兼職，小團隊的測試基本上是以兼職為主，等專案做出一些眉目，可以作為長期發展的專案時，就可以建設團隊，不斷配備人員。對於我經歷過的創業團隊來說，大部分情況是最初的開發測試人員配比為 4 : 1 或者 5 : 1，測試人員相對來說數量是不夠的。在這樣的情況下，不適合大張旗鼓地去做工具、流程方面的工作，等整個團隊的人數超過十個人或者產品非常穩定了，再增加測試人員，這時就可以開展敏捷測試、自動化測試了。有些公司可能為了降低成本還會引入一些外包資源，就是通過外包人員來做手動測試，之後再由核心人員來做自動化，這些核心人員慢慢往測試開發的方向轉。
2、邏輯經常變動的情況下維護成本很大，此時要怎麼做自動化？
邏輯經常變的情況建議就不要再做自動化了，因為變化太快，在穩定之後再補充做自動化反而合適。經常變的情況我認為還是用純手工的方式比較合適，因為作為初創型的企業，一切還是以簡單效率為主，沒有必要追求完美和標準，這對企業來說不是好事。
3、單獨的效能測試在什麼時機切入比較合適？
在產品設計之初，產品的效能其實就是產品的一個指標，如果產品面向的是企業內部，有幾十人使用，從某種意義上來說效能測試沒有那麼重要。而電商平臺這種 2C 的產品，有數千人甚至數十萬人使用，一定要帶著效能指標。這種情況則越早開展越好，可以階段性地開展，千萬不要等上線前再開展，如果上線前再開展，一旦發現了問題，再去解決效能問題的成本是非常大的。如果採用敏捷的方式，兩週一個迭代，那麼就兩週測一輪，提早解決問題，如果是傳統的開發模式，比如六個月的專案，那麼至少每個月測一輪。
活動預告
7 月 16 日下午，聲網開發者創業講堂 • 第 4 期將以「創業團隊如何保障產品業務的安全合規？」為題，邀請環信、遊族、白山雲三家優秀企業的技術專家為大家帶來精彩的分享。
心動不如行動，趕快掃描二維碼或者點選此處報名吧！
