软件测试各过程的意义21页精选文档.docx

1、软件测试各过程的意义21页精选文档软件测试过程“教书先生”恐怕是市井百姓最为熟悉的一种称呼，从最初的门馆、私塾到晚清的学堂，“教书先生”那一行当怎么说也算是让国人景仰甚或敬畏的一种社会职业。只是更早的“先生”概念并非源于教书，最初出现的“先生”一词也并非有传授知识那般的含义。孟子中的“先生何为出此言也？”；论语中的“有酒食，先生馔”；国策中的“先生坐，何至于此？”等等，均指“先生”为父兄或有学问、有德行的长辈。其实国策中本身就有“先生长者，有德之称”的说法。可见“先生”之原意非真正的“教师”之意，倒是与当今“先生”的称呼更接近。看来，“先生”之本源含义在于礼貌和尊称，并非具学问者的专称。称“老

2、师”为“先生”的记载，首见于礼记?曲礼，有“从于先生，不越礼而与人言”，其中之“先生”意为“年长、资深之传授知识者”，与教师、老师之意基本一致。海辉软件应用测试部门在长期的行业测试经验中，在软件测试过程模型方面总结出了如下图所示的改进W模型：观察内容的选择，我本着先静后动，由近及远的原则，有目的、有计划的先安排与幼儿生活接近的，能理解的观察内容。随机观察也是不可少的，是相当有趣的，如蜻蜓、蚯蚓、毛毛虫等，孩子一边观察，一边提问，兴趣很浓。我提供的观察对象，注意形象逼真，色彩鲜明，大小适中，引导幼儿多角度多层面地进行观察，保证每个幼儿看得到，看得清。看得清才能说得正确。在观察过程中指导。我注意帮

3、助幼儿学习正确的观察方法，即按顺序观察和抓住事物的不同特征重点观察，观察与说话相结合，在观察中积累词汇，理解词汇，如一次我抓住时机，引导幼儿观察雷雨，雷雨前天空急剧变化，乌云密布，我问幼儿乌云是什么样子的，有的孩子说：乌云像大海的波浪。有的孩子说“乌云跑得飞快。”我加以肯定说“这是乌云滚滚。”当幼儿看到闪电时，我告诉他“这叫电光闪闪。”接着幼儿听到雷声惊叫起来，我抓住时机说：“这就是雷声隆隆。”一会儿下起了大雨，我问：“雨下得怎样?”幼儿说大极了，我就舀一盆水往下一倒，作比较观察，让幼儿掌握“倾盆大雨”这个词。雨后，我又带幼儿观察晴朗的天空，朗诵自编的一首儿歌：“蓝天高，白云飘，鸟儿飞，树儿摇

4、，太阳公公咪咪笑。”这样抓住特征见景生情，幼儿不仅印象深刻，对雷雨前后气象变化的词语学得快，记得牢，而且会应用。我还在观察的基础上，引导幼儿联想，让他们与以往学的词语、生活经验联系起来，在发展想象力中发展语言。如啄木鸟的嘴是长长的，尖尖的，硬硬的，像医生用的手术刀样，给大树开刀治病。通过联想，幼儿能够生动形象地描述观察对象。软件测试改进W模型“教书先生”恐怕是市井百姓最为熟悉的一种称呼，从最初的门馆、私塾到晚清的学堂，“教书先生”那一行当怎么说也算是让国人景仰甚或敬畏的一种社会职业。只是更早的“先生”概念并非源于教书，最初出现的“先生”一词也并非有传授知识那般的含义。孟子中的“先生何为出此言也

5、？”；论语中的“有酒食，先生馔”；国策中的“先生坐，何至于此？”等等，均指“先生”为父兄或有学问、有德行的长辈。其实国策中本身就有“先生长者，有德之称”的说法。可见“先生”之原意非真正的“教师”之意，倒是与当今“先生”的称呼更接近。看来，“先生”之本源含义在于礼貌和尊称，并非具学问者的专称。称“老师”为“先生”的记载，首见于礼记?曲礼，有“从于先生，不越礼而与人言”，其中之“先生”意为“年长、资深之传授知识者”，与教师、老师之意基本一致。相对于传统V模型，W模型更科学，由一个开发的“V”和一个与之并行的测试“V”组成，体现了“尽早地和不断地进行软件测试” 的软件测试基本原则，强调的是测试伴随着

