jmeter属性

通常我们会使用用户自定义变量，把每个用例共用的东西提取出来。然而，当测试环境多起来时，这些写死在jmx脚本里的变量就不那么好用了。例如，对多个环境测试时，难道要复制多个脚本、单独改变量值？

此时，我们可以使用jmeter属性。因为属性是可以通过命令行传递的，例如：

1

-Jtestproperty=202

自动化测试对于小团队来说非常重要，特别是技术负责人更偏向于用技术解决问题时（习惯用管理解决问题时，可能会用手动+人海方式）。
而在接口测试中，jmeter无疑是一个低成本方案的自动化测试工具。

为什么呢？因为它在整体设计上把业务逻辑、测试框架、测试数据三者分离了。jmeter进程就是测试框架，而通过如csv等文件提供测试数据，jmx提供包含业务逻辑的测试用例。而jmx脚本，则是以可视化的配置方式来编写（且配置时，可以利用内置函数提供多种功能）。这样的方案，无疑是维护成本最低的。

第三章示例源代码

chapter3

第四章示例源代码

chapter4

第五章示例源代码

chapter5

第六章示例源代码

chapter6

搭建cms内容站点时，wordpress是一个很好的选择，不用做任何开发就可以通过配置、插件获得丰富的功能。用Docker容器技术部署运维都非常简单，特别是对于wordpress这种我们无需做任何开发的组件。而出于低成本考虑，公有云都是一个最佳选择，这里我选择阿里云。为了提速，wordpress前会有一个nginx作为负载均衡和web加速服务器，将静态内容都由nginx处理。出于高可靠性，我选用阿里云的容器服务（目前免费），由它来管理所有容器。而多容器间的磁盘目录共享，阿里云提供了oss映射和nas盘，oss盘的速度太慢，而nas盘IO与云盘相当，可以作为第一选择。数据库为了可靠性，如果没有独立的DB运维人员，就选择rds MySQL好了（目前单机版RDS刚上线，相比双机mysql便宜很多）。

django是Python语言快速实现web服务的大杀器，其开发效率可以非常的高！但因为秉承了语言的灵活性，django框架又太灵活，以至于想实现任何功能都有种“条条大路通罗马”的感觉。这么多种选择放在一起，如何分出高下？我想此时的场景下就两个标准： 1、相同的功能用最少的代码实现（代码少BUG也会少）； 2、相对最易于理解，从而易于维护和扩展。