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

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

问题是您说的这些：
感谢大家给我的回复，下边是我通过大家的回复总结的我个人想要研究的点
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 能测试了，那么代码也都可以自动写了，个人观点. 这应该还是有很长的路好走。我觉得测试开发也好，测试也好，对于大部分从事这个工作的人来说，就一件代码熟练这件事情能达到的比例熟练这个程度的都不多。 我们大部分人都低估了代码熟练度这件事情；同样关于提效这件事情，我们也低估了沟通和协作的重要性，看着产品经理说的是一套语言，开发是另外一套说辞，测试也有一套语言，其实可能说的都是一件事情，你一份文档，我一份文档，写了很多文档，但是为什么一件事情要这么多文档，为什么写了这么多文档，还是很多人说没有文档，同样为什么开了那么多会议没有一个统一的，结构化的，清晰的需求也好，说明也好，指导也好；这是为什么？ 反正我对我们团队的要求就是， 代码熟练度/沟通总结能力是不能少的，其他什么平台也好，工具也好，一点点加，需要就加；代码熟练了，加点功能就应该顺手写出来，代码熟练了，写接口调用的代码就应该顺手写出来；沟通顺畅了，抓到重点了，一件事情就不应该一遍又一遍的重复.

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