第21章 软件测试的故障模型

第二十一章软件测试故障模型上一章回顾•业务测试的内容•业务测试验证点课堂提问•业务测试的概念•业务测试需要关注什么•业务测试用例的注意事项本章学习目标•熟练掌握二十一种故障模型本章学习方法•运用内容进度•故障模型•功能性测试的测试方法–用户接口输入测试–用户接口输出测试6/21故障模型•故障模型概念–设计测试用例时有太多的单个输入变量、多个输入变量的组合，优秀的软件测试人员不会依靠运气，他们有着丰富的经验和直觉，可以从中找到哪些是要进行测试的，哪些不需要测试，哪些操作可能会引起软件失效。我们把这些测试人员的经验和直觉尽量归纳和固化，形成一些故障模型（FaultModel）。–为软件测试工程师敏锐发现缺陷提供帮助7/21内容进度•故障模型•功能性测试的测试方法–用户接口输入测试–用户接口输出测试8/21方法1：输入非法数据•案例演示•原理分析–处理非法输入的方法•输入时过滤非法数据，给出错误提示。（非法数据不进入程序内部）•程序内部捕获错误信息，给出提示。•如何发现这类错误–举例：假设“软件测试工程师管理系统”中每个工程师的信息单独使用一个文件进行保存，保存文件名为工程师姓名；即如果工程师姓名为张三，则保存的该工程师信息的文件为“张三.txt”，则在添加工程师测试时要注意工程师姓名输入的隐含问题。•输入非法类型：文件名中不能包括的9个非法字符，系统保留字等；•输入超长字符：255个字符；•注意–检查错误信息，保证正确、易懂！–举例：错误信息：Error5-unkowndata！9/21方法1：输入非法数据10/21实战演练方法2：输入默认值•案例演示–环境：Word2000（可以在虚拟机中安装重现缺陷）•此类缺陷产生原因–定义变量时未赋初值–赋初值不正确–再次赋初值后对程序其他部分的影响•如何发现这类错误?•测试方法小结–全面理解需求规格说明书中，对默认值的要求–同时深刻理解被测软件的行业背景•实战演练11/21方法3：输入特殊字符集12/21案例演示环境：Win2000、IE5此类缺陷产生原因特殊字符处理问题，没有对特殊字符输入做程序处理注意系统保留字符串注意应用程序处理特殊字符C语言中的“\n”、“++”、“&”等如何发现这类错误?测试方法小结实战演练方法4：输入使缓冲区溢出的数据•案例演示–环境：Win2000、Word2000•此类缺陷产生原因–输入的数据未经检查，超过该值固定大小内存缓冲区，影响其他内存单元，严重的引起程序关闭。•如何发现这类错误–获得需求（包括详细设计说明），输入最大字符串和超过最大字符串要求的输入数据•测试方法小结–加强和开发人员沟通，了解没有写到需求或设计文档中的变量范围•实战演练13/21方法5：输入产生错误的合法数据组合14/21案例演示在Word中插入表格，需求规格说明书中规定：列容许的最大值为63，行容许的最大值为32767输入：列=55，行=32005，结果？此类缺陷产生原因测试多个输入值的组合，每个合法输入值单独测试通过不代表合法输入值的组合测试也能通过。不过此例应用程序只是挂起，等待一段时间后，Word还是可以产生所需要的表格，所以此例是否确定为缺陷可以和需求或开发人员沟通，建议的做法是界面给出产生产生表格进度条。如何发现这类错误?测试方法小结尽可能多的了解程序内部数据结构，多与开发人员沟通。实战演练用户接口输入测试小结•输入非法数据•输入默认值•输入特殊字符集•输入使缓冲区溢出的数据•输入产生错误的合法数据组合15/21内容进度•故障模型•功能性测试的测试方法–用户接口输入测试–用户接口输出测试16/21方法6：同一个输入产生各种可能输出17/21案例分析输入：一个电话打来输出：状态一：如果此电话正在使用，则打来电话的人听到的声音应该是占线的提示音。状态二：如果此时电话未使用，则打来电话的人听到的声音应该是等待接听的提示音。缺陷产生原因开发人员可能没有判断当前所处状态，就想当然的给出了输出。如何发现这类错误熟悉被测软件业务知识，阅读各种程序文档，明确输入可能产生的输出。方法7：产生不符合业务规则的无效输出18/21案例演示缺陷产生原因程序开发人员对业务了解不深刻如何发现这类错误?用户接口输出测试小结•产生同一输入的各种可能输出•强制产生不符合业务规则的无效输出19/21内容进度•用户接口输出测试•数据结构的测试20/21方法8：输出属性修改后的结果•案例演示–输出具有可修改的属性–本案例是否为缺陷可以根据需求做进一步判断•缺陷产生的原因–开发人员在创建对象时设立了初始值，但当用户修改输出对象属性，开发人员编写的对应代码没有考虑这些属性值的修改对其他变量的影响。•如何发现这类错误及测试方法小结?21/21方法9：检查屏幕刷新•案例演示•缺陷产生的原因–刷新频率快了，程序运行变慢；刷新频率慢了，则会出现案例演示出现的现象。–刷新范围控制•如何发现这类错误?•测试方法小结–注意增加、删除和移动屏幕上的对象能发现类似的缺陷22/21用户接口输出测试小结•产生同一输入的各种可能输出•强制产生不符合业务规则的无效输出•强制通过输出修改属性•检查屏幕刷新23/21内容进度•用户接口输出测试•数据结构的测试24/21方法10：数据结构溢出•案例演示•缺陷产生的原因–数据结构限制–内存限制–硬盘限制•如何发现这类错误–上溢–下溢•测试方法小结–数组25/21方法11：数据结构不符合约束•案例演示•缺陷产生的原因–在建立数据项时对数据属性的约束进行了检查，而修改数据项的代码未做约束性检查。•如何发现这类错误–修改属性判断是否进行约束判断•测试方法小结–了解内部数据结构约束，尝试破坏这些约束进行测试。26/21方法12：操作数和操作符不符•案例演示–是否是缺陷？–如果是缺陷，开发人员修改成什么样的结果你作为测试人员会确认这个缺陷已经被修复。•如何发现这类错误–找到程序中容易引起操作数和操作符不符的计算、表达式等。•实战演练27/21方法13：函数递归调用•案例演示–Excel案例演示•缺陷产生的原因–函数递归调用，没有合理的退出条件，可能会导致系统死机。•如何发现这类错误–注意函数中的递归调用，注意合理的退出条件。•注意–教材中的例子需要的环境•Win2000，Word200028/21方法14：计算结果溢出•案例分析–如果value[0]=32700，value[1]=70，则？•缺陷产生的原因–32700+70=32770，32770大于int型（这里指用两个字节存储的int型）的最大存储值32767，所以溢出。•如何发现这类错误–输入非法值，强制数据产生溢出，观察程序的处理情况。29/21方法15：数据共享或关联功能出错•案例演示•缺陷产生的原因–当多个功能共享数据时，一个功能改变了数据值可能会对其他功能项产生不可预知的影响。•如何发现这类错误和测试方法小结30/21数据结构的测试小结•数据结构溢出•数据结构不符合约束•操作数与操作符不符•递归调用自身•计算结果溢出•数据共享或关联功能计算出错31/21本章学习目标•文件系统的测试•软件的故障模型32/17内容进度•文件系统的测试•软件的故障模型33/17方法16：使文件系统超载•案例–假设“软件测试工程师管理系统”要保存10000个工程师信息，则保存时engineer.txt文件会有20M大小，如果此时磁盘只有10M可用空间了，“软件测试工程师管理系统”会如何动作呢？•此类缺陷产生的原因–开发人员忽略了CreateFile、WriteFile等与操作系统交互的API错误代码检查。•如何发现这类问题?–使用工具CannedHeat，模拟文件系统负载。34/17方法17：使介质忙或不可用•案例演示•此类缺陷产生的原因–开发人员没有考虑介质忙或者不可用的情况，未对此种情况做出处理。•如何发现这类问题–使用工具CannedHeat，模拟介质忙或不可用的情况。35/17方法18：介质损坏•案例分析•缺陷产生的原因–损坏的介质可能会是操作系统传回错误代码，这些错误代码没有在应用程序中编程处理。–操作系统不能检测出所有的这些错误。•如何发现这类问题–一般软件，不必考虑介质损坏问题。一般用在操作系统、设备驱动程序/控制器以及以安全为主的应用程序才会考虑此类测试。–例如测试实现RAID5技术的软件，则需要模拟一块硬盘坏了之后，换一个硬盘，数据是否可以恢复。36/17方法19：使用不合法的文件名•案例演示–环境：Win2000，Word2000•此类缺陷产生的原因–Dos采用8.3格式存文件名，Windows文件名不超过255个字符，且有9个字符不能被使用，保留字不能被使用。–注意文件名中“.”应用程序是如何处理的。•如何发现这类问题–使用不合法的文件名测试，例如：test;filename-5.1.2004、abc\d.doc•测试方法小结–熟记文件名命名规则37/17方法20：更改文件访问权限•案例演示•此类缺陷产生的原因–特别需要注意：不同的用户对相同文件具有不同的访问权限，需要考虑登录同一台机器的多个用户操作相同文件的权限问题。•如何发现这类问题?38/17方法21：文件内容受损•案例演示•缺陷产生的原因–开发人员没有验证文件的格式和内容，对验证不通过的文件没有做出正确处理。•如何发现这类问题–手工损坏文件测试–使用工具，模拟CRC（循环冗余校验）错误39/17文件系统的测试小结•使文件系统超载•使介质忙或不可用•介质损坏•使用不合法的文件名•更改文件访问权限•文件内容受损40/17总结•二十种故障模型的来源•理解二十一种故障模型•请预习第二十一章