【测试开发】概念篇
【测试开发】概念篇
1. 什么是需求
“想睡觉”,“不想上课”,“想吃饭”,这就是需求
而在互联网行业,什么是需求呢?
1.1 需求的定义
- 用户/甲方需求
- 例如QQ截图,用户想要长截图
- 软件/功能需求
- 对于刚才的用户需求,则需要(产品经理)写成细致的功能描述文档,例如长截图如何触发,如何操作(滚动),限制(大小/长度)
再例如一个软件需要有注册功能,注册这个笼统的就是用户需求,而其具体功能(输入姓名,邮箱,密码,确认密码,邮箱验证码,点击注册,是否同意协议,不同意会怎么样,输入不规范会怎么样…)这个详细的就是软件需求
我们开发一个产品,或者测试一个产品,要拿着这个软件需求进行测试/开发!
1.2 为什么有需求
没有需求拿来目标,怎么实现目标?
1.3 测试人员眼里的需求
而测试人员要将软件需求书里的每一个点,转化为一个个的测试点:
小练习:qq登录
- 账号
- 功能
- 账号密码正确,登录成功
- …
- 兼容
- 性能
- 安全
- 密码
- 登录按钮
- …
对测试点分类是必须要的!
1.4 如何深入了解需求
在项目的需求评审会议上了解:
- 有什么需求
- 为什么做这样的一个需求
- 收益达到什么标准
- 软件要做成啥样
- 测试要何时开始,期限为多少天
- 开发要何时开始,期限为多少天
- …
但在开始做项目时,我们可以查阅文档(会议记录/笔记、软件需求文档、技术文档)
沟通一下,找产品经理了解软件功能,找开发了解软件的实现
2. 什么是测试用例
测试用例是一组集合,包含测试环境,测试数据,预期结果,操作步骤…
- 测试环境
- 例如OJ刷题系统,提供给学生一个测试环境(浏览器的一个页面)
- 测试数据
- 例如OJ刷题系统,自己输入测试数据、这道题检验是否通过的一组测试数据
- 预期结果
- 例如OJ刷题系统,通过率为100%
- 操作步骤
- 例如OJ刷题系统,写代码,提交
- 测试序号
- 例如OJ刷题系统,第1,2,3…
- 测试标题
- 例如OJ刷题系统,达到预期后,展现一个动画效果
- 也就是对这一组测试用例的简单描述
在工作中,常常将测试用例称为 CASE
2.1 为什么有测试用例
-
测试用例可以提高的是人员的工作效率
-
测试用例可以降低测试人员工作的重复性问题
如果没有事先列举出测试用例,假设现在有两个人去测试一个功能:
- 大马自己去测试功能,质疑对方的能力,就把能测的都测了执行了,大概100条吧
- 小马也是,就把自己想到的都测了一遍,大概90条吧
这样就会出现,花费时间过长,并且两人测试重复性高的问题
所以,他们的领导要求他们写成测试用例,统计起来再去执行,大概一百条,一半给大马,一半给小马~
-
测试用例是建立自动化的基础,甚至是开发测试工具的基础
自动化就是把测试人员的双手解放,让代码代替人员执行测试,既然如此我们就要有测试用例的集合,让代码以这些测试用例进行测试
2.2 练习=>手机打电话
3. 什么是bug
不严谨的说法:程序和规格说明书之间不匹配
准确的来说:当且仅当规格说明书存在的并且正确,程序与规格说明书之间的不匹配才是bug
- 规格说明书 => 软件需求文档
当需求规格说明书没有提到的功能和没有考虑到的点,判断标准以最终用户为准:当程序没有实现其最终用户合理预期的功能要求时,就是bug
4. 开发模型和测试模型
4.1 软件生命周期
人的生命周期是:呱呱坠地 到 死亡
而软件的生命周期是:
-
需求分析(诞生)
- 分析需求是否合理,遵纪守法…
- 比如,有登录没注册就不合理
-
计划
- 谁开发,谁测试,开发多久,测试多久…
- 就是那五个W…
-
设计
-
编码
- coding
-
测试
- 测试报告
-
运行维护
- 如果有线上问题,此时测试人员需要协助开发定位问题 + 解决问题,之后重新上线
-
停服(死亡)
4.2 开发模型
-
瀑布模型
无非就是把刚才的生命周期串在一起:
特定:线性的
优点:每个阶段做什么,产出什么非常清晰
缺点:风险往往迟至后期的测试阶段才显露,因此失去及时纠正的机会!
- 例如,需求分析出现问题,却在测试才被发现,一步步回溯到需求分析才发现问题,这样花费的时间、人力、精力也很大
适用的项目:
- 小型项目适用于此模型
-
螺旋模型
无非就是把刚才的生命周期反复几次:
特性:迭代的
优点:
- 每个阶段都会进行风险分析,避免一些线上问题发生
缺点:
- 可能迭代次数太多,项目迟迟无法上线
- 风险分析可能会分析错,请专家则人力和财力的投入
适用项目:
- 适用于比较大,风险比较多的项目
对于以下模块,略讲,以一个上课软件为例(登录,创建课程,上课)
- 主要是区分模型是“增量型”还是“迭代型”
-
增量模型
- 登录功能开发完毕 -> 创建课程功能开发完毕 -> 上课功能开发完毕
-
迭代模型
- 登录功能开发一部分 -> 创建课程功能开发一部分 -> 上课功能发一部分
-
敏捷开发
- 个体之间的高效交互
敏捷宣言:
个体与交互重于过程和工具
- 个体之间面对面沟通
可用的软件重于完备的文档
开发文档,需求文档,更 关注最终的软件符不符合用户需求客户协作重于合同谈判
- 一份合同必然无法涵盖每个需求,所以要多与客户合作沟通,也就是客户协作
响应变化重于遵循计划
- 变化是特别常见的,而不是一昧追求计划,而是拥抱变化!
在每对比对中,后者并非全无价值,但我们更看重前者。
- 以上的对比,后者并不能摈弃,后者也很重要,而是更看重前者
- 敏捷开发中的 scrum模型
三个角色:
- scrum由product owner(产品经理)、scrum master(项目经理)和team(研发团队)组成
其中:
- product owner负责整理user story(用户故事),定义其商业价值,对其进行排序,制定发布
计划,对产品负责。- scrum master 负责召开各种会议,协调项目,为研发团队服务。
- team 研发团队则由不同技能的成员组成,通过紧密协同,完成每一次迭代的目标,交付产品
- 后端开发,前端开发,UI设计师,测试工程师…
流程:
4.3 测试模型
4.3.1 敏捷中的测试
挑战1:轻文档
挑战2:快速迭代
- 测试工作的核心内客是没有变的,就是不断地找Bug,只是要调整好自己的心态,一切以敏捷的原则为主
- 测试人员不能依赖文档,测试用例作用减弱,更多的采用思维导图、探索性测试(强调自由度,设 计和执行同时执行,根据测试结果不断调整测试计划)、自动化测试
- 敏捷讲求合作,在敏捷项目组中,测试人员应该更主动点,多向开发人员了解需求、讨论设计、一 起研究Bug出现的原因。
4.3.2 V模型
特点:左边是开发,右边是测试,类似于瀑布模型(折了一下)
优点:测试被划分为许多类型
缺点:测试人员介入太晚,发现问题的时机太晚,故不适用于敏捷
4.3.3 W模型(双V模型)
特点:开发一个V,测试一个V
优点:测试人员在较早地介入了需求
缺点:
- 测试人员和开发人员一定长度上还是串行的(相关的准备都依赖于其左侧的开发模块,例如集成设计测试依赖概要设计、单元测试设计依赖详细设计)
- 这个测试模型不能拥抱变化,在验收测试发现问题,依旧要在测试V上不断回溯找到问题,故也不适用于敏捷
4.3.4 H模型
优点:
- H模型中的测试活动是一个独立的流程,只要满足了测试就绪条件,就可以开始测试活动
- 这种灵活的组织方式,使得H模型完全具备了前两个模型的优点——测试既可以与所有的开发活动紧密结合,又足够灵活满足敏捷和迭代的开发模型
缺点:
- H模型的灵活也造就它难以驾驭的特点
- 如果管理者没有足够的经验就实施H模型,可能会事倍功半,测试活动的成本收益比会比较低
总之,测试模型有三种,优缺点各不相同==建议一般的软件开发过程采用W模型,实施敏捷和迭代开发的可以考虑采用H模型。==
文章到此结束!谢谢观看
可以叫我 小马,我可能写的不好或者有错误,但是一起加油鸭🦆!’希望枯燥的概念没有让你丧失对测试的兴趣!