Iddc-tax-manage-plan

来自ling
跳转至: 导航搜索

目录

设计

  • 王波 项目启动前,技术负责人需按架构模板提供相关文档供评审

代码质量

参考Ling-cloud#编码规范

应用环境

  • 当前包含的环境如下:开发环境,测试环境,UAT环境,PRE环境,生产环境,其主要用途如下:
    • 开发环境 供开发人员开发联调,有自动发布,由开发人员发布
    • 测试环境 供测试人员测试,有自动发布,由测试人员发布
    • UAT环境 供用户测试 有自动发布,由Eric发布
    • PRE环境 发布生产前的验证和生产问题重现,其数据来源于脱敏的生产环境数据 无自动发布,由Eric发布
    • 生产环境 生产环境 无自动发布,由Eric发布

代码发布顺序为 开发环境-->测试环境-->UAT环境-->PRE环境-->生产环境

版本管理

版本管理与PRE发布流程

  1. 开发人员在DEV分支进行开发,在dev环境进行测试.可以通过jenkins自动发布开发环境.
  2. 开发人员开发完成,并在dev环境完成测试后,通知测试人员在jenkins自动发布测试环境相关模块,并完成测试.
  3. 测试人员测试工作在测试环境进行
  4. UAT环境会每隔2天发布一次.或按需发布,发布频率不得过于频繁.
  5. UAT环境需要发布当天15点前BA提供平台和ptc需要更新到uat环境的修改列表.
  6. 项目技术负责人将代码合并到UAT分支.如果有datachange,还需提供datachange
  7. 项目技术负责人通知Eric发布UAT环境
  8. Eric通知测试在UAT环境测试.
  9. 测试人员需要根据修改列表在UAT回归测试相关受影响的模块和流程.
  10. UAT测试通过后,如需更新PRE环境,测试人员通知Eric将UAT应用和datachange更新到PRE环境.
  11. 如需在pre环境进行验证,请联系Eric支持

更多参加Tax_gitlab管理


  • 分支位置
https://cnbejtaxapp03.atrapa.deloitte.com/svn/源代码管理/DrTaxPlatform/branches/DEV
https://cnbejtaxapp03.atrapa.deloitte.com/svn/源代码管理/DrTaxPlatform/branches/UAT
https://cnbejtaxapp03.atrapa.deloitte.com/svn/源代码管理/DrTaxPlatform/branches/PRE


  1. UAT和PRE环境会每隔2天发布一次.
  2. 测试工作在test环境进行
  3. 发布当天15点前Ailsa,Amanda提供平台和ptc需要更新到uat环境的修改列表.
  4. 代码负责人将合并所需的patch文件邮件给王波.
  5. 王波在代码合并完成后通知Eric将最新代码和datachange发布到UAT环境.
  6. Eric通知Lily,Deyi在UAT环境测试.
  7. Lily,Cino需要根据修改列表再UAT回归测试相关受影响的模块和流程.
  8. UAT测试通过后通知Eric将UAT应用和datachange更新到PRE环境.
  9. 如需在pre环境进行验证,请联系Eric支持

上线时间	变更事项	代码负责人	测试负责人	状态	描述

正式环境发布流程

  1. 正式环境每个开发周期发布一次.开发周期视情况有项目负责人决定,一般不能小于一个礼拜
  2. 正式环境发布前必须要UAT和PRE环境验证通过
  3. 如果没有特殊要求,正式环境发布要在7点下班后发布

正式环境紧急发布流程

正式环境紧急发布流程,此流程适用于正式环境出现阻断性bug,需要立即修改并发布

  1. Ailsa,Amanda,Don提交需要紧急发布到pre环境的问题清单
  2. 后续流程参考正常发布流程6-11

  1. 后续流程参考正常发布流程4-9

版本管理规范

权限申请

