从方案到用例再谈测试覆盖——改进决定成败

从方案到用例再谈测试覆盖——改进决定成败

     写这篇文章的目的来源于近半年来对高效测试过程的研究与心得。从大型项目测试经理试转到平台部门任部门经，职业规划发生较大转变，也让我更深层次的对整体管理有了新的入的认知与看法。如何做到效率测试呢？测试覆盖是必须要谈到的一个话题。成本、质量、时间是项目管理的三个重要约束，有人曾用经济法则来衡量一个优秀的测试项目。它必定具有以下特点：一、交付周期短；二、一次性交付；三、强调方法。

我们在对超过50家企业的测试人员面试记录研究后发现，从规模在几百人的中小企业还是上万人的跨国公司，其测试体系中的核心部分几乎完全一致。但从最终交付的结果数据来看，交付能力却差异距巨大。是什么原因造成一个模子出来的理论其实际效果却千差万别呢？

从咨询公司的一份调查报告来看，大部分企业对基础体系建设工作往往都充满热情。但在实践过程却经常忽视对过程指导方法的梳理与归纳，这种缺失使得基础体现无法有效发挥其实际作用，更多体系被当成摆设存在，被冠以浪费时间、浪费精力的恶名。从研究PMP管理思想中我们发现，西方管理思维与中方管理认知上有着本质区别。从测试管理的角度出发，用例命中率是我们普片关注的关键评估维度。邓小平同志曾用一个形象的比喻来描述这种差异。不管是白猫、黑猫，抓的住老鼠就是好猫！中国的项目管理往往不重视方法论的引导，更侧重于实际效果。这里当然不是想攻击某些人的看法，实际效果是我们必须要抓住的重要考核指标。但如果抓到老鼠就是好猫，这样导向可能让我们失去很多提升机会。本文的核心就是想针对解决方案及管理思想与大家做一次探讨。

现在，我们从传统工作模式引发的问题来思考如何高效的进行测试设计？

首先，来看看我们产品的一些特点和现有的测试设计模式。

产品特点（华为火车版本的特质，短平快，要求快速交付，需求变化大）：

1.周期短：3个月一个大版本，火车版本众多；

2.需求多：一个大版本，包含30-90个需求；

3.复杂度高：组件化程度高，要求快速集成；

4.响应快：从需求到设计，平均为周期为2周左右；

5.接口多：与核心网设备均有接口；

6.配置多：定制化需求多；

7.安全性：接入国家安全系统；

8.质量要求苛刻：万分之一出错概率，海外均是战火纷飞（实施长、威胁大）；

传统工作模式：需求规格->多次评审->测试需求->特性需求->测试用例

我们一般采用矩阵管理对原始需求及测试用例进行双向跟踪。当《需求规格说明书》第一次被基线时，测试设计过程组正式启动。测试设计人员通过对《需求规格说明书》多次评审，达到对整体项目需求把控与熟悉。评审过程是交叠或者瀑布的，项目需求渐进明细的，产品目标越发清晰。测试团队常见介入时机是在《需求规格说明书》基线以后。

接着用例设计组根据这些以测试需求作为指导框架提取测试特性。测试特性被有效离散与控制，并有序归纳起来。最终的设计者开始编写测试用例，一个用例可能覆盖多个特性，而每个特性将应不同的用例观察点。以此，用例设计阶段告一段落，这种用例设计方法是双向追溯的，需求与用例能较好的结合起来。且如果发生变更，我们便能从容的由复杂业务中梳理出相关特性，并最终仅以很小的代价就能完成这些看似繁杂的工作。

这个过程看似非常完美，但在使用过程却暴露了一系列问题，甚至有时候会让我们感到沮丧：

首先：设计过程缺乏记录，分析者与设计需要同一人完成，无法由两个组来完成；

其次：语言过于精炼，不利于评审，开发人员难以理解；

最后：测试特性过于零碎，难以归纳测试方法，如：同一项目可能存在多个同一类型的测试点；

在这样的背景下，新的决绝方案即是要解决这些问题。在与华为合作的五年之中，我们对精细化管理过程日趋成熟。随着产品团队的不断扩大，组织结构显得尤其重要。

由此，我们要做第一件是规划一个合理的组织结构。将不同水平的测试人员高效的组织起来，使技能分层达达到高度协作：

组织结构：DSE –> DTE -> TSE -> PM -> TL -> TE

这里需要注意几个角色：

DSE : 这个角色主要是负责项目整体技术方案（包括：测试点分析、关键技术测试难点分析）。

DTE : 这个角色意在辅助开发人员进行单元测试，他们将最基本的问题封堵在内部版本转测试之前。

TSE : 这个角色需要具有3年以上设计人员承担，成员数量随项目大小而进行规划，人员必须各有所长，一般为虚拟矩阵（可能来自不同项目人员组成）；

第二步，管理模式改良，以解决设计过程缺乏记录的问题。

    改良式的矩阵式管理，仍然延续双向追踪模式。加入了一些新的过程组以进行改良。我们来看看这个模式的工作原理。

    首先，在需求管理模板改良：增加原始需求、测试需求、需求变更统一变更模板。该模板流转于整体项目管理过程中。开发、测试、QA对同一模板进行维护，需求一旦变更立即对该表更新。该模板的变更，改变了以前多表维护、数据混乱的局面。

    其次，在需求评审阶段进行改良:增加了DSE及TSE两个角色，对需求的算法及实现全程跟踪。测试人员全程参与需求与设计过程，对算法及设计方案进行深度评估。DSE负责组织开发人员进行讲解，TSE负责安排测试人员进行跟进。测试方案组跟踪全程需求修改，并及时调整测试方案。

    最后，测试方案模板改良：增加测试对象分析过程、测试框架、观察点三个字段。以下我们来看一个例子：

模块拆分

测试对象分析

内容分析计数规则

计数规则：

阈值告警规则：在分析时间片内（可设置：1-60分钟），同一主叫发送的垃圾短信内容达到该关键字所设阈值，如：0级100条，1级50条，即产生该级别告警。

计数清零规则：在分析时间片内（可设置：1-60分钟），达到0级阈值则告警清零重新计数。

无告警清零规则：在分析时间片内（可设置：1-60分钟），如果在时间片内发送的告警一直没有达到阈值，则在已设置滑动分析时间片末，告警清零重新计数。

内容分析时间片

　

测试框架

测试需求

观察点

优先级

计数规则

分析时间片达到阈值

系统管理查询
数据表查询
配置变更包
业务流测试

M(中优先级)

　

分析时间片内达到0级阈值
告警清零重新计数

M(中优先级)

　

分析时间片内未达到阈值1级
在滑动分析时间片末，告警清理重新计数

M(中优先级)

引入测试对象分析，将原有测试用例分析过程及需求变化过程有效的记录下来。测试方案由于一本操作说明，详细而规范的记录了所有数据的应用规则。

引入测试框架管理，将对象分析点浓缩精炼，便于项目团队进行评审与完善。

引入测试观察点，防止用例设计和测试执行人员过程中产生遗漏，造成不必要的损失。

    通过上述两个步骤的改良与优化，新的控制体系解决了我们前期操作中的困惑与问题。使得我们广东三期版本得以高质量的交付。整体版本漏测率下降了12%，问题DI值整体下降了30%。