1、常規測試主要包含以下方面：
（1）UI測試
用戶界面測試，英文是User interface testing。又稱UI測試
用戶界面測試是指測試用戶界面的風格是否滿足客戶要求，文字是否正確，頁面是否美觀，文字，圖片組合是否完美，操作是否友好等等（可參考人機交互）
目標： 確保用戶界面會通過測試對象的功能來為用戶提供相應的訪問或瀏覽 功能。 確保用戶界面符合公司或行業的標准。包括用戶友好性、人性化、易 操作性等測試
（2）業務測試
主要是針對需求文檔進行測試----這部分最后確定方為需求人員（因公司需求經常具有不確定性，允許存在部分與需求不一樣的地方，最后由需求人員確定。）
此處建議:需求文檔確定之前，建議增加多方會審過程，可以去除掉大部分不合理的請求，將一些需求合理化，也能夠更好的優化需求流程。
（3）兼容性測試
兼容測試是測試軟件在一個特定的硬件/軟件/操作系統/網絡等環境下的性能如何。向上兼容向下兼容，軟件兼容硬件兼容。軟件的兼容性有很多需要考慮的地方。
因本項目是針對微信平台的web功能頁面 此處需要驗證的兼容性，主要在與android和ios兩個不同平台進行驗證測試；以及不同屏幕大小進行相應的驗證（一般邏輯來說，需要做到最低兼容以及最高兼容）
如：ios系統系統驗證ios7~9系統，屏幕大小包含3.5寸~5.5寸 Android系統，系統要求驗證android 4.0（含）以上，屏幕大小包含4寸及以上
2、用例設計方法
（1）邊界值分析法
邊界值分析：對輸入或輸出的邊界值進行測試的一種黑盒測試方法
實例： 本程序退款確認80字吐槽內容 （1）有效值為1~80個字 （2）邊界值數字為：80字，1字 （2）輸入0字 （3）超過81字 （此處可能存在問題:開發有可能寫成80字符（40漢字），也有可能沒做限制
（2）等價划分法
主要針對輸入區域等價划分為若干部分（子集），從每個部分選取少數代表性數據作為用例 （1）有效等價類（有效合理的輸入） （2）無效等價類（與上對立）
舉例：因發現好股不存在此類用例，取其他用例
用例ID 月份 日期 年 預期輸出
SR1 -1 15 1912 月份不在1～12中
SR2 6 -1 1912 日期不在1～31中
SR3 6 15 1811 年份不在1812～2012中
SR4 -1 -1 1912 兩個無效一個有效
SR5 6 -1 1811 兩個無效一個有效
SR6 -1 15 1811 兩個無效一個有效
SR7 -1 -1 1811 三個無效
（3）判定表
判定表是分析和表達多邏輯條件下執行不同操作的情況的工具
（4）錯誤判斷法
列舉出程序中所有可能有的錯誤和容易發生錯誤的特殊情況,根據他們選擇測試用例。
實例：測試手機端的通話功能
1) 無SIM 卡插入時進行呼出（非緊急呼叫）
2) 插入已欠費SIM卡進行呼出
3) 射頻器件損壞或無信號區域插入有效SIM卡呼出
4) 網絡正常，插入有效SIM卡，呼出無效號碼（如1、888、333333、不輸入任何號碼等）
5) 網絡正常，插入有效SIM卡，使用“快速撥號”功能呼出設置無效號碼的數字
（5）因果圖法
利用圖解法分析輸入的各種組合情況，從而設計測試用例的方法，它適合於檢查程序輸入條件的各種組合情況
E約束（異）：a和b中至多有一個可能為1，即a和b不能同時為1。
I約束（或）：a、b和c中至少有一個必須是1，即 a、b 和c不能同時為0。
O約束（唯一）；a和b必須有一個，且僅有1個為1。
R約束（要求）：a是1時，b必須是1，即不可能a是1時b是0。
（6）場景法
3、測試用例設計綜合策略
1) 在任何情況下都必須使用邊界值分析方法，經驗表明用這種方法設計出測試用例發現程序錯誤的能力最強。
2) 必要時用等價類划分方法補充一些測試用例。
3) 用錯誤推測法再追加一些測試用例。
4) 對照程序邏輯，檢查已設計出的測試用例的邏輯覆蓋程度，如果沒有達到要求的覆蓋標准，應當再補充足夠的測試用例。
5) 如果程序的功能說明中含有輸入條件的組合情況，則一開始就可選用因果圖法。
4、測試用例設計步驟
1) 構造根據設計規格得出的基本功能測試用例；
2) 邊界值測試用例；
3) 狀態轉換測試用例；
4) 錯誤猜測測試用例；
5) 異常測試用例；
6) 性能測試用例；
7) 壓力測試用例。