软件测试基础知识V10

《软件测试基础知识V10》由会员分享，可在线阅读，更多相关《软件测试基础知识V10（17页珍藏版）》请在装配图网上搜索。

1、软件测试基础知识软件生命周期软件生命周期(SDLC, Systems Development Life Cycle)是软件的产生直到报废的生命周期， 周期内有问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、验收与运行、 维护升级到废弃等阶段。这种按时间分程的思想方法是软件工程的一种思想原则，即按部就 班、逐步推进，每个阶段都要有定义、工作、审查、形成文档以供交流或备查，以提高软件 的质量。 问题定义及规划 此阶段是软件开发方与需求方共同讨论，主要确定软件的开发目标及 其可行性 需求分析在确定软件开发可行的情况下，对软件需要实现的各个功能进行详细分析。需求分析阶段是一个很重要的阶段，

2、这一阶段做得好，将为整个软件开发项目的成 功打下良好的基础。“唯一不变的是变化本身。”同样需求也是在整个软件开发过程中不 断变化和深入的，因此我们必须制定需求变更计划来应付这种变化，以保护整个项目的 顺利进行。 软件设计此阶段主要根据需求分析的结果，对整个软件系统进行设计，如系统框架设计，数据库设计等等。软件设计一般分为总体设计和详细设计。好的软件设计将为软 件程序编写打下良好的基础。 程序编码此阶段是将软件设计的结果转换成计算机可运行的程序代码。在程序编码中必须要制定统一，符合标准的编写规范。以保证程序的可读性，易维护性，提高程序 的运行效率。 软件测试在软件设计完成后要经过严密的测试，以发

3、现软件在整个设计过程中存在的问题并加以纠正。整个测试过程分为单元测试、组装测试以及系统测试三个阶段进行。 测试的方法主要有白盒测试和黑盒测试两种。在测试过程中需要建立详细的测试计划并 严格按照测试计划进行测试，以减少测试的随意性。 运行维护软件维护是软件生命周期中持续时间最长的阶段。在软件开发完成并投入使用后，由于多方面的原因，软件不能继续适应用户的要求。要延续软件的使用寿命， 就必须对软件进行维护。软件的维护包括纠错性维护和改进型维护两个方面。软件测试的定义软件测试是软件工程过程的一个重要阶段，是在软件发布前对软件开发各阶段产品的最终检 查，是为了保证软件开发产品的正确性、完全性和一致性而检

4、测软件错误、修正软件错误的 过程。软件测试的目标（1）测试是为了发现程序中的错误而执行程序的过程；（2）好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案；（3）成功的测试是发现了至今为止尚未发现的错误的测试。软件开发的目的是开发出实现用户需求的高质量、高性能的软件产品，而软件测试是以检查 软件功能和其他非功能特性为核心，是软件质量保证的关键，也是成功实现软件开发目标的 重要保障。软件测试的分类黑盒测试和白盒测试从测试是否针对软件结构与算法的角度分类（黑盒测试和白盒测试）。两种测试方法从不同的角度出发，反应了软件的不同侧面，也适用于不同的开发环境。黑盒测试又称功能测试、数据驱动测试或基于

5、规格说明的测试，也可被称为用户测试，主要 应用于快速应用开发（RAD）环境。黑盒测试方法把程序看成一个黑盒子，完全不考虑程 序内部结构和处理过程。黑盒测试是在程序接口进行测试，它只是检查程序功能是否按照规 格说明书的规定正常使用。典型的黑盒测试方法等价类划分 因果图边界值分析黑盒主要是为了发现以下几类错误1）是否有不正确或遗漏了的功能？2）在接口上，输入能否正确的接受？能否输出正确的结果？3）是否有数据结构错误或外部信息（例如数据文件）访问错误？4）性能上是否能够满足要求？5）是否有初始化或终止性错误？白盒测试又称结构测试、逻辑驱动测试或基于程序本身的测试，也可称为程序员测试，主要 用于结构化

