软件测试之功能测试完整版

一、测试项目启动与研读需求文档

（一） 组建测试团队

1、测试团队中的角色

2、测试团队的基本责任

• 尽早地发现软件程序、系统或产品中所有的问题。
• 督促和协助开发人员尽快地解决程序中的缺陷。
• 帮助项目管理人员制定合理的开发和测试计划。
• 对缺陷进行跟踪、分析和分类总结，以便让项目的管理人员和相关的负责人能够及时、 清楚地了解产品当前的质量状态。
• 帮助改善开发流程、提高产品开发效率。
• 促进程序编写的规范性、易读性、可维护性等

3、测试团队与开发团队的 3 种模式

（1）以开发为核心，测试只是开发队伍的一部分，也就是开发团队中有测试人员，但 没有形成独立的团队

（2）以项目经理为核心，开发小组和测试小组并存，隶属于项目经理领导。

（3）项目经理、开发组长和测试组长“三足鼎立”，测试团队具有独立的、权威的地 位。

同时，我也准备了一份软件测试视频教程（含接口、自动化、性能等），需要的可以直接在下方观看，或者直接关注VX公众号：互联网杂货铺，免费领取

软件测试视频教程观看处：

B站封神的接口测试教程，30天练完70个项目实战（含自动化测试、性能测试），学完即就业，永久白嫖！

（二）软件质量需求

1、软件质量需求的分类

• 软件质量需求用于确定测试目标。
• 测试目标包括：功能、性能、界面、易用性、兼容性、安全性、可用性/可靠性、可维 护性、可扩展性等。
• 功能以外统称非功能。

2、功能

• 软件能做什么？
• 需要做什么？
• 怎么做是正确的？
• 哪些功能要测试、哪些功能不需要测试？
• 哪些功能重要，哪些不重要？
• 哪些功能先实现或先测试？

3、性能

• 反映软件运行时的效率和占用资源情况的能力。

       时间特性：时间短、速度快、效率高。
       资源特性：占用资源（CPU、内存、硬盘、网络）少。

4、界面（UI）

• 布局合理；
• 控件位置恰当；
• 文字没有乱码、字体大小合适；
• 颜色使用恰当；
• 图片、表格恰当、舒适、美观。

5、易用性

• 在指定条件下使用时，软件产品被理解、学习、使用和吸引用户的能力。

6、兼容性/可移植性

• 指软件产品从一种环境迁移到另一个环境的能力，反映一个软件与不同的硬件环境、操 作平台、其他软件的共同使用的能力。

        包括与不同硬件、平台、软件自身不同版本、其他软件、数据的兼容。

7、安全性

• 指软件产品保护信息和数据的能力。

8、可用性/可靠性

• 指系统正常运行的能力或程度，可用性=正常运行时间/（正常运行时间+非正常运行时 间）×100%。

        可用性指标一般要求达到 4 个 9 即 99.99%（全年 52 分钟不正常工作）或 5 个 9 即 99.999%（全年 5 分钟），对一些军事系统，可用性高达 7 个 9（99.99999%（全年 失效时间不超过两秒）。
        一般测试时间不足，可以采用空间换时间的办法，如在高负载情况下进 行为期一周 或一个月的测试，以判断其可靠性。
        关注 MTTF（平均无故障时间）、MTTR（平均恢复时间）、MTBF（平均失效间 隔时间）。

9、可维护性

• 指软件产品可被修改的能力。

        修改可能包括修正、改进或软件对环境需求和功能规格说明变化的适应。
        可维护性的软件应该是易改变的、稳定的、易测试的。

10、可扩展性/可伸缩性测试

• 通过很少的改动就能实现整个系统处理能力的增长。

        如在部署两台服务器时测试系统性能（容量，即最大负载），再部署四台、八台服 务器时分别进行系统容量的测试，看其容量是否为上次（两台、四台）实验值的两 倍或接近两倍。如果是，系统就具有良好的可伸缩性。

（三）研读需求文档

1、测试需求分析的过程

• 收集与研读文档，提出并解决问题，整理需求信息
• 功能拆分、功能描述/需求整理
• 编写测试点
• 需求评审

2、研读需求文档

2.1 研读文档主要任务

• 提取有用的需求信息
• 提出需求中不清晰、不理解、不明白的问题

 和用户、业务人员、产品经理或产品设计人员、开发人员等沟通