联系Eric并邮件申请相关权限

  • tax-auth
  • tax-basic
  • tax-common
  • tax-common-dependencies
  • tax-common-parent
  • tax-config
  • tax-cor
  • tax-core
  • tax-doc
  • tax-eureka
  • tax-extra
  • tax-frontend
  • tax-gateway
  • tax-job
  • tax-monitor
  • tax-ocr
  • tax-ptc
  • tax-ptc-offlinePages
  • tax-tp

源代码分支说明

  • 源代码的主要分支和各个环境基本保持一致
    • DEV分支 对应开发环境和测试环境 开发人员拥有读写权限
    • UAT 对应uat环境 项目技术负责人拥有读写权限
    • PRE 对应pre环境 项目技术负责人拥有读写权限
    • TAG_VERSONx.x.x_yyyyMMdd 对应生产环境例如TAG_version1.0.0_20190531
    • BRANCH_VERSONx.x.x_yyyyMMdd_HOTFIX 如果生产环境发现问题,需要立即修复并发布,需要从生产tag创建hotfix分支,例如BRANCH_version1.0.0_20190531_HOTFIX


  1. 当前最新的前后端代码都合并到trunk,前端rebuild分支和trunk权限已收回.
  2. 从trunk创建新的普通开发分支branch_version1.1_20190607和预生产分支branch_version1.0_20190531_pre
  3. branch_version1.1_20190607分支对应dev和test环境
  4. branch_version1.0_20190531_pre对应uat和pre预生产环境,所有需要在2019-05-31上线的代码都会合并到此分支
  5. 请大家在branch_version1.1_20190607分支上完成当前开发工作.
  6. 需要在2019-05-31上线的内容请在dev和test环境完成验证后将要合并的代码邮件给王波,由王波完成到branch_version1.0_20190531_pre分支的合并工作.
  7. 需要在2019-05-31上线的内容由测试人员在uat环境完成测试(如果改动较小,简单测试即可)后再发布到pre预生产环境
  8. 非本次上线内容,Cor和tp可以继续在trunk完成开发,如发现没有权限,请联系Eric调整.

代码评审制度

  • 评审时间
  • 参与人员
  • 会议纪要
  • 评审评价

请假和加班填报

如果需要在timesheet中填报加班和ot,需要得到项目组负责人的确认

上线

  • 上线部署方案
  • application security and configuation assessent form
  • 技术运维和业务运维说明书
  • 安全扫描报告
  • 用户使用手册
  • 灾备申请
  • 灾备还原演练

测试人员管理初版

  • 刘畑提供测试模板文档 功能测试模板,性能测试,安全测试 测试计划模板,测试用例模板

测试流程/制度的建立与完善

有效的测试流程与制度会在工作中提高测试效率与产品质量。

人员的规划

首先需要掌握团队各成员的能力,再根据人员规模与项目的复杂程度进行项目成员调整,比如单个项目串行或者多个项目并行时对人员的规划,可模块分组或者测试类型分组,以平台为例,模块分组可分基础数据模块,项目管理模块,客户信息模块等 测试类型分组,业务测试(UI层功能测试)与非业务测试(接口/自动化/性能等,根据具体的项目设定测试范围与方案)。

测试资源安排

包括人力资源和软硬件资源,除了要求对项目需求和成员能力特别熟悉,还要根据项目的重要性与轻重缓急合理的安排资源,用人之长,避人之短,合理分工。

测试过程的管理

及时跟进各成员的工作完成情况,若遇到问题及时解决, 如遇到计划变更及时调整,项目信息与项目组其他团队成员消息保持同步,减少无效沟通等等。

知识的沉淀

测试流程文档化,如测试计划,测试方案,测试用例,测试总结等。

KPI的考核

人才梯队的建设

组织架构(包含virtual的架构组)/RACI定义

Draft组织结构(Scrum、支撑组、virtual架构组) Linda/Neil

组织结构Review与宣布实施 Linda/Neil

Draft RACI定义 Zhou

RACI定义Review与宣布实施 All

Scrum

Scrum training Neil Done

Scrum checklist Neil

确定Scrum实施的批次 All

按组正式实施Scrum All

需求管理/变更/版本管理/优先级管理

