ImageVerifierCode 换一换
格式:DOCX , 页数:29 ,大小:2.86MB ,
资源ID:28191579      下载积分:3 金币
快捷下载
登录下载
邮箱/手机:
温馨提示:
快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。 如填写123,账号就是123,密码也是123。
特别说明:
请自助下载,系统不会自动发送文件的哦; 如果您已付费,想二次下载,请登录后访问:我的下载记录
支付方式: 支付宝    微信支付   
验证码:   换一换

加入VIP,免费下载
 

温馨提示:由于个人手机设置不同,如果发现不能下载,请复制以下地址【https://www.bdocx.com/down/28191579.html】到电脑端继续下载(重复下载不扣费)。

已注册用户请登录:
账号:
密码:
验证码:   换一换
  忘记密码?
三方登录: 微信登录   QQ登录  

下载须知

1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。
2: 试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。
3: 文件的所有权益归上传用户所有。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 本站仅提供交流平台,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

版权提示 | 免责声明

本文(软件测试理论课程2.docx)为本站会员(b****8)主动上传,冰豆网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知冰豆网(发送邮件至service@bdocx.com或直接QQ联系客服),我们立即给予删除!

软件测试理论课程2.docx

1、软件测试理论课程2课程介绍1.软件测试的类型(重要)2.软件测试的方法(重要)3.缺陷管理(重要)4.软件质量(重要)5.敏捷开发(了解)1.软件测试的类型(重要)1.1.功能测试功能测试就是对产品的各功能进行验证,根据功能测试用例,逐项测试,检查产品是否达到用户要求的功能。1.2.性能测试相对于当前软件消耗的资源,它的产出能力。一天吃3顿吼一天、一天吃2顿吼二天性能测试是通过自动化的测试工具模拟多种正常、异常的条件来对系统的各项性能指标进行测试。1.3.接口测试接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据

2、的交换,传递和控制管理过程,以及系统间的相互逻辑依赖关系等。1.4.兼容性测试兼容性测试(Compatibility Test Suite )简称CTS, 指对所设计程序与硬件、软件之间的兼容性的测试。分为浏览器兼容测试 和分辨率兼容测试两类。IE,firefox,google,苹果内核:发动机1.5.用户体验测试用户体验测试(user experience)顾名思义就是测试人员在将产品交付客户之前处于用户角度进行的一系列体验使用,如:界面是否友好(吸引用户眼球,给其眼前一亮)、操作是否流畅、功能是否达到用户使用要求等。1.6.安全测试验证软件是否只能让授权用户提供功能使用。ATM机:不用输密

3、码? 输错3次吞卡?2.软件测试的方法(重要) 一、按测试对象进行分类:白盒测试,黑盒测试二、按测试对象是否执行:静态测试,动态测试三、按测试手段进行分类:手工测试,自动化测试2.1.白盒测试白盒测试又称结构测试、逻辑驱动测试或基于程序本身的测试,也可称为程序员测试,主要应用于结构化开发环境,基于代码的测试白盒测试的常用测试方法:代码检查法-静态测试逻辑覆盖法-动态测试基本路径测试法-动态测试2.2.黑盒测试黑盒测试又称功能测试、数据驱动测试或基于需求规格说明的测试.黑盒测试它是通过测试来检测每个功能是否都能正常使用。在测试中,把程序看作一个不能打开的黑盒子,在完全不考虑程序内部结构和内部特性

4、的情况下,在程序外部进行测试,它只检查程序功能是否按照需求规格说明书的规定正常使用。黑盒测试着眼于程序外部结构,不考虑内部逻辑结构,主要针对软件界面和软件功能进行测试。2.3.静态测试静态测试,不执行被测试的软件。类似于汽车检查。静态测试(static testing)就是不实际运行被测软件,而只是静态地检查程序代码、界面或文档中可能存在的错误的过程。对于代码测试,主要测试代码是否符合相应的标准和规范。对于界面测试,主要测试软件的实际界面与需求中的说明是否相符。对于文档测试,主要测试用户手册和需求说明是否符合用户的实际需求。2.4.动态测试动态测试是在测试过程中执行被测试软件,类似于试车。动态

