[本文出自天外歸雲的博客園] http://www.cnblogs.com/LanTianYou/p/7390567.htmlhtml
測試用例設計模板
本模板不包含專項測試的部份內容（好比流量、耗電量等測試），只針對功能需求自己進行設計。android
1. 資源（圖片）加載邏輯測試，包含弱網加載邏輯、延遲加載邏輯的測試；數據庫
2. 按鈕測試，包含三態（點擊前、點擊時、點擊後）的樣式、跳轉、具體實現效果的測試；網絡
3. UI弱網、網絡異常（斷網+恢復網絡）客戶端處理邏輯（包括請求超時處理邏輯）的測試；app
4. 頁面上的文案、顏色、內容（寫死的）方面的測試；工具
5. 動態數據（接口返回的數據）在頁面上的回顯邏輯檢查（正常狀況、容錯狀況）的測試；post
6. 輸入框類（焦點出現和消失的邏輯、彈出鍵盤遮罩頁面的處理邏輯、容錯數據提交的處理邏輯、數據輸入的動態校驗）的測試；測試
7. 刷新邏輯（包含上拉、下拉等方式的手動刷新和頁面自動刷新邏輯）的測試；spa
8. 請求延遲返回（包括斷網、弱網狀況下的）加載中的頁面loading動效檢查；設計
9. 彈層的出現與消失邏輯；
*10. 具體需求功能邏輯交互流程測試。
以上前九點的測試用例設計方法是固定的，第十點的測試用例設計要QA按需求文檔和交互文檔進行設計，基本就是把文檔中提到的需求交互點都提取出來做爲測試用例便可。
自動化設計思路
既然有模板就有自動化實現的方法，例如：前九點能夠提取出不變的成分名稱，第十點能夠經過制定需求交互文檔的標準模板從而規範化產品人員和交互設計人員的輸入，方便實現測試用例的自動提取與生成。
咱們的輸入能夠肯定爲：
1. 按鈕類UI的名稱列表；
2. 輸入框類UI的名稱列表；
3. 圖片、資源的名稱列表；
4. 涉及網絡請求的UI的名稱列表；
5. 頁面固定視覺走查（樣式、顏色、文案）列表；
6. 接口回顯數據名稱列表；
7. 全部的刷新位置列表；
8. 全部的loading動效出現的觸發條件列表；
9. 按標準模板（需求和交互內容清晰的按點列舉，可以根據文檔經過腳本工具自動提取生成測試用例）書寫的需求文檔、交互文檔。
根據上面概括的思路咱們能夠編寫程序來實現自動化生成軟件測試用例，經過在實際的工做環境下不斷完善上面的模板，將避免一些人爲的、經驗差別形成的在測試用例設計上的疏漏。
咱們能夠從規範以上肯定的輸入方面入手，從標準化的輸入中獲取咱們想要獲得的信息列表並自動化萃取和生成軟件測試用例。
覆蓋安裝測試
另外：每次app發版以前都要對android端進行覆蓋安裝測試。
在已經安裝舊版本包（最近三個版本的線上包）的狀況下，下載並安裝新包進行覆蓋安裝，對基本功能和改動功能進行迴歸測試。
發版以前禁止任何形式的數據庫結構變更。