软件测试基础理论_软件测试概念和目的

一、软件测试概念

1.1 什么是软件测试？

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

1.2 软件测试目的

• 发现被测对象与用户需求之间的差异，即缺陷。
• 通过测试活动发现并解决缺陷，增加人们对软件质量的信心。
• 通过测试活动了解被测对象的质量状况，为决策提供数据依据。
• 通过测试活动积累经验，预防缺陷出现，降低产品失败风险。

1.3 软件测试的原则

• 应当把“尽早地不断地进行软件测试“作为软件开发者的座右铭；
• 测试用例应由测试数据和与之对应的预期输出结果这两部分组成；
• 程序员应避免检查自己的程序；
• 在设计测试用例时，应当包括合理的输入条件和不合理的输入条件；
• 充分注意测试中的群集现象；
• 严格执行测试计划，排除测试的随意性；
• 应当对每一个测试结果做全面的检查
• 妥善保存测试计划、测试用例、出错统计和最终分析报告，为维护提供方便。

1.4 软件测试的对象

软件测试是不等同于程序测试，软件测试贯穿于软件定义和开发的整个期间。需求分析，概要设计，详细设计以及程序编码等各个阶段所得到的文档，包括需求规格说明书、概要设计规格说明，详细设计规格说明以及源程序，都是软件测试的对象。

1.5 软件测试的流程

软件测试流程：需求分析–》制订测试计划–》设计测试用例与编写–》实施测试–》提交缺陷报告–》生成测试总结和报告

测试工作流程：
（1）产品人员设计完原型和文档后，召开需求评审会，参会人员有开发，测试，产品。需求评审后之后，会产生一个完善之后的原型和需求文档。
（2）测试组负责人需要依据需求文档，项目周期、项目特点、工具、人员安排制定测试计划。
（3）测试人员就开始写测试用例（需要有冒烟测试用例和普通的测试用例），在写用例过程中会产生一些疑问，要及时和产品人员确认清楚，并要求他们回归需求文档。（开发就开始概要设计和编码）。
（4）测试人员完成用例后，组织测试用例评审。参与人员有开发，测试，产品。
（5）等待开发提交测试版本，提交后优先执行冒烟测试。冒烟测试的结果，需要邮件周知相关人，开发，测试，产品，其中重要的是开发领导，测试领导和产品。冒烟不通过等待开发重新提交版本，冒烟通过了进入执行用例进行测试阶段。
（6）测试阶段会发现一些问题，比如需求定义不明确，业务逻辑有冲突，要和相关人员沟通并定义清晰，得到结论后必须要求产品人员更新文档。
（7）每个人负责的模块测试结束后，小组内部要进行交叉测试（此时会进行一些性能测试）。
（8）测试通过后提交产品验收。产品验收期间协助产品验收。
（9）产品验收完毕后，项目部署仿真环境。此时需要线上的账号，所以一般也是产品和业务人员验收为主，各个公司情况不同，有些会给测试人员分配账号，进行基本流程的测试（细节视公司情况而定）。
（10）仿真环境ok了，部署线上。
（11）有些公司从测试环境提交验收的时间点开始，会要求写一些操作手册之类的文档，一些测试的报告，比如bug统计，bug的覆盖。

1.6 软件产品的质量模型

软件产品质量模型将一个软件产品需要满足的质量划分为六大属性：

• 功能性：能够满足明确和隐含要求的功能
• 可靠性：能够处理异常情况，在错误中很快恢复
• 易用性：易懂、易学、易用、漂亮好看
• 效率性：占用少量的资源，提供适当的性能
• 维护性：是指产品可被修改的能力
• 可移植性：是指软件产品从一种环境迁移到另一种环境的能力

1.7 软件生命周期各个阶段

件生命周期是指一个计算机软件从功能确定、设计，到开发 成功投入使用，并在使用中不断地修改、增补和完善，直到停止该软件的使用的全过程。
阶段：可行性分析与开发项计划、需求分析、设计（概要设计和详细设计）、编码、测试、维护等阶段。

