TCL是一脚本解释器，具有基本的语言特性，支持整型和字符串变量，支持循环等控制结构；同时它具有灵活的扩展性和跨平台的特性，后者是它最主要的特性。通过TCL脚本可以编写测试用例，通过扩展功能，可以扩展你想要的测试动作。最终目的是将测试的自动化和灵活性（可扩展性）结合在一起。     

TCL 提供以下接口：

    1、用户接口

对用户提供语言特性，如循环、条件判断等控制结构，通过它用户可以灵活的书写测试用例；当然只 提供语言特性远远不够，因为业务千差万别，所以用户需要业务接口，从而完成特定的测试任务。而业务接口，是通过下面的程序员接口实现。

    2、程序员接口

用户可以编写自己命令，它包括用户层（即名字）和实现层（通过 C 语言实现），然后用 TCL 提供的注册 函数登记，以后命令就可灵活的嵌入到脚本中了。

TCL测试模型分三部分：

被测试程序（由开发人员编写）---测试人员应搞清楚程序结构和业务功能，指导扩展命令的设计。

测试代码（由测试设计人员编写）---通过程序员接口，提供给脚本扩展命令。

测试用例（TCL脚本形式，由测试执行人员编写）---通过脚本对扩展命令进一步组合。

CMM为企业的软件过程能力提供了一个阶梯式的进化框架，阶梯共有五级。第一级只是一个起点，任何准备按CMM体系进化的企业都自然处于这个起点上，并通过它向第二级迈进。除第一级外，每一级都设定了一组目标，如果达到了这组目标，则表明达到了这个成熟级别，可以向下一级别迈进。

第一级、初始级：

初始级的软件过程是未加定义的随意过程，项目的执行是随意甚至是混乱的。也许有些企业制定了一些软件工程规范，但若这些规范未能覆盖基本的关键过程要求，且执行没有政策、资源等方面的保证时，那么它仍然被视为初始级。

第二级、重复级：

根据多年的经验和教训，人们总结出软件开发的首要问题不是技术问题而是管理问题。因此，第二级的焦点集中在软件管理过程上。一个可管理的过程则是一个可重复的过程，可重复的过程才能逐渐改进和成熟。可重复级的管理过程包括了需求管理、项目管理、质量管理、配置管理和子合同管理五个方面；其中项目管理过程又分为计划过程和跟踪与监控过程。通过实施这些过程，从管理角度可以看到一个按计划执行的且阶段可控的软件开发过程。

第三级、定义级：     

在可重复级定义了管理的基本过程，而没有定义执行的步骤标准。在第三级则要求制定企业范围的工程化标准，并将这些标准集成到企业软件开发标准过程中去。所有开发的项目需根据这个标准过程，裁剪出与项目适宜的过程，并且按照过程执行。过程的裁剪不是随意的，在使用前必须经过企业有关人员的批准。

第四级、管理级：
   

第四级的管理是量化的管理。所有过程需建立相应的度量方式，所有产品的质量（包括工作产品和提交给用户的最终产品）需要有明确的度量指标。这些度量应是详尽的，且可用于理解和控制软件过程和产品。量化控制将使软件开发真正成为一种工业生产活动。

第五级、优化级：
     

优化级的目标是达到一个持续改善的境界。所谓持续改善是指可以根据过程执行的反馈信息来改善下一步的执行过程，即优化执行步骤。如果企业达到了第五级，就表明该企业能够根据实际的项目性质、技术等因素，不断调整软件生产过程以求达到最佳。

CMM2级：可重复级

Requirement Management
需求管理

Goal 1:System requiremnets allocated to software are controlled to establish a baseline for software engineering and management use.

目标1：分配到软件部分的系统需求通过建立基线受控。

Goal 2:Software plans, products, and activities are kept consistent with the system requirements allocated to software.

目标2：软件计划、产品和活动与分配到软件部分的系统需求一致。

Software Project Planning
软件项目计划

Goal 1:Software estimates are documented for use in planning and tracking the software project.

目标1：用来计划和跟踪软件项目的软件估计文档化。

Goal 2:Software project activities and commitments are planned and documented.

目标2：制定了软件项目活动和任务书的计划，并且有文档记录。

Goal 3:Affected groups and individuals agree to their commitments related to the software project.

目标3：受影响的小组和个人接受和软件项目相关的任务书。

