软件测试过程模型的种类之--------------前置测试模型

    前置测试模型是由Robin FGoldsmith等人提出的,是一个将测试和开发紧密结合的模型,该模型提供了轻松的方式,可以使你的项目加快速度。

 

前置测试模型可参考下面的图示:

 

 

前置测试模型体现了以下的要点:

 

(一)开发和测试相结合

    前置测试模型将开发和测试的生命周期整合在一起,标识了项目生命周期从开始到结束之间的关键行为。并且表示了这些行为在项目周期中的价值所在。如果其中有些行为没有得到很好的执行,那么项目成功的可能性就会因此而有所降低。如果有业务需求,则系统开发过程将更有效率。在没有业务需求的情况下进行开发和测试是不可能的。而且,业务需求最好在设计和开发之前就被正确定义。

 

(二)对每一个交付内容进行测试

    每一个交付的开发结果都必须通过一定的方式进行测试。源程序代码并不是唯一需要测试的内容。在图中的绿色框表示了其它一些要测试的对象,包括可行性报告、业务需求说明,以及系统设计文档等。这同V模型中开发和测试的对应关系是相一致的,并且在其基础上有所扩展,变得更为明确。

 

    前置测试模型包括2项测试计划技术:

    其中的第一项技术是开发基于需求的测试用例。这并不仅仅是为以后提交上来的程序的测试做好初始化准备,也是为了验证需求是否是可测试的。这些测试可以交由用户来进行验收测试,或者由开发部门做某些技术测试。很多测试团体都认为,需求的可测试性即使不是需求首要的属性,也应是其最基本的属性之一。因此,在必要的时候可以为每一个需求编写测试用例。不过,基于需求的测试最多也只是和需求本身一样重要。一项需求可能本身是错误的,但它仍是可测试的。而且,你无法为一些被忽略的需求来编写测试用例。

    第二项技术是定义验收标准。在接受交付的系统之前,用户需要用验收标准来进行验证。验收标准并不仅仅是定义需求,还应在前置测试之前进行定义,这将帮助揭示某些需求是否正确,以及某些需求是否被忽略了。

 

    同样的,系统设计在投入编码实现之前也必须经过测试,以确保其正确性和完整性。很多组织趋向于对设计进行测试,而不是对需求进行测试。Goldsmith 曾提供过15项以上的测试方法来对设计进行测试,这些组织也只使用了其中很小的一部分。在对设计进行的测试中有一项非常有用的技术,即制订计划以确定应如何针对提交的系统进行测试,这在处于设计阶段并即将进入编码阶段时十分有用。

 

(三)在设计阶段进行计划和测试设计

    设计阶段是做测试计划和测试设计的最好时机。很多组织要么根本不做测试计划和测试设计,要么在即将开始执行测试之间才飞快地完成测试计划和设计。在这种情况下,测试只是验证了程序的正确性,而不是验证整个系统本该实现的东西。

 

    测试有2种主要的类型,这2种类型都需要测试计划。在V模型中,验收测试最早被定义好,并在最后执行,以验证所交付的系统是否真正符合用户业务的需求。V模型不同的是,前置测试模型认识到验收测试中所包含的3种成份,其中的2种都与业务需求定义相联系:即定义基于需求的测试,以及定义验收标准。但是,第三种则需要等到系统设计完成,因为验收测试计划是由针对按设计实现的系统来进行的一些明确操作定义所组成,这些定义包括:如何判断验收标准已经达到,以及基于需求的测试已算成功完成。

   

    技术测试主要是针对开发代码的测试,例如V模型中所定义的动态的单元测试,集成测试和系统测试。另外,前置测试还提示我们应增加静态审查,以及独立的QA测试。QA测试通常跟随在系统测试之后,从技术部门的意见和用户的预期方面出发,进行最后的检查.同样的还有特别测试。我们取名特别测试,并把该名称作为很多测试的一个统称,这些测试包括负载测试、安全性测试、可用性测试等等,这些测试不是由业务逻辑和应用来驱动的。

 

    对技术测试最基本的要求是验证代码的编写和设计的要求是否相一致。一致的意思是系统确实提供了要求提供的,并且系统并没有提供不要求提供的。技术测试在设计阶段进行计划和设计,并在开发阶段由技术部门来执行。

 

