测试需求管理

　　这个模块我们依旧可以理解它是作为测试需求管理的一款测试管理产品，不过这样的认为也得到产品功能的验证。比如我们可以配置需求的工作量，还可以通过需求管理项与计划或testcase，又或与缺陷的关联，那么最终结果可以分析出用例覆盖率、缺陷的探测率等一些指标显得有章可循，如下图。但是就如同TD的命运一下，这个功能在国内很多企业还是水土不服，试想一下，测试人员去牵头维护本来就不规范的需求衍生的测试需求，的确需要重新审视测试资源的配置与效果啰。

　　计划测试

　　正如之前文章所描述的一样，这个功能的确算得上Mercury系列测试管理工具的一大亮点，放在当下，也足以称道。用测试建模理念搭建出一个完整的测试架构，模块化的划分方式，对于用例管理与后期的测试执行起到重要的前提作用。

　　一直认为作商业性的管理系统，一定埋藏一些表面看似适用，但实际上意在激发使用者潜在需求的功能，如设计带参数的测试步骤、自动化脚本自动维护体现的淋漓尽致。试想没有配套的QTP或WinRunner，这功能不提也罢了

　　测试执行

　　测试执行实际上就是对之前定义的测试计划模型的实例化的过程。除了对测试用例执行人员、执行时间进行配置以外，还可图形化对执行工作流的配置。配合自动化测试工具自动调度脚本运行，并采集结果。这个功能除页面实现发生变化，其他的功能实现与TD无异

　　业务组件测试（部分观点来自于yangdaliang）

　　所谓业务组件，就是一种易于维护且可重复使用的单元，该单元包含执行特定任务的一个或多个步骤。业务组件可能需要来自外部源或其他组件的输入值，并可向其他组件返回输出值

　　QC引入"业务组件"的概念，有助于我们实现业务流程之间的组合，组合不同的组件实现不同的流程测试，规范业务流程，提高测试的覆盖率，这算是QC的扩展应用。

　　简单的说，业务组件模块功能与测试计划模块功能类似，只是一般企业不适合用业务组件这个功能，因为他需要业务人员参与到测试的整个流程中，而实际一般的公司这不存在这个情况。况且实际使用中这个还需要配合QTP使用。