# 我在测试自动化方面最大的错误

每个人都会犯错误，但不管错误看起来有多糟糕，你都可以恢复过来，更重要的是，从错误中学习。 在软件开发过程的任何领域，从编码到测试，我们都会时不时地犯一些错误。通常，这些错误都很小，而且很容易修复——由于最近的更改而导致的测试失败，导致运行时错误的错误代码，等等。没有伤害，就不算犯规。 但有时候，我们可能会犯更严重的错误。我不是在讨论那些烦人但无害的问题。我说的是会导致你或者你的公司损失大量的时间和金钱或者损害一个人名誉的严重错误。当你是这些错误的原因，这是世界上最糟糕的感觉之一。各种各样的想法闪过你的脑海——我会因此丢掉工作，而且在我的余生里，再也没有人愿意雇用我了。 然而，不管现在的情况看起来多么糟糕，这些问题并不像你想象的那么糟糕。我是怎么知道的？在我的职业生涯中，当我犯一些可怕的错误时，我有大量的第一手经验。尽管有一些糟糕的失误，但我相对没有受到什么伤害，并且通过一些工作从中恢复过来。 我想分享我作为软件开发人员和自动化测试人员职业生涯中最大的三个错误。这些轶事不仅仅是为了让别人面对我或嘲笑我的疏忽(尽管如果你这样做也是完全可以接受的)。正如本文前面提到的，每个人都会犯错。关键是要向他们学习，这也是我希望这些故事能够提供的。 在我职业生涯的大部分时间里，我都在小型创业公司工作，通常是整个组织中唯一的开发人员或自动化测试人员。这意味着要承担很多责任，包括开发、测试和系统管理。作为一个独立的 IT 部门，我经常可以访问公司运行软件所需的所有生产服务器。 在我职业生涯早期的一个项目中，我参与的项目有一个 bug，这个 bug 只出现在我们的生产环境中。这个问题没有出现在我的开发计算机上，也没有出现在登台服务器上，我认为登台服务器的运行方式与生产服务器相同。当然，在分级上有一些轻微的错误配置，导致漏洞滑过裂缝。 一旦我确定了问题，我修补了 bug 并编写了一个自动回归测试用例来覆盖这个场景，以避免问题再次弹出。在确认我修复了生产环境中的 bug 之后，我决定对生产环境运行自动化端到端测试套件，使用管理员帐户运行任何经过验证的场景，这是一个好主意。 在一半的测试套件成功执行之后，当我想起测试套件清除了一些数据库表作为其设置和清理过程的一部分时，我立刻脸色苍白。我立即停止了测试执行，但为时已晚——测试抹去了大量实时客户数据。 一个词: 备份。值得庆幸的是，这个应用程序并不太复杂，并且有一个自动备份系统，每小时对数据库进行一次快照。我将网站设置为维护模式，并恢复了最后一个备份，幸运的是，不到30分钟前就完成了。 我也很幸运，事故发生在清晨，当时网站上的顾客寥寥无几。查看网站的日志和分析，当意外的数据删除发生时，只有少数人在使用这个应用程序。由于这些备份，没有人的数据会永远消失。 经验教训 对于任何与现实世界用户有关的服务，始终有一个完善的备份系统，不管这个系统有多小。此外，确保这些备份工作，并且您可以在紧急情况下快速恢复它们 永远不要在生产环境中运行自动化测试。即使您有只发生在这些系统上的问题，最好手动检查它们，这样您就知道自己在做什么。让自动化接管是不明智的，尤其是当涉及到数据清理时 限制对生产系统的管理访问。在某种意义上，能够访问整个系统帮助我快速恢复数据库，而不会由于我的错误而影响其他人。如果我是一个更大的团队的一部分，我可能一开始就会遇到这个问题 在我自己的网站上引发意外的“拒绝服务”攻击 现在我工作的几乎所有项目都有一些扩展应用程序功能的第三方集成。大多数这些服务都是网站核心功能的一部分。如果没有这些服务，应用程序将无法正常工作。非功能性集成对应用程序的影响程度从功能退化到根本无法工作不等。 我参与的一个项目有一些第三方服务，这些服务对于这个应用的存在至关重要。如果这些集成中的任何一个停止运作，整个网站停止工作。对我们来说，确保这些集成与我们的代码一起工作是非常重要的，因此我们有许多自动化测试，而不是针对活动服务运行。

