关键字：软件测试知识帖
TCL是一脚本解释器，具有基本的语言特性，支持整型和字符串变量，支持循环等控制结构；同时它具有灵活的扩展性和跨平台的特性，后者是它最主要的特性。通过TCL脚本可以编写测试用例，通过扩展功能，可以扩展你想要的测试动作。最终目的是将测试的自动化和 灵活性（可扩展性）结合在一起。 TCL提供以下接口：
1、用户接口
对用户提供语言特性，如循环、条件判断等控制结构，通过它用户可以灵活的书写测试用例；当然只 提供语言特性远远不够，因为业务千差万别，所以用户需要业务接口，从而完成特定的测试任务。 而业务接口，是通过下面的程序员接口实现。
2、程序员接口
用户可以编写自己命令，它包括用户层（即名字）和实现层（通过C语言实现），然后用TCL提供的注册 函数登记，以后命令就可灵活的嵌入到脚本中了。
TCL测试模型分三部分：
被测试程序（由开发人员编写）----测试人员应搞清楚程序结构和业务功能，指导扩展命令的设计。
测试代码（由测试设计人员编写） ---通过程序员接口，提供给脚本扩展命令。
测试用例（TCL脚本形式，由测试执行人员编写）---通过脚本对扩展命令进一步组合。
第30贴【2004－6－15】：CMM的五级简介
CMM为企业的软件过程能力提供了一个阶梯式的进化框架，阶梯共有五级。第一级只是一个起点，任何准备按CMM体系进化的企业都自然处于这个起点上，并通过它向第二级迈进。除第一级外，每一级都设定了一组目标，如果达到了这组目标，则表明达到了这个成熟级别，可以向下一级别迈进。
第一级、初始级：
初始级的软件过程是未加定义的随意过程，项目的执行是随意甚至是混乱的。也许有些企业制定了一些软件工程规范，但若这些规范未能覆盖基本的关键过程要求，且执行没有政策、资源等方面的保证时，那么它仍然被视为初始级。
第二级、重复级：
根据多年的经验和教训，人们总结出软件开发的首要问题不是技术问题而是管理问题。因此，第二级的焦点集中在软件管理过程上。一个可管理的过程则是一个可重复的过程，可重复的过程才能逐渐改进和成熟。可重复级的管理过程包括了需求管理、项目管理、质量管理、配置管理和子合同管理五个方面；其中项目管理过程又分为计划过程和跟踪与监控过程。通过实施这些过程，从管理角度可以看到一个按计划执行的且阶段可控的软件开发过程。
第三级、定义级：
在可重复级定义了管理的基本过程，而没有定义执行的步骤标准。在第三级则要求制定企业范围的工程化标准，并将这些标准集成到企业软件开发标准过程中去。所有开发的项目需根据这个标准过程，裁剪出与项目适宜的过程，并且按照过程执行。过程的裁剪不是随意的，在使用前必须经过企业有关人员的批准。
第四级、管理级：
第四级的管理是量化的管理。所有过程需建立相应的度量方式，所有产品的质量（包括工作产品和提交给用户的最终产品）需要有明确的度量指标。这些度量应是详尽的，且可用于理解和控制软件过程和产品。量化控制将使软件开发真正成为一种工业生产活动。
第五级、优化级：
优化级的目标是达到一个持续改善的境界。所谓持续改善是指可以根据过程执行的反馈信息来改善下一步的执行过程，即优化执行步骤。如果企业达到了第五级，就表明该企业能够根据实际的项目性质、技术等因素，不断调整软件生产过程以求达到最佳。
第31贴【2004－6－16】：CMM 2级KPA的目标
CMM 2级：可重复级
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：软件基线的状态和内容通知受影响的小组和个人。
第32贴【2004－6－17】：Logiscope的功能
LOGISCOPE是为软件的全面质量控制而开发的强大工具，可以用在编程、测试和维护阶段。LOGISCOPE五个模块的功能：
(1) 阅读器(Viewer)：以文件调用图(各部件文件之间的关系)及组件调用图(函数和程序间的调用关系)的形式进行可视化应用软件设计。可以在各种各样的抽象级别上分析应用程序，在不同级别上的引导有助于整个应用程序的理解。
(2) 效果检查器(ImpactChecker)：允许用户检查使用的资源(文件、函数、用户定义类型、全局变量、结构成员常量)。它有助于我们理解函数间的信息流(参数传递)，以及数据和其它应用程序资源间的关系。
(3)规则检查器(RuleChecker)：软件公司应该定义自己的编程规则和质量目标。这样做的好处是公司编程行为保持一致性、易于维护、提高可靠性、易于移植到其它机器上。我们可以用规则检查器(RuleChecker)确立编程标准，保证质量控制。
(4) 测试检查器(TestChecker)：实时度量测试覆盖率、显示未覆盖路径原始数据、生成测试报告、帮助管理测试实例。测试检查器(TestChecker)和动态分析器 (Dynamic Analyzer)通过阅读器产生用于应用程序分析的数据。
(5) 代码检查器(CodeChecker)：验证应用程序与质量模型的一致性。代码检查器和静态分析器(Static Analyzer)通过阅读器(Viewer)产生用于应用程序分析的数据。代码检查器(CodeChecker)可以使我们尽早发现和修改质量缺陷。这对质量控制尤为重要。
第33贴【2004－6－18】：α测试
α测试是由一个用户在开发环境下进行的测试，也可以是开发机构枘部的用户在模拟实际操作环境下进行的测试。软件在一个自然设置状态下使用。开发者坐在用户旁边，随时记下错误情况和使用中的问题。这是在受控制的环境下进行的测试，α测试的目的是评价软件产品的FLURPS(即功能、局域化、可使用性、可靠性、性能和支持)。尤其注重产品的界面和特色。α测试人员是除开产品开发人员之外首先见到产品的人，他们提出的功能和修改意见是特别有价值的。 α测试可以从软件产品编码结束之时开始，或在模块（子系统）测试完成之后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程序之后再开始。有关的手册（草稿）等应事先准备好。
第34贴【2004－6－19】：β测试
β测试是由软件的多个用户在一个或多个用户的实际使用环境下进行的测试。这些用户是与公司签定了支持产品预发行合同的外部客户，他们要求使用该产品，并愿意返回有关错位错误信息给开发者。与α测试不同的是，开发者通常不在测试现场。因而，β测试是在开发者无法控制的环境下进行的软件现场应用。在β测试中，由用户记下遇到的所有问题，包括真实的以及主观认定的，定期向开发者报告，开发者在综合用户的报告之后，做出修改，最将软件产品交付给全体用户使用。 β测试主要衡量产品的FLURPS。着重于产品的支持性，包括文档、客户培训和支持产品生产能力。只有当α测试达到一定的可靠程度时，才能开始β测试。由于它处在整个测试的最后阶段，不能指望这时发现主要问题。同时，产品的所有手册文本也应该在此阶段完全定稿。
由于β测试的主要目标是测试可支持性，所以β测试应尽可能由主持产品发行的人员来管理。
第35贴【2004－6－20】：面向对象的集成测试
传统的集成测试，是通过各种集成策略集成各功能模块进行测试，一般可以在部分程序编译完成的情况下进行。而对于面向对象程序，相互调用的功能是散布在程序的不同类中，类通过消息相互作用申请和提供服务。类的行为与它的状态密切相关，状态不仅仅是体现在类数据成员的值，也许还包括其他类中的状态信息。由此可见，类相互依赖极其紧密，根本无法在编译不完全的程序上对类进行测试。所以，面向对象的集成测试通常需要在整个程序编译完成后进行。此外，面向对象程序具有动态特性，程序的控制流往往无法确定，因此也只能对整个编译后的程序做基于黑盒子的集成测试。
面向对象的集成测试能够检测出相对独立的单元测试无法检测出的那些类相互作用时才会产生的错误。基于单元测试对成员函数行为正确性的保证，集成测试只关注于系统的结构和内部的相互作用。面向对象的集成测试可以分成两步进行：先进行静态测试，再进行动态测试。
静态测试主要针对程序的结构进行，检测程序结构是否符合设计要求。现在流行的一些测试软件都能提供一种称为"可逆性工程"的功能，即通过原程序得到类关系图和函数功能调用关系图，例如International Software Automation 公司的Panorama-2 、Rational公司的Rose C++ Analyzer等，将"可逆性工程"得到的结果与OOD的结果相比较，检测程序结构和实现上是否有缺陷。换句话说，通过这种方法检测OOP是否达到了设计要求。
动态测试设计测试用例时，通常需要上述的功能调用结构图、类关系图或者实体关系图为参考，确定不需要被重复测试的部分，从而优化测试用例，减少测试工作量，使得进行的测试能够达到一定覆盖标准。测试所要达到的覆盖标准可以是：达到类所有的服务要求或服务提供的一定覆盖率；依据类间传递的消息，达到对所有执行线程的一定覆盖率；达到类的所有状态的一定覆盖率等。同时也可以考虑使用现有的一些测试工具来得到程序代码执行的覆盖率。
具体设计测试用例，可参考下列步骤：
1. 先选定检测的类，参考OOD分析结果，仔细出类的状态和相应的行为，类或成员函数间传递的消息，输入或输出的界定等。
2. 确定覆盖标准。
3. 利用结构关系图确定待测类的所有关联。
4. 根据程序中类的对象构造测试用例，确认使用什么输入激发类的状态、使用类的服务和期望产生什么行为等。
值得注意，设计测试用例时，不但要设计确认类功能满足的输入，还应该有意识的设计一些被禁止的例子，确认类是否有不合法的行为产生，如发送与类状态不相适应的消息，要求不相适应的服务等。根据具体情况，动态的集成测试，有时也可以通过系统测试完成。
第36贴【2004－6－21】：面向对象的系统测试
通过单元测试和集成测试，仅能保证软件开发的功能得以实现。但不能确认在实际运行时，它是否满足用户的需要，是否大量存在实际使用条件下会被诱发产生错误的隐患。为此，对完成开发的软件必须经过规范的系统测试。换个角度说，开发完成的软件仅仅是实际投入使用系统的一个组成部分，需要测试它与系统其他部分配套运行的表现，以保证在系统各部分协调工作的环境下也能正常工作。
系统测试应该尽量搭建与用户实际使用环境相同的测试平台，应该保证被测系统的完整性，对临时没有的系统设备部件，也应有相应的模拟手段。系统测试时，应该参考OOA分析的结果，对应描述的对象、属性和各种服务，检测软件是否能够完全"再现"问题空间。系统测试不仅是检测软件的整体行为表现，从另一个侧面看，也是对软件开发设计的再确认。
这里说的系统测试是对测试步骤的抽象描述。它体现的具体测试内容包括：
· 功能测试：测试是否满足开发要求，是否能够提供设计所描述的功能，是否用户的需求都得到满足。功能测试是系统测试最常用和必须的测试，通常还会以正式的软件说明书为测试标准。
· 强度测试：测试系统的能力最高实际限度，即软件在一些超负荷的情况，功能实现情况。如要求软件某一行为的大量重复、输入大量的数据或大数值数据、对数据库大量复杂的查询等。
· 性能测试：测试软件的运行性能。这种测试常常与强度测试结合进行，需要事先对被测软件提出性能指标，如传输连接的最长时限、传输的错误率、计算的精度、记录的精度、响应的时限和恢复时限等。
· 安全测试：验证安装在系统内的保护机构确实能够对系统进行保护，使之不受各种非常的干扰。安全测试时需要设计一些测试用例试图突破系统的安全保密措施，检验系统是否有安全保密的漏洞。
· 恢复测试：采用人工的干扰使软件出错，中断使用，检测系统的恢复能力，特别是通讯系统。恢复测试时，应该参考性能测试的相关测试指标。
· 可用性测试：测试用户是否能够满意使用。具体体现为操作是否方便，用户界面是否友好等。
· 安装/卸载测试（install/uninstall test）等等。
系统测试需要对被测的软件结合需求分析做仔细的测试分析，建立测试用例。
第37贴【2004－6－22】：TMM介绍
测试是软件开发的重要过程之一，但是CMM没有充分的定义测试，没有提及测试成熟度的概念，没有对测试过程改进进行充分说明，在KPA中没有定义测试问题，与质量相关的测试问题如可测性，充分测试标准，测试计划等方面也没有满意的阐述。
TMM是受CMM模型启发产生的，关注于测试的成熟度模型。它描述了测试过程，是项目测试部分得到良好计划和控制的基础。TMM测试成熟度分解为5级别，关注于5个成熟度级别递增：
Phase 0 ：测试和调试没有区别，初了支持调试外，测试没有其他目的
Phase 1 ： 测试的目的是为了表明软件能够工作
Phase 2 ：测试的目的是为了表明软件不能够能够正常工作
Phase 3 ： 测试的目的不是要证明什么，而是为了把软件不能正常工作的预知风险降低到能够接受的程度
Phase 4 ： 测试不是行为，而是一种自觉的约束(mental discipline)，不用太多的测试投入产生低风险的软件上的
第38贴【2004－6－23】：软件测试自动化的概念
软件测试自动化，是一项让计算机代替测试人员进行软件测试的技术。他可以让测试人员从繁琐和重复的测试活动中解脱出来，专心从事有意义的测试设计等活动。如果采用自动比较技术，还可以自动完成测试用例执行结果的判断，从而避免人工比对存在的疏漏问题。设计良好的自动化测试，在某些情况下可以实现“夜间测试”和“无人测试”。在大多数情况下，软件测试自动化可以减少开支，增加有限时间内可执行的测试，在执行相同数量测试时节约测试时间。
软件测试自动化通常借助测试工具进行。测试工具可以进行部分的测试设计、实现、执行和比较的工作。通过运用测试工具，可以达到提高测试效率的目的。所以测试工具的选择和推广使用应该给予重视。部分的测试工具可以实现测试用例的自动生成，但通常的工作方式为人工设计测试用例，使用工具进行用例的执行和比较。
软件测试自动化的设计并不能由工具来完成，必须由测试人员进行手工设计，但是在设计是却必须考虑自动化的特殊要求，否则无法实现利用工具进行用例的自动执行。为此，就必须在测试的设计和内容的组织方面采取一些特殊的方法。
对于软件测试自动化的工作，大多数人都认为是一件非常容易的事。其实，软件测试自动化的工作量非常大，而且也并不是在任何情况下都适用，同时软件测试自动化的设计并不比程序设计简单。
第39贴【2004－6－24】：自动化测试的优点
通过自动化测试，可以使某些任务提高执行效率。除此之外，还有其它优点：
①对程序的回归测试更方便。这可能是自动化测试最主要的任务，特别是在程序修改比较频繁时，效果是非常明显的。由于回归测试的动作和用例是完全设计好的，测试期望的结果也是完全可以预料的，将回归测试自动运行，可以极大提高测试效率，缩短回归测试时间。
②可以运行更多更繁琐的测试。自动化的一个明显的好处是可以在较少的时间内运行更多的测试。
③可以执行一些手工测试困难或不可能进行的测试。比如，对于大量用户的测试，不可能同时让足够多的测试人员同时进行测试，但是却可以通过自动化测试模拟同时有许多用户，从而达到测试的目的。
④更好地利用资源。将繁琐的任务自动化，可以提高准确性和测试人员的积极性，将测试技术人员解脱出来投入更多精力设计更好的测试用例。有些测试不适合于自动测试，仅适合于手工测试，将可自动测试的测试自动化后，可以让测试人员专注于手工测试部分，提高手工测试的效率。
⑤测试具有一致性和可重复性。由于测试是自动执行的，每次测试的结果和执行的内容的一致性是可以得到保障的，从而达到测试的可重复的效果。
⑥测试的复用性。由于自动测试通常采用脚本技术，这样就有可能只需要做少量的甚至不做修改，实现在不同的测试过程中使用相同的用例。
⑦可以让产品更快面向市场。自动化测试可以缩短测试时间，加快产品开发周期。
⑧增加软件信任度。由于测试是自动执行的，所以不存在执行过程中的疏忽和错误，完全取决于测试的设计质量。一旦软件通过了强有力的自动测试后，软件的信任度自然会增加。
总之，通过较少的开销获得更彻底的测试，提高软件质量，这是测试自动化的最终目的。
第40贴［2004-6-25］：自动化测试中常见的问题
在软件测试自动化的实施过程中会遇到许多问题，以下是一些比较普遍的问题：
①不现实的期望。一般来说，业界对于任何新技术的解决方案都深信不疑，认为可以解决面临的所有问题，对于测试工具也不例外。但事实上，如果期望不现实，无论测试工具如何，都满足不了期望。
②缺乏测试实践经验。如果缺乏测试的实践经验，测试组织差，文档较少或不一致，测试发现缺陷的能力较差，那么首先要做的是改进测试的有效性，而不是改进测试效率。只有手工测试积累到一定程度，才能做好自动化测试。
③期望自动测试发现大量的新缺陷。测试第一次运行时最有可能发现缺陷。如果测试已经运行，再次运行相同的测试发现新缺陷的概率就小得多。对回归测试而言，再次运行相同的测试只是确保修改是正确的，并不能发现新的问题。
④安全性错觉。如果自动测试过程没有发现任何缺陷，并不意味着软件没有缺陷。可能由于测试设计的原因导致测试本身就有缺陷。
⑤自动测试的维护性。当软件修改后，通常也需要修改部分测试，这样必然导致对自动化测试的修改。在进行自动化测试的设计和实现时，需要注意这个问题，防止自动化测试带来的好处被高维护成本所淹没。
⑥技术问题。商业的测试工具也是软件产品，并不能解决所有问题，通常在某些地方还会有欠缺。测试工具都有适用范围，要很好的利用它，对使用者进行培训是必不可少的。
⑦组织问题。自动测试实施并不简单，必须有管理支持及组织艺术。
第41贴【2004－6－27】：测试自动化的限制
测试自动化可以带来非常明显的收益，但也有其限制，主要有：
1.不能取代手工测试
2.手工测试比自动测试发现的缺陷更多
3.对测试质量的依赖性极大
4.测试自动化不能提高有效性
5.测试自动化可能会制约软件开发。由于自动测试比手动测试更脆弱，所以维护会受到限制，从而制约软件的开发。
6.工具本身并无想像力
另外，人工测试比测试工具更优越的另一个方面是可以处理意外事件。虽然工具也能处理部分异常事件，但是对真正的突发事件和不能由软件解决的问题就无能为力。
第42贴【2004－6－28】：什么是应首先被自动化的测试？
软件测试的自动化过程是一个渐进的过程，并不需要一开始就对所有的测试进行自动化，这通常也是不现实的。如何选择首先被自动化的测试成了最先遇到的问题。
有些测试，完全没有必要进行自动化，因为自动化它们所需的时间比手工运行它们全部的次数所需的时间总和还长。例如，手工运行一个测试要10分钟，而且一般每个月运行1次，那么一年需要120分钟。但如果自动化这测试需要10小时，那么这个测试需要连续不断运行5年才能收回成本。
有些测试，虽然执行的时间不长，但过程繁琐，需要执行的动作非常多。比 如，一个运行10分钟的测试，可能需要击键150次，打开4～5个窗口，切换操作。如果将其自动化，可以提高可靠性，也是值得的。
对软件进行的功能性测试，是测试软件系统在做什么。这些测试可以明确的知道应该在什么情况下输入什么，会有什么样的输出。这样的测试是非常容易被自动化的，也能从自动化中获得较大的收益。
对软件进行的性能测试，包括在不同的系统负载下进行的测试。这些测试需要采用工具辅助完成，非常适合进行自动化。
如果在测试中，运行10%的测试需要花费90%的时间，那么将这10%的测试自动化是值得的。
以下列出了选择首先进行自动化时要考虑的因素：
非常重要的测试
涉及范围很广的测试
对主要功能的测试
容易自动化的测试
很快有回报的测试
运行最频繁的测试
应该注意避免一口气自动化太多的测试。太多的工作导致参与人员工作积极性下降，可维护性下降，增加工作的风险。寻找可快速制胜的测试，尽快让大家看到工作成果，有助于获得更多的工作支持。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
