很多
測試人員會詢問, 是否有一種測試方法, 可以很系統(tǒng)化地, 來開立所有測試個案.
我也很期待有這種東西, 可惜一直沒有看到, 不管哪種
黑盒測試方法, 都有它的優(yōu)點和缺點.
更重要的是黑盒測試有個重大的致命點, 它是完全依賴測試人員的經(jīng)驗. 如果測試人員的產(chǎn)品領(lǐng)域知識, 以及產(chǎn)品所處的系統(tǒng)知識豐富, 就能開出更好的測試個案.
例如: 等價分析法(Equivalence Class). 他要求先找出等價區(qū)域 (Partition or equivalence class), 然后對每個區(qū)域開出一個測試個案, 只要這些個案執(zhí)行完, 就說測試完畢.
但是有經(jīng)驗的測試人員, 他能找出的區(qū)域, 可能質(zhì)量比沒有經(jīng)驗的人好上百倍. 所以不管測試方法再好, 也需要有優(yōu)秀的人才. 就像圓月彎刀中, 丁鵬殺了柳若松后說, "有些人縱有神刀在手, 仍是無法成為刀中之神的”. 資質(zhì)永遠是第一首選.
可是如果資質(zhì)不好, 就沒有辦法改變了?
在一次對話中, 讓我被啟發(fā)了. 或許這些方法無法讓你開出很完整的測試個案, 但是是否有方法, 讓你清楚表達你的思考邏輯. 如果可以清楚表示, 別人或是自己就可以容易檢查有沒有缺陷或是遺漏.
就這像用魚骨圖, mindmap, 或是 decision tree 等方式來呈現(xiàn)事情, 可以讓別人看到后很快可以理解, 并且也可以很快地給你回饋. 所以同理, 好的黑盒測試方法, 應(yīng)該也要具備相同的特質(zhì).
因此根據(jù)這樣的想法, 哪一種黑盒測試的方法比較合適呢? 目前看起來應(yīng)該是 Decision Table Testing. 因為它會將你想的測試狀況, 明確清楚的列出來, 這時候別人就可以檢視你的思考邏輯. 以下是使用 decision table 測試方法的范例: 說明在這樣的商業(yè)規(guī)則下, 你需要考慮哪些測試 scenario. 這樣的表達方式, 別人可以快速知道你是怎么思考, 是否有不足的地方.
所以我現(xiàn)在從找最好的測試方法, 改成找最容易表達你測試思維的方法. 這算是進步呢? 還是我很容易滿足 ….