2.2 怎么研读文档

• 分析思路

 分析软件的用户群，分析用户的实际需要；
 分析软件的开发环境、开发语言、数据类型；
 分析软件架构、软件的运行环境和平台、数据库类型；
 分析软件要实现哪些目标（功能、性能、界面、易用性、兼容性、安全性）以 及具体的要求是什么；
 分析软件有哪些功能，每种功能要完成什么业务，这些业务应该怎么实现，业 务逻辑是什么，业务流程是怎样的，业务规则有何要求；
 分析功能或业务间的联系，哪些业务更关键或重要；
 明确测试周期，测试目标，测试范围。

• 细节上

 分析每个模块或功能上实现的功能
 设计的开发原理包括数据类型
 从用户使用场景角度分析业务流程
 记录业务规则

• 实施

 以情景再现的形式写出需求信息。

2.3 研读需求文档案例

• 拿到一个项目，怎么入手？
• 即时贴程序部分需求说明

 便签的数量最多为 50 个
 便签标题字数最多为 40 个字节
 便签的正文文字数量最多为 200 个
 年份只能设置在 1900－2100 之间

（四）需求评审

1、意义

• 对软件需求进行正确性的检查。
• 保证软件需求的可测试性。
• 通过产品需求文档的评审，与市场、产品、开发等各部门相关人员沟通，使得大家 认识一致，避免在后期产生不同的理解，引起争吵。
• 通过产品需求文档的评审，更好地理解产品的功能性和非功能性需求
• 在需求文档评审通过后，测试的目标和范围就确定了。虽然此后会有需求的变更， 但可以得到有效的控制，这样可降低测试的风险。
• 评审是否完成是以需求文档获得多方“邮件确认”或“签字”通过为标志的。这不 应该只体现在“签字”形式上，更重要的是达到下面的结果。

 所有参与方达成一致。
 已发现的问题被阐述清楚、被修正。

2、需求评审的质量要求

• 正确性
• 完备性
• 易理解性
• 一致性
• 可行性
• 易修改性
• 可测试性
• 可追溯性

3、需求评审的参加人员

• 用户代表
• 需求人员
• 产品经理
• 项目经理
• 开发人员
• 开发经理
• 测试人员
• 测试经理
• 市场经理
• 质量保证人员

4、测试人员参与评审时的注意事项

• 明确自己的角色和责任。
• 熟悉评审内容，为评审做好准备，做细做到位。
• 在评审会上，针对问题阐述观点，而不是针对个人。
• 可以分别讨论主要的问题和次要的问题。
• 在会议前或会议后可以就存在的问题提出自己建设性的意见。
• 提高自己的沟通能力，采取适当的、灵活的表述方式。
• 对发现的问题跟踪下去。
• 应该在需求形成的过程中进行分阶段的多次评审，而不是一次评审。
• 测试人员要善于提问，多思考

 这些需求都是用户提出来的吗？
 有没有画蛇添足的需求？没有漏掉什么需求吗？
 和竞争对手的产品做过比较吗？我们的产品优势体现在哪里？
 是否正确地描述了每个需求？这条描述是否存在二义性的问题？
 我的理解和文档作者的理解一致吗？

二、测试需求分析与测试用例设计

（一） 界面中的控件知识

1、文本框和密码框

2、单选按钮、组合列表框、数码框

3、复选框

4、列表框

5、命令按钮

6、其他界面元素

三、 测试需求分析与测试用例设计方法

1、场景法

1.1 测试点/检查点

• 测试时应该考虑可以测试的诸多方面。

1.2 场景法概述

• 场景法模拟用户操作软件时的情景，主要用于测试系统的业务流程。
• 当拿到一个测试任务时，我们先要关注它的主要功能和业务流程是否正确实现，这 就需要使用场景法来完成测试。

1.3 场景的定义

• 场景用来描述软件操作的路径。
• 基本流
• 按照正确的业务流程来实现的一条操作路径（模拟正确的操作流程）。
• 备选流
• 导致程序出现错误的操作流程（模拟错误的操作流程）。

1.4 场景法的分析步骤

• 分析软件需求
• 从用户使用情景角度，写出业务流程和业务规则
• 写出基本流场景和备选流场景

1.5 场景法案例：ATM 机取款

步骤一：分析业务流程（可以绘制流程图）

步骤二：描述程序的基本流及备选流

