なぜプログラマーにはテストが必要なのでしょうか?
次の 2 つのレベルは、プログラマーが必要とする方法でのテストに専念します。まずは、テストとは何か、なぜテストが必要なのかを見てみましょう。
ソフトウェアに関して言えば、テストのタスクはプログラムが次のことを行っているかを確認することです。
- 彼女はやるべきことをやる
- 彼女はしてはいけないことをしない
ちなみに、2 番目のポイントは最初のポイントと同じくらい重要ですが、それについては後で詳しく説明します。
最初のポイントから始めましょう。「プログラムは本来の動作を行う」とはどういう意味ですか?
まず、誰かがプログラムのすべての使用例のリストを作成する必要があります。 次に、プログラムがどのように動作するか、ユーザーがどのように動作するか、どのような結果が期待されるかを説明する必要があります。これ以上続行することはできません。
「ユーザーがどのように行動すべきか」を書いたとたんに、良いドキュメントを書くという考え自体が崩れ去ってしまいました。人間は機械ではありません。さらに、人間はソフトウェアを使って自分の思い通りに行動することがよくあります。説明書を勉強することからテクノロジーを知り始める人はいません。事実です。
したがって、このソフトウェアの特徴は、さまざまな作業シナリオが多数あるということです。それらのうちのいくつかは明白であり、その他は文書化でき、その他は推測でき、その他は推測できますが、残りの 50% は思いつきません。
プログラマの観点から見ると、ほとんどのバグはまったくバグではありません。エラーとは、プログラムが期待どおりに動作しないことです。そして、プログラムがどのように機能するかが明確でない場合や、シナリオが互いに矛盾している場合もたくさんあります...
シナリオは無限にあり、製品内にはプログラムが期待どおりに動作しないケースが常に存在します (プログラマーがコードを作成したのは数十のシナリオのみです)。したがって、どのプログラムにも常にバグが存在し、どの製品も際限なく改良できると言えます。
その後はすべてご都合主義になります。最初にプログラマーは最大のバグを修正し、次に小さなバグを修正するというように続きます。そして最終的には、製品の所有者が、その製品の開発を続けるのは経済的に不可能であると考える段階が来ます。
しかし、誰もがエラーとして認識しているエラーに戻りましょう。プログラムが明らかに何か間違っている、落ちた、何かを壊した、などです。このようなエラーは、条件に応じて大、中、小の 3 つのカテゴリに分類できます。
プロジェクトにはさらに深刻な問題がまだたくさんあるにもかかわらず、プログラマーが中程度のバグや小さなバグの修正に取り組んでいることがよくあります。彼はそれらを見つけられなかっただけで、彼が知っている最大のものに取り組んでいます。
したがって、どのプロジェクトにもテスターが必要です。これらの人々は、製品をさまざまな角度から見ることを特に学びます。したがって、プログラムのより多くのシナリオを見ることができます。彼らの仕事は、エラーを見つけてそれを書き留めることです (同じエラーが何度も見つからないように)。
テストは、エラーを発見することを目的としたプロセスです。これらのバグは見つけて説明し、優先順位を付ける必要があります。エラーに優先順位を付けて初めて、効果的なソフトウェア改善プロセスについて話すことができます。
問題を解決するための最初のステップは、問題があることを認識することであることを忘れないでください。知らない間違いを修正することはできません。
テストの自動化
テストが重要であるという点では全員が同意したと思います。プログラマーと同じようにテストを見てみましょう。プログラマーはテストをどのように見ていますか? プログラマーは他の人の作業を自動化します。最後に消える職業はプログラミングの職業でしょう。
私たちは遭遇するすべてのプロセスを自動化します。したがって、テストを自動化する必要があります。そして、エラーの検索を自動化するにはどうすればよいでしょうか? 短い答え: いいえ。しかし、ここでも私たちがプログラマーであるという事実が役に立ちます。
ソフトウェア開発プロセスは、継続的な変更で構成されます。プログラマーは、絶えず変更を加える過程で、つい最近まで問題なく動作していたものを壊してしまうことがよくあります。
そしてテスターは、新たなエラーを探す代わりに、長い間正常に動作していたものが壊れていないかどうかを常にチェックする必要があります。いわゆる回帰テスト。この種のテストは自動化できるし、自動化する必要があります。
ここで、すべてのソフトウェアは 2 つの部分に分けることができます。
- プログラムは人と対話します
- プログラムが別のプログラムと対話する
最初のオプションは自動化がより難しく、特別な自動化テスト担当者が必要です。彼らは QA オートメーションまたはソフトウェア テスト エンジニアとも呼ばれます。
ただし、2 番目のオプションは独立して自動化できますし、そうすべきです。次のようなソフトウェアをお持ちの場合:
- うまくいきます
- すでにテスト済み
- 別個のモジュールまたは論理ブロックとして実装される
- 変えるつもりはない
- 他のモジュールまたはプログラムはそれに依存します
- 機能障害は高くつく
時間をかけて、現在の機能の重要な側面をキャプチャするテストを作成することをお勧めします。作業時間の 5% 、つまり月に 1 日をこのために割り当てるのが合理的です。
テストのためにテストを書く必要はありません。
誰もあなたのテストをサポートしません。他のプログラマーでも、あなた自身でもありません。誰もそんなことしませんよ。すべての筆記試験の 99% が放棄されたり、無効になったりします。テストを作成できない場合は、テストを作成しないでください。絶対にそれなしではやっていけない場合にのみ書いてください。
テストの種類
各プログラマは、特別な訓練を受けていなければ、テストとは何か、つまりプログラムが期待通りの動作をするかどうかをチェックすることを自分の言葉で説明できるでしょう。ただし、この分野の専門家は、テストの領域全体 (種類) を区別します。
すべてのテストは実際にはソフトウェアの信頼性と可用性を中心に展開しますが、テストの方向性をよりよく理解するために、いくつかの例を見てみましょう。
典型的なオンライン ストアをテストしているとします。テストの領域は、パフォーマンス テスト、機能テスト、統合テスト、単体テストの種類に分類できます。
サイト所有者が本格的な広告キャンペーンを開始すると決めた場合、多くのユーザーが同時にサイトにアクセスすることになります。サイトが落ちることはないかもしれませんが、そのセクションの一部が遅くなったり、動作しなくなったりする可能性があります。
このような事態を防ぐためには、そのような問題を事前に特定し、解決するための措置を講じる必要があります。これは負荷テストを使用して行われ、パフォーマンス テストとも呼ばれます。
また、バックエンド API がどのように動作するかをテストし、そのすべての機能 (登録、ログイン、カートへの追加、支払い処理、データベースへの書き込みなど) をテストすることもできます。すべてが TOR に従って機能する必要があります。この場合、機能テストを実行する必要があります。
オンライン ストアは、手紙や SMS の送信、支払いシステム、オンライン サポート チャット、ユーザーからのフィードバックの収集、広告システムなどのサードパーティ サービスと統合されている可能性が高く、これらすべてが意図したとおりに機能することを確認するには、統合テストを行う必要があります。。
最後に、複雑な製品は多くの場合、独立したモジュールに分割されます。このようなモジュールから、コンストラクターと同様に最終製品をアセンブルできます。このようなモジュールを開発している場合、またはそのようなモジュールと対話している場合は、単体テストを行う必要があります。
要約すると、サイトの個々の機能をテストするには機能テストが必要であると言えます。統合 - 製品の大規模なモジュールとシステムの相互作用をテストします。モジュラー - 個別のモジュールをテストするため、つまりパフォーマンス テスト - 負荷がかかった状態でのサイトの動作をチェックします。
テストの種類はさらに多くなる可能性があります。製品が複雑になるほど、開発のより多くの側面を制御する必要があります。