序文
正直に言うと、私はプロジェクトを探す過程で N 個以上のプロジェクトをダウンロードし (ダウンロードにお金を払ってまで)、多くのプロジェクトの作者に連絡を取りましたが、私の意見では、ほとんどのプロジェクトは実践には適していません。
1. ほとんどのプロジェクトは Web プロジェクトであり、アプリ プロジェクト、特にアプリ インストール パッケージを含むほとんどのプロジェクトを見つけるのが困難です。
2. アプリプロジェクトにはフロントエンドコードのみがあり、バックエンドサービスコードはありません。「ユーザー」としてのみ練習できます。
3. アプリ インストール パッケージを使用するほとんどのプロジェクトでは、プロジェクト作成者が試用版アプリを提供するため、個人のプライバシーやアカウントのセキュリティなどを保証することが困難になります。
4. ほとんどのプロジェクトには導入ガイドがなく、途方に暮れているようです
5. 一部のプロジェクトはビジネスを伴うため、決済、ブロックチェーン、通貨など、ビジネス基盤が不足している場合は開始することが困難です。
6. 複数の用途をカバーできる統合プロジェクトがほとんどない
皆さんも学習の過程でこうした問題に遭遇したことがあると思いますが、解決するのは困難です。
でも心配しないでください、私がしっかりカバーします！
何百ものプロジェクトを閲覧し、自分で 10 以上のプロジェクトを構築した後、最終的に、読者やファンにとって非常に適した、非常に包括的なソフトウェア テスト プロジェクトを選択しました。
これでもうこんな募集に悩まなくて済みますよ～
1. プロジェクト紹介
関連するテクノロジー
フロントエンド: HTML CSS JS/JQ (Bootstrap、node.js、angluar.js などが理解可能) AJAX
PHP : PHP+MySQL セッションとクッキー Nosql (redis memcache mongdb) インターフェース技術 キャッシュ技術 最適化技術 など
サーバー側：Linux Nginx
開発環境: LNMP などに加えて、WAMP または LAMP が一般的です。
履歴書や面接ではバージョン番号を記載しないようにしてください。バージョン番号を書きたい場合はバージョン番号を揃える必要があり、そうでない場合はバージョン番号を書かないでください。
電子商取引プロジェクトの技術的な特徴は何ですか?
1. テクノロジーは迅速に更新されます。市場のニーズに応じて、常に反復的に更新されます。
2. テクノロジーには広範囲が含まれます: PHP に加えて、Python、GO などの言語も使用され、データベースでは MySQL と nosql が最も頻繁に使用され (もちろん、Oracle を使用する企業もありますが、PHP は一般的に MySQL に基づいています)、サーバーでは Linux が使用され (Unix を使用する企業もいくつかあります)、サーバー セキュリティ、システム セキュリティ、その他のセキュリティ テクノロジが含まれることがよくあります。
3. 分散: 以前は 1 台のマシンで実行されていましたが、現在は複数のマシンに分散され、最終的にデータがまとめられます。集中型から分散型への開発は需要によって推進されます。
4. 高同時実行性、クラスター (高可用性クラスター)、およびロード バランシング: 同時実行性の問題はクラスターによって処理されますが、そのうちクラスターではサーバーのマスター/スレーブと分散に関する問題が発生し、ロード バランシングが使用されます。(高比重と低比重) 高可用性とは、ユーザーにとって、ユーザーのサービスが中断されないことを意味します (システムのアップグレード、サービスが中断されない、企業の電子商取引システムの一部が更新されるなど)。
5. 大量のデータ: 毎年、加盟店のさまざまな活動 (ダブル 11、ダブル 12 など) の注文量、閲覧数、商品量、イベント関連データが非常に大きくなります (通常、高い同時実行性を伴います)。
6. 複雑なビジネス: 電子商取引のビジネスは、商品が表示された後、ショッピングカートに追加するだけで購入が完了する単純なものではありません。さらに、バックグラウンドのビジネス ロジックは、割引 (送料無料、全額割引)、フラッシュ セール、スナップアップなど、非常に複雑です。
7. システムセキュリティ: システムをオンラインにする際にはシステムセキュリティ部門の承認が必要ですが、セキュリティの問題は徐々に俎上に上るようになっており、多くの企業がこの分野を非常に重視しています。
システム機能
このモール システムは、京東モールや天猫モールと同様の総合的な B2C プラットフォームです。
ユーザー
1. ユーザーはモールに会員登録し、モールにログインすることができます。
2. 会員レベルに応じた特典や特典を獲得
3. ユーザーは製品を閲覧し、製品タイプに応じて検索できます
4. 利用者はショッピングカートの操作（商品の追加、削除、変更、数量、商品詳細の確認等）ができます。
5. ユーザーは、注文の発注、注文の引き出し、注文の決済などを行います。
商人
1. 加盟店はモールに定住し、モール内に出店して自社商品を販売できる
2. 加盟店にも加盟店レベルがあり、モール内で良い評価を得たり、商品の販売量が一定以上になると、加盟店の特典を得ることができます
3. 販売者は、自分の店舗の商品を管理できます: 棚の出し入れ、在庫の設定、自分の店舗の会員システムの設定など。
eコマースプロジェクトのマインドマップ
上記は一般的に使用されるモジュールのほとんどです。他のモジュールがある場合は、それら自体で補完されます。上の図のアーキテクチャによれば、帰納的記憶はプロジェクト-モジュール-機能から層ごとに実行され、少しずつ記憶に慣れ、理解することができます。
プロジェクトチームの構成
プロダクトマネージャー：1名、要件を決定し、製品のプロトタイプを渡します。
プロジェクトマネージャー：1名、プロジェクト管理。
UIデザイン：1名、プロジェクトのプロトタイプレンダリングを作成。
フロントエンドチーム：1名、プロダクトマネージャーから渡されたプロトタイプをもとに静的ページを作成。
バックエンドチーム：3名で製品の機能を実現します。
運用保守：自社運用保守プロジェクトのシステム責任者1名。
テストチーム: 2 人ですべての機能をテストします。（中小企業は試験を行いません）
上記はチームを単位としたものですが、企業によっては複数の技術チームのほか、運用保守、UI、インタラクションデザイナーなどを状況に応じて配置している場合もあります。
プロジェクト開発プロセス
2. EC面接に関するよくある質問
1. 最近のプロジェクトの背景と簡単な紹介をお願いします。(この質問では、少なくともこのプロジェクトがどのような種類の企業または業界を対象としているのかを明確にしてから、このプロジェクトの基本的な機能モジュールを紹介する必要があります。) あなたが担当するモジュールは何ですか? あなたが担当するモジュールの機能は何ですか?
当社はかつて実店舗、卸売、小売りを主力としており、比較的伝統的なビジネスでした。一方で、市場の需要に適応し、企業の競争力を強化し、業績を向上させるために、インターネットをベースとしたビジネスモデル革新の基盤も築きます。そこで私は、商品管理、注文管理、カテゴリ管理、顧客管理、パートナー管理、顧客サービス管理、ショッピングプラットフォーム、コンテンツ管理などを含むxxxモール構築プロジェクトを開始しました。これにより、労働のプレッシャーを大幅に共有し、顧客サービスの効率と顧客満足度の向上においてより良い役割を果たすことができます。(最初にプロジェクト全体について説明し、次に最もよく知っているモジュールを 1 つまたは 2 つ選択して説明します)
2. プロジェクトの全体構成（フレームワークと具体的な技術）
フレームワーク: 一般的な観点から説明します。たとえば、このプロジェクトは e コマース プロジェクトであり、TP フレームワークを使用し、開発には php+MySQL+Apache を使用します。TP フレームワークはオープンソースで軽量であるため、より便利ですぐに使用でき、効率とコストの点で比較的コスト効率が高いため、チームは当時、このフレームワークを開発に使用することを決定しました。次に、面接官がこのフレームワークのテクノロジをよく知っていると感じられるように、フレームワークの利点と特徴を説明します。テクノロジを説明するときは、よく知っているモジュール (登録検証、定期的なマッチング、Ajax のリフレッシュなし検証などで使用される JS テクノロジなど) から始めて、徐々に他のテクノロジに広げていきます。
3. あなたのプロジェクトには何人で取り組んでいますか? どこまで開発するのか？どれくらいテストするのですか？どのような建築でしょうか？
約20名、開発10名、テスト3名、UIテスト2名、運用保守2名、B/Sアーキテクチャとアプリ2名
4. B/S アーキテクチャのシステムはどのような点からテストする必要がありますか?
機能: リンクテスト、ナビゲーションメニュー、ページジャンプ、フォームテスト、データテスト、ビジネスロジックテスト
互換性：お客様がよく使用するブラウザを確認し、IE、Firefox、Googleとの互換性テストを実施
インターフェース: フォントの色サイズ、アイコンとフィールドの間隔など。
パフォーマンス: 接続速度、負荷テスト、ストレステスト
セキュリティ: 権限制御、リンクのカプセル化、ログ記録テスト、ログイン暗号文、パスワード変更後の再ログイン、ログイン有効期限。
5. 従来のアーキテクチャの利点と比較した分散アーキテクチャ。
①最も明白な点は、従来のアーキテクチャでは、特定の機能を維持する必要がある場合、サービス全体を停止する必要があり、企業の運営に損失が生じるということです。分散システムでは、コア機能モジュールに別のサーバーが使用され、一部のモジュールの保守がユーザーの他の操作に影響を与えることはありません。
②大量データ処理の点では、従来のアーキテクチャは比較的弱いですが、分散システムアーキテクチャはサーバークラスタと負荷分散を採用しており、大量データ処理が容易です。
③ パフォーマンス (取得) とメンテナンスの点でも、分散システム アーキテクチャには明らかな利点があります。
6. プロジェクトに分割されるモジュールの数、どのモジュールを担当するか、およびこれらのモジュールにどのようなテスト テクノロジーを使用するか
プロジェクト内の関連機能の開発を主に担当します。主に以下が含まれます。
バックグラウンド管理システム：主に商品管理、商品仕様パラメータ管理、注文管理、会員管理など、CMS（コンテンツ管理システム）などを実現し、クロスドメインサポートを提供します。
フロントエンド システム: 主にユーザー アクセス用。フロントエンドとバックエンドのデータ対話には js と ajax を使用します (通常、データは json 形式で返されます)。
会員ログイン：ユーザー登録、問い合わせ等のユーザー情報に関わるインターフェースを提供（ログイン時には複数の認証が必要となり、セキュリティ面には特に注意が必要です）
注文機能：主に注文に関するビジネスインターフェースを提供する注文システムでは、厳格なデータ検証と高同時書き込みサポートが実装されており（ここではキューによって実装されていると言えます）、タイムアウト後に支払われない注文をクローズするなど、タイマーを使用した注文時間の制御が行われます。
検索機能: 主に製品検索を提供するために、Sphinx 全文検索を使用できます。もちろん、他の検索方法もあります。
会員システム：主にユーザー情報、購入注文、クーポン、システムメッセージの管理、パスワードの変更、携帯電話のバインド、その他の機能を目的としています。
キャッシュ: 主に Redis で実装され、Redis サービスの高可用性を確保するために Redis 用にクラスターが作成されます (redis 以外のキャッシュには memcached も使用されます)
支払いシステム: 主に注文の支払い、口座調整およびその他の機能を担当し、主に Alipay のインターフェースに接続されています。
個人の実際の状況に応じて最も身近なモジュールを選択し、物語を作成します
7. あなたのプロジェクトでどのようなテスト技術が使用されていますか。面接官はこの技術について尋ねます。
8. このプロジェクト用に作成されたテスト ケースの数、実行にかかる時間、見つかったバグの数
9. このプロジェクトで最も印象的なバグは何ですか?また、後でそれを解決する方法は何ですか?
10. プロジェクトはオンラインですか? オンラインであればどこで見ることができますか?そうでない場合は、なぜですか?
11. プロジェクトの特定のモジュールのテスト ケースをどのように設計しますか?またその理由は何ですか?
12. このプロジェクトで使用されるデータベースは何ですか?また、テーブルはいくつ設計されていますか?
13. このプロジェクトには繰り返しが行われていますか? ある場合、反復方法と反復後のテスト方法
14. このプロジェクトでは自動テストを使用していますか? 自動テスト スクリプトはどの言語で書かれているか、またどのモジュールが自動テストを使用しているか
15. プロジェクト サイクル。このプロジェクトにどれくらいの期間取り組んでいるか、いつテストが介入したかを尋ねられます。
16. トラフィックが多い Web サイトの場合、トラフィックの問題を解決するためにどのような方法を使用しますか?
17. SQL ステートメントの最適化?
18. 静的ページとは何ですか?
19. ユーザーの安全なログインを実現するにはどうすればよいですか?
20. Redis には永続化メソッドがいくつありますか? redisの欠点は何ですか?
21. 高い同時実行性にどう対処するか?
スペースの都合上、すべてを表示することはできませんが、上記のインタビューの質問に対する回答は、メッセージを残すことでご覧いただけます
3. 機能要件の説明
ログイン機能をテストするにはどうすればよいですか?
1. 正しいユーザー名とパスワードを入力し、送信ボタンをクリックして、正しくログインできるかどうか、および正しいページにジャンプできるかどうかを確認します。 2. 間違ったユーザー名を入力し、ログインが失敗することを確認し、対応するエラー メッセージが表示されます。
3. 間違ったパスワードを入力すると、認証ログインが失敗し、対応するエラー メッセージが表示されます。
4. ユーザー名が空の場合、検証ログインは失敗し、対応するエラー メッセージが表示されます。
5. パスワードが空の場合、検証ログインは失敗し、対応するエラー メッセージが表示されます。
6. ユーザー名とパスワードが空の場合は、「ログイン」をクリックします。
7. ユーザー名とパスワードの前後のスペースの処理
性能試験
1. ログインページを開くのにどれくらい時間がかかりますか
2. 正しいユーザー名とパスワードを入力してから、正常にログインして新しいページに移動するまでにどれくらい時間がかかりますか?
セキュリティテスト
1. パスワードがフロントエンドで暗号化されるかどうか、およびネットワーク送信中に暗号化されるかどうか
2. ユーザー名とパスワードの入力ボックスが SQL インジェクション攻撃を防止できるかどうか
3. ユーザー名とパスワードの入力ボックスが XSS 攻撃を防止できるかどうか
4. 間違ったログインの数を制限する (総当たりクラッキングを防ぐため)
5. 複数のユーザーによる同じマシンへのログインをサポートするかどうか
6. ユーザーが異なる端末でログインする
7. ユーザーのリモートログイン
ユーザーエクスペリエンステスト
1. ページレイアウトは適切か、入力ボックスとボタンの位置は合っているか
2. 入力ボックスのサイズとボタンの長さと高さが適切かどうか
3. キーボードですべての操作が可能か、ショートカットキーはあるか
4. ユーザー名とパスワードを入力して Enter キーを押し、ログインできるかどうかを確認します
5. 認証コードが含まれる場合は、テキストが歪みすぎて認識しにくいかどうか、色を考慮するか（色覚異常ユーザー向け）、更新ボタンや変更ボタンが使いやすいかどうかなども考慮する必要があります。
互換性テスト
BS アーキテクチャ: IE、Firefox、Google、360 などのさまざまなブラウザ テスト。
APP: Huawei、vivo、oppo など、さまざまなタイプ、さまざまな解像度、さまざまなオペレーティング システムの主流の携帯電話でテスト済み。
決済機能のテスト方法（特に重要）
1. 機能を考える
1) ユーザーの利用シナリオ: 正常に支払いを完了するプロセス、支払いが中断された後も支払いを継続するプロセス、支払いが中断された後に支払いを終了するプロセス、一括注文の支払いプロセスなど。
2) さまざまな端末での支払い: PC 支払い、ラップトップ支払い、タブレット支払い、携帯電話支払いなどを含む。
3）さまざまな支払い方法：銀行カードオンラインバンキング支払い、Alipay支払い、WeChat支払いなど。
4) 製品のフォールトトレランスの観点：支払い失敗後の再支払いおよび返金が可能かどうかを含む。
2. 性能面について
複数のユーザーが同時に支払いを行うことができます。
支払いの応答時間。
3. 安全性の観点から
Fiddler を使用して注文情報を傍受し、注文金額を変更するか、注文番号を変更します (2 つの注文 A、B を出し、支払い時に注文 B を傍受し、注文 B の注文番号を注文 A の注文番号に変更します) 支払いを完了できません。
4. ユーザーエクスペリエンスを考慮する
ショートカット キー機能をサポートするかどうか。
プロンプトが表示されるかどうかに関係なく、支払いボタンをクリックします。
支払いのキャンセル、督促の有無。
UI インターフェイスがきれいかどうか。
入力ボックスが揃っているか、適度な大きさかなど。
5. 互換性
BS アーキテクチャ: さまざまなブラウザーのテスト。
APP: さまざまなタイプ、さまざまな解像度、さまざまなオペレーティング システムの携帯電話でテスト済み
ショッピング カートをテストするにはどうすればよいですか? (非常に重要)
1. 機能テスト
a) ログインしていない場合:
ショッピングカートに商品を入れるとログインページにジャンプし、ログインに成功するとショッピングカートの数が増えます。
b) ログイン後:
- すべてのリンクは正しくリダイレクトされていますか。
- 製品をショッピング カートに正常に追加できるかどうか。
- ショッピングカート内のアイテムの総数に制限はありますか?
- 商品総数の統計が正しいかどうか。
- すべて選択機能が利用可能かどうか。
- 削除機能が利用可能かどうか。
- 価格の合計は正しいですか。
- 商品テキストが長すぎる場合に、商品テキストが完全に表示されるかどうか。
- ショッピング カートから削除された商品にマークが付いており、引き続き支払いが可能かどうか。
- ショッピングカートに新たに追加された商品の並び替え（ショッピングカートに存在する店舗の商品と存在しない店舗の商品を追加） - TABやENTERなどのショートカットキーをサポートするかどうか。
- 製品を削除した後に製品の総数が減少するかどうか。
- お気に入り機能が利用可能かどうか
- ショッピングカートのチェックアウト機能が利用可能かどうか。
2. 互換性テスト
BS アーキテクチャ: IE、Firefox、Google、360 などのさまざまなブラウザ テスト。
APP: Huawei、vivo、oppo など、さまざまなタイプ、さまざまな解像度、さまざまなオペレーティング システムの主流の携帯電話でテスト済み。
3. ユーザーエクスペリエンステスト
- 製品を削除するように求めるプロンプトがあるかどうか。
- ショートカット キー機能をサポートするかどうか。
- トップに戻る機能はありますか？
- 商品数が多すぎる場合にチェックアウトボタンをフローティング表示できるかどうか。
- ショッピングカートに複数の商品がある場合、1つの商品に対してのみ決済できます。
- インターフェイスのレイアウトと組版が合理的かどうか。
- テキストが鮮明に表示されるかどうか。
- 異なる販売者の製品が明確に区別されているかどうか。
4. 性能テスト
ショッピングカートのページを開くのにどれくらい時間がかかりますか
【ECプロジェクト実戦】対応関連ドキュメント、チュートリアル、ソースコードメッセージ取得
強力なペットファン、たくさん褒めてください〜