1、基本流（正确的流程）

（1）插入银行卡：客户将银行卡插入 ATM 机的读卡器
（2）验证银行卡：ATM 机从银行卡的磁条中读取账户代码，并检查它是 否属于可以接受的银行卡
（3）输入密码：ATM 机要求客户输入密码
（4）验证密码：确定该密码是否正确 
（5）进入 ATM 主界面：ATM 显示在本机中可用的各种选项
（6）选择取款并输入金额：客户选择“取款”，并选择取款金额
（7）ATM 机验证：ATM 机进行验证账户余额是否满足以及总取款金额 是否满足要求，验证 ATM 机内现金是否够用
（8）更新账户余额、出钞：验证成功，更新账户余额，输出现金，提示 用户收取现金
（9）返回主界面

2、备选流（各种错误情况）

（1）银行卡无效：提示错误并退卡
（2）密码错误：提示错误，并判断是否 3 次错误
（3）密码 3 次错误：吞卡
（4）账户余额不足：提示错误并退卡
（5）总取款金额超出当日可取限额：提示错误并退卡
（6）ATM 机余额不足：提示错误并退卡

步骤三：根据基本流和备选流生成不同的场景

2、等价类划分

2.1 案例引入

测试两位数加法器（学生思考、讨论、陈述）

2.2 等价类划分核心思想

• 通过需求分析，找出程序的输入域。
• 将输入域划分成若干类。
• 每一类中选取代表性数据等价于这一类中的其他值。

2.3 等价类划分的步骤

• 需求分析
• 划分等价类（根据需求，有效等价类、无效等价类）并细化（根据计算机知识）

2.4 等价类划分案例

步骤 1：需求分析

• 阅读文档 ：

 借助开发知识
 与开发或用户沟通
 了解用户群及行业知识

• 写出需求：

 -99~99 之间的整数

步骤 2：划分等价类并细化

• 有效类

 -99 到 99 之中的整数
 细化 ：负数、0 、正数

• 无效类

 超范围 ：<-99 或 >99
 非法类型 ： 浮点数 、 字符（串）

2.5等价类划分注意事项

• 不但要考虑有效等价类，也要考虑无效等价类
• 两块划成一块（等价类划分过粗），结果？

 遗漏一种测试情况
一块划成两块（等价类划分过细），结果？
 冗余测试

• 仔细划分，审查划分

 过于粗略可能会漏掉软件缺陷
 积累经验

3、边界值分析

3.1 边界值分析的思想与步骤

• 分析需求，找出边界。
• 写出边界值

 最小值
 小于最小值
 最大值
 大于最大值

3.2边界值分析案例

• 两位数加法计算器的边界值 ： -99 、-100、99 、100

3.3 为什么分析边界值

看看下面的代码有错误吗？

 输入或输出的边界最容易产生错误。

4、决策表

前面测试两位数加法计算器的测试没有考虑输入组合。

4.1 决策表的分析步骤

• 需求分析

分析输入和输出
 用等价类划分分析输入的各种情况、输出的各种情况

• 画判定表
• 分析与简化判定表

4.2 决策表案例

分析输入条件和输出条件

输入

输出
 正确计算
 错误提示

原始决策表/判定表

优化决策表

优化策略
 测试基本功能的保留；
 一个输入错误，另外输入无所谓，可以整合；
 所有输入都要错误过。

最终的决策表

4.3决策表的局限性与优化策略

导致测试量爆炸。

5、错误推测

5.1测试若干原则回顾

• 测试不是验证软件正确，而是攻击软件，发现错误。
• 测试要时刻保持怀疑的态度，具有缺陷预防意识。
• 测试要寻求系统设计、功能设计的弱点。
• 设计负面的、异常的测试，如考虑错误的或者异常的输入，往往可以发现更多的软件缺陷。

5.2什么是错误推测

在测试程序时，人们可以根据经验或直觉推测程序中可能存在的各种错误，从而有针对 性地编写检查这些错误的测试方法。

错误推测分类
 输入数据测试方面
 输出数据测试方面
 数据结构测试方面
 文件系统方面

5.3输入数据方面的错误推测

输入非法数据

• 一般用于键盘输入数据时。

测试方法
 输入非法类型
 输入非法范围/长度
 输入非法格式