6、整个软件开发周期，测试与开发是同步进行的，而且测试的对象不仅仅是程序代码，需求、设计同样要进行测试（图中的“V&V”即表示对需求文档、设计文档的验证Verification和确认Validation）。根据金融行业应用系统IT架构复杂、应用系统间关联度高的特点，在单一应用系统系统测试完成后，应进一步在具备其他应用系统的测试环境中执行“系统集成测试”（System Integration Testing，SIT），以验证各应用系统间数据传递正确、业务功能正常完成。鉴于金融行业对应用系统准确性、稳定性、安全性要求高及应用系统失败将造成巨大损失的特点，为保证万无一失，在用户验收测试完成后、系统正式上

7、线前，一般还会在准生成环境中进行“上线版本验证”测试，再次验证系统功能性能是否满足要求，系统在使用过程中是否会出错等等。按照当前金融行业开发测试现状，一般情况下，单元测试、集成测试由开发项目组执行，系统测试、系统集成测试、用户验收测试、上线版本验证测试由测试部门执行或参与（用户验收测试由业务部门组织执行，测试部门提供测试工具支持和测试环境支持等）。第一章 测试阶段说明根据海辉测试W模型，测试按阶段划分可分为：单元测试、集成测试、系统测试和用户验收测试（UAT），在系统测试完成后，根据被测系统具体情况可选择实施系统集成测试（SIT）和上线版本检验测试。测试在不同阶段涉及到的部分测试内容如下表所示

8、：阶 段测 试 内 容备 注单元测试静态测试代码走查、交叉检查、内部评审、静态扫描开发方测试动态测试动态执行检查开发方测试集成测试接口测试接口符合性测试开发方测试功能测试数据流转、处理逻辑测试开发方测试系统测试功能测试功能测试（GUI、业务、健壮性等）自动化回归测试第三方测试非功能测试（技术测试）性能测试第三方测试可靠性/可恢复性测试第三方测试安装配置测试第三方测试安全性测试第三方测试文档测试第三方测试对开发方提供的需求说明书、详细设计说明书、数据库安装手册等文档的检查和测试系统集成测试(SIT)兼容性第三方测试支持平台的兼容性互联测试第三方测试与其它生产系统的联通测试用户验收测试(UAT)功

9、能和业务流程测试业务用户测试系统用户的代表进行测试上线版本检验测试业务流程自动化回归测试第三方测试或业务用户测试业务流程测试第三方测试或业务用户测试可以有针对性地选择部分业务一.1 单元测试单元测试是测试的基础级别。单元测试着眼于程序或系统的较小构建模块，是执行每个模块以证实其履行了指定功能的过程。单元测试由开发人员完成。单元测试过程是根据详细设计文档和编码规范的要求，对系统中程序单元并行进行测试。单元测试阶段形成的文档包括：单元测试计划、单元测试案例、单元测试报告、代码审查表等。一.1.1 测试方法单元测试的方法主要采用静态测试方法和动态测试方法。 静态测试静态测试方法能快速找到缺陷，发现3

10、0%70%的逻辑设计和编码缺陷。静态测试方法的依据是项目的程序设计文档、程序的源代码清单、编码规范和代码审查表等。静态测试中最常用的手段是代码审查。审查是一种正式的评估方法，将由非制作者本人的个人或小组详细检查阶段成果，以查明是否有错误、是否违反开发标准及是否存在其他问题。代码审查可以发现违背编码规范的问题，程序中不安全、不明确和模糊的部分，找出程序中不可移植部分、违背程序编程风格的问题，包括变量检查、命名和类型审查、程序逻辑审查、程序语法检查和程序结构检查等内容。执行代码审查前，各个项目组需制定适用于本项目的代码审查表，覆盖以下几类问题，并对每类问题进行细化和补充： Comment：注释没写

