前言App自动化测试一直是小微团队很少涉足的领域，在互联网快速迭代的背景下，随着业务的发展，回归压力逐渐增大.相信每次因为回归覆盖面不够而导致的线上事故，气得想砸桌子的绝对不止我一个。一般来说，小微团队的测试，包括回归测试都是人工进行的，而一些偏离主流程但又比较关键的业务，往往很容易被人工回归测试遗漏。人手已尽。这时候，自动化测试的想法就从你的脑子里冒出来了，然后你就去研究。但它可能最终成为研究。自动化框架的搭建就更不用说了，各种细分的边界案例，必然是一件很繁琐的事情，想想就更繁琐了。如果你是APP开发者，业务开发的人手不是很充足，那么你开发自动化脚本就无能为力了！如果你是一名测试人员，业务需求测试的每一次迭代都会排满你的日程，更不用说负担不只是App测试任务了。作为一个小微团队，我们也想自动化，但是我们没有资源……首先，我们要明白，App自动化测试并没有你想象的那么强大，但是如果你面临着痛苦像我这样的回归测试点，绝对可以满足你的需求。它没有那么强大，所以它没有你想象的那么复杂，它的参与者应该不局限于Tester或Developer，这样你可以有更灵活的资源部署。当然，自动化测试是一个长期的过程，它的未来也不会只是一个倒退……最后，给大家安利一个冷门自动化测试工具：Calabash。并提供Calabash入门教程博客和我的一点经验。引入Calabash是因为我个人认为Calabash的特性更适合资源稀缺的小微团队。大话App自动化测试仅代表个人观点，知识还比较浅。欢迎打我脸。说说大家都知道的现状吧。以Android为例，从2010年开始，Android开发环境及其快速发展到今天已经成熟，开发者不再局限于这个单一的开发平台。统一：ReactNactive、WEEX、H5……开发环境成熟，但移动端测试环境落后。中间有几座大山是很多团队都在面临和停下来的：1.与服务端测试不同，App测试通常只需要验证数据本身。App涉及界面展示和交互，自动识别难度大。2、互联网公司一直追求快速迭代，App直连用户。App的界面和逻辑变化是家常便饭。写自动化测试脚本的稳定性很差。可以对之前链接到此页面的界面进行设计更改。的所有脚本。3.Android和iOS双平台，网页。在多平台的情况下，想要靠一套代码进行自动化测试几乎是不可能的。然后考虑你需要经常改变，你知道的。4.与手动测试相比，自动化测试可能需要针对各种边界情况编写大量脚本。与人工测试相比，可能需要提前设计几个场景，其他异常边界情况可以在测试过程中人工观察。自动化测试成本翻倍！因此，一个完整的移动端自动化测试环境，往往需要庞大的测试团队支撑，而庞大的测试团队，只有大公司才有能力承担。移动自动化测试一直被中小型创业公司所忽视。小公司开发自测，中型公司靠测试人员人工验证。自动化测试真的对小微团队关闭了吗？Justdoit上面提到的现状只能说是一个难题。也许现在讨论和解决这些问题还为时过早。我觉得有些事情你还没有把握好，不如先按照我的思路来吧？当你想通了以下几点，也许这些问题就可以避免，你就可以避免了。如果你需要努力工作，你应该做好心理准备。1.设置阶段方案的试错其实小微团队面临自动化测试最大的问题就是：投入产出比！很难估计实施自动化测试后页面的频繁变化和脚本的开发维护之间，测试人员或者开发人员都不会陷入困境。但是纸上谈兵永远不会有结果，其他大公司的参考价值也不是很强，因为涉及到团队、资源分配、业务变更频率、测试工具、脚本开发的解耦程度等等。但是自动化测试是必然趋势，所以行动才是最重要的！你的团队适不适合，你试过才知道。不妨先设置几个stage，然后使用第一个stage试错：Stage1：抽取一个人一次迭代资源完成主流程业务的自动化测试用例，测试跑两到三个迭代，并增加主进程在此期间的exceptioncase。用这三个迭代来评估后续开发的可行性！Phase2-（Stage1已成功通过）：如果你认为Phase1的状态还不错，那么在维持Phase1结果的基础上，按照业务key从剩余的业务场景中选择一个新的业务根据变化的程度和频率，按照一个业务一个一个迭代的节奏编写自动化测试用例！Phase2-(Phase1Excessivefailureofphase1)：当然，经过3次迭代评估，随着异常情况的增多，同步维护难度越来越大。你可能认为实施自动化测试的成本太高，但不要轻易放弃这三个迭代的结果。请先用编程思维检查所有测试脚本，是否可以提取类似代码，封装具体的View操作，提取与业务无关的指令。同时，考虑动用整组资源来维护这套主要流程自动化案例。执行阶段3或重新执行阶段1，直到未来资源充足或找到更好的替代方案。Phase3：经过大约5到8次迭代，你已经成功度过了Phase2，这意味着你的自动化测试环境走上了正轨。这时候可以根据团队资源适当加快自动化案例覆盖！每人使用一次迭代相信这是一种你可以接受的试错的损失。当然，不要急于先做。您可能只是决定进行自动化测试，但您仍然需要制定一些详细的计划并准备一些想法和实际行动！2.确定清晰简单的目标。有了大计划，还需要明确具体要求。可选需求大致如下：1.黑盒测试还是白盒测试虽然是UI自动化测试，但是也可以分为黑盒或者白盒，看你要测试的精度。度，也就是这个时候，你可以初步确定使用什么自动化测试工具。比如我们通常会选择Appium这个双平台的跨平台测试工具，但是如果你对测试要求比较高，以Android为例，建议你使用Android官方推荐的测试框架：Espresso，直接在Android项目在项目中编写测试。看起来大家都明白，但是如果前期不能明确自己的需求，后期可能会造成很大的麻烦！选择Appium，因为它是一个黑盒子，当你遇到一些特殊的场景或者需求的时候，就会出问题。个别情况无法测试。或者选择Espresso，后来发现没有那么精准的测试需求，导致后期无法跨平台，或者觉得Espresso写起来成本太高，很难交给测试组.2、前端UI还是整体业务。比如抢单发货的场景。找到订单点击抢单，然后取餐，最后完成配送。这套UI层操作只能用肉眼观察。我们暂且认为这是前端的UI逻辑。但在这一系列操作的背后，订单状态的流转导致了其他数据的变化，如：钱包数据变化、活动奖励数据变化、欺诈订单判定等，这个范围属于整体业务范畴。我们现在需要确定的是，你要达到的测试预期是UI测试还是整体业务测试。这直接决定了你的测试脚本的复杂程度。而我的建议是只测试UI逻辑，这也是希望大家降低期望值的一点。从一个清晰简单的目标开始，然后直接投入其中。想多了，困难就多了。最后，您可能只是考虑一下。这就是我接下来要说的：降低你的期望！3.降低你的期望。接下来，我们通常会通过操作应用程序来进行各种案例验证。只要运营app验证通过，我们就基本可以确认前后端没有问题。但这个前提是，人工验证是人脑加肉眼，会有更准确的主观判断。涉及前端和后端交互将增加很大的复杂性。你的测试用例不会无限多无限细，但作为人脑，你会在有限的案例执行中发现更多不合理的bug：不合理的折叠文本OK、不准确的数值显示、错误的按钮颜色、错误的Toast显示数量等等。自动化测试将严格遵循您编写的脚本。您能确保涵盖所有案例吗？这也是很多人在谈到自动化测试时都会问到的问题。这么多异常情况怎么写？想想都累，考虑投入产出比还是人工测试。首先必须明确，前后端自动化测试一定要分开。一套解决不了问题，所以在前端测试中可以忽略很多case。另外，自动化测试和项目成长一样，都是一个长期的过程。自动化完全取代人工还需要一段时间。一步也别想了。还有很多案例要写吧？如果我们没有足够的资源，我们可以先跑完主进程。跑通主进程意味着脚本依赖（环境搭建，视图定位）已经比较成熟，其他异常情况脚本只要修改主进程的脚本就可以了，慢慢来吧，这时候可以让其他开发或者测试让他们效仿。这是我们上面提到的阶段1。如果这些问题都想不通，你会发现在App自动化测试的有限条件下，达不到你想要的结果，你就会迫于压力而放弃。说服自己降低期望！降低期望值，首先要以回归为目标来降低期望值，必须要有前后端自动化测试，一套解决不了问题，降低期望值，client还有很多局限性-侧自动化测试，不能完全抛弃人工测试验证来降低你的期望值。不能一口咬成胖子，自动化测试也需要慢慢迭代完善。首先，它跑通然后关心验证异常情况。快速迭代，逐步完善4.技术行业专攻也许你的团队中有开发或测试方无法承受压力，于是开始探索App自动化测试。开发做自动化测试的好处是，因为你有更丰富的开发经验，你更熟练搭建测试环境，因为你自己写代码，你会更清楚风险点在哪里，你可以写有针对性的案例。测试做自动化测试的好处是可以发现更多的边界场景，编写更全面的测试用例。在自动化测试方面，开发和测试各有优势，但同时这也是彼此的劣势。测试用例要尽可能全面，自动化测试本身就是一个工程项目。在写脚本的时候，如果考虑更多的编程思路，合理的耦合解耦，会让后续的脚本编写更加方便。因此，不建议将自动化测试完全交给测试人员或开发人员单独负责，最好有密切的合作关系。这也是解决资源不足的办法。虽然是测试，但是开发的加入会让测试项目朝着更好的方向发展。5.一巴掌不能听首先，我们再次澄清我的一个观点：在没有足够资源的情况下，移动客户端的自动化测试应该以回归测试为主。与人工测试相比，自动化测试非常死板，因此需要非常“死板”的数据支持。如果是App开发（像我）做自动化测试，是不是必须mock所有的数据？?虽然前后端自动化应该分开，但是我也说了我们应该只关心前端逻辑。但是还是要在真实的服务环境（测试环境，非生产环境）中进行测试。mock数据过于死板，很多案例可能无法验证。比如注册场景，需要验证注册账号无法再次注册时的异常提示。mock数据显然很难兼顾正常注册和异常注册。在真实环境中进行测试，如果检测到后端错误，那岂不是很好。而且直接在生产环境测试手机淘宝这样一个完整的2C应用似乎问题不大，但是对于蜂鸟外卖这样的半2C应用就比较尴尬了。直接去网上抓单显然是不可能的，所以在测试环境下这个谁来发单，怎么发？所以这个时候，你自己是做不到的。去找测试同学看看能不能搭建一个配合自动化测试的测试环境。以抢单为例。我希望在这种环境下永远有很多订单。让我抓住。我是抢单的app，没有单我还玩什么。测试同学搞不定，那就去找后端同学。相信为了项目越来越好，他们是不会拒绝你的。自动化测试不仅有自动化测试工具就够了，还需要测试环境的支持。总结其实说了这么多，就是想让大家降低期望，付诸行动。自动识别App和多平台自然会有大量的自动化工具帮你实现，学会降低期望值也会降低脚本开发和维护的难度。
