很多測試人員會詢問, 是否有一種測試方法, 可以很系統化地, 來開立所有測試個案.

我也很期待有這種東西, 可惜一直沒有看到, 不管哪種黑箱測試方法, 都有它的優點和缺點.

更重要的是黑箱測試有個重大的致命點, 它是完全依賴測試人員的經驗. 如果測試人員的產品領域知識, 以及產品所處的系統知識豐富, 就能開出更好的測試個案.

例如: 等價分析法(Equivalence Class). 他要求先找出等價區域 (Partition or equivalence class),  然後對每個區域開出一個測試個案, 只要這些個案執行完, 就說測試完畢.

 

fig2  

但是有經驗的測試人員, 他能找出的區域, 可能品質比沒有經驗的人好上百倍. 所以不管測試方法再好, 也需要有優秀的人才. 就像圓月彎刀中, 丁鵬殺了柳若松後說, "有些人縱有神刀在手, 仍是無法成為刀中之神的”.  資質永遠是第一首選.

可是如果資質不好, 就沒有辦法改變了? 

在一次對話中, 讓我被啟發了. 或許這些方法無法讓你開出很完整的測試個案, 但是是否有方法, 讓你清楚表達你的思考邏輯.  如果可以清楚表示, 別人或是自己就可以容易檢查有沒有缺陷或是遺漏.

就這像用魚骨圖, mindmap, 或是 decision tree 等方式來呈現事情, 可以讓別人看到後很快可以理解, 並且也可以很快地給你回饋. 所以同理, 好的黑箱測試方法, 應該也要具備相同的特質. 

因此根據這樣的想法, 哪一種黑箱測試的方法比較合適呢? 目前看起來應該是 Decision Table Testing. 因為它會將你想的測試狀況, 明確清楚的列出來, 這時候別人就可以檢視你的思考邏輯. 以下是使用 decision table 測試方法的範例: 說明在這樣的商業規則下, 你需要考慮哪些測試 scenario. 這樣的表達方式, 別人可以快速知道你是怎麼思考, 是否有不足的地方.

 

螢幕快照 2014-02-24 上午6.41.07  

所以我現在從找最好的測試方法, 改成找最容易表達你測試思維的方法. 這算是進步呢? 還是我很容易滿足 ….

arrow
arrow
    全站熱搜

    kojenchieh 發表在 痞客邦 留言(0) 人氣()