19

背景 私は、物流システムに取り組む 7 人の開発者と 2 人のテスターのチームで働いています。Delphi 2007 と、Bold for Delphiをフレームワークとして使用したモデル駆動型開発を使用しています。このシステムは現在約 7 年間運用されており、約 170 万行のコードがあります。4 ～ 5 週間後に本番環境にリリースし、ほぼすべてのリリース後に、見つかっていないバグに対していくつかのパッチを適用する必要があります。もちろん、これは私たちと顧客の両方にとって苛立たしいことです。

現在のテスト もちろん、ソリューションはより自動化されたテストです。現在、手動テストを行っています。空のデータベースで開始し、モデル化されたメソッドからデータを追加する Testdbgenerator。また、GUI をテストするための非常に基本的なスクリプトを実行するTestcompleteもあります。時間がないため、これ以上テストを追加することはできませんが、スクリプトはアプリケーションの変更にも敏感です。数年前、私は DUnit で単体テストを実際に試みましたが、数日後にあきらめました。ユニット同士のつながりが強すぎる。

単体テストの前提条件 単体テストの前提条件 をいくつか知っていると思います。

  • 1 つのことを行う小さなメソッドを作成しますが、それをうまく実行します。
  • 繰り返さないでください。
  • 最初に失敗するテストを書き、次にテストがパスするようにコードを書きます。
  • ユニット間の接続は緩んでいる必要があります。彼らはお互いについてあまり知らないはずです。
  • 依存性注入を使用します。

使用するフレームワーク 主に 64 ビット コンパイラのため、Delphi XE2 にアップグレードする可能性があります。私はSpringを少し見てきましたが、これにはD2007からの更新が必要であり、今は起こりません. 多分来年。

質問 ほとんどのコードはまだ自動的にテストされていません。では、古いコードのテスト容易性を高めるための最善の道は何でしょうか? それとも、新しいメソッドのみのテストを書き始めるのが最善でしょうか? 自動テストを増やす最善の方法が何であるかはわかりませんが、それについてのコメントは大歓迎です。現在 D2007 + DUnit を使用して、後で Delphi XE2 + Spring に簡単に変更できますか?

編集:手動テストの現在のテスト方法論については、クリスが言うように、「それを叩いて壊そうとする」だけです。

4

3 に答える 3

8

あなたは Michael Feathers 著のWorking Effectively with Legacy Codeという本が欲しいと思っています。テスト容易性を考慮して書かれていないコードに (単体) テストを導入する方法を示します。

一部の章は、古いコードのテストが難しい理由について開発者が与える可能性のある言い訳にちなんで名付けられており、ケーススタディと各問題に対処するための提案された方法が含まれています。

  • 時間がないので交換したい
  • このメソッドをテスト ハーネスで実行できません
  • このクラスは大きすぎるので、これ以上大きくしたくありません
  • モンスターメソッドを変更する必要があり、そのためのテストを書くことができません。

また、依存関係を壊すための多くの手法についても説明します。いくつかはあなたにとって新しいものかもしれませんし、いくつかはすでに知っているかもしれませんが、まだ使用することを考えていないかもしれません.

于 2011-10-13T18:08:57.290 に答える
3

自動単体テストの要件は、まさに次のとおりです。

  1. 単体テスト フレームワーク (DUnit など) を使用します。
  2. ある種のモック フレームワークを使用します。

アイテム2は難しいものです。

DRY、小さな方法、テストから始める、DI はすべて砂糖です。まず、単体テストを開始する必要があります。DRYなどを適宜足していきます。結合を減らすと、単体テストが容易になりますが、大規模なリファクタリング作業を行わなければ、既存のコード ベースの結合を減らすことはできません。

新しいものとリリースで変更されたもののテストを書くことを検討してください。時間が経つにつれて、単体テストの合理的なベースが得られます。新しいものや変更されたものもリファクタリング (または適切に記述) できます。

また、単体テストを実行し、ビルドが中断したときにメールを送信する自動ビルド プロセスを検討してください。

これは単体テストのみを対象としています。QA テスターの場合は、自動テスト (ユニット テストではない) を実行できるツール (存在しますが、思いつきません) が必要になります。

于 2011-10-12T21:31:35.847 に答える
1

あなたのテストチームは小さすぎます、IMO。私は、QA 部門が開発者よりも多いチームで働いてきました。より小さなサイクルに収まる管理可能なチャンク (機能、修正) の「スプリント」で作業することを検討してください。「アジャイル」は 2 週間のスプリントを奨励しますが、それはきつすぎるかもしれません。いずれにせよ、QA は常に忙しく、リリース ウィンドウよりずっと前に作業を続けることになります。現時点では、膨大な量のコードを提供するまでアイドル状態であると思われます。リリース サイクルが短いほど、より多くのテスターを忙しくさせることができます。

また、あなたは彼らのテスト方法について多くを語っていませんでした。実行する標準スクリプトがあり、期待される外観と動作に対して外観と動作を検証しますか? それとも単に「叩いて壊そうとする」だけですか？

IMO、Dunit テストは、データベース、通信などの多くの依存関係で実行するのが困難です。しかし、実行可能です。データベース セットアップ スクリプトを自動的に実行する DUnit クラスを作成しました (テスト対象のクラスと同じ名前の .sql ファイルを探し、SQL を実行すると、テストが続行されます)。これは非常に効果的です。SOAP 通信の場合、既定の結果を返す SoapUI モックサービスを実行しているので、通信をテストできます。
手間はかかりますが、それだけの価値があります。

于 2011-10-12T21:00:44.013 に答える