软件测试各过程的意义.docx
《软件测试各过程的意义.docx》由会员分享，可在线阅读，更多相关《软件测试各过程的意义.docx（25页珍藏版）》请在冰点文库上搜索。
软件测试各过程的意义
软件测试过程
海辉软件应用测试部门在长期的行业测试经验中，在软件测试过程
模型方面总结出了如下图所示的改进W模型:
业务需求
V&V系统测试设计
V&V验收测试设计
需求分析
概要设计
详细设计
集成测试设计
编码实现
系统集成测试
*
（SIT）
系统构建
测试组测试
集成测试
试运行/部署验证
验证
模块集成
单元测试
用户验A测试上线版本验证/
系统测试
验证
内部集成
l』&V单元测试设计
开发组测试
软件测试改进W模型
相对于传统v模型，W莫型更科学，由一个开发的“V'和一个与之并行的测试“V’组成，体现了“尽早地和不断地进行软件测试”的软
件测试基本原则，强调的是测试伴随着整个软件开发周期，测试与开发是同步进行的，而且测试的对象不仅仅是程序代码，需求、设计同样要进行测试（图中的“v&v即表示对需求文档、设计文档的验证
Verification和确认Validation）。
根据金融行业应用系统IT架构复杂、应用系统间关联度高的特点，在单一应用系统系统测试完成后，应进一步在具备其他应用系统的测试环境中执行“系统集成测试”（SystemIntegrationTesting，SIT），
以验证各应用系统间数据传递正确、业务功能正常完成。
鉴于金融行业对应用系统准确性、稳定性、安全性要求高及应用系统失败将造成巨大损失的特点，为保证万无一失，在用户验收测试完成后、系统正式上线前，一般还会在准生成环境中进行“上线版本验证”测试，再次验证系统功能性能是否满足要求，系统在使用过程中是否会出错等等。
按照当前金融行业开发测试现状，一般情况下，单元测试、集成测试由开发项目组执行，系统测试、系统集成测试、用户验收测试、上线版本验证测试由测试部门执行或参与（用户验收测试由业务部门组织执行，测试部门提供测试工具支持和测试环境支持等）。
第一章测试阶段说明
根据海辉测试W模型，测试按阶段划分可分为：
单元测试、集成测
试、系统测试和用户验收测试（UAT，在系统测试完成后，根据被测系
统具体情况可选择实施系统集成测试（SIT）和上线版本检验测试。
测试在不同阶段涉及到的部分测试内容如下表所示:
阶段］
测试内容
备注
单元测试
静态测试
代码走杳、交叉检杳、内部评审、静态扫描
开发方测试
动态测试
动态执行检杳
开发方测试
集成测试
接口测试
接口符合性测试
开发方测试
功能测试
数据流转、处理逻辑测试
开发方测试
系统测试
功能测试
功能测试（GUI、业务、健壮性等）
自动化回归测试
第三方测试
非功能测试
（技术测试）
性能测试
第三方测试
可靠性/可恢复性测试
第三方测试
安装配置测试
第三方测试
安全性测试
第三方测试
文档测试
第三方测试
对开发方提供的需求说明书、详细设计说明书、数据库安装手册等文档的检杳和测试
系统集成测试（SIT）
兼容性
第三方测试支持平台的兼容性
互联测试
第三方测试
与其它生产系统的联通测试
用户验收测试（UAT）
功能和业务流程测试
业务用户测试
系统用户的代表进行测试
上线版本检验测试
业务流程
自动化回归测试
第三方测试或业务用户测试
业务流程测试
第三方测试或业务用户测试可以有针对性地选择部分业务
1.1单元测试
单元测试是测试的基础级别。
单元测试着眼于程序或系统的较小构建模块，是执行每个模块以证实其履行了指定功能的过程。
单元测试由开发人员完成。
单元测试过程是根据详细设计文档和编码规范的要求，对系统中程序单元并行进行测试。
单元测试阶段形成的文档包括：
《单元测试计划》、《单元测试案例》、《单元测试报告》、《代码审查表》等。
1.1.1测试方法
单元测试的方法主要采用静态测试方法和动态测试方法。
静态测试
静态测试方法能快速找到缺陷，发现30%-70%勺逻辑设计和编码缺陷。
静态测试方法的依据是项目的程序设计文档、程序的源代码清单、编码规范和代码审查表等。
静态测试中最常用勺手段是代码审查。
审查是一种正式勺评估方法，将由非制作者本人勺个人或小组详细检查阶段成果，以查明是否有错误、是否违反开发标准及是否存在其他问题。
代码审查可以发现违背编码规范勺问题，程序中不安全、不明确和模糊勺部分，找出程序中不可移植部分、违背程序编程风格勺问题，包括变量检查、命名和类型审查、程序逻辑审查、程序语法检查和程序结构检查等内容。
执行代码审查前，各个项目组需制定适用于本项目勺《代码审查表》，覆盖以下几类问题，并对每类问题进行细化和补充：
Commen：
t注释没写，或者格式不对，或者毫无意义CodingStandard：
没遵守编码规范
ExistingWheel：
重复现成勺代码，或者是开源项目，或者其他项目已有代码
PerformancebottleandImprovement：
性能问题
CodeLogicError：
代码逻辑错误
BusinessLogicError：
业务逻辑错误
动态测试
针对代码只进行静态测试是不完整的。
动态测试是通过输入一组预先按照一定的测试准则构造的实例数据来动态运行程序，而达到发现程序错误的过程。
动态测试的必要手段是设计和执行单元测试案例，其覆盖标准有：
语句覆盖：
每条语句至少执行一次判定覆盖：
每个判定的每个分支至少执行一次条件覆盖：
每个判定的每个条件应取到各种可能的值判定/条件覆盖：
同时满足判定覆盖条件覆盖条件组合覆盖：
每个判定中各条件的每一种组合至少出现一次路径覆盖：
使程序中每一条可能的路径至少执行一次。
要达到较强的覆盖程度，需要付出案例设计和编写的工作量。
动态测试案例的设计一般和代码重构并行完成，可以采用以下方法进行补充和完善：
基本路径法：
在程序控制流图的基础上，通过分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试案例的方法。
设计出的测试案例要保证在测试中程序的每个可执行语句至少执行一次。
边界值分析法：
合理的输入条件与不合理的输入条件。
错误推测法：
列举出程序中所有可能的错误和容易发生错误的特殊情况，根据它们选择测试案例。
1.1.2测试流程
单元测试对应开发过程中的编码阶段，其流程包括测试计划、测试
设计、测试执行、测试总结、测试过程审计等环节
在单元测试过程中体现了静态测试（代码审查）和动态测试相结合的方法。
代码审查一般在动态测试之前启动，并允许交错或同步进行。
1.2集成测试
集成测试，也叫组装测试或联合测试，是在单元测试的基础上，将
所有模块按照设计要求（如根据结构图）组装成为子系统或系统，进行集成测试。
集成测试的目的是检验软件单元之间、软件单元和已集成的软件系统之间的接口关系，并验证已集成软件系统是否符合设计要求。
集成测试的重要依据是《概要设计说明书》及相关设计文档。
集成测试阶段形成的文档包括：
《集成测试计划》、《集成测试案例》、《集成测试报告》等。
1.2.1测试方法
实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。
程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。
此外，在某些开发模式中，如迭代式开发，设计和实现是迭代进行的。
在这种情况下，集成测试的意义还在于它能间接地验证概要设计是否具有可行性。
以下介绍了几种常用的集成测试方法和策略：
自顶向下、自底向上、核心先行集成、高频度集成等。
在实践中通常会采用几种集成策略相结合的测试方法，例如：
复杂软件项目集成测试过程中，通常采用核心系统先行集成测试和高频集成测试相结合的方式进行；而传统瀑布式开发模式的软件项目集成过程中较常用自底向上的集成测试方案。
自顶向下集成
自顶向下集成（Top-DownIntegration）方式是一个递增的组装软件结构的方法。
从主控模块（主程序）开始沿控制层向下移动，把模块一一组合起来。
分两种方法：
结合项目的实际工程环境及各测试方案适用的范围进行合理的选型。
先深度：
按照结构，用一条主控制路径将所有模块组合起来；
先宽度：
逐层组合所有下属模块，在每一层水平地沿着移动。
自底向上集成
自底向上的集成（Bottom-UpIntegration）方式是最常使用的方法。
其它集成方法都或多或少地继承、吸收了这种集成方式的思想。
自底向上集成方式从程序模块结构中最底层的模块开始组装和测试。
因为模块是自底向上进行组装的，对于一个给定层次的模块，它的子模块（包括子模块的所有下属模块）事前已经完成组装并经过测试，所以不再需要编制桩模块（一种能模拟真实模块，给待测模块提供调用接口或数据的测试用软件模块）。
核心集成测试
核心系统先行集成测试法的思想是先对核心软件部件进行集成测试，在测试通过的基础上再按各外围软件部件的重要程度逐个集成到核心系统中。
每次加入一个外围软件部件都产生一个产品基线，直至最后形成稳定的软件产品。
核心系统先行集成测试法对应的集成过程是一个逐渐趋于闭合的螺旋形曲线，代表产品逐步定型的过程。
核心集成测试方法对于快速软件开发很有效果，适合较复杂系统的集成测试，能保证一些重要的功能和服务的实现。
缺点是采用此法的系统一般应能明确区分核心软件部件和外围软件部件，核心软件部件应具有较高的耦合度，外围软件部件内部也应具有较高的耦合度，但各外围软件部件之间应具有较低的耦合度。
高频集成测试
高频集成测试是指同步于软件开发过程，每隔一段时间对开发团队的现有代码进行一次集成测试。
如某些自动化集成测试工具能实现每日深夜对开发团队的现有代码进行一次集成测试，然后将测试结果发到各开发人员的电子邮箱中。
该集成测试方法频繁地将新代码加入到一个已经稳定的基线中，以免集成故障难以发现，同时控制可能出现的基线偏差。
该测试方案能在开发过程中及时发现代码错误，能直观地看到开发团队的有效工程进度。
在此方案中，开发维护源代码与开发维护软件测试包被赋予了同等的重要性，这对有效防止错误、及时纠正错误都很有帮助。
该方案的缺点在于测试包有时候可能不能暴露深层次的编码错误和图形界面错误。
1.2.2测试流程
集成测试对应开发过程中的概要设计阶段，其流程包括测试计划、
测试设计、测试执行、测试总结、测试过程审查等环节
制定集成测试计划（评审测试计划）
b设计集成测试*评审测试案例辽
编写集成测试报告
（评审测试报告莎
结束
集成测试计划
集成测试案例
缺陷记录表
集成测试报告
集成测试报告检查表—集成测试案例检查表.
集成测试计划检查表
集成测试流程图
集成测试阶段的测试活动首先应该根据项目所选的集成方式制定测
试策略。
同时，应该充分依据上一测试阶段（单元测试）的成果物，进行参考、复用和补充。
1.3系统测试
系统测试是在特定环境下对系统进行全面测试的过程。
系统测试执行一组测试，以验证软件质量保证计划中的各种质量属性。
系统测试的对象是完整的、集成的计算机系统。
这里不仅包括需要测试的产品系统的软件，还要包含软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等。
因此，必须将系统中的软件与各种依赖的资源结合起来，在系统实际（或模拟）的运行环境下来进行测试。
系统测试由独立的测试团队完成，应避免由开发方主导的系统测试。
系统测试的重要依据是《需求规格说明书》及相关设计文档。
系统测试阶段形成的文档包括：
《系统测试计划》、《系统测试需求》、《系统测试案例》、《系统测试报告》等。
1.3.1测试方法
系统测试主要采用黑盒测试的方法，说明如下：
功能分解：
功能分解法是将需求规格说明中每一个功能加以分解，确保各个功能被全面的测试。
等价类划分：
等价类划分是在分析需求规格说明的基础上，把程序的输入域划分成若干部分，然后在每部分中选取代表性数据形成测试案例。
边界值分析：
边界值分析法是对边界值进行测试，使用等于、小于或大于边界值的数据对程序进行测试。
判定表：
判定表由四部分组成：
条件桩、条件条目、动作桩、动作条目。
任何一个条件的组合的取值及其相应要执行的操作构成规则，条目中的每一条是一条规则。
条件引用输入的等价类，动作引用被测软件的主要功能处理部分，规则就是测试案例。
建立并优化判定表，把判定表中每一列标识的情况写成测试案例。
因果图：
因果图分析法是通过画因果图，把用自然语言描述的功能说明转换为判定表，然后为判定表的每一列设计一个测试案例。
随机测试：
随机测试输入的数据是在所有可能输入值中随机选取的。
测试人员只需规定输入变量的取值区间，在需要时提供必要的变换机制，使产生的随机数服从预期的概率分布。
该方法获得预期输出比较困难。
多用于可靠性测试和系统强度测试。
猜错法：
猜错法是由有经验的测试人员，通过列出可能有的差错和易错情况表，写出测试案例的方法。
正交实验法：
正交实验是从大量的实验点中挑出适量的、有代表性的点，应用正交表，合理的安排实验的一种科学的实验设计方法。
在系统测试的实践中，多采用几种测试方法相结合的方式进行。
1.3.2测试流程
系统测试对应开发过程中的需求分析阶段，其流程包括测试计划、
测试需求分析、测试设计、测试执行、测试总结、测试过程审查等环节。
系统测试计划
系统测试需求
系统测试报告检查表
系统测试案例检查表
系统测试案例
系统测试需求检查表
系统测试计划检查表
系统测试报告
开始
系统测试流程图
（评审测试计划
缺陷记录表
结束
系统测试阶段的测试活动应该是专门的测试团队独立完成的测试。
同时，应该充分依据上一测试阶段（集成测试）的成果物，进行参考、复用和补充。
1.4系统集成测试
系统集成测试也可称为兼容性测试，目的是验证被测系统与其它已经上线的生产系统之间交互操作的正确性和可靠性。
系统集成测试可以由测试团队或者测试与开发协作完成。
系统集成测试阶段形成的文档包括：
《系统集成测试计划》、《系统
集成测试需求》、《系统集成测试案例》、《系统集成测试报告》等。
1.4.1测试方法
系统集成测试主要采用黑盒测试的方法，说明如下：
功能分解：
功能分解法是将需求规格说明中每一个功能加以分解，确保各个功能被全面的测试。
等价类划分：
等价类划分是在分析需求规格说明的基础上，把程序的输入域划分成若干部分，然后在每部分中选取代表性数据形成测试案例。
边界值分析：
边界值分析法是对边界值进行测试，使用等于、小于或大于边界值的数据对程序进行测试。
判定表：
判定表由四部分组成：
条件桩、条件条目、动作桩、动作条目。
任何一个条件的组合的取值及其相应要执行的操作构成规则，条目中的每一条是一条规则。
条件引用输入的等价类，动作引用被测软件的主要功能处理部分，规则就是测试案例。
建立并优化判定表，把判定表中每一列标识的情况写成测试案例。
因果图：
因果图分析法是通过画因果图，把用自然语言描述的功能说明转换为判定表，然后为判定表的每一列设计一个测试案例。
随机测试：
随机测试输入的数据是在所有可能输入值中随机选取的。
测试人员只需规定输入变量的取值区间，在需要时提供必要的变换机制，使产生的随机数服从预期的概率分布。
该方法获得预期输出比较困难。
多用于可靠性测试和系统强度测试。
猜错法：
猜错法是由有经验的测试人员，通过列出可能有的差错和易错情况表，写出测试案例的方法。
正交实验法：
正交实验是从大量的实验点中挑出适量的、有代表性的点，应用正交表，合理的安排实验的一种科学的实验设计方法。
在系统集成测试的实践中，多采用几种测试方法相结合的方式进行。
1.4.2测试流程
系统集成测试对应开发过程中的需求分析阶段，其流程包括测试计划、测试需求分析、测试设计、测试执行、测试总结、测试过程审查等
环节。
系统集成测试阶段的测试活动是测试团队独立完成或测试与开发协
作完成的测试。
同时，应该充分依据上一测试阶段的成果物，进行参考、复用和补充。
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接收后解析缺正好相反，这就产生了问题，这是一个简单的例子，但是又一些集成的问题在后期发现的话，会因为无法集成而需要推翻之前的代码重新编写
升级会员 