| 高可靠性软件测试方案探讨 | ||||||||||||||||||||||||||||||||||
| 作者：戴金龙 文章来源：codesky | ||||||||||||||||||||||||||||||||||
|
[摘要] 随着软件系统规模和复杂度日益升高，越来越多的软件项目明确提出软件的可靠性要求。而涉及高可靠性软件开发的软件企业也越来越意识到，软件测试在这些项目开发过程中绝不是一种辅助性工作，而是从软件质量控制角度保证软件工程过程质量的最有效方法。有鉴于此，本文以CraftGS航天项目模型为例，系统地介绍了一套行之有效的软件测试方案，该方案对同类高可靠性软件项目测试工作的开展具有一定的参考意义和指导作用。 1 引言 高可靠性软件泛指一类软件：该类软件运行过程中若出现故障会引发重大灾难性事故或经济损失。通常航天型号软件、银行系统软件、医疗行业软件、通讯行业软件等均属此范畴。目前，越来越多的软件企业涉及高可靠性软件项目，如何保证软件质量成为众多企业面临的一个很重要的课题。这篇文章结合某航天项目地面应用系统模型（本文命名为 CraftGS ），重点讨论如何从软件测试的角度保证此类产品的软件质量。 2 CraftGS 项目简介 CraftGS 是一个很经典的卫星地面应用系统模拟项目。它分为 5 个子系统：数据接收子系统 (DAS) 、数据预处理子系统 (DPS) 、运行管理子系统 (OMS) 、数据管理子系统 (DMS) 以及数据产品实现 (DPRS) 子系统。 CraftGS 的总体可靠度要求是 0.95 。各分系统分配到的可靠度指标是如下：
CraftGS 的业务逻辑是 Data Package 从卫星传入 DAS ， DAS 负责解包，将解包后数据传入 OMS 及 DPS ， OMS 通过 DAS 传来的数据检测卫星是否正常运行并负责卫星飞行姿态调整； DPS 负责调制 DAS 传来的数据，转换成有意义的逻辑数据。 DPS 处理后的逻辑数据传入 DMS 以及 DPRS 。其中 DMS 负责数据备份、数据查询及数据链路维护等操作； DPRS 负责将 DPS 处理过的逻辑数据分门别类地转换成数据产品，并封装发布。 考虑到项目固有的可靠性安全性要求， CraftGS 系统采用 Java+Unix 技术架构实现。该架构从编程语言级和系统级对软件产品质量做了保证。为了控制软件产品开发过程中的质量，笔者推荐采用如下软件测试方案。 3 测试方案：软件验证技术 + 软件确认技术 + 软件测试管理 CraftGS 系统的软件测试方案由三个部分组成，即软件验证技术、软件确认技术和软件测试管理技术。它们内涵及相互之间的关系如下图所示：
其中，软件验证技术着眼于排除软件开发文档中的错误。验证活动涉及的文档按开发流程主要涉及需求规格说明、设计规格说明（包括概要设计规格说明、详细设计规格说明、数据库设计规格说明）、编码规格说明、产品交付文档等一系列书面材料。目前验证技术的实施在很大程度上是依靠测试人员手工完成的。验证活动视实际需要有时还会涉及到开发人员和目标客户，需要得到他们必要的理解和支持。验证测试采用的主要测试手段有：面对面质询、文档抽查、非正式会议、同行评审等等。 相对于软件验证技术，软件确认技术则主要着眼于排除程序代码中的错误。活动涉及的对象主要是程序部件的代码或软件成品。在实施过程中，常常按被测代码的规模和测试所处的层次将软件确认测试分为四个阶段，即：单元测试（也叫类测试）、集成测试（也叫组装测试）、系统测试和交付测试。确认测试基本上由软件测试人员对照相关开发文档运行程序独立完成的。必要时，也可让设计人员带领测试人员阅读程序代码共同发现其中的错误，（即所谓代码评审会）。有意见认为，在单元测试 ( 或类测试 ) 阶段，应该有软件编码人员参与，这样能减轻测试人员阅读代码障碍。原则上，测试理论不提倡程序作者负责把关自己编写的程序的质量。在实际实施过程中，可视实际情况灵活处理。（如成对编程可能会较好的处理单元测试这个难题，上面提到的代码评审会也是为应对这个难题而想出的一个好办法。），软件确认技术目前已经部分地实现了测试工具的自动化，市面上已有不少自动化工具能在测试人员的辅助下完成相应的测试工作（例如用于 Java 代码单元测试的 Junit 工具，又如用于 GUI 测试的 Rational Visual Test 工具，等等）。 软件验证技术和软件确认技术均属于测试技术层面的东西。然而对于工程质量的保证而言，光靠软件测试技术还远远不够，还需要技术管理层面上的东西。软件测试管理技术的诞生正是为弥补这个不足。按照管理的对象不同，测试管理技术大致涵盖软件测试团队组织管理、软件测试计划管理、软件缺陷（错误）跟踪管理以及软件测试件管理四大部分。下面，笔者将结合 CraftGS 项目对该测试方案做一个详细的诠释。 4 在 CraftGS 项目中具体应用上述测试方案 CraftGS 五个分系统的开发过程均在 CraftGS 测试团队的质量控制下有序进行，严格地实施了上述测试方案。经专家评定，各分系统及最后集成后的系统总体均达到了任务书中所分配的可靠性指标。 4.1 在 CraftGS 项目中应用软件验证技术 CraftGS 项目中应用的软件验证技术主要包括需求规格说明验证、设计规格说明验证、代码验证以及交付验证。以下逐一说明。 需求规格说明验证的主要任务是保证用户的功能需求、业务需求、以及其他的一些需求（如非功能性需求、约束性需求等等）都已经被分配到软件需求规格说明的各需求项中。 设计规格说明验证相对需求规格说明验证而言，稍微复杂些，它包括 3 个部分的内容：即概要设计规格说明验证、详细设计规格说明验证以及数据库设计规格说明验证。其中概要设计规格说明验证的主要任务是确保软件需求规格说明中的需求项全部已经分配到了概要设计规格说明的各软件模块之中并且无多余物，详细设计规格说明验证的主要任务是确保概要设计规格说明中的模块已经全部分配到详细设计规格说明的各软件单元之中并且无多余物，数据库设计规格说明虽然从范畴上讲应该属于详细设计规格说明范畴，但笔者认为因改把它独立出来实施验证活动。（数据库设计和软件设计毕竟有很多不同之处。）数据库设计规格说明验证的重点任务是验证数据库与外部应用程序的接口是否正确、数据操作实现界面是否清晰、数据库整体设计是否合理、数据表设计是否符合 3NF 要求（如违反范式要说明详细理由）以及数据表中的字段（键）和索引的设计是否高效合理等等。完成设计规格说明以后，下一步要做代码验证。 代码验证的内容包括：代码编写规范审查、代码审查和代码静态分析三个部分。代码编写规范审查主要是审核代码排版的格式以及注解的格式是否符合开发团队的相应规范；代码审查的任务主要是验证详细设计中的软件单元是否都已被代码覆盖并正确实现，并且代码中不含冗余物；代码静态分析技术主要任务是检查变量或标号的定义与使用、表达式运算以及程序的流程设计上是否存在缺陷或错误。 做完代码验证以后，软件系统需要依次做单元测试、集成测试和系统测试，这部分内容属软件确认技术范畴，下面有专门的论述。软件系统在做完系统测试后，就面临着交付使用的问题，在系统正式移交给用户之前，还需要做交付验证和交付测试。交付测试技术下文有专门的论述，不赘述，这里主要谈交付验证技术。交付验证包括安装验证和使用验证两部分内容。其中，安装验证的主要任务是保证程序能按照用户手册的提示正确安装到目标机器上，使用验证的主要任务是确保程序能按照用户手册的提示的操作正确完成某项功能或事务处理。这两部分工作通常是由测试人员完成的，用以核实相关安装和使用手册是否正确无误。 4.2 在 CraftGS 项目中应用软件确认技术 CraftGS 中应用的软件确认技术包括单元测试技术、集成测试技术、系统测试技术和交付测试技术。 其中单元测试的主要任务是验证详细设计规格说明中所划分出来的软件单元是否被程序编制人员用代码形式正确地实现了。这里软件单元可能是某个函数（或称方法）也可能是某个抽象数据类型（如类、数据结构或者模板）。单元测试在实际测试当中也常常被称为类测试（在面向对象的设计中）或白盒测试（白盒的意思是面向代码）。单元测试的工作原理是建构桩模块和驱动模块以驱动被测单元运行，然后，测试人员输入设计好的测试用例，测试被测单元能否按照设计要求处理这些测试用例，对出现异常的测试用例，测试人员应做记载并反馈给软件开发团队。 做完单元测试以后，下一步的工作是对照软件概要设计规格说明，验证各软件单元组装后形成模块能否达到概要设计规格说明中模块的设计目标；在模块级集成工作完成之后，测试人员还应测试各模块组装后形成的用户系统内部存在冲突，各模块能否正常工作。这里，模块可能是指某个软件部件，也可能是指某个或某几个分系统。通常在做集成测试时先是从分系统内部的集成测试开始做起，做完以后再测试各分系统是否能集成为最终要实现的大系统。也有其他做法（如自顶向下集成测试方法、核心系统先做集成测试或每日集成测试等等）。总之，万变不离其宗。集成测试要保证模块的内部正确性以及保证模块能最终集成为大系统。集成测试有时也被称为组装测试（在型号软件中）或灰盒测试（有人认为集成测试介于白盒与黑盒之间）。 做完集成测试以后，下一步工作就是做系统测试。系统测试的主要任务是验证经集成测试后形成的软件系统是否满足软件需求规格说明中的各需求项。这些需求项包括：业务需求、功能需求、非功能性需求（如：性能、可靠性、安全性、系统维护等方面的要求）以及一些约束性需求（如开发标准、编程语言、通讯协议）等等。由于需求项涉及的领域很广泛，这就导致了系统测试中对应的测试门类相当庞杂。如：功能测试、执行路径测试、可靠性测试、压力测试、可恢复性测试、可移植性测试等等。这些测试最显著的特征是在一定环境条件下（如：模拟现场或极端条件），设计各种测试用例，输入并运行完整的软件系统，根据软件系统运行过程中的实际表现，评估软件系统是否符合软件需求项的各类要求。由于这类测试一般不涉及内部代码，因此，也有人把系统测试称做是黑盒测试。 在做完系统测试以后，软件产品就到了交付用户使用这个阶段了。交付过程中的重要一环就是交付测试，交付测试的目标是保证用户对所交付的系统的满意。与前面所讨论的测试不同，交付测试主要的参与者应该是目标客户。客户参与越多越好。交付测试的内容一般包括安装测试、可用性测试、 alpha 测试、 beta 测试等。其中安装测试的主要任务是测试软件系统能否在模拟环境下或实际现场由目标用户顺利完成在目标机器上的安装；可用性测试的主要任务是测试软件系统在完成安装以后能否完成用户的模拟任务或现场任务； alpha 测试采用的形式一般是由一个用户在开发环境下对软件系统进行类似于黑盒的测试，测试的目的是从用户的角度评价软件产品的功能、可使用性、可靠性、性能和支持，尤其注重产品的界面和特色； beta 测试采用的形式一般是先由软件的多个用户在实际使用环境下使用 beta 版软件系统一段时间，然后把使用中出现的各类故障或缺陷反馈给 beta 测试负责人员，再由测试负责人员移交给软件开发者，由开发人员负责修正并完善软件系统。 Beta 测试的目的是确保软件产品交付给全体用户之前能部分或全面地修正其在实际应用中可能出现的各类 BUG 或不足。 4.3 在 CraftGS 项目中应用软件测试管理技术 一如前文所述，测试技术解决了测试采用的方法和技术问题，然而，对于一个工程而言，还需要相应的测试管理才能保证各项测试活动的有序开展。因此，在 CraftGS 项目中，软件测试管理技术要解决的问题是如何确保软件测试技术（包括软件验证技术和软件确认技术）能在软件项目在软件生命内得到顺利实施，并产生预期的效果。 按照软件测试管理面对的管理对象的差异，软件测试管理技术大致分为软件测试团队组织管理、软件测试计划管理、软件缺陷（错误）跟踪管理以及软件测试件管理四大部分。以下一一诠释： 软件测试团队组织管理通俗地讲就是测试团队应该如何组建。在实际项目开发中，我们常常看到有些单位忽视测试团队存在的意义，当要实施测试时，往往临时找几个程序员充当测试人员；也有些单位尽管认识到了组建测试团队的重要性，但在具体落实的时候往往安排一些毫无开发经验的行业新手去做测试工作，这常常导致测试效率的低下，测试人员对测试工作索然无味。 CraftGS 项目的测试团队首先聘有一名资深的测试领域专家，他具有极为丰富的航天项目软件测试经验，对软件开发过程中常见的缺陷或错误了然于胸，此外，他还具有较好的亲和力和人格魅力。其次， CraftGS 项目测试团队还具有很多具备一技之长的成员，如对某些自动化测试工具运用娴熟或能轻而易举地编写自动化测试脚本。另外，测试团队还聘有兼职成员。如验证测试实施过程中，同行评审是最常使用的一种形式，这些同行专家就属于兼职测试团队成员的范畴。至于测试团队里里的测试新手，这部分人可以安排去从事交付验证或黑盒测试之类的工作。 软件测试计划管理通俗地讲就是安排好测试流程。这部分内容具体涵盖软件测试策划、软件测试技术剪裁、测试进度管理、成本管理等几个部分。其中测试策划工作主要是指具体测试活动实施之前做好策划工作，如起草测试大纲以及测试计划；软件测试技术剪裁工作主要是指测试团队应根据软件项目的具体实际剪裁出所要实施的测试技术；测试进度管理工作主要是指排出各项测试的时间进度及人员安排，如有变动时应做相应调整；测试成本管理工作的内容即开列出测试活动中会涉及到的资源需求。 CraftGS 项目测试团队较好地按照上述要求，完成了软件测试计划管理。 软件缺陷（错误）跟踪管理通俗地讲就是确保发现的缺陷（错误）已经被开发团队纠正或处理过并且没有引入新的缺陷（错误）。具体来讲，当测试团队通过各种途径发现了文档或代码中的缺陷或错误以后，并不是交一份测试报告就草草了事，而是在递交报告以后继续督促开发团队及时关闭已知缺陷或错误（当然，如有必要应对这些缺陷、错误做严重程度排序，以便开发团队能视轻重缓急安排处理顺序）。当开发团队关闭了测试报告中的缺陷（错误）以后，测试团队还需验证开发团队在关闭过程中有没有引入新的错误。通常，这个过程称为回归测试。回归测试如发现问题，继续报开发团组，按上述流程循环，直至回归测试最终通过。这部分工作在 CraftGS 项目中是使用自动化的测试管理工具完成的，（市面上可选择的工具有 华创缺陷管理系统 (BMS) 和 Rational ClearQuest 等等 ），这么做非常有效率。 软件测试件管理通俗地讲就是指努力建设好测试团队的财富库并对测试团队成员进行技能培训以帮助他们能使用好这个财富库。这里，财富库是指软件测试件。测试件（ Testware ，指测试工作形成的产品）是一个不常见到的词汇，它包括是测试团队在长期实践过程中逐步积累起来的经验教训、测试技巧、测试工具、规格文档以及一些经过少量修改能推广至通用的测试脚本程序。测试件管理工作做得越好，测试团队在实际测试过程中就能越少走弯路，测试团队内部的知识交流和传递就越充分，测试脚本或规格文档的重复开发工作也就能被有效地避免。软件测试件管理工作包括两部分，一是建设，另一个是培训。建设工作大抵是收集各类测试外文档、测试工具、测试脚本，也包括收集整理测试人员的会议发言、总结报告、技术心得等等。培训工作大抵是通过技术讲座、正式或非正式团队会议、印发学习资料等形式进行。 CraftGS 项目组考虑到测试团队的长久发展，较好地完成了测试件管理，测试团队成员的技能水平在较短的时间内都有了非常迅速的进步。 5 结语：高可靠性软件测试技术需要更多关注 以上笔者结合 CraftGS 项目对从测试技术和测试管理的角度对高可靠性软件测试方案一个略粗浅的探讨。笔者希望此文的发表能对相关软件企业和软件项目实施软件测试技术起一定的参考和指导作用。需要说明的是目前对高可靠性软件如何实施软件测试技术仍是一个颇不成熟的领域，缺少一种体系化的方法。各个企业可能都有一定的经验积累，不妨整理出来，相互借鉴。这里，笔者所做的探讨虽然已经竭尽所能，但却不能保证一定能照搬照抄到所有的高可靠性软件项目的测试之中。希望该领域的学者和技术专家共同努力、不断摸索，逐步完善这一课题。 [2] Bill Hetzel.The complete Guide to Software Testing.2,NewYork:John Wilely Press,1988.137-190. [3] Edward Kit. Software Testing in the Real World. London:Pearson Education,1995.45-88. [4] Daniel J.Mosely,Bruce A.posey.Just Enough Software Test Automation..NewYork:Pearson Education,2002.87-91. [5] Paul C.Jorgensen. Software Testing -A Craftsman's Approach. 2,Florida:CRC Press,2002.260-296. [6] 许胜，支定镛等 . 航天软件工程实施技术指南及范例 . 北京 : 航天 5 院， 2003. |
||||||||||||||||||||||||||||||||||