有一天，我进行了一次非常紧张的调试会议，讨论这些集成中的一个问题。在尝试修复这个问题的同时，我不断地运行一些自动化测试来 ping 服务。我们已经有自动化的测试用例运行有缺陷的场景。在很短的时间内，我不断地对代码库进行更改，并执行测试以查看是否修复了它。这个工作流程加速了开发的调试过程。然而，整合对此并不满意。 这个特定的服务没有沙盒环境，我们可以在测试期间使用它，这意味着我们必须在开发期间使用相同的访问键来使用这个服务。集成的服务条款指定了速率限制。如果有人在给定的时间段内向服务发出了一定数量的请求，公司可以限制或关闭我们的访问，以防止他们的系统超载。速率限制是一个常见的做法，以避免滥用和失控的过量服务进程。 不出所料，在一次又一次地运行自动化测试的几分钟内，服务就断定我们的访问需要被切断。正如前面提到的，该服务没有测试环境，所以它也关闭了对实时生产环境的访问，引发了一系列错误，导致站点瘫痪。 我怎么恢复的 在事情发生的那一刻，我除了疯狂地联系第三方客户服务之外，什么也做不了。我花了几个小时才恢复我们账户的访问权限——时间太长了，让我很不舒服。 事件发生后，我立即和测试团队一起解释发生了什么。与开发团队一起，我们开始实施保护措施，以确保这个问题不再发生。测试人员开始寻找自动化测试套件中的一些区域，这些区域可以通过模拟而不是直接访问活动服务来进行测试，开发人员开始制定计划，当其中一个集成因为任何原因失败时，可以保持站点可用。 限制使用实时的第三方集成，特别是在没有沙箱环境用于测试的情况下。你和你的团队需要做出决定 当现场测试或模拟在您的项目中更有意义时 如果您需要在自动化过程中执行实时测试，请使用单独的帐户进行任何集成。许多第三方集成服务提供的沙箱不会影响您的实时设置。如果服务没有提供测试环境，可能的话创建一个辅助帐户

任何依赖第三方集成的应用程序都需要计划撤销，以防这些服务失败。任何第三方集成都不会有100% 的正常运行时间，因此团队必须确保站点能够保持部分正常运行，或者向用户提供站点不可用的消息。对于客户来说，有限的使用或维护信息总比失败的体验要好

