前情回顧：

質量內建， 稱得上VUCA時代的項目賴以生存的重要實踐。任何高速運行的項目都不應該將質量檢測作為整個工程周期的之中的一環(huán)，所以對質量內建的需求越發(fā)廣泛。作為質量保證的排頭兵--測試工程師，將付出極大的努力將“測試”這個動作轉變?yōu)椤百|量保證”這個角色，再進一步進化為“質量內建”的執(zhí)劍人。

這是個進化的過程。需要一個測試工程師付出很多時間并付諸很多實踐。接下來，我想用我的視角去介紹測試可以在質量內建上可以做的事。我將這些事分為了三類：行動，方法，準則。

行動是講述測試進行或者引導的具體的動作， 這是立竿見影的。

圖片.png

雖然我列舉出來如此多的行動， 但還完全不足以描述測試人員在質量內建工作中的實踐。

因為這些行動都是基于質量內建的方法。符合方法的行動包羅萬象， 所以如果要掌握全部的行動， 就需要掌握質量內建的方法，至于質量內建的方法， 請期待我后續(xù)的文章[狗頭]

好了， 經(jīng)過了這一波極限拉扯， 我們聊回正題：

下面， 我將給大家一一產(chǎn)出上面列出的質量內建的行動， 這些行動，是對很多項目，技術文章， 經(jīng)驗總結和最佳實踐分享的匯總，一旦落地，可以有效的增加你所在的項目的質量內建成熟度。

測試先行

在項目中，往往測試是最被忽略的， 我見過很多不成熟的項目都會將測試視為項目的一個環(huán)節(jié)， 即開發(fā)完成的某個時間段“交”給測試， 或讓測試在軟件開發(fā)某部分之后完成之后再進行投入等等。或許會發(fā)現(xiàn)， 這兩種情況都有一個隱含的邏輯，即“開發(fā)”這個活動和“測試”這個活動有明顯的時序性。

或者說，如果將測試活動的時間和開發(fā)活動的時間做一個時間軸的話， 你所在的項目是什么樣的呢？讓我們來嘗試著畫一下：

也許你的項目是這樣的

圖片.png

也許你的項目是這樣的

圖片.png

也或許你的項目是這樣的

圖片.png

如果你畫出的圖是圖3那樣的， 那么恭喜你， 有極大可能你的項目已經(jīng)處于高度的質量內建成熟度中了！

（不過也有種可能， 是你的項目測試人手不夠， 測試的人員的任務一直積壓，導致測試不停的加班，也會有這種圖出現(xiàn)）

我想大多數(shù)同學畫出的圖，都會和圖1， 圖2很像。因為我所在的項目也是這個樣子，從圖中不難看出，測試和開發(fā)的關系存在明顯的時序關系，就是測試一定是在某些開發(fā)活動以后進行的。

為了說明開發(fā)測試存在時序會引起的問題，首先引入著名的問題發(fā)現(xiàn)與修復成本曲線

圖片.png

大家可以看到，大多數(shù)缺陷都是在開發(fā)寫代碼的過程中被引入的， 單元測試可以發(fā)現(xiàn)一些問題， 但大多數(shù)問題都是在功能測試，系統(tǒng)測試（實地測試）中發(fā)現(xiàn)的。

這時的問題的修復成本要比在開發(fā)階段修復的成本已經(jīng)發(fā)生了指數(shù)級的增長， 因為這時，程序已經(jīng)形成，代碼之間的邏輯復雜度是指數(shù)級別的增長的，加上部署后的環(huán)境的復雜度，帶來了更多的定位后修復的難度，如果遇到了災難性的架構設計，難免會有“牽一發(fā)動全身”、“打地鼠”等等場景出現(xiàn)， 給整個項目組的開發(fā)和測試同學帶來無盡的傷痛。

同時根據(jù)對缺陷出現(xiàn)的根因進行分析，你會發(fā)現(xiàn)

一定程度上的缺陷都是基于對需求不理解導致的，項目中不符合需求的缺陷數(shù)量是與開發(fā)自身的素質、對業(yè)務背景的理解和需求清晰度是成反比的

所以，假如一個程序員完成了一個函數(shù)之后，在提交代碼的時候就會自動有人告訴TA，函數(shù)是否是正確的，符合業(yè)務邏輯和設計的， 這將發(fā)現(xiàn)缺陷的時間點提前了，也就是將修復缺陷成本降低了

我們來粗略的計算一下

假設一個bug在開發(fā)階段修復的成本是0.5人天， 經(jīng)過了單元測試，功能測試，集成測試，到了發(fā)布，他們的修復成本按照指數(shù)公式套入

圖片.png

我制作了一個表，描述了分別在開發(fā)， 單元測試，功能測試，集成測試，發(fā)布各個階段修復成本的預期

圖片.png

雖然這是理論值， 不難從這個n與項目周期的各個階段看出n發(fā)布后修復一個問題的成本照比開發(fā)時的差異隨著n的變化巨大。

