参考 sonic 吧 虽然是针对移动端的，但我觉得 sonic 整体设计上包括用户操作的封装都是很不错的

主要还是看能力吧，能力够了薪资自己跟 hr 谈，能力不行就算是多好的学校过来也不能要啊，是不

基本都是拿百度脑图源码做的二开，我现在也在做这个事情

要学的话。可能还是要偏算法和硬件吧

举一反三，掌握共性

如果是为了能够看上去更清晰，是不是可以使用 yml，或者是用一种类 yml 的字符串的方式，然后写个解析的类，比起这种多个花括号的嵌套、缩进要更明显的多，如下面的这种形式

有个思路 在写脚本之前先把注释写好了 最后写完再生成一个接口测试用例文档

xmind 主要优点是比较能够发散思维，讲究的是覆盖尽可能多的功能点，而不是通过用例来帮助新人了解系统，了解系统完全可以用其他的方式来达到目的

可以区分为增量代码覆盖率和全量代码覆盖率，另外，jacoco 有提供覆盖率 merge 的方法，可以了解下，或者说自己来处理两次执行后的代码覆盖率

1、首先基本的逻辑保证正确再来考虑并发问题
2、并发问题可以通过 jemter 模拟并发请求，在所有请求前和所有请求后都查下库存信息，然后根据收集到的接口返回的成功或失败计算出卖出的商品数 跟库存信息比较。

测试覆盖率其实不只是代码覆盖率，还应该有需求覆盖率

用例上直接执行是没有添加监听类的，你可以试下本地执行 xml 看看是个什么效果，是不是重试写的有问题

这个一般是找开发配合，让他们做成是可以配置时间的，不然我们不可能测个功能要等好几天吧。3 天，半个小时，累积在线时长 1 个小时。这些只是简单的一个数字，完全可以做成是配置化的。我们要测的是规则，而不是这几个数字。如果开发实在不做成可配置的 直接改库。

是的，这就需要自己动手去搞一个出来了

最好能够做到自动化，第一步，先对代码进行扫描，一般需要改造的地方都是有几种固定的写法；第二步，将第一步出来的扫描结果和翻译库做对比，有点像是你们做的第一步。

主要的原因是数据不一定都有对应的查询接口，或者接口不一定返回所有字段，所以保险起见还是直接从数据存储的地方进行校验。而且查询接口设计成返回所有数据不一定是一种好的做法。

appium 我也没玩过，只是大概猜测了下

这个看下，如果是 JAVA_HOME 的问题，查下怎么改吧

项目里面配置的 jdk 版本太高了吧，可以检查下

写的还不错，但是就两个字，“普通”，就是 11 楼说的没有亮点，怎么样凸显出你在当前工作中发挥的作用，可以尝试下，你在项目中做了什么事情，取得了什么成就，个人对于这份工作的理解。而不是我在这个项目用什么什么工具，做了什么什么。还有学历跟英语都是加分项

就拿会员注册这个功能来讲，从产品的角度来讲只需要用户注册，然后通过注册的账号和密码进行登录。但是系统在实现过程中，涉及到的不仅仅是把用户的账号密码保存下来，密码的加密，怎么加密，怎么做到安全性，这些都是没有直接体现出来的，这部分的话，就叫做业务之外的东西。那怎么样来针对这部分东西做测试，就是我们要想的，怎么让这些东西变得可以测试，可以验证它的正确性。

大部分还是赞同的，但是对于隔离数据的生成方式个人还是比较推崇通过接口来造数，sql 造数不轻易使用，sql 造出来的数据跟实际的数据出现偏差或遗漏的概率还是比接口造出来的风险要大的