6.2 软件测试策略
6.2 软件测试策略
软件测试策略
- 作用：为软件开发人员、质量保证组织、和客户提供了一个路线图、规定了测试的主要步骤
- 为保证可行性，须考虑人力成本、时间和资源
- 故应结合：测试计划、测试用例设计、测试执行、测试结果数据的收集与分析
- 要求
- 灵活性：有足够的可塑性来应付所有的大软件系统 严格：保证对项目进程进行合理的计划和跟踪管理·
软件测试策略注意事项
在着手开始测试之前，要对产品的需求进行量化。明确指出测试目标。为每类用户建立描述交互场景的用例。建立一个强调“快速循环测试”的测试计划。设计一个能够测试自身是否“强壮”的软件。在进行测试之前，对软件进行有效的正式技术审核。使用正式技术审核来评估测试策略和测试用例本身。为测试过程建立一种持续的改进方法。
软件测试策略基本步骤
执行阶段
搭建测试环境
构造测试数据
执行测试并记录问题
确认问题
撰写测试报告
计划阶段
制定计划
编写与评审测试用例
编写测试脚本和准备测试环境
软件测试策略V模型
-
单元测试
主要目的是验证软件模块是否按详细设计的规格说明正确运行。
-
系统测试
主要目的是验证整个系统是否满足需求规格说明。
-
集成测试
主要目的是检查多个模块间是否按概要设计说明的方式协同工作。
-
验收测试
从用户的角度检查系统是否满足合同中定义的需求，以及以确认产品是否能符合业务上的需要。
回归测试
回归测试可以在所有的测试级别执行，并应用于功能和非功能测试中。
- 范围
- 缺陷再测试：重新运行所有发现故障的测试，而新的软件版本已经修正了这些故障。
- 功能改变的测试：测试所有修改或修正过的程序部分。新功能测试：测试所有新集成的程序。完全回归测试：测试整个系统。
why
1、测试中，如有缺陷修正、功能增加，变化的部分必须再测试。
2、软件的修改可能会导致新的缺陷及其他问题。为防止，需再测试。
what
回归测试:指有选择地重新测试系统或其组件，以验证对软件的修改没有导致不希望出现的影响，以及系统或组件仍然符合其指定的需求。
by
回归测试应该尽量采用自动化测试。
1、单元测试
单元测试概念
单元内涵
不同环境含义不同，面向过程：函数、过程等，面向对象：类、类中成员函数等。
单元测试
针对软件设计的最小单位 ─ 程序模块，进行正确性检验的测试工作。
测试方法
单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。
主要依据
详细设计
进入和退出条件
√ 所用测试用例执行通过
√ 单元测试覆盖率达到预定要求
√ 单元测试未被执行的代码进行
正式审查。
√ 被测代码编译链接通过
√ 被测代码静态检查工具检查通过
√ 已完成至少一轮代码检视或走读
√ 单元测试用例的检视通过
√ 单元测试代码写完并通过检测
测试内容
单元测试主要内容
数据流测试
√ 调用本模块的输入参数是否正确；
√ 本模块调用子模块时输入给子模块的参数是否正确；
√ 全局量的定义在各模块中是否一致；
内外存交换测试
√ 文件属性是否正确；
√ OPEN与CLOSE语句是否正确；
√ 缓冲区容量与记录长度是否匹配；
√ 在进行读写操作之前是否打开了文件；
√ 在结束文件处理时是否关闭了文件；
√ 正文书写／输入错误，
√ I／O错误是否检查并做了处理。
•局部数据结构测试
不正确或不一致的数据类型说明、使用尚未赋值或尚未初始化的变量、错误的初始值或错误的缺省值、变量名拼写错或书写错误、不一致的数据类型、全局数据对模块的影响
路径****测试
重要路径
对模块中重要的执行路径进行测试。
计算、控制流
查找由于错误的计算、不正确的比较或不正常的控制流而导致的错误。
基本、循环
对基本执行路径和循环进行测试可以发现大量的路径错误。
错误处理测试
出错的描述是否难以理解
、出错的描述是否能够对错误定位
、显示的错误与实际的错误是否相符
、对错误条件的处理正确与否
、在对错误进行处理之前，错误条件是否已经引起系统的干预等
边界测试
•流边界：注意数据流、控制流中刚好等于、大于或小于确定的比较值时出错的可能性。对这些地方要仔细地选择测试用例，加以测试。
•关键路径：如果对模块运行时间有要求的话，还要专门进行关键路径测试，以确定最坏情况下和平均意义下影响模块运行时间的因素。
测试用例设计
测试环境搭建
•模块并非独立程序，进行测试时，要考虑它和外界的联系，需用一些辅助模块去做相应模拟
•驱动模块 ： 用来模拟被测试模块的上一级模块，相当于被测模块的主程序。
•桩模块 ： 模拟被测试的模块所调用的模块，而不是软件产品的组成的部分。
2、集成测试
集成测试含义
将软件集成起来后进行测试。 别名：子系统测试、组装测试、部件测试等。
目的
检查诸如两个模块单独运行正常，但集成起来运行可能出现问题的情况。
主要方法
-
自顶向下的集成方法
-
自底向上的集成方法
-
SMOKE方法
测试用例的设计
- 通过性测试
- 失效性测试
- 覆盖率
- 注意接口
-
显性接口：函数调用（API）接口
-
隐形接口：消息、网络协议等
-
（1）自顶向下的集成方法
基本思想：该集成方式将模块按系统程序结构，沿控制层次自顶向下进行集成。
内置方法：深度优先、广度优先
优点
可以较早地验证主要的控制和判断点。按深度方向，可首先实现和验证一个完整的软件功能。
缺点
是桩模块，开发量较大
适用情况
- 控制结构清晰稳定;高层接口变化较小;
- 底层接口未定义或经常可能被修改;
- 接口控制组件具有较大的技术风险
- 需要尽早被验证;
- 希望尽早能看到产品的系统功能行为。
（2）自底向上的集成方法
基本思想:从软件结构最底层的模块开始，按照接口依赖关系逐层向上集成以进行测试。
优点
每个模块调用其他底层模块都已经测试,不需要桩模块;
缺点
必须编写驱动模块;缺陷的隔离和定位不如自顶向下。
适用情况
- 底层接口比较稳定;
- 高层接口变化比较频繁;
- 底层组件较早被完成。
应用注意事项
•实际工作中，常综合使用：自底向上、自顶向下
如：按进度选择优先测试已经完成的模块
If：被测模块所调用的模块未完成，用自顶向下，打桩测试。
If：被测模块的上层模块未完成，用自底向上，模拟根模块。
（3）SMOKE方法
基本思想
将已经转换为代码的软件构件集成为构造（build）。一个构造包括所有的数据文件、库、可复用的模块以及实现一个或多个产品功能所需的工程化构件。
目 标
设计暴露影响构造正确地完成其功能的错误的测试。以发现极有可能造成项目延迟的业务阻塞错误。
方 法
每天将该构造与其他构造，及整个软件产品集成，冒烟测试。
两种方法：自顶向下，自底向上，均可。
3、系统测试
含义
从用户使用的角度进行测试，将完成了集成测试的系统放在真实的运行环境下进行。【软件质量保证的最重要环节。】
目的
功能确认和验证
测试方法
黑盒测试
测试内容：
面向:外部输入层测试，如不做,则外部输入层向接口层转换的代码就没有得到测试。
面向:系统所有组件相互协调，单元、集成测试未做。
测试角度：
系统测试依据:需求规格说明
单元、集成测试依据:技术规格说明
系统测试内容
-
压力测试
-
性能测试
-
功能测试
-
恢复测试
-
安全测试
1\功能测试
在规定的一段时间内运行软件系统的所有功能，以验证这个软件系统有无严重错误。
•测试方法
黑盒测试
•错误类型
功能****错误或遗漏、界面错误、•数据结构或外部数据库访问错误、性能错误、初始化
2\性能测试
检查系统是否满足在需求说明书中规定的性能。
- 结合
常常要与压力测试结合进行，硬件和软件检测同时进行。 - 内容
- 响应时间
- 吞吐量
- 辅助存储区，如缓冲区、工作区的大小、处理精度等。
3\压力测试
在系统运行环境不正常乃至发生故障的情况下，系统可以运行到何种程度的测试
测试方法
-
把输入数据速率提高一个数量级，确定输入功能将如何响应
-
设计需要占用最大存储量或其它资源的测试用例进行测试。
-
设计出在虚拟存储管理机制中引起“颠簸”的测试用例进行测试。
-
设计出会对磁盘常驻内存的数据过度访问的测试用例进行测试。
另：
敏感性测试：压力测试的一个变种。在程序有效数据界限内一个小范围内的一组数据可能引起极端的或不平稳的错误处理出现，或者导致极度的性能下降。
4\恢复测试
用来证实——在克服硬件故障后，系统能否正常地继续进行工作，并且不对系统造成任何损害。
手 段：人工干预等
测试方法
- 错误探测功能──系统能否发现硬件失效与故障；
- 设备故障时，能否切换或启动备用的硬件；
- 故障发生时，能否保护正在运行的作业和系统状态；
- 系统恢复后，能否从最后记录下来的无错误状态开始继续执行作业等。
- 掉电测试：电源中断时，能否保护当时的状态且不毁坏数据，然后在电源恢复时从保留的断点处重新进行操作。
5\安全性测试
检验在系统中已经存在的系统安全性、保密性措施是否发挥作用，有无漏洞。
主要攻击方法
- 正面、侧面或背面攻击系统中易受损坏的那些部分；
- 以系统输入为突破口，利用输入的容错性进行正面攻击；
- 申请和占用过多的资源压垮系统，以破坏安全措施，从而进入系统；
- 故意使系统出错，利用系统恢复的过程，窃取用户口令及其它有用的信息；
- 通过浏览残留在计算机各种资源中的垃圾（无用信息），以获取如口令，安全码，译码关键字等信息；
- 浏览全局数据，期望从中找到进入系统的关键字；浏览逻辑上不存在，但物理上还存在的各种记录和资料等
4、验收测试
时间节点
系统的有效性测试及软件配置审查通过之后。
人员组织
以用户为主\开发人员\质量保证人员
测试内容
功能和性能的可移植性、兼容性、可维护性、错误的恢复功能等
测试数据
是实际生产数据
测试停止标准
软件是无法完全测试的 —— 何时停止测试？
对数泊松执行时间模型的软件故障模型
μ(t) 是在测试时间t 后，预期的故障累积数目。λ0 是测试开始时初始软件故障的密度。θ值决定了随着软件修正进程，故障密度呈指数递减的情况。
验收测试过程
验收测试形式
α测试
模拟用户在实际操作环境下的测试
原 因
交付后，用户的实际使用程序是无法预测的
目 的
评价FLURPS特性（功能、局域化、可使用性、可靠性、性能和支持）。尤其界面和特色
开始时间
- 编码结束后
- 模块（子系统）测试完成后
- 系统测试过程中产品达到一定的稳定和可靠程度后
β测试
多个用户在实际使用环境下进行测试，这些用户反馈有关错误信息给开发者。
测试人员
开发者通常不在测试现场，开发者无法控制的环境下进行的软件现场应用。
测试形式
用户记录所有问题(真实的、主观的)，定期向开发者报告。开始条件
α测试达到一定的可靠程度时开始，
测试步骤
产品的FLURPS。着重产品的支持性（文档、客户培训和支持产品生产能力)
测试自标
测试的最后阶段，所有手册文本此阶段完全定稿。
