DBMS での単体テスト - Sportmaster での単体テストの実行方法、パート XNUMX

最初の部分 - ここで.

状況を想像してみてください。 あなたは新しい機能を開発するという課題に直面しています。 あなたには先人たちの経験があります。 あなたには道徳的義務がないと仮定すると、あなたならどうしますか?

ほとんどの場合、古い開発はすべて忘れられ、すべてが最初から始まります。 他人のコードを掘り下げるのが好きな人はいません。時間があれば、独自のシステムの作成を始めてみてはいかがでしょうか。 これは典型的なアプローチであり、多くの点で正しいです。 しかし、私たちのプロジェクトでは、違う行動を取りました。 私たちは、前任者による utPLSQL での単体テストの開発に基づいて将来の自動テスト システムを構築し、その後、いくつかの方向で並行して作業を進めました。

1. 古い単体テストを復元します。 リカバリとは、テストをロイヤルティ システムの既存の状態に適応させ、テストを utPLSQL 標準に適応させることを意味します。
2. 正確に何を、どのような方法とプロセスを理解して問題を解決するかを自動テストでカバーしました。 この情報を頭の中に入れておくか、自動テストのコードに直接基づいて結論を導き出す必要があります。 そこで、カタログを作成することにしました。 各自動テストに固有のニーモニック コードを割り当て、説明を作成し、設定を修正しました (たとえば、どのような条件で実行するか、テストの実行が失敗した場合に何が起こるかなど)。 基本的に、自動テストに関するメタデータを入力し、このメタデータを utPLSQL スキーマの標準テーブルに配置しました。
3. 拡大戦略の定義、すなわち自動テストによる検証の対象となる機能の選択。 私たちは、システムの新たな改善、本番環境からのインシデント、システムの主要なプロセスの XNUMX つに注意を払うことにしました。 したがって、リリースと並行して開発を行い、より高い品質を確保し、同時に回帰の範囲を拡大し、重要な箇所でのシステムの信頼性を確保します。 最初のボトルネックは、小切手による割引やボーナスの配布プロセスでした。
4. 当然のことながら、私たちは新しい自動テストの開発を開始しました。 最初のリリースのタスクの XNUMX つは、ロイヤルティ システムの事前定義されたサンプルのパフォーマンスを評価することでした。 私たちのプロジェクトには、条件に従ってクライアントを選択する、厳密に固定された SQL クエリのブロックがあります。 たとえば、最後の購入が特定の都市で行われたすべての顧客のリスト、または平均購入額が特定の値を超える顧客のリストを取得します。 自動テストを作成した後、事前定義されたサンプルをチェックし、ベンチマーク パフォーマンス パラメーターを修正し、さらに負荷テストを実行しました。
5. 自動テストの操作は便利であるべきです。 最も一般的な XNUMX つのアクションは、自動テストの実行とテスト データの生成です。 このようにして、起動モジュールとデータ生成モジュールという XNUMX つの補助モジュールがシステムに登場しました。

   ランチャーは、XNUMX つの入力テキスト パラメーターを持つ XNUMX つの汎用プロシージャとして表されます。 パラメータとして、自動テストのニーモニック コード、パッケージ名、テスト名、自動テスト設定、または予約されたキーワードを渡すことができます。 この手順では、条件を満たすすべての自動テストを選択して実行します。

   データ生成モジュールはパッケージとして提供され、テスト対象システムのオブジェクト (データベース内のテーブル) ごとに、そこにデータを挿入する特別なプロシージャが作成されます。 この手順では、デフォルト値が最大値まで入力されるため、文字通り指をクリックするだけでオブジェクトが作成されます。 また、使いやすさを考慮して、生成されたデータのテンプレートが作成されました。 たとえば、テスト用電話と購入が完了した特定の年齢のクライアントを作成します。

