作者 | 顧況

出品 | 騰訊云開發(fā)者

最近兩年，互聯(lián)網大廠的招聘中，測試工程師崗位似乎顯著減少。在騰訊內部，隨著一些 BG 的研效改革 逐漸深入，測試工程師這個崗位開始逐漸減少。似乎正在印證一個現(xiàn)象：測試崗位的未來已經不那么樂觀？

但軟件測試伴隨著軟件行業(yè)的出現(xiàn)經過了幾十年的進化，花了很多時間和汗水才走到今天，測試這個領域是不會消失的。不少人都議論過崗位和角色的消失是否合理，一般都分成兩派，一派認為測試工程師是獨立且專業(yè)的崗位應該保留，合理縮減比例；另外一派認為軟件測試領域并不復雜，覺得自己對于測試和自動化測試已經非常熟悉，完全可以勝任。

不管你屬于哪一派，首先要熟悉軟件測試才能更有發(fā)言權。熟悉是個模糊的說法，我們可以思考一個簡單的問題，測試自動化和自動化測試這兩個名詞有什么區(qū)別？如果區(qū)分不出來或者沒有概念的話，這篇文章非常適合你，這是專門寫給開發(fā)的測試漫談。

軟件測試發(fā)展史

軟件測試這件事本身就伴隨著計算機的出現(xiàn)而出現(xiàn)，并且持續(xù)保持著演進，但在我的身邊特別是一些改革較為激進的 BG，這種演進成為了噩夢的開始。逐漸發(fā)量化的測試工程師投入導致產品質量逐漸下滑，為了規(guī)避政治不正確的測試兜底而自裁系統(tǒng)測試導致缺陷滿天飛。有意思的是，結果數據也從事實上證明了這一點，測試開發(fā)比越低的項目，質量和口碑就越不堪，故障越來越頻繁，質量差到讓用戶逐漸麻木。

有些樂于嘗試的開發(fā)，積極擁抱變化，實踐 TDD，關注覆蓋率，但結果工作越來越累，任務越來越 delay，產品今天說老板中午吃飯?zhí)崃藗€甚好的建議你趕緊改改，項目經理明天說我們重新調整了一下優(yōu)先級你先做另外一個需求，你想哭但哭不出來，甚至覺得 TDD 是 Tech Driven Dead 的縮寫。更離譜的是某天連一位在平行世界早已被你捅了100刀的產品都忍不住站出來振臂高呼，別再瞎xx搞啦，再搞項目就要黃啦。所以軟件測試的演進到底是怎么回事，是不符合國情，比如硅谷工時短收入高，還是文化所限，比如硅谷技術至上產品靠邊站，且讓我們往下聊。

1.1 面向調試期（Debugging period）

參考軟件測試大師Hetzel 和 Dave Gelprin 可以將測試劃分為五個重要的時代。

第一次出現(xiàn)術語“Bug”和“Debugging”的故事大家應該都在課本里學過，1947年，哈佛大學科學家 Grace Murray 在Mark II 計算機中檢測到一只飛蛾卡在了繼電器中，導致繼電器接觸不良。她描述這起事件時將飛蛾稱為導致缺陷的“Bug”，并將消除缺陷的行為稱“Debugging”。

當時，因為計算機的發(fā)展主要還集中在硬件設備的發(fā)展商，所以測試也相應的集中在硬件上，而且硬件的可靠性對于軟件的正常運行至關重要，稍有不慎便是災難（可能跟當時的存儲條件有關，還沒有持久性存儲技術）。這個階段的測試其實就是調試，沒有任何區(qū)別，也沒有所謂的測試人員之分，所執(zhí)行的測試僅具有糾正性質，通過采取某些措施以使程序能正常工作。

1949年，艾倫·圖靈 (Alan Turing) 寫了他的第一篇關于對程序進行調試的文章，緊接著在1950年，他在“圖靈測試“一文中解釋了軟件必須如何適應項目要求以及機器或參考系統(tǒng)（人類邏輯）的行為必須無法區(qū)分的情況。簡而言之就是軟件必須經過人類邏輯的驗證，讓機器執(zhí)行結果和人類預期相符。

1.2 演示期（Demonstration period）

1957年，Charles Baker 進一步且系統(tǒng)性的解釋了開發(fā)測試的必要性，他對 Dan McCracken 所著的 Digital Computer Programming 一書的評論中將程序測試與調試區(qū)分開來，認為兩者的區(qū)別在于確保軟件滿足預先設計的要求（測試）以及程序的功能（調試）。

在這個時期，測試開始作為一項單獨的活動進行，軟件測試的主要目標是確保滿足軟件需求。例如，需求是“QQ 的登錄狀態(tài)有7種”。測試人員會確保只展示 7種狀態(tài)。

