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

おい、ハブル！

私の名前はマキシム ポノマレンコです。スポーツマスターの開発者です。 私はIT分野で10年の経験があります。 彼は手動テストでキャリアをスタートし、その後データベース開発に転向しました。 過去 4 年間、テストと開発で得た知識を蓄積し、DBMS レベルでテストを自動化してきました。

私は Sportmaster チームに所属して XNUMX 年余りで、主要プロジェクトの XNUMX つで自動テストを開発しています。 XNUMX 月に、Sportmaster Lab のメンバーと私はクラスノダールのカンファレンスで講演しました。私のレポートは「DBMS における単体テスト」と呼ばれていました。今回はそれを皆さんと共有したいと思います。 文章量が多くなるので、レポートをXNUMX回に分けて投稿することにしました。 XNUMX 回目では自動テストとテスト全般について説明し、XNUMX 回目では単体テスト システムとその適用結果について詳しく説明します。

まず、少し退屈な理論です。 自動テストとは何ですか? これはソフトウェアを使用して実行されるテストであり、現代の IT ではソフトウェア開発で使用されることが増えています。 これは、企業が成長し、情報システムが成長し、それに応じてテストする必要がある機能の量が増加しているためです。 手動テストの実施のコストはますます高くなっています。

私はリリースが 2 か月ごとにリリースされる大企業で働いていました。 同時に、XNUMX 人のテスターが手動で機能をチェックするのに丸 XNUMX か月かかりました。 少人数の開発者チームによる自動化の導入のおかげで、テスト時間を XNUMX 年半で XNUMX 週間に短縮することができました。 テストの速度が向上しただけでなく、品質も向上しました。 自動テストは定期的に開始され、テストに含まれる一連のチェックが常に実行されます。つまり、人的要因は排除されます。

現代の IT の特徴は、開発者が製品コードを書くだけでなく、このコードをチェックする単体テストを書くことも求められる場合があるという事実です。

しかし、システムが主にサーバー ロジックに基づいている場合はどうなるでしょうか? 市場には普遍的なソリューションやベストプラクティスはありません。 通常、企業は独自のテスト システムを作成することでこの問題を解決します。 これは私たちのプロジェクトで作成された独自の自動テスト システムであり、それについてはレポートで説明します。

忠誠心をテストする

まず、自動テスト システムを導入したプロジェクトについて話しましょう。 私たちのプロジェクトは、Sportmaster ロイヤルティ システムです (ちなみに、これについてはすでに記事で書きました)。 この郵便受け).

会社が十分な規模であれば、ロイヤルティ システムには次の XNUMX つの標準プロパティがあります。

• システムの負荷が高くなります
• システムには複雑なコンピューティング プロセスが含まれます
• あなたのシステムは積極的に改善されます。

順番に見ていきましょう... スポーツマスターのすべてのブランドを合計すると、ロシア、ウクライナ、中国、カザフスタン、ベラルーシに1000以上の店舗があります。 これらの店舗では毎日約 300 件の購入が行われます。 つまり、毎秒 000 ～ 3 個の小切手がシステムに入力されます。 当然のことながら、当社のロイヤルティ システムには非常に負荷がかかります。 また、ソフトウェアは積極的に使用されているため、最高水準の品質を提供する必要があります。ソフトウェアのエラーは多大な金銭的損失、評判などの損失を意味するためです。

同時に、スポーツマスターは XNUMX を超えるさまざまなプロモーションを実施しています。 商品キャンペーン、曜日限定キャンペーン、特定店舗連動キャンペーン、レシート金額キャンペーン、個数キャンペーンなど、さまざまなキャンペーンがあります。 一般的には悪くありません。 クライアントには、購入時に使用できるボーナスとプロモーション コードがあります。 これらすべてが、次数の計算が非常に簡単な作業ではないという事実につながります。

注文処理を実装するアルゴリズムは本当に恐ろしく複雑です。 そして、このアルゴリズムへの変更は非常に危険です。 一見取るに足らない変化が、まったく予測できない影響をもたらす可能性があるように思えました。 しかし、自動化の最適な候補となるのは、まさにそのような複雑なコンピューティング プロセス、特に重要な機能を実装するプロセスです。 数十件の同様のケースを手作業でチェックするのは非常に時間がかかります。 また、プロセスへのエントリ ポイントは変更されていないため、一度記述しておけば、自動テストをすぐに作成でき、機能が動作することを確信できます。

