CodePlex Home
Register | Sign In | CodePlex Home
Project Description
MIC在台灣推動的測試自動化程式庫計劃, 藉由參與此程式庫的開發來給大家一個快速進入自動測試的窗口.

本專案是希望能藉由一個小型自動測試系統的實作, 來帶給有心想要發展軟體自動測試系統的人一個簡單的起步, 目前的程式庫包含:
1) 檔案夾結構的設計, 可供未來多人同時開發.
2) 運用 VSTS 來 Build/Deploy/Test 的完整程序.
3) 隨機資料產生器, Assert 補充, Windows Service Helper, SQL Server Helper.
4) 驗證程式庫的一組測試程式 (BVT: Build Verification Test).

下一波我會依觀眾的需求來增加功能, 如果有興趣加入的請跟我聯絡.

Bentham Chang
Last edited Oct 21 2008 at 8:44 AM by benthamc, version 3
Comments
ChrisTorng wrote  Oct 22 2008 at 6:37 AM 
我想加入，有一些問題:
1. MICTA 目前看起來還蠻陽春的，是否有更完整 (且開放原始碼!?) 的專案可以作為開始? 或許我們只要找到一個適合的專案，並加入貢獻程式碼及測試，並使用繁體中文介紹給大家會更快更好?
2. 是否要區別 dev 與 tester 角色的測試? 上課主題是 TDD，TDD 是 dev 寫的單元測試，但 MICTA 中特別是 Random 相關的類別，應該是 tester 用的測試。MICTA 專案的目標是要給 dev 還是 tester 用?
3. 函式庫/WinForm 的測試需求與 WebForm 的測試需求我覺得差異蠻大的，連 ASP.NET/AJAX/MVC 之間的測試需求差異也很大，是否要針對哪一個特定目標?
4. MITCA 內命令提示字元方面的環境，我會感覺多此一舉。是否可以在個人開發端皆可直接由 IDE 內建置/測試，只有在 Server 自動 Build/Deploy/Test 時才使用命令提示字元環境? 我這裡的開發環境，個人端即由 IDE 內建置/測試，Server 端使用微軟提供的 CI (Continuous Integration Using Team Foundation Build http://msdn.microsoft.com/en-us/library/ms364045(VS.80).aspx)，我自己還有加一點功能，讓它可以自動建置 (+測試) 並部署完畢。我目前感覺 IDE 內的功能並沒有什麼不足之處，Server 端自動建置/測試/部署也沒有困難...

最後提供最近我看到的測試相關工具:
xUnit.net http://www.codeplex.com/xunit (An Introduction to xUnit.net for ASP.NET MVC Developers http://weblogs.asp.net/stephenwalther/archive/2008/06/30/an-introduction-to-the-xunit-net-testing-framework.aspx)
Test Automation FX http://www.testautomationfx.com/

ChrisTorng wrote  Oct 22 2008 at 7:12 AM 
再補一個: Lightweight Test Automation Framework for ASP.NET Samples http://www.codeplex.com/aspnet/Wiki/View.aspx?title=ASP.NET%20QA&referringTitle=Home

ChrisTorng wrote  Oct 27 2008 at 6:21 AM 
再加一個: Pex - Automated White Box Testing for .NET http://research.microsoft.com/pex/ (需要 VS 2010)

benthamc wrote  Oct 28 2008 at 8:48 AM 
先回答您的問題:
1) MICTA 是一個"拋磚引玉"的動作, 希望從小的程式庫開始, 鼓勵大家去思考測試自動化的議題, 並找到適當的切入點在個自的專案中去啟動, 所以在第一版就顯得比較陽春, 因為不希望大家望而卻步.
2) dev/tester 的角色是要看您的專案的特性及公司文化而定, 並沒有硬性的區分, 在微軟裡tester都必須要寫自動測試或工具, 所以大多數的時間也是當dev, 只是在看事情的角度上專注於測試比較多. MICTA是我用來示範TDD開放的例子, MICTA的核心部份必須要經過嚴厲的測試, 所以在將來寫 test case 的時候可以確保基本的功能正確運作, 因為當test case產生錯誤的時候, 我們不希望看到是MICTA的程式庫有問題.
3) 我們可以選定一個主題來開發, 目前在微軟總部這邊我也找到幾個專家來參與, 原則是先從 API 開始然後推入web service的測試, 到 WinForm UI 及 WebForm 的測試. 我想先從小東西導入觀念, 觀念建立以後再推比較複雜的應用.
4) 根據我的經驗, 命令字元的環境看起來沒什麼, 可是卻是自動測試的基礎, 想想看, 5個人的專案每個人都從IDE裡跑就OK了, 20個人的話, 任何一個人不小心簽入了一個錯誤就會造成其他19個人停擺, 再者從遠端操控其他電腦在不同的作業系統或配置情況下執行所有的測試即使有IDE的幫助, 背後也是靠執行這些批次檔案. 我同意您的看法使用 CI 可以將這個環境更進一步自動化, 但對剛入門的使用者來說從命令字元的環境開始, 還是有其教育的價值.

