我们正在看到测试自动化如何传播到越来越多的组织。这本身是一件好事，但同时，它给希望运行自动化测试但仍依赖手动测试来覆盖其场景重要部分的组织带来了巨大挑战。
I写了一篇关于我从与一些客户和其他质量检查经理一起工作中学到的知识的帖子，询问他们对这个问题的见解；但我想从遇到类似或不同问题的其他测试专家那里获取意见。
在将手动和自动测试工作进行集成时，您遇到什么挑战？
#1 楼
在将自动测试与手动测试集成在一起时，我发现的主要挑战是人们普遍缺乏编写GOOD自动测试的经验。如另一篇文章所述，组织购买“记录和回放”测试自动化存在严重问题。如果组织从这条路线开始，并且没有任何人致力于创建一个不基于记录和回放的良好自动化结构或框架，那么这通常会降低对自动化的信心，因为它不可靠，不可重用，并且通常是浪费人们普遍认为，添加任何类型的自动化测试是“灵丹妙药”，它将消除软件产品的所有质量弊端。自动化测试是软件测试人员用来确保产品可靠性的工具，就像您不使用锤子来拧螺丝一样（可以。。。但是，它确实弄乱了您所用的东西）。继续工作），某些事情非常适合自动化，而某些事情则不适合。每个组织，每个产品都必须进行这些评估。最后，如果您对创建自动化框架有很好的了解，并且意识到这是一种工具，那么组织面临的问题就是专门自动化的资源。像往常一样，当推挤和最后期限开始施加压力时，项目的测试时间就减少了。缩短测试时间的第一步是自动化。 “让我们对其进行测试并将其发布。我们稍后将介绍自动化。”而且，就像SDLC流程的任何其他部分一样，以后再也不会出现。需要专门留出时间和人员来创建，维护，更新和改进现有的自动化资源，以使其继续成为组织的好工具和好资产。
#2 楼
当人们谈论自动化测试的维护成本时，首先想到的是修复已损坏的东西的成本：更改的API，重新构造的UI，更改的文件格式，等等。但是，您还需要通过其测试的功能使自动化保持最新。这听起来并不容易。您的组织中可能没有人知道自动化测试涵盖哪些特定测试用例。使用手动测试，您可能会有某种文档。自动化开发人员在首次编写代码时可能已经写下了一些东西。默认情况下，文档不会与测试保持最新。
如果自动化开发人员仍然维护测试，他/她可能会记住该测试的内容。另一方面，如果他们不再参与项目，则很有可能没有人跟踪自动测试是否与应该测试的功能保持最新。最终，解决该问题的唯一方法可能是阅读和分析代码。
对于产品，如果功能集过时，则用户会告诉您。通过自动测试，您真正关心的唯一输出是PASS，FAIL或ERROR。无论测试是否涵盖开发团队在最近两个发行版中添加的新内容，该测试都将通过。
编写完成后不久，自动测试就变成了泄漏的抽象。人们认为自动化是“测试功能X的东西”或更糟糕的是，“告诉我功能X是否有效的测试”，而不是“测试功能X到发行Y为止的东西”。避免泄漏抽象至少需要维护一个列表，列出自动测试未涵盖的新事物。如果您知道的很多，您也许可以通过手动测试来弥合差距。要么，要么您可以运送错误。
自动化开发人员可以采取一些措施来解决此问题。一种策略是将事情记下来，但是正如我前面提到的，必须维护文档，就像代码中的注释一样。另一种策略是编写测试，以使测试用例与测试代码分离。有时这是不可能的或不值得麻烦的，但是在您可以做到的程度上，将更容易辨别自动化的功能和无效的功能。
评论
+1我完全同意。您需要专职于创建和维护测试的人员，同时还要牢牢把握“什么才是好的测试”。一旦您进行自动化测试，即“有空时就去做”，它就会被搁置一旁。
– Todd Bumbarger
2011年5月18日在13:11
几乎可以说出所有我想说的话:)我之前处理过的另一个问题是，可以将自动化脚本移植到岸上，并可以在岸上进行手动测试。通常这是行不通的，离岸团队不知道您要测试什么，并且您将花费更多的时间来支持他们，告诉他们与编写自动化测试相比，如何使自动化测试按您的要求进行并检查脚本。你自己需要自动化才能使它生效，这不是在海外雇用一些初级开发人员的情况，因为这不会，所以一切都会很好。
– Ardesco
2011年5月18日13:12
绝对是“他们所说的话”-如果没有人致力于维护和构建自动化测试，则最终结果是测试变得无法使用，并且自动化测试的概念也受到污染。自动化团队需要擅长自动化，善于测试，并且对他们正在测试的产品有充分的了解，或者测试的作用可能不及预期。
–凯特·保罗（Kate Paulk）
2011年5月18日在13:19
让我补充说，有时候记录和回放适合某些任务进行自动化测试。如果您的目的是创建一些快速的代码来执行某项操作然后将其丢弃，那么记录和回放无疑是您的最佳选择。但是，要重用的自动化测试需要进行更多的思考和计划，并且尽管记录和回放可能会为您提供一些简单的工作结构，但它不应成为自动化测试的最终形式。
– TristaanOgre
2011年5月18日在15:17