(四)测试和开发结合在一起

    前置测试将测试执行和开发结合在一起,并在开发阶段以编码-测试-编码-测试的方式来体现。也就是说,程序片段一旦编写完成,就会立即进行测试。普通情况下,先进行的测试是单元测试,因为开发人员认为通过测试来发现错误是最经济的方式。但也可参考X模型,即一个程序片段也需要相关的集成测试,甚至有时还需要一些特殊测试。对于一个特定的程序片段,其测试的顺序可以按照V模型的规定,但其中还会交织一些程序片段的开发,而不是按阶段完全地隔离。

 

    在技术测试计划中必须定义好这样的结合。测试的主体方法和结构应在设计阶段定义完成,并在开发阶段进行补充和升版。这尤其会对基于代码的测试产生影响,这种测试主要包括针对单元的测试和集成测试。不管在哪种情况下,如果在执行测试之前做一点计划和设计,都会提高测试效率,改善测试结果,而且对测试重用也更加有利。

 

(五)让验收测试和技术测试保持相互独立

    验收测试应该独立于技术测试,这样可以提供双重的保险,以保证设计及程序编码能够符合最终用户的需求。验收测试既可以在实施阶段的第一步来执行,也可以在开发阶段的最后一步执行。

    前置测试模型提倡验收测试和技术测试沿循2条不同的路线来进行,每条路线分别地验证系统是否能够如预期的设想进行正常工作。这样,当单独设计好的验收测试完成了系统的验证, 我们即可确信这是一个正确的系统。

(六)反复交替的开发和测试

    在项目中从很多方面可以看到变更的发生,例如需要重新访问前一阶段的内容,或者地跟踪并纠正以前提交的内容,修复错误,排除多余的成分,以及增加新发现的功能,等等。开发和测试需要一起反复交替地执行。模型并没有明确指出参与的系统部分的大小。这一点和V模型中所提供的内容相似。不同的是,前置测试模型对反复和交替进行了非常明确的描述。

 

(七)发现内在的价值

    前置测试能给需要使用测试技术的开发人员、测试人员、项目经理和用户等带来很多不同于传统方法的内在的价值。与以前的方法中很少划分优先级所不同的是,前置测试用较低的成本来及早发现错误,并且充分强调了测试对确保系统的高质量的重要意义。前置测试代表了整个对测试的新的不同的观念。在整个开发过程中,反复使用了各种测试技术以使开发人员、经理和用户节省其时间,简化其工作。

 

    通常情况下,开发人员会将测试工作视为阻碍其按期完成开发进度的额外的负担。然而,当我们提前定义好该如何对程序进行测试以后,我们会发现开发人员将节省至少20%的时间。虽然开发人员很少意识到他们的时间是如何分配的,也许他们只是感觉到有一大块时间从重新修改中节省下来可用来进行其它的开发。保守地说,在编码之前对设计进行测试可以节省总共将近一半的时间,这可以从以下方面体现出来:

针对设计的测试编写是检验设计的一个非常好的方法,由此可以及时避免因为设计不正确而造成的重复开发及代码修改。通常情况下,这样的测试可以使设计中的逻辑缺陷凸显出来。另一方面,编写测试用例还能揭示设计中比较模糊的地方。总的来说,如果你不能勾画出如何对程序进行测试,那么程序员很可能也很难确定他们所开发的程序怎样才算是正确的。

    测试工作先于程序开发而进行,这样可以明显地看到程序应该如何工作,否则,如果要等到程序开发完成后才开始测试,那么测试只是查验开发人员的代码是如何运行的。而提前的测试可以帮助开发人员立刻得到正确的错误定位。

在测试先于编码的情况下,开发人员可以在一完成编码时就立刻进行测试。而且,她会更有效率,在同一时间内能够执行更多的现成的测试,她的思路也不会因为去搜集测试数据而被打断。

   

    即使是最好的程序员,从他们各自的观念出发,也常常会对一些看似非常明确的设计说明产生不同的理解。如果他们能参考到测试的输入数据及输出结果要求,就可以帮助他们及时纠正理解上的误区,使其在一开始就编写出正确的代码。

前置测试定义了如何在编码之前对程序进行测试设计,开发人员一旦体会到其中的价值,就会对其表现出特别的欣赏。前置方法不仅能节省时间,而且可以减少那些令他们十分厌恶的重复工作。

 
  • 0
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 2
    评论
