需求测试可以尝试着这么来做
相信很多人跟我有过一样的困惑，那就是在需求阶段我们测试人员到底应该如何对需求进行测试？大家应该都经历过因为需求的缘故而导致大量的返工，造成进度上的delay以 及线上BUG的遗漏，要想得到好的result当然离不开一个好的process支持。那么我们在项目的前期，应该如何对需求进行把关呢？个人建议可以从需求的完整性、正确性、二义性这三个方面来着手，随着测试经验的积累，逐渐培养自己挖掘隐藏需求的能力，充分发现需求中不完善，不严密的地方。那么我们具体应该怎么做呢？第一步,先收集一切与需求有关的资料，如果可能的话，最好能拿到PD与运营方会议的讨论细节，里面一般会包含一些用户使用场景的讨论，这对我们的测试工作应该是很有帮助的。我们可以按模块去确定所包含的功能点，分析该功能所对应的actor，明确actor之间的关系。针对单独的usecase去分析其对应的输入、处理、和输出,将自己的分析有条理的写出来：不同条件下执行某操作后得到不同的结果。
第二步，分析业务流程，明确需求分析中不同的usecase所组成的业务，形成一系列的业务场景活动图：拆点: 对应的每一个功能点将其对应的输入,处理和输出进行提取; 连线 :将每一功能所对应的输入,处理和输出形成业务活动图;
第三步，了解系统所涉及到的数据流，分析功能入口和角色权限。确定系统的数据流动，包括系统的内部模块间数据流和系统间的数据流接口，在这些地方一般都比较容易出问题 。确定系统拥有多少角色（业务），他们负责什么样的工作，在系统中体现在那些模块中。然后画出这些角色的用例，或者他们涉及的业务。我们可以先把每一个角色所做的每一 个功能点列出来，然后再将它们放到一个完整的业务流中去；或者先画出整个的业务流，然后再分配给角色。最后得到一个完整的图，它包含整个系统所有业务流程，并且有哪些 角色在某个节点上能够做哪些操作（拥有哪些权限），这些其实就是我们测试的重点。
第四步，确定公共部分需要测试的需求。系统中有一些部分是很多角色所共同拥有的，并且不涉及具体的业务流程。将这部分内容整理出来，一般来说这些内容只会涉及到界面和
普通功能的测试，如定义系统界面风格。
针对需求完整性的验证方法：
1.项目范围是否清晰？应该能清楚的标明哪些功能要实现，哪些功能本期不实现，这样我们才能确定测试范围。
2.是否说明了对每个输入的验证措施，并描述了每个输入的属性，如：边界值、时序要求等以及对于出错时的处理
3.是否清楚描述了系统中与其它子系统、模块间的关系，包括页面的跳转，传递的参数，对于业务逻辑的控制是否需要两边都进行控制还是只需要调用方进行控制即可？这个主要是用于项目中涉及到系统之间的调用的情况
4.对于是改造型的项目，是否已经说明了对历史数据的处理？如果对于新老系统共存的情况下，要说明两个系统之间数据的处理关系，以及数据迁移时需要关注的内容
5.页面展现的处理：对于不允许进行操作的控制，是直接进行屏蔽还是展示后进行相关控件的disable处理
6.借助数据流图以及状态转化图对需求进行测试，检查每个路径的步骤是否都清晰明了，主干过程、分支过程、异常处理的每个步骤是否都已经描述清楚了参与者要干什么？系统要响应什么？是否还存在开环的情况？
7.是否有对用户类型的描述？需求组合是否充分地考虑了所有异常的情况?是否已经考虑到了所有人的需求？是否充分地提出了边界情况？所有到其它需求的交叉引用是否都正确?
针对需求正确性，二义性的检查：
主要是考虑文档中是否存在描述模糊的地方，对于模棱两可的问题，一定要明确具体的输出是什么，可以通过与PD进行讨论实际所想表达的内容，对于文字描述不清楚的地方，建议用图片的方式进行页面的交互。由于自然语言极易导致二义性，如果有条件的话，建议还是用基于原型的方式进行开发，这样可以在早期杜绝掉交互上出现的问题。来看一个功能需求的例子：“销售出货要考虑到信用额度”。 这里存在的问题就是出货与信用额度之间的依赖关系没有描述清楚,我们把它修改成：1.销售出货的前提是该客户拥有超过出货价值的信用额度XXX, 否则,系统提示‘该客户信用额度不足,不予出货!’ 2.正式出货后系统将扣减其信用额度 很显然,修改后的需求把出货和信用额度的来由去向和系统的具体反应都说明清楚了。如果你接手的项目也存在这样类似的问题，则一定要在需求阶段明确要求PD对需求做出调整。
要善于挖掘隐含需求，看一下下面的需求：“本月没有参加过竞价的会员显示0；本月参加过竞价的会员显示出价次数”这个需求看上去已经描述的很清楚了，但实际去测试的时候，我们必须覆盖以下的业务逻辑：从来没有出价记录的会员显示为0；上月有出价、本月没有出价的会员显示为0；本月有出价的会员显示出价次数。挖掘需求背后的测试要点，需要我们平时一点一滴的积累，不要被表象所迷惑。
我们一定要以测试目标为中心，去查找不充分的不完整的需求，通过以上的过程，我们可以把不直观的需求转变为直观的需求, 把不明确的需求转变为明确的需求，直到所有的问题都得到了解决并经过再测试OK，需求阶段的测试才可以结束。 分析的挺具体的 不错不错 必须顶一下，，，:):victory: 写得非常详细，赞一个！
页:
[1]
