软件需求文档的三种现状及应对策略(一)(组图)

前言

众所周知,软件需求是软件项目开发的开始,是研发团队组建后的第一次集体讨论,是保证质量的重要环节。

对于测试人员而言,测试设计和测试用例的编写取决于需求文档。因此,在需求阶段,需要对需求中不合理或难以理解的部分进行澄清,提出问题,并得到确认。为后续工作扫清障碍。

需求文档的三种现状及应对策略1.没有需求文档,也没有一句话描述需求现状

如果你很倒霉,遇到这样的一句话需求或者简单的描述需求,就需要设计测试用例进行测试。相信大家或多或少都遇到过,或者在面试的时候遇到过(这种面试题主要考察遇到不合理需求时的解决方案,以及是否有发散的测试思维)。

我们知道软件测试很重要的一点就是要有一个预期的结果,将软件运行的实际结果与预期的结果进行比较。如果达到预期值,则测试通过,否则测试失败。那么遇到这样一个没有明确描述的需求怎么办呢?

面试题:

一句话需求:做一个外卖点餐应用

应对策略

如果我们在企业中遇到这种一句话的项目,就需要多沟通协商,多确认,多站在用户的角度思考。大家确认没有问题。只有这样我们才能不断测试和沟通,如果有任何问题。

2.需求文档很粗略的状态描述

有需求文档,但是需求文档很粗糙。

图片[1]-软件需求文档的三种现状及应对策略(一)(组图)-唐朝资源网

应对策略3.详细的需求文档状态描述

提供详细的需求文档。

更严谨、更负责的团队,对项目的实施有详细的需求文件。我们可以仔细阅读需求文档,梳理出测试点。如果觉得需求不清楚,可以找项目负责人或者产品经理。对需求进行沟通,整体把握和理解,有利于更好的测试。

应对策略

根据用户的使用场景和行业经验,判断是否合理。

总结

总而言之,不管需求大小,需求文档是否详细,或者是一句话的需求,只要我们根据这句话发散思维,产生问题,提出问题,勾勒通过不断提出问题的范围要求,然后针对每个问题。如果给出了解决方案,问题就会得到解决。

© 版权声明
THE END
喜欢就支持一下吧
点赞124 分享
评论 抢沙发
头像
欢迎您留下宝贵的见解!
提交
头像

昵称

取消
昵称表情代码图片