直观上看,详细的测试用例是可以作为测试的依据,测试人员按照测试用例执行,心里感觉踏实;测试用例是白纸黑字,评审起来似乎也有根有据;测试用例是规范的文档,也符合维护、管理的要求。
但是,许多项目很难写出明确的期望标准,因为需求的标准就不明确,而是需要测试人员的综合判断,这时依赖测试用例很困难。基于用例来执行测试,容易限制测试人员的思维,甚至让许多测试人员不去思考,而测试用例自身又很难写得完整,需要不断完善。
当测试用例写得越详细,其维护的工作量越大,人们就更不愿意去维护,时间长了,许多用例失效了,也没有得到修改。把大量时间花在写测试用例、维护测试用例上,投入产出比(RoI)低,不合算,测试人员有更重要的事情去做。
如果评审几千条用自然语言写的详细测试用例,不仅工作量大,而且也不容易发现问题,因为不容易看到全局。如果把测试点、测试场景、测试数据很好地整理归纳在一张思维导图上,即使分解为几张思维导图,任何遗漏、不足之处倒是很容易发现。基于思维导图的测试设计评审更容易。
花在重写测试用例步骤上的时间是否有价值?是不是更应该花在其他测试活动上?例如用于探索式测试方式测试新特性,用更多时间在测试分析上,测试分析比测试设计更有价值,首先要知道测试什么,然后再决定如何测。即使对一个优秀工程师,要确定清楚哪些要测,依旧有挑战,而如何测,倒是比较简单。
如需了解更多测试技术信息请关注:https://www.duoceshi.cn/jswz/深圳多测师软件与技术服务有限公司
Copyright © 2016-2021 深圳多测师软件与技术服务有限公司 版权所有
本站部分文章源自于网络,如有侵犯您的版权,请联系删除