衡量软件测试结果的依据--需求

需求的概念

满足用户期望或正式规定文档(合同, 规范, 标准)所具备的条件或权能, 包含用户需求和软件需求.

IEEE:定义: 软件需求是(1)用户解决问题或达到目标所需的条件或权能. (2)系统或系统部件要满足合同, 标准, 规范或其它正式规定文档所具备的条件或权能. 一种反映上面(1)或(2)所述条件或权能的文档说明. 它包括功能性需求及非功能性需求, 非功能性需求对设计和实现提出了限制, 比如性能要求, 质量标准, 或者设计限制.

在多数软件公司, 会有两部分需求, 一个是用户需求, 另一个是软件需求.

用户需求:可以简单理解为甲方提出的要求. 如果没有甲方, 那么就是终端用户使用产品时必须要完成的任务. 该需求一般会比较简略.

软件需求: 或者叫功能需求, 该需求会详细描述开发人员必须实现的软件功能, 大多数公司在进行软件开发时会把用户需求转化为软件需求, 开发人员和测试人员工作的直接依据就是软件需求.

软件需求是测试人员进行测试工作的基本依据.

从软件测试人员的角度看需求

需求是测试人员开展软件测试的依据. 

在具体设计测试用例的时候, 首先需要搞清楚每一个业务需求对应的多个软件功能的测试点, 然后分析出每个软件功能需求点对应的多个测试需求点, 然后针对每个测试需求点设计测试用例.

过程如下: 业务需求 -> 软件功能需求点 -> 测试需求点 -> 测试用例. 

以用户登录为例, 来阐述下整个过程:

为什么需求对软件测试人员如此重要

1.从软件功能需求出发, 无遗漏的识别出测试需求是至关重要的, 这将直接关系到用例的测试覆盖率. 

2.对于识别出的每个测试需求点, 需要采用具体的设计测试用例的方法来进行测试用例设计

如何才可以深入理解被测试软件的需求

测试工程师在需求分析和设计阶段就开始介入,  因为这个阶段是理解和掌握软件的原始业务需求的最好时机.

只有真正理解原始业务需求之后, 才有可能从业务需求的角度去设计针对性明确, 从终端用户的使用场景到端的覆盖率较高的测试用例集.

测试用例的概念

测试用例是为了实施测试而向被测试的系统提供的一组集合, 这组集合包含: 测试环境, 操作步骤, 测试数据, 预期结果等要素. 

测试用例解决了两大问题: 测什么, 怎么测?

举个栗子:

测试用例ecsp39: 用户注册成功
步骤运作	预期结果
进入注册页面, 选择注册	系统展现注册页面
输入符合要求的单位名称, 单位邮箱, 密码, 确认密码, 验证码, 并确认《同意用户注册 协议》, 提交注册信息	系统进行注册操作, 发送激活邮件. 注册 成功后,跳转到注册页面, 并提示用户进行 激活操作
进入注册用的邮箱, 进行激活操作	激活成功
用注册的邮箱和密码, 进行登录操作	登陆成功, 系统展示欢迎的页面
测试方式	手工
重要性	重要
测试环境	CHROME, IE10
测试前提	系统运行正常, 邮件服务器已开启
功能模块	注册登录

测试过程中可能会遇到以下问题:  -不知道是否较全面的测试了所有功能 - 测试用例的覆盖率无法衡量 - 对新版本的重复测试很难实施 - 存在大量冗余测试影响测试效率. 

测试用例的产生就是为了解决上述问题.

软件错误(BUG)的概念

当且仅当规格说明是存在的并且正确, 程序与规格说明之间的不匹配才是错误. 

当需求规格说明书没有提到的功能, 判断标准以最终用户为准: 当程序没有实现其最终用户合理预期的功能需求时, 就是软件错误.

开发模型和测试模型

随着软件工程学科的发展, 人们对计算机软件的认识逐渐深入. 软件工作的范围不仅仅再局限于程序编写, 而是扩展到整个软件的生命周期, 如软件基本概念的形成, 需求分析, 设计, 编码, 测试, 安装部署, 运行维护, 直到软件被更新和替换新的版本.软件工程还包括很多技术性的管理工作, 例如过程管理, 产品管理, 资源管理和质量管理, 在这些方面也逐步建立起了标准或规范. 

软件的生命周期

软件生命周期是指从软件产品的设想开始到软件不再使用而结束的时间. 如果把软件看成是有生命的事物, 那么软件的生命周期可以分为6个阶段. 即需求分析, 计划, 设计, 编码, 测试, 运行维护.

