软件缺陷

软件缺陷概念

Bug有时也被泛指因软件产品内部的缺陷引起的软件产品最终运行时和预期属性的偏离。

产生原因

1.需求不明确2.软件结构复杂3.编码问题4.项目期限短5.使用新技术

类型

错误、遗漏、额外实现

准则

Correct（准确）：每个组成部分的描述准确，不会引起误解

Clear（清晰）：每个组成部分的描述清晰，易于理解

Concise（简洁）：只包含必不可少的信息，不包括任何多余的内容

Complete（完整）：包含复现该缺陷的完整步骤和其他本质信息

Consistent（一致）：按照一致的格式书写全部缺陷报告

状态

缺陷报告

每个缺陷都有一个唯一的编号。缺陷要有重现步骤。一个缺陷生成一条报告。缺陷报告要整洁、完整。

1.项目

2.编号

缺陷ID用来唯一标识缺陷，在缺陷管理中，缺陷ID不可重复，即使缺陷被删除，ID也不可复用。缺陷ID一般用阿拉伯数字标识即可，如1、2、3等。有的公司有自己的格式规定，则按照公司规定编写即可。

3.标题

标题：在xx地方做xx操作发现xx问题。

4.步骤

清晰明了，可操作性，可重现

5.期望结果

期望结果从需求（SRS）中获得，并且应该包含隐形需求。

6.实际结果

如果实际结果与期望结果一致则测试通过，如果实际结果与期望结果不一致则测试不通过。

如何确保实际结果是正确的？

1.培训2.规范流程（交叉测试）

7.严重级别

严重性顾名思义就是软件缺陷对软件质量的破坏程度，即此软件缺陷的存在将对软件的功能和性能产生怎样的影响。

致命A类：软件根本无法使用或者会导致系统问题。例如，软件的意外退出甚至操作系统崩溃，造成数据丢失。

严重B类：严重影响用户使用。例如，由于单功能失效导致多个相关功能均失效

一般C类：影响用户使用。例如，软件的单个功能失效。

提示D：软件界面的细微缺陷，例如，某个控件没有对齐，某个标点符号丢失等。

8.出现频率

必现

偶发：1.按照固定频率出现。2.不按照固定频率出现。3.只出现一次

9.测试环境

测试环境=硬件环境+软件环境+网络环境+数据+工具

10.优先级

该字段由研发团队确定，根据缺陷的严重度，决定缺陷修复的先后次序，原则上修复优先级与缺陷严重度相同。严重度级别越高的缺陷，修复优先级也越高。但是，严重性和优先级并不总是一一对应。有时候严重性高的软件缺陷，优先级不一定高，甚至不需要处理，而一些严重性低的缺陷却需要及时处理，具有较高的优先级

11.初步定位

找到问题的根源

12.发现人

用于追溯

13.附件

软件缺陷流程

软件测试的定义和原则

1.定义

使用人工和自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别

2.目的

发现被测对象与用户需求之间的差异，即缺陷。

通过测试活动发现并解决缺陷，增加人们对软件质量的信心。

通过测试活动了解被测对象的质量状况，为决策提供数据依据。

通过测试活动积累经验，预防缺陷出现，降低产品失败风险。

3.原则

1.测试应基于客户需求。
2.测试要尽早进行。
3.穷尽测试是不可能的。
4.遵循GoodEnough原则。（GoodEnough原则是指测试的投入与产出要适当权衡）
5.测试缺陷要符合“二八”定理。（一般情况下，软件80%的缺陷会集中在20%的模块中）
6.避免缺陷免疫。（测试用例被反复使用，发现缺陷的能力就会越来越差；测试人员对软件越熟悉越会忽略一些看起来比较小的问题，发现缺陷的能力也越差）
7.测试证明软件存在缺陷，无法证明软件不存在缺陷。（测试活动可以减少软件中存在未被发现缺陷的可能性，降低漏测风险）

测试用例

测试用例本质是上一个包含输入、步骤、期望结果等的文本。