11、，或者格式不对，或者毫无意义 Coding Standard：没遵守编码规范 Existing Wheel：重复现成的代码，或者是开源项目，或者其他项目已有代码 Performance bottle and Improvement：性能问题 Code Logic Error：代码逻辑错误 Business Logic Error：业务逻辑错误 动态测试针对代码只进行静态测试是不完整的。动态测试是通过输入一组预先按照一定的测试准则构造的实例数据来动态运行程序，而达到发现程序错误的过程。动态测试的必要手段是设计和执行单元测试案例，其覆盖标准有： 语句覆盖：每条语句至少执行一次 判定覆盖：每个判定的

12、每个分支至少执行一次 条件覆盖：每个判定的每个条件应取到各种可能的值 判定/条件覆盖：同时满足判定覆盖条件覆盖 条件组合覆盖：每个判定中各条件的每一种组合至少出现一次 路径覆盖：使程序中每一条可能的路径至少执行一次。要达到较强的覆盖程度，需要付出案例设计和编写的工作量。动态测试案例的设计一般和代码重构并行完成，可以采用以下方法进行补充和完善： 基本路径法：在程序控制流图的基础上，通过分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试案例的方法。设计出的测试案例要保证在测试中程序的每个可执行语句至少执行一次。 边界值分析法：合理的输入条件与不合理的输入条件。 错误推测法：列举出程序中

13、所有可能的错误和容易发生错误的特殊情况，根据它们选择测试案例。一.1.2 测试流程单元测试对应开发过程中的编码阶段，其流程包括测试计划、测试设计、测试执行、测试总结、测试过程审计等环节。单元测试流程图在单元测试过程中体现了静态测试（代码审查）和动态测试相结合的方法。代码审查一般在动态测试之前启动，并允许交错或同步进行。一.2 集成测试集成测试，也叫组装测试或联合测试，是在单元测试的基础上，将所有模块按照设计要求（如根据结构图）组装成为子系统或系统，进行集成测试。集成测试的目的是检验软件单元之间、软件单元和已集成的软件系统之间的接口关系，并验证已集成软件系统是否符合设计要求。集成测试的重要依据是

14、概要设计说明书及相关设计文档。集成测试阶段形成的文档包括：集成测试计划、集成测试案例、集成测试报告等。一.2.1 测试方法实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。此外，在某些开发模式中，如迭代式开发，设计和实现是迭代进行的。在这种情况下，集成测试的意义还在于它能间接地验证概要设计是否具有可行性。以下介绍了几种常用的集成测试方法和策略：自顶向下、自底向上、核心先行集成、高频度集成等。在实践中通常会采用几种集成策略相结合的测试方法，例如：复杂软件项目集成测试过程中，通常采用核心系统先行集成测试

15、和高频集成测试相结合的方式进行；而传统瀑布式开发模式的软件项目集成过程中较常用自底向上的集成测试方案。 自顶向下集成自顶向下集成（Top-Down Integration）方式是一个递增的组装软件结构的方法。从主控模块（主程序）开始沿控制层向下移动，把模块一一组合起来。分两种方法：结合项目的实际工程环境及各测试方案适用的范围进行合理的选型。 先深度：按照结构，用一条主控制路径将所有模块组合起来； 先宽度：逐层组合所有下属模块，在每一层水平地沿着移动。 自底向上集成自底向上的集成（Bottom-Up Integration）方式是最常使用的方法。其它集成方法都或多或少地继承、吸收了这种集成方式的

16、思想。自底向上集成方式从程序模块结构中最底层的模块开始组装和测试。因为模块是自底向上进行组装的，对于一个给定层次的模块，它的子模块（包括子模块的所有下属模块）事前已经完成组装并经过测试，所以不再需要编制桩模块（一种能模拟真实模块，给待测模块提供调用接口或数据的测试用软件模块）。 核心集成测试 核心系统先行集成测试法的思想是先对核心软件部件进行集成测试，在测试通过的基础上再按各外围软件部件的重要程度逐个集成到核心系统中。每次加入一个外围软件部件都产生一个产品基线，直至最后形成稳定的软件产品。核心系统先行集成测试法对应的集成过程是一个逐渐趋于闭合的螺旋形曲线，代表产品逐步定型的过程。核心集成测试方