由于我的一个测试，误导测试人员和开发人员长达数周 我曾经参加过一个从零开始实现自动化测试的项目。这个项目非常复杂，有许多复杂的业务逻辑用于几十个场景。这个项目没有任何测试自动化，现有的 QA 团队花了一个多星期的时间手工运行他们的回归测试用例，所以他们希望自动化一些他们工作中最乏味的部分。 考虑到项目的复杂性及其业务规则，我对这个行业(金融)不是很了解，所以我没有立即掌握很多概念。现有的团队已经在这个项目上工作了一年多了，大多数人从一开始就是这样，所以他们对这个应用程序的前前后后都有一个牢固的掌握。 不幸的是，我没有机会和现有的团队相处很长时间。他们都忙于工作——主要是因为他们的测试困难——所以我只能留下来为项目设置自动化测试。一开始，我觉得自己有足够的信心开始工作。 我设置了项目的测试环境，并开始编写最初的几个测试用例，以便为团队的其他成员提供一些指导，从而完成我将要完成的工作。最初的测试用例运行良好，我有时间在项目上继续投入。 团队希望在自动化设置中涵盖一个特定的流。这是一个单调乏味的场景，非常复杂，花费了他们大量的时间。几天来，我一直在思考需要做什么，最终我成功地将整个过程自动化了。我为自己的成就感到自豪，并继续从事其他任务。 几周后，这个项目的技术负责人联系了我，问我是否写了那个特殊的测试。我自豪地说我有，以为他会称赞我的工作。相反，他继续告诉我，在那个流程中，我错过了许多不同的规则和场景，而且这个测试也不是特别有用。 更糟糕的是，一些测试人员和开发人员一直在跟踪他们的任务的测试场景，认为应用程序的这个部分应该如何工作。他们做了一些工作，假设我的测试覆盖了与该部分相关的所有内容，这导致他们忽略了重要的细节，并重新做了一些与代码片段相关的工作。我无意中误导了他们，让他们相信我的测试是在我没有掌握全部情况的情况下，事情应该如何运作。 我怎么恢复的 在花了大量的时间研究这项技术之后，我发现我的测试漏掉了什么，于是我立即用新发现的理解重新做了自动化测试。在提交任何新代码之前，我一定要向技术主管征求意见，以确保它涵盖了必要的内容。 我还确保与受到我的误解影响的开发人员和测试人员一起道歉，并解释哪里出了问题。他们了解情况，他们能够继续工作而不再发生意外。 经验教训 始终与整个团队保持沟通，而且要多多沟通。尽管其他的开发人员和测试人员非常忙碌，我还是应该更密切地与他们一起工作，以获得更多关于我所测试的系统的知识。这样可以避免大量的混乱和额外的工作 仔细检查我的假设，在没有完全理解项目的情况下，千万不要投入工作。我太急于开始自动化测试，以至于我从未质疑自己对项目的有限洞察力是否就是整个情况。在做一个新项目的时候，在做任何事情之前提出正确的问题都会产生巨大的影响 相信可用的，但是要验证an excellent source of documentation 一个很好的文件来源, 并且团队应该使用它们来理解项目是如何工作的。然而，如果你没有测试它应该测试的东西，这就不重要了。使用测试作为指导，但是要确保它正在引导你走上正确的道路 总结: 每个错误中都隐藏着魔法 这三个故事是我作为一个开发人员和测试人员造成的压力更大的情况之一，但这只是冰山一角。在我的职业生涯中，我犯过很多错误，我相信在我完成之前，我还会犯更多的错误。不管我犯了多少错误，有一件事是肯定的——他们帮助我成长为一名测试员。 当然，在这些情况发生的时候，我想要羞愧地从地球上消失。但是现在回想起来，我很高兴这些问题发生在他们发生的时候，因为他们让我成为了今天的测试员。如果没有隐藏在这些情况背后的“魔法”——我从中学到的教训——我肯定不会拥有今天我所享受的工作技能和能力。 我也很感激我的经理和团队成员在我搞砸工作时表现出了难以置信的同情心。他们知道我不是故意制造这些问题的，所以他们提供了我所需要的支持来纠正这个问题并向前迈进。如果你是一个管理者或者团队的一员，当别人犯错误的时候，要宽容和同情。你不知道你什么时候会在这个等式的另一边。 最后，如果你在工作中很难犯错误，不要这样做。当你把事情搞砸的时候，就像他们感觉到的那样，会给你的职业生涯提供一些最好的机会。不要回避错误。你最终会做出一些的。但是区分好的测试人员和最好的测试人员的是他们一路上学到的经验教训，以及这些经验教训如何使他们变得更好。 你或你的团队是如何从工作中一个相当严重的错误中恢复过来的？在下面的评论区分享你的故事和经验教训。不要难为情——我们都经历过一些事情！

# author

石头 磊哥 seven 随便叫

# company

thoughtworks（离职了。。。。）

大家好，本人不才，目前依旧混迹于thoughtworks，做着一名看起来像全栈的QA，兴趣爱好前端，目前是thoughtworks 西安QA社区的leader，如果有兴趣分享话题，或者想加入tw，可以找我

# roles

QA（营生） dev（front-end dev 兴趣爱好）

# 联系方式

如果想转载或者高薪挖我 请直接联系我 哈哈

# wechat:

qileiwangnan

# email:

qileilove@gmail.com