模板
教程
环境
性能
功能
管理
软件测试设计与软件测试管理
然而，针对于某个特定的软件项目而言，测试团队应该如何合理地统筹安排软件测试工作？测试团队在完成一定数目软件项目的测试工作后又该如何快速提升下一软件项目测试工作的水平？这两个问题对于刚成立或成立不久的软件测试团队而言是很棘手也是很现实的。前者关乎软件测试设计，属于“近忧”；后者关于软件测试管理，属于“远虑”。本文的写作目的，正是试图为这些测试团队的负责人“排忧解难”，提供决策参考性意见。
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 测试用例设计
测试用例设计是对测试方案实现技术部分更为细致描述，相关设计技术已经相对成熟[注：目前测试用例设计的某些分支仍是研究热点]。市面上，关于测试用例的理论著作也是琳琅满目。下表列出了各类测试用例设计技术，在本文中笔者不打算一一介绍，而是根据测试实践和个人取向，选出了几个有代表性的方法，供读者参考。有兴趣的读者，可以进一步查阅论述更细致一些的书籍。
|
MILY: 宋体">项目与类别 |
黑盒测试（功能性） |
白盒测试（结构性） |
其他 |
|
共同点 |
参考单元接口和功能描述规格文档，不需了解被测单元的内部结构； |
参考详细设计规格文档，对照代码，测试被测单元内部如何工作的； |
强调个人经验，采用猜测或选测选择特殊值的方法。 |
|
具体类别 |
软件设计导出的测试 等价类划分 边界值分析 判定表驱动测试 因果图 基于状态的测试 …… |
路径测试 控制结构测试 逻辑覆盖 程序插装 …… |
错误猜测 特殊值测试 |
其中，黑盒测试中常用的等价类划分方法用例设计思想如下：
先把程序的输入域划分成若干区间，然后从每个区间中选取少数代表性数据当作测试用例。由于数量太大，穷举测试一般情况下不可能实现，因此我们往往仅从大量可能的数据中选取一部分有代表性作为测试用例。在使用等价类划分方法时，通常会涉及到两种等价类：有效等价类和无效等价类。顾名思义，有效等价类就是对程序的规格说明是有意义的合理的输入数据集；无效等价类就是对程序规格说明书不合理或无效的输入数据集。我们在设计测试用例时，要兼顾这两种情况。同时要注意一个测试用例只能覆盖一个无效等价类。这样便于错误定位，防止一个错误表征掩盖了另一个错误。例如，程序的规格说明中规定了“……每类科技图书10至50册，……”，若一个测试用例为“小说5册”，在测试中很可能只检测出书的类型错误（小说不是科技类图书），而忽略了书的册数错误（5不在10至50之间）。
黑盒测试中另一个常用的测试用例设计方法是边界值分析。它的思想如下：
边界值分析是一种补充等价类划分的测试用例设计技术，它选择一组测试用例检查边界值是否符合相应规格说明。因为输入域的边界比中间更加容易发生错误，所以我们引进了边界值分析方法往往能发现更多的软件缺陷和错误。
使用边界值分析的步骤为：选择等价类的边界值－>从输入域导出测试用例。
【例子】a是实数，在10到100之间，请使用边界值分析的方法设计测试数据。
测试数据为：9.9、10.1、20、99.9、100.1。
不管黑盒测试多么全面，它都可能忽略类似于逻辑性错误、潜在破坏性执行流程、冗余程序代码乃至于简单打字错误等，而白盒测试则可以进一步发现它们，查找出代码层次的错误和缺陷。白盒测试用例设计包括的门类相当繁多，这里笔者仅介绍路径测试方法。
在设计路径相关测试用例前，应首先分析程序的内在逻辑结构：查找程序的执行入口，然后跟踪程序体中经历的各个分支语句及判断语句，直到程序的出口。然后针对于每个分支及判断语句，均设置一个不同情况的测试用例，并向下依序遍历递归，生成更细的子用例，直至程序结束或抵达出口。细心的读者可能会发现，这种方法实际上是程序体中分支与判断语句各种可能情况的排列与组合。对于小的程序模块而言，这是可行的，然而，对于较为复杂的程序模块（尤其是对面向对象语言中频繁使用的异常与消息捕获时机而言）这种方法收效甚微。因此从该方法衍生出了很多变种，如功能点覆盖、语句覆盖等方法。这些方法对于设计白盒测试用例，均有较好的参考价值。
