Ruby元程式設計的在測試中的一點小實踐

因為公司自動化測試框架的一些要求，我們的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::testcase

2   # …
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的基礎上新**如下：

require 

require 
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 知道產品使用者 其教育背景 偏好等，便於提取場景，增...