• 精确测试


    # 定义

    直接引用百度的 :

    精准测试是一套计算机测试辅助分析系统。精准测试的核心组件包含的软件测试示波器、用例和代码的双向追溯、智能回归测试用例选取、覆盖率分析、缺陷定位、测试用例聚类分析、测试用例自动生成系统,这些功能完整的构成了精准测试技术体系

    # 背景

    集团的同学分享了关于精准测试的文章,看了下简单记录一下

    # 正文

    (以下都是个人理解,如果有不对欢迎留言讨论)

    1. 做测试的朋友都可能碰到过:漏测/少测,根本原因是不知道研发改动了什么/影响到什么 or 是知道了改动了什么但因为一些需求历史不清楚,导致不知道影响到了什么;

    1. 精准的对立就是模糊,精准测试说白了就是当研发提交一个新版本过来的时候,你知道它改动了什么,影响到哪些接口/方法,然后针对改动点去测试。是从测试的角度去看待问题,提高测试的效率,毕竟之前是要求全量回归的,现在只需要测试部分;

    2. 精准测试 跟 回归测试有没有悖论呢 ?回归测试,验证新功能会不会对其他原有功能造成影响;而精准测试貌似说是可以发现这些影响面? 了解了精准测试的大致原理,我只能说很难发现,why?

    3. 精准测试的大致思路:研发改动了什么 --> 影响面评估 -->  筛选用例 --> 用例执行 ;

    # 没有精确测试

    1. 提测 -- 研发提交代码,告知改动点,可能的影响面,自测点,测试重点(这里需要靠谱的研发!!)

    2. 用例编写 -- 针对这次需求/改动点编写用例,用业务经验/技术经验来评估影响面来新增用例;

    3. 用例review -- 用例发给组内同学一起讨论下,从别人的角度看待问题;

    4. 用例执行 ;

    总结: 其实用业务经验、技术经验、用例组内review就是一种精确测试,只是人工的形式罢了

    # 有了精确测试

    1. 提测 -- 通过git工具获取本次提交的变更记录,获取改动的情况,可具体到哪个文件;

    2. diff --  通过diff工具,git也有diff功能,class文件的diff,目的就是找出方法级别的改动;

    3. 分析调用链路 -- 通过分析源码,找到入口,也就是top方法,java的service层,controller层

    4. 筛选用例 --  根据链路上的影响分析需要回归哪些用例;

    总结:整体大致流程就是:代码push --> 触发精准测试任务 --> 通过git工具获取改动详情(文件,方法,入口)--> 在用例库中筛选用例自动化执行 --> 报告输出(用例+覆盖率)

    # 精确测试好处

    1. 评估影响面,对长链路测试有帮助,A-B-C-D,修改了C,能评估中ABD中方法级别的影响;

    2. 提高测试效率,避免了不必要的用例执行;

    # 精确测试的疑问

    1. 如果同一个工程中的链路,用精确测试确实可以精确的发现影响面,提供测试效率,但是多系统之间呢 ?如购物车系统 + 订单系统,两个不同的团队之间的链路,只能评估到比较粗的粒度;

    2. 数据依赖的,无法解决;A系统的代码变更导致写入DB中的数据变化了,B系统知识根据数据来走业务流程,那么A跟B的联系 就断开了,目前看到的文章只能在代码级别做关联;

    # 可借鉴的

    1. 思路:从代码追溯到接口级别的改动来筛选用例,可以帮忙评估影响面,结合CI流程,是不是每次代码push可以有个大致的影响面评估图呢?

  • 相关阅读:
    练习 : Flink 自定义Process_State 使用 OnTimer 连续3s大于70度 传感器报警
    练习 : 用 utils 读 存 kafak,flink sql 查询
    9. 查询user_info表中info:age大于等于18的记录
    练习: Flink Sink 将数据 保存 到 HDFS MySQL
    HBase Java API to Uitl
    练习:Flink 自定义 process 和 source
    ClickHouse 安装
    练习 : Flink TimeWindow 滑动 滚动 窗口 增量 全量 统计
    练习 : Flink 水位线 Flink_Watermark_Test
    Flink pom.xml
  • 原文地址:https://www.cnblogs.com/jwentest/p/9873110.html
Copyright © 2020-2023  润新知