隨著計算機軟件的蓬勃發(fā)展，應用程序的開發(fā)變得越來越復雜，越來越昂貴，成本也越來越高，解決軟件缺陷的成本明顯影響了項目的盈利能力，因此測試開始變得極為重要。隨之而來的是，軟件測試這個新領域正在被逐漸重視，更多的從業(yè)人員開始關注并投入進來。這個階段對于軟件測試的關注，主要體現(xiàn)在測試的數量和質量，軟件產品的質量第一次開始與測試結果關聯(lián)。逐漸的，軟件開發(fā)領域，細分出了軟件測試領域。

1.3 破壞導向期（Destruction period）

“軟件測試是為了發(fā)現(xiàn)錯誤而運行程序的過程”，1979年，Glenford J. Myers 從根本上改變了軟件測試這個行為的定義。

Myers 擔心的是，如果軟件測試用來追求證明程序是合格的這個目標時，人們可能會下意識地選擇導致程序失敗的可能性較低的測試數據，因為這樣更容易接近和達成目標。而如果目標是證明程序有缺陷，我們的測試數據將更有可能檢測到它們，我們將在測試中獲得更多的收獲，從而推動軟件質量的提升。

“成功的測試用例是檢測到尚未發(fā)現(xiàn)的錯誤的測試用例”，從此，軟件測試被重新定義，測試主要為了嘗試證明程序無法正常工作，從而幫助發(fā)現(xiàn)軟件質量的問題，并推動質量提升。這與之前的定義和工作方式相反，當這個定義被廣泛認同后，軟件開發(fā)領域逐漸產生了新的測試和分析技術，軟件測試領域真正的開始嶄露頭角。

1.4 面向評估期（Evaluation period）

從1983年到1987年，軟件測試的重點是評估和衡量軟件的質量。測試提高了對軟件工作方式的信心指數，大中型軟件沒有得到充分測試的情況下是不允許發(fā)布的，Winston Royce 提出的“瀑布模型”在這個時期幾乎是唯一被廣泛采用的軟件開發(fā)模型，模型中要求測試人員在下游進行測試，直到達到可接受的點，檢測到的錯誤數量減少，否則將無法進入到下一個環(huán)節(jié)。

自此測試階段被認為是軟件產品研發(fā)過程中不可或缺的階段，如工業(yè)領域一般，QA 開始進入到軟件開發(fā)團隊，測試結果決定了產品是否達到發(fā)布標準。相應的為了提高這個階段的研發(fā)效率，一些自動化測試的工具逐漸出現(xiàn)。當年的軟件開發(fā)領域不像工業(yè)領域可以靠堆積大量的人力去降低耗時，人才是十分稀缺的，所以提效工具自然而然的就被醞釀了出來。

1.5 預防期（Prevention period）

1988年 William Hetzel 出版了“軟件測試的成長”一書，他將測試按規(guī)劃、設計、構建、維護和執(zhí)行這幾個研發(fā)環(huán)節(jié)做了區(qū)分，不同的環(huán)節(jié)測試的行為和目的不同。顯著的變化是從產品規(guī)劃階段就涉及到了測試行為，這個階段的測試更多的是針對產品方案進行測試，起到提前預防的作用，有點類似我們的需求和用例評審。

測試所起到的作用更加廣泛，不僅需要證明軟件符合預期，還要嘗試發(fā)現(xiàn)更多的故障，并且還要嘗試預防缺陷。在這個時代，識別測試技術是關鍵。20 世紀的最后十年也出現(xiàn)了探索性測試，測試人員探索并深入了解軟件以試圖發(fā)現(xiàn)更多錯誤。再往后測試驅動開發(fā) (TDD) 和行為驅動開發(fā) (BDD) 等新測試概念興起，也是試圖更早的起到預防的作用。啰嗦一句，可能不少年輕人對于軟件測試的這個時間線會覺得跟我們的認知有些脫節(jié)，主要是因為我們國家軟件行業(yè)起步較晚，如果把這個時間線加上10-20年，并且把每個時期壓縮，基本上就能對齊我們國內的軟件業(yè)發(fā)展節(jié)奏了。

歷史告訴我們軟件測試是基于對軟件質量要求越來越高而形成的特定領域，又因為某個時期的大型軟件對質量有極高的重視度，催生了專職且專業(yè)的軟件測試工程師這個角色和崗位，但一些中小型特別是start up公司，他們并不會設立專職的軟件測試工程師，但別搞混淆了，沒有測試工程師不代表他們不做軟件測試。所以我們可以嘗試達成概念上的一致，軟件測試這個環(huán)節(jié)和行為是不可或缺的，軟件測試工程師的角色則根據公司和產品定位會有不同的設定。