5、测试(dynamic testing),指的是实际运行被测程序,输入相应的测试数据,检查实际输出结果和预期结果是否相符的过程.所以判断一个测试属于动态测试还是静态的,唯一的标准就是看是否运行程序。2.5.手工测试由测试人员手动的对被测对象进行验证,优点就是可以灵活的改变测试操作及环境。2.6.自动化测试所谓自动化主要有两种形式,一种是自己写测试脚本,另外一种就是通过第三方的工具对被测对象进行测试。优点就是可以高效率的去执行一些人工无法实现的操作。3.软件质量(重要)3.1.什么是软件质量?质量就是一个实体的所有特性满足明显的或隐含需求的程度。3.2.软件质量体现在哪些方面?ISO质量模型:1.

6、功能性:能满足明确和隐含需求的功能2.可靠性:成熟可靠,容错能力,易恢复3.易用性:易理解、易学习、易操作,颜值4.效率性:资源占用少,响应时间快5.可维护性:可被修改的能力6.可移植性:从一种环境迁移到另外一种环境的能力【功能靠用,效率可”以”】3.3.软件质量管理(SQM)由哪些构成? 软件质量管理分为软件质量保证(SQA)与软件质量控制(SQC)软件质量保证(SQA):SQA:事先的质量保证活动,以预防为主,通过制定相应的体系,流程,规范降低出错几率,通过控制流程,检查输出来确保品质是否满足于标准。软件质量控制(SQC):SQC:事后的质量检验活动,以测试为主,期望并发现错误,以体系要求

7、运作,通过具体实施来检验产品来确保符合规定软件质量保证(SQA)与软件质量控制(SQC)的主要区别:SQC是保证产品质量符合规定,SQA是建立体系并确保体系按要求运作.4.软件缺陷管理(重点)4.1.软件缺陷的定义(了解)4.1.1.软件缺陷的示例系统蓝屏:Win10系统在浏览器的地址栏中或使用其他 Windows 命令打开特定路径,即可使电脑系统崩溃并显示蓝屏。.globalrootdevicecondrvkernelconnect4.1.2.Bug名称的由来“名留青史”的飞蛾:4.1.3.软件缺陷的定义前面我们看到了软件失败所发生的事件的一些实例。其后果也许是带来不便,比如电脑游戏玩不了,

8、也可能是灾难性的,会导致人员的伤亡。改正软件缺陷也许花费很小,也可能需要花费上百万。在这些事件中,显然软件未按预期目标运行。软件缺陷的官方定义:只有至少满足以下5个规则之一才称发生了一个软件缺陷。1)软件未实现需求规格说明书要求的功能。(预期:加法功能;实际:没有实现加法功能)2)软件出现了需求规格说明书指明不应该出现的错误。(需求:永不崩溃;实际:死机)3)软件实现了需求规格说明书未提到的功能。(需求:加减乘除;实际:加减乘除、开平方根)4)软件未实现需求规格说明书虽未明确提及但应该实现的目标。(ECshop电子商城 订单查询 需求中未规定,要不要实现?)5)软件难以理解、不易使用、运行缓慢

9、或者-从测试员的角度看-最终用户会认为不好。小结:软件缺陷,即为计算机软件或程序中存在的某种破坏正常运行能力的问题、错误,或者隐藏的功能缺陷。缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。IEEE729-1983对缺陷有一个标准的定义:从产品内部看,缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题;从产品外部看,缺陷是系统所需要实现的某种功能的失效或违背。4.2.软件缺陷的属性(重要)4.2.1.缺陷属性软件缺陷的属性包括缺陷标识、缺陷类型、缺陷严重程度、缺陷优先级、缺陷状态、缺陷起源、缺陷来源、缺陷原因、缺陷产生可能性。序号属性名称说明01标识(Identifier)标记某

