第一部分 - .
想像一個情況。 您面臨著開發新功能的任務。 你有前輩的經驗。 假設你沒有道德義務，你會怎麼做？
大多數情況下，所有舊的發展都被遺忘了，一切都重新開始。 沒有人喜歡研究別人的代碼，如果您有時間，何不開始創建自己的系統？ 這是一個典型的做法，在很多方面都是正確的。 但在我們的項目中，我們的行為有所不同。 我們將未來的自動化測試系統建立在我們前人在 utPLSQL 上單元測試的發展上，然後在幾個並行的方向上工作。
- 恢復舊的單元測試。 恢復意味著使測試適應忠誠度系統的現有狀態以及使測試適應 utPLSQL 標準。
- 通過理解解決問題，以及究竟是什麼，什麼方法和過程，我們已經涵蓋了自動測試。 您必須將這些信息牢記在心，或者直接根據自動測試代碼得出結論。 因此，我們決定創建一個目錄。 我們為每個自動測試分配了一個唯一的助記碼，創建了一個描述，並修復了設置（例如，應該在什麼條件下運行，或者如果測試運行失敗應該發生什麼）。 本質上，我們填寫了有關自動測試的元數據，並將此元數據放在 utPLSQL 模式的標準表中。
- 擴張策略的定義，即選擇需要通過自動測試驗證的功能。 我們決定關註三件事：系統的新改進、生產中的事件和系統的關鍵流程。 因此，我們與發布並行開發，確保其更高質量，同時擴大回歸範圍並確保系統在關鍵位置的可靠性。 第一個瓶頸是通過支票分配折扣和獎金的過程。
- 自然地，我們開始開發新的自動測試。 第一個發布任務之一是評估忠誠度系統預定義樣本的性能。 我們的項目有一組嚴格固定的 sql 查詢，根據條件選擇客戶端。 例如，獲取最後一次購買是在特定城市的所有客戶的列表，或者平均購買金額超過某個值的客戶的列表。 編寫自動測試後，我們檢查了預定義的樣本、固定的基準性能參數，此外我們還進行了負載測試。
- 使用自動測試應該很方便. 兩個最常見的操作是運行自動測試和生成測試數據。 這就是我們系統中出現兩個輔助模塊的方式：啟動模塊和數據生成模塊。
啟動器表示為一個具有一個輸入文本參數的通用過程。 作為參數，您可以傳遞自動測試助記符代碼、包名稱、測試名稱、自動測試設置或保留關鍵字。 該過程選擇並運行所有滿足條件的自動測試。
數據生成模塊以一個包的形式出現，其中為被測系統的每個對象（數據庫中的一個表）創建了一個特殊的過程，用於在其中插入數據。 在這個過程中，默認值被填充到最大值，這確保了在手指點擊時創建對象。 為了便於使用，為生成的數據創建了模板。 例如，創建具有測試電話和已完成購買的特定年齡的客戶。
- 自動測試應該在您的系統的合理時間內運行和運行。 因此，每天晚上都會組織一次啟動，根據結果生成一份結果報告，並通過公司郵件發送給整個開發團隊。 恢復舊自動測試並創建新自動測試後，總運行時間為 30 分鐘。 這樣的表演適合每個人，因為發射是在下班時間進行的。
但我們必須努力優化工作速度。 生產忠誠度系統在晚上更新。 作為其中一個版本的一部分，我們不得不在晚上緊急進行更改。 凌晨三點半小時等待自動測試結果並沒有讓負責發布的人高興（向 Alexei Vasyukov 致以熱烈的問候！），第二天早上對我們的系統說了很多熱情的話。 但也因此制定了 5 分鐘的工作標準。
為了加快性能，我們使用了兩種方法：我們開始在三個並行線程中運行自動測試，因為由於我們的忠誠度系統架構，這非常方便。 當自動測試不為自己創建測試數據時，我們放棄了這種方法，而是試圖在系統中找到合適的東西。 進行更改後，總運行時間減少到 3-4 分鐘。
- 具有自動測試的項目應該能夠部署在不同的展台上。 在旅程的開始，曾嘗試編寫我們自己的批處理文件，但很明顯，自行編寫的自動化安裝是一個徹頭徹尾的恐怖，我們轉向了工業解決方案。 由於該項目直接有很多代碼（首先，我們存儲了autotests的代碼）和數據很少（主要數據是關於autotests的元數據），結果很容易集成到Liquibase 項目。
它是一個開源數據庫獨立庫，用於跟踪、管理和應用數據庫模式更改。 通過命令行或 Apache Maven 等框架進行管理。 Liquibase 的操作原理非常簡單。 我們有一個以特定方式組織的項目，其中包含需要滾動到目標服務器上的更改或腳本，以及確定這些更改應以什麼順序和參數安裝的控製文件。
在 DBMS 級別，會創建一個特殊的表，Liquibase 會在其中存儲回滾日誌。 每個更改都有一個計算出的哈希值，每次都會在項目和數據庫中的狀態之間進行比較。 多虧了 Liquibase，我們可以輕鬆地將對我們系統的更改推廣到任何電路。 自動測試現在在測試和發布循環以及容器（開發人員的個人循環）上運行。
那麼，讓我們談談應用我們的單元測試系統的結果。
- 當然，首先，我們確信我們開始開發更好的軟件。 自動測試每天運行，每次發布都會發現數十個錯誤。 此外，其中一些錯誤僅與我們真正想要更改的功能間接相關。 強烈懷疑這些錯誤是人工測試發現的。
- 團隊對特定功能正常工作充滿信心……首先，這涉及到我們的關鍵流程。 例如，在過去的六個月中，儘管每次發布都進行了更改，但我們在通過支票分配折扣和獎金方面沒有遇到任何問題，儘管在以前的時期出現了一些錯誤
- 我們設法減少了測試迭代次數。 由於自動測試是為新功能編寫的，分析師和兼職測試人員可以獲得更高質量的代碼，因為已經驗證過了。
- 開發人員使用自動化測試的一部分開發。 例如，容器上的測試數據是使用對像生成模塊創建的。
- 重要的是我們開發了開發人員對自動化測試系統的“接受”。 有一種理解認為這是重要且有用的。 根據我自己的經驗，我可以說情況遠非如此。 需要編寫自動測試，需要維護和開發，需要分析結果，而這些時間成本往往根本不值得。 去生產和在那里處理問題要容易得多。 在我們國家，開發人員排隊要求用自動測試來覆蓋他們的功能。
下一步是什麼
下面說說自動化測試項目的發展規劃。
當然，只要 Sportmaster 忠誠度系統存在並繼續發展，自動測試也可以幾乎無休止地發展。 因此，主要的發展方向是覆蓋區域的擴大。
隨著自動測試數量的增加，他們工作的總時間將穩步增加，我們將不得不再次回到性能問題上。 最有可能的解決方案是增加並行線程的數量。
但這些都是顯而易見的發展方式。 如果我們談論一些更重要的事情，我們會強調以下內容：
- 現在，自動測試在 DBMS 級別進行管理，即PL/SQL 知識是成功工作所必需的。 如有必要，系統管理（例如，啟動或創建元數據）可以通過使用 Jenkins 或類似工具的某種管理面板來完成。
- 每個人都喜歡定量和定性指標。 對於自動測試，這樣一個通用的指標就是代碼覆蓋率或代碼覆蓋率指標。 使用此指標，我們可以確定被測系統的代碼有多少百分比被自動測試覆蓋。 從 12.2 版本開始，Oracle 提供了計算該指標的能力，並建議使用標準的 DBMS_PLSQL_CODE_COVERAGE 包。
我們的自動測試系統剛剛使用了一年多，可能是時候評估覆蓋率了。 在我的上一個項目（不是 Sportmaster 的項目）中，發生了這種情況。 在進行自動測試一年後，管理層設定了評估我們覆蓋的代碼百分比的任務。 如果覆蓋率超過 1%，管理層會很高興。 我們，開發人員，預計結果約為 10%。 我們搞砸了代碼覆蓋率，對其進行了測量，得到了 20%。 為了慶祝，我們去爭取了這個獎項，但我們如何去爭取它以及我們後來去了哪裡是完全不同的故事。
- 自動測試可以測試公開的 Web 服務。 Oracle 允許您這樣做，並且我們將不再遇到一些問題。
- 當然，我們的自動化測試系統也可以應用於其他項目。 我們收到的解決方案是通用的，只需要使用 Oracle。 我聽說有人對其他 Sportmaster 項目的自動化測試很感興趣，也許我們會去做。
發現
讓我們回顧一下。 在 Sportmaster 的忠誠度系統項目中，我們設法實現了一個自動化測試系統。 它的基礎是 Stephen Feuerstein 的 utPLSQL 解決方案。 utPLSQL 周圍是自動測試和輔助自寫模塊的代碼：啟動器、數據生成模塊等。 自動測試每天運行，最重要的是，它會工作並受益。 我們確信我們已經開始發布更高質量的軟件。 同時，由此產生的解決方案是通用的，可以自由地應用於任何需要在 Oracle DBMS 上組織自動化測試的項目。
PS 這篇文章並不是很具體：有很多文字，幾乎沒有技術示例。 如果這個主題在全球範圍內都很有趣，那麼我們準備好繼續它並返回一個延續，在那裡我們將告訴您過去六個月發生了什麼變化並提供代碼示例。
如果以後有需要強調的地方，或者需要公開的問題，寫評論。
只有註冊用戶才能參與調查。 ， 請。
我們要寫更多嗎？
-
哦沒問題
-
不，謝謝
12 位用戶投票。 4 名用戶棄權。
來源： www.habr.com