謝謝您提出這個工具, 我們可以陸續討論這些熱門的議題:
1) xUnit vs Visual Studio Unit Test: 目前我是使用後者, 但對 xUnit 我並沒有後反對, 因為基本上這兩者功能的差異不大.
2) Test Automation FX 是 UI 測試的一套工具, 從錄製使用者UI的操作, 來產生程式並執行.
3) ASP.NET 的測試也是一個大方向.

您可以找到很多相關的資訊, 但是我希望還是能從簡單的東西開始建立, 畢竟沉默的大多數人對自動測試這個議題還是剛剛起步階段, 希望您能諒解.

franma wrote  Nov 4 2008 at 3:59 AM 
針對程式的部分提問
1 ) TestAutomation 的定位就是針對，Dev 自已所撰寫的 lib 對吧？那麼為什麼會特地要放一個 Verify \ AssertEx 呢？？而且此 class ，亦沒有被 TestAutomation 所使用到。 而且輸出大多都是針對 Assert 處理，很明顯就是 unit test 的用法

2 ) 小問題，時間日期格式的測試程式，目前會有因為地區的關係進而導致UT 會出錯。 這個部分是否也要考量在 UT 之中呢？？ (以前自已寫的時候是完全沒有考慮的，都會強制指定某一種樣式 )

3 ) 以往只要遇到 IIS / Windows Service 這一類的，程式碼盡量都寫在 Lib 的方式，以方便 UT 可以去測試其功能。 但 Windows Service 和 IIS 本身服務啟動等等的相關功能，則用人工的方式。 那麼這一塊未來會怎麼規劃去實作呢？

4 ) Log Test 的測試思維我覺得很棒，透過 listener 去取得中間所有的過程。 看來有很多地方都可以應用此方式。 但 reporting 是否也可以借此驗證呢？？

ChrisTorng wrote  Nov 7 2008 at 3:24 AM 
等了三個星期，還沒看到什麼動作? 還在期待中......

我想確定一下，這個專案的最終目標，是要做出一個協助大家在撰寫自己 AP 的測試專案時，可以引用 TestAutomation.dll 後，取得一堆協助測試的功能，讓自己的測試專案更容易撰寫，對嗎?

那請大家加入的目的，著重的是過程還是結果? 所謂過程，是請大家一起協助增加 TestAutomation 的測試功能，並在一起開發的過程中，了解如何測 TestAutomation，順便學習如何測自己的程式。所謂結果，是可以得到一個可用的 dll。

如果重視過程的話，是不是會找更多測試的生手加入，讓大家邊寫邊學呢? 或者只要讓人觀摩最終成品的程式碼即可?

我以前曾經想推一個「團隊開發學習計劃草案」http://groups.msn.com/ChrisTorng/teamdevelopment.msnw?action=get_message&ID_Message=6721，目的是邊寫邊互相觀摩邊學習。提出此案供參考，是否要讓生手一起寫，然後邊討論邊改善，或者只需要由各位專家直接寫出成品即可。

如果讓我加入撰寫，我想我的意見一定會很多... ;-) 比如我一定會開「程式碼分析」以及 StyleCop http://code.msdn.microsoft.com/sourceanalysis。

Sign in to add a comment
Updating...
© 2006-2009 Microsoft | About CodePlex | Privacy Statement | Terms of Use | Code of Conduct | CodePlex Blog | Version 2008.12.9.14291