编写

三大核心要素

标题

用概括性的语言描述出测试用例的测试点，测试用例的标题应该清楚的表达测试用例的用途，也就是看见标题就大概能知道测试什么，步骤是什么，预期结果是什么。

步骤

执行测试用例时参考的步骤。步骤应该清晰明了，无二义性。测试人员根据测试步骤能够完成测试操作。测试步骤应该尽量详细描述每一个操作步骤，能够让一个不熟悉的人也能按照测试步骤去执行测试用例。

期望结果

期望结果就是测试用例预期的输出结果。预期结果应该从需求中获得并且应该包含隐性需求。如果实际测试结果与期望结果一致则测试通过，如果实际结果与期望结果不一致则测试不通过。

八大要素

标题、步骤、期望结果、项目、编号、优先级、测试输入、预置条件。

编号：由字符和数字组成，能够唯一的标识一条测试用例，并且容易识别。一般按照：产品编号/产品名称测试阶段测试项编号。001/002/003。。。专业的编号：产品编号ST模块名称0001产品编号IT接口名称0001产品编号UT函数名称0001

重要级/优先级别：高：基本功能、核心业务、重要特性以及实际使用频率高。中：介于高和低之间。低：非基本功能、非核心业务、非重要特性及实际实际频率低。

禅道编写步骤

第一步：添加用户，开发人员、测试人员和项目经理

第二步：退出管理员账户，进入项目经理账户，并且创建产品

第三步：进入测试账户，提交bug

第四步：进入开发人员账户，解决bug

第五步：

返回测试人员账号，进行回归测试

设计

穷举法

穷举法用于测试就是穷举测试，它是一种理想状态下的测试：把所有可能出现的值一一列举，挨个覆盖。

优点：测试最全面，是最纯粹的测试。

缺点：工作量大，无法在固定的时间完成，甚至无法完成。

等价类

将数据划分为不同分区使得给定分区内所有成员被以相同方式处理

有效等价类：包含有效值的等价分区称为有效等价类。符合程序要求且有意义的输入数据。

无效等价类：包含无效值的等价分区称为无效等价类。不符合程序要求无意义的输入数据。

可以使用一个用例来覆盖多个有效等价类但是当使用无效等价类，应单独测试，不能与其他无效等价类组合，以保证没有失效屏蔽。

边界值

在区域的边界上的行为往往比在区域内的行为更容易出现错误，是等价类划分的扩展，但仅适用于等价类是有序的、由数字或顺序数据组成。等价类的最小和最大值（或第一和最后的值）是其边界值。选取5个值：最小值、略大于最小值、正常值、略小于最大值、最大值。

上点：边界上的点。

如果是闭区间：上点就在域内。

如果是开区间：上点在域外。

离点：离上点最近的点。

如果是闭区间：离点在域外。

如果是开区间：离点在域内。

内点：范围内的任意的点。

判定表法

判定表驱动法，或者决策表法。该方法是根据需求描述建立判定表后，导出测试用例的方法。判定表法是分析和表达多种输入条件进行组合完成不同动作的一种工具。应用于复杂的逻辑关系和多种条件组合的情况。贯穿条件项和动作项的一列就是一条规则，即决策表中的每一列就是一条规则，每一列都可以设计一个测试用例。

条件桩：列出问题的所有的条件。通常认为列出的条件的次序无关。

条件项：根据条件桩列出所有条件的取值。取真值和假值。

动作桩：列出规定的所有可能采取的操作。

动作项：列出在条件项的各种取值情况下应该采取的动作。

规则：任何一个条件组合的特定取值及相应要执行的操作称为规则。

若两条或者多条规则的动作项相同，条件项只有一项不同，则可以将该项合并。

判定表思路

1.根据需求列出所有的条件项和动作项。

2.确定规则数：2^n(n是条件数)。

3.根据规则数建立判定表。

4.填写判定表。

5.化简判定表。

6.根据判定表设计测试用例。

