测试执行阶段介绍.pptx

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