自動化測試平台化[v1.0.0][自動化測試基本需求]

随着軟體發展到不同的階段對自動化會有不同的測試需求，是以也産生了多種測試類型，然而萬變不離其宗，一切皆可自動化

單元測試

單元測試也可以看做是代碼層的測試，而但凡成熟的語言都附有單元測試架構，例如Java的Junit和TestNG，例如Python的Unittest和Pytest，在很多場合我都曾強調，單元測試才是自動化的核心，從某種意義上講具備單元測試架構的語言就都能進行單元測試的自動化執行，而這最小單元可以是一個函數、一個方法、一個類或是一個子產品

然而很多公司的研發團隊雖然要求單元測試，但很少要求傳遞單元測試報告的，也有很多公司的單元測試是有自動化測試團隊承擔的，雖然測試無法窮盡，但測試不同的輸入、邊界值、非法值、預設值、異常情況等等是基本要求，而這些内容讓研發團隊自行去做，若非嚴格的制度限制，又如何能保證高速疊代的環境裡真的能達到單元測試目的呢，研發人員的興趣點絕大多數都在創造力上，他們更喜歡開發新東西，而對品質興趣不大

功能測試

通常情況下，功能測試是測試團隊介入的第一個階段，開發人員将完成的功能特性寫成文檔輸出給測試團隊，測試團隊根據這些文檔開發設計測試用例，最後執行測試用例，對功能進行驗證，理想情況下，如果功能特性文的規範寫的足夠清晰，測試團隊應該在功能開發完成之前就開發完測試用例，甚至可以根據這些用例來編寫自動化測試用例

然而盡管大多數情況下，都希望根據品質體系的規範輸出詳盡的文檔，但實操起來确是各種問題：

• 功能文檔不規範，協作之間了解不一緻，出現偏差，導緻設計的用例變成了無效用例
• 需求變更，導緻功能特性更新，直接影響原先的測試用例設計
• 新功能不穩定，導緻測試用例無法順利執行

以第三點新功能不穩定為例，過早的執行自動化測試會被不穩定的新功能阻礙住，一個嚴重的問題可能導緻很多用例無法執行或執行失敗，最終仍然需要人來幹預執行結果的，認為進行判斷甚至重複勞動，這就使得自動化不那麼自動了，也就是說需要人值守，遇到問題後手動介入解決

測試開發也是軟體開發的一個類型，其本身的品質不能和被測系統的品質糾纏到一起，否則會讓問題的排查更為複雜

是以，如果非牛逼的研發團隊，自動化測試用來輔助測試提升測試效率的角度出發更為實際，将其用于單元測試自動化，接口測試自動化，輔助自動化工具類将成為相當可行的選擇，當功能相對穩定後，在全面的實作自動化測試。

再不然，對于功能測試而言非要強行引入自動化測試，那麼測試用例本身的建構和修改一定要非常迅速，自動化測試架構需要提供快速建構用例的能力，以此來響應需求的變更，測試代碼的健壯性和靈活性要求非常高，進而應對不穩定的功能産生的阻塞，并且還要對災難性的錯誤進行測試環境上的自動恢複

回歸測試

回歸測試時軟體開發疊代階段的一種測試，主要是保障原有的功能沒有因為新功能的引入而導緻功能回退，在這個階段自動化測試将得到大量的應用，相對于新功能的不穩定，回歸測試的目标是已經釋出的或者穩定的功能，相應的測試代碼也相對比較穩定，自動化代碼也已經經過多輪的完善，執行結果相對也會穩定的多

可用性測試及冒煙測試

系統測試

• 相對于功能測試比較固定的測試環境，系統測試環境比較複雜，配置繁多，不固定，不穩定，在這種情況下，自動化測試需要足夠靈活的應對不同的環境配置來執行相同的測試目的
• 測試用例的相容性要足夠強，穩定性足夠強，且被測系統的穩定性足夠強
• 壓力測試和性能測試的需求，自動化測試應能夠快速的內建相應的标準性能測試裝置或工具
• 客戶場景模拟測試，即便再聰明的測試工程師能夠設計出種類繁多的測試方案，總有想象不到的場景，客戶才是麻煩的最佳制造者，是以很多企業會花一些經曆收集客戶場景，并加入到系統測試的模拟場景中