因果图法

将复杂逻辑关系的需求转化为判定表的一种中间分析方法，其最终的目的是为了得到判定表。

因果图使用简单的逻辑符号，以直线连接左右节点。左节点表示输入状态(或者称为原因)，右节点表示输出状态(或者称为结果)

c1:表示原因，通常位于图的左边，e1表示结果通常在图的右边。c1和e1均可取0和1。0表示某状态不出现，1表示某状态出现。

场景设计法（流程分析法）

是场景法的子项。该方法主要针对业务流程测试使用，需要考虑用户的使用的流程。流程分析法是一种宏观的测试方法。将宏观的功能点替代语句对软件系统的用户使用场景做测试，主要从用户角度考虑，使用软件会有哪些流程，所以叫做流程分析法。

优点：降低了设计用例的难度，只需要搞清楚各种流程就可以设计出测试用例而不需要太多测试方法和经验。2.在测试时间紧迫的情况下，可以快速的跑一下流程，然后有时间的话再进行其他测试。

基本流：通过业务流程输入都为正确的，能够达到目标的流程。

例如：ATM取款:插入银行卡、输入密码、输入金额、取钱、取卡。

备选流：通过业务实现流程时，因错误操作或者异常输入，导致流程存在反复，但是最终能够完成期望业务的流程。

例如：插入银行卡、输入错误密码、再次输入密码。

异常流：通过实现业务流程时，因错误的操作或者异常输入，导致业务没有正确完成。

例如：插入银行卡、输入错误密码4次、吞卡。

正交试验法

从大量的实验点中挑选出适量的、有代表性的点，依据Glois理论导出“正交表”，从而合理的安排实验的一种实验设计方法。正交数据表明：如果两两组合测试没有问题，就认为其他组合测试出问题的概率很小。

行数：(Runs)：正交表中行的个数，即试验的次数。也是我们通过正交实验设计出的测试用例的个数。

因素数：(Factors)：正交表中列的个数，即我们要测试的功能点。(因子)

水平数：(Levels)：单个因素能够取得的值的最大个数，即要输入的功能点的输入条件。(状态)

步骤：

1.明确有哪些输入，以及这些输入可能的取值。(输入(因子数/因素数)，可能的取值(状态/水平数))

2.根据因素数和水平数选择合适的正交表。

考虑输入(因子数)的个数。考虑输入的取值(状态数)的个数。选择合适的或者接近的正交表。考虑正交表的行数，一般取行数最少的一个。

3.如果因素数和水平数没有合适的正交表则需要选择接近的正交表。

状态数相同，因子数接近并大于因子数

4.根据选择的正交表编写用例，一行代表一条用例。

5.补充测试用例。补充那些在实际工作中也必须考虑的多组合情况。

状态迁移法

抽象出待测系统的若干状态以及状态之间的转换条件和转换路径然后从状态迁移的路径覆盖的角度设计测试用例。状态迁移法的目标是设计足够多的测试用例覆盖系统的状态、状态-条件的组合、状态的迁移路径。

步骤：

1.首先根据需求提取出全部的状态：比如播放状态可以变为暂停状态，还可以变成停止状态。

2.绘制状态迁移图。(正常状态迁移、异常状态迁移)

一般我们从系统最初的状态开始。碰到异常状态迁移以及之前已经出现过状态路径就可以停止。路径数量从图的最外围算起最为简单方便。

3.根据状态迁移图确定测试路径。

4.选取测试数据针对每条路径设计测试用例

错误猜测法

基于经验和直觉推测程序中所有可能存在的各种错误，从而针对性的设计测试用例的方法。列出程序中所有可能有错误的和容易发生错误的特殊情况，根据它们选择测试用例，当测试用例的数量不够或者达不到标准时可以使用该方法来补充测试用例。

思路：

1.根据经验预计软件在哪些情况下可能会出现问题。

2.根据经验推测开发容易出错的地方。

3.根据业务流程经验，哪块业务复杂容易出问题。