因為公司自動化測試框架的一些要求，我們的ruby測試指令碼（使用test unit）以如下形式組織：
authentication\（目錄名為feature名字）
- 100_signature.rb （100為測試用例在testlink對應的id，後面為簡單描述）
- 101_signature_with_invalid_key.rb
在每個測試指令碼中，測試類根據id命名，比如100_***.rb中code如下:
1 tc_100 < test::unit::testcase2 # …
3
這種組織形式給我們的日常執行帶來了一些小麻煩，比如想執行乙個folder下的所有測試用例，只有採用以下兩種方式：
1）寫個shell指令碼，然後執行完後必須從很長的log中自己手工找出執行狀況。
2）維護如下檔案管理所有用例：
1 'test/unit/testsuite'2 'test/unit/ui/console/testrunner'
3 4 'authentication/100_***.rb'
5 'authentication/101_***.rb'
6 7 suites << test::unit::testsuite
8 self.suit
9 suites = self.new('suites')
10 suites << tc_100.suite
11 suites << tc_101.suite
12
13 14
15 test::unit::ui::console::testrunner.run(suites)
但是這個方法有個問題，必須長期手工維護。比如每次新增新的用例就必須手動修改此檔案以保持一致。
ruby語言是強大的，靈活的，我們可以利用元程式設計的一些基本特性比如eval來輕鬆解決這個問題。在解決方案2的基礎上新**如下：
requirerequire
path = argv[0]
$suite_names =
dir.foreach(path) do |filename|
c 模板元程式設計的一點體會
趁著國慶長假快速翻了一遍傳說中的 大名鼎鼎的 modern c design，鈦合金狗眼頓時不保，已深深被其中各種模板奇技淫巧傷了身。論語言方面的深度，我看過的 c 書裡大概只有 insight c object model 能與之一戰吧？難怪 herb 老喜歡調侃 andrei 在模板方面是個可怕...
大蝦程式設計中的一點感悟
秩名 這是我在程式設計中，從學習到應用階段的一點感悟，與大家一起分享，希望能給剛入這行的朋友們帶來一些好的啟示。1 學習應該從基礎打起，不要一開始就嘗試最高深的技術。2 每看一本書，不要說這章我以前學習過了，也掌握的很好，因此我可以跳過這一章看更重要的了。對於作業，遇到不會的盡量不要立刻向別人請教。...
關於測試的一點思考
測試部門接手乙個專案 產品的流程及關注點 1 明確產品需求 i.顯式需求 功能 效能 ii.隱式需求 安全性 應用場景等 2 確定產品定位 在效率 安全性 效能 易用性等方面的定位 2.5 確定產品質量目標 專案規範 驗收標準 執行維護標準等 3 知道產品使用者 其教育背景 偏好等，便於提取場景，增...