3 年有这些实践和基础已经不错了，1. 可以换大一些的公司继续做测试，丰富一些方法论。2. 转成开发。3. 转向项目管理。从我个人的历程来说，建议在不抛弃核心能力的基础上，尽早考虑转型。

建议多和前端研发沟通沟通，可以精简不少 case，同时增加一些从业务角度的特殊情况，比如边界值等测试

逻辑感觉有点问题，需求是产品同事提的，用例是测试同学写，这两类角色写的内容，怎么会融合到一个文档里？
但是需求文档里，有时是有测试用例的，但是这个测试用例是产品验收时的出口条件，是关键的主流程，也是产品同事写的。

有创意

这个东西与其去计算，不如一个经验丰富的负责人估算来的准确。研发水平，研发责任心，研发过程中对单元测试的执行程度，测试水平，测试工具，自动化测试是否包含。还有领导对测试是否重视，是否对自动化有要求，对产品质量的重视程度多大。包括项目价值，是否需要高质量。综合评定，多维度

相互学习

是的，RobotFramework 是可以照顾到编码能力欠缺的同学，我的总结就是，这个框架适合水平有高有低的测试团队使用，这个角度挺好的

属于合理，不然研发交付出来的东西测试不满意怎么办，为了解决这个矛盾，提供研发冒烟测试用例，必须测试通过后再交付测试，也是约束研发质量的一种方法

看来兄台是真的被伤过，哈哈
确实，RobotFramework 的界面 RIDE 不是很好用，用例多了还有性能问题，所以我这平时都是直接使用 IDE pycharm 了。第二个兼容问题，确实也是一个问题，Python 版本，还有用到的类库的版本，需要有一个组合匹配，不能全用最新的，用起来会出问题。我这好在之前花过一些时间调试过，有一套相对稳定的版本对应关系，团队成员就都用一样的了

嗯，RobotFramework 它是关键字驱动，可读性还是相对好一些。处理数据和根据实际业务测试，还是需要自定义 Python 类。其实，团队能力平均的话，使用 pytest 还是比较好的，脚本语言还是会更加灵活。我这团队不同人的能力是阶梯类型的，所以选择了 RobotFramework，懂代码多一些的人负责框架和类库的创建和维护，基础能力一般的，就写用例。