下个月就 40

为什么要用另一个语言去做一个语言的单元测试？

自动化都需要投入，如果不想投入开发成本和维护成本，我觉得不用考虑自动化了

Web : selenium
App: appium
鸿蒙：hypium

在论坛的不等于就是互联网吧

我们之前也想过用同一套 RF 去做 API 的测试，但考虑到 API 其实涉及很多数据的传递， 组装，验证，是不适宜用自然语言去处理的； 而且 API 本身不怎么涉及业务流程，自然语言的优势也发挥不上来。 所以还是采取 pytest

这个其实还是要看团队的情况和选择。 有些团队成员的代码能力达不到预期的话， 直接写出来的代码也很难维护，反而这种搭积木式的用例会更适合。

参考 8 楼的回答吧，这些都是测试的基础，自己可以查询一下

从结果来看，当然是希望 100% 覆盖。 但还是要看投入产出比。
根据测试金字塔， 更多的自动化应该放在 UT， API 上面， UI 的部分能多做就多做，不行就挑重点的覆盖； 然后如果是长期的产品， 就需要维护一个回归测试的用例库，然后朝着这个目标去慢慢把越来越多的回归用例自动化。这样后面可以大量节省回归测试的时间。

什么等价类，边界值，决策树 这些都了解过吗？

先搞清楚你的需要是什么，是 “把某些测试用例通过自动化的方式去执行”， 还是 “自动地去做测试执行，甚至探索”

平时善用 Google 、百度这些平台去查自己需要的信息的人，对 AI 的适应力和使用越强。

在银行的测试团队里面，身边很多三十多岁甚至四十多的小伙伴。 说下我的观察：在某些行业里面，还是会看重稳定的员工：业务扎实，项目测试可靠。 如果在一个行业里面有自己的业务积累，一定程度还是能找到工作；不过未来会受到多大冲击（AI? 年轻人的冲击？），这个我没办法评论。

我觉得还是需要有自己的积累：

1. 技术积累？ 基本的自动化经验还是需要的，不如很多面试的机会可能都拿不到； 如果能积累到某个水平的技术专家，那就是自己的竞争力了。 不过坦白说，如果本身不是太属于计算机科班出身，然后前期的工作中也没有这方面的学习和成长，想要有大的竞争力，还是很难。
2. 业务积累？ 如果有某个行业的业务深入的积累，比如金融，银行，通信之类的， 在对口的行业公司就比零经验的人更有竞争力。
3. 快速学习和适应能力？ 现在的行业用人淘汰率还是挺高的，要在一个新的公司、团队站得住脚，快速成长，就要快速地领悟业务，适应团队和工作模式，越快上手，在团队、领导眼中的表现就越好，也越愿意继续培养。
4. 沟通、交际能力？ 测试工作离不开跟各种角色的同事进行沟通，你的沟通能力越好，就越能胜任一些更容易出成绩的项目，甚至往测试经理，测试负责人方向走。
5. 某些特定的竞争力。 比如在外企里，学好英文是一个重要的加分竞争力。

既然用 python 了，用 flaskapi 来模拟一个简单的 api 会不会简单一点？
下面是让代码助手帮我生成的代码：

## 用flask api 写一个 mock 的商品查询返回
from flask import Flask
from flask_restful import Resource, Api, reqparse, abort
app = Flask(__name__)
api = Api(app)
products = {
    1:{'id':1,'name':'Apple','price':'10'},
    2:{'id':2,'name':'Banana','price':'5'},
    3:{'id':3,'name':'Orange','price':'8'},
    4:{'id':4,'name':'Pear','price':'7'},
    5:{'id':5,'name':'Grape','price':'9'},
    6:{'id':6,'name':'Pineapple','price':'12'},
}

class Product(Resource):
    def get(self, id):
        if id in products:
            return products[id]
        else:
            return {'message':'Product not found'}, 404

api.add_resource(Product, '/<int:id>')
app.run(debug=True)
if __name__ == '__main__':
    app.run(debug=True)

RF 也是可以放在 keyword 那个层级去定位元素的，不建议直接在 test case 级别直接写。 这块完全是你自己可以去掌握。

楼主的需求是要低代码，所以 RF 在方面是满足的。 至于性能，多线程，兼容性之类的， 要楼主自行判断和评估。
我们这边几十个人的团队，用了五六年 RF 问题也不大。

你们要用纯中文来写用例吗？一种可行的思路是把英文的关键字都用中文封装一遍， 自己评估一下吧

了解一下 robot framework ➕ selenium 或者 playwright， 自然语言描述就贴近低代码， 另外也有扩展的能力和空间。

CICD 自动构建不就好了吗？为什么还要手动部署？

同意啊， 已经很明显出现了奔溃的现象， 还在想着没必要加入回归测试，我没办法理解。
所谓回归测试，就是即使没有任何改动，也要去回归一遍， 保证功能正常。 因为就算没有代码的改动，也不能保证所有的依赖（服务器，操作系统，浏览器等等）可能的变化对功能的影响。

这其实是你们的策略制定的出发点是什么， 如果说纯粹从技术角度来看， 没问题；
但是从质量管理的角度来看， 已经有客户会在实际使用的时候遇到这种奔溃的问题，而且从你的描述来看，不是随机的小概率事件，而是某些功能你们选择性地不去回归，没有发现问题。

如果是新功能影响到的老功能，说明你们的回归测试策略不完整。
有没有必要都放到回归测试里面，是基于风险去评估的， 很明显你们现在的情况就是需要加上。

1. 如果奔溃是功能性产生的，可以考虑跑个 monkey 测试之类的， 多覆盖一些随机的操作
2. 如果奔溃是跟设备兼容性相关的， 检查一下兼容性的测试策略， 还有找云测平台跑一下不同的设备。
3. 做好奔溃日志收集，定期检查分析，找出可能存在的问题。

每个行业都有历史发展的过程啊， IBM 小型机在某个时间就是处理这种业务的最好选择，很多银行系统都是沿用到现在。

你把读出来的每个 row 打印出来就知道了 ， 自己调试一下吧。
先把这个 get data 的方法给调通。