縱觀軟件測試發(fā)展史，如果我們把整個開發(fā)階段想象成一條有限的線，從需求規(guī)劃（requirement）到產品上線，我們會看到測試階段是如何向左移動的：它最初是在產品完成階段的活動，后來開始在開發(fā)中后期活動，再后來更是提前到了需求規(guī)劃階段，這種現(xiàn)象被稱之為測試左移。所以你會發(fā)現(xiàn)，我們近兩年大力提倡測試左移非常符合軟件發(fā)展歷史規(guī)律。所以接下來我們直接聊「測試左移」，一個張口就來，卻沒有背普遍深入理解的概念。

測試左移（Testing shift left）

眾所周知，缺陷越晚在生命周期中被發(fā)現(xiàn)，修復起來就越困難，成本也越高。整個項目的風險和壓力時常在瀑布模型下層層傳遞最后壓在了測試人員的頭上，因此軟件測試社區(qū)中近些年最重要和最廣泛討論的趨勢之一便是左移測試，試圖打破這種局面，尋找更平衡更有效的方法保障質量。

2.1 怎么理解左移

測試左移本質上意味著“經常測試，并盡早開始”。但是為什么它被稱為“左”呢？聽上去容易令人困擾但很好理解，我們通常習慣從左到右閱讀（除了阿拉伯、希伯來和意第緒語等少數語言），所以如果我們要表示一個連續(xù)的階段，描述方式會從最左邊開始向右，瀑布模型中的階段可以表示如下：

Requirement →
      Design →
        Implementation →
            Verification →
                  Maintenance 

驗證階段（通常就是測試活動）是倒數第二個階段，如果我們想把測試活動提前到研發(fā)階段更早期開始介入，則需要把 Verification 階段向左側移動，于是社區(qū)將這樣的趨勢稱之為左移。

然而，不要誤解測試左移提倡的測試是一個離散的階段，只放在開始階段，而非結束階段。因為在真正的軟件敏捷開發(fā)中，不應該有階段，而是更早的開始關注質量和介入測試，是在短的迭代周期中發(fā)生的連續(xù)活動。

2.2 為什么要左移

幾十年來，無數大型項目證明了瀑布模型會導致缺陷通常在生命周期后期被發(fā)現(xiàn)，這種工作模式下，時間久了就會對這個軟件項目造成巨大的傷害：

1. 許多需求、架構和設計缺陷直到在它們的實現(xiàn)上浪費了大量的時間后才被發(fā)現(xiàn)和修復。

2. 代碼和功能越堆越多，調試（包括識別、定位、修復和回歸測試缺陷）變得更加困難。

3. 封裝使得執(zhí)行白盒測試和在測試期間實現(xiàn)高水平代碼覆蓋率變得更加困難。

4. 修復缺陷的時間比開發(fā)新功能的時間更多，項目可能會嘗試犧牲質量，這會加劇技術債的產生，如果不加以管控，可能會使項目沉沒。

5. 如果為了提升質量而放慢項目節(jié)奏，項目進度將會成為災難，因為開發(fā)們將會面臨著改不完的bug，做不完的需求變更。

造成這上面一系列問題的原因在于軟件開發(fā)項目中，項目成員總是對質量保證有不同的對待，他們承擔著不同的角色、擁有不同的職責、定義了不同的工作描述和以及不同的領導。

我們在工作中，特別是在騰訊的傳統(tǒng)項目管理風格下，經常會碰到以下場景：

1. 測試人員時常處于高壓狀態(tài)，一方面要為項目進度承擔風險，一方面要為項目質量承擔主要責任，這樣很容易導致測試環(huán)節(jié)的執(zhí)行效果變形。

2. 開發(fā)人員、產品人員和測試人員長期保持對立狀態(tài)，測試本著工作職責要保證最終產品的質量，會嚴格把控產品和開發(fā)的輸出，但開發(fā)有時會將問題歸咎到產品，而產品又會將矛頭指向開發(fā)，當開發(fā)和產品達成一致時又會將矛頭指向測試。

3. 測試環(huán)節(jié)的完成度和效果，幾乎完全依賴當前這個測試執(zhí)行者的個人能力和經驗，如果遇到能力不足，或工作狀態(tài)不佳的情況，最終輸出的產品質量可能會造成災難。

但是，如果我們將質量保證和開發(fā)人員以及團隊其他所有角色掛鉤，quality assurance is everyone’s responsibility，作為一個項目團隊每個人都要為質量負責，共同的目的是生產最終適合客戶的產品，我們很大幾率會得到以下效果：

• 在軟件開發(fā)生命周期的早期發(fā)現(xiàn)錯誤，并且能有效降低解決錯誤的成本。

• 獲得更高質量的產品，意味著打更少的 patch，改更少的 bug，更少的加班。

• 產品發(fā)布預期會更加可控，降低每個人發(fā)版本的焦慮。

• 極少技術債，代碼庫一直保持高質量維護狀態(tài)。

因為質量保障人人有責，所以我們提倡質量左移。又因為我們希望推動質量左移，所以人人都應該參與質量保障。

