从所有手动测试过渡到自动测试

#1 楼

我在自动化和手动测试方面做了很多工作，对三个问题的看法是：


回归有多少麻烦？这可能是您最大的潜在时间/成本节省者。任何需要长时间，无聊的回归测试的方法都是一个不错的目标-请注意不要过度销售。大量的启动费用会确保您的启动阶段比正常运行效率低下，成本更高。一旦有了基本框架并运行了一些简单的（最好是简单的，具有良好的投资回报率-这取决于您的应用程序）测试，就可以确保此功能适用于每个发行版，而无需执行
我在上面的测试中部分提出了问题：对于初学者来说，最好的选择是经常使用的东西，进行冗长或繁琐或耗时的回归测试，可能经常中断，或者是关键任务。通常，从满足以下两个或多个条件的简单方法开始：如果您的应用程序计算税金，则任何具有任何税率方案的交易都是一个不错的起点。您的基本目标应该是达到80/20规则： （登录/注销和会话管理是另一个很好的简单目标）。
好的自动化软件取决于您的应用程序和需求。您需要考虑的关键是您是否在处理Web应用程序（有许多免费或低成本的工具可用于Web应用程序），Windows应用程序，移动应用程序，Linux，Mac等。您需要能够至少对正在测试的软件进行调查的东西，以识别与之交互的各种组件并调用其公共方法。与基于屏幕上像素位置进行交互的东西相比，调用“ SubmitButton.ClickButton（）”之类的自动化要容易得多。

祝你好运，并祝您自动化愉快。

#2 楼

首先，如果您查看此网页的右上角，将会看到一个标有“搜索”的白框。如果单击该框，键入“ automation”，然后单击Return，您将看到许多有关自动化的问题和解答的链接。我相信值得您花时间仔细检查那里看到的内容。

这是一个很大的话题，但是如果是我，我将首先决定我的主要动机是节省时间还是寻找更多东西错误。

如果您的主要动机是节省时间，则应从自动化一些常见的，耗时的设置任务开始，例如，生成测试数据或自动安装和配置产品。这些事情是一个很好的起点，因为它们是可衡量的，这对您的管理层可能很重要。如果您可以用此报告可量化的成功，则证明其他自动化类型可能更容易。以我的经验，自动化设置任务比自动化测试还需要更少的编程技能。

如果您现在遇到严重的质量问题，并且怀疑自动化测试可以帮助您发现更多的错误，则应该确定一些特定的错误。自动化可以为您提供帮助的领域。有许多策略可以识别自动化的测试，例如特别是越野车的区域，特别耗时或容易出错的区域，或者具有可能的输入组合集但具有易于预测的输出的区域。请注意，尽管工具供应商和自动化测试的传播者声称，自动化测试不是万能的。此外，像所有软件一样，自动化测试需要先期投资，然后进行持续维护。像处理任何大型项目一样采用自动化方法：从小处着手，诚实对待结果，如果未实现目标，则准备好改变策略。

#3 楼

我最近离开了微软，在那里我们为一家规模较小的公司提供了很多自动化功能，而其中只有一点点自动化功能，可以帮助我们启动大量测试的自动化过程。幸运的是，这里的管理人员已经意识到他们需要提高自动化程度，但是即使承认他们需要更多的自动化程度，实际上提供启动和运行自动化所需的资源也变得更加困难。

因为我的公司已经取得了一些自动化成功，并且也出现了一些自动化失败，所以我知道我需要做的一件事就是在开发人员，管理人员以及其他利益相关者之间建立起对我们自动化的信心。因此，我选择了一些回报率很高的简单项目，作为前几个要处理的项目，这些项目显示出生产力和周转时间的显着提高。我创建的前两个工具实际上并不一定是自动化的。第一个工具是通过将数据插入日志文件来帮助进行手动测试的工具，当通过我们的产品运行该产品时，该文件将解析日志并将其插入数据库，从而使数据更易于使用。这个工具非常简单，但是允许我们做更多的深度测试，既增加了信心，同时也加快了过程。第二个只是修改了一些现有的自动化测试，并添加了一些工具以使用一种机制来实现以下目的：a）启动自动化（mstest）b）记录和报告结果，以及c）在构建之上运行。第三个是我在此答案中概述的用于自动部署验证的工具：部署测试。总而言之，当试图说服管理层（和其他任何人）自动化可以加快测试速度并提高您的置信度时，最好有一些具体的例子，因此像这样的几个快速工具已经很有价值了，它们确实非常有用。说服管理层让您做更多的事情。