• 注意
• 错误信息的检查：需要额外考虑错误提示信息的内容
• 错误信息和错误要对应一致
• 错误信息不能为空
• 错误信息的内容不能只是错误代码，不能包含开发信息
• 错误信息不能中英文混合

5.4错误推测

• 输入非法类型
• 输入非法范围（数值）
• 输入非法长度（个数）
• 输入非法格式
• 输入默认值
• 输入特殊字符
• 输入合法数据的非法组合
• 粘贴强制输入
• 一个输入多个输出不要遗漏
• 输出结果（含数据库）要正确
• 上溢、下溢（含结果）
• 操作数与操作符不符
• 文件超载
• 文件权限不足
• 介质忙或不可用
• 介质损坏

输入默认值

• 适用于有默认值的地方。
• 测试方法

        接受软件的默认值
        键入空值
        将默认值改为另外一个值
        将默认值改为另外一个值，再变为空值

输入特殊字符（集）

• 适用于不能输入有特殊含义的字符时。
• 测试方法

       根据被测软件所处的操作系统、程序设计语言、后台数据库以及具体业务 等信息列出表格，进行讨论，标明哪些需要测试，哪些需要剔除。
       了解具体行业知识，具体问题具体分析。

• 案例

      文件命名下列特殊字符（33 个）

         不能使用：\ /<>|“?，com0-com9，lpt0-lpt9，prn、aux、nul、 con。
      思考
         用户名有哪些特殊字符？
         QQ 昵称、聊天内容有哪些特殊字符？

输入合法数据的非法组合

• 适用于输入值之间存在依赖关系时。
• 测试方法

        输入可能是出现问题的组合值。

• 案例

输出数据方面的错误推测

1)同一个输入产生多种输出

案例
输入：一个电话打来
输出：
 状态一：等待接听。
 状态二：占线。
 状态三：停机。
 状态四：无法接通。
 状态五：关机。
 状态六：空号。

测试方法

• 详细测试每一种输出，不要有遗漏。
• 熟悉被测软件业务知识，阅读各种程序文档，明确输入可能产生的输出， 列出关于程序输入于输出的一个列表，然后进行测试。

2)验证输出结果的正确性

测试方法

• 不仅测试输入的正确性，还要检查结果的正确性。
• 测试人员要尽可能多地学习所涉及问题的领域。

数据结构方面的错误推测

1)数据结构溢出

• 适用于程序中存在变量、数组等数据结构时。
• 测试方法

     变量 
       上溢：值太大
       下溢：值太小
     数组
        上溢：数据量太多
        下溢：数据量太少

2)计算结果溢出

• 测试方法

        输入非法值或很大与很小数据，强制结果产生上溢或下溢。

3)操作数和操作符不符

• 适用于需要进行数值计算程序和图形操作程序的测试时，如加、减、乘、除等。
• 测试方法

        找到程序中容易引起操作数和操作符不符的计算、表达式等

文件系统方面的错误推测

1)使文件系统超载

• 适用于数据存储到硬盘中时。
• 案例

        假设“软件测试工程师管理系统”要保存 10000 个工程师信息，则保存时 engineer.txt文件可能会有20M大小，如果此时磁盘只有10M可用空间了， “软件测试工程师管理系统”会如何动作呢？

• 测试方法

        创建满容量或近乎满容量的文件系统，然后强制执行各种通过输入或输出 访问文件系统的操作。
        打开足够多的文件，文件打开时会强制创建备份副本，从而占用双倍的存 储空间。
        使用工具 CannedHeat，模拟文件系统超载。

2)更改文件访问权限

• 适用于对文件进行读写的应用程序。
• 测试方法

     不同的用户对相同文件具有不同的访问权限，需要考虑登录同一台机器的 多个用户操作相同文件的权限问题。
         打开一个文件，在操作系统中修改该文件的访问权限。有些操作系统 允许权限高的用户控制一般用户已经打开的文件。

     两个应用程序打开，关闭同一个文件。

         如把同一应用程序的不同版本安装在同一机器上，在不同版本的应用 程序中打开和关闭同一文件；
         试着在某个应用程序中打开在另一个程序中已打开的文件，这可能会 导致文件访问权限上出现冲突。

3)使介质忙或不可用

• 适用于应用程序的运行需要消耗大量内存或运行时需求其他相关软件同时运 行的情况。

        大多数操作系统能同时运行多个应用程序，但相互切换时会有延迟，但是 没有对错误响应。
