第20講：沒有 ATDD，就沒有用戶故事的可測試性

從這一講開始，我們就進(jìn)入了第 4 部分的學(xué)習(xí)：測試左移更體現(xiàn)敏捷測試的價(jià)值。因?yàn)槊艚莞岢珗F(tuán)隊(duì)對質(zhì)量負(fù)責(zé)、預(yù)防缺陷勝于發(fā)現(xiàn)缺陷，這兩點(diǎn)就意味著我們要構(gòu)建出高質(zhì)量的產(chǎn)品，把質(zhì)量構(gòu)建推向源頭——需求，把測試活動(dòng)左移到需求階段，持續(xù)地對需求和設(shè)計(jì)進(jìn)行評審、及時(shí)發(fā)現(xiàn)需求和設(shè)計(jì)的問題。

測試左移的目的是及時(shí)發(fā)現(xiàn)研發(fā)前期的錯(cuò)誤，避免將錯(cuò)誤帶到代碼階段、測試階段，TDD/ATDD（測試驅(qū)動(dòng)開發(fā)/驗(yàn)收測試驅(qū)動(dòng)開發(fā)）是更為徹底的測試左移，一次把事情做對，即零缺陷質(zhì)量管理思想在軟件研發(fā)中的實(shí)踐，從而幫助企業(yè)節(jié)省研發(fā)成本并縮短開發(fā)時(shí)間。測試左移還包括測試計(jì)劃和設(shè)計(jì)盡早開始，所有這些就構(gòu)成了第 4 部分要討論的內(nèi)容。

測試左移還包括讓開發(fā)人員做更多的測試、加強(qiáng)單元測試、持續(xù)集成等，在敏捷開發(fā)里這些都是核心實(shí)踐，持續(xù)集成已經(jīng)在第 12 講講過了，單元測試的內(nèi)容將在第 42 講中介紹。

在第 7 講介紹敏捷團(tuán)隊(duì)中的專職測試人員時(shí)，提到過測試人員的責(zé)任之一是對軟件的可測試性進(jìn)行把關(guān)，可測試性是測試的基礎(chǔ)或前提，沒有可測試性，談何測試？這一講，我就來講解什么是可測試性、可測試性的不同層次，以及如何提高用戶故事的可測試性。

可測試性概念

軟件的可測試性，從字面上的意思來說是指一個(gè)系統(tǒng)能不能進(jìn)行測試。從理論上講，可測試性基本上是由可觀察性和可控制性構(gòu)成的，還可以包括可預(yù)見性。

• 可觀察性（Observability）是指在有限的時(shí)間內(nèi)使用輸出描述系統(tǒng)當(dāng)前狀態(tài)的能力。系統(tǒng)具有可觀察性意味著一定要有輸出，沒有輸出就不能了解系統(tǒng)當(dāng)前處于什么狀態(tài)，也就不能確定系統(tǒng)行為表現(xiàn)是否正確。

• 可控制性（Controllability）是指在特定的合理操作情況下，整個(gè)配置空間操作或改變系統(tǒng)的能力，包括狀態(tài)控制和輸出控制。系統(tǒng)具有可控制性表明一定要有輸入，只有通過輸入才能控制系統(tǒng)。

理解了前面兩個(gè)，那可預(yù)見性（Predictability）也就好理解了，就是在一定的輸入條件下，輸出的結(jié)果是可以預(yù)測的，這樣我們就可以給出系統(tǒng)的預(yù)期行為或預(yù)期結(jié)果，常常用于測試用例設(shè)計(jì)中。

圖1 ?可控制性和可觀察性的示意圖

在此基礎(chǔ)上，你可以重新理解一下可測試性：通過被測系統(tǒng)提供的接口對系統(tǒng)進(jìn)行操作，然后，能夠通過輸出的結(jié)果了解到系統(tǒng)的狀態(tài)是否符合預(yù)期。

如果一個(gè)系統(tǒng)缺乏可控制性和可觀察性，如圖 1 所示，可以通過增加接口的方式，使之可以控制它或產(chǎn)生輸出。在敏捷測試中，沒有自動(dòng)化測試萬萬不行，而自動(dòng)化測試對可測試性提出更高的要求，因?yàn)樽詣?dòng)化測試更需要明確的輸入和輸出，所以要求系統(tǒng)能夠提供可以調(diào)用的接口，通過接口調(diào)用來驅(qū)動(dòng)程序運(yùn)行并驗(yàn)證返回的結(jié)果。接口可以是 UI 界面或 UI 下面那一層面向業(yè)務(wù)的 API， 也可以是微服務(wù)模塊暴露給其他模塊的 API。

AI 軟件的可測試性就是一個(gè)挑戰(zhàn)，因?yàn)槿狈深A(yù)見性，不太容易事先定義好 Test Oracle 來驗(yàn)證輸出結(jié)果是否符合預(yù)期。比如，Google 在 2018 年公布了用于 NLP（Natural Language Processing，自然語言處理）技術(shù)的 BERT（Bidirectional Encoder Representations from Transformers）模型，這個(gè)模型通過超過 3 億個(gè)參數(shù)提供了強(qiáng)大的語句預(yù)測能力。但是，模型處理的結(jié)果需要人類去綜合判斷分析是否正確，并且需要理解參數(shù)微調(diào)帶來的變化。不過，目前人們也在探索如何解決這些問題，第 44 講會(huì)討論 AI 軟件的測試設(shè)計(jì)與執(zhí)行。

需求、設(shè)計(jì)和代碼等不同層次的可測試性

對可測試性的需求不僅僅是能夠進(jìn)行自動(dòng)化測試和手工測試，既然我們要測試左移，那可測試性應(yīng)該包括三個(gè)方面：需求的可測試性、設(shè)計(jì)的可測試性和代碼的可測試性。

• 需求的可測試性，包括所定義的功能正確性是否能夠被判斷？輸入、輸出的數(shù)據(jù)是否有清楚的定義從而能驗(yàn)證其精準(zhǔn)性？系統(tǒng)的性能、可靠性等是否有驗(yàn)證的標(biāo)準(zhǔn)和方法？

• 設(shè)計(jì)的可測試性，是指通過設(shè)計(jì)來確保系統(tǒng)的特性具有可控制性、可觀察性。另外，需要通過設(shè)計(jì)確保系統(tǒng)的簡單性。從測試角度來說，設(shè)計(jì)越復(fù)雜，系統(tǒng)各組件之間的耦合度越高，對單個(gè)組件的測試難度就越大。

• 代碼的可測試性，一方面要保證需求和設(shè)計(jì)的可測試性得到實(shí)現(xiàn)，比如各項(xiàng)功能需求得到了滿足，并且按照設(shè)計(jì)實(shí)現(xiàn)了系統(tǒng)的松散耦合、模塊之間的接口定義。

用戶故事的可測試性和 ATDD

敏捷開發(fā)提倡“可工作的軟件勝于完備的文檔”，強(qiáng)調(diào)開發(fā)團(tuán)隊(duì)成員之間通過溝通來澄清需求，這就造成文檔質(zhì)量不高、需求描述不清楚。敏捷采用用戶故事的形式對需求進(jìn)行描述，一個(gè)用戶故事（User Story）通常按照下列的格式（模板）來表述：

As a who（誰？），I want to what（什么行為？）so that why（為何？）。

? ? ? ? ? ? ? ? ? ? ?（作為一個(gè)用戶角色，我需要做某事，這樣就能達(dá)到某個(gè)目的）?? ?

用戶故事示例：

作為這家購物網(wǎng)站的買家，我要通過商品名稱查詢歷史訂單，這樣我就能查看某個(gè)訂單的詳細(xì)信息了。

用戶故事是以業(yè)務(wù)語言來描述的，而不是使用技術(shù)語言，比如，我要實(shí)現(xiàn)微服務(wù) A 的一個(gè) API 供微服務(wù) B 調(diào)用，這就不是一個(gè)好的用戶故事。同時(shí)，用戶故事必須是可測試的，要不然怎么驗(yàn)證用戶故事的實(shí)現(xiàn)是不是符合預(yù)期？

