この記事を書く目的は、新しいテスターがソフトウェア テスト業界とその発展の見通しをよりよく理解できるようにすることです。初心者が業界について何も知らなくても、ソフトウェア テスト業界に簡単に参入できるようにします。
1. ソフトウェアテストエンジニアの責任
テクノロジーの発展により、時代に合わせてさまざまなアプリやアプリが登場しています！初期の頃、これらのアプリケーションは開発者、製品、および一部のユーザーによってのみ使用され、対応する改訂意見が与えられました。OK と感じた後、オンラインに移行しました。インターネット上で直接使用することも、一部のアプリ ダウンロード プラットフォームで使用することもできました。仕様なしでソフトウェアテスト! これらのソフトウェアには多かれ少なかれバグがあり、これらのバグは機能、互換性、パフォーマンスなどに問題がある可能性があります。
ソフトウェアの品質が低いという問題を改善するために、ソフトウェア テスト業界が注目され始めています。ソフトウェア テストの目的は、ソフトウェアの品質を向上させ、ユーザーにより良いエクスペリエンスを提供することです。
ソフトウェアテストエンジニアは、製品の機能要件を理解し、テストし、ソフトウェアに欠陥（バグ）がないかどうかを確認し、ソフトウェアの安定性（堅牢性）、セキュリティ、操作性などをテストし、対応するテストを作成します。仕様とテストケースの専任スタッフ。
ソフトウェアテストエンジニアの責任:
1. 要件文書と設計文書に従ってテスト ケースを作成します。
2. 製品統合テストとシステムテストを完了する。
3. テスト計画に従って、テスト環境を構築します。
4. テスト ケース、フィードバックに基づいて手動テストを実行し、製品のバグとユースケースの欠陥を追跡します。
5. テストツール/システムの研究と応用。
第二に、ソフトウェアテスト業界の特徴
私の周りにはソフトウェアテストに転職した学生が多く、「なぜソフトウェアテストエンジニアなのか？」とよく聞かれます。私は面接でよくこの質問をしますが、その答えは大きく2つに分類できます。
この仕事はテストが好きです。IT の給料は高く、IT の分野で働きたいですが、プログラミングの方法がわかりません。テストの敷居は低いです。テストの仕事が好きな同僚はとても尊敬していますし、私もコンピュータが好きでテストの敷居が低いのでテストファミリーに加わりました。その後、テストによってもたらされる達成感を楽しみ、問題を一人で見つける喜びを楽しみます。
参考までに、いくつかのソフトウェアテスト専門職の特徴を簡単に整理してみました。
迅速な入社、高給与、比較的低い学業敷居、高い市場需要、低い雇用競争、長いキャリアライフ、広い開発スペース 3. ソフトウェアテストの開発
テスターの開発は、自分の作業のテストに限定されない、広い意味で大きく分けて6つの方向性があります。さまざまな開発方向を決定する 3 つのコア スキル要素があります。
ビジネス開発、マネジメント開発、テスト開発の 3 つのコア要素。
事業開発
事業開発は品質とスピードの追求をもたらし、それが業界全体の発展の本筋です。事業開発のニーズは製品開発とテストに影響を与え、資本家と同じくらい貪欲で、常にボトルネックの突破とより迅速で優れた開発を追求しています。研究開発、製品、QA はすべて、多くの企業の死活と、多くの業界のエンジニアの将来を決定します。
技術開発
テクノロジーは生産性にとって重要な要素であり、テクノロジーの開発は加速しています。質的な変化は必ず大きな変化をもたらし、テクノロジーの成熟度によってテスト業界がどれだけの成果を達成できるかが決まります。テスト エンジニアは、現在のテクノロジー スタックを使用して、現在のニーズを満たすソリューションを作成することに長けていなければなりません。
経営開発
会社本体はシンプルかつ効率的な経営を追求し続け、テクノロジーとツールの進化は組織のコミュニケーション能力の向上を意味します。経営の方向性は徐々にフラット化し、上級管理職の数はますます減り、現場の管理職がますます増えます。検査業界の恥ずかしいことの一つは、大規模な品質部門モデルが消滅し、検査業界の発展が頭打ちになっていることであり、研究開発と製品が維持できなければ、検査業界の発展はあり得ません。上手に進めることができます。
3 つのコアスキルの習熟度およびそれらの交差点に応じて、それらは大まかに 6 つのカテゴリに分類できます。
管理部門: テスト監督者、テスト マネージャー、プロジェクト マネージャー、品質マネージャー、テクニカル サポート マネージャー、プリセールス テスト マネージャー テスト技術部門: シニア テスト エンジニア、テスト テクニカル エキスパート、テスト コンサルティング、テストのアウトソーシング、職業教育およびトレーニング ビジネス技術部門:開発者、システム分析エンジニア、需要分析エンジニア、ソリューションエキスパート、市場調査および製品企画、業界テストエキスパート技術サポートの方向性: プリセールスサポート、テクニカルサポート、カスタマーサービス、顧客トレーニング、社外の問題解決品質保証の方向性: QA、品質監査担当者、品質改善担当者、リスク分析担当者などの指示：文書作成、営業担当者、販売前テスト、マーケティング担当者、プロジェクト保守担当者は主要な方向性の具体的な方向性を示すだけであり、上司と部下は特定されない各方向・位置間の上下関係
4番目に、ソフトウェアテストのプロセス
開発でもテストでも需要側があり、需要側とコミュニケーションをとり、情報を統合し、需要仕様を策定していきます！要件仕様: ソフトウェアの機能、パフォーマンス、互換性、UI などに関するユーザーの要件のテキストを指します。開発 要求仕様に合わせてプログラムを開発・設計！しかし、一部の企業では要件仕様書が提供されておらず、ほとんどの企業はこの部分で不定期に会議や設計モデルを要件として使用していますが、その目的は要件が明確ではないことと、コミュニケーションコストが高すぎることです。
以下は、より厳密または標準化されていると思われるテスト フローチャートです。
五、ソフトウェアテストの分類
方法による分類:
ブラックボックステスト: 通常、機能をチェックするために、内部構造は見ることができないと理解されています。ホワイトボックステスト: 内部構造を確認し、内部コードを検出できます。グレー ボックス テスト: ブラック ボックス テストとホワイト ボックス テストを組み合わせたもの。方向別に分類:
機能テスト: ソフトウェアの機能をテストします。パフォーマンス テスト: ストレス テスト、負荷テスト、同時実行テストなど。セキュリティテスト: ソフトウェアのセキュリティをテストします。段階ごとに分類：
単体テスト：メソッド、関数、クラス統合テスト：インターフェースシステムテスト：機能、パフォーマンス、セキュリティ、互換性、ユーザビリティ、安定性、UIなど 受け入れテスト: 受け入れはオブジェクトによって分類されます。
アプリテスト Webテスト IoTテスト。。。ステータスごとに並べ替えます:
静的テスト: ホワイト ボックス テストに従ってコードをテストする 動的テスト: ブラック ボックスまたはグレー ボックスに従ってテストする その他:
スモークテスト: テスト前のテスト。ソフトウェアがテスト不可能であることを検出するためのものと思われます (ランダムテストでは問題があることがわかります) 回帰テスト: テストで発生した問題をフィードバックした後、問題を再テストします。αテスト：社内テスト βテスト：公開テスト 6. ソフトウェアテスト入門
1. ソフトウェアテストのライフサイクル
テスト要件分析 --> テスト設計 --> テスト計画 --> テスト実行 --> 品質評価
2. ソフトウェアテストの基礎
ソフトウェアテストにおいてテストの基礎は最も重要であり、テストを行う以上、どのような種類のテストであっても、テストの基礎と理論的な知識を習得する必要があります。
ソフトウェアテストの定義: ソフトウェアの正確性、完全性、安全性、品質の検証を容易にするために使用されるプロセスについて説明します。言い換えれば、ソフトウェア テストは、実際の出力と期待される出力をレビューまたは比較するプロセスです。
ソフトウェア テストの古典的な定義は、指定された条件下でプログラムを動作させてプログラム エラーを見つけ、ソフトウェアの品質を測定し、設計要件を満たせるかどうかを評価するプロセスです。
テスト方法: ソフトウェア テストは、手動または自動の手段を使用してソフトウェア システムを実行または測定するプロセスであり、その目的は、指定された要件を満たしているかどうかを確認すること、または期待される結果と実際の結果の違いを明確にすることです。
ソフトウェアの内部構造や具体的な実装を気にするかどうかという観点から、テスト方法には主にホワイトボックステストとブラックボックステストがあります。ホワイトボックステスト手法には、主にコード検査、静的構造解析、静的品質測定、ロジックカバレッジ、基本パステスト、ドメインテスト、シンボルテスト、パスカバレッジ、プログラムバリエーションなどが含まれます。ブラックボックステスト手法には主に、同値クラス分割法、境界値分析法、誤差推測法、特性要因図法、デシジョンテーブル駆動法、直交実験計画法、関数図法、シナリオ法などが含まれます。
テスト方法はプログラムを実行するかどうかの観点から静的テストと動的テストに分けられます。静的テストには、コード検査、静的構造解析、コード品質測定などが含まれます。動的テストは、テスト ケースの構築、プログラムの実行、プログラムの出力結果の分析の 3 つの部分で構成されます。
ソフトウェアテスト計画書：ソフトウェアプロジェクトのテスト計画書とは、ソフトウェアテストの目的、範囲、方法、焦点などを記述した文書です。テスト計画文書を作成することは、ソフトウェア製品の許容性を検証するのに便利な方法です。
優れたテスト計画は次の役割を果たすことができます。
テスト作業を全体的な開発作業と統合します。リソースと変更は、事前に管理可能なリスクと見なされます。テスト計画: テスト戦略はテスト計画の一部です。
テスト計画とは、要件をテストの観点から分析または分解し、その方向に向かってどのようにテストを行うかを規定するもので、分析結果がテストポイントやテスト方法となります。
テスト計画には以下が含まれます。
はじめに（a、執筆目的、b、想定される読者、c、参考資料を含む）、テスト範囲、テスト戦略（異なるテストの種類に応じて異なるテスト方法を検討する） テストケース作成のための全体的な書き方のアイデア：ブラックボックステストケース（優先度） + ホワイトボックス テスト ケース (補足) = 完全なテスト ケース
全体的な記述戦略: テスト ケースの記述には、基本的に、同値クラス、境界値、直交実験手法、エラー推論手法の 4 つの一般的に使用される手法で十分です。これにシナリオ テスト手法、要件/設計変換手法が追加されます。探索的テストのアイデアは、ほとんどの製品のテスト。個々の製品は、ある時点でまだ洗練され、拡張される必要があり、現状で議論する必要があります。
バグの定義: 製品マニュアルではやるべきことが規定されているが、ソフトウェアではそれが実装されていない (例: 製品マニュアルでは電卓に加算、減算、乗算、除算の機能を実装するよう要求しているが、作成された電卓は除算演算を実行できない)。これはバグです。製品のマニュアルで「してはいけない」と規定されているが、ソフトウェアがそれを実現している例：製品のマニュアルでは、電卓には加減乗除以外の機能を実装しないようにと規定されている 作成された電卓は、加算、減算、乗算だけを実行することはできませんと除算は、べき乗または三角関数の計算も実行できますが、これもバグです。製品マニュアルには記載されていないことですが、ソフトウェアは実現しています。たとえば、製品マニュアルでは電卓に加算、減算、乗算、除算の機能を実装することが求められており、作成された電卓はべき乗計算も実行できます。バグ。製品マニュアルには記載されていないが、必ず行わなければならないことであるが、ソフトウェアはそれを実装していない 製品マニュアルには、計算機に加算、減算、乗算、除算の関数を実装する必要があるが、それについては記載されていない電池残量が少なくても正常に使用できますが、電池残量が少ないと計算機が間違ってしまうのもバグです。ソフトウェアは理解しにくく、使いにくく、非常に遅いです。エンドユーザーの観点からテスターが見る問題は一般的ですが、正しくありません。製品マニュアルでは、計算機に加算、減算、乗算、除算の関数を実装するよう要求しています。しかし、 、「プラス」ボタンが「と」で表される、または 1+1 の計算に 1 分以上かかるなど、ボタンで使用されているテキストまたはロゴが明確ではありません。これもバグです。バグの分類: 致命的なバグ: システムが要件を完全に満たすことができない、システムの実行が停止する、システムの重要な部分が実行できない、システムがクラッシュまたはハングするなど、システムが正常に実行されなくなります。
重大なバグ: システム要件または基本機能の実現に重大な影響を及ぼし、修正方法がありません (ソフトウェアの再インストールまたは再起動は修正方法ではありません)。システムが不安定になったり、データが破壊されたり、誤った結果が生じたり、一部の機能が実行できなくなったりすることは、日常業務において頻繁に発生する、または非日常業務において避けられない重大な問題であり、システムが主要なビジネス要件を満たせなくなります。性能、機能、または使いやすさが著しく低下します。
一般的なバグ: システムはビジネス要件を満たしますが、システムのパフォーマンスまたは応答時間が遅くなり、間違った中間結果が生成されますが、最終結果には影響しません。
低レベルのバグ: オペレーターにとって操作が不便または面倒になりますが、作業機能や重要な機能のパフォーマンスには影響しません。スペルミスやインターフェイスの不便な使用などの軽微な問題、または改善が必要な問題
BUG の 8 つの要素: 欠陥番号: 欠陥の一意の識別子 欠陥ステータス: 欠陥追跡プロセスの進行状況 欠陥タイトル: 欠陥の概要、問題の本質を説明する 再現手順: 操作を段階的に説明欠陥を再現する手順 重大度: 欠陥 ソフトウェア システムの影響度 優先度: 欠陥修復の重要性または緊急性 欠陥の種類: 欠陥の原因と部門に応じた種類 テスト環境: テスト環境の構成、オペレーティング システムとブラウザを含む BUG ライフ サイクル バグの送信 - バグの割り当て - バグの処理 - バグの確認 - バグのクローズ
新規、確認、解決、再検証、閉じる、再度開く
テストと開発プロセスの関係
ウォーターフォール: 現在のアクティビティが前のアクティビティの作業を受け取りながら、直線的に進みます。仕事の結果は検証する必要があり、上から下まで不可逆なので効率が悪く、間違いがあれば全てひっくり返してやり直す必要がある
企画→要件分析→設計→コーディング→テスト→運用保守
役割: ウォーターフォール モデルは他のすべてのモデルの基本フレームワークであり、ソフトウェア エンジニアリングにおいて重要な役割を果たします。
ウォーターフォール モデルは、ウォーターフォール モデルの各ステージが 1 回だけ実行されるため、線形シーケンスで進行するソフトウェア開発モデルです。
ウォーターフォール モデルでは、テスト フェーズはソフトウェアの実装後にあります。つまり、コードの完成後にテスト活動に十分な時間が確保されます。そうでないと、テストが不十分になり、顧客に欠陥が直接残ります。
V 字型: V モデルはよく知られたウォーターフォール モデルを改良したもので、左側が開発グループ、右側がテスト グループであり、1 対 1 の関係があります。
W 型 (ダブル V) W モデルは、V モデルを進化させたモデルです。実際には、開発は V、テストは並列 V です。W モデルは、V モデルと比較して、検証と確認の活動が増加します。ソフトウェアの各開発段階で同時に実行される必要があるため、W はテストと開発の並行関係を明確に示しています。
w モデルは開発とテストが一緒に行われ、テストもユーザーのニーズに基づいて行われるため、開発の完了を待ってテストする必要がありません。そのため、テスト設計をテストする際に、テスト設計を参照するだけでなく、開発の概略設計だけでなく、以前の需要分析なども参照してください。
スパイラルプラン作成→リスク分析→実装エンジニアリング（要件確認、ソフトウェア要件、ソフトウェア製品設計、設計確認・認証、詳細設計、開発、テスト）→顧客評価
特徴：
スパイラル モデルは、ウォーターフォール モデルとラピッド プロトタイピング モデルを組み合わせ、他のモデルでは無視されているリスク分析に重点を置いています。各スパイラルには、計画、リスク分析、実装エンジニアリング、顧客評価の 4 つのステップが含まれます (漸進的なプロセスに相当し、各 A スパイラルにはこれらが含まれます) PDCA：PDCAサイクルの意味は、品質管理をPlan（計画）、Do（実行）、Check（検査）、Act（処理）の4つの段階に分けることです。品質管理活動では、計画を立て、計画を実行し、その効果を確認し、成功したものは規格に組み込み、失敗したものは次のサイクルで解決することが求められます。この作業方法は品質管理の基本的な方法であり、企業経営の一般法則でもあります。
1. ガイドラインや目標の決定、活動計画の策定などの P (Plan) 計画。
2. D（Do）実行 既知の情報に基づいて、具体的な手法、計画、計画レイアウトを設計し、その設計とレイアウトに基づいて計画の内容を実現するための具体的な作業を実行します。
3. C（Check） 実行計画の結果を確認し、まとめ、何が正しくて何が間違っているかを区別し、効果を明らかにし、問題点を見つけます。
4. A（行為）処理、概要検査の結果を処理し、成功体験を肯定および標準化し、失敗の教訓を要約し、注目を集める。未解決の問題は次の PDCA サイクルに提出して解決する必要があります。
上記の4つのプロセスは一度実行して終了ではなく何度も繰り返され、1サイクルが完了するといくつかの問題が解決され、未解決の問題が次のサイクルに入るというように段階的に上昇していきます。
5W2H：Wで始まる5つの英単語とHで始まる2つの英単語から問題解決のヒントを見つけたり、発明のアイデアを見つけたり、設計アイデアを実行したりして新たな発明プロジェクトを発想することを5W2H法といいます。
(1) 何 - それは何ですか? 目的は何ですか? あなたは何の仕事をしていますか？
(2) なぜ - なぜそれをするのですか? やれないの？代替手段はありますか?
(3) 誰 - 誰ですか? 誰がやるの？
(4) いつ - いつ? 何時にやりますか？最適な時期はいつですか?
(5) どこ - どこ? どこでやるか
(6) どのように - どのように行うか? 効率を向上させるにはどうすればよいでしょうか? どのように実装すればよいでしょうか? 方法は何ですか?
(7) いくら - いくらですか? どこまで？量は何ですか? 品質レベルはどのくらいですか? コストアウトプットとは何ですか?
3. ツールの学習
テスト管理ツール: TestDirector (大規模で包括的)、jira (シンプルで使いやすい)、Quality Center (複雑、有料)、Zen Road (シンプルで使いやすい)、bugzilla (シンプルな機能)、svn (コードとドキュメントの管理)ツール)、vss svn、git に似ています。svn と同じですが、マルチブランチ管理が svn より優れています。Note (大規模で包括的、高すぎる)、CQ (ClearQuest-IBM 製品 - 大規模で包括的)。
インターフェイス テスト ツール: Jmeter (オープン ソース)、postman、SoapUI
パフォーマンス テスト ツール: ロードランナー、大規模で包括的ですが、熟練度を習得するのはまだ少し難しい、重量級のツール
C/S 自動化ツール: vb 言語を使用した qtp (録音再生とスクリプト編集)、winrunner IBM 製品は qtp に似ており、autoit はウィンドウの位置決めに非常に優れています。
ホワイト ボックス テスト ツール: jtest Java 言語単体テスト フレームワーク、JUnit 検証 Java ツール、cppunit クロスプラットフォーム C++ 単体テスト フレームワーク、gtest クロスプラットフォーム C++ 単体テスト フレームワーク、PhpUnit Php、BoundsChecker C++、Delphi API および OLE エラー チェック、Pointer およびリーク エラー チェック、メモリ エラー チェック、TrueTime C++、Java、Visual Basic コード実行効率チェック、コンポーネント パフォーマンス分析
継続的統合ツール: jenkins、Hudson
アプリ自動化ツール: appium これは、現在最も人気のあるアプリベースの自動テスト フレームワークとみなされます。instruments ios プラットフォームの下で、Java 言語で書かれた自動テスト フレームワーク、uiauTomator Android 自動テスト フレームワークは、基本的に Android のすべてのイベント操作をサポートします。 , Monkey Android の組み込みテスト ツールである Monkey Runner Monkey 改良版は、自作のスクリプト テストをサポートし、Python 言語を使用します。Robotium は海外の Android 自動テスト フレームワークであり、その使用方法は比較的簡単です。
Webセキュリティテストツール：appscan、よく使われるツールです
始めたばかりの場合は、ツールと知識ポイントを学ぶ必要がありますが、順番に学んでください。
単純なネットワーク プロトコル: TCP/UDP、HTTP/HTTPSLinux の基本操作と一般的な手順。MySQL データベースの基本操作と一般的な SQL ステートメント。フィドルキャプチャツールの使用。ポストマン インターフェイス テスト ツールの使用。jmeter および loadrunner パフォーマンス テスト ツールの使用。4. コード学習
プログラミング言語の選択については、Java または Python をお勧めします。マスターしなければならないデータベースもあります。
プログラミング言語を学びますが、開発ほど深く学ぶ必要はありません。たとえば、Java については、JavaSE の部分だけを学習すれば十分です。Python についても同様で、基本を学ぶだけです。
以上がソフトウェアテスト初心者が習得すべき知識とスキルツールであり、一次テストであれば問題ありません。