测试方法
        通过启动大量应用程序，强制它们都打开并保存文件来使文件系统处于忙 的状态；或者同时下载大量文件也可以使后台拥挤。
        使用一些测试工具来模拟磁盘的状况。

4)介质损坏

• 使用场合

        损坏的介质可能使操作系统传回错误代码，这些错误代码可能没有在应用 程序中编程处理。

• 测试方法

       损坏介质的方法使用不很多，只有少数公司采用，大多是开发操作系统、 设备驱动程序以及以安全为主的应用程序的公司会采用这种测试方法。确 定是否使用该方法，主要要考虑数据对用户的重要性。
       该方法可以使用实际损坏了的介质。检查应用程序对错误的处理能力，应 用程序可以对错误进行处理或者将问题告诉用户，并且要确保用户数据文 件不丢失、不损坏。
       也可以通过软件模拟。

6、编写测试点

将测试点写入测试需求分析说明书，或者 XMind 等，留存下以供将来编写测试用例使
用。

四、编写测试用例

1、编写测试用例（一般公司都有固定模板）

2、测试用例的写作说明

2.1 用例编号/序号

• 简单、唯一。

2.2 用例说明

• 也称测试点、检查点、测试概述、用例概述、测试说明；
• 用一句话对测试用例进行概述；
• 可以总结测试目的；
• 可以用疑问句表示；
• 可以用“检查、验证、测试”等字眼（如验证 QQ 默认安装）；
• 最好看到这句话就能知道如何测试；
• 尽量唯一（决策表可能会有重复的测试说明）；
• 用例执行多轮时，越往后执行可能越快，如果用例写得好，直接看概述就行。

2.3 初始条件

• 也称预置条件、前提条件；
• 初始条件要是一个状态，而且是静态的，如管理员已登录后台；
• 初始条件是第一步操作步骤之前的状态，不能太远，不用从头写到尾
• 很多项目中不写预置条件。

2.4 操作步骤

• 若对数据要求高，需要把数据分离出来；
• 步骤要都有序号；
• 每一步用分号分开，最后用一个句号；
• 每一步必须换行；
• 参数前加冒号（如用户名：admin）；
• 涉及按钮界面用【】、“”等成对符号间隔；
• 功能的详细用例步骤 4-6 步左右；
• 最后一步一定是个动作，不能写结果。

2.5 预期结果

• 是一个状态；
• 如果参考文档中有描述，原封不动的抄过来；如果文档中没有具体要求，则点要一 致，可以有几个点，如 QQ 默认安装，应能启动、默认选项匹配等。

2.6 用例状态

• 通过、失败、阻塞、未执行、搁置、无效用例…
• 初始条件达不到时，一般用例状态设置为阻塞。
• 看如何执行用例，执行完关心什么来定。

2.7 优先级

• 用例的执行顺序。

3、测试用例的评审和管理

保证测试用例质量的方法

 首先，要对用户需求、服务质量要求、产品特性有深刻且全面的理解
 其次，采取正确、恰当的方法进行用例设计；
 再者，按照测试用例的标准格式或规范的模板来书写测试用例；
 最后，对测试用例的检查、评审，也是提高测试用例质量的主要且有效的手段。

五、提交缺陷报告

一） 软件缺陷的判定

1、什么是缺陷

• 软件存在着不符合质量需求或违背软件用户、客户、企业意愿的问题，这就是软件缺陷 （Defect），又叫“Bug（臭虫）”。

2、软件缺陷的判定准则

软件未达到产品说明书标明的功能；
 产品说明书简称为说明（spec）或产品说明（productspec），是软件开发小组 的一个协定。它对开发的产品进行定义，给出产品的细节、如何做、做什么、 不能做什么。这种协定从简单的口头说明到正式的书面文档有多种形式。
软件出现了产品说明书指明不会出现的错误；
 如金融软件 7*24 工作不能宕机
软件功能超出产品说明书指明范围；
软件未达到产品说明书虽未指出但应达到的目标；
 如软件在断电时的意外处理
软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。
 主要体现在易用性方面。

3、软件缺陷的表现形式

• 用户要求的功能、特性没有实现或部分实现。
• 运行出错，包括运行中断、系统崩溃、界面混乱等。
• 数据结果不正确、精度不够、不完整或格式不统一。
• 文字显示内容不正确或拼写错误。
• 系统性能低下、系统资源浪费。

