敏捷開發(fā)的小秘密

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

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

一定有更好的方法！

關(guān)注風(fēng)險

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

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

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

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

通過、失敗或不完整的狀態(tài)表示這些

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

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

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

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

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

如何應(yīng)用CBT工作流程

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

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

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

結(jié)論

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