深入了解软件测试基础03
本篇博客
一、正交表
二、正交表使用方法
三、混合正交表工具
四、测试用例方法的选择
五、软件缺陷
六、那些属于软件缺陷
七、缺陷的表现形式
八、软件缺陷的状态
九、软件缺陷的严重程度划分
十、软件测试的优先级
十一、软件缺陷分类
一、正交表
从全面试验中挑选出有代表性的点进行测试（均匀分散，整齐可比）；高效率、快速、经济（科学）的方法；
正交表：一种特制的表，一般的正交表记为：Ln（mk）
n是表的行数，也就是需要测试组合的次数
K是表的列数，表示控件的个数（因素的个数，或因子个数）
m是每个控件包含的取值个数（各因素的水平数，即各因素的状态数）
如下图实例：L9（34）：叫4因素3水平
有4个控件，（字体、字符样式、颜色、字号）
每个控件有3个取值：
字体：仿宋、楷体、华文彩云
字符样式：粗体、斜体、下划线
颜色：红色、绿色、蓝色
字号：20号、30号、40号
9为需要测试的组合个数
二、正交表使用方法
1、列举取值并编号，生成取值表
2、根据控件和取值数选择一个合适的正交表
3、 把取值表与选择的正交表进行映射
正交表查询：
练习：字符属性设置程序
窗体中有4个控件，每个控件有3个取值
步骤一：把控件及其取值列举出来，并对取值进行编号
4个控件（因素）：字体、字符样式、颜色、字号
每个控件有3个取值
34=81种组合情况
步骤二：选择合适的正交排列表
正交表查询：
由于组合量非常大（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---不填
全部替换
补充：2007excel中文字替换。点击“查找和选择”中找到替换，再按下图，全部替换就可以了。
三、混合正交表工具
混合正交表工具：
下载下来，解压即可。
在实际工作中，很多情况都是因素（控件个数）和水平（每个控件的可选个数）不同，我们在现成的正交表中找不到对应的表格，此时我们就需要使用混合正交表工具来生成混合正交表；
使用步骤：
1、 制作取值表（不需要编号，列出数据即可）
2、 复制表格中的数据放在一个新建的txt文本文档中（不要改格式），保存到allpairs文件夹中（例如：test2.txt），allpairs文件夹：就是刚刚下载allpairs工具的文件夹。
allpairs文件夹：G:\2020202020\测试资料\day3\4-代码\allpairs
注意：在当前路径：shift+在此处打开命令窗口（就不用执行第三步和第四步骤了）
3、 Win+r再输入cmd进入控制台界面
4、 使用控制台代码进入allpairs文件夹中
G: 切换盘符
cd G:\2020202020\测试资料\day3\4-代码\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、 推迟—可以放在后续版本解决的问题，但是要详细写出修复的日期或版本
补充：测试用例的优先级
刚接触软件测试，先熟悉一下测试用例的优先级概念：
有时会听到0级别case的说法，其实这是对具有一定优先级的测试用例的说法。在实际测试实践中，测试用例根据重要性分成一定的等级。在不同的公司，可能测试用例的等级划分有所差异，但是基本大同小异。如下
就是一种测试用例等级划分的方法，共分为4级，由高至低依次为P0—P3。
P0： 核心功能测试用例（冒烟测试），确定此版本是否可测的测试用例，此部分测试用例如果fail会阻碍大部分其他测试用例的验证。
P1： 高优先级测试用例，最常执行以保证功能性是稳定的；基本功能测试，和重要的错误、边界测试。
P2： 中优先级测试用例，更全面的验证功能的各个方面，异常测试，边界、中断、断网、容错、UI等测试用例。
P3： 低优先级测试用例，不常常被执行，性能、压力、兼容性、稳定性、安全、可用性等等。
九、软件缺陷的严重程度划分（重要）
软件缺陷的严重程度划分：
1、严重问题(Blocker) 2、高级问题(Critical) 3、中级问题(Major) 4、 低级问题(Minor)
一. 严重问题(Blocker)
定义： 不能完全满足系统要求，系统停止运行，系统的重要部件无法运行，系统崩溃或挂起等导致系统不能继续运行。修改优先级为最高（1级），该级别问题需要立即修改。
1、系统崩溃
2、导致程序重启,死机或非法退出
3、死循环
4、数据丢失或异常
5、数据通讯错误。
6、硬件故障，系统悬挂
二. 高级问题(Critical)
定义： 严重地影响系统要求或基本功能的实现，且没有更正办法（重新安装或重新启动该软件不属于更正办法）。使系统不稳定、或破坏数据、或产生错误结果，或部分功能无法执行，而且是常规操作中经常发生或非常规操作中不可避免的主要问题，系统无法满足主要的业务要求，性能、功能或可用性严重降低。 修改优先级为高（2级），该级别需要程序员尽快修改。
1、功能不符合用户需求
2、数据计算错误
3、业务流程错误
4、程序接口错误
5、因错误操作迫使程序中断；
6、系统可被执行，但操作功能无法执行（含指令）；
7、功能项的某些项目（选项）使用无效（对系统非致命的）；
8、功能实现不完整，如删除时没有考虑数据关联；
9、功能的实现不正确，如在系统实现的界面上，一些可接受输入的控件点击后无作用，
对数据库的操作不能正确实现。
三. 中级问题(Major)
定义： 系统可以满足业务要求，系统性能或响应时间变慢、产生错误的中间结果但不影响最终结果等影响有限的问题。修改优先级为中（3级），该级别需要程序员修改。
1、数据长度不一致
2、内容或格式错误
3、响应时间较慢
4、功能性建议
5、提示信息不太准确
6、操作界面错误（包括数据窗口内列名定义、含义是否一致）；
7、简单的输入限制未放在前台进行控制；
8、虽然正确性不受影响，但系统性能和响应时间受到影响；
9、不能定位焦点或定位有误，影响功能实现；
10、增删改功能，在本界面不能实现，但在另一界面可以补充实现。
四. 低级问题(Minor)
定义： 使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能。界面拼写错误或用户使用不方便等小问题或需要完善的问题修改优先级为低，该级别需要程序员修改或不修改（4级）。
1、界面不规范；
2、辅助说明描述不清楚；
3、输入输出不规范；
4、长时间操作未给用户提示；
5、提示窗口文字未采用行业术语；
6、可输入区域和只读区域没有明显的区分标志；
7、必填项与非必填项应加以区别；
8、滚动条无效；
9、键盘支持不好，如在可输入多行的字段中，不支持回车换行；
10、界面不能及时刷新，影响功能实现。
禅道严重程度划分：
p1:致命 p2:严重 p3:一般 p4:建议
一、严重程序
P1：致命（该问题在测试中较少出现，一旦出现应立即中止当前版本测试）
造成系统崩溃、死机、死循环，导致数据库数据丢失， 与数据库连接错误；
主要功能丧失，基本模块缺失等问题。如：代码错误、死循环、数 据库发生死锁、重
要的一级菜单功能不能使用、内存泄漏、严重计算错误、无法登录、无法正常退出、
功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出， 关联程序间
调用冲突等。
P2：严重（不影响其他功能测试的情况下可以继续该版本测试）
系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用 但是不影响其他功能的测试。安全问题、稳定性等。如：软件中数据保存后数据库中显 示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等
P3：一般（实际测试中存在最多，解决率关系版本的优化程度）
功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多、容错性不好、大数据无响应或没有滚动条等
P4：建议（测试初期较多，优先程度较低；在测试后期出现较少，应及时处理）
界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢 失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等
十、软件缺陷的优先级
按照bug被处理的先后顺序也可以分为四个等级，分别为最高优先(Immediate)、高级优先(Urgent)、中级优先(Normal)、低优先级(Low)。不过需要注意的是，bug的严重程度与优先级之间并没有必然的联系。
bug处理的优先级是指bug处理的先后顺序，
一. 最高优先级(Immediate)——立即修复
这类bug的优先级是最高的，其要求开发人员必须立即修改这条bug，一般是指该缺陷导致程序完全不能满足产品的要求，基本功能明显未实现或不可用，阻塞测试流程与进度等。
二. 高级优先(Urgent)——紧急修复
该类bug被要求马上处理，主要是指系统实现的功能与预期结果要求较大，但不影响其他功能和主要的核心功能。
三. 中级优先(Normal)——正常处理
该类bug正常按照个人计划处理即可，主要是指界面、交互和特别小的功能实现出错且可以直接跳过此类bug继续进行测试。
四. 低级优先(Low)——有时间再处理
一些可修改或不可修改，或者是还不确定能否修改成功的bug，均不影响用户体验使用，不过修改了最好，一般如果要修改且时间来不及可以在后面几个版本中在进行修改即可。
注意：
不是严重程度越高，优先级就越高。
比如：购物车中商品价格错误，严重程度:5，优先级：3（没有影响系统，但是发布之前要修改好。）
总结：一般来说，验收的标准就是不能留下优先程度为一级和二级的bug，且一级bug必须在24小时类解决，如果解决不了则需要提前报告上级
禅道的优先级
1、立即处理
2、紧急处理
3、正常处理
4、有时间再处理
十一、软件缺陷分类
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.操作建议
备注：建议性的改进要求
软件缺陷信息
|
编号 |
属性名称 |
描述 |
|
缺陷ID |
唯一的缺陷ID，可以根据该ID追踪缺陷 |
|
|
缺陷状态 |
缺陷状态指缺陷通过一个跟踪修复过程的进展情况 |
|
|
缺陷标题 |
描述缺陷的标题 |
|
|
缺陷的严重程度 |
对软件产品的影响程度，分致命、较严重、严重、一般、低 |
|
|
缺陷的优先级 |
缺陷修复的先后顺序，即哪些缺陷优先修正，哪些稍后修正 |
|
|
缺陷所属模块 |
缺陷所属的项目和模块，要能较精确的定位至模块 |
|
|
缺陷记录者 |
提交缺陷的人员姓名 |
|
|
缺陷提交时间 |
缺陷提交的时间 |
|
|
缺陷处理人 |
处理缺陷的处理人 |
|
|
10 |
处理结果描述 |
对处理结果的描述，描述处理情况和代码修改说明 |
|
11 |
缺陷处理时间 |
缺陷处理的时间 |
|
12 |
缺陷验证人 |
对被处理缺陷验证的验证人（回测者） |
|
13 |
验证结果描述 |
对验证结果的描述（通过、不通过） |
|
14 |
缺陷详细描述 |
缺陷的重现步骤 |
|
15 |
缺陷环境说明 |
对测试环境的描述 |
|
16 |
必要的附件 |
如涉及到附件的或错误现象的图片等。 |