17、法对于快速软件开发很有效果，适合较复杂系统的集成测试，能保证一些重要的功能和服务的实现。缺点是采用此法的系统一般应能明确区分核心软件部件和外围软件部件，核心软件部件应具有较高的耦合度，外围软件部件内部也应具有较高的耦合度，但各外围软件部件之间应具有较低的耦合度。 高频集成测试 高频集成测试是指同步于软件开发过程，每隔一段时间对开发团队的现有代码进行一次集成测试。如某些自动化集成测试工具能实现每日深夜对开发团队的现有代码进行一次集成测试，然后将测试结果发到各开发人员的电子邮箱中。该集成测试方法频繁地将新代码加入到一个已经稳定的基线中，以免集成故障难以发现，同时控制可能出现的基线偏差。该测试方案能

18、在开发过程中及时发现代码错误，能直观地看到开发团队的有效工程进度。在此方案中，开发维护源代码与开发维护软件测试包被赋予了同等的重要性，这对有效防止错误、及时纠正错误都很有帮助。该方案的缺点在于测试包有时候可能不能暴露深层次的编码错误和图形界面错误。 一.2.2 测试流程集成测试对应开发过程中的概要设计阶段，其流程包括测试计划、测试设计、测试执行、测试总结、测试过程审查等环节。集成测试流程图集成测试阶段的测试活动首先应该根据项目所选的集成方式制定测试策略。同时，应该充分依据上一测试阶段（单元测试）的成果物，进行参考、复用和补充。一.3 系统测试系统测试是在特定环境下对系统进行全面测试的过程。系统

19、测试执行一组测试，以验证软件质量保证计划中的各种质量属性。系统测试的对象是完整的、集成的计算机系统。这里不仅包括需要测试的产品系统的软件，还要包含软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等。因此，必须将系统中的软件与各种依赖的资源结合起来，在系统实际（或模拟）的运行环境下来进行测试。系统测试由独立的测试团队完成，应避免由开发方主导的系统测试。系统测试的重要依据是需求规格说明书及相关设计文档。系统测试阶段形成的文档包括：系统测试计划、系统测试需求、系统测试案例、系统测试报告等。一.3.1 测试方法系统测试主要采用黑盒测试的方法，说明如下： 功能分解：功能分解法是将需求规格说明

20、中每一个功能加以分解，确保各个功能被全面的测试。 等价类划分：等价类划分是在分析需求规格说明的基础上，把程序的输入域划分成若干部分，然后在每部分中选取代表性数据形成测试案例。 边界值分析：边界值分析法是对边界值进行测试，使用等于、小于或大于边界值的数据对程序进行测试。 判定表：判定表由四部分组成：条件桩、条件条目、动作桩、动作条目。任何一个条件的组合的取值及其相应要执行的操作构成规则，条目中的每一条是一条规则。条件引用输入的等价类，动作引用被测软件的主要功能处理部分，规则就是测试案例。建立并优化判定表，把判定表中每一列标识的情况写成测试案例。 因果图：因果图分析法是通过画因果图，把用自然语言描

21、述的功能说明转换为判定表，然后为判定表的每一列设计一个测试案例。 随机测试：随机测试输入的数据是在所有可能输入值中随机选取的。测试人员只需规定输入变量的取值区间，在需要时提供必要的变换机制，使产生的随机数服从预期的概率分布。该方法获得预期输出比较困难。多用于可靠性测试和系统强度测试。 猜错法：猜错法是由有经验的测试人员，通过列出可能有的差错和易错情况表，写出测试案例的方法。 正交实验法：正交实验是从大量的实验点中挑出适量的、有代表性的点，应用正交表，合理的安排实验的一种科学的实验设计方法。在系统测试的实践中，多采用几种测试方法相结合的方式进行。一.3.2 测试流程系统测试对应开发过程中的需求分

