測試用例設計方法

一、

Android系統功能測試設計的測試用例：

a.對所測APP劃分模塊

b.詳細列出每個模塊的功能點（使用Xmind繪制功能圖）

c.使用等價類劃分、邊界值、場景法等對各功能點編寫測試用例（考慮中斷功能測試用例）

d.執行測試之後，反思總結補充相關用例

二、

1）根據業務需求文檔、業務邏輯文檔和流程圖 等業務資料，整理測試方案和測試功能點；

2）將測試方案和測試功能點 內容細化，細化成一條條用例，包括頁面元素顯示、頁面功能交互、底層數據交互、接口交互等；

3）針對每一個測試功能點，利用 邊界值、等價類、因果圖、錯誤推測法 枚舉出每一個功能點的所有測試項，將每一測試項形成一條條測試用例；

4）考慮業務需求文檔之外的其它異常情況，形成測試用例；

三、

之前測試TV系統及其集成APP，也很少設計測試用例，用例都是寫好的，執行就可以，所以設計測試用例能力比較匱乏。但是自由測試的時候發現的bug數量還不少。

目前設計測試用例，主要是根據需求文檔寫測試用例。我們這邊先進行需求評審，評審的時候可以提出疑問，產品解答，之後測試寫用例，期間可以向產品確認需求。測試用例主要分為：

1)功能測試（正常用例、異常用例、參數校驗）

用到的設計方法：等價類、邊界值、正反法、流程圖

2)兼容性

3)容錯性：斷電、斷網、網絡切換

4）網絡測試：切換有線無線、延遲、丟包等

四、

根據產品給的需求，確定測試模塊、功能點；細化測試點，測試極端顯示情況

根據數據差異，確定特殊情況的測試

將設計測試用例時沒想到，但是實際測試時遇到的問題加入到測試用例中

五、

1、功能點測試用例：主要使用等價類、邊界值、因果圖進行功能點（輸入框、按鈕等）用例設計

2、場景分析法：畫流程圖，根據流程圖進行場景測試用例的設計

六、

a.梳理需求規格說明書，首先將說明書裏明確寫出的需求點梳理出來，然後寫成用例。

b.邊界值：如遇到文本框，需求裏邊明確規定範圍的，利用邊界值設計用例

七、

涉及到一個待測項目，因此只設計過一個項目的測試用例：

根據需求文檔和原型，按照頁面上的每個操作來一條一條的設計用例，常用的設計測試用例的方法有：邊界值、等價類、正交法等

八、

功能性根據需求編寫正常值、考慮邊界值、異常值用例，根據數據的輸入輸出涉及用例、數據輸出結果多方面驗證、其他考慮兼容性、性能（大多數情況不測試性能）

九、

A:流程和功能點分開設計，以流程優先級最高，各種涉及到的正反向流程都詳細設計，且數據準備充分；

B:功能點設計時，按模塊細分，每個模塊的獨立功能及交互、UI布局一起整理，一般都按照系統中實際情況先後排序，以便測試方便；

C：用例中包括每次執行結果，不通過時包括輸入bug編號及具體bug描述，方便跟蹤；

十、

（不同模塊的交互）接口跟前端的接口對接業務場景主流程異常場景接口主流程前端主流程前端對接口數據解析，前後空格，為空/null的情況，接口必填字段校驗，前端php跟java算法精度統一，弱網訪問，接口數據返回失敗，前端php跟java數據返回超期時間，種cookie,兼容高低版本，兼容pc跟app功能，不同版本接口數據的影響，新老用戶，同步，異步，檢查數據庫數據灰度發布，緩存機制，正則匹配的情況，頁面加載過程中不能操作

十一、

根據策劃的執行案寫詳細的需求分析，一般需求分析的每一行都是一條用例，基本的寫完再加入一些自
己能想到的情況

十二、

一般產品會給出REQ，根據REQ，畫出流程圖，這樣就有一個大概的知道影響那幾個模塊；

根據涉及到的模塊，寫測試點；

根據測試點，再細化，看REQ要求的字段長度，細到一個按鈕的操作，跳轉的頁面，就要看具體REQ要求了

