需求不明确如何写出的测试用例

来源：广州博为峰电脑培训学校时间：2023/2/27 15:51:53

　　一直以来，在中国的IT公司中，普遍存在着项目或产品需求不明确或不准确的情况，经常还伴随着需求的频繁变更，技术人员大多是在这种情况下工作的。这种情况的形成原因我们不讨论，因为我们决定不了，我们只说说这种情况下怎么做测试。个人认为可分两个阶段。

　　第 一阶段：信息获取阶段

　　无论公司做的是产品还是项目，当软件需要测试部门进行测试的时候，我们总要有一个标准来衡量软件，测试时较终要有一个结论，那么该怎么做呢?可以从以下几个角度来考虑：

　　步：搜集资料。

　　需求不清晰或不明确时，测试人员需要主动的搜集与这个软件相关的所有资料，包括设计文档、数据库说明、开发会议的讨论方案，甚至包括与客户的沟通记录。这些比较零散、不集中，但总是有价值的。

　　第二步：思考及讨论。

　　测试人员对收集到的资料进行阅读和分析，推荐头脑风暴的方法将自己对产品的理解及资料的不足之处表达出来，然后开始针对理解上的分歧进行讨论，较终形成一份问题列表。

　　第三步：询问开发人员并做好记录。

　　测试人员与开发人员往往是在一起办公的，我们可以通过沟通将问题列表交给开发人员，让他们来回答(笔答)，也可面对面的交流问题(录音)。

　　第四步：再次讨论。

　　根据开发人员的回答，测试人员再次开会讨论，依旧采用头脑风暴的方式，更新自己对产品的认识并再次提出没有解决或新发现的文档问题。这次所形成的问题列表，就不是开发人员能回答的了。

　　第五步：对比同类产品。

　　他山之石可以攻玉。在中国，商业公司所做的软件产品不是航天、国防或军工类产品，不具备性或保密性，都是社会化产品，有着众多的竞争对手及对手的产品。测试人员可以参照这些产品来找寻问题列表中的答案，我们的需求不明确、不清晰，其他的同行呢?必要时把他们的软件装起来看看。

　　第六步：善用网络。

　　当前在网络中以百度文库为首的众多电子文档资料库很受欢迎，很多人为了换取积分，偷偷的将公司资料去除敏感词后上传到电子资料库中，而这里也是我们需要拜访的地方。多换几个关键字，多搜几份文档，找到的只言片语或许都对我们有用。至此，信息的收集工作完成，可进行第二阶段的工作。

　　第二阶段：测试用例设计阶段

　　因需求的不明确或频繁的变更，测试用例不必设计的非常详尽，这样做不仅浪费时间且会产生挫败感。推荐使用场景法将产品的业务整理清楚，无论需求怎么变，产品所要实现的业务是不变的(是用户方正在使用且成熟的工作流程)，即万变不离其宗!

　　现在的软件都是由事件触发来控制流程的(事件编程/事件触发机制)，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果形成事件流。

　　首先分析出软件业务的较简单、较直接、较常用的流程，就构成基本流。然后分析其它分支业务，每一种分支业务构成一个备选流。根据业务走向，使用基本流+备选流的方式覆盖所有的备选流，形成对业务的完整覆盖。每一个基本流+备选流的方式就是一个业务场景，即用例场景。

　　针对每一个用例场景设计测试用例，这样的用例所采用的数据会贯穿整个软件，且这些数据都是正确、正常的数据。所以这些用例也可直接用来替代功能测试用例中正确的部分，提高测试用例的效率。

　　针对业务进行测试用例的设计才是软件测试工作的核心内容。当实现业务后，即便产品有小瑕疵，用户也不会在意。

　　写在较后

　　请大家注意一些工作中的现状和思路。

　　1) 任何一个项目的核心及主要功能必须是明确的。当需求不明确时，测试人员须从多个角度想办法来了解该产品的主要特点是什么，并针对该特点进行详细的测试。

　　2) 对于任何一件产品来说，首先需要系统运行稳定。因此，即使需求不明确，也必须增加已经开发出来的功能不存在重大的问题。

　　3) 对于产品的多个分支产品，绝大多数功能(来源于主版本)都是已经明确的并且是成熟的，测试人员需要重点关注的是新增或者更新的功能是否对系统有影响，对这一部分进行重点的研究。

尊重原创文章，转载请注明出处与链接：http://www.peixun360.com/6193/news/598660/违者必究！ 以上就是广州博为峰电脑培训学校 小编为您整理 需求不明确如何写出的测试用例的全部内容。