在實(shí)際工作中，也許你經(jīng)常會(huì)碰到這些情況：某個(gè)用戶故事的描述太簡單，每個(gè)看到用戶故事的人，其理解都不一樣，但產(chǎn)品負(fù)責(zé)人（PO）可能和開發(fā)人員有過面對面的溝通，開發(fā)人員基本知道做什么，但測試人員還是不清楚，測試就追著開發(fā)問這個(gè)用戶故事究竟要實(shí)現(xiàn)到什么程度？開發(fā)會(huì)說：別急，等過兩天，我做好了給你和 PO demo 一下，就清楚了，如果你們覺得不行，我再改?？此茟B(tài)度很好，但測試人員能做什么嗎？根本無法設(shè)計(jì)測試用例或?qū)懽詣?dòng)化腳本。

功能性的用戶故事還好，非功能性的用戶故事不可測問題更大。?例如，用戶故事描述是這樣的：作為一個(gè)注冊用戶，我希望能夠快速地登錄到系統(tǒng)內(nèi)。那么，你會(huì)問，究竟多快算快？1 秒鐘還是 3 秒鐘？

為了保證用戶故事是可測試的，需要對用戶的實(shí)際需求有一個(gè)明確的說明，這就是用戶故事的驗(yàn)收標(biāo)準(zhǔn)（Acceptance Criteria，AC）。比如，你閱讀上面那個(gè)用戶故事示例，會(huì)有很多疑問：

• 查詢歷史訂單，能夠查詢多長時(shí)間的歷史訂單？最近一年的，還是沒有時(shí)間限制？

• 支持不支持模糊查詢？

• 如果查到多個(gè)，如何顯示？

• 如果沒有查到，給出什么提示？

• 查看訂單的詳細(xì)信息，究竟包含哪些項(xiàng)？

有這么多問題不明白，驗(yàn)收標(biāo)準(zhǔn)就是要讓這些問題明白，因此為這個(gè)用戶故事示例增加相關(guān)的AC：

• 缺省是查詢過去一年的歷史訂單;

• 如果沒查到，問用戶是否選擇一個(gè)查詢的時(shí)段；

• 支持模糊查詢;

• 按匹配度來排序，而不是按時(shí)間排序;

• 每頁最多顯示十個(gè)記錄;

• 查到后只顯示訂單號、商品名稱、價(jià)格和日期;

• 如果想繼續(xù)看，再點(diǎn)擊訂單查看;

• ……

這樣，所要實(shí)現(xiàn)的用戶故事就清楚了，也可以驗(yàn)證了。如果沒有明確的驗(yàn)收標(biāo)準(zhǔn)，就沒有用戶故事的可測試性。用戶故事的驗(yàn)收標(biāo)準(zhǔn)不僅讓測試有據(jù)可依，而且由于列出了各種條件，開發(fā)人員在實(shí)現(xiàn)用戶故事時(shí)就不容易犯錯(cuò)誤，代碼質(zhì)量也會(huì)高得多。也正因?yàn)橛脩艄适碌尿?yàn)收標(biāo)準(zhǔn)澄清了需求，避免了開發(fā)和測試的爭吵，有利于開發(fā)和測試的協(xié)作，而且減少了溝通成本，可以提高開發(fā)效率。

驗(yàn)收測試驅(qū)動(dòng)開發(fā)（Acceptance Test Driven Development，ATDD）就是在開發(fā)設(shè)計(jì)、寫代碼之前，先明確（定義）每個(gè)用戶故事的驗(yàn)收標(biāo)準(zhǔn)，然后再基于用戶故事的驗(yàn)收標(biāo)準(zhǔn)進(jìn)行開發(fā)。這樣有利于我們之前強(qiáng)調(diào)的“質(zhì)量是構(gòu)建出來的”、“預(yù)防缺陷比發(fā)現(xiàn)缺陷更有價(jià)值”。

ATDD 與 TDD（UTDD）的關(guān)系

測試驅(qū)動(dòng)開發(fā)（Test Driven Development，TDD）是指測試先行的理念，即測試在前、開發(fā)在后，提倡在編程之前，先寫測試腳本或設(shè)計(jì)測試用例。TDD 在敏捷開發(fā)模式中被稱為“測試優(yōu)先的編程（Test-First Programming）”。

TDD 中測試先行的理念是為了給開發(fā)人員對編寫的代碼有足夠的信心，代碼的錯(cuò)誤可以通過測試來驗(yàn)證。敏捷開發(fā)往往是快速迭代，程序設(shè)計(jì)不足，所以經(jīng)常需要不斷重構(gòu)代碼，而重構(gòu)的前提是測試就緒，這樣重構(gòu)的質(zhì)量就可以通過運(yùn)行已有的測試得到快速的反饋。所以，有了 TDD，程序員就有了勇氣進(jìn)行設(shè)計(jì)或代碼的快速重構(gòu)，有利于快速迭代和持續(xù)交付。

重構(gòu)是指在不改變代碼外在行為的前提下，對代碼做出修改?！吨貥?gòu)：改善既有代碼的設(shè)計(jì)》

ATDD 和 UTDD（Unit Test Driven Development，單元測試驅(qū)動(dòng)開發(fā)）都屬于 TDD 思想指導(dǎo)下的優(yōu)秀實(shí)踐，可以看作是 TDD 具體實(shí)施過程的兩個(gè)層次：

• ATDD 發(fā)生在業(yè)務(wù)層次，在設(shè)計(jì)、寫代碼前就明確需求（用戶故事）的驗(yàn)收標(biāo)準(zhǔn)。

• UTDD 發(fā)生在代碼層次，在編碼之前寫單元測試腳本，然后編寫代碼直到單元測試通過，這里的 UTDD 相當(dāng)于傳統(tǒng)概念（如極限編程）的 TDD。

在開發(fā)實(shí)踐中，UTDD 在備受推崇的同時(shí)，也受到了廣泛且持久的爭議。 David H.Hansson 是著名的 Web 開發(fā)框架 Ruby On Rails 的開發(fā)者，他在 2014 年寫了一篇文章對 TDD 提出了公開的質(zhì)疑和否定，該文章是“TDD is dead. Long live testing”（TDD 已死，測試永生）。這篇文章一出來就引起了廣泛的討論，贊成者認(rèn)為說出了自己的心聲，當(dāng)然也趁機(jī)表達(dá)了自己的意見，比如，工期緊、時(shí)間短根本來不及寫單元測試；TDD 對開發(fā)人員的要求過高，推行的最大問題在于很多開發(fā)人員不會(huì)寫測試用例，也不會(huì)重構(gòu)代碼。

反對者認(rèn)為 David 對 TDD 的理解是片面的、不正確的，認(rèn)為 TDD 就是 UTDD，而忽略了 TDD 還包括 ATDD。這里暫時(shí)不對 UTDD 進(jìn)行詳細(xì)討論，但就目前的情況來看，UTDD 雖然沒有死，但推行的也不好。我在今年年初公布的 2019 年軟件測試調(diào)查結(jié)果中顯示，只有 21% 的團(tuán)隊(duì)在做靜態(tài)代碼分析、單元測試，更別提更加高大上的 UTDD 了。

而相比 UTDD，面向業(yè)務(wù)層面的 ATDD 推行起來就比較容易，而且是必須的。因?yàn)樾枨竽：?、需求不具有可測試性，你能接受嗎？模糊的需求往往意味著返工和浪費(fèi)，沒有可測試性也就意味著無法開展測試。 所以，團(tuán)隊(duì)按照驗(yàn)收標(biāo)準(zhǔn)來實(shí)現(xiàn)用戶故事，是不是理所當(dāng)然？

到這里，這一講的內(nèi)容就講完了，我簡單總結(jié)一下：

• 系統(tǒng)的可測試性包括可觀察性、可控制性和可預(yù)見性；

• 明確用戶故事的驗(yàn)收標(biāo)準(zhǔn)是讓用戶故事具備可測試性的關(guān)鍵，也是必要的；

• 把 TDD 看成是“測試先行”的理念，這樣 ATDD 和 UTDD 則是其兩個(gè)不同層次上的落地實(shí)踐；

• 相比 UTDD 引起的爭議和推行的困難，ATDD 更容易在實(shí)踐中落地。

