软件测试学习第一部分--软件测试理论基础

第一部分：手工测试 软件测试基础理论 第三讲（缺陷报告） 一、测试人员的主要工作职责 （1）编写测试计划 （2）编写测试用例 （3）执行测试，发现缺陷提交缺陷报告 （4）验证所有缺陷是不是得到修复 （5）编写测试总结报告 二、缺陷报告的组成 1、缺陷编号（Defect ID） 提交bug的顺序 说明： （1） 全项目组统一编号 （2） 如果使用管理工具，缺陷编号会自动生成

2、缺陷标题（summary） 简明扼要的描述一下该bug

3、缺陷的发现者（Detected By） 一般为自己

4、发现缺陷的日期（Detected on date） 一般就是发现缺陷的当前

5、缺陷所属的模块（subject） 在测试程序的那个功能模块或菜单时发现的bug 开发经理会根据bug所在的模块，找到bug的负责人

6、发现缺陷版本（Detected in release） 在测试程序的哪个版本时发现的bug

27、指派给谁处理（Assigned to） 测试人员把缺陷报告指派给开发经理，开发经理会根据缺陷所在的模块，需要再次指派给具体的开发人员

8、缺陷的状态（status）（重要） 表明缺陷所处的情况或处理结果。 （1） 测试人员发现bug提交缺陷报告给开发经理，把bug的状态写成：new(新提交) （2） 开发经理验证提交的bug，如果是Bug，把bug的状态改为：open(打开的bug、开发组承认的Bug)；如果不是bug,把缺陷的状态改为：rejected(被拒绝的缺陷)，是缺陷需要把缺陷指派给bug的负责人。 （3） 开发人员，看到指派给自己的bug ，进行Bug的修复，修改完后，把bug的状态改为：fixed(已经修复的bug) （4） 测试人员对修复的bug进行返测，如果反测成功，把bug的状态给为：closed(关闭bug、反测成功的bug)，如果返测失败把bug的状态改为：reopen(重新打开的bug、返测失败的bug)

以上的过程成为“缺陷（报告）的处理流程，也称之为“缺陷的跟踪过程”，或称作“缺陷的生命周期” New---open-Fixed--closed

9、缺陷的严重程度（Severity）（重点） 表明bug 多糟糕，或对软件造成多大影响 Urgent：造成死机、崩溃等致命问题 Veryhigh：非常严重的bug。 Hight：比较严重的、大的bug Medium：中等程度的bug Low：小的bug

以后再提交缺陷时会有一个专门的文档来说明什么样的错误时什么等级 Bug Level Definition 缺陷等级定义

说明：每个单词在不同项目中代表的含义是不尽相同，我们应该在专门的文档中给出比较详细的评判标准，这样才会减少争议。 Performance :性能 Function:功能

10、缺陷的优先级（priority）（重点） 希望缺陷在什么时间内或者在程序的哪个版本中解决 Urgent：立刻修改，否则会影响开发或测试的进度 Veryhigh：本版本修改（本周期修改） Hight：下一个版本修改（下一周期修改） Medium：发布之前修改（下一版本修改） Low：允许在发布中存在（发布之前修改）

优先级需要考虑的因素： （1） 严重程度：一般越严重，优先级越高 （2） 影响的范围：印象的范围越大，优先级越高 （3） 开发组的进度压力：压力越小，优先级越高 （4） 解决bug的成本问题：成本越低，优先级越高

11、缺陷描述（description）（重点） 把发现缺陷的步骤、使用的数据记录下来，让程序员通过描述能够再现bug

三、常见问题 1、严重程度和优先级不是严格成正比的 例如：界面问题的严重程度一般比较低，但优先级可能最高----立即修复。 错误提示中的错别字严重程度低，因为其好修改，优先级可能最高---立即修复 一些严重的错误，它不影响其他功能，但是难解决其严重程度高，但优先级可以低些 2、严重程度确定好后，一般不做修改；优先级可能会根据实际情况，适当修改 3、在产品发布之前有些缺陷可能解决不了，但一定要做好风险分析 例如：一些用户不常用的功能，或发现错误时不会造成很大的损失的 四、缺陷报告用途 （1）记录bug （2）对bug进行分类（发现者、日期、版本、模块、严重程度、状态。。。。） （3）跟踪bug（new->closed） （4）对bug总结、分析统计

五、如何识别bug （1）参考测试用例的预期结果，实际结果与预期结果不一致，就是bug （2）参考需求文档，与需求不一致就是bug （3）讨论 （4）参考第一讲中缺陷的5点定义

