Learn QTP (UFT)
私たちの創設者である Ankur Jain は、約 14 年前の 2006 年にこの Web サイトを開始しました。 QTP ツール (QTP は元々 Mercury 社の自動ソフトウェア テスト ツールです) での豊富な経験があったからです。 QTPは元々Mercury社の自動ソフトウェアテストツールで、現在はUFT Oneとして知られています）についての豊富な経験から、彼はこのウェブサイトをQTP学習者のためのワンストップショップにしたいと考えたのです。
このサイトを立ち上げたときから、QTPの世界ではいくつかのことが変わりました。 HP は、QTP を開発したオリジナルの会社である Mercury を買収しました。 HP が GUI テストと API テストを単一のツールに統合することを決定したとき、QTP は UFT になりました。 QTPとUFTの歴史はこちらをご覧ください。 HPは、HP IncとHPEの2つの会社に分割されました。 その間、HPEはUFTソフトウェアにいくつかの新しいイノベーションを導入しました。 2017 年 9 月、HPE は Micro Focus に合併されました。
LearnQTPのチームは、私たちの古い記事はまだ適切ですが、UFTの最新バージョンのための新しいUFTチュートリアルのセットが必要であることに気づきました。 そこで、UFT の初心者から上級者までを対象とした、新しい UFT チュートリアルのセットを開始しました。
これらの UFT チュートリアルは、自動ソフトウェア テストの全くの初心者でもフォローできるような方法で構成される予定です。 チュートリアルは自分のペースで進められるので、プレッシャーはありません。 リンクをブックマークしておけば、学びたいと思ったときにいつでも戻ってこられます。 各記事の下にある無料の UFT チュートリアルの PDF をダウンロードすることもできますので、旅行中やインターネットに接続していないときでも学習できます。
UFT に飛び込む前に、ソフトウェア テストとソフトウェア テストの自動化の方法と時期についての入門書に目を通しておきましょう。
著名なソフトウェア テスティング専門家である Cem Kaner 博士は、ソフトウェア テストを次のように定義しています:
関係者に品質関連の情報を提供するために行う、テスト対象の製品の技術調査
さらに説明すると、ソフトウェアのテスト担当者やチームはプログラムやシステムを実行してバグや不具合を探し、プログラムの正しさや信頼性を保持するプロセスです。
また、ソフトウェア テストでは、ビジネス要件と技術要件を満たし、期待どおりに動作しているかどうかを確認するために、プログラムを検証します。
検証では、テスト担当者はシステムが組織の標準とプロセスを満たしていることを確認し、「正しいシステムを構築できたか」という質問に回答します。 システムとは、ビジネス機能をサポートする 1 つまたは複数のソフトウェア アプリケーションを意味します。
検証では、テスト担当者は、システムがすべてのビジネス要件とユーザー要件を満たしていること、および、特徴と機能が設計どおりに動作していることを物理的に確認します。 検証は、テスト担当者が観察および評価できる一連のテストを通じて、システムの機能を実行することによって行われます。 また、検証は、「システムを正しく構築できたか」という質問に集中します。
なぜソフトウェア テストを行うべきなのか
ソフトウェア テストでは、主な目的は不具合を発見することです。 ある状態が、期待されることを満たしていない場合、欠陥であると考えることができます。 ソフトウェア開発の早い段階でテストで欠陥を発見することにより、障害のリスク、メンテナンス コスト、欠陥修正のコストを削減または回避し、ユーザーによりよいプログラムを提供することができます。 Docket Number は 12 文字の数字を受け入れる必要があります。 入力された文字が必要な文字より少ないか多い場合、「Invalid Entry. Please re-enter the Docket Number」と表示しますが、ユーザーは訴訟事件番号に 10 文字を入力したため、プログラムは必要な最小限の文字についてユーザーに通知するプロンプトではなく、例外エラーを返しました。
もう 1 つの理由は、高品質のプログラムを作成することです。 ソフトウェア テストでは、ソフトウェア テスター/チームは品質を向上させることはできませんが、測定することだけはできます。 IT 部門の視点から見ると、品質とは、ビジネス要件と技術要件に基づくプログラムの要件の適合性と機能が満たされていることを意味します。 ユーザーの視点からは、品質とは、ソフトウェアが使用に適していることを意味する。 ソフトウェアの品質は、プログラムごとに機能や使い勝手が異なるため、プログラムごとに異なります。
自動ソフトウェア テストとは
自動ソフトウェア テストでは、テストを行うテスト スクリプトを書くことによって、手動プロセスを自動化し、繰り返し実行できます。
テストの自動化は、テストの実行、実際と期待される結果の比較、前提条件の設定、その他のテスト制御およびテスト報告機能を、ソフトウェアを使って制御するために使用されます。
テストの専門家の間でよく見られる信念は、自動化は何らかの魔法によってテストの質を高めるというものです。 もしテストが自動化できるなら、それは自動化するべきだということではありません。 このサイトは自動テストのサイトですが、私たちは手動テストを否定していると思われるかもしれません。 しかし、そうではありません。
クリックでツイート。
手動テストと自動テストは手を取り合って行うものであり、互いに補完し合うものであるべきです。
自動化が最適とされるシナリオをいくつか紹介します:
- 回帰テスト/繰り返しテスト。 手動テストから自動テストに切り替える際の経験則として、テストを定期的に実行する必要がある場合、それらは自動化の良い候補となります。 ただし、これにはいくつかの注意事項があります。 自動テストの設定にかかるコストを、手動テストの取り組みと比較検討する必要があります。 このコストには、自動化の複雑さ、自動化スクリプトの構築と保守に必要な時間、そしてもちろん、与えられたツールでテスト担当者を訓練するために必要な時間と費用が含まれます。
- 複数のデータ値: 複数のデータ値に対して、同じアクションのセットを実行する必要があります。 あなたのアプリケーションは、数時間のうちに100万ヒットのストレステストを行う必要があります。 手動で行うことはできませんので、負荷テストツールが必要です。
- 異なるブラウザーまたは OS で同じテスト。 あなたのウェブアプリケーションは、一般的に使用されるすべてのブラウザーとオペレーティングシステムで良好に見えるようにしたいと思うでしょう。 50 のテストケースを含むテストスイートがあり、3 種類のブラウザーと 2 種類のオペレーティング システムで 20 の異なる値のセットでテストする必要がある場合。 この場合、テストの総実行回数は 50*20*3*2= 6000 回になります。 このようなテストケースを自動化することは理にかなっています。 市場で入手可能な携帯電話の数が膨大であるため、すべてのデバイスで手動テストを実行することは不可能に近いでしょう。 Amazon のような企業は、この問題に対する革新的なアプローチを考え出しました。つまり、実際のデバイスをクラウドに置き、自動化されたスクリプトでデバイス上でアプリケーションをテストできるようにしたのです。
ソフトウェア テストに関するこの入門書を気に入っていただき、与えられたシナリオに対してソフトウェア テストの自動化をどのように決定するかを理解していただけたと思います。 次のチュートリアルでは、UFT のインストールから始めて、このツールの基本について説明します (チュートリアル 2: UFT の紹介)。
以下のリンクから、これまでにカバーした UFT チュートリアルの完全なセットを参照できます:
- Tutorial 1: Introduction to software testing
- Tutorial 2: Introduction to UFT
- Tutorial 3: UFT Add-ins and Add-in Manager
- Tutorial 4: UFT の基礎
- Tutorial 3: UFT のアドイン
- Tutorial 4: UFT の基礎
以下にあなたの名前と電子メールを入力すると、準備ができ次第、必ずチュートリアルを送信します
– UFT メニューをすべて見ることができます。
お待たせしました。
UFT(QTP)に関するさらなる記事を追いかけたい場合は、こちらをご覧ください。 I recommend you to subscribe by Email and have new UFT articles sent directly to your inbox.