6、开发环境。白盒测试的前提是可以把程序看成装在一个透明的白盒子里，也就是完全了解程序结构和处 理过程。白盒测试按照程序内部逻辑测试程序，检验程序中每条通路是否按预定要求正确工 作。白盒测试又称结构测试。典型的白盒测试方法静态分析 动态测试使用白盒测试方法主要想对程序模块进行如下的检查：对程序模块的所有独立的执行路径至少测试一次 对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测试一次在循环的边界和运行界线内执行循环体 测试内部数据结构的有效性等白盒测试与黑盒测试比较白盒测试黑盒测试测试依据程序内部结构规格说明优点能够对程序内部的特定部位进行覆盖测试能站在用户立场上进行测试缺点无法检验程序的

7、外特性 无法对未实现规格说明的程 序内部欠缺部分进行测试不能测试程序内部特定部位 如果规格说明有误，则无法发 现静态测试和动态测试从是否需要执行被测试软件的角度分类（静态测试和动态测试）。静态测试不执行被测试的软件。类似于汽车检查。动态测试是在测试过程中执行被测试软件，类似于试车。测试不同阶段从测试的不同阶段分类（单元测试、集成测试、系统测试、验收测试）。按测试阶段分类，测试可分为4个主要阶段：单元测试、集成测试、系统测试和验收测试。 这是一种从小到大、循序渐进的测试过程。单元测试单元测试是对程序员编写完成的一个个程序单元进行测试。（单元通常不是可运行的程序， 单元测试必须编写额外的可运行的测

8、试驱动程序。）单元测试又称模块测试，是针对程序模 块（软件设计的最小单位）来进行正确性检验的测试工作。软件单元测试的目的是检测程序 模块对详细设计说明书的符合程度；软件单元测试依据是单元测试计划。软件单元 测试由测试工程师编制测试用例进行测试，及针对程序模块进行多次循环反复的单元测试， 并将测试结果记录在针对单元测试的软件测试报告上。若程序模块通过单元测试，则按配置管理规范所规定的标识方法进行标识。单元测试-设计测试模型：驱动模块一相当于所测模块的主程序桩模块一也叫做存根模块，用以代替所测模块调用的子模块。单元测试考虑方面模块接口测试局部数据测试独立路径测试出错处理测试边界条件测试单元测试原则

9、为模块正常运行设计为正向测试设计为逆向测试设计为满足特殊需求设计为代码覆盖设计单元测试执行检查编码是否遵循软件编程规范和标准自动或手动分析程序设计测试用例并运行错误跟踪分析集成测试集成测试有渐增式和非渐增式两种。渐增式的集成中可以采用两种“自顶向下”和“自底向 上”。集成测试中会混合使用白盒测试和黑盒测试方法。集成测试可以发现模块间接口以及 全局数据结构等问题。系统测试系统测试的目的是检查系统是否符合软件需求。系统测试采用黑盒测试方式。系统测试的主 要内容有：功能测试、健壮性测试、性能-效率测试、用户界面测试、安全性测试、压力测 试、可靠性测试、安装/反安装测试等。为了保证测试的客观性，一般由

10、机构的独立测试小 组来执行系统测试。验收测试验收测试是由用户完成的测试，验收测试的内容与系统测试的内容类似，验收测试可以分为 Alpha测试盒Beta测试。回归测试回归测试的范围 测试全部用例 问题修改后的检验 测试高风险模块/系统 基于操作剖面选择测试回归测试的基本过程 识别出软件中被修改的部分 从原基线测试用例库T中，排除所有不再使用的测试用例，确定那些对新的软件版本 依然有效的测试用例，其结果是建立一个新的基线测试用例库T0 依据一定的策略从T0中选择测试用例测试被修改的软件 如果必要，生成新的测试用例集T1，用于测试T0无法充分测试的软件部分 用T1执行修改后的软件 第2和第3步测试验

11、证修改是否破坏了现有的功能，第4和第5步测试验证修改工作本 身测试各种分类间关系单元测试的目的是检测程序模块对详细设计说明书的符合程度；软件单元测试依据为单元测试计划集成测试会混合使用白盒测试和黑盒测试方法测试阶段主要依据测试人员、测试方式主要测试内容单元测试详细设计规格说明书由程序员执行白盒测试接口测试、路径测试集成测试概要设计规格说明书由程序员执行白盒测试和黑盒测试接口测试、路径测试、功能测试、性能测试系统测试用户需求规格说明书由独立测试小组进行黑盒测试功能测试、健壮 性测试、性能测 试、用户界面测 试、安全性测 试、压力测试、 可靠性测试、安 装/反安装测试验收测试用户需求规格说明书由用

