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

加入VIP,免费下载
 

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

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

下载须知

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

版权提示 | 免责声明

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

软件测试学习笔记.docx

1、软件测试学习笔记一、概述 11.软件质量的定义 12.软件质量的模型 23.软件缺陷 34. 软件测试的狭义与广义观点 35.测试与开发 46.制定项目规范 5二、单元测试 51.白盒测试: 62.代码审查 83.单元测试工具种类 9三、 集成测试 9四需求评审 91、软件评审的方法与技术 92、产品需求评审 10五、测试计划 10六、设计验证 12七、功能测试(黑盒测试) 121、功能测试内容和方法 122、等价类划分法 133、边界值分析法 144、因果图法 155、决策表法和错误推测法 156、场景法和状态图法 16八、非功能测试用例设计 16九、国际化和本地化测试 17十、系统测试 1

2、7一、概述1.软件质量的定义软件产品反应实体满足明确的和隐含的与需求能力有关的全部特征和特性的综合,包括:软件产品质量满足用户要求的程度软件各种属性组合的程度用户对软件产品的综合反映程度软件在使用过程中满足用户要求的程度实体是可以单独描述和研究的事物,如产品、活动、过程、组织和体系等软件质量其它定义v 客户满意度:使最终的软件产品能最大限度地满足客户需求的程度。v 一致性准则:在生命周期的每个阶段中,其工作产品总能保持与上一阶段工作产品的一致性,最终可追溯到所分配的需求。v 软件质量度量:设立软件质量度量指标体系,并以此来度量软件产品的质量。v 过程质量观:软件的质量就是其开发过程的质量软件产

3、品质量的需求v 功能性需求 PRD/MRD, UI Mock-up, Functional Spec 也可称为可说明性v 非功能性需求 性能、兼容性、安全性、可用性、可靠性等 可扩展性和灵活性,以适应一定程度的需求变化 能有效处理例外或异常情况v 软件质量实际上是各种特性的复杂组合2.软件质量的模型v Boehm质量模型v McCall质量模型v ISO的软件质量模型Boehm质量模型v 分成 可移植性,可用性和可维护性v 可用性分为 可靠性,效率,人类工程v 可维护性分为 可测试性 ,可理解性,可修改性McCall质量模型ISO的软件质量模型v 按照ISO/IEC 9126-1:2001,软

4、件质量模型分为:内部质量和外部质量模型。v 内部质量和外部质量规定了六个质量特性,它们可以进一步细分为子特性v 功能性:适合性,准确性,互用性,保密性,功能性的依从性v 可靠性:成熟性,容错性,易恢复性,可靠性的依从性v 易用性:易理解性,易学性,易操作性,吸引性,易用性的依从性v 效率:时间特性,资源利用性,效率依从性v 可维护性:易分析性,易变更性,稳定性,易测试性,可维护性的依从性v 可移植性:适应性,易安装性,共存性,可替换性,可移植性的依从性3.软件缺陷从内部看,软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题;从外部看,软件缺陷是系统所需要实现的某种功能的失效或违背v

5、 软件缺陷的主要类型/现象: 功能、特性没有实现或部分实现 设计不合理,存在缺陷 实际结果和预期结果不一致 没有达到产品规格说明书所规定的特性、性能指标等 运行出错,包括运行中断、系统崩溃、界面混乱 数据结果不正确、精度不够 用户不能接受的其他问题,如存取时间过长、界面不美观 硬件或系统软件上存在的其它问题软件缺陷与软件错误之辩软件缺陷范围更广,涵盖了软件错误,还涵盖不一致性问题、功能需求定义缺陷和产品设计缺陷等。软件错误,属于软件缺陷的一种程序或系统的内部缺陷,往往是软件代码本身的问题4. 软件测试的狭义与广义观点程序测试是为了发现错误而执行程序的过程将测试延伸到需求评审、设计审查活动中去。

6、由静态测试和动态测试构成一个全过程的、完整的软件测试静态测试和动态测试v 静态测试是指不运行被测程序本身而尝试查找缺陷的方法。比如,分析或检查源程序的语法、结构、过程、接口,审查需求设计及其它文档。v 动态测试是通过运行程序检查运行结果与预期结果的差异,并分析运行效率和健壮性等性能,这种方法由三部分内容组成:构造测试实例、执行程序、分析程序的输出结果.软件测试的其它视点v 风险观点:软件测试是对软件系统中潜在的各种风险进行评估的活v 经济学观点:一个好的测试用例是在于它能发现至今未发现的错误。缺陷发现得越早,所造成得代价就越低,这就是从经济学的观点来说明测试越早越好。v 标准观点:软件测试就是