10、个缺陷的唯一符号,可以使用数字、字母组合来表示。02类型(Headline)缺陷的分类定义03描述(Description)对缺陷进行的详细的描述,以便缺陷重现04严重程度(Severity)指因缺陷引起的故障对软件产品的影响程度05优先级(Priority)缺陷必须被修复的紧急程度06状态(State)缺陷通过一个跟踪修复过程的进展情况表格2-2 缺陷属性列表4.2.2.缺陷类型缺陷种类:根据缺陷的自然属性来划分。编号缺陷类型描述子类型编号名称01功能问题F-Function影响了重要的特性、用户界面、产品接口、硬件结构接口和全局数据结构。并且设计文档需要正式的变更。如指针循环,递归,功能等

11、缺陷。0101功能错误0102功能缺失0103功能超越0104设计的二义性0105算法错误02接口问题I-Interface与其他组件、模块或设备驱动程序、调动参数、控制块或参数列表相互影响的缺陷。0201模块间接口0202模块内接口0203公共数据使用03逻辑问题L-Logic需要进行逻辑分析,进行代码修改,如循环条件等。0301分支不正确0302重复的逻辑0303忽略极端条件0304不必要的功能0305误解0306循环不正确0307计算顺序错误0308逻辑顺序错误04计算问题C-Computation等式、符号、操作符或操作数错误,精度不够、不适当的数据验证等缺陷。0401等式错误0402

12、缺少运算符0403错误的操作数0404括号用法不正确0405精度不够0406舍入错误0407符号错误05数据问题A-Assignment需要修改少量代码,如初始化或控制块。如声明、重复命名,范围、限定等缺陷。0501初始化错误0502存取错误0503引用错误变量0504数组应用越界0505数据单位不正确0506变量类型不正确0507数据范围不正确0508操作符错误0509数据覆盖0510输出数据错误0511输入数据错误06用户界面问题U-User interface人机交互特性:屏幕格式,确认用户输入,功能布局,页面排版等方面的缺陷。0601界面风格不统一0602屏幕上的信息不可用0603屏幕

13、上的错误信息604界面功能布局和操作不合常规07文档问题D-Documentation影响发布和维护,包括注释等缺陷。0701描述含糊不清0702项描述不完整0703项描述不正确0704项缺少或多余0705项不能验证0706项不能完成0707不符合标准0708与需求不一致0709文字排版错误0710文档信息错误0711注释缺陷08性能问题P-Performance不满足系统可测量的属性值,如:执行时间,事务处理速率等缺陷。0801事务响应时间过长0802系统资源占用过多:CPU,ARM09配置问题B-Build、package、merge由于配置库、变更管理或版本控制引起的错误。0901配置管

14、理问题0902编译打包缺陷0903变更缺陷10标准问题N-Norms不符合各种标准的要求,如编码标准、设计符号等缺陷1001不符合编码标准1002不符合软件标准1003不符合行业标准11环境问题E-Environments由于设计、编译和运行环境引起的问题。1101设计、编译环境1102运行环境12兼容问题软件之间不能正确的交互和共享信息。1201操作平台不兼容1202浏览器不兼容1203分辨率不兼容13其他问题O-Others以上问题所不包含的问题表格2-3缺陷类型列表4.2.3.缺陷严重程度缺陷严重程度:指因缺陷引起的故障对软件产品的影响程度。严重级别对应缺陷严重等级描述1-致命(Fata

15、l)致命缺陷系统任何一个主要功能完全丧失,系统无法执行、崩溃或严重资源不足、应用模块无法启动或异常退出、无法测试、造成系统不稳定,用户数据受到破坏,或者危机人身安全;例:1)严重花屏2)内存泄漏 3)系统崩溃/死机4)模块无法启动或异常退出5)功能设计与需求严重不符6)严重的数值计算错误7)其他导致无法测试的错误:如HTTP 500错误2-严重(Critical)严重缺陷系统的主要功能部分丧失,数据不能保存,系统的次要功能完全丧失,系统所提供的功能或服务受到明显的影响,不能执行正常工作功能或实现重要功能。例:1)功能未实现2)功能错误3)系统刷新错误4)影响功能及界面的错别字或拼写错误5)安全

