更准确地评价产品质量?

 

1       概述

测试是衡量产品质量的一把尺子,《TPI Next》中对测试的理解是“Testing is a process that provides insight into, and advice on, quality and the related risks.”

测试结束后总是要给出对产品质量的一个评价,供利益相关人做相应的决策。(关于测试是提供对产品质量的信息,而不是产品发布的决策者这一点之前在这篇blog中已经阐述。)当然,测试对质量给出评价的形式可能有很多种,可以陈述具体的问题和风险,也可以同时给出你对被测系统的评级,下表是一个简单评价形式。

本文重点讨论表中第二列的质量评级(A/B/C/D)如何更准确地给出。

2       问题: 测试人员如何准确的评价产品质量?

2.1问题描述

我们先来审视一下传统测试过程的输入-需求。当然,不同企业拿到用户需求后的处理流程是不一样的(比如Agile or V model),开发和测试的组织结构也是不一样的(比如是按照模块划分team还是按照特性划分team;开发team和测试team是一一对应还是有所交叉等等),下图表现的是只是其中一种可能的、简化的、典型的过程。

如上图所示,需求(Requirements)是测试的重要输入,通常我们用DR(设计需求),因为OR(原始需求)比较粗,too general。经常的做法是,将这些DR按大类划分到几个Test Feature中,每一个Test Feature可能同时由不同的测试小组负责测试设计和测试执行,当然,各个测试小组的侧重点是不一样的。每到一个测试里程碑点,各个测试组都会根据各自的测试情况(问题发现、测试用例执行率等)对所负责的Test Feature给出测试的评价,A/B/C/D,以及相应的陈述。当然,每个组织应该定义一套统一的A/B/C/D的标准供大家参考。

问题是,每个特性的A/B/C/D的结论是否准确?所有特性的A/B/C/D的结论加一起又如何判别整个系统的质量?是否所有特性的都是A或B,版本就可以对外发布?测试人员给出的A/B/C/D有多大成分是基于一种feeling给出的?

2.2      问题分析

这个问题其实比较大,和很多方面都有关系,我在另外一篇blog里谈到的通过Incremental Analysis & Traceability的方法确保测试的有效性,从而可以进行较为准确的质量评估,本文试图从另外一个角度探讨这个问题。

对于任何一条DR,开发人员的任务是比较明确的,实现它就可以,无论是由一个项目组实现,还是多个项目组配合实现。但是,对于测试人员,考虑的事情就复杂一些。我们除了要验证DR本身的功能实现是否正确,还要验证该DR和其它功能之间的交互,还要考虑客户可能使用的各种场景(Scenario),可能一个测试特性,涉及到多种组网场景、各种参数配置、兼容多种外部平台等。如果把测试场景和测试特性交互起来,测试就endless了,并且也没有必要在每一种测试场景下,都验证被测特性的基本功能、异常功能、与其它功能的交互、非功能属性等各方面。如何设计更有效的、有限数目的用例尽量做到最大的测试覆盖,这属于另外一个话题,本文先不探讨(其实关于这个问题,有多种思路,比如Richard Bender提出的基于需求的测试、比如我提出的MFQ&PPDCS也是一种)。测试设计人员基于测试经验,同时考虑外部商用信息等,尽量的考虑到他/她认为应该考虑的场景和功能交互,从而设计用例。测试执行人员为了尽可能的测试全面,经常变换组网环境、参数配置,试图尽最大程度的减少漏测,这可能是很多测试团队的现状。

某一个阶段的测试结束时,测试人员如何评价这个特性的测试质量呢?毫无疑问,尽管测试设计人员和测试执行人员精疲力尽的试图覆盖所有的场景,测试人员仍然只覆盖了一小部分的场景下的该特性的部分测试用例,如果没有Fatal的遗留问题,是否就可以评价为A或B,并且认为可以对外发布了呢?这个问题经常困扰着很多测试人员。我们不知道针对这个被测特性的“测试全景图”,从而评判出我们的测试已经覆盖了X%;即使知道了这个数据,也不清楚这样的测试覆盖和测试结果是否可以达到“对外发布”的标准。

2.3      换一种做法

08年我和一些来自瑞典的测试专家交流过这个问题,当我提出这个问题时,他们给我的答复出乎意料:既然无法做到全覆盖的测试,就不去做,不要试图在现有的测试模式下,设计和执行都投入很大精力去覆盖各种场景和交互,因为这样收效甚微,依然达不到目的。

