不错，已收藏。后面有空读下这些书

比较关注，各个平台的测试结果数据那么多，楼主是怎么沟通确定具体需要展示什么数据，用什么形式展示的？

可以分享下这块不？

我们有内部体验，发个邮件给各干系人可以直接下载体验，体验有问题可以找对接人反馈。不过一般实际上会体验的人不多。
也会直接约一个小时会议室，各个 leader 拿着已经装好包的测试机结合产品对本版本功能的介绍，集中进行体验 + 现场反馈。这种一般会比较有效果，也能收到不少有效反馈。

但我们没叫体验测试，不知道和你说的是不是一样。

你说的调试是指编写过程中的调试（类似写代码的断点调试），还是后面多次运行偶尔出现的出错后问题排查定位？

如果是前者，看是否可以支持一个一个 action 手动执行 + 随时手动插入 action 功能。之前看到站内开源的 opendx 这块做的挺不错，但它是针对 app 的，你可以看下看是否有可以借鉴的点？

不过从习惯写代码的角度，再怎么好的 web 平台，调试起来还是没有 ide 的断点调试那么强大。

对的。

一般叫做 configuration 的东西，用途都是全局配置，基本都是一个线程组里创建一次就够了。

防火墙？

招聘请发到招聘区，已帮你移到招聘专区了。

另外，麻烦补充下薪酬范围

一个 jdbc connection configuration 应该是对应创建一个数据库连接的
一个 jdbc request 才是对应使用这个数据库连接进行一次查询

如果查询的是同一个数据库，那创建一次连接就可以了

官方文档：https://jmeter.apache.org/usermanual/build-db-test-plan.html

你看下是不是你用法错了，每次查询都创建了新的数据库连接，导致连接数过多？

建议框架层面，增加在出错后自动截图和记录 page source 的功能，这类问题一般看截图和 page source 才能搞清楚发生了什么，光一个堆栈看不出啥。

没看懂你的问题，无法回答。

有点疑惑你想要校验的功能是什么？增加和删除元素后，列表是否能正常刷新展示最新数据？

我想如果可以增加/删除成功，应该说明它从服务器拉取的数据是正确的

你这个是纯 UI 自动化，只能看到用户看到的东西么？想校验拉取数据是否正确，我理解可以考虑加一个调用服务端接口或者直接查数据库的操作，然后比对下前几个内容是否一致，这样是不是效率更高、目标更纯粹呢？

通过增加删除来校验，有好处也有缺点。好处是一条用例把增删查都测完了，通过率高的话确实效率是有提升的，用例数量也少。缺点是把读和写混在一起了，会引起出问题的可能原因增加了，稳定性会降低，排查定位成本也会增加一些。比如如果出了问题导致读的内容不对，有可能是写的时候出问题，也可能是读的时候出问题，得人工另外排查。

建议先了解下开发是怎么实现的？

一般这种每一行的元素是重复的滑动控件，每一行的子控件是复用的。进入页面时根据控件大小申请对应的子控件对象数量，子控件在界面显示范围内消失后直接根据数据源更换里面的显示内容，再重新显示出来，减少重复申请释放对象消耗的时间。这个和 web 内部始终会记录完整 dom 树是不大一样的。

如果如你所说前一页显示列表长度，下一页显示具体列表，一般实现方式是第一页的长度是直接服务端返回的，不会是根据列表页实际内容计算长度（因为这个时候没必要显示列表内容，所以没必要拿数据量很大的列表页内容，而且还有可能遇到列表页数据分页，一次请求拿不到全部数据）。

如果采用的确实是这种实现，从原理上是会有一定概率前一个页面的长度显示和具体列表不一致的（比如在长度显示用的接口请求完毕到进入列表页这个时间间隔里，有其他用户修改了列表页内容，导致长度发生了变化），所以这个校验就算不通过也不能说一定有 bug。

因为日志的用处大多是在排查定位失败原因上，我们的解决方法是直接结合到测试报告框架里。

比如 extentreport 里面，提供了一些方法可以打印 info 到报告界面。我们在 Logback 加个自定义 appender ，appender 里打印日志时也调用报告框架里面打印 info 的函数。这样日志就同时也直接打印到这个报告界面里，看报告就可以直接一并看到当时打印的每条日志（比如完整的 request 和 response 信息）

你这个提问信息太少了，类比下，就像我问你为啥我电脑突然开不了机一样。你下一步应该会问最近电脑做过什么调整，开不了机具体什么症状啥的对吧？

建议补充下你相关的一些信息，比如你的自动化脚本内容、各个软件版本之类的。减少沟通成本=提高效率

另外，我搜了下你报错一些片段文字，貌似和 chrome 浏览器有关。你可以看下：

