テスト段階

ソフトウェアのテストは、ユニットテスト、統合テスト、システムテスト、受入テストの4つの段階を経ます。

1. ユニットテスト:ユニットテストは、テストの最小単位であり、テストの最も初期の段階です。通常、ユニットと見なされる機能メソッドウィンドウまたは機能モジュールに基づいて行われます。主に詳細設計書に基づいて行われます。主にホワイトボックステストに基づいて行われ、通常は開発者によって完了されます。

統合テスト: 結合テストとも呼ばれ、これはユニットテストに基づいてソフトウェアを徐々に組み立て、テストを継続するプロセスです。 ユニットとサブシステム間のインターフェースの接続も含まれます。 徐々に組み立てるプロセスでは、多くの暫定的なバージョンが作成されます。 統合テストは主にブラックボックステストに基づく

システムテスト: すべての機能が完了した後、ハードウェアとソフトウェアを統合したシステム全体を実環境でシミュレーションします。 テストの主な目的は、主に

1) システム全体が正常に機能するか

2) システム全体の互換性テスト

1) アルファ段階:ソフトウェア開発プロセス中にエンドユーザーがソフトウェアをチェック

2) ベータ段階:エンドユーザーの実際の環境でエンドユーザーがソフトウェアをチェック

1. 提案

ロジックカバレッジ

ホワイトボックステストに属します。ホワイトボックステストは、構造テストまたはロジック駆動型テストとも呼ばれます

1. ステートメントカバレッジ:プログラム内の実行可能なステートメントはすべて少なくとも1回は実行されなければなりません。ただし、ステートメント内の判断分岐には適用されません。

if A and B == true then Action1
if C or D == true then Action2
testcase: A == true B == true C == true D == falseそして、次のように実行する。
if A and B == true then Action1
if C or D == true then Action2
testcase: A == true B == true C == true D == falseそして、次のように実行する。

1. 決定カバレッジ:各決定は少なくとも1回は実行されなければなりません。つまり、真の分岐は少なくとも1回は実行され、偽の分岐も少なくとも1回は実行されなければなりません。

if A and B == true then Action1
if C or D == true then Action2
ABCDが真と偽の両方を持たなければならない場合である。
testcase1: A == true B == true C == true D == true
testcase2: A == false B == false C == false D == false
if A and B == true then Action1
if C or D == true then Action2
testcase1: A == true B == true C == true D == false(どちらも)
testcase2: A == false B == true C == false D == false(どちらでもない)

1. パスカバレッジ:この概念は比較的容易に理解できます。すべての可能なパスは少なくとも1回は通過されます。

内部ポイント、上部ポイント、下部ポイント

• 上部ポイント:境界上のポイント

• 内部点:領域内の点

上限点が有効なデータである場合、下限点は無効なデータです。

上限点が無効なデータである場合、下限点は有効なデータです。

テストケース

ソフトウェア開発ライフサイクル

1. SDLC: 要件フェーズ、設計フェーズ、構築/開発フェーズ、テストフェーズ、展開/デリバリーフェーズ、メンテナンスフェーズ

1. アルファテストとベータテストの違い

• **アルファテスト:**アルファテストは、開発環境におけるユーザー、または実際の運用環境をシミュレートした管理された環境における社内のユーザーによって実施されます。テスト現場で開発者にフィードバックを即座に提供でき、開発者はそれをタイムリーに分析し、対応することができます。機能性、ローカライゼーション、操作性、信頼性、パフォーマンス、サポート

アルファ、ベータ、ラムダは、ソフトウェアテストの3つの段階を示すためにしばしば使用されます。 アルファは最初の段階であり、通常は社内テストのみに使用されます。 ベータは2番目の段階であり、ソフトウェアの不完全な部分のほとんどが取り除かれています。 しかし、まだ欠陥や抜け穴が残っている可能性があり、通常は特定のユーザーグループにのみテスト用に提供されます。 ラムダは3番目の段階であり、この段階では製品はすでに成熟しており、市場にリリースする前に、いくつかの場所でさらなる最適化を行うだけで済みます。

ソフトウェアテストのライフサイクル

1. STLC: 要件分析:

• 開始条件: アプリケーションアーキテクチャの文書と受入基準を提供

• 成果物:テスト要件とテスト環境の詳細に必要なすべてのテストをリストアップします。

1. テスト計画

• 開始条件 - 要件文書 活動 - 目的、ソフトウェアの範囲を定義します。テスト方法をリストアップします。

テスト環境の解決策。テスト計画と管理手順の準備。役割と責任の決定。テスト成果物のリストとリスクの定義。

成果物 - テスト戦略の文書化

環境設定

開発環境:開発者が開発を行うために分岐する環境であり、開発完了後にコードをマージする環境

• リリース前環境:コードがリリース用にパッケージ化されている場合、テスト環境のコードは本番環境のコードと同じであるため、このステップは必要ありません。コードがGitブランチでリリースされている場合は、このステップが必要です。

Dev:開発ブランチ、開発者が開発し、自己テストを行うコードのブランチ

テスト:テストブランチでは、開発者がコードを開発し、コードをマージした後でテストを行います。

リリース前ブランチ:テスト環境がテストに合格した後、開発者はコードをこのブランチにマージします。テストに合格した後、運用部門がこのブランチのコードをオンライン環境にリリースします。

マスター:リリースに合格した後、この反復機能のコードをこのブランチにマージします。新しい開発機能では、新しい開発のためにマスターブランチからコードをプルします。

