测试人员,为什么要学习一门技术?(三)
从上一篇文章 测试人员,为什么要学习一门技术?(二), 我们了解到, 基线管理及日常工作中如果基线没有维护的情况下, 我们如何通过自主能力, 找到一个改变的方向, 今天, 我们来聊聊关于测试经验的扩拓展方向
我知道测试理论很重要, 但是不知道作用在哪些地方?
首先, 我们都知道测试理论是前辈们留下的宝贵财富, 那么他给我们带来了哪些价值?
-
等价类划分
- 把被测对象(入参), 分成多个等类型
- 区分类型后取出具有代表意义的类型参数
- 测试用例由有效等价类和无效等价类的代表组成
-
边界值法
- 边界值方法是基于等价类划分测试方法的一种补充方法
- 他基于等价类的多个类型进行细分补充
- 对系统入参进行略大或略小的偏移, 从而实现测试系统健壮性的一种方法
-
因果图(鱼骨图)
'因果图示例(来源于百度)'
- 这是一种被称为发现问题"根本原因"的测试方法
- 因为他从问题的最起点开始做分析
- 在测试中, 一个完整的测试流程包含了哪些分支与可能存在的情况, 从而分析出问题的根本原因出现在哪里
-
场景分析(错误推测)
- 基于业务分解后, 对于业务场景的一种错误猜测的测试方法
- 这里包含正负向(正向推测和逆向推测)
- 拆解子场景模块后, 再向外扩展, 多模块结合分析, 每一个交互逻辑的分析与理解
- 因为每个场景都有多个业务耦合(集成测试), 所以, 不要觉得子模块测试通过, 所有场景就都是ok的
-
正交分解法
- 在设计测试用例的时候, 如果正交分解不明确, 很可能会出现场景重复的情况
- 正交的特点是基于业务线最短的覆盖流程(完整的覆盖整个业务, 并分解出最短的测试路线)
- 正交分解法实例讲解
是不是看起来好像都用过, 在测试工作中也常常思考测试粒度?(如果你对这里提到的测试方法不明确其使用场景, 请点击这里)
我们的测试思路, 测试理论, 是奠定测试覆盖的有效保障, 如果你不能深刻的理解他, 这并不是会用, 而是"我知道, 就是这样的...."
这样的结果就是看起来好像我会的很多, 然而其实我什么都不会. 更多的时候, 你觉得需要进阶的时候, 回头看一下你对现有知识结构的理解与深度, 是否真的需要进阶, 还是有很多地方不懂, 无法利用与实际业务. 如果无法利用与实际业务, 那么再高明的测试方法, 再强大的编码技术, 也不能改变你的测试水平. 这是核心.
我们来分析一个场景
我们来通过以上测试方法, 做一个实际练习, 我们有这样一个登录页面
百度了一张不知道是谁家的登录页面
我们来分解一下Login这个功能
-
页面
- Logo的正确性
- 字符显示的正确性
- 可点击字符与不可点击字符的区别(马上注册 and 用户名)
- 图层的正确性(底色与蓝色的图层)
-
功能
-
点击"马上注册"的场景预期正确
-
用户名
- 可输入的字符类型(纯字符/纯数字/火星文/非主流文字/小于等于1个字符/大于9999999999999999999的字符/不同编码的字符/特殊符号/空格)
- 长度大于输入框时显示规则是否正确
-
密码
- 可输入的字符类型(纯字符/纯数字/火星文/非主流文字/小于等于1个字符/大于9999999999999999999的字符/不同编码的字符/特殊符号/空格)
- 输入密码显示为*
- 输入密码汉字密码
- 空密码
- 特殊符号密码
-
登录按钮
- 按钮点击规则是否正确(什么状态是可以点击的, 什么状态是不可点击的)
- 已知一个正确的密码和一个错误的用户名
- 正确的用户名密码
- 错误的用户名密码
- 无网络场景的登录行为
-
一周内自动登录
- 曾经点击一周内自动登录按钮后的用户是否需要登录
-
对于功能测试来说, 上面的拆解场景基本覆盖了大部分的内容, 但是某一天开发同学来找你了, 这里有个bug 是因为服务端同学某天回家睡觉前, 注释了本该正常使用的get请求方式, 本来是get和post都可以通过的, 现在get方式不通过了, 而get方法请求, 可能关联其他服务的登录请求行为
黑人问号脸??? WTF?
他在说什么?
我们已经很努力的覆盖了case的场景和交叉测试的过程, 出现这个问题之后leader 说这个问题很基础啊, 为什么测试的时候没有测???
今天我们先思考一下这里还有哪些场景是需要覆盖的.
- js加载策略
- Http测试方法的选择
- 登录成功后的Session和Cookies策略是怎样的
- DB查询和缓存策略是怎么定制的???
我们是否需要去对我们的测试对象进行更深一层的了解?
