11. 入力ボックス、テストケースの書き方は?
文字入力ボックス
1. 文字入力ボックス：全角英語、半角英語、数字、空またはスペース、特殊文字「~!@#￥%...&*?[]{}」はシングルクォーテーションマークに注意してください。 & 記号。特殊文字の直接入力が禁止されている場合は、「貼り付け、コピー」機能を使用して入力してください。
2. 長さチェック: 最小長、最大長、最小長-1、最大長+1、入力された長すぎる文字。
3. スペースチェック: 入力文字の間にスペースがあり、文字の前にスペースがあり、文字の後にスペースがあり、文字の前後にスペースがあります。
4. 複数行のテキストボックス入力：キャリッジリターンとラインフィードを許可し、保存後、入力を保存できる形式を表示し、キャリッジリターンとラインフィードのみを入力し、正しく保存できるかどうかを確認します（はいの場合は、保存された内容を確認します）結果がそうでない場合は、通常のプロンプトがあるかどうかを確認します)。
5. セキュリティチェック: 特殊文字列入力 (null,NULL, ,javascript,<script>,</script>,<title>,<html>,<td>)、スクリプト関数入力 (<script>alert(“abc”) )</script>)、doucment.write("abc")、<b>こんにちは</b>)。
数値入力ボックス
1. 境界値：最大値、最小値、最大値+1、最小値-1
2.桁数：最小桁、最大桁、最小桁-1、最大桁+1、入力超ロング値
3. 異常な値、特殊文字：空白（NULL）、スペース、または「~!@#$%^&*()_+{}|[]\:"<>?;',./?;:'」を入力してください。 -= などのシステムエラーを引き起こす可能性のある文字、特殊文字の直接入力が禁止されている場合は、コピー貼り付けを使用して正常に送信できるか確認してください。Word の特殊機能、クリップボード経由で入力ボックスにコピー、ページブレーク、セクション区切りは数式に似ています。下付き文字、添え字など、∑、㏒、㏑、∏、+、-などの値の特殊記号、負の整数、負の小数、分数、文字または文字を入力します。漢字、小数点（小数点以下の0を切り捨てた場合、小数点以下複数桁の場合）、01、02など最初の1桁が0の数字、科学的表記法が1.0E2をサポートしているかどうか、全角数字と半角数字数値、混合数字と文字、16 進数、8 進数値、通貨入力 (小数点以下の数桁を許可) ビット)。
4. セキュリティチェック：直接入力しない場合はコピー
日付入力ボックス
1. 合法性チェック：（0日、1日、32日を入力）、月入力[1、3、5、7、8、10、12]、日入力[31]、月入力[4、6、9、 11]、日入力[30][31]、閏年以外の入力、月入力[2]、日付入力[28、29]、閏年入力、月入力[2]、日付入力[29、30]、月入力 [0、1、12、13]
2. 異常な値、特殊文字: 空白または NULL を入力、~! を入力 @#￥%...&*(){}[] およびシステムエラーを引き起こす可能性のあるその他の文字
3. セキュリティチェック：直接入力できない場合は、データ検査でエラーがないかコピーするだけ
重複した情報
名前を付ける必要があり、その名前は一意である必要がある一部の情報では、名前または ID を繰り返し入力して、システムがそれを処理するかどうか、エラーが報告されるかどうか、重複した名前に大文字と小文字の区別があるかどうかを確認します。入力内容の前後にスペースを入力すると、システムは正しく処理します。
入力ボックスのキャッシュ
前回入力後に送信した後、再度開くと前回入力した内容がキャッシュされます。
12. テスト ケースの設計にはどのような方法を使用しましたか?
同値クラス、境界値、デシジョンテーブル、シナリオ手法、状態遷移図、エラー推測手法。
13. ZenTao はどのようにバグを管理しますか?
ZenTao での欠陥処理の基本プロセスは、テスト送信バグ => 開発確認バグ => 開発バグ解決解決 => テスト検証バグ => テストクローズバグです。
バグ検証が失敗した場合は、バグ検証をアクティブにすることができます。テスト送信バグ => 開発確認バグ => 開発解決バグ => テスト検証バグ => テスト アクティブ化バグ => 開発解決バグ => テスト検証 => テスト終了。
もう 1 つのプロセスは、バグが解決された後に再びバグが発生することです。バグを送信するためのテスト => バグを確認するための開発 => バグを解決するための開発 => バグを検証するためのテスト => バグを閉じるためのテスト => バグをアクティブにするためのテスト => バグを解決するための開発 => 検証するためのテスト => バグを解決するためのテスト。
14. バグかどうかの判断方法は？
1. まず第一に、誤操作や環境設定の問題など、個人的な理由によって引き起こされる問題を排除する必要があります。
2. 次に、要件文書がある場合は、要件文書を確認しますが、明確な要件があるかどうかは、主に次の観点から検討されます。
1) ソフトウェアが製品マニュアルに示されている機能を満たしていない場合。
2) ソフトウェアに、製品マニュアルでは発生しないと示されているエラーがある。
3) ソフトウェアの機能が製品マニュアルに定められた範囲を超える場合。
4) 製品マニュアルに明記されていないにもかかわらず、ソフトウェアが達成すべき目標を達成できない場合。
5) ソフトウェア テスターは、ソフトウェアが理解しにくい、使いにくい、実行が遅い、またはエンド ユーザーにとって悪いと考えています。
3. 要件ドキュメントがない場合は、プロダクト マネージャーまたは開発者に連絡してバグかどうかを判断できます。
4. 合意できない問題については、関係者による会議を開催し、共同でバグかどうかを決定することができます。