2.3 如何開展左移

如上面所說，測試左移是要讓開發(fā)參與到質量保障中來，將測試行為推向編碼階段。一個很好的采用方法是測試驅動開發(fā) ( TDD )， 它首先根據程序應有的邏輯來實現(xiàn)單元測試，然后編寫使測試正常工作的代碼。這種做法的目的是在開始寫代碼之前有一個清晰的結構，一個更健壯和高效的代碼（包括測試代碼），對于后續(xù)的迭代更具有持續(xù)性（持續(xù)集成，持續(xù)測試）。

還有一種工具化的測試左移的方法是使用靜態(tài)分析工具。靜態(tài)分析工具有助于識別參數類型或接口使用不當的問題，將這類工具集成在 IDE 里可以更早更快的發(fā)現(xiàn)問題，比如大家熟知的 ESLint 便一個非常著名的靜態(tài)代碼檢查工具。

此外，行為驅動開發(fā) (BDD) 也可以加速測試左移的開展。BDD 定義了一種所有利益相關者都可以理解的通用設計語言，例如產品經理、開發(fā)人員和其他角色。因此，它使所有相關利益相關者能夠同時處理相同的產品功能，從而加快團隊的敏捷性。特別要注意的是，這種模式較好地卷入了產品人員提前關注質量，將左移進一步前置，以將需求結構化的形式來驗證需求質量。試想一下，如果一個 scenario 寫出來就覺得不對勁，是不是應該先看看需求哪里有問題，而不是急于去實現(xiàn)它。所以換句話說，BDD 可以促進跨團隊協(xié)作，同時縮短了功能交付時間。

不過我們應該要理解的是測試左移的頂層思想，目標上希望盡可能早的發(fā)現(xiàn)甚至規(guī)避問題，角色上需要全員為質量負責，執(zhí)行上是要將軟件測試主流的冰淇凌模式轉變?yōu)榻鹱炙Ｊ剑?/strong>基于這個思想之下具體到團隊該怎么做，完全可以因地制宜，比如 BDD 和 TDD 本身并無沖突，甚至還可以嘗試 BDD+TDD 的模式，另外 TDD 更適合無用戶交互的項目比如純后臺，BDD 則更適合重交互的項目如客戶端和前端，還有 TDD 的進化版本 ATDD 是一個更重用戶體驗的模式。

2.4 測試左移的局限性

推行測試左移，通過 TDD、BDD 和 ATDD 框架，研發(fā)團隊可以利用清晰的流程來捕獲需求并在低級別（單元測試）和高級別（驗收測試）進行測試，以確保應用程序的質量，并且可以持續(xù)的享受穩(wěn)定可靠的測試代碼帶來的收益。然而，在現(xiàn)實世界中，我們面臨著許多壓力——競爭、時間、技能短缺——這使得這一切都難以成為現(xiàn)實，或者在執(zhí)行過程中產生各種各樣的技術變形，最終實現(xiàn)效果并沒有達到預期。

舉個充分具有騰訊特色的例子：開發(fā)A 在很好的踐行 TDD 開發(fā)，但某天產品說今天上午開會老板對一個特性表示了不同意見，產品們中午飯都沒吃開會討論出了調整方案，希望明天就能上線，時間緊迫來不及廢話，就拿著這張照片開發(fā)吧（會議室白板拍下來的方案），這時開發(fā)A 該如何保障質量？可能有人說這太特色了，場景反而沒那么多，那再舉個常見的例子：Android 50/iOS 80要發(fā)布了，開發(fā)B 提前拿到了開發(fā)者版本要針對新系統(tǒng)對 APP 做一次全面體驗和質量排查，發(fā)現(xiàn)了不少嚴重影響用戶使用的問題，大部分是兼容性問題可以直接優(yōu)化，也有一些是新功能產生的體驗問題需要產品給方案，但臨新系統(tǒng)發(fā)布不到一周時間了，這時開發(fā)B該如何保障這波更新的質量？

受時間和資源所限，我們只能將質量放在需求交付之后再進行把控，以希望快速發(fā)現(xiàn)和修復，避免產生更大范圍和更嚴重的影響，這就涉及到了下一個話題，測試右移。

測試右移（Testing shift right）

3.1 怎么理解右移

如果在產品開發(fā)周期的早期進行測試意味著向左移動，那么稍后進行就必須向右移動。這就是測試右移的意義所在——在產品發(fā)布后進行測試。按照測試左移的概念，我們將在生產環(huán)境進行的測試行為和質量保障稱之為測試右移。

在去年的一項由 Capgemini 和 Broadcom 聯(lián)合進行的問卷調查中，生產中的測試被列為目前實施或計劃中的首要實踐。此外，39% 的受訪者提到使用運營分析來確定或優(yōu)化測試覆蓋率。簡單來說就是越來越多的軟件企業(yè)開始重視生產環(huán)境的測試驗證，而非一味的追求前置的保障。