• 计划
  工作内容：
  （1）确定软件开发总目标；
  （2）给出软件的功能、性能、可靠性以及接口等方面的设想；
  （3）研究完成该项目的可行性，探讨问题解决方案；
  （4）对可供开发使用的资源、成本、可取得的效益和开发进度作出评估；
  （5）制定完成开发任务的实施计划。
• 需求分析
  工作内容：对开发的软件进行详细的定义，有需求分析人员和用户共同讨论决定，哪些需求是可以满足的，并且给予确切的描述，写出需求规格说明书。
• 设计
  工作内容：
  （1）设计是软件工程的技术核心，这个阶段需要完成设计说明书
  （2）概要设计，在设计阶段把各项需求转换成相应的体系结构，每一部分是功能明确的模块；
  （3）详细设计，对每个模块要完成的工作进行具体的描述。

二、软件测试常见分类

2.1 按是否覆盖源代码划分

• 黑盒测试：工作人员在不考虑任何程序内部结构和特性的条件下，检查程序的功能是否能够按照规范说明准确无误的运行（功能测试、界面测试属于黑盒测试）
• 白盒测试：测试程序内部逻辑结构及相关信息（检查程序源代码）
• 灰盒测试：灰盒测试则介于黑盒测试和白盒测试之间。灰盒测试除了重视输出相对于出入的正确性，也看重其内部表现

2.2 按开发阶段划分

• 单元测试： 是指对软件中的最小可测试单元进行检查和验证（方法、函数、类等，一般由程序员自己完成，属于白盒测试、静态测试）
• 集成测试： 也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求组装成为子系统或系统，进行集成测试，一般是对接口进行测试
• 系统测试： 对软件整体进行测试，是否满足用户所提要求，需要对功能、性能、安全、界面等所有方面进行测试。
  （1）回归测试（Regression Testing）：指修改了旧的代码之后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。（自动回归测试将大幅度降低系统测试、维护升级等阶段的成本）。

在整个软件测试过程中占有很大的工作比重，软件开发的各个阶段都会进行多次回归测试。随着系统的庞大，回归测试的成本越来越大，通过正确的回归测试策略来改进回归测试的效率和有效性是很有意义的。

（2）冒烟测试（smoke testing）：该术语来自硬件，指对一个硬件或一组硬件进行更改或修复后，直接给设备加电。如果没有冒烟，则该组件就通过了测试，也可以理解为该种测试耗时短，仅用一袋烟的功夫就足够了。
冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本功能正常，可以进行后续正式的测试工作。
冒烟测试的执行者是版本编译人。
冒烟测试一般在开发人员开发完毕后送给测试人员来进行测试时，测试人员会先进行冒烟测试，保证基本功能正常，不阻碍后续测试。
虽然系统测试包括冒烟测试和回归测试，但三者之间是有严格的先后顺序的，即：先冒烟、再系统、后回归。

• 验收测试： 与系统测试相比仅仅为测试人员上的区别，测试人员辅助甲方进行测试
  α测试：内测，内部人员测试
  β测试：公测，客户或用户测试

2.3 按测试执行方式划分

• 静态测试： 静态方法是指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性，对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错。分析如下：

检查项：代码风格和规则审核；程序设计和结构的审核；业务逻辑的审核；走查、审查与技术复审手册。
静态质量：度量所依据的标准是ISO9126。在该标准中，软件的质量用以下几个方面来衡量，即功能性(Functionality)、可靠(Reliability)、可用性(Usability)、有效性(Efficiency)、可维护性（Maintainability）、可移植性(Portability)。

静态测试：代码静态分析和文档测试都属于静态测试。

• 动态测试： 动态测试是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率、正确性、健壮性、等性能。

（1）动态测试有三部分组成：构造测试用例、执行程序、分析程序的输出结果。
（2）大多数软件测试都属于动态测试。

2.4 按是否手工执行划分

• 手工测试： 由人去一个一个的去执行测试用例，通过键盘鼠标等输入一些参数，查看返回结果是否符合预期结果。属于比较原始但是必须的一种
  优点：自动化测试无法代替探索性测试、发散思维类无既定结果的测试。
  缺点：执行效率慢，量大易错。
