软件测试策略_第1页
软件测试策略_第2页
软件测试策略_第3页
软件测试策略_第4页
软件测试策略_第5页
已阅读5页,还剩35页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

软件测试策略第2章软件测试策略第2页,共40页,2024年2月25日,星期天目录软件测试的分类1软件测试的原则2软件测试关键问题3软件测试与软件质量4软件测试的误区5第3页,共40页,2024年2月25日,星期天软件测试的分类按照开发阶段划分单元测试:模块测试,检查每个程序单元嫩否正确实现详细设计说明中的模块功能等。集成测试:组装测试,将所有的程序模块进行有序、递增的测试,检验程序单元或部件的接口关系系统测试:检查完整的程序系统能否和系统(包括硬件、外设和网络、系统软件、支持平台等)正确配置、连接,并满足用户需求。确认测试:证实软件是否满足特定于其用途的需求,是否满足软件需求说明书的规定。验收测试:按照项目任务或合同,供需双方签订的验收依据文档进行的对整个系统的测试与评审,决定是否接受或拒收系统。第4页,共40页,2024年2月25日,星期天软件测试的分类按照测试技术划分白盒测试:通过对程序内部结构的分析、检测来寻找问题。检查是否所有的结构及逻辑都是正确的,检查软件内部动作是否按照设计说明的规定正常进行。--结构测试黑盒测试:通过软件的外部表现来发现错误,是在程序界面处进行测试,只是检查是否按照需求规格说明书的规定正常实现。灰盒测试:介于白盒测试与黑盒测试之间的测试,关注输出对输入的正确性;同时,也关注内部表现,不像白盒那样详细,只是通过一些表征性现象、事件、标志来判断内部的运行状态。第5页,共40页,2024年2月25日,星期天软件测试的分类按照测试实施组织划分开发方测试:开发方通过检测和提供客观证据,证实软件的实现是否满足规定的需求,在开发环境下,开发方对提交的软件进行全面的自我检查。用户测试:在用户的应用环境中,用户通过运行软件,检测软件实现是否符合自己预期的要求,这里指用户的使用性测试。第三方测试:介于软件开发方和用户方之间的测试组织的测试。第6页,共40页,2024年2月25日,星期天按程序对象分面向测试对象粒度的划分按测试方法分类按运行状态分类面向软件测试实施者的划分嵌入式软件测试与非嵌入式软件测试软件测试的分类第7页,共40页,2024年2月25日,星期天软件测试的原则1完全测试的不可能性例:测试windows计算机器原因:输入量太大输出结果太多软件执行路径太多软件说明书是主观的,没有客观标准。第8页,共40页,2024年2月25日,星期天2软件测试是有风险的活动SoftwareTestingisaRisk-BasedExercise如果不选择完全测试所有情况,那就是选择了冒险Nottotesteverypossibletestscenario,Customerwilleventuallyfinditsomeday.如:1024+1024=2048矛盾:Testingvs.ReleasedeadlineStoptestingvs.Costlybug关键测试要点:把数量巨大的可能测试减少到可以控制的范围针对风险做出明智的选择,哪些测试重要,哪些不重要第9页,共40页,2024年2月25日,星期天软件缺陷故障数量测试量测试不足测试费用优化测试量测试过量遗漏软件缺陷数目测试工作量与软件缺陷数量之间的关系第10页,共40页,2024年2月25日,星期天3.测试无法显示潜伏的软件缺陷和故障软件测试员可以报告软件缺陷存在,却不能报告软件缺陷不存在.可以进行测试,发现并报告软件缺陷,但是任何情况下都不能保证软件缺陷不存在.Whatcanyoudo?!唯一的方法:继续测试,找到更多的缺陷第11页,共40页,2024年2月25日,星期天4.充分注意测试中的群集现象缺陷可能成群出现发现一个,附近就可能有一群缺陷一个接一个可能的原因:A.程序员也有心情不好的时候B.程序员往往犯同样的错误C.有些软件故障可能是冰山一角第12页,共40页,2024年2月25日,星期天5.杀虫剂现象农药—害虫软件测试越多,对测试的免疫力越强,寻找更多软件缺陷就更加困难.克服办法:在软件测试中采用单一的方法不能高效和完全的针对所有软件缺陷,因此软件测试应该尽可能的多采用多种途径进行测试.

