簡介一種標準的需求規(guī)格說明書(SRS)模板面向軟件項目團隊適用于項目經(jīng)理、需求分析師、開發(fā)工程師和測試工程師快速撰寫規(guī)范化需求文檔。模板內(nèi)容覆蓋引言、任務概述、需求規(guī)定、運行環(huán)境規(guī)定等核心章節(jié)其中引言細分為編寫目的、背景、定義、參考資料需求規(guī)定包含功能規(guī)定、性能規(guī)定、輸入輸出要求、數(shù)據(jù)管理能力要求、故障處理要求和其他專門要求并在性能規(guī)定下細化精度、時間特性要求與靈活性運行環(huán)境規(guī)定涵蓋設備與支持軟件。文檔已預設章節(jié)標題與目錄層級使用者只需替換具體描述即可能幫助團隊統(tǒng)一文檔結構、減少遺漏。資源為單個doc文件大小約61KB輕量易用。已有3400余人學習下載是項目初期規(guī)范需求描述、推進設計評審的實用工具。1. 提到「軟件需求規(guī)格說明書模板SRS」大多數(shù)團隊的第一反應是模板有什么好寫的找個現(xiàn)成的改改不就完了。但現(xiàn)實是一套能真正驅動開發(fā)、測試和驗收的SRS模板比多數(shù)人想象的要難設計得多。寫SRS這件事很多團隊的打開方式就錯了項目啟動時趕一份文檔應付立項評審評審一過就再沒人翻等開發(fā)做完了再補一份交差。真正的軟件需求規(guī)格說明書SRS應該回答一個問題——這份軟件到底要做什么做到什么程度算好。它服務的不是評審委員會而是三撥人三個月后接手代碼的開發(fā)、寫測試用例的測試、以及驗收時跟你扯皮的用戶。這篇不打算講虛的直接給一份能落地、能評審、能追蹤的SRS模板寫法以及我在多個項目里踩過的坑。新手照章填內(nèi)容熟手對照查漏項。2. 寫SRS前先想清楚讀者、邊界與需求分級2.1 先定讀者開發(fā)、測試、驗收誰是這份文檔的最終用戶很多團隊在動筆前沒有回答一個基本問題這份SRS的讀者是誰。讀者不同文檔的語言風格、詳細程度、甚至章節(jié)側重都會完全不同。如果讀者是開發(fā)團隊功能需求部分要寫到每條業(yè)務規(guī)則都能直接對應到代碼邏輯如果讀者包含客戶或業(yè)務方術語要少用每個功能塊前面最好有一段白話描述讓不懂技術的人也能讀懂業(yè)務閉環(huán)。我的做法是文檔開頭先用一小節(jié)寫明目標讀者后面再統(tǒng)一按最苛刻的讀者來寫——通常是最較真的那個測試工程師。原因很簡單測試是唯一會把文檔里每個字摳出來逐條驗證的人。開發(fā)看需求時可能會憑經(jīng)驗腦補業(yè)務方看需求時可能會跳過細節(jié)測試不會。他們會拿著文檔問這個等字等的是什么這個支持具體指什么操作。所以一份能讓測試不產(chǎn)生歧義的SRS大概率能讓所有讀者都不產(chǎn)生歧義。這里還要區(qū)分一個常見誤區(qū)SRS不等于產(chǎn)品需求文檔PRD。PRD往往面向產(chǎn)品團隊描述用戶故事、交互流程和產(chǎn)品決策背景SRS面向開發(fā)與測試描述系統(tǒng)的可驗證行為。兩者的讀者和使用場景不一樣混在一起寫文檔會變得既不夠產(chǎn)品、又不夠工程最后誰都不滿意。我一般建議團隊把PRD當成SRS的前置輸入而不是替身。2.2 需求分級Must / Should / Could / Wont 怎么定SRS最常見的翻車是需求清單上所有條目都寫著必須實現(xiàn)。當所有東西都是最高優(yōu)先級的時候等于沒有優(yōu)先級。我在模板里強制要求每個功能需求標注MoSCoW等級用四檔取代必須這種一棍子打死的描述。Must是缺失即失敗的硬需求系統(tǒng)沒有它就不能上線Should是重要需求但在資源不足時可以讓步Could是錦上添花的需求有精力才做Wont是明確本期不做的需求。前三個等級大家比較熟悉容易忽略的是Wont。我吃過這個虧有一次項目驗收時客戶指著我們當初討論過但沒做的功能說這個當時不是說要做的嗎翻遍文檔也找不到一句不做的說明最后只能加班補。從那以后我在SRS里專門留一節(jié)記錄Wont需求寫明不做的原因和可能的后續(xù)計劃。落地的操作方式并不復雜。需求評審時每個需求由提出人先自評等級然后與會者投票最終由項目負責人拍板。這里有一個建議我會在評審結束時統(tǒng)計各等級的需求數(shù)量如果Should和Could加起來超過40%就要和項目干系人重新討論范圍——要么砍需求要么調(diào)資源要么拉長排期總之不能假裝看不見。這個比例不是硬性標準但它是一個很好的預警線。提示需求分級不是一次性的。迭代開發(fā)中每個迭代開始前要重新審視需求等級把新需求加進來重新排序。優(yōu)先級是動態(tài)的不是寫進文檔就定型了。2.3 文檔邊界SRS不寫設計、不寫計劃、不寫實現(xiàn)細節(jié)新手寫SRS最容易越界把系統(tǒng)架構圖畫進來把數(shù)據(jù)庫表結構列進來把迭代計劃也寫進來。SRS的邊界是做什么不是怎么做。界面原型、接口定義、數(shù)據(jù)庫設計、項目排期這些內(nèi)容各有各的歸宿硬塞進SRS只會讓文檔變得臃腫。我對邊界的判斷方法是寫需求時如果出現(xiàn)通過XX實現(xiàn)采用XX技術數(shù)據(jù)庫使用XX這類句式停下來問一個問題——把這個句子刪掉開發(fā)是否仍然清楚他要做什么如果答案是清楚這句話就不屬于SRS如果答案是不清楚說明需求本身沒寫明白需要補充的是行為描述而不是技術選型。舉個例子。系統(tǒng)使用Redis緩存用戶session這句話是設計用戶登錄后30分鐘內(nèi)無需重復登錄超過30分鐘再次操作時跳轉登錄頁這句話是需求。前者是手段后者是行為。SRS寫后者就夠了具體用什么實現(xiàn)是設計文檔的事。這里容易引起爭議的是性能需求和一些強技術約束的場景比如必須兼容Windows Server 2022——這種約束是需求要寫用Java重寫舊系統(tǒng)是設計不要寫進SRS除非它是客戶指定的硬性約束。邊界不清導致的直接后果是文檔維護困難。設計變了SRS里的實現(xiàn)描述過期了開發(fā)不知道該信哪個干脆兩個都不看。所以我在模板開頭明確聲明SRS不包含設計決策并提醒團隊在評審時對照這個聲明檢查——發(fā)現(xiàn)實現(xiàn)細節(jié)就劃掉不留情面。3. 一份能落地的SRS模板10個章節(jié)逐節(jié)拆解3.1 引言部分目的、范圍、定義與參考文檔引言是SRS最容易變成廢話的地方。我見過不少文檔的目的節(jié)寫滿一頁為了規(guī)范軟件開發(fā)流程提高軟件質量增強團隊協(xié)作效率——全是正確的廢話。目的這一節(jié)兩句話就夠一句話說清楚軟件要解決什么問題一句話說明文檔的服務對象和適用范圍。范圍一節(jié)要同時寫在范圍內(nèi)和不在范圍內(nèi)兩個清單。不在范圍內(nèi)的價值經(jīng)常被低估。很多項目就栽在不做沒寫清楚到了驗收階段扯皮的全是當初沒明確說不做的事。我給客戶審閱SRS時會特意讓他們在這兩個清單上簽字確認這個動作能擋掉很多后續(xù)的需求蔓延。定義與縮寫列表要在文檔一開始就建好后續(xù)所有章節(jié)引用時全文統(tǒng)一。不要一會兒寫用戶、一會兒寫客戶、一會兒寫操作者同一個概念在不同章節(jié)用不同名詞開發(fā)很可能把一個概念當成兩個實體去設計。我一般用下面這個框架作為模板的基礎結構# 軟件需求規(guī)格說明書SRS ## 1. 引言 ### 1.1 目的 本文檔定義XX系統(tǒng)的功能需求與非功能需求作為開發(fā)、測試與驗收的依據(jù)。 ### 1.2 范圍 在范圍內(nèi) - 用戶注冊、登錄與權限管理 - 工單的創(chuàng)建、分派、處理與關閉 - 基礎統(tǒng)計報表 不在范圍內(nèi) - 移動端APP本期僅支持Web端 - 與第三方CRM系統(tǒng)對接排期未定 - 短信網(wǎng)關的接入依賴外部合同簽訂 ### 1.3 定義與縮寫 | 術語 | 說明 | | ---- | ---- | | 工單 | 用戶在平臺上提交的服務請求 | | 分派 | 將工單指派給具體處理人 | | 時效 | 工單從創(chuàng)建到關閉的時長 | ### 1.4 參考資料 ...這段模板的邏輯是先讓讀者在5分鐘內(nèi)判斷這份文檔跟我有沒有關系有關系再看下去。范圍一節(jié)的不在范圍內(nèi)清單是全文最重要的需求管理工具之一。參數(shù)說明定義表里每個術語只給一個含義如果同一個詞在業(yè)務中確實存在兩種理解換一個詞描述其中一種不要買一送一。3.2 總體描述產(chǎn)品視角、用戶特征、運行環(huán)境、約束與假設總體描述這一章給讀者建立全局畫面。產(chǎn)品視角用一兩段話描述系統(tǒng)在業(yè)務鏈路中的位置和它的核心價值不畫架構圖——那是設計文檔的職責。這段文字是給新成員和外包團隊快速了解業(yè)務用的寫法上以白話為主避免上來就堆功能清單。用戶特征用表格列出每類用戶的操作頻率、技術水平和使用場景。這個表格對后續(xù)交互判斷很有用如果用戶是每天8小時使用的內(nèi)部坐席人員界面密度可以高一些快捷鍵要有如果用戶是偶爾用一次的普通訪客界面引導就得做得更重。運行環(huán)境寫服務器、瀏覽器、移動端的支持范圍這里要具體不要寫支持主流瀏覽器要寫支持Chrome和Edge最近兩個大版本不支持IE。約束一節(jié)寫政策法規(guī)、技術選型限制、交付日期硬性要求。假設與依賴寫那些如果外部條件不成立就會出問題的事項例如依賴短信服務商的接口SLA達到99.5%若低于該標準驗證碼類功能時效性受影響。這一節(jié)在項目后期是排查責任邊界的重要依據(jù)寫的時候要細致不能含糊。3.3 功能需求編號、描述、優(yōu)先級、驗收標準一個都不能少這是SRS的核心章節(jié)也是寫得最爛的章節(jié)。功能需求的粒度要控制在一條需求對應一個可獨立驗收的功能點每條需求有四個必備元素唯一編號、功能描述、優(yōu)先級、驗收標準。編號是需求的身份證格式為FR-XXX遞增分配不刪號只作廢。這樣做的原因是追蹤時需要穩(wěn)定引用如果編號重排文檔里的交叉引用和測試用例里的關聯(lián)關系全部失效。### FR-001 工單創(chuàng)建 - 描述登錄用戶可以填寫工單表單并提交提交成功后生成唯一工單號。 - 優(yōu)先級Must - 驗收標準 1. 給定已登錄用戶當填寫所有必填字段并點擊提交時系統(tǒng)生成工單號并展示提交成功頁 2. 給定已登錄用戶當必填字段為空點擊提交時表單在對應字段下方紅字提示缺失項不生成工單記錄 3. 給定未登錄用戶當訪問工單創(chuàng)建頁面時系統(tǒng)跳轉登錄頁登錄成功后自動返回原頁面。 - 依賴FR-002 用戶認證這段模板的邏輯是驗收標準全部用給定/當/則的句式把前置條件、觸發(fā)動作、預期結果拆開寫讓不同讀者讀到同一句話時產(chǎn)生相同的理解。參數(shù)說明優(yōu)先級一列在評審時如果所有人都是Must回到2.2的統(tǒng)計方法討論范圍驗收標準條目數(shù)一般不超過5條超過5條說明需求粒度過粗要拆分成多條獨立需求依賴字段幫助排期時判斷哪些需求必須同批次交付也用于變更影響分析。3.4 外部接口需求把對接XX系統(tǒng)寫成可實現(xiàn)的描述外部接口是SRS里最容易被忽略的部分。很多文檔只在功能需求里提到一句對接第三方支付平臺卻沒寫清楚對接什么能力、傳輸什么數(shù)據(jù)、超時怎么處理、失敗怎么提示。等開發(fā)做到這一段才發(fā)現(xiàn)接口文檔還沒定、異常處理沒定、對接流程也不明確項目周期性停滯。接口需求分四類分別寫用戶接口描述人與系統(tǒng)的交互方式硬件接口描述設備型號、通信方式軟件接口描述被集成的外部系統(tǒng)、調(diào)用協(xié)議通信接口描述協(xié)議、端口、報文格式。每個接口需求的預期內(nèi)容接口用途、輸入數(shù)據(jù)、輸出數(shù)據(jù)、異常行為。這里不需要給出具體API設計——那是接口文檔的職責——但要寫清楚接口的約束和失敗時的行為。以對接短信網(wǎng)關為例SRS里應該寫系統(tǒng)通過HTTP調(diào)用短信服務商接口發(fā)送驗證碼短信當接口響應超時超過5秒時系統(tǒng)提示用戶稍后重試并記錄日志當服務商返回發(fā)送失敗時系統(tǒng)提示用戶短信發(fā)送失敗請檢查手機號是否正確。這比支持短信驗證碼發(fā)送多了三個維度調(diào)用方式、超時行為、失敗提示。開發(fā)拿到這段描述不需要再問超時了怎么辦測試也有明確的驗證依據(jù)。3.5 非功能需求性能、安全、可用性與可維護性全部量化非功能需求寫得好不好決定了系統(tǒng)后面能否平穩(wěn)運行。這一章的硬性原則每個指標必須是可驗證的數(shù)值。不要寫響應快要寫常規(guī)操作95%響應時間小于800ms99%小于2s不要寫支持大數(shù)據(jù)量要寫訂單數(shù)據(jù)量達到100萬條時列表查詢接口在1.5s內(nèi)返回。非功能需求同樣需要編號我習慣用NFR-前綴加類別縮寫NFR-PERF-001是性能、NFR-SEC-001是安全、NFR-AVA-001是可用性、NFR-MNT-001是可維護性。每個非功能需求的結構與功能需求一致描述、優(yōu)先級、驗收標準。各團隊最容易敷衍的是可維護性。我見過太多SRS在可維護性里只寫一句系統(tǒng)應具有良好的可維護性。這句等于沒寫。可維護性可以落到具體條目日志需要記錄哪些關鍵操作、日志保留多久、錯誤碼規(guī)范是什么、告警通知給誰。這些條目不需要多每類寫兩三條可執(zhí)行的規(guī)定比十句正確的廢話有意義。4. 讓SRS可驗證驗收標準、追蹤矩陣與評審清單4.1 驗收標準用Given-When-Then模板寫一條需求配3~5條功能需求部分已經(jīng)要求每條需求帶驗收標準這一節(jié)深入說說怎么把它寫好。Given-When-Then模板來自測試領域用來寫需求驗收標準非常順手。三條要素分別是Given前置條件When觸發(fā)動作Then預期結果。以登錄場景為例給定一個已注冊且狀態(tài)正常的用戶當輸入正確手機號和密碼時系統(tǒng)登錄成功并跳轉到首頁——這比一句用戶能夠正常登錄要好用得多。驗收標準的三個覆蓋維度值得對照自查正常流程、異常流程、邊界情況。正常流程保證能干活異常流程保證出問題時不至于白屏邊界情況保證數(shù)據(jù)臨界時不崩。很多需求文檔寫滿了正常路徑異常路徑全靠開發(fā)自覺補充這是需求分析偷懶的表現(xiàn)。我見過一種寫法上的反面典型系統(tǒng)會提示錯誤。這句話的主語模糊、行為模糊。驗收標準應該寫系統(tǒng)在輸入框下方以紅色12號字體提示驗證碼錯誤請重新輸入原輸入內(nèi)容保留。誰提示、提示什么內(nèi)容、提示在哪里、原數(shù)據(jù)是否保留這些細節(jié)決定了開發(fā)和測試對需求的理解是否一致。細節(jié)不是限制開發(fā)自由而是避免理解偏差。4.2 需求追蹤矩陣需求變更時一分鐘找到所有受影響對象追蹤矩陣RTM是SRS真正管理起來的橋梁。矩陣的每一行對應一條需求列一般包括需求編號、需求描述、優(yōu)先級、設計文檔位置、測試用例編號、測試結果狀態(tài)。這個表維護在Wiki或文檔管理工具中每次需求變更時同步更新。它的價值在于變更影響分析需求改了順著矩陣快速定位到受影響的測試用例和設計模塊然后按圖索驥逐個更新。需求編號需求描述優(yōu)先級設計位置測試用例測試結果FR-001工單創(chuàng)建Must設計文檔3.2TC-FR-001~003通過FR-002用戶認證Must設計文檔4.1TC-FR-004~007通過FR-010報表導出Could設計文檔5.1TC-FR-021~022未開始矩陣的維護時機有三個需求評審通過后建立初版每次需求變更時更新受影響的行每個迭代結束時核對測試結果。這里有一個常見誤解RTM是寫完文檔之后的工作。實際上RTM應該在需求評審當天就開始建先有矩陣再補文檔而不是反過來。需求變更時有一種常見的失聯(lián)場景測試已經(jīng)按舊需求寫好了用例開發(fā)按新需求完成了代碼兩邊對不上互相認為是對方的錯。有了RTM變更發(fā)起人可以提前看到這條需求綁定了哪些測試用例和設計模塊把更新任務派發(fā)給對應的責任人而不是靠大家自覺。4.3 評審清單評審會就按這份清單逐條過SRS投評審之前我習慣先跑一遍自查清單。這里有一份可以直接抄進團隊流程的問題清單覆蓋了文檔質量的主要維度每條功能需求是否都有唯一編號編號是否無重復、無重排每條需求是否標注了優(yōu)先級優(yōu)先級分布是否合理需求描述是否避免了快速友好等這類不可驗證的詞每條需求是否覆蓋正常流程、異常流程、邊界情況三類驗收標準非功能需求是否包含可測量的數(shù)值指標范圍一節(jié)是否同時寫了在范圍內(nèi)和不在范圍內(nèi)術語全文是否統(tǒng)一定義表是否覆蓋所有縮寫是否存在把設計混進需求的情況外部接口的異常行為是否有定義需求之間是否存在矛盾比如一個地方說只允許管理員刪除另一個地方說用戶可刪除自己的工單評審會的用法也很關鍵。我建議評審前每個人先對照清單自己過一遍評審會上只討論不通過的條目不從頭到尾朗讀文檔。朗讀式評審的效率和效果都很差大家坐下來兩小時真正有價值的討論其實集中在不到10%的內(nèi)容上。逐條過清單把有爭議的條目拉出來討論評審會才能控制在一小時以內(nèi)。5. 寫SRS的避坑指南5個高頻翻車現(xiàn)場5.1 把怎么做寫進需求現(xiàn)象需求描述里出現(xiàn)系統(tǒng)使用Redis做緩存采用微服務架構前端使用Vue框架。評審時沒人提出異議開發(fā)按部就班實現(xiàn)結果到了后期發(fā)現(xiàn)技術選型不適合業(yè)務場景想換方案但需求文檔寫死了用Redis只能硬著頭皮做下去。原因寫文檔的人把自己預想的技術方案直接寫進了需求混淆了做什么和怎么做。解決把實現(xiàn)細節(jié)從SRS中劃掉改成行為描述。系統(tǒng)使用Redis緩存熱數(shù)據(jù)改成系統(tǒng)需支持緩存熱數(shù)據(jù)在數(shù)據(jù)量100萬條時熱點查詢響應時間低于200ms。開發(fā)自然會為這個指標尋找最合適的方案如果最終選了Redis以外的方案只要指標達標文檔不會成為阻礙。5.2 形容詞型需求誰都能讀誰都不敢接現(xiàn)象系統(tǒng)應擁有友好的用戶體驗數(shù)據(jù)要快速加載頁面操作要流暢。評審時沒人反對因為每個人心里都有自己的一套標準但大家的標準各不相同。開發(fā)按自己理解做了測試按自己理解測了驗收時業(yè)務方說這不是我想要的。原因在沒有做需求分析的情況下用形容詞填補思考空白。解決把形容詞改成可測量的指標?？焖偌虞d改成頁面首屏加載時間在4G網(wǎng)絡下小于3秒。友好這種詞如果無法量化就拆解成具體的交互規(guī)則比如表單提交失敗時保留用戶已填寫內(nèi)容就是一條可驗證的友好表現(xiàn)。改完以后開發(fā)和測試就有了明確的標準。5.3 只寫主流程異常路徑全靠開發(fā)自覺現(xiàn)象需求文檔寫滿了登錄成功、下單成功、審核通過卻沒有密碼連續(xù)錯誤怎么處理、庫存不足怎么處理、審核駁回怎么處理。測試拿到文檔后正常流程用例寫完了異常流程問開發(fā)你們怎么實現(xiàn)的開發(fā)說我按自己理解做的。原因需求分析時把精力集中在主流程上忽略了異常路徑。主流程確定系統(tǒng)的核心價值異常路徑?jīng)Q定系統(tǒng)是否可靠兩者都重要。解決在評審時對每條需求追問一個問題如果這一步失敗系統(tǒng)應該展示什么把這個問題的答案寫進驗收標準。密碼連續(xù)錯誤5次鎖定30分鐘、庫存不足時提示具體缺口數(shù)量、審核駁回時通知申請人不通過原因——這些補齊后SRS才算真正完整。5.4 非功能需求形同虛設系統(tǒng)需穩(wěn)定運行等于沒寫現(xiàn)象SRS的非功能需求部分只有孤零零的一句話系統(tǒng)需保證穩(wěn)定運行具有良好的性能和安全性。到了壓測階段測試問性能指標是多少開發(fā)說能跑就行安全測試問有哪些安全要求負責的說你看行業(yè)通用的就行。原因寫的人認為非功能需求不重要或者覺得自己寫不出可量化的指標干脆用一句正確的廢話帶過。解決至少先確定三類非功能需求并量化性能響應時間、吞吐量、并發(fā)用戶數(shù)、安全認證方式、權限粒度、數(shù)據(jù)傳輸加密要求、可用性年度可用性百分比、故障恢復時間。每類寫兩三條就夠關鍵在可驗證。用戶并發(fā)數(shù)達到200時核心接口響應時間不超過1.5秒比一百句高性能有用。非功能需求不要求一步到位但必須起步。5.5 SRS寫完就鎖進抽屜需求變更后文檔徹底失聯(lián)現(xiàn)象SRS評審通過后被當作定稿封存項目進入開發(fā)階段后需求陸續(xù)變化開發(fā)按新需求改代碼沒有人更新SRS。項目尾聲測試按SRS寫測試用例和實際系統(tǒng)對不上只好不斷找開發(fā)問你們到底是怎么做的。原因文檔管理流程沒建立起來需求變更沒有走變更流程SRS沒有被當成活文檔維護。解決把SRS納入版本管理每次變更走同樣的流程提交變更請求、評估影響用RTM定位受影響范圍、評審并批準、更新SRS及所有受影響文檔、通知所有相關方。變更記錄表放在文檔頭部格式簡單就可以日期、變更人、變更內(nèi)容、關聯(lián)需求編號。6. 讓一條需求從SRS走到測試用例以忘記密碼為例的完整鏈路前面把模板和坑都講透了最后用一個例子把整條鏈路串起來。假設原始需求只有一句話用戶忘記密碼時可以重置密碼。這句話不能直接進SRS它缺少可驗證的行為定義。進入SRS后這條需求展開成FR-030### FR-030 密碼重置 - 描述用戶在登錄頁點擊忘記密碼通過驗證已綁定手機號重置登錄密碼。 - 優(yōu)先級Must - 驗收標準 1. 給定已注冊且綁定手機號的用戶當點擊獲取驗證碼時系統(tǒng)在60秒內(nèi)向該手機號發(fā)送短信驗證碼 2. 給定用戶當輸入驗證碼錯誤并點擊提交時系統(tǒng)提示驗證碼錯誤連續(xù)錯誤5次鎖定30分鐘 3. 給定用戶當輸入手機號未注冊時系統(tǒng)提示該手機號未注冊不發(fā)送驗證碼 4. 給定用戶當設置的新密碼與舊密碼相同時系統(tǒng)提示新密碼不能與舊密碼相同 5. 給定用戶當重置成功后使用新密碼登錄時系統(tǒng)登錄成功并跳轉首頁。對照驗收標準測試用例的設計幾乎是順理成章的TC-030-01驗證正常重置流程TC-030-02驗證未注冊手機號提示TC-030-03驗證驗證碼連續(xù)錯誤鎖定TC-030-04驗證新舊密碼相同情況TC-030-05驗證重置后登錄成功。每個測試用例的預期結果直接來自SRS的驗收標準不需要測試另起爐灶去猜需求。最后在RTM里登記一行FR-030密碼重置Must設計文檔4.2TC-030-01~05未執(zhí)行。這一行讓這條需求從文檔到測試的路徑變得透明需求變更時順著這一行找到測試用例更新起來有據(jù)可查。我后來養(yǎng)成了一個習慣寫一條需求之前先在腦子里把對應的測試用例過一遍。如果一條需求想不出至少3條驗收標準說明需求本身還沒想清楚如果測試用例與驗收標準對不上文檔里一定有一處是假的。把這個問題消滅在動筆階段比事后再補要省力得多。希望幫到你。本文還有配套的精品資源點擊獲取