本篇文章将从软件生命周期的第一步——需求分析开始，逐步深入地讲解软件测试实战工作。

需求，是软件项目研发的开始，是组建研发团队后的第一次集体参与讨论的内容，同样也是保障质量的重要一环。

为了让研发团队中各个岗位的人员充分理解需求，可以组织开展需求会议，进行需求澄清。

那么，在做需求澄清之前，先来了解什么是需求？

图片是一个网站的简单注册模块，比如，用户名长度 40 个字符、密码 8-16 位字母、数字下划线组合等，就是需求。

明白了什么是需求之后，进行需求澄清的时候，测试人员要深刻理解需求，在需求评审会议中，针对描述不清、不便于设计测试用例、找不准测试点、业务相关知识串联不起来的地方提出来，抛出疑惑，让产品经理给出说明。

比如，产生这样异常情况页面会给出什么提示信息？某个页面跳转后有几种状态，转态之间是如何转换的…… 多问几个为什么，后续的开展工作，可能就会更顺利。

上图中，仅仅针对快捷登录这个页面，就存在右侧的问题点需要了解清楚。

因此，为了需求会议能够达到预期的效果，参会人员都要提前细读需求文档，把问题点记录下来，然后在会议中高效解决。

作为一名测试工程师，你当然希望有一份详细清晰的需求文档。那实际的需求文档，又会是怎么的情况呢？

最差的情况：没有需求或者一句话需求

比如：做一个像淘宝那样的电商购物平台。

如果你遇到这样一个需求，真的是运气糟糕到了透顶。在测试中，很重要的一点是，我对需求有一个预期结果，再带着自己的预期来执行测试，对比实际结果是否与预期的一致？

但是现在，连需求都没有，该怎么办？

其实也不必慌，遇到这种情况，可以组织开需求评审会议，共同来完善需求文档；其次公司内部也会有相应的业务学习，或者邀请相关的专家来作为顾问等。

一般的情况：有需求文档，但是很粗糙

面对这种情况，有两种策略：

1. 如果开发团队配合，可以要求开发或者需求分析人员完善需求文档
2. 如果因为各种原因，比如时间紧张，或者开发就是不愿意配合，那就需要自己通过沟通，对文档中不明确的点问清楚，做好记录

切忌含糊不清就开始测试，于人于己都没有好处。

理想的情况：有详细的需求文档

如果你的公司是这样的话，那就恭喜你了。

有了详细的需求文档，测试团队就可以通过详阅需求文档来进行测试点的梳理工作。对于需求中不明确的地方，找项目负责人或者需求人员进行沟通，做到对需求整体把握和理解，利于测试更好地进行。

以上就是本篇文章所要分享的内容，欢迎各位大牛指正。你的指正，能让我在测试之路上快速成长。

Leo Never Stop Fighting！