當被問及客戶如何衡量持續(xù)測試流程的有效性時，利用生產數據和利用用戶反饋分別排名第一和第二。

有些專業(yè)人士將測試右移劃到SRE領域，也有一些DevOps概念將之稱之為TestOps，強調測試與運維之間的緊密結合，甚至還有一種說法叫運維左移，叫什么不重要，重要的是這說明測試右移引起了足夠的重視，值得關注和嘗試。

3.2 為什么要右移

先說第一個理由，創(chuàng)建質量門（Quality Gate）是開始左移運動的一個行之有效且簡單的方法。大多數公司都有某種類型的生產質量門，最簡單的形式是“所有測試用例的 X% 必須通過，并且關鍵優(yōu)先級缺陷少于 Y。” ，相信各位都經歷過或正在經歷這個階段。更DevOps的玩法則是流水線質量紅線，通過持續(xù)測試以及紅線來攔截潛在的質量問題。

但是如測試左移局限性章節(jié)所述，有些時候我們會收到來自各方的影響甚至干擾，導致技術動作變形，質量門也好流水線紅線也好，時常會被打破和踐踏，前幾年作為測試工程師我最大的噩夢便是來自項目經理的一句「我們再來review下bug單」......下圖是一張常見的影響和可能性對缺陷優(yōu)先級的視覺描述。低影響 + 低可能性 = 低優(yōu)先級（P2）；低影響 + 中等可能性 = 低優(yōu)先級（P2）；低影響 + 高可能性 = 中優(yōu)先級（P1）；中等影響 + 中等可能性 = 中優(yōu)先級（P1）；中等影響 + 高可能性 = 高優(yōu)先級（P0）；高影響 + 高可能性 = 關鍵優(yōu)先級（P00）。善于發(fā)明創(chuàng)造的鵝廠項目經理可能還會發(fā)明P000，甚至P0000來讓更多缺陷看上去優(yōu)先級沒有那么高，從而放過問題盡快發(fā)布。

于是在缺乏適當的質量心態(tài)的團隊或者場景下，第一道門被打破后，必須建立起第二道門來對質量進行把控，否則千里之堤將毀于蟻穴，每一次的缺陷漏出（不論是有意還是無意）都會對項目的未來造成不同程度的影響甚至傷害。

這第二道門便是測試右移（也可以叫做質量右移），當缺陷在并非我們預期的階段漏出了，我們應該具備足夠的能力和手段（工具）發(fā)現(xiàn)并修復，并且確保未來不會再次漏出。

再說第二個理由，研發(fā)團隊提高速度的最有效方法之一是將質量目標左移，也就是測試左移。實際情況，我們也正在推動早期測試的各種基礎設施和管道，以最終減少新增代碼發(fā)布到生產并且質量穩(wěn)定的時間。前面我們也探討了有多種測試可以輕松地將測試行為向左移動，例如單元測試。但有時候有些事情超出了傳統(tǒng)測試工程師的覆蓋范疇， 例如服務器可能會停機，又如一些熱點事件導致訪問激增，性能和可用性問題隨時可能爆發(fā)。雖然部署到測試環(huán)境可以模擬與生產相當的環(huán)境，但事實證明模擬畢竟是模擬，不是完全替代品。

生產環(huán)境的全面廣度和多樣性很難在測試環(huán)境中復制，用戶流量的真實場景也很難模擬。即使我們根據以往的案例構建并優(yōu)化了測試手段，隨著生產需求的不斷發(fā)展，維護這些配置文件和行為也成為一項重大責任。此外，生產環(huán)境也在不斷變化。它從來都不是一成不變的，即使我們的業(yè)務沒有變化，它下面的一切也在不斷變化，比如它所依賴的基礎設施。因此，經過一段時間后，團隊發(fā)現(xiàn)某些類型的測試只能也必須要在生產環(huán)境中進行。

兩個理由其實只是從不同角度說了同一件事，百分百的可靠性/質量通常是一個不切實際的目標。我們從 Google 的 SRE 哲學中學到的一個關鍵原則是，100% 的可靠性/完美質量的產品不僅不切實際，而且通常成本太高而無法實現(xiàn)。SRE 建立了服務水平目標(SLO) 和風險預算的概念，以量化生產系統(tǒng)中可接受的風險容忍度，同樣的原則也適用于測試和整體質量。Netflix 在這方面我個人覺得已經做到了業(yè)界極致，他們在2019年O'Reilly SACon 上名為《Anatomy of Testing in Production》的分享介紹了 Netflix 如何演進到在生產環(huán)境做測試的全歷程，內容非常清晰明了，我就不在本文越俎代庖湊字數了。

3.3 如何開展右移