12、户执行黑盒测试软件测试的内容回归测试回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码 产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。回归测试作为软件 生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个 阶段都会进行多次回归测试。功能测试功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到 用户要求的功能。功能测试也叫黑盒子测试或数据驱动测试，只需考虑各个功能，不需要考虑整个软件的内部 结构及代码。一般从软件产品的界面、架构出发，按照需求编写出来的测试用例，输入数据 在预期结果和实际结果之

13、间进行评测，进而提出更加使产品达到用户使用的要求。Mercury的WinRunner是典型的自动化测试工具。WinRunner是一种用于检验应用程序能否 如期运行的企业级软件功能测试工具。通过自动捕获、检测和模拟用户交互操作，WinRunner 能识别出绝大多数软件功能缺陷，从而确保那些跨越了多个功能点和数据库的应用程序在发 布时尽量不出现功能性故障。性能测试性能测试时通过自动化的测试工具模拟多种正常、峰值以及异常负载调节来对系统的各项性 能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试， 确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能

14、指标的变 化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的 最大服务级别的测试。性能测试类型包括负载测试、强度测试、容量测试等。负载测试(Load Testing):负载测试是一种主要为了测试软件系统是否达到需求文档设计的 目标，譬如软件在一定时期内，最大支持多少并发用户数，软件请求出错率等，测试的主要 是软件系统的性能。强度测试(Stress Testing)：强度测试也就是压力测试，压力测试主要是为了测试硬件系统能 否达到需求文档设计的性能目标，譬如在一定时期内，系统的CPU利用率，内存使用率， 磁盘I/O吞吐率，网络吞吐量等。压力测试和负载测试最大的差别在

15、于测试目的不同。容量测试(Volume Testing):确定系统最大承受量，譬如系统最大用户数，最大存储量，最 多处理的数据流量等。易用性测试易用性测试是指用户使用软件时是否感觉方便，比如是否最多点击鼠标三次就可以达到用户 的目的。易用性与可用性存在一定的区别，可用性是指是否可以使用，易用性是指是否方便 使用。易用性测试包括针对应用程序的测试，同时还包括对用户手册系统文档的测试。通常采用质 量外部模型来评价易用性。包括如下方面的测试：1) 易理解性测试2) 易学性测试3) 易操作性测试4) 吸引性测试5) 易用的依从性测试易用性测试方法有：静态测试；动态测试、动态和静态结合测试。安装与反安装

16、测试测试软件在“全部、部分、升级”等状况下的安装/反安装过程。软件安装测试1）安装过程中对于缺省安装目录及任意指定的安装目录，是否都能正确安装2）若是选择安装，查看能否实现其相应的功能3）在所有能中途退出安装的位置退出安装程序后，验证此程序并未安装成功（没有程 序组及程序项产生）4）软件安装后，对其他已经安装的软件是否有影响5）裸机安装后，各功能点是否可用6）安装前，安装程序是否判断可用磁盘空间大小，如果不能满足安装空间要求，安装 程序能否继续7）安装过程中查看版权声明、版本信息、公司名称、LOGO等是否符合标准8）安装过程中界面显示与提示语言是否准确友好9）重复安装时系统是否有提示、是否可以

17、覆盖安装、是否可以升级安装、是否允许多 版本共存、是否有注册码或硬件加密狗、在没有它们（或错误）的情况下能否顺利 安装。软件反安装测试1）卸载后注册表中的注册信息及相关的程序安装目录是否能完全删除掉2）卸载过程中完全删除共享文件后，看其他程序能否正常运行3）卸载后是否对其他已安装的程序有影响4）系统卸载后用户建立文档是否保留5）软件卸载画面上的软件名称及版本信息是否正确6）在所有能中途退出卸载的位置是否能正确退出7）卸载过程中界面显示与提示语言是否准确、友好8）卸载后安装此系统能否打开原来保存的文件，并一切运行正常9）卸载过程如果要求重新启动机器，在重启动之间是否给用户提示以保存现有的已运 行

