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