7、“验证(Verification)”和“有效性确认(Validation)”活动构成的整体,即软件测试= V&V验证和确认(V & V) Verification:Are we building the product right?验证产品满足规格设计说明书的一致性,我们正确地构造产品了吗?Validation: Are we building the right product?验证产品所实现的功能是否满足用户的需求。我们构造了正确的产品吗?软件测试的目标v 直接目标就是为了更快更早地将软件产品或软件系统中所存在的问题找出来,以促进系统分析人员、设计人员和程序员尽快地解决这些问题。v 间接目

8、标软件测试的间接目标是验证了所有功能已按照事先设计或定义而实现。但其直接目的并非验证每个功能都能实现,而是设法找到每个功能不能正常实现的地方,即尽量促使软件故障的产生。软件测试的非完备性因素v 测试覆盖率不可能达到100%v 发现缺陷越多的地方,往往漏掉缺陷的可能性更大v 修正过去的缺陷会产生新的缺陷v 测试人员对产品的理解不能完全代表实际用户的理解v 测试环境难以和实际运行或用户的环境完全吻合。v 没有缺陷不是靠测试来保证的,而是靠软件过程的各个环节来保证的。5.测试与开发制度性设置v 测试部门与开发部门的独立设置是软件开发质量得到保证的一个制度性设置。v 测试对于开发有效监督与反馈,从源头

9、促进质量提高,保证软件构造的质量。v 开发因测试结果而不断完善,测试还起着“把关”或“守门员”的作用测试&开发的同步关系测试&开发的依赖关系v 测试对象是软件开发的阶段性成果v 软件开发的进一步活动有依赖于测试结果前期更多地依赖于开发过程,设计和实现能力决定整个软件过程的进展状态。后期更多地依赖于测试过程,测试策略和能力,会直接影响测试效率,测试效率高就能更快地发现缺陷,缺陷就能得到更快地修正6.制定项目规范软件测试规范就是对软件测试的流程过程化,并对每一个过程元素进行明确的界定,形成完整的规范体系测试活动过程v 制定测试计划v 测试设计v 开发测试工具和脚本v 执行单元测试v 执行集成测试v

10、 执行系统测试v 评估测试角色和职责v 测试主管v 测试组组长(测试计划文档,测试规范说明文档)v 测试分析员(负责设计和实现用于完成AUT测试的一个或多个测试脚本,协助组长生成测试规格说明文档)v 测试者(负责执行由测试分析员建立的测试脚本,并负责解释测试用例的结果并将结果录到文档中)测试阶段v 单元测试v 集成测试v 系统测试v 系统集成测试v 验收测试v 回归测试 二、单元测试单元测试就是对已实现的软件最小单元进行测试,以保证构成软件系统的各个单元的质量 单元测试应从各个层次来对单元内部算法、外部功能实现等进行检验,包括对程序代码的评审和通过运行单元程序来验证其功能特性等内容。 黑盒测试

11、白盒测试优点适用于各阶段测试从产品功能角度测试容易入手生成测试数 据可构成测试数据使特定程序部分得到测试有一定的充分性度量手段可获较多工具支持缺点某些代码得不到测试如果规格说明有误,则无法发现不易进行充分性测试不易生成测试数据(通常)无法对未实现规格说明的部分进行测试工作量大,通常只用于单元测试,有应用局限性质是一种确认技术,回答“我们在构造一个正确的系统吗”是一种验证技术,回答“我们在正确地构造一个系统吗?”驱动程序和桩程序 v 驱动程序(driver),对底层或子层模块进行(单元或集成)测试时所编制的调用被测模块的程序,用以模拟被测模块的上级模块 v 桩程序(stub),也有人称为存根程序

12、,对顶层或上层模块进行测试时,所编制的替代下层模块的程序,用以模拟被测模块工作过程中所调用的模块1.白盒测试:测试覆盖率:用于确定测试所执行到的覆盖项的百分比。其中的覆盖项是指作为测试基础的一个入口或属性,比如语句、分支、条件等测试覆盖率可以表示出测试的充分性,在测试分析报告中可以作为量化指标的依据,测试覆盖率越高效果越好。但覆盖率不是目标,只是一种手段v 测试覆盖率包括功能点覆盖率和结构覆盖率: 功能点覆盖率大致用于表示软件已经实现的功能与软件需要实现的功能之间的比例关系。 结构覆盖率包括语句覆盖率、分支覆盖率、循环覆盖率、路径覆盖率等等。逻辑覆盖法逻辑覆盖又可分为语句覆盖、判定覆盖、条件覆