最后出一個(gè)思考題：你所在的公司里是在推行 UTDD、還是 ATDD 呢？有哪些挑戰(zhàn)和優(yōu)秀的經(jīng)驗(yàn)可以分享？歡迎留言討論。

第21講：產(chǎn)品價(jià)值分析：商業(yè)畫布、影響地圖、故事地圖

上一講介紹了用戶故事的可測試性及 ATDD。這一講為什么不繼續(xù)講測試，而要講解產(chǎn)品價(jià)值分析呢？首要原因是由于我們提倡業(yè)務(wù)驅(qū)動(dòng)測試，希望從業(yè)務(wù)的角度出發(fā)來進(jìn)行測試分析與設(shè)計(jì)，然后再回歸業(yè)務(wù)。

其次，當(dāng)一個(gè)項(xiàng)目開始進(jìn)行測試時(shí)，要清楚項(xiàng)目的上下文，這是第 3 講提到的敏捷測試“上下文驅(qū)動(dòng)”的思維方式，我們應(yīng)該基于上下文進(jìn)行測試需求分析、設(shè)計(jì)并制定測試計(jì)劃。其中，產(chǎn)品和業(yè)務(wù)是最重要的測試上下文之一。

再者，敏捷特別強(qiáng)調(diào)交付“價(jià)值”給客戶，團(tuán)隊(duì)必須做對客戶有價(jià)值的事情。所以，無論是開發(fā)還是測試，都需要關(guān)注產(chǎn)品的價(jià)值。測試具有保證質(zhì)量的責(zé)任，之前談質(zhì)量，更多是從質(zhì)量模型所定義的質(zhì)量特性（比如功能、性能、安全性等）出發(fā)；而在敏捷中，從客戶價(jià)值出發(fā)更有意義，所以這一講，我們就來討論產(chǎn)品價(jià)值分析。

產(chǎn)品價(jià)值是基礎(chǔ)

產(chǎn)品價(jià)值是軟件研發(fā)的基礎(chǔ)，用戶只有認(rèn)可產(chǎn)品的價(jià)值才會(huì)購買并使用它。敏捷團(tuán)隊(duì)首先需要了解的是產(chǎn)品可以帶給用戶什么樣的價(jià)值，以及誰才是目標(biāo)用戶；其次才是需求分析和功能特性的實(shí)現(xiàn)。然而在實(shí)際工作中，研發(fā)團(tuán)隊(duì)往往不太關(guān)心公司要做一個(gè)產(chǎn)品的目的是什么，只知道是由產(chǎn)品經(jīng)理給出的建議，由高層領(lǐng)導(dǎo)來做決定，最后落實(shí)到研發(fā)團(tuán)隊(duì)。

根據(jù) PMI（Project Management Institute）發(fā)布的年度報(bào)告，在 2017 年有 14% 的 IT 項(xiàng)目宣告失敗，其中有 39% 是因?yàn)椴徽_的產(chǎn)品需求導(dǎo)致的，需求問題是項(xiàng)目失敗的首要原因。為什么會(huì)這樣呢？我們可以看看圖 1，它用漫畫的形式形象地描述了客戶的需求是如何一步步走樣的，最后改的面目全非。參與項(xiàng)目的每個(gè)角色對需求的理解都不一樣，需求文檔又很簡單，客戶的需求主要靠角色之間的溝通和交流來傳遞，挺像敏捷開發(fā)的場景，所以往往最后做出來的東西和客戶想要的結(jié)果有很大偏差。

圖 1 ?被誤解的用戶需求（圖片來源：維基百科）

有意思的是，第一張圖里客戶描述的需求和最后一張圖里所揭示的客戶真正的需求也不一樣，正如喬布斯所說，客戶其實(shí)不知道自己真正需要什么。但根本的原因在于一開始就沒有挖掘出客戶真正的需求，福特汽車公司的創(chuàng)始人亨利福特曾經(jīng)說過：“如果我當(dāng)年去問顧客他們想要什么，他們肯定會(huì)告訴我需要一匹更快的馬?！笨蛻粽鎸?shí)的需求是一匹馬嗎？不，他們真正的需求是“更快的交通工具”。

由此可見，理解用戶真正想要什么進(jìn)而交付滿足需要的產(chǎn)品，并不是一件容易的事，也不要假設(shè)產(chǎn)品經(jīng)理要求你實(shí)現(xiàn)的功能一定是客戶真正想要的。在做產(chǎn)品之前，多問問用戶為什么需要這個(gè)產(chǎn)品或者某個(gè)功能特性，也許可以幫助糾正需求的偏差或者發(fā)現(xiàn)被忽略的隱性需求。

今天我來介紹三款工具，可以幫助我們了解產(chǎn)品價(jià)值和產(chǎn)品定位，以便更好地進(jìn)行需求分析和管理。它們都有一個(gè)共同的特點(diǎn)，那就是一頁紙可以包含所有的內(nèi)容，特別適合敏捷開發(fā)模式，也特別適合敏捷團(tuán)隊(duì)進(jìn)行需求方面的溝通和澄清，是非常有效的溝通工具。

商業(yè)畫布

商業(yè)畫布的概念來自《商業(yè)模式新生代》這本書，全稱應(yīng)該是商業(yè)模式畫布（Business Model Canvas）。它是一個(gè)適合敏捷的商業(yè)模式分析工具，可以幫助研發(fā)團(tuán)隊(duì)快速地對產(chǎn)品的價(jià)值和市場定位，有一個(gè)整體的認(rèn)識。

商業(yè)模式定義：
商業(yè)模式描述了企業(yè)如何創(chuàng)造價(jià)值、傳遞價(jià)值和獲取價(jià)值的基本原理?！渡虡I(yè)模式新生代》

商業(yè)畫布由 9 個(gè)模塊組成，如圖 2 所示。我們通常用它來做企業(yè)的商業(yè)模式分析，每個(gè)模塊其實(shí)有很多種可能性和替代方案，分析的過程就是從這些可能的方案里找到最佳的組合。好的商業(yè)模式往往不是一蹴而就的，需要在經(jīng)營過程中不斷調(diào)整，比如阿里巴巴最早的業(yè)務(wù)是 B2B 形式的，但今天更有價(jià)值的是淘寶天貓、螞蟻金服等。一旦企業(yè)形成極具業(yè)務(wù)價(jià)值的商業(yè)模式，即使企業(yè)在短期甚至長期都不能盈利，但仍然也能受到追捧，比如亞馬遜，因?yàn)槲覀兿嘈藕玫纳虡I(yè)模式下，賺錢是遲早的事。

研發(fā)團(tuán)隊(duì)可以用商業(yè)畫布去收集相關(guān)信息來做為需求分析的輸入。如果能邀請產(chǎn)品經(jīng)理坐下來一起完成一個(gè)產(chǎn)品的商業(yè)畫布，一邊制作，一邊溝通、澄清，效果更好。

圖 2 商業(yè)畫布構(gòu)造圖

用商業(yè)畫布進(jìn)行商業(yè)模式分析的過程基本如下。

找到產(chǎn)品的目標(biāo)用戶群（客戶細(xì)分） → 分析用戶的需求（價(jià)值主張）是什么 → 探討怎樣才能獲取到用戶（渠道通路） → 怎樣建立和維持客戶關(guān)系留住客戶（客戶關(guān)系） → 該用什么樣的方式實(shí)現(xiàn)盈利（收入來源） → 發(fā)掘產(chǎn)品目前擁有什么樣的核心資源，比如資金、技術(shù)、人力等（核心資源） → 列出必須要交付的業(yè)務(wù)功能（關(guān)鍵業(yè)務(wù)） → 找出重要的合作伙伴都有哪些（關(guān)鍵合作伙伴） → 分析投入產(chǎn)出比是怎樣的（成本結(jié)構(gòu)）。

圖 3 就是一個(gè)在線教育 App 產(chǎn)品的商業(yè)畫布示例。從測試角度來看，我們應(yīng)該重點(diǎn)關(guān)注其中的“客戶細(xì)分、價(jià)值主張、客戶關(guān)系、關(guān)鍵業(yè)務(wù)、渠道”等五項(xiàng)內(nèi)容。

圖 3 在線教育 App 商業(yè)畫布示例

影響地圖