關于測試右移，我的經驗并不多，還在邊學習邊實踐，很多事物都超出了我以前的經驗范疇，涉及到很多新名詞、新角色和新技術，我用我有限的知識幫大家捋一捋，開闊下思路。

數據分析能力：由于大多數生產數據都是大量、多樣且通常是臨時的，因此我們必須進行數據分析，以便快速從這些數據中獲得洞察力，并與其他數據集進行關聯(lián)以識別操作。高級分析技能（例如預測分析或機器學習）對于預測事件（例如發(fā)布質量）也是必不可少的。雖然這些分析技能在運營領域都是稀松平常的事物，不過對于開發(fā)人員和測試人員來說相對較新。

CX 測試能力(Customer Experience)：CX 現(xiàn)在被認為是衡量生產質量的關鍵指標。如今常見的 CX 測試包括 A/B test、金絲雀測試以及眾測。與其他運營數據一樣，CX 數據通常也非常龐大且通常是非結構化的。雖然理論上來說 CX 應該是運營團隊關注的事情，但如果要在生產環(huán)境做質量保障，則需要獲得足夠的技能來從 CX 流程和數據中收集數據并提升洞察力。舉個例子，現(xiàn)在騰訊文檔的很多生產缺陷反饋都來自于用戶反饋，然后其中參雜著體驗問題和功能缺陷，開發(fā)人員不得不對這些反饋做一道手工過濾，以便將有效的質量問題轉入研發(fā)計劃，這顯然是一種低效的做法。

監(jiān)控和操作能力(Ops)：了解監(jiān)控原理（例如創(chuàng)建、測試和部署監(jiān)控器以及使用監(jiān)控器中的數據）是測試右移的一項關鍵技能。同樣，熟悉 oncall 流程，運營手冊（事件、故障、警報、MTBF、MMTR、配置定義等）也是非常必要的。

可靠性技能：越來越多的項目開始組建 SRE 團隊，說明可靠性已經被意識到是一個非常關鍵的質量屬性。SRE 涉及到測試的包括混沌/彈性測試、部署和回滾測試以及配置測試。

新工具的支持：對于測試右移來說，工具的支持是不可或缺的，沒有合適的工具就無法執(zhí)行測試右移，這其中包括監(jiān)控、數據分析（針對生產和 CX 數據）、CX 測試（例如 A/B 和金絲雀測試）和可靠性測試等很多領域的工具。

復盤能力：當問題無法避免的在生產環(huán)境被放大，我們除了第一時間修復問題外，還需要對問題進行復盤，找出根因，想辦法從源頭或者更早的環(huán)節(jié)發(fā)現(xiàn)和攔截問題，甚至從最早的設計階段就可以避免它，不要浪費每一個被漏出去的問題，「Now, what did we learn today?」。

自動化測試 VS 測試自動化

如果你有耐心認真看到了這里，恭喜你已經開始對測試領域產生了興趣，那么我們接著聊點更「測試」的東西，也就是開頭提到的自動化測試和測試自動化的區(qū)別。

不管是前面說到的測試左移還是測試右移，都繞不過自動化測試這個詞，那么「測試自動化」又到底是個什么概念？作為開發(fā)我需要理解這個東西嗎？是不是測試領域的故弄玄虛？它們是相關的概念，但每一個都有非常具體的含義和目的。在簡單聊過測試左移和右移的重要性之后，是時候定義這兩個概念，闡明它們之間的不同和相似之處，因為他們的區(qū)別真的很重要。

先說自動化測試，“自動化測試”只是自動運行一組特定的測試并驗證其結果的過程，而不是手動進行。當我在機器上跑運行單元測試時，我正在做的是自動化測試。當有人MR新代碼時，CI 流水線自動執(zhí)行單元和集成測試，它也在做自動化測試。接著說測試自動化，“測試自動化”解釋起來可能有點棘手，雖然自動化測試=將測試驗證通過自動化執(zhí)行，但“測試自動化”是一個更廣泛的概念。它是指將管理組織內部不同測試需求以及行為的整個過程完全自動化。

如果把自動化測試比作流水線（Pipeline），那測試自動化則是工作流（Workflow）。現(xiàn)實情況自動化測試確實更多的是以 pipeline 的形式運用在 CI/CD 中，而測試自動化則是通過 worklfow 的形式對研發(fā)流程中涉及到測試行為進行編排，使這些環(huán)節(jié)可以自動串聯(lián)和執(zhí)行，而每個環(huán)節(jié)是用自動化測試還是其他測試工具來實現(xiàn)，都是測試自動化需要考慮的范圍。

4.1 自動化測試

貫徹自動化測試團隊中收益最大的角色是誰？在我看來，答案很明確：開發(fā)人員，but why？為了方便開發(fā)同學們聚焦，讓我們暫時專注于單元測試。其實“單元測試”并不是一個很好的名字，對于初學者來說，他們可能會被帶偏認為覆蓋了某個函數就叫單元測試或者代碼覆蓋率達到 X%就叫好的單元測試。真正意義上的單元測試要考慮的東西很多，或者說單元測試要承載的功能很多：