22、析阶段，其流程包括测试计划、测试需求分析、测试设计、测试执行、测试总结、测试过程审查等环节。系统测试流程图系统测试阶段的测试活动应该是专门的测试团队独立完成的测试。同时，应该充分依据上一测试阶段（集成测试）的成果物，进行参考、复用和补充。一.4 系统集成测试系统集成测试也可称为兼容性测试，目的是验证被测系统与其它已经上线的生产系统之间交互操作的正确性和可靠性。系统集成测试可以由测试团队或者测试与开发协作完成。系统集成测试阶段形成的文档包括：系统集成测试计划、系统集成测试需求、系统集成测试案例、系统集成测试报告等。一.4.1 测试方法系统集成测试主要采用黑盒测试的方法，说明如下： 功能分解：功能

23、分解法是将需求规格说明中每一个功能加以分解，确保各个功能被全面的测试。 等价类划分：等价类划分是在分析需求规格说明的基础上，把程序的输入域划分成若干部分，然后在每部分中选取代表性数据形成测试案例。 边界值分析：边界值分析法是对边界值进行测试，使用等于、小于或大于边界值的数据对程序进行测试。 判定表：判定表由四部分组成：条件桩、条件条目、动作桩、动作条目。任何一个条件的组合的取值及其相应要执行的操作构成规则，条目中的每一条是一条规则。条件引用输入的等价类，动作引用被测软件的主要功能处理部分，规则就是测试案例。建立并优化判定表，把判定表中每一列标识的情况写成测试案例。 因果图：因果图分析法是通过画

24、因果图，把用自然语言描述的功能说明转换为判定表，然后为判定表的每一列设计一个测试案例。 随机测试：随机测试输入的数据是在所有可能输入值中随机选取的。测试人员只需规定输入变量的取值区间，在需要时提供必要的变换机制，使产生的随机数服从预期的概率分布。该方法获得预期输出比较困难。多用于可靠性测试和系统强度测试。 猜错法：猜错法是由有经验的测试人员，通过列出可能有的差错和易错情况表，写出测试案例的方法。 正交实验法：正交实验是从大量的实验点中挑出适量的、有代表性的点，应用正交表，合理的安排实验的一种科学的实验设计方法。在系统集成测试的实践中，多采用几种测试方法相结合的方式进行。一.4.2 测试流程系统

25、集成测试对应开发过程中的需求分析阶段，其流程包括测试计划、测试需求分析、测试设计、测试执行、测试总结、测试过程审查等环节。SIT流程图系统集成测试阶段的测试活动是测试团队独立完成或测试与开发协作完成的测试。同时，应该充分依据上一测试阶段的成果物，进行参考、复用和补充。一.5 用户验收测试验收测试是最终用户执行的测试，使用黑盒测试技术对照系统规约对其进行测试。最终用户负责确保所有相关功能都被测试到。验收测试由用户在测试人员的指导下进行。用户验收测试的内容主要包括：适合性、准确性、互操作性、安全保密性、成熟性、容错性、易恢复性、易理解性、易学性、易操作性、吸引性、时间特性、资源利用性、易分析性、易

26、改变性、稳定性、易测试性、适应性、易安装性、共存性、易替换性和依赖性方法进行选择，确定测试内容。对具体的软件系统，可根据合同（或业务需求）的要求对测试内容进行裁剪。用户验收测试的重要依据是业务需求说明书、需求规格说明书及相关需求文档。用户验收测试阶段形成的文档包括：用户验收测试计划、用户验收测试案例、用户验收测试报告等。一.5.1 测试方法用户验收测试一般采用黑盒测试方法，如： 功能分解：功能分解法是将需求规格说明中每一个功能加以分解，确保各个功能被全面的测试。 等价类划分：等价类划分是在分析需求规格说明的基础上，把程序的输入域划分成若干部分，然后在每部分中选取代表性数据形成测试案例。 边界值