第13页,共40页,2024年2月25日,星期天6.并非所有的软件缺陷都要修复虽然测试员尽了最大的努力,但并非找到的所有软件缺陷都要修复。并非意味着软件测试员没有达到目的.解决办法依赖软件测试员的素质—进行良好的判断,根据风险决定哪些缺陷需要修复,哪些不需要修复。造成软件缺陷不能修复的原因:(1)时间不够(2)不算真正的软件缺陷(3)修复的风险太大(4)不值得修复第14页,共40页,2024年2月25日,星期天7.难以描述的软件缺陷如果软件中存在缺陷,但没有人能够发现,算不算缺陷?软件缺陷的定义:(1)软件未达到产品说明书中已经标明的功能;(2)软件出现了产品说明书中指明不会出现的错误;(3)软件未达到产品说明书中虽未指出但应当达到的目标;(4)软件功能超出了产品说明书中指明的范围;(5)软件测试人员认为软件难以理解、不易使用,或者最终用户认为该软件使用效果不良。一棵树在森林中倒下,没有人看见听见,它发出声音了吗?第15页,共40页,2024年2月25日,星期天8)80-20原则

第一个含义:80%的软件缺陷常常生存在软件20%的空间里。如果想使软件测试有效,就要更加关注那些经常或者可能出现错误的程序段,在那里发现软件缺陷的可能性会大的多。这一原则对于软件测试人员提高测试效率及缺陷发现率有着重大的意义。

第16页,共40页,2024年2月25日,星期天8)80-20原则

第二个含义:在系统分析、设计、实现阶段的复审工作中能够发现和避免80%的软件缺陷,此后的系统测试能够帮助我们找出剩余缺陷中的80%,最后的5%的软件缺陷可能只有在系统交付使用后用户经过大范围、长时间使用后才会曝露出来。因为软件测试只能够保证尽可能多地发现软件缺陷,却无法保证能够发现所有的软件缺陷。第17页,共40页,2024年2月25日,星期天8.)80-20原则

第三个含义:实践证明80%的软件缺陷可以借助人工测试而发现,20%的软件缺陷可以借助自动化测试能够得以发现。由于这二者间具有交叉的部分,因此尚有5%左右的软件缺陷需要通过其他方式进行发现和修正。第18页,共40页,2024年2月25日,星期天9.软件测试必须有预期结果

软件缺陷是经过对比而得出来的。没有预期结果的测试是绝不可以的。我们事先不知道或是无法肯定预期的结果,我们必然无法了解测试正确性。第19页,共40页,2024年2月25日,星期天10.应当把“尽早地和不断地进行软件测试”作为软件测试者的座右铭(想想虫卵、小虫、大虫)

第20页,共40页,2024年2月25日,星期天11.程序员应该避免检查自己的程序。Why?程序员从来不会承认自己写的程序有错误程序员的测试思路有明显的局限性多数程序员没有经过严格正规的职业训练,常忽视测试程序员无良好的BUG跟踪和回归测试的习惯第21页,共40页,2024年2月25日,星期天12追溯至用户需求

13及时更新测试第22页,共40页,2024年2月25日,星期天软件测试关键问题