6. 自動テストは、システムにとって適切な時間内に実行される必要があります。 そのため、毎日夜間の打ち上げが計画され、その結果に基づいて結果に関するレポートが作成され、社内メールで開発チーム全体に送信されました。 古い自動テストを復元し、新しい自動テストを作成した後の合計実行時間は 30 分でした。 打ち上げは営業時間外に行われたため、このようなパフォーマンスは誰にとっても適していました。

   しかし、作業速度の最適化に取り組む必要がありました。 プロダクションロイヤルティシステムは夜間に更新されます。 リリースの一部として、夜間に緊急に変更を加える必要がありました。 午前5時に自動テストの結果を待つXNUMX分は、リリースの責任者を喜ばせるものではありませんでした（アレクセイ・ヴァシュコフに熱烈な挨拶！）。そして翌朝、私たちのシステムに対してたくさんの温かい言葉がかけられました。 しかしその結果、作業時間の基準はXNUMX分に設定されました。

   パフォーマンスを高速化するために、3 つの方法を使用しました。4 つは、ロイヤルティ システムのアーキテクチャにより非常に便利なため、XNUMX つの並列スレッドで自動テストの実行を開始しました。 そして、自動テストがそれ自体でテストデータを作成せず、システム内で適切なものを見つけようとする場合、私たちはこのアプローチを放棄しました。 変更後、総作業時間は XNUMX ～ XNUMX 分に短縮されました。

7. 自動テストを含むプロジェクトは、さまざまなスタンドにデプロイできる必要があります。 取り組みの初めに、独自のバッチ ファイルを作成する試みがありましたが、自分で作成した自動インストールは完全に恐ろしいものであることが明らかになり、産業用ソリューションに目を向けました。 プロジェクトには多くのコードが直接含まれており (まず、自動テストのコードを保存します)、データはほとんどありません (主なデータは自動テストに関するメタデータです) という事実により、プロジェクトに統合するのは非常に簡単であることがわかりました。リキベースプロジェクト。

   これは、データベース スキーマの変更を追跡、管理、適用するためのオープン ソースのデータベースに依存しないライブラリです。 コマンドラインまたはApache Mavenなどのフレームワークを介して管理されます。 Liquibaseの動作原理は非常にシンプルです。 特定の方法で編成されたプロジェクトがあります。これは、ターゲット サーバーにロールする必要がある変更またはスクリプトと、これらの変更をどのような順序でどのようなパラメータでインストールするかを決定する制御ファイルで構成されます。

   DBMS レベルでは、Liquibase がロールバック ログを保存する特別なテーブルが作成されます。 各変更には計算されたハッシュがあり、プロジェクトとデータベース内の状態の間で毎回比較されます。 Liquibase のおかげで、システムへの変更をあらゆる回路に簡単にロールアウトできます。 自動テストは、コンテナ (開発者の個人ループ) だけでなく、テスト ループやリリース ループでも実行されるようになりました。

それでは、単体テスト システムを適用した結果について話しましょう。

1. もちろん、私たちはまず第一に、より良いソフトウェアの開発を開始したと確信しています。 自動テストは毎日実行され、リリースごとに数十のバグが検出されます。 さらに、これらのエラーの中には、本当に変更したい機能に間接的にのみ関連しているものもあります。 これらのエラーが手動テストによって発見されたかどうかは非常に疑わしいです。
2. チームは、特定の機能が正しく動作するという自信を得ました... まず第一に、これは私たちの重要なプロセスに関するものです。 たとえば、過去 XNUMX か月間、リリースごとに変更が加えられたにもかかわらず、小切手による割引とボーナスの配布に問題はありませんでしたが、以前の期間ではある程度の頻度でエラーが発生しました。
3. テストの反復回数を減らすことに成功しました。 自動テストは新しい機能用に作成されているため、アナリストとパートタイムのテスターはより高品質のコードを取得できます。 それはすでに検証されています。
4. 自動テストの開発の一部は開発者によって使用されます。 たとえば、コンテナ上のテスト データは、オブジェクト生成モジュールを使用して作成されます。
5. 開発者による自動テスト システムの「受け入れ」を確立することが重要です。 これが重要かつ有用であるという理解があります。 そして私自身の経験から言えば、これは決して事実ではありません。 自動テストを作成し、保守および開発し、結果を分析する必要がありますが、多くの場合、これらの時間コストはまったく価値がありません。 本番環境に行ってそこで問題に対処する方がはるかに簡単です。 私たちの国では、開発者が列をなして、自動テストで機能をカバーするよう求めます。

