1. ソフトウェア構成管理の役割は何ですか? ソフトウェア構成には何が含まれますか?
– ソフトウェア構成管理 (SCM) は、変更を特定、整理、および制御するための技術です。ソフトウェア構成管理は、ソフトウェア エンジニアリング プロセス全体に適用されます。ソフトウェアを構築する際には変更は避けられず、変更はプロジェクト上のソフトウェア開発者の混乱を悪化させます。SCM 活動の目標は、変更を特定し、変更を管理し、変更が正しく実装されていることを確認し、他の関係者に変更を報告することです。ある観点から見ると、SCM は、エラーを最小限に抑え、生産効率を最も効果的に向上させることを目的として、変更を識別、整理、および制御するためのテクノロジーです。 – ソフトウェア構成には、構成項目の識別、ワークスペース管理、バージョン管理、変更管理、ステータス レポート、および構成監査が含まれます
。
2. c/s モードまたは b/s モードを簡単に説明します。
C/S モード: クライアント/サーバー モード。動作原理: クライアントはサーバーにリクエストを送信し、サーバーはいくつかのメソッドを使用してリクエストを処理し、結果をクライアントに返します。
B/S構造、すなわちBrowser/Server(ブラウザ/サーバー)構造とは、主に成熟化が進むWWWブラウザ技術を活用し、ブラウザの各種スクリプト言語(VBScript、JavaScript…)やActiveX技術と組み合わせ、本来複雑な専用ソフトウェアが必要であった強力な機能を汎用ブラウザで実現し、開発コストを節約する新しいソフトウェアシステム構築技術です。
3. Webテストとアプリテストの違い
システム アーキテクチャの観点から見ると、
Web プロジェクトは通常 B/S アーキテクチャであり、ブラウザベースの
アプリ プロジェクトは C/S であり、クライアントが必要であり、ユーザーはクライアントをインストールする必要があります。
Web テストがサーバー側を更新する限り、クライアント側も同期して更新されます。アプリ プロジェクトでは、クライアントとサーバーの両方を更新する必要があります。
パフォーマンスの観点:
Web ページは主に応答時間に重点を置きます
が、アプリはトラフィック、電力、CPU、GPU、メモリなどにも注意する必要があります。
互換性の観点:
Web はブラウザーに基づいているため、ブラウザー、コンピューター ハードウェア、コンピューター システムとの互換性が高まる傾向があります。
アプリのテストは、解像度、画面サイズ、オペレーティング システム、ネットワークによって異なります。
Web テストはブラウザベースなので、インストールやアンインストールを考慮する必要はありません。
また、アプリはクライアント側であるため、インストール、更新、アンインストールをテストする必要があります。従来のインストール、アップデート、アンインストールに加えて、インストール中の中断、ネットワークの脆弱性、インストール後のインストール ファイルの削除などの異常なシナリオも考慮する必要があります。
4. 良いテストケースの鍵は何ですか?
ホワイトボックス テスト: 少ない使用例で、可能な限り多くの内部プログラム ロジックの結果をカバーします。
ブラックボックス テスト: モジュールの出力インターフェイスと入力インターフェイスをカバーする使用例はほとんどありません。最小限の使用例で、妥当な時間内に最大限の問題を発見します。
実現可能と不可能の両方を考慮します: (1) 入力 (2) 詳細な操作手順 (3) 期待される出力 (4) 実際の出力
5. ソフトウェアの品質とは何ですか?
一言で言えば、ソフトウェア品質とは「ソフトウェアが明示的および暗黙的に定義された要件にどの程度準拠しているか」です。具体的には、ソフトウェアの品質とは、ソフトウェアが明示的に記載された機能およびパフォーマンス要件、ドキュメントに明示的に記載された開発標準、および専門的に開発されたすべてのソフトウェアが持つべき暗黙の特性にソフトウェアがどの程度準拠しているかを指します。ソフトウェアの品質に影響を与える主な要因は、管理の観点からソフトウェアの品質を測定することです。ソフトウェア製品を使用する際のユーザーの 3 つの視点をそれぞれ反映する 3 つのグループに分類できます。正確性、堅牢性、効率、完全性、使いやすさ、リスク（製品の運用）、理解性、保守性、柔軟性、テスト容易性（製品の変更）、移植性、再利用性、相互運用性（製品の移行）。
6. 300 個のクライアントを持つクライアントと、サーバーに負荷をかける 300 個のクライアントを持つ 300 個のクライアントの違いは何ですか?
1 つのクライアント上に 300 人のユーザーがいると、クライアントのリソースがより多く占有され、テスト結果に影響します。スレッド間の干渉が発生し、一部の例外が発生する可能性があります。
1 つのクライアント上に 300 人のユーザーがいる場合は、より多くの帯域幅が必要です。
IP アドレスの問題の場合は、IP スプーフを使用して、単一の IP アドレスへの最大接続数に対するサーバーの制限を回避する必要がある場合があります。
すべてのユーザーは 1 つのクライアント上に存在するため、分散管理の問題を考慮する必要はありません。ユーザーが異なるクライアントに分散している間は、コントローラーを使用してユーザーを異なるクライアント全体に展開することを検討する必要があります。同時に、対応する権限構成とファイアウォール設定も与える必要があります。
7. テスト ケース、テスト スクリプトとは何ですか? 両者の関係は何ですか?
テストの実施のためにテスト対象システムに提供される、特定の入力データ、操作またはさまざまな環境設定、および期待される結果のセット。
テスト スクリプトは、自動テスト用に作成されたスクリプトです。
テスト スクリプトの記述は、対応するテスト ケースに対応する必要があります。
8. 300 個のクライアントを持つクライアントと、サーバーに負荷をかける 300 個のクライアントを持つ 300 個のクライアントの違いは何ですか?
1 つのクライアント上に 300 人のユーザーがいると、クライアントのリソースがより多く占有され、テスト結果に影響します。スレッド間の干渉が発生し、一部の例外が発生する可能性があります。
1 つのクライアント上に 300 人のユーザーがいる場合は、より多くの帯域幅が必要になります。
IP アドレスの問題の場合は、IP スプーフを使用して、単一の IP アドレスへの最大接続数に対するサーバーの制限を回避する必要がある場合があります。
すべてのユーザーは 1 つのクライアント上に存在するため、分散管理の問題を考慮する必要はありません。ユーザーが異なるクライアントに分散している間は、コントローラーを使用してユーザーを異なるクライアント全体に展開することを検討する必要があります。同時に、対応する権限構成とファイアウォール設定を与える必要もあります。
9. ウェブサイトが凍結される理由は何ですか?
理由 1: http リクエストが多すぎる
解決策: インターフェイスの設計を標準化し、http リクエストの数を減らします。
理由 2: ダウンロード リソースが大きすぎるなど、データの受信に時間がかかりすぎる
解決策: HTTP 送信を圧縮するには、gzip 可逆圧縮を使用でき、圧縮効果が最も優れています。
理由 3: JavaScript スクリプトが大きすぎるため、ページの読み込みがブロックされます。
解決策: JavaScript スクリプトをラベルの前に置きます。スクリプトに async と defer がない場合、JS ファイルはダウンロード後すぐに実行されます。この場合、スクリプトを先頭に置くとページのレンダリングがブロックされ、ネットワーク速度が遅いと「白い画面」が発生し、スクリプトがダウンロードされるまでページのレンダリングが続行されなくなります。したがって、スクリプトを下部に配置すると、ページをできるだけ早くレンダリングできます。
理由 4: CSS、JavaScript、画像などを繰り返し読み込む必要がある
解決策: 静的リソースを繰り返しダウンロードする負担を軽減するために、静的リソースは静的ドメイン名に配置されます。
理由 5: Cookie の影響
解決策: Cookie の影響を軽減します。不要な Cookie を削除するか、ページで Cookie が必要ない場合は完全に無効にします。さらに、Cookie のサイズを小さくし、適切な Cookie 有効期限を設定することによっても、Cookie の影響を弱めることができます。
理由 6: Web ページ リソースが多すぎる
解決策: CDN を使用してネットワークを展開し、ダウンロード速度を向上させます。まず、無料の CDN プロバイダーを通じて Web ページ リソースを配布します。
10. 圧力テスト中、QPS が増加できませんでした。どのようにトラブルシューティングしますか?
– テスト対象サーバーのパフォーマンスを調べて、リソースがいっぱいになってリクエストの接続に失敗していないかどうかを確認します。解決策
: テスト対象サーバーを拡張します。
– インターフェイスにエラーがあるかどうか、および応答時間が遅いかどうかを確認します。
解決策: インターフェイスのパフォーマンスの最適化。
– ストレス テスト マシンのパフォーマンスをチェックして、ネットワーク IO がいっぱいで同時実行数に達していないかどうかを確認します
解決策: 複数のストレス テスト マシンを同時に実行します。
– ストレス テスト ツールが同時リクエストをサポートしているかどうかを確認する
解決策: マルチスレッドまたはコルーチンを使用して同時リクエストを行う
11. 10% のユーザーがこの機能が使用できないと報告しています。トラブルシューティングはどのように行っていますか?
–APP バージョンの影響、インターフェースの変更がバージョン管理を考慮していない可能性があり、下位バージョンのユーザーに影響
–OS バージョン、ユーザーのオペレーティング システムが高すぎるか低すぎ、互換性がない可能性があります –グレー テストまたは AB テスト、一部のグレー ユーザーに影響を与える機能上の欠陥である可能性が
あり
ます
。
12. APP により、ネットワークに接続できないというメッセージが表示されます。どのようにトラブルシューティングしますか?
ステップ 1: ネットワーク環境を確認する
4G と Wifi が利用可能かどうかを確認します。まず、モバイル ネットワーク接続アイコンのステータス、信号があるかどうか、ネットワークが弱いかどうかを確認し、他のアプリに切り替えてネットワークが利用可能かどうかをテストできます。
会社のイントラネットでのみ利用可能なアプリがあり、他のネットワーク環境では接続できないなど、ネットワーク制限がないか確認してください。
プロキシに接続されているか、またはプロキシ接続が異常ではないかを確認してください 携帯電話をコンピュータのプロキシに接続した後、証明書がインストールされていない場合、HTTPS リクエストは異常となります。
ステップ 2: APP のネットワーク要求を確認します。
パケットをキャプチャし、APP によって要求されたドメイン名が正しいかどうかを確認します。パケットをキャプチャし、バックエンド インターフェイスがタイムアウトで応答するかどうかを確認します
。
13. WeChat のいいね機能をテストするにはどうすればよいですか?
機能テスト
1. いいね後、いいねの数が +1 され、いいねした人のアバターがいいねの青色で表示されます 2. いいね後、共通の友達はいいねエリアでいいねした人を見ることができるようになります 3. いいね後、共通の友達以外の友達はいいねしたエリアでいいねした人を見ることが
できなく
なります
6. 初めていいねをした場合、ユーザーに通知、いいねをキャンセル、その後いいねをした場合、ユーザーに通知しない いいねする前に普通にコメントできるか 15. いいねした後にコメントできるか 16. 繰り返しいいね、いいね
をキャンセル、
機能が正常か
APPテスト
1. 弱いネットワークテスト、弱いネットワーク条件下でリアルタイムにいいねが更新されるかどうか
2. いいねをするときに干渉（電話やテキストメッセージ）がある場合、いいねが表示されるかどうか
3. 消費電力とトラフィックが正常かどうか
パフォーマンステスト
1. 多数のユーザーが同時にいいね、インターフェースの応答時間、最大 QPS
2. 多数のユーザーが同時にいいね、現時点でのインターフェースは好き、機能が正常かどうか
互換性テスト
1. さまざまな携帯電話モデル、oppo モバイル バージョンと Netcom
2. さまざまな携帯電話バージョン、OPPO r7、r10 ios 7、8
3. さまざまなシステム、Android、iOS
UIテスト1. UIマップに従い、
表示位置、色、アイコン、フォントが正常に表示されるか 2.
いいねが表示されない場合
、灰色で表示されるか