那么怎么做呢?他们建议:FT (Function Test)功能测试环节只做最普通、最典型、最重要场景下的功能验证,保证每个测试特性的基本功能OK。然后开展模拟用户真实使用场景的测试(暂时把它称作UBT,Usage Based Testing),主要考虑各种configurations、scenarios,用simulator模拟真实用户/商用组网环境和以及真实的业务模型,也就是说,simulator可以模拟环境configuration,也可以模拟实际业务。当然,做UBT时,首先开展的还是针对老特性的Regression Test,然后在增加具体的业务时,逐步增加新特性涉及的业务类型

假如被测系统如下图的方框,灰色的小块就是我们的FT测试覆盖,很多团队都会投入很大精力试图尽最大能力增加这些灰色小块的覆盖,但依然会有很多覆盖不到的地方。而UBT就相当于红色的范围,虽然没有针对性的设计测试用例,但由于模拟了可能使用的商用场景和业务,业务之间交互的测试在这种测试环境下自动进行,潜在的一般的bug都被自动发现(比较难触发的异常bug依然发现不了),如果这样的UBT连续执行数天都没有问题,此时可以很有信心的说,版本稳定到可以对外发布了,这意味着用最少的人力、获得了最可信的测试效果。

2.4      解决建议

所以对于比较复杂的被测系统,与其不遗余力地做无穷无尽的测试覆盖,不如换一种思路,增加一种测试分层-UBT,让很多复杂的交互场景自动覆盖到、让很多很可能出现的bug自动冒出来。

不过,要明确的增加一个UBT环节,并非易事,一旦决定要这样做,意味着更多money、time、people的投入,意味着Regression test的加强,同时会有很多问题和困难需要克服(比如探索如何模拟Configuration,然后逐步增加Traffic的模拟,逐步改进)。下图示意了一种可能的演讲过程:

当模拟用户使用场景的UBT做到比较满意的阶段后,也许测试人员可以更准确的评价产品的质量:需要在FT报告中,从测试特性角度,只给出典型场景下的各特性测试结果的评价;在UBT报告中,从系统角度,给出更多场景下的整个系统的验证结果,例如“XXX产品在XXXX配置的场景下,连续运行XXX天,没有发现严重的问题,可以对外发布”。

 《更准确地评价产品质量?》有 7 条评论

  1. 天堂旅人说:

    如果真的按这样的模式测试,那么,我们的一大部分测试人员是否应该在客户那边,帮助客户去测试系统了?部分职责有点类似于我们部门的支持人员?

    回复

    • 邰晓梅说:

      其实,测试人员不就是帮助客户在测试产品吗?
      UBT只是所有测试的一部分,是否是大部分测试人员,取决于你们产品的测试上下文。
      之所以做UBT,是因为这样的测试更贴近真实用户使用场景。
      UBT需要很强的技术能力以及业务领域知识,与support people不一样。

      回复

  2. 天堂旅人说:

    我之前碰到过一些内存泄露以及高度并发下几个月才出现一次的问题,即使在真实环境上也要几个星期甚至多个月才能跑出来,这样的风险该如何解决呢?

    回复

    • 邰晓梅说:

      除了真实的用户环境,这种问题在UBT的环境下是最适宜发现的。
      在构造UBT用户典型场景、及模拟业务模型时,要考虑可能的风险。
      没有人什么方法可以保证能发现这样的问题。

      回复

  3. 里米特说:

    要看公司对质量的要求有多高。
    保持盈利1周要发1-2个版本,FT的测试时间都非常紧,这样的测试是奢望而且成本太高,我们的做法是增加白盒测试,从代码角度评审改动可能引发的风险,缩小黑盒的测试范围,包括楼上说的是否有内存不释放,没有初始化或没有删除之前的缓存数据而引发的一段时候后的性能问题,导致服务器无法正常工作等。

    回复

  4. 里米特说:

    补充一下,在游戏测试领域,这种测试是上线之前必须走的过程,也就是Beta测试,召集几百个玩家测试,让他们优先体现新版本,通过反馈bug可以得到奖励的制度。

    回复

  5. 熊锐奇说:

    UBT 如果在互联网或游戏领域,很好做,发布一个beta版本,让用户和玩家去玩,从而收集信息;
    在应用软件或ERP领域,建议产品经理去调研、收集和梳理用户的使用场景,形成清单(相对来说这些领域的用户需求和场景短期内变化不大),测试基于此细化用例,进行使用场景的覆盖。但测试如何细化用例,需要探讨。

Comment Box is loading comments...