第二章 软件测试理论
一、软件测试基础
1.软件测试的历史和发展前景
1.1软件测试是什么?
早在1979年,美国人Glenford J.Myers在《软件测试的艺术》这本书就已经给出了一个最经典的定义:
The process of executing a program with the intent of finding errors.测试是为发现错误而执行程序的过程。
1.2软件测试的行业现状
每年测试人员大量涌入,功能测试已基本饱和
测试人员在各公司地位不一
测试工程师能力参差不齐
1.3软件测试的行业前景
· 企业招人,综合技能要求会越来越高
· 市场需求逐渐趋于饱和,尤其是功能测试
· 功能测试会逐渐向性能测试和自动化测试方面转变
1.4软件测试的职业规划
技术方向
'''
技术方向,可以分为手工测试、自动化测试、性能测试,这三个方向
初级软件测试工程师:一般是指刚入行的测试人员,基本上是做功能测试,工作内容比较简单。
自动化测试工程师:主要负责自动化测试系统的设计和建设,完成自动化测试用例与脚本的设计与编写,要求熟悉主流开发技术与自动化测试框架,需要熟练掌握Java或Python,精通QTP工具Loadrunner、Robot、QTP等自动测试工具,熟悉Linux平台
性能测试工程师:通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。比如负载测试、压力测试,都是性能测试工程师的工作内容
测试架构师
高级测试工程师/资深测试工程师
'''
管理方向
'''
组长、主管、经理、总监
'''
参考:https://zhuanlan.zhihu.com/p/258885495
2.软件研发模型
2.1瀑布模型
定义: 瀑布模型(Waterfall Model)是将软件生存周期的各项活动规定为按固定顺序而连接的若干阶段工作,形如瀑布流水,最终得到软件产品。
地位: 这是一种经典模型,提供了软件开发的基本框架。
优点:
'''
1)各阶段划分清晰
2)强调计划与需求分析
3)适合需求稳定的产品开发
'''
缺点:
'''
1)单一流程,不可逆
2)风险显露得晚,纠正机会少
3)测试只是其中一个阶段,缺乏全过程测试思想
'''
适用于大型需求清晰的项目==》银行
2.2V模型
优点:相对于瀑布模型,V模型测试能够尽早的进入到开发阶段。
缺点:虽然测试尽早的进入到开发阶段,但是真正进行软件测试是在编码之后,这样忽视了测试对需求分析,系统设计的验证,时间效率上也大打折扣。
2.3W模型
定义:W模型又称为双V模型
优点:早介入、早发现、早修复。全软件生命周期。W 模型相对于 V 模型来说,测试更早的进入到开发阶段,与开发阶段是并行关系,更早的发现问题,能够及时解决问题,各个阶段分工明确,方便管理。
缺点:W 模型是顺序性的,不可逆,需求的变更和调整,依旧不方便。
2.4迭代开发模型
迭代式开发也被称作迭代增量式开发或迭代进化式开发,是一种与传统的瀑布式开发相反的软件开发过程,它弥补了传统开发方式中的一些弱点,具有更高的成功率和生产率。
迭代式开发的优点:
'''
1、降低风险
2、得到早期用户反馈
3、持续的测试和集成
4、使用变更
5、提高复用性
'''
2.5敏捷开发模型
敏捷开发小组主要的工作方式可以归纳为:
'''
1、作为一个整体工作
2、按短迭代周期工作
3、每次迭代交付一些成果
4、关注业务优先级
5、检查与调整
'''
2.6快速原型模型
优点: 解决瀑布模型缺点(适用于其需求变化)
适用于需求不清晰的中小型项目 ==》互联网
2.7螺旋模型
引入风险分析方法
适用于需求不清晰的大型项目
参考1:https://blog.csdn.net/Ariazm/article/details/107921802
参考2:https://blog.csdn.net/qq_38467948/article/details/96431494
3.软件测试模型
3.1V模型
用户需求==>需求分析==>概要设计==>详细设计==>编码==>单元测试==>集成维护==>系统测试==>验收测试
3.2W模型(双V模型)
开发V: 需求分析==>概要设计==>详细设计==>编码==>集成==>实施==>交付
测试V: 验收/系统测试设计==>集成测试设计==>单元测试设计==>单元测试==>集成维护==>系统测试==>验收测
优点: 早介入、早发现、早 修复;全软件生命周期。
3.3H模型
测试准备
测试就绪点
测试执行
3.4X模型
参考:https://zhuanlan.zhihu.com/p/103765623#
二、软件质量管理与模型
1.软件质量的定义
软件质量 是软件特性的综合,指软件满足规定或潜在用户需求的能力,其主要从 内部质量、外部质量、使用质量和过程质量 这四个方面来衡量。
2.软件质量模型
测度与度量: 在软件质量中用于测量的一种量化的标度和方法即为测度,而名词的度量即用来指测量的结果。
1. McCail质量模型
2. Boehm质量模型
3. ISO9126质量模型
3、软件质量的六大特性
3.1功能性
3.2可靠性
3.3易用性
3.4效率性
3.5可维护性
3.6可移植性
参考:https://blog.csdn.net/catch_dreamer/article/details/109139869
三、软件测试策略
1.软件测试的分类与方法
软件测试就是使用人工和自动手段来运行或测试某个系统的过程,其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。
软件测试从不同的角度有着不同的分类方式
一、按测试方法分类(是否覆盖源代码):黑盒测试 白盒测试 灰盒测试
黑盒测试
功能: 业务功能测试、界面、易用性、安装、卸载升级
性能: 时间、稳定、负载、压力
二、按测试方向分类:
1.功能测试: 测试功能能否使用
2.性能测试: 测试在不同的情况下软件响应的时间
其中又包括(压力测试)(负载测试)(并发测试)
3.安全测试: 防止别人攻击成功自己的安全系统
主要从渗透测试、流量攻击、SQL注入、跨域攻击这几方面测试
4.兼容性测试:
web:在不同的浏览器表现是否正常(在电脑上安装不同的浏览器,在不同的浏览器进行测试)
IE 、谷歌、火狐、edge、IE、QQ、360、saferi、Opra、夸克
App:Android 软件就在不同的安卓设备测试使用
ios软件就在不同的苹果手机上测试使用
5.UI测试/界面测试: 检查界面好不好看
从风格是否统一、布局是否合理、配色是否合适来进行测试
6.易用性测试: 好不好用(操作步骤越少越好 学习成本越低越好)
7.稳定性测试: 长时间运行使用看是否出问题
8…APP专项测试:
-
弱网测试
-
权限测试
-
安装、卸载、更新测试
-
场景交互测试
-
资源争用测试
-
消息推送测试
-
资源监控
三、阶段分类:
1.单元测试: 检查代码判断是否有问题,一般来说单元测试都是开发自己做。
2.集成测试: 测试模块和模块的连接有没有问题。
3.系统测试: 测试软件的整个整体。功能,安全,性能等等测试
4.验收测试: 甲方或者客户来验收这个软件是不是它要的软件,协助验收。
四、对象分类:
APP测试
WEB测试
物联网测试
车联网测试
大数据测试
AI测试
小程序测试
五、状态分类(是否运行):
动态测试 代码走查、设计与需求文档
静态测试
六、其他分类:
回归测试: 检查修改后的BUG还有没有问题
冒烟测试: 测试前的测试,检查软件是否具备可测试性
埋点测试: 通过打日志实现,属于测试手段
MOCK测试(打桩测试): 做自动化测试用到的测试手段
参考:https://zhuanlan.zhihu.com/p/245774996
2.软件测试的级别
2.1需求测试
需求测试(Requirement Test)的重点是检查需求规格说明书中是否存在描述不准确、定义模糊、需求用例不正确、语言存在二义性等问题。主要从以下几个方面考虑。
1. 完整性: 每一项需求都必须将所要实现的功能描述清楚,为开发人员设计和实现这些功能提供所有必要的需求依据。
2. 正确性。 每一项需求都必须准确地陈述其要开发的功能。
3. 一致性。 一致性是指与其他软件需求或高层(系统、业务)需求不相矛盾,或者与项目宣传资料一致。
4. 可行性。 每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。
5. 无二义性。 对所有需求说明书的读者都只能有一个明确统一的解释,由于自然语言极易导致二义性,所以尽量把每项需求用简洁明了的用户语言表达出来。
6. 健壮性。 需求说明中是否对可能出现的异常进行了分析,并且对这些异常进行了容错处理。
7. 必要性。 必要性可理解为每项需求都是用来授权编写文档的“根源”。要使每项需求都能回溯至某项客户的输入,如需求用例或其他来源。
8. 可测试性。 每项需求都能通过设计测试用例或其他的验证方法来进行测试。
9. 可修改性。 每项需求只应在软件需求规格说明书中出现一次。这样更改时易于保持一致性。另外,使用目录表、索引和相互参照列表方法将使软件需求规格说明书更容易修改。
2.2组件/单元测试
软件系统中,系统对象的基本组成单元称为组件或程序单元。程序代码中的函数或者类称为“单元”,或者实现某个独立需求的功能模块,称为组件/单元。组件可能由多个单元组成。
组件/单元测试(Unit Test) 是针对软件基本组成单元(软件设计的最小单位)来进行正确性检验的测试工作,其目的是检测被测组件/单元与详细设计说明书的符合程度。通过组件/单元测试活动验证被测对象的功能特性或非功能性特性,发现其可能存在的内存泄露、算法冗余、分支覆盖率低、循环调用效率低等问题,此类缺陷在系统测试层面很难发现。因此,组件/单元测试能够尽早地发现缺陷,修复缺陷成本相对较低。
组件/单元测试 一般由开发人员负责,成本较高。在敏捷研发模型中,测试工程师也可能需要实施此测试活动。组件/单元测试活动亦可以使用自动化测试方法。
组件/单元测试 活动依据包括组件/单元需求说明、详细设计文档、被测代码、编程规范等,典型的测试对象一般有组件、函数、类、数据转换/移植程序、数据库模型、关键字典等,关注被测对象内部数据结构、逻辑控制、异常处理等实现的正确性。
2.3集成测试
组件/单元测试通过后的组件或单元,即可进行集成测试。集成测试(Integration Testing)是对组件/单元之间及组件/单元与第三方接口之间进行测试,其目的是验证接口是否与设计相符,是否与需求相符。
集成测试 根据被测对象的集成程度,可分为3种集成:组件/单元间集成、模块间集成、子系统间集成。集成的规模越大,发现定位缺陷的难度就越大,所以一般根据被测对象的系统结构特性,先从组件/单元间的集成测试开始,使用自底向上或自顶向下渐增式策略实施集成测试活动,大爆炸式集成策略已渐渐被淘汰。
2.4系统测试
系统测试(System Test) 是将通过集成测试的软件,部署到某种较为复杂的计算机用户环境进行测试,这里所说的复杂计算机用户环境,其实就是模拟的用户真实计算机环境。
2.5验收测试
系统测试完成,在交付用户部署应用前,往往需要进行验收测试。验收测试(Acceptance Test)是以用户为主的测试,验收组应当由项目组成员、用户代表或系统的其他利益相关者等组成,原则上在用户所在地进行,但如经用户同意,也可以在公司内模拟用户环境进行。
验收测试根据合同、《需求规格说明书》或《验收测试计划》对成品进行验收测试。在此阶段,发现缺陷并不是其主要目的,期望通过验收测试,使用户建立对即将交付应用的软件系统的信心。
对于项目类的软件系统,一般都需要进行验收测试。验收测试通常情况下可有Alpha测试、Beta测试、UAT测试等验收测试形式。
2.6Alpha测试
Alpha测试 是由用户在开发环境下进行的测试,也可以是在开发机构内部的用户模拟实际操作环境中进行测试。进行Alpha测试时,软件在一个自然设置状态下使用。开发者坐在用户旁,随时记下错误情况和使用问题,Alpha测试在受控的测试环境下实施,其目的主要是评价软件产品的FLURPS(即功能、局域化、可用性、可靠性、性能和技术支持)是否达标。
2.7Beta测试
Beta测试 是由软件的多个用户在一个或多个用户的实际使用环境下进行的测试。与Alpha测试不同的是,进行Beta测试时,开发者通常不在测试现场。因而,Beta测试是在开发者无法控制的环境下进行的软件现场应用,测试者发现问题后,统一收集提交至开发人员进行修复。
2.8UAT测试
UAT测试(User Acceptance Test) 即用户接受度测试。一般用于商业用户验证系统的可用性。通常情况下,由采购方组织终端用户或软件利益相关方对被测对象进行选择性功能试用,关注被测对象核心功能的应用表现,从而为接受该软件系统提供数据依据。例如,银行在外包项目交付时,组织部分行方终端应用人员(如柜台服务人员)进行验收性测试,即为UAT测试。
UAT模式测试还有一种可能,就是根据法律法规、行业现行标准进行验收测试。例如,某政府机关采购的环保监控系统,需遵守政府管理需求及环保法规的约定。
参考:https://zhuanlan.zhihu.com/p/51558818
3.软件测试的复杂性
3.1完全测试是不现实的
3.2软件测试是有风险的
3.3杀虫剂现象
3.4缺陷的不确定性
参考:https://www.jianshu.com/p/43a55816486c
四、系统测试类型(重点)
1.功能测试
参考:https://blog.csdn.net/m0_37664730/article/details/80968458
2.性能测试
参考:https://blog.csdn.net/u010521062/article/details/115404178
3.兼容性测试
参考:https://zhuanlan.zhihu.com/p/78106223
4.安全测试
参考:https://zhuanlan.zhihu.com/p/60661148
5.冒烟测试
参考:https://www.jianshu.com/p/46a2fc4a1d00
6.回归测试
参考:https://blog.csdn.net/zhusongziye/article/details/80383878
作者:吴常文
出处:https://editor.csdn.net/md/?articleId=122199738
本文版权归作者和CSDN共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接。