13、盖、判定/条件覆盖、组合覆盖和路径覆盖 语句覆盖:选择足够多的测试用例,使得程序中的每个可执行语句至少执行一次。 判定覆盖:通过执行足够的测试用例,使得程序中的每个判定至少都获得一次“真”值和“假”值, 也就是使程序中的每个取“真”分支和取“假”分支至少均经历一次,也称为“分支覆盖”。 条件覆盖:设计足够多的测试用例,使得程序中每个判定包含的每个条件的可能取值(真/假)都至少满足一次。 判定/条件覆盖:设计足够多的测试用例,使得程序中每个判定包含的每个条件的所有情况(真/假)至少出现一次,并且每个判定本身的判定结果(真/假)也至少出现一次。 满足判定/条件覆盖的测试用例一定同时满足判定覆盖和条

14、件覆盖。 组合覆盖:通过执行足够的测试用例,使得程序中每个判定的所有可能的条件取值组合都至少出现一次。 满足组合覆盖的测试用例一定满足判定覆盖、条件覆盖和判定/条件覆盖。 路径覆盖:设计足够多的测试用例,要求覆盖程序中所有可能的路径。 测试覆盖准则v Foster的ESTCA覆盖准则:在容易发生问题的地方设计测试用例,即重视程序中谓词(条件判断)的取值。规则1 对于A rel B型 (rel可以是) 的分支谓词,应适当的选择A与B的值,使得测试执行到该分支语句时,AB的情况分别出现一次 这是为了检测逻辑符号写错的情况,如将“AB”。 规则2 对于A rel C型 (rel可以是或, A是变量,

15、C是常量)的分支谓词:当rel为时,应适当的选择A的值,使A=C+M。 这是为了检测“差1”之类的错误,如“A1”错写成“A0”。 规则3 对外部输入变量赋值,使其在每一个测试用例中均有不同的值与符号,并与同一组测试用例中其他变量的值与符号不同。 这是为了检测程序语句中的错误,如应该引用某一变量而错成引用另一个常量。基本路径测试方法在不能做到所有路径覆盖的前提下,如果某一程序的每一个独立路径都被测试过,那么可以认为程序中的每个语句都已经检验过了,即达到了语句覆盖。这种测试方法就是通常所说的基本路径测试方法控制流图计算环形复杂度的方法v V(G) = 区域数目 v V(G) = 边界数目 节点数

16、目 + 2 v V(G) = 判断节点数目 + 1v 独立路径是指程序中至少引入了一个新的处理语句集合或一个新条件的程序通路。采用流图的术语,即独立路径必须至少包含一条在本次定义路径之前不曾用过的边。循环测试方法测试简单循环。设其循环的最大次数为n ,可采用以下测试集: 跳过整个循环; 只循环一次; 只循环两次; 循环 m 次,其中mn; 分别循环 n-1、n 和 n+1 次测试嵌套循环。如果将简单循环的测试方法用于嵌套循环,可能的测试次数会随嵌套层数成几何级数增加。 此时可采用以下办法减少测试次数: 测试从最内层循环开始,所有外层循环次数设置为最小值; 对最内层循环按照简单循环的测试方法进行

17、; 由内向外进行下一个循环的测试,本层循环的所有外层循环仍取最小值,而由本层循环嵌套的循环取某些“典型”值; 重复上一步的过程,直到测试完所有循环。测试串接循环。若串接的各个循环相互独立,则可分别采用简单循环的测试方法;否则采用嵌套循环的测试方法。对于非结构循环这种情况,无法进行测试,需要按结构化程序设计的思想将程序结构化后,再进行测试。其它白盒测试方法程序插桩方法是借助往被测程序中插入操作,来实现测试目的的方法v 如果我们想要了解一个程序在某次运行中所有可执行语句被覆盖的情况,或是每个语句的实际执行次数,最好的办法是利用插桩技术。在程序中特定部位插入某些用以判断变量特性的语句,使得程序执行中

18、这些语句得以证实,从而使程序的运行特性得到证实。我们把插入的这些语句称为断言。Z路径覆盖下的循环测试方法在循环简化的思路下,循环与判定分支的效果是一样的,即:循环要么执行、要么跳过。域测试是一种基于程序结构的测试方法。 域测试正是在分析输入域的基础上,选择适当的测试点以后进行测试的符号测试的基本思想是允许程序的输入不仅仅是具体的数值数据,而且包括符号值,这一方法也因此而得名。 2.代码审查代码审查的目的就是为了产生合格的代码,检查源程序编码是否符合详细设计的编码规定,确保编码与设计的一致性和可追踪性 审查的内容 业务逻辑的审查 算法的效率 代码风格 编程规则 代码缺陷检查表把程序设计中可能发生

