个人觉得，这么说太笼统了，也有一些想当然，以下是一些想法：

1. 怎么叫别人的数据库？ 数据库都是公司的，还能是别人的？
2. 微服务是可能是按照领域划分，这个是逻辑概念，一个数据库，比如 postgresql，可以有很多 schema 的，共用一个数据库，但是使用不同 schema，这样数据库是别人的也是自己的，那开发肯定要直连数据库的
3. 数据库性能问题可能也只是猜想，性能问题都是相对的，你有多少访问量数据之后才好说性能问题
4. 访问日志的问题，最可靠的访问日志不是写到日志，是在数据库里记录，自己数据的变化没有记录，不能怪数据库不行，日志级别修改这个也不能说服人，一旦你发现数据改了，然后再把日志级别调整，这有用吗？改都改过了，日志没记录，还查什么东西？再试一次看日志？那再试一次看数据库不是也行吗？
5. 文件一般都不用数据库存储的，文件很大，实际上传输会不可靠，未必会比数据库好用；医院这个例子很明显这个文件方式本身就不好，数据实时性很差，万一晚上数据处理出错，那可能得拖延 1-2 天，用文件传输，是异步处理，异步处理方法多的很
6. 消息队列，添加新的组件，会增加开发成本，这都是衡量出来的，另外使用消息队列了，那谁是消息的发起方，谁是消费方呢？ 你要完成自己的需求，却要别人组帮你完成原来不需要做的事情，别人也未必为答应

我感觉可能有点太喜欢吐槽别人的方案了，但是自己其实也没想清楚，为什么不行？有什么好处，有什么坏处？这个方案需要再多久内解决？这些都是采用方案的变量，可能还有更多，脱离了实际情况的变量，存粹讨论方案，很难说就是别人的方案不好。

日常沟通都有的，这都是正常工作范围。日常的沟通指出问题都有，但是看不到改进和反馈。我觉得现实是不能把人想的太坏也不能太好，从自己的情绪里面自己走出来时最好，如果走不出来，那会把话说的狠点，只是没有到说狠点话的程度。给了三个月时间，足够可以看出能不能自我调整了。关于接口自动化并不是重要而紧急的事情，正因为这样可以看到一个人是不是自驱，是不是自己能够调整，是不是自己可以找到一些办法，是不是可以自己安排好自己的时间，主要是靠自己解决问题，如果都要靠别人哄着，反正在我这里是要减分。至于少一个人，确实也没什么影响，大部分的情况下，少一个人有什么影响？

可能都是太把自己当一回事了，技术上的事情听了一些大词汇，到实际又下不了手自己做不出来，又觉得自己听的是哪个大佬说的，是对的，那就只能怪没给资源了，或者被边缘化了.

2000 个页面，根本不是什么事情，有发帖这个功夫，一组人算他 5 个，可能一半工作都完成了。
自动遍历还要截图，截图还要看吗？如果要看一下，和自己点开看有什么区别。如果是一次性工作，手工做一下性价比最高。叫上开发一起做都行，如果公司有 30 个人，算下来一个人也就 65 个页面，一天抖音都不止看这么多。

第一张截图表示你没有使用 pytest 在 pycharm 里面跑测试。 load unittest 。。。。。，需要在 pycharm 里面配置一下使用 pytest 跑测试

这年头还在用 mycat 呀

这句话其实是不对的,这是领导的懒政。 这种都是前面 10 多年遗留下来的话，现实是你面对的是海量的用户，一部分用户的建议不能代表什么，反馈也不一定能代表什么，否则那些 AB test 工具用来做什么？你的意见就是个屁，你能代表哪个用户？代表了这个就能让另外的客户满意了？ 不按照数据看，都是领导懒政的说辞，说起来没问题的，但是如果现在领导还这么说，我觉得这种领导其实很久没学习了

只是就事论事的讨论，

1. 比如说 owner 心态不是每个开发都有的，有的也是少数， 把每个开发换成每个人也对的 - 所以呢？讨论测试还是讨论人？
2. 未知的东西往往价值更高，有时候把未知变成全部已知并评价，难度只会更大- 对，问题是已知的东西都没怎么搞懂，去能搞未知的？
3. 想突破自己，付出的努力比大部分人想象的要大的太多太多，很少有人能坚持下来。同时就算突破，也不会带来本质上的财富变化 -- 还是不要讨论什么财富的变化了，先有工作做吧

