测试提前—技术方案评审-阿里云开发者社区

开发者社区> 开发与运维> 正文
登录阅读全文

测试提前—技术方案评审

简介:
测试提前进行的越深入,越体会到了解系统架构的重要性,参与到技术方案评审,不仅是听,还要评,进一步学会审。这个阶段可以更关注可测性、性能考虑、可拓展性等
  举几个技术方案阶段关注并改进的例子.
  性能考虑
  关注方向:系统调用、单个\批量,串行\并行,读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/

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
开发与运维
使用钉钉扫一扫加入圈子
+ 订阅

集结各类场景实战经验,助你开发运维畅行无忧

其他文章