Sweet 与其他自动化测试框架最大的不同是什么？
答：Sweet 是让业务测试人员自己写自动化测试用例
其他自动化测试框架是谁写测试用例呢？
答：大部分都是专门的自动化测试人员写用例脚本
为什么他们不让业务测试人员写呢？
答：用例脚本也是代码，有一定的门槛，而大部分业务测试不会代码
那 Sweet 的业务测试就会代码了吗？
答：不是，Sweet 的测试用例不是用例脚本，而是在表格中用文本编写的
所以写 Sweet 的测试用例不需要会代码？
答：是的，Sweet 的测试用例和功能测试用例类似，业务测试可以轻松上手
业务人员写自动化用例有什么优劣吗？
答：业务人员自己写自动化测试用例，减少了沟通成本，没有中间商赚差价
脚本用例就没有优势吗？
答：业界有句话：是代码就有 bug，脚本用例也是代码，且人员代码能力更低，也就更加不可靠
Sweet 本身不也是代码写的吗？
答：Sweet 是按照产品级软件打造的，核心代码不足千行，经过4年的不断优化和改进，稳定性已经千锤百炼
如果使用 Sweet，是不是可以不需要自动化测试人员了？
答：Sweet 的测试用例是业务测试人员编写，但是还是需要一个 Sweet 教练
听起来，人员并没有减少？
答：假如要支持20个业务测试，Sweet 可以只要1个教练，而其他框架可能需要5个自动化测试人员
开发需求经常变更，自动化测试维护成本很大， Sweet 有解决办法吗？
答：Sweet 采用了定位、用例、测试数据分层设计，以及变量替换等方法，维护的工作量是最小的
都说自动化测试只能覆盖核心功能，特别是 UI 测试，Sweet 也是这样吗？
答：那是因为他们的用例设计和维护成本太高，Sweet 建议覆盖 80% 的业务用例
业务测试每天都忙于点点点，哪有这么多时间编写自动化用例？
答：这需要一点气魄，先在试点项目达到自动化 80% 覆盖，再看看他们还要不要这么忙
新的业务很多呀，自动化测试也帮不上忙？
答：非也，首先新业务上可以做接口测试，如果 API 文档写的规范，甚至可以提前写好接口用例；其次，手工测试可以只做一遍，之后就是自动化用例边测边写
按这个方法，测试周期是长了还是短了？
答：如果严格按照这个模式来，测试周期一定是短的，我希望测试人员一边喝茶，一般看 Sweet 打印日志
所有的项目都适用这个模式吗？
答：也不是，大部分开发模式，无论是瀑布模型还是 V 字模型，抑或是敏捷开发，都可以适用；但是如果是那种质量要求不高，开发极为迅速，测试周期按小时计算的小需求，则无法适用。
Sweet 还有其他优势吗？
答：Sweet 的 Web 测试报告，基于 Markdown 文件，无需安装数据库，既简单又漂亮
Sweet 可以集成到 DevOps 吗？
答：当然，Sweet 既可以命令行方式启动，也可以接口调用，很容易集成到 DevOps 系统
如果有些功能 Sweet 不支持咋办？
答：Sweet 可以满足 99% 的测试需求，同时也支持自定义函数和关键字模块二次开发
那么，最后请用一句话送给广大自动化测试的同学吧？
答：Sweet 本来就在你心里，只不过偶然被我敲了出来
微信公众号：
