最近遇到一件事劝评，要做一個(gè)特性，這個(gè)特性并不是第一次從頭開始做倦淀，之前已經(jīng)實(shí)現(xiàn)了大的框架蒋畜，流程也已經(jīng)打通，現(xiàn)在就是這之前的基礎(chǔ)上修改一個(gè)接口撞叽，對齊客戶的要求姻成。
按說這樣理解起來并沒有多少復(fù)雜的地方，但是如果上述需求并沒有描述清晰具體的流程是什么愿棋，系統(tǒng)間的交互應(yīng)該是怎么樣的科展，是否依賴于其他外部系統(tǒng)，并且需求也沒有描述清楚依賴的需求糠雨，就是該需求?哪個(gè)需求為基礎(chǔ)才睹，那么當(dāng)?shù)谝淮谓佑|這個(gè)需求的時(shí)候，難免會(huì)摸不清到底要做什么甘邀，做成什么樣算是ok的琅攘，后續(xù)如何驗(yàn)收，驗(yàn)收的標(biāo)準(zhǔn)是什么松邪。
于是坞琴，我根據(jù)這個(gè)需求，做了如下工作：
（1）閱讀該需求逗抑，大概知道這個(gè)需求要做什么剧辐；
用戶為什么要提交這個(gè)需求，背景是什么邮府，現(xiàn)有功能是否能夠滿足用戶的需求浙于；
用戶如何使用該需求；如果系統(tǒng)被多個(gè)外部系統(tǒng)使用時(shí)挟纱，實(shí)現(xiàn)該需求后羞酗，是否會(huì)影響其他使用該系統(tǒng)的用戶；
具體的需求點(diǎn)是什么紊服，比如是修改了接口檀轨，還是增加了變量胸竞；
（2）如果可以，找到在此需求之前的基礎(chǔ)需求是如何實(shí)現(xiàn)的参萄；
有沒有需求描述卫枝，方案是怎么實(shí)現(xiàn)的，流程交互又是怎么實(shí)現(xiàn)的讹挎，系統(tǒng)間交互是什么樣子的校赤，此接口什么時(shí)候會(huì)調(diào)用，請求和響應(yīng)又該是什么樣子的筒溃，是否對header有要求马篮；
（3）之前的需求是否有測試策略，測試策略重點(diǎn)是測試什么怜奖，有沒有實(shí)現(xiàn)自動(dòng)化驗(yàn)收浑测；
是否已有測試用例可以參考；
如果實(shí)現(xiàn)了自動(dòng)化驗(yàn)收歪玲，自動(dòng)化用例是否能夠滿足當(dāng)前需求的驗(yàn)收迁央，是否對工具有要求，如果有要求滥崩，要求又是什么樣子的岖圈；
之前的人工測試工作量是多少，遇到過哪些坑钙皮；自動(dòng)化用例是如何模擬的蜂科，有沒有現(xiàn)成的例子供參考下。
（4）對外部的依賴是什么株灸；
是要求外部系統(tǒng)返回新增接口的數(shù)據(jù)崇摄，還是修改的接口的數(shù)據(jù)的變更/刪除；
是否有依賴的外部系統(tǒng)可以用來驗(yàn)收慌烧；如果沒有如何協(xié)調(diào)逐抑，協(xié)調(diào)不到如何處理，是否可以只根據(jù)自動(dòng)化用例來驗(yàn)收交付屹蚊；
該系統(tǒng)是否要對外提供該接口厕氨，外部調(diào)用該接口的時(shí)候是否新增了該參數(shù)，那么又涉及到通道問題汹粤；
（5）熟悉上述后命斧，畫出該需求的流程圖；
流程圖可以規(guī)避遺留功能點(diǎn)嘱兼；
（6）寫出測試策略国葬；
大體是針對該需求的策略；當(dāng)然最好能夠在需求中明確該需求的流程是什么，實(shí)際上針對上述的1-5都應(yīng)該中需求中明確出來汇四。但是有時(shí)候并不能中每一個(gè)環(huán)節(jié)都能夠做到最好接奈，針對不同的需求，找到應(yīng)對的策略通孽。當(dāng)自己無法根據(jù)需求文檔得到什么的時(shí)候序宦，盡可能讓需求的作者給出，不懂就要問背苦，這也是我自己需要努力克服的一點(diǎn)互捌。
后面再補(bǔ)充一個(gè)需求跟蹤的流程。此次也只是需求跟蹤中的特例行剂。需求跟蹤涉及到很多環(huán)節(jié)秕噪，需要統(tǒng)籌考慮。
