1.认识测试
在学习测试之前,我们需要明白以下几点
1.什么是测试
2.测试的岗位有哪些
3.测试开发和开发之间的区别
4.优秀的测试人员需要有哪些品质
我们大概说一说
其实生活中处处有测试
我们试衣服 我们在买手机之前先看手机功能符不符合需求
这些都是测试
测试主要就是为了发现BUG,提高用户的产品体验避免产品上线之后出现重大失误
测试的岗位有哪些呢???
这里举几个例子,具体可以去招聘网站如boss直聘查看
1.软件测试开发工程师
重点在于测试 单也有开发 和开发功能不同
这里的开发主要是自动化工具框架的开发,为了提高测试效率
2.测试工程师
这里的主要就是测试
关注产品的功能和用户的需求是否符合
测试推进开发进行,协助开发提高产品质量
软件测试和开发的区别
工作内容上
测试基本上编写测试用例 执行测试用例 发现软件缺陷 验收BUG等业务
主要的功能是利用测试工具来保证对应的软件质量
而对应的开发一般是用编程语言开实现对应的业务功能,主要是业务逻辑的实现
对应的测试需要掌握的广度广一点儿开发需要掌握的技术的深度需要深入一点
测试为啥需要会开发?
因为我们需要编写代码,需要开发对应的性能测试工具,对应也需要能看懂了解开发的框架
我们在能读懂代码逻辑的同时也能更好的从代码层面去发现并且辅佐开发人员更好的完成业务需求
测试需要哪些素质(以下粗浅的列举)
1.沟通能力
我们需要更好的表达对应的bug才能帮助开发更好的完成需求
我们有时候自己脑子里面清楚自己需要表达什么bug,但是嘴巴说不出来,这也是需要训练的
2.快速学习能力
我们测试人员也需要迅速了解业务需求才能更好的完成对功能的测试
我们需要时刻保持快速上手新技术的能力从而满足市场需求
3.开发能力
我们通常在测试的同时也需要搞开发效率工具
不然对假设王者荣耀这个游戏来说
我上线了一个新的功能还得测试以前的旧功能还是都可用
这样的效率就太低了
4.文字能力
我们通常在测试的时候发现bug得完成测试报告 测试计划的书写
工作中写文档的任务是很常见的
5.责任感和抗压能力
互联网行业中加班和压力是很常见的
测试中工作量很难衡量,我们很难估计
经常我们完不成任务额的时候也需要抗住各种压力
为啥走测开不走开发?
从兴趣,职业规划,性格分析
2.概念
需求
1.什么是需求?
这里我们大概将需求分为用户需求和软件需求
用户需求往往就只有一句话,比如是让我们实现一个登录功能
实现一个支付功能等等
而软件需求一般是根据用户需求翻译成能实现的具体需求文档等等
比如登录功能设计有哪些输入框,需要输入什么样的值,具体的需求设计文档
这里引入一个prd 的概念
prodect required document 软件需求文档
需求其实也是我们开发人员设计代码逻辑的一个标准
也是我们测试人员编写测试用例的依据
如何深入理解需求呢?
我们通常在接到一个需求的时候会开一个需求评审会议
交代清楚软件产生的背景,软件预期的收益等等
还会有技术评审会议,评估需求是否能够实现,使用什么技术来实现
我们在参与会议之后深入理解需求了之后才能写出更加完善的测试用例
测试用例
什么是测试用例呢?
简单来说就是一组集合,为了试试测试向被测系统提供的一组集合
包括测试环境 操作步骤 测试数据 预期结果等等
为啥需要有测试用例?
测试用例是记录测试人员执行了测试的依据
也能避免重复多次的冗余测试
自动化的依据也是测试用例
BUG
我们在开发中经常会遇到BUG,那么什么是BUG呢?
只要产品所表现出来的和用户需求不符
和PRD不符,这就是BUG
但是我们在描述一个BUG的时候一定要有依据,不能全凭一张嘴说,需要列出具体的文档
开发模型和测试模型
这个模型主要是一些流程
我们先说说一个软件的生命周期
分析 计划 设计 编码 测试 运维
我们再看看某个阶段做啥呢?
分析阶段: 需求需要做什么 需求是不是正确能完成的..
计划阶段:开发时间 工期 测试时间 工期 人员分配等等
设计:UI/UE 设计师 将需求转化成图 - UI视觉稿
技术人员产生技术设计文档
测试:测试执行的用例是否存在BUG,产生测试报告
运行维护:上线 如果上线之后项目存在BUG,需要解决之后重新上线
下面介绍模型
1.瀑布模型
这个模型特点主要是线性的
优点是每个阶段做什么都很明确
但是缺点是测试介入的时间比较迟,发现BUG之后回溯起来会比较麻烦
主要适合一些小项目,比较容易就能完成的项目
2.螺旋模型
这个模型的特点是在进入下一个阶段之前都需要进行对应的风险评测
优点是能避免一些在线上出现的问题
缺点是如果风险分析错误就会把一些问题暴露在线上
3.敏捷模型
首先我们先看看敏捷宣言是怎么说的吧
这里你可能不能理解什么意思,但是这里的意思就是强调团队之间的沟通
强调实用性和拥抱变化
这里更重要的实现就是scrum
有以下重要角色
PO产品经理 项目经理 研发团队
流程主要就是
项目规划
每日站会(报告进度以及预期)
项目演示
总结会议
如果有需求经过产品经理的审核,就会加入到需求池中
增量/迭代模型
简单介绍一下
迭代模型就是先开发出来一套雏形,再在雏形上面去修改
增量模型就是一个模块一个模块开发,最后组装
V模型
特点是开发和测试之间分开了
缺点就是如果发现了BUG得一步一步去回溯
这样的开发效率就很低,测试介入的太迟了
于是就有了W模型
W模型
也称之为双V模型,这里的优点是猜测是人员很早就介入了需求,能很早的发现并修改BUG
缺点是和敏捷模型相悖
这里不能拥抱变化,如果出现了需求变化又得大篇幅的修改
3.BUG
软件测试的途中难免会遇见BUG,下面我们来说说关于BUG的问题
比如软件测试的生命周期(注意不是开发软件的生命周期)
软件测试的生命周期主要包括如下的知识点
需求分析 测试计划 测试设计,测试开发 测试执行 测试评估以上几点
需求分析:判断用户的需求是否合理可以实现
测试计划 啥时候测试 测试多久
测试设计 设计测试用例等
测试开发 开发自动化测试工具
测试评估:写评估测试报告(一般是邮件类型 向leader和开发发送)
如何描述一个BUG
为啥需要描述呢?
因为bug很可能不还复现,很可能会被测试人员忘记
不好一个一个直接转告,所以需要描述
包括但不限于以下几点
测试环境的版本 app,pc...
问题出现的环境 机型,适配?
错误重现的步骤 最好是最短步骤
预期结果是啥
错误的描述
错误的优先级????
优先级一般分为
崩溃 严重 一般 普通
崩溃就是可能无法访问,服务器崩溃的大错误
严重就是某个需求严格不符等等
一般和普通可能是不影响使用,性能问题等
小问题:要上线了但是你还有BUG咋办 ?
轻量级小BUG可以在下个版本迭代更新 ,大BUG就只能延迟上线或者加班了
BUG的生命周期
new: 新发现的bug 未经评审是否指派给开发人员要不要修改
open:确定是一个bug,评审完给开发
fixed:开发人员进行修改的状态
rejected:不是bug 不改
delay:暂时不用修改,延迟修改
closed: 关闭bug
reopen:没该好,继续修改
小问题:和开发起矛盾了咋办?
1.检查自身有问题不
2.站在用户角度看问题
3.实在不行开三方座谈会 商量是否需要解决...
测试的执行和BUG的管理
1.打开待测试的系统
2.执行测试用例
3.发现BUG 确定复现步骤
4.记录BUG
5.沟通BUG
6.记录以前的BUG
7.确认本次测试完成
8.编写测试报告........
4.测试用例
我们先介绍黑盒测试
在测试中我们一定是需要测试用例的
那么什么是一个好的测试用例呢?
好的测试用例需要测试点无二义性
可操作性强
输入输出明确
一条测试用例只对应一个测试结果
用例对需求的测是覆盖率高
下面我们来说说如何设计出测试用例
我们这里说几个常用的设计方法
1.等价类的思想
首先什么是等价类,等价类就是取出一个代表,能代替大部分的整体
解决的是不能穷举全部用例的问题
比如说我现在需要测试一个输入框
输入需要 6 -15位
那么有效的等价类就是在这个区间内的
无效等价类就是不在这个区间内的数据
我们用思维导图的方式来举个例子
我们需要一个6-15位的字母
此时我们分完了就可以来测试了
注意一个测试用例无效等价类需要有有效等价类的组合
比如我们可以设计小于6位的字母 大于15位的非字母等测试用例
边界值测试
下面我们说三个概念
上点:区间边缘的点
内点:区间内的点
离点:对于开闭区间是不同的 开区间则在区间内
闭区间则在区间外
举几个例子
[1,12]
上点: 1 12
内点:5
离点:0,13
(1,12)
上点和内点不变 离点变成 2 11
(1,12] 离点变成2,13
注意边界值的测试一般和上面的等价类可以配合使用
注:这里还有一些错误猜测法:完全凭经验来
场景测试法
先介绍几个概念:主事件流 次事件流
我们可以想象一个购物的场景
主时间流: 打开app 搜索 选择商品 下单购买
在这些事件发生的同时,也可能发生很多问题
比如打开app的时候闪退 搜索的时候搜索不到 选择商品失败等次时间流
我们可以逐个进行测试即可
判定表法
将一个一个结果纷纷列举出来
用得不多 还可以使用allpairs工具生成
万能公式
最后介绍一下我们测试中的万能公式
就是无论让你测试什么东西,可以套一套来说
1.功能相关:干啥用
2.界面相关:长啥样
3.易用性:符不符合人体工学
4.兼容性:除了本质功能还能做啥
5.安全性:是否安全
6.性能,网络 ....
7.抗压能力如何
