第一章-软件测试基础、流程与规范

1、第一章软件测试流程与规范 目录 软件测试理论 软件测试模型 软件测试计划 软件测试环境 软件测试方法 软件测试阶段 软件测试用例 软件配置管理 软件缺陷管理 软件文档管理软件测试理论 -基本概念 软件系统的重要性视频：新闻报道视频：新闻报道( (软件缺陷引起的生产事故）软件缺陷引起的生产事故）软件测试理论 -基本概念 引起软件缺陷的原因ErrorMistakeDefectFaultBugFailure）人类历史上第一个程序人类历史上第一个程序BUGBUG软件测试理论 -基本概念 测试目的 检查产品需求是否全部实现 检查产品完整性（包括相关的组件） 确保软件产品在发布前软件缺陷均定位并解决 一个

2、成功的测试是发现了至今尚未发现的错误找错测试目标： 发现缺陷； 增加对质量的信心； 为决策提供信息； 预防缺陷。 软件测试理论 -基本概念 软件测试的定义 软件测试是为发现缺陷而执行程序的一组过程。 软件测试，通常是按软件需求规格说明和程序的内部结果而精心设计一组测试用例，并依据测试用例执行测试并发现错误。软件测试理论 -基本概念 质量的定义 软件质量是软件特性的总和，软件满足规定或潜大的用户需求。 软件产品质量是所生产的软件产品的质量，包括软件系统以及组成它们的所有元素。 过程质量是指为保证产品质量而采用的实现过程（包括措施和标准）的质量。软件测试理论 -基本概念 软件测试的类型 按开发阶段

3、划分 按测试实施的组织划分 按测试技术划分软件测试理论 -基本概念 测试与调试的区别 测试：找错 调试：排错（定位、修改）瀑布模型需求分析需求评审概要设计概要设计评审详细设计编码走查单元测试集成测试系统测试测试计划用例设计测试流程测试评审各子模块省略迭代开发与测试软件测试模型 V模型客户需求客户需求需求分析需求分析概要设计概要设计详细设计详细设计编码编码单元测试单元测试集成测试集成测试系统测试系统测试验收测试验收测试软件测试模型 V模型 特点：V模型是瀑布模型的延伸，其开发各阶段结构清晰，软件开发与测试分离 作用：早期的软件开发模型，能够明确软件开发的各个阶段，适用于小型软件项目的开发。 局限

4、：测试在编码后，软件缺陷发现的较晚，修复成本较高。软件测试模型 W模型客户需求客户需求需求分析需求分析概要设计概要设计详细设计详细设计编码编码单元测试单元测试集成测试集成测试系统测试系统测试验收测试验收测试验收测试设计验收测试设计系统测试设计系统测试设计集成测试设计集成测试设计单元测试设计单元测试设计集成集成实施实施交付交付软件测试模型 W模型 特点：W模型是V模型的延伸，加强了V模型中各个阶段的测试，并将开发与测试同步。 作用：针对各个阶段进行监控，能够较早的发现软件中的缺陷。 局限：同V模型一样，仍将需求至编码阶段作为串行实施，前后依赖较强，不利于变更。软件测试模型 H模型 测试准备测试就

5、绪点测试执行其他流程测试流程软件测试模型 H模型 特点：较早发现软件中的缺陷，能够适应软件项目的动态变更。 作用：将软件测试过程贯穿于整个项目周期，各阶段测试按层次进行，并且测试过程可循环实施。 局限：前期投入较大，各阶段交互时间较长，变更频繁也对软件产品质量构成威胁。软件测试模型 X模型软件测试模型 X模型 特点：该模型左半部分是针对程序片段进行相互分离后进行频繁的交接，最后合成可执行程序；右半部分即对生成的可执行程序进行测试，同时有针对性进行各种测试。 作用：能够节约时间，较早发现软件产品的缺陷 局限：前期的拆分过多，对测试人员要求较高，实施较难。计划 什么是计划？第一：应当具有明确的目标

6、；第二：计划工作必须先于其它各项管理活动而展开；第三：计划必须是准备付诸实施、切实可行的方案，不允许任何为了计划而计划的活动；第四：计划必须有益于在总体上提高管理的效益，虽然制定计划所造成的消耗也属于组织活动的成本，但这种消耗必须获得高额的回报。计划 计划的特征 计划应具有明确性 计划必须具有全面性 计划必须具有协调性 计划必须具有弹性 计划必须具有功利性计划的目的是用来识别任务、分析风险、规划资源和确定进度计划的目的是用来识别任务、分析风险、规划资源和确定进度软件测试计划 测试计划的目的 使软件测试工作进行更顺利 促进项目参加人员彼此的沟通 使软件测试工作更易于管理任何测试计划都是保证软件质

7、量，提高工作效率。任何测试计划都是保证软件质量，提高工作效率。 软件测试计划 测试计划的原则 制定测试计划应尽早开始 保持测试计划的灵活性 保持测试计划简洁和易读 尽量争取多渠道评审测试计划 计算测试计划的投入软件测试计划 测试计划文档应该包括如下内容 目标 概述、术语 组织形式 角色及职责 测试对象 测试通过/失败的标准 测试挂起的标准及恢复的必要条件 测试任务安排 应交付的测试工作产品 工作量估计软件测试计划-1 目标 表示该测试计划所应该达到的目标 概述 项目背景：如项目的主要功能特征，体系结构，简要历史等 范围：指明该计划的使用对象，范围 术语：项目中的特定名称 组织形式 表示测试计划

8、执行过程中的组织结构及之间的关系，以及所需要的组织的独立程度。 同时指出测试过程与其他过程（开发，管理，）之间的关系。 还包括沟通渠道等软件测试计划-2 角色与职责定义角色及其职责，在每个角色与测试任务之间建立关联。 测试对象列出所有将被作为测试目标的测试项（功能需求，非功能需求)软件测试计划-3 测试通过/失败的标准指明了判断/确认测试何时结束，以及所测试的应用程序的质量。可以直接陈述，也可以引用其他的文档。至少应该说明： 什么将被测试？ 度量尺度是如何建立的? 使用了哪些标准对度量进行评价? 测试挂起的标准以及恢复的必要条件指明挂起全部或部分测试项的标准,并指明恢复测试的标准及其必须重复的

9、测试活动。软件测试计划-4 测试任务安排明确测试任务。对于每个任务说明： 各阶段任务 方法和标准 输入/输出 时间安排 资源 风险和假设 角色和职责软件测试计划-5 应交付的测试工作产品指明应该交付的文档，测试代码及测试工具，一般包括测试计划，测试方案，测试用例，测试规程，测试日志，测试事故报告，测试总结报告，测试输入以及测试输出，测试工具。 工作量估计给出前面定义任务的人力需求及总计。测试计划的变更软件测试环境 软件测试环境组成软件测试环境硬件环境网络环境软件环境软件测试环境 硬件环境 服务器、客户端、网络设备、硬盘、CPU、内存以及打印机、扫描仪等辅助硬件设备所构成的环境 硬件环境的最低配

10、置软件测试环境 软件环境 操作系统 数据库 软件开发平台 浏览器 应用软件 杀毒软件 软件测试环境 网络环境 网络设备 网络结构 网络系统软件测试环境 配置测试环境主要遵循以下原则： 被测试软件运行的是低配置要求，即测试环境首先要保证支撑软件正常运行； 测试环境应量简单、独立，避免不相关的软件影响测试的实施； 软件版本保持最新，同时避免安装多个版本； 保证测试平台没有病毒； 保证环境前后一致； 兼容性检查等软件测试环境 通用测试环境的要求 尽可能真实的环境 符合软件运行的最低要求 选用比较普及的操作系统和软件平台 营造纯净、独立的测试环境 无毒的环境软件测试环境 测试环境与测试阶段的关系测试环

11、境的真实性测试环境的真实性测测试试环环境境的的完完整整性性软件测试环境影响软件测试环境的因素影响软件测试环境的因素 因素因素测试级别测试级别 Unit Integration System Acceptance 测试者Developers Developers & Testers Testers Testers & Users 硬件平台Programmers Workbench Programmers Workbench System Test Machine or Region Mirror of Production 操作系统中的共存软件None None None/Actual Actu

12、al 接口 None Internal Simulated & Real Production 测试数据来源Manually Created Manually Created Production & Manually Created Production 测试数据量Small Small Large Large 策略Unit Groups of Units/Builds Entire System Simulated Production 软件测试环境 测试环境的备份 测试过程中会遇到多种不可预测的事情发生，一但造成系统崩溃，则会造成测试数据丢失、测试过程中断或者测试环境的重新搭建 经常对测

13、试环境进行多次必要的备份是一个必备的预防措施和一个比较好的习惯 对测试环境的备份可以挽回不必要的损失、节省测试的时间、保持测试的连续性软件测试环境 测试环境的恢复 一旦测试环境遭到破坏，可以还原最近备份的系统，实现测试环境的恢复 目的 维持测试环境的一致性 恢复测试数据 恢复测试环境的当前状态软件测试环境 测试环境备份和恢复工具 Ghost Partimage 还原精灵等软件测试环境 测试环境对结果的影响 测试数据信息不准确 软件测试不充分 软件运行速度 软件的兼容性 软件测试方法 白盒测试方法 灰盒测试方法 黑盒测试方法软件测试方法 什么是白盒测试（white-box testing） 白盒

14、测试是依据被测试软件，分析程序内部构造，并根据内部构造设计用例后进行测试。软件测试方法 白盒测试一般会用到静态分析和动态分析两类技术，常用的有： 静态分析：控制流分析，数据流分析，信息流分析等 动态分析：逻辑覆盖测试（分支测试，路径测试等），程序插装测试用例设计方法 白盒测试用例设计方法 语句覆盖 判定覆盖 条件覆盖 判定/条件覆盖 组合覆盖 路径覆盖白盒测试用例设计方法 语句覆盖 指设计若干个测试用例，运行被测程序，使得每一可执行语句至少执行一次。这种覆盖又称为点覆盖，它使得程序中每个可执行语句都得到执行，但它是最弱的逻辑覆盖准，效果有限，必须与其它方法交互使用语句覆盖示例例: IF CON

15、DITION THEN DO_SOMETHING; ELSE DO_SOMETHING_ELSE; END IF;语句覆盖优缺点 优点： 可以很直观地从源代码得到测试用例，无须细分每条判定表达式 缺点： 由于这种测试方法仅仅针对程序逻辑中显式存在的语句，但对于隐藏的条件和可能到达的隐式逻辑分支，是无法测试的 白盒测试用例设计方法 判定覆盖 指设计若干个测试用例，运行被测程序，使得程序中每个判断的取真分支和取假分支至少经历一次。判定覆盖又称为分支覆盖判定覆盖示例例: IF CONDITION THEN DO_SOMETHING; ELSE DO_SOMETHING_ELSE; END IF; T

16、EST: CONDITION 1 TRUE 2 FALSE判定覆盖优缺点 优点： 判定覆盖比语句覆盖要多几乎一倍的测试路径，当然也就具有比语句覆盖更强的测试能力。同样判定覆盖也具有和语句覆盖一样的简单性，无须细分每个判定就可以得到测试用例 缺点： 大部分的判定语句是由多个逻辑条件组合而成（如，判定语句中包含AND、OR、CASE），若仅仅判断其整个最终结果，而忽略每个条件的取值情况，必然会遗漏部分测试路径。白盒测试用例设计方法 条件覆盖 指设计若干个测试用例，运行被测程序，使得程序中每个判断的每个条件的可能取值至少执行一次。 条件覆盖示例例:IF (A1) AND (B=0) THEN X=X

17、/A IF (A=2) OR (X1) THEN X=X+1 条件中判定条件中判定A1，为真时，记： T1A1，为真时，记： T4X=1，为假时，记： F4满足覆盖条件的测试例测试用例ABX覆盖条件Case1103F1、T2、F3、T4Case2211T1、F2、T3、F4条件覆盖示例 满足覆盖条件的测试例测试用例ABX覆盖条件Case1103F1、T2、F3、T4Case2211T1、F2、T3、F4条件覆盖优缺点 优点： 条件覆盖比判定覆盖，增加了对符合判定情况的测试，增加了测试路径 缺点： 要达到条件覆盖，需要足够多的测试用例，但条件覆盖并不能保证判定覆盖。条件覆盖只能保证每个条件至少有

18、一次为真，而不考虑所有的判定结果 白盒测试用例设计方法 判定-条件覆盖 指设计足够的测试用例，使得判断中每个条件的所有可能取值至少执行一次，同时每个判断本身的所有可能判断结果至少执行一次。示例X、Y取值如下表Test Case X Y 覆盖路径case 1 90 90 OAEcase 2 50 50 OBDEcase 3 90 70 OBCEcase 4 70 90 OBCE判定-条件覆盖示例X、Y取值如下表Test Case X Y 覆盖路径case 1 90 90 OAEcase 2 50 50 OBDEcase 3 90 70 OBCEcase 4 70 90 OBCE判定-条件覆盖优缺

19、点 优点： 判定/条件覆盖满足判定覆盖准则和条件覆盖准则，弥补了二者的不足 缺点： 判定/条件覆盖准则的缺点是未考虑条件的组合情况 白盒测试用例设计方法 组合覆盖 设计足够多的测试用例，使得每个判定中条件结果的所有可能组合至少出现一次。组合覆盖示列X、Y取值如下表 Test Case X Y 覆盖路径 case1 90 90 OAE case2 90 70 OBCE case3 90 30 OBDE case4 70 90 OBCE case5 30 90 OBDE case6 70 70 OBDE case7 50 50 OBDE组合覆盖优缺点 优点： 多重条件覆盖准则满足判定覆盖、条件覆盖

20、和判定/条件覆盖准则。更改的判定/条件覆盖要求设计足够多的测试用例，使得判定中每个条件的所有可能结果至少出现一次，每个判定本身的所有可能结果也至少出现一次。并且每个条件都显示能单独影响判定结果 缺点： 线性地增加了测试用例的数量 白盒测试用例设计方法 路径覆盖 设计足够的测试用例，覆盖程序中所有可能的路径。 路径覆盖示例X、Y取值如下表 Test Case X Y覆盖路径case 1 90 90 OAEcase 2 50 50 OBDEcase 3 90 70 OBCEcase 4 70 90 OBCE路径覆盖优缺点 优点： 可以对程序进行彻底的测试，比前面五种的覆盖面都广 缺点： 由于路径覆

21、盖需要对所有可能的路径进行测试（包括循环、条件组合、分支选择等），那么需要设计大量、复杂的测试用例，使得工作量呈指数级增长 白盒测试的优缺点 优点： 针对程序内部进行覆盖测试，覆盖率较高 能较早期的发现程序中的缺陷 缺点： 设计过于复杂 无法验证程序的外部特性 需求变更时，付出的代价较大软件测试方法 什么是灰盒测试（Gray-box testing） 灰盒测试是介于白盒测试与黑盒测试之间的测试。灰盒测试关注输出对于输入的正确性；同时也关注内部表现，但这种关注不像白盒测试那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态。 最常见的灰盒测试是集成测试，它关心集成模块之间的接

22、口数据。测试用例设计方法 灰盒测试用例设计方法测试用例设计 灰盒测试的优缺点 优点： 借助测试工具实现手工无法实施的测试 能够重复利用设计的测试用例 可靠性高 缺点： 软件项目前期投入大，成本较高 不利于变更 无法替代手工测试软件测试方法 什么是黑盒测试（black-box testing） 黑盒测试主要关注被测试软件的功能和非功能属性的实现，测试人员对被测试产品的验证主要是根据其需要规格，验证其与规格的一致性测试用例设计 黑盒测试用例设计方法 等价类划分法 边界值分析法 因果图法 错误推测法 场景分析法 判定表驱动分析方法 正交实验设计方法黑盒测试用例设计方法 等价类划分法 有效等价类：有效

23、等价类是程序规格说明有意义，合理的输入数据， 无效等价类：无效等价类是程序规格说明无意义，不合理的输入数据。黑盒测试用例设计方法 边界值分析法 边界值分析的理论基础，是假定大多数的错误是发生在各种输入条件的边界上，如果在边界附件的取值不会导致程序出错，那么其它的取值导致程序错误的可能性也很小。黑盒测试用例设计方法 因果图法 因果图法是一种适合于描述对于多种条件的组合、相应产生多个动作的形式的测试用例设计方法 因果图基本符号 c1e1c3c2c1c2e1c1e1c1e1恒等非或与V约束符号babababacbaEIORM异或唯一要求强制因果图实例讲解 某软件规格说明中包含这样的要求： 第一列字符

24、必须是A或B，第二列字符必须是一个数字，在此情况下进行文件的修改。但如果第一列字符不正确，则给出信息L；如果第二列字符不是数字，则给出信息M 分开原因和结果 原因：1-第一列字符是A; 2-第一列字符是B; 3-第二列字符是一数字。 结果：21-修改文件; 22-给出信息L; 23-给出信息M因果V黑盒测试用例设计方法 错误推测法 根据经验猜想可能有什么问题并依据此设计测试用例。黑盒测试用例设计方法 场景分析法黑盒测试用例设计方法 判定表驱动分析方法 判定表通常由四个部分组成.条件桩（Condition Stub）:列出了问题得所有条件.通常认为列出得条件的次序无关紧

25、要.动作桩（Action Stub）:列出了问题规定可能采取的操作.这些操作的排列顺序没有约束.条件项（Condition Entry）:列出针对它左列条件的取值.在所有可能情况下的真假值.动作项（Action Entry）:列出在条件项的各种取值情况下应该采取的动作.黑盒测试用例设计方法 正交实验设计方法 指从大量的实验点中挑选出适量的、有代表性的点，应用依据Galois理论导出的“正交表”合理的安排实验的一种实验设计方法测试用例设计 黑盒测试的优缺点 优点： 不需了解程序内部的代码 从用户角度出发，能尽早发现常见的错误 易于实施 缺点： 覆盖率较低 重复工作量较大 依赖设计的测试用例，对测

26、试结果影响较大 对于软件规格说明书等文档缺陷无法发现测试用例设计 黑盒测试与白盒测试的比较测试方式特征依据测试人员测试驱动程序黑盒测试只关心软件的外部表现，不关心内部设计与实现。软件需求任何人（包括开发人员、独立测试人员和用户）一般无需编写额外的测试驱动程序白盒测试关注软件的内部设计与实现，要跟踪源代码的运行。设计文档由开发人员兼任测试人员的角色需要编写额外的测试驱动程序软件测试阶段（测试级别） 单元测试 集成测试 系统测试 验收测试 （回归测试）ISTQBISTQB定义定义测试级别测试级别 test level ：统一组织和管理的一组测试活动。测试级别与项目的职责相关联。例如，测试级别包括组

27、件测试/单元测试、集成测试、系统测试和验收测试。软件测试阶段 -单元测试 单元测试（Unit Testing） 测试的最早期阶段，焦点在于最小的被测软件单元软件测试阶段 -单元测试 桩模块的种类桩模块A桩模块B桩模块C桩模块D图例：信息流及方向显示跟踪信息显示参数返回参数（从表或外部文件）根据输入参数查表，返回相应输出参数软件测试阶段 -单元测试 驱动模块的种类驱动器A驱动器B驱动器C驱动器D图例：信息流及方向调用低层次模块传递参数（查表或外部文件）显示参数B和C的组合软件测试阶段 集成测试 集成测试（Integration Testing） 在运行（可能是不完整）的应用中保证软件单元被结合后

28、能正常操作的测试执行的阶段测试结果测试结果测试用例测试用例软件测试阶段 集成测试 自顶向下集成M1M2M3M4M5M6M8M7软件测试阶段 集成测试 自底向上集成M3M1M2D3D1D2簇1簇2簇3软件测试阶段 系统测试 系统测试（System Testing）ISO9126：系统测试是进行全面的系统工程级测试，其内容包括产品功能、性能指标、兼容性(包含互连性)、可靠性(包含满负荷)、容错能力、可维护性等方面。ISTQB：测试集成系统，以验证它是否满足指定需求的过程。 系统测试，英文是System Testing。是将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起，进行信息系统的各

29、种组装测试和确认测试，系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需求规格的定义，找出与需求规格不符或与之矛盾的地方，从而提出更加完善的方案。系统测试发现问题之后要经过调试找出错误原因和位置，然后进行改正。是基于系统整体需求说明书的黑盒类测试，应覆盖系统所有联合的部件。对象不仅仅包括需测试的软件，还要包含软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等。软件测试阶段 系统测试 系统测试（System Testing） 系统测试目的 验证系统功能是否符合需求规格定义 验证系统的可靠性、安全性、可维护性、适用性、稳定性、容错性等.软件测试阶段 系统测试 系统测试常见

30、类型:功能测试:性能测试:压力测试:容量测试:安全性测试:可用性测试:GUI测试:安装测试:配置测试:异常测试(破坏性测试):备份测试:健壮性测试:文档测试:在线帮助测试:网络测试:稳定性测试软件测试阶段 系统测试安装测试定义：可安装性测试，主要是根据软件的测试特性列表、软件安装、配置文件、设计安装过程的测试用例，发现软件在安装过程中的错误。目标：系统可安装性测试的目的不仅是找安装软件本身的错误。在安装软件系统时，会有多种选择，要分配和装入文件和程序，布置适当的配置，进行程序和联结。而安装测试就是要找出这些安装过程中出现的错误。软件测试阶段 系统测试配置测试定义：配置测试主要测试系统在各种软硬

31、件配置，不同的参数配置下系统具有的功能和性能。目标：验证全部配置的可操作性和有效性，特别需要对最大配置，最小配置或特殊配置进行测试。软件测试阶段 系统测试 文档测试（Documentation Testing） 指验证用户文档是正确的并且保证操作手册的过程能够正确工作。软件测试阶段 系统测试 在线帮助测试（Online Help Testing） 主要用于验证的实时在线帮助的可用性和正确性软件测试阶段 系统测试 网络测试 定义 网络测试是在网络环境下和其他设备对接，进行系统功能，性能与指标方面的测试，保证设备对接正常。 目标 网络测试考察系统的处理能力，系统兼容性，系统稳定可靠性及用户使用等方

32、面。软件测试阶段 系统测试 稳定性测试 定义：系统稳定性测试目的是评价系统在一定负荷情况下，长时间的运行情况。 目标: 包括系统在一定负荷下，再增加新的业务，原有的业务是否影响，新的业务是否能正常工作，系统资源有无泄露，数据有无不一致的情况，系统测试是否会降下来，关键点是长时间的运行后，系统的状况如何，系统平均无故障时间是否满足系统设计要求。软件测试阶段 系统测试 安全性测试（Security Testing） 用来验证集成在系统内的保护机制是否能够在实际中保护系统不受到非法的侵入。用来保证系统本身数据的完整性和保密性。如当受到恶意攻击时，设备的自我保护能力，病毒防护能力，自定义通信协议安全性

33、等。广义的还包括物理安全性测试，业务安全性测试软件测试阶段 系统测试 异常测试（又称破坏性测试） 容错性 可恢复性 网络故障 断电 传输异常中断 病毒影响等软件测试阶段 系统测试 备份测试 备份测试（Backup Testing）是恢复性测试的一个补充，目的是验证系统在软件或者硬件失败的事件中备份它数据的能力。软件测试阶段 系统测试 健壮性测试 健壮性测试（Robustness Testing）用于测试系统在出现故障时，是否能够自动恢复或者忽略故障继续运行。软件测试阶段 验收测试 验收测试 产品经过严格测试后最终提交验收 特点： 用户参与验收 测试环境尽可能模拟用户实际运行环境 按软件需格说明

34、书和验收测试计划实施软件测试阶段 验收测试 验收测试的整个过程 根据软件需求和验收要求编制计划，制定需测试的测试项，制定测试策略及验收通过准则，并经过客户参与的计划评审 根据验收测试计划、项目或产品验收准则完成测试用例的设计，并经过评审 准备测试数据、执行测试用例，记录测试结果 根据验收通过准则分析测试结果，做出验收是否通过及测试评价 软件测试阶段 回归测试 回归测试 指软件缺陷修复后再次测试测试结果分析改正错误可靠性分析软件配置测试配置测试工具回归测试测试结果预期结果预测可靠性改正的软件错误软件测试阶段 回归测试 回归测试策略 完全重复测试 选择性重复测试 仅回归修复的缺陷软件测试用例 测试

35、用例的定义 测试用例的作用与目的 测试用例设计原则软件测试用例 测试用例定义 测试用例是一个包含输入和预期输出的与程序行为有关的标识 软件测试的本质就是针对要测试的内容确定一组测试用例 测试用例是由测试中经过的一系列状态和在每个状态中必须依靠输入/输出数据满足的一对条件组成的软件测试用例 测试用例的作用与目的 执行测试，发现缺陷 重复执行测试，重现缺陷 管理测试过程 回归测试，验证缺陷是否修复使测试更加方便的执行软件测试用例 测试用例的作用与目的 提高测试效率 节省执行测试的时间 使测试更能按照时间计划进行 使测试过程更方便管理测试用例设计 测试用例设计原则 准确性 测试用例的设计确实符合测试

36、需求，并且必须准确地说明测试的内容 简洁性 测试用例的设计中必须包含完成测试必要的步骤、要素，不需要加入多余的、可有可无的步骤、要素测试用例设计 测试用例设计原则 可重用性 测试用例的设计要求测试是可控的，它能够使任何人在任何时间进行测试都能获得同样的结果 适用性 测试用例对于当前的测试环境和测试者而言是可以执行的测试用例设计 测试用例设计原则 可跟踪性 测试用例是针对特定测试需求的 独立性 不会因为执行该测试用例而影响其它测试用例的执行，用例中应说明如何将应用系统恢复到最初状态，而不影响后续测试的进行测试用例设计一个优秀的测试用例应该满足下列条件： 找出软件错误的可能性较大 不是冗余的，即不

37、过于复杂，又不过于简单 格式统一，描述清晰、简洁 无二义性测试用例设计 测试用例ID号 通常由测试用例管理工具自动生成的一组数字，具有唯一性。 项目名称 项目的名称是主要以英文缩写表示，有的也用模块名称的首字母表示。 例如：HIS测试用例设计 用例分类 用例分类主要是为了更好的归类问题，更具有代表性，通常分为：功能测试用例、性能测试用例等 前提条件 主要是在执行测试用例时，需要相关的数据作支持。 例如：注册用户的账号信息；等价类划分使用的数据。测试用例设计 用例优先级 通常将用例分为三类，高（Highs）、中（Mediums）、低（Lows）级别级别含义含义高（高（HighsHighs）指用例

38、必须执行，以保证软件功能正常工作。中（中（MediumsMediums） 指在给定的功能区域检查功能的多方面数据信息，包括边界、错误和配置测试的测试用例。低（低（LowsLows）指最少被执行的测试用例，这并不意味着该测试用例不重要，只是在测试过程中每次都运行，例如：用户界面、性能测试、易用性等。测试用例设计 测试环境 软件环境 通常包含：操作系统、数据库、浏览器、网络、办公软件、开发环境配置、自动化测试工具 硬件环境 通常包含：CPU、内存、硬盘、打印机、扫描仪等外部设备。测试用例设计 摘要信息（Summary） 用简明扼要的方式描述用例，通常不超过二十个字。 操作步骤 设计测试用例步骤注意

39、事项： 操作步骤清晰，易理解执行； 描述没有二义性 操作步骤数量不应过多，通常在8步左右较为合理 对于多种路径的操作，尽量分开设计多个测试用例测试用例设计 预期结果 按客户需求说明书、软件需求说明书、概要设计/详细设计说明书等规范要求，预测结果的值，依据该数据与实际执行获取的数据进行比较，最终确定用例成功或失败的标准 测试人员 主要是注明该测试用例的设计人员。测试用例设计 审核人员 主要是注明该测试用例的审核人员。 更新日期 主要是注明该测试用例最后更新的时间。 备注信息 其它需要注明的信息。 例如：用例执行的环境，是Windows或Linux操作系统测试用例设计项目名称软件版本优先级用例编号

40、用例分类summary前提条件/环境要求（测试要求的软、硬件、网络要求）：操作步骤输入说明（列出选用的输入项，覆盖正常、异常情况）：期望结果输出说明（逐条与输入项对应，列出预期输出）：备注信息（主要是执行用例时的注意事项）：设计人审核人日期软件配置管理 软件配置管理 软件配置管理简称SCM（Software Configuration Management），简单而言就是管理软件的变化，其应用于整个软件工程过程，通常由相应的工具、过程和方法学组成。软件配置管理 没有软件配置管理可能存在的问题 开发人员未经授权修改代码或文档 人员流动造成企业的软件核心技术泄密 找不到某个文件的早期版本 无法重现

41、早期版本 无法重新编译其个时间段的早期版本，直接影响维护工作软件配置管理 实施软件配置管理可能遇到的困难 软件系统复杂，编译速度慢，造成进度延误 已修复的Bug在新版本中出现 分处异地的开发团队难于协同，可能会造成重复工作，并导致系统集成问题 配置管理制度难于实施 构造版本时，开发冻结，造成进度延误软件配置管理 软件配置管理工具 ClearCase CVS VSS 软件配置管理 配置管理之间的逻辑关系软件缺陷管理 软件缺陷管理 缺陷的定义 缺陷的生命周期 缺陷的分类 缺陷的状态软件缺陷管理-缺陷 缺陷的定义 软件未达到产品说明书的功能要求 软件出现了产品说明书指明不会出现的错误 软件功能超出产

42、品说明收范围 软件未达到产品说明书虽未指出但应达到的目标 软件被认为难以理解、不易操作、运行速度慢或最终用户认为不好。软件缺陷管理-缺陷生命周期软件缺陷管理 缺陷的状态 New：报告一个Bug。 Open：验证后分配给相关的开发人员进行修改状态。 Fixed：开发人员修改后的状态。 Verified：等待测试人员验证的状态。 Reject：拒绝修改Bug。 Reopen：如果没修改成功，则重新打开。 Closed：如果修改成功，则关闭Bug。软件缺陷管理 缺陷的类型 功能缺陷 性能缺陷 兼容性缺陷 用户界面缺陷 设计文档缺陷 可靠性缺陷 安全性缺陷 易用性缺陷 安装/卸载缺陷等等。软件缺陷管理

43、-缺陷报告表项目名称：模块名称：缺陷状态：Bug_ID：严重级：版本号：测试环境：优先级：缺陷重现Summary：操作步骤：123456缺陷类型：报告人：缺陷所有人：附件：审核人：日期：软件缺陷管理-测试完成 测试何时结束？一、基于测试用例的规则 （1）先构造测试用例（并请有关人员进行评审）。 （2）在测试过程中，当测试用例的不通过率达到20时，则拒绝继续测试，待开发人员修正软件后再进行测试。 （3）当功能性测试用例通过率达到100，非功能性测试用例通过率达到90时，允许正常结束测试。 该规则的优点是适用于所有的测试阶段，缺点是太依赖于测试用例。如果测试用例非常糟糕，那么该规则就失效了。软件缺

44、陷管理-测试完成 测试何时结束？二、基于“测试期缺陷密度”的规则 把测试一个CPU小时发现的缺陷数称为“测试期缺陷密度”。 绘制“测试时间缺陷数”的关系图，如果在相邻n个CPU小时内“测试期缺陷密度”全部低于某个值m时，则允许正常结束测试。例如n大于10，m小于等于1。 该规则比较适用于系统测试阶段。软件缺陷管理-测试完成 测试何时结束？三、基于“运行期缺陷密度”的规则 把软件运行一个CPU小时发现的缺陷数称为“运行期缺陷密度”。 绘制“运行时间缺陷数”的关系图，如果在相邻n个CPU小时内“运行期缺陷密度”全部低于某个值m时，则允许正常结束测试。例如n大于100，m小于等于1。 该规则比较适用于验收测试阶段，即客户试运行软件期间。软件缺陷管理-缺陷管理工具 软件缺陷管理工具 Bugzilla TestDirector ClearQuest QAdirector BugFree .软件文档管理 软件文档管