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

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

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

有创意

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

相互学习

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

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

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

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

给你一个建议，1、先梳理流程，得出每个节点上应该干什么事。2、每件事要干啥。3、每件事该如何做（这就是规范了）。4、每件事开始和结束的准入和准出条件，满足什么条件这个事才可以开始，这个事到达什么程度算结束。这四点做好了，项目就运转起来了

看会议类型吧，如果是讨论问题的，不愿意讨论的人，就放飞自我了

建议规范和流程分开说，先明确每个事应有的规范，然后根据实际情况梳理流程，实际情况不同，流程不同，但基本原则还是 v 模型和 w 模型

很可能是驱动力不足，在学习新技术上，要是有人涨工资了，级别提升了，动力就来了

谢谢，我试试

你好，请问这个文件是在哪啊，我用的是 RobotFramework，这里有 pytest.main 这个文件么？

base64 转图片，就直接拿到图片了

请教一下虫师，如果写接口用例时，像自定义一些方法实现特定功能，在平台上http://quick.testpub.cn/RF 的关键字那种怎么实现啊，就是类似

不客气，最近我也在研究，可以一起交流

classfiles 路径这里，最后要到 classes 文件夹，...\target\classes

配置好 LB 后，可以先不用业务去测试，可以用一个默认 web 页，去验证负载均衡。验证没有问题后，再对业务进行测试。

10000 并发，需要再细化一下场景，比如 10000 用户，在多长时间，完成什么样的访问。基于场景设计测试工具的并发量。可以开始进行少量的并发，监控服务端带宽情况。然后进一步看看是否需要优化功能减少带宽，或者增加服务端节点和带宽