罗列了想到的6条学习笔记。

最近前端团队越发觉得目前API接口有些不好用，所以我也借此重新理一下我们的API接口。

API没有什么完美的设计理念和原则，只有最适合当下的设计。这个最适合包括：当前使用的技术架构、团队规模、团队成员技术特点、开发时间、人力成本、未来业务与技术的预期等。我先来回顾下我们产品的API变迁过程。

jmeter属性

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

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

1

-Jtestproperty=202

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

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

当我们需要与一些安全级别要求很高的服务对接时，服务提供商的网络提供方式可能是使用ipsec点对点对接网络。如果我们不是使用公有云，而是有自己的机房和路由器，这些就只是按照服务方的参数要求配置下路由器的小事情。但对公有云来说（例如阿里云），我们没有自己的路由器，当对接方要求我们使用预共享密匙进行ipsec点对点对接，第一反应什么鬼（之前没接触过的朋友可以看下这篇文章http://www.ibm.com/developerworks/cn/[Linux](http://lib.csdn.net/base/linux “Linux知识库”)/l-ipsec/，对该概念讲得蛮清楚）？而接下来拥有私有云独立机房的服务提供方则可能要求最简单直接的解决方案：拉条专线接入服务提供者机房（这个开发成本和运维成本都不小，不适合小而美型的敏捷项目！）？或者买个路由器，在办公室找台机器与服务方对接（高可靠性完全无法保障了）？ 本文讲述使用openswan在linux centos 7下进行ipsec vpn网络的对接，由于相对小众中文资料不多，故也是一篇实践总结笔记。