I'm CaLendarW Blog

呢排重溫緊 Pragmatic Unit Testing in C# with Nunit, 開始試緊寫有關 Performance 既 Test Case, 書中有一段有關 Performance 既 Code:

[Test]
public void FilterRanges()
{
    Timer timer = new Timer();
    String naughty_url = "http://www.xxxxxxxxxxx.com";
    // First, check a bad URL against a small list
    URLFilter filter = new URLFilter(small_list);
    timer.Start();
    filter.Check(naughty_url);
    timer.End();
    Assert.IsTrue(timer.ElapsedTime < 1.0);
    // Next, check a bad URL against a big list
    filter = new URLFilter(big_list);
    timer.Start();
    filter.Check(naughty_url);
    timer.End();
    Assert.IsTrue(timer.ElapsedTime < 2.0);
    // Finally, check a bad URL against a huge list
    filter = new URLFilter(huge_list);
    timer.Start();
    filter.Check(naughty_url);
    timer.End();
    Assert.IsTrue(timer.ElapsedTime < 3.0);
}

段 code 係一個幾好既 example 去講點 Test Performance, 但當真係要試果陣, 就發現左樣野, 就係我搵唔到 Code 中既 Timer Class, 係我在 System 入面既幾個 namespace 中, 都搵唔到啱用既 Timer, 因為 System namespace 入面既 Timer 大部份都係用黎 Trigger Timeout Event, 而當中既 Stop method 都只係用黎停止 Event Trigger, 而沒有任何計時結果做到出黎, 所以經過一輪網上既搜尋之後, 得出以下 Timer, 主要目的係用黎計時, 仔細度高, 最啱用黎作 Performance Testing 之用!!~

using System;
using System.Collections.Generic;
using System.Text;
using System.Runtime.InteropServices;

namespace TestUtil
{
    public class HighResolutionTimer
    {
        private long frequency;
        private long start;
        private long stop;

        public HighResolutionTimer()
        {
            QueryPerformanceFrequency(ref frequency);
        }

        public float ElapsedTime
        {
            get
            {
                float elapsed = (((float)(stop - start)) / ((float)frequency));
                return elapsed;
            }
        }

        public void Start()
        {
            QueryPerformanceCounter(ref start);
        }

        public void Stop()
        {
            QueryPerformanceCounter(ref stop);
        }

        [System.Runtime.InteropServices.DllImport("KERNEL32.dll", CharSet = System.Runtime.InteropServices.CharSet.Auto)]
        private static extern bool QueryPerformanceCounter([In, Out] ref long performanceCount);

        [System.Runtime.InteropServices.DllImport("KERNEL32.dll", CharSet = System.Runtime.InteropServices.CharSet.Auto)]
        private static extern bool QueryPerformanceFrequency([In, Out] ref long frequency);

    }
}

HighResolutionTimer 來源 : 在 C# 中實現高性能計時

Test Driven Development, 係以測試來驅動程式既設計, 目的係為了提高軟件既質素.

好多人覺得測試對軟件方面只在於用戶接受測試 (UAT), 因為只要通過 UAT, 公司就可以袋袋平安. 不過, UAT 通常都浪費人手, 而且該次 UAT 只計對於該次既軟件需求, 當需求需要更改, 所有既測試都要人手重頭做過, 浪費人力物力.

自動化軟件測試既好處係可以減省人手及時間, 以及提高軟件既質素及完整度.

以下係一個由 NUnit 提供既自動化測試例子:

// 一個 object oriented 既 Account class
namespace bank
{
  public class Account
  {
    private float balance;
    public void Deposit(float amount)
    {
      balance+=amount;
    }

    public void Withdraw(float amount)
    {
      balance-=amount;
    }

    public void TransferFunds(Account destination, float amount)
    {
    }

    public float Balance
    {
      get{ return balance;}
    }
  }
}

namespace bank
{
  using NUnit.Framework;

  [TestFixture]
  public class AccountTest
  {
    // 自動化測試來測試 TransferFunds Method
    [Test]
    public void TransferFunds()
    {
      Account source = new Account();
      source.Deposit(200.00F);
      Account destination = new Account();
      destination.Deposit(150.00F);

      source.TransferFunds(destination, 100.00F);
      Assert.AreEqual(250.00F, destination.Balance);
      Assert.AreEqual(100.00F, source.Balance);
    }
  }
}

以上只係其中一個例子用來測試軟件既完成度, 在現實上, Test Case 除左要測驗一般情況外, 仲要測試錯誤情況出來既結果, 保証軟件質素, 所以正常使用既情況係唔會得一個 Test Case 咁少.

要實行 Test Driven Development, 通常要有一個良好既 Object Oriented Design 以及 Design for Test, 如果沒有這兩個設計既技巧, 那測試既質素有可能會受影響.

愈多 Test Case 未必代表軟件的準確率愈高, 正常情況 Test Case 既數量應該多過 Use Case 既數量, 而且會因應不同既考慮點而增加一定的測試數量, 以我所知, 在某些大學既科目中, 有計算要有多少 Test Case 既試題 (因為我都有睇過), 用作驗證是否足夠全面地測試每一行代碼.

在測試失敗時, 有問題既地方除了可能係軟件本身外, 自動化測試部份亦有可能會有錯誤, 錯誤既多少在乎實現 Test Case 既人對軟件測試既知識同經驗所得.

雖然軟件在有測試既環境下推出, 但有時都有可能會在軟件發現有 bug 既情況, 當遇到這個情況下, Programmer / Tester 應該用 Test Case 去模擬問題既環境, 當得出相同既結果後才可以更改軟件, 因為未能模擬出相同環境下更改軟件, 失敗後亦未知是軟件問題定 Test Case 問題, 所以 Programmer 應該先更改 Test Case 後才更改軟件, 而更改軟件途中, Programmer 亦可透過測試來避免 side effect 出現, 所以不段發現問題環境才能提高軟件既完整性, 以及提高軟件人員對軟件既信心.

測試, 除了要滿足軟件既完整性, 亦要滿足不段改變既需求, 世界變, 軟件同測試不變就只會不進則退, 所以為新既需求而更改軟件及擴充其功能既環境下, 自動化測試係必須的.

一年前我工作既地方, 因為無自動化測試, 軟件無 Design for Test, 要用到硬件 及 3rd Party 提供既模擬程式下, 人手測試既時間應該超過一個月, 除了測試一個月既時間外, 測試既人手通常都要兩至三人, 而且大部份都係重複既輸入工作, 以及已改幾句 code 而重做半小時既測試結果既慘況下, 自動化測試變成我寫軟件生活既其中一個有興趣深入研究既地方.