Software Project Tracking and Oversight
软件项目跟踪及监控

Goal 1:Actual results and performances are tracked against the software plans.

目标1：按照软件计划跟踪实际结果和性能。

Goal 2:Corrective actions are taken and managed to closure when actual results and performance deviate significantly from the software plans.

目标2：当实际的结果和性能严重偏离软件计划时，采取了正确的行动终止这种状况。

Goal 3:Changes to sofware commitments are agreed to by the affected groups and individuals.

目标3：受影响的小组和个人接受软件任务书的变化。

Software Subcontract Management
软件子合同管理

Goal 1:The prime contractor selects qualified software subcontractors.

目标1：主签约人挑选有资格的子签约人。

Goal 2:The prime contractor and the software subcontractor agree to their commitments to each other.

目标2：主签约人和子签约人互相接受他们的任务书。

Goal 3:The prime contractor and the software subcontractor maintain ongoing communications.

目标3：主签约人和子签约人保持持续的沟通。

Goal 4:The prime contractor tracks the software subcontractor's actual results and performance against its commitments.

目标4：主签约人按照任务书跟踪子签约人的实际结果和效能。

Software Quality Assurance
软件质量保证

Goal 1:Software quality assurance activities are planned.

目标1：制定了软件质量保证计划。

Goal 2:Adherence of software products and activities to the applicable standards, procedures, and requirements is verified objectively.

目标2：客观地检验软件产品和活动是否符合适用的标准、过程和需求。

Goal 3:Affected groups and individuals are informed of software quality assurance activities and results.

目标3：软件质量保证的活动和结果通知了受影响的小组和个人。

Goal 4:Noncompliance issues that cannot be resolved within the software project are addressed by senior management.

目标4：高层管理着手解决在软件项目内部不能解决的不符合项。

Software Configuration Management
软件配置管理

Goal 1:Software configuration management activities are planned.

目标1：制定了软件配置管理活动的计划。

Goal 2:Selected software work products are identified, controlled, and available.

目标2：选定的软件工作产品是被标识的、受控的和可利用的。

Goal 3:Changes to identified software work products are controlled.

目标3：被标识的软件工作产品的变化是受控的。

Goal 4:Affected groups and individuals are informed of the status and content of software baselines.

目标4：软件基线的状态和内容通知受影响的小组和个人。

LOGISCOPE是为软件的全面质量控制而开发的强大工具，可以用在编程、测试和维护阶段。LOGISCOPE五个模块的功能：

1) 阅读器(Viewer)：以文件调用图(各部件文件之间的关系)及组件调用图 (函数和程序间的调用关系)的形式进行可视化应用软件设计。可以在各种各样的抽象级别上分析应用程序，在不同级别上的引导有助于整个应用程序的理解。

2) 效果检查器(ImpactChecker)：允许用户检查使用的资源(文件、函数、用户定义类型、全局变量、结构成员常量)。它有助于我们理解函数间的信息流 (参数传递)，以及数据和其它应用程序资源间的关系。

3) 规则检查器(RuleChecker)：软件公司应该定义自己的编程规则和质量目标。这样做的好处是公司编程行为保持一致性、易于维护、提高可靠性、易于移植到其它机器上。我们可以用规则检查器(RuleChecker)确立编程标准，保证质量控制。

4 ) 测试检查器(TestChecker)：实时度量测试覆盖率、显示未覆盖路径原始数据、生成测试报告、帮助管理测试实例。测试检查器(TestChecker)和动态分析器(Dynamic Analyzer)通过阅读器产生用于应用程序分析的数据。

5 ) 代码检查器 (CodeChecker)：验证应用程序与质量模型的一致性。代码检查器和静态分析器(Static Analyzer)通过阅读器(Viewer)产生用于应用程序分析的数据。代码检查器(CodeChecker)可以使我们尽早发现和修改质量缺陷。这对质量控制尤为重要。

α测试是由一个用户在开发环境下进行的测试，也可以是开发机构内部的用户在模拟实际操作环境下进行的测试。软件在一个自然设置状态下使用。开发者坐在用户旁边，随时记下错误情况和使用中的问题。这是在受控制的环境下进行的测试，α测试的目的是评价软件产品的FLURPS(即功能、局域化、可使用性、可靠性、性能和支持)。尤其注重产品的界面和特色。α测试人员是除开产品开发人员之外首先见到产品的人，他们提出的功能和修改意见是特别有价值的。α测试可以从软件产品编码结束之时开始，或在模块（子系统）测试完成之后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程序之后再开始。有关的手册（草稿）等应事先准备好。