我计划处理的下一部分是UI自动化框架（在当前selenium / webdriver构建的基础上的抽象），然后再进行更深入的测试，以在HTTP和数据库层进行测试。

我对Automation Anywhere不熟悉，但是我知道正确的自动化工具套件在很大程度上取决于您要测试的内容。您是在谈论UI自动化，还是在谈论其他附加自动化？它是哪种UI-网页，Windows应用程序，Flash，Silverlight等？您需要在哪个OS /浏览器/环境中运行自动化？通常，自动化的成功与实现的关系要比对所使用的基础框架的影响更大。一个常见错误的例子是，使用现成的框架，而在框架之上没有抽象，经常使用诸如记录器之类的工具来记录和回放测试用例。尽管这将使您快速起步，但也将使自动化的维护和稳定性（即使不是不可能）变得困难。花时间投资于构建适当的抽象，它将使开发和维护自动化测试变得更加简单。

#4 楼

不断增加新功能，以节省长期时间。您可能会自动进行回归分析，并能够花时间彻底测试新功能，并发现可能无法找到的可能会花费更多金钱的错误。很少能看到预先节省的钱，这通常使得在自动测试中出售管理变得困难。期待挑战。 ;）
如果您的软件只有API部分，那么您可以专注于将其作为概念证明进行测试，而不必处理基于UI的测试。可以使用Watir（Ruby）等低成本工具快速构建原型，并快速入门。
这绝对是测试工具上的空白。选择合适的工作。在不了解您的产品的情况下，很难给出好的意见。有一些厂商出售极其昂贵的系统，还有一些免费的框架和API。如果成本是一个问题，并且通常是您提出的方式，请以此为指导。

#5 楼

鼓励采用自动化测试（主要是关于
管理）

-//-


确定一些当前的测试，这些测试很容易替换为自动测试




a）首先，从基本的CRUD模式开始（http：// en.wikipedia.org/wiki/Create,_read,_update_and_delete）操作。

我确信，您的应用程序中有几项可能是CRUD。

例如，测试以下内容：
1.创建用户


查看用户详细信息
更新用户详细信息
并删除用户

那将是主要的优先级功能。

如果您对应用程序中的每个实体都有非常基本的CRUD覆盖范围，那么您将获得良好的测试覆盖范围。

b ）不要花时间使自动化测试与手动测试相同。您将永远不会这样做。

c）查找最无聊的测试并将其自动化。使用MSI（http://zh.wikipedia.org/wiki/Windows_Installer）命令行执行静默安装。创建DOS / Powershell / Jscript命令行，以帮助您部署应用程序，复制文件并自动准备测试环境。




选择一个好的自动化测试软件（我们显然拥有
Automation Anywhere，但我不知道这是否是一个好的产品，
开始使用进行自动化测试）




请记住，良好的自动化与良好的应用程序开发相同。请咨询您的高级开发人员。如果应用程序具有200行源代码，则可以轻松控制该应用程序。如果应用程序有2万行，则很难控制。您的测试可能更大。

#6 楼

免费下载Hudson或最好是TeamCity Pro。
将其指向您的源代码，并要求其运行编译。
编写您能想到的最简单的noddy测试。
问一下CI服务器运行该测试。

上面的内容在一夜之间要花几个小时，但是如果没有第一个测试，就无法进行第二个测试。

即使连续编译也可以使您的团队在不编译时获得更好的反馈（因为我忘了签入文件），所以您在第2步之后便会感到惊讶。

当您已经建立并运行自动测试系统以向他们展示情况时，与管理人员争辩要容易得多。

做与不做，没有尝试。

#7 楼

我想回答最后一个有关最适合使用的工具的问题。不可避免地，大多数公司已经在某种形式的自动化上进行了投资。这些大多是Shell脚本，运行一些自定义应用程序，然后解析输出。当您选择一种工具时，该工具将带有其自己的报告基础结构，这通常假定该工具是引入真空中的。选择一种可以与您的计划和报告基础架构轻松共存（即向其中报告）的工具非常重要。自动化测试会产生大量数据（不仅是通过/失败，而且还会包含有关测试条件的更有趣的内容），这些数据对于以后存储和分析非常有用。这就是我所说的自动化成熟度的下一阶段。向管理层出售产品时，重要的是要显示长期访问此数据的好处。