从事测试工作的各位同学都知道，测试用例在软件测试活动中是最重要的，它是测试工作的指导，是软件测试必须遵守的准则，更是软件测试质量待定的根本保障。
在实际的软件产品或是项目中，测试用例的设计，基本上都是几百条，或是上千条，如遇到大项目或是新建系统或平台，可能是几千条以上的测试用例，在项目紧张的周期下，组织项目中的各位专家对每条测试用例进行逐一评审的可能性和可行性极低，但测试用例的评审又是重中之重。
测试列表
评审测试用例，除了了解测试人员对测试用例设计的方法、思路，还审视测试用例是否覆盖得正确、全面、连贯和可操作性。
因此，需要对测试用例的设计方法、思路及场景进行分类和归纳，继而对分类和归纳的测试用例进行评审，这样，既能审视测试用例的覆盖率，又能节省项目组各位成员的时间。这种对测试用例的设计方法、思路及场景进行分类和归纳的点，称为测试列表。
编写测试要点，可以采用Excel表格法或是思维导图法，无论是哪种方法，都需要先对功能点进行拆分和归类。
比如，页面的验证，验证点包括UI、边界值、按钮功能、数据传输、数据加密等等，因此，需要对这些进行归类，把同一类的验证点放在一起。
比如：
-
UI类中，对整个页面的所有要素及按钮的检查。检查点包括要素和按钮的名称是否正确、位置是否正确、大小和颜色是否正确，这些归纳一个拆分点；
-
对页面中各要素的必填项控制是否正确，这些归纳成一个拆分点；
-
对页面中各个要素输入的值进行验证，包括正常值、最大小值、特殊字符等这些字段的值控制，归纳成一个拆分点。
Excel表格法
下面就用Excel表格法，说明每一列的用法。
如图一，测试列表可分为最少六列：系统名称、交易模块、测试要点、计划编制测试用例数、实际编制测试用例数和备注。
01、系统名称
显示当前要验证的点属于哪个系统，在不同的系统上，可能存在要验证的点是一样的。
02、交易模块
显示当前要验证点的属于哪支交易，在不同的交易上，可能存在要验证的点是一样的。
03、测试要点
以一个同类的拆分点为单位，总结列出每个拆分点需要验证的内容。
04、计划编制测试用例数
写出一个测试要点里面计划需要编写出多少条测试用例。
05、实际编制测试用例数
一个测试要点在实际编写出来的测试用例数。
06、备注
需要其他情况说明。
举例说明
举一个最常用的场景：客户去银行开户，开户成功就可以拿到相应的卡和卡信息。
这个场景涉及到的需求可以拆分为需要新增客户开户资料填写的页面，页面提交到审批的流程的设计，最后到核心记账的功能。
对应涉及到的功能点为前端需要新增一个页面，中间需要设计开户审批流程的转换，最后到核心记录客户的资料信息和开卡的卡号。
需求分析人员根据业务需求，编写出一份需求分析说明书，开发工程师编写出概要设计文档和接口文档，测试工程师拿到这些文档后，对需求点进行测试要点的拆分。
图一
对于按钮的归类，拆分为正常提交及重复提交，以验证正常功能及异常功能。
开户在前端提交后，流转到审批流程，对于接口类的验证的测试要点，可以归类于：
需要做性能测试的小需求，没有单独出性能测试方案，也可以先在测试列表中列出来，以免在写测试用例和执行的时候，忘记需要出测试脚本来做性能测试。
以上的测试要点整理成测试列表，在测试列表完成后，组织项目中的各位专家对测试列表评审。
总结
对测试列表评审有以下的好处：
第一，节省各位评审专家的时间，节约项目成本；
第二，要验证的测试要点的内容，各位评审专家对列表，都会有清晰的了解和认识。在评审过程中，容易总结出是否还存在遗漏的测试点或是场景；
第三，在测试列表评审通过后，在编写测试用例时有指导的方向，不会遗漏测试点或测试场景；
第四，当测试用例执行完成后，测试经理或是测试分析师对测试用例进行复核时有依据。
最后感谢每一个认真阅读我文章的人，看着粉丝一路的上涨和关注，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走
