全文共2399字，預計學習時長6分鐘
圖源：unsplash
本文首先將討論sprint測試和開發中的一些長期障礙，然後尋找一個可行的辦法，以在短時間內交付經過嚴格測試的系統。
這種方法的兩大因素是資料和自動化，它們協同工作，將有關需要測試的見解轉化為嚴格的自動化測試。但首先，讓我們來思考一下為什麼在sprint中設計、開發和測試仍然如此具有挑戰性。
20 年後，獨立組織仍然是軟體交付方面的挑戰。
儘管敏捷宣言已釋出20年，軟體交付生命週期仍然充滿了獨立組織。這些獨立組織不僅造成耗時的錯誤溝通，還擴大了人工的工作量。每次資訊從一個移動組織轉移到另一個移動組織時，都需要將其從一種格式轉換為另一種格式：
這些“資訊躍點”延遲釋出並引入缺陷，因為誤解在每個階段都出現。現在，讓我們更詳細地檢視每個獨立組織。
設計
從測試和開發的角度來看，在基於文字的文件和不同的圖表中收集需求根本不適合使用。零碎的書面使用者情景和文件與需要開發的確切邏輯很不一。同時，基於文字的格式和靜態關係圖之間通常很少或沒有正式的依賴關係對映。
發展
因此，軟體設計在轉換為原始碼時會引入錯誤，進而產生耗時的返工。事實上，多項研究估計，需求造成了一半以上的缺陷，而進一步的研究估計，開發人員花了一半的時間修復錯誤。因此，設計缺陷佔用了開發新功能的大量時間。
測試
需求的靜態特性進一步增加了測試中的人工工作量。“平面”文件和圖表還沒有為自動化做好準備，測試人員常常被迫手動將設計轉換為測試用例、資料和指令碼。
除了浪費時間，這些手動流程還會降低質量。如今，一個簡單的系統可能需要數千次測試才能釋出。面對非正式和不完整的要求，測試人員無法系統或自動識別和建立在釋出前需要執行的測試。
相反，手動測試設計幾乎完全側重於“快樂路徑”方案，過度測試這些方案，而犧牲了最有可能導致Bug 的方案。同時，過期和無效的測試堆積起來，導致測試失敗，使測試進一步落後於版本。
自動化可以提供幫助——但只有當它擴充套件到測試執行之外時。
圖源：unsplash
當然，自動化可以加速許多手動流程。然而，到目前為止，“測試自動化”幾乎完全集中在一個任務上，即執行測試。在這樣做的過程中，它引入了大量手動流程，而忽略了關鍵的質量問題。
在許多情況下，測試自動化引入了一個新的獨立組織，以及與之相關的所有時間和精力。測試自動化引入的手動過程包括大量測試指令碼以及大量指令碼維護。同時，測試執行的速度和數量會增加資料供應瓶頸，而過時或不一致的資料會導致耗時的測試失敗。
進一步自動化測試執行對提高測試質量沒有任何幫助，也無助於識別要執行的測試。測試設計人員和自動化工程師仍然面臨著擁有比在sprint中執行更多的系統邏輯的挑戰。
對錯誤測試進行優先順序排序不僅會浪費測試指令碼中的額外時間，還會使關鍵系統面臨破壞性的生產缺陷。因此，測試執行自動化是sprint測試的關鍵元件，但它本身並不是解決方案。
“資料驅動”測試，但不是你所知道的那樣。
幸運的是，一個解決方案正在出現。它在於資料，以及可以將自動化應用於當今廣泛可用的資料的方法。這為在sprint中準確自動地劃分測試優先順序打開了大門，在下一個版本之前生成所需的測試。
DevOps工具鏈中（自動）技術的激增導致了相關的資料激增。此外，這些資料現在以可捕獲和分析的格式輸出。
如果將這些資料與自動分析和測試生成相結合，就可以開始將最新的測試人工專案填充到收集資料的相同工具中。然後建立一個閉合反饋迴圈，收集和分析更多資料，以推動sprint中的嚴格測試。
現在來看看這個“資料驅動”的sprint測試方法的元件。
連線
此方法的第一個先決條件是跨應用程式交付生命週期的技術之間的連線。如果不同的工具不能在彼此之間傳遞資訊，則獨立組織將持續存在。這將沒有足夠的資料進行分析，也不可能跨工具填充測試套件。
因此，技術之間的連通性至關重要，在sprint中，技術必須建立在開放技術之上。幸運的是，機器人流程自動化和DevOps編排工具可以幫助快速整合不同的技術。
基線資料
此外，還必須收集這些不同工具產生的資料，為收集資料提供基線。然後可以應用工具從這個單一的真相來源中獲取見解，告知測試人員sprint中需要測試的內容。分析工具包括但不限於基於AI和ML的技術。
sprint測試和資料生成
此時，已經收集和分析了資料，指出了sprint中需要測試的內容。但是，如何構建和執行對這些資訊進行操作所需的測試呢？
第一部分是自動化測試生成，將此生成與基線資料分析聯絡起來。第二部分在於根據已生成的測試自動生成和分配資料。這可以透過在測試執行時查詢和生成資料的工具實現，為每次測試提供豐富且相容的資料。
圖源：unsplash
開放測試平臺
如果你擁有所有這些元件，那麼就有了所謂的開放測試平臺。一個開放的測試平臺可以管理整個應用程式開發生態系統的資料，準確地確定在sprint中需要測試的內容。它還構建了執行這些測試所需的測試和資料，使用資料驅動的洞察來實現sprint測試自動化。
開放式測試平臺不是從系統需求和一系列獨立組織出發，而是分析整個開發生態系統中的資料。因此，它會隨著需求或環境的變化來通知和更新測試，而不是玩一個不斷的追趕遊戲。
簡而言之，開放測試平臺支援sprint測試自動化。
留言點贊關注
我們一起分享AI學習與發展的乾貨
如轉載，請後臺留言，遵守轉載規範