结论是，别多提什么概念了，做软件测试的，最少要知道软件怎么做出来的吧？一门语言要熟悉吧，代码能写写吧，文档能看懂吧，出了问题自己能解决一些吧？最少最少别出来一堆英文报错，连怎么找资料怎么修复一下吧

问题是您说的这些：
感谢大家给我的回复，下边是我通过大家的回复总结的我个人想要研究的点
1、研发流程中的改进
2、如何挖掘测试人员的价值
3、为什么有的团体队还需要测试，怎么让他们成长的不需要测试
4、接口自动化
5、开发方案多参与，对于用例和测试能更全面
6、性能，安全
7、调研不需要测试的开发人员看看他们是如何做自测的，是否需要测试人员提供协助

哪个开发或者架构师不能做？放弃幻想吧，这个高水平的团队里面测试就要和开发开发能力相当才行。否则连他们讨论什么担心什么都不知道。

小公司测试开发比一般开发要求高了，往往面对的问题是：

1. Devops 各种平台集成,什么 gitlab，k8s,jenkins,jira, 需要很快的学习能力
2. 不管工具还是平台需要走产品化路线，所以你需要自己有想法，又了解日常测试需求和潜在需求，才可能好样
3. 基本上可能需要全栈了，前端后端，js，java，python，typescript 估计都需要，搞不好还需要点 golang 之类的
4. 最后平台需要有数据追踪，分析的能力，所以又需要建立点指标系统，那么数据分析什么 ETL/数据可视化多少又需要了，这是需要点数仓基础支持，可能还需要点大数据周边的一些能力
5. 推广能力/优先级设定能力， 说的直白点就是 PPT 的能力，和说服别人的能力

所以做起来很累，小公司一般基础设施不太好，大公司可能也很累，系统繁多而复杂，各个组都是小山头，沟通很费劲，另外每个组的惯性思维方式也不一样，谈需求的时候需要尽可能的适应不同的说法，抽象不同说法里面的共性。嗨，苦苦苦。。。。

大部分问题不准备能回答出来，但是有啥用呢，年纪太大，不要。

突然发现这个和我很久以前的框架其实思路差不多的， http://testerhome.com/topics/3690
其实都不需要打包放 jenkins 的，直接使用 maven 命令就可以跑了.

有一点不明白，既然 UI 变化很大，不停的变，录制一边变化和实际做一次测试的区别是啥呢？

个人觉得 AI 测试也好，自动化测试也好，如果要真的要完全自动化，那么最终都会 AI。我举个例子来说，在测试行当很多人其实对 selenium 做自动化测试有很大的质疑，但是其实现在有些什么 RPA 工具也在用 selenium，可能都是用在实际商业流程中。目前的自动化实际上大体上把手工测试的内容用代码实现，如果和 AI 代表的自动化来说，这都不能算是自动化，AI 测试是推导，可以根据历史自运行，自己解决问题；但是如果 AI 能测试了，那么代码也都可以自动写了，个人观点. 这应该还是有很长的路好走。我觉得测试开发也好，测试也好，对于大部分从事这个工作的人来说，就一件代码熟练这件事情能达到的比例熟练这个程度的都不多。 我们大部分人都低估了代码熟练度这件事情；同样关于提效这件事情，我们也低估了沟通和协作的重要性，看着产品经理说的是一套语言，开发是另外一套说辞，测试也有一套语言，其实可能说的都是一件事情，你一份文档，我一份文档，写了很多文档，但是为什么一件事情要这么多文档，为什么写了这么多文档，还是很多人说没有文档，同样为什么开了那么多会议没有一个统一的，结构化的，清晰的需求也好，说明也好，指导也好；这是为什么？ 反正我对我们团队的要求就是， 代码熟练度/沟通总结能力是不能少的，其他什么平台也好，工具也好，一点点加，需要就加；代码熟练了，加点功能就应该顺手写出来，代码熟练了，写接口调用的代码就应该顺手写出来；沟通顺畅了，抓到重点了，一件事情就不应该一遍又一遍的重复.

