私の会社は自動テストツールを購入しようとしています。私たちは大企業ではなく、ツールのライセンスを1つしか購入できません。テストされたOSが、クライアント（XP）または次世代OS（Windows 7）で最も一般的に使用されるものであるかどうかについては内部的な論争があります。とにかく、考えられるすべてのOSがテストされますが、規模ははるかに小さくなります。
開発のほとんどはPowerBuilderを使用して行われ、すべての開発マシンはXPを実行します。したがって、Vistaまたは7で提供される新機能は使用しません。これは、ソフトウェアが7で実行されている場合、XPでの実行に問題がないことを意味します。逆は別の話なので、適切にテストする必要があります。OTOH、メインのテスト環境がメインの本番環境であることは理にかなっています。
このような限られたリソースを考えると、どのOSにテストを集中させますか？
間違いなくメイン環境。
主なユーザー ベースが XP の場合、なぜ Windows 7 でのテストに時間を浪費するのでしょうか。はい、XP でテストしたら、必ず vista と 7 でもテストする必要がありますが、いずれかのテストを自動化するリソースしかない場合は、プライマリ プラットフォームに集中する必要があります。
アプリが Windows 7 で問題なく動作するからといって、XP でも動作するとは限りません。2 つの OS バージョンの間には無数の変更があり、壊れる可能性があります。理想的には、サポートするすべての OS でテストする必要があります。これは不可能かもしれませんが、主なことは、メイン ターゲットで動作することを保証することです。
古い「PowerBuilder 1 と Windows ベータ版」の話のほこりを払う時が来ました。覚えておいてください：私はそこにいませんでした.
Powersoft は、この主要なマーケティング スコアを獲得しました。彼らは Microsoft と提携して、Windows (3.0) の新しいリリースと同じ日に新しい製品 PowerBuilder をリリースしました。Microsoft は、彼らが構築したこのプラットフォームが、グラフィックス プログラムやマインスイーパだけでなく、カスタム基幹業務アプリケーションに適していることを証明しようとしていました。そのため、Powersoft は Microsoft から最後のリリース候補を取得し、PowerBuilder を徹底的に打ち負かしました。彼らは満足していました。発売当日、ビジネスマンは、片方の腕に Windows を、もう片方の腕に PowerBuilder のコピーを持って、コンピュータ ストアから歩いていました。その後、電話がかかってきました。PowerBuilder は深刻な問題を抱えており、痛ましいほど明白でした。Microsoft は、リリース候補版と PowerBuilder を屈服させた一般提供バージョンとの間で何かを変更しました (おそらくバグを修正する目的で)。Powersoft は修正で迅速に対応しましたが、その後何日もの間、多くの赤い顔がありました.
この話の教訓: ベータ版に対するテストは、実質的に何の意味もありません。10 月 22 日以降の計画を立てているのでない限り、Windows 7 で大ざっぱなテストを行う以上のことを計画すべきではありません。実際のWindows 7 が出荷されたときにテストを最初からやり直す必要があるからです。
幸運を、
テリー。
サポートするものをテストします。その後、近い将来にサポートする必要があるものをテストし、最後に、開発者に「最先端」のエッジ/ベータ/rtm/アルファ OS をテストさせます。
たとえば、XP をサポートしている場合、それがテスト用のメイン OS であり、適切に行われている場合、その OS をテストするためのリソースは最小限に抑える必要があります。次のリリースで Vista がサポートされている場合は、Vista をテスト ループに入れて、優先順位。
Windows 7 をサポートする必要がある場合は、開発者に最初の実行を任せてください。何らかの「コーディング」が必要になる可能性があり、自動テストが機能しなくなる可能性があります。許容できるレベルの品質になったら、テスト ループに持ち込みます。
Windowsのリリースは、最初の2、3のサービスパックまでは一般的に不安定です。今すぐジャンプするということは、ソフトウェアをテストしているだけでなく、テストされていないシステムでもテストしていることを意味します。バグがある場合、それが自分のプログラムなのか新しいOSなのかをどうやって知るのでしょうか。
あなたの顧客は今後しばらくの間XPを利用するでしょう（Vistaのおかげでそれはまだ人気があります）。あなたが知っていることで行きなさい。
その上、おそらくウィンドウキャンディーや通常の肥大化よりもコンパイラーやツールに使用できるRAMを1〜2ギガ節約できます。
ばかげているように聞こえるかもしれませんが、両方をテストしてください。我慢してください。
ソース管理からソフトウェアのクリーン ビルドを実行できる自動ビルド プロセスを用意することから始めます (ソース管理がありますよね?)。自動テストを追加します。これには、低レベルの単体テストから統合テスト、TestCompleteやSmarteScriptなどを使用した無人機能テストまで、すべてが含まれます。これで、人間の介入なしで製品全体 (または少なくとも重要な部分) をテストできるようになったので、これらのテストを何度でも実行できます。
典型的なクライアント PC を表すクリーンな仮想マシンを作成します。あなたの開発ボックスは、おそらくこれの良い例ではありません。自動ビルド プロセスの一環として、仮想マシン (少なくとも VMWare と VPC) をスクリプト化して、既知の正常なスナップショットから開始し、ソフトウェアの最新ビルドをインストールし、自動テストを実行して結果を公開できます。
それが難しい部分でした。次に、オペレーティング システム、サービス パック、メモリなどを任意に組み合わせて新しい仮想マシンを作成し、それぞれに対して自動テストを繰り返すだけです。
非常に多くのプロセスを追加しているように聞こえます。あなたが実際に行っているのは、自動化できる (そして自動化すべき) すべてのことを手放すことであり、より興味深いもの (それを自分自身に売り込む方法) と収益性 (自分にそれを売る方法) に多くの時間を割くことができます。上司）もの。
それ以外の場合は、ほとんどの顧客が使用している OS に対してテストし、免責事項を含めてください。