• 提升代碼質量，它可以幫助開發(fā)人員在進行集成測試之前識別單元中可能存在的最小缺陷。

• 提升調試性，可測試性一定程度上等于調試性（capability of being (easily) debugged）。

• 功能文檔，想要了解代碼邏輯的開發(fā)人員可以通過閱讀每個單獨模塊的單測輕松了解系統(tǒng)。

• 開發(fā)效率，因為單元測試天然是自動化測試的緣故，可以快速變更快速驗證快速迭代。

• 提升信心，重構代碼和更新引用庫變得更加容易，不論是擔心改動對他人的影響，還是他人的改動對自己的影響，在進入下一階段之前，優(yōu)秀的單元測試意味著該單元在與其他模塊集成之前已被證明處于正常工作狀態(tài)。

單元測試是由程序員編寫的，對于程序員來說，是為了“證明”，至少在一定程度上有信心，一段給定的代碼確實做了它應該做的事情。截至目前，自己驗證自己產生的代碼，聽上去很合理，收益最大的人自然也是自己或其他協(xié)同開發(fā)的人，即開發(fā)人員。

我們再將“可執(zhí)行規(guī)范”的定義擴展到集成測試。集成測試簡單來說就是將測試范圍擴大到系統(tǒng)級別的功能驗證，并且使用真實的數據庫/文件系統(tǒng)/賬號等而非模擬/存根。集成測試要考慮的東西是什么，或者說集成測試要承載的功能有哪些？我就不再展開細說了，聰明的你一定已經結合上面單元測試的結論有了自己的答案。

最后我們將“可執(zhí)行規(guī)范”的定義擴展到端到端測試，已無需多言，答案似乎很清楚：項目中“自動化測試”的主要受益者是開發(fā)人員。或者，換句話說：自動化測試是實現(xiàn)開發(fā)人員理性的工具（曾經的你「一把梭」過嗎，DDDD），測試代碼和業(yè)務代碼相輔相成，它允許開發(fā)人員無所畏懼地重構，因為他們知道有一個可靠的安全網，分別在不同層面以測試套件的形式出現(xiàn)，如果他們破壞了什么，都會被發(fā)現(xiàn)并被攔截。

看到這里如果你還認為自動化測試是為了節(jié)約測試工程師人力，那......是在下認輸了。

4.2 測試自動化

貫徹測試自動化，團隊中誰會從中受益最大？這個答案可能有爭議，但在我看來最大受益人依然是開發(fā)人員。

在傳統(tǒng)的瀑布模式的組織中，測試只不過是整個周期中的另一個階段。測試階段往往發(fā)生在周期結束或接近結束時。我們在前面的測試左移中已經討論的足夠清晰，這樣做實在太晚了，反饋周期變慢會降低整個測試策略的實用性和效率。如今，推行 DevOps 的公司正朝著全面 CI/CD 的世界邁進，他們不能永遠等待測試的反饋，測試本身必須是連續(xù)的（continuous testing），這樣才能在開發(fā)的所有階段確保質量，不然 CI/CD 很難完整。

在這種情況下，自動化測試是可以派上用場，但這只解決了單點的測試行為被自動化執(zhí)行的問題。如果要將測試完全且徹底的融入到 CI/CD 中，這必須依賴更完整的測試工具鏈，比如測試環(huán)境、測試數據（賬號、素材等）的自動生成和管理；又比如通過 IDE 實現(xiàn)本地開發(fā)遠程執(zhí)行自動化測試；再比如針對一些核心業(yè)務或模塊需要設置定時任務以及風險告警；最后再提一個對自動化測試本身的運營思路，使用自動化測試本身已經比較成熟沒有難度，但在哪個階段/環(huán)節(jié)執(zhí)行，執(zhí)行哪種類型的測試任務，執(zhí)行結果是否可以作為有效的攔截依據，這些是需要花些心思的。如果前面說的這些測試域的事情不能自動化，就很難提升自動化測試的速度和一致性，也無法連續(xù)的啟動和運行測試。更惡劣的情況甚至會讓自動化測試本身變得非常困難且容易出錯，而且還很耗時，最終失去了做這件事的全部意義。這并非危言聳聽，騰訊文檔項目就正在經歷著折磨......

通過自動化管理上述測試需求，測試自動化可幫助組織在整個開發(fā)周期中將質量保持在最高標準。此外，測試自動化我認為屬于測試域，屬于研效部的事兒，而非業(yè)務自己做，他們要考慮工具的持續(xù)迭代，考慮解決通用、抽象的問題，這意味著業(yè)務的開發(fā)們可以專注于創(chuàng)建更有針對性的 testcase 并更有效的通過測試代碼來覆蓋（對，我說的就是你，刷覆蓋率的，出來挨打）。這點文檔后臺團隊做的就不錯，在我跟他們短暫的合作過程中能感受到他們在踏踏實實的寫能讓自己放心的 UT，并將工具交給更專業(yè)和專注的團隊去負責，這里要點名感謝 Testone 后臺測試工具鏈的開發(fā)同學非常接地氣的合作。

