2010-04-14 24 views
8

我们有很多开发人员,只有几个质量保证人员。通过编写自动化测试,开发人员在整个开发过程中越来越多地参与qa,但我们的质量保证实践大多是手动的。我怎样才能决定手动测试什么,以及相信自动测试的内容?

我很喜欢的是,如果我们的开发实践是BDD和TDD,并且我们开发了一个强大的测试套件。问题是:在构建这样的测试套件时,我们如何确定我们可以信任的测试,以及我们应该继续手动进行测试?

回答

7

第一分界线 - 什么是基本上容易手动测试,并且什么是基本上容易以自动化的方式来测试?

这些当然很容易弄清楚,也许你会在中间留下一大堆垃圾。

我的下一个筛将是 - 用户界面问题是最难测试的自动化方式之一,尽管一些项目使其更容易。因此,我会将这些问题留给QA人员一段时间,然后将您的自动化测试集中在小部分后端代码上,然后逐渐扩展到跨多个单元和/或多个应用程序层的较大集成测试。

+0

+1关于UI自动化的评论。很难保持良好的UI测试框架。 – 2010-04-15 12:56:51

+0

我们是一个.NET商店,我们使用NUnit进行单元测试,并使用Watir的Cucumber进行用于UI的验收测试。 我们发现的是,我们的黄瓜测试很脆弱,我们不会将它们用于它们旨在支持的BDD样式过程。 您认为使用BDD样式测试来测试服务层代码而不是UI会更好吗? – bhazzard 2010-04-29 14:03:20

+0

至少在2010年,服务层代码将比UI层代码更容易以自动方式进行测试。你可以也应该做黄瓜式的BDD和服务层代码测试(虽然我承认我从来没有使用黄瓜 - 我真的很想有机会这样做!)。 – 2010-04-29 14:46:08

6

我的建议是,你可以自动化所有可能的自动化。让人类做他们擅长的事情,比如回答“这个看起来对不对?”或“这是否可用?”。对于其他一切,自动化。

+0

这是我想听到的。但我不确定我们的质量保证人员(甚至是我自己)是否会购买我们可以信任自动化套件的产品。 – bhazzard 2010-04-29 13:59:37

+1

很明显,你绝对不能100%测试自动化套件,但我已经和很多人类测试人员合作过了,我不会100%信任他们。 – 2010-04-29 14:40:53

+1

@Jim Kiley:你说得很对。自动化测试的优势在于您可以合理确保每次运行完全一样。对于人类,特别是被迫一次又一次地进行相同手动测试的人来说,很容易犯错误。手动测试可能令人头脑麻木。 – 2010-04-29 17:18:35

4

+1给Jim推荐手动测试UI元素;使用UI自动化工具创建测试相对容易,但需要设计一个足够强大且全面的测试框架,以最大限度地减少测试的维护,这需要很多思考和预期。

如果需要优先考虑,一对夫妇的我已经习惯identfiy会从另外的测试中受益最大的非UI方面的技术是:

  1. 看看以前版本的bug报告,尤其是如果您有权访问客户报告的错误。一些特定的功能区域通常会占据大部分错误。
  2. 当您运行现有的自动化测试时,请使用代码覆盖工具,并记下覆盖很少或没有覆盖的区域。
5

看看Mike Cohn的文章Test Automation Pyramid。具体来说,考虑真正需要以这种方式测试UI的哪一部分。例如,角落案例通常通过服务层得到更好的测试。

+1

什么是用于测试服务层的有效工具?我们应该使用传统的XUnit测试框架还是更多的BDD风格的基于小黄瓜的框架(即Cucumber或SpecFlow)? – bhazzard 2010-04-29 14:07:18

1

手动测试任何新功能以确保其符合要求,然后将其添加到自动化套件以进行回归,这并不会带来任何负面影响。 (或者它太传统了?)

4

手动测试能做到以下几点,不像自动化测试:运行测试时

  • GUI测试
  • 可用性测试
  • 探索性测试
  • 使用变化
  • 寻找新的,不回归bug
  • 人眼可以注意到所有问题。自动测试只验证几件事情。

自动化测试可以做到以下几点,不像手动测试:

  • 压力/负载测试
  • 你甚至可以使用一个自动化测试套件来测试性能
  • 配置测试(恕我直言,这是最有利)。 写完后,您可以在不同环境下使用不同设置运行相同的测试,并发现您从未想过的隐藏依赖项。
  • 您可以对数千个输入数据运行相同的测试。 在手动测试的情况下,您必须使用不同的技术选择最小的一组输入数据。

此外,在自动测试中犯错误更容易,然后更可能在手动测试过程中犯错。 我建议你自动化最有价值的功能,但在重要版本之前手动运行测试(至少理智)。

+0

加1以获得详细回复。 – bhazzard 2010-06-13 14:33:29

相关问题