需求评审分析什么——测试维度

软件质量的六个标准：
1:功能性；
2:可靠性；
3:易使用性；
4:效率；
5:可维修性；
6:可移植性

测试人员，可以简单的分为4个级别。

第一层：功能性上保证。做好本职工作，考虑正常的业务主线以及各种异常流，尽量不出现问题。
测试的最重要最基本的问题，就是保证产品质量，做到发布上线没问题，那么，在需求评审的时候，首先了解这个需求本身是做什么，具体是怎么做的，考虑业务正常操作的主干线，以及，还要考虑各种异常流（比如用户的其他非法操作等）
这里再引入一个三种流派的概念：
1:基本流：也称为基线，正常的操作，最终完成预期效果；
2:备选流：其实备选流分成2种，一种是不同的做法，最终达成目标效果；另一种是不同的做法，最终没有完成预期效果。
3:异常流：就是上述备选流里面的，不同的做法，但最终未完成预期的情况。也称之为基本流的异常情况。
正常工作中，把备选流放入基本流中，统一为基本流，记录正常的场景，而异常流就记录基本流的异常情况，这样会更清晰。

第二层：从技术层面给予考虑，考虑实现问题。
比如说，产品说，我要在这里显示一个图，有xxxxxx的效果，这个时候技术可能就会说，这个我们目前技术上没法实现，因为这边是怎么怎么写的，接口是怎么调用的。
而测试也是可以这样，比如说，产品说，我们要支持批量生成入库信息采集表，同兼容10000的并发情况；这个时候，测试就考虑，这个我们目前可能实现不了，因为批量生成的时候，会在wms后台对应生成待审核数据，而之前做过压测，这个接口承载不了这么大的并发量。

第三层：考虑上线之后可维护性、可扩展性
这个东西这么上了，目前是没问题了，上线也没问题了，但是后期呢，后期如果要做个改造，或者在这个基础上，再扩展、增加一些功能，是否支持，不至于这个功能上线了，就不能再在上面增加一些别的。

第四层：架构上面设计。
这个就是很宏观彻底的分析设计，总之很牛（个人想法）。

另外的，至于我们说，测试去站在客户的角度思考问题，考虑需求的合理性，这个其实是不应该被强调的点，因为这个考虑是一个个人主观考虑，一点都不客观，而且产品产生需求，前期是做了很多的调研以及数据分析的，是比较客观的存在。但是如果从现有的业务角度，考虑一些可能真实存在但是被产品遗漏的点，这个还是可以的。