• 自动化测试： 是把以人为驱动的测试行为转化为机器执行的一种过程。通常，在设计了测试用例并通过评审之后，由测试人员根据测试用例中描述的规程一步步执行测试，得到实际结果与期望结果的比较。在此过程中，为了节省人力、时间或硬件资源，提高测试效率，便引入了自动化测试的概念。 简单来说，自动化测试就是是把人为驱动的测试行为，转化为机器执行的一种过程。
  自动化测试：又可分为功能自动化测试与性能自动化测试。我们一般所说的自动化测试就是指功能自动化测试。
  自动化测试按照测试对象来分，还可以分为接口测试、UI测试等。接口测试的ROI（产出投入比）要比UI测试高。

自动化实施的步骤：
（1）完成功能测试，版本基本稳定
（2）根据项目特性，选择适合项目的自动化工具，并搭建环境
（3）提取手工测试的测试用例转换为自动化测试的用例
（4）通过工具、代码实现自动化的构造输入、自动检测输出结果是否符合预期
（5）生成自动测试报告
（6）持续改进、脚本优化

2.5 按测试对象划分

• 功能测试： 功能测试就是对产品的各功能进行验证，检查产品是否达到用户要求的功能。
• 性能测试： 检查系统是否满足需求规格说明书中规定的性能。
  通常表现在以下几个方面：
  1）对资源利用（如内存、处理机周期等）进行的精确度量
  2）对执行间隔
  3）日志事件（如中断，报错）
  4）响应时间
  5）吞吐量（TPS）
  6）辅助存储区（例如缓冲区、工作区的大小等）
  7）处理精度等进行的监测
  性能测试又分为：
  a. 压力测试：给软件不断加压，强制其在极限的情况下运行，观察它可以运行到何种程度，从而发现性能缺陷，包括内部内存、CPU 可用性、磁盘空间和网络带宽。
  b. 负载测试：逐步增加系统负载，测试系统性能的变化，并最终确定在满足性能指标的情况下，系统所能承受的最大负载量的测试
  c. 并发测试：主要指当测试多用户并发访问同一个应用、模块、数据时是否产生隐藏的并发问题，如内存泄漏、线程锁、资源争用问题
• 安全测试： 安全测试是检查系统对非法侵入渗透的防范能力（渗透测试、流量攻击、SQL注入、跨域攻击）
• 兼容性测试： 兼容性测试是指要测试的软件在不同的硬件平台上、不同的应用软件之间、不同的操作系统中、不同的网络环境中是否可以正常的运行、有无异常的测试过程。即是通常说的软件的可移植性。
  兼容性测试又分为：
  a. Web兼容性测试：
  1）浏览器上的兼容性（Google 、saferi、Firefox、opra、eadge、360、QQ、夸克、搜狗…根据市场所占份额，从高到低进行测试）
  可以使用第三方工具：推荐IEtester（离线）、SuperPreview（离线）和Browsershots：http://browsershots.org（在线）
  2）操作系统：windows系列、Mac OS X系列、UNIX/Linux系列
  3）屏幕尺寸和分辨率兼容性测试
  b. APP兼容性测试：考虑操作系统兼容性测试：
  1）Android：不同安卓设备、安卓版本、系统版本、屏幕分辨率、屏幕大小、屏幕形状等综合考虑情况下测试
  注意：安卓机型较多，实际情况下怎样进行测试
  公司提供部分型号的手机进行测试，如果覆盖率不够时，考虑同事之间众筹，大家凑一下啦，如果还是达不到覆盖率，最后还可以采用百度众测平台和云测平台，这两款测试工具里面包含了安卓和iOS的测试（收费）
  2）iOS兼容性：各型号的iPhone手机上进行测试
