怎样从测试的角度来参加需求评审？

silvertree

怎样从测试的角度来参加需求评审？

比方说全面性、可测试性等等

[ 本帖最后由 silvertree 于 2006-12-13 18:30 编辑 ]

huangsh2004

需求一致性。比如：业务概念在各子系统中时候一致使用，业务活动是否满足整个系统中的业务约束等等。建议先了解整个需求了，有个大概的理解后，去分析细节，可能你会有所发现。
至于可测试性，个人理解为可验证，就是说待讨论的需求，是可以使用某种技术手段去验证的。

Qvist

要看你对系统的了解有多少，如果接手的是从未涉足过的项目，只有学习的份了吧。
如果对系统有一定的了解，在参加评审前必定要熟悉软需。
全面性，感觉主要还是对整个系统有个通盘的考虑。软需设计是否有缺漏，是否可能会存在性能，效率问题。
至于可测试性，不太明白，难道有不可测试的程序吗？

hmilyjch

可测试性是对需求的可测试性
可能需求描述不是很明确
比如需求对性能的要求只有一句话：性能良好
这句话能测试么？

wonder

在看需求的时候就可以顺便考虑一下测试用例会如何去写， 这样很容易发现一些别人考虑不到的问题。比如：
1，原有的功能是否已经可以折中的满足现在的需求？（需求的必要性）
2，需求中说明的流程是否遗漏了一些异常的操作情况。
3，流程动作或者状态是否没有明确， 或者有二义性？
4，操作是否符合用户的习惯？是否可以实现更人性化更简单的操作？
5，是否存在潜在的性能问题。
等等。

刘洪鹏

对于一条软件需求或着一个软件需要实现的特征，必须存在一个可以明确预知的结果，并且可以通过设计一个可以重复的过程来对这个明确的测试结果进行验证。说得具体一点，就是要保证所有的需要实现的需求都可以用某种方法来明确的判断是否符合需求文档的描述，如果对于某条需求或某个特征无法通过一个明确的方法来经行验证，或者无法预知的结果，那末就意味这这条需求存在缺陷。

phoenixDT

楼上说得有点道路
但是对于采取什么方法来验证需求，并没有涉及到。因为测试的时间总是不够用的，而且软件需要大量的需求。