你要对系统中
哪个部分先进行测试？前置测试模型可以帮助你优化这些次序
管理项目级计划并驾驭项目风险
虽然大多数人都认同模型重要性但在开发周期中测试模型并没有受到应有关注V模型是最广为人知测试模型不过很多测试人员仍对V模型不是很了解V模型还受到很多质疑其中Brian Marick(
The Craft of Software Testing9 (Prentice Hall, 1995)
书作者就曾对V模型提出过些中肯批评在本系列第 2篇中我们讨论了X模型该模型覆盖了Marick意见并由此形成了个相适测试模型而在第篇中我们已经讨论了V模型在第 3篇文章中我们将V模型和X模型相结合提出了前置测试模型该模型沿用了前者长处同时又尽量弥补了前者不足在本文中我们将介绍说明实行“测试驱动开发”所能带来益处前置测试
计划附图“
个复杂标准”描述是IEEE标准829-1998中提供测试计划概念性结构然而些批评家曾认为该标准并不切合实际情况仅仅是书面出版物而已![](\"/A-A-B/Image/2005/08/1203/testdriven4-1.g<img)
\" width=\"500\" alt=\"\"/>图1
个复杂文档计划结构从图中可以看到
该标准将测试计划分为多个区别层次其中也包括个人文档部分这些文档可以作为整个较大规模文档即单独测试计划(例如单元测试计划)组成部分而主测试计划则最终可以成为项目计划个组成部分我们将逐层往下看
并探讨下这些层次是否真对我们工作有帮助主测试计划组合了
整套测试计划该计划主要考虑是系统作为个整体时必须正常运作通常在个分计划(详细计划)中应描述相应单元测试、集成测试、特殊测试及系统测试其中特殊测试是种综合性测试而并不是被应用所驱动那种测试可以是诸如压力测试、安全性测试或者可用性测试等等相应地在各分测试计划中分别组合了各自套性能或功能以确保相关单元测试、集成测试、特殊测试及系统测试内容能够正常运作对于每个性能和功能来说份测试设计介绍说明可以对如何验证其正常运作进行了描述每份测试用例设计介绍说明都要标明相关性能或功能是如何工作测试计划结构带来了很多
益处虽然很多测试人员认为IEEE标准提供了大量冗余文档这些文档并没有太多价值但我们并不这么认为我们并不反对象X模型中所提倡写完即交付测试计划文档但我们更提倡记录重要测试计划信息并将其作为容易记忆内容进行充分共享和重复利用以及对其进行持续改进对很多人来说
测试计划主要是对测试用例收集整理但收集起来后文档可能会变得很大很难进行管理其实从图中可以看到标准结构可以帮助组织和管理测试用例由此也体现了该结构所具有直接价值我们应提前定义好可重用
测试设计介绍说明确定如何在通用情形下进行测试这些介绍说明可以防止大量重复工作使我们能顺利开展可靠测试而不至于造成时间上延误同样地该结构可以帮助我们定义好可重用测试用例及可选择资源分配另外该结构和测试设计介绍说明将有助于在必要时候重复创建测试用例前置内容
优先级划分风险
优先级划分是任何测试思路方法个组成部分在V模型和X模型中却都没有进行明确定义而我们使用前置风险分析思路方法则要比我们所见过其它思路方法都有效得多前置测试可以从2个途径来改进测试
其传统思路方法般会把风险定位到每个测试上由于没有对比因此每项测试都成了高风险有了前置测试计划结构后就可以很快地揭示可选项这样即可从选项中区分其优先级别其 2我们可以排除那些常用评定测试风险等级技术显然对于那些被忽略测试不会有风险加到这些测试上面但忽略这些测试本身常常就是最大风险相应地前置风险分析可以使我们确定传统思路方法所忽视紧要风险然后定义好有关测试以避免这些风险出现当我们在各个区别层次上使用前置测试计划时候其中最重要任务就是在主测试计划中列入项目级风险识别及其处理优先级排定特别要指出是这前置技术可以帮助我们预见到很多常见突发事件其实每个开发人员都能列举出很多使项目停顿意想不到事件而且这些事件往往是发生在项目实施前后在和
个项目团队(Team)协同工作时我们总是可以发现他们直在试图使用前置风险分析思路方法来确定大量潜在突发事件而有关报告指出传统项目和测试计划往往会忽视多达75%突发事件旦我们确定了风险并对风险划分了优先级别我们就可以定义哪些系统部分需要优先进行测试这些部分往往和组织中原先计划好次序有所区别然而通常开发计划目是要开发整个
所以常常会以工作执行顺序来做计划而前置测试模型定义了出现在高风险区系统部件--单元或集成测试让测试驱动开发就要优先对这些部分进行开发优先创建并测试这些高风险
部分可以帮助开发人员在付出额外劳动的前就能抓住问题所在如果能对特殊测试给予应有重视则效果将会更好特殊测试还有益于详细测试结果致性这比在系统测试 (例如负载测试和安全性测试)中进行更好另外风险分析还可以避免忽略其它测试(例如培训、文档和操作示范测试)这样每次创建可以包含传统思路方法需要同时通过单元、集成和系统测试后才能包含成分个基本A-B-C例子为了感受
些测试驱动开发模式让我们看个简单例子假设我们有个系统包含了A、B和C 3个系统按A-B-C顺序执行表面上看开发和测试可能都会以同样顺序进行但是
我们风险分析揭示B和C的间集成会产生最大风险因此B和C应该首先创建并优先进行单元测试由于在B和C中发现问题可能会影响到A所以在A开发的前发现这些问题可以有助于避免A中某些部分重写下
个高风险是A中通讯能力在传统方式开发计划中我们会将A作为个整体进行开发然后进行单元测试但作为个整体来看A可能很庞大比较难以进行测试查找问题和修改
因此我们可以将A分成为2个单元其中个专门处理通讯功能另个则处理剩余其它功能这样我们就可以更快地针对通讯能力进行测试同时其它问题也相对更容易被发现和修改
接着
我们需要对A2个组成部分进行集成测试以确保这2个部分能正确地组合在起最后既然B-C以及A内部组成部分集成测试已经完成我们可以引入并处理第 3个风险即对全部3个集成所进行测试需要注意
是前置测试模型并没有规定测试要按怎样特定顺序来进行它可以指导我们基于每个项目特殊性来排定开发和测试计划由此可以快速而低成本地达到项目预期结果:高质量软件Software使用过前置测试模型
开发人员可以很快地想起该思路方法曾帮助他们避免问题固有优越性他们也知道这些问题常常就是项目延期、超预算主要原因当项目经理(project manager)和开发人员意识到前置测试是如何帮助他们认识到那些风险及其规避思路方法时候他们将欣然接纳具备如此多内在价值前置测试所带给他们满意成果
最新评论