前言
老牛是資深測試專家、技術架構師。具備多年網際網路公司從業經驗以及十多年一線研發經驗。同時也是 DevOps 踐行者，近幾年兼任質量團隊的管理工作。其中，負責的某技術平臺，穩定執行兩年多，累計呼叫量超 2800 億次。
本文基於老牛在「聲網開發者創業講堂 • 第三期丨創業初期如何保障產品質量」活動中分享內容二次整理。關注公眾號「聲網開發者」，回覆關鍵詞「JT0611」即可下載活動相關 PPT 資料。
隨著微服務架構、雲端計算、容器技術的發展和普及，DevOps 在開發者中逐漸成為共識，併成為主流開發模式。但在 DevOps 快速迭代中，測試成為快速交付的一大短板，敏捷測試呼之欲出。很多人提及敏捷測試，卻鮮有人提及如何實現敏捷測試。
本文以敏捷測試催化劑為引子，闡述敏捷測試四要素及其組織管理形式，分享中小公司捉襟見肘的測試困境，初創企業如何成功落地敏捷測試的"脫困"案例，及敏捷測試未來的發展趨勢與展望。
01 敏捷測試催化劑
1、背景
與炒股一樣，軟體開發包括基本面和技術面。從基本面的角度來說，隨著軟體工程技術的發展，軟體架構和基礎設施、軟體工程文化，以及產品的競爭態勢與之共同構成軟體開發的基礎。隨著移動網際網路的發展，大家都開始遵循唯快不破思想，比拼速度。軟體工程文化也從以前的瀑布，到現在的敏捷、scrum、看板等。只有這些基礎設施和相關基本層面達到一定程度以後，才能實現業務落地。
圖 1 是對基本面的描述，隨著 DevOps 的流行，敏捷開發/CICD、微服務/容器技術/雲端計算、移動網際網路的發展、質量內建推動了敏捷測試的發展，對開發側的觸動是非常大的，提升了開發的速度。在快速迭代的過程中，測試隨之出現了很多痛點，這也是我從架構又反過來研究測試的原因，也就是希望解決測試這塊短板。
■圖 1
2、DevOps 對測試的期待
目前測試已成為快速交付的一大短板，很多公司可能每週釋出一個版本或是兩週（或一個月）進行一次迭代，隨著微服務的增加，開發快速交付後，測試如果還是沿用以前的辦法，則很難滿足需求，這個木桶效應對整個團隊的影響很大。
DevOps 要求快速有效的測試以及改進加快交付的途徑，隨著微服務和雲端計算等技術的逐漸成熟，我們可以進行動態實時質量的監控，持續的反饋機制、預防性評估等。此外，還要具備流水線環境的管理能力，因為如果部署環境依賴於開發或是運維，而此時如果有停頓，那麼就無法繼續工作了，其實測試人員完全可以自己來進行 CICD，這樣就不用等待了。
對於非功能性的質量保障來說，在上雲之後，除了功能性之外，還有與雲相關的多租戶、無狀態、彈性擴充套件，服務的無狀態，服務的治理等，測試人員也需要了解，否則無法滿足敏捷開發的需要。最後，整個團隊還需要具備敏捷基因，我認為要做敏捷測試，就應該先了解什麼是敏捷開發。
02 試如何敏捷起來
1、敏捷測試的四要素
從測試流程來說可能都是一樣的，順序是計劃-準備-執行-報告-釋出上線。敏捷的過程的本質沒變，但是它的組織過程發生了改變，也就是它的組織模式。敏捷開發中包含 scrum、看板、極限等，我認為也可以將其中的迭代、看板放到測試中。
首先，迭代是組織形式；其次，看板是為了方便監管，使工作更透明化；然後還需要自動化，比如釋出新版本要做迴歸，對於大型系統手動迴歸的工作量太大，此時就需要自動化來輔助，這是為了提升迴歸的效率；最後，對於測試的產出需要進行度量。因此，如果要實現敏捷測試，我認為必須要具備這四個要素：迭代、看板、度量、自動化。
2、敏捷測試邏輯模型
■圖 2
圖 2 所示為敏捷測試的模型，左側是看板和度量，最右側是 CICD。sprint backlog 對應 sprint case，product backblog 對應 pro case 庫。底層是流程驅動，上面是 bug 庫，針對這 bug 庫包含 To do 和 regression fixed bug，以及其他 To do(介面自動化測試、smoke caseUI 自動化測試，以及其他活動）。每次迭代就是對這些內容的重複操作。
目前市面上的很多測試管理工具都沒有迭代概念，基本沿用了 testlink，但它已經不適合敏捷模式。
我們來看看 testlink 測試的組織管理形式的侷限性。因為沒有迭代，這個抽像層，特別不方便測試執行的過程管理，一個計劃（建計劃的過程也很繁瑣）就是一個待測試用例集(或一個測試任務)，要按排 10 個人執行不同的測試任務，就要建 10 個計劃，從管理層面沒法瞭解某個迭代有多少測試任務，以及總體進度如何，相當於 testlink 一下進入細節，少了一箇中間管理的抽。
另外，團隊人員少時還好些，要是有 10 個人員，testlink 的過程管理，就相當不便，沒有全域性的視角來分配測試任務，和跟進這些任務這進度。且用例重用，也談不上，沒有可以專案用例雙向同步的產品例庫，也沒有腦圖用例等等便捷性的功能，統計分析也很弱，且測試管理不只是管用例編寫和用例執行，還有其他前後移的相關任務。
3、敏捷測試持續改進
在專案管理中遵循 PDCA 原則，包括計劃、實施、檢查和行動四個要素，對應到敏捷測試是執行-評估-改進的過程，如圖 3 所示。
■圖 3
只有具備這些過程要素，才能保障敏捷測試工作真正落地。我們的工作都在看板上執行，以實現透明化。然後通過度量進行資產質量風險的評估，包括過程的監控、結果的分析，以及團隊評估，最後再進行持續的反饋，並圍繞這個過程不斷地迭代。由此不禁要發出疑問，你的測試工具本身支援按照迭代的方式來進行管理嗎？這是一個值得思考的問題。
4、敏捷測試度量
除了常規的統計分析外，一個質量大屏值得擁有,這對促進質量意識很有幫助。
圖 4 展示了是對敏捷測試的監控，其中包括用例的情況、發生事故的情況、CICD 的情況、用例執行情況、用例執行的成本等，這裡只是一個示例。
■圖 4
03 公司（敏捷）測試的困境
1、中小公司測試亂象
中小公司測試存在很多亂象，我總結了如圖 5 所示的幾個方面：
■圖 5
很多公司沒有版本的規劃，導致需求測試開發疲於奔命，bug 根本無法收斂；隨著不斷的變更需求，測試時間一直被壓縮，測試人員由於沒有產出直接的價值而背鍋；專案沒有有效的專案管理機制，尤其中小型公司（大公司非常健全、規範），基本上專案完成得好與壞取決於人，而正常的公司應該依靠制度而不是人；專案沒有較好的質量管理體系，只是通過機械式的工具代表管理，實際上我認為工具只是用於幫助落地，應該通過管理的理念來使用或者適配工具，管理必須是有體系、有規範的，包含過程的規範、過程的監控、不斷的迭代和反饋；沒有培訓機制，團隊之間的資訊傳輸僅靠口口相傳等。
2、中小公司一線測試人員和測試管理者普遍遇到的問題
我總結了一下中小公司一線測試人員和測試管理者普遍遇到的問題，如圖 6 所示。
■圖 6
對測試人員來說，普遍遇到的問題包括沒有特別好用的平臺，影響工作效率；質量控制過程難以保證執行（雖然說公司可能都會有相關規定，但是如何保證過程是按照規定來的呢？從測試人員的角度來說，只要按照規定去做就可以了，不需要懂太多的管理性的問題，但是如果不能推行一個有效的手段，則可能到其他部門就被返回了）；測試任務不方便跟進；工作量及工作質量難以用資料來體現，這是普遍在很多公司都碰到的問題。
對測試管理者來說，普遍遇到的問題包括報告的資料維度單一，測試過程無法充分的分析（如果不能充分分析，就無法通過發現潛在的風險或是進行改進）；缺少專案的基線管理、版本迭代管理、測試任務管理等過程管理，跟進和優化測試過程都比較困難。
3、中小公司的測試困境
關於中小公司的測試困境，我總結了五個方面，如圖 7 所示。
■圖 7
4、測試陷入困境的癥結
從上面的現象由表及裡進行總結，問題的本質就是沒有質量管理體系、質量控制手段缺失以及基礎設施弱（基礎設施包括測試環境、運維環境等）/成果難以度量，這些都是主要的癥結。
04 敏捷測試落地案例分享
這裡會列舉 3 個案例。第一個是真實的案例，為什麼把它放在第一個案件重點介紹呢？因為我覺得大廠一般比較規範，那麼怎麼把這些規範放到小廠中落地和實踐？我覺得這是一個大家都應該學習的榜樣。第二個案例是創業公司，它沒有很多規範的流程，也沒有很多的資源，這裡介紹了他們如何以工具為牽引逐步落地，並總結出了自己的流程和管理規範。第三個案例介紹了起步公司，這些公司可能連老闆在內也就十一、二個人，沒有專業的 QA 但還要實現高頻的發版。
1、共同目標
不管是做敏捷測試，還是別的的測試，我認為我們共同目標就是打造專業化的測試、提升測試的效率、建設一體化的工具鏈以及提升全員的質量意識。進一步延伸，就是質量內建，包括體系-人-目標-效率。
2、大廠到小廠以頂層設計的方式實踐敏捷測試
(1) 大小廠的差異
大廠和小廠的差異如圖 8 所示，大廠沉澱多，體系也比較健全，兵強馬壯，但是部門牆比較厚，溝通成本也比較高，制度刻板不靈活，重複發明輪子多，基礎設施比較完善，團隊管理成本高。小廠基本上是拓荒的狀態，沒有太多的沉澱，體系也不健全，質量意識不強，質量測試管理也比較弱，軟硬體不齊，有一定的環境管理能力，但是平臺工具比較少或者沒打通，團隊的整體技術稍弱，有一定的測開能力，優勢是靈活、快捷，管理成本相對較低。
■圖 8
如圖 9 所示，前面分析了差異，在實施敏捷測試的時候，還需要進行摸底，首先是摸底瞭解現狀，摸底瞭解現狀，然後瞭解一線人員的訴求和管理人員的訴求，找出突出的問題。比如發版隨意的情況，如果隨便亂髮版，而且變更也很頻繁，那麼大家就會疲於奔命。
■圖 9
根據調研的結果，得出初步結論：大廠的規範在小廠中並不適用，需要有所取捨；敏捷化轉型需要化解哪些問題；追求質量與效率，輕量級的團隊去快速迭代；利用敏捷測試管理平臺來縮短跨部門的溝通，解決傳統工具鏈分散，沒有打通的問題。
(2) 頂層設計：測試生命週期及組織過程
根據結論就可以從頂層整體測試生命週期，對從需求的評審開始一直到版本釋出後的生產驗證再到上線的過程不斷進行不同版本的迭代，這裡甚至存在多個版本並行的情況，具體的流程如圖 10 所示，包括測試計劃、測試準備（其中最重要的是准入準出的條件）、測試執行（包括缺陷的分析、准入的判斷等）、測試報告、釋出上線。在測試的過程中，通過合理、科學、標準的測試步驟來規範測試過程，結果才能有保障。
■圖 10
圖 11 展示了整個測試過程：
■圖 11
(3) 敏捷測試落地過程：基礎建設
頂層規劃之後分了 5 方面進行落地，首先是在基礎建設方面建立體系，如圖 12 所示，包括髮版的流程、測試組織過程、bug 的生命週期的管理、bug 的流轉機制、bug 的規範，以及字典的自定義維護、用例編寫的規範、報告的產出物等。
■圖 12
(4) 敏捷測試落地過程：團隊建設
團隊的建設如圖 13 所示，包括梯隊的建設，可在調研之後，提拔小組長，識別核心成員進行培養，對新員工進行培訓（部門職能與簡介、業務的範圍、工作的機制、年度規劃等）；質量意識，建立規範之後，要進行宣教並培訓，讓大家都要了解質量規範，特別是組長，因為他是落地執行的最小管理單元，一定要要深刻地理解質量管理體系的相關內容；制定一年或一年半的技術發展路線，為團隊技術定一個基調，讓大家都圍繞這個方向學習或提升，而不至於偏離；建立學習型的團隊。
■圖 13
儘量少提錢，花錢的事，不好辦，克服困難用現有資源搞定最好，有了業績，後續伸手找老闆要錢，要人才有底氣。
(5) 敏捷測試落地過程：過程管理建設
過程管理建設如圖 14 所示，前面提到了迭代，這裡就要定義是以什麼樣的方式進行迭代（是按版本來迭代，還是按時間週期來迭代），以及每個迭代的任務分配和監督機制是怎樣的，過程管理也可以放在基礎建設中，但是我是覺得把過程管理單獨拆分出來比較好一些，可以更聚焦過程優化。
對於過程監控部分，在執行過程中，如評審環境的流程，環境的管理流程是怎樣的，線上問題的響應機制又是如何的，這些是過程監控需要關注的內容；對於彙報部分，除了測試內部的彙報之外，還包括對 PMO 的質量彙報的機制、形式及內容。一定要從整個專案管理去搞流程改進，同時還要有考核的相關辦法（不是私利，要有大棒也要有棗），要不然，最後就是不了了之。
■圖 14
(6) 敏捷測試落地過程：平臺建設
對於小廠來說還要建設平臺，如圖 15 所示，應利用管理工具作為輔助，否則如果按傳統的週期去培養團隊，時間將會非常很長。此時匯入一個符合敏捷測試的管理平臺，則可以通過無人驅動的方式，通過工具來快速健全各種規範和落地，進而定義敏捷測試管理平臺的訴求，並據此做選型的對比，在 POC 完之後與前面定製的質量管理體系進行對標，客觀地評估 POC 的結果，以點帶面、培訓、推廣。
■圖 15
(7) 敏捷測試管理平臺的訴求
對於敏捷測試管理平臺的訴求如圖 16 所示，它需要具備怎樣的能力呢？包括支援以產品和迭代的維度來追蹤需求生產到落地的全過程；版本的測試計劃的執行過程追蹤；以版本的維度設計、編寫、評審、維護和管理測試用例；缺陷的追蹤和管理；版本質量和測試過程的資料統計分析，這部分是基本的功能要求。
然後是平臺的安全問題，因為要強調安全合規，不能在引入工具之後出現安全合規(比如介面測試，用線上的平臺，你的 token，加解密過程等等有可能造成安全問題)、資料洩密等問題。接下來是易用性，這裡要求必須交付友好，並且學習成本較低。最後要具備二次開發能力。
歸納起來就是，測試部的日常工作流程管理,和安全、穩定、易用、可定製的測試過程也是平臺需要具備的。
■圖 16
選型的時候，最關鍵的是要看是否更新頻繁，而不是看廣告，還要看是不是安全合規，如果說免費，但只是線上的免費，用介面測試這就非常不合適，這免費就是個噱頭，安全合規根本過不了關。如果要用商用的，那就要有正當理由說服老闆買單，如不能降本增效，用商用的不如用真正免費的替代產品，不為公司創造價值，老闆咋可能買單。
比如你選用的商業介面測試，根本沒有降低使用門檻，只有測開才能玩得轉，很難說降本，如果點工都能用好，這一定能降本。一定要選一個 PLG 導向的，也就是產品驅動的，藍湖就是 PLG 的榜樣,她很牛，但是你見過多少藍湖的廣告!
(8) 敏捷測試管理平臺功能對標
如圖 17 所示，我根據前面的模型進行了敏捷測試管理平臺的功能對標，包括環境的維護、測試流程的設定、介面用例、手工用例、不同的迭代等。
■圖 17
其中，在每一個迭代裡，不只是對測試用例的執行，還有 bug 以及其他事務等。在迭代下面就是各種分析的報告。前面確定了所需的工具，那麼對工具進行評估之後，就反向促進團隊敏捷思維的轉變，讓敏捷測試觸手可及。
圖 18 所示為一個看板，可以在其中處理 bug 和用例，從領導的角度來說，通過看板，就可以清楚地瞭解任務進展，實現透明化。
■圖 18
圖 19 展示了迭代的報告，包括用例、介面、任務、bug 的情況等，匯出後會產生企劃報告以及各種明細資料。
■圖 19
另外，測試流程是可以設定的，如圖 20 所示，不僅僅是通常大家所熟悉的提交問題、開發、能驗證修復。
■圖 20
如果測試人員中的新手特別多，則可以開啟測試交叉流程，這樣新人提交了 bug 後就能夠先流轉到有經驗的測試人員手中進行 review，從而對新手進行指導，這種手把手的方式好過，對他再說的說教,比如，如何寫一個好的 bug。
其他流程還包括分析修改工時、開發之人員之間的互動測試、分歧後有仲裁等，這些測試流程可以根據專案不同階段，或是團隊不同時期，可以實時變更。不同的流程也對應不同的狀態的的演化(可按當前流程以及當前處理人，來控制當前 BUG 可轉化的 BUG 態),這樣才可以按需要來進行微調。
目前市面上我看到的工具基本上都是寫死的，而且狀態也很簡單，很多根本不滿足管理的需要，如“待改/持續跟蹤”用於偶現的 BUG，暫時找到不原因，通過這狀態可以直接看出來當前對這 BUG 的處理結果，另外，如開發設定 bug 狀態為“非錯”，測試人員不認同，可能設定為“分歧”就流轉到仲裁人那裡,開發如設定 bug 狀態為“待改/延遲”,仲裁人同意後改為"待改/下版本修改"，不同意就是"待改"表明必須當前版本修改。
前面我們還講到了頻繁的變更的情況，如圖 21 所示，可以線上下維護用例，再同步到線上，這裡不是匯入的概念，而是匯出線上下執行離線修改。
■圖 21
(9) 敏捷測試落地過程：度量及自動化
通過介面自動化可以做到：補充開發自測的不足；初級人員上手容易；快速冒煙；定時的巡檢；長穩測試；實現 0 程式碼，全員都可以進行介面測試；實現 0 程式碼的壓測；完成呼叫鏈的跟蹤和介面的拓補；測開重點實現，元件服務化。
就度量而言，過程的監控、趨勢的分析、結果分析、工作量分析、bug 處理時效、任務進度跟蹤、測開重點是實現多維度統計分析。如圖 22 所示，介面自動化中能推匯出介面拓撲圖（自動推導的），方便排查任務，如果出錯，可以脫離被測服務，直接在調鏈上看到一切。
■圖 22
如圖 23 所示，通過拖拽後產生的斷言可以自動生成一個表示式：
■圖 23
圖 24 展示了拖拽變數的操作：
■圖 24
圖 25 是介面的拓撲圖，介面之間彼此存在依賴關係，如果採用手動執行的方法，我認為是把業務的邏輯強化在腦子中，隨著介面的增加，很容易產生混亂。
■圖 25
但這裡的介面平臺是自動推導，這樣當執行介面的時候，就可以自動生成交易鏈，如圖 26 所示。
■圖 26
當把介面組裝成更復雜的場景時，呼叫鏈看起來可能如圖 27 所示：
■圖 27
介面呼叫的引數情況如圖 28 所示：
■圖 28
此外還支援介面混沌測試，詳見貼尾所列 testerhome 上的貼子。
另外，還有介紹一種通過反模式的方式來實現用例的覆蓋率的情況。比如一個 case 要關聯一個 bug，如果發現 10 個 bug 結果中有 5 個是沒有關聯用例的，一種情況是之前沒寫用例，並且有 10% 的值是允許探索的，最終目的是計算 bug 和用例的配比情況。這不是要求最開始就把用例寫完，這麼做的目的是規避風險。這樣隨著專案的推進，哪怕你在專案上線那一天，就把用例補完，那麼從公司角度來說，用例既然這麼完善，那麼人員的變對專案影響就小得多。
用例覆蓋率計算公式：（（用例數- 未關聯 bug 數）/ 用例數 ）可+10%，開始一個 bug 沒有 未關聯的 bug 也是 0，這時 100% 對的，等專案做著做著就變了，如果是負數 那就更差，總之值越小覆蓋率越低。如果低 1 可能沒時間寫用例；2 給時間寫了，不認真寫。算出來後 加一個 10% ，10% 的探索是合理的，我們不是強制要求測試人員一開始寫完所有用例，我們是鼓勵邊測試邊豐富用例，補也算他寫了，後續版本，這用例就有了，這樣 有人離職也不怕 用例在呢；這不是一刀切，只是保證最後得到好的結果。
通過執行成本來度量，而不是單看用例數，度量示例可見案例 29 的截圖。
■圖 29
(10) 敏捷測試落地過程：遇到的難題
落地過程中遇到的問題如圖 30 所示(最上面是事前，中間是事中，最下面是事後)。
■圖 30
前期包括調研時不配合（我覺得測試人員應該去考軟考高項，而不是說去考 PMP，因為我覺得 PMP 花錢就能過，那麼能學的東西就有限，而且軟考更專注於 IT。在掌握這些知識之後，再去調研，就能夠從專案管理的角度展開，視野會不一樣，視野開啟才能提出最合理的方案）、取得測試和研發領導的支援、資源不足、有反對的抱怨聲、取得開發人員和 PM 的支援、專案提測演示退不下去。
在推進改革時，推不下去最主要的一個原因，是沒有軟實力，你的話沒人信。去推動改進時，要從專案管理的方面去推，不能說開發哪哪不行，測試這塊受影響，開發當然不樂意，要從大局來談過程改進，想從測試則來推，推的人必須要有專案管理的視角，要不然，說難聽點和上面溝通時，說話都不利索，也沒有高度，上面咋信任你呢對吧，所以我都建議大家考軟考高項，沒過也沒事，主要是確實要學一些東西，要麼在大廠幹過，有基礎，要麼自己系統學習過，自己工作中慢慢悟，太慢了。
一句話，軟實力就是建立在和上面溝通過程中，你的談吐的高度，你的認知的外在體現中體現的；測試管理這些其實都很虛，但是要真去做，並沒那麼簡單，我幹了這麼多年，都一直在學習和改善我的管理體系。我做測試時，我們團隊就是救火隊的角色，有需要攻堅就是我們出馬，儘管各種困難很多，我們還是幹了出來，幹出來了，說話才有份量，也間接提升了軟實力，做事不要先講客觀原因，只要盡心盡力就好了，不要再意別的，幹得多成長也快，老闆要是瞎了眼，看不到你的價值，用腳投票就行。
另外測試人員，還要對新技術新事物，保持好奇心，每年要有一個成長計劃，有什麼新的技術，新的工具，都多去了解一下，儘可能的 POC 一下，不要拒絕新事物，後續才能左右縫源，出的方案能考驗到方方面面。
作為一個測試人員，如果 mtsc 大會的是什麼不知道，不知道 testerhome，我覺得很不應該；面試的話，我都要考查學習能力，以及學習慾望，這樣的人一定是自驅動強，值得重點培養的人，潛力無窮。每年還要做好總結中，除本職工作外電，技術上有什麼進步，有什麼得失，對管理體系，有什麼建議，看到什麼問 題等等，這些都值得總結。馬馬虎虎過每年，工作 5 年和工作 2 年，沒什麼進步，這就危險;還要樂於分享，不要怕你的大招被人學了，分享也是自我總結。慢慢軟實力冰就提升了，這是一個慢增長的過程。
前面提到整體從專案管理的角度來推進過程改進，主要是形成大家共同的工程意識，就算團隊技術水平不錯，技術人員的業務意識也很好，如沒有工程意識，協作起來，溝通起來，就很費事。
實施過程中包括緊急需求和需求變更的衝擊，可以通過建立產品規劃、產品迭代制度、完善專案管理制度來解決；開發自測不充分，分支版本管理亂套，開發隨時可以建分支版本，但是在提測的時候，只針對合併過來的版本進行測試。後期則需要通過度量來分析產生的問題，包括進度的分析、質量的分析，然後解決問題。
3、創業公司，以工具平臺為牽引，逐步實踐敏捷測試
以平臺為牽引逐步落實逐步實踐敏捷測試的訴求如圖 31 所示。
■圖 31
包括平臺簡單易上手，能夠規範並固化管理流程，用例、bug 的管理快捷，方便 PM 做好監工角色，應對頻繁的需求變更，缺陷狀態更豐富，建立起有效的執行管理體系，逐步落地敏捷測試。小公司的測試負責人可能並不知道什麼是好的流程，那麼可以採用反向的方式，更注重流程的管理以及快捷，把迭代、看板、度量和自動化融合到測試的過程中，然後找到工具並反推其流程，總結出適用的公式流程，比如圖 31 所示的測試人員、測試經理、分配人、開發人員、仲裁人員的流轉等。
圖 32 所示的這些狀態可能和市面上看的有些不一樣，因為是通過深度研究和反向來整理的。
■圖 32
這種形式整理的文件包括測試的流程、冒煙測試流程、bug 的處理的流程等，它通過工具流程的形式反向促進團隊的敏捷測試。通過深入研究工具，結合對公司的理解，可以整理出適合自己的規範體系。
■圖 33
如圖 34 所示，這裡的發版也是採用離線形式，流程的實時定製、bug 的處理、演變狀態等這裡不再贅述。
■圖 34
■圖 35
■圖 36
■圖 37
■圖 38
■圖 39
4、創業起步公司且無 QA 且每兩週高頻發版的祕訣
創業公司什麼都缺，連創始人都是幹活的，但是方向和業務都非常清晰，有夢想與創新，加入這種團隊也是一種榮幸。在這種情況下應該控制需求的力度，每一個需求都要儘量拆分，不允許一個需求的實現花兩天，通過需求倒逼產品。另外，每個迭代都要實現技術方案的評審，評審要求簡單講清楚思路即可，可以兩週執行一個迭代，第一週的週四進行單元和介面測試，第二週的週三再測試業務，保持效力。
在過程管理方面，我不提倡加班行為，上班的時候只做工作相關的事情，扁平化、透明化進行管理。日報除了給老闆發之外，也應該發在工作群中，讓所有人能看見。對於初創公司來說，如果起步剛剛還在 MVP 階段，創始人對產品的要求很高，基本上都是創始人兼任首席產品的形式，但這只是短期的過渡，最終還是需要有測試團隊。
05 敏捷測試趨勢及展望
對於後續的展望，我比較認可的就是 testOps，如圖 40 所示。
■圖 40
06 問答環節
1、在敏捷測試中如何準備一份完善的測試用例？
在我們看來用例完不完善，主要在於 checklist 的時候有沒有漏測試點。從執行角度來說要關注細節，但是從領導的角度來說，一份完整的用例首先是不要漏測試點，如果你漏測試點了，那麼寫再細也沒用。在做用例評審的時候，我不會看用例的細節，而是看測試點是不是完整。所以我覺得好的用例應該具備完整的用例測試點，一看標題就能知道這個用例是幹什麼的，這樣才能梳理測試點是否完整，否則細節寫再多，我覺得從平臺角度來說沒辦法花時間看。
點沒漏，那如何保障執行細節不出差錯呢？這就需要在評審時，先做業務講解，然後再來檢查，通過業務講解可以很好的 cover 住，我們的測試人員是不是真正掌握了業務，業務都不明白，測試結果肯定不行，都不用看他的用例了。
2、案例中分享的工具或平臺叫什麼名字，能分享一下嗎？
這個平臺是免費的，大家可以去搜尋一下，用關鍵詞"開源中國敏捷測試管理平臺" 去搜尋。大家也可以看看 testerhome 上這個 122 個贊 ，近 2 W 個瀏覽量的貼子 。
https://testerhome.com/topics/30495 測試架構師如何解讀測試平臺的各種爭議或是直接訪問 www.itest.work
活動預告
7 月 16 日下午，聲網開發者創業講堂 • 第 4 期將以「創業團隊如何保障產品業務的安全合規？」為題，邀請環信、遊族、白山雲三家優秀企業的技術專家為大家帶來精彩的分享。
心動不如行動，趕快掃描二維碼或者點選「閱讀原文」報名吧！
