6月12日功能测试Day2

2.2边界值分析法 

 场景： 

开发人员常常在边界的位置容易出现问题，此时需要针对边界位置再测试

有 边界范围 的批量数据的输入类测试（重点关注边界）

对于等价类划分法的完善和补充

 范围： 

 上点 ：边界上的点（正好等于）   取值不考虑开闭区间 

 离点 ：距离上点最近的点（刚好大于、刚好小于）  取值类型看需求 

 内点 ：范围内的点（区域范围内的数据）  取中间的值 

 边界值最多7条用例，优化后最少5条 

 步骤： 

1.明确需求

测试目的

测试条件： 长度、类型、规则

2.确定有效和无效等价类

3.确定边界范围值

上点、离点（可优化）、内点

4.提取数据编写设计用例

注意：边界值只能覆盖数字，无法覆盖非数字、类型等，所以等价类和边界值要配合使用。

 优化： 

7个优化为5个点

上点：必选（不考虑区间开闭）

内点：必选（建议选择中间范围）

离点：开内闭外（考虑开闭区间，开区间选择内部离点，闭区间选择外部离点）

开区间：不包含

闭区间：包含

边界上的点可以优化： 开内闭外 

 2.2.1案例 

案例1：通过边界值法验证标题长度的合法性（要求：标题长度大于0，小于等于30个字符）

 2.3判定表法 

 解决多条件依赖 关系的方法

 案例引用：  （主被叫就是：拨打接通电话）

验证”若用户欠费或者关机，则不允许主被叫“功能的测试

说明：

等价类边界值分析法主要关注 单个输入类条件 的测试

并未考虑输入条件之间的各种组合， 输入条件与输出结果之间有相互制约关系 的测试

 使用场景： 

有多个输入条件，多个输出结果。输入条件之间 有组合关系 ，输入条件和输出结果之间有 依赖（制约）关系 

判定表一般适用于条件组合数量较少的情况（比如4个条件以下）

常见词汇：如果。。。那么。。。；若。。。则。。。

 判定表的构成： 

条件桩： 列出问题中的所有条件 ，列出条件的次序无关紧要。

动作桩：列出问题中 可能采取的操作 ，操作的排列顺序没有约束。

条件项：列出条件 对应的取值 ，所有可能情况下的真假值。

动作项：列出条件项的、各种取值情况下应该 采取的动作结果 

 规则： 

判定表中贯穿调价项和动作项的一列就是一条规则

假设有n个条件，每个条件的取值有（0，1） ，全组合有2的n次方中规则

 步骤： 

1.明确需求

测试目的

测试条件：根据需求列出

2.画出判定表

列出条件桩和动作桩

填写条件项，对条件进行全组合

根据条件项的组合确定动作项

简化、合并相似规则（有相同的动作）

3.根据规则编写测试用例

 2.3.1案例：文件修改规则 

如想对文件进行修改，需要遵守以下规则

输入的第一列字符必须是A或B

第二列字符必须是一个数字

如果第一列字符不正确，则给出信息L；

如果第二列字符不正确，则给出信息M；

如果两列字符输入正确，则修改文件成功。

 2.4场景法 

场景法，也可以叫 流程图法 ，是用流程图描述用户的使用场景，然后通过覆盖流程路劲来设计测试用例。

 意义 

用户使用角度：用户平时使用的不是单个功能，而是多个功能组合起来进行使用

测试人员角度：平时测试的都是单个功能点进行测试，容易忽略多个功能的组合测试

 适用场景 

一般在测试的后期，对于整个系统的模块功能进行全部的 组合测试 

测试的依据：业务流程图

 2.4.1流程图 

要使用场景法，必须使用流程图。

使用 标准图形 和 箭头 来表达程序或业务的走向

流程图对测试人员有什么用？

1.能够看懂流程图，设计业务用例

2.当需求文档信息不全时，能够根据需求，梳理出流程

网页版工具： https://processon.com 

Windows工具：visio

椭圆：表示流程的开始/结束

长方形：流程的处理或者操作

菱形：表示流程节点的判断（一般两种结果）

平行四边形：表示流程流转过程中数据的输入/输出

箭头线：表示流程的走向（箭头线上可以添加标记）

 2.5错误推荐法（扩展） 

场景：

时间紧，任务量大时使用。（没有时间写用例）

定义：

通过经验推测系统可能出现的问题

思想：

根据经验列举出可能出现的问题的清单，根据清单分析问题可能原因，推测发现缺陷

场景：

1. 时间紧任务量大 时，根据之前项目类似 经验 找出易出错的模块重点测试

2.实践宽裕通过该方法列出之前出现问题较多的模块再次测试

 3.0测试理论第三章 

目标

按照缺陷报告的模板提交缺陷

理解缺陷的跟踪流程

使用禅道管理用例和提交缺陷

 3.1软件的缺陷 

 缺陷的定义： 

