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
