本篇博客
一、正交表
二、正交表使用方法
三、混合正交表工具
四、测试用例方法的选择
五、软件缺陷
六、那些属于软件缺陷
七、缺陷的表现形式
八、软件缺陷的状态
九、软件缺陷的严重程度划分
十、软件测试的优先级
十一、软件缺陷分类
一、正交表
从全面试验中挑选出有代表性的点进行测试（均匀分散，整齐可比）；高效率、快速、经济（科学）的方法；
正交表：一种特制的表，一般的正交表记为：Ln（mk）
n是表的行数，也就是需要测试组合的次数
K是表的列数，表示控件的个数（因素的个数，或因子个数）
m是每个控件包含的取值个数（各因素的水平数，即各因素的状态数）
如下图实例：L9（34）：叫4因素3水平
有4个控件，（字体、字符样式、颜色、字号）
每个控件有3个取值：
字体：仿宋、楷体、华文彩云
字符样式：粗体、斜体、下划线
颜色：红色、绿色、蓝色
字号：20号、30号、40号
9为需要测试的组合个数
二、正交表使用方法
1、 根据控件和取值数选择一个合适的正交表
2、 列举取值并编号，生成取值表
3、 把取值表与选择的正交表进行映射
正交表查询：
https://www.cnblogs.com/zhangyangcheng/diary/2020/02/05/12267353.html
练习：字符属性设置程序
窗体中有4个控件，每个控件有3个取值
步骤一：把控件及其取值列举出来，并对取值进行编号
4个控件（因素）：字体、字符样式、颜色、字号
每个控件有3个取值
34=81种组合情况
步骤二：选择合适的正交排列表
正交表查询：
https://www.cnblogs.com/zhangyangcheng/diary/2020/02/05/12267353.html
由于组合量非常大（34=81种组合情况），因此考虑使用科学的正交法，选择根据（34）到正交排列表去选择：L9（34）正交排列表
选择L9（34）正交排列表
注意：有的时候没有刚刚好的，比如：你的是25，而正交排列表只有：23和27，这里就选择27,因为选多不选少。多一些案例更准确点。
步骤三：把控件及其取值映射到正交排列表中
图1 图2
图1：是把L9（34）正交排列表拷贝到excel中
映射操作：
把图1中第一行（1,2,3,4）换成图2中（字体，字符样式，颜色，字号）
图1中红色框中的序号替换成图2中对应的红色框中的内容。
步骤四：根据映射好的正交排列表编写测试用例。编写如下图，测试用例即完成。
小案例：114系统查询企业单位
完全测试需设计用例数：25=32
有五个因素：
音形码、拼音码、路名码、行业类别和特征码
每个因素有两个水平5
音形码：填、不填
拼音码：填、不填
路名码：填、不填
行业类别：填、不填
特征码：填、不填
选择正交表
表中的因素数＞＝ 5
表中至少有五个因素的水平数＞＝ 2
你的是25，而正交排列表只有：23和27，这里就选择27,因为选多不选少。多一些案例更准确点。
结果： L8（27）。把多余的列给删除掉。
ctrl + f
替换
2---不填
全部替换
三、混合正交表工具
混合正交表工具：
下载下来，解压即可。
在实际工作中，很多情况都是因素（控件个数）和水平（每个控件的可选个数）不同，我们在现成的正交表中找不到对应的表格，此时我们就需要使用混合正交表工具来生成混合正交表；
使用步骤：
1、 制作取值表（不需要编号，列出数据即可）
2、 复制表格中的数据放在一个新建的txt文本文档中（不要改格式），保存到allpairs文件夹中（例如：test2.txt），allpairs文件夹：就是刚刚下载allpairs工具的文件夹。
allpairs文件夹：G:2020202020测试资料day34-代码allpairs
注意：在当前路径：shift+在此处打开命令窗口（就不用执行第三步和第四步骤了）
3、 Win+r再输入cmd进入控制台界面
4、 使用控制台代码进入allpairs文件夹中
G: 切换盘符
cd G:2020202020测试资料day34-代码allpairs
5、 再输入allpairs.exe test2.txt>chenggong.txt （test2.txt是我们刚新建的文件，chenggong.txt是我们最终生成出来的正交表文件）
把上面红色框框的复制到excel里面来。
混合正交表
注意：~表示男女都可以。
四、测试用例方法的选择（重要）
1、 如果测试功能和流程，要使用场景法
2、 需要输入数据的地方，我们要使用等价类划分法，要注意配合边界值法来做详细测试
3、 如果有条件组合的情况，我们要使用因果图制作出判定表
4、 配置类软件，组合比较多的，我们要使用正交表来科学的选择测试用例
5、 如果没有达到覆盖标准，就要增加一些测试用例
6、 依靠经验追加一些测试用例（错误推断法）
测试用例的力度
测试用例可以写的很简单，也可以写的很复杂。
测试用例写的过于简单，则可能失去了测试用例的意义
测试用例写得过于复杂或详细，会带来两个问题：一个是效率问题，另一个是维护成本问题。另外，测试用例设计的过于详细，留给测试执行人员的思考空间就比较少，容易限制测试人员的思维。
大多数的测试团队编写的测试用例的力度介于两者之间。
测试用例的本质
测试用例的设计本质应该是在设计的过程中理解需求，检验需求，并把对软件系统的测试方法的思路记录下来，以便指导将来的测试。
基于需求的测试用例设计
基于需求的用例场景来设计测试用例是最直接有效的方法，因为它直接覆盖了需求，而需求是软件的根本，验证对需求的覆盖是软件测试的根本目的。
要把测试用例当成活的文档，因为需求是活的，善变的。因此在设计测试用例方面应该要把敏捷方法的“及时响应变更比遵循计划更有价值”这一原则体现出来。
不要认为测试用例设计是一个阶段，测试用例的设计也需要迭代，在软件开发的不同阶段都要回来重新评审和完善测试用例。
测试用例评审
1、同行评审
2、用户评审
五、软件缺陷
定义：缺陷就是软件的问题，最终表现为没有满足用户的需求。
软件缺陷是指存在于软件（程序、数据、文档）中的那些不符合用户需求的问题。
六、那些属于软件缺陷
1、 软件未达到规格说明书表明的功能
举例：计算器说明书一般声称该计算器将准确无误地进行加、减、乘、除运算。如果测试人员或用户选定了两个数值后，随意按下了“+”号键，结果没有任何反应。
2、 软件出现了规格说明说中指明不会出现的错误。
举例：假如计算器说明书指明计算器不会出现崩溃、死锁或者停止反应，而在用户随意按、敲键盘后，计算器停止接受输入或没有了反应。
3、 软件功能超出了规格说明书指明的范围
举例：若在进行测试时，发现除了规定的加、减、乘、除功能之外，还能够进行求平方根的运算，而这一功能并没有在说明书的功能中规定。
4、 软件未达到规格说明书虽未指明但应该达到的目标
举例：若在测试过程中发现，因为电池没电而导致了计算不正确，但软件需求规格说明书未能指出在此情况下应如何进行处理。
5、 软件测试人员或用户觉得不好
举例：按键太小、显示屏在亮光下无法看清等。
七、缺陷的表现形式
1、 功能、特性没有实现或者部分实现
2、 设计不合理、功能不明确、逻辑不清楚或存在矛盾
3、 实际结果和期望结果不同
4、 没有达到规格说明说要求的性能指标（例如：要求500人同时在线，但是最多只能300人同时在线。）
5、 运行出错、崩溃、中断、界面混乱
6、 数据不正确、精度不够、不完整或格式不统一
7、 用户不能接受的其它问题，如存取时间过长、界面不美观
8、 硬件或软件存在其它问题
八、软件缺陷的状态（重要，记）
1、 提交—测试人员提交了一个缺陷给程序员
2、 打开—待处理
3、 拒绝—程序员认为不是缺陷或者重复，就可以修改状态为拒绝
4、 修复—程序员修复缺陷后提交的一个状态
5、 关闭—测试人员经过回归测试后，认为此缺陷已经解决，将其关闭
6、 推迟—可以放在后续版本解决的问题，但是要详细写出修复的日期或版本
九、软件缺陷的严重程度划分（重要）
1、 Low—表面性错误，如错别字
2、 Medium—
a.影响一个相对独立功能、b.仅仅发生再特定条件上、c.与需求定义不一致、d.断断续续出问题
3、 High—
a.功能点没有实现、不符合用户需求、b.导致数据丢失
4、 VeryHigh--频繁死机、大部分功能不能使用
5、 Critical—系统瘫痪、异常退出、死循环、严重的计算错误、
有的公司，严重程度：4和5算一个。
十、软件测试的优先级
1、 Low—时间和资源允许的情况下修复（最低优先级）
2、 Medium—不会延迟发布，会在以后修复（低优先级）
3、 High—会制约开发和测试的进行，需要在发布之前修复（中优先级）
4、 VeryHigh—影响系统，产生严重影响（高优先级）
5、 Urgent—导致系统几乎不可用（最高优先级）
注意：
不是严重程度越高，优先级就越高。
比如：购物车中商品价格错误，严重程度:5，优先级：3（没有影响系统，但是发布之前要修改好。）
十一、软件缺陷分类
1、 系统缺陷
内容说明：
- 1.由于程序所引起的死机，异常退出
- 2.程序死循环
- 3.程序错误，不能执行正常工作或重要功能，使系统崩溃或资源不足
备注：不能执行正常工作或重要功能，使系统崩溃或资源不足
2、 数据缺陷
内容说明：
- 1.数据计算错误
- 2.数据约束错误
- 3.数据输入、输出错误
备注：严重地影响系统要求或基本功能的实现，且没有办法更正（重新安装或重新启不属更正方法）
3、 数据库缺陷
内容说明：
- 1.数据库发生死锁
- 2.数据库的表、缺省值未加约束条件
- 3.数据库连接错误
- 4.数据库中的表有过多的空字段
4、 接口缺陷
内容说明：
- 1.数据通信错误
- 2.程序接口错误
5、 功能缺陷
内容说明：
- 1.功能无法实现
- 2.功能实现错误
备注：严重地影响系统要求或基本功能的实现，但有合理的办法更正（重新安装或重新启动不属更正方法）
6、 安全性缺陷
内容说明：
- 1.用户权限无法实现
- 2.超时限制错误
- 3.访问控制错误
- 4.加密错误
7、 兼容性缺陷
内容说明：
- 与需求规定配置兼容性不符合
8、 性能缺陷
内容说明：
- 1.未达到预期的性能目标
- 2.性能测试中出错，导致无法继续进行测试
9、 界面缺陷
内容说明：
- 1.操作界面错误
- 2.打印内容、格式错误
- 3.删除操作未给出提示
- 4.长时间操作未给出提示
- 5.界面不规范
备注：操作者不方便或遇到麻烦，但不影响执行工作功能的实现
10、 建议
内容说明：
- 1.功能建议
- 2.操作建议
备注：建议性的改进要求
软件缺陷信息
|
编号 |
属性名称 |
描述 |
|
1 |
缺陷ID |
唯一的缺陷ID，可以根据该ID追踪缺陷 |
|
2 |
缺陷状态 |
缺陷状态指缺陷通过一个跟踪修复过程的进展情况 |
|
3 |
缺陷标题 |
描述缺陷的标题 |
|
4 |
缺陷的严重程度 |
对软件产品的影响程度，分致命、较严重、严重、一般、低 |
|
5 |
缺陷的优先级 |
缺陷修复的先后顺序，即哪些缺陷优先修正，哪些稍后修正 |
|
6 |
缺陷所属模块 |
缺陷所属的项目和模块，要能较精确的定位至模块 |
|
7 |
缺陷记录者 |
提交缺陷的人员姓名 |
|
8 |
缺陷提交时间 |
缺陷提交的时间 |
|
9 |
缺陷处理人 |
处理缺陷的处理人 |
|
10 |
处理结果描述 |
对处理结果的描述，描述处理情况和代码修改说明 |
|
11 |
缺陷处理时间 |
缺陷处理的时间 |
|
12 |
缺陷验证人 |
对被处理缺陷验证的验证人（回测者） |
|
13 |
验证结果描述 |
对验证结果的描述（通过、不通过） |
|
14 |
缺陷详细描述 |
缺陷的重现步骤 |
|
15 |
缺陷环境说明 |
对测试环境的描述 |
|
16 |
必要的附件 |
如涉及到附件的或错误现象的图片等。 |