4、分离和再现软件缺陷

发现缺陷后，应该做好分离和再现，排查发现的“缺陷”是不是软件本身的问题， 然后才能提交。
再现 3 次
 重现
 复现

5、避免提交缺陷的缺陷和重复缺陷

缺陷的缺陷
 是测试人员提交的不是缺陷的缺陷；
 是一种无效缺陷；
 此类缺陷常使测试人员遭受指责。
怎么办 ： 正确理解需求； 做好复现。
重复缺陷
 同一个缺陷 A 测试工程师提交后，B 测试工程师又提交或者自己提交的缺陷 与之前提交的缺陷相同或类似；
 是一种无效缺陷；
怎么办 ： 尽量避免两个人同时测试同一模块； 自己提交的缺陷与自己的重复，提交前查找一下，增强开发知识。

6、处理无法再现的缺陷

• 首先，对这样的缺陷进行详细的记录，使用不同办法去尝试复现。
• 其次，要合理地安排时间，要考虑到测试项目的整体进度，对一时难以再现的缺陷 可以暂时搁置，以保证项目的正常进度，并尽快提交给开发人员。
• 最后，在测试过程中对未再现缺陷予以关注。

7、处理有争议的缺陷

• 跟有关人员进行沟通、讨论；
• 搁置。

二） 提交缺陷报告

1、什么是缺陷报告

• 缺陷报告是对缺陷进行记录、分类和跟踪的文档。

2、缺陷报告的读者对象

• 软件开发人员

         报告缺陷是为了缺陷得到修复。
         希望获得缺陷的本质特征和复现步骤。

• 质量管理人员、市场人员、技术支持人员

         希望获得缺陷的严重程度和分布情况，以及对市场和用户的影响程度。

3、缺陷报告的写作准则（5C）

Correct（准确）
 每个组成部分的描述准确，不会引起误解；
Clear（清晰）
 每个组成部分的描述清晰，易于理解；
Concise（简洁）
 只包含必不可少的信息，不包括任何多余的内容；
Complete（完整）
 包含复现该缺陷的完整步骤和其他本质信息；
Consistent（一致）
 按照一致的格式书写全部缺陷报告。

4、缺陷报告的组织结构

• 缺陷的标题/缺陷摘要/缺陷概述/缺陷基本信息
• 预处理
• 复现步骤
• 期望结果
• 实际结果
• 缺陷的严重程度
• 缺陷的优先级
• 测试的软件和硬件环境
• 测试的软件版本
• 缺陷的类型
• 注释文字和缺陷截图

5 缺陷报告的写作要求

5.1 缺陷标题

• 尽量按缺陷发生的原因与结果的方式书写；

        执行完 A 后，发生 B；
        在什么地方，做了什么事情，出了什么结果；

• 使用“在…以后”，“在…时候”或“在…期间”等连结词有助于描 述缺陷的原因和结果。
• 避免使用模糊不清的词语；
• 为了方便搜索和查询，尽量使用关键字；
• 为了便于他人理解，避免使术语、俚语或过分具体的测试细节。

5.2 复现步骤

• 提供测试的预备步骤和信息；
• 步骤完整，准确，简短，没有缺漏任何操作步骤，没有任何多余的步骤；
• 将常见步骤合并为较少步骤；
• 简单地一步一步地引导复现该缺陷；
• 每一个步骤尽量只记录一个操作；
• 每一个步骤前使用数字对步骤编号；
• 尽量使用短语和短句，避免复杂句型和句式；

        只记录各个操作步骤是什么，不要包括每个步骤的执行结果。

5.3 预期结果

 软件应该具有的结果，或者说正确结果应该是什么样子。

5.4 实际结果

• 实际结果的描述要列出具体的表现行为，而不是简单的指出“不正确”或“不起作 用”。
• 如果一个动作产生彼此不同的多个缺陷结果，或者一个动作将产生一个结果，而这 个结果又产生另一个结果。为了易于阅读，这些结果应该使用数字列表分隔开来。 如实际结果：

        1.显示“命令代码行…错误”；
        2.显示“并且终止…服务”。

5.5 注释/截图

• 可以包含以下各方面的内容：

        截取缺陷特征图像文件；
        测试过程所使用的测试文件；
        测试附加的打印机驱动程序；
        再次描述重点，避免开发人员将缺陷退回给测试人员补充更多信息；
        再次指明该缺陷是否在前一版本已经存在；
        多个平台之间是否具有不同表现；
        注释包含缺陷的隔离信息，指出缺陷的具体影响范围。

