测试人员应该想些什么
我自己是做后端的,对于模棱两可的需求和莫名其妙的测试case是深恶痛绝的,所以有时候我就会想测试人员应该会需要注意什么?以他们的角度,他们更在乎什么
最近有机会了解相关的知识,遂整理记录一下,以便之后在工作中更好的理解发生的各种事情
以客户为中心
这个真的很重要,以至于可以直接作为标题
做测试之前要真正理解需求,一切以客户为出发点
不要被“故事”误导
首先,要区分清楚客户群体,明确他们的诉求在大方向上的差异,有针对性的去进行业务分析
值得注意的是,客户有时候给到的所谓“方案”,它并不是真正的需求
所谓的方案多见进行"故事性"的描述,因此要分析客户真正想要的(你可以通过需求的对比分析,逐步明确客户想要的产品是什么)
干系人识别
客户在传达需求时,可能会出现很多不同的负责人、领导,他们会从自己领域角度给出很多需求点
我们需要对这些“需求提出者”进行权重划分
按照 类型-名称-说明-相关度-影响度 这几项进行罗列,确认项目组真正应该关注的需求点
例如,在讨论具体的技术需求方案时,市场部领导的意见就可以稍稍
当然你也需要全部记录,事后再进一步向相关性更高的领导确认
需求文档
需求文档是给项目组全员看的,请好好理解,用人话写,不行你就画点图,求你了
敏捷开发
敏捷开发的价值: 分步骤实现需求,了解客户需要什么
这里属于测开的理论部分,提一提,记一记
敏捷开发的主要模式
SCRUM
三个角色:
- 产品负责人(product owner,PO);
- SCRUM负责人(SCRUM master, SM);
- 团队Team(DTeam);
三个产出物(文档):
- 产品列表;
- 迭代列表;
- 增量列表;
五个会议:
- 迭代计划会;
- 每日站会;
- (测试用例)评审会;
- 回顾会;
- 待办事项梳理会;(哪些问题,何时解决)
确定项目类型
在开始项目前要确定项目属于哪种类型,迭代 or 增量
迭代型生命周期
分析--->设计原型系统--->构建测试--->交付(产生原型) (改善系统)
适用于复杂度高、变更频繁(相关方经常提修改需求并直接影响最终产品的)
增量型生命周期
| 分析 |<-----|
| 设计 | |
| 构建 | | 重复上述过程直到项目结束
| 测试 | |
| 交付 |----->|
适用于客户愿意接受先交付半成品,并接受后续不断改进的情况
目的是为了加快交付速度
敏捷测试流程图(简要)
“一页纸测试计划”指的是在写测试计划的时候,不要长篇大论,一个迭代对应一个计划即可
时间有限嘛
敏捷测试的要求是"交付可用的产品",而不是"发现缺陷"
敏捷测试四象限
四个象限无先后顺序,主要是看当前迭代的需求,对症下药
说明
Q1
如图所示,客户不一定专业,他们提的内容有可能有问题,要学会"PUA"他们,即帮助客户知道自己想要的
Q2
单元测试一般就是做白盒测试,要达到以下几个点:
- 语句覆盖;(减少无用代码)
- 判定覆盖;(覆盖尽可能多的分支)
- 路径覆盖;(作为测试补充)
原则:做单元测试的时间不应该超过编写代码的时间
每个单元测试是独立的, 每次测试仅测试一个维度
因此,需要分清优先级,评判任务重要性可以采用团队投票的方式进行
Q3
是否所有的测试用例都要分等级?是的,为了控制迭代交付时的风险
项目时间紧怎么办?通过思维导图提炼测试要点
Q4
如果要做性能测试,最重要的事情是:确定要不要做性能测试
测试方法
等价类划分(重点)
步骤
step1:先依据常用方法划分等价类;(就是从直觉出发去做)
step2:为等价类表中的 每一个等价类 分别规定一个唯一编号;
step3:设计一个新用例,使它能够尽量多的覆盖尚未覆盖的有效等价类;(重复该步骤直到所有有效等价类均被用例覆盖)
step4:设计一个新用例,使它能仅覆盖一个无效等价类;(重复该步骤直到所有无效等价类均被用例覆盖)
总之就是先找有效的(数量少的),再找无效的
要注意,不要对测试用例进行组合,只考虑当前情况
练习-三角形问题
输入三个整数a、b、c,分别作为三角形的三条边,现通过程序判断由三条边构成的三角形的类型为等边三角形、等腰三角形、一般三角形(特殊的还有直角三角形),以及构不成三角形。现在要求输入三个整数a、b、 c,必须满足以下条件:
条件1 1≤a≤ 100 条件4 a<b+c
条件2 1≤b≤ 100 条件5 b<a+c
条件3 1≤c≤100 条件6 c<a+b
首先进行等价类划分
-
无效等价类:
- 所有边长小于1的值(不满足条件1、2、3)。
- 任何一边长超过100的值(不满足条件1、2、3)。
- 任意两边之和小于第三边的值(不满足条件4、5、6)。
-
有效等价类:
- 所有边长在1到100之间的值(满足条件1、2、3)。
- 任意两边之和大于第三边的值(满足条件4、5、6)。
-
三角形类型等价类:
- 等边三角形:a = b = c。
- 等腰三角形:a = b ≠ c 或 a = c ≠ b 或 b = c ≠ a。
- 一般三角形:a ≠ b ≠ c 且 a + b > c, a + c > b, b + c > a。
- 直角三角形:满足勾股定理的三边关系,例如 a² + b² = c² 或 b² + c² = a² 或 c² + a² = b²。
测试用例
基于上述等价类,我们可以设计以下测试用例:
-
无效测试用例:
- 测试用例1:a = 0, b = 2, c = 3(不满足条件1)。
- 测试用例2:a = 101, b = 2, c = 3(不满足条件1)。
- 测试用例3:a = 2, b = 3, c = 5(不满足条件4)。
-
有效测试用例:
- 测试用例4:a = 10, b = 10, c = 10(等边三角形)。
- 测试用例5:a = 5, b = 5, c = 8(等腰三角形)。
- 测试用例6:a = 3, b = 4, c = 5(一般三角形)。
- 测试用例7:a = 3, b = 4, c = 6(直角三角形,满足勾股定理)。
-
边界值测试用例:
- 测试用例8:a = 1, b = 1, c = 2(边界值,一般三角形)。
- 测试用例9:a = 100, b = 100, c = 100(边界值,等边三角形)。
- 测试用例10:a = 1, b = 2, c = 100(边界值,一般三角形)。
这些测试用例覆盖了各种可能的输入情况,包括无效输入和各种类型的有效三角形。通过这些测试用例,可以验证程序对三角形类型的判断是否正确。
边界值法
略
正交试验法
多用于兼容性测试
略,本质上是通过概率手段(运用正交表进行排列组合)获取尽可能多且覆盖度高的测试情况
场景法(基础)
概述
何为场景?
- 哪些人、什么时间、什么地点做啥梦以及如何做等要素组成场景
- 场景可嵌套
何为场景法?
场景法是通过使用“场景”对软件系统的功能点或业务流程进行描述,
即针对需求模拟出不同的场景进行所有功能点及业务流程的覆盖,从而提高测试效率并达到良好效果的一种方法。
适用场合?
适用于解决业务流程清晰的系统或功能。
场景法组成
基本流+备选流=场景法
永远先提取基本场景
步骤
step1:分析需求,确定出软件的基本流及各项备选流;
step2:依据基本流和各项备选流,生成不同的场景;
step3:针对生成的各场景,设计相应的测试用例;
step4:重审测试用例,去掉冗余,并设计测试数据;
决策法
略
因果图
略