18、的程序资料10）是否可以选择组件进行卸载11）卸载过程中对意外情况的处理（断电等）12）在卸载过程中，是否有中止或者结束按钮恢复性测试软件测试是发现软件中的大部分缺陷的一种技术。软件测试大体上划分为三大阶段：单元测 试、集成测试、系统测试。系统测试是检验整个系统是否满足需求规格说明书所提出的 所有需求。其中系统测试的非功能性测试包括可靠性测试、容错测试和恢复性测试等。可恢复性测试是测试一个系统从灾难或出错中能否很好的恢复的过程，如遇到系统崩溃、硬 件损坏或其他灾难性出错。可恢复性测试一般是通过人为的各种强制性手段让软件或硬件出 现故障，然后检测系统是否能正确的恢复（自动恢复和人工恢复）。简单的

19、说，可恢复性测 试是一种对抗性的测试过程。在测试中将把应用程序或系统置于极端的条件下或者模拟的极 端条件下产生故障，然后调用恢复进程，并检测、检查和核实应用程序和数据能否得到正确 的恢复。可恢复性测试通常需要关注恢复所需要的时间以及恢复的程度。例如当系统出错时能否在指 定时间间隔内修正错误并重新启动系统。对于自动恢复需验证重新初始化、检查点、数据恢 复和重新启动等机制的正确性；而对于需要人工干预的恢复系统，还需估计平均修复时间， 确定其是否在可接受的范围内。安全性测试安全性测试是有关验证应用程序的安全服务和识别潜在安全性缺陷的过程。软件安全性测试 包括程序、数据库安全性测试，根据系统安全指标不

20、同测试策略也不同。一个完整的web安全测试可以从部署与基础结构、输入验证、身份验证、授权、配置管理、 敏感数据、会话管理、加密、参数操作、异常管理、审核和日志记录等几个方面入手。用户认证安全测试要考虑问题：1. 明确区分系统中不同用户权限2, 系统中会不会出现用户冲突3. 系统会不会因用户权限的改变造成混乱4. 用户登录密码是否是可见、可复制5, 是否可以通过绝对路径登录系统（拷贝用户登录后的链接直接进入系统）6, 用户退出系统后是否删除所有鉴权标记，是否可以使用后退键而不通过输入口令进入系 统系统网络安全的测试要考虑问题1. 测试采取的防护测试是否正确装配好，有关系统的补丁是否打上2. 模拟

21、非授权攻击，看防护系统是否坚固3. 采用成熟的网络漏洞检查工具检查系统相关漏洞（即用最专业的黑客攻击工具攻击试一 下，现在最常用的是NBSI系列和IPhacker IP）4. 采用各种木马检查工具检查系统木马情况5. 采用各种防外挂工具检查系统各种程序的外挂漏洞数据库安全考虑问题1. 系统数据是否机密（比如银行系统）2. 系统数据的完整性3. 系统数据可管理性4. 系统数据的独立性5. 系统数据可备份与恢复能力（数据备份是否完整，可否恢复，恢复是否可以完整）兼容性测试兼容性测试是指测试软件在特定的硬件平台上、不同的应用软件之间、不同的操作系统平台 上、不同的网络等环境中是否能够很友好的运行的测

22、试。兼容性测试的主要目的是为了兼容第三方软件，确保第三方软件能正常运行。具体表现如下：1. 待测项目在不同的操作系统平台上正常运行，包括待测试项目能在同一操作系统平台上 的不同版本上正常运行。2. 待测项目能与相关的其他软件或系统协调工作3. 待测项目能在指定的硬件环境中正常运行4. 待测项目能在不同的网络环境中正常运行兼容性测试主要可分为三大类：硬件兼容性测试、软件兼容性测试、数据兼容性测试。硬件兼容与整机兼容与外设兼容软件兼容操作系统/平台应用软件之间的兼容不同浏览器的兼容数据库的兼容软硬件配合兼容数据兼容不同版本间的数据兼容不同软件间的数据兼容内存泄露测试内存泄露指由于疏忽或错误造成程序

