使用 QC 本身存储函数库、存储库是否更好？

Question

我计划使用 QC 作为库、对象存储库和其他数据文件的存储库。我将执行 QC 的所有测试用例。如果我使用 QC 来处理这些，那会是更好的意见吗？执行速度会比平时更快吗？

注意：通常的方法是函数，本地存储库，只需更新 QC 中的驱动程序脚本并从 QC 运行它。

Answer 1

QC 上存储的任何内容都必须下载到执行 QTP 测试运行的计算机上。增加从 QC 下载的项目数量不会提高性能。

Answer 2

想了一段时间后，我决定提出自己的答案：

如果您

• 与多个人一起进行 QTP 测试，
• 和/或在多于一台或两台机器上执行测试，
• 和/或使用 QC工作流脚本功能来跟踪测试的状态（或其他属性）
• 和/或想要做的不仅仅是使用 Run/F5 从 QTP 直接（“交互地”）执行测试
• 和/或想要使用 QC 的版本控制来进行 QTP 测试（呃..）

那么强烈建议将测试放入 QC，因为

• 中央存储库在这种情况下很有用，
• 这是使用 QC 的需求树、测试实验室和缺陷管理器以及自动化测试集成（包括图形/报告）的唯一方法设施。

在 QC 中使用它们的最大缺点是，您

• 将永远不会再看到这些测试的可用分层文件系统（但是嘿！没有 QC 的 QTP 是否会为每个测试创建一个有用的文件系统？不！），
• 因此必须通过以下方式执行所有操作QC 界面（忘记使用 Windows 资源管理器删除或复制树）
• 将付出性能损失，因为每次打开或保存操作时，测试都必须从 QC 传输到本地文件系统或从本地文件系统传输到 QC。 （一旦它在那里，你就拥有了完整的本地性能，至少在大多数情况下。）
• 大大增加了对本地网络稳定性的依赖
• ，应该始终拥有最新的 QTP 和 QTP。 QC 版本（特别是在补丁/SR 方面）
• 会看到一些罕见的情况，其中 QTP IDE 崩溃，而如果测试在本地文件系统中则不会崩溃（之间的接口实现中似乎仍然存在一些错误）两者）

因此，只有在您可以忍受缺点的情况下，才将这些东西放入质量控制中。

Answer 3

过去，我使用了一个名为 StarTeam 的工具，其中包含一个包含所有存储库的工作文件夹。这是版本控制的，意味着任何一位工程师都可以访问它或签出它以对其进行更改。

执行速度很快，因为您自己的个人版本的工作文件夹保存在本地驱动器上，使您可以快速访问。

然而，最好将其放在 QC 中，以提高其他测试人员的可见性。个人喜好确实每个解决方案都有优点和缺点。