說起自動化測試，在這個軟件吞噬世界的時代裏，早不是什麼高端技術了。從基本的單元測試，到複雜的系統測試，幾乎都可以使用自動化測試來代替原本的手動測試。
隨着軟件規模的增大，軟件的速度開始提升，特性也越來越豐富，測試的要求就逐漸變得高了起來。曾經那些不能夠自動化的測試場景，如今也可以利用各種軟硬件技術來實現自動化，就像是爲了打敗更強大的對手，越來越多的武功祕籍被開發了出來。
但就算最終練成了絕世高手，當我們面對的事一支軍隊的時候，那註定會毫無招架之力……
同樣，即便我們有再強大的自動化測試技術來測試某個產品特性（比如JMeter的性能測試，Selenium的Web圖形測試，RobotFramework的關鍵字驅動等等），想要測試好一個完整的產品，僅僅使用單一的一個框架是無法勝任的！
怎麼辦
雖然自動化測試技術已經發展到人工智能的階段，但是很多企業和團隊由於成本或者其他因素，依舊在自動化測試工具、平臺的選擇和開發上苦苦摸索和前進。
我們需要一個測試平臺去統一集成這些框架，在這些框架的基礎上發展出適合自己業務的平臺，就好比帶領武林高手去打仗，通過排兵佈陣贏得勝利！
兵者，國之大事，死生之地，存亡之道，不可不查也。
既然如此，我們不妨先來接受下幾個靈魂拷問——
問題1：你的自動化測試用例足夠靈活嗎？對於一個功能測試，這個測試用例是否能適應不同的測試環境？
問 題 背 景
很多團隊開發的測試腳本業務和技術代碼耦合得非常緊密，甚至對測試場景也有嚴格規定，所以往往不能夠自動匹配不同的測試環境，甚至在環境做了一些修改之後，測試用例也需要相應進行修改。
問題2：你的測試用例擴展性足夠強大嗎？如果有新的測試技術和工具引入，能夠快速擴展測試用例來支持新的技術和工具？
問 題 背 景
如果對於一個功能的測試，有了更可靠有效的測試工具支持，往往需要修改現有測試用例，或者修改現有的工具庫來對新工具進行支持，在不修改或者少量修改測試用例的情況下很難完成擴展。
問題3：你的自動化測試報告是不是適合團隊不同的使用者分析使用？你能否在測試報告中快速找到測試Failed的原因？
問 題 背 景
目前有大量的實踐還是將測試結果以log日誌的形式進行輸出，沒有很好地將測試結果分類和結構化，所以導致測試執行者在分析測試結果的時候需要花大量的實踐去定位問題。
問題4：你能否根據不同的測試需求，來靈活組織和配置現有的測試用例？
問 題 背 景
一般在軟件測試中，測試會分爲不同的階段，不同階段的測試用例要求也不同。所以一些團隊往往會去重複開發測試用例來滿足不同階段的需求，這個問題還涉及到自動化測試用例管理，如何高效管理現有的測試用例也是一個需要解決的問題。
問題5：如果你所在公司的其他團隊也需要類似的測試平臺，你是否能快速讓他們部署你的測試平臺？
問 題 背 景
如果把測試平臺作爲一個產品來看待，部署和安裝是用戶對該產品的第一次接觸，如果一個產品的部署和安裝非常複雜，那麼會大大減少用戶使用該產品的興趣。但是往往很多測試團隊不注重這一點，整個自動化測試項目以源代碼形式託管在代碼倉庫中，沒有規範化的部署文檔，一個新手很難獨自將整個測試平臺執行起來。