1、軟體測試的系統流程

軟體工程模型基本就是業務建模-〉系統分析-〉概要設計-〉詳細設計-〉編碼-〉測試-〉部署。其中測試過程按4個步驟進行，即單元測試、整合測試、系統及發版測試和迴歸測試。

 (1)、單元測試，集中對每一個程式單元進行測試，檢查各個程式模組是否正確地實現了預定的功能，屬於白盒測試，測試範圍為單元內部的原始碼和程式結構(如資料結構，邏輯控制，異常處理等)。

 (2)、整合測試把已測試過的模組組裝起來，檢查模組間介面是否正確，檢查各個模組之間的通訊和相互呼叫是否符合需求。屬於灰盒測試，測試範圍為模組介面之間的資料傳遞，以及模組組合後的功能。

(3)、系統測試把被測軟體系統和計算機硬體、資料庫、外設、前端和後端以及其它軟體結合在一起，在實際執行環境下對軟體系統進行一系列的組裝測試和執行測試。目的在於檢測軟體對《需求規格說明書》的符合程度。屬於黑盒測試，只關心輸入和輸出結果，測試範圍為整個系統。

       (4)、迴歸測試：是軟體上線後的維護階段或者是研發修復Bug之後進行確認測試。目的在於驗證缺陷已經得到修復，並檢測是否引入新的缺陷。

2、測試用例及編寫方法

測試用例是一份描述具體測試步驟的文件，包括測試的輸入引數、條件及配置、預期的輸出結果等，用以判斷被測軟體的工作是否正常。

2.1、測試用例設計的三大原則

(1)、設計測試用例要力求最大的覆蓋率，參考《需求規格說明書》對每個功能點進行操作上的細化，儘可能趨向最大需求覆蓋率。

(2)、用例要對測試功能點、測試條件、測試步驟、輸入值和預期結果準確描述。

(3)、在設計測試用例的時候，除了滿足系統基本功能需求外，還應該考慮各種異常情況、邊界情況和承受壓力的能力等。

2.2、設計測試用例設計方法

設計測試用例時要根據具體的產品和需求所明書，比如NetSign C介面普遍得就是根據輸入和輸出引數的不同情況設計用例，但也有通用的情況。

(1)、等價類劃分。把程式的輸入域劃分成若干部分子集，然後從每個部分中選取少數代表性資料作為測試用例。每一類的代表性資料在測試中的作用等價於這一類中的其他值，比如傳輸IP地址時，可以分為A類地址、B類地址和C類地址。既能減少用例總數，又能提高測試覆蓋率。

(2)、邊界值分析法。通常邊界值分析法是作為對等價類劃分法的補充，其測試條件來自等價類的邊界。因為 很多錯誤是發生在輸入或輸出範圍的邊界上，而不是發生在輸入/輸出範圍的中間區域。因此針對各種邊界情況設計測試用例，可以查出更多的錯誤。

(3)、錯誤推斷法。基於測試人員的經驗和直覺推測程式中所有可能存在的各種錯誤, 從而有針對性的設計測試用例。比如字串和普通的字元陣列結尾’\0’的區別，記憶體拷貝函式stycpy和memecpy必須要進行+1或-1的操作。

3、APP測試中經常出現的基礎案例

3.1、APP的安裝、解除安裝測試

（1）、軟體在不同作業系統及版本（Android的EMUI\Flyme\MIUI、iOS、WindowsPhone）下安裝是否正常

（2）、軟體安裝後的是否能夠正常執行，安裝後的資料夾及檔案是否寫到了指定的目錄裡，安裝後沒有生成多餘的目錄結構和檔案

（3）、軟體安裝過程是否可以取消

（4）、軟體安裝過程中意外情況的處理是否符合需求（如宕機，重啟，斷電）

（5）、安裝空間不足時是否有相應提示

（6）、對於需要通過網路驗證之類的安裝，在斷網情況下嘗試一下

（7）、重複安裝應該有提示，

（8）、升級安裝時，版本更新連結有效，比如後臺設定的版本白名單

