软件测试设计与软件测试件管理
越来越多的软件企业已经意识到了软件测试在软件质量管理工作中的重要位置，并开始着手组建自己的软件测试团队。这对于软件产品质量的提升以及企业的中长期发展而言，无疑具有深远的促进
意义。
然而，针对于某个特定的软件项目而言，测试团队应该如何合理地统筹安排软件测试工作？测试团
队在完成一定数目软件项目的测试工作后又该如何快速提升下一软件项目测试工作的水平？这两个
问题对于刚成立或成立不久的软件测试团队而言是很棘手也是很现实的。前者关乎软件测试设计，
属于“近忧”；后者关乎软件测试件管理，属于“远虑”。本文的写作目的，正是试图为这些测试团队
的负责人“排忧解难”，提供决策参考性意见。
1、做好软件测试设计，排除“近忧”
正如上文所言，测试团队建立伊始，就会碰到这么一个问题：“应该如何合理地统筹安排软件测试
工作”？测试技术林林总总，过度测试会造成项目的测试成本上升，而测试不够又会造成项目中遗
留某些重要的缺陷。一些企业的测试主管曾私下向我咨询过此类问题，我觉得这可能带有一定的普
遍性。的确，针对于某个特定的软件项目量身定做相应的软件测试方案是需要足够的技术能力和实
战经验的。一些资历尚浅的测试团队需要在这方面获得帮助，以解燃眉之急。
要回答这个问题，我们必须先从“软件测试活动的生命周期”开始谈起。一个典型的软件测试活动的
生命周期大致可以分为“测试计划 à 测试设计 à 测试执行 à 测试总结与改进”四个环节[注：也有些技
术文章在测试设计环节后增加了一个环节：测试环境搭建，笔者认为这也是一种可取的划分方法]。
其中，测试计划环节要对具体的测试活动给出宏观的指导与预算，具体内容包括：1.定义开发团队
和用户对于测试工作的需求项；2.定义测试可能会经历的阶段、测试类型、测试大致会采用的技术
及工具、测试通过的标准等等；3.确定测试协作需求。如需要临时聘用的专家、测试进度与开发进
度协调、测试活动与用户存在接口关系的计划安排等等；4.粗略估计测试需要的工作量。可根据同
类项目的数据进行模拟逼近，也可以根据某个算法，从项目规模导出；5.确定测试活动需要配备的
资源（如人、场地、软硬件等等）。测试设计环节则是在“测试计划”环节的基础上进一步细化和分
析，从而制定出针对于该项目及每个测试活动的测试策略、测试方案及测试用例的过程。通常，这
一部分工作对测试人员提出的素质要求是相当高的，也是最不易把握的部分，下文将有详细的论述。
测试执行是按照测试设计产生的输出，执行相应的测试活动，查找并报告相应错误和缺陷的过程，
当然，也包括某些不使用测试用例的开放式测试，如GUI测试等等。测试总结与改进则是完成以上
三个环节的基础上收集各环节产生的相关测试件（如测试文档、测试脚本、测试工具及测试工作经
验教训等等），纳入测试团队知识库，以便于测试团队更好地进行测试件管理，从而推动测试工作
的不断优化与改进。
上面对测试活动的生命周期做一个简要的介绍。需要提醒注意的是某些概念在特定的领域可能含义
稍有差异。如在某些大型项目的测试活动中，测试计划环节产生的文件是《测试大纲》以及高层《
软件测试计划》，而在测试设计环节产生的文件是针对于某个系统、某个模块的底层《测试计划》、
测试方案等等。这些差异并不影响本文对测试设计及测试件管理的讨论。
有了前面的铺垫，我们就可以开始讨论软件测试设计这个大难题了。测试设计实际上是对高层测试
计划（含测试大纲）进行进一步细化、具体化从而形成针对于特定项目的测试策略、测试方案及
测试用例的过程。
1.1测试策略设计
测试策略要解决的问题是根据测试需求、资源配备及工程环境，因地制宜剪裁测试技术，形成测试
工作的技术路线。我们知道，对于一个小项目做大测试是得不偿失的，同样，对一个大项目做小测
试也是不负责任的。或者更专业一点，对于工作量小于5个人月的普通商用软件，重点应该抓系统测
试（包括功能测试、性能测试及GUI测试等）及验收测试，而不宜铺排开来，面面俱到（如设计验证
与确认、代码评审及单元测试可以视情况压缩）。而对于一个工作量接近30个人月的中型商用软件
而言，一般应该认真完成需求验证、设计验证、单元测试、集成测试、系统测试及验收测试，而不
宜只关注系统测试，忽略其它部分。以上讨论是以人月数为参照系的，这并不绝对。譬如，用户需
求就常常是更重要的考虑因素，如用户希望软件有好的人机交互界面，这时，就应该考虑采用快速
原型生成工具来进行用户界面设计的确认测试，又如用户希望软件有较好的健壮性，这时，就应该
考虑进行相应的负载测试和可恢复性测试。除此之外，资源配备也是很重要的考虑因素。一个团队
成员寥寥无几的测试团队，要承担一个中型项目的软件测试工作，这几乎是不可能的。然而，个别
企业的高层出于成本考虑或技术上的不敏感可能会分派出此类不可实现的任务。这时，消极应付是
下策，要充分利用测试外包、测试协作（如从其他部门借调人员）等多种形式，把优先级相对较低
的部分甩出去，留下最核心的、优先级最高的部分，组织测试人员进行专业的测试。
测试策略设计本质上是一门艺术，因为它是测试经验积累与特定项目工程实际交互作用下的“厚积薄
发”，是多个因子（测试需求、测试资源配置、项目规模、类似项目测试策略参考等）综合作用的
结果。要做好测试策略的设计工作，是非常不容易的事情。一个好的测试策略设计应能清楚地回答
下列问题：（1）是否在测试成本与测试预期效果之间达到了最佳平衡？（2）是否在测试需求与测
试活动安排之间达到了最佳平衡?（3）策略设计形成的技术路线是否在工程实际与企业质量承诺之
间达到了最佳平衡？（4）策略设计形成的技术路线是否具有可行性？有无设计依据？等等。对于资
历较浅的测试团队而言，可能在团队建设早期尚难以达不到这种境界。不过也无需过于担心和忧虑，
随着不同项目测试经验的积累，以及测试团队测试件管理工作的深入，很多障碍会逐步消除，从而
最终达到“胸中有丘壑”的境界。
1.2测试方案设计
经过测试策略设计，形成了针对特定项目的测试工作技术路线，下一步测试团队就进到了测试方案
的设计阶段。测试方案是对技术路线的进一步细化。如某一技术路线规定了某小型软件项目测试工
作要重点围绕 “功能测试与验收测试”展开。那么测试方案设计阶段就必须具体定义哪些功能需要被
测试到以及如何去测试，哪些部分（软件？用户手册？操作指南）需要做验收以及采用什么形式去
做验收测试（评审会？Beta测试?还是现场测试?等等）。
测试方案的设计要除了要明确定义各个测试活动的对象、执行人员、测试进度、放行标准等一系列
属性外，还要充分考虑到成本与技术可行性。一个好的测试方案总是遵循着以下设计原则：(1) 测试
成本与测试工作产生的效益处于最佳比值；（2）各具体测试活动描述清晰，目标明确，内容完备；
（3）测试手段是可行的；（4）测试产生的结果是可以用于指导产品质量改进的。笔者注意到一些
企业对于第（3）点存在认识上的误区，盲目购置的一批自动化测试工具，却无人懂操作，或者根本
就不适合自己的开发环境。这些问题在测试方案设计过程中应该努力避免的。
在进行测试方案的具体设计时，常常也暴露出来一些难题和障碍。最常见的就是角色安排多，测试
人员少。解决这一问题的根本途径是招募测试人才，建设高效测试团队。然而，远水解不了近渴。
如果你的测试团队遭遇到此类尴尬，那么，你就需要考虑一下变通之策：前面提到的外包和外协都
是不错的处理办法。另外，建议你适当考虑自动测试工具，某些工具的确能减少你的工作压力（如
自动集成工具能实现每日建构、压力测试工具能缓解你编写模拟并发程序的压力）。除了人手的问题，
了解你所在的测试团队各成员的专业技能也是很重要的。有些项目测试方案设计得很好，但由于缺乏
相应素质的测试团队成员担当测试方案中的相应角色，测试方案只能无限期搁浅，结果不了了之。除
此之外，测试方案设计人员还应多多参考软件开发管理类文档，在测试的时间进度安排上与开发保持
同步，如果开发进度有变动，应及时调整相应的测试进度安排。
1.3测试用例设计
测试用例设计是对测试方案实现技术部分更为细致描述，相关设计技术已经相对成熟[注：目前测试
用例设计的某些分支仍是研究热点]。市面上，关于测试用例的理论著作也是琳琅满目。下表列出了
各类测试用例设计技术，在本文中笔者不打算一一介绍，而是根据测试实践和个人取向，选出了几
个有代表性的方法，供读者参考。有兴趣的读者，可以进一步查阅论述更细致一些的书籍。
项目与类别
黑盒测试（功能性）
白盒测试（结构性）
其他
共同点
参考单元接口和功能描述规格文档，不需了解被测单元的内部结构；
参考详细设计规格文档，对照代码，测试被测单元内部如何工作的；
强调个人经验，采用猜测或选测选择特殊值的方法。
具体类别
软件设计导出的测试
等价类划分
边界值分析
判定表驱动测试
因果图
基于状态的测试
……
路径测试
控制结构测试
逻辑覆盖
程序插装
……
错误猜测
特殊值测试
其中，黑盒测试中常用的等价类划分方法用例设计思想如下：
先把程序的输入域划分成若干区间，然后从每个区间中选取少数代表性数据当作测试用例。由于数
量太大，穷举测试一般情况下不可能实现，因此我们往往仅从大量可能的数据中选取一部分有代表
性作为测试用例。在使用等价类划分方法时，通常会涉及到两种等价类：有效等价类和无效等价类
。顾名思义，有效等价类就是对程序的规格说明是有意义的合理的输入数据集；无效等价类就是对
程序规格说明书不合理或无效的输入数据集。我们在设计测试用例时，要兼顾这两种情况。同时要
注意一个测试用例只能覆盖一个无效等价类。这样便于错误定位，防止一个错误表征掩盖了另一个
错误。例如，程序的规格说明中规定了“……每类科技图书10至50册，……”，若一个测试用例为“小说
5册”，在测试中很可能只检测出书的类型错误（小说不是科技类图书），而忽略了书的册数错误（
5不在10至50之间）。
黑盒测试中另一个常用的测试用例设计方法是边界值分析。它的思想如下：
边界值分析是一种补充等价类划分的测试用例设计技术，它选择一组测试用例检查边界值是否符合相
应规格说明。因为输入域的边界比中间更加容易发生错误，所以我们引进了边界值分析方法往往能
发现更多的软件缺陷和错误。
使用边界值分析的步骤为：选择等价类的边界值－>从输入域导出测试用例。
【例子】a是实数，在10到100之间，请使用边界值分析的方法设计测试数据。
测试数据为：9.9、10.1、20、99.9、100.1。
不管黑盒测试多么全面，它都可能忽略类似于逻辑性错误、潜在破坏性执行流程、冗余程序代码乃至
于简单打字错误等，而白盒测试则可以进一步发现它们，查找出代码层次的错误和缺陷。白盒测试用
例设计包括的门类相当繁多，这里笔者仅介绍路径测试方法。
在设计路径相关测试用例前，应首先分析程序的内在逻辑结构：查找程序的执行入口，然后跟踪程序
体中经历的各个分支语句及判断语句，直到程序的出口。然后针对于每个分支及判断语句，均设置一
个不同情况的测试用例，并向下依序遍历递归，生成更细的子用例，直至程序结束或抵达出口。细心
的读者可能会发现，这种方法实际上是程序体中分支与判断语句各种可能情况的排列与组合。对于小
的程序模块而言，这是可行的，然而，对于较为复杂的程序模块（尤其是对面向对象语言中频繁使用
的异常与消息捕获时机而言）这种方法收效甚微。因此从该方法衍生出了很多变种，如功能点覆盖、
语句覆盖等方法。这些方法对于设计白盒测试用例，均有较好的参考价值。
2、做好软件测试件管理，消除“远虑”
如何有效地管理好测试件，是影响测试团队效率与整体水平的重要因素之一。在待测项目规模小、
功能点少的情况下，测试工作或许能正常进行，但如果测试团队要同时测试多个项目，各项目规模
都相对较大，涉及的测试人员较多，在此情况下，测试工作的效率可能会大为降低：如，测试人员
在进行自动化测试时，发现测试脚本、测试数据与待测程序的版本有时根本不匹配，或者发现很多
缺陷报告实际上是重复的，等等。这些典型的低效率事件多半是由测试件管理工作的低效引起的。
除此之外，测试件管理对于团队的整体水平提高亦具有不可估量的长远意义。如果某个测试团队完
成一个项目的测试工作后不做分析、总结，不将有代表的测试用例、测试方案等等积累起来，那么
这个团队可能会长时间在一个较低的水平上徘徊，无法将类似项目的测试件迁移到当前项目中来，
测试团队的新成员也无法通过测试件管理库中获取前人已有的知识积累。
那么，测试团队该如何做好测试件管理？在谈这个问题之前，先要弄明白测试件这个概念。在本文
中，测试件泛指一切手工测试和自动测试活动中必须受控或值得纳入测试团队知识库的所有输入和
输出数据（包含团队自主开发的测试自动化工具）。它的外延可用下图表示：
测试件
测试输入
测试输出
测试大纲测试计划
测试用例测试脚本
方案策略规范文档
测试工具
测试记录
测试总结
测试结果
缺陷报告
测试工作日志
测试分析数据
测试评估数据
项目经验与教训
上述测试件中，已经较好地实现了自动化管理的有：测试用例自动化管理、测试缺陷（报告）跟踪
管理。除此之外的测试件目前尚未发现有对应的专用管理工具，笔者建议采用配置管理工具（如C
VS）来完成对它们的自动化管理。下面，笔者将简单介绍一下这些自动化管理工具。[由于测试缺陷
跟踪管理在第二专题已有详细的论述，这部分内容本文从略。]
2.1测试用例管理系统
一个中等规模的待测软件，需要设计的测试用例往往有数万个之多，如果不进行专门的管理，测试人
员很快就被淹没在测试文档及测试用例的海洋中。测试用例设计人员需要了解目前已经设计了哪些模
块或部件的测试用例，还需要完成哪些模块或部件测试用例的设计工作，而测试执行人员需要明确地
被告知“今天我要测试什么？需要执行多少个测试用例？”等等。基于这些需求，人们开发了测试用
例管理系统。使用这个系统的目的是为了对项目的测试用例的设计、执行及执行结果进行统一管理，
提高测试活动的效率。
测试用例管理系统市面上有很多（如微创测试用例管理系统等），有需要的读者可以在完成市场调研
的基础上选择购买。笔者这里只简单介绍测试用例管理系统的大致流程。
一个典型的测试用例管理系统采用如下工作流程：设置基本参数→登录系统→选择项目→新增模块
节点→新增需求→新增测试用例→审核测试用例→新增测试组→新增测试计划→执行测试→测试结
果查看→统计分析。该流程涉及到的角色包括测试组长、测试设计人员、测试执行人员、系统管理
员、测试评审员等等。其中，测试设计人员拥有写入测试用例的权限，测试执行人员负责测试用例
的执行，这二者是测试用例管理系统的主体。
2.2配置管理
除测试用例、测试缺陷报告之外的测试件均可以使用配置管理的方式进行管理。这里有两个可选择
的配置管理方式。
一种是将测试件的逻辑集合（称为测试件组）作为配置项保存在配置库中（即将测试件组打包成为一
个文件）。每个测试件组有自己的版本信息，而组成测试件组的各个测试件没有自己的版本信息。
测试人员可以根据需要随时从配置库中取出任何版本的测试件组（包含已修改的和未修改的测试件
）。因为这种方式操作简单，并且出现错误版本测试件的可能性比较小，所以它适用于配置管理体
系不成熟或者刚刚启用的情况。
另一种方式是把单个的测试件作为配置项，每个测试件有自己的版本信息。这种方式需要在测试件
组或多个测试件组上进行基线化。通过基线化操作，方便测试人员能取出对应于不同版本系统的所
有测试件。这种方式如果使用不当，可能导致使用的测试件版本错误，所以这种方式适用于有较完
善的配置管理体系的情况。
不管我们采用上面提到的哪种方式进行配置管理，我们都要注意控制测试件的更新。如果配置管理
体系不是很完善的话，那么就设置一些简单的规则，避免两个或更多的人同时试图修改同一配置项。
关于测试件的存放，需要注意的是，必须规定好各测试件在配置库中的物理位置。如采用的是第一
种管理方式，就需要规定好测试件在各测试件组中的目录层次，以避免在文件复制、移动时，产生
不必要的重构。
2.3测试件的复用与迁移
测试件管理工作的另一个更为重要的价值就在于测试件可以被复用，测试件蕴含的经验和知识可以
被后来者获取并迁移到当前项目中。测试团队的整体水平的提高很大程度上在于团队内部知识传递
的充分有效。由于测试件管理库记载了各个项目采用的测试技术以及获得的经验教训，这对于团队
中的新手而言，是很宝贵的资源，即便是对于从业多年的老手来说，也应该多多参考这个知识库，
因为测试件的复用能有效规避重复劳动。另外，建议测试团队负责人通过多种方式，让团队成员多
多了解、学习和利用测试件库，鼓励团队成员对测试件提出改进意见。
页:
[1]
