ソフトウェアテスト環境構築のアイデア/テストプロセス

1.ソフトウェアテスト環境

思考：
ソフトウェアテストを行うための条件は？
ソフトウェアテストを行う方法

1.1テスト環境をセットアップする前に

テストの目的を決定します。
機能テスト（ソフトウェアがユーザーのニーズを満たしているかどうかを確認）、安定性テスト、またはパフォーマンステスト（ソフトウェアの効率）をテストします。テストの目的に応じて、テスト環境をセットアップするときにさまざまな点に注意する必要があります。

次に例を示します
。1.機能テスト：大量のデータは不要で、高いカバレッジが必要であり、テストデータは可能な限り実在している必要があります;
パフォーマンステスト：大量のストックデータまたは実際のハードウェア環境に可能な限り類似したハードウェア構成;数千万人のユーザーが同時にアクセスした場合でも対応できますか）

2。测试的软件环境要尽可能模拟真实的环境，选用合适的操作系统和软件。（比如有的用户用ios系统，有的用安卓系统）

3. 软件运行的最低要求ユーザーが使用するテストとハードウェア構成を理解する

4. 了解用户常使用的软件，避免我们做的软件配置与其相冲突（競合が発生した場合、フラッシュバックまたはその他のエラーが発生する可能性があるため、ユーザーの一般的なソフトウェア構成との競合を回避してください。）

5. 产品化的测试需要考虑兼容性测试（例は、外部アプリまたはWebページです。つまり、携帯電話にインストールされているソフトウェアに関係なく、私のソフトウェアを使用できます）

6.建設独立的测试环境、さまざまな人やプロジェクトが現在のテストに影響を与えてはなりません（他の人やプロジェクトが原因でテストが変更されないことを願っています。たとえば、開発が彼の変化も見ることができる場合に備えて、私が今行っているテストは私にテストします）影響があります。）

7. 可复用的测试环境
バックアップまたはデータ分離を介して構築します。
一連のテスト環境を繰り返し使用して、複数のバージョンと複数の期間をテストします。

1.2環境構築モード

オフライン構築：会社でローカルに構築

申请独立测试服务器或者虚拟机

测试环境配置

测试项目导入

例：
Java環境の構築：Java環境の
構成（jdkの
ダウンロードと環境変数の構成）ミドルウェア（tomcat、jettyまたはその他）のダウンロードと
インストール、データベースのインストールとインポート、初期化スクリプトの入力

オンラインで構築する：
Dockerモード（私は自分の環境と必要なものを大きな箱に封印し、それを使いたいときに箱を捨て、箱が直接環境を構築します。）
自分のイメージミラーを構築し、次にデプロイを実行する

サードパーティのプラットフォームに依存します。
たとえば、利用可能な仮想マシンやデータベースなどを備えたクラウド環境であれば、必要に応じて組み合わせることができます
。

1.3テスト環境構築の考え方

考慮事項：
使用、使用コスト、メンテナンスコスト

基本アーキテクチャ：
R＆D環境：R＆Dセルフテストおよび統合テストに使用（R＆Dで使用される環境に基づいて、彼は自己調整可能）
テスト環境：毎日の単一システムまたは2つまたは2つのマイクロサービス間で使用、自動テストも統合可能戻る

共同テスト環境：
大規模な共同テストに使用される完全な環境。
（全体的な共同テストには、すべてのビジネスフロー、インターフェイスなどが含まれるため、非常に完全な環境が必要です）

外部環境（必要な場合）：
外部マーチャントおよびその他の共同デバッグに使用される安定したバージョン環境

グレースケール/サンドボックス環境：
生産データテストおよびシミュレーションテストに使用されます。
テスト中に独自のデータを省略できるため、本番データが導入されます
（グレースケール本番検証など。サンドボックスデータクエリ本番データ、本番ファイル検証など）。

2.テストプロセス

論理的に。テストアクティビティは順番に実行されます
が、実際のテストプロセスでは、これらのアクティビティを重複または同時に実行できます（Alipayのフレンドの追加、ログイン、転送など）。フレンド追加モジュールのテストでは、このモジュールの操作にログインする必要があります）

2.1テスト計画プロセス

テスト計画は、次の3つの部分に分かれています。
テスト計画の手順：

続行 测试需求的分析

テストするコンテンツまたは品質特性を特定する

明確なテストの十分性要件

先に進める 测试的基本方法

テスト計画を実行する必要があります。

よし 测试的资源和技术需求

行動の风险分析・評価

上記の分析結果によると 定测试计划

対応するを実行するテスト計画によると 测试控制活动

2.1.1需要分析

過去のソフトウェアライフサイクルでは、要件分析段階に関与するテスターはいませんでした。しかし、ソフトウェアプロセスの最適化により、测试人员的加入对需求分析阶段有了更大的作用。

要件分析フェーズでテストが追加された理由