• 文档测试 ：国家有关计算机软件产品开发文件编制指南中共有14种文件，可分为3大类。
  开发文件：可行性研究报告、软件需求说明书、数据要求说明书、概要设计说明书、详细设计说明书、数据库设计说明书、模块开发卷宗。
  用户文件：用户手册、操作手册，用户文档的作用：改善易安装性；改善软件的易学性与易用性；改善软件可靠性；降低技术支持成本。
  管理文件：项目开发计划、测试计划、测试分析报告、开发进度月报、项目开发总结报告。
  在实际的测试中，最常见的就是用户文件的测试，例如：手册说明书等。
  文档测试关注的点：文档的术语、文档的正确性、文档的完整性、文档的一致性、文档的易用性
• 易用性测试（用户体验测试） ：易用性（Useability）是交互的适应性、功能性和有效性的集中体现。又叫用户体验测试。
• 业务测试 ：业务测试是指：测试人员将系统的整个模块串接起来运行、模拟真实用户实际的工作流程。满足用户需求定义的功能来进行测试的过程。
• 界面(UI)测试 ：界面测试（简称UI测试)，测试用户界面的功能模块的布局是否合理、整体风格是否一致、各个控件的放置位置是否符合客户使用习惯，此外还要测试界面操作便捷性、导航简单易懂性，页面元素的可用性，界面中文字是否正确，命名是否统一，页面是否美观，文字、图片组合是否完美等。
• 安装测试 ：安装测试是指：测试程序的安装、卸载。最典型的就是APP的安装、卸载。

2.6 按测试实施组织划分

• α测试（Alpha Testing）：内测，内部人员测试
  α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。
  α测试的目的是评价软件产品的FLURPS（即功能、局域化、可使用性、可靠性、性能和支持）。
• β测试(Beta Testing)： 公测，客户或用户测试
  Beta测试是一种验收测试。Beta测试由软件的最终用户们在一个或多个客房场所进行。通常由软件公司免费发布，用户可从相关的站点下载。通过一些专业爱好者的测试，将结果反馈给开发者，开发者们再进行有针对性的修改。

α测试与Beta测试的区别：
（1）测试的场所不同：Alpha测试是指把用户请到开发方的场所来测试,beta测试是指在一个或多个用户的场所进行的测试。
（2）Alpha测试的环境是受开发方控制的,用户的数量相对比较少,时间比较集中。beta测试的环境是不受开发方控制的,用户数量相对比较多,时间不集中。
（3）alpha测试先于beta测试执行。通用的软件产品需要较大规模的beta测试,测试周期比较长。

• 第三方测试： 介于开发方和用户方之间的组织测试。

三、软件开发常见模型

软件开发模型是软件生命周期基础上构造出的由软件开发全过程中的活动和任务组成的组成架构，也称为软件生命周期模型或软件过程模型，它反映了软件开发中各种活动组织的的衔接方式。它是软件项目开发工作的基础。

3.1 瀑布模型

瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。瀑布模型强调文档的作用，并要求每个阶段都要仔细验证。但是，这种模型的线性过程太理想化，已不再适合现代的软件开发模式，几乎被业界抛弃，其主要问题在于：（1） 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量；（2） 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险；（3） 早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。
瀑布模型的特点是：
阶段间具有顺序性和依赖性，前一阶段结束后才能开始后一阶段的工作，前一阶段的输出是厚意阶段的输入；推迟实现观点，尽可能推迟程序的物理实现；强调质量保证观点，每个阶段必须完成规定的文档，每个阶段结束前完成文档以便及早改正错误。
优点：
（1）原理简单，容易掌握。
（2）各阶段间都有验证和确认环节，以便进行质量管理。
（3）主要用于支持结构化方法
缺点：
（1）缺乏灵活性，不能适应用户的需求变化。
（2）缺乏演化性，返回上一级的开发需要付出十分高昂的代价
（3）是线性的软件开发模型，回溯性差。
使用场合：
（1）适合于软件需求比较明确或很少变化，且开发人员可以一次性获取到全部需求的场合
（2）适合开发技术比较成熟，工程管理比较严格的场合
（3）一般用于低风险的项目，适合开发人员具有丰富的经验。

3.2 快速原型模型

快速原型模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么；第二步则在第一步的基础上开发客户满意的软件产品。