六、写缺陷报告时注意的问题 说明：有些bug是不可重新的。可以称为随机bug,也要提交，要注明一下 七、缺陷报告的处理流程 参考缺陷状态（status ）笔记 作业：至少提交三个缺陷报告 第四讲（测试用例） 一、 测试用例基本概念 测试用例是在测试执行之前由测试人员编写的指导测试过程的重要文档，主要包括：用力编号、测试目的、用例描述、预期结果 二、测试思想：

“穷举测试”是最全面的测试，但是时间成本太高，在实际中不能采用。编写用例的方法，是在保证测试质量的前提下，使用最少的数据、最少的成本达到最优的测试效果。 不做穷举测试，是存在风险的，所以如果有时间可以再适当的补充

三、编写测试用例的方法 （1） 等价类划分 （2） 边界值法 （3） 因果图法 （4） 判断表法 （5） 正交排列法 （6） 场景法 （7） 测试大纲法

四、 写测试用例的参考 （1） 文档，尤其是需求文档 （2） 参考已经开发出来的程序 （3） 讨论

五、 测试用例的用途 1、 防止遗漏 使软件测试的实施重点突出、目的明确、确保需求功能不能被遗漏 2、 版本重复测试 快速正确的进行版本重复测试 3、 监督过程 可以准确有效的评估工作量 4、 评价结果 对产品进行评估，对测试完成情况进行评价 5、 提高效率 避免盲目测试 6、 缩短周期 版本升级或修改时只需要修正少部分测试用例，资源复用

六、 写用例时注意的点 1、在写测试用例之前，还要明确项目对用例的具体要求 ———测试用例编号如何命名 ———测试用例应该提交到什么地方 ———测试用例用到的附件命名规则、存放位置 2、测试用例是需要跟新和维护的，是一个不断修改和完善的过程 3、测试用例需要正式的评审 4、测试用例覆盖系统的程度，决定测试的覆盖程度

七、 对测试人员的要求 1、基本要求 在编写一条测试用例时，要求步骤清楚准确易读，预期结果明确 如有特殊的设置，预期条件等要明确写出 如果有输入数据一般要给出输入数据取值 如果有附件，要给出附件存放位置名称 检验标准 写完用例后让别人照着自己的用例去执行测试可以很顺畅的执行下来 2.高标准要求 测试用例写的有条理逻辑性强，可以按照功能点分类操作顺序等逻辑编写，而不要一会测试这，一会测试那 功能覆盖全面深入，能够发现软件中的更多缺陷 检验标准 能把软件中的缺陷尽可能多的找出来，按照你的测试用例测试完软件、遗漏的缺陷最少要求测试人员最终达到的目的，是一个需要长期积累学习的过程

第四讲（等价类划分、边界值法） 1、 等价类划分法

（1） 应用场合 只要有数据输入的地方就可以使用。把可以输入的无穷多的数据进行分类，从中挑选一些代表进行测试即可 （2） 核心概念  有效等价类 对程序的规格说明有意义、合理的输入数据集合，程序接受到有效数据，应该正确计算，执行  无效等价类 对程序的规格说明无意义，不合理的输入数据集合，程序接受到无效数据应给出错误提示，或者根本无法输入

有效等价类主要验证程序的正常业务功能实现， 无效等价类验证程序的异常处理能力（健壮性）

（3） 使用等价类划分分析程序 案例： 需求：如图： 功能展示：如图 首先，明确测试对象——“第一个数”文本框 说明：在测试“第一个数”文本框时。“第二个数”文本框要填写正确 1、 分析需求，划分等价类（有效等价类、无效等价类）  有效等价类 -99——99的整数  无效等价类 ①<-99的整数 ②>99的整数 ③为空 ④非整数 2、 细化等价类 依据的一般是隐式需求，比如，数据再内存中存储的形式，数据在数据库、程序中的类型  整数在计算机中是按照“补码存储”整数和负数的补码计算方式不同，有必要单独测 把有效等价类-99—99细化为： ①-99—-1的整数 ②0—99的整数  非整数可以细化为： ① 小数 ② 字符 ③ 汉字 ④ 符号 3、 建立等价类表（熟练以后直接做该步） 有效等价类 序号 数据范围 1 -99—-1的整数 2 0—99的整数

无效等价类 序号 数据范围 1 <-99整数 2 >99的整数 3 为空 4 小数 5 字母 6 汉字 7 符号 4、 根据等价类表，编写用例 从每个等价类中至少挑选出一个数据编写用例

在分析“第二个数”文本框跟分析第一个是一样的 说明：保证“第一个数”文本框填写正确

2、 边界值法 案例： 跟等价类划分采用同一个（也两个文本框分开分析） 对上边等价类划分进行补充 （1）应用场合 有数据输入的地方，一般就可以使用。