一般的な用語
ソフトテストの一般的な用語：
C / S
Cはクライアント（クライアント）を指し、Sはサーバー（サーバー）を指します。このソフトウェアはLANまたはインターネットに基づいており、サーバーにサーバー側ソフトウェアをインストールする必要があり、各クライアントはクライアントソフトウェアをインストールする必要があります。たとえば、私たちがよく使用するQQやさまざまなオンラインゲームは、C / S構造化ソフトウェアに属しています。
B / S
Bはブラウザー（ブラウザー）を指し、Sはサーバー（サーバー）を指します。このソフトウェアもローカルエリアネットワークまたはインターネットに基づいています。それとC / S構造ソフトウェアの違いは、クライアント（クライアント）をインストールする必要がないことです。 ）、ブラウザさえあれば、そのままご利用いただけます。たとえば、Sohu、Sina、163メールボックスなどのポータルWebサイトはすべてB / S構造化ソフトウェアです。B/ S構造化ソフトウェアは現在のソフトウェアの主流です。C/ S構造化ソフトウェアと比較すると、アップグレードと保守が簡単であり、テストの焦点となっています。
不具合[バグ/不具合]
ソフトウェアのバグとは、ユーザーのニーズを満たさないソフトウェア（プログラムやドキュメントを含む）の問題を指します
テスト環境
ソフトウェアテスト環境は、ソフトウェア、ハードウェア、およびネットワークのコレクションを含む、ソフトウェアが実行されるプラットフォームです。
方程式を使用して表現：テスト環境=ソフトウェア+ハードウェア+ネットワーク
テストケース[テストケース]
テスト環境、テストステップ、テストデータ、期待される結果など、テスト実行前に設計された詳細なテスト計画。
式を使用して簡単に表現します。テストケース=入力+出力+テスト環境
（
「入力」にはテストデータと操作ステップが含まれる）
「出力」は期待される結果を参照
「テスト環境」はシステム環境設定を参照
煙のテスト[煙のテスト]
新しいバージョンで大規模なシステムテストを行う前に、まず、ソフトウェアの基本機能が実現されているかどうか、およびそれらがテスト可能かどうかを確認します。
回帰テスト
以前に見つかった問題が修正されているかどうか、および新しいバグが生成されているかどうかを確認します。
回帰テストとは、古いコードが修正された後に再テストして、修正によって新しいエラーが発生したり、他のコードでエラーが発生したりしないことを確認します。自動回帰テストは、システムのテスト、メンテナンス、アップグレードの段階のコストを大幅に削減します。
ソフトウェアテストプロセス全体では、ワークロードの大部分を占め、ソフトウェア開発の各段階で複数の回帰テストが実行されます。正しい回帰テスト戦略を選択することにより、回帰テストの効率と効果を向上させることは意味があります。
内部および公開ベータ
内部テスト：ソフトウェアが作成された後、実際のユーザーに引き渡されますか？それを使用したときに見つけられなかった問題がありますか？問題があるかどうかを確認するために一緒に使用する内部スタッフを探してください。
パブリックベータ：
内部ベータと同じですが、外部ユーザーのみを探します
アルファテストとベータテスト
€アルファテスト //重要な
アルファテストは、開発環境でユーザーが実行するテストです。または、シミュレートされた実際の動作環境で社内のユーザーが実行するテストでもかまいません。アルファテストの目的は、ソフトウェア製品のFLURPS（つまり、機能、ローカリゼーション、使いやすさ、信頼性、パフォーマンス、およびサポート）を評価することです。
受け入れテストの1つのタイプは、ユーザー、テスター、開発者などが共同で参加する
大規模な汎用ソフトウェアの内部テストを指します。正式リリース前に、通常、アルファテストとベータテストを実行する必要があります。アルファテストは、プログラマーやテスターが行うことはできません。
€ベータテスト（ベータテスト） //重要な
ベータテストは受け入れテストです。ベータテストは、ソフトウェアのエンドユーザーが1つ以上のゲストルームの場所で実施します。
アルファテストとベータテストの違い：
さまざまなテストサイト：アルファテストとは、開発者の施設にユーザーにテストを依頼することを指し、ベータテストとは、1人以上のユーザーの施設で実施されるテストを指します。
Alphaテストの環境は開発者によって制御され、ユーザー数は比較的少なく、時間は比較的集中しています。ベータテスト環境は開発者によって制御されておらず、ユーザー数は比較的多く、時間が集中していません。
アルファテストは、ベータテストの前に実行されます。一般的なソフトウェア製品は大規模なベータテストを必要とし、テスト期間は比較的長いです。
テストカバレッジ
カバレッジは、テストの整合性を測定する手段であり、テストテクノロジーの有効性の尺度でもあります。
カバレッジ=（少なくとも1回実行されるアイテムの数）/アイテムの合計数
（Alipayには、今回は10,000の関数ポイントがあります） 9,000のテストがテストされました。つまり、カバレッジは90％
です
。）機能： 1.カバレッジデータを通じて、テストが十分かどうかを確認できます
。2。テストの弱点を分析し
ます。ユースケースはテストの品質を効果的に改善しますが、テストのコストはカバレッジの増加に伴って増加するため、テストケースの設計はカバレッジを追求できません。
ブラックボックステストのテストカバレッジは、主に2つの側面を参照します。
要件カバレッジとユースケースカバレッジ
需要カバレッジ
1.定義：テスト中にテストされた機能とそれらがテストされた頻度、およびこれらの機能の何パーセントがシステムで説明されたかを示します。特定のテストケースを設計することにより、それぞれが必要になります需要地点はテストされています。
2.計算式：需求覆盖= (被验证到的需求数量) / (总的需求总数)
ユースケースカバレッジ（非常に重要な測定要素）
1.定義：ユースケース全体におけるテスト検証の各ラウンドで合格するユースケース数の割合に主に反映されます
。2.計算式：用例覆盖= (验证通过的用例数量) / (总的用例总数)
テストカバレッジの使用
単純なテストカバレッジ：本次测试执行的用例数/所有用例数
上記のカバレッジ統計は、ユースケースの総数が包括的に記述されているという見解に基づいており、大規模なシステムテストでは通常100％のカバレッジが必要です。
主にテスターをテストして、戦略の現在のバージョンを制御し、カバレッジ率がテスト戦略を満たすことを確認します。
覆盖率的审核:抽样验收
製品ベースのテストカバレッジ：已测试需求点/设计所有需求数
大規模なプロジェクトや小さな需要の反復が100％のカバレッジを必要
とするかどうかにかかわらず、製品と需要のディメンションに基づいて、この結果を製品側に送信するのがより多く、製品側は漏れがないかどうかを判断しますの。
覆盖率的审核:抽样验收
ホワイトボックスベースのテストカバレッジ：ほとんどのツールが文のカバレッジを判断します。单元测试代码覆盖代码行/总代码行
より多くの研究開発スタッフ、より頻繁に80％のカバー率が必要+
缺陷:覆盖率数据只能代表测试过哪些代码，コードが適切にテストされているかどうかを表すことができないため、ロジック、判断、その他のシナリオを見逃しがちです
自動化に基づくテストカバレッジ：自動化によってカバーされるテストシナリオ（テストケース）/すべてのテストシナリオ（ユースケース）
80/20原则.たとえば、ユーザーは自分の機能の20％を80％の時間使用し、20％の機能が最も重要なビジネスシナリオをサポートできます。自動テストのユースケースの選択は、コア機能のこれら20％に重点を置いています。
用途：自动化测试更着重于回归验证，過度のカバレッジを追求する必要はありませんが、ユースケースの設計を検討する必要があります（回帰テストはメインプロセスビジネスを追跡しています）
テストカバレッジの究極の意味
最も広く使用されている場所は、测试停止标准，以及考核测试人员的标准
テストカバレッジについて簡単に説明することです。テストカバレッジは、ウォーターフォール開発モデルでは重要ではありませんが、スパイラルでアジャイルな開発モデルでは、継続的な反復と累積により、很难确定哪些模块在开发过程中没有给予足够的测试
その中短迭代、DevOpsで、ユニットテストカバレッジを使用して、増加するコード量を評価することに重点が置かれています。
