本篇文章将从软件生命周期的第一步——需求分析开始,逐步深入地讲解软件测试实战工作。
需求,是软件项目研发的开始,是组建研发团队后的第一次集体参与讨论的内容,同样也是保障质量的重要一环。
为了让研发团队中各个岗位的人员充分理解需求,可以组织开展需求会议,进行需求澄清。
那么,在做需求澄清之前,先来了解什么是需求?
图片是一个网站的简单注册模块,比如,用户名长度40个字符、密码8-16位字母、数字下划线组合等,就是需求。
明白了什么是需求之后,进行需求澄清的时候,测试人员要深刻理解需求,在需求评审会议中,针对描述不清、不便于设计测试用例、找不准测试点、业务相关知识串联不起来的地方提出来,抛出疑惑,让产品经理给出说明。
比如,产生这样异常情况页面会给出什么提示信息?某个页面跳转后有几种状态,转态之间是如何转换的…… 多问几个为什么,后续的开展工作,可能就会更顺利。
上图中,仅仅针对快捷登录这个页面,就存在右侧的问题点需要了解清楚。
因此,为了需求会议能够达到预期的效果,参会人员都要提前细读需求文档,把问题点记录下来,然后在会议中高效解决。
作为一名测试工程师,你当然希望有一份详细清晰的需求文档。那实际的需求文档,又会是怎么的情况呢?
最差的情况:没有需求或者一句话需求
比如:做一个像淘宝那样的电商购物平台。
如果你遇到这样一个需求,真的是运气糟糕到了透顶。在测试中,很重要的一点是,我对需求有一个预期结果,再带着自己的预期来执行测试,对比实际结果是否与预期的一致?
但是现在,连需求都没有,该怎么办?
其实也不必慌,遇到这种情况,可以组织开需求评审会议,共同来完善需求文档;其次公司内部也会有相应的业务学习,或者邀请相关的专家来作为顾问等。
一般的情况:有需求文档,但是很粗糙
面对这种情况,有两种策略:
- 如果开发团队配合,可以要求开发或者需求分析人员完善需求文档
- 如果因为各种原因,比如时间紧张,或者开发就是不愿意配合,那就需要自己通过沟通,对文档中不明确的点问清楚,做好记录
切忌含糊不清就开始测试,于人于己都没有好处。
理想的情况:有详细的需求文档
如果你的公司是这样的话,那就恭喜你了。
有了详细的需求文档,测试团队就可以通过详阅需求文档来进行测试点的梳理工作。对于需求中不明确的地方,找项目负责人或者需求人员进行沟通,做到对需求整体把握和理解,利于测试更好地进行。
以上就是本篇文章所要分享的内容,欢迎各位大牛指正。你的指正,能让我在测试之路上快速成长。
Leo Never Stop Fighting!