一、如何学习?
1、要知道什么是软件测试,为什么会有软件测试这个岗位,了解软件测试基础概念和特点。
2、要知道怎么去做测试,用什么工具去做测试,熟悉软件测试流程和相关测试工具。
二、软件测试的定义
软件测试是使用人工或自动的手段来运行或测定某个软件系统的过程,其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。使用标准和规范的方式,来保证软件全流程质量,防范质量风险。
三、软件测试工作流程
需求评审 | 测试计划 | 测试用例设计 | 测试执行 | 测试评估 |
测试人员分解、了解需求,得出测试点、测试需求。 需求评审会议:需求人员讲解,研发、测试相关负责人参加。 | 根据需求编写测试计划:包括主要功能、人员分配、项目大致时间安排等。 | 测试人员根据需求,进行测试用例设计。 测试用例评审会议。 | 测试人员最为重要的工作阶段,结合测试方法、测试基础知识,暴露出软件各方面的缺陷。 目标:软件质量过关,达到需求要求,上线后不能出现严重的bug,如:404、500等。 | 测试人员给出软件测试的评估,包括是否满足上线条件,严重bug是否都已关闭。保证顺利上线,并做出测试报告总结。 |
四、软件测试模型
1、瀑布模型
瀑布模型适合于结构化方法。
软件项目或产品选择瀑布模型必须满足下列条件:
- 在开发时间内需求没有或很少变化
- 分析设计人员对应用领域很熟悉
- 低风险项目(对目标、环境很熟悉)
- 用户使用环境很稳定
- 用户除提出需求以外,很少参与开发工作
缺点是:测试工作后置,导致整个项目开发完成之后如果发现比较重要的问题,修改成本非常高。
2、V模型
V模型主要特点是将测试过程细化,分为了单元测试、集成测试、系统测试和验收测试四个过程,清楚的标识了开发和测试各个阶段的先后关系。
缺点是:测试工作后置,在实际工作中,需求经常变化,导致V模型步骤反复执行,返工量很大,灵活度较低。
3、W模型
W模型即开发一个V模型,测试一个V模型,这两个V模型组合起来形成W模型。
W模型将测试和开发过程分离出来,对整个项目过程中的需求文档、设计文档等同样要进行测试,将测试工作前置,大大降低整个项目的质量风险。
4、敏捷模型
敏捷模型是为了适应现代互联网公司“短频快”的开发节奏而设计的一种测试和开发的模型。
五、软件测试方法的分类
1、按开发阶段划分
1)单元测试(Unit Testing)
是对软件的组成单位进行测试,目的是检验软件基本组成单位的正确性。测试的对象是软件的最小单位:模块。【例如:登录测试】
2)集成测试(Integration Testing)
是将程序各个模块采用适当的集成策略组装起来,对系统的接口及集成后的整体功能进行正确性检测。集成测试的主要目的是检查软件各个单位之间的接口是否正确。【例如:京东购物调用微信支付】
3)系统测试(System Testing)
是对软件系统整体进行的测试,包括对功能、性能以及运行所需的软硬件环境进行测试。【例如:微信能不能聊天(功能)、群聊人数太多会不会卡顿(性能)】
系统测试的完整工作流程是:需求评审(功能需求、性能需求、接口需求)- 测试计划 - 测试用例 - 用例评审 - 测试环境搭建(平台、架构、web服务器、数据库)- 执行用例 - 提交问题 - 缺陷的跟踪和回归测试 - 测试报告。
4)验收测试(Acceptance Testing)
也称为交付测试,是部署软件前的最后一个测试操作,向软件购买者展示该软件系统满足原始需求。实施验收测试的策略有三种:正式验收测试、非正式验收测试或α测试、β测试。
2、按是否手工执行划分
1)手工测试(Manual Testing)
手工测试是由人一个一个的输入测试用例,然后观察结果,属于比较原始但是必须的一种。
2)自动化测试(Automation Testing)
自动化测试是指在预设条件(包括正常条件和异常条件)下运行系统或应用程序,评估运行结果。简单来说,自动化测试就是把人为驱动的测试行为,转化为机器执行的过程。
3、按是否查看代码划分
1)黑色测试(Black-Box Testing)
黑盒测试也是功能测试,测试中把被测的软件当做一个黑盒子,不关心盒子的内部结构是什么,只关心软件的输入数据和输出数据。
2)白盒测试(White-Box Testing)
白盒测试又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。白盒测试是指打开盒子,去研究里面的源代码和程序结果。
3)灰盒测试(Gray-Box Testing)
灰盒测试是介于白盒测试和黑盒测试之间的一种,灰盒测试多用于集成测试阶段,不仅关注输入、输出的正确性,同时也关注程序内部的情况。
4、按是否运行划分
1)静态测试(Static Testing)
静态测试是指不运行被测程序本身,仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性,对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错。【静态测试属于白盒测试】
2)动态测试(Dynamic Testing)
动态测试是指通过运行被测程序,检查运行结果与预期结果的差异。【黑盒测试属于动态测试】
5、按测试对象划分
1)非功能测试
a)性能测试(Performance Testing)
检查系统是否满足需求规格说明书中规定的性能。通常表现在以下方面:
- 稳定性【例如:一万人的时候和十万人的时候,甚至一百万的时候系统会不会卡顿】
- 响应时间【例如:等待响应的时间是否过慢】
- 吞吐量(TPS)
b)安全测试(Safety Testing)
安全测试是一个相对独立的领域,需要更多的专业知识。如:WEB的安全测试需要熟悉各种网络协议、防火墙、CDN,熟悉各种操作系统的漏洞、路由器等。c)兼容性测试(Compatibility Testing)
兼容性测试主要指软件之间能否很好的运作,会不会有影响、软件和硬件之间能否发挥很好的效率工作,会不会影响导致系统的崩溃。
- 平台测试【例如:各种不同品牌型号、不同操作系统(如android、iOS)的手机是否兼容】
- 浏览器测试【例如:不同浏览器兼容性测试(火狐、谷歌、360等)】
- 软件本身是否向前或向后兼容【例如:本版本和上一版本是否兼容】
- 测试软件是否与其他相关软件兼容【例如:同时下载两款软件是否都能正常使用】
- 数据兼容性测试【要确保数据之间有一定的隔离性,两个软件里面的数据不会串、相互隔离、兼容】
d)文档测试(Document Testing)
- 开发文档:可行性研究报告、软件需求说明书、数据要求说明书、概要设计说明书、详细设计说明书、数据库设计说明书、模块开发卷宗等。
- 用户文档:用户手册、操作手册。用户文档的作用:改善易安装性;改善软件的易学性与易用性;改善软件可靠性;降低技术支持成本。
- 管理文档:项目开发计划、测试计划、测试分析报告、开发进度月报、项目开发总结报告等。
在实际测试中,最常见的就是用户文档的测试,例如:用户操作手册。文档测试过程中主要关注的点是:文档的术语、文档的正确性、文档的完整性、文档的一致性、文档的易用性。
e)易用性(用户体验性测试)(User Ability Testing)
易用性是交互的适应性、功能性和有效性的集中体现,又叫用户体验测试。f)界面测试(User Interface Testing)
界面测试(又称UI测试),测试用户界面的功能模块的布局是否合理、整体风格是否一致、各个控件的放置位置是否符合客户使用习惯,此外还要测试界面操作便捷性、导航简单易懂性、页面元素的可用性、界面中文字是否正确、命名是否统一、页面是否美观以及文字、图片组合是否完美等。g)安装测试(Installation Testing)
安装测试是指测试程序的安装、卸载过程是否有问题。2) 功能测试(Functional Testing)
功能测试就是对产品的各功能进行验证,根据功能测试用例,逐项测试,检查产品是否达到用户要求的功能。这也是黑盒测试,测试中把被测的软件当做一个黑盒子,不关心盒子的内部结构是什么,只关心软件的输入数据和输出数据。
6、按测试实施的组织划分
1)α测试(Alpha Testing)
2)β测试(Beta Testing)
α测试与β测试区别:
a)测试的场所不同:Alpha测试是指把用户请到开发方的场所来测试,Beta测试是指在一个或多个用户的场所进行的测试。【例如:游戏内测版本】
b) Alpha测试的环境是受开发方控制的,用户的数量相对比较少,时间比较集中。Beta测试的环境是不受开发方控制的,用户数量相对比较多,时间不集中。
c)Alpha测试先于Beta测试执行。通用的软件产品需要较大规模的Beta测试,测试周期比较长。
3)第三方测试(Third-party Testing)
介于开发方和用户之前的测试组织。【例如:众测网】
7、按测试地域划分
软件的国际化和本地化是开发面向全球不同地区用户使用的软件系统的两个版本,而本地化测试和国际化测试则是针对这类软件产品进行的测试。由于软件的全球化普及,还有软件外包行业的兴起,软件的本地化和国际化测试俨然成为一个独特的测试专门领域。
1、国际化测试(International Testing)
国际化测试的对象是软件的国际化版本。
2、本地化测试(Localization Testing)
本地化测试的对象是软件的本地化版本。
六、软件测试原则
1、测试应该尽早进行,最好在需求阶段就开始介入,因为最严重的错误不外乎是系统不能满足用户的需求。
2、程序员(开发)应该避免检查自己的程序,软件测试应该由第三方(测试人员)来负责。
3、设计测试用例时应考虑到合法的输入和不合法的输入。
4、在测试程序时,不仅要检验程序是否做了该做的事,还要检验程序是否做了不该做的事,多余的工作会带来副作用,影响程序的效率,有时会带来潜在的危害或错误。
5、应长期保留所有测试用例,保留测试用例有助于以后修改程序后的回归测试。
七、软件测试策略
1、选择测试方法:选择适合当前项目的测试方法。例如:重复测试的工作可以采用自动化测试。
2、角色和职责:需要在测试策略里面明确定义各个角色,以及该角色的职责。例如:项目经理、测试组长、测试工程师。
3、环境需求:这一点非常重要,它将描述测试时需要的系统环境(软件、Linux服务器、MySQL数据库等),包括软硬件以及网络环境等等。在澄清环境需求的时候,测试组织可以识别出资源方面的风险。
4、风险分析:影响测试过程的风险都应该尽早被识别出来,而且必须有相应的解决办法以便消除或减轻这些风险。例如:人员休假、软件是否完成。
5、测试进度评估:测试进度将会评估完成测试所需要的时间。在设定进度的时候,首先需要明确测试范围(比如说这次增加一个D模块,部分功能会影响原来已经上线的B模块的功能),然后根据测试资源的多少来指定能被各方面认可的测试进度计划。
6、回归测试(Regression Testing)策略:回归测试用来保证fix bug的代码不会影响软件的其他部分,这样需要我们选择已经执行过的测试用例重新运行。测试人员需要找到一个方法来确定哪些测试用例应该在回归测试中运行,用例不能太多,因为资源有限;用例也不能太少,否则会达不到必须的测试强度。
7、优先级:测试范围内的东西不会都是一样重要的,加上测试资源各种有限,所以为测试的模块排定优先级是十分有必要的。