23、未能释放已经不再使用的内存的情况。内存泄露并非指 内存在物理上的消失，而是应用程序分配某段内存后，由于设计错误，失去了对该段内存的 控制，因而造成了内存的浪费。一般我们常说的内存泄露是指堆内存的的泄露。堆内存是指程序从堆中分配的，大小任意的 （内存块的大小可以在程序运行期决定），使用完后必须显式释放的内存。应用程序一般使 用malloc，calloc，realloc等函数从堆中分配到一块内存，使用完后，程序必须负责相应的 调用free或delete释放该内存块，否则这块内存就不能再被使用，我们就说这块内存泄露了。 常发性内存泄露：发生内存泄露的代码会被多次执行到，每次被执行的时候都会导致一块内

24、 存泄露。偶发性内存泄露：发生内存泄露的代码只有在某些特定环境或操作过程下才会发生。常发性 或偶发性是相对的。对于特定的环境，偶发性的也许就变成了常发性的，所以测试环境测试 方法对检测内存泄露至关重要。一次性内存泄露：发生内存泄露的代码只会被执行一次，或者由于算法上的缺陷，导致总会 有一块且仅一块内存发生泄露。隐式内存泄露：程序在运行过程中不停分配内存，但是直到结束的时候才释放内存。严格的 说这里并没有发生内存泄露，因为最终程序释放了所有申请的内存。但是对于一个服务器程 序，需要运行几天，几周甚至几个月，不及时释放内存也可能导致最终耗尽系统所有内存。 所以我们称这类内存泄露为隐式内存泄露。Al

25、pha测试a测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环 境下进行的测试。a测试的目的是评价软件产品的FLURPS（即功能、局域化、可使用性、 可靠性、性能和支持）。尤其注重产品的界面和特色。a测试可以从软件产品编码结束之时 开始，或在模块（子系统）测试完成之后开始，也可以在确认测试过程中产品达到一定的稳定 和可靠程度之后再开始。a测试是指软件开发公司组织内部人员模拟各类用户行对即将面市软件产品进行测试，试图 发现错误并修正a测试的关键在于尽可能的逼真的模拟实际运行环境和用户对软件产品的 操作并尽最大努力涵盖所有可能的用户操作方式。经过a测试调整的软件产品称为

26、8版本。 a测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环 境下进行的受控测试，a测试不能由程序员或测试员完成。a测试发现的错误，可以在测试 现场立刻反馈给开发人员，由开发人员及时分析与处理。目的是评价软件产品的功能、可使 用性、可靠性、性能和支持。尤其注重产品的界面与特色。a测试可以在软件产品编码结束 之后开始，或在模块测试完成后开始，也可以在确认测试过程中产品达到一定的稳定和可靠 度之后再开始。a测试的特点：1. 它是在开发环境下进行的，不对发布2. 它不需要测试用例评价软件使用质量3. 用户往往没有相关经验，可以是兼职人员，开发者或测试者坐用户旁边4. 目

27、 的主要是评价产品的 FLURPS-Function、Location、Usability Reliability Performance Security即功能、局域化、可用性、可靠性、性能和技术支持。Beta测试Beta测试是一种验收测试，所谓验收测试是软件产品完成了功能测试和系统测试之后，在 产品发布之前所进行的软件测试活动，它是技术测试的最后一个阶段，通过了验收测试，产 品就会进入发布阶段。验收测试一般根据产品规格说明书严格检查产品，逐行逐字的对照说 明书上对软件产品所做出的各方面要求，确保所开发的软件产品符合用户的各项要求。通过 综合测试之后，软件已完全组装起来，接口方面的错误也已排

28、除，软件测试的最后一步一验 收测试即可开始。Beta测试由软件的最终用户们在一个或多个客房场所进行。与Alpha测试不同，开发者通常 不在Beta测试现场，因Beta测试是软件在开发者不能控制的环境中的真实应用。用户Beta 测试中遇到的一切问题，并且定期把这些问题报告给开发者。接收到在Beta测试期间报告 的问题之后，开发者对软件产品进行必要的修改，并准备向全体客户发布最终的软件产品。测试的执行过程测试计划确定各测试阶段的目标和策略。这个过程将输出测试计划，明确要完成的测试活动，评估完 成活动所需要的时间和资源，设计测试组织和岗位职权，进行活动安排和资源分配，安排跟 踪和控制测试过程的活动。

