测试基础 统一测试用例的写法,公司目前有两种意见,投票结果差不多,大家能补充下这两种的优缺点吗

初晴 · 2021年09月14日 · 最后由 李胖 回复于 2021年11月03日 · 5901 次阅读

第一种是 xmind 写的思维导图,类似下图这种

第二种就是用 excel 写的,类似下图

目前讨论出来的优缺点如下

第一种优点:看起来简单明了,一眼就能知道测试的内容,写用例耗费的时间相对较少

第一种缺点:如果有人员变动,不方便后续人员测试

第二种优点:比较规范 (听说很多大厂都用这种),方便其他接班人快速了解需求

第二种缺点:写用例耗费时间较长,看起来比较麻烦,很多页面需要点击再返回,需要多写几次重复的

还有什么优缺点大家能补充下吗

共收到 38 条回复 时间 点赞
初晴 回复

确实,看项目的迭代速度吧,有时候写用例的时间并不会那么宽裕

xmind 主要优点是比较能够发散思维,讲究的是覆盖尽可能多的功能点,而不是通过用例来帮助新人了解系统,了解系统完全可以用其他的方式来达到目的

liumomo 回复

哈哈,看昵称,应该是 itestwork,开源的测试平台

我也觉得 xmind 更好梳理思路,至于打状态换个颜色标记一下就好了😂

用哪一种,主要取决于你面向的对象是谁。如果是个人用,我是选 xmind 的。

codes 回复

这啥平台?

用平台吧,web 脑图,以及标准用例都支持且可转换 如下图


且还可以导出来,在线下,执行, 修改,新增后,再同步回系统

我觉得使用平台也是一种不错的方法,比如禅道之类的,也能导入导出 excel,很方便

问这种问题一看就是项目做少了

初晴 回复

有自己内部平台,基于 agiletc 做的,也是 xmind 形式写用例。

这个看个人习惯,不能一锤子事。这还是要定好 excel、xmind 的用例格式(大忌团队风格百花争鸣,这样没法维护),支持 excel、xmind 这样可以实现互相转换,并且最重要测试管理平台用例管理一般都是按 excel 去导入。

我认为这两者简单来说分两者情况:
1.大组网系统,会进行很多次的版本迭代:版本测试用例还是使用 Excel 写比较好,其中的特性测试用例可以使用 xmind
2.敏捷测试、单系统小需求多迭代:可以使用 xmind 来编写用例,也是因为用例的复用率较低,更多的是一次性使用

xmind 梳理测试思路
excel 编写测试用例

初晴 #24 · 2021年09月15日 Author
陈恒捷 回复

大佬,荔枝现在也是用的 xmind 来写的吗,还是说有自己内部的平台

凌先生 回复

内部的,不过市面上的用例平台包括开源也不少了,还是要匹配自己公司及部门的规范习惯才是合适的。

我们这个不复杂,主要是 antd pro+flask,那个思维导图及流程图组件则是 gg-editor 改造的

JoyMao 回复

你演示的用例平台是内部的吗?还是有开源?

我们这边是根据需求用 xmind 来梳理测试功能点,Excel 来编写测试用例,

第一种比较清晰,但是最终都要录入到类似 jira 平台里去的吧?

xmind 优点是编写简单,缺点是别人相对没那么容易看懂(也有办法优化,写细一些,有问题能问人就行),适合经常有新功能要写用例,且大部分用例其实不会换着人重复执行的场景。互联网大多是这种,就算是发版固定要跑的场景,xmind 写细点其实也够用。

excel 优点是很规范容易统一,缺点是写起来的成本比 excel 高,适合写完基本就不怎么会改,且会需要换着人执行的情况。只是互联网现在这种情况太少了,所以用得很少。

至于你提到的 excel 听说很多大厂都用这种 ,建议细问下是大厂的啥业务,啥场景(比如给流动性很高的外包纯执行用)?不能听到大厂就直接追随,大厂通常有很多不同类型的业务,不同业务差异还是很大的。

我们两种都要写,xmind 写测试点,excel 写详细用例😑

按照规范格式写,都是可以相互转化的吧。

个人感觉 excel 好,思维导图适合罗列测试点,测试点细分成测试用例会大大增加用例条数,excel 更利于管理

不需要维护的需求,直接 xmind;需要维护的,还是得 excel。要不重构或者回归的时候就火葬场了。

初晴 回复

主要看新的需求是否以后是否需要维护及当前的 xmind 用例是否有保留价值呢?
如果有的话,xmind 的数据可以像其他楼层提议转化 excel 保存下来,或者就使用适合的测试用例平台是比较合适的。

对于一个持续进行的业务,除了考虑当前是否方便,也得考虑后续的维护、参考及协做了。

初晴 #13 · 2021年09月14日 Author
JoyMao 回复

有些经常用到的,比如每个版本都需要回归的,是可以用 excel 来写一份或者建立一个管理网站,如果只是一个新增的需求,个人觉得用 xmind 会方便很多

就我来说,类似 excel 表格方式及思维导图的方式、甚至流程图方式的用例都存在,毕竟各有各的场景及方便之处。
表格类型适合执行时一条条过,思维导图适合设计时发散思考,流程图更是适合便于理解业务及执行时清晰了解执行的分支覆盖情况。
不必纠正统一那种格式。
如果是要有 1 个平台或者工具统一管理及方便执行,那肯定是比较好的





xmind 吧 特别是项目灵活的,且测试人员不是很够的情况,写用例耗时间而且不灵活,人少考虑的不完善。xmind 就可以一目了然,而且可以各种覆盖。。测试人员少项目迭代快需求不清晰的去写用例就存粹是耍流氓,你会发现很多时候用例满足不了以及不灵活

初晴 #10 · 2021年09月14日 Author
dxx4396 回复

emmm 如果是用楼上那种的话,其实这样子写的 xmind 用例相当于是用 excel 来写了,耗费的时间是一样多的

你们现在缺的是一个把 xmind 转换成 Excel 的工具

xmind 写测试用例,执行转换成 Excel 执行,试试这个工具,https://github.com/zhuifengshen/xmind2testcase

李胖 回复

用 xmind 写,可以把预置条件这种另外列一个单独项,有 bug 或者有疑问的加个外框备注这种也会好点吧😀

初晴 回复

上世纪大厂是这么写的吧。。。这玩意儿我们这儿培养测试新员工才这么写。

我推荐,第一种,可以加上写用例的规范,组内的人对相关产品和模块一起产出一份通用的用例(作用是告诉后来的人,类似模块的测试应该包含哪些内容)。
解决后来人不了解就让离职的人先做好工作交接给还在公司的人,新人不懂的地方直接可以过来问情况。
解决测试用例结果不好维护,测试结果只展示正向的结果,和正向结果有出入就是 BUG,提单记录,如程序认为不是 BUG 拉上产品解决问题,产品也觉得不是 BUG 那他就不是 BUG(记得 BUG 单关闭的时候附上处理结果,如聊天记录)

Ouroboros 回复

是的,我们大部分测试也是这么想的,感觉很浪费时间,但是领导们坚持说很多大公司都是这样做的😓

初晴 #36 · 2021年09月14日 Author
墨妖 回复

其实 xmind 可以用记号来标记通过或者未通过,然后测试完了可以用替换的方式把标记全部去掉

excel 不好维护。就 xmind 挺好。excel 可以移植过去的。

“人员变动,不方便后续人员测试。”——这算哪门子缺点。非要为这个理由花一倍多的时间写一大堆废话吗?

第一种缺点还有个不好维护测试执行结果,然后想要看用例快速了解需求,那用例写的是真好,感觉有点难

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册