十三、

1、熟悉產品需求
在編寫測試用例前，首先分析產品需求，透徹明白產品功能和業務流程，完全掌握每一個需求點的功能及效果

2、用例編寫
首先使用等價類、邊界值、正常、異常等方法設計每個模塊、每個功能點的測試用例，包括UI界面（對比效果圖）、用戶權限（不同權限展示的模塊不同、操作權限不同）、數據操作（增刪除改查等）；再次通過場景法、業務流設計產品業務測試用例，包括正確流、錯誤流等

十四、

a、本期及往期有關聯的軟需中的需求點
b、明確本期用例需要的測試方法、測試點的覆蓋
c、根據用例在不同公司的實際需求搭用例架構

十五、

後端

1、設計正常流程用例，關註流程的每一步，該記錄的狀態是否正確記錄，該寫的庫表是否正常寫了；整個流程的數據流是不是通暢

2、系統對於異常的容錯處理，每一步操作失敗，是否正常記錄狀態與庫表；對於錯誤狀態的出現，是否能觸發下一步的處理操作

3、大數據量測試：1000條數據同時處理，是否每一條數據都能正確無誤

PC前端

1、查詢條件（各個下拉框顯示正確（is_delete或acitve的過濾條件正常），單個查詢條件每個選項查詢正確，多個查詢條件組合每個選項查詢正確；）

2、輸入框（長度、特殊字符處理（是否要求只包含一種或以下幾種文字：中文、英文大小寫、數字、特殊字符））

3、列表顯示（分頁是否正常顯示，大數據量分頁是否有性能問題；列表每個字段是否取值正確）

4、菜單、鏈接、頁面跳轉是否正常，是否跳到了預期的地方；

5、權限控制，不同的角色和用戶，是否跳轉到了權限不可訪問的地方；前端頁面做了攔截，但是後臺是否返回了用戶不具備權限訪問的數據

APP：

1、按鈕點擊、菜單點擊是否正常跳轉

2、兼容性測試：不同版本的安卓系統、IOS系統，頁面元素是否正常顯示

3、權限控制，不同的角色和用戶，是否跳轉到了權限不可訪問的地方；前端頁面做了攔截，但是後臺是否返回了用戶不具備權限訪問的數據

十六、

• 可支配的時間

根據可支配的時間決定如何設計如何寫、設計以什麽方式寫。

• 項目類型

根據項目的類型，比如接到一個領導中標項目，這樣的用例基本是按照對方（或驗收的第三方）給出的固定格式去填內容，這種的用例一般沒營養只是應付學生都能寫；再比如是自己內部公司的產品的叠代測試，那根據本次的測試內容去靈活設計。

• 用例格式（方式）

測試用例格式（方式）不限定，如果是公司內部的產品的叠代測試，測試用例格式方式不限定，你可以天馬行空發揮想象，但是就一個宗旨：我認為能達到測試目的用例就是一個好的測試設計。寫的很規整但是覆蓋不全、用例重復也不是好的測試設計。

• 用例框架

用例的作用是給測試過程提供服務的，假如你的用例覆蓋的很全、也沒有重復用例、也很規整，但是你的框架設計的不好，實際測試的時候測試時間發生了變化，你需要在很短的時間提煉出最需要測試的內容，這時就體現出框架的重要性。

• 特殊情況（適合老司機）

臨時得到領導通知沒時間設計測試用例怎麽辦？此時需要發揮你老司機的看家本領，憑借你多年的測試經驗和對產品的熟悉程度再加上你對bug的敏感度，在腦子裏自動創建探索式測試用例。

十七、

根據需求文檔編寫測試用例，一般後臺的那些增刪改查之類就用常說的那些邊界值法、等價類法寫；

涉及到邏輯，關聯的就會串到一塊，按照邏輯思路整個寫下來

十八、

單純的從功能角度來說，直接把主要的功能點寫在用例模板裏面即可，把要測試的點所有想到的都寫出來或者部分也行，在實際測試功能時候，把沒有想到的點在補充上，設計用例時有時候會用到等價類、邊界值、錯誤猜測的法穿插到設計用例的思路裏面

