软件测试就是一系列活动,这些活动是为了评估一个程序或软件系统的特征或能力,并确定其是否达到了预期结果。
软件测试和软件开发在整个软件开发生命周期中交互协作,自始至终在一起工作,共同致力于同一个目标。
SQA是一项管理工作,侧重于对流程的评审和监控
测试是一项技术性的工作,侧重对产品进行评估和验证
计算机系统或者程序中存在的任何一种破坏正常运行能力的问题、错误,或者隐藏功能缺陷、瑕疵,其结果会导致软件产品在某种程度上不能满足用户的需要。
5.1 按测试层次分类
底层测试:单元测试(Unit Testing)
接口层次:集成测试(Integration Tesing),完成系统内单元之间接口和单元集成为一个完整系统的测试。
系统层次:系统测试(System Testing)
用户层次:验收测试(Acceptance Testing, Beta Testing):验证是否是用户真正所需要的产品特性,验收测试关注用户环境、用户数据,而且用户也参与测试过程中。
5.2 按测试对象分类
单元测试,包括组件测试(Component Testing)、模块测试(Module testing)等。
程序测试
系统测试
文档测试,包括需求文档、设计文档、用户手册等。
web应用测试、客户端测试。
数据库测试、服务器测试。
5.3 按测试阶段分类
白盒测试,黑盒测试,单元测试,集成测试,系统测试(功能测试、性能测试),验收测试(α测试,β测试)。
5.4 按暴力程度
压力测试
冒烟测试
Logiscope RuleChecker: 根据工程中定义的编程规则自动检查软件代码错误,可直接定位错误。包含大量标准规则,用户也可定制创建规则。自动生成测试报告。
Logiscope Audit: 定位错误模块,可评估软件质量及复杂程度。提供代码的直观描述,自动生成软件文档。
Logiscope TestChecker: 测试覆盖分析,显示没有测试的代码路径,基于源码结构分析。直接反馈测试效率和测试进度,协助进行衰退测试。既可在主机上测试,也可在目标板上测试。支持不同的实时操作系统、支持多线程。可累积合并多次测试结果,自动鉴别低效测试和衰退测试。自动生成定制报告和文档。
Logiscope对代码分别进行静态度量、编程风格检测、和测试覆盖率分析。
评审是对软件元素或者项目状态的一种评估手段,已确定其是否与计划的结果保持一致,并使其得到改进。检查工作产品是否正确地满足了以往工作产品中建立的规范,如需要或设计文档是否符合所定义的模板要求,各项内容是否清除、一致。
互为评审(Peer Review): 同行间互相检查。
走查(Walk-through): 由他人从头到尾进行检查。
会议评审(Inspection): 最正式的集体审查形式,由主持人、作者和相关人员、项目干系人等共同参与,经过一系列准备工作,开会确定存在的各种问题,并事后跟踪、解决问题。
9.1 静态测试
包括对软件产品的需求和设计规格说明书的评审、对程序代码的审查以及静态分析等。Logiscope,findbugs。
9.2 动态测试
通过真正的运行程序发现错误,通过观察代码运行过程,来获取系统行为、变量实时结果、内存、堆栈、线程以及测试覆盖度等各方面来判断系统是否存在问题,或者通过有效的测试用例,对应的输入输出关系来发现缺陷。
9.3 主动测试
测试人员主动向被测试对象发送请求、或借助数据、时间驱动被测试对象的行为,从而验证被测试对象的反应或输出结果。
9.4 被动测试
软件产品运行在实际环境中,测试人员不干预产品的运行,而是被动地监控产品的运行,通过一定的被动机制来获得系统运行的数据,包括输入输出数据。
int a, b ; float c ; scanf(“%d%d%f”, &a, &b, &c); if (a >0 && b > 0) c = c / a ; if (a > 1 || c > 1) c = c + 1 ; c = b + c ; Printf(“%d, %d, %f\n”,a, b, c);
10.1 语句覆盖
度量被测代码中每个可执行语句是否被执行到了。
测试用例 | 具体取值条件 | 覆盖语句 | 覆盖路径 |
输入:a=2,b=1, c =2 输出:a=2, b=1, c=4 | a>0,b>0 a>1,c>1 | c=c/a c=c+1 | P(1-2-4) |
10.2 判定覆盖
使得每个判断的取真分支和取假分支至少经历一次。一个判定往往代表程序的一个分支,所以判定覆盖也被称为分支覆盖。
每个判断的整体取真假。
测试用例 | 具体取值条件 | 判定覆盖 | 覆盖路径 |
输入:a=2,b=1, c =2 输出:a=2, b=1, c=4 | a>0,b>0 a>1,c>1 | M=.T. N=.T. | P(1-2-4) |
10.3 条件覆盖
使每个判断中的每个条件的可能取值至少满足一次。
测试用例 | 具体取值条件 | 覆盖判定 | 覆盖条件 | 覆盖路径 |
输入:a=2,b=1, c =2 输出:a=2, b=1, c=4 | a>0,b>0 a>1,c>1 | M=.T. N=.T. | T1,T2,T3,F4 | P(1-2-4) |
10.4 判定-条件覆盖
判定-条件覆盖是判定和条件覆盖设计方法的交集,即设计足够的测试用例,得使判断中每个条件的所有可能取值至少执行一次,同时每个判断本身所有可能结果也至少执行一次。
缺点:忽略了条件的组合情况。
10.5 条件组合覆盖
设计足够的测试用例,使得判断中每个条件的所有可能至少出现一次,并且每个判断本身的判定结果也至少出现一次。
与判定-条件覆盖对比:解决了判定-条件覆盖的不足,差别是它不是简单的要求每个条件都出先“真”与“假”两种结果,而是要求让这些结果的所有的可能的组合都至少出现一次。
缺点:有冗余的测试用例,可能会丢失路径。
10.6 基本路径覆盖
设计足够的测试用例,来覆盖程序中的所有可能的、独立的执行路径。
缺点:不能保证覆盖所有的条件组合;需要设计大量、复杂的测试用例,使得工作量呈指数级增长。
11.1 等价类划分法
用一组有限的数据去代表近似无限的数据。解决了如何选择适当的数据子集来代表整个数据集的问题,通过降低测试的树木实现“合理的”覆盖。
有效等价类:输入完全满足程序输入的规格说明、有意义的输入数据所构成的集合,利用有效等价类可以检验程序是否满足规格说明所规定的功能和特性。
无效等价类:和有效等价类相反,即不满足程序输入要求或者无效的输入数据构成的集合。使用无效等价类,可以测试程序/系统的容错性(对一场输入情况的处理)。
11.2 边界值分析法
在某个输入输出变量范围的边界上,验证系统功能是否正常运行的测试方法。
11.3 判定表方法
借助表格方式完成对输入条件的组合设计,以达到完全组合覆盖的测试效果。一个判定表由“条件和活动”(条件作为输入,活动作为输出)两部分组成,也就是列出了一个测试活动执行所需的条件组合,所有可能的条件组合定义了一系列的选择,而测试活动需要考虑每一个选择。
判定表制定步骤:
列出所有的条件桩和动作桩
填入条件项
填入动作项,指定初始化判定表
简化、合并想死规则或者相同动作
判定表的5个概念
条件桩:列出问题的所有条件,如打印机—驱动程序、纸张、墨粉等、
动作桩:列出可能针对问题所采取的的操作,如打印正确内容、打印错误内容、不打印内容等。
条件项:针对所列条件的具体赋值,即每个条件可以取真值或假值。
动作项:列出在条件项(各种取值)组合情况下应该采取的动作。
规则:任何一个条件组合的特定取值及其相应要执行的操作。在判定表中贯穿条件项和动作项的一列就是一条规则。
11.4 因果图法(Cause-effect Diagram)
借助图形,着重分析输入条件的各种组合,每种组合条件就是“因”,它必然有一个输出的结果,这就是“果”。
设计方法:
分析软件规格说明文档描述的哪些是原因(输入条件),哪些是结果(输出条件),给每个原因和结果赋予一个标示符。
找出原因与结果,原因与原因之间的对应关系,划出因果图
在因果图上标上哪些不可能发生的因果关系,表明约束或限制条件
根据因果图,创建判定表,将复杂的逻辑关系和多种条件组合很具体明确的表示出来
把判定表的每一行作为依据设计测试用例。
11.5 正交试验法
解决组合数非常大的问题,正交实验设计方法(Orthogonal Test Design Method,OTDM)是依据Galois理论,从大量的(实验)数据(测试例)中挑选适量的、有代表性的点(条件组合),从而合理地安排实验的一种科学实验设计方法。
常用正交表:
两水平:L4(23)、L8(27)、L12(211)
三水平:L9(34)、L27(213)
四水平:L16(43)
混合水平:L8(41X24)、L16(41X212)、L16(41X29)、L16(43X23)、L16(36X61)
11.6 功能图法
11.7 错误推断法:
有经验的测试人员往往可以根据自己的工作经验和直觉推测出程序可能存在的错误,从而有针对性的进行测试,这就是错误推断法。
责任感
沟通能力
技术能力
自信心
耐心
怀疑精神
适度的好奇心
洞察力
反向思维和发散思维能力
记忆力
传统模型:瀑布模型(V模型),W模型,TMAP
V模型:又称为瀑布模型,是一种普遍的软件开发模式,旨在改进软件开发的效果和效率,反映出测试活动与分析设计活动的关系。指出,单元和集成测试应检测程序的执行是否满足软件设计的要求;系统测试应测试系统功能,性能的质量特性是否达到系统要求的指标,验收测试确定软件的实现是否满足用户需要或合同的要求。每个测试环节都是按照步骤来进行的,一种测试完毕后,才能开始下一种测试。此模型的实用性不高,而且如果后期发现问题,修复成本很大
W模型:是由两个V字型模型组成,分布代表测试与开发过程,测试与开发是同步进行的,有利于今早地全面发现问题,需求,设计,编码等活动被视为串行的,测试和开发活动保持着一种线性的前后关系,无法支持迭代的开发模型。
H模型下:的测试是一个独立的流程,贯穿产品整个生命周期,与其他流程并发地进行,不同的测试活动可以是按照某个次序先后进行的,只要某个测试达到准备就绪点,执行测试就开始进行,具有很强的灵活性。
Tmap:是一种业务驱动的,基于一种业务驱动的,基于风险策略的,结构化的测试体系,讲述如何建立一个测试策略,建立测试过程,编制测试计划,测试用例。T
TMap三基石: O、I、T,支持整个生命周期L,从而构成其稳固的方法体系。
坚实的组织融合(O)
正确的基础设施和工具(I)
可用的技术(T)
分析学派:认为软件测试具有严格的技术性,可进行分析和建模
标准学派:用于衡量进度的一种方式,强调成本度量和安全性的标准
质量学派:确定开发人员是否遵守规范,测试人员扮演质量的守门员角色
上下文驱动学派;强调人的作用,寻找另一相关的bug认为测试是bug的分支
敏捷学派:测试是用户角色的部分,用软件测试实验证开发是否完成,强调测试的自动化
检验各单元模块是否被正确的编码,即验证代码和软件系统设计的一致性是单元测试的主要目标,还需要确保代码在结构上可靠且简装,能够在各种条件下给与正确的响应。
驱动程序:用以模拟被测模块的上级模块,能够调用被测模块。测试过程中,驱动程序接收测试数据,调用被测模块并把相关的数据传送给被测模块。
桩程序:用以模拟被测模块工作 过程中所调用的下层模块,桩程序由被测模块调用。
集成测试是将已分别通过测试的单元按设计要求集成起来再进行的测试,以检查这些单元之间的接口是否存在问题,包括接口参数的一致性引用、业务流程端到端的正确性等。
自顶向下:从主控模块(主程序)开始,沿着软件的控制层次向下移动,从而逐渐把各个模块结合起来。
自底向上:从“原子”模块开始,集成以进行测试。
将经过集成测试过后的软件,作为计算机系统的一个部分,与计算机硬件、某些支持软件、数据和平台等系统元素结合起来,在真实运行环境下对计算机系统进行一系列的严格有效的测试来发现软件的潜在问题。
功能测试:根据产品规格说明书,来检验被测试的系统是否满足各方面功能的使用要求。功能测试也包括部分的系统安全性测试,如用户登录、授权等功能测试,而且需要针对不同的环境进行测试,一方面可以看作是系统环境的兼容性测试,另一方面可以看作不同配置下的功能测试。
性能测试:为了发现系统性能问题或获取系统性能相关指标(如运行速度、响应时间、资源利用率)而进行的测试。
回归测试:指修改了旧代码后,重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。
安全测试:全面检验软件在需求规格说明书中规定的防止危险状态措施的有效性和在每一个危险状态下的反应,对软件设计中用于提高安全性的结构、算法、容错、冗余、中断处理等方案进行针对性测试,并对安全性关键的软件单元和软件部件,单独进行加强的测试,已确认其满足安全性要求。
验收测试:在软件产品完成了功能测试和系统测试之后,在产品发布之前所进行的软件测试活动。。
ɑ测试:由一个用户在开发环境下的测试,也可以开发机构内部用户在模拟实际操作环境下的测试。α测试的目的是评价软件产品的FLURPS(即功能、本地化、可使用性、可靠性、性能和支持)。
ß测试:由软件的多个用户在一个或多个用户的时机使用环境下进行的测试。与α测试不同额是,开发者通常不在测试现场。
软件本地化:是将一个软件产品按特定的国家或语言市场的需要进行全面定制的过程,包括翻译、重新设计、功能调整以及功能测试、是否符合各个地方的风俗、文化背景、语言和方言的验证等。
软件国际化:意味着对软件“原始产品”本地化的支持,也就是为了解决软件能在各种不同语言、不同风俗的国家和地区使用的问题,对计算机是和编程做出的某些规定。
自动化测试:是相对手工测试而存在的一个概念,主要是通过所开发的软件进行测试工具,脚本来实现,具有良好的可操作性、可重复性和高效率等特点。
自动化测试的优势:提高测试效率、覆盖率和可靠性。
自动运行的速度快、执行效率高,是手工无法比的。
用不疲劳。
测试结果准确。
可靠。
可复用性。
特别的能力。测试手工测试不到的地方,如对网站进行负载测试,点击1w次。
脚本技术:是一组测试工具执行的指令集合,也是计算机程序的一种形式。可以通过录制测试的操作产生,然后再做修改,这样可以减少脚本开发的工作量。可以包含
同步
比较信息
捕获何种屏幕数据及存储在何处
从另一个数据源读取数据时从何处读取
控制信息等
产品规格说明书是测试的标准,是基于需求的定义,详细描述将要开发出一个怎么样的产品,包括产品的用途、有哪些功能、用户界面的表现形式及其交互特性等。
作者:real慕华
原文链接:https://blog.csdn.net/weixin_42132763/article/details/92803852