Mithun Sridharan是Blue Ocean Solutions(BlueOS)公司的总经理，BlueOS是一家德国的专注于技术公司的集客营销和数字转化公司。他有十多年的业务开发、市场、全球交付和咨询方面的国际经验。他拥有ESMT学院管理和技术专业的MBA证书和德国基尔大学的理学硕士证书。他是哈佛管理导师及研究生，一名项目管理专业人员（PMP）以及一名认证信息系统审计师（CISA）。2013年他还担任过本部在德国埃施博恩的德国外包协会的通讯主席。

　　根据Pinch媒体数据2009年进行的研究，一个移动应用程序的平均生命周期只有30天。此后移动应用程序的数量激增，生命周期变得更短了。这些变化趋势要求软件质量保证团队重新改进他们的软件测试方法，并将之与移动应用程序开发团队和客户群紧密相连。客户需要更多的应用程序和功能，因此保证移动应用程序的质量对维护现有客户群并获取新客户都是必不可少的。鉴于软件开发和质量保证（测试）的时间很短，即使有替代策略存在，软件测试自动化从一定程度上在公司的生命周期中是必要的。
　　一家app开发公司会因为各种原因（内部和外部的都有）而决定将其测试工作自动化。不论深层原因，一旦一家公司决定将其测试工作自动化，需要一个系统的方法来定下自动化流程的工具。测试自动化的成功很大程度上取决于所使用的工具。如今市场上有各种自动化工具，选择正确的工具满足公司特定的测试需求算得上是一个蛮有压力的任务。
　　一个刚开发的产品，相对来说还是不太稳定。在那些阶段，手动测试是一个快速验证产品是否如期运行的好方法。为了验证和确认（V&V），软件测试员应该利用这个阶段熟悉产品规格并编写测试用例。产品规格一完成，测试员应该开始思考他们该如何将测试用例自动化了。软件开发公司经常要在为特定短期客户项目挑选工具并投资挑选工具和为长期项目/产品挑选工具间做出调解，以避免重新加工或后期浪费大笔费用。移动应用程序短暂的生命周期里在形成一个连贯的工具策略时提出了一个管理难题。这种情况下，基于场景的方法可以帮助管理者对连贯的需求投资负责，为他们公司的移动测试自动化做准备，并为战术和战略项目投资正确的工具。

　　1.支持移动平台
　　无论要求规范是什么，你都需要挑选正确的工具，不仅要支持目标操作系统如iOS，Android，Windows以及它们的不同版本，还要支持底层硬件配置。质量保证团队安排其测试工作时需要考虑许多移动应用程序特有的难题。根本的问题之一是搞明白一个应用程序（代码库）如何在不同的操作系统，界面上运行。尽管移动平台市场的玩家主要是Google和Apple，但开发者仍需要将Symbian和Windows Phone用户考虑在内。即使是在单个平台内，也有一堆软件版本等因素要考虑。因此，检查老和新的平台支持版本极其重要。
　　2.支持应用程序类型
　　一旦初始自动化工具入选，你需要检查可以用这些工具所管理的应用程序的类型。多数工具都是特定的不能同时支持本地，混合和web应用程序。多数移动测试进程并不是万全之策。因此，很有可能需要在自动化流程链中挑选一些工具。根据被测应用程序的类型，至少80%的测试活动可以被自动化（按照帕累托定律算）。然而考虑到一堆平台上的应用程序的功能，需要一些特别的手动测试。使用正确的工具可以帮助提高效率，减少成本，同时可以在部署应用程序或服务时，提供一个客观环境来评估应用程序的质量并预测实际环境中的用户体验。
　　3.源代码要求
　　为了获得佳测试质量，本地移动应用程序应该在安装程序内随附一些工具特定框架，这样软件测试员可以向设备/仿真器发送一些指令直接用本地应用程序执行任务。多数常规浏览器都有它们自己的网络驱动程序，所以测试员可以在这些特定浏览器网络驱动程序的帮助下测试应用程序。在多数情况下，移动应用程序不会带着它们的源代码或框架被交付给测试团队，也是说，它们可以在不同移动平台上模拟同样的功能。在一些情况下，有用于iOS的App Package一类的方法，尽管该模块并不以和拥有源访问的流程一样的方式提供测试覆盖率，但它却为测试提供比精易应用程序安装本身更多的容量。于是源代码和平台框架是需要考虑在内的重要指南，因为不是总能够获得测试用的源代码，尤其是当测试工作被外包给第三方时。
　　4.应用程序重构要求
　　移动测试自动化的另一个障碍是修改应用程序的要求，即重构使之可以被自动化工具测试。重构的技巧是能够验证功能被保留了。测试专业需要确保所有变化在重构前后都被验证了。尽管将这个流程自动化没必要，但这在随后的回归中或许有帮助。重构复杂的应用程序或代码模块是一门艺术，将这些元素自动化应该尽大的努力。挑选的工具应该满足在不同粒度水平交付预期结果所需的可扩展性要求；或许有必要将第三方库包含在测试项目中，建立你的产品的测试版本或改善现有交付测试的app版本。
　　5.测试脚本生成
　　对于需要大量测试覆盖的移动应用程序，创建实时测试脚本或许会提出一个极大的挑战。尽管测试自动化大大地提高了执行效率，但这些效率提高都伴随着巨大的成本，尤其是开发测试脚本库以确保测试覆盖需求的时候。自动化测试用例脚本生成工具也许能通过帮助创建关于运行需求的脚本测试场景进一步提高效率并扩大测试范围。关于可扩展性，所挑选用来自动化生成测试脚本的工具应该要支持脚本参数。然而该方法通常受限于工具能力且无法交付和编程方法一样的覆盖度，它使用power coding和基本编程语言。编程选项没有自动化测试脚本方法那么快，但是其结果更有效更灵活。因此，有必要评估可用资源以便在工具评估过程中挑选一个方法。