通过代码覆盖率来检测啊，服务端差不多就是 jaocco,移动端 Android 可以使用 jacoco, iOS 也可以使用 XcodeCoverage，这个是精准测试的一部分内容。可以通过测试过程中收集覆盖率数据，最后评估测试的覆盖情况。

首先要了解在公司开发测试平台的目的是什么？不是为了解决什么问题，也不是为了提高测试效率，这些看似首要目标，其实都是次要的。开发测试平台主要是为了让你在晋升，涨工资或是换工作的时候有东西可说；对于你老大来说，他向上汇报的时候，部门是有产出的。明白了这个目的，你就能先定位做什么东西，再后看有没有开源的，如果有改一下做个定制化的封装就好了。如果没有，就根据自己的能力，快速使用前后端框架，开发测试平台即可，不要从零做起，要学会利用现有的开源工具 搭建。

用不用是公司的事，你会不会是你的事。公司可以不用，但是你不会，面试就让你挂掉，这就是现状！无解！！！

如果你说你做过自动化，这几个问题是必问的，因为从这几个问题中可以考查出你是否真正做过自动化。现在就算有实际项目经验的人给你总结一下，你也不可能在面试官面试糊弄过去的，有太多的问题能考查出你是否做过自动化了，比如说：
1，你用的是什么框架和语言，为什么要用这个？
2，这个自动化项目在你们产品有有什么不适应的地方吗？有没有考虑过如何改进？
3，针对这个框架通用的一些弱点，或是不兼容的地方，你们是如何处理的？
4，从你们现在达到效果来看，如果让你从新开始，你会如何做？
5，有没有考虑过以后如何做？或是是业界现在都是怎样做的呢？
.......

领导让你做什么你做什么，不要去考虑什么意义啊，价值啊，成长啊！只要让他认为你能解决他的问题就行了，领导这么做自然有他的考虑，我们不需要知道，只需要知道做了这事后，领导就满意，你就能拿到好绩效就行了。

安装一下 Android Studio，配置一下开发环境，从 github 上下载个 Demo,自己编译安装就可以了；有一定的能力的话，可以修改 Demo,添加自己的功能。如果不是想做 Android 开发，没有必要一步步自己写的。

appium 本身就支持混合 Flutter 的，你可以多研究一下

其实不用论述那么多，你会写代码了，就能拿到高工资；然后面向领导编程就可以了，

不同的项目代码覆盖率的要求不一样的。比如说：
1，服务端的覆盖率，增量一般要求达到 80-90% 左右；
2，移动端的增量覆盖率要求 70-80% 左右；
3，前端覆盖率要求也是 70-80% 左右吧。
全量覆盖率一般会根据 checklist 进行测试的时候，差不多要达到 70% 左右。

本人经历了六七家公司，没有在一家公司看到过主做性能发展的很好的人。早期在新浪微博，有一个主做性能的大牛，最后也是越来越差，究其原因可能是如下几点，个人感觉啊！
1，性能测试需求量不大，一家公司只有发展到一定规模才比较注重性能，初中期比较关注业务；
2，性能做要做好，非常难。需要对公司使用的开发框架，中间件，架构等非常熟悉，才有可能找到性能瓶颈，给出调优建议。如果只是得到性能数据，给开发让他们去调优的话，那就没有必要主要做性能测试了，常规的性能测试工具即可。
3，性能测试硬件要求难以满足，如果测试的服务器和线上服务差别很大，或是用虚拟机来做性能测试，根本达不到效果，而很少有公司做到性能测试的服务器和线上服务器一样的配置的。
4，如果不是公司大领导关注性能，开发不会做性能优化的，出力不讨好，所以从上到下都不愿意做这个事情；
5，现在主流和性能相关的做法是做性能测试平台，全链路测试等等！

根据我做了十多年的测试开发的经验来说，做过了不少尝试，也见过很多大公司类似的产品。只所以说不要做 WebUI 和 AppUI 的自动化的平台化功能，主要是这是要考虑一个投入产出比的问题。

这方面做的还算可以的，是淘宝的一个测试平台，名字就不说了，内部平台。他们成功的原因有如下几个前提：
1，被测试 App 和 Web 是组件化开发，组件是不变化，页面是组件的组合；
2，强大的图像识别服务，有一个团队专门提供这样的服务，识别的准确率较高；
3，以组件为单元进行开发和组织测试用例，而不是以元素。
如果你要测试的应用没有这样的前提，想做成平台化，后续维护起来就非常耗时。举个例子，如登录功能，你要测试的应用有多个地方可以登录，而登录操作的元素都不一样，那就要写多个公用的操作。平台化写用例，还不利于封装和公用，投入产出比较低，所以很多公司不会这么做的。
如果想做 UI 自动化做成平台，可以考虑平台关注以下功能：
1，测试资源的管理，如测试环境，手机设备，测试帐号等；
2，任务调度，灵活生成测试计划，定时执行任务等；
3，测试报告及结果分析，分析执行的结果，失败的原因，最近或是各个版本的执行情况及趋势等；
4，用例的编写和执行，还是交给具体的测试框架来完成，不要用平台来做。
个人经验，仅供讨论！！！

