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

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

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

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

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

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

通过 jacoco 或是对 jacoco 做二次开发，有一套完整的方案可以使用，同时能支持 java 和 kotlin 系列的语言，经过多方验证的成熟方案他不香吗？对不自研的，没有经过业界验证的方案，在性能，安全性等方面还有待考量的，学习可以，生产中不会有人使用的。

流量回放和录制用例在几年前就提出的概念，经过各大公司多个业务实践过，理论和现实差距很大的。综合考评，投入产出比严重失衡，也可以说价值不够大，这也是这方面的技术后续没有大的发展的原因。文章介绍的工具思路很好，不过无法使用到真实的环境中，一是，不同公司的产品会因为技术，架构，实现方案等原因，造成千差万别，无法统一化；二是，由于安全限制，产品特点等，无法让你获取到相应的流量的；三，收益得不到认可，搞过很多次相关技术专项，业务相关同事只是拿来做参考，不会重视，慢慢的就没有人投入精力去使用了。个人的一些经验，讨论一下。

无论你工作多久，能力多强，都不建议在简历上写"精通"两个字，可以换种说法，比如说：从零开始参与了某个项目的全流程，测试计划是什么？设计了多少用例？发现了多少 Bugs？最终达到了什么效果？而你自己在这个项目中又学到了什么？把数据一一罗列出来，面试官自然会给你的水平打级的。如果你自己说精通，那以中国人的个性，他会努力证明你并不怎么精通，然后再给你定为能力不行，何必给自己挖坑呢！

SDK 测试技术含量很高的，只是你没有接触到而已。首先，需要开发一个测试的 App, 然后基于这个 App 去做 SDK 的动态注入，以便灵活测试各个版本。如果可以的话，也可以拿客户的应用进行动态注入。第二，做自动化测试，基于 app 做自动化测试；性能测试等；第三，当然兼容性测试也是非常重要的，要做兼容性测试，就会涉及到手机集群什么的。总之涉及到的内容是非常多的，可以深入了解一下。

个人做了十年的自动化测试相关的内容，结合个人的经验，不建议使用宣传功能比较强是的框架，直接使用最基础的就行了。python 的话，可以使用 pytest+requests ,或者 requests+unittest；java 的话，直接使用 httpclient+testNG 即可。结合自己公司的业务场景，做一下封装，使用方便灵活，还有成就感！

当你对 App 自动化测试了解的深或是全面的时候，你就不会有这样的疑惑了。不管是什么自动化测试，都是要解决一定的问题的。比如说，想写一个 App 的 UI 自动化测试，只需要针对核心业务的测试用例进行覆盖就行了，不需要把所有的用例都写完的，后面再逐步迭代就行了。曾经遇到一个同事，开发能力还可以，但是要写一个程序，考虑的非常多，非常全；但是呢，迟迟不出成果。这样是非常不好的，要小步快跑，逐步优化才行。

测试工具还是比较初级的玩法，直接拿开源的东西，针对你们的业务做定制化开发就好了。一般都是做测试平台，形成一体化的测试体系，或是从降本提效的角度出来，在项目流程中解决遇到的各种问题，并能形成闭环！

Selenium 想做深入的学习，个人建议有以下几个方向：1，自动化架构设计，无论是 PO 模式，还是数据驱动型模式，做好架构设计，提高代码重用率，降低用例维护成本，添加业务辅助需求。2，框架二次开发，针对固定的业务，做高度定制化，封装固定的业务操作，降低业务同学自动化测试开发的成本。3，引入图像识别和 AI 技术，通过图像识别降低用例元素识别和检测的成本，提高速度和效率；通过 AI 进行场景识别，自动生成测试计划。4，引入性能分析，操作录制等功能，可以自动化的使用场景。5，以 Selenium 为底层技术，构建 UI 自动化测试质量保障体系。个人工作经验积累，仅供参考！

平台看着不错，其实实用效果不强。现在的接口平台都是集成接口管理，接口自动化，Mock 平台，监控，项目管理，持续集成一体化的，单一的接口平台只是工具，简化了 PostMan 而已。WebUI 为什么没有人做平台呢？因为不适合做平台，UI 自动化维护成本高，录制回放的方式都没有流行起来，更不用说使用平台写用例了。这个项目你用来做练习还可以，如果想通用，这个是远远不够的。

你需要一个自动化测试框架，如 Appium 来处理登录的问题，不过不可能支持所有的应用， 要针对特定的应用来写登录脚本。然后借助于字节的 fastbot_android 来实现自动化测试，就可以了！

现在不应该有这样的疑问了吧？互联网行业要会提升自己的能力，首先要了解一下现在测试技术有哪些儿，再有针对性地了解。针对想了解某项技术，如接口自动化，去网上搜，很多搞培训的会给出很多详细的介绍，图表等；了解了一下后，再有针对性地去学习。什么事都不能只想不做，最好是动手去做写写，边写边学！

啥叫 QA 管理工具啊，你得先明确一下自己的需求。testlink 其实就是用例管理工具，现在有不少项目管理工具，不但 QA 可以用，而且整个项目的参考人员都可以用，不过开源的应该不多。先明确了自己的需求，再找对应开源的项目，不要寄希望于开箱即用，能解决你部分问题，再定制化开发即可。

开源就没有好用的，因为这类东西很难做成通用的，要根据公司不同的业务，使用场景，公司基建做定制化才行。常规的做法是，找一些解决通用问题的开源项目，根据公司的业务做二次开发，整合，最后拿来晋级和涨薪；就算有开箱即用的，也不要直接使用。

最好是分开来做，有如下好处：1，方便维护，接口相对来说比较简单，但 UI 就麻烦的多，两者几乎没有共用的。2，显示工作量，一个平台能体现你们的工作量，还是两呢？3，UI 自动化如果想做的好，需要对自动化测试框架做深度定制，对机器的性能要求也高，分开不会相互影响。

工作后不能和上学期间一样了，要调整一下学习方法。以解决当前问题为目的，带着问题去学习。如果要看书，从现在看到死，也看不完，而且很多书你看完也没有用。这点儿可以借鉴一下犹太人，如果不能给你带来金钱的书，都可以不看！

百分之八九十的公司不会写单元测试的，一是因为开发人员不稳定，换来换去，造成代码大家都不太理解，能运行就行了，写什么单元测试啊；二，单元测试增加工作量，收效不大，开发同学认为有 QA 呢，写它干嘛呢？三，单元测试没有使用场景，没有统一的流程去卡单元测试通过率，没有人检测单元测试写的质量，写不写无所谓。四，项目太紧张了，没有时间写！

其实很简单啊，工作就是为了挣钱，让自己过的更好一些儿。怎么能多挣钱呢，就是让自己值钱！每个人让自己值钱的方法不一样，而面试过程就是一个交易过程，你认为自己值多少，面试官认为你值多少？你能说服他，就成功入职，如果不能就面试挂掉。

Appium 只是 AppUI 自动化测试框架，而执行其用例的时候，就有相应的 java 和 python，甚至是其他语言。在对应的语言测试框架下，使用命令行执行自动化用例，分别指定在不同的手机上执行就可以了，通过参数将手机序列号传给 Appium 的 client。这也是很多云测平台做的事情，叫任务分发。

是啊，没有年薪千万，也不送房子，也不包找对象，好像待遇不咋的。