十九、

一般是先分析需求，再結合測試用例的設計方法，例如等價類、邊界值等設計測試用例，有時候也會根據以往的測試中遇到的情況設計測試用例。

二十、

1、需求了解，通過過對需求的了解，寫一個對本次測試功能點理解的文檔，再對需求分析人員、測試、開發宣講自己對需求的解讀

2、邏輯復雜時，用思維導圖列出功能點對應的正常場景\異常場景\組合場景

3、通過用例模板來寫用例的輸入輸出

4、用例評審

二十一、

我這裏是用思維導圖當作測試用例的測試的。

組內分配任務後：

1）找文檔：先整理下目前能拿到哪些產品文檔、技術文檔，要到產品原型、交互原型、接口文檔。整理放一個目錄或收藏夾下，便於查找。

2）梳理功能點及涉及頁面：新建一個思維導圖，一邊看原型一遍寫導圖，記錄原型裏的每個功能：為啥做（目的）？涉及幾個頁面？每個功能總共能做哪幾件事？然後再隨手記一些想到的測試點（交互、流程等）。

3）找產品答疑：上一步梳理完功能點，可能會找到一些不明白的地方，或者產品沒考慮到的地方，然後再補充下。

4）轉換為測試點：考慮下之後測試時的順序，將功能點轉化為測試點，保證功能提測後，自己能按照導圖測試，避免導圖的不實用。

5）組內評審：講述自己的負責的功能是怎麽一回事，給別人說明白了。然後講一下自己都考慮哪些方面、怎麽測的（交互、邊界值、流程等），然後相互討論下，看看哪裏有沒有漏的。

6）評審後調整補充測試導圖，然後設計測試數據（等價類／邊界值），再準備測試數據。

二十二、

l 根據需求文檔，確保覆蓋所有本期功能點；

l 場景：根據用戶使用的所有相關場景，設計用例；

l 等價類：

l 邊界值：（分別設計等於邊界值，小於邊界值， 大於邊界值時）；

l 流程圖：根據程序判斷分支，設計不同前提條件下的實現結果；

l 正常值 & 異常值。

二十三、

通常使用等價類邊界值，場景法，因果圖，隨機正則，根據產品需求使用以上方法進行測試用例的設計

二十四、

（1）編寫接口用例時用到等價類劃分和邊界值的方法。

例：編寫"創建會員"測試用例時，會員id使用等價類劃分的方法，找出有效等價類和無效等價類，分別作為請求成功和請求失敗的條件；會員id最長限制為11個數字，使用邊界值劃分的設置2到3個邊界值點編寫測試用例；

（2）采用因果圖的方法，查看那些那些輸入會產生那些結果；

例：創建不同的規格的廣告，輸出不同的樣式及內容；

（3）根據測試被測系統所積累的經驗，使用錯誤猜測和隨機測試來補充用例；

（4）根據tapd中的描述，有針對性的創建測試用例；

二十五、

（1）拿到需求後，先分析需求，確定測試範圍，明確測試任務；

（2）列出所有功能點和交易流程；

（3）根據列好的功能點設計用例，如邊界值分析/等價類劃分等方法；根據列出的交易流程發散出分支流程和異常流程場景

二十六、

我在工作中通常是拿到需求文檔後，與產品經理溝通，在充分理解需求的基礎上開始編寫測試用例：

（1）劃分功能模塊，編寫基本功能測試用例

（2）劃分流程，畫流程圖，整理成場景用例

（3）整理平臺間及平臺內功能模塊之間的數據關聯，編寫聯調測試用例。

設計測試用例中用到的方法：

（1）正常功能流程測試用例

（2）異常功能流程測試用例

二十七、

1. 等價類輸入條件：有效等價類、無效等價類

2. 功能路徑混合分析：比如一個功能，存在多個入口，每個入口攜帶參數以及跳轉

3. 邊界值：存在輸入的，確定範圍的

4. 錯誤猜測：空值提交，重復操作，負值，特殊字符，html代碼等

5. 並行：被打斷後重新回到被測軟件，鎖屏、後臺等重新喚醒

