QC是一个众所周知的强大的管理工具。许多测试爱好者都在追逐它并学习如何使用它。今天写这篇文章不是为了讲解如何使用，而是分析一下这个管理软件，让我们来看看测试管理的思路。事实上，工具不仅给我们带来了效率和便利，也给了我们流程上的指导。如果你有深刻的理解，你会发给我们一个很好的QC测试管理指南。好了，废话不多说，一起来看看吧！首先我们来看QC的整体管理流程图，如下图所示：看似简单的一张图，其实包含了很多内容。QC涵盖了从前期的需求管理到测试点的提取，到测试用例的形成、测试的执行、缺陷的跟踪和管理。也许这时候你会问，这有什么新鲜事吗？现在很多管理工具都使用这个流程，包括我们现在的流程。有什么好炫耀的？好吧，让我们认真一点。如果你熟悉QC，你会发现QC中的需求可以关联测试用例和对应的bug（这就是QC中将需求转化为测试的功能），在这方面非常实用。你为什么这么说？大家都知道，我们基本上是在和网络产品打交道，其特点是变化快，更新快。也许这个版本与以前的版本有很大不同。这是网络产品的一个特性，我们无法改变，但我们可以改变自己去适应它。说白了，按照QC的思想，我们会建立需求、测试用例和bug之间的关系。这样做的好处是当需求发生变化时，可以发现变化的需求涉及的用例和bug。如果你买不起昂贵的QC，我们可以这样做（个人看法，如有雷同，纯属巧合）：1.规范需求的格式，在需求中给出功能模块划分图和各功能的优先级。这样做的好处是，轮到测试人员分工时，可以按照需求中的功能模块图进行分工，避免功能重复或遗漏，同时，我们可以按照产品人员提供的优先级直接拿到用例中。在这种情况下，需求和用例之间存在关联。当然，这个协会是薄弱的，需要改进。2.测试用例的规范和测试用例的原子化。其实这还是QC的体现。在上一篇文章中，我们提到了功能模块的划分，所以在测试用例中，根据功能模块的细分，分解为原子状态。你为什么这么做？其实功能模块的划分就相当于QC中的测试点，我们继续将其划分为详细的用例。那么至此，我们就建立了requirements->testpoints->testcases关联。3.接下来，如何将用例与错误关联起来？您可以使用TestLink来管理用例。TestLink是一个开源的测试管理工具，可以与JIRA等缺陷管理工具集成，从而建立用例与缺陷之间的关联。老实说，TestLink是一个很好的测试管理工具，尤其是对于那些买不起昂贵的商业工具的工具，但我真的无法称赞TestLink的易用性。习惯就好了。好了，至此我们基于QC的思想建立了一个基本的管理流程，但是流程这里还需要加强，如何提高它们之间的关联性还是一个问题，尤其是当需求发生变化时，如何在最短的时间内管理它找到涉及的用例和错误。让我们继续关注QC用例的思想。我们知道QC可以和LoadRunner、QTP等HP测试工具很好的结合，在QC中调用和管理这些工具，那么这里就有一个用例格式和用例复用的问题。用例对于测试至关重要，因此用例的规范也是必要的。所以这里我就说一下UICheckList，功能测试用例和性能测试用例。个人一直认为，对于需要测试复用性高的UI和模块，我们可以将其设计成CheckList，这样看起来方便，执行速度快，维护成本低，可以立即使用。好方法。对于功能测试用例和性能测试用例，我个人更喜欢将功能测试用例的格式扩展为性能测试用例，这样它们之间的格式和关联性不会有太大差异。下图是我设计的一个性能测试用例。其实也是源于LoadRunner工具的思想。如果仔细观察，你会发现这个用例是功能测试用例的演变，与LoadRunner的测试过程非常吻合，从用例的信息到脚本设计再到场景设计到执行结果。并且测试结果也可以简单明了的方式体现出来。个人觉得很舒服，O(∩_∩)O~呵呵，写了好多。***我们将以QC自定义功能文章结束本文。QC比其他测试工具更受测试人员欢迎的原因之一是因为它具有强大的自定义功能，可以自定义字段、流程等，编写代码完成你想要的各种流程功能。这也体现了一个道理，任何管理流程都是灵活的，最好的管理流程不一定适合你。俗话说，适合自己的才是最好的。因此，当我们有了一个比较完善的测试管理流程后，就应该逐步将其个性化、人性化，而不是固步自封，加入新的元素，加入新的管理理念，展示给更多的人。只有空间才能不断推动流程的改进和完善。【本文为专栏作者“小强”原创稿件，转载请微信联系作者【测试求助日记】点此阅读更多本作者好文
