用例驱动方法来自UP,由jacobson提出,并成为UP中最闪亮的瑰宝和核心,用例驱动主张一切来自需求,这本身非常正确,但用例之后的分析,设计过程被一些敏捷专家所诟病,认为这个过程太过重量级,因为需求一直在变,而且随着项目的进展,设计会弱化,同时还得保持分析文档,设计文档和代码的同步,如果能时刻保持增量和迭代那么还好,否则就是灾难了。
测试驱动则采取另外的思路,非常轻型的分析和设计,所有的代码从测试的角度产生,一旦需求发生改动,重构代码到测试通过。传统上,大多数人是先写代码再写测试,如果已知代码可行,确实写测试也会失去激情,随着项目的深入,需求的改动,最后期限的到来,为代码编写测试就是mission impossible。
那么两种非常优秀的开发方法如何结合呢?
我来谈谈我的一点初步的实践:
实践中我发现用例驱动和测试驱动有重叠的地方,因为在测试驱动的前期会有很多称之为story的东西,我认为这个story就是需求( 测试驱动偏重于代码的编写和维护,对story介绍相对较少) ,既然是需求,还有什么比使用usecase更贴切的呢,我在项目中通常首先使用usecase做需求,这样会对整个项目有个全局的认识,然后我再根据usecase做测试驱动(此前还会做些简单的领域分析) ,实际上我们将测试驱动很大程度上取代了up需求之后的分析,设计和编码,一旦需求发生改动,我会考虑更新usecase(可跟踪被建模的代码),然后改写测试,改写代码(几乎100%要重构代码),最后进行单元测试来保证我的改动没有破坏我所有预期的行为.
这样做的好处在于:
1) 采用usecase可以很好的反应需求,同时也可以很平滑的过渡到代码,是一个跟踪需求和代码的很好的手段
当然这牵涉到如何编写有效用例的问题,这超出了本文讨论的范围,请参考其他文献
2)采用测试驱动可以大胆的重构代码和不必担心引入bug,而且所有的代码都来自于测试,这就使得代码可控.另外测试可以改进设计,通常不方便测试的代码往往耦合严重,等你改动代码方便测试了,往往你的设计会变得更好.
当然这里面还牵涉到如何测试和测试覆盖率的统计问题,这超出了本文讨论的范围,请参考其他文献
分享到:
相关推荐
软件测试_测试用例软件测试_测试用例软件测试_测试用例软件测试_测试用例
测试用例示例测试用例示例测试用例示例测试用例示例测试用例示例测试用例示例测试用例示例测试用例示例测试用例示例测试用例示例测试用例示例
软件测试过程中,功能测试及性能测试的测试用例一般比较多,但安全测试的用例就少一些,这是我日常工作中整理的安全测试用例的样例,与大家分享探讨。
测试用例实践回顾和简析 研究测试用例的重要意义 软件领域发展对测试用例技术实践的挑战 测试用例制约因素 微软测试用例实践研究 测试用例最佳实践 问题解答
有关系统测试的流程,以及缺陷管理,测试管理,测试用例设计,系统测试流程和用例
测试用例方法及实践用例,包含[优]测试用例设计之判定表驱动分析方法.pdf [优]测试用例设计之因果图方法 [优]测试用例设计之正交法 [优]公共用例设计实践 [优]精简测试用例编写 [优]授客细说场景测试用例设计与实践
软件测试用例模版【仅供参考】软件测试用例模版【仅供参考】软件测试用例模版【仅供参考】软件测试用例模版【仅供参考】软件测试用例模版【仅供参考】软件测试用例模版【仅供参考】软件测试用例模版【仅供参考】软件...
标准测试用例标准测试用例标准测试用例标准测试用例标准测试用例标准测试用例标准测试用例标准测试用例标准测试用例标准测试用例标准测试用例
多个软件测试资料合集 测试培训 测试用例设计 测试用例设计原则和模板 软件测试报告 软件测试基本方法 测试新员工培训 测试管理精华 技术文档-测试规范(公司)
硬件测试用例参考(二)
测试用例的基本概念 测试用例的设计和编写 测试用例评估 测试用例的管理
性能测试用例性能测试用例性能测试用例性能测试用例
测试用例的分类 3 文本框需求 4 字段为特殊代码校验: 4 文本框为数值型 4 文本框为日期型 5 文本框为时间型 6 密码框 返回目录 6 单选按钮 7 组合列表框/下拉列表 7 数码框(up-down)控件 8 搜索框填充域测试 8 复...
********售票系统测试项目测试用例模板
测试用例模板测试用例模板测试用例模板测试用例模板
软件测试实践之测试需求与测试用例。很有帮助
白盒测试测试用例设计,实验中经常用到的典型的白盒测试案例!
测试用例模板 测试用例 模板测试用例模板 测试用例 模板
黑盒测试方法和用例设计 基本黑盒测试方法 实例讲解 用例设计步骤