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

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

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

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

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

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