次のステップ

自動テストプロジェクトの開発計画について話しましょう。

もちろん、Sportmaster ロイヤリティ システムが存続し、発展し続ける限り、自動テストもほぼ無限に開発できます。 したがって、開発の主な方向性はカバーエリアの拡大です。

自動テストの数が増えると、総作業時間は着実に増加し、再びパフォーマンスの問題に立ち返らなければなりません。 おそらく、解決策は並列スレッドの数を増やすことです。

しかし、これらは明らかな開発方法です。 もっと重要なことについて話す場合は、次の点を強調します。

1. 自動テストは DBMS レベルで管理されるようになりました。 作業を成功させるには、PL/SQL の知識が必要です。 必要に応じて、システム管理 (メタデータの起動や作成など) は、Jenkins などを使用して、ある種の管理パネルから取り出すことができます。
2. 誰もが定量的および定性的な指標を好みます。 自動テストの場合、そのような普遍的な指標はコード カバレッジまたはコード カバレッジ メトリックです。 このインジケーターを使用すると、テスト対象システムのコードの何パーセントが自動テストの対象となっているかを判断できます。 バージョン 12.2 以降、Oracle はこのメトリックを計算する機能を提供し、標準の DBMS_PLSQL_CODE_COVERAGE パッケージの使用を推奨します。

   当社の自動テスト システムはまだ 1 年ほど前に完成したばかりなので、カバレッジを評価する時期が来ているかもしれません。 私の最後のプロジェクト（スポーツマスターによるものではないプロジェクト）で、これが起こりました。 自動テストに取り組んでから 10 年後、経営陣はコードの何パーセントをカバーしたかを評価するというタスクを設定しました。 カバレッジが 20% を超えれば、経営陣は満足するでしょう。 私たち開発者はXNUMX％程度の結果を期待していました。 コードカバレッジをめちゃくちゃにして測定したところ、XNUMX% でした。 それを祝うために、私たちは賞を取りに行きましたが、どのように賞を獲ったのか、そしてその後どこに行ったのかはまったく別の話です。

3. 自動テストでは、公開された Web サービスをテストできます。 Oracle ではこれを行うことができるため、多くの問題が発生することはなくなります。
4. そしてもちろん、当社の自動テスト システムは別のプロジェクトに適用できます。 私たちが受け取ったソリューションは汎用的なもので、Oracle の使用のみが必要です。 他の Sportmaster プロジェクトでも自動テストに興味があると聞いたので、おそらく私たちはそこに行くことになるでしょう。

所見

要約してみましょう。 スポーツマスターのロイヤルティ システム プロジェクトでは、自動テスト システムの実装に成功しました。 その基礎となっているのは、Stephen Feuerstein の utPLSQL ソリューションです。 utPLSQL の周囲には、自動テスト用のコードと、ランチャー、データ生成モジュールなどの補助的な自作モジュールがあります。 自動テストは毎日実行され、最も重要なことに、機能し、利益をもたらします。 私たちは、より高品質なソフトウェアをリリースし始めていると確信しています。 同時に、結果として得られるソリューションは汎用的であり、Oracle DBMS 上で自動テストを組織する必要があるあらゆるプロジェクトに自由に適用できます。

PS この記事はあまり具体的ではないことが判明しました。テキストが多く、技術的な例がほとんどありません。 トピックが世界的に興味深いものである場合は、そのトピックを続行し、過去 XNUMX か月間で何が変わったかを説明し、コード例を示します。

今後強調すべき点や開示が必要な質問がある場合は、コメントを記入してください。

登録ユーザーのみがアンケートに参加できます。 ログインお願いします。

これについて詳しく書きましょうか？

• はい、もちろん

• 結構です

12 人のユーザーが投票しました。 4名のユーザーが棄権した。

出所： habr.com