我们有大量的开发人员，但只有少数 QA 人员。通过编写自动化测试，开发人员在整个开发过程中更多地参与了 QA，但我们的 QA 实践大多是手动的。
我希望我们的开发实践是 BDD 和 TDD，并且我们开发了一个健壮的测试套件。问题是：在构建这样一个测试套件时，我们如何决定我们可以信任哪些测试，以及我们应该继续手动测试哪些？
问问题
1726 次
6 回答
7
第一条分界线是——什么更容易手动测试，什么更容易以自动化方式测试？
当然，这些很容易弄清楚，而且您可能会在中间留下一大堆垃圾。
我的下一个筛子是——用户界面问题是最难以自动化方式测试的问题之一，尽管一些项目正在使它变得更容易。因此，我会将这些留给 QA 人员一段时间，并将您的自动化测试集中在后端代码的小单元上，慢慢扩展到跨多个单元和/或应用程序的多个层的更大集成测试。
于 2010-04-14T16:50:21.260 回答
6
我的建议是，自动化所有你可以自动化的东西。让人类做他们擅长的事情，比如回答“这看起来对吗？”这个问题。或“这有用吗？”。对于其他一切，自动化。
于 2010-04-14T16:54:18.200 回答
5
查看 Mike Cohn 关于测试自动化金字塔的文章。具体来说，考虑真正需要以这种方式测试 UI 的哪一部分。例如，角落案例通常通过服务层进行更好的测试。
于 2010-04-14T21:26:29.233 回答
4
+1 向 Jim 推荐手动测试 UI 元素；使用 UI 自动化工具来创建测试相对容易，但是要设计一个足够健壮和全面的测试框架以最大限度地减少测试的维护需要大量的思考和预期。
如果您需要确定优先级，我用来识别最能从额外测试中受益的非 UI 区域的一些技术是：
- 查看以前版本的错误报告，尤其是客户报告的错误（如果您可以访问它们）。一些特定的功能区域通常会导致大部分错误。
- 在运行现有的自动化测试时使用代码覆盖率工具，并注意覆盖率很少或没有覆盖率的区域。
于 2010-04-14T19:03:03.773 回答
4
与自动化测试不同，手动测试可以执行以下操作：
- 图形用户界面测试
- 可用性测试
- 探索性测试
- 运行测试时使用变体
- 发现新的，而不是回归错误
- 人眼可以注意到所有问题。自动测试只验证几件事。
与手动测试不同，自动化测试可以执行以下操作：
- 压力/负载测试
- 您甚至可以使用自动化测试套件来测试性能
- 配置测试（恕我直言，这是最大的好处）。编写完成后，您可以在具有不同设置的不同环境中运行相同的测试，并发现您从未想过的隐藏依赖项。
- 您可以对数千个输入数据运行相同的测试。在手动测试的情况下，您必须使用不同的技术选择最小的输入数据集。
此外，在自动测试中出错比在手动测试中出错更容易，也更有可能出错。我建议您将最有价值的功能自动化，但在重要发布之前手动运行测试（至少是理智的）。
于 2010-06-12T17:01:10.333 回答
1
手动测试任何新功能以确保它符合要求，然后将其添加到自动化套件中进行回归不会有什么坏处。（还是太传统了？）
于 2010-04-27T20:31:06.233 回答