7、 是否存在一些普通的动作序列可以分解成独立的用例?
用例之间也有可复用的,能够把公共的动作序列独立出来，用例达到可复用的目标也是用例撰写要考虑的。
8 每个路径的步骤是否都清晰明了,无歧义而且完整?
用例中的主干过程、分支过程、异常处理的每个步骤都建议使用主动结构来陈述,即参与者要干什么、系统要响应什么,一步一步地描述直到完成整个用例流程。这个用例通常会是参与者完成了一个业务或任务流程。
9 、用例中的每个参与者和步骤是否都与所执行的任务有关?
要防止用例目标和用例描述出现了文不对题或牛头马面的现象。
10 、用例中定义的每个可选路径是否都可行和可验证?
用例描述与用例图的每个动作序列保持一致，是可以经过验证和系统执行通过的。
11、用例的前置条件和后置条件是否合理?
分析师必须确认用例的前置条件和后置条件准确界定了用例的边界范围,区分了用例和用例之间的界限。
分析师经常会发现在检查一个包含九个步骤的用例时,发现执行完第六个步骤就满足了后置条件,第七、八、九在用例的边界之外,很显然是不必要的。同样,用例的前置条件必须是启动在第一个步骤就已经满足。
八、 注意需求评审会的过程和结束 标准
通常，需求评审会都不是件容易的事情,业务审查人员分散在各个地域和时间上的不一致性是困难产生的所在。在很多情况下,我们可以使用 分布式需求评审软件从网络上对需求文档进行预先评审,而在评审会中则要注意不要使评审会演变成了“业务会”或“技术研讨会”。
同时,需求评审会的结果是对需求规格书完成了评审过程,那我们又如何判断审查的结束标准呢?请看如下几条建议:
1 、审查期间评审员们提出的所有问题都已经解决。
2、 相关文档中的所有更改都已经正确完成。
3、 修订过的文档进行了拼写检查。
4 、所有标识为TBD(待确定)的问题已经全部解决, 或者已经对每个TBD的问题的解决过程、计划解决的目标日期和责任解决人等编制了文档。
5 、需求文档正式进入了配置库。
本文阐述了需求评审和确认的一些”注意”事项，一旦完成需求评审将表示进入了需求设计阶段，欲知需求设计如何实现，且听下文为您分解。
文章来源于领测软件测试网 https://www.ltesting.net/
