需求评审
需求会议评审的最根本有以下几个目的：
第一，评审需求中产品设计的功能中有问题的地方，和没有量化的地方，比如功能设计的字段的类型和限制长度，规则等等。
第二，评审需求中有问题的地方我们肯定都要推动产品进行修改最终达成一致。
第三，我强调为什么要量化，只有量化之后，测试才能后期的用例编写，开发才能进行一些程序设计包括数据库设计。
什么是量化？
我举个简单的例子：
比如某软件登录是手机号登录，产品设计的文档中写的是输入规范的手机号。
这句话就是有问题的，没办法量化，什么是规范的手机号？
如果说手机号为首位为1,11位数字，这样的需求才是没问题。
开发才有可能投入到对数据库字段以及表的设计过程中。
比如：规定为Varchar（11）别问我为什么不用int或者bigint等等，这篇文章不解释。
测试才有可能用等价类，边界值进行手机号测试。
今天写出来的原因是因为，我们做一件事情之前，我们首先需要知道做这件事的意义这样我们才不会迷惑。
就跟上面我们了解了事情的本质，我们就才能知道需求评审对于测试人员重要。
你认真的评审产品需求会获得以下的好处：
第一，深刻的熟悉被测软件的业务。
第二，在产品设计初期帮助整个团队避免了很多错误，和软件测试原则越早介入越好，最好在需求阶段就介入，因为最严重的的问题不外乎是需求出现了问题。
第三，一份好的需求评审会议，对于你后期的测试用例编写会带来极大的好处，会少了很多返工的无效工作。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