私たちのシステムが積極的に使用されているので、企業はあなたから何か新しいものを求め、時代に乗り、顧客志向になるでしょう。 当社のロイヤルティ システムでは、リリースは XNUMX か月ごとに公開されます。 これは、XNUMX か月ごとにシステム全体の完全な回帰を実行する必要があることを意味します。 同時に、当然のことながら、現代の IT と同様に、開発は開発者から本番環境にすぐに移行するわけではありません。 開発者の回路から始まり、テストベンチ、リリース、承認を経て、ようやく本番環境に到達します。 少なくとも、テスト回路とリリース回路では、システム全体の完全な回帰を実行する必要があります。

説明されているプロパティは、ほぼすべてのロイヤルティ システムの標準です。 私たちのプロジェクトの特徴について話しましょう。

技術的には、ロイヤルティ システムのロジックの 90% はサーバー ベースであり、Oracle に実装されています。 Delphi には、自動化された職場管理者の機能を実行するクライアントが公開されています。 外部アプリケーション (Web サイトなど) 用に公開された Web サービスがあります。 したがって、自動テスト システムを導入する場合、Oracle 上で実行するのは非常に論理的です。

Sportmaster のロイヤルティ システムは 7 年以上存在しており、7 人の開発者によって作成されました。この 3 年間で私たちのプロジェクトに参加した開発者の平均数は 4 ～ 10 人でした。 しかし、この XNUMX 年で私たちのチームは大幅に成長し、現在 XNUMX 名がプロジェクトに取り組んでいます。 つまり、一般的なタスク、プロセス、アーキテクチャに精通していない人々がプロジェクトに参加します。 そして、間違いを見逃すリスクも高まります。

このプロジェクトの特徴は、スタッフユニットとして専任のテスターが存在しないことです。 もちろんテストはありますが、テストは、企業顧客やユーザーとのコミュニケーション、システム要件の開発などの他の主な責任に加えて、アナリストによって実行されます。 etc... テストが非常に高品質で実行されているという事実にもかかわらず（アナリストの中にはこのレポートに注目する人もいるかもしれないので、これは特に言及するのが適切です）、専門化と一つのことへの集中の有効性は取り消されていません。 。

上記すべてを考慮すると、納品される製品の品質を向上させ、開発時間を短縮するために、プロジェクトのテストを自動化するというアイデアは非常に論理的であるように思えます。 そして、ロイヤルティ システムの存在のさまざまな段階で、個々の開発者はコードを単体テストでカバーする努力をしました。 全体として、それはかなりばらばらのプロセスであり、全員が独自のアーキテクチャとメソッドを使用していました。 最終結果は単体テストに共通でした。テストは開発され、しばらく使用され、バージョン管理されたファイル ストレージに保存されましたが、ある時点で実行が停止され、忘れられていました。 まず第一に、これはテストがプロジェクトではなく特定の実行者に関連付けられていたという事実によるものです。

utPLSQL が助けになります

スティーブン・フォイヤースタインについて何か知っていますか?

この人は、キャリアの長い時間を Oracle と PL/SQL の使用に費やし、このトピックに関して非常に多くの著作を書いている賢い人です。 彼の有名な本の 2016 つに、『Oracle PL/SQL』というものがあります。 プロフェッショナル向け。」 utPLSQL ソリューション、つまり Oracle PL/SQL の単体テスト フレームワークを開発したのは Stephen でした。 utPLSQL ソリューションは 24 年に作成されましたが、現在も積極的に開発が進められており、新しいバージョンがリリースされています。 レポート時点では、最新バージョンは 2019 年 XNUMX 月 XNUMX 日に遡ります。
それは何ですか。 これは別のオープンソース プロジェクトです。 サンプルとドキュメントを含めると数メガバイトになります。 物理的には、単体テストを整理するためのパッケージとテーブルのセットを備えた ORACLE データベース内の別個のスキーマです。 インストールには数秒かかります。 utPLSQL の特徴はその使いやすさです。
世界的には、utPLSQL は単体テストを実行するためのメカニズムであり、単体テストは通常​​の Oracle バッチ プロシージャとして理解され、その構成は特定のルールに従います。 utPLSQL は、起動に加えて、すべてのテスト実行のログを保存し、内部レポート システムも備えています。

この手法を使用して実装された単体テスト コードがどのようなものになるかの例を見てみましょう。

