敏捷模式下的测试用例该如何存在? - 51ste.com
登录|注册

敏捷模式下的测试用例该如何存在?

作者:testbird  发布时间:2020-01-03 15:03:48  关键字:敏捷测试 敏捷测试用例 

软件行业发展到今天,可以说是步伐越来越快了。老板们坚信,时间就是金钱。早一天上线就是早一点占领市场。于是敏捷开发,敏捷测试的概念流行开来。所谓敏捷,说白了就是没时间。在敏捷模式下,团队几乎没有时间写文档。在不断强调质量之后,研发团队又被要求一快再快。那么作为测试人员,如何“敏捷”的完成自己的工作呢?

我们回顾一下常规的测试流程:需求分析--编写用例--执行用例--回归验收。其中,写测试用例占用了我们大量的时间。很多小伙伴都抱怨说,测试时间太紧张啦,根本没有时间写测试用例啊!嗯,敏捷模式下我们确实没有时间写详细的测试用例(包含详细测试条件、步骤)。但是,没有文档的测试常常让测试人员感到心里没底,甚至逻辑混乱。那么,我们可以写测试点。关于测试点,我分享一下我个人的经验,希望能帮助大家。

曾经习惯用Excel写测试用例。到了敏捷,就习惯用它来写测试点。一般来说用一句话概括一个测试点,一句话中包含测试条件以及预期结果。测试时用颜色标记执行结果。

常用句式为:XXX(条件)时,XXXX(预期结果)。以登陆举例:
测试点1 输入正确的用户名和密码时,登陆成功。
测试点2 输入正确的用户名和错误的密码时,登陆失败,提示:密码错误。

如此,以足够指导自己测试。有小伙伴喜欢把测试点写成思维导图的形式,清晰明了,也不失为一种好的方法。工具形式神马的看个人习惯,能简单高效的写清楚就好。
 
对于多个平台相互关联的测试,我一般习惯把平台放在一起列在表格里。如比较常见的是app和pc端关联,思路一般为同一条件下,app如何显示,pc端如何显示。如此用例清晰明了,也比较高效。
 
很多小伙伴的公司用例都是有固定模板的,我这里想要和大家说明的一点是,固定的模版是比较影响发挥的。为了高效,大家完全可以打破模版,根据待测产品的特点来设计模版,让用例更清晰明了,执行更高效,让测试人员思路更清晰,这个才是最重要的。
 
下面说点敏捷下关于测试的两个小tips

01 关于测试能力

很多小伙伴都有这样的困惑:空有一身的本领,面试之后就完全用不上了,到了实际工作中还是点点点,完全不能理解企业为什么花大价钱请了一个点工。

这里我想给这样的小伙伴打打气。其实企业比我们想象得精明的多,在敏捷模式下,企业希望招聘更有能力的测试,来提高效率。会数据库的测试可以更准确的找到数据问题,懂接口的测试可以更精准的定位问题所在,懂代码的测试更容易猜出开发哪里写的不对。

在测试初期,当待测模块受上游功能限制时,有能力的测试会自己做测试数据来满足自己的测试条件,而不是一味的找开发给做数据或干等全流程做好了再测。我们都知道,测试介入得越早,越能争取到更多的测试时间,也能更好的帮助团队保证质量,提高效率。所以,就算是我们做点工,我们也是一个高效的点工。
 
02 关于回归和验收

测试的最后阶段,很多测试人员都曾遇到这样的情况:提出的bug开发人员已经全部修改完了,现在怎么点也点不出bug了,但是因为没有像传统测试那样的流程一板一眼的执行测试,总觉得心里慌慌,生怕漏测而不敢提交。

这个时候,我要对你说的是:兄弟莫慌!其实这个阶段从研发团队的角度来说不会再发现什么明显的问题了,那么我们要做的就是结合具体的业务来进行测试。可以从生产上导出真实数据进行测试,也可以请教使用系统的客户进行操作。

总之,想办法让自己站在客户的角度上,尽可能的用客户真正使用的角度上去操作。此方法对于专业性比较强的软件来说尤其适用。很多公司会安排准生产环境邀请客户来做最终的验收测试。这些都是保证产品质量的方法。

敏捷模式对于开发和测试都比较有压力。压缩的工期,不足的人手,庞大的工作量,都是敏捷模式下带来的问题。除了加班为了提高效率非常重要的一点是,必须对业务非常非常非常熟悉。团队中的每一个人,无论是研发还是测试,除自己负责的模块外,尽量去多了解了解其他相关模块的业务。这样不仅能够减少漏洞,还能使团队更紧密的配合,从而提高整个研发团队的工作效率。

--End--

以上是我在版本周期高速迭代的团队中总结的实战经验,希望能帮助一些在敏捷环境中工作的测试小伙伴。

本文由51ste.com网友编辑,未经授权,不得转载使用上述作品盈利;个人转载,需标明原文作者及出处。

更多相关文章

说说看法查看全部评论(0)

微信二维码

部落微信公众号

QQ二维码

部落QQ群二维码