HP ALM/Quality Center/TestDirector

听海——sky

QC是很出名的强大的管理工具，很多测试爱好者都追逐着它，学习怎么使用它，今天我写这篇文章不是
讲解如何使用，而是通过分析这个管理软件来看看测试管理的思想，其实工具不仅给我们带来了效率和
便捷，更多的是给我们流程上的指导，如果你深刻理解你会发下QC就给了我们一个很好的测试管理指导
。好了，废话不多说，我们就来看看它吧！

首先我们来看下QC的整体管理流程图，如下图：



看似简单的图，其实蕴藏着很多内容。QC从前期的需求管理到测试点的提取，再到测试用例的形成，测
试的执行，以及缺陷的跟踪管理全部包括了。也许这时候你会问，这有什么新鲜的现在好多管理工具都
是这个流程，包括我们现在的流程也是如此，有什么炫耀的？

ok，那咱们就来点真格的。如果你熟悉QC，你会发现QC中的需求是能和测试用例以及相应的Bug关联
的（这就是QC中需求转化为测试的功能），就这点来说非常实用。为什么这么说呢？大家知道我们基
本面对的都是web产品，他的特点就是变化快，更新换代更快，也许这个版本就和上个版本有天壤之别
。这是web产品的特点我们无法改变，但我们可以改变自己来适应他。说白了，就是按照QC的思想，
我们来建立需求与测试用例以及Bug之间的关联。这样做的好处就是当需求发生变更时，能找到变更的
需求涉及
到的用例以及Bug。如果你买不起昂贵的QC我们可以这样来做（个人观点，如有雷同，纯属巧合）：

1、需求格式规范化，在需求中给出功能模块划分图，以及各个功能的优先级。这样做的好处是轮到test
er分工时可以根据需求中的功能模块图来划分，这样的话就能避免重复或遗漏功能，同时根据产品人员
提供的优先级我们可以直接拿到用例中来，这样的话需求和用例间就建立了关联，当然这个关联关系很
弱，还有待改进。

2、测试用例的规范，测试用例的原子化。其实这里仍然是QC中的体现，在上一条中我们提到了功能模
块划分，那么在测试用例中就根据功能模块的再次细分，分解到原子状态。为什么这么做呢？其实功能
模块的划分相当于QC中的测试点，而我们继续划分则分解成了详细的用例，那么到这一步，我们就建立
了需求—>测试点—>测试用例之间的关联了。

3、接下来这是怎么把用例与Bug关联起来？可以使用TestLink来管理用例，

TestLink是一个开源的测试管理工具能够和JIRA等缺陷管理工具集成，这样就建立了用例与Bug之间的
关联。说实话，TestLink是个不错的测试管理工具，尤其是对于无法购买昂贵的商业工具的工具来说，
但TestLink的易用性我实在不敢恭维啊，用起来超级无敌不顺手，但时间长了也就习惯了。

ok，到这里我们仿照QC的思想建立了一个基础的管理流程，但这里流程还需要加强，如何提高他们之
间的关联度还是个问题，尤其是当需求发生变化时，如何能在最短时间内找到涉及的用例以及Bug。

下面我们继续关注QC用例方面的思想。我们知道QC能够很好的和LoadRunner、QTP等HP的测试工具
结合，在QC中去调用和管理这些工具，那么这里就设计到一个用例格式以及用例重用的问题。对于测
试来说用例是至关重要的，所以用例的规范也是很有必要的。那么这里我就UI Check List、功能测试用
例和性能测试用例来说下。

我个人一直认为，对于UI方面以及经常要测试重用性非常高的模块，我们可以设计成一个Check List，
这样的话看起来方便，执行起来快捷，维护成本也低，拿来就能用，是个很好的方法。

对于功能测试用例以及性能测试用例，我个人比较喜欢把功能测试用例的格式进行扩充转化为性能测
试用例，这样他们之间的格式和关联性方面就不会有太大的差异了。下面的图是我设计的一个性能测
试用例，其实它也是源于LoadRunner这个工具的思想演变而来的。



仔细观察你会发现，这个用例就是功能测试用例的演变，而且非常符合LoadRunner的测试流程，从
用例的信息到脚本设计到场景设计再到执行结果能很好的体现出来。而且就测试结果也能简单明了的
反应出来，个人感觉看上去很舒服，O(∩_∩)O~

哦了，写的也不少了，最后我们以QC的自定义功能来结束这篇文章。QC比其他测试工具更受测试人
员喜欢的原因之一就是因为他有强大的自定义功能，能对字段、流程等进行自定义，编写代码来完成
你想要的各种流程功能。这也就反映了一个道理，任何管理流程都是灵活的，最好的管理流程并不一
定适合你，俗话说的好，适合自己的才是最好的。所以，当我们有了一个基本比较完善的测试管理流
程后应该慢慢的把他个性化、人性化，而不是一成不变的去死守，加入新鲜元素，加入新的管理理念，
给更多人的展示空间才能不断的去促进流程的改进与提高。