16、性问题。3-重要(Major)较大缺陷产生错误的结果,导致系统不稳定,运行时好时坏,严重影响系统要求或基本功能实现的问题。例:1)操作界面错误(包括数据窗口内列名定义、含义是否一致);2)提示信息错误(包括未给出信息、信息提示错误等);3)长时间操作无进度提示;4)兼容问题。4-一般(Minor)一般缺陷系统的次要功能没有完全实现,但不影响用户的正常使用,不会影响系统稳定性的:1)提示信息不太准确或用户界面差、操作时间长等一些问题;2)功能的实现有问题,如在系统实现的界面上,一些可接受输入的控件点击后无作用,对数据库的操作不能正确实现;5-较小(Slight)轻微缺陷使操作者不方便或遇到麻烦,

17、但它不影响功能的操作和执行,如个别不影响产品理解的错别字、文字排列不整齐等一些小问题,重点指系统的UI问题:1)滚动条无效;2)可编辑区域和不可编辑区域不明显;3)光标跳转设置不好,鼠标(光标)定位错误;4)上下翻页,首位页定位错误;5)界面不一致,或界面不正确;6)日期或时间初始值错误(起止日期、时间没有限定);7)出现错别字,标点符号错误,拼写错误,以及不正确的大小写等;6-有待改进(Enhancement)其他缺陷系统中值得改良的问题:1)容易给用户错误和歧义的提示;2)界面需要改进的,某个控件没有对齐等;3)对有疑虑的部分,提出修改建议。表格2-4 缺陷严重程度4.2.4.缺陷优先级序

18、号缺陷优先级描述01立即解决 (Resolve Immediately)缺陷导致系统几乎不能使用或者测试不能继续,需立即修复;02高优先级(high priority)缺陷严重,影响测试,需要优先考虑;03正常排队(Normal Queue)缺陷需要正常排队等待修复;04低优先级(Low priority)缺陷可以在开发人员有时间的时候被纠正。表格2-5 缺陷优先级4.2.5.缺陷状态缺陷状态:是指缺陷通过一个跟踪修复过程的进展情况。序号缺陷状态描述01新建New测试人员提交新的错误到库。02激活或打开(Active or Open)问题还没有解决,存在源代码中,确认“提交的缺陷”,等待处理。

19、03拒绝(Rejected)拒绝“提交的缺陷”:不需要修复(Wont Fix)或不是缺陷(Invalid)或缺陷已经被其他的软件测试人员发现(Duplicate)。04已修正或已修复(Fixd or Resolved)已被开发人员检查、修复过的缺陷,通过单元测试,认为已解决但还没有被测试人员验证。05关闭(Closed)测试人员验证后,确认缺陷不存在之后的状态。06重新打开(Reopen)测试人员验证后,还依然存在的缺陷,等待开发人员进一步修复;07推迟(Deferred)这个软件缺陷在下一个版本解决。表格2-6 缺陷状态14.3.如何提交缺陷报告(重要)4.3.1.一个简单的缺陷报告示例4.

20、3.2.报告软件缺陷的基本原则:在软件/测试过程中,对于发现的大多数软件缺陷,要求测试人员简捷、清晰地把发现的问题报告给判断是否进行修复的小组,使其得到所需要的全部信息,然后才能决定怎么做。1.尽快报告软件缺陷软件缺陷发现的越早,在进度中留下的修复时间就越多。2.有效的描述软件缺陷短小:只解释事实和演示、描述软件缺陷必须的细节单一:每一个报告只针对一个软件缺陷明显并通用:用阅读者容易看懂的,简单易行的步骤 所描述的软件缺陷,得到修复的机会较大。可再现:要想得到重视,软件缺陷报告必须展示其可再现性-按照预定步骤可以使软件达到缺陷再次出现的相同状态。3.在报告软件缺陷时不要做评价测试员和程序员容易