显然，快速原型方法可以克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险，具有显著的效果。快速原型的关键在于尽可能快速地建造出软件原型，一旦确定了客户的真正需求，所建造的原型将被丢弃。因此，原型系统的内部结构并不重要，重要的是必须迅速建立原型，随之迅速修改原型，以反映客户的需求。

快速原型是快速建立起来的可以在计算上运行的程序，是软件的一个早期可运行的版本，它的功能是最终产品的子集。用途主要是获取用户的真正的需求。

优点：
（1）增强了开发者于用户间的交流，有助于满足用户的真实需求。
（2）用户可及早得到有用的产品，可及早发现问题，随时纠正错误，
（3）减小技术、应用风险，可降低开发费用，缩短开发时间

缺点：
（1）缺乏丰富而强有力的软件工具和开发环境
（2）对设计人员及开发环境要求较高
（3）难于做到彻底测试，更新文档较为困难

适用场合：
（1）预先不能确切定义需求的软件系统，或需求多变的系统
（2）开发人员对设计方案没信心或对将要采用的技术手段不熟悉或把握性不大
（3）原型模型可作为单独的过程模型使用，也常被作为一种方法或实现技术应用于其他的过程模型中。

3.3 增量模型

又称演化模型。与建造大厦相同，软件也是一步一步建造起来的。在增量模型中，软件被作为一系列的增量构件来设计、实现、集成和测试，每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成。
增量模型在各个阶段并不交付一个可运行的完整产品，而是交付满足客户需求的一个子集的可运行产品。整个产品被分解成若干个构件，开发人员逐个构件地交付产品，这样做的好处是软件开发可以较好地适应变化，客户可以不断地看到所开发的软件，从而降低开发风险。但是，增量模型也存在以下缺陷：（1） 由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。（2） 在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而是软件过程的控制失去整体性。在使用增量模型时，第一个增量往往是实现基本需求的核心产品。核心产品交付用户使用后，经过评价形成下一个增量的开发计划，它包括对核心产品的修改和一些新功能的发布。这个过程在每个增量发布后不断重复，直到产生最终的完善产品。例如，使用增量模型开发字处理软件。可以考虑，第一个增量发布基本的文件管理、编辑和文档生成功能，第二个增量发布更加完善的编辑和文档生成功能，第三个增量实现拼写和文法检查功能，第四个增量完成高级的页面布局功能。
优点：
（1）可分批次提交软件产品，方便用户及时了解软件开发进展情况，及早发现问题。
（2）以组件为单位进行开发，降低了软件开发的风险。
（3）开发顺序灵活，优先级最高的服务首先交付。
缺点：
（1）由于对整个软件系统的需求没有一个完整的定义，会给总体设计带来麻烦。
（2）在把每个新的增量构件集成到现有软件结构中时，必须不破坏原来已开发出的产品。
（3）软件的体系结构必须是开放的，即向产品中加入新构件的过程必须简单、方便。每次增量开发的产品都应当是可测试的，可扩充的。
适用场合：
（1）软件产品可以分批次地进行交互
（2）待开发的软件系统能够被模块化
（3）软件开发人员对应用领域不熟悉、难以一次性地进行软件开发时。
（4）项目管理人员把握全局的水平较高时
（5）对软件需求把握不准确、设计方案有一定风险的项目

3.4 螺旋模型

它将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。
如图所示，螺旋模型沿着螺线进行若干次迭代，图中的四个象限代表了以下活动：（1） 制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件；（2） 风险分析：分析评估所选方案，考虑如何识别和消除风险；（3） 实施工程：实施软件开发和验证；（4） 客户评估：评价开发工作，提出修正建议，制定下一步计划。螺旋模型由风险驱动，强调可选方案和约束条件从而支持软件的重用，有助于将软件质量作为特殊目标融入产品开发之中。但是，螺旋模型也有一定的限制条件，具体如下：（1） 螺旋模型强调风险分析，但要求许多客户接受和相信这种分析，并做出相关反应是不容易的，因此，这种模型往往适应于内部的大规模软件开发。（2） 如果执行风险分析将大大影响项目的利润，那么进行风险分析毫无意义，因此，螺旋模型只适合于大规模软件项目。（3） 软件开发人员应该擅长寻找可能的风险，准确地分析风险，否则将会带来更大的风险。一个阶段首先是确定该阶段的目标，完成这些目标的选择方案及其约束条件，然后从风险角度分析方案的开发策略，努力排除各种潜在的风险，有时需要通过建造原型来完成。如果某些风险不能排除，该方案立即终止，否则启动下一个开发步骤。最后，评价该阶段的结果，并设计下一个阶段。