软甲在使用过程中存在的任何问题（如：错误、异常、失效等），都叫软件的缺陷，简称bug

 软件缺陷的判定标准： 

软件未实现需求规格说明书中明确要求的功能- -少功能 

软件出现了需求规格说明书中指明不应该出现的错误- -功能错误 

软件实现的功能超出需求规格说明书指明的范围- -多功能 

软件为实现需求规格说明书中虽未明确指明但应该实现的要求- -隐性功能错误 

软件难以理解，不易使用，运行缓慢，用户体验不好- -不易使用 

 一般事项： 

对于满足标准1、2的缺陷，一般都属于中高优先级的缺陷

对于满足标准5的缺陷，一般属于建议级别的缺陷（优先级较低）

特殊情况除外，例如需求中有明确的性能要求或者其他规范要求

 缺陷产生的原因： 

需求阶段：需求描述不易理解，有歧义，错误等

设计阶段：设计文档存在错误或者缺陷

编码阶段：代码出现错误

运行阶段：软硬件系统本身出现故障导致软件缺陷

比如：

需求阶段：产品对于需求本身理解不透，没有领悟到用户真实意图（或需求发生变化）

设计阶段：开发框架不稳定，设计逻辑不严谨

编码阶段：代码写错了，单词写错了等

故障解决：对于系统不太熟悉，修改出现新问题

 缺陷生命周期： 

需求文档-设计-编码- 测试（发现bug) -故障分类-故障隔离-故障解决

注入bug->发现bug->修复bug

 软件缺陷的核心内容： 

缺陷描述：发现缺陷以后描述，让别人看懂

缺陷提交：指派人、优先级、类型等

 具体： 

缺陷的标题：描述缺陷的核心问题  测试错误结果的描述 

缺陷的预置条件：缺陷产生的前提  相当于用例中的预置条件 

缺陷的复现步骤：复现缺陷的过程  相当于用例中的执行步骤 

缺陷的预期结果：希望得到的结果  相当于用例中的预期结果 

缺陷的实际结果：实际得到的结果  和预期结果比较（和预期结果不一样） 

缺陷的必要附件：图片、日志等信息（ 证据 ） 方便开发快速找出问题 

 缺陷报告的其他要素 

 1.缺陷的编号： 

能够唯一的表示一个缺陷

 2.缺陷的状态： 

描述缺陷生命周期的过程

New：新建 表示缺陷的产生

Open：打开 表示开发确认通过

rejected: 拒绝 表示开发确认不通过

inprogress: 进行中 表示开发正在修复缺陷

Closed：关闭 表示测试通过，已关闭

Postponed：延期 表示开发延迟修复

fixed： 已修复 表示开发以及修复完成

reopen：测试不通过 表示测试不通过，重新打开

 3.缺陷的所属模块： 

类似于用例的所属项目，描述缺陷产生的模块范围

 4.缺陷优先级： 

Priority：24h之内必须解决

Priority1：发布前必须修复

Priority2：可以在下一个版本中修复

 5.严重程度： 

严重（s1）：主功能

一般（s2）：次功能

微小（s3）：易用性界面

建议（s4）：建议性问题

 缺陷报告示例 

 ID、模块、严重程度、优先级、缺陷类型、状态、缺陷标题、预置条件、重现步骤、预期结果、实际结果、附件图片 

 缺陷的跟踪流程 

提交缺陷——分派缺陷——验证缺陷（是否为bug）——处理缺陷——回归测试

面试题：

当你发现bug以后，你会怎么做？

 确认bug可复现，是否为bug 

 提交缺陷注意事项 

可重现：缺陷可以复现

唯一性：一个缺陷报告中上报一个问题

规范性：符合公司或者项目要求

 缺陷编写规范 

准确：描述的信息正确

具体：有细节且是真实特定

简介易懂：描述简单容易理解

次序清晰：描述缺陷过程有条件，有先后顺序

注意事项：

确保上报的bug是准确的

描述尽可能简介易懂具体

不能使用感情色彩的词语

不能使用模棱两可的词汇

不能使用人称代词

 3.1.1面试题 

 在实际测试中如果出现不可复现的bug怎么办？ 

经过多次复现后，还是没有出现。此时在本地记录当前的问题

回顾当时操作的流程及测试环境的配置要求，确认是否由于操作失误或者环境临时故障引起

请开发协助（自己）查找当前测试模块是否有对应的日志信息（日志的位置可以问开发）

再考虑更换一套环境查看是否能够复现上述问题

在后续的版本中测试，此时需要关注当时测试该功能时是否还出现上述的问题

在后续版本还出现过，需要开发协

助打印日志进行分析定位，同时测试需要提交bug

小总结：

两天时间回顾前面测试基础，明天正式开始功能测试

ps：晚上回去赶期末大作业！