我写过一篇文章《为什么要做精准测试？》，和你这篇要唱对台戏了，不过涉及到很多内部技术，无法发出来，

测试中手工环节均有可能工具化，工具扩大一下就是平台化，平台功能多点儿就是体系化，度量化，监控化，智能化。。。

看完本篇文章，忍不住地要赞美一下，配图真的不错！

不用那么费劲，就是指定的手机号，输入 000000 验证码，过滤一切验证逻辑就可以了！

如果是自家的系统，可以添加上白名单，如果是这个帐号，验证码为固定的，后面的滑块验证不会出现就行了。如果要是其他公司的产品，你是绕不过去的，这就是为了防止自动化的。

你可以看出做测试产品的公司，有发展好的吗？有没有想过是什么原因呢？如果把公司的产品交给第三方测试，首先，安全如何保证，我的产品还没有上线呢，让竞对知道了怎么办？第二，项目周期无法把控，第三方测试如何保证测试时间。第三，沟通成本太高，发现了 bug 后，怎么能让开发全面了解情况，修改后又如何快速验证。这些都限制着第三方测试，大部分公司都不会用这样的产品的。

必须有啊，漏测率是一个基本的指标，还会统计增量覆盖率，召回率，精确度，筛选率等精准测试的基本指标。通过相应的指标评估测试质量，对比每轮测试的效率，各个版本的测试质量等等吧！

我们的精准测试体系已经落地了，现在在效率工程团队用了一年多了。通过使用精准测试，评估需求改动范围，解析调用链路，精准定位影响范围；根据变动，推荐需要回归的用例，大大提高了测试效率；同时，在测试完成后，又可以通过全量和增量报告分析测试的覆盖率，增量了测试的信心。

根据我多年做自动化测试的经验来提醒一下，不要把各种自动化都放到一个项目中，虽然感觉这样做的话一个项目非常强大；有个页面化管理的话，那就非常牛 X 了。但是你有没有在业界看到有这样成熟的方案呢？各大公司也没有这么做的，因为后期的维护成本高的吓人，会让使用者放弃对自动化的使用的。还是把不同的自动化拆解成不同的项目，不同的项目甚至可以采取不同的框架，后期做统计的调度分析即可！

大家讨论的挺激烈的嘛，其实只是站的角度不同，考虑问题的方面就不同。如果把测试用例的用途仅仅是拿来测试开发的功能，检测是否存在 bug 的话，那就无所谓了，Excel，FreeMind 都可以，哪个维护成本比较小，就用哪儿个。甚至可以把测试用例写的非常细化，这样领导看起来显得工作量比较多。
但是，如果想拿测试用例去做一些儿高级的事情，如 15 所说，就必须标准化了。如手工用例关联自动化用例，测试用例关联开发代码，在精准测试中利用机器学习做用例推荐等等。如果测试用例不标准，你就知道有多痛苦了，无论你使用什么模型，都推荐不准确的。

以十一年测试开发经验，期间差不多一直在做 UI 自动化相关的工作，可以很负责任地告诉你，UI 自动化不能做平台。如果想做的话，要明白平台化的 UI 自动化，是依赖于录制回放的，业界这么多年都没有好的录制回放方案，说明投入产出比太低了。如果你有好的图像识别服务的话，这块可以搞，否则不用搞，没有办法执行的。

通过代码覆盖率来检测啊，服务端差不多就是 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 搜索