<thead id="htxjv"><meter id="htxjv"><del id="htxjv"></del></meter></thead>
      <thead id="htxjv"></thead>
      <thead id="htxjv"></thead>

        <dfn id="htxjv"></dfn>

        <thead id="htxjv"><dfn id="htxjv"></dfn></thead>
        <meter id="htxjv"><thead id="htxjv"><del id="htxjv"></del></thead></meter>

        <mark id="htxjv"></mark>
        <th id="htxjv"></th>

        <thead id="htxjv"><menuitem id="htxjv"><ol id="htxjv"></ol></menuitem></thead>
        北京物流信息聯盟

        【PM手冊·品質管理】需求分析方法——把測試流程圖表化.

        項目管理智匯團 2021-10-03 09:23:36

        一、需求分析基礎

        1、什么是測試需求

        需求測試,是驗證需求是否是正確的、完整的、無二義性。測試人員要能夠分辨出來問題點,并跟用戶進行核對,確定用戶的真實需求。

        需求測試的輸入:需求文檔(MRD、PRD、UC)

        需求測試的輸出:問題點及修改建議,測試分析MM圖。

        2、為什么要進行需求測試

        1)新人對業務不熟:測試人員對被測系統的業務流程不熟悉

        2)錯誤或缺失測試方法:對功能點沒有采用正確的測試方法, 導致測試不充分。

        3)場景的缺失或部分缺失:Spec非常詳細,所有的精力放在功能點的測試上,忽視了業務場景的覆蓋

        4)為了知道需求變更:這是最不想,但又最經常發生的事情

        3、需求測試的范圍

        1)需求背景,目標,影響范圍

        2)系統的輸入輸出,類型,精度,允許的出錯次數,輸出的格式,數據的來源以及正確性

        3)響應時間,提示的方式,異常處理方式,性能指標

        4)主要流程描述,操作流程和步驟說明,分析是否合理化

        5)需求的上下文是否一致,有沒有于其他需求發生沖突

        6)需求邏輯是否足夠清晰,每個條款都是描述問題及解決問題是否包含

        7)需求是否都是可測試的

        8)尋找隱含的需求,和相互依賴的需求

        4、推薦的需求文檔格式

        1)業務名稱解釋

        2)需求背景及目標介紹

        3)用戶操作場景說明

        4)功能總覽:用列表的方式,逐項敘述對系統所提出的功能要求,說明輸入什么量、經怎么樣的處理、得到什么輸出

        5)系統交互圖

        6)界面原型(對該系統的輸入、輸出數據類型、格式、數值范圍、精度的描述)

        7)業務規則說明

        8)業務正常流流程:功能模塊,主要操作

        9)業務異常流處理:異常場景,錯誤提示;異常流轉

        二、淘寶需求模式

        PD、運營參與,前期需求討論、PRD需求整理、PRD,UC評審、測試需求分析,測試用例設計

        淘寶存在的項目優化很多,中途接手項目的情況很普遍,測試人員需要考慮的全局觀和整體性體現在業務建模上和業務流程上的全面性

        需要注意的:項目背景

        三、如何進行需求分析的方法論

        工程經驗中,需求分析工作方法可以分為 三個方面進行考慮

        第一階段:全局式

        這一階段是和需求方溝通,主要目的是從宏觀上把握用戶的具體需求方向和趨勢,了解組織架構、業務流程、硬件環境、軟件環境、現有的運行系統等等具體情況、客觀的信息。確定對應的接口人

        輸出成果:調查報告、業務流程分解、問題確認

        內容校驗方法:

        1、需求總體完整性測試:包含內容(業務名詞解釋、需求背景和目標、用戶操作場景說明、功能總覽、系統交互圖、界面原型、業務規則說明、業務正常和異常流處理)

        2、來源測試,需求的來源,使用者,確認需求的各個模塊的重要性

        3、可以使用的方法或者圖表

        功能分解圖,MM圖,系統交互圖

        明確系統涵蓋的功能點和范圍

        系統用例圖:明確角色關系,系統的調用者與系統之間的關系,明確角色的權限設置和權限沖突,

        第二階段:流程式

        已經了解了具體用戶方的組織架構、業務流程、硬件環境、軟件環境、現有的運行系統等等具體實際、客觀的信息基礎上,結合現有的硬件、軟件實現方案,做出簡單的用戶流程頁面,一起探討業務流程設計的合理性、準確性、便易性、習慣性。用戶可以操作簡單演示的DEMO,來感受一下整個業務流程的設計合理性、準確性等等問題,及時地提出改進意見和方法。

        可以輸出成果:業務流程報告

        可以采用的方式方法:功能分解表、活動圖

        明確功能入口,頁面間的跳轉,參數的傳遞等

        1、服務結果為導向的測試方法,用用例結構圖方式進行功能分解的形式進行,校驗流程形式的復雜度便易性,合理性,準確性

        2、通過設計用例來驗證需求中描述中不詳細的遺漏點

        實際應用中可以考慮的測試方法:

        1)內容測試:輸入輸出是否明確,格式校驗定義是否完整,是否有預計的響應時間,異常流處理等

        a)缺少導致這個行為結果的原因的描述;

        b)沒有給出明確定義說明;描述中遺漏了幾種可能的異常信息需要進行處理;

        c)缺少用戶權限的描述;

        d)缺少分支流程的說明;

        e)業務規則說明上的遺漏;

        f)邊界值上的遺漏

        可以采用的流程圖表法:畫決策流程表(針對if—else—then的形式),明確用戶流程導向,區別出核心流程和優先級

        2)二義性:和一致性并行檢查

        a)異常分支是否已經說明

        b)引用上的歧義,未指明具體引用的內容

        c)動作的范圍界限不清

        d)遺漏:有原因但沒有結果的說明;有結果但缺少原因的說明

        e)邏輯操作符歧義:與,或,非,與非等復合操作符使用不當

        f)否定的范圍不明確

        g)含糊性陳述:一些變量添加了不必要的別名,引起歧義

        h)結構混淆:因果混淆,用例先后次序不嚴謹

        i)內置假定臆斷條件:對知識范圍的臆斷

        j)邊界值上的含糊

        可以采用用例圖的方法:

        3)一致性檢查:這點比較難理解,需要考慮在需求中的功能分解,和有交互的功能重合部分和交互部分會否出現一致性的需求錯誤

        a)任何一條需求不能和其他需求互相矛盾,主要表現為邏輯關系之間是否有沖突(包含、并且、或之間的關系驗證)

        實例說明:

        如果小于18歲,并且打網球,那么寄送給他們一本網球俱樂部的手冊

        如果大于等于18歲,或者有一個摩托車的駕照,那么寄送給他們一個摩托車俱樂部的手冊

        如果這個人同時收到了2份手冊,那么把這個人放在A的郵件列表中

        擁有摩托車手的駕照,必須大于18歲

        第三階段:詳細確認式

        這一階段是在上述兩個階段成果的基礎上,進行具體的流程細化、數據項的確認階段,這個階段必須提供原型系統和明確的業務流程報告、數據項表,并能清晰地向用戶描述系統的業務流設計目標??梢酝ㄟ^技術方案業務流程報告、數據項表以及操作承建方提供的DEMO系統

        實現手段:原型演示系統、交互圖、時序圖、流程圖

        測試方法:

        1、對demo中的功能進行需求文檔的功能點是否能覆蓋進行排查。

        例如: 覆蓋的功能、覆蓋的市場、覆蓋的異常流、覆蓋的數據類別

        2、對接口引用的關系,數據傳輸的過程,系統的交互等

        整體來講,需求分析的三個階段是測試中不可忽視一個重要的部分,三個階段的實施和采用,在系統建設的過程中,特別在采用迭代法的開發模式時,需求分析的工作需一直進行下去,而在后期的需求改進中,工作則基本集中在后兩個階段中。

        四、總結校驗的內容是否完整checklist

        一般需求清單

        業務需求清單


        本文選自:《uml.org.cn》

        原文鏈接:http://www.uml.org.cn/RequirementProject/201603214.asp