呢排為設置 Testing 場而預備緊 d SQL statement, 有部份 Data 得 detail table, 但使用時要整返個 master 比佢, 所以就要使用 update statement 黎 link 返唔同 table 既 key, 以下係一個例子:
update tblModel set series_pkey = tblSeries.pkey from tblModel, tblSeries where tblSeries.full_name = 'A Series' and tblModel.full_name like 'A %';
今日因為想組織下 d source code, 所以 download 左 Regionerate 黎用
之前 VS 2002 都有用過類似 Sort Code 既 Macro, 但我見 VS 2008 用果時有問題 (sort 完走位, 係唔啱既地方 cut 左我 d code), 所以就搵過第二個.
今次呢個都 ok, group 都所有 method, variable, constructor 同 properties, 不過行完後 d encode 好似有 d 問題, 要成日自己選返個 encode method.
類似既野聽講 Resharper 都做到, 但可惜, 要錢已經係一個問題.
今日經 email 見到呢個網站 – AlternativeTo, 係用黎比大家容易地搜尋有關相同產品既選擇.
選擇, 從來都唔容易, 而且社會上充滿咁多唔同類型既產品既情況下, 要選出啱用既野都十分難, 呢個網站做到既野就係比你有其他既選擇, 以及唔同人用不同選擇既傾向.
當有時搵到 d 要收費既產品時, 可以在呢個網站內搜尋一下, 應該可以搵到其他可能價錢啱心水又或者係唔使錢既軟件, 都幾啱而家呢個審慎理財既時間用!~~
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 而重做半小時既測試結果既慘況下, 自動化測試變成我寫軟件生活既其中一個有興趣深入研究既地方.