影響地圖（Impact Mapping）是《影響地圖：讓你的軟件產(chǎn)生真正的影響力》這本書提出的一個(gè)用于業(yè)務(wù)分析的可視化工具，它從 Why-Who-How-What 這四個(gè)方面，按照“目標(biāo)——角色——角色的影響方式——具體方案”的順序進(jìn)行討論，逐步提取出達(dá)成業(yè)務(wù)目標(biāo)的解決方案。

利用這個(gè)工具，研發(fā)團(tuán)隊(duì)從“為什么要做這個(gè)產(chǎn)品或者功能”出發(fā)，和業(yè)務(wù)負(fù)責(zé)人一起討論并制定一個(gè)產(chǎn)品或功能要實(shí)現(xiàn)的業(yè)務(wù)目標(biāo)，然后識別出哪些角色會(huì)影響這個(gè)目標(biāo)的實(shí)現(xiàn)，影響方式是什么，每種方式具體要做什么。研發(fā)團(tuán)隊(duì)可以從中識別出產(chǎn)品需要做哪些功能特性，同時(shí)幫助實(shí)現(xiàn)業(yè)務(wù)目標(biāo)。

我以上面的在線教育 App 產(chǎn)品為例來講解影響地圖的使用。假設(shè)產(chǎn)品經(jīng)理希望添加一個(gè)課程分銷的功能，App 用戶可通過這個(gè)功能把課程推廣出去，并獲得收益。

它的 Why-Who-How-What 四個(gè)方面內(nèi)容如下：

• Why：包含兩個(gè)方面的內(nèi)容，第一，作為研發(fā)團(tuán)隊(duì)要了解為什么需要這個(gè)功能？比如“分銷功能“是為了實(shí)現(xiàn)課程推廣的裂變效應(yīng)，從而提高銷售額；第二，通過這個(gè)功能可以實(shí)現(xiàn)什么樣的業(yè)務(wù)目標(biāo)？設(shè)定的業(yè)務(wù)目標(biāo)應(yīng)該是明確、清晰、可衡量的，并且是可以實(shí)現(xiàn)的，比如在三個(gè)月內(nèi)課程銷售額通過分銷功能增加 20%。

• Who：為了達(dá)成目標(biāo)需要影響到哪些角色？這些角色既可以幫助我們實(shí)現(xiàn)業(yè)務(wù)目標(biāo)，也可能是阻礙目標(biāo)的實(shí)現(xiàn)。在此案例里，識別出影響目標(biāo)的角色包括：App 用戶、市場推廣人員、課程審核人員、課程講師等。

• How：表示需要用什么樣的方式影響上述角色的行為來達(dá)成目標(biāo)，既包含產(chǎn)生促進(jìn)目標(biāo)實(shí)現(xiàn)的正面行為，也包含消除阻礙目標(biāo)實(shí)現(xiàn)的負(fù)面行為。

• What：對于每一種影響方式，需要采取哪些具體方案。

圖 4 就是為這個(gè)分銷功能制作的一個(gè)影響地圖的示例。

圖 4 影響地圖示例

從這個(gè)例子的具體方案中，是不是可以識別出不少需要研發(fā)團(tuán)隊(duì)實(shí)現(xiàn)的功能特性？比如推廣海報(bào)的制作、收益查看、提現(xiàn)和微信鏈接等。如果分析出來的功能特性比較多，團(tuán)隊(duì)需要對它們進(jìn)行優(yōu)先級排序，按照功能特性對業(yè)務(wù)目標(biāo)的影響大小來決定哪些功能必須要有、哪些功能無關(guān)緊要，哪些功能要先做、哪些可以后做等。

同時(shí)，通過影響地圖，研發(fā)團(tuán)隊(duì)可以清晰的知道產(chǎn)品或功能如何幫助企業(yè)實(shí)現(xiàn)業(yè)務(wù)目標(biāo)，這樣就會(huì)對自己做的產(chǎn)品更有信心，工作也會(huì)更有動(dòng)力。

（用戶）故事地圖

使用商業(yè)畫布和影響地圖可以幫助團(tuán)隊(duì)明確產(chǎn)品的價(jià)值、目標(biāo)、用戶、主要功能特性等問題，這些問題解決之后，接下來研發(fā)團(tuán)隊(duì)就可以開始編寫用戶故事。一般情況下，先編寫史詩級的用戶故事（Epic），然后將每個(gè) Epic 拆分成若干個(gè)用戶故事。下一講將會(huì)詳細(xì)介紹如何進(jìn)行用戶故事的拆分和評審。這些不同的用戶故事組成要實(shí)現(xiàn)的軟件功能特性的待辦事項(xiàng)（Backlog）。但這樣形成的 Backlog 所呈現(xiàn)的用戶故事是零散的，因此呈現(xiàn)的需求也是零散的，缺乏系統(tǒng)性。這時(shí)就需要引入用戶故事地圖（User Story Mapping）——一種生成用戶故事的團(tuán)隊(duì)協(xié)作溝通的新方法。

用戶故事地圖的概念來自 Jeff Patton 創(chuàng)作的一本書，書名就叫《用戶故事地圖》，敏捷團(tuán)隊(duì)可以用它來協(xié)作產(chǎn)生用戶故事，也可以用來進(jìn)行需求分析管理。用戶故事地圖可以為敏捷團(tuán)隊(duì)解決下列問題：

• 團(tuán)隊(duì)協(xié)作產(chǎn)生用戶故事；

• 系統(tǒng)化地呈現(xiàn)軟件要提供的全部功能；

• 識別出要交付軟件的 MVP（Minimum Viable Product，最小化可用產(chǎn)品），目的是以最小的投入快速交付對用戶最有價(jià)值的軟件，這一點(diǎn)對于敏捷開發(fā)尤其重要，可以很好地服務(wù)于迭代增量開發(fā)；

• 呈現(xiàn)不同粒度的用戶故事之間的關(guān)系（Epic 和用戶故事）；

• 識別用戶故事的優(yōu)先級。

用戶故事地圖需要敏捷團(tuán)隊(duì)成員共同完成，可以采用大家坐在一起進(jìn)行頭腦風(fēng)暴的方式。我還是以在線教育 App 這個(gè)案例來設(shè)計(jì)一個(gè)用戶故事地圖，如圖 5 所示，它從購買課程的用戶角色出發(fā)，按照課程購買發(fā)生的活動(dòng)順序從左到右排列。最上面一行是 Epic 級別的用戶故事，下面是每個(gè) Epic 拆分出來的細(xì)粒度的用戶故事，從上到下顯示了用戶故事的優(yōu)先級，按照輕重緩急把用戶故事分成三批進(jìn)行交付，最有價(jià)值的用戶故事放在第一批，次要的放在第二批，其他的放在第三批。這樣，第一個(gè)可交付軟件的 MVP （第一批用戶故事）就出來了。

在一個(gè)軟件產(chǎn)品中，不同用戶類型對應(yīng)不同的用戶故事地圖，對于在線教育 App，比如也可以給“專欄講師”這個(gè)角色制作一個(gè)用戶故事地圖。

圖 5 用戶故事地圖示例

今天的課程就講到這里了，我來對所講的內(nèi)容做一個(gè)總結(jié)。這一講主要介紹了三個(gè)工具，從價(jià)值和商業(yè)模式分析、如何對產(chǎn)品的某個(gè)功能深入分析，以及如何就功能特性及其優(yōu)先級等進(jìn)行有效溝通這三個(gè)方面進(jìn)行了講解。我把其中的重點(diǎn)總結(jié)如下。

• 了解“為什么要做一個(gè)產(chǎn)品“是做出具有價(jià)值的軟件產(chǎn)品的基礎(chǔ)，研發(fā)團(tuán)隊(duì)可以用商業(yè)畫布來對產(chǎn)品進(jìn)行價(jià)值分析。

• 影響地圖可以幫助團(tuán)隊(duì)進(jìn)行產(chǎn)品或某個(gè)功能的業(yè)務(wù)分析。從要實(shí)現(xiàn)的業(yè)務(wù)目標(biāo)開始，按照 Why-Who-How-What 的順序分解出要實(shí)現(xiàn)的具體功能特性，同時(shí)也能幫助我們整體了解實(shí)現(xiàn)業(yè)務(wù)目標(biāo)的方式和途徑。

