64ビットWindowsで32ビットソフトウェアをテストする必要がありますか？

私はソフトウェア開発者としてソフトウェア開発チームで働いています。私は今、3年間同じプロジェクトに取り組んでいます。このソフトウェアは、.NET 4の32ビットデスクトップベースのC＃アプリケーションです。Windows7のターゲットプラットフォーム（昨年までWindows XPをサポートする必要がありました）。ソフトウェアは、カスタムドライバが記述されているさまざまなカスタムハードウェアと通信します。ハードウェアの製造とドライバーソフトウェアは、お客様が作成します。もちろん、32ビットと64ビットのWindows用に異なるドライバーがあります。

システムテストフェーズでは、32ビットと64ビットの両方のWindows 7ですべて/ほとんどのテストケースを実行します。Windowsの1つのフレーバーのみに存在するソフトウェアにバグがあるかどうかは思い出せません。このような経験があるので、64ビットWindowsで32ビットソフトウェアをテストする必要があるのでしょうか？

業界標準とは何ですか？

64ビットウィンドウで32ビットソフトウェアを実行する際に発生したバグのほとんどは、ソフトウェアの場所（Program Files (x86)ではなくProgram Files）、レジストリキーの場所（一部はWow6432Nodeで見つかりました）に関係していました。主に他のソフトウェア（32ビット）と通信する必要があるため、これらの問題が発生したため、32ビットと64ビットの両方でソフトウェアをテストする必要がありました...

これらの問題が発生していなかった場合、32ビットモードで明示的にコンパイルする場合、両方のプラットフォームでテストしないことは非常に安全だと思います。32ビットでコンパイルすると、.NETランタイムはすべてを32ビットモードで実行し、32ビットプラットフォームの32ビットモードと同じように動作するはずです。

64ビットアプリケーション（MSDN）によると、32ビットアプリケーションはWow64モードで実行され、32ビットアプリケーション（MSDN）の実行ではこのモードについて詳しく説明しています。

ハードウェアの製造とドライバーソフトウェアは、お客様が作成します。もちろん、32ビットと64ビットのWindows用に異なるドライバーがあります。

32ビットWindowsでは、ソフトウェアが1つのドライバーと通信し、64ビットWindowsでは別のドライバーと通信しますか？時々これらのドライバの新しいバージョンがあると仮定しましょう。したがって、ソフトウェアを32ビットWindowsでのみテストする場合、ソフトウェアと64ビットドライバーの組み合わせが失敗する64ビットドライバーに違いがないことを確認することはできません。そして、ユーザーの観点からは、誰が責任を負うかは関係ありません（あなたまたはドライバーの作成者）。彼らが見るのは、機能しないシステムだけです。したがって、コードにバグがない場合でも、テストによって64ビットドライバーのバグが明らかになる可能性があり、そのようなバグを見つけると、適切な対策（ドライバーの作成者にバグレポートを送信するなど）を行うのに役立ちます。

もちろん、これら2つのドライバーを何年も使用しており、動作がまったく同じであると確信している場合は、@ DavidPerforsの回答の引数に従って、1つのプラットフォームのテストをスキップできます。妥協案として、新しいドライバーバージョンが利用可能な場合にのみ、64ビットWindowsでテストを実行できます。実際、これはドライバーの複雑さ、ドライバーの経験と自信に依存します。

考慮すべき追加事項：

• ユーザーベースで最も使用しているOSの種類は何ですか？32ビットまたは64ビットWindows？1つのプラットフォームでのみテストすることにした場合、ユーザーが最も頻繁に使用するプラットフォームを選択します。
• ソフトウェアの新しいリリースがあまり使用されていないプラットフォームで動作しない場合、どれほど深刻ですか？たとえば、顧客はすぐに戻って以前の作業リリースをインストールできますか？これにより、不便または実質的な金銭的損失のみがありますか？前者の場合、1つのプラットフォームでのテストで十分ですが、後者の場合は明らかにそうではありません。

啓発されたQAサークルのデフォルトの前提は、「テストしなかった場合、機能しません」です。

実際問題として、通常、アプリケーションエンジニアがすべての単体テストを希望するのとほぼ同じ方法で努力することは、到達不可能な目標です。しかし、彼らはそれに到達してスケジュール通りにリリースするとは思わない。

ただし、あなたの質問は、販売とマーケティングによって、またはそれと組み合わせてのみ答えることができます。あなたは彼らにテスト費用を提供し、市場の利益の分析を提供します。上の推計場合は、両方の側面が十分に正確であったが、答えは簡単だろう

if B > C:
    test_32bit_version()

私の経験では、全員の費用の見積もりは不正確です。方程式の反対側に関しては、ディルバートはかつて、「猫、ミトンに尋ねたところ」でそこで意思決定をパロディ化したことがありました。もっと良くするために、彼らは人類学のフィールド方法の訓練を必要とするでしょう。

Windows 7以降のすべてのWindowsインストールの99％、およびVistaのかなりの部分も64ビットであると考えていますが、なぜそのプラットフォームでテストしないことを検討するのでしょうか？
32ビットWindowsを使用している既知の非常に限られたユーザーグループ向けに特別に作成していない限り、これは簡単なことです。

ええ、64ビットの問題をテストしてください。実際、64ビットプラットフォームで開発し、おそらく過去6〜8年ほどで新しいコンピューターとOSにアップグレードしていない少数の顧客向けに、オプションとして32ビットコンパイルバージョンと共に64ビットバージョンを標準として提供します。 。

私の経験からすると、インストーラーは異なるシステムで失敗する可能性が高いため、可能な限り多くの異なるWindowsセットアップでインストーラーをテストします。

それ以外の場合は、あなたが知っているあなたの経験を持つ与えられたソフトウェア、バグがするのが最も可能性は低いだけで 32ビットまたは64ビットに表示され、あなたは、いくつかの計算されたリスクを取ることができます。

まず、出荷に近づくにつれて、後のサイクル間でコードをほとんど変更せずに多くのテストサイクルを行う必要があります。保存できるときはいつでも、より多くのテストケースを作成したり、より多くの（したがってより小さな）サイクルを許可したりできるため、より迅速なフィードバックが得られます。（Xのテストに時間を費やすリスクは、Yのテストが多すぎるため、Yをテストしないリスクよりも大きい場合があります。）

だから

• 進行中のテストサイクルに使用した「その他のビットネス」でテストしてみてください。
• 開発者が使用する「ビットネス」を知っている場合は、他の開発者でテストを開始します。
• テストケースを「ビットネス」の間で分割して、それぞれに対応するようにします
• ただし、各テストサイクルで「ビン」間で交換してください。

いや。同様に、FDAがマウスとラットで新薬のテストを完了すると、サルでのテストはスキップされ、人間が消費するために販売されます。

</ sarcasm>

はい、はいはいはいはい。可能な限りすべてのプラットフォームをテストしなければ、ソフトウェアには悲しみ以外に何もありません。物事は常に異なり、プロジェクト中のデザイナー/コーダーの頭の中の仮定は通常、現実のモデリングにかなり近いものになります。ソフトウェアをテストしてください。お願いします。