3.5 边做边改模型

许多产品都是使用"边做边改"模型来开发的。在这种模型中，既没有规格说明，也没有经过设计，软件随着客户的需要一次又一次地不断被修改。
在这个模型中，开发人员拿到项目立即根据需求编写程序，调试通过后生成软件的第一个版本。在提供给用户使用后，如果程序出现错误，或者用户提出新的要求，开发人员重新修改代码，直到用户满意为止。
这是一种类似作坊的开发方式，对编写几百行的小程序来说还不错，但这种方法对任何规模的开发来说都是不能令人满意的，其主要问题在于：（1） 缺少规划和设计环节，软件的结构随着不断的修改越来越糟，导致无法继续修改；（2）忽略需求环节，给软件开发带来很大的风险；（3）没有考虑测试和程序的可维护性，也没有任何文档，软件的维护十分困难。

四、软件测试常见模型

随着测试过程的管理和发展，测试人员通过大量的实践，从而总结出了不少测试模型，如常见的V模型、W模型、H模型等。这些模型与开发紧密结合，对测试活动进行了抽象，成为了测试过程管理的重要参考依据。

4.1 V模型

V模型是一个著名的、以测试为驱动的开发模型。
优点：

• 包含了底层测试（单元测试）和高层测试（系统测试）；
• 清楚的标识了开发和测试的各个阶段；
• 自上而下逐步求精，每个阶段分工明确，便于整体项目的把控。

缺点：

• 自上而下的顺序导致了，测试工作在编码之后，就导致错误不能及时的进行修改；
• 实际工作中，需求经常变化，导致v模型步骤，反复执行，返工量很大，灵活度较低。

4.2 W模型

定义：开发一个v；测试一个v组合起来的模型（w模型也叫双v模型）

优点：

• 开发伴随着整个开发周期，需求和设计同样要测试；
• 更早的介入测试，可以发现初期的缺陷，修复成本低；
• 分阶段工作，方便项目整体管理。

缺点：

• 开发和测试依然是线性的关系，需求的变更和调整，依然不方便；
• 如果没有文档，根本无法执行w模型；对于项目组成员的技术要求更高！

五、软件缺陷(BUG)

5.1 什么是软件缺陷？

软件或程序中存在的各种问题及错误。

5.2 软件缺陷的判断标准

• 软件未达到需求规格说明书中标明的功能；
• 软件出现了需求规格说明书中指明不会出现错误的地方；9
• 软件的功能超出了需求规格说明书指明的范围；
• 软件未达到需求规格说明书虽未指明但应该达到的目标；
• 软件难以理解，不易使用，运行速度慢或者最终用户体验不好。

5.3. 软件缺陷产生原因：

• 需求不断变化
• 软件的复杂性
• 工期短，任务大
• 文档不完善
• 程序设计错误
• 软硬件支持不完善
• 沟通交流不够

5.4 缺陷报告的关键要素

• 缺陷ID： 缺陷的唯一标识
• 缺陷状态： 缺陷的所处状态，包括：新建、已指派、已解决、已拒绝或无效、已关闭、已激活、已延期。
• 缺陷的标题： 缺陷的简要描述，通常采用“在什么情况下发生了什么问题”的模式。如：用户不能正常登录”可以改成“输入正确用户名、正确密码且用户状态正常却不能正常登录”；“输入查询条件不能匹配结果”改成“用户名搜索框不支持模糊查询”。这样相对清晰易理解。
• 缺陷的类型：
  （1）bug：测试人员通过测试发现的问题能称为bug。
  （2）需求：需要产品经理对需求进一步梳理。
  （3）建议：是软件产品改进建议
  （4）优化：功能已实现，需要优化问题。可以是用户体现优化、性能优化
