提高项目质量的长期计划

一、概述

质量和效率是提高项目质量的两个维度。
质量在易用性上,有一些优化被“老师”提出来,其他的基本还行。
效率上,由于自动化实施早,自动化部署也上了,测试只专注功能和接口的测试,测试是非常快的。甚至有很多时间去摸鱼,有更多的思考时间。

项目快一年了,目前情况:

  • 完整的项目流程,明确说明了项目每个阶段的具体产出;
  • 开发和测试产出的归档;(需求文档、组件依赖、部署方案及资源要求、提测文档、测试方案、测试文档、前后端镜像、接口用例与接口自动化用例)
  • 完成了接口自动化用例;(总接口覆盖100%、接口中参数的等价类覆盖100%、功能流程覆盖100%、其他的用例暂时没有)
  • 完成了自动化环境部署;(直接登录k8smaster机器,执行部署的。暂时就先这样,后续还是要优化成“直接创建jenkins任务的镜像,执行部署完成后,直接自动销毁”)

但是:

  • 对测试来说,虽然完成了接口自动化和自动化环境部署,但是,接口用例的覆盖率是多少,没有标准的专业的数据去说明。不能够专业的说出“项目接口自动化用例覆盖接口100%,代码覆盖xxx%”的情况,没有数据支撑。

  • 对开发来说,完成代码后的单元测试,单元测试覆盖率是多少,没有数据支撑。单元测试报告和报告的归档是空的,也不合适。

  • 上线发布的模式,灰度发布、回滚策略、数据库数据清理和更新策略。

  • 线上监控、线上数据回传测试环境,模拟线上数据测试、数据脱敏。

举例可能不恰当或者不适用,但是目标是对标互联网大厂的项目 。不是普通公司的普通项目。所以,这也是写提高测试质量长期计划的一个原因。

二、阶段一:提升代码覆盖率

覆盖率统计的使用级别:

  • 第一个级别 :只是去统计,统计得出一个数字;
  • 第二个级别 :看未覆盖的代码,从而丰富我的测试用例;
  • 第三个级别 :我的用例开始细化了,我清楚的知道每个用例对应的代码覆盖;然后可以利用这个关系进行反推,根据代码变更找到要测那些测试用例,测测试用例的时候,我可以知道哪些东西没有测试完全。
  • 第四个级别 :对流程进行建模,你现在看到的只是代码是否覆盖,在它之前,走的代码流程是什么样子的?我们要把这个控制流以链路的形式分析出来,类似于分布式的一个链路追踪。比如“zipkin”这个工具,有这个东西,系统的运行就可以一目了然(能分析到函数级别),根据trace id能做到,哪个人,操作了什么,他测试过程的覆盖率是多少,类似这样的结果。当然,执行的自动化用例+单元测试用例,在整体覆盖率占比多少,也是一清二楚。

目前,利用覆盖率去完成第二、第三级别的要求,就达到阶段一的需求。第四级别,属于精准化测试,需要掌握的技术栈会很多,对测试人员能力要求也更高。目前行业中还没有开源的精准化测试的工具。只能通过jacoco等覆盖率统计的工具,自己去实现精准化测试平台。python语言就更少了,利用coverage模块,获取覆盖率统计数据。可以作为长久目的去一步步走。

2.1 要求

  1. 单元测试,补充单元测试用例,得到单元测试的代码覆盖率。
  2. 已有的接口测试用例,在执行后,代码的覆盖率是多少?功能的覆盖率是多少?有没有工具去展示覆盖率?然后用例去查漏补缺。

2.2 单元测试

单元测试,xx同学在xx做过单元测试,我感觉非常棒。
利用mock技术、unittest框架编写单元测试用例,最后利用python的coverage模块,完成项目单元测试覆盖率的统计。生成的html报告,也非常直观的展示了覆盖情况。

虽然,报告展示的只是语句覆盖率 的数据,但是在写的单元测试用例中,依旧看到有分支覆盖 的测试用例。也就达到了条件覆盖 的测试标准。条件覆盖它综合了“语句覆盖(行覆盖)”和“分支覆盖”。已经达到了单元测试的目的,测试最小单元。

