51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

查看: 3353|回复: 1
打印 上一主题 下一主题

[转贴] 从事软件测试行业将会面临哪些考验

[复制链接]
  • TA的每日心情
    无聊
    昨天 09:19
  • 签到天数: 933 天

    连续签到: 5 天

    [LV.10]测试总司令

    跳转到指定楼层
    1#
    发表于 2021-9-2 09:38:00 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
    在技术层面,不同开发模型所采用的开发、测试方式也不尽相同,这正是驱动 IT 行业技术发展的真正的原因。
      简单地说,在传统的瀑布模型时代,大家都挺慢,系统需求也不会有太多变化,单纯美好的年代里,我们有足够的时间来准备详尽的测试计划、测试用例,慢慢地测。但如果在敏捷迭代的短频快开发模式下,事情就变得不那么美好了。
      由于敏捷开发模式下,每个迭代周期最终都要开发一个完整的可用版本,所以在每一个迭代周期内,软件测试工程师都要进行完备的测试,以确保发布出去的软件产品是没有问题的。但每个迭代版本的周期又比过去的瀑布模式开发缩短了很多,这意味着相同时间内,你发布的次数增多了。而每一次发布版本都意味着你要快速回归所有重要的测试场景,这通常来说工作量非常巨大。
      所以,测试不能等着编码完成之后再去完成了,那怎么办呢?
      这时,我们提出了测试左移和测试右移的概念。所谓测试左移,即测试往需求方向移动,介入到需求、设计、编码、集成过程中去,提前寻找可能存在的问题。而测试右移,则是指测试加入到发布后的流程中去,通过生产环境监控得来的各种数据去分析潜在的缺陷。

    所以,现在质量已经不再单单是软件测试工程师的责任了,而是团队所有角色(开发、质量保证人员、技术运维)都要对产品质量负责。
      · Devops
      最近几年业界流行的所谓 Devops(开发运维)其实就是开发、质量保证人员、运维三个角色的交集。Devops 旨在通过自动化的“软件交付”和“架构变更”的流程,来解决不同角色之间合作的流畅度,以及把软件交付的构建、测试、发布变得更加快捷、频繁和可靠,充分适应现代互联网产品短频快的特点。

    Devops 在提高了公司的研发效率的情况下,也给测试人员带来又一个挑战:即如何在持续集成、持续部署的模式下保障质量?
      对于软件测试来说,如何把测试活动,特别是自动进行的测试活动无缝融合到公司的持续集成、持续部署框架下,将是一个非常大的挑战,也是未来大家在软件测试职业生涯上再走远一些,将要面对的问题。
      · 微服务
      微服务这词现在在 IT 行业非常火,几乎是大厂产品的标配了。怎么理解微服务呢?
      它也是一种产品实现模式,虽然微服务实现起来比较复杂,但理解起来相对来说还是比较容易的。你可以理解为,传统的开发是基于单体应用,就是不管功能再多,都是作为一个应用整体来进行构建和部署的。虽然有分层,但仍然是一个整体。而微服务模式下会将应用进行拆分,拆分成更小的独立服务,并使它们可以单独构建和部署。

    微服务的引进提升了开发效率,降低了发布时间,但也带来了新的挑战:由于各个微服务常由不同的团队负责微服务的引进提升了开发效率,降低了发布时间,但也带来了新的挑战:由于各个微服务常由不同的团队负责契约测试”也就相应产生了。
      还有,相较于传统单体应用,微服务的测试也更加复杂。仅从代码打包部署这件事儿来说,在单体应用里,不太会出现使用错测试包的情况,但是在微服务里,这个情况可能会发生。
      单体应用,一个版本就对应一个代码分支;而使用微服务,每个微服务通常对应不同的代码分支。这就意味着在测试微服务时,测试不仅要关注你测试的微服务是否版本部署正确,还要检查其依赖的其他微服务的部署分支,查看其他微服务的分支是不是也部署正确。
      除此之外,微服务的采用,也让我们的技术栈更为繁多、复杂,比如:
    1. 因为我解决微服务间复杂的通信和消息传递问题,引入了 RabbitMQ、RocketMQ、Kafka 各种消息中间件;
    2.   因为多个微服务的独立部署导致的环境依赖问题,引入了容器化技术 Docker;
    3.   容器越来越多,要解决其管理和维护问题而引入了 Kubernetes;
    4.   为简化故障定位问题,引入 ELK(Elasticsearch + Logstash + Kibana);
    5.   上线后,要对系统运行情况进行监控,因而引入了 Prometheus 与 Grafana 等。
    复制代码
    以上“新”技术的引入,是为了不断应对软件开发演变中带来的各项需求和问题,解决了旧问题的同时,也为测试带来了新挑战。
      面对这些挑战,软件测试在快速演进的同时,也在裹挟前行,寻找破局之道。那么这个破局之道是什么呢?
      答案就是测试开发工程师。
      正如前文所述,软件的发布动作变得越来越频繁,以往靠大量手工功能测试+少量主流程自动化测试+部分回归测试来保障质量的做法,变得越来越不现实。自动化测试,特别是不同层次的自动化测试在整个测试活动中的占比,正逐渐成为影响软件发布质量的关键。这也就是测试开发在近年来越来越受追捧的原因。
      这么多的自动化测试用例,需不需要维护?如何维护?如何将自动化测试融入公司的持续集成流程中并自动触发运行?这些都是测试开发首要关注的问题,可以预料的是,随着交付频率的加快,测试开发会变成软件测试人员的基本技能。
      所以,为什么我们一开始就说现在传统的点点点工程师已经没有出路,测试开发工程师才有未来,就是这个原因。



    本帖子中包含更多资源

    您需要 登录 才可以下载或查看,没有帐号?(注-册)加入51Testing

    x
    分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
    收藏收藏
    回复

    使用道具 举报

  • TA的每日心情
    开心
    2021-6-9 14:08
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    2#
    发表于 2021-9-26 16:05:09 | 只看该作者
    测试行业各种考验,不过话又说回来,测试还是最好入行的工作
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-4-20 12:08 , Processed in 0.070013 second(s), 23 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表