プレリリース環境の役割:プレリリース環境は、正式リリース前の最後のテストです。すべての機能と構成、およびデータベースは、すでにオンライン環境と非常に類似しています。今回リリースされる機能のコードのみが許可されます。テスターがテスト環境でコードがテストケースのテストに合格したことを確認した後、プレリリース環境に提出してテストを行います。プレリリース環境が合格しても、正式な本番環境で100%問題が発生しないという保証はないためです。

プレリリース環境の構成とデータベースはオンライン環境のものと同一ですが、一部の企業ではプレリリース環境のデータベースがオンライン環境に接続されており、これは危険です。

プレリリース環境のデータベース接続はオンライン環境と非常に類似しています。

テストケース

不具合記録

テストサイクル

ソフトウェア品質保証

ソフトウェアテスト ブラックボックステスト

2番目のケースでは、メールアドレスは正しいがパスワードが間違っている場合、「パスワードが違います」と表示されます。3番目のケースでは、メールアドレスが間違っているがパスワードは正しい場合、「メールアドレスが違います」と表示されます。

境界値分析:境界値付近の入力値はエラーが発生する可能性が高いため、境界値をテストするために使用されます。

1. ペアワイズテスト技法:

ソフトウェアテスト:ホワイトボックステスト

ホワイトボックステストは、ガラスボックステスト、構造テスト、アウトオブザボックステスト、透明ボックステストとも呼ばれます。

透明ボックスまたはホワイトボックスまたは透明ボックスという用語は、ソフトウェアの外殻を通してソフトウェア内部を観察できる能力を指します。

ユニットカバレッジ

1. ユニット実行でカバーされた行数 / 新規コードの行数 = コードカバレッジ

• 関数Aに新規のコード行が追加されました。コード実行中に、新規のコード行が実行され、コード行がカバーされたとみなされます。

スペースやコメントは現在、計算に含まれています。

テストベース

assert_matchとassert_equalの違いは、assert_matchが厳密なマッチングではなく正規表現マッチングを使用している点です。

上記の例は失敗しますが、以下の正規表現アサーションは成功します。

assert_match と assert_equal のもうひとつの違いは、assert_match が文字列または文字列互換型の値のチェックのみをサポートしているのに対し、assert_equal はほとんどの型の値のチェックをサポートしていることです。

テストケースを実行するための QTA インターフェイスは、まず run_test を実行し、その後 post_test を実行します。テストケースで run_test の実行中に例外が発生した場合でも、post_test は実行され、テスト環境が確実にクリーンアップされます。

歴史的な理由により、QTAはコードスタイルpreTest、runTest、postTestの別のインターフェースセットも提供しています。 テストケースを作成する際には、テストプロジェクトの既存のコードのコードスタイルを使用することが推奨されます。 新しいテストプロジェクトの場合は、コードスタイルlower_with_underを使用することが推奨されます。

テストケースでは、コードスタイル・インターフェースは1セットのみサポートされます。QTAは、run_test/runTestで選択されたスタイルに基づいて、インターフェースのコードスタイルを選択します。つまり、テストケースでrunTestが定義されている場合、preTestとpostTestのみが実行され、pre_testとpost_testは実行されません。run_testとrunTestの両方のインターフェースが存在する場合、QTAはrun_testインターフェースを優先的に選択して実行します。

k8s-podの概念の紹介

1. 基本的な枠組み

1. 状態の紹介

保留中:

ポッドは Kubernetes システムに受け入れられましたが、1つ以上のコンテナイメージはまだ作成されていません。 待機時間には、ポッドのスケジューリング時間とネットワーク経由でのイメージのダウンロード時間が含まれます。

実行中

ポッドはノードにバインドされ、ポッド内のすべてのコンテナが作成されています。 少なくとも1つのコンテナが実行中、または起動中または再起動中の状態です。

成功

ポッド内のすべてのコンテナが正常に終了し、再起動されません。 終了状態

失敗した

ポッド ポッド内のすべてのコンテナが終了し、少なくとも1つのコンテナが失敗により終了しました。つまり、コンテナがゼロ以外のステータスで終了したか、システムにより終了させられたということです

不明

何らかの理由でポッドのステータスを取得できません。通常は、ポッドが配置されているホストとの通信に失敗したことが原因です。

起動から実行までの待機状態です。この状態が長く続く場合は、原因を追跡する必要があります。

実行中

実行状態です。

終了

終了状態、削除または異常終了状態です。

アクティブな

プロセスが存在し、プロセス監視はサービス設定に依存し、プロセス監視間隔がある場合があります。

非アクティブな

プロセスは存在せず、プロセス監視はサービス設定に依存し、プロセス監視間隔がある場合があります。

不明な

サービスにはプロセス監視タスクが割り当てられていません。その理由は、容量が拡張された可能性があり、起動時に実行される開始/停止スクリプトがゼロ以外の値を返すためです。

• サービスステータス:最終的な結果ステータスで、サービスステータスにも反映されます。健全/不健全/不明などがあります。

サービスステータスは、Polarisのプラットフォームによって確認されます。サービスがPolaris側に登録されていない場合は不明となります。

123プラットフォームのtrpcサービスは、デフォルトで健全性の検出が有効になっています。

123プラットフォーム上のtrpcサービスは、デフォルトで3秒ごとにステータスを報告します。3回報告がない場合は、不健全な状態です。

インターフェース上の詳細なステータス表示

インターフェース上の詳細なステータス表示は、左から右に順に表示されます(上図参照)。下部に問題がある場合は、下部のステータスが最初に表示されます。例えば、ポッドが正常に作成され、コンテナが作成中の場合、全体のステータス表示は「待機中」となります。