先分析一下你这个需求：你要执行自动化测试，必须有一个地方打开浏览器，访问你要测试的网站。所以执行的时候，必须有这样的一个环境。gitlab 只是管理代码的，没有听说过可以执行用例。通常情况下，会从 gitlab 上下载代码到要执行测试用例的机器上，再借助于 jenkins 进行任务调度执行。

刚刚看了一下你的平台，如果做为练手的还可以，但是要做成产品的话，差的还太多。结合着真实的使用场景去优化一下，WebUI 和 AppUI 是很难用平台去写用例的，不建议往这方面去做，因为在真实的产品中根本无法使用。

github 搜索

很早以前就遇到这样的一个问题了，自己想学习提升，想请教大佬教一下自己或是带一下自己。那么是不是可以反过来问一下，为什么大佬要带你呢？现在在公司内部已经很少有老员工去带新员工了，更不用说不在一个公司呢！如果有一个人让你出 5000 块钱，可以教会你一个什么技术，你是否愿意呢？正是因为太多人想不付出就得到，所以也就没有人愿意分享了

其实这就是职业发展到了一定的阶段都会遇到的问题，想去提升又不知道如何提升？想找一个有相关工作机会的公司，这个可能性比较小，因为公司招你来是解决问题的，并不是让你去学习的。想找个人带你，也不现实，现在公司内都没有老员工愿意带新员工了。现在可以去网上买一些儿线上视频课程，或是买一些测试的书，自己来学习；如果公司有相应的同学在做你感兴趣的事情，也可以花点儿心思去学习一下。

1,iOS 的 Monkey 确实比较慢，这个没有办法，这是因为 WDA 的原因，fastMonkey 也是在 WDA 基础上做的，不过 iOS 系统相对来说稳定些儿，Crash 和 ANR 比较少，可以作为与 Android 相对应的功能，不必放为重点。做了几年的相关工作，也没有发现有什么好的工具，网上相关的资料也比较少。
2，Android 的 Monkey 是模拟点击的，所以可以操作 Native+H5，Flutter 都是没有问题的，只是要控制好相应的跳转。我这个文章的时候，字节的 fastbot-android 还没有开源，后来我分析了一下它的工作原理，感觉还是不错，就用这个了。

公司的项目，不能开源，抱歉，只能讨论一下思路！

是的，这个是业务同学最能直接产出的结果，然后再去找是否有相应的工具；否则没有需求，就谈不上开发工具了

流水帐式写法，毫无特点，不能吸引 HR 的注意力。如果你真不知道怎么写，就去各个招聘网站上，按他们的模块填写你的内容，然后再导下来，就比你这个强。

作为多年做自动化测试的老兵，给你点儿建议：1，先吃透一下做自动化测试目的，常规的使用场景；2，多看一下优秀的开源项目，学习一下架构设计；3，所有自动化测试的维护成本都很高，任何项目架构设计必须易于维护；4，要想真正发挥使用，执行时间，性能方面必须要考虑。然后再对照着你的项目看一下吧？！

增加硬件资源可以提高效率，不过不是最好的手段。二楼说的对，需要多方面考虑一下：
1，从用例执行的流程分析一下，找到耗时的地方，从减少用例执行步骤，提升用例执行时间如入。如通过接口减少操作步骤，合理安排用例执行顺序，优化元素定位方法等。
2，在保证用例之间低耦合的前提下，多开几个浏览器，并发执行就可以了。
3，合理选择用例集，因为 UI 用例天生比接口慢，所以要合理安排执行的用例集，也能有效地提高执行速度的。

这个是肯定的，因为太多的测试同学喜欢被动，产品，开发或是其他测试同学给安排了工作才去干，自己不主动，两三年时间就直接和其他同学拉开了距离！

我们已经做好了整套精准测试的东西，支持服务端，移动端和 Web 端，由于是公司内部的东西，不方便和你讨论的太多！

看了一下大家的讨论，感觉对覆盖率的理解不够全，或者比较片面。代码覆盖率只是一个基础，反映你的测试用例执行到了哪些代码。以这个为基础，可以做调用链路分析，自动化和手工用例与代码的关联，代码和用例之间的追溯关系，用例智能推荐，diff 代码的自动化回归，测试质量评估等一套东西，对应的就是精准测试体系。