• 用戶故事地圖是一個(gè)團(tuán)隊(duì)協(xié)作和需求管理的工具，研發(fā)團(tuán)隊(duì)用來生成用戶故事的同時(shí)，對要交付軟件的功能特性以及用戶故事的優(yōu)先級也有了一個(gè)清晰、完整的理解和共識。

最后給你留一個(gè)動(dòng)手的練習(xí)：針對你所參與的軟件產(chǎn)品，整理出一個(gè)用戶故事地圖，并思考是否需要增加新的用戶故事？

第22講：從 Epic 到 Uer Story 完成需求評審

傳統(tǒng)的需求評審是通過評審會(huì)議，產(chǎn)品、開發(fā)、測試等各路人馬坐在一起來完成市場需求文檔（Market Requirements Document，MRD）或產(chǎn)品需求文檔（Product Requirements Document，PRD）的評審，以發(fā)現(xiàn)如需求缺失、無意義的需求、模棱兩可的描述等問題。

通用的評審標(biāo)準(zhǔn)

一般在評審前，需要明確評審標(biāo)準(zhǔn)，使評審有據(jù)可依。在一定程度上看，無論是傳統(tǒng)的需求評審，還是敏捷需求評審，有些標(biāo)準(zhǔn)是通用的，具有普適性，例如在第 20 講中所提到的需求可測試性，就是通用且必要的。需求評審標(biāo)準(zhǔn)還包含可行性（能夠?qū)崿F(xiàn)）、易修改性（文檔容易維護(hù)）、正確性、易理解性、一致性等，有些要求，比如正確性、易理解性，看似簡單，要做到也是不容易的，我們針對其中一個(gè)可以提出一系列的問題，想一想我們平時(shí)的需求文檔是否都能給出明確、正確的回答？恐怕很難吧？

1. 正確性：

• 需求定義是否符合軟件標(biāo)準(zhǔn)、規(guī)范的要求？

• 每個(gè)需求定義是否都合理，經(jīng)得起推敲？

• 是否所有的功能都有明確的目的？

• 是否存在對用戶無意義的功能？

• 所采用的算法和規(guī)則是否科學(xué)、成熟和可靠？

• 有哪些證據(jù)說明用戶提供的規(guī)則是正確的？

2. 一致性：

• 所定義的需求內(nèi)容前后是否存在沖突和矛盾？

• 是否使用了標(biāo)準(zhǔn)術(shù)語和統(tǒng)一形式？

• 使用的術(shù)語是否是唯一的？

• 所規(guī)定的操作模式、算法和數(shù)據(jù)格式等是否相互兼容？

除了正確性、易理解性、一致性、可測試性、可行性和易修改性之外，還需要考慮需求的完備性和可追溯性，這兩點(diǎn)更有挑戰(zhàn)，要做到完備幾乎是不可能的，在敏捷中也不追求功能特性的完備性，而且是先交付高價(jià)值的特性，再交付中等價(jià)值、低價(jià)值的特性。但是，就第 20 講提到的用戶故事的驗(yàn)收標(biāo)準(zhǔn)，就需要考慮其完備性，盡量考慮或挖掘出各種輸入 / 輸出、條件限制、應(yīng)用場景或操作模式，不僅包括正常的輸入 / 輸出、應(yīng)用場景和操作模式，而且還要包括非法的輸入 / 輸出、異常的應(yīng)用場景和操作模式等。針對數(shù)據(jù)項(xiàng)，甚至需要考慮其來源、類型、值域、精度、單位和格式等。

需求的可追溯性主要指每一項(xiàng)需求定義是否可以確定其來源，比如：

• 是來自哪項(xiàng)具體的業(yè)務(wù)？

• 由哪個(gè)用戶提出來的？

• 是否可以根據(jù)上下文找到所需要的依據(jù)或支持?jǐn)?shù)據(jù)？

• 后續(xù)的功能變更是否都能找到其最初定義的功能？

• 功能的限制條件是否可以找到其存在的理由？

Epic 的評審

對于敏捷項(xiàng)目，需求如何評審呢？一般敏捷的用戶故事也是由特性拆解出來的，一個(gè)特性可以拆出很多個(gè)用戶故事。從具體評審來看，就是要評審特性的描述和用戶故事的描述，但在敏捷中，可能沒有具體的特性描述，或者說，特性的評審屬于傳統(tǒng)的范圍，可以按照上面討論的通用標(biāo)準(zhǔn)來進(jìn)行評審。而在敏捷中，面對的兩個(gè)具體評審對象是用戶故事和 Epic。我們可以先從宏觀的——Epic 開始，再到微觀——具體的每一個(gè)用戶故事。

Epic 在敏捷中應(yīng)用還是比較普遍的，但不同的人對 Epic 理解是不一樣的，容易引起一些爭議和混亂。Epic 最早由 Mike Cohn 在其《用戶故事與敏捷開發(fā)》（User Stories Applied to Agile Software Development）一書中提出來，即“When a story is too large, it is sometimes referred to as an epic”。這里，Epic 是史詩般的大用戶故事，也符合 Epic 這個(gè)詞的本意。例如，說一部“動(dòng)作冒險(xiǎn)電影”，自然少不了一場汽車追逐、一場格斗或一場槍戰(zhàn)等；上一講提到的在線教育 App 的案例，自然也會(huì)有發(fā)現(xiàn)課程、購買課程、分銷課程等這樣的大故事。

但也有人（如 Atlassian 公司）認(rèn)為 Epic 是一種與用戶故事分開但包含用戶故事的積壓項(xiàng)目：Epic 是大塊頭的工作項(xiàng)，它可以分解為許多較小的用戶故事（An epic is a large body of work that can be broken down into a number of smaller stories），可以看作圖 1（即上一講所描述的用戶故事地圖——圖 5）的一列，即一組用戶故事。

圖1 用戶故事地圖示例

總而言之，把 Epic 看成更大的故事，這沒錯(cuò)，可以用圖 2 來區(qū)分特性、Epic、用戶故事和任務(wù)（task）之間的關(guān)系。

圖2 ?特性、Epic、用戶故事和任務(wù)之間的關(guān)系

下面就來討論 Epic 的評審，還是以在線教育 App 為例，從購買課程的用戶角色出發(fā)，按照課程購買發(fā)生的活動(dòng)順序從左到右排列，從賬戶管理開始，到課程搜索、課程購買、課程管理，最后以課程分銷結(jié)束。評審時(shí)，我們會(huì)提出以下一些問題：

• 這個(gè)過程合理嗎？符合時(shí)間順序嗎？

• Epic 名稱是否合理？

• Epic 每個(gè)特性下面的用戶故事（列）設(shè)置合理嗎？

• 優(yōu)先級設(shè)置是否合理？

例如，比如 圖 1，從購買課程的用戶角色來看，是否能發(fā)現(xiàn)這些問題：

• 賬戶管理是不是可以往后排一排？

• “課程搜索”后是否要增加“試讀”內(nèi)容？取“課程發(fā)現(xiàn)”名稱是不是更貼近用戶？

• “綜合查詢”比較模糊，也沒必要，是不是可以改為“關(guān)鍵詞查詢”更明確些？

• “課程管理”是否改完“課程學(xué)習(xí)”更為合理？

• “收益管理”也偏大，是不是可以拆成兩個(gè)故事“收益提現(xiàn)”和“收益詳情”？

• 拼團(tuán)購買，目前比較流行，也能吸引更多新用戶參與。

• 課程分享再增加一個(gè)“影響力榜”，會(huì)吸引更多用戶參與。

• 課程學(xué)習(xí)后是不是要做學(xué)習(xí)筆記，發(fā)現(xiàn)某一講很好，是否要收藏？

• 如果要“管理課程”，是否要分為“已購課程”和“未購課程”或“已購課程”和“所有課程”。

• …..

經(jīng)過評審之后，修改評審中所提出的問題，就形成了新的、更合理的用戶故事地圖，如圖 3 所示。

圖3 評審?fù)ㄟ^的用戶故事地圖示例

用戶故事的評審

