一种高可靠性软件测试方案（二）

　　CraftGS中应用的软件确认技术包括单元测试技术、集成测试技术、系统测试技术和交付测试技术。

　　其中单元测试的主要任务是验证详细设计规格说明中所划分出来的软件单元是否被程序编制人员用代码形式正确地实现了。这里软件单元可能是某个函数(或称方法)也可能是某个抽象数据类型(如类、数据结构或者模板)。单元测试在实际测试当中也常常被称为类测试(在面向对象的设计中)或白盒测试(白盒的意思是面向代码)。单元测试的工作原理是建构桩模块和驱动模块以驱动被测单元运行，然后，测试人员输入设计好的测试用例，测试被测单元能否按照设计要求处理这些测试用例，对出现异常的测试用例，测试人员应做记载并反馈给软件开发团队。

　　做完单元测试以后，下一步的工作是对照软件概要设计规格说明，验证各软件单元组装后形成模块能否达到概要设计规格说明中模块的设计目标;在模块级集成工作完成之后，测试人员还应测试各模块组装后形成的用户系统内部存在冲突，各模块能否正常工作。这里，模块可能是指某个软件部件，也可能是指某个或某几个分系统。通常在做集成测试时先是从分系统内部的集成测试开始做起，做完以后再测试各分系统是否能集成为最终要实现的大系统。也有其他做法(如自顶向下集成测试方法、核心系统先做集成测试或每日集成测试等等)。总之，万变不离其宗。集成测试要保证模块的内部正确性以及保证模块能最终集成为大系统。集成测试有时也被称为组装测试(在型号软件中)或灰盒测试(有人认为集成测试介于白盒与黑盒之间)。

　　做完集成测试以后，下一步工作就是做系统测试。系统测试的主要任务是验证经集成测试后形成的软件系统是否满足软件需求规格说明中的各需求项。这些需求项包括：业务需求、功能需求、非功能性需求(如：性能、可靠性、安全性、系统维护等方面的要求)以及一些约束性需求(如开发标准、编程语言、通讯协议)等等。由于需求项涉及的领域很广泛，这就导致了系统测试中对应的测试门类相当庞杂。如：功能测试、执行路径测试、可靠性测试、压力测试、可恢复性测试、可移植性测试等等。这些测试最显着的特征是在一定环境条件下(如：模拟现场或极端条件)，设计各种测试用例，输入并运行完整的软件系统，根据软件系统运行过程中的实际表现，评估软件系统是否符合软件需求项的各类要求。由于这类测试一般不涉及内部代码，因此，也有人把系统测试称做是黑盒测试。

　　在做完系统测试以后，软件产品就到了交付用户使用这个阶段了。交付过程中的重要一环就是交付测试，交付测试的目标是保证用户对所交付的系统的满意。与前面所讨论的测试不同，交付测试主要的参与者应该是目标客户。客户参与越多越好。交付测试的内容一般包括安装测试、可用性测试、alpha测试、beta测试等。其中安装测试的主要任务是测试软件系统能否在模拟环境下或实际现场由目标用户顺利完成在目标机器上的安装;可用性测试的主要任务是测试软件系统在完成安装以后能否完成用户的模拟任务或现场任务;alpha测试采用的形式一般是由一个用户在开发环境下对软件系统进行类似于黑盒的测试，测试的目的是从用户的角度评价软件产品的功能、可使用性、可靠性、性能和支持，尤其注重产品的界面和特色;beta测试采用的形式一般是先由软件的多个用户在实际使用环境下使用beta版软件系统一段时间，然后把使用中出现的各类故障或缺陷反馈给beta测试负责人员，再由测试负责人员移交给软件开发者，由开发人员负责修正并完善软件系统。Beta测试的目的是确保软件产品交付给全体用户之前能部分或全面地修正其在实际应用中可能出现的各类BUG或不足。

　　4.3 在CraftGS项目中应用软件测试管理技术

　　一如前文所述，测试技术解决了测试采用的方法和技术问题，然而，对于一个工程而言，还需要相应的测试管理才能保证各项测试活动的有序开展。因此，在CraftGS项目中，软件测试管理技术要解决的问题是如何确保软件测试技术(包括软件验证技术和软件确认技术)能在软件项目在软件生命内得到顺利实施，并产生预期的效果。

　　按照软件测试管理面对的管理对象的差异，软件测试管理技术大致分为软件测试团队组织管理、软件测试计划管理、软件缺陷(错误)跟踪管理以及软件测试件管理四大部分。以下一一诠释：

软件测试团队组织管理通俗地讲就是测试团队应该如何组建。在实际项目开发中，我们常常看到有些单位忽视测试团队存在的意义，当要实施测试时，往往临时找几个程序员充当测试人员;也有些单位尽管认识到了组