详细的测试用例能不能成为测试的依据?

　　直观上看，详细的测试用例是可以作为测试的依据，测试人员按照测试用例执行，心里感觉踏实;测试用例是白纸黑字，评审起来似乎也有根有据;测试用例是规范的文档，也符合维护、管理的要求。

　　但是，许多项目很难写出明确的期望标准，因为需求的标准就不明确，而是需要测试人员的综合判断，这时依赖测试用例很困难。基于用例来执行测试，容易限制测试人员的思维，甚至让许多测试人员不去思考，而测试用例自身又很难写得完整，需要不断完善。

　　当测试用例写得越详细，其维护的工作量越大，人们就更不愿意去维护，时间长了，许多用例失效了，也没有得到修改。把大量时间花在写测试用例、维护测试用例上，投入产出比(RoI)低，不合算，测试人员有更重要的事情去做。

　　如果评审几千条用自然语言写的详细测试用例，不仅工作量大，而且也不容易发现问题，因为不容易看到全局。如果把测试点、测试场景、测试数据很好地整理归纳在一张思维导图上，即使分解为几张思维导图，任何遗漏、不足之处倒是很容易发现。基于思维导图的测试设计评审更容易。

　　花在重写测试用例步骤上的时间是否有价值?是不是更应该花在其他测试活动上?例如用于探索式测试方式测试新特性，用更多时间在测试分析上，测试分析比测试设计更有价值，首先要知道测试什么，然后再决定如何测。即使对一个优秀工程师，要确定清楚哪些要测，依旧有挑战，而如何测，倒是比较简单。

如需了解更多测试技术信息请关注：https://www.duoceshi.cn/jswz/深圳多测师软件与技术服务有限公司