まず、基礎：理論テスト
最初のテストベース[記事]記事では、テストの基礎を徹底的に理解を取ります
1、ソフトウェアのテストの目的：検出（探索エラー）→（仕事にショーのソフトウェア）を証明する→予防（品質管理）
2、テストの実行：
試験実行部（UT実行）：テスト実行のテストケース。
統合テストの実行（ITの実行）：テスト実行のテストスイート。
テスト実行システム（STが実行）：テスト異なるテストフェーズを実行します。
3、相違点のテストと試運転：
[テスト]：エラーが存在する見つける; [デバッグ]：位置決め誤差、プログラムエラーが修正された変更は
4、回帰テストの目的：（使用される回帰テスト：インクリメンタル開発、バージョン管理、ソフトウェア・メンテナンス）は、欠陥の修理または増加の一部が正しいかどうかを確認し、コードの変更は、新しいエラーを導入するかどうかを検出します。
5、ソフトウェアテストの主な仕事は： ;テストドキュメントを書く（テスト計画、テスト計画、テストケース、など）、設計・テスト、コード、レビューの開発ドキュメントを見るテストを実行したところ、ソフトウェアの欠陥、ポストバグレポートを、そして最終的に確認欠陥を取得します修理、
品質テスト対策ソフトを可決した。......
6、主にソフトウェアの危機の出現：
1.によりソフトウェアの開発とデータ蓄積の大規模なソフトウェア開発経験の不足、開発計画を策定することは困難です。
2.初期の開発は分析がポストに矛盾濃厚暴露の開発で、その結果、十分に明らかではないが、必要があります。
3.開発に従って維持することは困難で標準化され、不完全な開発ドキュメント、ソフトウェアではありません。
ユーザーの貧弱なソフトウェア品質に配信厳格かつ効果的なソフトウェアの品質テストツールの4.不足、。
7、ソフトウェア危機の影響：
1.ソフトウェアの品質が安定化するために、高い難しいことではありません。2.ソフトウェアプロジェクトの遅延は、進行状況が制御することはできません。3.費用の増加は、予算を制御することができませんでした。
8、ソフトウェア危機：
1.ムーアの法則、急速に開発されたハードウェアによると、ソフトウェアシステムの対応する期待がますます厳しくなってきました。
2.ソフトウェア、システムの複雑性の増加、人々が協力する必要があります。
3.ソフトウェア開発は人間の知的活動で、組織と管理に既存の生産工学的アプローチを使用することはできません。
9.なぜソフトウェアの欠陥があります：
ソフトウェアの欠陥が最大の理由につながる要求仕様であり、二番目に大きなソースソフトウェアの欠陥がデザインされ、コードを書き、他のもの。
10、理由の一般的な欠陥の導入：
1.効果的な通信、または全く通信の開発プロセスの欠如、（デザインが正しくないように誤った発現が、その理解は、正しくありません）
2.ソフトウェアの複雑さが増加しています。
3.プログラミング・エラー（構文エラー、セマンティックエラー、等）
4.刻々と変化する需要に、（プロジェクトの失敗の最大のキラーは、再設計、リエンジニアリングの手配が発生します）
5.圧力プロジェクトスケジュール;（市場をつかむために、あなたは一定の時間外労働は、最終的にはソフトウェアので、他の局面を作り出し、エラーの多くにつながるので、無理なスケジュールが生じ、競争が早くステップアウトよりも製品を提供しなければなりません。プロジェクトのタイミング）は、通常、最も困難な推測多くの作業を要するので、期限が来たときに、エラーが発生した同行します
6.文書の発展を重視していない。（1つのチームがコードのドキュメントを読み、維持するために、と言って入ってくる新入社員のために残されたときには非常に難しいことではありません）
7.ソフトウェア開発ツール自体隠された問題は、（比較的成熟した製品を選択してみてください）
8.傲慢な人。......
11、欠陥の種類：
[欠落]：所定のまたは予想される需要は、製品（仕様が完全に実現されていないか分析段階省略需要を要求することができる）に反映されません。
[]エラー：指定のない正しい実装（可能な設計ミス、コーディングエラーがあります）。
[追加]実現：仕様は、要件を実現するための製品に組み込まれている指定されていません。
12、欠陥特定のパフォーマンス：
製品の仕様を満たしていないソフトウェアは、機能を示しました。エラーは、ソフトウェア製品の仕様は、ケースを示していないが発生しました。製品仕様に指定された範囲を超えたソフトウェアの機能。ソフトウェアは、製品の仕様を満たしていないが、まだ達成すべき目標を明記していません。ソフトウェアテスターは、ソフトウェア、使いにくい、分かりにくい低速、またはエンドユーザーが良くないと思うと思いました。
13、共通のソフトウェア生産プロセス：
[]（ソフトウェア、ソフトウェアライフサイクルモデル、9段階のライフサイクル）：フィージビリティスタディ市場調査→→→→製品需要の研究プロジェクト→→→→→→製品のメンテナンス製品リリースのテストの→→→→→→システムの設計と開発製品のアップグレード。問題定義→→フィージビリティ・スタディは、分析を必要とする（機能モデリング、データモデリング）アウトライン設計→→→詳細設計・コーディング→→メンテナンステスト
[1]プラン（計画）:( 1）全体的なソフトウェア開発の目標を決定し、機能におけるアイデア（2）ソフトウェア、パフォーマンス、信頼性、インターフェイスを提供し;（3）プロジェクトの実現可能性調査の完了、探索します問題の解決策;（4）を推定するために作られた、開発、コスト、有効性と開発の進展のために利用可能な資源の使用を、（5）実施計画を策定するために開発タスクを完了するため。
[2]需要分析（要求分析）：一緒にソフトウェアのニーズ分析の詳細な定義の開発とユーザーの需要を満たすため、正確な記述を与える、ソフトウェアの要求仕様のSRSを書くことで意思決定を、議論します。（ソフトウェア製品の開発、市場調査からの需要、およびのために、彼らは自分自身を開発し、開発したいものがあり、ソフトウェア開発プロジェクトのために、顧客の要求、研究開発からの需要が他の人々は、我々はR＆Dプロジェクトを助けたと思うものによって特徴付けられます。ソフトウェアタイプ：特定のソフトウェア製品ベンダーに指定した特定の顧客、すべてのお客様が所有するソフトウェア知的財産権、製品のソフトウェア：すべてのソフトウェア開発者が所有している汎用ソフトウェア製品、ソフトウェア、知的財産権の特定のグループのための特定のソフトウェア開発）。
[3]設計（デザイン、概要設計と詳細設計）：ソフトウェア工学のコア技術である、設計仕様はこのフェーズを完了する必要があります。[デザイン（HLD）の概要アーキテクチャのための対応する要求に変換するための設計段階で、各機能部分は、特定のモジュールである[詳細設計（LLD）：モジュールごとに実行される作業のためには、具体的に説明します。
[4]プログラムコーディング（符号化）：プログラムを受信することができるコンピュータを変換するように設計されたソフトウェアを、それは、プログラミング言語で表現ソースリストに書き込まれます。
[5]試験（テスト）：機能と機能のためのユニットテスト（各機能の試験）、統合テスト（：ソフトウェアは、品質要件を満たすために、顧客の需要を満たすためにかどうかを確認し、一般的に独立したグループ試験によって行わはに分割されています統合、即ちサブシステムおよびサブシステムの統合システム、即ち、テスト）、機能要件、性能要件、等テスト）のそれぞれについて試験システム（の間のモジュール間すなわち機能、モジュールと統合されたモジュール、、、の間。
[6]運転・保守（ランとメンテナンス）：彼らは維持期に入った後、ソフトウェアは、このようなソフトウェアのエラー、システムソフトウェアのアップグレード、ソフトウェアの機能拡張として、それを修正する必要がある多くの理由があるかもしれない、正式に使用に入れ、ユーザーに配信され、パフォーマンスを向上させます。
14、ソフトウェア開発三つの要素：
人、プロセス、ツール、
高品質のソフトウェアを開発するためのプロセスに適したツールの助けを借りて右の人だけが、人材サービスのためのツールと手順は、補助的な役割を果たし、重要な役割は、人とプロセスで果たしています。
15、プロジェクトチーム（ソフトウェアプロジェクトチームスタッフ）の共通のフレームワーク：
1.プロジェクトマネージャ。
2.開発グループ：開発マネージャー、アナリスト、設計者、開発者、
3.テストグループ：テストマネージャー、テスター;
4.グループ管理設定：設定マネージャ、管理者の設定（CMO、構成管理官）;
5.SQA（品質保証担当者）。
16、ソフトウェア開発プロセスの種類：
[1]、ウォーターフォールモデル（滝モデル）：線形、シリアル、リスク管理能力、小さな変更の需要。ウォーターフォールモデルステップを簡略化問題の核となるアイデアに基づいている、すなわち、分業、ウォーターフォールモデル構造解析および設計を容易にし、別々に実装物理ロジックを実装するために、デザインの特徴とは別に実装されます。ソフトウェアのライフサイクルは、6つの基本活動の計画、要件分析、ソフトウェア設計、プログラミング、ソフトウェアのテストと運用・保守に分割され、水が落ちるよう下、一定の秩序の相互の収束、上から彼らのために提供し、レベルごとれ行方。
計画段階：プロジェクト計画、プロジェクト計画の
要件フェーズ：要件仕様、SRS：ソフトウェア要件仕様
設計段階：概要設計：高レベル設計、詳細設計：低レベル設計
開発段階：コード、ユースケース
テスト段階：テスト実装と実行
維持期：製品のメンテナンスの
利点：シンプルで効率的な（一般的な製品の要件すぐにライン上で、動作を保証するのは初めてである必要があり、他の人が実行する時間を持っている）
短所：テストは後半厳しいアイドルスタッフを必要とする、フォローアップが追いついていないこと、各プロジェクトでステージ間のいくつかのフィードバックは、過度の力を完了日とマイルストーンを通じて、プロジェクトの様々な段階を追跡するために;のみ、プロジェクトのライフサイクルの後半で結果を表示するには、ユーザーのニーズに合っていないウォーターフォールモデルの欠点変更を強調表示します。
スコープ：リクルートテスターの後に開発されたプロジェクトは、プロジェクトへの頻繁な変更のニーズに適していないウォーターフォールモデルが存在する可能性があります。小規模の伝統的なプロジェクト事業開発のための大規模なプロジェクトには適していません。適切な範囲：小さなプロジェクト、明確な需要。
ソフトウェアのテストのウォーターフォールモデルに応じて位相が単体テスト、統合テスト、システムテストに分けることができます。
リスク駆動型モデル、反復モデル（反復）、ウォーターフォールモデルは、反復モデルに適用することができます。各繰り返しは、より多くの機能を追加しながら実行することができますバージョンを生成します。各繰り返しは、品質と統合テストでなければなりません。
インクリメンタル：最終的にソフトウェア製品のニーズを満たすために開発されたソフトウェア開発プロセス、主な機能モジュールを開発した後、二次機能モジュールを開発し、徐々に改善するために、。
反復：後インクリメンタル開発プロセスを指し、各モジュールの開発が繰り返され、次のモジュールを開発する代わりに、モジュールの開発を終了するためのモジュールを完了していない、モジュールは、以前に継続的な改善のために開発されている可能性があり、新機能を追加します。
[2]、スパイラルモデル：モデルリスク管理、高リスク優先的、リスク管理上の高い需要。統合された基本的なウォーターフォールモデルと進化論/増分試作。代替スパイラルモデル、並列ウォーターフォールモデルの複数のセット：これは、滝を異なります。完全なリスクのアカウントなので、選択肢のデザイン。
利点：完全に、強い抗リスク能力のリスクを考える;
短所：高コストは、専門的なリスク分析の専門家を必要としています。
有効範囲：システムの生命と財産に関連付けられています。
[3]、RUP（ラショナル統一プロセス）：統一ソフトウェア開発プロセスは、オブジェクト指向、ネットワークベースのアプリケーション開発方法論です。ワークフローのすべての段階ですべてが反映されています。オブジェクト指向、多彩な。特長：リスクベース;ケース駆動型のセットを使用し、アーキテクチャ中心、反復と増分。だから、ワークフローの各段階で反映されています。
長所：大規模で複雑なシステムのために、徐々に実装の複雑さを軽減、改善することが、効果的に変化（多くの場合、ローカルの変更）のリスクとコストを制御するために、ユーザは、早い段階で変更することがありますし、修復するためには、早期での利用者の信頼を高めることができます（半製品を参照してください）。
短所：機能と機能との間の接触が近すぎるときには、ログインし、登録リンクとして、RUPモデルを使用することはほとんどありません、プロの建築家（建築家の義務を）持っている、特定した変化の関数は許可されていません、しかし、本質的なリンクによる設計変更のため、制御不能に起因しています。
範囲：大規模で複雑な研究開発プロジェクト、低カップリングシステム。
[4]、IPD（統合製品開発）： -統合製品開発、「製品ライフサイクルの最適化と法」の米国PRTMの問題からIPDのアイデアは、（製品とサイクルタイムの優秀PACEと呼ばれる ） 、本を詳細に説明したこの新製品の開発モデルのさまざまな側面が含まれています。製品構造を改（改リソース）;共通の共通モジュール。
製品全体の観点からだけでなく、研究開発のために。
長所：ソフトウェアとハードウェアの開発と生産、効果的に統合のための販売および他の部門、意思決定の精度と適時性を改善するための1つの統合管理プラットフォームの下に一元化、重要なデータのすべての部門を共有に資する;
短所：管理のコストが高い;の部門より複雑な関係を座標;
範囲：ハードウェアとソフトウェアベンダーの大規模集積。
[5]、アジャイル開発：スクラムは、通常、アジャイルソフトウェア開発のために使用される反復と増分ソフトウェア開発プロセス、です。
特定の機能、および迅速一つ一つを達成するための機能、（アウトラインデザインなどを含む）の書き込みを省略文書を開発する計画は、これに基づいて機能を追加することが可能です。
他の多くのテスターの豊富な実務経験のモデルまたはVモデル、または精通していないが、ソフトウェアテストでは、Vモデルは、最もよく知られているモデルです。ウォーターフォールモデルを批判し、疑問視されているとこれも同じVモデルは、長い時間のために存在している、と滝の開発モデルは、いくつかの共通の特性を持っている、と。左から右へのプロセスのVモデルは、基本的な開発プロセスとテスト動作を説明します。Vモデルの値は、それが非常に明確に異なるレベルでテストプロセスの存在を示し、明確にテスト段階と開発プロセス中にこれらの様々な段階の間の対応関係を記述していることです。
制限事項：後半の受け入れテストまで、このような要件分析として符号化後の最後のイベントとして事前テストによって生成されたエラーは、見つけるために。テストはコーディングが完了した後にのみ開始し、ソフトウェアテストの「3つの早期」の原則を満たしていません。
2、Wモデル
Vモデルの制限事項は、「できるだけ早くと、ソフトウェアのテストを実行し続ける」の原則を反映する一切明記初期のテストがないことです。Vモデルのテストを増加させるためのソフトウェアの開発の各段階は、W進化モデル（下記参照）を同期させる必要があります。モデルに見やすい、開発、テストがこの、「V」と平行であり、「V」です。基づき、「できるだけ早くとソフトウェアテストを実施していき、」ソフトウェア要件とIEEE1012-1998の設計段階でのテスト活動の原則は、「ソフトウェアの検証と妥当性確認（V＆V）」の原則に従うべきです。
Evolutif当社が提案したWモデルは、Vモデルに関して、Wモデルは、より科学的です。Wモデルは、Vモデルの開発で、重点は、全体のソフトウェア開発サイクルと一緒にテストされ、テストオブジェクトは、単に手続き、要件、機能設計およびテストすることもあるではありません。テストおよび開発は、このように可能な限り早期に問題を識別するために貢献し、同時に行われます。コーディングが完了するまで、要求分析の間に例えば、SRS評価、SRSは、設計および統合テスト設計、詳細設計、ユニットテスト設計の概要に続いて設計された、システムのテスト計画、プログラム、ユースケースを、ベースライン、コードレビュー、 UT、IT、STを継続します。
Wモデル：（需要V＆V、システムテストの設計と評価）→→アウトライン設計（基本設計のV＆V、統合テスト設計と評価）→→ユーザー要件の詳細設計（ユーザーがV＆V、受け入れテストの設計と評価を必要とする）の分析を（必要→→ V＆Vの詳細設計、ユニットテストとデザインレビュー）→→コーディング（ユニットテスト）→→モジュール積分（統合テスト）→→実施例（試験システム）→→送達（受入テスト）。
Wモデルは、ソフトウェア開発モデルのWとVモデルは要件、設計、コーディング、などのシリアル一連の活動とみなされ、私たちは繰り返し、自発性と変更の調整をサポートすることができない、制限があります。
3、Xモデル
Xモデルは、符号化のためのモデルV、X提案モデルを改善し、実行可能プログラムの最終的な合成を統合することにより、その後の頻繁なハンドオーバを介して、個々のテストプログラムフラグメントについて互いに分離されています。
左Xモデルは、符号化のために記載及び頻繁なハンドオーバ、統合された最終的になり、実行可能プログラム、実行可能プログラムとは、これらを試験した後にのみプログラムの断片を行う互いにテストから分離されます。、包装され、ユーザに提示することができるが完了したテストを統合することによって、より大きな規模の一部として、および範囲内に統合されてもよいです。平行な複数の曲線は、変化が様々な部分で発生する可能性があり表します。図から分かるように、Xのモデルはまた、テストの特殊なタイプは事前に計画されていないされて探索的テストを、位置決め、このアプローチは、多くの場合、経験豊富なテスターを助けることができるテスト計画以上にそのソフトウェアのエラーを発見しました。しかし、これはテストの人材、材料及び財源の無駄になることがあり、テスターの能力要件は比較的高いです。
4、Hモデル
Hモデルは、ソフトウェアのテストプロセスでは、実装フェーズにテスト準備フェーズからテストでき、テストポイントの準備ができ、同時に他のプロセスを用いて、全体の製品サイクル全体にわたって、完全に独立した活動です。ソフトウェアのテストは、可能な限り早く行うことができ、検体の異なるレベルに応じて分割してもよいです。
この回路図は、いくつかのレベルでのテスト「微小」で全体の生産サイクルを示しています。図面に注意他のプロセスは、例えば、任意の開発プロセス、設計プロセス、または符号化プロセスであってもよいです。言い換えれば、限り、試験条件が熟していると、テストの準備活動が完了していると、テスト実行活動を行うことができます。
H模型揭示了一个原理：软件测试是一个独立的流程，贯穿产品整个生命周期，与其他流程并发地进行。H模型指出软件测试要尽早准备，尽早执行。不同的测试活动可以是按照某个次序先后进行的，但也可能是反复的，只要某个测试达到准备就绪点，测试执行活动就可以开展。
5、总结
1.软件测试过程模型－V模型
是软件开发瀑布模型的变种，主要反映测试活动与分析和设计的关系；
局限性：把测试作为编码之后的最后一个活动，需求分析等前期产生的错误直到后期的验收测试才能发现。
2.软件测试过程模型－W模型
在V模型的基础上，增加开发阶段的同步测试，形成W模型；测试与开发同步进行，有利用尽早的发现问题；
局限性：仍把开发活动看成是从需求开始到编码结束的串行活动，只有上一阶段完成后，才可以开始下一阶段的活动，不能支持迭代，自发性以及变更调整。
3.软件测试过程模型－H模型
在H模型中，软件测试过程活动完全独立，贯穿于整个产品的周期，与其他流程并发地进行，某个测试点准备就绪时，就可以从测试准备阶段进行到测试执行阶段；软件测试可以进行尽早的进行；软件测试可以根据被测物的不同而分层次进行。
在实际工作中应灵活地运用各种模型的优点，
V模型： 强调了在整个软件项目开发中需要经历的若干个测试级别，并与每一个开发级别对应；忽略了测试的对象不应该仅仅包括程序，没有明确指出对需求、设计的测试；
W模型： 补充了V模型中忽略的内容，强调了测试计划等工作的先行和对系统需求和系统设计的测试；与V模型相同，没有对软件测试的流程进行说明；
H模型： 强调测试是独立的，只要测试准备完成，就可以执行测试。
测试基础【第三篇】测试流程
测试的流程，可以遵循“计划→设计→实现→执行”这几步，细分下来是：
0、成立测试组：根据团队需要具备的技能树来组件团队
1、测试需求评审：分析测试需求
2、制定测试方案：包含计划、规程、方案等，
参考：https://www.cnblogs.com/UncleYong/p/10967722.html
3、提取测试需求：分解测试需求为测试点（思维导图）
4、编写测试用例：根据测试点编写测试用例，包含正向用例、反向用例，
参考：https://www.cnblogs.com/UncleYong/p/10967497.html
5、搭建测试环境：根据系统架构，搭建测试环境，初始化基础测试数据
6、执行冒烟测试：选取优先级高的用例执行
7、执行测试用例：系统测试
8、跟踪回归缺陷：跟踪自己提交的缺陷，及时回归，如果通过，更改缺陷状态。缺陷生命周期，
参考：https://www.cnblogs.com/uncleyong/p/10967748.html
9、输出测试报告：
测试基础【第四篇】测试计划、方案
Y**项目测试方案
涉及敏感信息，只能分享目录
测试基础【第五篇】测试用例要素及其设计方法
测试用例的要素
测试用例编号 测试标题 所属模块 测试需求项编号 案例状态 预置条件 优先级 测试输入 操作步骤 预期输出 实际结果 案例设计者 设计日期 案例性质
用例设计方法
等价类
找出发现bug效果一样的一个组合。分为有效等价类和无效等价类。
步骤：1.划分等价类；2.确定测试用例；
举例：输入三角形三边应为正整数，分别构成非三角形、一般三角形、等腰三角形和等边三角形。
需求分析：1.正整数；2.两边之和大于第三边；3.两边相等；4.三边相等。
等价类设计
边界值
大量bug集中在输入的边界上，边界值和等价类互补。
边界值：
上点：边界上的点，不管是开还是闭区间
离点：距离上点最近的点，闭区间离点在外，开区间离点在内
内点：边界内的任意一点，可以采用折中的方法确定内点
步骤：1.划分等价类（可选）；2.分析样点；3.确定测试用例。
判定表
增强条件与结果之间的逻辑性，弥补等价类的不足，判定表无法直接生成测试用例，而且条件得到什么结果需要手工处理。
步骤：1.标识输入和输出；2.构造判定表；3.逐列分析条件项组合，填入其动作项；4.简化判定表（可选）；5.生成测试用例。
因果图
因果图，得到条件和条件、条件和结果的逻辑关系，可以通过与或非运算直接得到测试规则，然后合并，最后通过等价类、边界值抽取测试用例。
步骤：1.标识输入和输出；2.画出因果图；3.将因果图转换为判定表；4.简化判定表（可选）；5.生成测试用例。
条件与结果：恒等、非、或、与
条件与条件：异、唯一、要求、或
1.E约束（异）：所有输入中至多一个输入条件发生。（<=1，也可以没有）
2.I约束（或）：所有输入中至少一个输入条件发生。（>=1）
3.O约束（唯一）；所有输入中有且只有一个输入条件发生。（=1）
4.R约束（要求）：所有输入中只要有一个输入条件发生，则其它输入也会发生。
正交试验
确定需求中因子及所对应的状态的个数
因子与水平相等：直接查找正交表，使用取值进行替换
因子不等：查找比因子稍大的正交表，选取行数最小的，将最后多出的因子空闲，不做替换
水平不等：查找水平稍大的正交表，选取行数最小的，将多余的水平留着，在抽取用例的时候根据均分原则替换
因子和水平都不相等：查找比因子、水平都稍大的正交表，选取行数最小的，根据上述方法选定正交表
最后，需要根据经验进行用例的补充。
《常用正交表对照图》，加Q群获取
步骤：1.提取功能说明，构造“因子—状态”表；2.加权筛选，生成因素分析表（删除重要性较小的因子或状态）；3.利用正交表构造测试数据集；4.利用正交表每行数据构造测试用例。
流程分析
涉及流程的，都可以用流程分析，能将系统功能进行串联，但是流程没问题不表示功能没问题
流程分为正常流程和异常流程
步骤：1.画出业务流程图；2.定义状态节点和条件分支；3.确定测试路径（每个流程构成一个测试用例）；4.选取测试数据，构造测试用例。
异常分析
断电、断网、硬件故障等。
步骤：1.针对系统罗列可能的故障；2.针对每种可能故障设计测试用例。
测试基础【第六篇】bug要素及其生命周期
bug的要素
为了让开发人员更准确、更快的看懂Bug，测试需要按照一定的规范提交bug。
缺陷id：一般由缺陷管理系统自动生成；
缺陷标题：概要描述缺陷；
发现人：一般是缺陷管理系统自动获取当前用户；
发现时间：一般是缺陷系统自动获取当前系统时间；
版本：
缺陷所属模块：
是否可重现：
严重度：缺陷的严重程度；
优先级：缺陷修复的优先级；
缺陷状态：一般初始状态为new；
指派给：选择修改缺陷的开发人员；
Bug复现步骤：描述Bug出现的详细过程，即：
1.URL、用户名、密码；
2.操作步骤；
3.预期结果；
4.实际结果；
5. Bug截图
bug状态
NEW：所有提交到开发对接的问题状态为NEW，表示为未处理
OPEN：开发对接人初判为需流转问题，指定测试人员和开发人员，状态为OPEN。
REFUSE：开发对接人判断为不需要流转至下环节的问题，状态为REFUSE，并且填写原因
FIXED：开发人员完成修复，待测试，状态为FIXED
REOPEN：测似人员针对开发人员的修复结果测试部通过，状态为REOPEN
CLOSE：测试人员判断问题为需求或其他问题，需填写原因；
非代码类问题处理完成
BUG类问题，测试通过
bug管理流程
下面是一个简单的bug生命周期图，每个公司的可能不一样，比如，有歧义的可能指派给需求。
另一个更复杂的流程：Y**项目缺陷管理流程
测试基础【第七篇】测试报告
Y**项目系统测试报告
涉及敏感信息，只能分享目录
Y**项目UAT测试报告
其它【第一篇】兼容性测试
其它【第二篇】敏捷测试
==============================================
> > > 声明：部分转载、整理自网络，如有侵权，请联系删除。
==============================================
==============================================
测试的流程，可以遵循“计划→设计→实现→执行”这几步，细分下来是：
0、成立测试组：根据团队需要具备的技能树来组件团队
1、测试需求评审：分析测试需求
2、制定测试方案：包含计划、规程、方案等，
参考：https://www.cnblogs.com/UncleYong/p/10967722.html
3、提取测试需求：分解测试需求为测试点（思维导图）
4、编写测试用例：根据测试点编写测试用例，包含正向用例、反向用例，
参考：https://www.cnblogs.com/UncleYong/p/10967497.html
5、搭建测试环境：根据系统架构，搭建测试环境，初始化基础测试数据
6、执行冒烟测试：选取优先级高的用例执行
7、执行测试用例：系统测试
8、跟踪回归缺陷：跟踪自己提交的缺陷，及时回归，如果通过，更改缺陷状态。缺陷生命周期，
参考：https://www.cnblogs.com/uncleyong/p/10967748.html
9、输出测试报告：
参考：https://www.cnblogs.com/uncleyong/p/10967872.html
Y**项目测试方案
涉及敏感信息，只能分享目录
测试用例的要素
测试用例编号 测试标题 所属模块 测试需求项编号 案例状态 预置条件 优先级 测试输入 操作步骤 预期输出 实际结果 案例设计者 设计日期 案例性质
用例设计方法
等价类
找出发现bug效果一样的一个组合。分为有效等价类和无效等价类。
步骤：1.划分等价类；2.确定测试用例；
举例：输入三角形三边应为正整数，分别构成非三角形、一般三角形、等腰三角形和等边三角形。
需求分析：1.正整数；2.两边之和大于第三边；3.两边相等；4.三边相等。
等价类设计
边界值
大量bug集中在输入的边界上，边界值和等价类互补。
边界值：
上点：边界上的点，不管是开还是闭区间
离点：距离上点最近的点，闭区间离点在外，开区间离点在内
内点：边界内的任意一点，可以采用折中的方法确定内点
步骤：1.划分等价类（可选）；2.分析样点；3.确定测试用例。
判定表
增强条件与结果之间的逻辑性，弥补等价类的不足，判定表无法直接生成测试用例，而且条件得到什么结果需要手工处理。
步骤：1.标识输入和输出；2.构造判定表；3.逐列分析条件项组合，填入其动作项；4.简化判定表（可选）；5.生成测试用例。
因果图
因果图，得到条件和条件、条件和结果的逻辑关系，可以通过与或非运算直接得到测试规则，然后合并，最后通过等价类、边界值抽取测试用例。
步骤：1.标识输入和输出；2.画出因果图；3.将因果图转换为判定表；4.简化判定表（可选）；5.生成测试用例。
条件与结果：恒等、非、或、与
条件与条件：异、唯一、要求、或
1.E约束（异）：所有输入中至多一个输入条件发生。（<=1，也可以没有）
2.I约束（或）：所有输入中至少一个输入条件发生。（>=1）
3.O约束（唯一）；所有输入中有且只有一个输入条件发生。（=1）
4.R约束（要求）：所有输入中只要有一个输入条件发生，则其它输入也会发生。
正交试验
确定需求中因子及所对应的状态的个数
因子与水平相等：直接查找正交表，使用取值进行替换
因子不等：查找比因子稍大的正交表，选取行数最小的，将最后多出的因子空闲，不做替换
水平不等：查找水平稍大的正交表，选取行数最小的，将多余的水平留着，在抽取用例的时候根据均分原则替换
因子和水平都不相等：查找比因子、水平都稍大的正交表，选取行数最小的，根据上述方法选定正交表
最后，需要根据经验进行用例的补充。
《常用正交表对照图》，加Q群获取
步骤：1.提取功能说明，构造“因子—状态”表；2.加权筛选，生成因素分析表（删除重要性较小的因子或状态）；3.利用正交表构造测试数据集；4.利用正交表每行数据构造测试用例。
流程分析
涉及流程的，都可以用流程分析，能将系统功能进行串联，但是流程没问题不表示功能没问题
流程分为正常流程和异常流程
步骤：1.画出业务流程图；2.定义状态节点和条件分支；3.确定测试路径（每个流程构成一个测试用例）；4.选取测试数据，构造测试用例。
异常分析
断电、断网、硬件故障等。
步骤：1.针对系统罗列可能的故障；2.针对每种可能故障设计测试用例。
bug的要素
为了让开发人员更准确、更快的看懂Bug，测试需要按照一定的规范提交bug。
缺陷id：一般由缺陷管理系统自动生成；
缺陷标题：概要描述缺陷；
发现人：一般是缺陷管理系统自动获取当前用户；
发现时间：一般是缺陷系统自动获取当前系统时间；
版本：
缺陷所属模块：
是否可重现：
严重度：缺陷的严重程度；
优先级：缺陷修复的优先级；
缺陷状态：一般初始状态为new；
指派给：选择修改缺陷的开发人员；
Bug复现步骤：描述Bug出现的详细过程，即：
1.URL、用户名、密码；
2.操作步骤；
3.预期结果；
4.实际结果；
5. Bug截图
bug状态
NEW：所有提交到开发对接的问题状态为NEW，表示为未处理
OPEN：开发对接人初判为需流转问题，指定测试人员和开发人员，状态为OPEN。
REFUSE：开发对接人判断为不需要流转至下环节的问题，状态为REFUSE，并且填写原因
FIXED：开发人员完成修复，待测试，状态为FIXED
REOPEN：测似人员针对开发人员的修复结果测试部通过，状态为REOPEN
CLOSE：测试人员判断问题为需求或其他问题，需填写原因；
非代码类问题处理完成
BUG类问题，测试通过
bug管理流程
下面是一个简单的bug生命周期图，每个公司的可能不一样，比如，有歧义的可能指派给需求。
另一个更复杂的流程：Y**项目缺陷管理流程
Y**项目系统测试报告
涉及敏感信息，只能分享目录
Y**项目UAT测试报告