完成 Epic 的評審，就可以進(jìn)入用戶故事的評審。用戶故事的評審相對具體、有標(biāo)準(zhǔn)，最常用的標(biāo)準(zhǔn)就是 INVEST：

INVEST 原則：
Independent(獨(dú)立的),Negotiable(可協(xié)商的),Valuable(有價(jià)值的),Estimable(可估算的),Sized Appropriately or Small(大小合適的),Testable(可測試的)

這個(gè) INVEST 清單最早起源于 Bill Wake 在 2003 年寫的文章 INVEST in Good Stories, and SMART Tasks，該文章也將首字母縮寫為 SMART（特定的、可衡量的、可實(shí)現(xiàn)的、相關(guān)的、限時(shí)），重新用于用戶故事的技術(shù)分解所產(chǎn)生的任務(wù)。他還在 2012 年，寫了 6 篇系列文章：

• Independent Stories in the INVEST Model

• Negotiable Stories in the INVEST Model

• Valuable Stories in the INVEST Model

• Estimable Stories in the INVEST Model

• Small – Scalable – Stories in the INVEST Model

• Testable Stories in the INVEST Model

其中以獨(dú)立性這篇文章為例，他舉了一個(gè)極端的例子，想象一組功能，具有 6 個(gè)能力：{A, B, C, D, E, F}。

如果我們也寫了 6 個(gè)用戶故事，分別覆蓋了其中一些功能，比如：

• {A, B}

• {A, B, F}

• {B, C, D}

• {B, C, F}

• {B, E}

• {E, F}

這種重疊（耦合）是不是很痛苦？所以一定要讓每個(gè)用戶故事相對獨(dú)立，這樣不僅有利于實(shí)現(xiàn)，也有利于理解和溝通。

當(dāng)初是為了整成一個(gè)容易記住的單詞，所以 INVEST 由每個(gè)單詞的首字母組成。從評審的過程看，先看這個(gè)用戶故事有沒有價(jià)值，這種價(jià)值是指對客戶 / 用戶的價(jià)值，而不關(guān)心對開發(fā)人員或測試人員有沒有價(jià)值；如果沒有價(jià)值，其他的 INEST 就不用看了。所以，評審的過程是從是否有價(jià)值開始，再檢查其獨(dú)立性、可協(xié)商性、可測試性、可估算等，如圖 4 所示。

圖4 用戶故事評審過程示意圖

一個(gè)用戶故事越大，其估算的誤差就越大，而可測試性在第 20 講中已介紹，所以可估算、可測試性等比較容易理解，這里就不再說明了。

不容易理解的是“可協(xié)商的（Negotiable）”，因?yàn)槲覀冎罢f，需求越明確越好，不希望出現(xiàn)“快”、“大概”、“可能”、“幾乎”等這樣的詞，越模糊就越不可測?？蓞f(xié)商，是否意味著不明確呢？其實(shí)不是，只是說，用戶故事不是功能的約定，將來是可以調(diào)整的，即用戶故事的細(xì)節(jié)在未來開發(fā)過程中可以由客戶和開發(fā)人員去協(xié)商，包括測試思路。

“可協(xié)商的”要求和可測試性是矛盾的，而且和我們之前說的 ATDD 也是有沖突的。如果在設(shè)計(jì)、編程之前就把用戶故事的驗(yàn)收標(biāo)準(zhǔn)等明確下來，在未來開發(fā)過程中協(xié)商的空間就很小了。

再者，如果用戶故事越明確，不僅有利于可測試性，也有利于估算。規(guī)模小，有時(shí)具有迷惑性或欺騙性，搞清楚更為重要；太小，也不一定是好事情，Mike Cohn 和 Kent Beck 合著的《用戶故事與敏捷方法》提到了故事太小是第一個(gè)不良征兆，還舉了一個(gè)例子，即下面的兩個(gè)用戶故事：

搜索結(jié)果可以保存為XML文件
搜索結(jié)果可以保存為HTML文件

就應(yīng)該合并為一個(gè)用戶故事。用戶故事的大小可以控制在幾個(gè)人天的工作量，甚至 Bill Wake 認(rèn)為故事通常最多只能代表幾個(gè)人周的工作量。圖 2 描述的場景算是通常情況，或者系統(tǒng)規(guī)模不大的情況，用戶故事的工作量是幾個(gè)人天；如果是大規(guī)模系統(tǒng)，用戶故事的工作量可以達(dá)到幾個(gè)人周。

至于說，用戶故事需要滿足 3C 原則：Card（卡片）、Conversation（會(huì)話）和 Confirmation（確認(rèn)）等，即：

• 卡片：卡片的空間很有限，促進(jìn)用戶故事簡潔，捕獲需求的精髓或目的。

• 會(huì)話：類似前面“可協(xié)商的”，強(qiáng)調(diào)需求的細(xì)節(jié)是在開發(fā)團(tuán)隊(duì)、產(chǎn)品負(fù)責(zé)人及利益相關(guān)人之間的會(huì)話中暴露和溝通的，用戶故事僅僅作為建立這個(gè)會(huì)話的一個(gè)承諾。

• 確認(rèn)：用戶故事還要包含滿足條件形式的確認(rèn)信息，這些就是之前所說的、用于澄清期望行為的驗(yàn)收標(biāo)準(zhǔn)。

從用戶故事需求評審來看，還有一點(diǎn)要注意，它是表達(dá)客戶的真實(shí)需求還是表達(dá)客戶給出的解決方案。我們需要的是客戶的真實(shí)需求，而不是解決方案，解決方案倒是我們開發(fā)團(tuán)隊(duì)所要做的事情。

我經(jīng)常會(huì)舉一個(gè)簡單的例子，你去食堂吃飯，你的同事在路上碰到你，說：幫我買幾個(gè)饅頭回來，我就不去食堂了?！百I幾個(gè)饅頭”是用戶的需求，還是用戶基于某個(gè)需求給出的解決方案呢？他的真實(shí)需求可能會(huì)是哪些呢？這算是留給你的思考題，歡迎留言討論。

第23講：不可忽視的設(shè)計(jì)評審

設(shè)計(jì)評審的價(jià)值和重要性

與需求評審不同，傳統(tǒng)開發(fā)模式下測試人員很少參加設(shè)計(jì)評審，總覺得和測試的關(guān)系不大，其實(shí)，這樣的認(rèn)知是錯(cuò)誤的。

記得在一次會(huì)議演講之后，一位與會(huì)的測試同學(xué)提問：如何進(jìn)行可靠性測試？

如果是你的話，可能會(huì)將可靠性計(jì)算公式告訴他，然后告訴他用壓力測試、故障注入的方式來進(jìn)行可靠性測試，你甚至可能想到今天比較時(shí)髦的混沌工程，但這并不是最有效的方法。

更好的做法是這樣：我會(huì)告訴他，首先要加強(qiáng)設(shè)計(jì)評審，在評審時(shí)，問系統(tǒng)架構(gòu)師或系統(tǒng)設(shè)計(jì)人員，他們是如何來保證系統(tǒng)可靠性的？關(guān)鍵組件有冗余設(shè)計(jì)嗎？故障轉(zhuǎn)移機(jī)制有沒有？如果有故障轉(zhuǎn)移機(jī)制，又是如何設(shè)計(jì)的？可以在線上進(jìn)行演練嗎？系統(tǒng)一旦失效，估計(jì)花多少時(shí)間恢復(fù)？用戶數(shù)據(jù)是實(shí)時(shí)備份的嗎？用戶數(shù)據(jù)是否有被攻擊的漏洞？線上數(shù)據(jù)庫遭受破壞，數(shù)據(jù)能恢復(fù)嗎？數(shù)據(jù)恢復(fù)需要多長時(shí)間？了解了這些可靠性相關(guān)的信息后，驗(yàn)證這些具體措施就相對容易得多。

也就是說，我們需要先通過設(shè)計(jì)評審，當(dāng)檢查系統(tǒng)設(shè)計(jì)時(shí)是否充分考慮了可靠性的需求，在設(shè)計(jì)中是否存在考慮不周的問題，并且通過設(shè)計(jì)評審，清楚如何去驗(yàn)證系統(tǒng)的可靠性；否則，使用壓力測試的方法進(jìn)行高負(fù)載測試，無論是從時(shí)間上還是從要付出的其它代價(jià)上來看，往往很難讓人接受。即使有故障注入的測試方法，也需要先了解可能有哪些故障觸發(fā)點(diǎn)或故障模式，才能把有效的故障數(shù)據(jù)注入進(jìn)去。

