测试用例问题引入.ppt

9.1.1 软件测试的必要性 9.1.2 软件测试目的 9.1.3 软件缺陷定义 9.1.4 测试用例 9.1.5 软件测试的原则 9.1.1 软件测试的必要性 1. 问题引入 根据统计表明，软件测试的工作量往往占软件开发总工作量的40%以上，可能我们会思考这样一个问题，花费那么多资源在测试上，花费在一个对整个软件工程“没有任何建设成果”的活动上，值得吗？ 2. 解答问题 事实上，答案是肯定的。软件缺陷和故障问题在某些情况下会造成相当严重的损失和灾难，花费大量的资源在测试上，目的是为了提高软件质量，尽可能地减少软件缺陷造成的损失。 3. 分析问题 让我们先来了解几个“著名”的计算机工程事故吧，借此说明软件缺陷和故障问题有时会造成相当严重的损失和灾难。 (1) 2007年5月18日，国内大量用户的电脑集体出现问题：开机后自动重启、蓝屏，屏幕上显示unknown hard error的字样，安全模式下也无法正常进入系统等等。用户的第一反应就是感染了病毒，而在经过金山毒霸反病毒专家的仔细分析后，发现了问题的症结所在：诺顿杀毒软件的误报所致，赛门铁克SAV 2007-5-17 Rev 18版本的病毒定义码中，将Windows XP操作系统的netapi32.dll文件和lsasrc.dll文件判定为Backdoor.Haxdoor病毒，并进行隔离，导致重启电脑后无法进入系统，并出现蓝屏、重启等现象，造成了大量的数据丢失，系统崩溃，损失惨重。 此次电脑病毒误报事件被反病毒专家称为是近5年来国内影响面最大的误报事件。诺顿在企业级用户中占据了30%的份额，这次低级的错误造成了大量的电脑系统崩溃，造成了巨大的损失，虽然，赛门铁克已经公开道歉，修复了Bug，并提出了拯救系统的方案，但是，赛门铁克还是很可能面临着巨额的索赔。其实，针对类似很多的“误杀门”事件，软件厂商只需在软件发布前做一个完整的兼容性测试就可以很有效地避免这样的灾难事故了。 (2) 2000年12月4日上午10时30分起，浦东地区不少电话用户突然发现通话受阻，一部分移动电话、寻呼机用户也受到影响，无法正常收发信息。由于故障地区位于浦东中心地区，大量中外商务机构包括证券大厦、期货交易所等都在其中，造成了严重的局面。 经电信部门紧急查寻，发现问题出在一电话汇接局内的贝尔电话交换机上，估计是软件系统发生故障。上海有关部门立即调集了一批电信专家和技术人员来到现场，与上海贝尔公司派出的专家一起进行“会诊”和抢修。通话受阻情况在当晚午夜得到平息。 最终，上海电信部门确认了交换机软件的缺陷是造成这次事件的主要原因。虽然这一系统7年前就已经安装在汇接局，并一直没有被发现有缺陷。但有关专家认为，如果多种作用因素同时出现，或者是瞬间出现极高的话务量，这一缺陷迟早会“现身”。 (3) 1999年12月3日，美国航天局的火星极地登陆飞船在试图登陆火星表面时失踪了，造成了巨大的损失。错误修正委员会观测到故障，并确定出现误动作的原因极可能是由于某一数据位被意外地更改了。大家对这一错误感到非常震惊，认为该问题应该在内部测试时就予以解决。 可以很肯定地说，这只是表面现象，暴露问题、“破坏”程序并不是软件测试的最终目的，软件测试的目的是尽早发现软件缺陷，并确保其得以修复。换而言之，软件测试的最终目的是提高软件质量。所以，软件测试表面看起来是“破坏”，其实质却是为了“建设”质量更高的软件产品。用一句不太恰当的话总结就是，破而后立。 8.2.1 客户服务系统业务架构分析 (2) 不过，一般来说，我们习惯上把所有的软件问题都统称为缺陷（bug）。要定义软件缺陷，我们必须先了解另一个概念——产品需求规格说明书（又称需求说明书）：是软件开发小组的协定，它对开发的产品进行定义，包括产品有何细节、如何操作、功能如何、有何限制等。 (3) 软件缺陷的正式定义如下，只要符合下列5个规则中的任何一条都是软件缺陷： 软件未达到产品说明书表明的功能； 软件出现了产品说明书指明不会出现的错误； 软件功能超出了产品说明书指明的范围； 软件未达到产品说明书虽未指出但应达到的目标； 软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。 8.2.1 客户服务系统业务架构分析 (2) 假设，测试员发现，按要求输入了两个数字1和2，并且按下了“+”键，要求进行加法数学运算，但是，最终计算器并没有在显示屏上显示结果，又或者是计算器在显示屏上显示的是错误的结果，比如显示结果是4，而不是正确结果3。那么，根据第1条规则，这就是一个软件缺陷。 假设，测试员对计算器的键盘随意敲击（猴子测试），发现计算器“死机”了，对任何操作都无响应，那么，根据第2条规则，这就是一个软件缺陷。 假设，测试员发现，计算机除了能够进行加、