19、的各种缺陷进行分类,以每一类列举尽可能多的典型缺陷,形成代码缺陷检查表在不同的测试节点,测试的侧重点不同:在单元测试阶段,以代码检查、逻辑覆盖为主;在集成测试阶段,需要增加静态结构分析等;在系统测试阶段,应根据黑盒测试的结果,采取相应的白盒测试。3.单元测试工具种类 代码规则/风格检查工具 内存资源泄漏检查工具 代码覆盖率检查工具 代码性能检查工具静态测试工具和动态测试工具 静态测试工具不需要运行代码,而是直接对代码进行语法扫描和所定义的规则进行分析,找出不符合编码规范的地方,给出错误报告和警告信息。 动态测试工具则需要通过运行程序来检测程序,需要写测试脚本或测试代码来完成分支覆盖、条件覆盖或

20、基本路径覆盖的测试。三、 集成测试集成测试的模式非渐增式测试模式:先分别测试每个模块,再把所有模块按设计要求放在一起结合成所要的程序,如大棒模式。渐增式测试模式:把下一个要测试的模块同已经测试好的模块结合起来进行测试,测试完以后再把下一个应该测试的模块结合进来测试。驱动程序/驱动模块(driver),用以模拟被测模块的上级模块。驱动模块在集成测试中接受测试数据,把相关的数据传送给被测模块,启动被测模块,并打印出相应的结果。桩程序/桩模块(stub),也有人称为存根程序,用以模拟被测模块工作过程中所调用的模块。桩模块由被测模块调用,它们一般只进行很少的数据处理,例如打印入口和返回,以便于检验被测

21、模块与其下级模块的接口v 自顶向下集成测试v 自底向上集成测试v 混合策略四需求评审1、软件评审的方法与技术软件评审是对软件元素或者项目状态的一种评估手段,以确定其是否与计划的结果保持一致,并使其得到改进。 产品需求审查是软件开发重要环节之一,也是测试活动之一,即静态测试需求验证。借助需求审查保证用户需求在市场/产品需求文档及其相关文档中得到准确、完整、无歧义的反映,并使各类开发人员在需求理解上达成一致。技术评审文档评审管理(流程)评审评审的技术:检查表、场景分析、头脑风暴和工具等2、产品需求评审重要性测试人员在需求评审中作用测试人员主要起着评审员的作用,检查需求定义是否合理和清楚标准过程五、

22、测试计划1、测试计划的内容 确认测试目标、范围和需求 识别测试风险,制订相应的测试策略 对测试任务和工作量进行估算 确定所需的时间和资源 进度安排和资源分派,包括团队角色、责任和培训 测试阶段划分,包括阶段性任务和成果 跟踪和控制机制1)测试需求功能性测试需求主要是根据产品规格说明书来检验被测试的系统是否满足软件各方面的功能的使用要求,包括用户界面的友好性。非功能性质量需求,包括系统性能、安全性、兼容性、扩充性,其测试需求会因不同的项目类型差异较大。各个阶段测试任务需求分析审查设计审查单元测试集成测试功能测试系统测试验收测试版本发布维护测试范围分析如何通过测试的执行来满足测试的需求,这就需要分

23、析测试的范围、任务和其他条件,从而估算工作量和测试时间,安排测试进度和配置资源。 功能测试范围可以借助流程图和框图按功能层次分解,也可以按功能区域、功能逻辑进行分解 非功能性测试范围可以分别从性能测试、兼容性测试、适用性测试和安全性测试等各个方面进行分析2)工作量估计测试工作量是根据测试范围、策划任务和开发阶段来确定的,测试范围和测试任务是测试工作量估算的主要依据估算方法v 工作分解结构表方法测试工作量的估算依赖于测试任务的细化,对每项测试任务进行分解,然后根据分解的子任务进行估算。通常分解粒度越小,估算精度越高v 功能点方法、 对象点方法v 测试用例估算v 代码行预估v 历史数据推算(相似规

24、模、同类型)v 经验法 (资深人员或专家小组)v 综合方法3)资源安排和进度管理v 1 测试资源需求v 2 团队组建与培训v 3 测试进度管理4)测试风险的控制 风险识别的有效方法就是建立风险项目检查表控制风险的对策 v 消除执行风险v 降低进度风险v 减少人员风险5)测试策略的内涵测试策略描述当前测试项目的目标和所采用的测试方法,描述不同测试阶段的测试对象、范围和方法以及每个阶段内所要进行的测试类型,或者说是在一定的软件测试标准、测试规范的指导下,依据测试项目的特定环境约束而规定的软件测试的原则、方式、方法的集合。6)完整的测试计划书v 目标和范围:产品特性、质量目标、范围和限制v 项目估算

