kkamegawa's weblog

Visual Studio,TFS,ALM,VSTS,DevOps関係のことについていろいろと書いていきます。Google Analyticsで解析を行っています

プラットフォーム更新時のテスト

id:kkamegawa:20100907:p1 にコメントいただきました。groundさんありがとうございます

> たとえばO(1)の計算量の処理で1秒かかったとすると、O(n)では最悪n秒かかります。
O(ビッグオー)記法は、計算の比例係数は無視します。
なので、計算量は代わりませんが、Dictionaryは要素数によらず100秒かかり、Listは要素数*1秒かかる、というような場合もあります。
そのような場合は、要素数が100個以下だったらListを使ったほうが速いことになります。

確かにその通りですね。ソートなどもデータによっては使えないソートがあったりしますので(順序がくるってはいけない場合など)、計算量だけで決めることはできません。
今日のお題はプラットフォーム変更時のテスト。

環境が変わった場合のテスト

たとえば以下のような場合があります。

  • OSのバージョンが変わった(Windows Server 2003から2008へ)
  • サービスパックが適用された(SP1からSP2へ)
  • 特定の現象に対応するためのパッチを個別に提供してもらった(契約によっては作ってくれることがあったり、既知の問題でKB非公開状態ならば即時提供してくれたりする場合があります)

業種パッケージ製品などの場合、「開発したとき」のバージョンのまま固定で、その後のService Packの適用で「大丈夫か?」などと聞かれることがあります。どんなテストすればいいのでしょうか?
私の場合、まずは修正点一覧をじっくり見ます。今は少なくなりましたけど、以前はSPでも機能追加や仕様変更が多くあり、そのような時は変更が自分の物件に影響を及ぼしているか、まずドキュメントから判断してみます。APIレベルで変更がなければ第一段階クリア。載っていない変更があるかどうかはまずは気にしません(気にしていたらいつまでも何もできない)。
後は実際に動かしてみればいいのですが、実際にどうすればいい?という場合、手で評価するのは手間がかかりすぎます。操作の自動化を検討したいところです。WinFormやアンマネージドのWindowsアプリケーションではQuickTestFunctional Testerのような回帰テストを支援してくれるソフトを使えば楽でしょう。
Visual Studio 2010の場合、自動テスト機能もありますが、テスト対象にできるプログラムにはいくつか気を付けなくてはならない点があります。WebアプリやWPFアプリなら大丈夫のはず。
「そんなことを言っても、テストデータによって自動テストの結果変わるじゃないか」という話もあるでしょう。もちろん最初にテストを作った時のデータを保持しておく必要があります。保持しておけば、いつテストしても同じデータなので、同じ結果が得られるはずです。
性能が劣化していないことを証明するためのテストももちろん必要です。テスト時間は有限なので、性能が重視されるテストと、実行時間以外の結果に差がないかどうか確認するという二段階で考えたほうがいいのではないかと思います。もちろんパッチの変更点が「性能に問題があったケースを解消した」(特にデータベースの場合)という場合、性能が変化したかを優先的にみるといった必要がありますね。