第 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 】：自动化测试的优点
通过自动化测试，可以使某些任务提高执行效率。除此之外，还有其它优点：
① 对程序的回归测试更方便。这可能是自动化测试最主要的任务，特别是在程序修改比较频繁时，效果是非常明显的。由于回归测试的动作和用例是完全设计好的，测试期望的结果也是完全可以预料的，将回归测试自动运行，可以极大提高测试效率，缩短回归测试时间。
② 可以运行更多更繁琐的测试。自动化的一个明显的好处是可以在较少的时间内运行更多的测试。
③ 可以执行一些手工测试困难或不可能进行的测试。比如，对于大量用户的测试，不可能同时让足够多的测试人员同时进行测试，但是却可以通过自动化测试模拟同时有许多用户，从而达到测试的目的。
④ 更好地利用资源。将繁琐的任务自动化，可以提高准确性和测试人员的积极性，将测试技术人员解脱出来投入更多精力设计更好的测试用例。有些测试不适合于自动测试，仅适合于手工测试，将可自动测试的测试自动化后，可以让测试人员专注于手工测试部分，提高手工测试的效率。
⑤ 测试具有一致性和可重复性。由于测试是自动执行的，每次测试的结果和执行的内容的一致性是可以得到保障的，从而达到测试的可重复的效果。
⑥ 测试的复用性。由于自动测试通常采用脚本技术，这样就有可能只需要做少量的甚至不做修改，实现在不同的测试过程中使用相同的用例。
⑦ 可以让产品更快面向市场。自动化测试可以缩短测试时间，加快产品开发周期。
⑧ 增加软件信任度。由于测试是自动执行的，所以不存在执行过程中的疏忽和错误，完全取决于测试的设计质量。一旦软件通过了强有力的自动测试后，软件的信任度自然会增加。
总之，通过较少的开销获得更彻底的测试，提高软件质量，这是测试自动化的最终目的。
