本篇文章将详细介绍测试中的相关概念(需求、BUG、测试用例)以及常见的开发模型和测试模型。
目录
一、需求
1.需求的定义
2.需求的产生
3.测试人员眼中的需求
练习:将“删除微信聊天记录功能是否正常”的需求拆分成子需求(测试需求点)
4.需求的重要性
5.测试人员深入理解需求
二、测试用例(重点)
1.什么是测试用例
2.测试用例练习--注册网易邮箱
3.测试用例练习--输入关键词,校验返回的数据是否包含关键词
4.测试用例的重要性
三、什么是BUG
四、软件的生命周期
五、开发模型(重点)
1.瀑布模型(Waterfall Model)
2.螺旋模型(Spiral Model)
3.增量、迭代
4.敏捷(scrum)
六、测试模型
1.V模型
2.W模型
一、需求
首先,我们介绍什么是需求。通俗的来说,需求就是对具体事务的要求。比如,平时我们上网查阅资料就是一种需求,需要买衣服也是一种需求。那么,需求是如何定义的呢?
1.需求的定义
需求的定义:满足用户期望或正式规定文档(合同、标准、规范)所具有的条件和权能,包含用户需求和软件需求。
用户需求:可以简单理解为甲方(即合同投资方)提出的需求,如果没有甲方,那么就是终端用户(比如QQ、微信的用户)使用产品时必须要完成的任务。该需求一般比较简略。
软件需求:也称为功能需求,该需求详细描述开发人员必须实现的软件功能。
大多数公司在进行软件开发时,会把用户需求转化为软件需求,开发人员和测试人员直接依据的就是软件需求。软件需求是测试人员进行测试工作的基本依据。
2.需求的产生
需求由产品经理(QA)从各个渠道收集而形成,之后编写软件需求规格说明书。那么软件产品需求规格说明书是什么呢?里面包括哪些内容呢?
软件产品需求规格说明书是由产品编写后,提供给软件设计、开发、测试人员的参考文档。一般的软件产品需求规格说明书格式大家可以在网上浏览。
3.测试人员眼中的需求
测试人员需要根据用户需求测试软件是否满足用户的期望。
测试人员的测试过程:业务需求->软件功能需求点->测试需求点->测试用例。
我们以“用户登录”为例,来阐述以上过程:
我们不难发现,测试用例并不是一下子就写出来的,而是通过先将收集到的需求拆分成子需求,再找到每个子需求的测试点,最终进行测试用例的设计。
但是,在测试中不免会产生漏测的现象。 什么是漏测呢?
漏测---测试人员测试软件测试的不全面,导致项目上线后出现了BUG。
练习:将“删除微信聊天记录功能是否正常”的需求拆分成子需求(测试需求点)
基本测试点:
(1)单条删除;
(2)全部删除;
(3)清空聊天记录;
(4)没有网络的情况下删除聊天记录;
(5)弱网的情况下删除聊天记录。
兼容性:
(1)测试不同的微信版本;
(2)测试不同的手机系统(iOS,Android,包括不同安卓机不同品牌的机型)。
性能:
删除聊天记录时的速度(单条,全部,清空)。
4.需求的重要性
如果没有需求或者需求不明确,可能会使产品未达到预期的要求。主要体现在以下两个方面:
a.从软件功能需求来看,无漏测是至关重要的,直接关系到用例的测试覆盖率。
b.对于每个测试需求点,需要采用具体的设计测试用例的方法来进行测试用例的设计。
测试覆盖率---衡量测试的充分性和完整性。
5.测试人员深入理解需求
测试工程师在需求分析和设计阶段就开始介入。因为这个阶段是理解和掌握软件的原始业务需求最好的时机。只有深入的了解了原始业务才能设计出测试覆盖率高的测试用例。
二、测试用例(重点)
1.什么是测试用例
测试用例是为了实施测试而向被测试的系统提供的一组集合,这组集合包括:测试环境、测试步骤、测试数据、测试结果等要素。
测试用例是测试人员执行测试的重要的工作依据。
测试用例解决了两大问题:测什么、怎么测。
2.测试用例练习--注册网易邮箱
标题 | 注册网易邮箱 |
测试环境 | win 10 Chrome版本 112.0.5615.140(正式版本)(64 位) |
测试数据 | 邮箱地址:**** 密码:**** 手机号:**** 验证码:**** |
测试步骤 | 1.打开谷歌浏览器,输入网易注册网址: https://mail.163.com/register/index.htm2 2.输入邮箱地址、密码、手机号,获取验证码并输入验证码,勾选同意用户协议 3.点击注册 |
期望结果 | 展现注册成功的结果页,并且使用账号可以正常登录。 |
测试方式 | 手工 |
功能模块 | 注册登录 |
3.测试用例练习--输入关键词,校验返回的数据是否包含关键词
标题 | 输入关键词,校验返回的数据是否包含关键词 |
测试环境 | win 10 Chrome版本 112.0.5615.140(正式版本)(64 位) |
测试数据 | test |
测试步骤 | 1.打开谷歌浏览器,百度首页 2.在搜索框输入“test”,点击回车 3.观察结果页面返回的数据是否包含“test” |
期望结果 | 百度搜索的结果页面都包含“test” |
序号 | 1 |
4.测试用例的重要性
1.测试用例是测试人员执行测试的重要依据;
2.测试用例是自动化测试的重要依据;
3.测试用例能够降低测试人员工作的重复性,提高测试效率;
4.测试用例可以保证测试的质量(测试覆盖率)。
三、什么是BUG
BUG定义:当且仅当规格说明(即上文介绍的软件需求规格说明书)是存在的并且正确,程序与规格之间的不匹配才是错误。当需求规格说明书没有提到的功能,判断标准最终以用户为准:当程序没有实现其最终用户合理预期的规格要求时,就是软件错误。
四、软件的生命周期
软件的生命周期是指从软件产品的设想开始到软件不再使用而结束的时间。软件的生命周期可以分为六个阶段,即需求分析、计划、设计、编码、测试、运行维护。
我们了解一下每个阶段大概都在进行什么:
需求分析:分析需求是否合理、完整。
计划:计划项目由谁开发、由谁测试,什么时候开发结束、什么时候测试结束、项目什么时候上线等。
设计:开发人员设计项目底层如何实现,输出一个技术文档(详细记录软件技术上是如何实现的)。测试人员设计测试用例。UI设计师将需求文档转换成图片-UI设计稿。
编码:开发人员开发软件,测试人员设计测试用例和测试工具。
测试:测试人员执行测试、提交BUG、测试BUG。
运行维护:将项目推到线上环境,如果发现线上BUG,此时需要修复BUG重新上线。
五、开发模型(重点)
1.瀑布模型(Waterfall Model)
特点:瀑布模型是所有其他模型的基本框架,瀑布模型的每一个阶段都只执行一次,因此是线性顺序进行的软件开发模式。
优点:每个阶段分工明确。
缺点:测试人员介入需求太晚,以至于风险在后期的测试阶段才显露,因而失去早纠正的机会。
2.螺旋模型(Spiral Model)
特点:适用于规模庞大、复杂度高、风险大的项目(每次实施之前都要进行风险分析)。
优点:风险分析可以避免一些未知的问题。
缺点:风险分析一旦分析错误就会带来损失,风险分析需要的成本高。
3.增量、迭代
增量通常和迭代混为一谈,但二者是有区别的。假设完成一项任务需要3个步骤,增量模型就是先执行步骤1,再执行步骤2,最后执行步骤3;而迭代模型就是先执行步骤1的一部分,再执行步骤2的一部分,最后再执行步骤3的一部分。
下图即为迭代模型。
4.敏捷(scrum)
敏捷宣言:
个体交互重于过程和工具
可用的软件重于完备的文档
客户协作重于合同谈判
相应变化重于遵循计划
在每对对比中,后者并非全无价值,但我们更看重前者。
即轻流程、重交互、拥抱变化。
scrum中的角色 | |
PO(product owner) | 产品经理:收集用户需求 |
SM(scrum master) | 项目经理:协助整个项目顺利完成 |
Team(研发团队) | 包括前后端开发、测试、设计 |
scrum将产品的开发分解为若干个小sprint(迭代),其周期一般1-4周,参与的团队成员是5-9人,每次迭代会产生一定的交付。
scrum的基本流程:
六、测试模型
1.V模型
用户需求 | 收集用户需求 |
需求分析与系统设计 | 分析需求是否正确、完整 |
概要设计 | 用什么语言开发、什么框架、项目结构如何设计 |
详细设计 | 开发人员设计技术文档 |
编码 | 开发人员写代码 |
单元测试 | 测试一个个的单元(Java中的单元--类、方法,C语言中--函数) |
集成测试 | 将单元集成在一起,测试某个模块 |
系统测试 | 把整个项目运行起来然后进行整体测试(性能、界面、易用性等) |
验收测试 | 产品、运营、用户进行测试 |
特点:V模型是瀑布模型的变种,目的是改进软件开发的效率和效果。左边是开发,右边是测试。
优点: 每个阶段分工明确;测试被划分成多种类型。
缺点:测试人员介入太晚;测试和开发是串行的。
2.W模型
特点:开发一个V模型,测试一个V模型;测试的对象不仅是程序,还要测试需求、设计等。
优点:测试人员尽早介入了需求;测试和开发是并行的(纵向)。
缺点:不能拥抱变化,不适用于敏捷;测试和开发在一定程度上依旧是串行的(横向,前后关系上)。