那么我的测试【处理 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 也可以哈。

心态很赞。

看到楼主提到自己要补的东西很多，然后后面就只是持续学习，感觉好像楼主还没找到自己接下来一段时间要专注的方向。
建议还是找准一个方向，定个自己觉得比较有挑战的目标，钻下去想尽办法达成它。然后你会发现，你收获的将不只是这个方向的知识，还有独立学习的方法、一些志同道合的朋友和成就感，这些对以后的成长帮助都会很大。

@weizhao1zhao 可以用 jmeter 。可以用 JavaSamplerClient（自己写 java 代码并打包给 jmeter ）或者把 grpc 契约包打包成 jar 包，加入 jmeter 依赖后给 beanshell 使用。

后者相对灵活一些，但会有额外的性能损耗（beanshell 解析器的资源消耗）。

想了解下，这里提到了很多 “建议将该值设为 xx” ，这里的建议是基于什么场景下给出的？

我理解参数调优，没有最好，只有最合适的吧。调大了占资源，调小了容易达到瓶颈。没有具体上下文场景的参数调优，真的比默认值好吗？

另外，能否给个各参数优化前后的性能对比数据？要不只知道要这么做，不知道为啥和做不做的效果区别，感觉有点只是抄答案，记忆不够深刻。

这个写法是可以解决问题，但感觉有点像是补丁，写起来比较别扭。

建议可以把需要引用不同 page 的部分单独再抽离一层，或者直接写到用例层。这样同层之间跨文件不相互引用，只有上层引用下层，就不会有循环引用的问题。别人理解起来也方便。

写得好全，测试时间被压缩，都可以用这招了。

其实这种测试时间被压缩的，质量风险大，整个团队都知道。更多是业务确实非常需要，没有这个都无法开展业务，质量风险大也得顶着先上产生价值。这个时候一般就冒烟通过、未覆盖的点列出来且大家觉得可接受，就直接上了。

很完整的文章，各种 python 官方地址，很齐全。

想请教下，文章中用到的 adb 二进制文件应该是 windows 用的。如果这个包想要做到跨平台可用，不同平台用不同的二进制文件，这个怎么操作？

感觉楼主有点激情不再的感觉。怎么说呢，既然进公司面试有些技术问题也都可以答上来，说明还是有些技术底子的，一直只是做业务不搞改进，不会觉得没什么意思吗？

看到你最后写了 好多 ，我理解你不是没思路，是东西太多不知道从何做起？

如果是，可以把痛点列出来，解决困难度也列一下，然后按性价比排序，先从性价比高的做起。