ソフトウェア開発のテスト

1.ソフトウェア開発中のテスト

ソフトウェア開発ライフサイクル(SDLC,Software Development Life Cycle)は、ソフトウェアの開発、維持、改善、変更に関するガイドラインです.
ソフトウェアを開発する際には、より良いサービスでアップグレードするために、分析、設計、実施、テスト、導入、メンテナンスなどの段階を経なければなりません.
この開発ライフサイクルに従ってソフトウェアを開発する方法は様々であるが,方法論におけるV-modelから테스트 단계をより容易に理解できる.

需要分析、システム設計、設計、モジュール設計の順にタスクを細分化して実施した場合、단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트の徐々に拡大した実施をテストする.

2.テストの種類

-単位テスト

:ユニットテストは、1つのモジュールを基準に、独立して行う最小ユニットテストです.通常、メソッドレベル(機能単位)のテストに使用されます.
単位テストの特徴は以下の通りです.

インスタントフィードバックは良い利点です.

は、できるだけ簡単で、デバッグが容易で、実行が迅速であり、プログラム内の最小の構築ブロックが組み立てる前に予想通りに動作しているかどうかを証明するのに役立ちます.

の1つの方法が良好に動作することは保証できるが、それらが結合されたときに良好に動作することは保証できない.

-統合テスト

:ユニットテスト後、ユニットを結合し、テスト結果の組み合わせが正常に動作しているかどうかを確認します.

-トップダウンテストタイプ

:最上位レベルのモジュールから統合し、順番にテストする
-テストスタブの使用(stub)
->設計上の欠陥の迅速な検出

-通常試験タイプ(Bottom-UP)

:最下位レベルのモジュールを統合し、上部のモジュールを順にテストします.

を使用してドライバをテスト
->障害を分離しやすく、サブモジュールを十分にテスト
->上部構造における重要な欠陥の発見(設計上の欠陥)

-サンドイッチテスト

:トップダウンのメリットを活用
->並列テスト、時間の節約
->ルートとドライバが必要(コストがかかる)

-システムテスト

:統合テストが完了した後、完全なシステムに対するテスト

ユニットのテストまたは統合テストの機能が正しいかどうかを検証することに重点を置いている場合は、

は、システムテストが非機能性(可用性、堅牢性、信頼性、セキュリティ、パフォーマンス)の要件を満たしているかどうかを検証します.

ex)堅牢性試験、信頼性試験等

-テストを受ける

アルファテスト
:社内の他のユーザーまたは実際に買収されたユーザーに開発環境で制御されたテストを行い、エラーと使用上の問題をリアルタイムで理解させ、エラーの買収テスト方式の一つをタイムリーに是正させる.

βテスト
:一部のユーザーにソフトウェアを配布して直接使用し、ユーザーにフィードバックを通じて可用性を理解させるテスト方法.

3.ソフトウェアテストを行う理由

-コードがうまく機能しているかどうかをどうやって確認できますか?

どんなに明確に要求されても、ソフトウェアの機能に予想外の異常なストリームが発生したり、計画的な修正が発生したりします.開発が進むにつれて、いくつかの修正が行われる可能性があります.需要の変化に伴い、開発者は需要を最適化できない可能性が高い.初期の実装では、機能が細分化されるにつれて、コードの構造や関係がより曖昧になります.
これらの手順を繰り返すと、コードの品質が低下し、修復機能に多くの時間とコストがかかります.
この点を最小限に抑えるために、メンテナンスに専念し、一連の手順で変更の安定性を確保します.
メンテナンスが早ければ早いほど、メンテナンスコストが低くなります.ソフトウェアテストの目標は、新しく発生したエラーを減らし、メンテナンス中にどのような問題が発生したかを確保し、私のコードを良好に数値化し、それによって新しく発生したエラーを減らし、既存の正常な運行機能に問題が発生しないようにすることです.

4.有効検証のテストコード基礎

1.F.I.R.S.Tユニット試験原則

Fast-Unitテストは速くしてください.
Isolate d-他のテストに依存するテストは絶対に作成されません.
Repeatable-テストは、実行するたびに同じ結果を生成する必要があります.
自己検証テストは、結果が正しいかどうかを自分で判断できるはずです.実行するために手動で特定のステータスを作成する必要があるテストなどは作成されません.
Timely-Unitテストは、本番コードテストが成功する前に構成する必要があります.テスト主導も開発(TDD)方法論の原則に適しているが,適用しない場合もある.

2.Given When-Thenモード

:代表的なテストコード作成スタイル.
[準備-実行-検証]プロセス

Given
 테스트에서 구체화하고자 하는 행동을 시작하기 전에 테스트 상태를 설명하는 부분
When
구체화하고자 하는 그 행동
Then
어떤 특정한 행동 때문에 발생할거라고 예상되는 변화에 대한 설명

5.テストコードの利点

実行ガイド:EXCELドキュメントのように、テスト結果を記録するのではなく、方法が要求通りに動作しているかどうかを確認できます.

テスト時間の短縮:手動で介入する必要はありません.コードにテストする値を付けるだけで終わります.

の柔軟性を提供:変更しても、既存の機能に影響を及ぼすかどうかを簡単に確認できます.側面効果のコントラストが容易になりました.

再利用可能:最大の利点.コードを実行すれば、テストは終了します.

ソース
SDLC
テストの種類
ユニットテスト
統合テスト
保守コスト
ユニットのテストケースと利点