世界を作るのが好きな人もいれば、開発者です。開発者が好きな人もいれば、テスターです。ソフトウェアテストとは何ですか？ソフトウェアテストでは、ユーザーの前で発生するはずの災害が事前に発生したため、救世主のように感じられ、ユーザーを救い、ソフトウェアを保存し、アンインストールの運命を回避します。
プロジェクトのテストプロセス
-
要件ドキュメントを入手したら、テストケースを作成します
-
テストケースを確認する
-
開発キットを待っています
-
展開テスト環境
-
スモークテスト（Webページのアーキテクチャ図）
-
ページ初期化テスト（データベース内のデータコンテンツとページに表示されるコンテンツが一致しているかどうか、およびそれらが特定の順序で配置されているかどうかを確認します）
7.特定の実行テストケース（ほとんどすべての機能テスト、プロセスメソッド、シナリオメソッド）
-
欠陥が見つかった場合は、欠陥フォームに記入してください
-
非機能テスト（SQL、jsインジェクション、ページ効率、js検証のバイパス、データベースへの直接データの追加）
-
最終テストレポートを書く
テストケースの設計方法
同値類、境界値、直交実験法、状態遷移法、因果関係図、シナリオテスト法、異常分析法、因果関係図、誤差推測法、判定表
テストケースの要素
IDサブジェクトテスト名作成日デザイナーの説明ステップ名ステップの説明期待される結果の実行ステータス
テストの優先順位
-
最初に変更されたパーツをテストし、次に変更されていないパーツをテストします
-
最初にプログラムのコア機能をテストし、次に一般的な機能をテストします
-
最初に論理関数をテストし、次にビジネス関数をテストします
-
最初に正常な状態をテストし、次に異常な状態をテストします
-
最初に機能をテストし、次にパフォーマンスをテストします
テストレポートに含まれるもの
1.テストの背景を書く
2.テストの目的
3.テスト範囲
4.テスト環境
5.テストデータ
6.テスト基準（強調）
7.テストの進捗状況
8.テスト結果
9.テストの結論
一部の企業は非標準のテストレポートを使用します
おおよそ、テストに費やした時間、テスト環境、テストでテスターによって発見されたバグの数、修正されたバグの数、残りのバグの数、残りのバグの原因が含まれます
試験結果等
夢は予定通りに来ると信じてください。
道に迷ったら、もっと難しい道を選んでください。
心の中に目標や夢があるときは、恐れずに勇気を出して試してみてください。諦めやすく、心の熱意を一掃するのも簡単です。でも、頑張れば、別の自己。人生は別のものです。帰りに、自分にチャンスを与えてみませんか。
成功する人は皆、これからもたくさんの励ましを受け、他の人も喜んで励ましてくれます。励ましが私にもたらす助けを深く感じています。あなたが好きなときはいつでも、それはあなたの最大のサポートです。私は常により良くすることを主張します。コンテンツ。
バグのライフサイクル
送信-開発検証-承認-拒否-開発ソリューション-テスター検証-クローズ-オープンに失敗
バグステータス
-
NEW：開発ドッキングステータスに送信されたすべての問題はNEWです。つまり、処理されません。
-
OPEN：開発ドッキング担当者の最初の判断は、問題を転送する必要があり、テスターと開発者が指定され、ステータスがOPENであるというものです。
-
REFUSE：開発ドッカーは、問題を次のリンクに転送する必要はないと判断し、ステータスはREFUSEであり、理由が入力されています。
-
修正済み：開発者は修復を完了し、テストを保留しており、ステータスは修正済みです
-
REOPEN：テスト部門は、開発者に対するテスターの修復結果に合格し、ステータスはREOPENです。
-
閉じる：テスターは、問題が要求またはその他の問題であると判断し、理由を入力する必要があります。
欠陥の要素
欠陥タイトル欠陥ステータス提出者担当者優先度重大度欠陥説明時間スクリーンショット
欠陥レベル
致命的な問題：コア機能が使用できないか、システムがクラッシュします
重大な問題メインビジネスプロセスが使用できず、メインビジネスプロセスの機能に欠陥があり、メインプロセスの使用を継続できません。
一般的な問題一般的な問題、非メインプロセスの機能上の欠陥
マイナーな問題インターフェイスUIの問題プロンプトは標準化されていません。
提案された質問は、あなた自身の経験に基づいていくつかの示唆的な質問をします
WEBテストとAPPテストの違い
- アーキテクチャが異なります。
Web側はb / sアーキテクチャに基づいており、b / sアーキテクチャはブラウザアドレスに基づいてアクセスされます
アプリ側はc / sアーキテクチャであり、c / sアーキテクチャにはキャリアとしてのクライアントが必要です
- バージョンリリースの方法とプロセスは異なります。
Web版がリリースされ、新しいコードが開発され、対応するサーバーアドレスにデプロイされ、Web側の更新を均一に実現できます。
アプリのバージョン、開発はパッケージ化する必要があります（apkパッケージとipaパッケージ）、パッケージ化後、対応するチャネルに公開する必要があります
- 互換性
Web、さまざまなブラウザ（つまり、chrome、firefox、360、QQ）の互換性をテストします
アプリ、さまざまな解像度、画面サイズ、電話のブランド、システムバージョンをテストします
- パフォーマンスの側面
Web、テスト応答時間
アプリ、テスト応答時間、トラフィック、消費電力、CPU、GPU、メモリ
- 安全性
ウェブ、SQLインジェクション。xss攻撃など
アプリ、https暗号化、署名、強化、パスワード暗号化など。
6.アプリのテスト機能
適合性試験
ネットワークテスト
オンラインアップグレードテスト
割り込みテスト
消費電力テスト
弱いネットワークテスト
インストールとアンインストールのテスト
フローテスト
ソフトウェアテストに興味があり、テストの知識、テストの問題の解決、およびテストで遭遇するパズルの解決に役立つガイダンスの開始について詳しく知りたい場合は、ここに技術専門家がいます。仕事を探している、学校を卒業したばかり、またはすでに働いているが難しいと感じることが多い場合は、テストで十分に学んでいないと感じ、転職したい場合は学び続けたいと考えています。 、
グループの1079636098に参加できます。Pythonの自動化、インターフェイス、フレームワーク構築のための最新のソフトウェアテストインタビュー資料と学習資料を受け取ることができます。
アプリテストの主な内容
- 機能テスト
ビジネスロジックの正当性テスト
- 互換性テスト
システムバージョン
解決
開発者がバグをバグではないと判断した場合の対処方法
一般的なLinuxコマンド
どのような状況で要素を見つけることができないか
GETリクエストとPOSTリクエストの違い
ネットワークの状況
- 異常テスト
ホットスタート
ネットワークスイッチ
電話情報端末復旧
-
アップグレード、インストール、アンインストール
-
堅牢性テスト
携帯電話のリソース消費
データ消費
バッテリーテスト
クラッシュリカバリ
開発者がバグをバグではないと判断した場合の対処方法
-
問題を欠陥管理データベースに送信して記録します。
-
判断の根拠と基準を得る
要件仕様書、製品説明書、設計書などに従って、実際の結果が計画と矛盾していないかどうかを確認し、欠陥を確認するための直接的な基礎を提供します。
文書の根拠がない場合は、同様のソフトウェアの一般的な特性に基づいて不整合があるかどうかを説明し、それが欠陥であるかどうかを確認できます。
ユーザーの一般的な使用習慣に従って、それが欠陥であるかどうかを確認します。
設計者、開発者、顧客担当者、およびその他の関係者と話し合い、それが欠陥であるかどうかを確認します。
-
合理的な発言をし、あなたの判断の理由をテストマネージャーに説明し、客観的で、厳密で、個人的な感情と混ざらないようにします。
-
テストマネージャーが最終決定を下すのを待ちます。それでも紛争が発生する場合は、会社の方針で提供されているチャネルを通じて上司に報告し、上司が決定を下すことができます。
一般的なLinuxコマンド
-
ifconfigビューのIPアドレス
-
catは、指定されたファイルの内容全体を表示するために使用されます
-
moreは、指定されたファイルの内容をページネーションの形式で表示します
-
mkdir作成ディレクトリ
-
タッチして新しいファイルを作成します
-
grepは、ファイル内で修飾された文字列を検索します
-
検索指定されたファイルを検索
-
tail -fは、表示ファイルの後にN行のデータコンテンツを自動的に更新するために使用されます
-
-9強制終了を殺す
-
netstat -anp | grepポート番号ビューポート
-
chmod -R777は777パーミッションを与えます
どのような状況で要素を見つけることができないか
-
不正なコード
-
要素が表示されない（要素を待つ必要がある）
-
iframeの要素
-
マルチウィンドウ
-
ポップアップウィンドウが表示されます（システムポップアップウィンドウ、JSポップアップウィンドウ）
-
要素の属性値は動的に読み込まれます
-
要素を一意にすることはできません
-
読み取り専用属性（要素は操作できません）
GETリクエストとPOSTリクエストの違い
-
GETはURLまたはCookieを使用してパラメーターを渡し、POSTはデータをBODYに配置します
-
GET URLには長さの制限があり、POSTデータは非常に大きくなる可能性があります
-
POSTはアドレスバーに表示されないため、GETよりも安全です。
-
通常、GETはデータの取得に使用され、POSTはデータの送信に使用されます
なぜインターフェーステストを行うのですか
-
BUGが低いほど、修理コストは低くなります。
-
フロントエンドが変更された場合、バックエンドインターフェイスを変更する必要はありません
-
システムのセキュリティと安定性を確認してください。フロントエンドパラメータが信頼できません。
インターフェイステストはどのように行われますか
–プロジェクトのフロントエンドとバックエンドの呼び出しは主にhttpプロトコルインターフェイスに基づいているため、インターフェイスのテストは主にツールまたはコードを介したhttpリクエストの送受信をシミュレートすることです。postman、jmeter、soupUIなどの多くのツールがあります。
–これは、コードによって実現されるインターフェイスの自動化によっても実現できます。フレームワークはUIオートメーションに似ています。要求の送信は、アサーションによって判断されます。
インターフェイステストの要点
-
インターフェイスから返されるデータが期待される結果と一致しているかどうかを確認します
-
インターフェイスのフォールトトレランスを確認し、渡されたタイプが間違っている場合に処理できるかどうかを確認します
-
インターフェーステストの境界値
-
インターフェイスのパフォーマンス
-
インターフェイスのセキュリティ
httpステータスコード
-
1xx：要求は正常ですが、応答がありません。実験状態でのみ使用できます。
-
2xx：2の始まりは、送信が成功したことを意味します
-
3xx：3はリダイレクトを表し、一般的な302
-
4xx：400はクライアントから送信された文法が正しくないことを意味し、401はアクセスされたページが許可されていないことを意味し、403はWebページへのアクセスが許可されていないことを意味し、404はそのようなページがないことを意味し、415はフォーマットエラーです。
-
5xx：5の先頭はサーバー例外を表し、500はサーバー内部例外を表し、504はサーバータイムアウトを表します
クッキーとセッションの違い
-
Cookieデータはクライアントのブラウザに保存され、セッションデータはサーバーに保存されます
-
Cookieはあまり安全ではありません。他のユーザーは、ローカルに保存されているCookieを分析し、Cookieのなりすましを実行できます。セキュリティを考慮して、セッションを使用する必要があります。
-
セッションは一定期間サーバーに保存されます。訪問数が増えると、セッションはより占有されます。サーバーのパフォーマンスを考慮すると、サーバーのパフォーマンスを下げるためにCookieを使用する必要があります。
一般的に使用されるadbコマンド
-
adb start-server start adb service
-
adb kill-server close adb service
-
adbデバイスはデバイス番号を表示します
-
adbプッシュコンピュータ電話
-
adbプルモバイルコンピューター
-
adb logcat | grep包名（unix）
-
adb logcat | findstr包名（win）
-
adbshellシェルコマンドラインに入る
-
adbinstall電話にアプリをインストールします
-
adbアンインストールアンインストールアプリを電話に
-
adblogcat>ファイル名出力ログをファイルに
-
adb shell top testappリソース消費コマンド
製品のビジネスプロセス
構文解析
履歴書に書かれたプロジェクトの全体的なビジネスプロセスを尋ねる
たとえば、eコマースプロジェクトの登録機能、登録から登録の成功までのプロセス全体
オンライン基準を満たすバージョンは何ですか
合否基準
（1）ソフトウェア要求分析仕様で定義されているすべての機能が完全に実現されており、すべてのパフォーマンス指標が要件に達している。
（2）検収試験で見つかったエラーが修正され、すべてのレベルでの欠陥修復率が標準に達しました。
（3）すべてのテスト項目には、緊急または重大なレベルのエラーが残っていません。
（4）要求分析文書、設計文書、およびコーディングは一貫しています。
（5）完全な受け入れテスト成果物（テスト計画、テストケース、テストログ、テスト通知、テスト分析レポート、受け入れられるソフトウェアインストールプロセス）
シーケンス。）
欠陥修理率基準
（1）緊急および重大レベルのエラー修復率は100％に達する必要があります。
（2）通常レベルのエラー修復率は95％以上である必要があります。
（3）最適化レベルのエラー修復率は60％以上に達する必要があります。
注：プロジェクトが緊急の場合、通常レベルのエラー修復率は60％以上に達し、最適化されたレベルのエラー修復率は20％に達します。
サーバーの動作ステータス応答インジケーター
（1）同時実行期間中のcpu％の最大使用率は70〜80％を超えてはなりません。ランデブー同時実行がある場合は、短時間で100＆に近づくか、到達することができますが、ほとんどの場合
95％をチェックする必要があります。
（2）メモリテスト中に、メモリが十分であり、使用可能なメモリが20％以上であることを確認します。
（3）ディスクは、ハードディスクの読み取りと書き込みが40％以下であるかどうかを監視します。
（4）CPU負荷平均は、CPUコア数* 2を超えない、またはCPUコア数を超えないようにしてください。
テストケースレビュープロセスと関連する参加者
1：レビュープロセス
A：開始する前に次の準備をしてください
1.レビューの理由を特定します
2.レビューの時間を決定します
3.参加者を決定します
4.レビューの内容を明確にする
5.レビュー基準の終了を決定します
6.少なくとも1日前に、レビュー対象のコンテンツがレビュー会議の関係者にメールで送信されます。また、詳細なレビューの時間と場所、および補償に関与した人物を示してください。
7.電子メールで、レビュー会議の関係者にレビューの内容を少なくとも1回読んでもらい、関連する質問を記録して、レビュー会議で提起できるようにします。
8.会議の主催者（通常はユースケースの作成者）は、会議の前に関連する質問を整理して、会議で提起できるようにする必要があります。
B：レビューを開始する
1.レビューミーティングを開催します。参加者は、デザイナーの説明の後にコメントや提案をすると同時に、詳細なレビュー記録を行いました。
2.一般郵便で関係者と連絡する
3.一般的なIMツールは関連する担当者と直接通信します
4.レビューの内容に応じてレビューする
2：コンテンツを確認する
1.ユースケース設計の構造が明確で合理的であるかどうか、およびそれが要件の効率的なカバレッジに役立つかどうか。
2.優先順位の取り決めが合理的かどうか。
3.テスト要件のすべてのファンクションポイントをカバーするかどうか。
4.ユースケースが適切に実行可能かどうか。たとえば、ユースケースの前提条件、実行ステップ、入力データ、および期待される結果が明確で正しいかどうか、期待される結果の明確な検証方法があるかどうかなどです。
5.冗長なユースケースは削除されましたか？
6.十分なネガティブテストケースが含まれていますか？完全に定義すると、ここで2＆8ルールを使用すると、ポジティブユースケースの数の4倍になります。結局のところ、堅牢なソフトウェアであるコードの80％は、関数実装の20％を「保護」することです。
7.ユーザーの使用シナリオと使用プロセスのテストケースをユーザーレベルから設計するかどうか。
8.簡潔で再利用可能かどうか。たとえば、反復性の高いステップまたはプロセスを抽出して、再利用可能な標準ステップとして定義できます。
3：参加しているレビューア（ここではレビューのために複数のレベルに分けられます）
1.部門レビュー、テスト部門のすべてのメンバーが関与するレビュー。
2.プロジェクトマネージャー、要件アナリスト、アーキテクチャデザイナー、開発者、テスターを含む会社のレビュー。
3.顧客側の開発者とテスターを含む顧客レビュー。この状況は、アウトソーシング企業でより一般的です
やっと：
あなたと私が会い、あなたが何かを見つけることができますように！WeChatパブリックアカウントのフォローへようこそ：プログラマーYifan
1.216ページのソフトウェアテストエンジニアのインタビューブックを無料で受け取ります。
2.ソフトウェアテストの学習ルートと対応するビデオ学習チュートリアルは無料で共有できます。