主要讲述了计算机系统的开发领域。在每章的漂亮代码都是来自独特解决方案的发现,而这种发现是来源于作者超越既定边界的远见卓识,并且识别出被多数人忽视的需求以及找出令人叹为观止的问题解决方案。 本书介绍了人类在一个奋斗领域的创造性和灵活性:计算机系统的开发领域。在每章的漂亮代码都是来自独特解决方案的发现,而这种发现是来源于作者超越既定边界的远见卓识,并且识别出被多数人忽视的需求以及找出令人叹为观止的问题解决方案。 本书33章,有33位作者,每位作者贡献一章。每位作者都将自己心目对于“美丽的代码”的认识浓缩在一章当,张力十足。33位大师,每个人对代码之美都 有自己独特的认识,现在一览无余的放在一起,对于热爱程序的每个人都不啻一场盛宴。 虽然本书的涉猎范围很广,但也只能代表一小部分在这个软件开发这个最令人兴奋领域所发生的事情。 本书收录的是软件设计领域的一组大师级作品。每一章都是由一位或几位著名程序员针对某个问题给出的完美的解决方案,并且细述了这些解决方案的巧妙之处。 本书既不是一本关于设计模式的书,也不是一本关于软件工程的书,它告诉你的不仅仅是一些正确的方式或者错误的方式。它让你站在那些优秀软件设计师的肩膀上,从他们的角度来看待问题。 本书给出了38位大师级程序员在项目设计的思路、在开发工作的权衡,以及一些打破成规的决策。 第1章 正则表达式匹配器 。 1.1 编程实践 1.2 实现 1.3 讨论 1.4 其他的方法 1.5 构建 1.6 小结 第2章 Subversion的增量编辑器:像本体一样的接口 2.1 版本控制与目录树的转换 2.2 表达目录树的差异 2.3 增量编辑器接口 2.4 但这是不是艺术? 2.5 像体育比赛一样的抽象 2.6 结论 第3章 我编写过的最漂亮代码 3.1 我编写过的最漂亮代码 3.2事倍功半 3.3 观点 3.4 本章的心思想是什么? 3.5 结论 3.6致谢 第4章 查找 4.1. 耗时 4.2. 问题:博客数据 4.3. 问题:时间,人物,以及对象? 4.4. 大规模尺度的搜索 4.5. 结论 第5章 正确、优美、迅速(按重要性排序):从设计XML验证器学到的经验 5.1 XML验证器的作用 5.2 问题所在 5.3 版本1:简单的实现 5.4 版本2:模拟BNF语法——复杂度O(N) 5.5 版本3:第一个复杂度O(log N)的优化 5.6 版本4:第二次优化:避免重复验证 5.7 版本5:第三次优化:复杂度 O(1) 5.8 版本 6:第四次优化:缓存(Caching) 5.9 从故事学到的 第6章 集成测试框架:脆弱之美 6.1. 三个类搞定一个验收测试框架 6.2. 框架设计的挑战 6.3. 开放式框架 6.4. 一个HTML解析器可以简单到什么程度? 6.5. 结论 第7章 美丽测试 7.1 讨厌的二分查找 7.2 JUnit简介 7.3将二分查找进行到底 7.4 结论 第8章 图像处理的即时代码生成 第9章 自顶向下的运算符优先级 9.1. JavaScript 9.2. 符号表 9.3. 语素 9.4. 优先级 9.5. 表达式 9.6. 置运算符 9.7. 前置操作符 9.8. 赋值运算符 9.9. 常数 9.10. Scope 9.11. 语句 9.12. 函数 9.13. 数组和对象字面量 9.14. 要做和要思考的事 第 10章 追求加速的种群计数 10.1. 基本方法 10.2. 分治法 10.3. 其他方法 10.4. 两个字种群计数的和与差 10.5. 两个字的种群计数比较 10.6. 数组的1位种群计数 10.7. 应用 第11章 安全通信:自由的技术 11.1 项目启动之前 11.2剖析安全通信的复杂性 11.3 可用性是关键要素 11.4 基础 11.5 测试集 11.6 功能原型 11.7 清理,插入,继续…… 11.8 在喜马拉雅山的开发工作 11.9 看不到的改动 11.10 速度确实重要 11.11 人权的通信隐私 11.12 程序员与文明 第12章 在BioPerl里培育漂亮代码 12.1. BioPerl和Bio::Graphics模块 12.2. Bio::Graphics的设计流程 12.3. 扩展Bio::Graphics 12.4. 结束语和教训 第13章 基因排序器的设计 13.1 基因排序器的用户界面 13.2 通过Web跟用户保持对话 13.3. 多态的威力 13.4 滤除无关的基因 13.5 大规模美丽代码理论 13.6 结论 第14章 优雅代码随硬件发展的演化 14.1. 计算机体系结构对矩阵算法的影响 14.2 一种基于分解的方法 14.3 一个简单版本 14.4 LINPACK库的DGEFA子程序 14.5 LAPACK DGETRF 14.6递归LU 14.7 ScaLAPACK PDGETRF 14.8 针对多核系统的多线程设计 14.9 误差分析与操作计数浅析 14.10 未来的研究方向 14.11 进一步阅读 第15章 漂亮的设计会给你带来长远的好处 15.1. 对于漂亮代码的个人看法 15.2. 对于CERN库的介绍 15.3. 外在美(Outer Beauty) 15.4. 内在美(Inner Beauty ) 15.5. 结论 第16章,Linux内核驱动模型:协作的好处 16.1 简单的开始 16.2 进一步简化 16.3 扩展到上千台设备 16.4 小对象的松散结合 第17章 额外的间接层 17.1. 从直接代码操作到通过函数指针操作 17.2. 从函数参数到参数指针 17.3. 从文件系统到文件系统层 17.4. 从代码到DSL(Domain-Specific Language) 17.5. 复用与分离 17.6.分层是永恒之道? 第18章 Python的字典类:如何打造全能战士 18.1. 字典类的内部实现 18.2. 特殊调校 18.3. 冲突处理 18.4. 调整大小 18.5. 迭代和动态变化 18.6. 结论 18.7. 致谢 第19章 NumPy的多维迭代器 19.1 N维数组操作的关键挑战 19.2 N维数组的内存模型 19.3NumPy迭代器的起源 19.4 迭代器的设计 19.5 迭代器的接口 19.6 迭代器的使用 19.7 结束语 第20章 NASA火星漫步者任务的高可靠企业系统 20.1 任务与CIP 20.2 任务需求 20.3 系统架构 20.4 案例分析:流服务 20.5 可靠性 20.6 稳定性 20.7 结束语 第21章 ERP5:最大可适性的设计 21.1 ERP的总体目标 21.2 ERP5 21.3 Zope基础平台 21.4 ERP5 Project的概念 21.5 编码实现ERP5 Project 21.6 结束语 第22章 一匙污水 第23章 MapReduce分布式编程 23.1 激动人心的示例 23.2 MapReduce编程模型 23.3 其他MapReduce示例 23.4 分布式MapReduce的一种实现 23.5 模型扩展 23.6 结论 23.7 进阶阅读 23.8 致谢 23.9 附录:单词计数解决方案 第24章 美丽的并发 24.2 软件事务内存 24.3 圣诞老人问题 24.4 对Haskell的一些思考 24.6 致谢 第25章 句法抽象:syntax-case 展开器 25.1. syntax-case简介 25.2. 展开算法 25.3. 例子 25.4. 结论 第26章 节省劳动的架构:一个面向对象的网络化软件框架 26.1 示例程序:日志服务 26.2 日志服务器框架的面向对象设计 26.3 实现串行化日志服务器 26.4 实现并行日志服务器 26.5 结论 第27章 以REST方式集成业务伙伴 27.1 项目背景 27.2 把服务开放给外部客户 27.3 使用工厂模式转发服务 27.4 用电子商务协议来交换数据 27.5 结束语 第28章 漂亮的调试 28.1 对调试器进行调试 28.2 系统化的过程 28.3 关于查找的问题 28.4 自动找出故障起因 28.5 增量调试 28.6 最小化输入 28.7 查找缺陷 28.8 原型问题 28.9 结束语 28.10 致谢 28.11 进一步阅读 第29章 把代码当作文章 第30章 当你与世界的联系只有一个按钮 30.1 基本的设计模型 30.2 输入界面 30.3 用户界面的效率 30.4 下载 30.5 未来的发展方向 第31章 Emacspeak:全功能音频桌面 31.1 产生语音输出 31.2 支持语音的Emacs 31.3 对于在线信息的简单访问 31.4 小结 31.5 致谢 第32章 变动的代码 32.1 像书本一样 32.2 功能相似的代码在外观上也保持相似 32.3 缩进带来的危险 32.4 浏览代码 32.5 我们使用的工具 32.6 DiffMerge的曲折历史 32.7 结束语 32.8 致谢 32.9 进一步阅读 第33章 为“The Book”编写程序 33.1 没有捷径 33.2 给Lisp初学者的提示 33.3 三点共线 33.4 不可靠的斜率 33.5 三角不等性 33.6 河道弯曲模型 33.7 “Duh!”——我的意思是“Aha!” 33.8 结束语 33.9 进一步阅读 后记

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值