认识达内从这里开始

我们在前几期的文章中给大家简单介绍了软件测试都包含了哪些测试环节等内容，其中我们就说到了做好软件测试是需要进行需求分析的，而本文我们就简单来了解一下，常见软件测试需求文档类型与处理方法。

1.没有需求文档或一句话的需求

现状描述

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

我们知道软件测试很重要的一点就是需要有一个预期结果，把软件运行的实际结果跟预期结果进行对比，若达到预期值，则测试通过，反之测试不通过。那么如果碰到这种描述不清晰的需求，我们该怎么做?

面试题举栗：

一句话的需求：做一个外卖点餐APP

拿到这种需求，先可以向面试官询问更多的需求信息(比如：应用场景、针对的客户群体……)，不过面试官给到你信息后肯定还是不够的，这时可以这样回答“这个需求不够明确，有不少信息还需要补充，我们通常是打回处理，不过基于当前的信息，我来说一下我考虑的点，相关疑问点后续会提给产品经理，让其确认”。

设计测试用例，利用发散思维把能想到的问题都罗列出来(作为待确认即可，当然也可以提出自己的想法)，多维度考虑问题，例如：功能、性能、兼容性、易用性、安全等，运用等价类划分法、边界值分析法、场景法、判定表、因果图、错误推断法、正交试验法等手段进行设计。

当然还有许多需要考虑的地方，但是面试时只需要表现出你有足够的发散能力就OK了。

应对策略

如果在企业中碰到这种一句话需求的项目，我们需要多沟通协商、多确认、多从用户角度思考，大家都确认没问题，这样才有的测，有问题就不断沟通。

2.需求文档很粗糙

现状描述

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

应对策略

如果研发团队很配合，可以要求开发或者产品经理完善需求文档。

如果因为各种原因，比如：时间紧张、开发不配合等，那么就需要自己去沟通，对于文档中不明确的点进行标记整理，抛出问题进行澄清，切不可含糊不清地测试。

直接喊产品经理、研发人员一起开会讨论，过一下需求点，整理出测试点，抛出疑问确认，达成共识，实现高效信息同步。

3.详细的需求文档

现状描述

有详细的需求文档。

比较严谨负责的团队，项目的实施有详细的需求文档，我们就可以仔细阅读需求文档来进行测试点的梳理工作，对于需求中你认为不明确的地方可以找项目负责人或产品经理进行沟通，做到对需求整体把握和理解，利于测试更好地进行。

应对策略

基于用户使用的场景和行业的经验去做判断，判断它是否合理。

总结

总而言之，无论需求大小，需求文档是否详细，是否一句话的需求，只要我们基于这句话，发散思维，产生并抛出疑问，通过不断设问来圈定需求范围，再针对每个问题的给出解决方案，问题就能迎刃而解。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。