测试提前-技术方案评审

发表于:2014-06-13来源:淘测试作者:玉浓点击数: 标签:软件测试
测试提前进行的越深入,越体会到了解系统架构的重要性,参与到技术方案评审,不仅是听,还要评,进一步学会审。这个阶段可以更关注可测性、性能考虑、可拓展性等 举几

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

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

  性能考虑

  关注方向:系统调用、单个\批量,串行\并行,读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所有异常并包装一个统一的返回值给业务系统,这种设计方式下,除非系统挂了服务找不到了才可能对业务系统产生影响

 

原文转自:http://www.taobaotest.com/blogs/2532