本章节重点：1.测试用例书写2.缺陷报告书写3.禅道的了解以及使用！
有任何问题可以评论或者私信我哦，一起学期共同进步！！！

软件测试由来

软件测试的目的

产品的风险识别，提高产品成功的几率。

一、本质
站在用户的角度来检验一个软件是否满足客户的功能需求，并且能够及时准确的发现其中用户可能察觉不到的软件的缺陷。
二、立场
为了证明程序有错误！
三、成本
及时的发现漏洞或者逻辑缺陷，能够避免产品在未来投入生产后可能产生异常所造成的公司成本资源的浪费。

软件测试的概述

一、定义
对某个软件系统运行过程进行检验其是否满足需求(或者说实际运行结果是否符合预期)

二、原则

1.方向
- 一切测试都要以用户需求为中心
- 测试的用例是设计出来的，不是写出来的(按需设计)
2.执行
- 测试贯穿整个产品的声明周期
- 提前测试+不断测试
- 不要妄想穷举所有的可能测试用例
3.错误
- 二八原则：80%的错误,发生在20%的模块中
- 对发现错误较多的程序段，应进行更深入的测试
- 错误的优先级排序->先解决影响产品基础功能的问题

软件测试的发展以及过程产物

发展过程

一、软件证明阶段

1960年代—> 测试即debug程序

二、软件检测阶段

1960-1978年代—>证明软件是正确的
1979-1982年代—>测试思想初成(为了返现软件错误：破坏性测试)
黑盒测试的概念诞生：把程序看做一个黑盒子，不考虑内部结构，只是在外部测试程序的功能是否能够按照规范说明准确无误的运行。

三、软件预防阶段

1983年测试行业的标准IEEE829的诞生—>标志着软件预防阶段的开始
白盒测试的概念诞生：把程序看做一个白盒子，能够清楚的看减盒子内程序的逻辑和相关信息，观察程序运行内部是否按照规格设计说明书设定的运行，以及每个独立的模块结构是否正常有效。

四、软件全面质量管控阶段

21世纪至今—>以用户为中心，降低产品风险，全流程把控产品的质量。
灰盒测试概念诞生—>当今产品的开发速度过快的环境下衍生的一种测试模式，根据需求高效的来进行产品测试，即包含了黑盒的纯用户行为的测试又可以根据测试需求查看具体某一个功能代码的内部逻辑。

过程产物

一、软件开发模型

1.瀑布型（20世纪70年代）
- 概念：
  将开发流程划分6个阶段—>制定计划、产品需求、设计功能、编码、测试、运维各个阶段严格按照线性执行, 逐级操作, 从上到下固定次序
- 优点：
  - 6个阶段划分明确, 清晰
  - 只需要关注后续阶段
  - 迭代功能期间, 复用性高
  - 提供了一个开发模板从分析->设计->开发测试->上线
- 缺点：
  - 不灵活, 固化, 每个阶段产生大量文档(产品需求文档, 接口文档, 原型图, 设计报告, 测试报告, 测试设计, 运维报告, 上线文档)
  - 用户参与度比较低, 产品风险较高
  - 突出缺点是不适应用户需求的变化
  - 用户需要足够的耐心
- 适用场景：
  - 需求非常明确, 变化极少的项目
  - 客户要求相对较低, 参与度低

2.快速开发模型
- 概念：
  借助原型辅助工具根据用户的需求构建一个产品原型, 让用户参与使用, 反复进行：确认需求>需求敲定>运行查看>总结改进
- 优点：
  适应用户需求的变化, 用户参与度比较高, 满意度比较高, 节约成本
- 缺点：
  - 前提必须有产品原型, 限制开发的思路
  - 开发技术和工具不一定符合最新技术
  - 频繁修改
- 适用场景：
  - 中小型的项目, 不适用大型项目
  - 对所开发的领域比较熟悉
3.增量模型（常用）
- 概念：
  按照需求将项目拆分模块化,开发一个模块,测试一个模块, 用户参与体验模块, 及时响应用户的需求
- 优点：
  - 降低开发风险, 提高用户参与度
  - 模块顺序可以随时调整, 比较灵活
- 缺点：需求变化尽可能控制变化少
- 适用场景：迭代更新、新产品开发
4.螺旋模型（20世纪90年代）
- 概念：以风险分析驱动开发, 将瀑布型和快速原型模型结合.
- 优点：
  - 设计灵活, 在整个阶段可以灵活调整变更
  - 风险更低
- 缺点：
  - 风险评估的专家要求特别高, 评估结果需要科学准确
  - 如果风险评估干扰了项目的营收, 整个风评可以不做
- 适用场景：大型项目

二、测试模型