29、测试目标测试范围开始标准完成标准测试重点和优先级需考虑的特殊事项测试用例测试用例就是一个文档，描述输入、动作、或者时间和一个期望的结果，其目的是确定应用 程序的某个特性是否正常的工作。软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入（前置条件、 操作步骤、预期结果。测试用例的编号有一定规则，比如系统测试用例编号这样定义规则：project-st-001，命名规 则为项目名称+测试阶段类型（系统测试阶段）+编号。定义测试用例编号，便于查找测试 用例，便于测试用例的跟踪。测试标题是对测试用例的描述，测试用例标题应该清楚表达测试用例的用途。比如“测试用 户登录时输入错误密码时，软

30、件的响应情况”。重要级别：定义测试用例的优先级别，可以笼统的分为“高、“低”两个级别。一般来说如 果软件需求的优先级为高，那么针对该需求的测试用例优先级也为“高”；反之亦然。输入限制条件：提供测试执行中的各种输入条件。根据需求中的输入条件，确定测试用例的 输入。测试用例的输入对软件需求当中的输入有很大的依赖性，如果软件需求中没有很好的 定义需求的输入，那么测试用例设计中会遇到很大的障碍。操作步骤：提供测试执行的过程步骤。对于复杂的测试用例，测试用例的输入需要分为几个 步骤完成，这部分内容在操作步骤中详细列出。预期结果：提供测试执行的预期结果，预期结果应该根据软件需求中的输出得出。如果在实 际测

31、试过程中，得到的实际结果与预期结果不符，那么测试不通过；反之则测试通过。测试缺陷软件缺陷（Defect），常常又被叫做Bug。所谓软件缺陷，即为计算机软件或程序中存在的 某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。缺陷的属性缺陷标识（Identifier）是标记某个缺陷的一组符号，每个缺陷必须有一个唯一的标识、缺陷基 本信息、缺陷的标题、缺陷严重程度（Severity）是指因缺陷引起的故障对软件产品的影响 程度、缺陷优先级（Priority）指缺陷必须被修复的紧急程度；缺陷状态（Status）指缺陷通 过一个跟踪修复过程的进展情况、缺陷起源（Origin）指缺陷引起的故障或事件第一次

32、被检 测到的状态、缺陷提交人、缺陷提交时间、缺陷所属项目和模块、缺陷处理人、缺陷处理时 间、对缺陷处理结果的描述、缺陷验证人、缺陷验证结果描述、缺陷验证时间、缺陷的详细 描述、必要的附件等。缺陷严重程度（Severity）缺陷严重等级划分A类【紧急（critical）】导致系统崩溃、死机；出现不可挽救的数据丢失或损坏、内存泄露。B类【高（very high）导致程序模块丢失；软件错误导致数据丢失；用户需求未实现。C类【中（high）影响系统正常运行的缺陷，主要功能出现错误，影响到产品的使用；D类【低（medium） 一般性错误或者一些建议性的错误。A类bug描述：1、系统崩溃，如应用程序死掉、

33、应用程序异常退出、通讯意外中断或系统进入死循环。2、基本功能无法实现或遗漏，如某一应用程序启动不了或关键活动无法运行，关键数据丢 失较多。3、性能问题，如操作实时失败、数据库读写效率低。4、无法正常安装5、升级脚本错误，使升级失败。6、内存使用错误，如内存泄露、内存溢出、数组越界等。7、进程资源不能释放。B类bug描述：1、基本功能存在部分问题或次要功能无法实现或遗漏2、程序抛出异常信息没有处理，如空指针、通讯异常等。3、安装后文件不全、文件错误造成基本功能无法实现。4、前后台版本不兼容。C类bug描述1、次要功能存在部分问题2、界面存在明显缺陷，设计不友好、不完善3、安装时的小问题，或者安装

34、后文件不全、文件错误造成次要功能无法实现。D类bug描述1、界面不规范2、辅助说明描述不清楚3、输入输出不规范4、长操作未给用户提示5、提示窗口文字未采用行业术语6、建议性的改进要求缺陷优先级（Priority）（高、中、低）1 Resolve Immediately缺陷必须被立即解决。2 Normal Queue缺陷需要正常排队等待修复 或列入软件发布清单。3 Not Urgent缺陷可以在方便时被纠正。缺陷状态（Status）Submitted已提交的缺陷Open确认“提交的缺陷”，等待处理Rejected拒绝“提交的缺陷”， 不需要修复或不是缺陷Resolved缺陷被修复Closed确认

