加油！

有和开发沟通过大部分 bug 自测应该就能发现这个问题么，开发的想法是怎样的？

看到历史已经有同学问过类似问题，可以看下是否可以参考？

https://testerhome.com/topics/18304

个人理解并不是没有启动，而是 jenkins 执行完 job 释放资源时，连带把你启动的 tomcat 集成也一起杀掉（释放）了。

突然被 @ 了好惊喜呀，这个项目挺不错，让 golang 的同学也可以用上 WDA ，点赞！

她们的诉求是造数据能不能只给出看到 code 值（页面上实际展示的编码），id 界面上看不到，也不知道是什么

如果 code 和你接口用到的 id 有一一对应关系，我理解也可以呀，你在底层做一个 codeToId 的转换就好，根据 code 到数据库查 id 。不过说实话，如果界面看不到就不知道怎么查的话，感觉做接口测试这类相对灰盒的测试，有点早？

能问下你这边指的思路也是通过调用接口去生成吗？但是抽取出来？

调用接口后，去数据库查出来。没有通用组件那么复杂。我们的业务是借贷业务，贯穿全程的是用户和账单信息，1:n 关系（一个用户可以多个订单），所以做了一个 model 统一存储一次流程中这些会强相互关联的信息。model 里面的值可以从手动写的配置文件取，配置文件没有那就调用对应造数据方法造出来 set 到 model 的实例里，这些写在一些全局 setUp 的方法里就行。

关于最后一点，“其实本质上所有协议都是数据传输加接收” 这一点我时间认同的，有两点疑问，一个是抽象出来的 model 是包括了 url、header，请求内容和期望的吗？现在只是基于 testng 将请求内容和期望外加描述信息做了一个抽取，请求的 url 是单独的一个配置，能具体描述下 model 的全貌吗？另外，你这边指的 send 方法类似于 httpClient 中的 execute 这种感觉吗？

