测试人员应该想些什么
我自己是做后端的，对于模棱两可的需求和莫名其妙的测试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：重审测试用例，去掉冗余，并设计测试数据；
决策法
略
因果图
略
标签：场景,防忘,等价,测试用例,笔记,测试,三角形,100 From： https://www.cnblogs.com/DAYceng/p/18423731