β测试是由软件的多个用户在一个或多个用户的实际使用环境下进行的测试。这些用户是与公司签定了支持产品预发行合同的外部客户，他们要求使用该产品，并愿意返回有关错位错误信息给开发者。与α测试不同的是，开发者通常不在测试现场。因而，β测试是在开发者无法控制的环境下进行的软件现场应用。在β测试中，由用户记下遇到的所有问题，包括真实的以及主观认定的，定期向开发者报告，开发者在综合用户的报告之后，做出修改，最将软件产品交付给全体用户使用。β测试主要衡量产品的FLURPS。着重于产品的支持性，包括文档、客户培训和支持产品生产能力。只有当α测试达到一定的可靠程度时，才能开始β测试。由于它处在整个测试的最后阶段，不能指望这时发现主要问题。同时，产品的所有手册文本也应该在此阶段完全定稿。

由于β测试的主要目标是测试可支持性，所以β测试应尽可能由主持产品发行的人员来管理。

传统的集成测试，是通过各种集成策略集成各功能模块进行测试，一般可以在部分程序编译完成的情况下进行。而对于面向对象程序，相互调用的功能是散布在程序的不同类中，类通过消息相互作用申请和提供服务。类的行为与它的状态密切相关，状态不仅仅是体现在类数据成员的值，也许还包括其他类中的状态信息。由此可见，类相互依赖极其紧密，根本无法在编译不完全的程序上对类进行测试。所以，面向对象的集成测试通常需要在整个程序编译完成后进行。此外，面向对象程序具有动态特性，程序的控制流往往无法确定，因此也只能对整个编译后的程序做基于黑盒子的集成测试。

面向对象的集成测试能够检测出相对独立的单元测试无法检测出的那些类相互作用时才会产生的错误。基于单元测试对成员函数行为正确性的保证，集成测试只关注于系统的结构和内部的相互作用。面向对象的集成测试可以分成两步进行：先进行静态测试，再进行动态测试。

静态测试主要针对程序的结构进行，检测程序结构是否符合设计要求。现在流行的一些测试软件都能提供一种称为“可逆性工程”的功能，即通过原程序得到类关系图和函数功能调用关系图，例如International Software Automation公司的Panorama-2、Rational公司的Rose C++ Analyzer等，将“可逆性工程”得到的结果与OOD的结果相比较，检测程序结构和实现上是否有缺陷。换句话说，通过这种方法检测OOP是否达到了设计要求。

动态测试设计测试用例时，通常需要上述的功能调用结构图、类关系图或者实体关系图为参考，确定不需要被重复测试的部分，从而优化测试用例，减少测试工作量，使得进行的测试能够达到一定覆盖标准。测试所要达到的覆盖标准可以是：达到类所有的服务要求或服务提供的一定覆盖率；依据类间传递的消息，达到对所有执行线程的一定覆盖率；达到类的所有状态的一定覆盖率等。同时也可以考虑使用现有的一些测试工具来得到程序代码执行的覆盖率。

具体设计测试用例，可参考下列步骤：

1. 先选定检测的类，参考OOD分析结果，仔细出类的状态和相应的行为，类或成员函数间传递的消息，输入或输出的界定等。

2. 确定覆盖标准。

3. 利用结构关系图确定待测类的所有关联。

4. 根据程序中类的对象构造测试用例，确认使用什么输入激发类的状态、使用类的服务和期望产生什么行为等。

值得注意，设计测试用例时，不但要设计确认类功能满足的输入，还应该有意识的设计一些被禁止的例子，确认类是否有不合法的行为产生，如发送与类状态不相适应的消息，要求不相适应的服务等。根据具体情况，动态的集成测试，有时也可以通过系统测试完成。

通过单元测试和集成测试，仅能保证软件开发的功能得以实现。但不能确认在实际运行时，它是否满足用户的需要，是否大量存在实际使用条件下会被诱发产生错误的隐患。为此，对完成开发的软件必须经过规范的系统测试。换个角度说，开发完成的软件仅仅是实际投入使用系统的一个组成部分，需要测试它与系统其他部分配套运行的表现，以保证在系统各部分协调工作的环境下也能正常工作。　　