所以從理論上縮減修復問題的成本有以下兩個途徑：

1. 盡早的發(fā)現(xiàn)問題

2. 縮減n

n是價值流從左向右移動的速度參考系數(shù)，這是DevOps領域的知識， 在這里不再贅述；接下來，我們要討論的是如何盡早的發(fā)現(xiàn)問題。

這個問題的解決方式很簡單，讓我們想象一下問題由誰來發(fā)現(xiàn)：測試工程師。如何盡早的發(fā)現(xiàn)問題：盡早介入。我們來做一個簡單的加法從而得出我們這次的主題：讓測試工程師盡早的介入

使測試在開發(fā)環(huán)節(jié)就介入的一個重要的實踐就是引入TDD，ATDD。

TDD

TDD:TDD是測試驅動開發(fā)（Test-Driven Development）的英文簡稱，是敏捷開發(fā)中的一項核心實踐和技術，也是一種設計方法論。TDD的原理是在開發(fā)功能代碼之前，先編寫單元測試用例代碼，測試代碼確定需要編寫什么產(chǎn)品代碼。TDD雖是敏捷方法的核心實踐，但不只適用于XP（Extreme Programming），同樣可以適用于其他開發(fā)方法和過程。

TDD中的測試往往是單元測試，很多項目中使用大量的測試去和業(yè)務規(guī)則進行映射， 建立代碼修改的防火墻，在代碼創(chuàng)建和修改的時候第一時間驗證了代碼的正確性。

以下是一個使用TDD構建代碼過程閉環(huán)：

圖片.png

在這個閉環(huán)中， 最重要的就是一切的開發(fā)活動都是“圍繞讓測試用例通過進行的”， 所以，在TDD的工程實踐中， 是以測試用例為核心進行開發(fā)。這與現(xiàn)在大多數(shù)項目代碼為主，測試用例為輔的模式正好相反。很多的測試用例也是開發(fā)為了滿足單元測試覆蓋率而草草了事的。我個人認為TDD是倒逼開發(fā)認真編寫測試用例的重要手段。

聊了這么多，你可能會問：測試需要干什么？測試在TDD中合適的介入，是會極大的幫助整個開發(fā)過程的， 試想如果寫測試用例和寫代碼的人是同一個開發(fā)工程師的話， 他就會有可能因為自己的主觀理解錯誤導致編寫的測試用例和代碼的錯誤，這就使得TDD失去了存在的價值。因為測試人員的水平不同， 測試能在這方面做的事情也會不太一樣：

如果測試具有開發(fā)同等的代碼水平， 可以讓測試工程師編寫測試用例，這會降低因個人對需求理解錯誤產(chǎn)生的風險，也可以提高開發(fā)編寫代碼的效率（開發(fā)可以和測試并行工作）

如果測試具有讀代碼的能力，可以讓測試參與審計開發(fā)編寫的測試用例，通過測試工程師豐富的業(yè)務經(jīng)驗和專業(yè)的業(yè)務技能來使測試用例更加的完善和準確

此外，測試人員還可以作為觀察員， 檢測各個節(jié)點，設置準入規(guī)則， 請開發(fā)人員交叉編寫測試用例，在開始開發(fā)前說明自己的對需求的理解等等非技術性的方式達到落地TDD的目的。

ATDD

這是一種在編碼開始之前將客戶帶入測試設計過程的技術。它也是一個協(xié)作實踐，用戶，測試人員和開發(fā)人員定義了自動驗收標準。 ATDD有助于確保所有項目成員準確理解需要完成和實施的內容。

圖片.png

直觀的看上去，這個大的三角形里邊包含了很多的TDD， ATDD和TDD都是編程中“以終為始” 的做法，先確定終點，然后再去向終點努力。

但ATDD的視角更高， 它是在“用戶驗收”這個角度上的觀察，所以作為測試工程師，可以確定很多用戶驗收的用例，這里推薦這樣一個時序：

圖片.png

這使得開發(fā)和測試在原有的傳統(tǒng)工程中通過改進流程達到了將測試工作提前至與開發(fā)動作開始基本相同的時間點， 作為開發(fā)的“守護進程”的角色出現(xiàn)。

好了， 這就是測試可以在質量內建中進行的一個活動： 測試先行中的TDD和ATDD的介紹， 符合測試先行的實踐有很多， 真香的有TDD和ATDD，所以著重的介紹。

在TDD和ATDD中， 實踐中的技術并不難， 困難的是消除開發(fā)同學， 項目同學和業(yè)務同學對測試定固有思考：

將測試工程師以質量保證工程師來看待，這將會是公司乃至軟件行業(yè)的一大進步。

下期預告 ：

打完這次太祖長拳，下期我們來學習測試在質量內建中的第二式：測試金字塔。這將讓測試在生成用例的過程中不再迷茫，從一開始就把測試和自動化測試這兩件事情做對，做好。