まず、最初のソフトウェアのテストは何ですか？ソフトウェアテストの目的と原則
動作させるためのプログラムで指定された条件の下では、バグ、対策ソフトの品質を、発見し、それが設計プロセスの要件を満たすことができるかどうかを評価します。
ソフトウェアテストの目的：
- テストは、プログラムの実行で、それがエラーを発見することを目指して
- 成功したテストは、これまでのところ、エラーを発見していない発見されました
- 成功したテストは何のテストを発見したこれまでの間違った発見されました
- それは約束したかを発表しました機能の完了を確認し、明確に指示を書かれている機能へのユーザーアクセスを提供します。
- 製品は、パフォーマンスと効率性の要件を満たしていることを確認するために、
- 製品が堅牢であることを確認し、ユーザーの環境に適応
ソフトウェアテストの原則：
- テストケースの一部でなければなりません出力を引き継ぐことが予想または定義されています
- プログラマは、自分の書かれた手順をテストすることは避けてください
- 書き込みソフトウェアへの組織は独自のテストソフトウェアを書くべきではありません
- これは、各テストの結果を徹底的に調査する必要があります
- 書き込みテストにのみ有効と予想外の入力状況に基づくべきではありませんが、また、不正な入力や予期せぬ状況に基づくべきです
- 手順は、「それが行われるべきで行われていない」こするかどうかのチェックは半分しかテストのある、テストは、プログラムの残りの半分がチェックすることです「それは行うべきではありませんやって。」
- ソフトウェア自体は1回限りのソフトウェアでない限り、使い捨てテストケースは、避けるべきです
- 私たちは、テスト作業を計画する際に、デフォルトのエラーを見つけることができませんことを仮定するべきではありません
- プログラムのより多くの間違った一部の可能性があり、エラーの数に一部の比例が発見されています
- ソフトウェアのテストは非常に創造的、挑戦的な知的作業であります
第二に、あなたは、ソフトウェアテスト、簡単な紹介の種類が何であるかを知っています。
カテゴリ別テスト戦略：
1、静的および動的試験
2、ブラックボックスとホワイトボックス
3、手動および自動テスト
4、スモークテスト
5、回帰テスト。
カテゴリ別テストフェーズ：単体テスト、統合テスト、システムテスト、受け入れテスト。
他の一般的な試験方法：1、2機能試験、性能試験3,4ストレステスト、負荷試験5,6ユーザビリティテスト、設置および試験7、8インタフェース試験、9は、テスト文書10、11互換性テストにテストを配置、 12セキュリティテスト、復旧テスト
ソフトウェアの受け入れの正式な受け入れテスト、アルファテスト、3つのテストをベータテストを含むテスト。
第三に、何であるか、現在の主要なテストケースの設計方法？
ホワイトボックス：サイクルをカバーする論理的なカバレッジ、基本的なパスカバレッジ
ブラックボックステスト：境界値分析、同値分割、エラー推測方法、因果ダイアグラム、状態図、アウトライン試験方法、ランダムテスト、シーンメソッド
DESCRIPTION静的試験、動的試験、ブラックボックステスト、ホワイトボックス、β、αテストテストは何
- 静的テストが存在する可能性のあるエラーまたはプロセスアセスメントプログラムコードのプログラムコードのためのプログラム自体を実行していませんでした。
- 動的試験は、実際の差分演算の結果が期待される結果を確認するために、テストケースに対応する入力、テスト対象プログラムを実行して、それが試験手順の正確さ、信頼性および妥当性に要求の実行結果かどうかが決定されると、システムの動作効率を分析し堅牢性の特性。
- ブラックボックステストは、一般に、正確さとソフトウェア機能の操作、ソフトウェアの目的は、プログラムに関係なく、それらの内部構造の、ブラックボックスのように試験されて実現されるかどうかを検出するの各機能を確認するために使用され、プログラムが知りますまたはソフトウェアのテスト仕様と推論によって入力と出力の間にプログラム機能との関係は、テスト結果の正しさを決定する場合。
- ソフトウェアの内部ロジックをテストするホワイトボックス構造解析、コードがテストに基づいて、テスタープログラムコードを読み取ることにより、または品質シングルステップデバッギングソフトウェアを決定するために開発ツールを使用して、典型的には、プロジェクトマネージャーによってテストブラックボックスで開発プログラマが実現しています。
- αテストは、テストは、ユーザが開発環境で実行され、ユーザーに制御することができる内部テストをシミュレートし、実際の動作環境の下で行われ、アルファテストは、プログラマーやテスターで完了することができません。
- βテストは、ユーザーの実際の環境の一つ以上のユーザソフトウェアの複数をテストするために行われます。開発者は通常、テストサイト、ベータテストは、プログラマーやテスターで完了していないではありません。
第四に、ソフトウェアのライフサイクルとどのモデル？
ソフトウェアのライフサイクル（ソフトウェアライフサイクル）が、また、ソフトウェアのライフサイクル、生存率として知られています。終焉まで失う値まで全体のプロセス、開発されたソフトウェアの将来の利用の形成からソフトウェア開発の概念を指します。一般的に、3つの期間の計画（定義）、開発、動作（メンテナンス）を含む全体のライフサイクルは、各期間は、いくつかの段階に分けられます。各ステージには、明確な権限を持っています。
サイクルモデル（通常数）：
- ウォーターフォールモデル
- ラピッドプロトタイピングモデル：ラピッドプロトタイピングモデルは予備可能にし、ソフトウェア要求分析段階、迅速な設計とプロトタイプソフトウェアシステムの開発における要件の分析と定義を完了していない、プロトタイプディスプレイのすべて、またはユーザのソフトウェアに機能と性能の一部が開発されます;プロトタイプのテストのユーザー評価は、洗練されたソフトウェア要件を豊かにする具体的な改善を与え、承認後、完全なソフトウェア実装とテスト、および保守までそれに応じて修正されたソフトウェアの開発と改善、顧客満足度を。
- 反復モデル：反復がすべての開発活動の製品リリース（安定し、製品の実行可能なバージョン）を生成することを含む、出版のために必要なすべての他の周辺要素を使用します。要件分析、設計、実装、テストのワークフロー：ように、反復は、すべてのワークフローのプロセスを経て完全な開発です。本質的には、それは小さな滝のプロジェクトに似ています。RUPは、すべてのステージを反復処理に分けることができると信じています。各反復は、製品の可能性リリースを持っていますが、この製品は、最終製品のサブセットです。
ライフサイクルのステージ：
- 計画と実現可能性解析ソフトウェア
- 要求分析
- ソフトウェア設計
- コーディング
- ソフトウェアのテスト
- 運用・保守
第五に、テスト計画作業の目的は何ですか？テスト計画書は何を含める必要がありますか？これらのうちどれが最も重要なのでしょうか？
ソフトウェアのテスト計画は、テストプロセスをガイドするためのプログラム文書です。
- 指導等マクロ対照試験計画、資源の対応する割り当てすることができます
- テスター等、実施すべきテストケースとテストプロジェクトの異なる段階で、プロジェクト全体の仕事を理解することができます
- 他の人の仕事の内容テスターを理解しやすい、行って仕事に関連します
これは、製品の内容の概要は、テスト戦略、テスト方法、テスト領域、為替、リスク分析をテストするテスト構成、テスト期間、テストリソースが含まれています。ソフトウェアテスト計画、プロジェクトに関わるテストのメンバー、特にテスト管理で、テストタスクと明確なテスト方法、テストの進行状況の円滑な通信テスト実装、追跡および制御を維持するために、テストプロセスの変化に対応しています。
テスト計画6つの要素（5W1H）を書き込みます：
- なぜwhy--これらのテストを実施します。
- 何、what-テストの異なる段階での仕事内容。
- when-異なる段階での試験開始時刻と終了時刻。
- where-適切な文書、欠陥、試験環境の格納場所、
- テスターはテスト用にアレンジwho-プロジェクト関連のスタッフ、。
- 、それを行う方法をHow-たテストツールとテスト方法テストのため
詳細なテスト計画、テスト仕様書、テストケースは、戦略と戦術の関係で、テスト計画の主な活動は、計画されたマクロ試験方法及びリソースの割り当て、および詳細なテスト仕様書の範囲、テストケース、テスト作業の具体的な戦術を完成させることです。最も重要なことは、テスト戦略とテストメソッドをテストすることですので、（それが最初のレビューに最善です）。
第六に、どのようなテストは、ソフトウェアのテストの方針と各段階のいくつかのステージの要件に分けていますか？
どのようなソフトウェアのテスト戦略？
ソフトウェアテストの戦略：特定のソフトウェアの下でテスト仕様書、テスト項目がテストされ、特定の環境制約に基づいて原則およびソフトウェア要件のセット、道、方法を導くために基準をテストします。
そして、対応する開発プロセスは、テストプロセスは、内ユニットテスト、統合テスト、システムテスト、受け入れテストの4つの主要な段階を経るになります。
- ユニットテスト： - でも、コードセグメントは、通常、開発者によって行われ、作業プログラムモジュールの正当性を確認するテストユニットテストは、ソフトウェア設計の最小単位です。
- 統合テスト：統合テストは、テストのための設計要件に合わせてモジュールを組み立てることで、主な目的は、インタフェースに関連する問題を特定することです。検査部門に提出する前に製品ので、製品開発チームは、ほとんどのエンタープライズ統合テストは開発者によって行われているそうで、関節のデバッグを持っています。
- システムテスト：システムのテストは、サブシステムが正常に動作しているかどうかを検証し、設計を完了するために、完全に動作システムの目的によって、統合テストの後に行われます。これは主に、検査部門によって行われた試験部門は最大かつ最も重要なテストでは、製品の品質に大きな影響を及ぼしています。
- 受け入れテスト：受け入れは、受け入れ基準のための要件フェーズ「要求仕様」をテストするテスト中に実際の動作環境をシミュレートするために、ユーザが必要となります。実際のプロジェクトのために実施し、顧客の製品のため、最終的なシステムテストすることができます。特に文書のテストのための機能モジュールの包括的なテストのためのテスト内容。
ユニットテスト戦略：
トップダウンのユニットテスト戦略：孤立ユニットテストよりもはるかに高いコストが、良い選択は、ユニットテストではありません。
ボトムアップ戦略ユニットテスト：ユニットより合理的な戦略をテストするが、より長いテスト期間。
分離されたユニットテスト戦略：最高のユニットテスト戦略。
テスト戦略をテストの統合：
ビッグバンは統合：メンテナンス型プロジェクトや小さなテスト・システムに適応します
トップダウン統合：制御構造は、製品に適合しているが、比較的透明で安定であり、マイナーレベルのインターフェースを変更し、基本的なインタフェースは、多くの場合、定義されていないか、変更されてもよい;収量ポート制御アセンブリできるだけ早く検証するために、大きな技術的なリスク、必要性を持つ、早期希望あなたは、製品のシステム機能の動作を確認することができます。
統合されたボトムアップ：インタフェースが安定底部に適合し、高レベルのインターフェースは頻繁に変化;底アセンブリが早く完了する。
統合進歩の利点：並列性の高い、効果的にプロジェクトの開発の進捗状況を短縮することが可能です。短所：ワークロードとパイルが大きい駆動、いくつかのインターフェーステストは十分ではなく、いくつかのテスト複製及び廃棄物。
テスト戦略をテストシステム：
データとデータベースの整合性テスト、機能テスト、ユーザー・インタフェース・テスト、性能評価、負荷テスト、強度試験、能力テスト、テストセキュリティとアクセス制御、フェイルオーバーおよびリカバリのテスト、設定テスト、テストインストール、暗号化テスト、ユーザビリティテスト;ビルド検証テスト、テストドキュメント
七は、ソフトウェアテストのすべての段階は、通常、どのような仕事をしていますか？文書の様々な段階が、結果は何ですか？何が含まれていますか？
ユニットテストフェーズ：単位モジュールはそれぞれ独立して、各プログラム・モジュールのチェックサムの正しさを検査する相対的分離、ユニット内のシステムの残りの部分は、プログラムチェックが各機能モジュールが正しく指定実施しているか場合に試験しました。テストレポート生成部は、レポートの欠陥を提出します。
統合試験：試験は、統合ユニットテストに基づいて、ワークの各部分のテストに達し又は設計仕様プロセスの概要とによって要求されるように、モジュール、サブシステムまたはシステムに組み込まれているすべてのソフトウェアユニットのそれぞれの仕様に達成してい必要な活動。テストレポートを生成するための統合フェーズは、バグレポートを提出します。
システムテストフェーズ：検証テストソフトウェアを介して、素子全体所与のコンピュータシステム、およびコンピュータ・ハードウェアなど、周辺の他のシステム要素、共にサポートソフトウェア、データ及び人員の一部、実際の動作環境下で、コンピュータシステムは、完全に機能カバレッジです。このフェーズでは、バグレポートとテストの概要を提出する必要が。
八、一般的なブラックボックステストケースの設計方法は何ですか？それぞれ具体的には、設計作業におけるこれらの試験方法の適用を説明するためにしてください。
1）同値類に分割：同値クラスは、サブセット内の入力フィールドのサブセットを指し、プログラムのエラーを公開するために、それぞれの入力データが仮定に相当し、合理的である。同等の試験クラスの代表値は、このようにテストのこのタイプの他の値に等しく、すべての入力データは、いくつかの合理的な等価クラスに分けることができ、少量使用することができる、試験された条件のそれぞれの入力としてデータの同値類を取り有効および無効な等価クラス等価クラス：より良い結果を達成するための代表的なテストデータは、クラスが2つの異なる状況に分けることができる等価性。
2）境界値分析：相補体は分割方法を同値。テストの経験ではなく、入力と出力の範囲内で発生したよりも、エラーの多くは、入力または出力範囲の境界で起こると言われます。ボーダーさまざまな状況のためにそのため、設計・テスト・ケースを、より多くのエラーを検出することができます。
境界値分析テストケースを使用して、第1の境界条件を決定すべきである。ある通常の入力および出力の境界等価クラス、テストの境界に焦点を当てるべきである場合には、正確にだけ少ないテストデータとしての境界の値よりもよりわずかに大きい、等しい、または選択されるべきです典型的な値または任意の値に対し、テストデータとして等価クラスを選択していません。
3）の方法を推測エラー：ターゲットデザインのテスト例の方法があるように、経験と勘で存在することができるすべての様々なエラーに基づいて、プログラムを推測しています。
方法を推測誤りの基本的な考え方：すべての可能なプログラムエラーが含まれるとエラーが発生しやすい、いくつかの特別な事情が、例えば彼らの選択のテストケースに応じて、モジュールのテストユニットには多くの一般的なエラーは、以前の製品をリストされていました。これらは要約テストはエラーの経験を発見している。また、入力データと出力データは、表スペースの0入力フォームであるか、または唯一の行を入力する。これらは、エラーを起こしやすい。任意これらの場合テストケースの一例。
4）方法図の因果関係は：等価分割方法及び境界値の分析方法は、上述した、入力条件が重要な考慮事項であるが、入力条件との間のリンクを考慮していなかった、およびその他の考慮事項は、入力条件の間に互いに組み合わせる各々と組み合わされます。いくつかの新しい状況を生成します。しかし、チェックへの入力条件の組み合わせは、すべての入力条件は同値クラスに分割されている場合でも、簡単な作業ではありません、それらの間の組み合わせは非常に多くのことを、とても適していると考えなければなりませんでした種々の条件に記載の組合せのために、考慮すべきテストケースの複数の形で対応するアクションを生成する。これは、原因と結果の図（論理モデル）の使用を必要とする。プログラム入力条件をチェックするように適合されて生成された最終的な決意テーブル原因図3の方法をさまざまな組み合わせ。
5）直交表分析：これは、理由パラメータの数の組み合わせであってもよいが、同時に、これらのテストケースと優先順位に明らかなギャップ、およびテスターは、試験のような多数を完了することができない、テストケースの数の急増を引き起こしましたユースケース直交表の最大の可能な範囲をカバーする可能性を達成するように、できるだけ、ケースの数とを低減することができます。
6）シーン分析方法は：ユーザの操作ステップ、より類似因果ダイアグラムが、深さに応じてシーンをシミュレートするためにユーザを指し、より良い実行可能性を実行することができます。
7）図メソッドの状態：テスト中のシステムの状態を説明したすべての条件とシステム要件を入力することにより得られるが、入力条件及び状態により得られた出力条件は、テスト入力条件と出力条件の状態を介してテストシステムを星。
8）メソッドの概要：概要方法は、さまざまなテスト条件をリストし、需要に着目する方法である、需要が輪郭の形に変換されます。輪郭は、固有のパスは、各葉ノードとルート間に存在する、木構造として表現されます。各パスは、入力条件の特定のセットの輪郭を規定する、テストケースを定義するために使用されます。ツリーパスまたはアウトラインの数は、実質的にテストケースの数を必要なすべての機能をテスト葉が与えられます。
九、簡単にバグのライフサイクル？
1.有効記録BUG
2.テンプレートBUG
3.評価と重要度の優先BUG
4.BUG生活
データベースBUGを維持5.
テン、ソフトウェアのバグ（またはと呼ばれるバグ）には何が記録しますか？高品質なソフトウェアの欠陥（バグ）レコードを提出するには？
バグの記録を最小限に含まれている必要があります。
バグ番号、
バグの重要度、優先順位、
モジュールによって生成されたバグ、
まずバグ要約を持っている、一般的なバグの内容が記載され、
バグがバージョン対応する、
現象のバグの詳細な説明を、いくつかのスクリーンショット、ビデオなど....など、
バグテスト環境が発生した場合、対応する操作条件は、発生すなわち、ステップと、
高品質の記録バグ：
1）一般的なUIを統一するために、正確な
UI UIのバグレポートは、簡単な位置決めを見つけるために、テスト・ソフトウェアと一致しています。
2）業界の従来の方法を発現する用語および表現のメイク使用
正確な発現を確実にするために、式業界の用語および表現の従来の方法を用いては、特殊化を反映しています。
3）各欠陥レポートは、唯一の欠陥などが
あたりの欠陥報告書は、欠陥修正はすぐに欠陥、欠陥の修正に集中する時間を見つけることによって作製することができる、唯一の欠陥を含んでいます。欠陥が正しく修正されたかどうかを時間チェック検証。
4）非再現性の欠陥が報告しなければならない
最初の不具合報告が欠陥を再現する能力を示さなければなりません。再現しようとする非再現性の欠陥、その後、まだ、まだ欠陥を報告する必要がありますが、レポートでは、欠陥の発生頻度を再現することはできませんを示すために、再現しようとしない場合。
5）明らかに欠陥のタイプを示す
欠陥のタイプを決定するために合計欠陥現象に記載の方法。例えば、機能欠陥、界面欠陥、欠陥データ、合理化を提案することをこれは、欠陥や欠陥、欠陥または形態のいくつかの種類に属する欠陥の他の形態の最も一般的なタイプです。
6）明らかに欠陥の重大度レベル及び優先度を示す
重要度レベルと優先順位との間の時間差を明確。高い深刻な問題は、小さな装飾的な問題は、高い優先度として見られるかもしれない、価値が解決されない場合があります。
7）完全な記述（説明）、簡潔、正確には、位置の欠陥または欠陥の記録、実質ベースの欠陥を明らかにした
正確な欠陥、ショートおよびクリアを反映するコンテンツ記述の性質。欠陥が良い習慣である場合、ユーザインターフェース（UI）を含むソフトウェアの欠陥管理データベースの開発の欠陥を見つけるためにテストを容易にするために。このようなダイアログボックスのタイトル、レコード、メニュー、ボタンなどのコントロールの名前として。
8）同じフォント、フォントサイズ、行間用いて、シリアル番号との間の自動短い線を使用して
短い線との間の自動化されたシリアル番号を使用して、同じフォント、フォントサイズ、行間、各レコードを使用して標準的な操作を行うために、一貫性のある形式を確保することができプロ。
9）の可能な各ステップは、唯一の動作を記録する
単純な、よく組織、容易に反復手順を確保します。
10）検証ステップ完全、正確、簡単には
迅速かつ正確な繰り返しの欠陥を確実に、「完全な」すなわち隙間なく、「正確な」それは余分なステップ正しいステップ、「簡単」です。
11）欠陥は、撮影をするかどうかを選択する
欠陥又は欠陥を目視観察される現象に、多くの場合、記録部の「取り付け」の添付として画像の形で発生する追加の界面欠陥又は欠陥が必要です。スペース、だけでなく、欠陥や欠陥の性質の真の反射を保存するには、フルスクリーンの欠陥や欠陥、アクティブウィンドウ、およびローカルエリアをキャプチャすることができます。すばやく見つけるには、欠陥または欠陥を修正位置は、一般的に追加の制御中国の図が必要です。
追加の必要な特殊な文書や個人的な提案やコメントは、
あなたが特定の文書が生成開くと、すぐに不具合や欠陥を再現することができますので、あなたは、ドキュメントを添付する必要があり、欠陥や欠陥。時には、欠陥や傷のために、さらにパフォーマンスの欠陥や欠陥を明確にするために補正した、それは個々の提案された変更やコメントに取り付けることができます。
12）スペルおよび文法の欠陥を確認し
、各欠陥または欠陥を送信する前に、スペルチェック、文法、コンテンツは、欠陥の正しい説明正しいことを確認します。
複雑な文の回避フレーズとフレーズ、センテンスの13）メイク用
ソフトウェアの欠陥管理データベースオブジェクトは、欠陥の位置合わせを容易にするためであり、したがって、読める強化語彙と文の複雑さの変更を必要としない、手続きの客観的な説明が必要でセックス。
上記は、ソフトウェアテスターの異なるテスト要件は、長い期間にわたってテストして、テストの欠陥を報告するための規制要件をまとめたもので、対応するテストの経験を蓄積してきた、徐々に良いプロの習慣を開発する、新しい要求仕様の書き込みを追加していきます。また、頻繁に読書は、比較して、考えるように彼の前のテスト、バグレポートと合わせ、他のテストエンジニア・テスト・バグレポートを、学習スキルを改善し続けることができます。
14）欠陥説明
欠陥の欠陥に記載された手順、実際の結果と、所望の結果を含んでもよいです。精通していない、彼はあなたが欠陥を参照していることを理解しているが、手順の開発者が簡単に再生欠陥は、一部の開発者の再生不良欠陥の能力を修正することができますが、それはシステムに参加する新しい開発者のために特別に再現することができない、彼らは簡単にできることな手順を説明再現。実際の結果は、開発者が間違っているかを理解することを可能にする所望の結果は、開発者が正しい結果がどうあるべきかを理解することを可能にするということです。
（Bugzillaのと一例として）XIバグ追跡プロセス管理ツール
テスターは、状態は新しいもので、Bugzillaのに提出し、バグを発見したスタッフの開発インターフェイスへのBUG者
BUG開発インタフェースは、関連する開発者のモジュールに割り当てられます、状態が確認BUGに変更、開発者とテスターのために割り当てられた、それは私のバグであれば、受信するように設定されている、別の開発者が問題である場合、転送し、この動作は、次の開発者によって行われ、あなたはそれが問題ではないと思われる場合、我々はバグを拒否し、議論し、確認する必要があり、近くにテスタこの問題を。
開発者がバグを受け入れた場合、良い変更した後、固定とBUGのステータスを修正し、あなたがテスト可能なテストバージョンを知らせます。
あなたは問題が持続を見つけた場合、新しいバージョンをテストするためのテスターは、その後、認証が拒否され、あなたが修復する必要がある場合は、バグをオフにしてください。
十二、ソフトウェア開発プロセスのどのタスクテスターはありますか？
1は、可能な限り早期に、システム内のバグを見つけるために、
ソフトウェア開発プロセスの欠陥を回避するために2、されます。
3、ソフトウェア、品質保証システムの品質を測定します。
図4に示すように、ユーザに注意が必要で、システムがユーザのニーズを満たしていることを確認します。
全体的な目標は次のとおりです。ソフトウェアの品質を確保するために。
XIII。その他の基本
- Vモデル
RAD（RAPアプリケーション開発、迅速なアプリケーション開発）モデル、ソフトウェアのテストとして知られているV字モデル組成物の形状、従ってVモデルによるソフトウェア開発プロセスの重要なモデルであり、Vモデルは、おおよそ以下の異なる相に分けることができますステップ：需要分析、一般的な設計、詳細設計、コーディングソフトウェア、ユニットテスト、統合テスト、システムテストと受け入れテスト。
第四に、どのようなソフトウェア製品の品質特性がありますか？
機能：適合性、正確性、相互運用性、コンプライアンス、セキュリティ。
信頼性：成熟度、耐障害性、簡単に回復。
ユーザビリティ：習得が容易、理解しやすい、使いやすい操作性。
効率性：時間特性、リソースのプロパティ。
保守性：簡単には簡単に変更、安定性、テスト容易性に、分析します。
移植性：適応性、インストールの容易さ、コンプライアンス、および簡単な代替
第五に、どのように紙コップをテストするには？
機能：水カップ水を通過する漏れない、飲料水はできません
セキュリティ：毒性や細菌のカップがありません
信頼性：異なる高さからの落下カップへの損傷の程度
移植性：異なる場所、温度やその他の環境で使用する場合はカップが正常であることができます
互換性：ジュース、白い水、アルコール、ガソリン等のカップを収容するか否か
使いやすさ：滑り止めがある場合、カップが簡単かどうかを飲むために、暑いです
ユーザーマニュアル：詳細に記載されている使用、制限、使用条件、カップのためのマニュアルを使用するかどうか
疲労試験：充填カップ上環（ケースA）放電時間24時間リークやケースをチェックする。盛ガソリン（ケースII）24時間の放電時間は漏れをチェックするなど
ストレステスト：針と針が貫通したときどのくらいの圧力を見るために、重量を超えて増加し続けます