Sweet 的問與答

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 本來就在你心裡，隻不過偶然被我敲了出來