27、分析：边界值分析法是对边界值进行测试，使用等于、小于或大于边界值的数据对程序进行测试。 判定表：判定表由四部分组成：条件桩、条件条目、动作桩、动作条目。任何一个条件的组合的取值及其相应要执行的操作构成规则，条目中的每一条是一条规则。条件引用输入的等价类，动作引用被测软件的主要功能处理部分，规则就是测试案例。建立并优化判定表，把判定表中每一列标识的情况写成测试案例。 因果图：因果图分析法是通过画因果图，把用自然语言描述的功能说明转换为判定表，然后为判定表的每一列设计一个测试案例。 随机测试：随机测试输入的数据是在所有可能输入值中随机选取的。测试人员只需规定输入变量的取值区间，在需要时提供必要的变

28、换机制，使产生的随机数服从预期的概率分布。该方法获得预期输出比较困难。多用于可靠性测试和系统强度测试。 猜错法：猜错法是由有经验的测试人员，通过列出可能有的差错和易错情况表，写出测试案例的方法。 正交实验法：正交实验是从大量的实验点中挑出适量的、有代表性的点，应用正交表，合理的安排实验的一种科学的实验设计方法。在实践中，用户验收测试多采用几种测试方法相结合的方式进行。 一.5.2 测试流程用户验收测试对应开发过程中的业务需求分析阶段，其流程应包括：测试计划、设计测试、执行测试、总结测试等环节。用户验收测试流程图用户验收测试应该以用户（通常是业务人员）为主体，由业务人员独立完成该阶段的测试活动。

29、业务人员可以参考前一测试阶段（系统测试）的交付物，即：系统测试需求系统测试案例、系统测试报告等。第二章 测试阶段意义从上一章中已经了解了测试应该做那些测试，如果做这些测试，但是为什么要做这些测试，做这些测试有什么好处，不做这些测试会存在哪些问题或隐患，下面将介绍各测试阶段的实施的意义以及不实施这些阶段的问题。二.1 单元测试二.1.1 单元测试的意义为了很好的完成软件系统的测试任务，我们采用了分层测试的方式，从整体来说做UAT测试的时候我们假设软件系统是一个出厂的产品，最基本的功能都已经实现，这种假设我们通过系统测试来完成，但在做系统测试时，就要假设整个系统的集成运行已经没有问题了，在运行测试

30、或性能测试时，我将不再考虑“系统无法正常运行”这种场景。那么如何保证集成运行没问题呢?我们用集成测试来检验。但是在做集成测试的时候，我们同样要基于一个假定，就是各个模块的功能都能够如期正常工作。而这一点，又是通过模块自身的功能测试来完成的。这样一层层往下推，每个层次就假设它所依赖的层次没有问题，这样就可以减少很多场景以及由这些场景引出的额外的分支。将原先一个几何级数的测试用例分解成可以接受的若干层次的算术级数的用例。这样一来我们就可以很好的完成测试任务。而单元测试，正是这些测试的最低层次保证每个函数/方法，或者说最小功能模块的正确性的一种测试。二.1.2 无单元测试阶段的问题如果不进行单元测试

31、，开发人员开发完成代码后，顶多是从他实现功能的角度上进行一些验证，但这种验证是不全面，无法保证可能会出现的产生无法走通的分支、无法走出的循环以及产生内容泄露的问题，这些问题如果在在单元测试阶段发现的话，很容易查找并修改完成，但是如果在后期系统测试或者是上线以后发现就会产生很大的问题，首先上线后可能会产生生产的事故，其次如果没上线，在大量的代码中去查找分析和修改这些代码会产生很多的成本，甚至发现这样的问题都因为影响非常大而无法修改。二.2 集成测试二.2.1 集成测试的意义集成测试识别组合单元时出现的问题。通过使用要求在组合单元前测试每个单元并确保每个单元的生存能力的测试计划，可以知道在组合单元时所发现的任何错误很可能与单元之间的接口有关。这种方法将可能发生的情况数量减少到更简单的分析级别。 集成测试是在单元测试的基础上，测试在将所有的软件单元按照概要设计规格说明的要求组装成模块、子系统或系统的过程中各部分工作是否达到或实现相应技术指标及要求的活动。也就是说，在集成测试之前，单元测试应该已经完成，集成测试中所使用的对象应该是已经经过单元测试的软件单元。