这是《落叶》文集里第 346 片落叶,希望你能喜欢,不为别的,只为这份坚持。
第二十一章 你真的会设计测试用例吗?
今天了解到大家的测试点都梳理好了,于是把大家喊到一起,讨论下设计测试用例的思路,也想了解一下大家的设计风格,确保最终的产物风格不会偏差太多。
会议开始的头一分钟,我问了大家一个问题:“你们真的会设计测试用例吗?”下一分钟,满屋子就都是等价类、边界值、场景法、因果图和判定表的声音了,大家纷纷阐述着自己所掌握的测试用例设计方法。
我敲了敲白板,吸引了一下大家注意力,然后问大家:
- 这些测试用例设计方法是在设计初期就要用的吗?
- 什么时候该用等价类设计?什么时候该用因果图设计?
- 使用这些方法是否能保证很高的测试用例覆盖率?
这几个问题让声音慢慢地小了下去,大家逐渐地进入了思考模式。我说,你们可以带着这些问题,会后好好想一想,我先说下我的观点:
我并不是反对大家使用这些方法,相反地,这些设计方法肯定会给测试用例的设计工作带来很大的帮助。但从实际做项目的角度出发,我并不认为,在一开始的时候,它们就会派上用场,在测试点刚刚梳理完成的时候,我们首先应该建立的是用户场景,或者说是业务场景,再基于实际的场景,去分析测试用例里对应的几个关键参数:
- 前置条件
- 输入数据
- 期望结果
得出这些关键参数之后,结合着你们所说的那些设计方法,再开始设计测试用例,会不会更好一些。
另外,我认为,测试用例设计的好不好,并不是看它用了多么专业的方法,而是要看它是否可以完全丢给另外一个不了解系统的人去执行,那个人只要按照测试用例里的前置条件、输入数据、步骤和期望结果,就可以独立完成测试。
同时,在开始设计具体的测试用例之前,也应该先根据产品的结构和特性,设计合理的测试用例框架,便于后期升级和扩展,尽可能地降低后期用例维护的成本。
《告诉你如何从执行测试到管理测试》带你迈出第(21)步!,点击这里可查看完整地图
作者简介:14 年测试 + 11 年项目管理 + 11 年团队管理 = 一个测试老兵
网友评论