1.V模型
- 概念: 先开发后测试
  - 开发阶段: 需求分析—概要设计–详细设计–编码
  - 测试阶段:单元测试—集成测试–系统测试–验收测试
    四个测试阶段：
  - 单元测试->白盒测试, 测试代码有没有问题,–django子应用-test.py ; 单模块测试
  - 集成测试->多模块测试, 至少两个模块①冒烟测试->主功能测试,②回归测试->测试人员发现了BUG–提交给开发–开发修改完毕–测试再次测试–回归测试③系统测试->是检测系统的功能、质量、性能能否满足系统的要求
  - 验收测试->确定上线之前的测试
- 优点：
  - 阶段清晰明了
  - 既包含单元测试又包含系统测试
- 缺点：测试介入太晚

2.VV模型（常用配合增量模型的开发模式）
- 概念：边开发边测试, 测试和开发是相互独立的, 弥补了V模型的缺点可以让测试尽早介入开发过程中，跟上项目进度
- 优点：测试伴随整个项目的开发周期、测试和开发是并行独立进行
- 缺点：面向中大型企业对技术要求较高

3.H模型

概念：测试独立于开发, 根据测试的就绪点进行测试, 灵活性较高, 随时开发随时测试
优点：测试伴随整个项目的开发周期、测试于开发是并行独立进行
缺点：H模型的中间就绪点难找，管理难度大，对测试人员技术经验要求较高

三、测试的基本流程

1、需求分析阶段
- 开需求分析会
- 出需求分析报告
2、测试计划阶段
- 预估测试时间
- 预估测试的人力
- 测试环境搭建
- 测试数据准备
- 测试服务器
3、测试设计阶段
- 设计测试用例
- 评审测试用例
4、执行测试阶段
- 点界面
- 代码测试
- 自动化测试
5、测试评估阶段
- 根据测试用例, 测试报告, 缺陷报告–对产品进行上线评估

测试分类

在这里插入图片描述

软件测试的依赖->测试用例

什么是测试用例

一、测试用例概念
测试用例(test-case)，就是一个用来实现测试具体的软件某个功能是否可以满足用户需求的一个demo，包含输入、执行条件以及预期结果。
二、特性

提升效率，可以复用
有效性，不同人测试同一结果
容易组织分类
可以作为评估依据
方便管理

三、原则

保证测试用例的明确性(一个借口一个用例，条件明了)
确保测试用例具有代表性(减少类似功能测试用例的重复)
确保测试用例的简洁性(可读性高、过程目的明确)

测试用例怎么写***

一、测试用例组成的八要素

1.测试用用例的编号（唯一）
2.测试标题（唯一）

3.测试模块（所属接口）
4.预置条件（硬件、版本、系统）
5.测试输入（程序需要传递的数据）
6.测试步骤（足够明了）
7.预期输出结果（返回值、响应等）
8.重要程度
- 高
- 中
- 低

二、测试用例的几种设计方法

1.等价类划分法(包括边界值分析法)
- 定义：从大量数据里划分范围（每个范围内的数据测试效果是等价的所以每个范围是一个等价类），然后从每个范围中挑选代表数据，这些代表数据能反应这个范围内数据的测试结果。
- 分类：
  - 有效等价类：
    - 满足程序的规格说明
    - 检验程序是否实现了规格说明中所规定的功能和性能
  - 无效等价类：
    - 超出程序规格说明外的数据，不合理、无意义的数据
    - 可校验程序对于无效数据的处理能力,检测程序的健壮性、容错能力
- 适用场景：大量数据中挑选出具有代表性的样本数据
2.判定表法
- 定义：
  将复杂的需要测试的代码逻辑可能的各种情况全部列出来，避免测试项遗漏
- 组成元素
  - 条件桩：列出了问题的所有条件，通常认为列出条件无关紧要。
  - 动作桩：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。
  - 条件项：列出针对它左列条件的取值。在所有可能情况下的真假值。
  - 动作项：列出在条件项的各种取值情况下应该采取的动作。
- 使用原则：
  - 规则：任何一个条件组合的特定取值以及相应的执行操作为规则。条件项和动作项自由组合构成全部可能条件。
  - 化简：规则合并有两条或者多条具有相同动作并且其条件项之间存在着极为相似的关系，即可化简为一个操作。
- 适用场景：
  某些业务逻辑实现依赖于多个条件组合，针对不同的组合值分别针对执行不同的测试条件。
3.正交验证法
- 定义：
  - 也叫正交实验法或者正交排列法，就是使用最小的测试过程集合获得最大的测试覆盖率。
  - 在一项实验中，把影响试验结果的量称为试验因素(因子)，简称因素。因素可以理解为试验过程中的自变量，试验结果可以看成因素的函数。在试验过程中，每一个因素可以处于不同的状态或状况，把因素所处的状态或状况，称为因素的水平，简称水平。
- 组成：公式->Ln(m^k)
  - n代表行数：n=k*(m-1)+1
  - k代表列数：即条件的个数(因子的个数)
  - m代表因子选项：即因子中的包含的所有值
- 试用场景：
  - 需求中条件的组合数量量比较大的时候
  - 需求两个两个因子相互组合的时候
- 正交法的局限性：
  - 对于控件个数，如果没有，就选择一个接近的
  - 对于控制的取值，应该少数服从多数，有更多空间的取值一样
