<ruby id="bdb3f"></ruby>

    <p id="bdb3f"><cite id="bdb3f"></cite></p>

      <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
        <p id="bdb3f"><cite id="bdb3f"></cite></p>

          <pre id="bdb3f"></pre>
          <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

          <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
          <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

          <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                <ruby id="bdb3f"></ruby>

                ThinkChat2.0新版上線,更智能更精彩,支持會話、畫圖、視頻、閱讀、搜索等,送10W Token,即刻開啟你的AI之旅 廣告
                # 測試用例設計怎么做?怎么設計一個好的測試用例? **一、測試用例的定義** 測試用例(Test Case),是為某個特殊目標而編制的一組測試輸入、執行條件以及預期結果,以便測試某個程序路徑或核實是否滿足某個特定需求。 **二、為什么要寫測試用例** 1、 理清測試思路 有的系統本來就是一個大而復雜的項目,因此需要把項目功能細分,根據每一個功能通過編寫用例的方式來整理測試系統的思路,避免遺漏掉要測試的功能點。 2、 明確測試任務 編寫完用例后,可以明確自己需要執行的用例總數,以便預估測試工作量。并且可以很清楚的知道實際測試執行的進度,還很容易統計和跟蹤我們的剩余工作量和回歸工作量。 3、 規范測試行為 每個人對于功能和開發原理的理解都是不同的,同一條案例,每個人的理解程度和擴展都是不一樣的。對于沒有測試經驗的新人來講,更是需要詳細明確的用例來規范,以減少遺漏。 **三、如何編寫用例** 1、 測試用例的來源 a) 分析需求文檔 需求文檔是編寫測試用例的第一依據,需求分析的目的一般是: l 了解需求的背景; l 分析需求的合理性; l 明確需求的范圍; l 挖掘隱含需求; b) 了解開發原理 l 確定開發的實現框架; l 明確輸入輸出代碼規則; l 減少測試方向偏差; 2、 測試用例的要素 a) 測試環境 測試的系統是什么?硬件軟件的要求是什么? b) 測試數據 測試執行的輸入值 c) 測試步驟 提供測試執行過程的步驟。一般控制在三個步驟完成。否則需要考慮用例是否需要拆分,因為每條用例對應的測試目的應該是具有唯一性的。 d) 預期結果 預期結果根據軟件需求中的輸出得出。那么實際測試過程中,實際測試結果如果與預期結果不符,則就測試不通過;反之則測試通過。 e) 用例標題 用例標題是對測試用例主旨的描述,既要言簡意賅,也要能夠清楚表達測試用例的目的 f) 用例編號 定義測試用例編號,用來標示每個用例的唯一性,進行測試用例的跟蹤和維護。 g) 用例級別 一般分為四個等級,P0、P1、P2、P3。 ![](http://qa.tedu.cn/upload/20171011/20171011154902_548.png) 3、 用例設計方法 結合一個需求來講講不同方法的應用: a) 等價類劃分 將輸入值分為有效等價類和無效等價類。如果輸入規定了輸入區間,可劃分出一個有效等價類,兩個無效等價類; b) 邊界值 任何測試場景下都可以使用邊界值法做設計,輸入類型可以數值、字符等,要測試的邊界包括上點、下點、離點。 c) 錯誤推測法 錯誤推測法,即猜測可能和常出現的錯誤,來提前制定用例,規避風險。錯誤推測法很受設計人員的測試經驗影響,測試經驗不同,設計出來的測試用例區別會很大。 d) 因果圖法 羅列出所有的輸入和輸出,將輸入和輸出整理出因果圖和依賴關系,根據每一個依賴做設計。因果圖方法考慮輸入的組合,特別適用于多個輸入條件相關有關聯又相互約束的情況。 e) 判定表驅動法 判定表適合于解決多個邏輯條件的組合,將各種邏輯的組合羅列出來,避免遺漏。列出每個對應條件所有可能情況下的取值,不需要考慮條件和順序,再列出結果動作項,對每個條件進行結果判定。最后可以適當的進行規則簡化和合并。 f) 正交法 當輸入條件很多時,因果圖等設計方法設計出來的用例數往往多的驚人,用正交法可有效減少用例數。正交法的核心思想是從大量測試數據中選取有代表性的點來測試,從而減少測試用例數。 > 在實際的軟件項目測試中,有時候會遇到輸入條件很多,且每個條件的取值也較多的情況,這時如果用因果圖或者判定表將所有可能的情況都列出來的話將會很麻煩,甚至不可能完成,時間上往往也不允許。比如某輸入入口有4個條件,每個條件有3個不同取值,則完整的用例組合就多達81種(3\*3\*3\*3),這時我們就可以考慮通過正交試驗法從這81種情況中科學合理的選取一少部分作為測試用例 正交試驗設計介紹 正交試驗設計是研究多因素多水平的一種設計方法。它基于Galois理論,根據正交性從全面試驗中挑選出部分有代表性的點進行試驗。這些有代表性的點具備了“均勻分散,齊整可比”的特點。日本著名統計學家田口玄一將正交試驗選擇的水平組合列成表格,稱為正交表。例如一個4因素3水平的試驗,如果按全面試驗設計,則有81種組合的試驗,但如果按正交表設計試驗,則只需要9次試驗,在確保足夠的有效性、合理性的同時大大降低了試驗成本。 一般的正交表可以記為Ln(mk),L表示正交表,n表示正交表的行數,也就是試驗的次數;k是表中的列數,也就是因素的個數;m表示各因素的水平數。如L9(34)正交表如下所示。 ![](http://mmbiz.qpic.cn/mmbiz/YY9qU8W8U9cM4xnlmHWLpNnC4eaYVkUk7XVULOv7gcBq8N7Q2dIgtP5XfLib1crwDPgkyV28nh06X9PSgfVIicDg/640?wx_fmt=jpeg&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1) 正交表的兩條重要性質 ◆?每列中不同數字出現的次數是相等的。如上L9(34)表中每一列不同的數字1、2、3各出現3次。 ◆?在任意兩列中,將同一行的兩個數字看成是有序數對時,每種數對出現的次數是相等的。如上L9(34)表中的有序數對共有9個:(1,?1),(1,?2),(1,?3),(2,?1),(2,?2),(2,?3),(3,?1),(3,?2),(3,?3)。 由于正交表的這兩條性質,用它來設計試驗時,各因素的各種水平搭配是均衡的,這就是正交表的優點。 舉例說明 例如測試某WEB程序兼容性時,需要考慮如下三個因素: ????操作系統(Windows?XP,?Win?7,?Win10) ????瀏覽器(IE8,?Fire?Fox,?Chrome) ????分辨率(1366x768,?1024x768,?800x600) 由上面的需求可以得知有三個因素,三個水平,如果窮舉則有27種情況,我們可以用L9(34)正交表設計測試用例,注意這里只有3個因素,但是L9(34)有4個因素,這不沖突,我們選取上表中的三列即可。代入具體的數據后如下表所示。 ![](http://mmbiz.qpic.cn/mmbiz/YY9qU8W8U9cM4xnlmHWLpNnC4eaYVkUkZAdia6icfaE0Nkg70ezZs0EPSGhxP8nND2W7gMupuA2I3PHXh5ZYWOKA/640?wx_fmt=jpeg&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1) 一些常見的正交表可以在網上找到,不需要自己去排列,如L4(23)、L9(34)、L8(27)、L27(313),根據需要選取合適的正交表代入數據就可以了。 g) 場景法 畫出程序流程圖,再把流程圖轉換成控制流圖,根據控制流圖設計出場景,再根據場景設計測試用例。 結合這樣一個需求: ![](http://qa.tedu.cn/upload/20171011/20171011154920_675.png) 判定表: ![](http://qa.tedu.cn/upload/20171011/20171011154929_626.png) **四、如何提升用例編寫能力** 1、 從大往小抓起測試框架先行 極力推薦思維導圖工具,快速的梳理清晰要測試的模塊、測試點、以及結構關系,讓自己先對要測試的內容有個整體的框架和印象,腦圖也能夠快速的讓開發、接手的測試同學快速理解和看出大方向上的偏差和遺漏。 另外細節的地方,推薦幾個圖形工具結合用,比如流程圖、魚骨圖和N-S 圖,詳情見另一篇文章『軟件開發流程常用圖』 2、 多緯度的思考和覆蓋 從界面、功能、性能、兼容、異常等角度思考,盡可能的覆蓋更全更廣。 3、 熟悉被測的業務和系統 任何系統都有大的業務背景,比如測試金融 APP,要了解金融業務,基金、理財產品的業務流程和邏輯,要了解什么是結算、賬戶、和支付幾個系統的差異以及作用。才能更準確的把握好測試重點寫好用例。 任何系統在使用過程中,都有一個熟悉的過程,對系統越熟悉,越容易發現系統的特點,以及容易出現錯誤和異常的地方。 4、 站在用戶角度分析 站在客戶的角度分析:客戶需要什么,客戶想要什么,客戶不想要什么,也就是客戶的使用場景。這樣有利于我們更好的挖掘和思考隱含的需求。甚至可以拉上幾個同事來體驗下產品,看看他們的操作行為和順序是怎樣的。 5、 重視用例評審 重視測試評審和評審意見,把經常見到的用例設計的誤區和一些好的用例設計,還可以多看看他人的測試思路和用例,查漏補缺。
                  <ruby id="bdb3f"></ruby>

                  <p id="bdb3f"><cite id="bdb3f"></cite></p>

                    <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
                      <p id="bdb3f"><cite id="bdb3f"></cite></p>

                        <pre id="bdb3f"></pre>
                        <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

                        <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
                        <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

                        <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                              <ruby id="bdb3f"></ruby>

                              哎呀哎呀视频在线观看