25、:工作量、资源的估算v 风险计划:风险分析、识别与回避/缓解对策v 进度安排:分解项目工作结构,指定时间/资源表v 资源配置:人员、硬件和软件等分配。v 跟踪和控制机制:质量保证、变更控制等六、设计验证1、设计审查测试人员参与设计评审保证需求能在设计中得到准确和完整的表示,也就是保证产品规格说明书的质量。 系统架构的审查 设计规格说明书的审查 系统部署设计的审查 多层次审查:high-level low-level 2、软件设计验证的需求v 软件运行和服务的设计验证需求:性能、安全性、可用性、功能性、可使用性v 软件部署和维护周期的设计验证需求:可修改性、可移植性、可复用性、可继承性、可测试性

26、v 与体系结构本质相关的验证需求:概念完整性、正确性、完备性和可构造性3、系统设计的评审标准4、系统架构设计的审查产品设计规格说明书的复审系统部署设计的审查七、功能测试(黑盒测试)功能测试一般采用黑盒测试方法黑盒测试被称为功能测试或数据驱动测试。不深入代码细节的测试方法称为动态黑盒测试。软件测试员充当客户来使用它。1、功能测试内容和方法v 内容 界面测试 数据测试 操作测试 逻辑测试 接口测试v 方法 全面理解功能特性􀂙 客户需求导向的思维方式􀂙 用例􀂙 工作流图/数据流图/UML charts􀂙 负面测试主要的功能测试方

27、法v 也就是黑盒测试用例设计方法 等价类划分法 边界值法 因果图法 决策表法 错误推测法 2、等价类划分法等价类划分法是把所有可能的输入数据,即程序的输入域划分为若干部分(子集),然后从每一个子集中选取少数具有代表性的数据作为测试用例有效等价类、无效等价类等价类的划分原则(1)按照区间划分 (2)按照数值划分 (3)按照数值集合划分 4)按照限制条件或规则划分 (5)细分等价类 等价类划分法的测试用例设计(1)首先为等价类表中的每一个等价类分别规定一个唯一的编号。(2)设计一个新的测试用例,使它能够尽量覆盖尚未覆盖的有效等价类。重复这个步骤,直到所有的有效等价类均被测试用例所覆盖。(3)设计一

28、个新的测试用例,使它仅覆盖一个尚未覆盖的无效等价类。重复这一步骤,直到所有的无效等价类均被测试用例所覆盖。v 针对是否对无效数据进行测试,可以将等价类测试分为 标准等价类测试和健壮等价类测试。v 标准等价类测试不考虑无效数据值,测试用例使用每个等价类中的一个值。v 健壮等价类测试主要的出发点是考虑了无效等价类。对有效输入,测试用例从每个有效等价类中取一个值;对无效输入,一个测试用例有一个无效值,其他值均取有效值。 健壮等价类测试存在两个问题: (1)需要花费精力定义无效测试用例的期望输出 (2)对强类型的语言没有必要考虑无效的输入 3、边界值分析法边界值分析法就是对输入或输出的边界值进行测试的

29、一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充,这种情况下,其测试用例来自等价类边界1、用边界值分析法设计测试用例(1) 每次保留程序中一个变量,让其余的变量取正常值,被保留的变量依次取min、min+、nom、max-和max。 (2) 对程序中的每个变量重复 (1) 。推论:对于一个含有n个变量的程序,采用边界值分析法测试程序会产生4n+1个测试用例。健壮性测试健壮性测试是作为边界值分析的一个简单的扩充,它除了对变量的5个边界值分析取值外,还需要增加一个略大于最大值(max+)以及略小于最小值(min-)的取值,检查超过极限值时系统的情况。因此,对于有n个变量的函数采用健壮性测试需要6n+1个测试用例。利用边界值作为测试数据边界值测试用例的设计思路字符起始-1个字符/结束+1个字符假设一个文本输入区域允许输入1个到255个 字符,输入1个和255个字符作为有效等价类;输入0个和256个字符作为无效等价类,这几个数值都属于边界条件值。数值最小值-1/最大值+1假设某软件的数据输入域要求输入5位的数据值,可以使用10000作为最小值、99999作为最大值;然后使用刚好小于5位和大于5位的数值来作为边界条件。空间小于空余空间一点/大于满空间一点例如在用U盘存储数据时,使用比剩余磁盘空间大一点(几KB)的文件作为边界条件。选择测试用例的原则(1)

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

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