App的基本測試點
2.1安全測試
2.1.1軟體許可權
1）扣費風險：包括髮送簡訊、撥打電話、連線網路等
2）隱私洩露風險：包括訪問手機資訊、訪問聯絡人資訊等
3）對App的輸入有效性校驗、認證、授權、敏感資料儲存、資料加密等方面進行檢測
4）限制/允許使用手機功能接人網際網路
5）限制/允許使用手機發送接受資訊功能
6）限制/允許應用程式來註冊自動啟動應用程式
7）限制或使用本地連線
8）限制/允許使用手機拍照或錄音
9）限制/允許使用手機讀取使用者資料
10) 限制/允許使用手機寫人使用者資料
11) 檢測App的使用者授權級別、資料洩漏、非法授權訪問等
2.1.2安裝與解除安裝安全性
1）應用程式應能正確安裝到裝置驅動程式上
2）能夠在安裝裝置驅動程式上找到應用程式的相應圖示
3）是否包含數字簽名信息
4）JAD檔案和JAR包中包含的所有託管屬性及其值必需是正確的
5）JAD檔案顯示的資料內容與應用程式顯示的資料內容應一致
6）安裝路徑應能指定
7）沒有使用者的允許, 應用程式不能預先設定自動啟動
8）解除安裝是否安全, 其安裝進去的檔案是否全部解除安裝
9）解除安裝使用者使用過程中產生的檔案是否有提示
10）其修改的配置資訊是否復原
11）解除安裝是否影響其他軟體的功能
12）解除安裝應該移除所有的檔案
2.1.3資料安全性
1）當將密碼或其他的敏感資料輸人到應用程式時,其不會被儲存在裝置中, 同時密碼也不會被解碼
2）輸人的密碼將不以明文形式進行顯示
3）密碼, 信用卡明細, 或其他的敏感資料將不被儲存在它們預輸人的位置上
4）不同的應用程式的個人身份證或密碼長度必需至少在4一8 個數字長度之間
5）當應用程式處理信用卡明細, 或其他的敏感資料時, 不以明文形式將資料寫到其它單獨的檔案或者臨時檔案中。以6）防止應用程式異常終止而又沒有側除它的臨時檔案, 檔案可能遭受人侵者的襲擊, 然後讀取這些資料資訊。
7）當將敏感資料輸人到應用程式時, 其不會被儲存在裝置中
8）備份應該加密, 恢復資料應考慮恢復過程的異常通訊中斷等, 資料恢復後再使用前應該經過校驗
9）應用程式應考慮系統或者虛擬機器器產生的使用者提示資訊或安全替告
10）應用程式不能忽略系統或者虛擬機器器產生的使用者提示資訊或安全警告, 更不能在安全警告顯示前,，利用顯示誤導資訊欺騙使用者，應用程式不應該模擬進行安全警告誤導使用者
11）在資料刪除之前，應用程式應當通知使用者或者應用程式提供一個“取消”命令的操作
12）“ 取消” 命令操作能夠按照設計要求實現其功能
13）應用程式應當能夠處理當不允許應用軟體連線到個人資訊管理的情況
14）當進行讀或寫使用者資訊操作時, 應用程式將會向用戶傳送一個操作錯誤的提示資訊
15）在沒有使用者明確許可的前提下不損壞側除個人資訊管理應用程式中的任何內容Μ
16）應用程式讀和寫資料正確。
17）應用程式應當有異常保護。
18）如果資料庫中重要的資料正要被重寫, 應及時告知使用者
19）能合理地處理出現的錯誤
20）意外情況下應提示使用者
2.1.4通訊安全性
1）在執行其軟體過程中, 如果有來電、SMS、EMS、MMS、藍芽、紅外等通訊或充電時,是否能暫停程式，優先處理通訊, 並在處理完畢後能正常恢復軟體, 繼續其原來的功能
2）當創立連線時, 應用程式能夠處理因為網路連線中斷, 進而告訴使用者連線中斷的情況
3）應能處理通訊延時或中斷
4）應用程式將保持工作到通訊超時, 進而傳送給使用者一個錯誤資訊指示有連線錯誤
5）應能處理網路異常和及時將異常情況通報使用者
6）應用程式關閉或網路連線不再使用時應及時關閉) 斷開
7) HTTP、HTTPS覆蓋測試
--App和後臺服務一般都是通過HTTP來互動的，驗證HTTP環境下是否正常；
--公共免費網路環境中（如：麥當勞、星巴克等）都要輸入使用者名稱和密碼，通過SSL認證來訪問網路，需要對使用HTTP Client的library異常作捕獲處理。
2.1.5人機介面安全性
1）返回選單總保持可用
2）命令有優先權順序
3）聲音的設定不影響應用程式的功能
4）應用程式必需利用目標裝置適用的全屏尺寸來顯示上述內容
5）應用程式必需能夠處理不可預知的使用者操作,例如錯誤的操作和同時按下多個鍵
2.2安裝、解除安裝測試
驗證App是否能正確安裝、執行、解除安裝以及操作過程和操作前後對系統資源的使用情況
2.2.1安裝
1）軟體在不同作業系統（Palm OS、Symbian、Linux、Android、iOS、BlackBerry OS 6.0、WindowsPhone 7）下安裝是否正常。
2）軟體安裝後的是否能夠正常執行，安裝後的資料夾及檔案是否寫到了指定的目錄裡。
3）軟體安裝各個選項的組合是否符合概要設計說明
4)）軟體安裝嚮導的UI測試
5）軟體安裝過程是否可以取消，點選取消後，寫入的檔案是否如概要設計說明處理
6）軟體安裝過程中意外情況的處理是否符合需求（如宕機，重啟，斷電）
7）安裝空間不足時是否有相應提示
8）安裝後沒有生成多餘的目錄結構和檔案
9）對於需要通過網路驗證之類的安裝，在斷網情況下嘗試一下
10）還需要對安裝手冊進行測試，依照安裝手冊是否能順利安裝
2.2.2解除安裝
1）直接刪除安裝資料夾解除安裝是否有提示資訊。
2）測試系統直接解除安裝程式是否有提示資訊。
3）測試解除安裝後文件是否全部刪除所有的安裝資料夾。
4）解除安裝過程中出現的意外情況的測試（如宕機、斷電、重啟）。
5）解除安裝是否支援取消功能，單擊取消後軟體解除安裝的情況 。
6）系統直接解除安裝UI測試，是否有解除安裝狀態進度條提示 。
2.3 UI測試
測試使用者介面(如選單、對話方塊、視窗和其它可規控制元件)佈局、風格是否滿足客戶要求、文字是否正確、頁面是否美觀、文字、圖片組合是否完美、操作是否友好等。
UI測試的目標是確保使用者介面會通過測試物件的功能來為使用者提供相應的訪問或瀏覓功能。確保使用者介面符合公司或行業的標準。包括使用者友好性、人性化、易操作性測試。
2.3.1導航測試
1）按鈕、對話方塊、列表和視窗等；或在不同的連線頁面之間需要導航
2）是否易於導航，導航是否直觀
3）是否需要搜尋引擎
4）導航幫助是否準確直觀
5）導航與頁面結構、選單、連線頁面的風格是否一致
2.3.2圖形測試
1）橫向比較。各控制元件操作方式統一
2）自適應介面設計，內容根據視窗大小自適應
3）頁面標籤風格是否統一
4）頁面是否美觀
5）頁面的圖片應有其實際意義而要求整體有序美觀
6）圖片質量要高且圖片尺寸在設計符合要求的情況下應儘量小
7）介面整體使用的顏色不宜過多
2.3.3內容測試
1）輸入框說明文字的內容與系統功能是否一致
2）文字長度是否加以限制
3）文字內容是否表意不明
4）是否有錯別字
5）資訊是否為中文顯示
6）是否有敏感性詞彙、關鍵詞
7）是否有敏感性圖片，如：涉及版權、專利、隱私等圖片
2.4功能測試
根據軟體說明或使用者需求驗證App的各個功能實現，採用如下方法實現並評估功能測試過程：
1)採用時間、地點、物件、行為和背景五元素或業務分析等方法分析、提煉App的使用者使用場景，對比說明或需求，整理出內在、外在及非功能直接相關的需求，構建測試點，並明確測試標準，若使用者需求中無明確標準遵循，則需要參考行業或相關國際標準或準則。
2)根據被測功能點的特性列丼出相應型別的測試用例對其進行覆蓋，如；涉及輸入的地方需要考慮等價、邊界、負面、異常或非法、場景回滾、關聯測試等測試型別對其進行覆蓋。
3)在測試實現的各個階段跟蹤測試實現與需求輸入的覆蓋情況，及時修正業務或需求理解錯誤。
2.4.1執行
1）App安裝完成後的試執行，可正常開啟軟體。
2）App開啟測試，是否有載入狀態進度提示。
3）App開啟速度測試，速度是否可觀。
4）App頁面間的切換是否流暢，邏輯是否正確
5）註冊
--同表單編輯頁面
--使用者名稱密碼長度
--註冊後的提示頁面
--前臺註冊頁面和後臺的管理頁面資料是否一致
--註冊後，在後臺管理中頁面提示
6）登入
--使用合法的使用者登入系統。
--系統是否允許多次非法的登陸，是否有次數限制。
--使用已經登陸的賬號登陸系統是否正確處理。
--使用禁用的賬號登陸系統是否正確處理。
--使用者名稱、口令（密碼）錯誤或漏填時能否登陸。
--刪除或修改後的使用者，原使用者登陸。
--不輸入使用者口令和使用者、重複點（確定或取消按鈕）是否允許登陸。
--登陸後，頁面中登陸資訊。
7）登出
--登出原模組，新的模組系統能否正確處理。
--終止登出能否返回原模組，原使用者。
--登出原使用者，新使用者系統能否正確處理。
--使用錯誤的賬號、口令、無許可權的被禁用的賬號進行登出
2.4.2應用的前後臺切換
1) APP切換到後臺，再回到app，檢查是否停留在上一次操作介面。
2) APP切換到後臺，再回到app，檢查功能及應用狀態是否正常，IOS4和IOS5的版本的處理機制有的不一樣。
3) app切換到後臺，再回到前臺時，注意程式是否崩潰，功能狀態是否正常，尤其是對於從後臺切換回前臺資料有自動更新的時候。
4) 手機鎖屏解屏後進入app注意是否會崩潰，功能狀態是否正常，尤其是對於從後臺切換回前臺資料有自動更新的時候。
5) 當App使用過程中有電話進來中斷後再切換到app，功能狀態是否正常
6) 當殺掉app程序後，再開啟app，app能否正常啟動。
7) 出現必須處理的提示框後，切換到後臺，再切換回來，檢查提示框是否還存在，有時候會出現應用自動跳過提示框的缺陷。
8) 對於有資料交換的頁面，每個頁面都必需要進行前後臺切換、鎖屏的測試，這種頁面最容易出現崩潰。
2.4.3免登入
很多應用提供免登入功能，當應用開啟時自動以上一次登入的使用者身份來使用app.
1) app有免登入功能時，需要考慮IOS版本差異。
2) 考慮無網路情況時能否正常進入免登入狀態。
3) 切換使用者登入後，要校驗使用者登入資訊及資料內容是否相應更新，確保原使用者退出。
4) 根據MTOP的現有規則，一個帳戶只允許登入一臺機器。所以，需要檢查一個帳戶登入多臺手機的情況。原手機裡的使用者需要被踢出，給出友好提示。
5) app切換到後臺，再切回前臺的校驗
6) 切換到後臺，再切換回前臺的測試
7) 密碼更換後，檢查有資料交換時是否進行了有效身份的校驗
8) 支援自動登入的應用在進行資料交換時，檢查系統是否能自動登入成功並且資料操作無誤。
9) 檢查使用者主動退出登入後，下次啟動app，應停留在登入介面
2.4.4資料更新
根據應用的業務規則，以及資料更新量的情況，來確定最優的資料更新方案。
1) 需要確定哪些地方需要提供手動重新整理，哪些地方需要自動重新整理，哪些地方需要手動+自動重新整理。
2) 確定哪些地方從後臺切換回前臺時需要進行資料更新。
3) 根據業務、速度及流量的合理分配，確定哪些內容需要實時更新，哪些需要定時更新。
4) 確定資料展示部分的處理邏輯，是每次從服務端請求，還是有快取到本地，這樣才能有針對性的進行相應測試。
5) 檢查有資料交換的地方，均有相應的異常處理。
2.4.5離線瀏覽
很多應用會支援離線瀏覽，即在本地客戶端會快取一部分資料供使用者檢視。
1) 在無網路情況可以瀏覽本地資料
2) 退出app再開啟app時能正常瀏覽
3) 切換到後臺再切回前臺可以正常瀏覽
4) 鎖屏後再解屏回到應用前臺可以正常瀏覽
5) 在對服務端的資料有更新時會給予離線的相應提示
1) 當客戶端有新版本時，有更新提示。
2) 當版本為非強制升級版時，使用者可以取消更新，老版本能正常使用。使用者在下次啟動app時，仍能出現更新提示。
3) 當版本為強制升級版時，當給出強制更新後用戶沒有做更新時，退出客戶端。下次啟動app時，仍出現強制升級提示。
4) 當客戶端有新版本時，在本地不刪除客戶端的情況下，直接更新檢查是否能正常更新。
5) 當客戶端有新版本時，在本地不刪除客戶端的情況下，檢查更新後的客戶端功能是否是新版本。
6) 當客戶端有新版本時，在本地不刪除客戶端的情況下，檢查資源同名檔案如圖片是否能正常更新成最新版本。如果以上無法更新成功的，也都屬於缺陷。
2.4.7定位、照相機服務
1) App有用到相機，定位服務時，需要注意系統版本差異
2) 有用到定位服務、照相機服務的地方，需要進行前後臺的切換測試，檢查應用是否正常。
3) 當定位服務沒有開啟時，使用定位服務，會友好性彈出是否允許設定定位提示。當確定允許開啟定位時，能自動跳轉到定位設定中開啟定位服務。
4) 測試定位、照相機服務時，需要採用真機進行測試。
2.4.8時間測試
客戶端可以自行設定手機的時區、時間，因此需要校驗該設定對app的影響。
--中國為東8區，所以當手機設定的時間非東8區時，檢視需要顯示時間的地方，時間是否展示正確，應用功能是否正常。時間一般需要根據伺服器時間再轉換成客戶端對應的時區來展示，這樣的使用者體驗比較好。比如發表一篇微博在服務端記錄的是10：00，此時，華盛頓時間為22：00，客戶端去瀏覽時，如果設定的是華盛頓時間,則顯示的發表時間即為22:00,當時間設回東8區時間時，再檢視則顯示為10：00。
1) 檢查push訊息是否按照指定的業務規則傳送
2) 檢查不接受推送訊息時，檢查使用者不會再接收到push.
3) 如果使用者設定了免打擾的時間段，檢查在免打擾時間段內，使用者接收不到PUSH。
在非免打擾時間段，使用者能正常收到push。
4) 當push訊息是針對登入使用者的時候，需要檢查收到的push與使用者身份是否相符，沒有錯誤地將其它人的訊息推送過來。一般情況下，只對手機上最後一個登入使用者進行訊息推送。
5) 測試push時，需要採用真機進行測試。
2.5效能測試
評估App的時間和空間特性 ：
1)極限測試：在各種邊界壓力情況下，如電池、儲存、網速等，驗證App是否能正確響應。
--記憶體滿時安裝App
--執行App時手機斷電
--執行App時斷掉網路
2)響應能力測試：測試App中的各類操作是否滿足使用者響應時間要求 。
--App安裝、解除安裝的響應時間
--App各類功能性操作的影響時間
3)壓力測試：反覆/長期操作下、系統資源是否佔用異常。
--App反覆進行安裝解除安裝，檢視系統資源是否正常
--其他功能反覆進行操作，檢視系統資源是否正常
4)效能評估：評估典型使用者應用場景下，系統資源的使用情況。
5)Benchmark測試（基線測試）：與競爭產品的Benchmarking, 產品演變對比測試等。
2.6交叉事件測試
針對智慧終端應用的服務等級劃分方式及實時特性所提出的測試方法。交叉測試又叫事件或衝突測試，是指一個功能正在執行過程中，同時另外一個事件或操作對該過程進行干擾的測試。如；App在前/後臺執行狀態時與來電、檔案下載、音樂收聽等關鍵運用的互動情況測試等。交叉事件測試非常重要，能發現很多應用中潛在的效能問題。
1） 多個App同時執行是否影響正常功能
2）App執行時前/後臺切換是否影響正常功能
3）App執行時撥打/接聽電話
4）App執行時傳送/接收資訊
5）App執行時傳送/收取郵件
6）App執行時切換網路（2G、3G、wifi）
7）App執行時瀏覽網路
8）App執行時使用藍芽傳送/接收資料
9）App執行時使用相機、計算器等手機自帶裝置
2.7相容測試
主要測試內部和外部相容性
1）與本地及主流App是否相容
2）基於開發環境和生產環境的不同，檢驗在各種網路連線下(WiFi、GSM、GPRS、EDGE、WCDMA、CDMA1x、CDMA2000、HSPDA等)，App的資料和運用是否正確
3）與各種裝置是否相容，若有跨系統支援則需要檢驗是否在各系統下，各種行為是否一致
--不同作業系統的相容性，是否適配
--不同手機螢幕解析度的相容性
--不同手機品牌的相容性
2.8迴歸測試
1）Bug修復後且在新版本釋出後需要進行迴歸測試。
2）Bug修復後的迴歸測試在交付前、要進行全量用例的迴歸測試。
2.9升級、更新測試
新版版釋出後，配合不同網路環境的自勱更新提示及下載、安裝、更新、啟勱、執行的驗證測試。
1）測試升級後的功能是否與需求說明一樣
2）測試與升級模組相關的模組的功能是否與需求一致
3）升級安裝意外情況的測試（如宕機、斷電、重啟）
4）升級介面的UI測試
5）不同作業系統間的升級測試
2.10使用者體驗測試
以主觀的普通消費者的角度去感知產品或服務的舒適、有用、易用、友好親切程度。通過不同個體、獨立空間和非經驗的統計複用方式去有效評價產品的體驗特性提出修改意見提升產品的潛在客戶滿意度。
1）是否有空資料介面設計，引導使用者去執行操作。
2）是否濫用使用者引導。
3）是否有不可點選的效果，如：你的按鈕此時處於不可用狀態，那麼一定要灰掉，或者拿掉按鈕，否則會給使用者誤導
4）選單層次是否太深
5）互動流程分支是否太多
6）相關的選項是否離得很遠
7）一次是否載入太多的資料
8）介面中按鈕可點選範圍是否適中
9）標籤頁是否跟內容沒有從屬關係，當切換標籤的時候，內容跟著切換
10）操作應該有主次從屬關係
11）是否定義Back的邏輯。涉及軟硬體互動時，Back鍵應具體定義
12）是否有橫屏模式的設計，應用一般需要支援橫屏模式，即自適應設計
2.11 硬體環境測試
1）手機開鎖屏對執行中的App的影響
2）切換網路對執行中的App的影響
3）執行中的App前後臺切換的影響
4）多個執行中的App的切換
5）App執行時關機
6）App執行時重啟系統
7）App執行時充電
8）App執行時kill掉程序再開啟
手機的網路目前主要分為2G、3G、wifi。目前2G的網路相對於比較慢，測試時尤其要注意此塊的測試。
1) 無網路時，執行需要網路的操作，給予友好提示，確保程式不出現crash。
2) 內網測試時，要注意選擇到外網操作時的異常情況處理。
3) 在網路訊號不好時，檢查功能狀態是否正常，確保不因提交資料失敗而造成crash。
4) 在網路訊號不好時，檢查資料是否會一直處於提交中的狀態，有無超時限制。如遇資料交換失敗時要給予提示。
5) 在網路訊號不好時，執行操作後，在回撥沒有完成的情況下，退出本頁面或者執行其他操作的情況，有無異常情況。此問題也會經常出現程式crash。
2.11.3伺服器宕機或出現404、502等情況下的測試
後臺服務牽涉到DNS、空間服務商的情況下會影響其穩定性，如：當出現域名解析故障時，你對後臺API的請求很可能就會出現404錯誤，丟擲異常。這時需要對異常進行正確的處理，否則可能會導致程式不能正常工作。
2.12介面測試
服務端一般會提供JSON格式的資料給客戶端，所以我們在服務端需要進行介面測試，確保服務端提供的介面並轉換的JSON內容正確，對分支、異常流有相應的返回值。此塊測試可以採用itest框架進行測試。最方便的是採用httpclient進行介面測試。
進行服務端測試時，需要開發提供一份介面文件。
2.13客戶端資料庫測試
1）一般的增、刪、改、查測試。
2） 當表不存在時是否能自動建立，當資料庫表被刪除後能否再自建，資料是否還能自動從服務端中獲取回來並儲存。
3） 在業務需要從服務端取回資料儲存到客戶端的時候，客戶端能否將資料儲存到本地。
4） 當業務需要從客戶端取資料時，檢查客戶端資料存在時，app資料是否能自動從客戶端資料中取出，還是仍然會從伺服器端獲取？檢查客戶端資料不存在時，app資料能否自動從伺服器端獲取到並儲存到客戶端
5） 當業務對資料進行了修改、刪除後，客戶端和服務端是否會有相應的更新。
2.14登陸、新增、刪除、查詢模組
① 使用者名稱和密碼都符合要求(格式上的要求)
② 使用者名稱和密碼都不符合要求(格式上的要求)
③ 使用者名稱符合要求，密碼不符合要求(格式上的要求)
④ 密碼符合要求，使用者名稱不符合要求(格式上的要求)
⑤ 使用者名稱或密碼為空
⑥ 資料庫中不存在的使用者名稱，不存在的密碼
⑦ 資料庫中存在的使用者名稱，錯誤的密碼
⑧ 資料庫中不存在的使用者名稱，存在的密碼
⑨ 輸入的資料前存在空格
⑩ 輸入正確的使用者名稱密碼以後按[enter]是否能登陸
2.14.2新增
① 要新增的資料項均合理，檢查資料庫中是否添加了相應的資料
② 留出一個必填資料為空
③ 按照邊界值等價類設計測試用例的原則設計其他輸入項的測試用例
④ 不符合要求的地方要有錯誤提示
⑤ 是否支援table鍵
⑥ 按enter是否能儲存
⑦ 若提示不能儲存，也要察看資料庫裡是否多了一條資料
2.14.3刪除
① 刪除一個數據庫中存在的資料，然後檢視資料庫中是否刪除
② 刪除一個數據庫中並不存在的資料，看書否有錯誤提示，並且資料庫中沒有資料被刪除
③ 輸入一個格式錯誤的資料，看是否有錯誤提示，並且資料庫中沒有資料被刪除。
④ 輸入的正確資料前加空格，看是否能正確刪除資料
⑤ 什麼也不輸入
⑥ 是否指出table鍵
⑦ 是否支援enter鍵
2.14.4查詢
精確查詢：
① 輸入的查詢條件為資料庫中存在的資料，看是否能正確地查出相應得資料
② 輸入正確的查詢條件以前加上空格，看是否能正確地查出相應的資料
③ 輸入格式或範圍不符合要求的資料，看是否有錯誤提示
④ 輸入資料庫中不存在的資料
⑤ 不輸入任何資料
⑥ 是否支援table鍵
⑦ 是否支援enter鍵
2.14.5模糊查詢
在精確查詢的基礎上加上以下一點
① 輸入一些字元，看是否能查出資料庫中所有的相關資訊
2.設計功能測試用例
文字框、按鈕等控制元件測試
2.14.6文字框的查詢
文字框的測試
如何對文字框進行測試
a,輸入正常的字母或數字。
b,輸入已存在的檔案的名稱;
c,輸入超長字元。例如在“名稱”框中輸入超過允許邊界個數的字元，假設最多255個字元，嘗試輸入 256個字元，檢查程式能否正確處理;
d,輸入預設值，空白，空格;
e,若只允許輸入字母，嘗試輸入數字;反之;嘗試輸入字母;
f,利用複製，貼上等操作強制輸入程式不允許的輸入資料;
g,輸入特殊字符集，例如，NUL及\n等;
h,輸入超過文字框長度的字元或文字，檢查所輸入的內容是否正常顯示;
i,輸入不符合格式的資料，檢查程式是否正常校驗，如，程式要求輸入年月日格式為yy/mm/dd，實際輸入yyyy/mm/dd，程式應該給出錯誤提示
在測試過程中所用到的測試方法：
1,輸入非法資料;
2,輸入預設值;
3,輸入特殊字符集;
4,輸入使緩衝區溢位的資料;
5,輸入相同的檔名;
2.14.7命令按鈕控制元件的測試
a,點選按鈕正確響應操作。如，單擊確定，正確執行操作;單擊取消，退出視窗;
b,對非法的輸入或操作給出足夠的提示說明，如，輸入月工作天數為32時，單擊”確定“後系統應提示:天數不能大於31;
c,對可能造成資料無法恢復的操作必須給出確認資訊，給使用者放棄選擇的機會;
單選按鈕控制元件的測試
a,一組單選按鈕不能同時選中，只能選中一個。
b,逐一執行每個單選按鈕的功能。分別選擇了“男”“女”後，儲存到資料庫的資料應該相應的分別為“男”“女”;
c,一組執行同一功能的單選按鈕在初始狀態時必須有一個被預設選中，不能同時為空;
up-down控制元件文字框的測試
a,直接輸入數字或用上下箭頭控制，如，在“數目”中直接輸入10，或者單擊向上的箭頭，使數目變為10;
b,利用上下箭頭控制數字的自動迴圈，如，當最多數字為253時，單擊向上箭頭，數目自動變為1;反之亦適用;
c,直接輸入超邊界值，系統應該提示重新輸入;
d,輸入預設值，空白。如，“插入”數目為預設值，點選“確定”;或，刪除預設值，使內容為空，單擊“確定”進行測試;
e,輸入字元。此時系統應提示輸入有誤。
組合列表框的測試
a,條目內容正確，其詳細條目內容可以根據需求說明確定;
b,逐一執行列表框中每個條目的功能;
c,檢查能否向組合列表框輸入資料;
2.14.8複選框的測試
a,多個複選框可以被同時選中;
b,多個複選框可以被部分選中;
c,多個複選框可以都不被選中;
d,逐一執行每個複選框的功能;
2.14.9列表框控制元件的測試
a,條目內容正確;同組合列表框類似，根據需求說明書確定列表的各項內容正確，沒有丟失或錯誤;
b,列表框的內容較多時要使用滾動條;
c,列表框允許多選時，要分別檢查shift選中條目，按ctrl選中條目和直接用滑鼠選中多項條目的情況;
滾動條控制元件的測試
要注意一下幾點：
a,滾動條的長度根據顯示資訊的長度或寬度及時變換，這樣有利於使用者瞭解顯示資訊的位置和百分比，如，word中瀏覽100頁文件，瀏覽到50頁時，滾動條位置應處於中間;
b,拖動滾動條，檢查螢幕重新整理情況，並檢視是否有亂碼;
c,單擊滾動條;
d,用滾輪控制滾動條;
e,滾動條的上下按鈕。
各種控制元件在窗體中混和使用時的測試
a,控制元件間的相互作用;
b,tab鍵的順序，一般是從上到下，從左到右;
c,熱鍵的使用，逐一測試;
d,enter鍵和esc鍵的使用;
在測試中，應遵循由簡入繁的原則，先進行單個控制元件功能的測試，確保實現無誤後，再進行多個控制元件的的功能組合的測試。
ps:密碼輸入框測試時要特別注意進行字母大寫輸入的測試。
查詢替換操作
案例演示:開啟word中的"替換"對話方塊
測試本功能有通過測試和失敗測試兩種情況
通過測試:
1,輸入內容直接查詢,或查詢全部
2,在組合框中尋找已經查詢過的內容,再次查詢並確認文件的內容正確,如,已經查詢過"測試用例",再次進入不用重新輸入查詢內容,直接在文件中搜尋就可以.
失敗測試:
1,輸入過長或過短的查詢字串.如,假設查詢的字串長度為1到255,那麼輸入0,1,2,256,255和254進行測試;
2,輸入特殊字符集,如,在word中.^g代表圖片,^代表分欄符,可以輸入這類特殊字元測試;
替換測試大體相同.
關於編輯操作視窗的功能測試的用例:
1,關閉查詢替換視窗.不執行任何操作,直接退出;
2,附件和選項測試.假如,設定"精確搜尋","向後"搜尋等附件選項等等來測試;
3,控制元件間的相互作用.如,搜尋內容為空時,按鈕"搜尋全部","搜尋","全部替換","替換"都為灰色.
4,熱鍵, Tab鍵.回車鍵的使用.
插入操作
1)插入檔案
測試的情況
a,插入檔案;
b,插入影象;
c,在文件中插入文件本身;
d,移除插入的原始檔;
e,更換插入的原始檔的內容;
2)連結檔案
測試方法:
a,插入連結檔案;
b,在文件中連結文件本身;
c,移除插入的原始檔;
d,更換插入的原始檔的內容.
3)插入物件
要測試的內容
a,插入程式允許的物件,如,在word中插入excel工作表;
b,修改所插入物件的內容.插入的物件仍能正確顯示;
c,解除安裝生成插入物件的程式,如,在word中插入excel工作表後解除安裝excel,工作表仍正常使用.
編輯操作
編輯操作包括剪下,複製,貼上操作.
測試剪下操作的方法
a,對文字,文字框,圖文框進行剪下;
b,剪下影象
c,文字影象混合剪下
複製操作方法與剪下類似.
測試時,主要是對貼上操作的測試,方法是:
a,貼上剪下的文字,文字框及圖文框;
b,貼上所剪下的影象;
c,剪下後,在不同的程式中貼上
d,多次貼上同一內容,如,剪下後,在程式中連續貼上3次;
e,利用貼上操作強制輸入程式所不允許輸入的資料.
3.介面測試用例的設計方法
1)窗體
測試窗體的方法:
a,窗體大小,大小要合適,控制元件佈局合理;
b,移動窗體.快速或慢速移動窗體,背景及窗體本身重新整理必須正確;
c,縮放窗體,窗體上的控制元件應隨窗體的大小變化而變化;
d,顯示解析度.必須在不同的解析度的情況下測試程式的顯示是否正常;
進行測試時還要注意狀態列是否顯示正確;工具欄的圖示執行操作是否有效,是否與選單懶中圖示顯示一致;錯誤資訊內容是否正確,無錯別字,且明確等等;
2)控制元件
測試方法:
a,窗體或控制元件的字型和大小要一致;
b,注意全形,半形混合
c,無中英文混合.
3)選單
進行測試時要注意
a,選擇選單是否可以正常工作,並與實際執行內容一致;
b,是否有錯別字:
c,快捷鍵是否重複;
d,熱鍵是否重複;
e,快捷鍵與熱鍵操作是否有效
f,是否存在中英文混合
g,選單要與語境相關,如,不同許可權的使用者登陸一個應用程式,不同級別的使用者可以看到不同級別的選單並使用不同級別的功能;
h,滑鼠右鍵快捷選單
4)特殊屬性
1,安裝介面應有公司介紹或產品介紹,有公司的圖示
2,主介面及大多數介面最好有公司圖示
3,選擇"幫助"->"關於"命令,應看見相關版權和產品資訊