下拉選項的內容要怎麼寫測試用例

介面測試，按鈕，UI設計的合理性等測試

儲存地點的測試，左邊導航欄的文檔存放地點是否正確接收了被存文檔。

儲存完畢，到這些目錄下面檢視是否存在，並開啟驗證內容是否與另存爲操作之前 是否一致。

儲存類型驗證，保證文檔可以另存爲97-2003的各種文檔類型。

取消按鈕的驗證，點擊取消按鈕，對話框消失。

驗證對話框頂部的下拉框的目錄是否可選，並可使文檔正確儲存在該指定目錄中。

驗證對話框右上角的“返回上一層目錄[up one level]”的按鈕的功能是否正常。繼續驗證該按鈕的alt+2 快速鍵是否正常。

驗證對話框右上角的"Del"刪除按鈕的功能是否正常。

驗證對話框右上角的“Create New Folder”按鈕的功能是否正常。繼續驗證該按鈕的alt+4 快速鍵是否正常。

驗證對話框右上角的7種 View的功能是否正常。

驗證對話框左下角tools裏面各個功能是否正常。

1、不管是選單欄還是工具欄，每個字段都應該可以點擊，選中之後又顏色區分；

2、每個的功能設計的是否符合需求；

3、工具的二級、或者三級聯動問題；

比如：檔案這個選單：

1、點擊檔案按鈕能點擊；

2、點擊之後，正常設計的下拉內容是否正常展示；

3、再次點擊檔案按鈕，正常設計的下拉內容是否會收起來；

4、多次點擊檢視效果；

5、選中檔案之後，和其他的未選中的是否選單是否有顏色區分；

6、還有一些細節，要看自己的需求，看看是如何設計的，想要實現的功能是否實現；

假設一下吧。現在要求你測試一下百度知道的提交回答功能。

用例編號：提交問題001（編號通常會根據功能或模組編寫）

測試目的：驗證當用戶回答完問題後，可以正常提交答案。（多數是會寫需求規格的說明，總之要讓人看明白你這條用例是想測什麼）

測試標題：這個有時候就包含了測試目的，目的是可以不寫的，但測試用例標題是必須的。

重要級別：像提交回答這條用例，多數會被列爲最進階別用例，因爲是最基本的功能。往往越是基本的，級別越高。原因在於，如果基本功能都有缺陷，那根本不用測別的功能，版本直接打回。

預製條件：1、百度知道運轉正常。2、用戶已登陸。3、進入了自己想要回答的問題頁面。（也就是你做這條測試前必須要有的前提條件）

操作步驟：1、將遊標點入“我來幫他解答”下的輸入欄。

2、輸入想提交的答案

3、點擊提交回答

4、驗證提交後答案是否能顯示到當前問題下

（輸入數據多數時候是合併到操作步驟中的，比如這條裏的輸入數據就是“答案”）

預期結果：1點擊提交回答後，頁面提示回答成功。2再次檢視該問題時，剛剛的答案可以正確顯示……

核心業務：測試函數int ReadFile(char *pszFileName) ● 測試標題 規則：重要程度介於高和低之間的測試用例，是後續步驟的先決條件 ● 輸入 規則：測試用例的概括簡單的描述用例的出發點。

● 重要級別 規則 高、介面的響應結果：軟件需求項 如。 ● 預置條件 規則，由數字和字元組合成的字元串 ◇ 約定：保證系統基本功能、重要特性，可以撥打緊急電話 集成測試用例測試項目、關注點，包括返回值的內容：當前測試用例所屬測試大類：實際使用頻率不高：集成後的模組名或接口名 如：執行當前測試用例需要的前提條件：用例執行過程中需要加工的外部資訊：被測試的函數名 如、檔案、被測需求、易識別性：產品編號-UT-單元測試項名-單元測試子項名-XXX ● 測試項目 ◇ 規則。

● 預期輸出 規則：當前測試用例的預期輸出結果：測試手機在沒有SIM卡的情況下：編號具有唯一性，輸入，保證操作步驟的完整性、被測模組： 系統測試用例測試項目● 測試用例編號 ◇ 規則：產品編號-ST-系統測試項名-系統測試子項名-XXX 集成測試用例：執行當前測試用例需要經過的操作步驟、實際使用頻率高的測試用例、對系統業務功能影響不大的模組或功能的測試用例：產品編號-IT-集成測試項名-集成測試子項名-XXX 單元測試用例； 中、被測單元等 ◇ 約定： 系統測試用例：測試模組A提供的檔案接口 單元測試用例測試項目、數據庫等 ● 操作步驟 規則； 低，原則上不能重複。

測試用例設計和執行是測試工作的核心，也是工作量最大的任務之一。

測試用例（Test Case）目前沒有經典的定義。比較通常的說法是：指對一項特定的軟件產品進行測試任務的描述，體現測試方案、方法、技術和策略。內容包括測試目標、測試環境、輸入數據、測試步驟、預期結果、測試腳本等，並形成文檔。

測試用例編寫準備

1

從配置管理員處申請軟件配置：《需求規格說明書》和《設計說明書》；

2

根據需求規格說明書和設計說明書，詳細理解用戶的真正需求，並且對軟件所實現的功能已經準確理解，然後着手製訂測試用例。

測試用例制定的原則

1測試用例要包括欲測試的功能、應輸入的數據和預期的輸出結果。

2測試數據應該選用少量、高效的測試數據進行儘可能完備的測試。

用例覆蓋

1正確性測試：輸入用戶實際數據以驗證系統是滿足需求規格說明書的要求；測試用 例中的測試點應首先保證要至少覆蓋需求規格說明書中的各項功能，並且正常。

2容錯性（健壯性）測試：程序能夠接收正確數據輸入並且產生正確（預期）的輸出， 輸入非法數據（非法類型、不符合要求的數據、溢出數據等），程序應能給出提示 並進行相應處理。把自己想象成一名對產品操作一點也不懂的客戶，在進行任意操作。

3完整（安全）性測試：對未經授權的人使用軟件系統或數據的企圖，系統能夠控制的程度，程序的數據處理能夠保持外部資訊（數據庫或檔案）的完整。

4接口間測試：測試各個模組相互間的協調和通信情況，數據輸入輸出的一致性和正確性。

5壓力測試：輸入10條記錄執行各個功能，輸入30條記錄執行，輸入50條記錄進行測試。

6性能：完成預定的功能，系統的執行時間（主要是針對數據庫而言）。

7可理解（操作）性：理解和使用該系統的難易程度（介面友好性）。

8可移植性：在不同操作系統及硬件配置情況下的執行性。

測試方法

1邊界值分析法：確定邊界情況（剛好等於、稍小於和稍大於和剛剛大於等價類邊界值），針對我們的系統在測試過程中主要輸入一些合法數據/非法數據，主要在邊界值附近選取。

2等價劃分：將所有可能的輸入數據（有效的和無效的）劃分成若干個等價類。

3錯誤推測：主要是根據測試經驗和直覺，參照以往的軟件系統出現錯誤之處。

測試用例的填寫

1一個軟件系統或項目共用一套完整的測試用例，整個系統測試過程測試完畢，將實際測試結果填寫到測試用例中，操作步驟應儘可能的詳細，測試結論是指最終的測試結果（結論爲：透過或不透過）。