• 软件测试之成品测试


    GMV: Golden Master Verification Test, 即通常说的成品测试或介质测试。它的测试目的一个是保证客户拿到的成品没有质量问题,从软件发布的角度来说,即保证客户能够顺利安装并使用产品生产部门提供的光盘或者网上下载的应用程序进行产品;另一个目的是保证产品在前期缺陷修复过程中不会因为代码改动而产生新的问题。

    注意:在此阶段不要运行新的测试用例,保证GMV能在合理的时间(一般2~4周)内完成并成功交付给客户或投放市场。

    对于不同操作系统平台或数据库,调用的安装程序和启动的包装油可能不同,因此在成品测试阶段,应该尽可能涵盖所有系统平台和数据库,以保障客户在不同系统上的正常应用。

    成品测试范围及策略归纳总结:

      成品测试的测试案例必须是以前测试阶段测试过的案例,不应该有新测试案例或对新系统平台设置的测试
      所被挑选的回归测试案例要尽量能够涵盖程序的主要功能,确保程序的主框架没有由于前期代码改动而产生缺陷
      对于前期测试中发现较多问题并改动代码较多的功能部分,应多挑选一些回归测试案例进行回归测试
      性能测试一般选择最被广泛使用或者大型客户常用的平台。选择最简单的分支但尽量扩大分支覆盖的范围
      所有测试都应基于DVD或ISO文件安装应用程序,严禁用构建测试环境来安装应用程序并进行测试
      安装应尽量涵盖应用程序支持的所有系统平台及数据库类型还有安装模式
      由于时间限制,成品测试案例大约占前期测试阶段所有测试案例的5%~10%

     成品测试是各团队协同作战,一个团队的完成并不等于整体的完成。成品测试大约需要1~2周时间,对于每个驱动,大约需要2天完成。对不同的驱动,由于周期短,时间有限,每个测试团队根据情况有自己的测试策略。并不是每个驱动都要重新测试所有案例。

    对不同成品测试候选驱动测试策略:

      各团对必须完全测试第一个驱动,以后的驱动需要审时度势,看编码改动情况来决定测试范围。
      由于每个驱动都需要重新构建打包,因此每个驱动都需要进行必要的安装测试和构建测试,以保障没有重要文件的缺失。
      项目组决定的最终成品候选驱动,将会是客户最终拿到的产品。各测试团对尽可能在此驱动上重新完成重要测试案例,以防功亏一篑。
      迁移测试和个别安装测试(集群安装)案例测试周期长,极少受由于其他类别测试缺陷而修改代码的影响。因此在整个成品测试周期一般只需要测试一遍。
      由于大部分测试都会在两天内完成,为了有效缩短整个成品测试周期,第二个成品测试候选驱动会在两天后开始构建,而不必等待迁移测试和个别安装测试案例测试结束。

    -->在成品测试中,代码已经几乎被冻结,但由于可能存在一些新bug,还是需要修改代码,因此,大部分公司会开成品测试缺陷评判例会,在敏捷模式下,由于每天都有站会的存在,这个会议在成品测试期间可能单独开,也可能会在站会里同时开,后者会占据较多的时间。

    -->回归正题,为什么要有成品测试缺陷评判例会?因为成品测试阶段时间有限,且测试接近尾声,不适合改动大量代码以防给客户造成更大的损失,但是缺陷不可能完全不存在,因此,在此期间需要对发现的缺陷进行综合分析,并根据对客户的影响和其紧迫性提出相应解决方案。

    -->成品测试缺陷评判例会是怎么样一个会议?其实这个例会主要用来及时分析所发现的缺陷并根据缺陷影响给出解决方案。

    -->那么,谁会参加成品测试缺陷评判例会?一般项目经理都会要求各开发团队代表、各测试团队代表、客户支持代表甚至产品补丁版本项目经理一起参加。

    -->如何在例会中决定缺陷的最终解决方案呢?会议由项目经理组织,项目经理会通过听取各方意见来决定其最终解决方案。

    成品测试阶段对缺陷的综合分析要点

    缺陷是如何发现的。如果不是回归问题,为什么在测试前期没有发现,是否存在其他潜在的测试漏洞。

    有几种方法可以解决缺陷,每种方法的优缺点及客户的接受程度。

    缺陷修改对当前代码架构的影响,会影响到哪些测试团队。

    受影响的测试团队需要多少时间和人力来完成由于代码修改而必须运行的测试案例包括回归测试案例。

    如果此缺陷不在当前的版本里修改,将对客户和客户技术支持团队造成什么影响。

    客户对此产品缺陷的最大容忍时间大约多久。

    成品测试阶段对缺陷的解决方案

    在当前产品版本里修改缺陷,并按时交付给客户。

    在当前产品版本里不修订缺陷,尽快在产品补丁版本或小版本里修改缺陷,并尽快交付给客户。

    在当前产品版本里不修复缺陷,在下一个产品升级版本里修改缺陷。

    在当前产品版本里修改缺陷,但需要延迟交付时间。---这种情况很少见,也是产品项目都要想方设法避免的。

    质量检测报告

    质量检测报告时项目中需要完成并得到审批的一个重要文件。在项目初期,项目经理需要和各团队负责人共同制定产品质量检测计划。

    质量检测报告的内容

      项目特征:包括产品交付日期、项目大致介绍、人力物力数据、关键日期、潜在的产品介绍、开发流程等。
      产品用户体验:开发产品的可用性、可靠性、安全性、集成性、维护性等方面制定一些具体指标。
      性能指标:避免超负载、运行过慢等有害现象。
      产品试用版本计划:如果有此计划,需要列明试用版本交付日期(一般早于产品正式交付日期)和潜在试用客户名单。
      质量预见性指标:是产品质量保障的重要检测指标。通过对这些指标的制定,可以对开发和测试环节的流程,方法及范围起到有效的监督作用,主要包括:
        评审指标:对一系列方案、架构、案例、代码进行质量把关,能够有效杜绝严重的设计错误和测试漏洞。
        测试指标:判定测试来进行质量把关。
        项目退出指标:允诺的功能都完成了开发和测试,若是升级版本,还要求没有回归问题产生。
        延缓缺陷指标:延缓修复的缺陷不能超过总体发现缺陷的一定百分比,从而对产品所知缺陷率有总体控制,保证产品质量。
        源代码分析指标:评测源代码是否利用一些工具进行静态代码分析、架构分析、代码测试覆盖度分析,用于侧面判定产品质量是否有保障。

    最终审批

    项目最终是否和计划的项目特征相符,是否按照计划进行开发流程。

    产品用户体验的指标诸如可用性、可靠性、安全性、集成性、可维护性等方面是否达到要求。

    所有性能指标是否能达到计划的标准。

    缺陷分析

    贯穿整个项目测试过程,通过不断进行缺陷分析,来监控在开发和测试中是否存在问题和漏洞,并根据分析结果来调整测试范围和策略,防范于未然。

  • 相关阅读:
    Entity Framework 6 (7) vs NHibernate 4: DDD perspective(纯净DDD很难很难...)
    asp.net解决高并发的方案
    我所经历的SAP选型[转]
    为什么我不再用 .NET 框架
    Why I Left the .NET Framework
    Docker 传奇之 dotCloud
    ICE概述
    .NET Out Of Memory Exception
    iOS-申请邓白氏编码的超详细流程介绍
    .NET对象与Windows句柄(三):句柄泄露实例分析
  • 原文地址:https://www.cnblogs.com/Ribbon/p/4875242.html
Copyright © 2020-2023  润新知