敏捷開發的小秘密

當目標確實是更準確地交付市場時，敏捷通常會誤售給高級管理人員，這是實現更快上市時間的一種方法。我們沒有告訴任何人的小秘密是，這實際上是有代價的……上市時間變慢了！是的，我們發布的頻率更高（即“更快”），但最終要花更長的時間才能將完整的功能推向市場。當我們將問題分解成更小的部分時，為什么要花更長的時間呢？好吧，到目前為止，最大的罪魁禍首是后期缺陷檢測和降低風險的措施所帶來的瓶頸。

增量代碼更改（尤其是它們對測試和整體系統穩定性的影響）使敏捷開發的許許多多速度降低了。由于質量檢查/測試著重于驗證所實現的新功能，每個沖刺通常以一個短劃線結尾。然后，由于缺乏對代碼更改所產生的間接影響的了解，因此組織需要在發布時進行完全回歸。這通常會在周期后期發現許多問題，從而導致工作時間過長和難以做出業務決策。

一定有更好的方法！

關注風險

由于當今代碼庫的復雜性，每一個代碼更改（無論多么無害）都會微妙地影響應用程序的穩定性，并最終“破壞系統”。這些意想不到的后果是無法通過人工檢查發現的，因此測試對于降低它們所代表的風險至關重要，但是除非您了解需要重新考慮的內容，否則您將無法實現有效的測試實踐。如果每個沖刺測試過多，那么您將失去敏捷開發帶來的許多收益。如果測試太少，則會使自己處于后期檢測周期。

需要一種方法來確定需要重新執行哪些測試，并將測試工作（單元測試，自動功能測試和手動測試）集中在驗證受最新更改影響的功能和相關代碼上。通過結合使用Parasoft的代碼分析引擎（Jtest，C/C++test，dotTEST）和Parasoft DTP中的流程智能引擎（PIE），開發人員和測試人員可以了解兩次構建之間的代碼庫變化，并深入了解敏捷的承諾。這稱為基于變更的測試。

基于變更的測試（CBT）使Sprint持續進行

關鍵是要知道可以使用哪些測試來驗證代碼更改，這是Parasoft的相關覆蓋范圍交付產品的地方。通過了解這些文件中的哪些已更改以及哪些特定測試接觸了這些文件，DTP的分析引擎（PIE）可以分析兩次構建之間的差異，并確定需要重新執行的測試子集。下圖顯示了DTP儀表板中的小部件，該小部件顯示了CBT分析結果的餅圖。此圖表顯示了可用于驗證代碼更改的測試子集，按測試狀態分類：通過、失敗、不完整和需要重新測試。

通過、失敗或不完整的狀態表示這些

 此高級視圖表明，已修改的代碼引入了許多故障，并且尚未執行但可以用來進一步驗證更改的許多測試。

通過、失敗或不完整的狀態表示這些測試已經針對構建執行，作為全自動測試過程的一部分（例如，CI驅動的構建步驟），或者在測試新功能時進行。但是，狀態為“重新測試”的測試是尚未執行的手動測試，或者是自動化運行的一部分，這些測試未計劃在當前sprint期間執行。

深入研究圖表，我們可以快速了解代碼中發生了哪些更改，現有測試如何與這些更改相關以及需要集中測試資源的地方。

從這里，我們可以創建一個測試計劃，以最高的優先級處理失敗和不完整的測試用例，并使用重新測試建議來重點安排其他自動運行的計劃并確定手動測試工作的優先級。

DTP中的Violation Explorer提供了用于定義和管理測試計劃的界面。瀏覽測試和結果，資源管理器顯示每個測試用例的詳細信息。使用優先級視圖來設置測試元數據，用戶可以為每個測試用例分配所有者，操作并設置優先級。

如何應用CBT工作流程

那么，這如何有助于敏捷過程？簡而言之，這是一種快速簡潔地確定需要在何處應用測試資源的能力。通過僅測試需要的內容而不是所有內容（或只是猜測），測試時間大大減少了。質量提高，沖刺按時完成。

在實踐中這將如何工作？盡管基于變更的測試（CBT）分析的結果可以以幾種不同的方式使用，但我建議以下工作流程是最有效的方法，以專注于基于sprint的測試工作：

• 確定您的基線。這是您要用于重點重新測試的已完成測試工作的內部版本。通常，這是從先前的sprint或發行版的末尾開始的構建。
• 執行單元測試和可用的自動化功能測試。將自動化測試集成到您的CI流程中，并根據最新版本衡量/監控CBT結果。這使您能夠查看自己的工作方式并計劃重新測試的工作。
• 縮小重新測試差距。根據目標構建進行測試，并將重新測試工作的結果提交回去進行分析；并重新審查CBT的結果。
• 重置基線。在sprint結束時，將基線移至您已完成測試的內部版本，并為下一個sprint重置/重復。

結論

我們需要在敏捷開發中提高測試效率。測試是持續交付的主要瓶頸，由于錯誤的測試，在發布周期結束時發現了太多缺陷。為了獲得最佳結果，請將測試工作重點放在您所做更改的影響上，并釋放敏捷性以加快向市場的交付速度。