• 严重程度： 缺陷的严重程度
  （1）致命：系统崩溃、数据丢失、数据毁坏、安全性被破坏。
  （2）严重：操作性错误、结果错误、功能遗漏。
  （3）一般：小问题、拼写错误、UI布局、罕见错误。
  （4）建议：对产品的改进建议。
• 优先级： 缺陷修复的优先级，优先级表示修复缺陷的重要程度和紧迫程度。
  （1）紧急：影响进一步测试，需要立即修复。
  （2）高：必须在版本发布前修复。
  （3）中：必须要修复，不一定马上修复，可以讨论确定在某个时间节点修复好。
  （4）低：对产品影响比较少，不修复也不影响产品的发布。在时间不允许的情况下可以暂时不修复。
• 详细信息： 缺陷的详细描述，把发现缺陷的过程、步骤、使用的数据、期望结果、实际结果等记录下来，使程序员通过该描述，能够再现该BUG。
  

5.4 缺陷报告处理流程

5.5 缺陷的严重级别

缺陷的严重级别：

• 致命：系统崩溃，404报错，报500，造成系统或应用程序崩溃，死机，系统悬挂，造成数据丢失，页面出现错误乱码，蓝屏等。
• 严重：功能未实现，逻辑错误，影响用户正常操作，与需求完全不符，或因此BUG导致后续功能无法测试；
• 一般：功能实现但不正确，功能上的错误，页面中的错误，逻辑实现但不正确；
• 轻微：文案内容与实际不符，错别字，图片错误，建议性BUG。

5.6 缺陷的优先级

缺陷的优先级：可分为高，中，低，建议。当然这个根据公司和工具不同，叫法不一样。不过划分都是差不多的。

• 高：BUG严重级别较高，需要立刻解决的，或者一般级别的但是比较棘手的；
• 中：BUG严重级别一般的，不影响用户正常操作的；
• 低：BUG严重级别处于较低的，可以下一次alpha测试前解决的；
• 建议：建议性的BUG，可以改也可以不改。

六、测试用例

6.1 定义

测试用例(Test Case)是为特定的目的而设计的一组测试输入、执行条件和预期结果的文档。其实简单来说，测试用例就是解决要测什么，怎么测和如何衡量的问题。
测试用例

6.2 认识生活中的测试用例

买手机、买电脑，要试用一下：开机、屏幕、运行速度、内存大小；这就是生活中的测试用例！
举例说明：买手机：按开机键，相当于输入了一组数据来测试，执行条件指的是开机的前提条件，比如是否有电；预期结果就是能顺利打开手机，那么测试完毕后，是否达到了想要的需求（顺利开机）

6.3 测试用例八大要素

软件测试用例的基本要素包括：
1. 用例编号： 具有唯一性。最好用数字或者字母表示
2. 用例标题： 用简单概括性的语言表述该条测试用例的测试点。每个测试用例的标题不能够重复，因为每个测试用例的测试点事不一样的
3. 测试模块： 你现在这个测试用例所测的项目名，可以是测试用例所属的大类，被测需求，被测的模块，或者是被测的单元。
4. 用例级别： 优先级。级别分为高中低三等：
　　高：保证系统基本功能、重要特性、实际使用频率比较高的用例；
　　中：重要程度介于高和低之间的测试用例；
　　低：实际使用频率不高，对系统业务功能影响不大的模块或功能的测试用例。
5. 预置条件： 前提条件，执行此测试用例之前需要做的准备，如果不满足这些条件，则无法进行测试。
6. 测试输入： 外界给予的数据的支撑
7. 执行步骤： 执行当前测试用例所要经过的操作步骤，需要给出每一步操作的详细描述，测试人员根据测试用例操作步骤，完成测试用例的执行。
8. 预期结果： 期望的结果
9.作者
10.创建日期：写用例的日期
11.修改日期：最后一次修改用例的日期
12.测试结果：执行用例后的结果：Pass、Fail、Block