与产品经理讨论需求管理/变更管理/版本管理的规范 Linda/Neil

与重庆TPO/主要leader review规范 Linda/Neil

重大架构和需求变更处理方式 Neil

宣布并实施规范 All

架构标准和Review制度

架构标准/技术栈标准 Jason

  • 系统模块的划分
主要是对系统整体的梳理,将问题大而化小。同时保证系统的单一职责,减少耦合。
模块划分是指在软件设计过程中,为了能够对系统开发流程进行管理,保证系统的稳定性以及后期的可维护性,从而对软件开发按照一定的准则进行模块的划分。根据模块来进行系统开发,可提高系统的开发进度,明确系统的需求,保证系统的稳定性。
  • 涉及到的外部系统及交互方式
主要是列出当前系统需要交互的系统和交互的方式。判断交互方式是否高效合理。判断系统调用是否正向,是否循环调用等。
  • 各个模块的部署方案
根据各个模块的特点,性能,压力等因素,来选择单机部署或者多机部署等,拟定最后的一个部署方案。
  • 重要模块的技术选型
针对模块中的技术问题,在解决时,需要对多个技术方案进行调研和选择。需要记录选择的技术方案和原因。
  • 重要逻辑中的问题的考虑
比如数据一致性,比如耗时操作的处理等问题的一个考虑和应对措施。
  • 模块中的重要设计和性能考量
比如数据库设计,流程设计等对程序性能的影响。提出衡量程序的性能的标准和指标
  • 系统的拓展性
系统拓展性展示

架构文档模板 Jason

文件:概要设计模板.docx

架构Review制度 Jason

  • 评审时间和评审标准
项目开始前架构评审,由王波组织和发起
架构评审后代码完成度为50%,80%和上线后,由项目scrum master发起和组织评审,评审时间和规律同代码review会议
主要核心业务需要变更
架构评审没包含的复杂程度高的新业务内容.
认为需要从架构角度提炼为基础服务的功能
大的表结构变化
  • 参与人员
王波,曾周,宴川,张权,陈耀平,和每个team的scrum master
  • 评审评价
  1. 设计方案内容是否完整
  2. 主要业务所涉及的核心技术
  3. 表结构设计是否合理,主要业务逻辑是否有流程图设计
  4. 包括前端,后端代码
  5. 参与评审人员,必须积极主动提出意见
  • 会议纪要
傅小康

Review与宣布实施 All

测试规范和Bug定义

测试总览 Tian

Bug严重级定义 Tian

测试用例guideline Tian

测试报告模板 Tian

Bug流程 Tian

性能测试规范 Tian

安全测试规范 Tian

Review与宣布实施 All

SDLC (软件开发生命周期管理)/I2A playbook/project mgmt.

新产品/模块总体流程 Zhou

Review与宣布实施 All

汇报制度

定义周报汇报内容(报告,会议流程) Zhou

Review与宣布实施 All

团队建设

制定技术培训规划 Jason

  • 每月第二周一次新技术研究和分享,由团队中有兴趣和有经验的研究和分享
  • 通过代码评审,提高团队成员代码质量
  • 从应届生中培养新鲜血液,见应届生中培养计划

兴趣小组建立 & 分享机制 Jason

  • 通过微信群 分享好的技术文章

个人发展规划和跟踪 Neil

Review与宣布实施 All

代码标准和review制度

整合现有代码规范并优化(前端) Jason

文件:阿里巴巴Java开发规范1.4.pdf

前端编码规范-李远.docx

代码框架说明(前端) Jason

文件:微前端计划书-李远.docx

整合现有代码规范并优化(后端) Jason

文件:阿里巴巴Java开发规范1.4.pdf

代码框架说明(后端) Jason

文件:平台系统上线部署方案.docx

整合现有代码规范并优化(数据库设计) Jason

文件:数据库设计规范 v1.0.docx

整合现有代码规范并优化(高性能SQL) Jason

文件:SQL 语句书写与性能调优规范.doc

