测试提前进行的越深入，越体会到了解系统架构的重要性，参与到技术方案评审，不仅是听，还要评，进一步学会审。这个阶段可以更关注可测性、性能考虑、可拓展性等

　　举几个技术方案阶段关注并改进的例子.

　　性能考虑

　　关注方向：系统调用、单个\批量，串行\并行，读tair\读db

　　例子：

　　qc系统资质验证的过程是，业务系统发起验证一颗资质树（多个资质）的请求，资质系统获取请求后，从多个业务方系统获取数据并和要求值进行对比，将对比验证结果返回到业务系统

　　以下是技术方案时对老系统的改进.

　　1. 单条验证 -> 提供批量验证接口，避免多次HSF调用

　　2. 单颗资质树资质获取 -> 资质数据读取方式从原有的懒加载改为预加载。合并多个资质树的资质，一次读取

　　3. 串行读取 -> 并行数据读取。资质数据涉及多个系统，将多个HSF调用从串行改为并行

　　4. 串行验证 -> 并行验证。批量验证时采用并行的方式验证

　　5. 提供服务方式：HSF -> JAR，本地调用和hsf调用的性能差别

　　6. 缓存读取方式：只读取所需 -> 读取所有,减少二次读取时对DB的访问

　DB设计

　　关注方向：避免分库查询、分表查询、多表查询

　　例子：

　　服务评价项目的项目目标是对客服小二处理case的服务进行评价。record表（评价任务表，一个case对应买卖家共两条record记录即两个评价 问卷）、answer表（买卖家的答卷记录，一个问卷对应多条答案记录，recordId作为answer表外键），record为单表，answer分 表按recordId进行分表

　　问题点在answer表的分表是按照recordId进行取模分表。

　　这种方式下，查询一个case对应的评价记录：先根据caseId查询record表获得两个recordId，再根据recordId取模查询两个answer表的记录，再返回结果

　　改进方案是：在answer表增加一个caseId字段，根据caseId分表，这样查询答题记录只一个caseId查询一个answer表即获取买卖家答题记录。只查询一次和查询两次且有分表查询的对比，效率提升是显而易见的

　　hsf设计

　　关注方向：异常处理

　　例子：

　　服务评价系统对外提供一个重要hsf服务，业务系统case在完结时调用该hsf服务触发评价任务开启。下图是开发设计的调用流程， 主要关注红框中的调用方式。

　　业务case完结是业务主流程，开启评价是分支流程，分支流程应该是不能影响到主流程的，一个p1级应用***不要去依赖一个p3级应用。所以，评价系统的 hsf服务不能抛任何异常给业务系统，hsf服务需要catch所有异常并包装一个统一的返回值给业务系统，这种设计方式下，除非系统挂了服务找不到了才 可能对业务系统产生影响

最新内容请见作者的GitHub页：http://qaseven.github.io/