做完代码验证以后，软件系统需要依次做单元测试、集成测试和系统测试，这部分内容属软件确认技术范畴，下面有专门的论述。软件系统在做完系统测试后，就面临着交付使用的问题，在系统正式移交给用户之前，还需要做交付验证和交付测试。交付测试技术下文有专门的论述，不赘述，这里主要谈交付验证技术。交付验证包括安装验证和使用验证两部分内容。其中，安装验证的主要任务是保证程序能按照用户手册的提示正确安装到目标机器上，使用验证的主要任务是确保程序能按照用户手册的提示的操作正确完成某项功能或事务处理。这两部分工作通常是由测试人员完成的，用以核实相关安装和使用手册是否正确无误。

　　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 项目对从测试技术和测试管理的角度对高可靠性软件测试方案一个略粗浅的探讨。笔者希望此文的发表能对相关软件企业和软件项目实施软件测试技术起一定的参考和指导作用。需要说明的是目前对高可靠性软件如何实施软件测试技术仍是一个颇不成熟的领域，缺少一种体系化的方法。各个企业可能都有一定的经验积累，不妨整理出来，相互借鉴。这里，笔者所做的探讨虽然已经竭尽所能，但却不能保证一定能照搬照抄到所有的高可靠性软件项目的测试之中。希望该领域的学者和技术专家共同努力、不断摸索，逐步完善这一课题。