4.其他不常用方法
- 错误推测法
- 场景法
- 因果图法

三、写测试用例（Important）

等价类划分法的测试用例
要求：测试某网站账号的合法符合规范(8-12位、只能由数字组成)
测试用例：

用例编号	等价类划分	输入	预期结果	测试结果	重要级别
Test-账号01	有效等价类(有效边界值)	12345678	正确	正确	高
Test-账号02	无效等价类(无效边界值)	1234567	正确	正确	高
…	…	…	…	…	…

判定表法的测试用例
要求：对于显卡功率大于250W的主机、维护记录不全或运行5年以上的主机，应优先维修。
测试用例：

条件+动作

条件桩	显卡功率大于250W?
	维护记录不全？
	运行超过5年？
动作桩	优先维修

初始判定表(所有可能)

条件桩	条件项	1	2	3	4	5	6	7	8
	显卡功率大于250W?	Y	Y	Y	Y	N	N	N	N
	维护记录不全？	Y	Y	N	N	Y	Y	N	N
	运行超过5年？	Y	N	Y	N	Y	N	Y	N
动作桩	优先维修?	X	X	X		X		X
…	其他处理				X		X		X

化简后的判定表
- 在三个条件中有2个不满足时，剩下的一个完全没有参考价值，可以进行简化。
- 只有功率大于250W、维修记录全的、运行5年以上的才优先处理。
- 其他处理的情况是：
  满足动力大于250W、维修记录完全、没有运行5年以上中只要满足两项。

条件桩	条件项	1	2	3	4	5
	显卡功率大于250W?	Y	Y	N	N	N
	维护记录不全？	Y	N	-	-	N
	运行超过5年？	-	Y	Y	N	N
动作桩	优先维修?	X	X	X
…	其他处理				X	X

正交法法的测试用例
要求：测试某网站账号的合法符合规范(8-12位、只能由数字组成)

测试用例：实现“字符属性设置”的测试用例编写

列举因子表

字体	字符样式	字体颜色	字号
仿宋	粗体	红色	20号
楷体	斜体	绿色	30号
华为楷体	下划线	蓝色	40号

正交表确定：L9(3^4)
所有的可能取值

实验号	字体	字符样式	字体颜色	字号
1	仿宋	粗体	红色	20号
2	仿宋	斜体	绿色	30号
3	仿宋	下划线	蓝色	40号
4	楷体	粗体	绿色	40号
5	楷体	斜体	蓝色	20号
6	楷体	下划线	红色	30号
7	华文楷体	粗体	蓝色	30号
8	华文楷体	斜体	红色	40号
9	华文楷体	下划线	绿色	20号

测试用例编写(上图每一行都是一条测试用例！)

用例编号	输入	预期结果	实际结果	是否为BUG
UT-设置字符子项测-01	字体:仿宋; 字符样式: 粗体; 颜色:红色; 字号:20	仿宋、粗体、红色、20号	仿宋、粗体、红色、20号	否
UT-设置字符子项测-02	字体:仿宋; 字符样式: 粗体; 颜色:红色; 字号:30	仿宋、粗体、红色、20号	仿宋、粗体、红色、25号	是
…	…	…	…	…

软件测试的结果->缺陷

认识缺陷

一、什么是缺陷
缺陷就是软件系统中不符合用户需求或者达不到用户满意的的问题。
二、缺陷来源
软件系统运行过程中发现的某种破坏系统正常运行能力的问题，而导致不满足用户的需求。
三、缺陷表现形式

从严重程度上划分：
- 失效(高)：
  软件运行时产生的外部异常行为结果，表现与用户需求不一致，功能能力终止，用户无法完成所需要的应用。
- 故障(中)：
  软件运行中出现的状态，可引起意外情况，若不加处理，可产生失效，是一个动态行为
- 缺陷(低)：
  存在于软件中的偏差，可被激活，以静态的形式存在于软件内部，相当于bug；
从外在表现上划分
- 1.设计性
  - 设计不合理，功能特性不明确，逻辑不清楚或存在矛盾
  - 数据不正确，或者精度不够，不完整或者格式不统一
- 2.功能性
  - 功能、特性没有实现或者部分实现
  - 没有达到需求规格说明书所规定的性能指标
  - 运行出错，包括运行中断，系统崩溃，界面混乱等
  - 用户不能接受的其他问题，比如等待时间过长，界面不美观
- 3.其他
  - 硬件或者系统软件上存在的其他问题

写缺陷报告（Important）***

一.组成

缺陷名称
缺陷状态
缺陷的严重程度(高->低)
* 1.Fatal：致命缺陷
* 2.Critical：严重缺陷
* 3.Major：一般缺陷
* 4.Minor：小缺陷
* 5.Enhancemental：建议的问题
缺陷解决的优先级(高->低)
* 1.P1：立即解决
* 2.P2：高级优先
* 3.P3：正常级别
* 4.P4：低级优先