35、被修复的缺陷，将其关闭 缺陷起源（Origin）缺陷起源 描述Requirement在需求阶段发现的缺陷Architecture在构架阶段发现的缺陷 Design在设计阶段发现的缺陷Code在编码阶段发现的缺陷Test在测试阶段发现的缺陷测试管理工具（Qulity Center为例）Quality Center是Mercury Interactive公司推出的一个基于Web且支持测试管理的所有必要方 面的应用程序。该软件提供统一、可重复的测试流程，用于收集需求、计划和安排测试、分 析结果并管理缺陷和问题。组织可使用该软件在较大的应用程序生命周期中实现特定质量流 程和过程的数字化。该软件还支持在

36、IT团队间进行高水平沟通和协调。QC的主要功能1、QC有助于维护测试的项目数据库，这个数据库涵盖了应用程序功能的各个方面。设计 了项目中的每个测试，以满足应用程序的某个特定的测试需求。要达到项目的各个目标， 可将项目中的测试组织成各种特定的组。QC提供了一种直观、高效的方法，用于计划 和执行测试集、收集测试结果以及分析相关数据。QC还具有一套完善的系统，用于跟 踪应用程序缺陷，通过它，您可以在从初期检测到最后解决的整个过程中严密监视缺陷。 将QC链接到电子邮件系统，所有应用程序开发、质量保证、客户支持和信息系统人员 可以共享缺陷跟踪信息。2、QC 可以集成 Mercury 测试工具(WinRu

37、nner、QuickTest Professional、LoadRunner 等) 以及第三方和自定义测试工具、需求和配置管理工具。QC可以无缝的与您选择的测试 工具通信，提供一种完整的解决方案，使应用程序测试完全自动化。3、QC可指导您完成测试流程的需求指定、测试计划、测试执行和缺陷跟踪阶段。它把应 用程序测试中所涉及的全部任务集成起来，有助于确保客户能够得到最高质量的应用程 序。需求管理(Requirements)需求管理是测试管理的第一步。需求管理可以定义哪些功能需要测试，哪些功能不需要测试， 它是我们成功进行测试管理的基础。在需求管理模块中，所有的需求都是用需求树(需求列 表)来表示的

38、。可以对需求树中需求进行归类和排序，还可以自动生成需求报告和统计图表。 需求管理模块中还可以自动和测试计划模块相关联，将需求中的需求自动导出到测试计划 中，需求管理功能的好处是，当需求发生变动时，能够很快定位变化的需求以及相应的责任 人。备注【需求当前的状态】，默认情况下需求为Not CoveredNot Covered：这个需求没有被链接到测试Failed :覆盖此需求的一个或多个测试被执行，且状态为failedNot Completed :覆盖此需求的一个或多个测试被执行，且状态为Not CompletedPassed :覆盖此需求的所有测试均有同样状态PassedNo Run：覆盖此需求

39、的所有测试均有同样状态No RunN/A：不适用用编号方式显示测试需求、切换至需求覆盖分析视图查看；上交生成测试报告。测试计划管理(Test Plan )设计完测试需求后，下一步就需要对测试计划进行管理了。在测试计划中，需要创建测试项， 并为每个测试项目编写测试步骤，也就是测试实例，包括操作步骤、输入数据、期望结果等。 我们还可以在测试计划和需求之间建立连接(将测试用例与需求关联)。除了创建功能测试项以外，还可以创建性能测试项，引入不同测试工具生成测试脚本。例如 LoadRunner， QuickTestProfessional 等。测试执行管理(Test LAB)设计完测试用例之后，就可以执行测试了，执行测试是整个过程的核心。测试执行模板就是 对测试计划模板中静态的测试项的执行过程，在执行过程中需要为测试项创建测试集进行测 试，一个测试集可以包含多个测试项。在界面的左侧列举了所有的测试集合(Test Sets)。测试集合是测试项的集合，一个测试集 合可以包含若干个测试项。它可以看做是测试实例的动态执行过程。执行结果说明 测试项的默认状态为No Run即没有执行Failed：测试集合中的部分实例执行没有通过N/A：测试实例无法执行No Run：所有的测试实例没有执行 Not Complete：部分实例没有执行 Passed :通过缺陷管理（Defects）