软件测试理论.docx
《软件测试理论.docx》由会员分享,可在线阅读,更多相关《软件测试理论.docx(25页珍藏版)》请在冰豆网上搜索。
![软件测试理论.docx](https://file1.bdocx.com/fileroot1/2023-6/19/b8b927cc-62c5-4268-b4f6-5fe8fec7d469/b8b927cc-62c5-4268-b4f6-5fe8fec7d4691.gif)
软件测试理论
Forpersonaluseonlyinstudyandresearch;notforcommercialuse
软件测试理论篇
一、为什么软件要做软件测试
纵观历史事件说明软件测试的重要性
二、软件测试的概念
1、测试是为了发现错误而执行程序的过程;
2、在规定条件下,对程序进行操作,以发现错误,以软件质量进行评估;
3、使用人工或者自动化手段,来运行或者测试某个子系统的过程,其目的在于检查它是否存在满足规定需求或弄清预期结果与实际结果之间的差别(IEEE:
美国电气和电子工程师协会);
正向思维:
验证软件的正常工作
评价一个程序或系统的特性或能力并确定是否达到预期的结果。
在设计规定的环境下运行软件的所有功能,直至全部通过。
逆向思维:
假设软件有缺陷
测试是为了发现错误而针对某个程序或系统的执行过程;
寻找容易犯错地方和系统薄弱环节,试图破坏系统直至找不出问题;
三、软件测试的原则
1、所有软件测试都要追溯到客户需求;
客户、产品、业务
2、应当把“尽早地和不断地的进行软件测试”作为软件测试者的座右铭;
尽早地:
需求分析以后并且经过评审
不断地:
5轮测试,3轮测试
3、完全测试是不可能的,测试需要终止;
避免穷举
4、测试除了检查程序是否做了“应该做的”还应该检查是否“做了不应该做的’’;
5、严格执行测试计划,尽量避免测试的随意性
测试是一个有组织、有计划、有步骤的一个活动
6、杀虫剂现象
缺陷会具有抗药性
组内互测。
新人测试。
7、用例包含合理和不合理的输入条件
测试用例testcase
8、充分注意测试中的集群现象
发现错误数目多的模块,往往意味着残留在该模块的缺陷会更多。
软件测试的2/8原则
i、80%的缺陷产生于20%的模块;
ii、80%的测试效果取决于20%的测试工作;
iii、修复了20%的缺陷,可以带来客户80%的满意度;
9、程序员应避免检查自己的程序
一方面,自己是不愿意承认自己错误;
另一方面,由于思维定式开发人员很难发现自己的问题;
10、妥善保存一切测试过程文档
测试的效果往往要依赖文档来体现。
四、软件测试的目的及对象
1、软件测试是程序的执行过程,目的在于发现错误;
2、测试是为了证明程序有错,而不是证明程序无错误;
3、一个好的测试用例在于它能发现至今未发现的错误;
4、一个成功的测试是发现至今未发现的错误的测试;
软件测试的最终目的是确保给用户的软件产品符合用户的要求。
软件测试对象:
软件=程序+数据+文档
五、测试和调试的区别
调试是建设性的
测试是破坏性的
1、人员的不同:
通常来说,测试人员是测试工程师,调试人员是是程序员
2、目的不同:
测试的目的之一是发现软件店中的缺陷。
而调试的主要目的是为了定位和修改软件中的缺陷;
3、过程不同:
测试是从已知的条件开始,使用预先定义的过程,并且有预期的结果,并且有与之的结果。
调试是从未知的条件开始,结束的过程可能不可预计
4、计划不同:
测试可以计划,可以预先制定测试用例和过程。
工作进度可以度量。
调试的过程或持续时间相对比较困难
5、对象不同:
测试的对象包括软件开发过程中的程序、数据、文档,而调试的对象一般来说只有代码;
六、测试的风险
1、进度风险:
测试的周期短而造成测试覆盖不全面;
开发不能按时交付版本,导致测试周期缩短;
2、人员风险
测试人员不足影响测试进度:
请假、调岗、离职(核心人员)
测试人员经验不足,技能不够、业务不熟。
3、质量风险
质量的标准不统一,某些缺陷的严重等级不一致;
4、成本风险
人力和物力
5、变更风险
需求变更
七、测试工程师应该具备的技能
1、计算机相关的知识,能够熟练使用常用的管理工具
Bugfree、禅道、bugzilla、mantis、testlink、JIRA、QC(HP)QC(11.5版本后叫ALM)应用程序管理工具
2、软件基础知识:
软件工程,软件生命周期、测试理论和测试方式有较深的理解;
3、软件测试技术,方法,流程,测试文档编写,能独立设计和执行测试用例,提交完整的缺陷报告单,编写测试报告。
4、计算机开发语言C,C++,java,JavaScript,VBScript,shell;
C面向过程
Java面向对象、跨平台
JavaScriptVBScriptpython脚本语言
5、数据库SQLServer,Oracle,MySQL等数据库知识
Oracle(甲骨文)、MySQL、SQLServer、DB2
6、操作系统linux、windows、UNIX、MAC等
7、网络基础知识,能够独立完成测试环境的搭建;
8、测试工具,能够熟练使用至少一种功能/性能自动化测试工具;
自动化工具:
QTP(HP)QTP11.5改名为:
UFT
WinRunnerSelenium:
支持Java、perl、python
性能工具:
LoadRunner(LR)HP—c语言类c、QAload、Jmeter
9、质量管理知识,如CMM,CMMI以及ISO9001;
10、学好一门或者多门外语;
八、测试工程师具备的素质
1、三心:
责任心、耐心、细心
2、二力:
沟通能力、洞察力
3、一个精神:
团队精神
九、测试工程师的职责
1、配置测试环境
2、编写测试计划
3、设计测试用例
4、执行软件测试
5、提交软件缺陷
6、编写缺陷报告
7、验证修正的缺陷
软件研发过程
一、软件研发的模型
I、瀑布模型:
是一种线性的、顺序的软件的开发模型
三个阶段:
定义阶段、开发阶段、维护阶段
瀑布模型的特点:
1、线性化模型结构;2、各个阶段具有里程碑式特征
3、基于文档的驱动;4、严格的阶段评审机制
优点:
提供了软件开发的基本框架,
缺点:
初始阶段指出了全部需求,不方便修改;流程不可逆
II、V模型
用户需求✍需求分析✍概要设计✍详细设计✍编码
单元测试✍集成测试✍系统测试✍验收测试
V模型的优点:
1、明确了测试过程中存在的不同级别;
2、说明了测试和开发的对应关系;
3、v模型的测试策略包含了低层测试(代码测试)又包含了高层测试(需求测试)
V模型的缺点:
1、它仅仅把测试过程作为需求分析,概要设计,详细设计编码之后的一个阶段,容易让人理解为测试是软件开发的最后一个阶段
2、没有明确说明早期的测试,不符合尽早测试和不断地进行测试的原则(用户需求对不对要到验收测试才能发现)。
3、和瀑布模型一样,流程单一不可逆;
III、W模型
W模型的优点:
1、符合尽早测试和不断测试的原则
2、符合实际工作中的测试要求
W模型的缺点:
无法迭代,不可逆
X模型:
X模型提出了探索测试的概念(边设计用例,边测试)。
H模型
螺旋模型:
明确风险和化解风险
原型范型:
问题:
开发初期很难确定用户需求规格
解决:
用户与开发者之间的鸿沟
敏捷开发:
以人为核心,适应变化,迭代,循序渐进的开发方法
敏捷开发的理念:
1、个体和交互,胜过过程和工具
2、可以工作的软件,胜过面面俱到的文档
3、客户合作,胜过合同谈判
4、响应变化,胜过遵循计划
二、软件的生命周期
需求✍设计✍编码✍测试✍维护✍升级✍废弃
SPEC产品需求规格说明书
三、软件的测试流程
需求分析✍测试计划✍测试用例✍测试执行✍测试报告
四、软件项目组的成员
项目经理:
(PM)
架构师:
程序员:
测试工程师:
资料工程师:
配置管理员:
质量监管员:
(QA)
技术顾问:
数据库专家:
软件测试分类
一、按阶段划分
单元测试(unittesting):
是指对软件中最小可测试单元进行检查和验证。
I、对于单元测试中的单元的含义,一般来说,要根据实际情况去判断其具体含义,如c语言中单元指一个函数,Java里面指一个类,图形化软件中指一个窗口或者菜单等
II、总的来说,单元就是指人为规定的最小被测功能模块。
单元测试是在软件开发过程中要进行的最低级的测试活动,软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。
III、单元测试包含的内容如下:
入口和出口函数
输入和输出信息
错误处理信息
部分边界数值测试
集成测试(Integrationtesting),也叫组装测试或者联合测试。
在单元测试的基础上,将所有模块按照设计要求(如根据结构图)组装成子系统或者系统,进行集成测试(集成测试测的是接口)
实践表明,一些模块虽然能够单独地工作,但是并不能保证连接起来也能正常工作,程序在某些局部反映不出来的问题,在全局上很可能暴露出来,影响功能的实现
集成测试的方法:
I、非增量式集成(一次性集成)
优点:
集成速度快;
缺点:
集成的难度大,同时一旦某个模块出现问题。
很难定位问题和修改
II、增量式集成:
自顶而下增量式测试桩程序;
自底而上增量式测试驱动程序;
确认测试:
目的是向未来的用户表明系统能够像预期要求的那样工作。
进过集成测试后,已经按照设计把所有的模块组装成一个完整的软件系统,接口错误也已经基本排除了,接着就应该进一步验证软件的有效性这就是确认测试的任务,即软件的功能和性能如同用户所合理期待的那样。
系统测试(Systemtesting)将确认的软件、计算机硬件、外设、网络等其他元索结合在一起,进行信息系统的各种组装测试和确认测试
系统测试是针对整个产品系统进行测试
目地是验证系统是否符合满足了需求规格的定义,找出与需求不符合或者与之矛盾的地方,从而提出更加完善的方案
系统测试发现问题之后要经过调试找出错误的原因和位置,然后进行改正,是基于系统整体需求说明书的黑盒测试,应该覆盖系统所有联合部件
测试对象不仅仅包括测试的软件还包括软件依赖的硬件、外设甚至包括某些数据、某些支持软件及接口等
测试范围:
功能测试(functionaltesting):
验证软件是否符合《需求规格说明书》包含的功能;
性能测试(performancetesting):
检查系统运行时的各项性能指标(CPU、内存、网络、响应时间、点击率、吞吐量、用户并发数);
负载测试(loadtesting):
性能测试的一种,不断给系统施加压力的过程,来判断系统的承受能力;
压力测试(stresstesting):
又称为强度测试,也是性能测试的一种,不断给系统施加压力,在饱和的状态下,再持续一段时间,来测试系统的最大承受能力
稳定性测试(stabilitytesting):
主要测试系统在一段时间内是否正常运行(7*24H、3*24H)
兼容性测试(compatibilitytesting):
硬件兼容(整机兼容和外设兼容)、软件兼容(操作系统兼容{windows、UNIX、LINUX、MAC}、不同版本之间的兼容性{}、浏览器兼容性{IE、Chrome、FireFOx、opera、Safari}、数据库兼容{Oracle、MySQL、SQLServer、DB2}、与其他软件中间件的兼容)
容量测试(volumetesting):
面向数据的测试,测试系统最大限度处理数据的能力;
数据备份测试(backuptesting):
验证程序失效是,备份数据的能力,自动备份和手工备份;
失效恢复测试(recoverytesting):
系统从软件或者硬件中恢复的能力,强调系统在发生失效时,必须在一定的时间范围内可以恢复成功,同时可以继续运行。
可用性测试(usabilitytesting):
主要测试用户在理解和使用系统的时候是否方便;
健壮性测试(robustnesstesting):
又叫容错性测试,系统出现故障时候可以恢复,忽略故障是否可以继续运行;
安装测试(installationtesting):
是否可以安装、是否可以选择正确路径来安装、可以在不同系统上安装、安装过程中断后,是否可以继续安装、安装过程中是否有良好的错误提示信息、再次安装、取消安装、卸载(有无残留文件)、更新版本、修复
配置测试(configurationtesting):
主要针对硬件,测试软件在一定的硬件配置下是否出现问题,大体包括:
pc、组件、外设、接口、驱动;
文档测试(documentationtesting):
《帮助文档》《使用手册》等,主要验证用户使用文档是否正确、和保证操作手册的过程能欧冠正常工作;
在线帮助测试(onlinehelptesting):
主要测试的是给用户提供的实时的资讯服务的可操作性和准确性;
GUI测试(graphicaluserinterface)图形用户接口测试,主要测试的是前端的展示内容:
菜单、按键、对话框;
安全测试(securitytesting):
主要测试具备非法或者非正常途径访问被测试系统,系统可以提供的保护和防御的机制;
验收测试:
确定产品是否能够满足合同或用户所规定需求的测试,这是管理性和防御性控制
主要确认软件是否按照合同要求进行工作,既满足软件需求规格说明书中的要求。
验收测试的方法:
I、非正式的验收测试
а测试:
软件开发公司组织内部人员模拟各类用户行为对即将上市的产品进行测试
开发和测试人员在场,测试可控
?
测试(Beta):
软件开发公司组织各方面的的典型客户在日常工作中实际使用,并要求用户报告异常情况、提出改进意见,然后公司再进行完善。
开发和测试人员不在场,测试不可控
II、正式的验收测试
有正规的测试过程,需要制定测试计划、定义测试方案、选择测试用例,进行测试,结果提交。
着重考虑软件是否满足合同规定的所有功能和性能,文档资料是否完整、准确,人机界面和其他方面。
二、按照是否运行程序划分
静态测试
不运行被测试的软件,而只是静态地检查代码、界面或者文档
方式名称
执行人员
检查内容
检查过程
桌面检查
程序员
对源程序代码进行分析、检验,并补充相关的文档,发现程序中的错误
代码审查
程序员和测试员组成的检查小组
通过阅读、讨论和争议,以程序进行静态分析的过程
第一步:
小组成员提前阅读设计规格书、程序文本等相关文档
第二步:
召开程序审查会,开发人员读程序,审查小组讨论、发现、解决问题
走查
程序员和测试员组成的审查小组
通过逻辑运行程序,发现问题
第一步:
小组成员提前阅读设计规格书、程序文本等相关文档
第二步:
利用测试用例,使程序逻辑运行,记录程序的踪迹,发现、讨论、解决问题
动态测试
实际运行被测试的软件,输入相应的测试数据,检查实际的输出结果是否和预期结果相一致的过程。
三、按照是否查看代码划分
黑盒测试:
把软件看成一个黑盒子,不管内部逻辑和内部特性,只依据规格说明书检查程序的功能是否符合功能说明,又称为功能测试或数据驱动测试
白盒测试:
又称为结构测试或逻辑驱动测试。
着重于程序内部结构和算法,不关心功能和性能指标
灰盒测试:
介于白盒和黑盒测试之间,基于程序运行时刻的外部表现同时又结合程序内部逻辑结构来设计用例,执行程序并采集程序路径执行信息和外部用户接口结果的测试技术。
四、其他划分
回归测试:
对软件新版本测试时,重复执行上一版本使用过的测试用例
在项目周期很紧张的时候,如何开展回归测试?
第一:
验证开发人员已经修复的缺陷;
第二:
测试用例优先级别高的测试用例;(主要的功能)
第三:
验证有关联的模块;
第四:
验证经常出现问题的模块;(2-8原则)
冒烟测试:
冒烟测试的对象是每一个新编译需要正式测试的版本,目的是确认软件的基本功能正常,可以进行后续的正式测试工作。
随机测试(猴子测试):
测试数据是随机产生的,在测试用例之外,只能作为测试的补充。
敏捷测试(敏捷开发引发):
TDD(测试驱动开发):
软件质量
软件质量:
软件特性的总和,软件满足规定或潜在用户需求的能力。
软件质量包括:
内部质量:
软件内部设计和结构;
外部质量:
软件外部功能和性能等的体现;
过程质量:
软件生产流程是否合理;
使用质量:
在使用过程中的用户满意度和易用性的表现;
软件质量的六大特性:
功能性:
当软件在指定条件下使用时,软件产品提供满足明确和隐含要求的功能的能力
明确的(显性的需求)隐含的(隐形的需求)
适合性:
软件为指定任务和用户目标,提供了一组合适功能的能力
准确性:
软件系统提供给用户的功能是否满足用户对该功能的精确度要求
互操作性:
软件系统和一个或多个周边系统进行信息交互的能力
保密安全性:
软件系统保护信息和数据的能力;
Ⅰ、防止未得到授权的人或系统访问相关的信息或数据;
Ⅱ、保证得到授权的人或系统能正常访问相关的信息或数据;
不同的系统对于安全性的需求差别很大
常见的安全性测试:
1、户验证:
登录密码验证、IP地址访问限制等
2、用户权限管理:
验证低级别用户是否具有了高级别用户的权限,各级别用户权限都得到了实现。
3、统数据的保护:
对例如系统文件、用户密码文件等进行隐藏、密码验证、内容加密、备份
4、防DOS攻击(拒绝服务)
5、加密、解密:
在计算机通讯中,采用密码技术将信息隐蔽起来,再将隐蔽后的信息传输出去,使信息在传输过程中即使被窃取或截获,窃取者也不能了解信息的内容,从而保证信息传输的安全
功能性的依从性:
遵循相关的标准(国际标准、国家标准、行业标准、企业内部规范等)约定或法规以及类似规定的能力
可靠性:
在特定条件下使用时,软件产品维持性能级别的能力;
成熟性:
软件为避免由软件中的错误而导致软件失效的能力
容错性:
软件出现故障或者违反了制定接口的情况,软件规定了维护性能级别的能力
易恢复性:
系统失效以后恢复原有功能和性能的能力
1原有能力恢复的程度
2原有能力恢复的速度
易用性:
在指定条件下使用,软件产品被理解、学习、使用和吸引用户的能力
易理解:
用户在使用软件系统的过程中,系统交互给用户的信息是否准确、清晰、易懂,能帮助,用户准确理解系统当前真实的状态,指导其进一步的操作。
易学性:
软件系统提供相关的辅助手段,帮助用户学习使用它的能力。
易操作性:
软件使用户能操作和控制它的能力。
效率:
时间效率:
系统在各业务场景下完成用户指定的业务请求所需的响应时间
资源效率:
系统在各业务场景下完成用户指定的业务请求所消耗的系统资源。
如CPU使用率、内存使用率、IO,通信带宽使用等
效率的依从性:
维护性:
易分析性:
是指软件产品诊断软件中的缺陷或失效原因,以及判定待修改的部分的能力。
易改变性:
是指软件产品使指定的修改可以被实现的能力
稳定性:
是指软件产品避免由于软件修改而造成意外结果的能力。
易测试性:
是指软件产品使已修改软件能被确认的能力
可移植性:
适应性:
软件系统无需做任何相应变动就能适应不同运行环境
易安装性:
易安装性,是指软件产品在指定环境中被安装的能力
共存性:
软件系统和在公共环境与其共享资源的其他系统共存的能力
易替换性:
是指软件产品在环境相同、目的相同的情况下替代另一个指定软件产品的能力。
可移植性的依从性:
遵循相关的标准(国际标准、国家标准、行业标准、企业内部规范等)约定或法规以及类似规定的能力。
QA即英文QUALITYASSURANCE的简称,中文意思是质量保证
QC即英文QUALITYCONTROL的简称,中文意义是质量控制
QC和QA的主要区别:
前者是保证产品质量符合规定,后者是建立体系并确保体系按要求运作,以提供内外部的信任
QC就是测试人员,职责是尽可能早地发现软件的缺陷,并确保缺陷得到修复
QA是流程的监督者,职责是创建和执行改进软件开发过程,并防止软件缺陷发生的标准和方法
ISO:
国际标准化组织.iso表示光盘的镜像文件
OSI:
开放系统互联
IOS:
苹果系统
CMMI:
CapabilityMaturityModelIntegration(能力成熟度模型综合)
5个成熟度等级分别为:
第1级:
初始级
第2级:
受管理级
第3级:
已定义级
第4级:
定量管理级
第5级:
持续优化级
需求分析
一、测试需求:
测试需求主要解决“测什么”的问题,即指明被测试对象中什么需要测试
测试需求通常是以软件开发
测试需求的特征:
1、制定的测试需求项必须是可核实的(可量化);
2、测试需求应指明满足需求的正常的前置条件,同时也要指明不满足需求的是的出错条件(包含差错条件);
3、测试需求不涉及具体的测试数据(不涉及测试数据);
测试需求分析过程
需求采集:
《需求规格说明书》
需求分析:
测试要点分析、功能交互分析、质量特性分析、测试
需求评审:
二、测试计划
1、为什么要编写测试计划?
避免测试的随意性
上:
PM、QA、产品经理、开发经理、测试经理
中:
测试组长、销售人员
下:
开发人员、测试人员
2、什么时间编写测试计划
需求分析之后,在整个测试工作过程中,不断修改
3、由谁来编写测试计划
具有丰富经验的项目测试负责人
如何制定好测试计划
认真做好测试资料的搜集整理工作;
《项目计划》、《版本计划》
明确测试目标,增强测试计划的实用性
坚持测试的“5W”原则,明确内容和过程
5W:
why:
为什么要进行这些测试
what:
测试哪些方面,不同阶段的工作内容
where:
相关文档,缺陷的存在位置,测试环境等
when:
测试不同阶段的起止时间
who:
项目有关人员组成,安排哪些测试人员进行测试
测试的开始和结束条件
开始条件:
软件测试在项目启动、需求分析开始时随之启动
结束条件:
需求覆盖率(100%)、用例执行率(100%)、缺陷遗留率(2-5%)
、达到预期的质量目标
三、测试计划模板
DRAFT:
初稿
MODIFY:
修改版
RELEASE:
终稿
测试用例设计testcase
一、软件测试用例包含哪些部分
1、用例编号(用例ID)
项目名+模块名+编码(唯一标识)
美萍酒店管理系统_营销管理_001
2、功能接口
一级模块+二级模块
营销管理_VIP会员管理
3、用例标题(用例名称)
见名知意
(在哪里+操作+结果)
(地点+动作+)
QQ登录界面用户名和密码匹配一致登录成功
学生信息系统输入部分非法信息登录失败
注意事项:
(1)、要简洁(≤24个字)
(2)、不能出现句号
(3)、不能有两个以上的逗号
(4)、名称不能重复:
不能出现两个或者以上完全一样的用例标题。
(5)、不能写成缺陷(缺陷表示一个错误,用例描述的是一种情况)。
4、优先级
高、中、低
高:
基本的、重要的功能。
中:
错误的、边界的、配置的
低:
低级别不代表这个功能不重要,在整个项目周期中,被使用的频率不是非常高。
如:
GUI、信息提示、压力、性能。
高:
中:
低=3:
4:
3=2:
6:
2
回归测试和冒烟测试
5、预置条件(前提条件)
6、操作步骤(要有具体数据)
1.输入用户名:
“”;
2.输入密码:
“aaaaa@2”;
3.点击:
【登录】按钮。
7、预期结果
登录成功。
8、实际结果(excel)
9、设计人(作者)
10、设计时间
11、备注
粒度:
1、用例的粒度大,则总的用例数就少,用例看起来也简洁。
2、用例的粒度小,则单条用例关注的测试点很集中,不容易遗漏,并且执行需要的时间比较好估计。
用例粒度大,用例数目少,但是有可能有遗漏。
用例粒度小,用例数目多,