挺好的，最少不虚伪。
几年前，我自己做过一些统计:

1. 自己报的 Bug 占整个团队的 1/3， 团队总共 10 个人左右
2. 大部分的业务难点都会找我来询问或者配置一下
3. 结果没有卵用，领导不喜欢我，绩效打成最差
4. 然后反抗了一下，公司对团队不记名调查了一下，谁对你工作中帮助最大，是我
5. 然后我就只能走了

后来，对报 Bug 这种事情，已经没什么感觉了，甚至修 Bug 也无所谓了。
一次开发找一个很奇怪的问题，找不到原因，让复现，偶然复现还是找不到原因，然后开发扔出一堆日志说这那。

最后我把 Apache 的一个包的代码自己看了下，自己调试了一下，发现问题了，结论是

1. apache 这个包会自己默认一个保存文件目录，然后每次重启就会清除一下目录内容
2. 然后这台服务器上有两个服务，同时都用这个包，然后这个重启，就把另外一个服务内容给清楚了

领导会说你好吗？不会，都不会知道，Bug 大家都还以为是开发改的。 现实就是这样，所以后来大家都开始不停的 PPT，需要展示呀。所以大家都需要理解为什么需要 PPT，因为确实也需要，你问不想报 Bug，其实也行，不出问题就行，沟通下就行，就看你自己评估了，再说了，有些开了 Bug 其实开发也不看，也就是来问你，有什么问题吗？问为什么，说邮件或者消息太多了，懒得看了，Bug 管理系统也懒得看，你告诉他就行。所以又说我们都是工具人。一切都有因果吧。

还是很好用的，效率很高，尤其对后端熟悉的同学友好

感谢大佬关注，这个已经有了，马上再写一篇，东西一点一点拼出来。不过都是低成本。

这个样子怎么像重新再做一个 metersphere

其实呢，真自动化了，反正也无所谓，只要出了错开发自己看就行。不要让测试看。

其实使用 jinja2，都不太用写什么，代码一下就都明白了，不用太发明轮子,尤其这种模版引擎之类的

def greeting(name: str):
    return "Hello," + name;


class StructureClass(BaseModel):
    name: str = "name"
    value: str = "value"


def raw_render():
    tpl_str = """
    "Hello, {{ name.upper() }}!"
      Hello, {{ hello()}}!
      Hellom {{greet(name)}}
      Hellom {{ greet(name.upper()) }}
      Hello {{clazz.name}}
    """
    template = tpl_env.from_string(tpl_str)
    template.globals.update({
        "hello": hello_world,
        "greet": greeting
    })
    print(template.render(name="test",clazz=StructureClass()))


raw_render()

运行结果是：python 自己的函数，自己定义的函数都可以使用

"Hello, TEST!"
  Hello, hello_world!
  Hellom Hello,test
  Hellom Hello,TEST
  Hello name

没有量化和其他部门的认可，就舍也不是。
你帮别人发现了很多需求问题，产品很开心，最后也不后说你什么好，如果没有数据支持的话，老板眼里就是产品做的好。
你澄清了很多需求问题，开发做的顺利了，也和你无关，老板眼里就是开发好。
出了 bug，你说再多也没用，老板眼里第一责任人就是你测试。

你不澄清需求，自己最后忙的瘫倒在地，老板说你需求澄清做的不好，你为什么一开始没有发现问题，为什么不反馈问题。还是你测试没做好。

价值怎么体现？都是自己想的吧。

Linux 肯定有用呀，要是 Linux 都没用了，代码可能都没用了

我没那么多想法，理解不了什么本质，无非就是觉得没必要把没学到东西都怪外包，也不要太天真的认为就是有人会来教你东西。至于谋求更大的利益，我觉得我也想的，至于能不能做到那是另外回事。
你说的自我想象的多，哪个人真到了随便一家公司都要去感恩了这个地步你倒是说说呢？你说的这些都是正确的废话，搞得自己很有正义感，众人皆醉，我独醒，外包就是社会畸形产物，你倒是见了多少的社会，在这夸夸其谈的，我见过外包工资比正式员工都高的，也见过外包 java 开发连打字都不太熟悉，也见过死命逼外包的，各式各样都有. 你用别人产品，产品公司就是你的外包，你请别人做家政，家政就是你的外包，你做出租车，出租车就是你的外包，所以这畸形的有点离谱了。

这个话题有点大了，我只是想谋生。至于外包好不好，坏不坏，我说不清楚。每个人都有需求，每个人也都是外包，个体户也有要有活路的。所谓资本洗脑之类的，怎么说呢，反正你爱怎么说怎么说，我也不在意，都看个人吧。至于其他如果你能去改变最好，改变不了也正常，没有必要说什么洗脑之类的。再说洗脑了有怎么样呢？和你有什么关系呢？非要把外包说的那么不好也没有太大意义。

怎么给你哇？好像没地方私聊

2017 年的时候研究过，嗨，时光飞逝，估计给区块链用的

和客户接触多些没有太多坏处，没有必要太局限自己。测试方案主要为了展示自身产品优势，也没坏处；工作是为了挣钱，不是为了当测试。

@allure.title("{name},期望为{expected}")
这样就可以的，name 放到测试方法的参数里面就可以

关于两个问题，如果不客气一点的说，楼主还是明白什么道理，问题分析的非常模糊。而且逻辑也不够通。

1，第一个是开发有个字段取错了，这个字段以前一直都是别人系统传过来的，但是这次要查别人接口取，忘记检查字段取值了，结果影响线上 1000 多个单

这里我有问题问： 别人系统传过来的？和查别人接口获取，有区别吗？别人系统怎么传过来的？无论是别人送过来的还是自己主动调用，对你测试系统来说都是输入，不能完全相信输入这是一条准则？ 别人传过来和自己去查询，就是一回事，不要被开发忽悠了。收到输入参数要做合法性校验的，测试起来确实有点麻烦，但是不是到处在说什么 Mock 吗，那就 Mock 一个了呗。 忘记字段检查取值是个什么意思？这个字段是必须要的还是不必须的？这个字段是变化的还是不变的？都没有挖的底，直知道漏侧，但是不深挖是很难避免的。最少这个事情里面， 对你的帮助：

1. 是不是可以使用 Mock 帮助你测试？
2. 如果一个业务有几个关键字段会直接影响订单的，这几个字段的正常值，null，空，都需要用例去覆盖一下，还有字段的阈值也需要验证

2，java 的一个工具类计算今天是周几，因为老外一周的第一天是周日，所以周日返回 1，周一返回 2，以此类推周六返回 7，开发直接把得到的数减 1，所以周一到周六都是没问题的，周日本来就是 1，减一就成 0 了。当时我没测到周日这个点，结果上线了又出问题了

这个问题有点坑，我觉得对我的启发就是，类似于这种情况，开始和结束时间都需要试一下，这样才能确定这个顺序是怎么排的。 当然工具类，其实可以直接把代码拿出来，自己跑一下测试，工具类其实没什么依赖的。还有就是周 1-周日业务上有什么不同吗？为什么 0 就不行了，星期几不是只用来做一下表示吗？

1. 基础理论，怎么 ACID，CAP，一致性这种需要了解下
2. 如果是分布式，可能更复杂一些，如果内存数据库，也可能更复杂
3. 最少 SQL 要会，各种 SQL 函数用的很溜
4. 最少要一门语言
5. 理论知识要比想的难多了

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

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. 想突破自己，付出的努力比大部分人想象的要大的太多太多，很少有人能坚持下来。同时就算突破，也不会带来本质上的财富变化 -- 还是不要讨论什么财富的变化了，先有工作做吧

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