21、形成对立关系。软件缺陷报告应该针对产品,而不是具体的人,只陈述事实。避免幸灾乐祸,自负,责怪。得体和委婉是关键。需要善于沟通与合作。4.对软件缺陷报告跟踪到底比没有找到重要软件缺陷更糟糕得是,发现了一个重要的软件缺陷,作了报告,然后把他忘掉了或者跟丢了。对项目负责,有责任心是每个测试工程师必须有的。4.3.3.缺陷定位文件的重要性提交缺陷报告时,附带缺陷定位可以使开发人员更快的定位问题,一般的定位文件有:缺陷图片操作视频运行日志LOG文件等4.3.4.缺陷报告的基本元素一个完整的缺陷报告通常由下列几部分组成:4.3.5.缺陷报告基本元素解释4.4.软件缺陷的生命周期(重要)5.敏捷开发(了解)

22、5.1.什么是敏捷开发简单的说,敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。敏捷最大的特色是迭代式开发。5.2.敏捷开发的优势敏捷开发确实是项目进入实质开发迭代阶段,用户很快可以看到一个基线架构版产品的模式。敏捷注重市场快速反应能力,也即具体应对能力,客户前期满意度高。1、敏捷开发属于增量式开发,对于需求范围不明确,需求变更较多的项目而言,可以很大程度上响应及拥抱变化。2、对于

23、互联网产品而言,市场风向转变很快,需要一种及时快速的交付形式,而敏捷开发则能更好地适用于此。3、敏捷开发可最大程度体现80/20法则的价值,通过增量迭代,每次都优先交付那能产生80%价值效益的20%功能。能最大化单位成本收益。5.3.敏捷开发的特点1.人员交流重于过程与工具2.可以工作的软件胜过面面俱到的文档3.客户合作胜过合同谈判4.响应变化胜过遵循计划5.4.与瀑布模型对比敏捷开发:客人到餐馆来点菜(新项目)客人不确定想吃什么的时候,通常选好餐厅后会先看看餐厅的菜单(客户往往提不出具体的需求)根据图文菜单,客人点了十个菜(根据原型和设计稿,基本确定了需求)后厨开始准备(项目启动)配菜、炒菜

24、,先上了两盘,让客人尝了尝味道(先提供可用实例给客户用)客人说还不错,后厨继续准备后面的菜,陆续上菜(不断迭代,不断测试)上菜过程中,客人突然发现有个菜的味道太淡了,让后厨加了点盐又端上来了(敏捷的好处,可以不断测试和需求变更)又上了两盘,不够辣,又拿到后厨加了辣(敏捷的坏处,需求没有提前明确,反复迭代,增加了工作量)到最后两盘时,客人要求换两个菜,还好没炒(迭代的好处,随时接受需求变更)客人吃完,很满意(基本满足了全部的要求)瀑布模型开发:客人到餐馆来点菜(新项目)客人不确定想吃什么的时候,通常选好餐厅后会先看看餐厅的菜单(客户往往提不出具体的需求)根据图文菜单,客人点了十个菜(根据原型和设

25、计稿,基本确定了需求)后厨开始准备(项目启动)根据客人的下单配菜,炒菜(基本上不会主动去了解完整需求)半个小时了,菜还没上桌,客人饿极了(项目启动后很长一段时间客户什么都看不到)再过了二十分钟,十个菜都一起上来了(项目最终一次交付)客人说,有几个菜挺好的,但是有个菜味道淡了,有两个不够辣,还有两盘重复了想换掉(我是买单的,我要变需求)这时候大堂经理来了,说,“味道淡了可以加盐,不辣可以加辣,但是换菜不行,已经炒好的那两盘菜也是要算成本的”(瀑布的坏处,需求变更比较麻烦)于是,后厨只给客户加了盐,加了辣客人吃完,不是很满意,下次不来了(没有满足需求)5.5.敏捷开发小结总的来说,在现在管理项目过程中,并没有严格的按照完全的敏捷或者完全的瀑布模式,都是各自掺杂了其他的方式。在实际项目过程中,过于强调模式并没有意义,重要的是能不能预防问题的发生,在问题发生之后能不能用最小的成本解决,模式更多起一个参考作用。6.课程总结6.1.重点1.缺陷生命周期2.质量模型6.2.难点1.缺陷生命周期2.质量模型7.课后练习8.每日一练1.一条缺陷记录包含哪些信息?2.请描述一下缺陷管理的流程?

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1