需求分析還可以這樣做

搜狗測試2019-06-26 02:33:09

作為一名測試開發工程師,與我們密切相關的不止是開發的代碼,還有功能依賴的需求文檔。一份好的需求文檔,不止能夠加速開發和測試的腳步,還能夠提前發現風險,是產品的第一道風險保障。


當然,工作中難免會遇到並不“完美”的需求文檔,比如牽一髮而動全身不清楚的交互邏輯,子條目頻繁的變更,交流缺失導致的歧義,都會讓測試在項目推進中手足無措。吶這篇文章就是想和你一起討論,當我們閲讀需求文檔時,我們都需要了解啥。



從宏觀的角度看需求文檔


在閲讀需求文檔之前,我們要對項目或者功能本身有一個宏觀的認識,當前項目追求的是什麼,是與時俱進快速迭代的更新速度,還是穩中求勝的代碼質量,還是耳目一新的智能化設計,明確這些有助於我們在測試中有明確的重心。站在宏觀的角度看需求文檔,主要是明確需求的合理性和優先級,是針對需求整體作用進行的評審,如果整體的方向錯誤,那麼細節上也沒有再討論的意義了。




合理性的意義上,通讀需求文檔,從客觀的角度出發,應有一整套合理、公正、客觀、完善的需求文檔的評價體系去保證需求質量。更多的時候我們也要換位思考,站在用户的角度,去評價需求文檔解決的痛點是什麼,是否符合用户需求;解決的這個需求會不會只考慮到小範圍的用户,從而影響到大眾關注的邏輯,更應站在開發的角度去評估,在效率、效果上是否可行,在技術上實現是不是會有阻礙。如果這個需求的涉及到的資源緊張,那麼這個需求和其他需求的優先級又該怎麼取捨,都是應該在需求評審時,首先應該考慮到的。



從細節的角度看需求文檔




站在完整性的角度看需求文檔,實際上是將當前的負責的項目模塊化(或者抽象化),根據功能的需求確定功能的影響範圍,再細化,同時對比需求文檔,這樣對目標的操作有個明確的預期結果。



1)結構化項目流程



以內核為例,無論是功能類的需求、質量類的需求還是解決用户反饋的需求,都可以把這些需求抽象成為操作(增、刪、改)、查詢兩個大模式。要麼是純查詢類需求(即刻俊譯),要麼就是兩者結合操作類+查詢類(靈犀)。在這裏有些看起來是純操作類的需求(刪詞),但是實際上要通過查詢的方式才能生效在這裏就不單獨作為一個模式贅述。

2)確認影響模塊



比如一個純查詢類的功能需求,我們通過以上的圖就可以知道,整個過程影響我們的因素有:



I. 用户輸入

例如:   

   1) 類型(中文、漢字、英文、數字、不支持編碼、表情、符號)

   2) 長度(最短、最長)

   3) 異常輸入


II. 查詢條件

   例如:

   1)完全匹配查詢、部分匹配查詢(簡拼、暴力)

   2)需求中定義的查詢規則(匹配規則、優先級邏輯)


III. 查詢內容

這裏的查詢內容指的是被查詢內容的特性,存在/不存在,同步/異步,正常/異常,或某些需求文檔中指明的情況


IV.效果展示

   例如 :

   1)展示位置

   2)排序優先級

   3)展示個數

   4)標記情況等



3)考量綜合因素



這裏的外界影響因素,指的是其他外界因素,有可能改變這四個過程中的某些因素,比如開啟繁體下會改變用户輸入,比如當用户關閉用户詞會使用户詞查詢內容失效,再比如某些固排的詞會影響效果展示。



還有一些效果性的需求,比如提高查詢效率,我們知道這個功能只需要改動查詢條件就可以,但是在需求文檔中也應明確是否有用户輸入和查詢內容的約束。當然這些綜合考量離不開測試人員項目知識的掌握程度、在這裏建議(類比相似功能、總結記錄(bug、特殊)以及用例評審去提升綜合因素的覆蓋度)。



將以上因素排列組合和歸納,再對比需求文檔,我們就可以知道某種特定的輸入下,有哪些預期結果,那這些預期結果到底好不好,這就涉及到需求細節的合理性明確性以及優先級



合理性的驗證也需要從用户行為和開發行為兩個角度去進行分析,細節是否合理到位。比如之前出現過得需求中,上屏標點後,再輸入上屏不會自動補空格。我們找了一篇英文文章去輸入體驗,發現每次上屏標點後,都需要手動輸入一個空格,再輸入其他詞條,這樣的體驗肯定不是用户想要的,因此會針對這種現象提出需求建議,再比如某些效果需求的時候,罰分與其他功能衝突,都是我們期待在需求分析階段發現的。



明確性是需求閲讀中的痛點,因為閲讀的時候人都是主觀的,所以很難有這個明確性的意識。經常出現問題的地方是歧義和沒有約束。在這裏我對歧義的建議是多次閲讀,特別是那些覺得非常拗口的地方,往往都是問題頻發的根源。約束的問題往往依賴個人經驗,比如鍵盤類型的約束以及異常校驗的約束等。



優先級某些需求項與已有功能有“衝突”,針對這些需求項,是否明確了優先級,並評估優先級的合理性。


需要注意的是,合理性、明確性以及優先級的相關的影響因素是在完善性的考量中確定的,所以結構化項目流程,明確影響因素範圍尤其重要。





需求的測試成本與質量風險



最後一個是在閲讀需求文檔後會被頻繁討論的事情,值得大家深入思考。


一般來説常見的有兩種問題:



1)測試和開發的成本比較高,難以匹配當前的產品進度。

2)當目前的已有測試手段不能有效保證功能的質量。



針對這兩種問題,我的建議是嘗試變更測試方案,提出對被測試需求的多種測試策略,並在每種方案後標註測試成本和風險,並將方案與合作方討論,選擇大家都可以接受的方案進行調整。


以上就是我的一些閲讀需求文檔的經驗,可能每一個測試同學對應的項目不同,抽象出來的流程不同,思考和解決的方式也不同,歡迎在下面分享經驗,與大家討論,如何進行需求分析。




https://hk.wxwenku.com/d/201004004