本文來(lái)自作者 何勉 在 GitChat 上精彩分享， 「閱讀原文」看看大家與作者交流了哪些問(wèn)題
【不要錯過(guò)文末彩蛋】
編輯 | 強東
「產(chǎn)品開(kāi)發(fā)中如果只有一件最困難的事，那就是精確的決定做什么」，《人月神話(huà)》的作者布魯克斯如是說(shuō)?！感枨蟆箯膩?lái)都是產(chǎn)品開(kāi)發(fā)的重點(diǎn)和難點(diǎn)，對精益和敏捷產(chǎn)品開(kāi)發(fā)也不例外。
許多精益敏捷實(shí)施的失敗，在實(shí)踐層面 [1] 都根源于缺乏有效的需求實(shí)踐。實(shí)例化需求是我所知道的兩個(gè)投入產(chǎn)出比最高的敏捷和精益需求實(shí)踐之一 [2] ，它能有效解決精益敏捷實(shí)施中的需求的分析、澄清和拆分等問(wèn)題。
本文的主旨是幫助大家，第一：理解實(shí)例化需求，介紹實(shí)例化需求的 Why 和 What；第二：實(shí)施實(shí)例化需求，介紹實(shí)例化需求的 Who，When 和 How。如此 4W1H，幫助大家掌握這一高效的精益和敏捷需求實(shí)踐，并落實(shí)驗收測試驅動(dòng)開(kāi)發(fā)（ATDD）方法。
為了理解實(shí)例化需求，我們將從實(shí)例化需求的目標（why）和核心概念（what）講起。
實(shí)例化需求的目標可以概括為四個(gè)字——以終為始（Begin with the End in Mind）?！敢越K為始」是《高效能人士的7個(gè)習慣》一書(shū)中的第二個(gè)習慣，指在開(kāi)始一件事情之前，先明確其目標，再努力實(shí)現之。
對應產(chǎn)品開(kāi)發(fā)，它指：開(kāi)始開(kāi)發(fā)前，充分澄清需求，明確其驗收標準，并保證相關(guān)人員對需求的一致理解。
「以終為始」的反面是「GIGO」——Garbage In， Garbage Out（輸入的是垃圾，輸出垃圾）。這恰恰是很多精益敏捷實(shí)施的現狀，極大影響團隊交付的質(zhì)量、節奏和最終業(yè)務(wù)成果。
敏捷開(kāi)發(fā)團隊中普遍以“用戶(hù)故事”承載需求。
用戶(hù)故事有兩個(gè)核心作用：
1）它是交付的單元。用戶(hù)故事應該是足夠小的、端到端的可交付單元，基于它可以組織和規劃迭代或持續交付；
2）它是溝通的載體。與傳統的需求表述方式不同，用戶(hù)故事中并不包含需求的詳細信息，它只是對未來(lái)進(jìn)一步溝通的承諾。
極限編程的發(fā)明人之一Ron Jefferise 用 3Cs（Card，Conversation，Confirmation）來(lái)形容用戶(hù)故事。
用戶(hù)故事卡片（Card）上的內容有限，更多的信息依賴(lài)于未來(lái)的溝通（Conversation），并最終確認（Confirmation）。
問(wèn)題是如何才能有效溝通？確認什么？怎么確認？這是困擾很多敏捷開(kāi)發(fā)團隊的問(wèn)題。傳統的需求分析問(wèn)題，在精益和敏捷開(kāi)發(fā)中依然存在。
實(shí)例化需求既要解決傳統上需求分析的問(wèn)題，又要適應迭代和持續交付的模式，更加高效、有效和持續地溝通需求，做到“以終為始”。
以終為始是目標，那實(shí)例化需求具體包含什么內容呢？實(shí)例化需求的英文是 Specification by Example，簡(jiǎn)稱(chēng) SBE，直譯過(guò)來(lái)就是用實(shí)例說(shuō)明需求。
為什么要用實(shí)例來(lái)說(shuō)明需求？讓我們從需求溝通中的一個(gè)最常見(jiàn)誤區——知識的詛咒——說(shuō)起。
知識的詛咒是指：人們在溝通時(shí)會(huì )不自覺(jué)地假設別人擁有和自己一樣的背景知識，造成溝通的困難和誤解。在陌生的地方問(wèn)路，經(jīng)常體會(huì )到「知識的詛咒」。
上圖中，當地人告訴你：「噢，那家旅館啊，前面左拐就到了」。但事實(shí)上，你需要走到第三個(gè)路口再左拐，然后穿過(guò)一個(gè)街區，再從巷口進(jìn)去才是。
并不是當地人不夠友善，而是他太熟悉這里了，不自覺(jué)地假設別人也有同樣的背景知識，這就是典型的“被自己的知識詛咒”，而影響了與他人的溝通。
「知識的詛咒」在需求溝通中時(shí)常發(fā)生。我們經(jīng)常會(huì )看到這樣的場(chǎng)景，需求交付后，才發(fā)現場(chǎng)景的遺漏，或規則的錯誤。
對此，開(kāi)發(fā)人員抱怨：「需求說(shuō)明中并沒(méi)有說(shuō)要考慮余額不足啊」，或者說(shuō)：「從來(lái)沒(méi)人告訴我還有這種類(lèi)型的交易啊」。
而業(yè)務(wù)人員卻說(shuō)：「這不是很明顯嗎？」。業(yè)務(wù)人員口中明顯的事，對開(kāi)發(fā)和測試人員可不一定。
為避免需求溝通過(guò)程中的「知識詛咒」，“實(shí)例化需求”方法從場(chǎng)景出發(fā)，以用戶(hù)的操作實(shí)例來(lái)澄清需求。
相比一般的規格說(shuō)明，實(shí)例更加場(chǎng)景化，能夠激發(fā)參與和深度討論；同時(shí)，實(shí)例是具體的，其典型形式是：「在什么情況下，做什么操作，會(huì )得到什么結果」?；诰唧w的實(shí)例，更加便于溝通中的雙向確認，保證理解的一致和場(chǎng)景覆蓋。
上圖是對實(shí)例化需求的概念說(shuō)明。
用例子來(lái)分析和澄清需求。
這些例子隨后會(huì )轉化為測試用例。
最后再通過(guò)測試驗證需求。
如此形成閉環(huán)，這個(gè)三角是實(shí)例化需求的核心概念。
綜合以上的內容，可以用一句化來(lái)定義實(shí)例化需求：
基于用戶(hù)使用的實(shí)例分析和澄清需求，做到“以終為始”，為其后的持續需求交付提供高質(zhì)量的輸入。
概念并不復雜，而讓實(shí)例化需求真正不同的是其實(shí)施過(guò)程的有效性。接下來(lái)將介紹實(shí)例化需求的實(shí)施，具體包含：Who：誰(shuí)參與，When：什么時(shí)間做，How：步驟和方法。
管理學(xué)大師德魯克曾說(shuō)：「每一次信息傳遞會(huì )使信息減半，而噪音加倍」[3]，德魯克稱(chēng)之為信息學(xué)第一原理。
綜藝節目中的傳話(huà)游戲，常利用這一現象制造歡樂(lè )效果。在產(chǎn)品開(kāi)發(fā)中，需求在逐級傳遞中同樣會(huì )不斷丟失信息和引入噪音，只不過(guò)它一點(diǎn)不歡樂(lè )，反而是很多誤解和信息遺漏的根源。
在「實(shí)例化需求」中，開(kāi)發(fā)、測試和業(yè)務(wù)人員一起溝通需求，避免信息傳遞的噪音和損耗。
如上圖所示，開(kāi)發(fā)、測試和業(yè)務(wù)三個(gè)角色是實(shí)例化需求的參與者，當然條件不具備時(shí)，業(yè)務(wù)可能是業(yè)務(wù)方的代表，比如業(yè)務(wù)分析師或系統分析師等。
通常開(kāi)發(fā)、測試和業(yè)務(wù)會(huì )在足夠大的白板或墻面前直接分析和溝通需求，上圖是實(shí)例化需求溝通過(guò)程中的典型產(chǎn)出。
實(shí)例化需求是適合精益和敏捷開(kāi)發(fā)的需求分析方法。與精益和敏捷所倡導的持續交付相對應，實(shí)例化需求應該持續和小批量的進(jìn)行。這帶來(lái)如下的好處：
接近實(shí)現階段，此時(shí)團隊擁有決策所需的最充分和最新鮮的信息，更能做出正確的決策，等開(kāi)始實(shí)現時(shí)信息的保真度也足夠。
因為很快就要實(shí)現，團隊也會(huì )更加專(zhuān)注和投入，溝通更加充分。
即時(shí)進(jìn)行，能夠體現最新的變化，提高了對外響應的靈活性。
即時(shí)小批量的溝通是指導原則，具體到使用Scrum或看板方法的團隊，則對應不同的活動(dòng)。
如上圖所示，Scurm團隊會(huì )在Sprint計劃會(huì )議上澄清和承諾需求，這時(shí)進(jìn)行實(shí)例化需求活動(dòng)是較為合適的。同時(shí)，很多團隊會(huì )引入產(chǎn)品待辦事項的梳理（Product Backlog Refinement）機制，在當前Sprint的某個(gè)時(shí)間點(diǎn)梳理下個(gè)Sprint的內容。這時(shí)，在待辦事項梳理會(huì )議上進(jìn)行實(shí)例化需求活動(dòng)更適合。
使用看板方法的團隊，通常會(huì )進(jìn)行有節奏的就緒隊列填充，這也是團隊的計劃活動(dòng)。
所謂「就緒」是指：需求已經(jīng)準備好，可以開(kāi)始實(shí)現了。如上圖所示，在就緒隊列填充前進(jìn)行實(shí)例化需求活動(dòng)，可以幫助團隊分析、澄清、一致理解需求，并定義驗收標準，做到名副其實(shí)的「就緒」。
接下來(lái)介紹如何組織實(shí)例化需求活動(dòng)。需求的分析和澄清本質(zhì)上是在挖掘和梳理需求的信息，并合理澄清和組織它們。下面，我們將從理清需求的信息結構出發(fā)，來(lái)組織實(shí)例化需求的實(shí)施步驟。
需求的組織和溝通要符合 MECE 原則
不管問(wèn)多少麥肯錫校友（麥肯錫的員工和前員工），麥肯錫解決問(wèn)題的方法中，哪些他們映像最深刻，答案都是MECE，MECE，MECE?！?摘自《麥肯錫方法》
「MECE，MECE，MECE」重要的事情說(shuō)三遍，MECE 是麥肯錫方法的最核心原則，它是思考、分析也是溝通和表達問(wèn)題的邏輯。
MECE 原則指出觀(guān)點(diǎn)和事實(shí)的表達，在各個(gè)層次上都要做到：
1）條目之間相互獨立（Mutually Exclusive），通俗的講就是要“分清”各個(gè)條目，做到無(wú)重疊；
2）這些條目作為一個(gè)整體要完全窮舉（ Collectively Exhaustive），也就是要“分凈”，做到無(wú)遺漏。這兩點(diǎn)合起來(lái)就是所謂 ME-CE。
MECE 原則最早由芭芭拉.明拓在《金字塔原理》一書(shū)中提出的。問(wèn)題的分析和表達符合 MECE 原則，就會(huì )呈現出金字塔結構——每個(gè)層次的的抽象級別清晰一致，各個(gè)層次向下逐漸明晰。
如上圖所示，如果符合 MECE 原則，需求的信息也會(huì )呈現金字塔結構。
金字塔的頂端是需求的目標，也就是解決什么用戶(hù)或業(yè)務(wù)問(wèn)題？以及與之相關(guān)的上下文。
金字塔的中間層次是操作和操作流程，為了實(shí)現上面目標，系統需要支持哪些用戶(hù)操作？這些操作的流程是什么樣的？
金字塔的底層是業(yè)務(wù)規則，各個(gè)操作步驟對應的業(yè)務(wù)規則是什么樣的？
以上三個(gè)層次自頂向下，逐漸明晰，形成的金字塔信息結構，確保信息的清晰、完整和一致性。
為了提高溝通的效率和效果，團隊還應該在需求的分析和溝通過(guò)程中，持續構建和精化領(lǐng)域模型，并把領(lǐng)域模型作為溝通的統一語(yǔ)言。
領(lǐng)域模型是對領(lǐng)域中的概念或現實(shí)世界的對象的可視化表示，被被認為是面向對象分析最重要的產(chǎn)出。
領(lǐng)域模型雖不是實(shí)例化需求的必選項，但它能讓需求的溝通和澄清事半功倍，讓團隊快速就問(wèn)題域達成一致理解和高效溝通。
領(lǐng)域模型的構建和精化還為領(lǐng)域驅動(dòng)設計（Domain Driven Design）和微服務(wù)（Micro-Service）的實(shí)施提供輸入。它是今天的技術(shù)環(huán)境下，團隊應該掌握和嫻熟應用的技能。關(guān)于領(lǐng)域模型，后面還會(huì )更詳細介紹。
實(shí)例化需求活動(dòng)的步驟
需求的信息結構為實(shí)例化需求的實(shí)施步驟提供了指導。上圖是我在實(shí)施實(shí)例需求時(shí)常用的組織步驟，它與需求的信息金字塔結構是一致的。下面將逐一介紹這些步驟。
第一步：澄清價(jià)值
實(shí)例化需求的第一步“澄清價(jià)值，它包含兩個(gè)子步驟：
描述背景。也就是需求的業(yè)務(wù)背景和系統的上下文。這一步形式相對自由。上面的示例圖中，我使用了面向對象分析中的常用的系統上下文圖（SCD，System Context Diagram），定義了系統的邊界、所處的環(huán)境以及主要組成部分，你也可以使用更自由的線(xiàn)框圖來(lái)表達系統的上下文。
系統上下文相對穩定，并不需要對每個(gè)需求重復這樣描述，只要在必要時(shí)(比如發(fā)生變化時(shí))，做出澄清就可以了。
澄清用戶(hù)問(wèn)題和業(yè)務(wù)目標。需求最終要解決用戶(hù)的問(wèn)題，從而實(shí)現產(chǎn)品的業(yè)務(wù)目標。因此，在討論具體的需求前，我們還要澄清用戶(hù)是誰(shuí)，要解決他們什么問(wèn)題。
針對目標和問(wèn)題的典型挑戰性檢驗是：如果不做這個(gè)需求會(huì )怎么樣？有沒(méi)有其它替代方法？認真回答上面兩個(gè)問(wèn)題，往往能挖掘出需求的本質(zhì)，確保我們在解決的是真正的用戶(hù)或業(yè)務(wù)問(wèn)題。
第二步：列出操作并明確操作步驟
明確目標后，接下來(lái)就是分析為實(shí)現這一目標，產(chǎn)品所要支持的功能。實(shí)例化需求的第二步是：列舉產(chǎn)品要支持的用戶(hù)操作，并描述它們的流程。具體分為兩個(gè)子步驟。
列出用戶(hù)的操作。產(chǎn)品的功能體現為它所支持的用戶(hù)操作，列出用戶(hù)操作，可以涵蓋其功能性需求。在上圖中，我們通過(guò)用例圖描述了用戶(hù)的操作。
用例圖定義了為完成特定目標，操作者和系統之間的交互，它包含操作者和操作兩個(gè)部分。
用例是需求工程中獲取和列舉功能需求最常用的手段之一。如果不習慣用例的表示法，更簡(jiǎn)單的方法是直接列出用戶(hù)和用戶(hù)的操作。
畫(huà)出用戶(hù)操作的流程步驟。這一步的目的是：定義操作的具體交互流程。上圖使用了活動(dòng)圖和時(shí)序圖兩種形式，來(lái)表達操作步驟。
其中，活動(dòng)圖形式上與流程圖類(lèi)似，只不過(guò)它表達的是用戶(hù)操作流程，而不是技術(shù)實(shí)現流程；
時(shí)序圖則在表達系統間的交互方面更勝一籌，例如針對金融類(lèi)系統的需求，可以用時(shí)序圖表示系統間的資金往來(lái)和記錄存取等。
這兩種表示法，都表示了操作的步驟，團隊應該靈活選取適合的表達方式，當然也可以選取其它表示法如帶泳道的活動(dòng)圖、通信圖、狀態(tài)機等。
針對操作和步驟的典型挑戰性檢驗是：這些操作能解決識別出的用戶(hù)問(wèn)題并實(shí)現業(yè)務(wù)目標嗎？操作步驟合理嗎？操作流程可以更簡(jiǎn)單嗎？認真應對這些的挑戰，將確保功能和操作的合理性、簡(jiǎn)單性和完整性。
第三步：列出業(yè)務(wù)規則
實(shí)例化需求的最重要輸出是需求驗收標準，它們可以表達為一條條的業(yè)務(wù)規則。上一步，我們已經(jīng)列出了操作和操作步驟，用它們來(lái)組織業(yè)務(wù)規則非常合適，對于操作中的主要步驟，團隊可以列出它們的業(yè)務(wù)規則。
最常見(jiàn)的業(yè)務(wù)規則可以表達為三段式的結構，也就是「Given（當），When（如果），Then（那么）」。比如：
當用戶(hù)是 VIP 會(huì )員時(shí)，如果其購買(mǎi)金額為100元，那么運費為0元。
當用戶(hù)是 VIP 會(huì )員時(shí)，如果其購買(mǎi)金額為99元，那么運費為0元。
當用戶(hù)是普通會(huì )員時(shí)，如果其購買(mǎi)金額為100元，那么運費為0元。
當用戶(hù)是 VIP 會(huì )員時(shí)，如果其購買(mǎi)金額為99元，那么運費為10元。
實(shí)例的形式表達場(chǎng)景和業(yè)務(wù)規則，這是”實(shí)例化需求“這個(gè)詞的來(lái)源。之前對用戶(hù)操作步驟的分析，正好可以用來(lái)組織這些實(shí)例。上圖所示，正是按操作步驟分別列舉對應的實(shí)例（業(yè)務(wù)規則）。
這些實(shí)例可以用條目化的方式表達。同時(shí)，當規則組合較多時(shí)，可以將他們抽取為數據表格。上圖中關(guān)于”共同貸款人審查“這一步驟的規則，就被抽象成了表格。這一方面讓規則更清晰和易于理解；另一方面，將來(lái)表格在映射為測試用例時(shí)，能自然的做到測試流程和測試數據分離，更易于閱讀、維護和擴展。
以上列出的都是功能性的需求和規則。在實(shí)際過(guò)程中可能還會(huì )涉及非功能性需求，如可用性、可靠性、性能、安全性等。非功能性需求大部分體現在系統級別，而實(shí)例化需求針對的是單個(gè)需求。實(shí)例化需求過(guò)程中，一般只需要列出與特定功能相關(guān)的非功能性需求，如針對某一特定操作的特定安全性和性能要求。
針對業(yè)務(wù)規則的典型挑戰性檢驗是：相關(guān)業(yè)務(wù)規則考慮全面嗎？特殊情況，異?；蝈e誤處理包含了嗎？是否考慮了不同用戶(hù)、數據和操作類(lèi)別？認真應對以上的挑戰，將確保規則的完整性，以及產(chǎn)品交互細節的合理性。
持續的活動(dòng)：在進(jìn)行以上三個(gè)步驟的同時(shí)，持續構建和精化領(lǐng)域模型
以上介紹了實(shí)例化需求的三個(gè)主要步驟。與這三個(gè)步驟并行，團隊還應該在需求分析和澄清過(guò)程中，持續梳理和澄清所分析領(lǐng)域的概念，建立統一的認知，形成需求溝通的統一語(yǔ)言。領(lǐng)域模型是承載這一目標的最佳載體。
使用 UML（統一建模語(yǔ)言）表示法，領(lǐng)域模型體現為不包含操作的類(lèi)圖[4]，領(lǐng)域模型由三個(gè)要素構成：
領(lǐng)域中的實(shí)體對象（如: 房產(chǎn)，房主等）和概念（如：交易，按揭方案等）。
對象或概念間的關(guān)系。如：房主擁有房產(chǎn)等，”擁有“就是房主與房產(chǎn)之間的關(guān)系。
這些對象或概念所包含的屬性。如：房產(chǎn)的屬性包含房齡、價(jià)格、面積等。
領(lǐng)域模型又被稱(chēng)為術(shù)語(yǔ)表和概念詞典。理論上，純文本描述也能達到統一概念和認知的作用。
不過(guò)我強烈的建議使用 UML 類(lèi)圖來(lái)表示，一方面它的表達能力更強，形成的可視化的概念詞典更加簡(jiǎn)潔直觀(guān)，也方便溝通和演進(jìn)。
同時(shí)，良好的領(lǐng)域模型為 DDD 的實(shí)施提供了基礎，是分析和設計之間過(guò)渡的橋梁，為 DDD 中的子域和微服務(wù)中的服務(wù)的劃分提供了業(yè)務(wù)依據。
如上圖所示，領(lǐng)域模型是對分析領(lǐng)域的描述，屬于需求分析中的靜態(tài)視圖；而操作和操作流程屬于系統的動(dòng)態(tài)視圖。
在需求分析中，靜態(tài)視圖和動(dòng)態(tài)視圖相互印證，將極大提高需求分析和澄清的效率，以及其輸出的準確性和覆蓋。
靜態(tài)模型和動(dòng)態(tài)模型相互印證，這是需求分析方法的精髓所在，不管是傳統的需求分析方法，還是適合精益和敏捷的需求分析方法，都是如此。
實(shí)例化需求活動(dòng)上，業(yè)務(wù)、開(kāi)發(fā)和測試人員通過(guò)實(shí)例澄清小批量的需求，澄清過(guò)程通常符合金字塔結構，在目標、操作和業(yè)務(wù)規則這三個(gè)層面，逐漸明晰，解決相應的挑戰：
目標層面：目標是什么？不做這個(gè)需求會(huì )怎么樣？
操作層面：通過(guò)哪些操作來(lái)實(shí)現這些目標？操作步驟合理嗎？還可以更簡(jiǎn)化嗎？
業(yè)務(wù)規則層面：和操作相關(guān)的業(yè)務(wù)規則都考慮了嗎？特殊情況，異?；蝈e誤處理包含了嗎？是否涵蓋了不同的業(yè)務(wù)、數據和接口類(lèi)型？
解決以上問(wèn)題，保障了需求目標的清晰、交互流程的簡(jiǎn)單合理、業(yè)務(wù)規則的完整覆蓋，并讓業(yè)務(wù)、開(kāi)發(fā)和測試對需求形成一致理解。
特別是基于共同領(lǐng)域模型的溝通，靜態(tài)和動(dòng)態(tài)視圖相互印證進(jìn)一步確保了需求的質(zhì)量。
作為副產(chǎn)品，實(shí)例化需求還起到了需求拆分的作用。在實(shí)施精益敏捷產(chǎn)品開(kāi)發(fā)過(guò)程中，需求拆分是許多團隊面臨的難題。
之所以需求拆分困難，是因為它要做到：
足夠?。哼@樣才能保障迭代或持續交付。
端到端，這樣才能保證交付有意義的價(jià)值。
相對獨立，這樣才便于迭代和交付的靈活安排。
拆分完還能看到整體的結構。
采用實(shí)例化需求，以上要求往往能順便達成，需求會(huì )被自動(dòng)的分解成一個(gè)個(gè)小的獨立的操作，從用戶(hù)角度的分析也保證了這些拆分后的需求是端到端且可交付的。
實(shí)例化需求和驗收測試驅動(dòng)開(kāi)發(fā)是一對近義詞。字面上，實(shí)例化強調需求澄清活動(dòng)，而驗收測試驅動(dòng)開(kāi)發(fā)則關(guān)注整個(gè)過(guò)程。
但兩者的目標是一致的，都是要做到「以終為始」，實(shí)例化需求落實(shí)到位，驗收測試驅動(dòng)開(kāi)發(fā)則水到渠成。
上圖反映了某個(gè)產(chǎn)品團隊的驗收測試驅動(dòng)開(kāi)發(fā)過(guò)程。正如前面實(shí)例化需求的概念三角中所表達的：
在就緒隊列填充前，團隊通過(guò)實(shí)例化需求活動(dòng)產(chǎn)生實(shí)例。
實(shí)現過(guò)程中，團隊將這些實(shí)例自動(dòng)化，功能實(shí)現和自動(dòng)化測試開(kāi)發(fā)同步完成。
實(shí)現完成后，團隊用已經(jīng)完成的自動(dòng)化測試來(lái)驗收這些需求。這個(gè)循環(huán)就是驗收測試驅動(dòng)開(kāi)發(fā)循環(huán)。
上圖中，團隊選用了 RobotFramework [5]作為驗收測試的自動(dòng)化工具，他們做了接口自動(dòng)化測試100%覆蓋率，并輔以少量的端到端的界面自動(dòng)測試。
在開(kāi)發(fā)過(guò)程中，自動(dòng)功能和單元測試的回歸是持續進(jìn)行的，而交付新功能后，團隊會(huì )用新開(kāi)發(fā)的自動(dòng)測試進(jìn)行基本的功能驗收，而后再開(kāi)始快速的手動(dòng)驗證。
聯(lián)系客服
