很多测试人员会询问, 是否有一种测试方法, 可以很系统化地, 来开立所有测试个案.
我也很期待有这种东西, 可惜一直没有看到, 不管哪种黑盒测试方法, 都有它的优点和缺点.
更重要的是黑盒测试有个重大的致命点, 它是完全依赖测试人员的经验. 如果测试人员的产品领域知识, 以及产品所处的系统知识丰富, 就能开出更好的测试个案.
例如: 等价分析法(Equivalence Class). 他要求先找出等价区域 (Partition or equivalence class), 然后对每个区域开出一个测试个案, 只要这些个案执行完, 就说测试完毕.
但是有经验的测试人员, 他能找出的区域, 可能质量比没有经验的人好上百倍. 所以不管测试方法再好, 也需要有优秀的人才. 就像圆月弯刀中, 丁鹏杀了柳若松后说, "有些人纵有神刀在手, 仍是无法成为刀中之神的”. 资质永远是第一首选.
可是如果资质不好, 就没有办法改变了?
在一次对话中, 让我被启发了. 或许这些方法无法让你开出很完整的测试个案, 但是是否有方法, 让你清楚表达你的思考逻辑. 如果可以清楚表示, 别人或是自己就可以容易检查有没有缺陷或是遗漏.
就这像用鱼骨图, mindmap, 或是 decision tree 等方式来呈现事情, 可以让别人看到后很快可以理解, 并且也可以很快地给你回馈. 所以同理, 好的黑盒测试方法, 应该也要具备相同的特质.
因此根据这样的想法, 哪一种黑盒测试的方法比较合适呢? 目前看起来应该是 Decision Table Testing. 因为它会将你想的测试状况, 明确清楚的列出来, 这时候别人就可以检视你的思考逻辑. 以下是使用 decision table 测试方法的范例: 说明在这样的商业规则下, 你需要考虑哪些测试 scenario. 这样的表达方式, 别人可以快速知道你是怎么思考, 是否有不足的地方.
所以我现在从找最好的测试方法, 改成找最容易表达你测试思维的方法. 这算是进步呢? 还是我很容易满足 ….
最新内容请见作者的GitHub页：http://qaseven.github.io/
