开源版是免费使用的，核心功能都是免费的

好用也很关键。一旦不好用，摩擦力大，不够易用，测试人员就会选择他最舒服的方式，分分钟放弃自动化。

自己写 beanshell 比较合适，语法比较简单 链接 https://blog.csdn.net/hujyhfwfh2/article/details/80862134

没有试过

可以使用官方最新的版本，目前是 v1.9.3

搭建成功了，使用的离线包

期待！

还是不错的，有央企国企，也有很多本土知名企业。

目前先进行议题和讨论话题征集，6 月开始活动报名！

对朱少民老师的观点总结的很到位

首先最最重要的，我认为是快速学习并转化为生产力的能力，即 “学了就能会，学了就能用”。

研发相关能力：

至少一门熟练掌握的语言及其对应的框架（应用及测试框架），拿到需求（评审&设计后）可以又快又好做得出来
熟悉主流数据库，SQL 语句会写会调，视图、函数、事务都能用得上
扎实的计算机基础知识：数据结构、算法、计算机网络、操作系统，并能应用到具体问题分析中
熟悉自己的枪：各种开发环境的搭建、插件配置等等
测试相关能力：
这个大家都比较专业，就不展开了，核心我想表达的就一点：能够无缝切换为业务测试的工程师

运维相关能力：

Linux、Docker、K8s 等容器化虚拟化技术
Ansible 等自动化运维能力
持续集成相关（归纳到运维里不太合适，暂且放在这里），Jenkins、CICD、DevOps
项目管理能力：
掌握应知应会的项目管理能力，敏捷、CICD 等等。一个项目的各个阶段能够主持开展，能够去调研用户（这里的用户可能是你开发工具及平台的用户，比如测试工程师）的需求，并真正挖掘用户的根本需求，可以少走很多弯路

工程效能思维：

站在与测试同事不同的视角去看待软件生命周期的全流程，去熟悉并改进开发与测试之间的写作方式，对现有的积累、痛点、弊端都了然于胸，知己知彼，从解决问题到创造需求，以达到质的提高。

对新兴技术的敏感度

时刻保持对技术的热情，积极主动关注各大技术博客、论坛、开源社区等，多探索，多动手，多实践。

表达能力

关键时候要能说出来哦

不看掌握啥技能，只看解决啥问题 、 主动发现，主动解决，逐个击破，提高质效

很详细！具有参考价值

首先最最重要的，我认为是快速学习并转化为生产力的能力，即“学了就能会，学了就能用”。

研发相关能力：

• 至少一门熟练掌握的语言及其对应的框架（应用及测试框架），拿到需求（评审&设计后）可以又快又好做得出来
• 熟悉主流数据库，SQL 语句会写会调，视图、函数、事务都能用得上
• 扎实的计算机基础知识：数据结构、算法、计算机网络、操作系统，并能应用到具体问题分析中
• 熟悉自己的枪：各种开发环境的搭建、插件配置等等

测试相关能力：

这个大家都比较专业，就不展开了，核心我想表达的就一点：能够无缝切换为业务测试的工程师

运维相关能力：

• Linux、Docker、K8s 等容器化虚拟化技术
• Ansible 等自动化运维能力
• 持续集成相关（归纳到运维里不太合适，暂且放在这里），Jenkins、CICD、DevOps

项目管理能力：

掌握应知应会的项目管理能力，敏捷、CICD 等等。一个项目的各个阶段能够主持开展，能够去调研用户（这里的用户可能是你开发工具及平台的用户，比如测试工程师）的需求，并真正挖掘用户的根本需求，可以少走很多弯路

工程效能思维：

站在与测试同事不同的视角去看待软件生命周期的全流程，去熟悉并改进开发与测试之间的写作方式，对现有的积累、痛点、弊端都了然于胸，知己知彼，从解决问题到创造需求，以达到质的提高。

对新兴技术的敏感度

时刻保持对技术的热情，积极主动关注各大技术博客、论坛、开源社区等，多探索，多动手，多实践。

表达能力

关键时候要能说出来哦

不看掌握啥技能，只看解决啥问题 、 主动发现，主动解决，逐个击破，提高质效

不看掌握什么技术，只看解决什么问题。
目标是为了解决问题，需要什么就学习什么，相信自己的学习能力和应用能力！

不看运用什么技术，只看解决什么问题。

（先声明我真的不是打广告）可以看下这篇文章的内容 https://mp.weixin.qq.com/s/6qBEFMgKt5BA-dBjineVPQ ，这个平台应该可以解决你的问题。

针对你的问题，
1.一般认为自动化应该首先保障正常场景，以供冒烟和归回，之后再进行异常场景。
2.如何写要看你的自动化用例准备怎么管理
3.httprunner 我在 2020 年上半年用过，然后弃坑了。。。

不完全是这个意思，希望能从实际场景出发，分析实际场景中各个接口的比例（这一步会用到请求日志），然后来决定如何设计测试计划。

建议拉一份生产的请求日志，然后写个简单的脚本处理一下看看各个场景占比各多少，或者分析性能需求，需要什么就测什么。

类似的步骤可以有：

• 测试需求分析：测试中涉及的性能指标的定义，要看用户的明确需求和隐含需求

• 测试对象分析：测试中涉及的业务及系统内部模块的定义，分析各个模块的调用关系，理清系统架构

• 测试重点分析：测试执行策略、测试监控策略、测试风险的定义，分析测试重点，一般来说性能测试都不会进行全面的测试，而是对测试重点进行测试

• 测试环境分析：测试中涉及到的服务器资源、测试软件、测试数据、测试桩定义，性能测试环境往往和生产环境不是 1:1 的，这些对测试结果的影响是需要分析确定的

• 测试场景构建：从性能负载、接口、疲劳角度定义测试场景

• 性能测试执行：按照预设的计划利用工具完成测试过程，注意系统资源的监控

• 测试数据分析：分析上述过程中产生的数据，得出结论

一般都是人数比，时间比确实没听说过，而且测试环节的时间不是只有测试设计和执行呀，从可行性和需求就开始介入了，是全流程的质量保障，leader 应该能意识到这一点才对。。。

好的，之后一定注意，看到这篇内容觉得 MS 适合这个场景，代码方式的话也推荐 pict 或者 allpairs，我们也有在用的。

为你的动手赞一个，这里有个现成的轮子 https://metersphere.io/
对于条件组合类型，可以考虑一下 pict 或者 allpairs，后者是个 python 库。
希望对你有帮助。

可以尝试一下 MeterSphere，能满足你的需求。 可以直接看这里的文档 https://metersphere.io/docs/user_manual/api_test/api_definition/