質量保證測試的後門API - 好還是壞？

Question

爲了QA測試的好壞，有API嗎？

我們正在從頭開發一個應用程序，我們一直在創建後門API以簡化QA的工作。這些後門處理很多事情，比如更改服務器的日期以模擬時間進程等。我對此非常不滿。這些後門的數量幾乎可以與生產中使用的真正的API相媲美。

這是推薦的方法嗎？顯而易見的好處是，它使質量保證的生活變得更加簡單。我可以看到許多缺點，例如維護這些測試API的功能，確保這些後門API不會在生產環境中暴露。

如果其他人使用了這種方法，有什麼方法可以確保這些API在生產環境中不被暴露？

對於那些反對這種方法的人來說，是否有替代方案可以使QA的工作更容易？

感謝

Answer 1

如果它不造成QA錯過的問題，這是做了一件好事;如果你可以在未來沒有成本的情況下讓自己的工作更輕鬆，那就去做吧。

但是，通常情況下，只要您測試一個API，但使用時使用另一個API，則實際上並未測試正在投入生產的真實API。如果QA對正常的API有破解，他們也應該測試黑客和真實世界之間的差異。

在這種情況下，聽起來像他們有助手方法來修改狀態，以啓用測試。如果沒有好的方法來做到這一點，否則他們正在做的事情可能相當合理......或者，至少，可能有更好的方法來花時間改善事情。

但總體而言;它是否定期（重複）導致它們錯過應該捕獲的錯誤？

Answer 2

你正在使用什麼構建系統？

對於具有任何時間/調度邏輯的任何軟件，我認爲這是非常重要的，以添加一個名爲SystemClock類與調用方法「（）currentTime的。」

在我們的Android項目中，我們從Gradle變量中注入開始時間，然後我們可以確定代碼無法通過移動時間進入生產（因爲該變量僅針對調試版本定義）。

對於我們的iOS版本，我們能夠使用擴展。這是一個很好的方法，因爲它只被編譯到測試範圍中。然後它將getCurrentTime方法替換爲移位的方法。

你在Java世界中有另一種選擇是各個方面。他們可以很方便地在測試版本中進行混入，而這些混入在生產中不存在。