写在“喜文测试”官网启动之时

前言

以前，测试行业的普遍看法是：

自动化测试的成本较高，接口测试还可以开展一下，UI 自动化测试的性价比很低，完全没有必要。

这句话是对的，但也是错的。

就比如，小程序发布之初，大部分人都说不看好，而后小程序经过短暂的热闹，也就真的迅速的沉寂了将近一年之久。

但是，一年之后，当潜心打磨的新特性持续发布，终于让小程序爆发起来，各大友商也纷纷效仿。

那么，现在你说孰对孰错。其实这世上本就没有对错，只有对的人，在对的时候，做对的事。

我们回到UI 自动化测试这个话题，为什么不可以做呢？UI 自动化测试的难点肯定有，但不是无法解决的，所以我才做了 Sweetest。不是为了反驳谁，只是想让测试这个行业在正确的道路上前进。

Sweetest 的设计原则

通用

Sweetest 从开发的第一天起，就本着通用性框架的原则来设计的，无论是起初的公司内部需求，还是后来开源社区的需求，都坚持在通用的原则下开发。

简单

Sweetest 足够简单，只要你会用 Excel 写功能用例，你就可以学会用 Sweetest 写自动化测试用例，无需代码能力。

灵活

Sweetest 是当一个产品来做打磨的，一切以用例设计为中心，为了简单灵活，做了非常多的开创性符号设计，比如条件语句：if(^) then(>) else(>) for 循环等，变量定位法(#)，双逗号(,,)分隔等。

Sweetest 的现在

一点小成绩

Sweetest 是今年5月底在 TesterHome) 做了开源，发布后，点赞数迅速上升至第一，到现在差不多半年时间，点赞数已经是第二名的差不多2倍之多。

自动化测试当然不只是 Web UI 自动化，得益于 Sweetest 的分层设计思想，在后面我逐步加入了 DB 操作，Http 接口测试，Android 测试，小程序测试等功能。

这些都大大扩展了 Sweetest 的使用场景，特别是 Http 接口测试，我独创性的设计了 inJSON 比较方法，大大简化了 JSON 比较和变量获取。inJSON 本身也是一个 Python 开源库，甚至可以集成到其他接口框架内使用。

更多开源项目

如上面所说，除了 Sweetest，半年来我还开源了一些项目，如下：

inJSON：测试一个 JSON 是否在另一个 JSON 中

Doo：接口文档及 Mock 服务

Look：验证码识别库

官方网站启用

毫无疑问，Sweetest 是主打项目，但是为了减少困扰，我决定做一次项目归集，把名下自动化测试相关的项目统一到一个标识下面，建一个官网统一展示使用文档。

既然是网站，那就要有一个域名，经过一番折腾，我最终选择了 sweeter.io ，即保留了 Sweetest 的特色，又有所区别。

中文名称：喜文测试

同时，公众号和 QQ 群也同步更名为：喜文测试

喜文测试的未来

有很多人说不敢用个人维护的开源项目，特别是还未发布1.0版本的。

正如本文开头所说，这句话对也不对。你看 Vue.js 也是个人项目，不也很多人在使用。

在此我承诺：喜文测试名下的项目将永久开源。

特别是 Sweetest ，目前在 Web UI，Http 接口，DB 操作等方便，已经有多个内部和外部项目在实际使用，其中会有很多新的需求，也会发现 bug，这些都已经解决，可以说你最大的或者不知道的，想要的或者不知道自己想要的，我们都踩过了好多遍，系统已经非常稳定成熟，将很快迎来1.0版本的发布。

感谢

最后，感谢喜欢和使用喜文测试的同行，是你们让这些项目有动力继续前进，也感谢更多的开源贡献者，喜文测试也是建立在你们的肩膀之上。

了解喜文测试，请访问：https://sweeter.io

公众号：喜文测试