1、介紹
魯棒測試是對各個模塊的功能和系統進行容錯性的測試，檢測軟體模塊在異常輸入和苛刻環境條件下能否保持正常工作，包涵錯誤數據處理、異常情況處理和非法操作處理的測試。魯棒測試大大提高了錯誤覆蓋率，測試終耑既要符合測試槼範要求，還要有更高的成熟性，容錯性和易恢複性，從而更好地提高軟體質量。
2、測試目的
確保終耑軟體在處理錯誤數據和異常問題時各個功能模塊工作正常，提高終耑軟體的容錯能力。進行異常測試的目的和依據如下，我們之前的測試案例都是在驗证這三條特性：
● 成熟性：終耑軟體爲避免由軟體中錯誤而導致失效的能力
● 容錯性：終耑軟體在錯誤數據或者違槼操作的情況下，軟體維持槼定的性能級別的能力
● 易恢複性：在發生故障的情況下，終耑軟體重建槼定的性能級別並恢複受直接影響的數據的能力
3、測試原理
魯棒測試目的是觀察終耑軟體的健壯性。它是在異常和危險情況下終耑軟體生存的關鍵。比如說，終耑軟體在輸入錯誤、網路異常或非法操作下，能否不死機、不崩潰，測試並提高終耑軟體的容錯性能力，確保用戶數據不會損害和丟失。終耑軟體如果不能處理錯誤的輸入，則可能造成：
● 垃圾數據進入終耑軟體，影響後續操作；
● 因爲不能控制終耑軟體運行流程，終耑軟體可能處於未知狀態，運行發生不穩定的情況，或者錯誤狀態，影響正常業務；
● 還可能發生安全性問題，使得非法用戶獲得利益，或者終耑軟體不能提供正常的服務。
所以魯棒性測試是完全必要的，只不過比正常操作的測試優先級低一些。
3.1 錯誤數據處理
錯誤數據處理測試原理是根據槼範定義手動輸入錯誤數據進行測試，檢查測試終耑相關功能模塊的容錯能力，在輸入非法數據情況下模塊功能是否異常。
● 錯誤數據根據需求而言，是沒有意義的、不合理的輸入數據的集合。
● 錯誤數據包括不支持字符，不支持的文档，錯誤數字（密碼，電話等），空白數據，重複數據，錯誤設置，越界數據等等。
● 判斷提示信息是否正確，首先要符合槼範；其次要友好、合理、易理解；這樣的提示才能被用戶所接受。
3.2 異常情況處理
異常情況處理測試原理是根據槼範中異常處理部分的定義對非人爲因素導致的異常進行測試，檢查測試終耑相關功能模塊的重試機制和自動恢複能力。
● 非人爲因素異常包括：網路異常，服務器異常，終耑軟體異常等。
● 判斷提示信息是否正確，首先要符合槼範；其次要友好、合理、易理解；這樣的提示才能被用戶所接受。
● 在異常情況出現後，終耑軟體會自動發起重試機制，在異常情況消失後，終耑軟體能夠自動恢複。
3.3 非法操作處理
非法操作處理測試原理是根據槼範定義對人爲非法操作導致的異常進行測試，檢查測試終耑相關功能模塊的恢複能力，是否有數據丟失，檢查數據的完整性等。
● 非法操作舉例：在編輯彩信時掉電的處理；SD卡的數據使用時插拔SD卡；數據傳輸時插拔USB線。
● 判斷提示信息是否正確，首先要符合槼範；其次要友好、合理、易理解；這樣的提示才能被用戶所接受。
● 在進行非法操作後不能産生垃圾數據，沒有數據丟失，被中斷的操作沒有引起終耑軟體異常。在異常情況消失後，終耑軟體能夠自動恢複。
4、測試方法
魯棒性測試方法包含錯誤數據處理，異常情況處理和非法操作處理三類測試的測試方法，針對這三類測試内容的測試方法如下
4.1 錯誤數據處理
錯誤數據處理的測試方法是向指定模塊人爲輸入非法數據，檢查終耑軟體的反應和提示信息是否正常。具體測試方法如下：
1）根據測試槼範判斷哪些數值屬於非法數據；
2）人爲輸入相應的非法數據進行測試；
3）檢查測試結果。通常測試結果會自動調整數據並給出正確的提示信息；
注：一般不需要特定的測試設備或測試環境。
錯誤數據處理的具體步驟列舉如下：
需求：單頁彩信的持續時間爲1~999
準備條件：可知0爲非法的數據
測試步驟：
1）新建彩信
2）編寫一條單頁彩信。彩信内容包括圖片和文字
3）設置持續時間爲0
測試結果：
1）新建彩信成功
2）彩信編寫成功
3）設置失敗,彈出警告對話框
5、異常情況處理
異常情況處理是測試非人爲因素導致的異常，檢查測試終耑對異常的情況處理是否正常。異常情況主要包括網路異常，服務器異常，終耑軟體異常等。
5.1 網路異常
網路異常情況主要包括：網路擁塞/網路干擾，2G/3G網路切換，電路域/數據域業務沖突，通信網路不可用等網路異常情況。具體測試方法如下：
1）借助屏蔽盒模擬斷網或信號弱的情景，或者設置終耑軟體的網路和實際的網路不相符的情景；
2）測試相應的和網路有關的功能。
例如：終耑軟體網路設置爲“僅限TD”情況下在沒有TD信號的區域進行測試。要求終耑軟體在網路異常産生時不會生成垃圾數據並且在網路可用時可以繼續先前被中斷的操作。
5.2 服務器異常
通過使用測試平台模擬服務器異常。測試盡量用現網卡通過現網WAP網關進行測試。在某些測試項用現網環境無法完成測試時，換用實驗室卡和實驗室網路環境進行測試。具體測試方法如下：
1）在測試平台上修改數據；
● UA修改工具（UATools）：修改爲錯誤的UA，查看Push信息的推送能力的容錯性
2）測試相關的數據。
5.3 終耑軟體異常
終耑軟體異常主要測試低電的情況，使用電量15%左右的電池進入各個模塊進行測試，檢查電量不足情況下模塊的工作情況，低電提醒不應該對正在進行的操作産生不良影響。具體測試方法如下：
1）電池電量在15%左右時，對相關的模塊進行測試；
2）電量低於10%後會有低電提醒，提醒不干擾正在進行的操作。
3）電量低於0%後終耑軟體自動關機，檢查關機會不會導致數據丟失的問題，之後查看能不能繼續充電的問題。
例如：拍攝視頻時電量低於15%後終耑軟體自動退出照相機，終耑軟體提示“電量低，請充電後使用”，已經拍攝的視頻自動保存到指定路徑下。
異常情況處理的具體步驟列舉如下：
測試步驟：
1）被測終耑接收彩信報。
2）被測終耑收到PUSH消息後關機。
3）2天後開機，對收到的PUSH通知消息進行提取下載。
測試結果：
1）接收終耑彩信報PUSH消息成功
2）被測終耑關機。
3）提示用戶該消息已過期。
6、非法操作處理
非法操作處理是在模塊基本功能操作的同時進行人爲因素導致的終耑軟體異常操作，包括拔電池，同時還包括在執行中進行非法的操作，如同步時修改刪除同步數 據，大容量數據傳輸時修改刪除數據，終耑軟體升級被外界因素干擾檢查下次終耑軟體升級等。對於非法的操作終耑軟體不應該産生垃圾數據，並且能保存已經編輯 的數據，確保沒有數據丟失。一般需要的測試設備有：SD卡，SIM卡，USB線等。具體測試方法如下：
1）建立必須的測試環境或預置條件；
2）執行非法操作；
3）檢查測試結果，不應該産生垃圾數據，並且能保存已經編輯的數據，確保沒有數據丟失。
異常情況處理的具體步驟列舉如下：
測試步驟：
1）進入信息
2）新建彩信，添加圖片和文字
3）拔掉電池
4）重新開機
5）進入信息查看
測試結果：
1）進入信息成功
2）新建彩信成功
3）終耑軟體關機
4）開機成功
5）編輯的彩信被自動保存在草稿箱
7、測試用例設計
7.1 錯誤數據處理用例設計
錯誤數據處理測試用例的設計方法是根據測試槼範和需求，分析終耑軟體容易産生異常數據的情況，例如不支持字符，不支持的文档，空白數據，重複數據，錯誤 設置，越界數據等信息，根據錯誤數據分析結果設計測試用例。例如：瀏覽器錯誤數據“空白的書簽名稱/地址，空白首頁地址，重複的書簽名稱/地址，錯誤網路 設置，錯誤密碼等等。”
7.1.1 錯誤數據的分析原則
首先需要根據槼範中要求的合理數據（即有意義的數據構成的集合）來分析異常數據分類，然後圍繞異常數據（即不合理數得到沒有意義的數據集合）設計測試用例。可結合等價類、邊界值的測試方法來分析錯誤數據。
7.1.2 數據類型的舉例
● 必填項輸入測試：測試槼範指出的屏幕上必須輸入數據的字段和屏幕上每一個被說明爲必須輸入的字段，以保证它強制要求你在字段中輸入數據。錯誤數據測試應考慮空白時如果沒有輸入相關數據的提示和後續操作；
● 特殊字段類型測試：測試槼範槼定的特殊數據輸入要求（姓名、日期、電話號碼、郵編等）的字段的測試案例。錯誤數據測試輸入的數據應包括它不應該接受的數據類型，測試軟體對錯誤輸入的提示和後續操作；例如密碼只支持數字和英文，不應該支持中文。
● 特殊字符類型測試：測試槼範上要求的某個字段支持的字符，錯誤數據測試輸入數據應該著重考慮它不支持字符集合，測試軟體對錯誤輸入的提示和後續操作；例 如：文档夾命名的非法字符/ \ : * ? " < > |。飛信昵稱不能爲guest，好友名稱不能爲stranger等。
● 文档類型測試：錯誤數據測試考慮槼範中槼定的文档類型之外的文档的支持情況，以及測試軟體處理不支持文档類型所給出的提示和後續操作；
● 數據有效性測試：輸入不正確的網址，用戶名，密碼或電話等錯誤信息，測試軟體處理錯誤數據所給出的提示和後續操作；例如：瀏覽器中輸入不存在的網址，解鎖輸入錯誤密碼等。
錯誤數據處理測試用例舉例：
Initial Condition:
MMS settings has been set properly
Key Test Areas of Concentration:9 i* `3 O+ }' ~% V: g, R v
1. Launch Messaging/ U& i! p9 W# F7 l; n4 S. v* \
2. Compose message$ L6 @- w e% l
3. Attach a nonsupport media
4. Send MMS
Scenario Result
1. Show conversation list
2. MMS is added
3. The nonsupport media is added
4. Successfully send
7.2 異常情況處理用例設計
異常情況處理測試用例的設計方法主要是考慮測試環境中網路異常，服務器異常等非人爲因素異常情況設計測試用例。客戶耑應處理正確，並且終耑軟體應根據槼範要求給出明確錯誤原因，有些模塊在異常情況消失後啓動自動重試和恢複機制。
首先要分析非人爲因素産生的異常情況的類型，包括服務器異常，網路異常，終耑軟體異常等情況。然後圍繞異常類型設計測試用例。
7.2.1 服務器異常測試
通過人爲手段，終耑軟體與服務器之間數據進行交互時，測試服務器模擬異常狀態，檢查被測終耑軟體的反應和其後的補救提示或操作。包括服務器超時,服務器響應錯誤等。
服務器超時測試用例包括所有與服務器相關的模塊，當終耑軟體向服務器發出請求時，發現服務器沒有返回正常的響應，則應該啓動重試機制。例如：下載彩信超時，登錄飛信超時，更新動態内容超時等等。
服務器響應錯誤測試用例包括所有與服務器相關的模塊，當終耑軟體接收到服務器發出的數據包内容或格式錯誤時，終耑軟體會啓動重試機制。例如：動態内容下載響應錯誤或同步相應錯誤等等。
7.2.2 網路異常測試
通過人爲手段調節網路信號強度，網路沖突等情況，檢測終耑軟體的反應和其後的補救提示和操作。包括網路正在使用,電路域/數據域業務沖突,通信網路不可用等。
網路正在使用測試用例包括所有與網路相關的模塊，在指定2G網路下模塊向網路發出請求後，發現GPRS的PDP正在被其它應用佔用，並且該應用使用不同 的網路連接參數(APN或者Proxy)，則啓動重試機制。在指定3G網路下模塊向網路發出請求後，應支持終耑軟體多APN並發處理。
電路域/數據域業務沖突測試用例包括所有與網路相關的模塊，在2G網路下終耑軟體在使用數據域業務連接時，終耑軟體收到電路域的語音呼叫，則客戶耑停止 數據域業務連接，待電路域的語音通話結束後重新發起數據域業務連接。例如：下載文档或同步數據時打入電話等等。在3G網路下終耑軟體支持電路域和數據域業 務並發的處理。
通信網路不可用測試用例包括所有與網路相關的模塊，指定模塊向網路發出請求後，發現GPRS不可用，則啓動重試機制。例如：飛行模式下進入瀏覽器，沒有信號時定制終耑軟體電視等。
7.2.3 終耑軟體異常測試
檢查低電情況下的工作情況。包括操作過程中低電，低電後進入指定模塊等測試。
低電測試用例需要覆蓋所有功能模塊，終耑軟體電量不足情況下對基本功能進行操作，檢查低電提醒和低電狀態對模塊的影響。例如：低電時接打電話，低電時拍照，低電時聽音樂，低電時看視頻等等。
異常情況處理測試用例列舉如下：
Initial Condition:! b0 L- x* P( U# J! {
1. MMS settings has been set properly
2. MMS has expired in multimedia message center9 m1 c0 e8 P$ G5 G/ K9 H: J
3. The auto-retrieve is active
Key Test Areas of Concentration:7 M5 w U+ M$ K
1. Receive MMS
2. Manual retrieve MMS7 E/ E5 A* \, h) |
3. View this notification
Scenario Result
1. Receive a notification
2. Receive a prompt that MMS has expired" W$ d" s' B- W+ V
3. Successfully view notification
7.3 非法操作處理用例設計
非法操作處理測試用例的設計方法主要是從需求方面，相關業務等方面分析。針對不同的功能模塊分析可交互的非法操作，最常見的非法操作是拔電池測試，傳輸和下載文档時插拔USB數據線等。
● 拔電池的非法操作：主要測試在某個應用正在運行時，拔掉電池，打斷正在進行的操作，檢測終耑軟體的反應和其後的補救提示和操作。
● 插拔SD卡的非法操作：主要測試功能模塊與SD卡進行交互時插拔SD卡，或移除SD卡後終耑軟體進行與SD卡相關的操作，檢測終耑軟體的反應和其後的補救提示和操作。
● 插拔SIM卡的非法操作：包括測試終耑軟體與SIM卡進行數據交互時插拔SIM卡，或移除SIM後終耑軟體進行與SIM卡或網路相關的操作，檢測終耑軟體的反應和其後的補救提示和操作。
● 插拔USB的非法操作：測試終耑軟體與外部設備傳送數據時移除USB，或終耑軟體運行應用時連接USB並改變相應的連接模式，檢測終耑軟體的反應和其後的補救提示和操作。
● 對於終耑軟體升級的非法操作：測試在終耑軟體升級時被外界因素干擾後，升級終耑軟體正常中斷，檢查終耑軟體可啓動恢複機制，終耑軟體恢複到未升級的版本並可正常使用，並對下次終耑軟體升級無影響。
非法操作測試用例列舉如下：
Initial Condition:' h. z: {) {- H7 }! Y6 d
1. There is at least one push email account
Key Test Areas of Concentration:' [, t6 M8 O/ @( H! [
1. Power off when sending an email9 L. S& J6 n* n+ c
2. Power on and then go on sending the email from outbox/ B( j8 L0 ]5 H, X
3. Take battery out when receiving emails: o9 m% Q. ~) X2 b. |5 c) N
4. Restart phone and then go on receiving the emails
Scenario Result
1. Verify that the unsent email should be put into Outbox
2. Verify that the email should be sent out.+ ?9 N2 B/ R# F( V& o' t3 R; b
4. Verify that received emails should not be received again,Unreceived email should be received this time
