2、其次要同一个pc上并发执行多个app真机，加上bp和chromedriver端口号。
3、最后启动程序，即可跑多个app自动化。
自动化测试的问题我们已经探讨了很多次了，所以今天我们就给大家简单分享了在自动化测试过程中常用的一些测试工具和方法，下面java课程http://www.kmbdqn.com/就一起来了解一下吧。希望通过对本文的阅读，能够提高大家对自动化测试的认识和理解。
1.带RobotFramework的Selenium
Selenium无疑是受欢迎的Web自动化测试工具。其开源的特性是被广泛使用的原因之一。您可以使用不同的语言在Selenium中实施各种框架，从而为自动化测试提供更多的功能。
Selenium能够支持多种操作系统(Windows、Mac、Linux)和多种浏览器(Chrome、火狐、IE和Headless类型浏览器)。我们可以运用多种语言(如Java、Groovy、Python、C#、PHP、Ruby和Perl)来开发出不同的测试脚本。
Selenium内置了许多工具和框架，您可以启用它们来进行持续测试。RobotFramework是Selenium用来进行持续测试的一种常用的框架。通过Robot，您可以运行各种自动化测试，包括由SeleniumWebdriver所提供的、基于UI元素和API的测试。
Selenium既可以使用关键字驱动的方法进行验收测试，也可以进行验收测试驱动式的开发(AcceptanceTest-DrivenDevelopment，ATDD)。通过使用Python和Java所实现的附加测试库，其测试功能得到了进一步扩展。而RobotFramework不仅可以用于Web应用的测试，也可被用来测试Android和iOS的应用。
但是，Selenium本身并不能满足所有的持续测试需求。它需要与大量的工具相集成，以满足在软件开发生命周期(SDLC)中的不同目的。此外，Selenium还需要使用者具有高级的编程技能，并愿意花费专门的时间与精力，来构建自动化框架，以满足其特定的测试需求。
2.Testsigma
Testsigma是一个统一的、以AI驱动测试的自动化平台。它采用Shift-Left方法，将持续测试集成到了端到端的持续交付生态系统之中。Testsigma通过减少自动化测试技术中的复杂性，为功能和自动化团队带来了更多的灵活性。
功能测试人员可以轻松地使用自然语言，编写出简化的代码，来进行自动化测试。Testsigma通过可重用的步骤组合、与集中对象存储库(CentralizedObjectRepository)大限度地提高了测试代码的重用性。同时它通过使用AI，来大幅降低了与测试有关的维护开销。
Testsigma能够与各种开源的或三方工具相集成。它支持上千种不同“设备+浏览器+操作系统”组合的云端测试环境，以不断满足各种的动态测试需求。
Testsigma能为企业级的自动化测试、和持续测试提供所有必需的功能，其中包括：数据驱动测试、跨浏览器测试、可重用性测试套件、测试计划与数据管理、电子邮件与Slack通知、并行测试执行、集中对象/元素存储库、综合报告、与CI工具的集成、以及自动化Bug报告等。
作为一款基于云端的自动化测试工具，Testsigma为Web、移动Web、Android、iOS应用、以及RESTful服务提供了各种类型的应用支持。
3.IBMRationalFunctionalTester
RFT是另一种能够进行功能、API、性能和回归测试的工具。RationalFunctionalTester使用记录和回放来创建自动化的功能测试，并将预期结果与执行时系统所产生的实际结果相比较。
IBM支持广泛的应用程序，并能够与IBMRationalQualityManager等工具相集成。另外，IBMRationalTestWorkbench还支持在API级别、用户界面级别、以及整个系统级别进行回归测试，以实现在DevOps或持续交付生命周期内的各种测试目标。
软件测试在大部分的软件开发项目中都是非常重要的组成部分，而随着互联网的不断发展，自动化的测试方法被更多的程序员掌握。
下面我们就一起来了解一下，自动化单元测试的基本原理。
越是在底层的测试类型，其测试的成本越低，反馈越及时。
在单元测试阶段能发现的一个缺陷，假设修复它的成本是10块钱，那如果它没有在这个阶段被发现，而是推迟到了组件测试阶段，那修复它的成本是100元，以此类推，每晚一个阶段发现，其修复成本都会增加一个数量级——想一想那高昂的沟通和回归成本吧。
如果在线上才发现这些缺陷，那成本和损失就更难以估量。
基于上面的原理，专业的开发团队应该选择一个合理的测试策略。
先是测试覆盖率的要求不一样。
单元测试的覆盖率终极目标可以追求100%，但系统测试能做到10%就已经很昂贵了。
其次，是每种测试类型的关注内容应该不一样。
单元测试关心代码层面的正确性，大多数的异常路径都是由单元测试来覆盖的，单元测试应该由开发者自己来做，组件测试更多的关心成功路径的情况，以及一些明显的极端情况、边界状态和可选路径，组件测试可以由QA和业务人员来负责。
软件在其生命周期内会频繁地变更，这和建筑物、飞机汽车等非常不同，充分体现了软件”软“的一面。
在这种高度变化的环境下，要每次做到这么高的测试覆盖率，成本是巨大的。
幸好，也正是由于软件”软“的一面，自动化的测试在软件领域更容易实现。
什么是自动化单元测试1.自动化单元测试=自动化+单元+测试近，我调研了一些自动化单元测试覆盖率是个位数的应用，下面宁夏电脑培训http://www.kmbdqn.cn/用实例来说明什么不是自动化单元测试，然后大概就清楚了为什么对很多开发者来说自动化单元测试那么难。
个别的Java开发者还在写main方法，通过System.out.println()的方式来做单元测试，main方法很难被自动执行，println的结果也需要人眼去盯着判断，显然这种单元测试不是自动化的。