系统测试应该尽量搭建与用户实际使用环境相同的测试平台，应该保证被测系统的完整性，对临时没有的系统设备部件，也应有相应的模拟手段。系统测试时，应该参考OOA分析的结果，对应描述的对象、属性和各种服务，检测软件是否能够完全“再现”问题空间。系统测试不仅是检测软件的整体行为表现，从另一个侧面看，也是对软件开发设计的再确认。

这里说的系统测试是对测试步骤的抽象描述。它体现的具体测试内容包括：

·功能测试：测试是否满足开发要求，是否能够提供设计所描述的功能，是否用户的需求都得到满足。功能测试是系统测试最常用和必须的测试，通常还会以正式的软件说明书为测试标准。

·强度测试：测试系统的能力最高实际限度，即软件在一些超负荷的情况，功能实现情况。如要求软件某一行为的大量重复、输入大量的数据或大数值数据、对数据库大量复杂的查询等。

·性能测试：测试软件的运行性能。这种测试常常与强度测试结合进行，需要事先对被测软件提出性能指标，如传输连接的最长时限、传输的错误率、计算的精度、记录的精度、响应的时限和恢复时限等。

·安全测试：验证安装在系统内的保护机构确实能够对系统进行保护，使之不受各种非常的干扰。安全测试时需要设计一些测试用例试图突破系统的安全保密措施，检验系统是否有安全保密的漏洞。

·恢复测试：采用人工的干扰使软件出错，中断使用，检测系统的恢复能力，特别是通讯系统。恢复测试时，应该参考性能测试的相关测试指标。

·可用性测试：测试用户是否能够满意使用。具体体现为操作是否方便，用户界面是否友好等。

·安装/卸载测试（install/uninstall test）等等。

系统测试需要对被测的软件结合需求分析做仔细的测试分析，建立测试用例。

测试是软件开发的重要过程之一，但是CMM没有充分的定义测试，没有提及测试成熟度的概念，没有对测试过程改进进行充分说明，在KPA中没有定义测试问题，与质量相关的测试问题如可测性，充分测试标准，测试计划等方面也没有满意的阐述。

TMM是受CMM模型启发产生的，关注于测试的成熟度模型。它描述了测试过程，是项目测试部分得到良好计划和控制的基础。TMM测试成熟度分解为5级别，关注于5个成熟度级别递增：

Phase 0：测试和调试没有区别，初了支持调试外，测试没有其他目的

Phase 1：测试的目的是为了表明软件能够工作

Phase 2：测试的目的是为了表明软件不能够能够正常工作

Phase 3：测试的目的不是要证明什么，而是为了把软件不能正常工作的预知风险降低到能够接受的程度

Phase 4：测试不是行为，而是一种自觉的约束(mental discipline)，不用太多的测试投入产生低风险的软件上的

软件测试自动化，是一项让计算机代替测试人员进行软件测试的技术。他可以让测试人员从繁琐和重复的测试活动中解脱出来，专心从事有意义的测试设计等活动。如果采用自动比较技术，还可以自动完成测试用例执行结果的判断，从而避免人工比对存在的疏漏问题。设计良好的自动化测试，在某些情况下可以实现“夜间测试”和“无人测试”。在大多数情况下，软件测试自动化可以减少开支，增加有限时间内可执行的测试，在执行相同数量测试时节约测试时间。

软件测试自动化通常借助测试工具进行。测试工具可以进行部分的测试设计、实现、执行和比较的工作。通过运用测试工具，可以达到提高测试效率的目的。所以测试工具的选择和推广使用应该给予重视。部分的测试工具可以实现测试用例的自动生成，但通常的工作方式为人工设计测试用例，使用工具进行用例的执行和比较。

软件测试自动化的设计并不能由工具来完成，必须由测试人员进行手工设计，但是在设计是却必须考虑自动化的特殊要求，否则无法实现利用工具进行用例的自动执行。为此，就必须在测试的设计和内容的组织方面采取一些特殊的方法。

对于软件测试自动化的工作，大多数人都认为是一件非常容易的事。其实，软件测试自动化的工作量非常大，而且也并不是在任何情况下都适用，同时软件测试自动化的设计并不比程序设计简单