說到這里我埋個小坑，今年的 DORA state of DevOps 2021 report 又重點強調了持續(xù)測試，他們指出正在進行 DevOps 轉型的公司的持續(xù)測試能力對能否真正實現(xiàn)持續(xù)交付有著重大影響，未來我應該會輸出一些關于持續(xù)測試的內容。

4.3 我該怎么做

我在這里澄清“自動化測試”和“測試自動化”之間的混淆，并不是想爭論命名的歧義，而是概念本身確實不同。我希望給開發(fā)同學們普及更廣泛的測試概念，如果你希望你的團隊能持續(xù)以最高質量標準交付軟件，就要懂得更多。自動化測試很重要，尤其是讓開發(fā)人員有信心無畏地重構他們的代碼，毫無疑問，這有助于提高代碼質量，你已經感受到我很克制的在傳遞「自動化測試完全應該由開發(fā)人員自行完成」這個思想。但是，當你的團隊或項目開始轉向持續(xù)集成/持續(xù)部署（CI/CD）場景時，測試自動化變得至關重要，因為測試不僅要左移也要右移。除此以外還要將測試行為流程化并且盡可能自動化，質量不是一道門就可以完全把關好，而是需要層層把關，守護好自己創(chuàng)造出來的東西。當你了解了測試自動化這個更高維度的概念，你便走進了如何通向高質量產品的大門，你會發(fā)現(xiàn)質量這東西除了測試工程師，還要跟 Infra/SRE，DevOps 工程師和數據工程師等各種角色打交道和密切配合才能追求卓越，精益求精。

來自 EX 測試的寄語

筆者在騰訊做了近十年的測試工程師，很多開發(fā)人員因各種理由習慣性的將隱患甚至顯而易見的問題直接丟給下一個環(huán)節(jié)也就是測試，真正發(fā)自內心對質量和品質有意識的開發(fā)屈指可數，不過有個很有意思的現(xiàn)象是，這些鳳毛菱角的開發(fā)們現(xiàn)在都逐漸擔做起了管理工作，有的做完需求敢跟我對賭，一個 bug 一頓飯，利用我來鞭策他提升自己的開發(fā)質量；有的當 bug 輾轉多人幾個月仍未解決的時候，我就會想到把 bug 單轉給他，即便不是他負責的模塊他也會抽時間根治，并且很討厭的拉著你說一堆你一點也不想聽的分析過程；當年合作時還沒升技術高 P 的某位，質量意識之高從現(xiàn)在騰訊會議這款產品完全能體會得到。騰訊文檔的開發(fā)們我就不夸了，一來做的確實還不夠好，二來怕大家驕傲～

我在想，可能沒有天生就對質量有追求或測試能力強的開發(fā)，但一定有 owner 意識、責任心以及合作精神都很強的開發(fā)，他們重視自己所做的項目，重視自己的每一個產出，重視跟自己合作的伙伴，所以他們愿意花時間，甚至犧牲時間去保障質量。擁有這樣品質的同事，已不僅僅被局限在是一位優(yōu)秀的開發(fā)，一定會被領導認可，被放在更高的位置去影響更多人。

“在計算機存在的整個過程中，如何設計軟件以及如何開發(fā)軟件一直是一直討論的中心。沒有哪篇文章像 Frederick P. Brooks 的“No Silver Bullet”那樣成為討論的核心。然而，在他寫下這篇對知識的貢獻將近 35 年后，布魯克斯的觀察仍然正確。軟件工程是一個復雜且要求很高的領域，它給從業(yè)者帶來了許多問題，并且沒有單一的解決方案，即沒有靈丹妙藥，可以提供一種簡單的方法來減少創(chuàng)建軟件產品所需的工作。”

很多開發(fā)者覺得讓開發(fā)為質量負責，對開發(fā)們造成了很大的傷害，甚至是一種變相的壓榨。但現(xiàn)在政策和市場暗流涌動，互聯(lián)網行業(yè)風云變化，快速抓住機遇和有效保障質量之間如何平衡很難抉擇，去測試化不是銀彈，但不可否認是符合趨勢的一種為未來做人才儲備的手段。至少我們要先學會自動化測試，并接受測試左移和右移的思想，這是軟件測試發(fā)展的趨勢，再遠一些幾十年后會怎么樣我不知道，當下我們只是在嘗試走別人走過的路，僅此而已。

本文經授權轉載騰訊云開發(fā)者，如需轉載，請聯(lián)系