测试执行阶段介绍

缺陷分布
修复情况
趋势分析
在一个完整的测试项目周期中，缺陷发现和解决趋势应遵循着一种比较 好的预测的模式，并且假定有足够的开发和测试资源保证缺陷是能够立 即得到解决，因此，理想的缺陷趋势应该是这样的： －在测试执行周期的初期，缺陷增长很快，达到顶峰后，将随时间以较 慢速率下降。 －大幅缺陷的趋势会不断增长，逐步逼近累计发现的缺陷 如果新缺陷的发现在测试执行后期反而趋于增长，或缺陷发现的顶点处 于测试执行后期，甚至到计划的测试结束点还未出现缺陷发现顶点，则 很有可能说明测试策略存在一定问题，没有优先测试可能存在较多问题 的特性。 如果关闭缺陷的趋势远落后于打开缺陷的趋势，则说明缺陷修复所需的 资源或再次测试和确认修复所需的资源可能不足。
测试缺陷管理总览
在测试执行过程的管理工作中，测试负责人主要关注两个基本点：测试 用例执行情况和测试缺陷发现情况。 通过缺陷管理支撑工具，我们可以动态观察“bug的一生”－缺陷发现和 解决情况，从而定性的评估产品测试质量和缺陷修复质量，为测试策略/ 计划的实时调整提供依据：
趋势分析
修复情况
缺陷管理 支撑工具
测试用例执行管理
在测试用例执行管理中，主要关注以下5个目 标：
控制进度
用例质量 测试用例执行 管理工具
测试覆盖度
开发质量 执行效率
控制测试用例执行进度
通过测试用例执行进度曲线，可以反映出版本测试用例分配策略的情况 控制测试覆盖度 在多轮版本情况下，往往只关注单个版本的测试用例执行情况，而忽视 整个产品的测试用例执行覆盖度，从而发生漏测、重测，带来不少的测 试风险和测试浪费。
测试执行阶段介绍
目录
测试启动评估 测试用例执行 测试缺陷管理 测试结束评估
测试执行阶段流程
组织缺陷修复和单板改板 开发支撑组经理 软件缺陷修复 软件开发工程师 大规模逻辑/缺陷修复 单板硬件改板 组织开 工会 转测试 Y 评估 N BACK 准备SDV测试报告 测试小组组长 组织SIT/SVT执行 缺陷 分析 准备SIT/SVT测试报告
测试用例执行
测试执行的闭环过程 测试执行活动是整个测试过程的核心环节，所有测试分析，测试设计， 测试计划的结果，将在测试执行中得到最终的检验，它包括以下5个环 节：
测试用例执行
测试用例分配 测试缺陷管理
执行进度跟踪
测试策略调整
测试用例分配
在进入测试启动评估环节之前，由测试经理或测试小组长依据测试执行策略进行 测试用例的分配，需要考虑的因素有： 需要测试的新增特性用例 －新增特性的所有测试用例是否都在这一版本完成测试 需要回归的特性用例 －新增特性所影响的哪些旧特性需要回归 特性之间的交互 －各特性之间的组合、冲突、依赖关系如何？ －那些特性的用例执行可以合并、合作、分离？ 测试用例的执行进度 －哪些高优先级的用例首先被执行？ －大概每天执行多少测试用例可以达到预期的进度？ －是否需要设置测试用例执行的缓冲区以防止意外事件？
范围
覆盖度 100％
用例总 数 18
passed 4
investig ated 0
failed 12
blocked 2
unavail able 0
防火墙
观察用例质量
我们不能指望在测试执行过程中通过撞大运的方式来发现缺陷，最终的 测试质量应该通过测试设计来保证，但从测试设计过程中我们无法知道 通过这一大堆的测试用例执行究竟能发现多少缺陷，测试用例的冗余情 况如何。通过观察测试用例发现缺陷的情况，我们可以大致评价用例质 量的情况，尤其对于新增特性。 计算测试执行效率 单位时间执行的测试用例数并不能说明太多问题，无论执行的快慢，都 无法直接判定当前情况的好坏，但这个数据却为测试执行进度的估计带 来了方便，同时也反映了不同特性的执行难易程度，为将来的测试策略 调整提供依据。 反映产品开发质量 除了观察用例执行结果的分布图以外，由于新特性的增加，往往会给老 特性带来麻烦，原来测试OK的用例变的不可知了，通过观察测试用例执 行结果的变迁，我们可以间接的反映产品的开发质量。
测试结束评估概述
测试结束评估包括产品质量评估，测试过程 能力评估，测试退出评估：
产品质量评估：通过各类缺陷分析手段，完成产品的质量分析，为产品 的质量评估提供客观、全面的依据，为测试结束提供可靠的依据。 测试过程能力评估：通过测试过程度量，评估测试过程目标达成情况， 分析测试过程能力的改进措施，聚焦于过程管理能力的提升。 测试退出评估：根据产品质量评估与测试过程目标达成情况评估的结果 ，结合实际的测试进度，评估测试退出的可行性。
wenku.baidu.com
测试启动评估
为什么需要设置测试启动评估环节
－ 在产品级测试过程中，测试组为了准备一个版本的测试，将投入很大 的成本，包括测试环境、测试人力资源等，这种投入将随着产品特性的 增加，测试环境的复杂化而不断膨胀； 测试启动评估的目的不在于评估开发人员的工作绩效，而是在于控制版 本的转测试质量，尽量减少前期不成熟的版本对测试资源的浪费； － 通过牺牲短期的内部控制成本（转测试评估和预测试），可以较好的 避免后期浪费大量测试投入的风险。
缺陷分布
漏斗效应：在同等测试条件下，一个产品前期发现的缺陷越多，遗留到 后期的缺陷也可能越多。 在测试过程中，我们往往通过一个产品中不同特性的缺陷分布来评价特 性质量的高低，从而调整测试策略和开发策略，将主要精力投入到“重 灾区”。
修复情况
如果一个版本存在很多未解决的缺陷，即使我们已经测试饱和了，我们 仍然无法放心的在这个版本上新增特性或进行版本发布，这就需要我们 定期关注版本中的缺陷解决情况 并不是所有的缺陷都必须得到马上修复，在资源有限的情况下，我们需 要对重点特性的缺陷做额外的关照，这就需要我们准确把握每个特性未 解决缺陷的分布情况。
Sys level verification
SDV
说明
SIT测试从生产线上生产出来的最初的产品（SDV测试是在实验室中测试 产品的原型），验证产品是否达到最初的功能要求，包括： 系统功能、性能、容错性、可用性、安全性、包装测试、网络运行测试 （包括内部、外部设备网络运行测试） 如果最初的产品和产品原型没有区别，那么SIT测试阶段可以省略，所有 的测试活动都在SDV测试阶段进行。 SVT测试执行 核查生产过程，确保产品在大量生产时设计仍能保持完整性 SVT测试执行的环境必须是典型的用户要求的环境 如果需要的话，其他要求的特殊的测试也在SVT测试阶段完成 测试项目包括：电磁兼容性（EMC）抽检、环境抽检、安全抽检、回归 测试、一致性验证和需要的特别测试。
测试启动评估测试主要评估的内 容
－根据给定的版本测试时间及测试用例分配结果，结合测试执行能力基 线，评估本轮测试需达到的覆盖度 －根据覆盖度确定本轮应发现缺陷的阶段目标 －评审各特性用例分配情况是否合理，是否存在极不均衡现象，是否存 在过渡测试？是否存在部分特性无法完成测试？ －评审测试执行计划时间安排的合理性
测试用例执行态度
测试执行的主要目标是尽可能的发现产品的缺陷，而不是达到测试计划完成率， 如果过于关注测试计划完成率，而不重视测试执行的质量，会导致测试完成后仍 没有信心，需要重复测试，加大了测试冗余度，从而造成累计测试进度的延迟或 缺陷的逃跑，后一种情况往往更严重： “急功冒进” －在测试过程中仅关注测试用例的执行结果，忽视执行过程，出现的各类异常现 象，如来自告警、日志、维护系统的异常信息。 －只重视缺陷的发现，却不注意测试结果是否可靠，缺陷报告是否清晰，垃圾缺 陷单误人误己。 “好记性不如烂笔头” －为了赶进度，在测试结束后才集中提交缺陷报告，测试环境已经今非昔比，缺 陷现象无法描述的非常详尽，并且贻误了缺陷解决时间。 “教条主义” －机械的执行用例，缺乏发散型思维和逆向思维。
更新测试与验 证计划
阶段结束会
测试小组组长
测试工程师
优化测试设计 （方案和用例）
SDV执行 SDV执行
Beta
Build A Build C Build B Build E SIT SVT
Module（s）
Build D
SW/HW develop
Module level validation
Building block integrate test
在正常的情况下，一个测试启动评估过程主要经历5个环节：
开始
测试组预测试
版本经理创建 转测试评估任务
提交转测试评估意见
版本经理提供代码 规模、配套文档、 预测试信息
转入测试
测试经理提供测试 计划、测试文档准 备信息
测试启动评估的常见问题
版本配套信息不正确 －测试组面临多个版本信息接口，存在不少主机软件、硬件、单板软件 、逻辑等版本信息不统一的情况 测试组的预测试投入太大 －没有专门的预测试环境，每次预测试要重新搭建，仅仅使用手工预测 试的成本太高 测试组没有区分预测试和全面测试 －在预测试过程中急于投入深层次测试，指望这些问题能够把版本打回 即使测试启动评估结果很差，版本仍然转入测试 －迫于各方面压力开展版本的全面测试，结果在测试过程中被各类问题 困扰，没能按照既定的测试策略做好测试覆盖。
硬件开发工程师
测试经理
组织SDV执行/ 组织资料测试方 案、用例设计 SDV测试执行 资料测试方案与用例设计
缺陷 分析
测试工程师
自动化测试技术支持 自动化工程师
测试工具维护
测试执行阶段流程
TR4A/TR5 更新E2E计划 开发代表
开发支撑组经理
更新开发支持计划
测试经理
度量分析
SDV测试总结
优化测试策略