嘿哈布爾！
我叫 Maxim Ponomarenko，是 Sportmaster 的開發人員。 我在 IT 領域有 10 年的經驗。 他的職業生涯始於手動測試，然後轉向資料庫開發。 在過去的 4 年裡，我累積了在測試和開發中獲得的知識，並一直在 DBMS 層級進行自動化測試。
我在 Sportmaster 團隊工作了一年多，正在為一個主要專案開發自動化測試。 四月份，我和 Sportmaster Lab 的人員在克拉斯諾達爾的一次會議上發表了演講，我的報告被稱為“DBMS 中的單元測試”，現在我想與您分享。 文字會很多，所以我決定將報告分成兩篇文章。 在第一篇中，我們將討論一般的自動測試和測試，在第二篇中，我將更詳細地討論我們的單元測試系統及其應用結果。
首先，有點無聊的理論。 什麼是自動化測試？ 這是使用軟體進行的測試，在現代 IT 中，它越來越多地用於軟體開發。 這是因為公司不斷發展，其資訊系統也在不斷發展，因此需要測試的功能量也不斷增加。 進行手動測試變得越來越昂貴。
我在一家大公司工作，該公司每兩個月發布一次版本。 同時，花了整整一個月的時間讓十幾名測試人員手動檢查功能。 由於一小群開發人員實施了自動化，我們能夠在一年半的時間內將測試時間減少到兩週。 我們不僅提高了測試速度，還提高了測試品質。 自動化測試會定期啟動，並且始終執行其中包含的整個檢查過程，也就是說，我們排除了人為因素。
現代 IT 的特點是，開發人員可能不僅需要編寫產品程式碼，還需要編寫檢查該程式碼的單元測試。
但是如果您的系統主要基於伺服器邏輯怎麼辦？ 市場上沒有通用的解決方案或最佳實踐。 通常，公司會透過創建自己編寫的測試系統來解決這個問題。 這是我們自己寫的自動化測試系統，是在我們的專案上創建的，我將在我的報告中討論它。
測試忠誠度
首先說一下我們部署自動化測試系統的專案。 我們的專案是 Sportmaster 忠誠度系統（順便說一句，我們已經在 ).
如果您的公司夠大，那麼您的忠誠度系統將具有三個標準屬性：
- 您的系統將處於高負載狀態
- 您的系統將包含複雜的計算過程
- 您的系統將得到積極改進。
讓我們按順序進行... 總的來說，如果我們考慮所有 Sportmaster 品牌，那麼我們在俄羅斯、烏克蘭、中國、哈薩克和白俄羅斯擁有 1000 多家商店。 這些商店每天約有 300 萬次購買。 也就是說，每秒有 000-3 張支票進入我們的系統。 當然，我們的忠誠度系統負荷很高。 由於它被積極使用，我們必須提供最高的品質標準，因為軟體中的任何錯誤都意味著巨大的金錢、聲譽和其他損失。
同時，Sportmaster 也舉辦一百多項不同的促銷活動。 促銷有很多種：有產品促銷，有專門針對一週中某一天的促銷，有與特定商店相關的促銷，有針對收據金額的促銷，還有針對商品數量的促銷。 總的來說，還不錯。 客戶在購買時可以使用獎金和促銷代碼。 所有這些都導致計算任何階數都是一項非常重要的任務。
實現訂單處理的演算法確實很糟糕而且很複雜。 而且這個演算法的任何改變都是相當危險的。 似乎最看似微不足道的變化可能會導致相當不可預測的影響。 但正是如此複雜的計算過程，尤其是那些實現關鍵功能的計算過程，才是自動化的最佳候選者。 手動檢查數十個類似案例非常耗時。 由於流程的入口點沒有改變，只描述過一次，您就可以快速建立自動測試，並確信該功能將發揮作用。
由於我們的系統被積極使用，企業會希望從您那裡得到一些新的東西，與時俱進並以客戶為導向。 在我們的忠誠度系統中，每兩個月發布一次。 這意味著每兩個月我們需要對整個系統進行一次徹底的回歸。 同時，自然地，就像在任何現代 IT 中一樣，開發不會立即從開發人員轉向生產。 它起源於開發人員的電路，然後依序經過測試台、發布、驗收，最後才最終投入生產。 至少，在測試和發布電路上，我們需要對整個系統進行完整的回歸。
所描述的屬性是幾乎所有忠誠度系統的標準屬性。 我們來談談我們專案的特點。
從技術上來說，我們的忠誠度系統 90% 的邏輯都是基於伺服器並在 Oracle 上實現的。 Delphi 中公開了一個客戶端，它執行自動化工作場所管理員的功能。 有針對外部應用程式（例如網站）的公開 Web 服務。 因此，如果我們部署自動化測試系統，我們會在Oracle上進行，這是非常合乎邏輯的。
Sportmaster 中的忠誠度系統已經存在了 7 年多，並且是由單一開發人員創建的...這 7 年裡我們專案的開發人員平均數量為 3-4 人。 但在過去的一年裡，我們的團隊有了顯著的成長，現在有 10 個人在做這個專案。 也就是說，參與專案的人們並不熟悉典型的任務、流程和架構。 而且我們錯過錯誤的風險也會增加。
該項目的特點是沒有專門的測試人員作為參謀單位。 當然，還有測試，但測試是由分析師執行的，此外還有他們的其他主要職責：與業務客戶、使用者溝通、開發系統需求等。 等等...儘管測試的品質非常高（這一點特別值得一提，因為一些分析師可能會注意到這份報告），但專業化和專注於一件事的有效性並沒有被取消。
考慮到上述所有因素，為了提高交付產品的品質並減少開發時間，對專案進行自動化測試的想法似乎非常合乎邏輯。 在忠誠度系統存在的不同階段，個別開發人員努力透過單元測試來覆蓋他們的程式碼。 總的來說，這是一個相當脫節的過程，每個人都使用自己的架構和方法。 最終結果對於單元測試來說是常見的：測試已開發，使用了一段時間，儲存在版本化文件儲存中，但在某些時候它們停止運行並被遺忘。 首先，這是因為測試與特定執行者相關，而不是與專案相關。
utPLSQL 來救援
你了解史蒂芬費厄斯坦嗎？
這是一個聰明的人，他將職業生涯的很長一段時間投入到使用 Oracle 和 PL/SQL 上，並就此主題撰寫了大量著作。 他的一本著名著作名為：《Oracle PL/SQL》。 對於專業人士來說。” Stephen 開發了 utPLSQL 解決方案，或者，正如其代表的那樣，Oracle PL/SQL 的單元測試框架。 utPLSQL 解決方案於 2016 年創建，但仍在積極開發中並發布了新版本。 截至報告時，最新版本可追溯至 24 年 2019 月 XNUMX 日。
它是什麼。 這是一個單獨的開源專案。 它重達幾兆位元組，包括範例和文件。 從物理上講，它是 ORACLE 資料庫中的一個單獨模式，具有一組用於組織單元測試的套件和表。 安裝需要幾秒鐘。 utPLSQL 的一個顯著特徵是它的易用性。
在全球範圍內，utPLSQL是一種運行單元測試的機制，其中單元測試被理解為普通的Oracle批次過程，其組織遵循一定的規則。 除了啟動之外，utPLSQL 還儲存所有測試運行的日誌，並且還有一個內部報告系統。
讓我們來看看使用此技術實現的單元測試程式碼的範例。
因此，螢幕顯示了帶有單元測試的典型套件規範的程式碼。 有哪些強制性要求？ 資料包必須以“utp_”為前綴。 所有帶有測試的過程都必須具有完全相同的前綴。 該套件必須包含兩個標準過程：「utp_setup」和「utp_teardown」。 第一個過程是透過重新啟動每個單元測試來呼叫的，第二個過程是在啟動後呼叫。
通常，「utp_setup」會準備我們的系統執行單元測試，例如建立測試資料。 「utp_teardown」 - 相反，一切都會回到原始設定並重置啟動結果。
以下是最簡單的單元測試範例，用於檢查輸入的客戶電話號碼是否標準化為我們的忠誠度系統的標準形式。 關於如何編寫單元測試程序沒有強制性標準。 通常，呼叫被測系統的方法，並將該方法傳回的結果與參考結果進行比較。 重要的是，參考結果與所獲得的結果的比較是透過標準 utPLSQL 方法進行的。
單元測試可以有任意數量的檢查。 從範例中可以看出，我們連續呼叫四次測試方法來標準化電話號碼，並在每次呼叫後評估結果。 在開發單元測試時，您必須考慮到有些檢查不會以任何方式影響系統，並且在某些檢查之後您需要回滾到系統的原始狀態。
例如，在所提供的單元測試中，我們只是格式化輸入的電話號碼，這不會以任何方式影響忠誠度系統。
而如果我們採用建立新客戶端的方式來編寫單元測試，那麼每次測試後系統都會建立一個新的客戶端，這會影響後續測試的啟動。
這就是單元測試的運作方式。 有兩種可能的啟動選項：從特定套件執行所有單元測試或在特定套件中執行特定單元測試。
這就是內部報告系統的範例。 根據單元測試的結果，utPLSQL 建立一個小報告。 在其中我們可以看到每個特定檢查的結果以及單元測試的整體結果。
自動測試的 6 條規則
在開始創建用於忠誠度系統自動化測試的新系統之前，我們與管理層一起確定了未來自動化測試應遵循的原則。
- 自動測試必須有效且有用。 我們有出色的開發人員，他們肯定需要被提及，因為他們中的一些人可能會看到這份報告，他們編寫了精彩的程式碼。 但即使他們精彩的程式碼也不完美，並且過去、現在、將來都會繼續包含錯誤。 需要自動測試來發現這些錯誤。 如果情況並非如此，那麼要么我們正在編寫糟糕的自動測試，要么我們已經進入了原則上尚未開發的死區。 在這兩種情況下，我們都做錯了，我們的方法根本沒有意義。
- 應使用自動測試。 花費大量時間和精力編寫軟體產品，將其放入儲存庫然後忘記它是沒有意義的。 應該運行測試，並且盡可能定期運行。
- 自動測試應該可以穩定工作。 無論一天中的任何時間、發射台和其他系統設定如何，測試運行都應該得到相同的結果。 通常，自動測試使用具有固定係統設定的特殊測試資料這一事實可以確保這一點。
- 自動測試應該以您的專案可接受的速度進行。 此時間是針對每個系統單獨決定的。 有些人可以負擔一整天的工作，而有些人則認為在幾秒鐘內完成工作至關重要。 稍後我將告訴您我們在專案中達到了哪些速度標準。
- 自動測試開發應該要靈活。 不建議僅僅因為我們以前沒有做過或出於其他原因而拒絕測試任何功能。 utPLSQL 不會對開發施加任何限制，並且 Oracle 原則上允許您實現各種事物。 大多數問題都有解決方法，只是時間和精力的問題。
- 可部署性。 我們有幾個需要進行測試的站。 在每個站，資料轉儲可以隨時更新。 有必要以這樣的方式進行自動測試項目，以便您可以輕鬆執行其全部或部分安裝。
在幾天後的第二篇文章中，我將告訴您我們做了什麼以及我們取得了哪些結果。
來源： www.habr.com