我正在尝试确定是否应该花一些时间使用HP Quality Center试用版。由于多种原因,无论是在工作还是在个人生活中,我的时间现在对我来说都是非常宝贵的,所以“为什么不呢?”甚至还没有足够的理由开始下载试用版并进行设置。是的,现在甚至几个小时都很难。我已经看过他们的网站,但是无法浏览所有的营销演讲,甚至无法弄清产品的真正含义,至少是在我关心的方面。

现在,我主要是可以对各种产品进行自动化测试,并且随着时间的推移,它将测试越来越多的应用程序,并在测试中指导其他人(主要是开发人员,将来可能还会聘请一些额外的质量检查人员)。我目前正在创建,使用和维护使用C#测试装置和编码检查以及存储在SQL DB中的测试用例的本地测试系统。我目前很少进行UI测试,但将来可能会越来越多地开始进行Web UI测试,并且目前正计划使用Selenium或WatiN。该产品基于主要是.NET堆栈,并在此处和此处有一些开源工具。该公司正在实践某种形式的敏捷开发,主要是Scrum(一些团队使用的是“ Scrumlike”,而不是IYKWIM)。

我想弄清楚测试人员HP Quality Center的技能水平是多少目的是,我是否可以轻松编写固定装置和可重用的测试代码,以使其易于使用,以及它对我的影响将比使用本地系统更好,更容易。我特别担心它是否缺乏灵活性,尤其对是否可以节省我目前在自己的框架上的投资感到兴趣。

有没有人在使用此工具之前能给我一些见识吗?

#1 楼

谁将负责质量控制?如果要成为您,我建议您暂时错过它。我认为它并不特别适合小型团队或敏捷团队:它是针对具有瀑布式开发方法的大型公司的,而整个设计几乎都是针对此的-您可能会发现自己不得不在当前的环境中游刃有余时,我得到的印象正是您想要避免的。

从我的经验来看,它也非常昂贵-足以使我见过的每个地方所使用的许可证数量都非常有限,因此破坏了集成错误跟踪器和测试&需求管理系统。

评论


这也是我的经验。我们目前正在远离它。

– Lyndon Vrooman
2011年5月14日在1:54

同意讨厌那个工具。在HP QC测试计划中添加/编辑测试用例非常缓慢,以至于我听说的每个使用它的团队都开发了自制的解决方案,可以从外部来源(例如Excel)导入测试用例。

– dzieciou
13年11月15日在20:51



#2 楼

HP Quality Center是已经存在很长时间的产品。我已经有好几年没有用过该产品了,但是我认为它与任何方法都不特别相关。

HP的工具通常被有记录的非技术测试人员使用以及回放和分步测试执行,尤其是在WinRunner即将停产的情况下。

作为一个在Microsoft和.net领域拥有丰富经验的人,尤其是在WatiN方面,我建议您可能更适合使用Visual Studio Team System 2010和Microsoft测试管理器,尤其是因为您可能已经在使用Visual Studio并且已经拥有许可证。这些工具直接与通常与C#代码一起使用的单元测试运行器集成。

另一个选择是,由于您已经在构建自己的工具,所以需要投资需要花费的$$$在QC上雇用一个人来开发自己的内部工具(是的,这要花很多钱)。

#3 楼

在工作中,我们正在使用HP QC。这是一个非常强大的工具,但我只会将其用于大型项目。我认为它不适用于小型/媒体项目。我正在工作的项目有17个团队和160多人,这个工具是公司的决定,而不是对可用工具分析的结果。

评论


“工具是公司的决定”也与我的经验息息相关。

– testerab
2011年5月14日在9:40

@testerab这里也是。

– Mugen
2011年7月23日14:49

#4 楼

如果您在考虑敏捷和硒,请不要忘记Quality Center。这不能满足您的需求,为此,您必须购买价格比QTP和QC更高的其他附件。
如果您需要灵活性和敏捷性,可以选择Jira或Mingle,QC是真正的封闭的系统并使用ActiveX控件,没有人再使用它。

#5 楼

我曾在多个地方与Test Director(QC的前身)一起作为Bug跟踪工具使用,价格太高了,以至于一家中等盈利的公司也无法(或不想)购买多于几个的许可证,只有基本模块使工作变得非常繁琐。
根据我的经验,它非常灵活,稳定并且易于由非代码编写者使用,并且最重要的是在需求,测试计划,测试和错误之间实现了出色的集成。 />

#6 楼

我同意其他人的观点,即Quality Center更适合被认为是敏捷厌恶的大型(陈旧的)公司。 QC的基本要点是许可及其对座椅上烧伤的承诺。

您可以查看一些开源测试工具,例如Cucumber(Cuke4nuke)和FitNesse。如果您现在还不解决UI方面的问题,那么也可以考虑进一步探讨这些问题,但是请牢记它们,因为它们可以促进良好的敏捷实践(尤其是黄瓜)。

很棒,但是和所有记录/回放自动化一样,请确保您的UI相对稳定,否则将有很高的维护开销。

如果您要变得更加敏捷,那么缺陷跟踪就会减少这是一个问题(例如,双关语),因为通常会在开发功能时捕获错误,而不是在6个月内捕获错误。我不认为这些是错误,需要更多工作。

我们目前使用Mingle(来自Thoughtworks)进行所有故事计划和缺陷“管理”,但这主要是因为我们拥有Thoughtworks顾问该项目。

+1进行JIRA投票,还签出Bugzilla

#7 楼

如果时间不足,请停放它。我们确实在敏捷团队中成功使用了质量控制,但仅限于手动测试,尽管测试计划适合用作适当的存储库,但以与您的团队流程相匹配的方式进行设置会花费很长时间。 br />
我们拥有它,因为它是很久以前购买的,当时该公司有一个中央测试团队,他们在一个共享系统上跨多个开发团队工作,但是现在我们将测试团队拆分了起来,并拥有多个系统不会再买了

我最近建立了一个新项目,并对其进行定制以使其能够支持我们的流程,而不是进行更改,而这花了我几个星期的时间