• 如，缺陷的注释可能包含下面的内容：

        能在 Win2000 和 WinXP 文本框中显示文本内容，但不支持 Win98
        屏幕刷新后，现象会消失。
        使用二进制文件，不存在该错误。
        参见附加的使用说明书和测试文件。

6、怎么提交高质量的缺陷报告

• 尽早提交缺陷报告。
• 清楚地说明此问题对用户价值的危害。  提供尽可能多的技术信息（如包含复现该缺陷需要的环境变量或测试所用的数据文 件），方便程序员调试。
• 报告的软件缺陷进行了必要的隔离，报告的缺陷信息具体、准确。
• 易于搜索软件测试报告的缺陷。
• 一个缺陷报告中只报告了一种缺陷。
• 缺陷报告中不要提问题。
• 避免常见的错误

       我（I）、你（You）、他/她（He/She）
       情绪化的语言和强调符号！！！
       似乎（Seems）、看上去可能（Appearstobe）
       认为比较幽默的内容  不确定的测试问题（Issues）/不确定是否是缺陷

三） 缺陷的分类

1、缺陷的分类标准

2、根据缺陷类型对缺陷分类

• 功能缺陷
• 界面缺陷
• 文档缺陷
• 代码缺陷
• 算法错误
• 性能缺陷

3、根据缺陷的等级对缺陷分类

A 类—致命缺陷，包括以下各种错误：

 由于程序所引起的死机，非法退出；
 死循环；
 数据库发生死锁；
 因错误操作导致的程序中断；
 功能错误；
 与数据库连接错误；
 数据通讯错误

B 类—严重缺陷，包括以下各种错误：

 程序错误；
 程序接口错误；
 数据库的表、业务规则、缺省值未加完整性等约束条件

C 类一般缺陷，包括以下各种错误：

 操作界面错误（包括数据窗口内列名定义、含义是否一致）；
 打印内容、格式错误；
 简单的输入限制未放在前台进行控制；
 删除操作未给出提示；
 数据库表中有过多的空字段

D 类—较小缺陷，包括以下各种错误：

 界面不规范；
 辅助说明描述不清楚；
 输入输出不规范；
 长操作未给用户提示；
 提示窗口文字未采用行业术语；
 可输入区域和只读区域没有明显的区分标志

E 类—意见或建议

4、根据缺陷处理的优先级对缺陷分类

5、根据缺陷状态对缺陷分类

六、缺陷报告的处理

1、缺陷报告的简单处理流程/缺陷的生命周期

• 软件测试人员提交缺陷报告；
• 测试负责人审核后将缺陷报告分配给相关的开发人员修改；
• 缺陷被修改后由测试人员根据缺陷报告中的修改记录进行返测；
• 返测通过的缺陷报告由负责人关闭，返测未通过的缺陷报告直接返回开发人员重新 修改，缺陷报告直到缺陷被修复以后才关闭；
• 关闭或已解决的缺陷报告可能会被阶段性的复审重新打开，这些报告一旦被再次打 开应该立即处理。

2、缺陷报告的标准处理流程

• 正常缺陷
• 重复缺陷
• 无效缺陷
• 推迟修改
• 验证不通过
• 描述不清楚

3、缺陷跟踪管理系统/缺陷管理工具

3.1 缺陷管理工具的功能

• 缺陷提交
• 缺陷跟踪
• 缺陷分析

       有效的缺陷分析不仅可以评价软件质量，同时可以帮助项目组很好地掌握和评 估软件的研发过程，进而改进研发过程，未对缺陷进行分析就无法对研发流程 进行改进。
       缺陷分析还能为软件新版本的开发提供宝贵的经验，进而在项目开展之前，指 定准确、有效的项目控制计划，为开发高质量的软件产品提供保障。

3.2 常见缺陷管理工具

• Bugzilla
• Bugfree
• Mantis
• Jira
• ZenTao（禅道）
• QualityCenter/Application Lifecycle Management
   

PS：如需要软件测试学习资料，可在公众号（互联网杂货铺），后台回复1，小编后面会逐步完善自己收藏的资料。

整理不易，给个关注点个赞吧，谢谢各位大佬！