软件测试教程

软件测试 软件测试的基本概念 测试现状 电子工程师和建筑工程师要远比软件工程师们训练有素，电子工程师们可以制造近乎0缺陷的包含上百万个晶体管的大规模集成电路。在有关Pentium处理器的热烈的缺陷声讨中，经常被忽略的是310万个晶体管中竟然只有一个缺陷。再看看软件，你上次看到的在310万行软件代码中只有一个缺陷是什么时候？硬件工程师们难道比软件工程师们更加聪明吗？他们达到的质量水平幅度远远高于软件，是因为他们更加训练有素，他们的开发和测试方法更加严格。他们愿意话更多的时间和精力来保证产品的完整性。他们真正认识到了缺陷所带来的影响：经济的或者其他的。建筑工程师在建造摩天大楼面临着同样的挑战。在他们的世界中，系统坍塌意味着建筑倒塌。 CMM的首要的而且也是最重要的目标是，建立一种机制来对软件工程是引进文化改变。测试工作是促进这个目标的重要手段。 测试的说明 不存在没有缺陷的代码，软件测试是为了发现错误而执行程序的过程。 任何软件均有缺陷，无论经过多么严格的测试，都不能确认已经发现了所有的缺陷；所以测试可以证明程序有错，而不能证明程序无错误。 测试的目标在于有效的发现缺陷，所以一个好的测试用例是在于它能发现至今未发现的错误。 验证：正确执行了活动，正确完成了产品 确认：执行了正确的活动，完成了正确的产品 测试属于确认工作，一个最优的测试用例集合原则上可以覆盖所有确认要求；同时测试工作属于验证工作，一个最优的测试用例集合应当可以发现所有的异常情况和错误；所以一个最优的测试过程原则上可以确认系统的要求被满足，并发现了所有的缺陷，而且开销最小。 测试工作的成果包括：一个确认结果的集合、一个缺陷集合；在实际操作中，确认结果的任务蕴含在测试用例中，如果通过了所有的测试用例，意味着确认结果集合的完备；这样测试工作的工作成果主要体现在缺陷集合上。 测试用例首先要满足确认要求，然后针对系统特性 设计 领导形象设计圆作业设计ao工艺污水处理厂设计附属工程施工组织设计清扫机器人结构设计 可以有效发现缺陷的测试用例。 质量说明 图1 软件工程：提供了质量的基础，分析、设计和构造方法通过提供一致的技术和可预测的结果帮助提高质量。 技术复审：通过对各个步骤产生的成果进行跟踪检查，控制质量。 测度：通过测量和数据分析来控制质量 SQA&SCM：SQA是支撑整个质量控制手段的监督协调机制，SCM是对产品进行管理的基础性设施。 标准 excel标准偏差excel标准偏差函数exl标准差函数国标检验抽样标准表免费下载红头文件格式标准下载 过程：在组织级保证一致性，从而实现更加广大范围的质量管理 测试：质量控制的最后堡垒，但是测试不能完全的保证质量；同时测试工作的高成本，也要求上述各方面机制的有效配合。 测试原则 测试工作的一些基本原则如下： 测试用例：所有测试均应当追溯到特定要求 测试过程：测试应当从“小规模”开始，逐步转向“大规模” 测试组织：为了达到最佳效果，测试应当由独立的第三方来进行 工具：依据选定的测试方法和测试过程选择工具，将测试工具和过程结合起来 测试的意义 过程反馈机制：测试集成到软件过程中，形成一个反馈环，从而快速的提高质量 可测试性 可测试性，是软件容易被测试的程度，主要包括下面几个指标： 可确认性：可以明确确认软件是否符合要求，例如有明确的要求和指标 可观察性：用于确认的结果可以进行有效的观察 可控制性：相对应的测试环境可以进行控制，从而保证测试的有效性 可分解性：软件可以进行分解，对分解的结构进行测试 测试体系 整个测试体系包括：测试过程、测试方法、测试工具、测试管理工具、测试用例库和缺陷库。他们之间的关系如下图： 图2 根据系统特性选择相应的测试方法 为了高效的利用测试方法，要使用有效的工具 通过测试过程灵活的组合各种测试方法，并进行有效管理 为了有效的管理和改进测试过程，要采用测试管理工具 测试过程的主要财富是“测试用例库”和“缺陷库” 通过分析“缺陷库”可以有效的进行过程改进，并评价一个软件的质量 白盒测试 白盒测试主要关注程序结构，通过分析程序中的关键结构设计测试用例。白盒测试通过逻辑覆盖、路径覆盖等方式选择测试用例，可以用测试覆盖率评价测试用例。 白盒测试的开销相比黑盒测试要大的多，一般情况下，我们不会对每个模块都进行白盒测试，只是选择重要个的模块进行。 程序的一些主要结构：语句、分支、逻辑路径、变量；所以白盒测试的主要方法是：语句覆盖方法、分支覆盖方法、逻辑覆盖方法。 语句覆盖方法 Tom McCabe提出的一种白盒测试方法，主要的技术在于环形复杂度的计算，具体步骤如下： 序号 步骤 说明 1 程序结构化 将程序转化为流图 2 环形复杂度计算 得到的是要覆盖所有语句，独立路径数量的上限N 3 构造独立路径 构造N条独立路径 4 确认分支点 针对每条独立路径，确认独立路径上的所有分支点 5 构造执行条件 根据一条独立路径上的所有分支点集合确认路径执行条件集合 6 编制用例 对这些路径和路径执行条件集合进行分析，编制用例 流图 各种程序结构的流图如下： 图3 “UNTIL”结构其实所有相关语句均会执行，所以可以将整个“UNTIL”作为一个节点。 “WHILE”结构类似于“IF”结构 “CASE”语句可以很方便的转化为“IF”结构 所以后面的讨论主要针对“IF”结构进行。 对于“IF”结构复杂判定要进行处理，实际说明系统运行的实际情况，如下图 图4 环形复杂度 根据流图的拓扑结构可以计算流图的环形复杂度，计算方法有： 序号 计算方法 1 环形复杂度=区域数量+1 2 环形复杂度=边的数量-节点数量+2 3 环形复杂度=判定节点数量+1 分支覆盖 分支覆盖测试是检查程序逻辑条件的测试用例方法。 一个逻辑条件的构成：布尔操作符、布尔变量、关系操作符、算术表达式，具体说明如下： 元素 构成结构 布尔操作符 AND，OR，NOT 布尔变量 T，F 关系操作符 <，>，=<，=<，=，<> 分支覆盖测试检查分支判断是否有错误，并对每个分支执行；覆盖了所有分支的测试用例集合一定也覆盖了所有的语句。分支覆盖测试用例的设计主要步骤入下： 序号 步骤 说明 1 寻找分支 寻找并定位所有分支 2 约束因素提取 对一个分支中的所有约束因素进行提取 3 分析取值分布 从判定条件的最外层开始进行约束因素的取值分析，要求保证每个约束因素的取值范围均被覆盖，并被划分为等价划分区域 4 编制用例 根据每个约束因素的取值分布，确定用例 逻辑覆盖 逻辑覆盖也叫做路径覆盖，即程序执行的路线的覆盖。考虑一个“WHILE”结构有10次循环，就至少包括10条逻辑路径，有些循环语句的循环次数比这个大得多，甚至可能随机出现，所以一个程序结构到底有多少逻辑路径都难以确定。这个意义上测试用例在逻辑覆盖率上很难进行测量。 从形式上我们可以确定，逻辑覆盖更加彻底，比较分支覆盖强度更大。如果检验了程序所有的逻辑路径可以确保程序不出现异常和错误情况，但是即使很小的一段程序，它的路径数量也是惊人的，所以追求全面的逻辑覆盖是不可能的。在技术上对程序进行语句覆盖是可行的，现行的技术也是较为完备的，并有一些辅助工具帮助实现。 对比的例子 如下面的流图： 图5 分支数量：6个 独立路径数量：5 逻辑路径数量：9个 循环测试 循环结构是程序结构的主要组成部分，针对循环的测试注重于循环结构的有效性，属于白盒测试的范畴。 循环根据他们之间的关系分为：简单循环、嵌套循环、串行循环。针对不同的循环应当由不同的方法。 简单循环的测试用例集合构造（N表示循环最大次数） 测试用例跳过整个循环 测试用例只通过一次循环 测试用例两次通过循环 测试用例通过M次循环（M 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 》进行评审，从而通过测试用例的充分和有效来保证软件的质量，测试完成的标准在于所有测试用例被通过。 单元测试 单元测试完成对软件最小的结构的测试，一般用来验证模块的功能属性，它利用设计文档作为指导，主要使用白盒测试技术；但也可以测试其它项目，如性能、可用性等等，可使用“黑盒”或“白盒”方法进行。在单元测试中，检查出模块内部的错误是单元测试的主要工作。单元测试一般看作验证的一种形式，因为它将功能模块的行为与功能规范进行比较。下面对单元测试的基本内容分别说明： 单元测试应当确定要检查的内容，并且依据一定的顺序进行，才能有效的进行单元测试。 测试的顺序： 1、接口测试：保证进出单元模块的数据流是正确的 2、局部数据结构：保证临时存储的数据在算法执行过程中的完整性 3、全局数据结构：全局数据结构对单元模块的影响应当审查 4、边界：采用边界值分析技术，保证模块在边界条件和及县情况下正常执行 5、语句覆盖：保证每个语句均执行一次 6、错误路径：对所有处理错误的路径进行测试 单元模块本身往往不是一个单独的程序，必须为每个模块配置驱动器和桩(Stub)。一般“驱动器”是传送测试数据，并接收测试、显示结果的“主程序”；“桩”作为此单元模块调用的模块的替代。驱动器和桩(Stub)属于必须开发，但又不属于提交软件，如果驱动器和桩(Stub)很简单，那么额外开销较小，但是实际不完全是这样，在这种情况下，针对此单元模块的完成的测试工作要等到集成测试的时候才能进行。下图是单元测试的模式： 根据模块间关系的不同需要有不同的桩和驱动器，可以根据桩的类型开发一些通用结构的桩和驱动器，这样可以大大减少桩和驱动器的开发工作量。桩和驱动器的类型如下： 单元测试工作的主要过程应当满足上述的单元测试模式，并针对不同组织、项目、开发团队采用不同的过程，一个参考如下： 单元测试过程： 1、选择进行单元测试的模块以及相应的单元测试内容 2、明确测试目标和完成准则 3、测试和修正协调的策划 4、驱动器和桩的开发 5、测试方案编制 6、测试产品和测试环境准备 7、依据测试方案进行测试 8、根据测试结果提交测试报告 9、测试报告的分析 10、缺陷的管理 11、修正和测试工作 12、完成测试产品提交配置 集成测试 集成测试发现和接口有关的问题，它的测试对象是把通过了单元测试的模块按照设计要求组装起来的软件结构。应当避免一次性的集成（除非软件规模很小），这样可能会发现令人沮丧的数量巨大的缺陷，对发现的缺陷也很难定位，进行的修复工作很可能在不知不觉中影响了其他的模块，这些因素综合在一起让整个团队容易陷入“发现缺陷--修正--新缺陷”的循环中。集成的方法有两种：自顶向下，自底向上，他们分别介绍如下： 自顶向下集成 自顶向下构造的顺序是首先集成“主控模块”，然后按照控制层次结构向下进行集成。向下集成的顺序包括“广度优先”和“深度优先”两种方式。“广度优先”首先集成同一层次的模块，然后再集成下一个层次的模块；“深度优先”则有很多选择，主要思路是按照一个“树遍历算法”进行集成。 自顶向下集成能够较早的关注系统完整的功能；在集成过程中要开发较多的“桩”(Stub)；在集成过程中可能会出现一些困境，例如用“桩”代替了真正的模块，在测试过程中不会有一些重要向上传递的数据，从而造成无法有效测试。 自顶向下集成的过程： 1、主控模块作为测试驱动器，所有桩属于主控模块 2、根据集成的顺序，下层的桩一次一个的被真正的模块替换 3、每个模块集成的时候要进行测试 4、可以用集成测试来保证没有引进新的错误 自底向上集成 自底向上集成中，因为模块是自底向上集成的，所以在进行时要求所有隶属于某个层次的模块总是存在的，这样就不必使用桩了，但是要提高“驱动器”。 自底向上集成的过程： 1、将底层模块组合成能够实现软件特定子功能的簇 2、写一个驱动程序来协调测试用例的输入输出 3、对簇进行测试 4、一周程序，沿着程序结构的层次向上对簇进行集成 集成的方法综述 两种集成测试方法都有其优点和缺点；“自顶向下”的主要缺点是有时依赖于桩不能有效的进行测试，优点就是可以对主控模块进行尽早得测试；“自底向上”的主要缺点是直到测试快要结束了才能看到整个程序结构，优点就是简单的测试用例和不需要桩。 在实际进行集成测试的工作中，建议在程序结构的高层使用“自顶向下”方法，而在较低层使用“自底向上”。实际上任何方法都可以使用，只要测试人员能了解特定模块组合所表示的行为，组合从最前面两个模块开始，到加入最后一个模块结束，形成一个完整的系统。理想状况下，集成测试应每加入一个模块进行一次。 在进行集成测试的时候要识别程序的关键部分，对关键部分要尽早进行测试。回归测试也应当集中关注这些关键部分。 集成测试一般也看作验证的一种形式，因为组合模块的行为是一个功能规范的产品。 集成测试的基本过程如下： 集成测试的过程： 1、明确测试目标和完成准则，并确定关键部分 2、确定阶段和进度安排 3、测试和修正协调的策划 4、清理系统结构 5、确定集成测试方法的组合策略 6、描述集成顺序 7、针对每次集成编制测试用例，从而形成测试方案 8、进行附加软件（驱动器及桩）的开发 9、测试产品和测试环境准备 10、依据测试方案进行测试 11、根据测试结果提交测试报告 12、测试报告的分析 13、缺陷的管理 14、修正和测试工作 15、完成测试产品提交配置 系统测试 根据需求规格的要求进行系统测试，确认系统满足需求的要求。系统测试人员相当于用户代言人，系统测试一般看作确认的一种形式，至少包含如下方面： 系统测试的主要内容： 1、所有功能需求得到满足 2、所有性能需求得到满足 3、其他需求（例如安全性、容错性）得到满足 要有效完成系统测试工作，一定要对“需求规格”中的要求形成确认标准，并且在其形成之初进行评审，保证可测试性；对于一些不能由测试确认的需求，要在“需求规格”说明，如果可能尽量明确其他的确认方式。系统测试的主要过程包括如下内容： 系统测试的过程： 1、参与“需求规格”的评审，针对可测试性进行确认，并达成共识 2、确定进度、阶段安排 3、测试和修正协调的策划 4、分析需求，针对每个要求制定测试用例，从而形成测试方案 5、测试产品和测试环境准备（配置审计） 6、依据测试方案进行测试 7、根据测试结果提交测试报告 8、测试报告的分析 9、缺陷的管理 10、修正和测试工作 11、完成测试产品提交配置 验收测试 由用户执行或者参与的测试工作， Alpha测试 Beta测试 回归测试 回归测试就是漏洞修复完成后再对软件进行测试，以确保软件没有产生“回归”或因修复而变得更糟，这种测试一般要重新运行最初发现问题的原始测试程序。有关回归测试有两个焦点：有没有产生新的漏洞，修复是否确实使缺陷消除。为进行有效的回归测试，自动测试一般是肯定需要的。 回归测试方式 在软件生命周期中，即使一个得到良好维护的测试用例库也可能变得相当大，这使每次回归测试都重新运行完整的测试包变得不切实际。一个完全的回归测试包括每个基线测试用例，时间和成本约束可能阻碍运行这样一个测试，有时测试组不得不选择一个缩减的回归测试包来完成回归测试。 回归测试的价值在于它是一个能够检测到回归错误的受控实验。当测试组选择缩减的回归测试时，有可能删除了将揭示回归错误的测试用例，消除了发现回归错误的机会。然而，如果采用了代码相依性分析等安全的缩减技术，就可以决定哪些测试用例可以被删除而不会让回归测试的意图遭到破坏。 选择回归测试策略应该兼顾效率和有效性两个方面。常用的选择回归测试的方式包括： 再测试全部用例： 选择基线测试用例库中的全部测试用例组成回归测试包，这是一种比较安全的方法，再测试全部用例具有最低的遗漏回归错误的风险，但测试成本最高。全部再测试几乎可以应用到任何情况下，基本上不需要进行分析和重新开发，但是，随着开发工作的进展，测试用例不断增多，重复原先所有的测试将带来很大的工作量，往往超出了我们的预算和进度。 基于风险选择测试 ： 可以基于一定的风险标准来从基线测试用例库中选择回归测试包。首先运行最重要的、关键的和可疑的测试，而跳过那些非关键的、优先级别低的或者高稳定的测试用例，这些用例即便可能测试到缺陷，这些缺陷的严重性也仅有三级或四级。一般而言，测试从主要特征到次要特征 基于操作剖面选择测试 ： 如果基线测试用例库的测试用例是基于软件操作剖面开发的，测试用例的分布情况反映了系统的实际使用情况。回归测试所使用的测试用例个数可以由测试预算确定，回归测试可以优先选择那些针对最重要或最频繁使用功能的测试用例，释放和缓解最高级别的风险，有助于尽早发现那些对可靠性有最大影响的故障。这种方法可以在一个给定的预算下最有效的提高系统可靠性，但实施起来有一定的难度。 再测试修改的部分： 当测试者对修改的局部化有足够的信心时，可以通过相依性分析识别软件的修改情况并分析修改的影响，将回归测试局限于被改变的模块和它的接口上。通常，一个回归错误一定涉及一个新的、修改的或删除的代码段。在允许的条件下，回归测试尽可能覆盖受到影响的部分。 再测试全部用例的策略是最安全的策略，但已经运行过许多次的回归测试不太可能揭示新的错误，而且很多时候，由于时间、人员、设备和经费的原因，不允许选择再测试全部用例的回归测试策略，此时，可以选择适当的策略进行缩减的回归测试。 回归测试的过程 有了测试用例库的维护方法和回归测试包的选择策略，回归测试可遵循下述过程进行： 回归测试过程： 1、识别出软件中被修改的部分 2、从原基线测试用例库中排除所有不再适用的测试用例，确定那些对新的软件版本依然有效的测试用例 3、如果必要，生成新的测试用例集，用于测试原来测试用例集无法充分测试的部分 4、依据一定的策略选择测试用例测试被修改的软件。 5、进行测试，并 记录 混凝土 养护记录下载土方回填监理旁站记录免费下载集备记录下载集备记录下载集备记录下载 测试结果到测试报告 6、分析测试报告 7、修正和测试工作 8、完成测试产品提交配置 面向对象测试 面对对象技术技术使得测试在三个方面进行了改变： 测试的改变： 1、测试应当包括对OOA和OOD的错误发现技术 2、单元测试和集成测试发生很大改变 3、测试用例设计技术考虑OO的特性 由于OO软件采用了统一的表示法，所以正式的技术审查和同行评审效果更好 OO测试中的阶段： 1、单元测试：针对类的测试，测试类中封装的方法，以及由类的属性确定的状态 2、集成测试：采用基于线程和使用的策略进行测试 3、系统测试：基于UC的场景作为系统测试用例的主要驱动 在OO中单元测试就是针对类的测试，类封装了操作和属性，这样测试的时候要结合类来考虑对操作和属性的测试。类的几个性质对单元测试方法吐了新的问题 OO单元测试新的内容： 1、类的封装性：封装使得对象的状态难以获得，除非使用内置操作 2、类的继承性：由于超类和子类运行的环境可能有区别，测试用例要多一些 OO单元测试的基本步骤： 1、测试用例应当唯一标示，并明确关联到类 2、陈述测试目的 3、将被测试对象的特定状态 4、进行测试必须存在的外部条件 5、测试的传送的消息，返回的消息以及对应关系 6、例外情况 测试过程 图6 基于测试原则中的“测试过程：测试应当从“小规模”开始，逐步转向“大规模””，由于这种原因，形成了一个测试过程和建造过程的对应关系，如下图： 图6 测试过程的主框架就是：单元测试、集成测试、系统测试。在整个测试过程的生命周期中应当关注的内容还包括如下内容： 测试前提： 由于测试过程各个阶段的工作是基于软件系统构造各个阶段工作的，所以应当尽量保证构造阶段工作产品的形式化和量化，保证足够的可测试性，只有这样才能有效的进行测试；通过正式的技术审查和同行评审是有效的办法 测试方案的评审： 对测试方案本身进行评审，评审的主要方法主要是使用ChekList；通过保证测试方案的质量来保证软件产品的质量。 修正工作的安排： 修正工作和测试工作安排是引起测试过程混乱，从而影响软件产品质量的重要原因之一；测试和修正工作的协调主要包括两种方式：严格式、快速式。无论哪种方式均需要较好的配置管理支持。 1、严格式：针对某一版本执行完所有测试用例后，将缺陷一次性汇总提交修正，统一修正完成并经过开发人员自测后形成新的版本，提交测试。 2、快速式：测试提供一定的限制条件，一旦满足条件就暂缓测试工作，要求开发人员的修正，并提交新的版本，限制条件的例子包括“测试2天提交开发修正”、“发现缺陷超过5个提交开发修正”等 3、选择策略：一般在测试工作早期采用“严格式”，这个阶段一般能够发现较多的缺陷，双方交流成本较高，发现缺陷的可能性较大，也有必要向开发人员提供软件质量的一个整体认识，有利于修正工作；在测试工作后期，缺陷数量减少，而且顺着测试和开发人员对软件更加深刻的认识，有时没有必要运行全部的测试用例了，只是有选择的进行回归测试 测试工具开发： 有时针对特定的软件系统开发一些测试工具，比较常见的是集成测试中的“桩”，以及性能测试，这些要统筹安排 关键测试点分析： 用来确认测试重点，用于指导测试工作重点，主要有如下几种： 1、使用分析：将用户分类，分析每类用户可能的使用方式，确定系统被经常使用的部分，从而明确重点； 2、耦合分析：针对系统结构，扇入、扇出较多的模块是测试的重点； 3、复用分析：复用较多模块是测试重点 4、运行关键模块：严重影响系统正常运行和性能的模块是测试重点 测试计划： 由于测试工作量较大、周期较长，以及测试工作的重要性，应当对测试工作进行计划。在测试计划中应当明确测试目标，例如测试覆盖率、测试后的故障发生概率，发现缺陷和改正缺陷的开销；在计划重要明确测试工作的里程碑，例如首次测试完成的时间，完成首次修正工作的时间，二次测试完成和二次修正完成时间，安排测试工具开发的时间；测试计划要明确资源和职责，要描述基本测试策略，必要的时候对测试工具进行说明 测试总结： 1、评价软件产品质量 2、分析提交客户后的缺陷预测分析，以及维护成本分析 3、对测试工作进行经验、教训、建议总结 4、过程财富提交组织过程财富库 测试过程的主要阶段： 1、测试策划 2、测试设计 3、测试实施 4、测试报告和分析 5、测试总结 测试工作的主要流程如下图： 测试工具 测试的组织结构 序号 角色 职责说明 1 测试组长 1、 测试计划制定 2、 测试小组和测试工作管理，以及外部协调 3、 测试管理报告提交 2 测试用例编写者 1、 确定测试重点 2、 规划测试路径、方法、工具 3、 编制测试方案 4、 指导测试执行者 5、 测试技术学习和测试小组培训 3 测试工具开发人员 1、 开发测试工具 2、 培训测试执行者使用测试工具 4 测试执行者 1、 根据测试方案执行测试 2、 保留测试结果，便于缺陷定位 3、 根据测试结果提交测试报告 4、 缺陷跟踪和管理 5 配置人员 1、 被测试软件产品的配置管理 2、 测试用例库和缺陷库管理 3、 测试工具管理 6 环境搭建者 1、 对测试环境进行搭建 2、 测试环境的维护 3、 合适时参与性能测试 7 SQA 1、 验证测试过程符合要求 2、 验证测试工作产品符合要求 1、 测试计划的制定上述角色均应参与，但由测试组长主导 2、 测试组长、测试用例编写者、测试执行者均应参与测试报告的分析 缺陷管理 缺陷是测试工作的主要工作产品，对缺陷进行有效的管理，是非常必要的。缺陷管理的主要原则是进行有效缺陷管理的主要指导。 缺陷管理的原则： 1、避免缺陷 2、尽早发现缺陷 3、缺陷尽早解决 缺陷管理的主要工作： 1、缺陷预防：将缺陷预防技术和方法纳入到开发的过程以及组织的习惯中，从而减少缺陷的引入，这样的成本最为低廉 2、检测策略：基于缺陷可能性和重要性分析明确质量重点，从而尽快的发现重要的缺陷，在这样原则指导下的测试工作会更加有效果 3、缺陷的跟踪：对某个项目已经发现的缺陷进行记录、分发、修正、验证，并整理到缺陷库；可能伴随着一些奖惩 制度 关于办公室下班关闭电源制度矿山事故隐患举报和奖励制度制度下载人事管理制度doc盘点制度下载 来强化质量工作 4、缺陷库管理：缺陷的入库、修改、查阅、备份等管理，缺陷库可以作为过程财富 5、缺陷的统计分析：根据缺陷库的信息进行统计分析，为缺陷预防提供基础信息 调试方法 调试是为了找到缺陷症状的原因，但是调试也是非常困难的，相对于技术而言主要的因素是人的心理问题。下面简述关于调试的内容： 令人困扰的缺陷： 1、症状和原因相隔的非常遥远，不利于进行跟踪和分析 2、症状不是一个原因造成的，非常让人困惑 3、症状的出现不受控制，有时不能重现 调试方法： 1、跟踪法 2、分析法 调试的工具： 1、跟踪工具 2、交叉应用分析工具 3、内存和CPU使用情况工具 4、一般这些工具在编译器中已经具备 完成调试后的总结内容： 1、本次修正可能引起那些新的缺陷，怎样避免 2、同类型的缺陷在其他地方可能存在吗？ 3、怎样改进，杜绝或者减少这类问题再次出现 测试度量 首先，软件度量是指在现实的世界中，把数字或符号指定给实体的某一属性，以便以这种方式来根据已明确的规则来描述它们。在软件开发中，软件度量的根本目的是为了管理的需要。利用度量来改进软件过程。 使用软件度量方法来判定是否已经实施和执行了充分的测试及确定测试对象和测试流程的质量。这就是测试评估。 测试评估的方法主要有测试覆盖和质量评测。下面我分别讨论： 1. 测试覆盖 我们使用测试覆盖而判断测试的完全程度。最常用的覆盖评测是基于需求的测试覆盖和基于代码的测试覆盖。 需求覆盖：基于需求的测试覆盖在测试生命周期中要评测多次，并在测试生命周期的里程碑处提供测试覆盖的标识（如已计划的、已执行的和成功的测试覆盖）。 测试覆盖通过以下公式计算： 测试覆盖 = T(p,i,x,s) / RfT 其中： T 是用测试过程或测试用例表示的测试 (Test) 数（已计划的、已执行的或成功的）。 RfT 是测试需求 (Requirement for Test) 的总数。（此时的测试需求由系统需求确定） 在制定测试计划活动中，将计算测试覆盖以决定已计划的测试覆盖，其计算方法如下： 测试覆盖（已计划的） = Tp / RfT 其中： Tp 是用测试过程或测试用例表示的已计划测试 (Test) 数。 RfT 是测试需求 (Requirement for Test) 的总数。 在执行测试活动中，使用两个测试覆盖评测，一个确定通过执行测试获得的测试覆盖，另一个确定成功的测试覆盖（即执行时未出现失败的测试，如没有出现缺陷或意外结果的测试）。 这些覆盖评测通过以下公式计算： 测试覆盖（已执行的） = Tx / RfT 其中： Tx 是用测试过程或测试用例表示的已执行的测试 (Test) 数。 RfT 是测试需求 (Requirement for Test) 的总数。   成功的测试覆盖（已执行的） = Ts / RfT 其中： Ts 是用完全成功、没有缺陷的测试过程或测试用例表示的已执行测试 (Test) 数。 RfT 是测试需求 (Requirement for Test) 的总数。   如将以上比率转换为百分数，可以描述为：x% 的测试用例（上述公式中的 T(p,i,x,s)）已经覆盖，成功率为 y%。然后可以将其与已定义的成功标准进行对比。如果不符合该标准，则此陈述将成为预测剩余测试工作量的基础。 2. 质量评测 a) 缺陷分析 在测试过程中已发现缺陷的评估提供了最佳的软件质量指标。因为质量是软件与需求相符程度的指标，对缺陷的评估证明了软件与需求的不相符合性。 对于缺陷分析，常用的主要缺陷参数有四个： 状态：缺陷的当前状态（打开的、正在修复或关闭的等）。 优先级：必须处理和解决缺陷的相对重要性。 严重性：缺陷的相关影响。对最终用户、组织或第三方的影响等等。 起源：导致缺陷的起源故障及其位置，或排除该缺陷需要修复的构件。 b) 缺陷报告 缺陷分布（密度）报告允许将缺陷计数作为一个或多个缺陷参数的函数来显示。 缺陷龄期报告是一种特殊类型的缺陷分布报告。 缺陷龄期报告显示缺陷处于特定状态下的时间长短，如“提出的”。在龄期类别中，缺陷还可以按其他属性分类，如“拥有者”。 缺陷趋势报告按状态（新的、已打开的或关闭的）将缺陷计数作为时间的函数显示。趋势报告可以是累计的，也可以是非累计的。 测试结果和进度报告显示对测试的应用程序进行若干次迭代和测试生命周期后的测试过程执行结果。 · 缺陷密度报告 缺陷密度指总的已知缺陷数量/能够测试的软件实体，一般限制在某一个时间段。 我们可以根据优先级来测量软件质量是否达到预定的标准。。如我们的测试分为四个优先级：致命、严重、一般和建议。定义一个成功的测试标准为：不存在优先级为致命的打开的缺陷，而且优先级为严重的打开的缺陷要少于 5 个。例如下面的缺陷分布图：     很明显该图显示的情况没有达到标准。 · 缺陷龄期报告 缺陷龄期分析提供了有关测试有效性和缺陷排除活动的良好反馈。例如，如果大部分龄期较长的、未解决的缺陷处于有待确认的状态，则可能表明没有充足的资源应用于再次测试工作。 · 缺陷趋势报告 趋势报告确定缺陷率并提供了一个出色的测试状态视图。在测试生命周期中，缺陷趋势遵循着一种比较好预测的模式。在生命周期的初期，缺陷率增长很快。在达到顶峰后，就随时间以较慢的速率下降。     要发现问题，可以根据这一趋势复审项目时间表。例如，在四个星期的生命周期中，如果缺陷率在第三个星期中仍然增长，则项目很明显没有按时间表进行。 这一简单的趋势分析假定：缺陷是立即关闭的，且在随后的工作版本中对修复进行测试，这样关闭缺陷的速率应该遵循与打开缺陷的速率相同的增减趋势。如果情况并非如此，则表明缺陷解决流程发生了问题；缺陷修复所需的资源或再次测试和确认修复所需的资源可能不足。 测试用例库管理 测试用例库的维护 为了最大限度地满足客户的需要和适应应用的要求，软件在其生命周期中会频繁地被修改和不断推出新的版本，修改后的或者新版本的软件会添加一些新的功能或者在软件功能上产生某些变化。随着软件的改变，软件的功能和应用接口以及软件的实现发生了演变，测试用例库中的一些测试用例可能会失去针对性和有效性，而另一些测试用例可能会变得过时，还有一些测试用例将完全不能运行。为了保证测试用例库中测试用例的有效性，必须对测试用例库进行维护。同时，被修改的或新增添的软件功能，仅仅靠重新运行以前的测试用例并不足以揭示其中的问题，有必要追加新的测试用例来测试这些新的功能或特征。因此，测试用例库的维护工作还应包括开发新测试用例，这些新的测试用例用来测试软件的新特征或者覆盖现有测试用例无法覆盖的软件功能或特征。 测试用例的维护是一个不间断的过程，通常可以将软件开发的基线作为基准，维护的主要内容包括下述几个方面。 (1)、删除过时的测试用例 因为需求的改变等原因可能会使一个基线测试用例不再适合被测试系统，这些测试用例就会过时。例如，某个变量的界限发生了改变，原来针对边界值的测试就无法完成对新边界测试。所以，在软件的每次修改后都应进行相应的过时测试用例的删除。 (2)、改进不受控制的测试用例 随着软件项目的进展，测试用例库中的用例会不断增加，其中会出现一些对输入或运行状态十分敏感的测试用例。这些测试不容易重复且结果难以控制，会影响回归测试的效率，需要进行改进，使其达到可重复和可控制的要求。 (3)、删除冗余的测试用例 如果存在两个或者更多个测试用例针对一组相同的输入和输出进行测试，那么这些测试用例是冗余的。冗余测试用例的存在降低了回归测试的效率。所以需要定期的整理测试用例库，并将冗余的用例删除掉。 (4)、增添新的测试用例 如果某个程序段、构件或关键的接口在现有的测试中没有被测试，那么应该开发新测试用例重新对其进行测试。并将新开发的测试用例合并到基线测试包中。 通过对测试用例库的维护不仅改善了测试用例的可用性，而且也提高了测试库的可信性，同时还可以将一个基线测试用例库的效率和效用保持在一个较高的级别上。 其他     该报告反映的趋势显示，在项目开始时，发现和打开新缺陷的速率很快，但随着时间推移，该速率不断降低。打开的缺陷的趋势与新缺陷的趋势相似，但稍微滞后一些。关闭的缺陷的趋势随着打开的缺陷的修复和核实而不断增长。这些趋势描述的是成功的工作。 如果您的趋势与这些趋势差别显著，则表明存在问题，并可以确定可能需要附加资源以应用于开发或测试特定区域的时间。 当与测试覆盖评测结合起来时，缺陷分析可提供出色的评估，测试完成的标准也可以建立在此评估基础上。 系统需求分析 制定验收计划 制定STP(软件测试计划) 图：1_01 发布 发布评审 提交验收，验收评审， 验收测试 更改流程 系统测试 提交系统测试版本，纳入配置管理 制定SDP(软件开发计划) 集成测试 测试程序 制定集成测试计划 制定系统测试计划 系统联调 高层设计(总体与概要) 编码实现 详细设计分析 审核测试 �PAGE \# "'页：'#'�'" ��白盒测试的对象一般是程序模块/函数，模块/函数在被测试时也有测试目标和测试正确性的验证。