我们有很多开发人员,只有几个质量保证人员。通过编写自动化测试,开发人员在整个开发过程中越来越多地参与qa,但我们的质量保证实践大多是手动的。我怎样才能决定手动测试什么,以及相信自动测试的内容?
我很喜欢的是,如果我们的开发实践是BDD和TDD,并且我们开发了一个强大的测试套件。问题是:在构建这样的测试套件时,我们如何确定我们可以信任的测试,以及我们应该继续手动进行测试?
我们有很多开发人员,只有几个质量保证人员。通过编写自动化测试,开发人员在整个开发过程中越来越多地参与qa,但我们的质量保证实践大多是手动的。我怎样才能决定手动测试什么,以及相信自动测试的内容?
我很喜欢的是,如果我们的开发实践是BDD和TDD,并且我们开发了一个强大的测试套件。问题是:在构建这样的测试套件时,我们如何确定我们可以信任的测试,以及我们应该继续手动进行测试?
第一分界线 - 什么是基本上容易手动测试,并且什么是基本上容易以自动化的方式来测试?
这些当然很容易弄清楚,也许你会在中间留下一大堆垃圾。
我的下一个筛将是 - 用户界面问题是最难测试的自动化方式之一,尽管一些项目使其更容易。因此,我会将这些问题留给QA人员一段时间,然后将您的自动化测试集中在小部分后端代码上,然后逐渐扩展到跨多个单元和/或多个应用程序层的较大集成测试。
我的建议是,你可以自动化所有可能的自动化。让人类做他们擅长的事情,比如回答“这个看起来对不对?”或“这是否可用?”。对于其他一切,自动化。
这是我想听到的。但我不确定我们的质量保证人员(甚至是我自己)是否会购买我们可以信任自动化套件的产品。 – bhazzard 2010-04-29 13:59:37
很明显,你绝对不能100%测试自动化套件,但我已经和很多人类测试人员合作过了,我不会100%信任他们。 – 2010-04-29 14:40:53
@Jim Kiley:你说得很对。自动化测试的优势在于您可以合理确保每次运行完全一样。对于人类,特别是被迫一次又一次地进行相同手动测试的人来说,很容易犯错误。手动测试可能令人头脑麻木。 – 2010-04-29 17:18:35
+1给Jim推荐手动测试UI元素;使用UI自动化工具创建测试相对容易,但需要设计一个足够强大且全面的测试框架,以最大限度地减少测试的维护,这需要很多思考和预期。
如果需要优先考虑,一对夫妇的我已经习惯identfiy会从另外的测试中受益最大的非UI方面的技术是:
看看Mike Cohn的文章Test Automation Pyramid。具体来说,考虑真正需要以这种方式测试UI的哪一部分。例如,角落案例通常通过服务层得到更好的测试。
什么是用于测试服务层的有效工具?我们应该使用传统的XUnit测试框架还是更多的BDD风格的基于小黄瓜的框架(即Cucumber或SpecFlow)? – bhazzard 2010-04-29 14:07:18
手动测试任何新功能以确保其符合要求,然后将其添加到自动化套件以进行回归,这并不会带来任何负面影响。 (或者它太传统了?)
手动测试能做到以下几点,不像自动化测试:运行测试时
自动化测试可以做到以下几点,不像手动测试:
此外,在自动测试中犯错误更容易,然后更可能在手动测试过程中犯错。 我建议你自动化最有价值的功能,但在重要版本之前手动运行测试(至少理智)。
加1以获得详细回复。 – bhazzard 2010-06-13 14:33:29
+1关于UI自动化的评论。很难保持良好的UI测试框架。 – 2010-04-15 12:56:51
我们是一个.NET商店,我们使用NUnit进行单元测试,并使用Watir的Cucumber进行用于UI的验收测试。 我们发现的是,我们的黄瓜测试很脆弱,我们不会将它们用于它们旨在支持的BDD样式过程。 您认为使用BDD样式测试来测试服务层代码而不是UI会更好吗? – bhazzard 2010-04-29 14:03:20
至少在2010年,服务层代码将比UI层代码更容易以自动方式进行测试。你可以也应该做黄瓜式的BDD和服务层代码测试(虽然我承认我从来没有使用黄瓜 - 我真的很想有机会这样做!)。 – 2010-04-29 14:46:08