1.テストエンジニアが要件分析に参加し对需求了解很深刻，、開発者とのやり取りを減らし、時間を節約します（一部の機能では、テストは開発者と
早い段階で連絡する必要があります）2.テストケースを書くアイデアを早期に決定し为测试打好了基础
ます3.はい获取一些测试数据，为测试用例设计提供帮助（製品によってはユーザーニーズの詳細を学び、より多くのデータをマスターして、いくつかのテストデータを早期に取得できるようにします
。4。はい发现需求不合理的地方、テストコストを削減します（通常の操作ガイドラインの違反などを早期に発見して、再処理を回避できます）。

要件テストの役割：
1.テスト要件の分析は、テスト作業全体を決定し、テストオブジェクトとテスト作業の範囲と役割を明確にし、テストカバレッジの基礎として役立ちます。
2.決定されたテスト要件は検証可能である必要があり、テスト要件には観察可能で測定可能な結果が必要です。
3.検証できない要件がテスト要件でない場合。
4.テスト要件の分析には、特定の混乱を明確にするための顧客とのコミュニケーションも含まれ
ます5.どの要件がより重要であるかを明確にします
6.利害関係者がプロジェクトにできるだけ早く合意を得るようにします
7.将来の製品を明確に理解します
8.テスト要件が策定されますテスト計画の基本的な基礎
9.テスト要件は、テストケースを設計するためのガイダンスです
。10.ユースケースを効果的に設計するために何をテストし、どの側面をテストするかを決定します。

要件の検証：
◆要件のドキュメントを確認する ◆
要件のドキュメントと関連モデルを慎重に確認する
◆さらに、要件の開発中に行われた非公式のレビューも有益です

これを行う必要があります：
以需求为依据编写测试用例：
ユーザーマニュアル
の作成理解しやすいユーザーマニュアルを要件開発の早い段階で作成し、ユーザーに表示されるすべての機能を記述して、要件仕様のリファレンスとして使用し、要件分析に役立てることができます。

適格性基準の決定：
ユーザーがどの製品が要件を満たし、用途に適しているかを説明します
。適格性を確認するテストは、使用シナリオの説明またはユースケースに基づいています。

Yu'ebao需要テスト戦闘

AlipayのYu'ebaoビジネスを例にとります

1.当初の需要：
早くも2012年頃、Alipayはすぐに一般に受け入れられましたが、比較的一般的な現象に直面していました。Alipayアカウントの残高には常にアイドル状態の資金がありますが、異なるアカウントの資金の量はわずかです、しかし一般的に、アカウントで実行できないアイドルファンドの量は依然として比較的多く、これはAlipayの開発にとって非常に好ましくありません。

2.需要：
つまり、ファンド会社と協力して金銭商品を立ち上げると同時に、ユーザーが金銭購入後、商品やサービスの購入代金を金銭金額で直接支払うことができるという需要があります。
貨幣資金は、あたかも残高や売却であるかのように、消費の支払い手段として使用できます。

3.要件ドキュメントの確認：要件ドキュメントを
簡単に見てみましょう。ドキュメントは次のように大別できます。
要件分析
フローチャート
テキストフロー
制約制約
控除優先度
例外処理
セキュリティコントロール
ページ

需要分析のプロセスでは、上記のプロセスを
通貨ファンドの購入、現金の引き出し、消費、資産管理、トランザクションクエリに分割し
ます。これは、需要仕様チェックリストで確認できます。

2.1.2テスト戦略

テスト前に考慮すべき質問：

テストするシステムの動作
を知っていますか？
システムの特性は何ですか？システムの機能は何ですか？
システムのどの部分をテストする必要がありますか？テストする必要のない部分は何
ですか？
システムのパフォーマンス要件は何ですか？システムのセキュリティ要件は何ですか？

テスト戦略の要件は、上記の質問から導き出すことができます。テスト戦略は、テストプロジェクトとテストタスクの間の関係を記述することです。
測定対象、測定方法、テストリソースとテスト時間の調整方法などを説明するために使用されます。

テスト戦略の要素：
1.テストスケジュールとリリース計画
テストプロジェクト自体の重要なマイルストーンをリストします。
各マイルストーンには明確な終了時刻が必要です。

2.テスト時間
テストの時間スケジュールが不十分な場合、後続のテスト範囲で優先度の高い機能を選択してテストを実行
できます。これにより、製品の品質を最大化できます。

3.試験範囲は、（優先順）
にスコープと（へと範囲の範囲外）範囲外に
したモジュールは、試験のこの段階で考慮されていない試験範囲に注目すべきである
試験用スコープ内のモジュールは優先順位を付ける必要があるため、テスト時間が不足し
、テスト対象外のモジュールは理由を述べる必要があります。

4.テストリソース

テストリソースは、テスト戦略の非常に重要な部分でもあります。これは
、人的リソースとツールの2つの部分に分かれています。人的リソースは、主にテストに関係する人々を説明します。もちろん、プロのテスター、顧客、製品マネージャー、その他の
ツールなど、多くの役割を含めることができます。使用されるその他のソフトウェア

5.テスト環境
テスト環境には、主に推奨環境ソリューション、オペレーティングシステム要件、ハードウェアおよびソフトウェア要件が含まれます。
推奨ソリューションの場合、テストプロジェクトが他のソフトウェアに依存していることを示す必要があります。たとえば
、テストプロジェクトはJAVAに依存しており、推奨バージョンは1.7である場合があります。

