和需求评审一样，开发设计方案也是需要进行评审的，只是目前还没有机会去做出相关的系统检查表，就要离开这个项目了。

先把现阶段我有的一些心得沉淀一下。目前我主要的开发设计方案评审基本是基于自我设计猜想而来的。

1、和开发打交道--体现自身专业与价值

想要对开发的设计进行评审，少不免要和开发GG聊天。有些开发团队会非常的乐于和你分享自己的设计思路，但是有些比较传统的开发团队会认为测试只要做好自己的执行就可以了，不需要来了解设计也无法理解设计。

那么这种情况下，测试就需要让自己的上游知道QA存在与介入这个阶段的价值。举个栗子，最初接触开发设计是基于最基本的好奇心。于是就主动去询问开发关于功能的实现，好在开发比较乐于分享，对功能模块设计进行了介绍，出于测试的敏感，我提出了几个设计上的质疑，例如你这样设计，可能可以被别人截获包，对数据进行更改，就可以对这个功能进行操作了。开发评估确实存在这个问题就赶紧进行了调整。这样就避免了一个BUG提高了自己的质量，于是在下次功能开发的时候开发在设计接口定义的时候不仅拉上了前端还叫上了QA

2、如何进行设计猜想

凭空说自己去猜想设计这个是比较抽象的，所以我总结了一些方法和思路去执行。

有些同学会反馈无从下手，那么我建议可以从一些核心流程开始。

猜想切入点==抓住核心功能流程，从功能层面落地想象。

举个例子。打开你测试的软件，选取某个功能，比如购买某个物品的功能，

1、首先你会点击来到商品列表界面（这个过程客户端请求后端获取商品列表）

2、接着你会点击的某个商品进入商品详情（这个过程客户端请求后端获取商品详情）

3、选择商品属性后生成订单（客户端提交订单请求，服务端进行订单生成）

4、用户进行支付操作   （客户端向支付宝sdk发起支付请求，支付宝方返回订单支付信息给业务方，再反馈前端展现）

那么以上就是整个功能的设计猜想，相应的我们可以画出对应的时序图，请忽略我拙劣的画技，由于是随意举例并且是猜想所以很有可能存在错误

猜想技能养成==善于使用接口wiki或者抓包工具

对于一些经验不足的同学来说，需要直接看功能表现或者策划案去猜想设计会存在一定的难度。

那么有个折中的技能养成方案，我们可以通过抓包或者查看接口wiki知道客户端在什么时候会发起什么内容的请求，同样开始梳理出业务时序图。

但是这样更多是依托于现有的实现，而没有独立的想法，容易被开发GG带着跑。

猜想技能养成==通过切割黑盒子，理清模块之间协作流程来梳理业务脉络或者想象业务脉络

以上两个模块基本上都是说明了这个思想，一开始对于我们来说整个功能模块就是黑盒子一个。那么我们最简单的入手方法，就是

1、采用手段对这个黑盒子切上一刀，比如通过抓包或者接口定义我们可以知道前后端是怎么协作的，于是可以梳理出前后端的交互脉络。

2、然后我再对前端进行切割一刀，将前端切分为本公司开发部分与支付宝部分。于是我们可以通过接口或者支付宝sdk接入wiki等手段理清客户端这个模块的业务脉络

3、也许远远不止以上的两个层次，比如前端商城与背包的交互，后端数据库交互等等，我们都可以进行切割。

3、设计猜想的价值

    沟通

当我们有了基本设计方案猜想以后，我们和开发的沟通会变的顺畅许多，去找开发了解具体实现逻辑的时候可以先说我是这样猜想的，开发来纠正，或者能够更加清晰自己需要了解的重点是什么。

    对比

拿出的你方案和开发的方案进行对比，和开发沟通的时候不妨多问一句为什么要这么设计。

例如现在要实现一个简单的列表功能

我的设计方案是

1、根据时间戳进行列表分页功能实现

开发的设计方案是：

1、根据记录个数进行分页功能实现  从第一个开始取 一页取50个

经过对比两个方案的优劣，发现开发的方案存在一个问题，当我已经获取第一个分页的时候，有新的记录插入，这个时候原来的第五十条记录会变成第51条，于是我再去加载第二分页的时候会出现原来取的50条和现在取的51条记录是同一条。用户表现为出现2条一样的记录。

    迭代

我有一个思想、你有一个思想，我们交换一下，我们各自都有2个思想。

我有一个方案，你有一个方案。我们PK一下，我们都有了2个方案以及这2个方案的优劣。