我觉得或许以后有议题说如何让忙碌的测试同样可以达到代码熟练这个简单又不简单的目标.

有很多的内容都不错，但是又是一看代码就觉得有时 ppt 说的是不是过头了。举个例子来说： https://github.com/alibaba/intelligent-test-platform 这个以前 alimama 分享出来的测试平台，但是代码质量真的......,如果开源出来的测试工具代表业界的一定水准，那么我觉得 alimama 这个代码，让我对所有分享的高大上内容产生了怀疑。

比如说对接能不能通？配置配的对不对等等等，大体就是这个事我做完了，配置也改了，对接也做了，但是不知道对不对。需要测试去测试下，当然自己还没有试过。

一般启动看到类似：

java.lang.NoSuchMethodError: org.yaml.snakeyaml.LoaderOptions.setAllowDuplicateKeys(Z)V

这种 NoSucheMethodError 错误基本上都是 java maven 依赖的问题.

可以使用 mvn dependency:tree > depenency.txt ，再仔细检查一下有没有重复依赖的包，同时版本又不一样的.

不抢 KPI，但是想分别人如果 KPI 获得的好处呢？

我很赞同你的想法 @hellohell ，多谢 @ 恒温 @ 陈恒捷 大佬，这块我自己也想到一些问题：

1. 线上数据如何说明场景覆盖更全了？有什么理论依据吗？要不然就算采集了数据，回放 100 万次是同样的用例有什么价值呢？
2. 如果说异常数据只是偶然的几条造成的，这个数据如何被采样到 diff 平台？不能只是撞运气吧
3. 还是就是数据脱敏的问题怎么解决？这么多线上数据被用来做测试的话，我感觉要被告死的
4. 还有就是线上数据和测试环境的用户基础数据应该是完全不同的，线上数据就这么容易的可以回放了？感觉真是有很多很多的问题待解答

到底这中 Diff 平台带来了多大的提升？
继续请各位大佬帮助回答。

但是接口测试不是比 UI 自动化容易吗？

很多英语文档要看的，英语学好没坏处。看文档看的快，做事情就快。

“CBU的一次大促，运营人员至少需要配置千级以上的活动页面，而每一个页面上又包含几百上千个商品等活动元素，平均一个页面需要5到10分钟的人肉检测，同时运营和测试人员需要不断就测试标准和 Bug 来回讨论、提交。一次大促下来，我们至少需要十几人/日的测试资源才能保证会场的正确性。”

说实话不太明白为什么运营人员要和测试人员不断测试标准和 Bug 来回讨论，测试要是花 10 多天检查会场页面的显示的正确性，其实测试人员也很贵的。如果运营人员不够，没有办法支撑大型活动，那么要么产品还有很大改善空间（或者确实有很大难点不好突破，或者其实就是短期就是没办法突破了），要么就是通过流程，在短时间内增加外包人员。 但是和测试有多大关系？不过本人呆过的大部分公司其实也都是这样，缺人的时候就找测试帮忙。

这东西写的都很好，但是可能一看代码就把人吓死。就像 alimama 前面开源的一个什么智能引擎。这东西有点不明白的就是运营上传一个文件不能预览一下吗？这么费劲搞了一大堆，都不知道面对的具体问题到底什么

“CBU的一次大促，运营人员至少需要配置千级以上的活动页面，而每一个页面上又包含几百上千个商品等活动元素，平均一个页面需要5到10分钟的人肉检测，同时运营和测试人员需要不断就测试标准和 Bug 来回讨论、提交。一次大促下来，我们至少需要十几人/日的测试资源才能保证会场的正确性。”

这种东西到底是产品问题还是测试问题？实在是很难说。

另外这个架构要是追查什么实时质量数据能扛住，那是见鬼了。阿里一天的数据量要这个结构能扛住，我觉得有点不可思议。

自动化的难点就是这个，需要测试接口 8，结果需要把 1-7 的接口都调用一次。然后各种环境问题，各种团队合作的问题，各种不稳定的问题。不是自动化本身有多难，而是你需要把周边的各种事情安排的妥妥帖帖。生活是真艰难。