瀑布模型

瀑布模型在软件工程中占有重要地位, 是所有其它模型的基础框架. 瀑布模型的每一个阶段都只执行一次, 因此是线性顺序进行的软件开发模式.

优点: 强调开发的阶段性; 强调早期计划以及需求检查.

缺点: 依赖于早期进行的唯一一次需求调查, 不能适应需求的变化; 由于是单一流程, 开发中的经验教训不能反馈应用于本产品的过程; 风险往往迟至后期的测试阶段才显露, 因而失去早期纠正的机会. 

 螺旋模型

一般在软件开发的初期阶段需求不是很明确时, 采用渐进式的开发模式. 螺旋模型是渐进式开发模型的代表之一.

这对于那些规模庞大, 复杂度高, 风险大的项目尤其适合. 这种迭代开发的模式给软件测试带来了新的要求, 它不允许有一段独立的测试时间和阶段, 测试必须跟随开发的迭代而迭代. 因此, 回归测试的重要性就不言而喻了.

优点: 强调严格的全过程风险管理; 强调各开发阶段的质量; 提供机会检讨项目是否有价值继续下去.

缺点: 引入非常严格的风险识别, 风险分析和风险控制, 这对风险管理的技能水平提出了很高的要求. 这需要人员, 资金和时间的投入. 

增量, 迭代

增量开发能显著降低项目风险, 结合软件持续构建机制, 构成了当今流行的软件工程的最佳实践之一. 增量开发模型, 鼓励用户反馈, 在每个迭代的过程中, 促使开发小组以一种循环的, 可预测的方式驱动产品的开发. 因此, 在这种开发模式下, 每一次的迭代都意味着可能有需求的更改, 构建出新的可执行软件版本, 意味着测试需要频繁进行, 测试人员需要与开发人员更加紧密的合作.

增量通常与迭代混为一谈, 但其实两者是有区别的. 增量是逐块构造的概念,  例如画一幅人物画, 我们可以先画人的头部, 再画身体, 再画手脚.... 而迭代是反复求精的概念, 类似于画素描, 从简入繁.

敏捷开发

敏捷开发的价值观:

个体与交互重于过程与工具

可用的软件重于完备的文档

客户协作重于合同谈判

响应变化重于遵循计划

在每对比对中, 后者并非全无价值, 但我们更看重前者

敏捷中的测试

挑战1: 轻文档. 

挑战2:快速迭代.

1.测试工作的核心内容是没有变的, 就是不断地找BUG, 只是要调整好自己的心态, 一切以敏捷的原则为主.

2.测试人员不能依赖文档, 测试用例作用减弱, 更多的使用思维导图, 探索性测试(强调自由度, 设计和执行同时执行, 根据测试结果不断调整测试计划), 自动化测试.

3.敏捷讲求合作, 在敏捷项目组中, 测试人员应该主动点, 多向开发人员了解需求, 讨论设计, 一起研究BUG的出现原因.

软件测试V模型

 

 特点:

1.明确地标注了测试过程中存在不同类型的测试, 并且清楚的描述了这些测试阶段和开发过程期间各阶段的对应关系.

2.V模型指出, 单元和集成测试应检测程序的执行是否满足软件设计的要求; 系统测试应检测系统功能, 性能的质量特性是否达到系统要求的指标; 验收测试确定软件的实现是否满足用户需要或合同的要求.

软件测试W模型

 

W模型增加了软件各开发阶段中应同步进行的验证和确认活动. W模型由两个V字模型组成, 分别代表了测试和开发的过程, 图中明确表示出了测试与开发的并行关系.

W模型特点: 测试的对象不仅是程序, 需求, 设计等同样要测试, 测试和开发是同步进行的.

W模型优点: 有利于尽早地全面发现问题. 例如: 需求分析完成后, 测试人员就应参与到对需求的验证和确认活动中, 以尽早找出缺陷所在. 同时, 对需求的测试也有利于及时了解项目难度和测试风险, 及早指定应对措施, 显著减小总体的测试时间, 加快项目进度.

局限性: 需求, 设计, 编码等活动被视为串行的; 测试和开发活动也保持着一种线性的前后关系, 上一阶段完全结束, 才可以正式开始下一个阶段的工作. 无法支持敏捷开发模式. 对于当前软件复杂多变的情况, W模型并不能解除问题.