6.テスト方法テスト方法
のリストは、主にテストプロジェクトに対して実行する必要があるテストの種類を示すためのものです。
機能テストは必要ですが、非機能テストはオプションです

7.ドキュメント管理
完全な製品の場合、ドキュメントは重要な部分です。通常、ドキュメントには、インストール、アップグレードのドキュメント、ユーザーガイド、その他の
ドキュメントが含まれます。これは単なるファイルではなく、すでにソフトウェアの一部であるため、送信するにはテストを完了する必要がありますユーザーに誤ってユーザーを誤解させ、テストプロジェクトへの信頼を失わせないようにするため。

8.リスク管理
リスク管理モジュールは、不確実に思われる可能性のある現在知られている要因を一覧表示する必要があります（当社のテクノロジーは、3億人が同時にアプリにアクセスするなどのユーザー要件を満たすことができないなど）
これらの要因テクノロジー、リソース、またはその他の側面から発生する可能性があります（必要なソフトウェアの場合、非常に高価である、会社がそれを買う余裕がない、またはテストに成功するために銀行に接続する必要があるが、銀行に接続できない場合があります）

2.1.3テスト計画の設計

テスト戦略：
侧重需求分析，评估风险テストの範囲を定義し
、テスト方法を決定し、テストの開始、停止、完了の基準と条件を策定する

テスト計画：
プロジェクトの開発测试过程中的测试重点
タスクの割り当てを、配置の様々な段階のスケジュールを設定
し、さまざまなタスクの評価を提供するために、リスク分析、テスト戦略が含まれます

テスト計画：
侧重测试的方法，テスト環境の計画、
テストツールの設計と選択、テストケースの設計方法、テストコードの設計計画

テスト戦略VSテスト計画VSテスト計画
◆実際の実装プロセスでは、多くの場合、同様の方法があります。

◆ 测试方案=测试计划+用例设计方案+工具选择+自动化/性能测试具体方案

◆ 测试计划=测试策略+测试任务分配+时间进度安排
金融ファンド消費テスト計画の分析プロセス
1.分析需求：
現在のテストには、要件（要件ドキュメントまたはwikiリンクなど）が含まれています
。2. 测试计划（マイルストーン）および担当者：
現在のプロジェクトの各モジュールのテストリーダー、タスク割り当て、テストスケジュールを整理し
ます。3.テスト范围とテストの焦点：
これらのポイントテストの必要性、重点を置く場所、優先順位の配置
4.戦略とツール: 是否需要进行自动化、性能、安全测试?使用哪些工具.
5.テストケースの設計方法：設計に
使用するブラックボックステスト方法の種類（等価クラス？境界値？原因と結果の図？など）
6。テスト環境：テスト環境
とは何ですか？どのサーバー、データベース、および構成が必要ですか？
7.共同デバッグテスト
是否需要与第三方或其他部门进行联调：？いつ起動されますか？共同デバッグにはどのような機能が含まれますか？たとえば、ファンド会社
8.テスト制限：
テスト環境で哪些内容无法测试？
9.テスト风险：
テストまたは計画されたテストプロセス中のタイミング、テスト制限、および優先順位の配分によるテストリスクの考慮事項

2.1.4テスト計画のレビュー

テスト計画がレビューされない場合、それは深刻な結果を引き起こし
ます。ドキュメントとコミュニケーションから情報を取得するだけで、情報の非対称性、一方的な理解、誤った理解または詳細な理解が引き起こされる可能性があります。
ピアの相互レビューと開発レビューのメカニズムの欠如は、十分に活用できません。集団の知恵、個人的な思考を打ち破ることは困難であり、テストが失敗する場合があるかもしれません

テストの見直しの目的：
テスト作業をレンダリングする
与开发达成共识.（例えば赤い封筒など、この操作は、それを開発するには：お金を口座に、操作が完了した場合でも、テストのために：ユーザーが赤い封筒を要求したいされていない場合）
不同的思维方式、衝突の火花を、人間のことを学びます考え方
このような行動パターンを育成します。個人的な経験、専門知識、補完的なスキル
を团队协作，最大限に活用するために、チームや他の人に喜んで提案します。

レビューの要点：（
采用的测试方法たとえば、このプロジェクトにはパフォーマンステストが必要だとは思わないが、必要になる場合がある）
等价类划分的依据
测试数据的选取和准备方法（たとえば、追加計算機を作成して、それが選択されているかどうかを確認するには、すべてのデータを入力することは不可能なので、なぜこれらのデータを選択する必要があるのか​​。レビュー）
流程测试的路径组合（
数据比对选取的对象和检查点淘宝網で商品を購入するプロセスを実行する方法）（淘宝網で新しい携帯電話を購入する、注文後にデータベースインターフェイス、データなどが正常かどうかを評価するなど）
是否需要模拟数据およびデータをシミュレートする方法（ダブルイレブンを予測するアクティビティなど） 、次に
、风险的测试取舍（リスクを克服できない場合はバッチでリークする必要がある）に基づいて、計画を作成するためのデータ量と注文数をシミュレートする必要があります。