浅谈Quality Center测试管理

      很久没有这么认真的去研究一款测试工具了，之前学习和使用LoadRunner工具时让我比较专注，可是总因为个人在学习，没有讨论的对象，同时基本上对这个也都是半斤八两，着实让我有点力不从心。毕竟学习还是需要相互交流和讨论才能知长短，才能有进步和发展的空间，所以这次我学习QC就比较有底气了，因为跟大家一起学，相信这样的方式提高起来会比较快。

      其实作为一名测试人员，要了解的知识远远多余一名开发人员，知道现在我也才真正明白这个结论，要想成为一名高级测试工程师，必须从事几年开发工作才行，只有这样才能既有深度也有广度，既要参透客户的心理，也能把握开发的方法。这样来执行测试工作才会两者兼备，不拘一格。不过说真的，测试技术现在也是突飞猛进啊，谁说国内不求质量，但毕竟还是跟老外比测试，小巫见大巫，就如人家微软一名开发对应三名测试，换着国内，好比我们公司来说吧，一名测试对付一群开发，这就国内的现状～～呵呵！既然如此，但只要有测试人员，软件质量还是不容忽视。现在所谓的自动化测试，开始成为新一代测试工程师们的未来方向，都会认为学好了自动化测试，就是一名高级测试工程师的标杆。其实我也是跟风者之一，我想这些都是市场效应带来的问题，因为只要你上51job一搜索，基本招聘测试的职位都是首先要求会自动化测试，当然就少不了自动化测试工具了，所以在国内目前这样一个现状，任何市场反应都是驱动行业发展的主导因素。基于此我也很快熟悉了所谓的自动化测试三剑客：QC、LR、QTP，不过说到这里，作为一名测试人员不了解这三款工具中的其中一款，那绝对就OUT了，至少在一般企业里面，只要开展测试就必须得去对测试工作进行管理，既然如此，QC也就是一款饱受好评的测试管理工具。因为之前在同事的引导下，我一直在TD的环境中提交我缺陷，直到这位同事最近离职我才开始有机会深入学习QC，也才了解到TD就是QC的前身，既然如此，之前我们用TD也就是作为一款BUG管理工具才用，现在才发现真是杀机焉用牛刀，因为QC的功能是在是太强大了。呵呵写了那么多，感觉是在写小说......

      好了，该详细谈谈QC 了。QC功能之所以强大，因为它的功能在整个测试流程，应该说是开发流程中都一一体现。首先是在需求管理阶段，通过用户提交的需求，经过需求分析人员、开发人员和测试人员三方审核之后，提交到QC的需求管理模块上，进行整理和分类。第二不分，根据需求模块的分类，制定测试计划，也就是所谓测试方案和用例，在这一部分中进行细化，并且如需求模块中的每个需求进行关联，这样就形成了一个上下链接，只要需求有改动，计划就会随之改动。第三部分，业务组件，这一部分开始我也很不理解，后来跟同事一起分析得知，这部分主要是跟自动化测试工具LR、QTP进行联动，实现自动化测试框架体现，这里的业务组件一般用于回归测试，其实是一个业务流程，因为在任何一个项目中，需求中的业务流程一般都是确定的。第四部分，就是测试实验室，这里就是给大家做实际操作的工作室，也就是我们通常所说的执行测试用例，这里是跟前面的需求和测试计划进行管理的。第五部分，就是缺陷管理，这里就很明了了，对每个执行测试用例之后产生的BUG进行提交，并指派给开发人员修复，并最终关闭。这个模块也是跟前面的每个环节联动的。所以QC的管理就因为上下联动而变得简单，并且非常容易管理，只要其中任何一个模块中的一个字节点发现改变，系统就会已邮件的方式通知相关用户，并且跟随联动的其他模块就得到了及时更新。

      不管你是一名测试员，还是一名测试部经理，熟练地掌握QC工具，你的测试工作将会变得非常简单。