（a）、使用各種方式解除安裝程式，如直接刪除安裝資料夾解除安裝是否有提示資訊、長按圖示解除安裝、手機設定裡解除安裝、第三方應用解除安裝

（b）、測試解除安裝後文件是否全部刪除所有的安裝資料夾

（c）、解除安裝過程中出現的意外情況的測試（如宕機、斷電、重啟）

（d）、解除安裝是否支援取消功能，單擊取消後軟體解除安裝的情況

3.2、APP的註冊、登入和修改密碼測試

3.3、核對rp原型圖和效果圖，進行UI測試

（1）、觀察APP的使用者介面(如選單、對話方塊、視窗和其它可規控制元件)是否符合UI稿

（2）、不同的連線頁面之間導航連結是否有效，是否跳轉是否正確。

（3）、旋轉手機，確保程式不退出，頁面排版無異常。

（5）、輸入框說明文字的內容與產品需求一致

（6）、某頁無資料時、斷網時、有網但介面異常時的狀態頁是否和UI一致

3.4、核對需求文件，進行功能測試

功能測試的用例要根據具體產品設計，這裡只提供通用點。APP端測試最關心的是流程和資料，避免Crash和ANR問題。

（1）、App安裝完成後是否能正常啟動，且開啟速度控制在預期時間內。

（2）、切換後臺再切換前臺的操作對當前狀態如登陸、當前頁、資料重新整理的影響

（3）、強制殺掉APP程序再啟動對當前狀態如登陸、當前頁、資料重新整理的影響

（4）、登陸驗證/免密登陸時的手勢密碼和指紋是否符合產品需求

（5）、對於有資料交換的頁面，每個頁面都必需要進行前後臺切換、鎖屏解鎖的測試，這種頁面最容易出現崩潰。

（6）、同一使用者在多個終端先後登陸時，APP是否有符合產品需求的處理

（7）、App使用過程中有電話進來的中斷測試，與檔案下載、音樂播放、等應用的交叉情況測試。

（8）、很多應用會支援快取資料，測試在斷網啟動或從有網到無網時是否可以瀏覽快取資料

3.5、安全性測試

a、軟體許可權 

          扣費風險：包括簡訊、撥打電話、連線網路等。 

          限制/允許使用手機拍照或錄音

          限制/允許使用手機讀取使用者資料，手機資訊、聯絡人資訊等

          限制/允許使用手機寫入使用者資料 

         沒有使用者的允許, 應用程式不能預先設定自動啟動。

          對App的輸入有效性校驗、認證、授權、資料加密等方面進行檢測 

         沒有使用者的允許, 應用程式不能預先設定自動啟動

         手機能控制該APP能否使用Wi-Fi和移動資料

b、資料安全性 

         如果資料庫中重要的資料正要被重寫，應及時告知使用者。 

         在資料刪除之前，應用程式應當通知使用者或者應用程式提供一個“取消”命令的操作。 

         對密碼長度和複雜度的要求，

         當將密碼或其他的敏感資料輸人到應用程式時, 其不會被儲存在裝置中, 同時密碼也不會被解碼。

         當應用程式處理信用卡明細或其它的敏感資料時，不以明文形式將資料寫到其他單獨的檔案或者臨時檔案中

3.6、效能壓力測試

（1）、APP端效能測試：在各種邊界壓力情況下，如電池、儲存、網速等，驗證App是否能正確響應

（2）、Server端效能測試：通過測試介面的執行效率，如http介面

3.7、相容性測試

（1）、與本機已經安裝的App是否相容

（2）、在各種系統、系統版本的不同手機上測試註冊、登陸、修改密碼等功能

  （3）、UI層的相容，介面的顯示根據不同尺寸手機是否自適應

（4）、在各種系統、系統版本的不同手機上進行全方面的功能測試，如使用每一個iOS版本的iPhone上測試“我的銀行卡”模組的提現功能。

（5）、基於開發環境和生產環境的不同，檢驗在各種網路連線下(WiFi、2G/3G/4G等)，App的資料和運用是否正確