更糟糕的是，如果沒有設(shè)計(jì)評審，或在設(shè)計(jì)評審時(shí)，沒有從測試的角度去提問，可靠性、性能、安全性等問題就很難在系統(tǒng)設(shè)計(jì)時(shí)被發(fā)現(xiàn)。等到后期系統(tǒng)測試時(shí)再發(fā)現(xiàn)，往往為時(shí)已晚，團(tuán)隊(duì)將付出很大的代價(jià)，需要修改設(shè)計(jì)和代碼，再重新測試。

這就體現(xiàn)了設(shè)計(jì)評審的價(jià)值和重要性，通過設(shè)計(jì)評審，可以給我們帶來下列 3 點(diǎn)收益：

• 更好的確保軟件設(shè)計(jì)的可測試性，包括系統(tǒng)的功能、性能、安全性、可靠性等可測試性。

• 更重要的是能夠提前發(fā)現(xiàn)設(shè)計(jì)上的缺陷，避免直到系統(tǒng)測試時(shí)才發(fā)現(xiàn)問題，大大降低了系統(tǒng)的質(zhì)量風(fēng)險(xiǎn)、項(xiàng)目管理風(fēng)險(xiǎn)和軟件研發(fā)成本。

• 更好地了解系統(tǒng)是如何實(shí)現(xiàn)的、由哪些組件、服務(wù)構(gòu)成，更深入地了解系統(tǒng)架構(gòu)、關(guān)鍵組件、關(guān)鍵接口等，有助于實(shí)現(xiàn)分層測試、面向接口的測試，從而提高測試方案、測試設(shè)計(jì)的有效性和效率。

在敏捷開發(fā)模式下，我們更強(qiáng)調(diào)測試左移和持續(xù)測試，這就少不了設(shè)計(jì)評審。從設(shè)計(jì)評審的角度看，無論是傳統(tǒng)開發(fā)還是敏捷開發(fā)，都有一些基本的評審標(biāo)準(zhǔn)，比如設(shè)計(jì)的規(guī)范性、開放性、可測試性、可擴(kuò)展性和一致性等，設(shè)計(jì)應(yīng)力求簡單、合理、清晰，做到高內(nèi)聚、低耦合。同時(shí)，最終設(shè)計(jì)必須能滿足需求，所有功能特性都有相應(yīng)的組件去承載，并且它們之間的映射是合理的。

下面就來說說如何高效地完成敏捷開發(fā)模式下的設(shè)計(jì)評審。

如何完成架構(gòu)評審

在敏捷開發(fā)模式下，文檔再省，系統(tǒng)架構(gòu)圖不能省，其次，接口定義文檔也不能省。所以在敏捷開發(fā)模式下，設(shè)計(jì)評審重點(diǎn)應(yīng)放在架構(gòu)評審和接口定義文檔的評審上。

首先，我們攤開系統(tǒng)架構(gòu)設(shè)計(jì)圖，如圖 1 所示，針對這個(gè)架構(gòu)圖先整體評審，再對每層進(jìn)行 Review，從UI（User Interface）開始，深入到 API 層、安全層（Security Layer）、核心（Core）層、存儲(chǔ)（Storage）層、工作流引擎（Workflow Engine）、搜索引擎（Search Engine）、目錄和元數(shù)據(jù)引擎（Catalog & Metadata Engine）、狀態(tài)與報(bào)告（Status & Reporting）等組件。

圖1 ?某軟件系統(tǒng)邏輯架構(gòu)示意圖

在系統(tǒng)架構(gòu)設(shè)計(jì)評審時(shí)，如本講開始所說的，可以就性能、可靠性、安全性等進(jìn)行提問，了解系統(tǒng)整體架構(gòu)設(shè)計(jì)是否合理、是否有緩存機(jī)制、是否有冗余設(shè)計(jì)、是否存在單點(diǎn)失效等問題；在整體上，則需要了解選型是否合理、是否是分布式架構(gòu)、是否更應(yīng)該選用微服務(wù)架構(gòu)等問題。如果具體到非功能特性，也有以下這些原則或規(guī)律可循。

性能：一般在設(shè)計(jì)上會(huì)考慮分層架構(gòu)、分布式架構(gòu)、（文件）系統(tǒng)緩存機(jī)制、輪詢式任務(wù)分配、數(shù)據(jù)服務(wù)器和應(yīng)用服務(wù)器分離、數(shù)據(jù)分片和數(shù)據(jù)讀寫分離、CDN 等措施，比如，現(xiàn)在普遍采用的 CDN（Content Delivery Network，內(nèi)容分發(fā)網(wǎng)絡(luò)）技術(shù)，能夠?qū)⒄军c(diǎn)內(nèi)容發(fā)布至遍布全國的海量加速節(jié)點(diǎn)，使其用戶可就近獲取所需內(nèi)容，避免網(wǎng)絡(luò)擁堵、地域、運(yùn)營商等因素帶來的訪問延遲問題，有效提升訪問速度、降低響應(yīng)時(shí)間，獲得流暢的用戶體驗(yàn)。

安全性：數(shù)據(jù)和系統(tǒng)的分離、將系統(tǒng)權(quán)限和數(shù)據(jù)權(quán)限分別設(shè)置、基于角色的訪問控制設(shè)計(jì)等都可以提高系統(tǒng)的安全性。如圖 1 所示，設(shè)計(jì)中間層可以隔離客戶對所存儲(chǔ)數(shù)據(jù)的直接訪問，以進(jìn)一步保護(hù)數(shù)據(jù)庫的安全性。

可靠性：采用多節(jié)點(diǎn)分布式體系架構(gòu)，這樣單個(gè)節(jié)點(diǎn)失效不會(huì)造成整個(gè)系統(tǒng)失效，從而確保系統(tǒng)的可靠性。而且，負(fù)載也能平衡地分布在不同節(jié)點(diǎn)上，不會(huì)像單體系統(tǒng)受到集中式負(fù)載壓力沖擊而引起類似“拒絕服務(wù)（DoS）”的問題，以保證服務(wù)的可用性。

可擴(kuò)展性：區(qū)分可變和不可變業(yè)務(wù)，采用多層分布體系架構(gòu)，基于不同的組件或?qū)哟螢椴煌臉I(yè)務(wù)提供開放的服務(wù)接口（API、SDK），并盡可能簡化架構(gòu)，降低模塊間的耦合性等。

有層次的（組件）評審

在整體評審?fù)ㄟ^后，我們會(huì)繼續(xù)就系統(tǒng)的各個(gè)層次或各個(gè)組件進(jìn)行更為細(xì)致的評審，逐層往前推進(jìn)。

UI 層是否采用了類似 GWT（Google Web 工具包）的 Web 2.0 用戶界面框架，從而能夠支持 Firefox、IE、Safari、Google Chrome 等瀏覽器的最新版本，以及是否適用基于 JQuery Mobile 的移動(dòng)設(shè)備、WebDAV 和 CIFS 協(xié)議等。

API 層，檢查是否支持 OASIS 開放標(biāo)準(zhǔn)的 CMIS（Content Management Interoperability Services）協(xié)議，即是否允許使用 Web 協(xié)議互連，并控制各種文檔管理系統(tǒng)和存儲(chǔ)庫；檢查是否支持 OpenAPI 標(biāo)準(zhǔn)，能否通過 Web 服務(wù)（SOAP）和 REST 提供完整的、開放的 API，從而實(shí)現(xiàn)與第三方應(yīng)用程序的集成；檢查是否提供了用于 Java、.NET 和 PHP 等二次開發(fā)的 SDK。

安全層，涉及用戶身份的驗(yàn)證、注冊用戶和用戶訪問權(quán)限的管理、安全控制等。如圖 1 所示，該架構(gòu)采用了 Spring Security 實(shí)現(xiàn)基于用戶的憑據(jù)集中管理用戶的訪問權(quán)限、通過 Access Manager 模塊實(shí)現(xiàn)安全控制、通過 CAS（Authentication Centralized Service）服務(wù)實(shí)現(xiàn)身份驗(yàn)證等。

