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

前言

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

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

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

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

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

面试题：

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

应对策略

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

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

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

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

提供详细的需求文档。

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

应对策略

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

总结

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