搜索
第1章软件测试概述第2次课内容提纲复习软件缺陷软件测试模型软件测试与软件工程的关系软件测试原则软件测试关键问题作业复习软件测试的定义软件测试的分类1、软件缺陷（1）软件未达到产品说明书中已经标明的功能；（2）软件出现了产品说明书中指明不会出现的错误；（3）软件未达到产品说明书中虽未指出但应当达到的目标；（4）软件功能超出了产品说明书中指明的范围；（5）软件测试人员认为软件难以理解、不易使用，或者最终用户认为该软件使用效果不良。计算器的例子计算器说明书：该计算器将准确无误地进行加、减、乘、除运算。计算器不会出现崩溃、死锁或停止反应。（1）2+3，没有反应？（2）随意敲击键盘后，没有了反应？（3）还能计算某数的平方根（4）因为电池没有电，所以计算错了（5）按键很小、显示屏看不清楚2、为什么会产生软件缺陷？（1）产品需求说明书（2）设计方案（3）编写代码（4）其他图1-1软件缺陷产生的原因分布软件产品说明书（需求）56％其他10％设计27％3、软件缺陷修复的费用软件在从需求、设计、编码、测试一直到交付用户公开使用后的过程中，都有可能产生和发现缺陷。随着整个开发过程的时间推移，更正缺陷或修复问题的费用呈几何级数增长。020406080100编制说明书设计阶段编写代码测试发布Thecostarelogarithmic$1$10$100需求设计编码发布$1000+软件缺陷例子1事件1996年6月4日，Arane5发射40秒后爆炸。原因将一个64位浮点值转换为16位有符号整数值时，超出了16位整数的表示范围，而这个异常未得到正确解决软件缺陷例子2事件1999年；火星气象卫星(MarsClimateOrbiter)到达火星之后不久就消失；火星极地登陆者(MarsPolarLander)在火星上着陆时坠毁原因地面系统软件和飞行器上软件分别使用公制和英制两种单位。神舟七号：测试用例3万多。确保稳定，确保万无一失。基本消除缺陷2、软件测试模型V模型W模型H模型V模型：20世纪80年代后期,PaulRook提出了著名的软件测试的V模型，是瀑布模型的变种，它反映了测试活动与分析和设计的关系，非常明确的表明了测试过程中存在的不同级别，以及各测试阶段与开发过程中的各阶段的对应关系，图中的箭头代表了时间方向，左边下降的是开发各阶段，右边上升的是测试过程的各个阶段。“V”模型V模型指出:单元测试和集成测试应检测程序的执行是否满足软件设计的要求;系统测试应检测系统功能,性能的质量特性是否达到系统要求的指标;验收测试确定软件的实现是否满足用户需要或合同的要求.“V”模型V模型的缺陷仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段忽视了测试对需求分析,系统设计的验证，一直到后期的验收测试才被发现。Evolutif公司提出了W模型的概念，增加了软件各开发阶段中应同步进行的验证和确认活动,明确了测试与开发的并行性.W模型测试伴随着整个软件开发周期测试的对象不仅仅是程序，需求、设计和功能同样要测试根据W模型的要求，一旦有文档提供，就要及时确定测试的条件、编写测试用例W模型的局限性在W模型中，需求、设计、编码等活动被视为串行的，同时，测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。H模型这个示意图仅仅演示了在整个生产周期中某个层次上的一次测试“微循环”。图中的其他流程可以是任意开发流程。测试就绪点测试流程其他流程（如设计流程）测试准备测试执行H模型软件测试不仅仅指测试的执行，还包括很多其他的活动。软件测试是一个独立的流程，贯穿产品整个生命周期，与其他流程并发的进行。软件测试要尽早准备，尽早执行。软件测试是根据被测物的不同而分层进行的。不同层次的测试活动可以按照某个次序先后进行的，但也可能是反复的。测试在开发阶段的作用如下：（1）项目规划阶段：负责从单元测试到系统测试的整个测试阶段的监控。（2）需求分析阶段：确定测试需求分析、系统测试计划的制定。其中，测试需求分析是对产品生命周期中测试所需求的资源、配置、每阶段评判通过的规约；系统测试计划则是依据软件的需求规格说明书，制定测试计划和设计相应的测试用例。（3）概要设计和详细设计阶段：确保集成测试计划和单元测试计划完成。（4）编码阶段：由开发人员进行自己负责部分的测试代码。3、软件工程与软件测试的关系1.4软件工程与软件测试的关系4.软件测试的原则4.1完全测试的不可能性例:测试windows计算机器原因：输入量太大输出结果太多软件执行路径太多软件说明书是主观的，没有客观标准。4.2软件测试是有风险的活动SoftwareTestingisaRisk-BasedExercise如果不选择完全测试所有情况，那就是选择了冒险Nottotesteverypossibletestscenario,Customerwilleventuallyfinditsomeday.如：1024+1024=2048矛盾：Testingvs.ReleasedeadlineStoptestingvs.Costlybug关键测试要点：把数量巨大的可能测试减少到可以控制的范围针对风险做出明智的选择，哪些测试重要，哪些不重要软件缺陷故障数量测试量测试不足测试费用优化测试量测试过量遗漏软件缺陷数目•测试工作量与软件缺陷数量之间的关系4.3.测试无法显示潜伏的软件缺陷和故障软件测试员可以报告软件缺陷存在,却不能报告软件缺陷不存在.可以进行测试,发现并报告软件缺陷,但是任何情况下都不能保证软件缺陷不存在.Whatcanyoudo?!唯一的方法:继续测试,找到更多的缺陷4.4.充分注意测试中的群集现象缺陷可能成群出现发现一个,附近就可能有一群缺陷一个接一个可能的原因:A.程序员也有心情不好的时候B.程序员往往犯同样的错误C.有些软件故障可能是冰山一角4.5.杀虫剂现象农药—害虫软件测试越多，对测试的免疫力越强，寻找更多软件缺陷就更加困难.克服办法：在软件测试中采用单一的方法不能高效和完全的针对所有软件缺陷，因此软件测试应该尽可能的多采用多种途径进行测试.4.6.并非所有的软件缺陷都要修复虽然测试员尽了最大的努力，但并非找到的所有软件缺陷都要修复。并非意味着软件测试员没有达到目的.解决办法依赖软件测试员的素质—进行良好的判断，根据风险决定哪些缺陷需要修复，哪些不需要修复。造成软件缺陷不能修复的原因：（1）时间不够（2）不算真正的软件缺陷（3）修复的风险太大（4）不值得修复4.7.80-20原则第一个含义：80%的软件缺陷常常生存在软件20%的空间里。如果想使软件测试有效，就要更加关注那些经常或者可能出现错误的程序段，在那里发现软件缺陷的可能性会大的多。这一原则对于软件测试人员提高测试效率及缺陷发现率有着重大的意义。4.7.80-20原则第二个含义：在系统分析、设计、实现阶段的复审工作中能够发现和避免80%的软件缺陷，此后的系统测试能够帮助我们找出剩余缺陷中的80%，最后的5%的软件缺陷可能只有在系统交付使用后用户经过大范围、长时间使用后才会曝露出来。因为软件测试只能够保证尽可能多地发现软件缺陷，却无法保证能够发现所有的软件缺陷。4.7.80-20原则第三个含义：实践证明80%的软件缺陷可以借助人工测试而发现，20%的软件缺陷可以借助自动化测试能够得以发现。由于这二者间具有交叉的部分，因此尚有5%左右的软件缺陷需要通过其他方式进行发现和修正。4.8.软件测试必须有预期结果软件缺陷是经过对比而得出来的。没有预期结果的测试是绝不可以的。我们事先不知道或是无法肯定预期的结果，我们必然无法了解测试正确性。4.9.应当把“尽早地和不断地进行软件测试”作为软件测试者的座右铭（想想虫卵、小虫、大虫）4.10.程序员应该避免检查自己的程序。Why?程序员从来不会承认自己写的程序有错误程序员的测试思路有明显的局限性多数程序员没有经过严格正规的职业训练，常忽视测试程序员无良好的BUG跟踪和回归测试的习惯4.11追溯至用户需求4.12及时更新测试5、软件测试的关键问题(1)软件测试的对象：——软件测试不等于程序测试。——软件测试贯串于软件定义和开发的整个过程。——软件开发过程中所产生的需求规格说明、概要设计规格说明、详细设计规格说明以及源程序都是软件测试的对象。（2）测试由谁来执行：通常，开发人员完成单元测试，而系统测试有一些独立的测试人员或者专门的测试机构进行。----第三方测试机构5、软件测试的关键问题5、软件测试的关键问题（3）什么时候进行测试：可以与开发并行进行；可以在开发完成某个阶段任务之后开发结束后。需求分析说明书详细设计说明书源程序代码单元测试集成测试确认测试概要设计说明书5、软件测试的关键问题（4）怎样进行测试：根据软件的功能规范说明和程序实现，利用各种测试方法，生成有效的测试用例，对软件进行测试。软件配置测试配置测试工具测试结果分析改正错误可靠性分析回归测试错误测试结果修正的软件测试结果预测的可靠性预期结果（5）测试停止的依据第一类标准：测试超过了预定时间，则停止测试。第二类标准：执行了所有的测试用例，但并没有发现故障，则停止测试。第三类标准：使用特定的测试用例设计方案作为判断测试停止的基础。第四类标准：正面指出停止测试的具体要求，即停止测试的标准可定义为查出某一预订数目的故障。第五类标准：根据单位时间内查出故障的数量决定是否停止测试。小结软件测试的定义软件缺陷软件测试的原则软件测试的过程模型软件测试与软件工程的关系