二十八、

1) 理解對應的需求,根據需求設計測試用例; 2)會對邊界地方設計一些測試用例

二十九、

主要以個的

1.絡情況

2G,3G,4G,WIFI

2.適配情況 Android iOS

特別說下

Android 對於些控件的處理，在低的系統版本是不兼容的。rd經常會犯的錯

誤。

3.根據業務的功能模塊圖，延伸到涉及此次改動，影響的其他功能的功能點。

如，訂單的改動，肯定會要增加收和客戶

CRM的case。如上詞條，增加個點：就

是要熟練的了解業務，個功能的改動，如果不熟練了解業務的話，那想到的點，肯定只

只限制於這個需求。

4.涉及case的法

錯誤猜測法

看到個需求後，應該先想，怎麽能才出錯。

邊界值法

常談，取最值，最值，中間值

5.性能測試

主要涉及些切換和拉取的操作的時候

可以寫個腳本，切換

tab，50次，查看內存

拉取，

50次，查看內存

6.壓測試

主要測試接的壓，因為不是我這邊做，不是很清楚具體實現，主要是測試接並發的

時候，看返回錯誤率。

付適配關註點：

Android適配關註點，踩坑數，共勉。

tip：如果公司接第三數據統計後臺（友盟，騰訊MNT），看下top10的機型，重點

關註適配。

1.分辨率適配

480*800，

2.商機型適配

華為，

oppo，vivo，錘，

3.特殊ROM適配

MIUI, ColorOS，ymeOS，SmartisanOS，google親

4.針對CPU架構適配

X86 機，和普通的android機

5.系統版本

4.0 4.3 4.4 5.X 6.X 7.X 8.X

這邊說下，

4.X以下的版本需要兼容4.0.X和4.3.X和4.4.X 因為各個版本需求很。

ios 適配

iOS 8 iOS 9 iOS 10

三十、

1、需要了解需求。需求的來源最主要的是產品PRD（包括頁面展示、跳轉等說明）和開發的設計文檔（修改內容的主要邏輯、修改內容的影響點、新老數據兼容、緩存處理、風險點、發布順序等）。只有了解需求才能全面考慮怎麽做到覆蓋全面，不漏測。

2、需要選好用例模板。選擇適合自己項目的用例模板很關鍵，因為用例是需要評審的，需要自己給別人展示並講解的。個人推薦用腦圖，用excel表不是很容易展示自己的邏輯。

3、用例要素。

預制條件，說清楚該條用例執行的前置條件。

用例分層，核心的幾個要素從一級模塊->二級模塊->。。。->具體的某個功能點，清晰的分層能很明白交代自己測試的邏輯，讓自己和他人明白該模塊是否完成全部覆蓋。

預期結果，指出該條用例執行應該得到的結果。

4、用例的設計方法。目前接觸的到有等價類、邊界值和正交分解法。正確的使用設計方法也是體現覆蓋率的良好途徑。

三十一、

1.熟悉清楚系統業務及需求，這樣才能編寫出高效的測試用例；

2.根據公司測試用例編寫規範、模版編寫測試用例；

3.測試用例編寫思路清晰，要有順序、優先級、邏輯性；

4.根據項目類型、特性、情況分析出系統核心、重點部分，保證這部分用例的高覆蓋率，剩余部分用例如果項目時間緊急可寫粗點；

5.測試過程中對系統測試用例進行維護；

三十二、

無

三十三、

我目前的公司做的是雲平臺項目，公司中沒有任何需求文檔，需求一般是經理或市場反饋，需要加一個功能，然後參考其它同行產品，UI進行設計，前端依據圖稿做頁面，JAVA寫代碼方法，測試依據展現的功能進行測試。最初為了快速熟悉業務，按展現的功能及使用流程，設計了一遍測試用例，但基本上未按測試用例執行。平臺裏就是一套系統，不停的加入新功能。測試元素中，輸入情況也不多，偶爾我也會用不同的電腦系統、瀏覽器做兼容測試。常規的測試就是輸入、流程分析、邊界測試。

如何設計測試用例