url、header 本身就是 http 协议的一部分，应该属于请求执行方面的东西，model 不需要包含。model 只需要管理这个接口对应的数据模型即可。这只是抛砖引玉哈，我们公司内部项目基本上是比较统一的 http 协议，所以暂时用不到这个。我这里的思路有点类似于 rpc 调用，程序只需要知道方法，直接去调用即可，具体用什么协议由 rpc 框架来负责。比如 dubbo 支持多种不同的网络传输协议 (https://dubbo.apache.org/zh-cn/docs/user/references/protocol/http.html)，切换协议只需要调整一些配置，不用调整代码编写方式。
send 方法类似于你说的 execute ，本质上就是一个通用接口，固定函数的格式。不同协议，提供不同的实现即可。

关于 1：例如我调用新增订单的时候，我需要选择一些额外的系统信息（必填项），例如用户、店铺、商品等等，那么如果这些是前置造好的话，那么每个环节新增用户生成的 id 什么的都不一样，所以才会不好配置，因为这些属性太多了；但是如果我为了新增订单，每次再去新增用户、店铺、用户等信息那么我觉得链路过长了。

我理解你的目标应该是造数据给第八个接口用？如果是，那先保障第八个接口的需要，如果第八个接口可以使用固定的用户、店铺等信息，那就在你的接口调用里直接把这些 id 做成配置项传入即可。id 管理由人来做。到后面有需要那就把配置项改为不是人写上去，而是程序自动生成和记录即可。

另外还有个痛点是，现在系统相当于是三种不同架构模式的...

这个是老系统持续重构的常见问题，严格不是技术问题，而是取舍。最低成本当然是统一架构后再直接基于新架构写接口用例，但这样价值也最低，因为重构过程中用不上。如果重构也希望有自动化协助，那就要增加成本（新老架构各写一套用例）。

至于接口调用实际使用协议的差异，其实本质上所有协议都是数据传输加接收。框架设计得好数据应该是抽象的模型（比如 model 层），具体协议可以直接基于模型写生成方法（如 json、xml、yaml 等），请求发送也是类似，统一命名为 send 方法，使用者只需要用这个方法即可。至于实际用的是 http 还是别的协议，由负责维护这个接口的同学写具体实现即可。我理解并不是不能做，而是这么做框架设计会变得复杂一些，所以需要像上面说的，衡量投入产出比。

比如 jmeter 支持把自己设置为 http proxy 后，自动录制经过的调用为 http sampler ，然后调整改动下后可以变为接口调用的封装。
又或者把你的抓包记录导出为 har 格式，然后用 httprunner 生成对应的调用 yaml 用例，同样把需要变化的入参变为变量传入，也可以成为接口调用的封装。

可能数据有点太乐观，1 天我这里指的是编写用例的时间，具体调通 8 个接口并可以连起来，如果遇到阻碍或者疑难杂症（比如环境有问题、用的是非 http 接口、数据带有加解密之类的），估计会需要更长时间。

看投入产出比。

个人经验，假设说现状是没有隔离，如果有下面的情况，建议隔离：
1、经常出现一个功能一会可以，一会不行。问了整个研发团队都没人反馈，只能不了了之，上线时这个功能是可以还是不可以都得碰运气
2、阻塞性问题出现频繁，而且卡住后大家一起上都得解好几个小时，其他人只能等，然后加班赶进度
3、有些配置或开关，打开后会严重影响其他人使用（比如直接通过开关关掉用户登录）。但开发需要开，测试需要关，两边需要有冲突

不过隔离后必须要解决的问题是，开发环境的持续维护。
一方面，开发人比测试多，变更更频繁，且上去的很可能是没有跑通过的代码，出问题可能性更大。
另一方面，如果系统服务比较多，链路比较复杂，开发不熟悉整个环境，容易自己改动破坏了流程的正常使用而不自知。

这个持续维护的成本，很可能对开发团队而言挺高的。但不处理好的话，开发环境就会变得无法使用（流程都走不通，也没人知道怎么解决，相当于废掉了），为了项目进度，测试环境还是会被开发占用做联调。

最好的办法是，一套公共环境维持和线上版本一致，然后每个需求开发自己可以基于这个公共环境复制一套，测试也自己复制一套，上线后这些环境回收，并更新公共环境。这样就不用持续维护一个环境了，而且以需求为单位人数会少一些，也避免了太多人使用相互影响。不过背后就需要有比较完善的环境管理平台了，人工操作成本太高了。

那么我的测试【处理 8】这个接口的时候，数据准备应该如何？

个人建议用方案一，从 1-7 的 api 一个个造过来，原因嘛，主要是方案二很难协作，且很明显对外的接口改动频率会比对内的数据库结构改动频率要低和容易察觉。成本方面，其实一次性做 8 个接口的 http 调用函数，如果接口文档明确，或者基于抓包的实际报文直接写调用（注意是调用而非用例），应该全时间投入的话 1 天内的工作量？

1、说明一下另一个不太愿意调用接口去造数据的原因是，现在业务中例如单据这种都是要求的 id，包括单据中的一些属性值都是需要传值 id，然后和公司账号相关联的，还考虑到环境的问题，例如我测试环境和灰度环境，数据库是两套，所以一套入参不能满足两个环境运行，可能我还是想要脱离这个限制吧，让这个接口测试代码是可复用的，而不是一旦换了环境或者数据库因为某种原因重置了，一些前置的操作还需要手动去执行。

不大明白为何和环境有关就会影响用接口造数据？

我举个场景，比如第一个接口是创建订单，第二个接口是修改订单。第一个接口会插入记录创造 id ，然后第二个会需要根据创建的订单去请求，那只需要在第一个接口调用成功和第二个接口开始调用之间，增加一个数据库查询的动作就可以了。至于如何查，可以考虑根据订单的创建时间、订单内容之类的去查询，只要订单内容有一定的随机性（比如加上一些日期时间戳）就好

而多环境，本质上是配置的差异（后端服务的 url、数据库地址等），这些只需要把这些抽离成配置项或者全局变量，切换时调整这些值就好，接口调用本身是可以复用的。我们现在内部也是这么做，框架集成了 spring boot config 特性，通过 profile 切换不同配置文件，进而切换环境。

2、不知道大家现在服务架构是如何的，我们现在是在切换到 vue+springboot 的模式进行中，会有一个 service 和 controller，我的理解上，要做接口测试，应该是针对 controller 层的，但是实际要求我做 service 层的接口测试，会有点迷茫吧，就是一个 service 接口可能支持了好多 controller 的，实际上 service 接口的入参真的有点庞大了，让我在对入参组合的测试上非常的懵，不知道界限是什么。

service 一般不会直接暴露为外部调用的 http 接口吧？不大理解你这里接口测试的范畴是什么。一般 mvc 结构里，service 应该在 controller 和 dao 之间，用于做比较复杂的业务逻辑，避免 controller 过重。如果针对这一层做测试，个人理解应该是属于单元测试范畴了，需要把 dao 通过 mock 等手段控制返回，然后模拟各种可能的场景组合（查到数据、查不到数据、查到但值为 null 等）。

hmm，我的意思是，你讲的这些都是比较虚的道理，缺少和大家会遇到的场景结合，新手会觉得云里雾里。对于大部分同学来说，学习知识比较高效且容易的方式，是类比或者举例子。

举个例子：
1、对象（Object) ：可以对其做事情的一些东西。一个对象有状态、行为和标识三种属性。类（class)：一个共享相同结构和行为的对象的集合。
2、举例来说，“狗” 这个类会包含狗的一切基础特征，例如它的孕育、毛皮颜色和吠叫的能力。而一只实际在你面前撒娇的二哈则是一个对象。

