需求评审之后，开发人员一般会开始拆分任务，测试人员需要对新需求进行消化，消化过程最好的产物就是输出对新功能的需求项梳理，并且根据需求项列出测试注意点以及影响模块。这个过程很像去肉剔骨，抽丝剥茧的感觉，也就是掌握到了版本的精髓。

需求点的形式有哪些呢？简单来说就是这个版本产品提出的希望实现的很多个功能点，比如：需要给门加一个锁，这就是一个需求点，智能锁还是机械锁，能不能支持反锁，装几个锁，安全性怎么样，可靠性怎么样，这些是根据需求点发散的测试点，这些测试点有一些在文档里有说明，有一些是没有说明的，需要根据用户实际使用场景考虑。

很多人又会有这样的疑惑：测试项和需求项之间的区别有哪些呢。不看以下内容，你脑海里首先蹦出来这两者的区别是什么？

打个比方：需要在手机上返回桌面，有哪几种方法：1、多次按back键；2、直接按home键。3、menu键选择退出，在这个过程中，返回桌面就是需求项，后面的3种方法就是测试项。

往往我们在参加需求评审会议时需要梳理出需求项，在参加测试点评审时需要预先梳理出测试项。

需求项和测试项可以简单粗暴的理解为一个是功能点，一个是实现该功能的途径和渠道。包括正确的渠道和错误的渠道。

需求项和测试项划分之后，就可以设计用例了。

编写测试用例时，需要按照如下规格划分测试内容。

首先是功能模块，其次是需求项（功能点），最后是测试项。测试结构最好不要超过三层。

比如回到主页是需求项，测试项可以是左上角返回，按手机home键，按手机返回键。测试项是一个完整的句子。