前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >关于测试用例的几个观点

关于测试用例的几个观点

作者头像
张树臣
发布2018-05-15 16:25:17
7340
发布2018-05-15 16:25:17
举报
文章被收录于专栏:软件测试经验与教训

背景

这篇是自用文章,不过为了方便更多读者,适当介绍一下背景。

笔者最近换了新工作,可能是跟下属不熟悉的关系,昨天在会议上要求他们在用例中说清楚测试点。这句话引起了下属的一些情绪。我觉得这个问题有必要拿出来说一说,而且讨论这个问题的时候很容易从A变成B,这需要管理者警惕。

昨天讨论的问题,归结起来有三点:

  1. 为什么测试用例标题中要把测试点描述清楚?
  2. 为什么写测试用例?
  3. 测试用例应该写成什么样的粒度?

这几个问题,测试新手大都能说出个一二三来,不过据我了解,很多测试工作很多年的同行,在工作中仍会对此产生困惑。

为什么测试用例标题中要把测试点描述清楚?

首先申请,这个要求是基于我们公司的情况而定的,并不一定适用于读者所在的公司。

  • 我们公司用工具来管理测试用例,如果不在标题中写清楚测试用例,后期创建测试套件和安排测试都会受到影响,不好操作,必然会返工。
  • 虽然当时大家没说,我猜测不止一个人会觉得,用例写出来都是自己执行,自己都知道要测试什么。这句话我们分两方面来深入分析一下:(1)以后要区分产品线、也会不断来新员工、也会结对测试。。。。这都意味着其他人会执行你们写的用例。如果不写清楚测试点,别人必然要花更多的时间在你们的用例上,甚至还不一定能正确理解。这不是给别人制造麻烦吗?到时候就算别人不说,心里也会有想法吧,而且从风险控制的角度,怎么判断执行了这些用例就代表测试工作覆盖了全部需求?(2)其次,如果只是自己执行测试,那就带来一个问题,有必要写这些用例吗?把更多的时间放在测试执行上岂不更好?反正这些东西都在心里面有?

为什么写测试用例?

在这个问题上产生疑惑,大都是在测试时间紧张的时候应不应该写测试用例。

我的看法:如果用例只用一次,那可能确实没必要写。但我们现在一是在测试产品,用例必然反复使用,其次这个用例并没有让大家立刻写出来,没有影响到现在的工作。所以,当有人遇到这种情况时,先不要急着起情绪,先把问题搞清楚。换个角度说,我听到时间紧张就叫嚣不要写用例,我心里都觉得这句话换个说法就是时间紧张了,是不是就意味着我们可以对工作放低要求?

再说,用例是辅助我们测试的,即使时间再紧张,只写写测试点不过分吧?(这其实就是测试点了)

测试用例应该写成什么样的粒度?

首先申明,我很赞同做一些探索式测试,并不是非要大家把用例写的多么规范、步骤多么详细,做了一些要求也不是因为刚上任为了所谓的三把火可以的制定新规。

用例颗粒度要多细?原则上就是覆盖需求,但基于我们的情况,需求本身很多时候都不清楚,没有文档,产品是买的第三方公司的,大家对这个行业也没有多丰富的了解。那必然带来一个问题,就是很难把需求覆盖全面。

在这样的背景下,用例还不把测试点写的清晰一些,是不是留下隐患、自讨苦吃呢?

给还是员工的你一点个人小建议:

在领导拿拿着你做的事做例子去说一些事的时候,没必要着急去解释、理论, 因为一般领导没打算听你的解释,只是在就事论事。领导不打算听,其他人听了意义也不大,所以领导很可能就觉得你在浪费大家时间,显得不职业。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2017-10-11,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 软件测试经验与教训 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档