https://cn.bing.com/search?q=ERROR%3Agpu_init.cc%28426%29&qs=n&form=QBLH&sp=-1&pq=error%3Agpu_init.cc%28426%29&sc=0-22&sk=&cvid=134E0FEE4C2A475A89F921EBC4F59EB4

https://cn.bing.com/search?q=ERROR%3Adevice_event_log_impl.cc%28214%29&qs=n&form=QBRE&sp=-1&pq=error%3Adevice_event_log_impl.cc%28214%29&sc=0-35&sk=&cvid=ADD1587A7993400B84A1E362E6A0FD69

持续集成（把接口自动化做到每次提交代码都自动执行，执行不通过自动预警啥的）、流程改进、左移右移，方向挺多的。

建议可以审视下目前有什么东西是重复出现问题的，优先去改进，效果会比较明显。

但是一旦该模块调用其他模块后，在其他模块内报错了，就显示用例通过

没看懂这一句，把你会失败和成功的两个用例具体代码贴上来？

日志模块只是额外打印日志，一般不会影响成功失败的判定吧。

想确认下，你这里的操作对象，是同一个 app 吗，不同之处只是一个用 appium inspector ，一个用代码的 driver ？

1、开发很忙不愿意配合——给你代码权限，你撸完加上单测，直接提 PR 给开发审核合并

2、从日志输出获取信息——不用那么复杂吧，最简单操作完毕后，直接调 shell 命令 tail 一下日志文件最后几行，用正则提取就好。

建议用第一种方式，既帮助你熟悉 sdk 内部实现，也降低自动化成本，关键还提高了你在开发眼中的地位，以后做这类可测性提升的意见建议也会更容易被接纳吧。

另外，不知道你这里提到的监听器具体对应是什么，建议你也先了解清楚内部实现以及为何这么实现，再确定最佳解决方案吧。

我在另一个帖子里有提过，面试回答问题不要太简略，容易被误以为这方面不熟悉，换着方向问寻找技能点。有兴趣可以看看，了解下从面试官角度是怎么看待简略的回答的：https://testerhome.com/topics/29703#reply-192242

这个时候会比较被动，因为一般情况下面试官知识面广度和深度会比你强一些，这么问下来你的长处没被发觉，短板倒是都被问出来了。

不过平时这些知识倒是都可以了解下，比如 mq 怎么发消息，怎么保证幂等之类的。涨知识同时也便于出现 bug 时更好理解出现原因以及如何解决，让你后面有更多机会在设计、代码评审阶段预防问题，而非测试阶段甚至线上再发现问题。

二面技术细节问得挺细的，既有移动端，也有服务端，还有性能压测和造数据提效工具。

好奇面得是什么岗位，还是你简历里这些都有写上？

sdk 是你们自家的么？如果是，让开发加几个一些可以查状态值的方法，是不是就可以？

另外建个贴，把成功和不成功的两个 python 完整代码都发出来吧。

也是。

有什么好招么？毕竟不是人口普查，挺难做到真的全部覆盖。

这个信息略敏感，而且还是非匿名，这么公开收集不妥当吧。

之前社区有做过调查问卷采集，可以参考下。离题主说的 30K 起步还有很大距离。
https://testerhome.com/topics/27946

另外，真想了解真实工资，认识一些同行闲聊了解吧。只要是公开收集的信息，都会带有收集平台本身的受众倾向性，我也认识一些同学可能都没听过社区的，会听过社区甚至关注社区的，一般团队里都是比较不错的，薪酬也会相对高一些。

感谢详尽的回复，这个视角确实和我的不大一样。

可能我个人想法比较简单直接吧，我倒不会很介意解释失败原因会导致自己陷入不必要的困境这个点。面试本身也是一种交流和相互认识，坦诚直面自己没做好的地方，并去分享自己的反思，我倒觉得没什么。如果对方确实关注流程改进能力，而自己确实没有这方面的成功经验，坦诚说出来就好，如果对方看重必须有成功经验，不合适通不过也情理之中。

至于第二句的三个句号，我想表达的点并不是不认可这种提意见的人，只是放在面试场景且期望他有这方面能力经验的话，这个水平和期望会有差距，会有点惋惜。一般这种情况我会询问当时的完整情况，以及他自己没有再进一步的原因。客观因素导致难以推动可以理解，我自己也遇到过很多推动很困难的情况，所以并不会因为没有结果而否定努力。但我更关注的是他的态度，做过哪些尝试，努力到了什么程度，自己的反思是什么。如果是已经被客观条件影响，态度比较消极不愿意再努力尝试，个人表示能力有限，没信心能让他快速恢复积极心态成为战斗力，只能遗憾错过。

最后，忘了以前从哪里看到过，面试招聘，应该要找到水平在团队 50% 同学水平之上的人，才能让团队保持持续上升。面试始终会是一个比较甄选的过程，对内部愿意提意见的员工进行鼓励支持，和面试中录取只愿意提意见不愿意行动的面试者，还是不大一样的。