したがって、画面には、単体テストを含む典型的なパッケージ仕様のコードが表示されます。 必須要件は何ですか? パケットには「utp_」というプレフィックスを付ける必要があります。 テストを含むすべてのプロシージャには、まったく同じプレフィックスが必要です。 パッケージには、「utp_setup」と「utp_teardown」という XNUMX つの標準プロシージャが含まれている必要があります。 最初のプロシージャは各単体テストを再起動することによって呼び出され、XNUMX 番目のプロシージャは起動後に呼び出されます。

「utp_setup」は通常、テストデータの作成など、単体テストを実行するためにシステムを準備します。 「utp_teardown」 - 逆に、すべてが元の設定に戻り、起動結果がリセットされます。

これは、入力された顧客の電話番号がロイヤルティ システムの標準形式に正規化されていることを確認する最も単純な単体テストの例です。 単体テストを使用したプロシージャの記述方法に関する強制的な標準はありません。 通常、テスト対象のシステムのメソッドが呼び出され、このメソッドによって返された結果が参照結果と比較されます。 参照結果と取得結果の比較が標準の utPLSQL メソッドを通じて行われることが重要です。

単体テストには任意の数のチェックを含めることができます。 この例からわかるように、テスト対象のメソッドを XNUMX 回連続して呼び出して電話番号を正規化し、各呼び出し後に結果を評価します。 単体テストを開発するときは、システムにまったく影響を及ぼさないチェックが存在することを考慮する必要があり、いくつかのチェックの後はシステムの元の状態にロールバックする必要があります。
たとえば、提示された単体テストでは、入力された電話番号をフォーマットするだけであり、ロイヤルティ システムにはまったく影響しません。

また、新しいクライアントを作成する方法を使用して単体テストを作成すると、各テストの後にシステム内に新しいクライアントが作成され、その後のテストの起動に影響を与える可能性があります。

これが単体テストの実行方法です。 可能な起動オプションは XNUMX つあります。特定のパッケージからすべての単体テストを実行するか、特定のパッケージで特定の単体テストを実行します。

内部通報制度の一例はこんな感じです。 単体テストの結果に基づいて、utPLSQL は小さなレポートを作成します。 そこには、特定の各チェックの結果と単体テストの全体的な結果が表示されます。

自動テストの 6 つのルール

ロイヤルティ システムの自動テストのための新しいシステムの作成を開始する前に、私たちは経営陣と協力して、将来の自動テストが準拠すべき原則を決定しました。

1. 自動テストは効果的であり、有用でなければなりません。 私たちには、間違いなく言及する必要がある素晴らしい開発者がいます。彼らの何人かはおそらくこのレポートを見るでしょうし、彼らは素晴らしいコードを書いているからです。 しかし、彼らの素晴らしいコードも完璧ではなく、これまでも、そしてこれからもエラーを含み続けるでしょう。 これらのエラーを見つけるには自動テストが必要です。 そうでない場合は、間違った自動テストを作成しているか、原則として開発されていない死角に達しているかのどちらかです。 どちらの場合も、私たちは何か間違ったことをしており、私たちのアプローチはまったく意味がありません。
2. 自動テストを使用する必要があります。 ソフトウェア製品の作成に多くの時間と労力を費やし、それをリポジトリに入れて忘れるのは意味がありません。 テストは可能な限り定期的に実行する必要があります。
3. 自動テストは安定して動作するはずです。 時間帯、発射台、その他のシステム設定に関係なく、テスト実行では同じ結果が得られます。 原則として、これは自動テストが固定システム設定の特別なテスト データで動作するという事実によって保証されます。
4. 自動テストは、プロジェクトにとって許容可能な速度で動作する必要があります。 この時間はシステムごとに個別に決定されます。 一日中仕事をする余裕のある人もいますが、数秒で仕事をすることが重要であると感じる人もいます。 私たちのプロジェクトでどのような速度基準を達成したかについては、後ほど説明します。
5. 自動テストの開発は柔軟である必要があります。 これまでにテストを行ったことがない、またはその他の理由で、機能のテストを拒否することはお勧めできません。 utPLSQL は開発に制限がなく、Oracle では原理的にさまざまな実装が可能です。 ほとんどの問題には解決策があり、時間と労力の問題です。
6. 展開可能性。 テストを実行する必要があるスタンドがいくつかあります。 各スタンドでいつでもデータダンプを更新できます。 完全または部分的なインストールを簡単に実行できるように、自動テストを使用してプロジェクトを実行する必要があります。

数日後の XNUMX 回目の投稿では、私たちが何を行ったのか、どのような結果が得られたのかをお話しします。

出所： habr.com