在前面两篇文章中，小酋讲了软件需求和测试需求分析。在软件项目研发中，软件需求的重要性不再赘述。然而，在实际的情况中，测试人员可能会面临“压根没有软件需求”的尴尬处境。因此今天小酋将针对这些情况，给出一些建议性的解决办法。
我们在测试，可能会遇到以下没有需求的情况：
- 入职新公司，被测软件没有任何软件需求文档，公司需求原为口口相传，或者因为一些历史遗留问题导致需求文档丢失，这该怎么办？
- 版本快速迭代版本，产品设计人员托辞没时间，直接发布开发任务，这又该怎么办？
- 突然上面丢下一款“三无”软件，让你测试，这到底该怎么办？！
遇到这些情况，肯定不能直接说“No！拒绝测试”，除非领导有“必须要有软件需求才接手测试”的明文要求。
在一些棘手的情况下，让产品设计人员去整理需求，可能也不现实。
此时，具体该怎么做？
下面小酋结合自身工作经历和经验，整理了以下几点：
1、搜寻项目其他文档（如UI效果图、设计等）
纯粹靠口口相传研发的软件实属罕见。没有需求，至少有设计（如概要设计、详细设计），或者UI效果图这类文档。
因此，我们不妨找到项目版本库，去搜查这些文档。通过阅读这些文档，我们能对被测软件的功能模块和流程有一定程度（具体程度，取决于这些文档的覆盖度）上的了解。
至少，不会出现我们除了软件名，其他一脸萌萌哒的表情。
2、沟通、了解、确认
任何问题，沟通可能都是最好的解决途径。
软件需求没有的情况下，我们可以通过向产品设计人员、项目经理、项目开发人员或其他了解软件的人员进行沟通。
沟通时，注意“借力”。
大部分项目人员可能缺乏足够的耐心耗费自己的宝贵时间去向你讲解软件。所以，不管私下关系有多铁，在沟通之前，都应该向上级阐明要求，协调好人员和时间。这样，我们才能愉快的进行下去。
沟通时，我们最好准备一个问题清单，即要了解的内容，如：
- 软件背景是什么？
- 软件测功能模块和主要流程？
- 用户有没有特别的要求，比如兼容性、性能？
- ……
沟通时，我们应该做好记录；并在沟通后做好梳理，如梳理软件功能模块图、流程图。完成后，并向沟通人员进行确认，进行查漏补缺。
3、既有软件的熟悉
很多时候，没有需求，原因为我们是“接盘侠”？！
作为接盘侠，软件需求可能因为各种原因缺失。
比如，不赶巧，产品设计人员已经走了一波，软件需求不存在的，因为原来压根没文档、没原型，靠古老传递信息的方式：口口相传。
作为接盘侠，有个优势就是，软件已经不是一个全新的产品（不然怎么叫接盘）。我们可以通过既往的软件版本的操作使用，去了解、熟悉软件，并提取我们的测试点。
4、了解同类软件
比“接盘侠”所面临的更大的尴尬是：“天上”掉下款三无软件，直接让测试人员测试。
此时，如果我们没有同类软件的测试经验时，就需要多去了解市面上优秀的同类软件。
通过参考同类软件，去提取补充我们的测试点，包括功能、业务等。
5、切记做好评审，查漏补缺
通过前面4种方式，我们提取到测试需求后，最重要的工作是要做好评审。
做评审明面上是查漏补缺，
实际是让项目主要干系人（如产品负责人、开发经理、测试经理）对最终的被测软件的测试内容、边界、测试预期效果达成一致，避免后面扯皮、互相甩锅的混乱局面。
软件需求没有，很可能是项目研发流程出了问题。
为了避免后续继续出现这样的问题，我们可以“推动”后续改进（切记：尽力即可）
可能的方式：
- 向上级分析说明没有软件需求下的测试的时间成本。
- 与开发、UI设计等项目人员达成共识：软件需求对产品质量、项目研发效率起着决定性的作用。
- 尽可能的借力、借势去要求产品设计人员出软件需求：可以简化（如界面原型替代），但不能无。
最后：软件测试中，关于需求的问题还有很多，如果大家需要探讨交流的，可以给小酋留言，我后面会单独开篇向大家分享解决之道。
（微信扫一扫，有更多精彩等着你哦~）