是不是有第二个生活中的例子辅助，会容易理解很多？

另一方面，实际上大部分软件公司系统测试、集成测试其实没有那么明确的区分，或者说基本没有完全符合你上面概念的系统、集成测试。那是不是从一些实际项目实践上讲，会比单纯教科书里讲概念更有意义？

违法，原因是你没法说清哪些部分是公司定制的。

如果真想开源，直接基于原来你基于的那个开源项目重新做更好，你那些更好的设计也可以直接用上，少很多技术债务

不错，说得挺简单易懂。

感觉这么讲有点虚，建议可以结合一个实际项目的实战来举例说明？

不要一棍子打死大部分产品。只能说你接触到的都不大好。

另外，"拓展用户， 利润点回归"、” 市场上新的营销和富增长点 “ ，这两个没太看懂是什么意思？

后面的几点都很认可，应该说做优秀的效能提升人员，都需要做到这几个点。

但对于开篇的其它团队误解，个人觉得核心点还是成果不够明显，以及和其它团队交流不够。问题不是大家不了解行业中的测开，而是不了解你们公司的测开。这其实有点危险。

一场测开团队成果分享，或者一些测开项目和其它团队交流合作下，也许会好很多。

手机连电脑，用电脑截屏、传钉钉和装 apk？

看得出来，你和你头儿关系挺好的。开弓没有回头箭，祝你下一家更好吧。

稍微多口说一句，有大委屈可以试着先找人倾诉下，不一定都得自己憋着，自己也会好受点。

走捷径的办法，可以考虑直接做流量录制回放。

如果不好做录制回放，那如果接口没有产生变更，以前也没有做对应接口测试的话，没太大必要特意当时就做接口测试。每次只做有改动的而且比较重要的，慢慢你也会积累到不少用例了。

PS：建议先想清楚做接口测试的目的和价值，这样你做接口测试的范围应该不会是这全部过千个接口。

10.15.1 (19B88)

1、不要想着用 ui 自动化、接口自动化测试完，就不用再去测。这些自动化实践中作用更多是确保没有非常明显突出的问题，要达到自动化测试完就不用再测，校验点会非常多，编写和维护成本也高

2、楼主的核心目标其实是减少回归测试工作量，提高效率。个人觉得，相比用各种自动化，更建议可以尝试下面 2 个方向：
2.1 熟悉开发的代码，掌握从开发改动点倒推影响范围的能力，缩小自己的回归范围。既然有能力做 ui 自动化，那熟悉下项目的代码应该不至于非常难。
2.2 根据线上业务情况，精简回归用例，找准重点。确认哪些地方出问题风险高、用户量大、必须回归后才能上线，哪些地方风险低，发现后修复也可以。