代码Review制度 Jason

  • 评审时间和评审标准
代码完成度为50%,80%和上线后,由项目scrum master发起和组织评审
  • 评审内容
sonar中问题是否处理
架构中表结构与当前表结构变化
架构中所用技术和当前所有技术变化
主要流程代码,编码规范和实现
  • 参与人员
王波,曾周,宴川,张权,陈耀平,和每个team的scrum master
  • 评审评价
  1. 包含表结构设计是否合理,主要业务逻辑是否review完整,代码质量如何,代码讲解主要谁开发的谁讲
  2. 包括前端,后端代码
  3. 参与评审人员,必须积极主动提出意见
  • 会议纪要
傅小康

单元测试规范 Jason

  • 以后会去掉掉接口测试,接口测试转由单元测试为基础的测试
  • 主要业务需要以测试团队提供的测试案例完成测试套件的编写
  • 单元测试原则以阿里java单元测试准则为主,参考如下


  • 1. 【强制】好的单元测试必须遵守AIR原则。
说明:单元测试在线上运行时,感觉像空气(AIR)一样并不存在,但在测试质量的保障上,却是非常关键的。好的单元测试宏观上来说,具有自动化、独立性、可重复执行的特点。
 A:Automatic AutomaticAutomatic Automatic Automatic (自动化)
单元测试应该是全自动执行的,并且非交互式的。测试用例通常是被定期执行的,执行过程必须完全自动化才有意义。输出结果需要人工检查的测试不是一个好的单元测试。单元测试中不准使用System.out来进行人肉验证,必须使用assert来验证。
 I:Independent IndependentIndependent Independent Independent Independent (独立性)
保持单元测试的独立性。为了保证单元测试稳定可靠且便于维护,单元测试用例之间决不能互相调用,也不能依赖执行的先后次序。 反例:method2需要依赖method1的执行,将执行结果作为method2的输入。
 R:Repeatable RepeatableRepeatable Repeatable Repeatable Repeatable(可重复)
单元测试是可以重复执行的,不能受到外界环境的影响。 说明:单元测试通常会被放到持续集成中,每次有代码check in时单元测试都会被执行。如果单测对外部环境(网络、服务、中间件等)有依赖,容易导致持续集成机制的不可用。 正例:为了不受外界环境影响,要求设计代码时就把SUT的依赖改成注入,在测试时用spring 这样的DI框架注入一个本地(内存)实现或者Mock实现。
  • 2,【强制】对于单元测试,要保证测试粒度足够小,有助于精确定位问题。单测粒度至多是类级别,一般是方法级别。
说明:只有测试粒度小才能在出错时尽快定位到出错位置。单测不负责检查跨类或者跨系统的交互逻辑,那是集成测试的领域。
  • 3. 【强制】核心业务、核心应用、核心模块的增量代码确保单元测试通过。 说明:新增代码及时补充单元测试,如果新增代码影响了原有单元测试,请及时修正。
  • 4. 【强制】单元测试代码必须写在如下工程目录:src/java/test,不允许写在业务代码目录下。
说明:源码构建时会跳过此目录,而单元测试框架默认是扫描此目录。
  • 5.【推荐】单元测试的基本目标:语句覆盖率达到70%;核心模块的语句覆盖率和分支覆盖率都要达到100%
说明:在工程规约的应用分层中提到的DAO层,Manager层,可重用度高的Service,都应该进行单元测试。
  • 6.【推荐】编写单元测试代码遵守BCDE原则,以保证被测试模块的交付质量。
 B:Border,边界值测试,包括循环、 特殊取,边界值测试包括循环、 特殊取特殊时间点、数据顺序等。
 C:Correct,正确的输入,并得到预期结果。 ,正确的输入并得到预期结果。
 D:Design,与设计文档相结合,来编写单元测试。 ,与设计文档相结合来编写单元测试。
 E:Error,强制错误信息输入(如:非法数据、异常流程业务允许等),并得 ,强制错误信息输入(如:非法数据、异常流程业务允许等),并得到预期结果。
  • 7.【推荐】对于数据库相关的查询,更新,删除等操作,不能假设数据库里的数据是存在的,或者直接操作数据库把数据插入进去,请使用程序插入或者导入数据的方式来准备数据。