白盒测试 的执行手段涵盖单元测试、集成测试。一般用代码覆盖率作为白盒测试的主要度量指标

覆盖率常见概念如下:

  • 语句覆盖:每行代码都要覆盖至少一次(最基础,不能保证完整度)
  • 判定覆盖:判定表达式的真假至少覆盖一次
  • 判定/条件覆盖:判定覆盖与条件覆盖都必须覆盖
  • 条件组合覆盖:判定表达式中的所有条件组合都需要覆盖
  • 分支覆盖:控制流中的每条边都要被覆盖一次
  • 路径覆盖:所有的路径都要尽量覆盖
  • 指令覆盖:一行代码会被编译为多条指令,尽可能的覆盖所有指令
  • 方法覆盖:每个方法至少要被覆盖一次
  • 类覆盖:每个类至少被覆盖一次

总结:

  • 单元测试,能达到90%语句覆盖、100%分支覆盖的要求,单元测试就很不错。但是并不做强制指标。
    开发同学需要花时间去写单元测试用例,增量代码优先。然后完成单元测试的测试覆盖率的报告。作为数据,也进行单元测试的归档。(测试写单元测试也不是不行,能力是一个原因,还有就是代码熟悉的时间成本是另一个原因。这也就是单元测试通常都是开发同学自己去做的一个情况。)《Google软件测试之道》中:“you build it ,you break it ,you fix it”,解铃还须系铃人,开发对自己写的代码负责,比专职的测试更适合做测试工作。

2.3 接口测试

接口测试包括了集成测试和功能测试,甚至性能、安全等都可以在接口测试中做。所以,如何保证接口测试的覆盖率呢?(在这里我们先不考虑性能、安全等,只看集成和功能)
这个文章,我认为写的非常全面:如何保证接口测试的覆盖率? - 知乎
想要提高接口测试的覆盖率,首先要知道代码覆盖率低的原因,才能更好的采取措施来提高代码的覆盖率

大白话来说,影响点有这些:

  • 代码覆盖率:度量代码的覆盖度,一般通过行覆盖、分支覆盖进行度量。
  • 功能点覆盖率:根据被测业务的接口数进行统计,使用已调用接口数/总接口数度量.
  • 参数组合覆盖率:根据接口的可能参数组合度量。使用参数的测试范围/总的组合测试范围度量
  • 流程的覆盖,部分接口比如订单,并不是仅仅只调用一个接口,那么需要多接口调用的情况下就要考虑各种接口的不同情况

接口测试中,但是无论是自动化还是手动测试,都会执行程序,然后看代码运行,得到覆盖率的一个情况。利用运行的情况,看代码覆盖率,这样的场景需要去看下,搜索下。

总结:

  • 开发同学:提高和保持提供的接口文档的质量;
  • 开发同学:在做一个功能的时候,更清晰的将每一步表达出来,流程图方式。(这一点我们项目就特别好:+1:);
  • 测试同学:写的用例,无法实施的过程,找大佬帮忙;
  • 测试同学:测试人员加强学习,深入理解业务,用例或者测试方案写出时,项目组成员多注意、多发表意见。(我们项目贼棒:+1:
  • 开发和测试多沟通,毕竟都是为了共同的目标:“质量”。《Google软件测试之道》第一章就非常明确的说出了这样一句话:质量不等于测试,当你把开发过程和测试放到一起,就像在搅拌机里混合搅拌那样,直到不能区分彼此的时候,你就得到了质量。还有一句骚话:测试是开发过程中必不可少的一部分,当开发过程和测试一起携手联姻时,即是质量达成之时。

2.4 todo:给出接口测试的覆盖率

问题:

三、阶段二:精准化测试

xxx​:thinking:


折腾了这么多,也算有进步,只是不扎实。我觉得以你现在的水平,还是要先扎实的深入自动化测试吧。不要盲目追新追热。先从业务的覆盖着手吧,所覆盖的接口数量、参数组合覆盖占比等。

1 Like

嗯嗯,好的,已经找到对应的代码覆盖率方式了。主要还是虚。

思寒大佬,参数组合覆盖占比,是测试其中一个参数,其他参数正常情况下测试这个接口,我已经写完了。

关闭