zoukankan      html  css  js  c++  java
  • 测试之道,从哪里来,到哪里去?

    这里不谈哲学,也不是无的放矢,而是有感而生。这要回到两个月前,看到两篇文章:

    • 软件测试人,你们在逐渐失去一些东西
    • 测试十二年-六道轮回后的初心能否找回

    作者都是一线的资深软件研发人员,了解测试的过去,但更受目前测试现状的煎熬:

    • 面对这些被测对象,你们的质量理念是什么?

    • 不知道后来人会怎么评价这一段历史,从质量技术人的角度看,理论与应用不但停滞不前、还在不断后退“追求形,忽略神,小心技术革命的坑”

    • 测试用例,一个熟悉而又陌生的名词

    • 大部分人对于测试生涯、测试价值、测试发展、测试方向都有一种悲观的预感。

    • 我们都是不敢正视这些问题的,因为我们会被彻底打败

    • 有没有去思考测试本身的核心定位,测试本身的经验教训到底是什么?

    • 测试的目的和初心到底是什么?

    • 我们还能找回初心吗?

    • 还能静下心来思考我们真的是正确的做测试吗?

    • 真的只有这样的一条路吗?我们还能有其他的路吗?

    • ......

    才有了如文章标题那样的演讲。

    软件开发模式、技术和环境进步很快,但软件测试则感觉进步较慢、****比较被动,这其中的原因可能很多,软件测试的从业人员少,研究软件测试的人更少、在软件测试上的投入也比较低。

    1. 今天的软件测试如何呢?

    积极的一面:

    • 重视持续集成(CI)建设、关注DevOps

    • 非常关注自动化测试(TA)

    • 多数公司建成(TA)测试平台

    • 开始大量使用开源测试工具

    • 代码静态分析有较大提升

    • 大数据、云平台的测试初有成效

    • 软件测试社区活跃

    • …..

    负面(主要问题):

    • 公司的质量基建年久失修

    • 内建质量文化没有形成,缺陷预防做得较差

    • 热衷于招测试开发、重复造轮子,但TA成效低

    • 热衷技术,而缺乏对测试自身的思考

    • 面对软件开发新模式缺乏应对策略,如敏捷测试是形似而神不似

    • 介入研发深度不够,测试效率偏低

    • 许多困惑依旧困扰不少测试人员

    • ……

    大多数测试人员还有下列困惑:

    • 测试与开发有没有界限?

    • 谁来做测试更好?

    • 如何更好地开展测试活动?

    • 如何快速反馈质量?

    • 测试效果的度量?

    • 测试有没有发展前途?

    • ……

    再举一个例子,自动化测试是大家最为关心的、最愿意投入的部分,但成效很低。例如:国际上调查报告显示:

    根据国内今年的调查结果,显示国内TA状况更糟糕:

    如果在深入TA的投入产出(RoI),可能就更糟糕。在TA上投入很大,而收益很低,特别是在需求不稳定、变更频繁的情况下,收益更不明显。

    2. 重新找回测试的初心

       ——按时交付用户满意的产品
    

    (许多测试人员不了解 软件质量模型 ,这是很可怕的)

    如何找回初心?就是要多思考思考测试自身的问题——测试的质量(充分性)和测试的效率,从下列这些方法不断思考如何做好软件测试:

    • 如何做好软件测试的策划、分析、设计、执行、评估、管理?

    • 如何从被测对象——产品自身来提高其可测试性?

    • 如何在组织中营造良好的质量文化?

    • 如何制定有效的测试策略?

    • 如何运用好测试方法、技术、工具?

    • 如何建立稳定的、和开发环境集成的基础设施?

    • .....

    测试是不能穷尽的,不管采用什么技术和工具,测试总是有风险的,我们就要去思考如何降低测试风险,包括测试输入、操作和上下文(应用场景)、业务规则组合、环境的多样性、Test Oracle的启发性等:

    说起测试金字塔,十有八九会提到这个:

    这里实际是展示了自动化测试(投入)策略,但测试不只有一座金字塔,还有两座更为重要的金字塔:

    因为经常感受到不少测试人员忽视测试需求分析、缺乏测试分析和设计的思路,甚至本末倒置,一上来就讨论功能及其测试用例,忽视业务、忽视用户行为、应用场景的分析,而产品最终是需要满足业务需求、满足用户的需求,能适应不同的应用场景。测试设计的确重要,需要依赖所设计的测试用例(测试脚本)来执行测试,测试的覆盖率体现在测试用例的覆盖上,但没有测试分析作为基础,测试设计会忽视某些测试区域、测试风险等。如果按照右边金字塔这样的分析设计之路去探索、逐步细化、逐步扩展,测试的充分性就有良好的保证。

    1. 测试的明天

    当我们回归初心,在今天快速发展、激烈竞争的环境下,还会遇到一些新的挑战:

    • 极速测试

    • 高度的自动化

    • 开发者自测(赋能、责任心)

    • 大规模系统的复杂性

    • 新技术

    • ……

    如何应对这些挑战呢?

    (这里省去一万字,如文化与流程重构、技术提升、开发与测试的融合 ... )

    1) 契约驱动测试(CDT)

    • 降低服务集成的难度,将其分解为单元测试和接口测试

    • 团队能以一种离线的方式完成验证, 并将联调的成本几乎降到零

    • 基于契约让接口的变更有迹可循

    • 常用的CDT框架 Janus、Pact、Pacto和Spring Cloud Contract

    1. MBT的高度自动化, **帮助我们克服下列问题:
    • 自动化程度低

    • 模糊的需求

    • 有限的测试覆盖率

    • 测试数据瓶颈

    • 某些组件无法正常工作

    1. 端到端的、全覆盖的TA
    • ATDD/BDD、需求可执行

    • 全SDLC

    • Harness/高度集成

    • 跨平台

    • 可测试性保障

    • 支持CD、DevOps

      image

    4)AI助力测试

    • 智能的单元测试

    • 智能的UI/API测试

    • AI驱动的脚本生成

    • 优化或补充测试用例

    • 质量风险评估的自我调整

    • 缺陷诊断机器人(DDB)

    • 测试环境的智能运维

    • ……

    5)总结:测试发展趋势

    • ATDD/BDD/RBE,需求即测试~彻底左移

    • CI/DevOps: 测试与开发、运维更加融合

    • 分层测试、API/契约驱动测试

    • ET + TA: 更有效的测试策略

    • 借助MBT+AI,高度、智能的自动化测试

    • 高度的可视化、集成化的过程监控、在线测试与实时反馈

    • 测试人干更具创造性、综合性分析建模的工作

    结语:

    跟大家推荐一个学习资料分享群:1079636098,里面大牛已经为我们整理好了许多的学习资料,有自动化,接口,性能等等的学习资料!人生是一个逆水行舟的过程,不进则退,咱们一起加油吧!
    本文转载自微信公众号,如有侵权,请联系删除!  

  • 相关阅读:
    codeforces 455B A Lot of Games(博弈,字典树)
    HDU 4825 Xor Sum(二进制的字典树,数组模拟)
    hdu 1800 Flying to the Mars(简单模拟,string,字符串)
    codeforces 425A Sereja and Swaps(模拟,vector,枚举区间)
    codeforces 425B Sereja and Table(状态压缩,也可以数组模拟)
    HDU 4148 Length of S(n)(字符串)
    codeforces 439D Devu and Partitioning of the Array(有深度的模拟)
    浅谈sass
    京东楼层案例思维逻辑分析
    浅谈localStorage和sessionStorage
  • 原文地址:https://www.cnblogs.com/cemaxueyuan/p/13032281.html
Copyright © 2011-2022 走看看