软件测试各过程的意义.doc

软件测试过程海辉软件应用测试部门在长期的行业测试经验中，在软件测试过程模型方面总结出了如下图所示的改进W模型：软件测试改进W模型相对于传统V模型，W模型更科学，由一个开发的“V”和一个与之并行的测试“V”组成，体现了“尽早地和不断地进行软件测试” 的软件测试基本原则，强调的是测试伴随着整个软件开发周期，测试与开发是同步进行的，而且测试的对象不仅仅是程序代码，需求、设计同样要进行测试（图中的“V&V”即表示对需求文档、设计文档的验证Verification和确认Validation）。根据金融行业应用系统IT架构复杂、应用系统间关联度高的特点，在单一应用系统系统测试完成后，应进一步在具备其他应用系统的测试环境中执行“系统集成测试”（System Integration Testing，SIT），以验证各应用系统间数据传递正确、业务功能正常完成。鉴于金融行业对应用系统准确性、稳定性、安全性要求高及应用系统失败将造成巨大损失的特点，为保证万无一失，在用户验收测试完成后、系统正式上线前，一般还会在准生成环境中进行“上线版本验证”测试，再次验证系统功能性能是否满足要求，系统在使用过程中是否会出错等等。按照当前金融行业开发测试现状，一般情况下，单元测试、集成测试由开发项目组执行，系统测试、系统集成测试、用户验收测试、上线版本验证测试由测试部门执行或参与（用户验收测试由业务部门组织执行，测试部门提供测试工具支持和测试环境支持等）。第一章 测试阶段说明根据海辉测试W模型，测试按阶段划分可分为：单元测试、集成测试、系统测试和用户验收测试（UAT），在系统测试完成后，根据被测系统具体情况可选择实施系统集成测试（SIT）和上线版本检验测试。测试在不同阶段涉及到的部分测试内容如下表所示：阶 段测 试 内 容备 注单元测试静态测试代码走查、交叉检查、内部评审、静态扫描开发方测试动态测试动态执行检查开发方测试集成测试接口测试接口符合性测试开发方测试功能测试数据流转、处理逻辑测试开发方测试系统测试功能测试功能测试（GUI、业务、健壮性等）自动化回归测试第三方测试非功能测试（技术测试）性能测试第三方测试可靠性/可恢复性测试第三方测试安装配置测试第三方测试安全性测试第三方测试文档测试第三方测试对开发方提供的需求说明书、详细设计说明书、数据库安装手册等文档的检查和测试系统集成测试(SIT)兼容性第三方测试支持平台的兼容性互联测试第三方测试与其它生产系统的联通测试用户验收测试(UAT)功能和业务流程测试业务用户测试系统用户的代表进行测试上线版本检验测试业务流程自动化回归测试第三方测试或业务用户测试业务流程测试第三方测试或业务用户测试可以有针对性地选择部分业务1.1 单元测试单元测试是测试的基础级别。单元测试着眼于程序或系统的较小构建模块，是执行每个模块以证实其履行了指定功能的过程。单元测试由开发人员完成。单元测试过程是根据详细设计文档和编码规范的要求，对系统中程序单元并行进行测试。单元测试阶段形成的文档包括：单元测试计划、单元测试案例、单元测试报告、代码审查表等。1.1.1 测试方法单元测试的方法主要采用静态测试方法和动态测试方法。q 静态测试静态测试方法能快速找到缺陷，发现30%70%的逻辑设计和编码缺陷。静态测试方法的依据是项目的程序设计文档、程序的源代码清单、编码规范和代码审查表等。静态测试中最常用的手段是代码审查。审查是一种正式的评估方法，将由非制作者本人的个人或小组详细检查阶段成果，以查明是否有错误、是否违反开发标准及是否存在其他问题。代码审查可以发现违背编码规范的问题，程序中不安全、不明确和模糊的部分，找出程序中不可移植部分、违背程序编程风格的问题，包括变量检查、命名和类型审查、程序逻辑审查、程序语法检查和程序结构检查等内容。执行代码审查前，各个项目组需制定适用于本项目的代码审查表，覆盖以下几类问题，并对每类问题进行细化和补充： Comment：注释没写，或者格式不对，或者毫无意义 Coding Standard：没遵守编码规范 Existing Wheel：重复现成的代码，或者是开源项目，或者其他项目已有代码 Performance bottle and Improvement：性能问题 Code Logic Error：代码逻辑错误 Business Logic Error：业务逻辑错误q 动态测试针对代码只进行静态测试是不完整的。动态测试是通过输入一组预先按照一定的测试准则构造的实例数据来动态运行程序，而达到发现程序错误的过程。动态测试的必要手段是设计和执行单元测试案例，其覆盖标准有： 语句覆盖：每条语句至少执行一次 判定覆盖：每个判定的每个分支至少执行一次 条件覆盖：每个判定的每个条件应取到各种可能的值 判定/条件覆盖：同时满足判定覆盖条件覆盖 条件组合覆盖：每个判定中各条件的每一种组合至少出现一次 路径覆盖：使程序中每一条可能的路径至少执行一次。要达到较强的覆盖程度，需要付出案例设计和编写的工作量。动态测试案例的设计一般和代码重构并行完成，可以采用以下方法进行补充和完善： 基本路径法：在程序控制流图的基础上，通过分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试案例的方法。设计出的测试案例要保证在测试中程序的每个可执行语句至少执行一次。 边界值分析法：合理的输入条件与不合理的输入条件。 错误推测法：列举出程序中所有可能的错误和容易发生错误的特殊情况，根据它们选择测试案例。1.1.2 测试流程单元测试对应开发过程中的编码阶段，其流程包括测试计划、测试设计、测试执行、测试总结、测试过程审计等环节。单元测试流程图 在单元测试过程中体现了静态测试（代码审查）和动态测试相结合的方法。代码审查一般在动态测试之前启动，并允许交错或同步进行。1.2 集成测试集成测试，也叫组装测试或联合测试，是在单元测试的基础上，将所有模块按照设计要求（如根据结构图）组装成为子系统或系统，进行集成测试。集成测试的目的是检验软件单元之间、软件单元和已集成的软件系统之间的接口关系，并验证已集成软件系统是否符合设计要求。集成测试的重要依据是概要设计说明书及相关设计文档。集成测试阶段形成的文档包括：集成测试计划、集成测试案例、集成测试报告等。1.2.1 测试方法实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。此外，在某些开发模式中，如迭代式开发，设计和实现是迭代进行的。在这种情况下，集成测试的意义还在于它能间接地验证概要设计是否具有可行性。以下介绍了几种常用的集成测试方法和策略：自顶向下、自底向上、核心先行集成、高频度集成等。在实践中通常会采用几种集成策略相结合的测试方法，例如：复杂软件项目集成测试过程中，通常采用核心系统先行集成测试和高频集成测试相结合的方式进行；而传统瀑布式开发模式的软件项目集成过程中较常用自底向上的集成测试方案。q 自顶向下集成自顶向下集成（Top-Down Integration）方式是一个递增的组装软件结构的方法。从主控模块（主程序）开始沿控制层向下移动，把模块一一组合起来。分两种方法：结合项目的实际工程环境及各测试方案适用的范围进行合理的选型。 先深度：按照结构，用一条主控制路径将所有模块组合起来； 先宽度：逐层组合所有下属模块，在每一层水平地沿着移动。q 自底向上集成自底向上的集成（Bottom-Up Integration）方式是最常使用的方法。其它集成方法都或多或少地继承、吸收了这种集成方式的思想。自底向上集成方式从程序模块结构中最底层的模块开始组装和测试。因为模块是自底向上进行组装的，对于一个给定层次的模块，它的子模块（包括子模块的所有下属模块）事前已经完成组装并经过测试，所以不再需要编制桩模块（一种能模拟真实模块，给待测模块提供调用接口或数据的测试用软件模块）。q 核心集成测试 核心系统先行集成测试法的思想是先对核心软件部件进行集成测试，在测试通过的基础上再按各外围软件部件的重要程度逐个集成到核心系统中。每次加入一个外围软件部件都产生一个产品基线，直至最后形成稳定的软件产品。核心系统先行集成测试法对应的集成过程是一个逐渐趋于闭合的螺旋形曲线，代表产品逐步定型的过程。核心集成测试方法对于快速软件开发很有效果，适合较复杂系统的集成测试，能保证一些重要的功能和服务的实现。缺点是采用此法的系统一般应能明确区分核心软件部件和外围软件部件，核心软件部件应具有较高的耦合度，外围软件部件内部也应具有较高的耦合度，但各外围软件部件之间应具有较低的耦合度。 q 高频集成测试 高频集成测试是指同步于软件开发过程，每隔一段时间对开发团队的现有代码进行一次集成测试。如某些自动化集成测试工具能实现每日深夜对开发团队的现有代码进行一次集成测试，然后将测试结果发到各开发人员的电子邮箱中。该集成测试方法频繁地将新代码加入到一个已经稳定的基线中，以免集成故障难以发现，同时控制可能出现的基线偏差。该测试方案能在开发过程中及时发现代码错误，能直观地看到开发团队的有效工程进度。在此方案中，开发维护源代码与开发维护软件测试包被赋予了同等的重要性，这对有效防止错误、及时纠正错误都很有帮助。该方案的缺点在于测试包有时候可能不能暴露深层次的编码错误和图形界面错误。 1.2.2 测试流程集成测试对应开发过程中的概要设计阶段，其流程包括测试计划、测试设计、测试执行、测试总结、测试过程审查等环节。集成测试流程图集成测试阶段的测试活动首先应该根据项目所选的集成方式制定测试策略。同时，应该充分依据上一测试阶段（单元测试）的成果物，进行参考、复用和补充。1.3 系统测试系统测试是在特定环境下对系统进行全面测试的过程。系统测试执行一组测试，以验证软件质量保证计划中的各种质量属性。系统测试的对象是完整的、集成的计算机系统。这里不仅包括需要测试的产品系统的软件，还要包含软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等。因此，必须将系统中的软件与各种依赖的资源结合起来，在系统实际（或模拟）的运行环境下来进行测试。系统测试由独立的测试团队完成，应避免由开发方主导的系统测试。系统测试的重要依据是需求规格说明书及相关设计文档。系统测试阶段形成的文档包括：系统测试计划、系统测试需求、系统测试案例、系统测试报告等。1.3.1 测试方法系统测试主要采用黑盒测试的方法，说明如下： 功能分解：功能分解法是将需求规格说明中每一个功能加以分解，确保各个功能被全面的测试。 等价类划分：等价类划分是在分析需求规格说明的基础上，把程序的输入域划分成若干部分，然后在每部分中选取代表性数据形成测试案例。 边界值分析：边界值分析法是对边界值进行测试，使用等于、小于或大于边界值的数据对程序进行测试。 判定表：判定表由四部分组成：条件桩、条件条目、动作桩、动作条目。任何一个条件的组合的取值及其相应要执行的操作构成规则，条目中的每一条是一条规则。条件引用输入的等价类，动作引用被测软件的主要功能处理部分，规则就是测试案例。建立并优化判定表，把判定表中每一列标识的情况写成测试案例。 因果图：因果图分析法是通过画因果图，把用自然语言描述的功能说明转换为判定表，然后为判定表的每一列设计一个测试案例。 随机测试：随机测试输入的数据是在所有可能输入值中随机选取的。测试人员只需规定输入变量的取值区间，在需要时提供必要的变换机制，使产生的随机数服从预期的概率分布。该方法获得预期输出比较困难。多用于可靠性测试和系统强度测试。 猜错法：猜错法是由有经验的测试人员，通过列出可能有的差错和易错情况表，写出测试案例的方法。 正交实验法：正交实验是从大量的实验点中挑出适量的、有代表性的点，应用正交表，合理的安排实验的一种科学的实验设计方法。在系统测试的实践中，多采用几种测试方法相结合的方式进行。1.3.2 测试流程系统测试对应开发过程中的需求分析阶段，其流程包括测试计划、测试需求分析、测试设计、测试执行、测试总结、测试过程审查等环节。系统测试流程图系统测试阶段的测试活动应该是专门的测试团队独立完成的测试。同时，应该充分依据上一测试阶段（集成测试）的成果物，进行参考、复用和补充。1.4 系统集成测试系统集成测试也可称为兼容性测试，目的是验证被测系统与其它已经上线的生产系统之间交互操作的正确性和可靠性。系统集成测试可以由测试团队或者测试与开发协作完成。系统集成测试阶段形成的文档包括：系统集成测试计划、系统集成测试需求、系统集成测试案例、系统集成测试报告等。1.4.1 测试方法系统集成测试主要采用黑盒测试的方法，说明如下： 功能分解：功能分解法是将需求规格说明中每一个功能加以分解，确保各个功能被全面的测试。 等价类划分：等价类划分是在分析需求规格说明的基础上，把程序的输入域划分成若干部分，然后在每部分中选取代表性数据形成测试案例。 边界值分析：边界值分析法是对边界值进行测试，使用等于、小于或大于边界值的数据对程序进行测试。 判定表：判定表由四部分组成：条件桩、条件条目、动作桩、动作条目。任何一个条件的组合的取值及其相应要执行的操作构成规则，条目中的每一条是一条规则。条件引用输入的等价类，动作引用被测软件的主要功能处理部分，规则就是测试案例。建立并优化判定表，把判定表中每一列标识的情况写成测试案例。 因果图：因果图分析法是通过画因果图，把用自然语言描述的功能说明转换为判定表，然后为判定表的每一列设计一个测试案例。 随机测试：随机测试输入的数据是在所有可能输入值中随机选取的。测试人员只需规定输入变量的取值区间，在需要时提供必要的变换机制，使产生的随机数服从预期的概率分布。该方法获得预期输出比较困难。多用于可靠性测试和系统强度测试。 猜错法：猜错法是由有经验的测试人员，通过列出可能有的差错和易错情况表，写出测试案例的方法。 正交实验法：正交实验是从大量的实验点中挑出适量的、有代表性的点，应用正交表，合理的安排实验的一种科学的实验设计方法。在系统集成测试的实践中，多采用几种测试方法相结合的方式进行。1.4.2 测试流程系统集成测试对应开发过程中的需求分析阶段，其流程包括测试计划、测试需求分析、测试设计、测试执行、测试总结、测试过程审查等环节。SIT流程图系统集成测试阶段的测试活动是测试团队独立完成或测试与开发协作完成的测试。同时，应该充分依据上一测试阶段的成果物，进行参考、复用和补充。1.5 用户验收测试验收测试是最终用户执行的测试，使用黑盒测试技术对照系统规约对其进行测试。最终用户负责确保所有相关功能都被测试到。验收测试由用户在测试人员的指导下进行。用户验收测试的内容主要包括：适合性、准确性、互操作性、安全保密性、成熟性、容错性、易恢复性、易理解性、易学性、易操作性、吸引性、时间特性、资源利用性、易分析性、易改变性、稳定性、易测试性、适应性、易安装性、共存性、易替换性和依赖性方法进行选择，确定测试内容。对具体的软件系统，可根据合同（或业务需求）的要求对测试内容进行裁剪。用户验收测试的重要依据是业务需求说明书、需求规格说明书及相关需求文档。用户验收测试阶段形成的文档包括：用户验收测试计划、用户验收测试案例、用户验收测试报告等。1.5.1 测试方法用户验收测试一般采用黑盒测试方法，如： 功能分解：功能分解法是将需求规格说明中每一个功能加以分解，确保各个功能被全面的测试。 等价类划分：等价类划分是在分析需求规格说明的基础上，把程序的输入域划分成若干部分，然后在每部分中选取代表性数据形成测试案例。 边界值分析：边界值分析法是对边界值进行测试，使用等于、小于或大于边界值的数据对程序进行测试。 判定表：判定表由四部分组成：条件桩、条件条目、动作桩、动作条目。任何一个条件的组合的取值及其相应要执行的操作构成规则，条目中的每一条是一条规则。条件引用输入的等价类，动作引用被测软件的主要功能处理部分，规则就是测试案例。建立并优化判定表，把判定表中每一列标识的情况写成测试案例。 因果图：因果图分析法是通过画因果图，把用自然语言描述的功能说明转换为判定表，然后为判定表的每一列设计一个测试案例。 随机测试：随机测试输入的数据是在所有可能输入值中随机选取的。测试人员只需规定输入变量的取值区间，在需要时提供必要的变换机制，使产生的随机数服从预期的概率分布。该方法获得预期输出比较困难。多用于可靠性测试和系统强度测试。 猜错法：猜错法是由有经验的测试人员，通过列出可能有的差错和易错情况表，写出测试案例的方法。 正交实验法：正交实验是从大量的实验点中挑出适量的、有代表性的点，应用正交表，合理的安排实验的一种科学的实验设计方法。在实践中，用户验收测试多采用几种测试方法相结合的方式进行。 1.5.2 测试流程用户验收测试对应开发过程中的业务需求分析阶段，其流程应包括：测试计划、设计测试、执行测试、总结测试等环节。用户验收测试流程图用户验收测试应该以用户（通常是业务人员）为主体，由业务人员独立完成该阶段的测试活动。业务人员可以参考前一测试阶段（系统测试）的交付物，即：系统测试需求系统测试案例、系统测试报告等。第二章 测试阶段意义从上一章中已经了解了测试应该做那些测试，如果做这些测试，但是为什么要做这些测试，做这些测试有什么好处，不做这些测试会存在哪些问题或隐患，下面将介绍各测试阶段的实施的意义以及不实施这些阶段的问题。2.1 单元测试2.1.1 单元测试的意义为了很好的完成软件系统的测试任务，我们采用了分层测试的方式，从整体来说做UAT测试的时候我们假设软件系统是一个出厂的产品，最基本的功能都已经实现，这种假设我们通过系统测试来完成，但在做系统测试时，就要假设整个系统的集成运行已经没有问题了，在运行测试或性能测试时，我将不再考虑“系统无法正常运行”这种场景。那么如何保证集成运行没问题呢?我们用集成测试来检验。但是在做集成测试的时候，我们同样要基于一个假定，就是各个模块的功能都能够如期正常工作。而这一点，又是通过模块自身的功能测试来完成的。这样一层层往下推，每个层次就假设它所依赖的层次没有问题，这样就可以减少很多场景以及由这些场景引出的额外的分支。将原先一个几何级数的测试用例分解成可以接受的若干层次的算术级数的用例。这样一来我们就可以很好的完成测试任务。而单元测试，正是这些测试的最低层次保证每个函数/方法，或者说最小功能模块的正确性的一种测试。2.1.2 无单元测试阶段的问题如果不进行单元测试，开发人员开发完成代码后，顶多是从他实现功能的角度上进行一些验证，但这种验证是不全面，无法保证可能会出现的产生无法走通的分支、无法走出的循环以及产生内容泄露的问题，这些问题如果在在单元测试阶段发现的话，很容易查找并修改完成，但是如果在后期系统测试或者是上线以后发现就会产生很大的问题，首先上线后可能会产生生产的事故，其次如果没上线，在大量的代码中去查找分析和修改这些代码会产生很多的成本，甚至发现这样的问题都因为影响非常大而无法修改。2.2 集成测试2.2.1 集成测试的意义集成测试识别组合单元时出现的问题。通过使用要求在组合单元前测试每个单元并确保每个单元的生存能力的测试计划，可以知道在组合单元时所发现的任何错误很可能与单元之间的接口有关。这种方法将可能发生的情况数量减少到更简单的分析级别。 集成测试是在单元测试的基础上，测试在将所有的软件单元按照概要设计规格说明的要求组装成模块、子系统或系统的过程中各部分工作是否达到或实现相应技术指标及要求的活动。也就是说，在集成测试之前，单元测试应该已经完成，集成测试中所使用的对象应该是已经经过单元测试的软件单元。这一点很重要，因为如果不经过单元测试，那么集成测试的效果将会受到很大影响，并且会大幅增加软件单元代码纠错的代价。 集成测试是单元测试的逻辑扩展。在现实方案中，集成是指多个单元的聚合，许多单元组合成模块，而这些模块又聚合成程序的更大部分，如分系统或系统。集成测试采用的方法是测试软件单元的组合能否正常工作，以及与其他组的模块能否集成起来工作。最后，还要测试构成系统的所有模块组合能否正常工作。集成测试所持的主要标准是软件概要设计规格说明，任何不符合该说明的程序模块行为都应该加以记载并上报。 所有的软件项目都不能摆脱系统集成这个阶段。不管采用什么开发模式，具体的开发工作总得从一个一个的软件单元做起，软件单元只有经过集成才能形成一个有机的整体。具体的集成过程可能是显性的也可能是隐性的。只要有集成，总是会出现一些常见问题，工程实践中，几乎不存在软件单元组装过程中不出任何问题的情况。一般来说，集成测试需要花费的时间远远超过单元测试，直接从单元测试过渡到系统测试是极不妥当的做法。 集成测试的必要性还在于一些模块虽然能够单独地工作，但并不能保证连接起来也能正常工作。程序在某些局部反映不出来的问题，有可能在全局上会暴露出来，影响功能的实现。此外，在某些开发模式中，如迭代式开发，设计和实现是迭代进行的。在这种情况下，集成测试的意义还在于它能间接地验证概要设计是否具有可行性。2.2.2 无集成测试阶段的问题集成测试是在单元测试的基础上进行的组装测试，就像积木一样的将各个单元组合成我们所需要的功能，如果不进行集成测试，可能会出现两个功能之间的数据格式不一致、功能无法联通等等一系列的问题，例如：如果有两个功能A和B，A输出的数据是1时表示的是“YES”，输入是2时表示的是”NO”,而B接收后解析缺正好相反，这就产生了问题，这是一个简单的例子，但是又一些集成的问题在后期发现的话，会因为无法集成而需要推翻之前的代码重新编写，就像房子快盖好了发现中间一块钢材有裂缝，必须推倒重新盖一样，需要花费大量的人力和物力。2.3 系统测试2.3.1 系统测试的意义系统测试是将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起，进行信息系统的各种组装测试和确认测试，其目的是通过与系统的需求相比较，发现所开发的系统与用户需求不符或矛盾的地方，从而提出更加完善的方案。系统测试的任务是尽可能彻底地检查出程序中的错误，提高软件系统的可靠性，其目的是检验系统做得怎样？。这个阶段的测试包含内容较多，除了对于功能的测试外，还包含对系统的性能测试、安全性测试、可靠性测试等非功能测试的内容，是针对整个软件系统是否满足用户功能和性能要求的测试。该阶段结束应交付测试报告，说明测试数据的选择，测试用例以及测试结果是否符合预期结果。测试发现问题之后要经过调试找出错误原因和位置，然后进行改正。是基于系统整体需求说明书的黑盒类测试，应覆盖系统所有联合的部件。系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需求规格的定义，找出与需求规格不相符合或与之矛盾的地方。2.3.2 无系统测试阶段的问题系统测试很明显是开发完成后再进行的一系列的测试，在这个阶段中系统已经基本成型，但是这个成型只是表面上的成型，这个成型的“东西”的东西是否可以使用，满足使用的需求，很明显无法保证，因此才进行这系统测试，如果不进行系统测试，那么系统的存在的很多问题都只能放到用户验收的时候才能发现很解决，但是这很不现实的，用户在很多情况下只是会根据自己的需求来验收产品，但是很少会全面的去验证这个产品的所有功能，将这样的产品拿来上线，所承担的风险可想而知，可以举个例子，2008北京奥运会官方提出“先到先得”的销售政策刺激公众踊跃提交购票申请，这时，在线网站瞬间访问数据量急剧上升，技术系统应对不畅，官方售票系统叫停。原因是超负荷，官方售票系统的访问流量每小时达100万次，而那一天瞬时每小时达到800万次，1个小时处理15万张，而一启动瞬间达到20万张，从而出现网络堵塞。从这个例子看，网站的性能也隐含潜在危机。这是因为缺乏性能测试，在现实中有很多这样的例子。系统测试的目的和用户验收测试的目的是完