全国咨询热线：136-9172-9932
软件测试自学教程，本章主要讲解“软件测试在质量体系中的位置”，软件测试不仅仅是找出软件中的缺陷，它在软件质量体系中占有重要的位置，下面我们来讨论在能力成熟度模型和基于过程的质量模型中，软件测试所处的位置。
一、能力成熟度模型集成
CMMI(Capability Maturity Model Integration，能力成熟度模型集成)认证评估在过去的十几年中，对全球的软件产业产生了非常深远的影响。CMMI 共有五个等级，分别标志着软件企业能力成熟度的五个层次，如图2-1 所示。从低到高，软件开发生产计划精度逐级上升，单位工程生产周期逐级缩短，单位工程成本逐级降低。据SEI 统计，通过评估的软件公司对项目的估计与控制能力提升约40%～50%，生产率提高10%～20%，软件产品出错率下降超过1/3。
图2-1 CMMI 模型
第一级：初始级
初始级的软件过程是未加定义的随意过程，项目的执行也是随意的，甚至是混乱的。当然有些企业可能已经制定了一些软件工程规范，但若这些规范未能覆盖基本的关键过程要求，并且在执行过程中没有政策、资源等方面的支持，它仍然被视为初始级。
第二级：受管理级
根据多年的经验和教训，企业总结出软件开发的首要问题不是技术问题，而是管理问题。因此，CMMI 发展到了第二级，更强调软件管理过程，建立一个可管理的过程是很重要的，它可以将开发的过程重复，只有可重复的过程才能逐渐改进并使其成熟。受管理级的管理过程主要包括五个方面：需求管理、项目管理、质量管理、配置管理和子合同管理;其中项目管理过程又分为计划过程和跟踪与监控过程。通过实施这些过程，从管理角度可以看到一个按计划执行且阶段可控的软件开发过程。
第三级：已定义级
在受管理级定义了管理的基本过程，但并没有定义执行的步骤标准。在第三级则要求制定企业范围的工程化标准，并将这些标准集成到企业软件开发标准过程中。规定所有开发的项目或产品都必须遵守该标准过程，并且按照过程执行，当然在实际过程中，可以根据具体的项目对该过程进行适当的裁剪，但过程的裁剪不是随意的，在使用前必须经过企业有关人员的批准。
第四级：定量管理级
第四级的管理是量化的管理。所有过程需建立相应的度量方式，所有产品(包括工作产品和提交给用户的最终产品)的质量需要有明确的度量指标。这些度量应是详尽的，且可用于理解和控制软件过程和产品，量化控制将使软件开发真正成为一种工业生产活动。
第五级：持续优化级
持续优化级的目标是达到一个持续改善的境界。所谓持续改进，是指根据过程执行的反馈信息来改善当前已定义的开发过程，即优化已定义的执行步骤。如果企业达到了第五级，就表明该企业能够根据实际的项目性质、技术等因素，不断调整软件开发过程使开发过程达到最优。CMMI 模型中包括验证(VER)和确认(VAL)两大过程域，这两大过程域与软件测试有着紧密的联系，也是规范软件测试的两大过程域。
(1)验证(VER)过程域的目的是确保所选定的工作产品符合其指定的需求。验证过程域包括验证准备、验证执行和纠正措施识别。验证的对象包括产品和中间工作产品，验证方法是将待验证的对象与选定的客户需求、产品需求和产品组件需求加以比较。验证是渐进的过程，因为它发生在产品和工作产品的整个开发过程中，从需求开始验证，历经工作产品的验证，最终为已完成产品的验证。
(2)确认(VAL)过程域的目的是展示完全置于预期环境中的产品或产品组件是否满足预期的使用需求。
所有的产品都可在其预期环境中实施确认活动，例如：操作、培训、制造、维护及支持服务。所有用于工作产品的确认方法，也能使用在对产品和产品组件的确定过程中(在所有过程域中，产品和产品组件的含义包括服务和其组件)。工作产品(例如需求、设计、原型)存在于整个产品生命周期，应及早并逐步实施确认。
确认环境必须可代表产品和产品组件的预期环境，同时该确认环境也适用于工作产品确认活动的预期环境。
确认证明是指所提供的产品是否符合预期的使用需求，验证与确认很容易被混淆，验证是确定每个工作产品是否正确反映了特定需求，即验证确保“你正确地做了”;而确认是指“你做了正确的事”。确认活动使用与验证类似的方法，例如测试、分析、检查、示范或模拟。通常，确认活动包含最终用户和其他相关人员。确认与验证活动经常同时实施，且可能使用部分相同的环境。若有可能，实施确认应将产品或产品组件置于其预期环境中运行。确认可能使用全部或部分的预期环境，使用工作产品实施确认，可让问题在项目生命周期中通过相关人员的参与及早被发现。服务的确认活动可应用于工作产品，例如建议书、服务目录、工作描述和服务记录。
当在确认过程中问题被识别出来时，需要参考需求开发、技术解决方案或项目监控过程域的实践来解决。
二、基于过程中的质量
目前，软件项目需求正飞速增长，相应的软件开发活动也随之急剧增长，这样使得软件过程(即用于开发和维护软件及其相关产品的一组活动、方法、实践及转换)得到更多的关注。软件过程在成本估算、项目进度和软件质量等方面必须把握准确，同时产品必须满足用户对其功能和质量的要求，所以深入研究软件度量模型、建立基于度量的量化管理是控制软件过程、提高软件质量的有效保证。基于过程的质量控制如图2-2 所示。
图2-2 基于过程的质量控制
而软件测试是评估产品质量的重要手段，软件测试贯穿产品开发的始终，那么在整个软件测试过程中，应该如何来度量软件测试的质量呢?在整个测试过程中，质量度量主要包括以下几个方面：
测试覆盖率;
测试执行的质量和效率;
测试用例深度、质量和有效性;
缺陷分布分析。
(1)测试覆盖率。
测试覆盖率是指在测试过程中对被测试对象的需求、功能、代码测试的程度。主要包括对需求和代码两个方面的覆盖评估，但其实这两个方面的评估本质是一致的，都是通过测试用例来评估覆盖率。
1)基于需求的测试覆盖评估依赖于对已执行/运行的测试用例的核实和分析，其主要是通过评估测试用例覆盖率来评估，在测试过程中的目标是要求需求的覆盖率达到100%。在实际测试过程中，可以通过统计已执行的覆盖率和执行成功的覆盖率来评估需求覆盖率的值。
已经执行的测试用例覆盖率指所有测试用例中被执行用例所占百分比，公式如下：
已执行的测试覆盖率=Tx/Rft
其中，Tx 表示已执行的测试用例数，Rft 是测试需求的总数。成功执行的覆盖率指测试过程中执行成功的测试用例所占百分比，公式如下：
成功的测试覆盖率=Ts/Rft
其中，Ts 表示已执行并且执行状态为成功的测试用例，Rft 是测试需求的总数。
2)基于代码的测试覆盖率是对被测试的程序代码语句、路径或条件的覆盖率分析。代码覆盖可以建立在控制流(语句、分支或路径)或数据流的基础上，主要用于白盒测试阶段。控制流覆盖的目的是测试代码行、分支条件、代码中的路径或软件控制流的其他元素;数据流覆盖的目的是通过软件操作测试数据状态是否有效，例如，数据元素在使用之前是否已经定义。
基于代码的测试覆盖通过以下公式计算：
已执行的测试覆盖率=Tc/Tnc
其中，Tc 是指使用代码语句、条件分支、代码路径、数据状态判定点方法设计的并被执行的用例数，Tnc(Total number of items in the code)是指项目中总的代码数。
(2)测试执行的质量和效率。
测试执行的效率是指测试工程师每天执行的测试用例数，一般每天执行50 条测试用例。测试执行的质量包括两个方面：一方面是指每个测试用例发现的缺陷数;另一方面是指软件发布后遗留的软件缺陷数占总缺陷数的百分比，一般要求低于0.5%。
故测试执行的质量和效率一般使用以下指标来统计：
每人每天所执行的测试用例数;
每人每天发现的缺陷数;
缺陷遗留率。
(3)测试用例深度、质量和有效性。
测试用例是所有测试活动的基础，测试用例质量的好坏直接影响软件测试的质量。
测试用例的度量主要从测试用例深度(也叫测试用例密度)、质量和有效性三个方面来实现。当然如果开展了自动化测试，还可以从测试用例自动化的程度这一维度来度量。测试用例深度(Test Case Depth，TCD)指每KLOC(千行代码)设计的测试用例数或每个功能点所设计的测试用例数，一般情况下认为每KLOC 设计的用例数越多，表示测试的质量越高。当然必须考虑冗余或重复的用例数，在设计用例时应该尽量避免出现冗余或重复。
测试用例质量(Test Case Quality，TCQ)其实是一个很复杂的指标，它包括两个方面：一方面指如何设计一个好的测试用例;另一方面指测试发现缺陷的数量。
一般情况下，一个好的测试用例应该考虑以下几个方面：
测试用例覆盖程度;
测试用例是否已达到工作量最小化;
测试用例的分类、描述是否清晰;
测试用例是否表明目的;
测试用例的易维护性;
有充分的负面测试;
测试用例没有重复、没有冗余。
发现缺陷方面主要是指测试用例发现的缺陷数量，公式如下：
TCQ=测试用例发现的缺陷数量/总的缺陷数量总的缺陷数量除了测试用例发现的缺陷数外，还包括通过ad-hoc 测试(随机、自由的测试)、集体走查(Work-through)和Fire-drill 测试(类似消防训练的用户压力/验收测试)等其他手段发现的缺陷。
企业开展自动化测试，可以计算可自动化测试用例的数量，这也是衡量测试用例质量的一个方面，将手动测试用例转换为自动化测试用例可以节约写自动化测试用例的时间，可转换的越多，节约的成本就越多。
(4)缺陷分布分析。
缺陷是测试过程中体现工作效率和价值的重要指标之一，也是分析系统质量的重要指标。在测试过程中除了要提交缺陷外，还需要对缺陷的分布情况进行分析，这样可以作为改进系统质量的依据。在提交缺陷时，需要注意一些必需的元素项，即一个好的缺陷通常需要包含的内容，现在一些企业通常会使用缺陷管理工具来管理测试过程中所发现的缺陷。对提交的缺陷需要进行分析，这样可以进一步改进系统质量，并且可以改进测试方法和测试策略，常用的缺陷分析方法有：ODC 正交缺陷分析法、Gompertz 缺陷分析法、Rayleigh 缺陷分析法、四象限缺陷分析法和根源缺陷分析法，具体的缺陷分析法在第7章详细介绍。
本章主要介绍了关于“软件测试在质量体系中的位置”的内容，大家觉得有用的话，记得每天来这里和小编一起学习涨薪技能。识别下方二维码，免费领取学习课件、视频哦。(笔芯)
附：川石信息全国校区最新开班时间，课程资料获取13691729932(微信同号)。
