这是《落叶》文集里第 341 片落叶，希望你能喜欢，不为别的，只为这份坚持。
第二十章 为什么要从梳理测试点开始做测试设计？
需求评审基本接近尾声了，开发开始写代码去了，我们也进入了测试设计阶段。在早上的晨会上，我要求大家不要着急直接去写测试用例，而是先梳理一下各自需求的测试点。有些人不明白，就问我，一般不都是按照测试用例去执行吗？测试点又是什么？
我说，测试点其实就是功能点对应的测试项，比如我们要测试 APP 的订单列表，那订单列表就是 APP 的一个功能点，而对于这个功能点，列表的 UI 布局、订单数据的完整性、列表超过12条之后的自动分页、空数据页面以及列表数据展示速度，这些测试项就是测试点。
我们如果要再进一步细化测试点，就是在设计测试用例了。之所以我们要先从测试点开始梳理起，我先说下为什么吧：
- 测试点比功能点会更精细一些，可以根据测试点得出更为精准的测试工作量估算；
- 在功能点的优先级已经确定的前提下，我们可以再对测试点做一个优先级的分析，当项目出现风险的时候，比如测试时间被压缩的时候，就可以舍弃一些低优先级的测试点，优先完成重要的测试点；
- 先将测试点梳理出来，然后再根据实际需要，针对部分测试点设计测试用例，一方面能节省部分人力，另一方面也可以提高测试设计的效率，而不会盲目地一上来就设计测试用例，最后执行时发现，有些测试用例都是为了设计而设计，没有任何价值；
- 我们目前因为也没有引入比较好的 Case 管理系统，所以从执行进度跟踪管理的角度来看，测试点的颗粒度正正好；
这几个就是我要求你们先梳理测试点的理由，接下来，我们再看一下整体的测试思路，你们就能理解和接受了。
功能性需求的测试思路：
根据公司的质量要求，确认测试目标；
阅读需求文档，确定测试范围、测试难点和测试重点；
根据功能点，梳理测试点，并制定优先级；
制定测试策略，根据风险和项目事业环境因素，分析可用的时间和人力；
基于测试点，采用合适的方法完成测试用例的设计和开发；
基于测试点，采用合适的工具完成自动化脚本的设计和开发；
执行测试用例，并提交缺陷；
执行自动化脚本，并分析执行结果；
根据缺陷的分布和测试覆盖率的分析，及时调整测试策略和测试执行；
UI 测试：
顾名思义，就是检查每个页面的实现是否跟设计图一致，包括布局、图片、背景色、文字字体、颜色、字号、文案是否有错误、是否有显示问题，还包括在不同尺寸、分辨率屏幕的手机上的适配性；
- 交互测试：
交互指的其实就是检查用户使用中的界面交互，页面跳转是否跟产品交互设计原型一致，比如，点击某个按钮，应该跳转到某个页面，再点击返回按钮，应该返回到哪个页面。某个订单流程从发单开始到订单完成，用户跟商户在整个过程中的交互是否简单、易用、流畅等等。从我狭义上的理解，在交互测试里，有一部分是在做用户体验测试；
- 业务逻辑测试：
这个是最好理解的，就是按照需求文档或功能规格说明书去验证每个功能模块的逻辑和流程是否符合设计要求。包括正向的流程逻辑验证，也包括逆向的或异常的验证，比如登录接口传参把密码置为空，看服务端是否也有不能为空的保护，因为测试的目的并不是证明软件是可用的，而是想尽办法证明它是不可用的；
- 数据验证：
其实也可以算在业务逻辑测试的范畴里，我习惯把它抽取出来，主要是因为很多情况下，我们需要对业务产生的数据做完整性、逻辑性、合理性、兼容性的测试；
再以登录为例实际看下它的不同维度下的测试点：
- UI 测试：
登录界面的标题、输入框、按钮布局，输入错误用户名或密码时的提示信息，输入框里的默认提示语等都属于这个维度的测试；
- 交互测试：
登录成功应该跳转到哪个页面，登录失败会有哪几种提示指引，登录成功后点击返回应该跳转到哪，选中电话号码输入框，是否会自动切换到数字键盘等等都属于交互测试；
- 业务逻辑测试：
输入正确的用户名和密码会怎么样，输入正确的用户名和错误的密码会怎么样，输入不合法的手机号会怎么样，连续输入错误地密码会怎么样，这些都属于业务逻辑测试范畴；
- 数据测试：
登录模块的数据测试简单来说就在于新用户注册后，数据库里保存的密码是明文还是密文的，检查所有显示用户手机号的页面，看是否按需求要求加密中间四位数等等；
如果你们没有其它意见，我们就先从测试点梳理开始吧，给大家两天的时间，等大家测试点都梳理好了，我们就开始设计测试用例。
《告诉你如何从执行测试到管理测试》带你迈出第（20）步！，点击这里可查看完整地图
作者简介：14 年测试 + 11 年项目管理 + 11 年团队管理 = 一个测试老兵