(1)测试由谁来执行?通常软件产品的开发设计包括开发者和测试者两种角色。开发者:通过开发形成产品,如分析、设计、编码调试或文档编制等。测试者通过测试来检测产品中是否存在缺陷,包括根据特定目的而设计测试用例、构造测试、执行测试和评价测试结果等。通常由开发者负责完成第一阶段的代码单元测试,而系统测试则由独立的测试人员或专门的测试机构进行。按照测试实施组织划分,软件测试可分为开发方测试、用户测试(β测试)、第三方测试。第23页,共40页,2024年2月25日,星期天软件测试关键问题开发方测试通常也叫“验证测试”或“α测试”。开发方通过检测和提供客观证据,证实软件的实现是否满足规定的需求。验证测试是在软件开发环境下,由开发者检测与证实软件的实现是否满足软件设计说明或软件需求说明的要求。主要是指在软件开发完成以后,开发方对要提交的软件进行全面的自我检查与验证,可以和软件的“系统测试”一并进行。第24页,共40页,2024年2月25日,星期天软件测试关键问题用户测试在用户的应用环境下,用户通过运行和使用软件,检测与核实软件实现是否符合自己预期的要求。通常情况用户测试不是指用户的“验收测试”,而是指用户的使用性测试,由用户找出软件的应用过程中发现的软件缺陷与问题,并对使用质量进行评价。β测试通常被看成是一种“用户测试”。β测试主要是把软件产品有计划地免费分发到目标市场,让用户大量使用,并评价、检查软件。通过用户各种方式的大量使用,来发现软件存在的问题与错误,把信息反馈给开发者修改。第25页,共40页,2024年2月25日,星期天软件测试关键问题第三方测试介于软件开发和用户方之间的测试组织的测试。也称为独立测试。软件质量工程强调开展独立验证和确认(IV&V)活动。由在技术、管理和财务上与开发方和用户方相对独立的组织进行的软件测试。一般情况下是在模拟用户真实应用环境下,进行软件确认测试。第26页,共40页,2024年2月25日,星期天软件测试关键问题(2)测试什么?软件产品的组成:软件产品到底是什么?并不仅仅是从软盘或者光盘安装到计算机上的程序,还包括许多隐含的内容,容易被忽视,但这些也往往是包含软件缺陷的测试对象,需要软件测试员铭记在心!第27页,共40页,2024年2月25日,星期天软件测试关键问题软件测试对象:软件测试不仅仅是对程序的测试,而是贯穿于软件定义和开发的整个过程。因此,软件开发过程中产生的需求分析、概要设计、详细设计以及编码等各个阶段所得到的文档,包括需求规格说明、概要设计说明、详细设计规格说明以及源程序,都是软件测试的对象。软件测试在软件生命周期,也就是从开发设计、运行、直到结束使用的全过程中,主要横跨以下两个测试阶段:第28页,共40页,2024年2月25日,星期天软件测试关键问题第一阶段:单元测试阶段,即在每个模块编写出以后所做的必要测试。第二阶段:综合测试阶段,即在完成单元测试后进行的测试,如集成测试、系统测试、验收测试等。研究表明,通常表现在程序中的故障,并不一定是由编码所引起的,可能是需求分析,概要设计、详细设计等阶段的问题所致,要排除故障就必须追溯到前期的工作(这就涉及到下一个问题——什么时候进行测试)第29页,共40页,2024年2月25日,星期天软件测试关键问题(3)什么时候进行测试。测试可以是一个与开发并行的过程,也可以是开发完成某个阶段任务后的的活动,即模块开发结束之后,还可以在各模块装配成为一个完整的程序之后再进行测试。第30页,共40页,2024年2月25日,星期天软件测试关键问题(4)怎样进行测试。对软件进行测试就是根据软件的功能规范说明和程序实现,利用各种测试方法,生成有效的测试用例,对软件进行测试。第31页,共40页,2024年2月25日,星期天软件测试关键问题(5)测试停止的标准是什么从现实和经济的角度来看,对软件进行完全测试是不可能的。那么,什么时候停止测试呢?因为无法判断当前查出的故障是否为最后一个故障,所以决定什么时候停止测试是一件很困难的事。测试完成的传统标准是分配的测试时间用完了或完成了所有的测试又没有检测出故障。但这两个完成标准都没有什么实用价值。实用的停止测试标准应该基于以下几个因素:成功地采用了具体的测试用例设计方法;每一类覆盖的覆盖率;第32页,共40页,2024年2月25日,星期天软件测试关键问题故障检测率(即每一单元测试时间内检测出的故障数)低于指定的限度。基于故障检测数量的标准必须注明故障的严重性程度。检测出故障的具体数量或消耗的具体时间等。常用的停止测试的标准有5类测试超过了预定的时间,停止测试;执行了所有测试用例但没有发现故障,停止测试;使用特定的测试用例设计方法作为判断测试停止的基础;正面指出测试停止的要求,比如发现并修改70个软件故障;根据单位时间内查出故障的数量决定是否停止测试。第33页,共40页,2024年2月25日,星期天软件测试与软件质量事实上,对于软件来讲,不论采用什么技术和什么方法,软件中仍然会有错。采用新的语言、先进的开发方式、完善的开发过程,可以减少错误的引入,但是不可能完全杜绝软件中的错误,这些引入的错误需要通过测试来发现,软件中的错误密度也需要测试来进行估计。统计表明,在典型的软件开发项目中,软件测试工作量往往占软件开发总工作量的40%以上。而在软件开发的总成本中,用在测试上的开销要占30%到50%。

第34页,共40页,2024年2月25日,星期天软件测试与软件质量软件质量保证(SQA)的职能是向管理层提供正确的可视化的信息,从而促进与协助流程改进。SQA还充当测试工作的指导者和监督者,帮助软件测试建立质量标准、测试过程评审方法和测试流程,同时通过跟踪、审计和评审,及时发现软件测试过程中的问题,从而帮助改进测试或整个开发的流程等,因此有了SQA,测试工作就可以被客观的检查与评价,同时也可以协助测试流程的改进。第35页,共40页,2024年2月25日,星期天软件测试与软件质量而测试为SQA提供数据和

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论