【防忘笔记】测试过程与技术

测试人员应该想些什么

我自己是做后端的，对于模棱两可的需求和莫名其妙的测试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的值（不满足条件1、2、3）。
   • 任何一边长超过100的值（不满足条件1、2、3）。
   • 任意两边之和小于第三边的值（不满足条件4、5、6）。

2. 有效等价类：

   • 所有边长在1到100之间的值（满足条件1、2、3）。
   • 任意两边之和大于第三边的值（满足条件4、5、6）。

3. 三角形类型等价类：

   • 等边三角形：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. 无效测试用例：

   • 测试用例1：a = 0, b = 2, c = 3（不满足条件1）。
   • 测试用例2：a = 101, b = 2, c = 3（不满足条件1）。
   • 测试用例3：a = 2, b = 3, c = 5（不满足条件4）。

2. 有效测试用例：

   • 测试用例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（直角三角形，满足勾股定理）。

3. 边界值测试用例：

   • 测试用例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：重审测试用例，去掉冗余，并设计测试数据；

决策法

略

因果图

略