存儲(chǔ)模塊是否足夠安全、可靠和開放。圖 1 的系統(tǒng)架構(gòu)使用了 Hibernate 進(jìn)行 OMR（Object Relation Mapping）數(shù)據(jù)映射，并能支持不同的關(guān)系數(shù)據(jù)庫，而整個(gè)元數(shù)據(jù)層則存儲(chǔ)在 DBMS 數(shù)據(jù)庫中。

其他組件，比如搜索引擎、目錄和元數(shù)據(jù)等組件設(shè)計(jì)是否合理，如果選擇第三方開源產(chǎn)品，那么它是否是成熟的組件？屬于哪一類開源許可協(xié)議？有沒有法律風(fēng)險(xiǎn)等？

接口定義的評審

架構(gòu)評審?fù)曛?，就需要深入到各個(gè)組件詳細(xì)設(shè)計(jì)的評審，而在這之前，需要針對接口詳細(xì)設(shè)計(jì)文檔進(jìn)行評審，這也是值得我們特別關(guān)注的，因?yàn)榻涌陉P(guān)系到每個(gè)開發(fā)人員能否相對獨(dú)立、高效的工作，關(guān)系到之后眾多組件能否集成為可正常運(yùn)行的系統(tǒng)。

接口也分為多種，比如資源接口、操作接口和頁面接口。前面兩種接口相對簡單，要求按照 RESTful 方式定義即可，而對頁面可能會(huì)涉及太多接口，不能一個(gè)個(gè)地調(diào)用， 這樣會(huì)導(dǎo)致系統(tǒng)性能比較差，嚴(yán)重影響用戶體驗(yàn)。所以我們需要在后臺把數(shù)據(jù)處理好，然后形成一個(gè)聚合型接口提供給前端來使用。

從接口定義看，要求遵循 RESTful 風(fēng)格、采用 UTF-8 統(tǒng)一接口編碼方式，接口應(yīng)具備可擴(kuò)展性，接口拆分合理、粒度合適，接口描述清晰、一致，標(biāo)注請求方式并能區(qū)分 GET、POST 等不同方式的應(yīng)用場景，比如獲取數(shù)據(jù)用 GET，新增 / 修改 / 發(fā)送數(shù)據(jù)用 POST；接口地址（URL）使用相對路徑，從而盡量減少參數(shù)傳遞；參數(shù)命名準(zhǔn)確并符合統(tǒng)一的命名規(guī)則，同時(shí)標(biāo)注參數(shù)數(shù)據(jù)類型、值域范圍、是否可為空等；接口必須提供明確的數(shù)據(jù)狀態(tài)信息、統(tǒng)一的標(biāo)識調(diào)用狀態(tài)（無論成功還是失?。?/p>

從接口性能看，數(shù)據(jù)格式采用 JSON 格式比 XML 好，這是因?yàn)樗臄?shù)據(jù)量少，而且盡量按需傳遞數(shù)據(jù)，前端需要什么數(shù)據(jù)就返回什么數(shù)據(jù)。為了更好的性能，還要設(shè)置緩存機(jī)制，包括文件緩存、Memcache 緩存等。

從安全性看，包括驗(yàn)證簽名機(jī)制、接口訪問授權(quán)機(jī)制、數(shù)據(jù)傳輸加密、客戶端身份驗(yàn)證和時(shí)間戳驗(yàn)證等，包括選用合適且安全的算法。對于核心數(shù)據(jù)的 ID 字段, 不要使用自增的數(shù)字類型, 而使用 Hash 算法產(chǎn)生隨機(jī)的字符串類型，避免核心數(shù)據(jù)被輕易抓取等。

設(shè)計(jì)的可測試性

可測試性不僅要從需求開始抓，設(shè)計(jì)環(huán)節(jié)也同樣重要，人們經(jīng)常提到“可測試性設(shè)計(jì)（Design for Testability，DFT）”、“設(shè)計(jì)驅(qū)動(dòng)開發(fā)（Design-Driven Development，DDD）”。通過設(shè)計(jì)可以確保系統(tǒng)結(jié)構(gòu)的簡單性、可觀察性和可控制性，如 MVC 設(shè)計(jì)模式、接口單一性、各個(gè)模塊有明確的接口定義等。在設(shè)計(jì)上改善軟件的可測試性，主要是通過設(shè)立觀察點(diǎn)、控制點(diǎn)、驅(qū)動(dòng)裝置、隔離裝置等來實(shí)現(xiàn)。

1. 測試驅(qū)動(dòng)設(shè)計(jì)方法，比如先確定驗(yàn)收測試用例，再設(shè)計(jì)具體的功能；先確定性能、可靠性等測試用例，再考慮如何實(shí)施架構(gòu)設(shè)計(jì)，以滿足不同特性的要求。

1. 選用開放、先進(jìn)而成熟的設(shè)計(jì)模式和框架，在一定程度上能保證系統(tǒng)結(jié)構(gòu)的低耦合性、單一的依賴關(guān)系，具有較高的可測試性。

1. 可控制性設(shè)計(jì)，包括業(yè)務(wù)流程、模塊、場景、全局變量、接口等的可控制性設(shè)計(jì)，即在外部提供適當(dāng)?shù)姆椒?、途徑，直接或間接地來控制相應(yīng)的模塊、全局變量和接口等。這些途徑可能包括設(shè)立 XML 配置文件、暴露 API 接口、統(tǒng)一接口等操作。

1. 數(shù)據(jù)顯示與控制分離，通過分層，增加了系統(tǒng)的可觀察性和可控制性。這樣，就可以通過接口調(diào)用，分別完成相應(yīng)的業(yè)務(wù)邏輯、數(shù)據(jù)處理等的測試。

1. 遵守設(shè)計(jì)原則（如接口隔離原則），并針對模塊，盡量分解到相對穩(wěn)定、規(guī)模合適的程度，以確保模塊的獨(dú)立性和穩(wěn)定性，有利于獨(dú)立開展對模塊的測試活動(dòng)。

1. 設(shè)計(jì)易理解性，包括明確的設(shè)計(jì)標(biāo)準(zhǔn)、規(guī)范的設(shè)計(jì)文檔、明確的接口及其參數(shù)的定義，使設(shè)計(jì)有據(jù)可依，層次清晰，設(shè)計(jì)文檔易讀。

關(guān)于設(shè)計(jì)評審就介紹到這里，總結(jié)一下這一講的內(nèi)容，概括為下列 4 個(gè)要點(diǎn)：

• 非功能性的質(zhì)量在很大程度上取決于系統(tǒng)的設(shè)計(jì)質(zhì)量，在設(shè)計(jì)評審時(shí)，我們要善于質(zhì)疑和提問，不僅能獲得更好的可測試性，而且也能及時(shí)發(fā)現(xiàn)設(shè)計(jì)上的缺陷。

• 設(shè)計(jì)評審先從整體架構(gòu)設(shè)計(jì)評審開始，把握全局質(zhì)量，包括系統(tǒng)的性能、安全性、可靠性等，再分層評審，逐步深入到各個(gè)組件的評審。

• 今天面向接口的設(shè)計(jì)和編程占比越來越大，微服務(wù)架構(gòu)也逐漸流行，要加強(qiáng)對接口設(shè)計(jì)文檔的評審，接口設(shè)計(jì)評審要關(guān)注的細(xì)節(jié)還比較多，需要認(rèn)真對待。

• 設(shè)計(jì)上還有一些更好的理念，如 DFT、DDD 等，值得提倡和實(shí)踐。

最后給你出一個(gè)思考題：在架構(gòu)設(shè)計(jì)評審中，性能、可靠性、安全性等之間也存在著一定的沖突，比如提高安全性可能會(huì)降低性能。關(guān)于這方面的沖突，你有具體的例子嗎？如何解決？文章來源地址http://www.zghlxwxcb.cn/news/detail-421884.html

到了這里，關(guān)于高效的敏捷測試第九課 ATDD、需求分析、需求評審和設(shè)計(jì)評審的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！