反例:删除某一行数据的单元测试,在数据库中,先直接手动增加一行作为删除目标,但是这一行新增数据并不符合业务插入规则,导致测试结果异常。
  • 8. 【推荐】和数据库相关的单元测试,可以设定自动回滚机制,不给数据库造成脏数据。或者对单元测试产生的数据有明确的前后缀标识。
正例:在RDC内部单元测试中,使用RDC_UNIT_TEST_的前缀标识数据。
  • 9.【推荐】对于不可测的代码建议做必要的重构,使代码变得可测,避免为了达到测试要求而书写不规范测试代码。
  • 10.【推荐】在设计评审阶段,开发人员需要和测试人员一起确定单元测试范围,单元测试最好覆盖所有测试用例(UC)
  • 11.【推荐】单元测试作为一种质量保障手段,不建议项目发布后补充单元测试用例,建议在项目提测前完成单元测试。
  • 12. 【参考】为了更方便地进行单元测试,业务代码应避免以下情况:
 构造方法中做的事情过多。
 存在过多的全局 变量 和静态方法。
 存在过多的外部依赖。
说明: 多层条件语句建议使用卫语句、策略模式、状态模式重构
  • 13.【参考】不要对单元测试存在如下误解:
 那是测试同学干的事情。本文开发 手册 ,凡是本文内容都与开发同学强相关的。
 单元测试代码是多余的。 汽车的整体功能 与各单元部件的测试正常否是强相关。
 单元测试代码不需要维护。 一年半载后,那么几乎处于废弃状态
 单元测试与线上故障没有辩证关系。好的单元测试能最大限度规避线上故障。

代码规范与review制度宣讲 Jason

静态代码检查 Jason

  • 标准
以sonar中已经整理的规则为主
  • 工具
sonar
  • 频率
dev每次发布时自动扫描代码
  • 问题处理
UAT前相关问题必须解决,由scrum master负责
上线前检查问题是否解决,由王波,曾周负责

运维(包含DBA)

运维流程 Eric

产品上线发布规范 Eric

环境规划(包括服务器权限控制) Eric

服务器设置规范 Eric

运维自动化 Eric

数据库维护规范 Eric

服务器资源申请规范 Eric

Review与宣布实施 Eric

Support体系

资产支持流程和规范

SLA

Review与宣布实施

git代码管理规范

日志

对日志规范的思考

审计日志

  • 统一在controller的方法上加上@SysLog,便于分析那些业务接口的使用量和耗时等信息
  • 从业务角度收集,那些日志需要输出

基本审计日志

登录,登出

审计日志内容

日志类型,日志标题,请求uri,操作人,操作时间,操作ip地址,操作方式,提交数据,方法执行时间,异常信息,应用标识

日志格式规范

由...biz\src\main\resources\logback-spring.xml中约束

接口日志

  • 接口名称,接收数据量,耗时
  • 更新,修改,删除目标数据库的数据量
  • 输入的每条数据用json格式打印在日志中
  • 每条数据都要进行关键字段是否存在和是否非法的验证,如果不符合要求,不管是否需要中断后续数据的处理,都需要记录到日志中

日志规范

  • 应用中不可直接使用日志系统(Log4j、Logback)中的 API,而应依赖使用@SysLog 有利于维护和各个类的日志处理方式统一。
  • 使用@Slf4j注解来注入log变量
  • 每个项目中由...biz\src\main\resources\logback-spring.xml
  • 使用GlobalExceptionHandlerResolver捕获全局异常,并统一输出异常
  • 使用RequestAspect输出前端controller层方法的拦截内容,应该输出那些内容
  • 打印sql语句,传参是否打印?
  • 打印主流程的过程及其链路追踪

日志清理

审计日志清理

应用日志清理