挺不错的感悟，很正能量。加油！

这个问题挺有意思的。

我本地试了下：

$ crontab -l
* * * * * /bin/date
* * * * * cat /Users/hengjiechen/pgadmin.log > ~/crontab.log 2>&1

# 确认 date 是不是会持续存在
$ ps aux | grep date
...
hengjiechen      45574   0.0  0.0        0      0   ??  Z    10:32PM   0:00.00 (date)
hengjiechen      45542   0.0  0.0        0      0   ??  Z    10:31PM   0:00.00 (date)

# 看下 mail 是不是有增加
$ mail
No mail for hengjiechen

# 查看同时段其它进程情况
$ ps aux | grep 10:32
root             45573   0.0  0.0  4297100     92   ??  S    10:32PM   0:00.00 /usr/sbin/cron
root             45575   0.0  0.0        0      0   ??  Z    10:32PM   0:00.00 (cron)
hengjiechen      50546   0.0  0.0  4269212    476 s002  R+   11:16PM   0:00.00 grep --color=auto --exclude-dir=.bzr --exclude-dir=CVS --exclude-dir=.git --exclude-dir=.hg --exclude-dir=.svn 10:32
hengjiechen      45574   0.0  0.0        0      0   ??  Z    10:32PM   0:00.00 (date)

# 查看这几个进程之间的关系
$ pstree 45573
-+- 45573 root /usr/sbin/cron
 |--= 45574 hengjiechen (date)
 \--- 45575 root (cron)

# 删掉最上层的 crontab 进程
$ sudo kill 45573

# 确认删除结果
$ ps aux | grep 10:32
hengjiechen      50608   0.0  0.0  4287752    728 s002  S+   11:18PM   0:00.00 grep --color=auto --exclude-dir=.bzr --exclude-dir=CVS --exclude-dir=.git --exclude-dir=.hg --exclude-dir=.svn 10:32

从现象上看：
1、crontab 定时执行，每次执行会新建一个进程。
2、如果任务中有些命令没有重定向输出，会持续存在，进程不会自动结束。而有重定向的会自动结束。
3、mail 默认收不到 crontab 日志通知。至于什么原因，待探究。

至于原因嘛，还在查询中，这方面资料太少了，大多只是说要用重定向，但基本都没提及不用的话会怎样。

感觉你样样会，但都不精。作为 4 年测试工程师，应该有个主攻方向或者比较深入能拿得出手的技能？

个人建议，相比于对行业来说需要你学习什么，更建议你关注对于你们自己公司、你们当前项目，你需要做什么，可以去提高质量或者效率，并把它作为你接下来一段时间的主攻方向。如果你觉得你现在做的平台确实能在项目中用起来，那就去收集确认这个平台怎么做更能在项目中让大家用起来，大部分时候时候明确需求比明确技术方案要重要得多，方向不对容易努力白费。

另外，没见到楼主提到是否有阅读熟悉过公司开发使用的一些框架技术，建议也可以去熟悉下，参与到一些开发设计方案中，这样你的影响力也更大，也更容易看到性价比高的提效方法，产生价值。

个人觉得，测试开发的核心点不是用工具或者会编程，而是能够用技术的手段更有效地去提高公司项目的质量和效率。

这个是 repeater 自动生成的，对于同一个回放记录来说是固定值，类似回放记录自己的唯一 id 。

看你日志，appium 的两个辅助应用都没给安装（[INSTALL_CANCELED_BY_USER]），官方文档有提到可能会用到这两个应用，建议装上？
官方文档地址：http://appium.io/docs/en/drivers/android-uiautomator2/index.html

另外，也建议确认下，你的手机是否支持 uiautomator 2 。

uiautomator2 和默认模式不一样，所以需要加载的内容、对设备的要求也有差异，所以默认模式可以不能代表 uiautomator2 也可以哈。