我们写的代码是如何被用户看到的——前端篇

于 2024-08-30 14:14:53 发布
阅读量321 收藏 21
点赞数 20
文章标签： 前端
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/AlibabaTech1024/article/details/141716953
版权

我们写的代码是如何被用户看到的——前端篇

作者：飞流

一、前言

“用户在浏览器地址输入 URL 之后发生了什么？”

这个问题对于我们前端开发者来说简直是典中典了，是前端基础，也是工作面试八股，更是性能优化依据。但本文想分享的重点不是之后发生了什么，而是之前发生了什么，即我们平时码出来的代码经历了哪些步骤处理，成为互联网用户能打开浏览的页面的？我们又是如何合理的更新网页的？

前一个问题涉及开发与部署，后一个问题涉及发布。下面我将会从网页入口、开发、部署与发布这 4 方面逐步展开分享。

二、Part 1 网页入口

这一 Part 还是简单对用户看到的网页由什么构成，浏览器又做了哪些工作才让这些构成部分呈现在用户面前的网页进行简单介绍，这是 alibaba 商详页：

alibaba.com 商详页

一个内容丰富、设计美观、交互友好的网页离不开前端三剑客 HTML、CSS、JS 以及图片、字体等资源文件：

  • HTML 决定网页内容，是用户访问任意一个网站的入口，既可以在 HTML 中直接编写 CSS、JS 代码，也可以将 CSS、JS 代码写在单独的文件中在 HTML 引入；

  • CSS 作用于网页样式；

  • JS 实现用户交互。

网页入口 HTML 的基本结构：

<!DOCTYPE html><html>  <head>    <title>网页标题，在浏览器打开的网页tab上显示</title>    <meta name="keywords" content="网页关键词，SEO"/>    <meta name="description" content="网页描述，SEO"/>    <!-- html中内联css写法 -->    <style>      .foo {        color: red;      }</style>    <!-- html引入外部单独的css文件写法 -->    <link rel="stylesheet" href="https://x.alicdn.com/xx/xxx/screen.css"/>  </head>  <body>    <!-- 网页内容 -->    <div class="foo">      Page Content    </div>    <!-- html中内联js脚本写法 -->    <script>      function log(param) {        console.log(param)      }      log('解析并执行这段js代码')</script>    <!-- html引入外部单独的js文件写法 -->    <script src="https://x.alicdn.com/xx/xxx/screen.js"></script>    </body></html>

用户访问任意网站之前，要先在地址栏输入一个有效地址，接着浏览器会向服务器发起请求，去拿到该地址对应的网页入口文件即"xxx.html"，打开浏览器 Network 控制台便可以看到，这一定是浏览器第一个接收到的响应内容。

紧接着，浏览器解析 HTML 代码，识别到其他资源发起更多请求，经过各种类型资源的加载、解析、执行（非必需）逐步成为用户眼前看到的完整页面，讲到这里就不得不提到 CRP（Critical Rendering Path，关键路径渲染），即浏览器将 HTML、JS、CSS 代码转换成屏幕上用户可见像素必经的一系列关键步骤，如下：

CRP

  • 网络下载 HTML，解析 HTML 代码构建 DOM；

  • 网络下载 CSS，解析 CSS 代码构建 CSSOM；

  • 网络下载 JS，解析执行 JS 代码，可能会修改 DOM 或 CSSOM；

  • 待 DOM & CSSOM “定型”，浏览器根据 DOM 和 CSSOM 构造 Render Tree；

  • 重排过程计算每个元素节点所在位置与样式；

  • 重绘过程将绘制真实像素于屏幕上。

至此，网页呈现在用户面前，进行下一步的浏览和操作。

三、Part 2 开发阶段

看完上一 Part ，想必你也知道浏览器搜索-呈现网页是怎么回事了，这一 Part 将简单介绍现代化网页开发过程。

3.1 代码编写

在网页内容越来越丰富，网页功能越来越复杂的今天，前端三剑客 HTML、CSS、JS 代码都变得庞大起来，显然，将 CSS、JS 代码都组织在单一 HTML 文件里不再合适，我们也并不会再以传统的方式直接去编写 HTML、CSS、JS 代码，取而代之得是使用各种 UI 框架（如 React/Vue/Angular 等）进行组件式开发，CSS 预处理器（如 Sass/Less/Stylus 等） 等去编写样式。

页面——组件树

3.2 工程能力

利用前端构建工具（如 Webpack/Vite/Rollup 等）组织各种类型的文件，并提供模块化、自动化、优化、转义等构建能力，进行本地开发与生产打包。

各类型业务源码经由构建工具处理转化

其中，有必要对模块化进行说明，它带来的好处就是，在开发阶段，我们可以将不同类型的文件统一视为模块处理，模块成为模块系统中的第一公民，它们之间可以相互引用，至于不同文件类型模块之间的差异，交由构建工具去解决。

在 JS 模块中引入其他模块：

import '@/common/style.scss' // 引入scssimport arrowBack from '@/common/arrow-back.svg' // 引入svgimport { loadScript } from '@/common/utils.js' // 引入js中的函数

区别于开发阶段，构建工具还针对生产环境提供了丰富的构建能力，能将业务源码进行压缩、tree-shaking 优化，uglify 混淆、兼容、extract 抽离等处理，成为适用于生产环境的最优代码。

构建出来的生产环境 JS：

!function(){"use strict";function t(t){if(null==t)return-1;var e=Number(t);return isNaN(e)?-1:Math.trunc(e)}function e(t){var e=t.name;return/(\.css|\.js|\.woff2)/.test(e)&&!/(\.json)/.test(e)}function n(t){var e="__";return"".concat(t.protocol).concat(e).concat(t.name).concat(e).concat(t.decodedBodySize).concat(e).concat(t.encodedBodySize).concat(e).concat(t.transferSize).concat(e).concat(t.startTime).concat(e).concat(t.duration).concat(e).concat(t.requestStart).concat(e).concat(t.responseEnd).concat(e).concat(t.responseStart).concat(e).concat(t.secureConnectionStart)}var r=function(){return/WindVane/i.test(navigator.userAgent)};function o(){return r()}function c(){return!!window.goldlog}var i=function(){return a()},a=function(){var t=function(t){var e=document.querySelector('meta[name="'.concat(t,'"]'));if(!e)return;return e.getAttribute("content")}("data-spm"),e=document.body&&document.body.getAttribute("data-spm");return t&&e&&"".concat(t,".")......

构建出来的生产环境 CSS：

@charset "UTF-8";.free-shipping-block{-webkit-box-orient:horizontal;-webkit-box-direction:normal;-webkit-box-align:center;-ms-flex-align:center;-webkit-align-items:center;align-items:center;background-color:#ffe8da;background-position:100% 100%;background-repeat:no-repeat;background-size:200px 100px;border-radius:8px;display:-webkit-box;display:-webkit-flex;display:-ms-flexbox;display:flex;-webkit-flex-direction:row;-ms-flex-direction:row;flex-direction:row;margin-top:24px;padding:12px}.free-shipping-block .content{-webkit-box-flex:1;-ms-flex-positive:1;color:#4b1d1f;-webkit-flex-grow:1;flex-grow:1;font-size:14px;margin-left:8px;margin-top:0!important}.free-shipping-block .content .desc img{padding-top:2px;vertical-align:text-top;width:120px}.free-shipping-block .co.....

构建出来的生产环境 HTML：

<!doctype html><html><head><script defer="defer" src="/build/xxx.js"></script><link href="/build/xxx.css" rel="stylesheet"></head><body><div id="root"></div></body></html>

四、Part 3 代码部署

至此，我们就得到了网页入口所需所有资源（HTML 及相应的 CSS、JS、其他静态资源），双击 html 文件在浏览器中打开即可本地访问我们的页面，哈！前端就是这么简单！那么可以考虑下一步了，我们还得让测试、产品、运营以及网络上的全球用户都能访问到我们的页面吧？那只在本地运行起来玩一玩儿（doge）肯定不行的，起码得把这些资源全部上传到网络上。

在开发阶段访问网页，一种是在本地运行的开发服务器上， IP 通常是 127.0.0.1/本机 IPv4/IPv6，端口号自定，通过 IP + Port + Path 形式访问；一种是手动将资源上传至服务器，其他人拿到服务器 IP + Port + Path 访问页面（关于网站域名申请备案、映射绑定本文省略一万个字...）。后者可通过专门的发布平台（CI/CD）将整个流程自动化，发布平台做的事情简单来说有：

CI/CD 平台

  • 检查分支提交信息、必须配置、依赖合规检查等系列卡口；

  • 运行脚本，执行事先配置好的依赖安装及打包构建指令，开启云构建，安装项目依赖，并打包一份生产环境产物（说白了云构建这一步就跟我们刚刚 git clone 项目到本地初始化运行、本地 build 是一样的）；

  • 将产物上传至 CDN。

至此，用户就可以在浏览器输入网址访问我们的页面了，服务器返回 HTML，HTML 中引用 CDN 上的资源，交给端（浏览器）去把页面渲染出来。

五、Part 4 发布对外

对于上万（百万）DAU 的页面来说，超多的访问量和极致性能指标，要求我们对页面的迭代修改在正式对外访问前，必须考虑安全发布与用户体验。

5.1 迭代更新

index.css：

.foo {  background-color: red;}

对于 index.css，如果用户每次打开页面都要重新发起对该文件的请求，不仅浪费带宽而且用户还要多等待一段下载时间，完全可以利用 HTTP 缓存中的强缓存将静态资源缓存在浏览器本地，使用户更快看到页面（快体现在浏览器直接从 memory/dist cache 中读取文件，省去了下载时间）。

Cache-Control: max-age=2592000,s-maxage=86400

对于静态资源，服务器往往设置一个非常大的缓存过期时间以充分利用缓存，这样浏览器就彻底不用发起请求了。但是浏览器都不发请求了，如果我们页面有更新/bug 修复该怎么办呢？很容易想到的办法是在资源 url 上拼接版本号，如：

<!doctype html><html>  <head>    <script defer="defer" src="https://x.alicdn.com/build/foo.js?t=0.0.1"></script>    <link href="https://x.alicdn.com/build/index.css?t=0.0.1" rel="stylesheet">  </head>  <body>    <div class="foo"></div>  </body></html>

下次更新时更换版本号就能强制让浏览器重新发起新的请求：

<!doctype html><html>  <head>    <script defer="defer" src="https://x.alicdn.com/build/foo.js?t=0.0.2"></script>    <link href="https://x.alicdn.com/build/index.css?t=0.0.2" rel="stylesheet">  </head>  <body>    <div class="foo"></div>  </body></html>

但这样做存在一个问题，HTML 同时引用了多个文件，如果在一次迭代中只变更了其中的某个文件，其他文件没做修改，统一加版本号的方法岂不是连带让其他文件的本地缓存都失效了！

为解决这个问题，就得实现文件级别粒度的缓存控制，我们很容易想到 HTTPS 中的数据摘要算法，根据文件内容生成唯一 hash 值，文件无修改 hash 值不变，这样就能精确到单个文件的缓存了：

<!doctype html><html>  <head>    <!-- foo.js 无修改继续使用缓存 -->    <script defer="defer" src="https://x.alicdn.com/build/foo.js"></script>    <!-- index.css 改了样式，得请求更新后的文件并缓存 -->    <link href="https://x.alicdn.com/build/index_1i0gdg6ic.css" rel="stylesheet">  </head>  <body>    <div class="foo"></div>  </body></html>

或者通过迭代版本号加入资源路径 Path 的方式：

<!doctype html><html>  <head>    <!-- 资源路径更新，请求新的资源 -->    <script defer="defer" src="https://x.alicdn.com/0.0.2/build/foo.js"></script>    <!-- 资源路径更新，请求新的资源 -->    <link href="https://x.alicdn.com/0.0.2/build/index.css" rel="stylesheet">  </head>  <body>    <div class="foo"></div>  </body></html>

5.2 动静分离

现代前端部署方案，往往将静态资源（JS、CSS、图片等）往往上传到离用户更近的 CDN 上，这些资源基本不怎么改变，需要充分利用缓存提高缓存命中率；而动态页面（HTML）用户数据千人千面、为 SEO 做 SSR，以及为了性能同构，往往存放在离业务服务器更近的地方，取数查数注入数据更快。

两种资源分布在不同地方，那么静态资源就以 CDN 链接引入的方式写于 HTML 中，那么问题来了，我们在更新页面时先发布静态资源还是先发布页面呢？

1）先发布页面，后发布资源：

<!doctype html><html>  <head>    <!-- 资源还没发布完 -->    <script defer="defer" src="https://x.alicdn.com/0.0.1/build/foo.js"></script>    <link href="https://x.alicdn.com/0.0.1/build/index.css" rel="stylesheet">  </head>  <body>    <!-- 页面修改了 -->    <div class="bar"></div>  </body></html>

静态资源发布完成前，期间用户访问到新的页面结构，但是静态资源还是老的，用户可能会看到一个样式错乱的页面，也可能因旧的 JS 脚本找不到元素节点而执行错误的白屏页面，不可行🙅。

2）先发布资源，再发布页面：

<!doctype html><html>  <head>    <!-- 资源已发布 -->    <script defer="defer" src="https://x.alicdn.com/0.0.2/build/foo.js"></script>    <link href="https://x.alicdn.com/0.0.2/build/index.css" rel="stylesheet">  </head>  <body>    <!-- 页面还没发布 -->    <div class="foo"></div>  </body></html>

页面发布完成前，页面结构没变，而资源是新的了，如果用户此前访问过，本地存在老资源的缓存，那么他看到的页面是正常的，否则访问到旧页面却加载新资源，还会出现上述一样的问题，要么样式错乱、要么 JS 执行错误导致白屏，不可行🙅。

所以先部署谁都不行！这也是为啥古早上线项目时要辛苦程序员大佬们半夜偷偷上，挑流量低谷时上的缘故了，毕竟影响面能小些。但是哇，这对于大厂来说可没有绝对的低峰期只有相对低峰期。但哪怕是相对低峰期，对于做事追求极致的我们，也是不可接受的！

上面的问题其实是覆盖式发布导致的，当待发布资源覆盖已发布资源时就会出现问题，对应的解决办法就是非覆盖式发布，通过文件路径添加版本号或文件名加 hash，发布新的资源时不覆盖旧的资源，先全量发布静态资源再逐步灰度推全量发布页面，整个问题就完美解决了。

所以，关于静态资源优化基本要做到：

  • 配置超长缓存过期时间，提高缓存命中率，节省带宽；

  • 采用内容摘要或带版本号的文件路径作为缓存更新依据，做到精确缓存控制；

  • 静态资源 CDN 部署，节省网络请求传输路径，缩短请求响应时间；

  • 以非覆盖式发布更新资源，平滑过渡升级。

至此，前端大佬们辛苦码的代码经过不断迭代、（云）构建、产物资源部署，发布对外，全球用户就可以在互联网上，体验我们的产品，愉快冲浪了～

参考链接

[01] Critical Rendering Path: What It Is and How to Optimize It

https://nitropack.io/blog/post/critical-rendering-path-optimization

[02] Understanding the critical path

https://web.dev/learn/performance/understanding-the-critical-path

[03] 大公司里怎样开发和部署前端代码？

https://www.zhihu.com/question/20790576

阿里技术
关注
  • 20
    点赞
  • 踩
  • 21
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
博客
Java 日常反常识踩坑
08-21 775
本文主要是日常业务开发中自身碰到过跟常识不一致的坑，问题虽然基础，但却可能造成比较大的线上问题。
博客
“JVM” 上的 AOP：Java Agent 实战
08-16 754
说起 AOP 的实现方式，大家可能第一时间想到的是 Spring AOP。Spring AOP 通过封装 Cglib 和 JDK 动态代理的相关逻辑，提供给我们方便的途径来生成动态代理对象，从而轻松实现方法执行前后的切面逻辑。很多常见的日志框架、权限校验框架（Apache Shiro）、RPC 调用框架（Apache Dubbo）的切面逻辑都是通过集成 Spring AOP 来实现的。
博客
深入理解 RDMA 的软硬件交互机制
08-07 906
随着数据中心的飞速发展，高性能网络不断挑战着带宽与时延的极限，网卡带宽从过去的 10 Gb/s 、25 Gb/s 到如今的 100 Gb/s、200 Gb/s 再到下一代的 400Gb/s 网卡，其发展速度已经远大于 CPU 发展的速度。为了满足高性能网络下的通信需求，阿里云不仅自研了高性能用户态协议栈 （Luna、Solar） ，也大规模使用了 RDMA 技术，以充分利用高性能网络。尤其是在存储和 AI 领域，RDMA 被广泛使用。
博客
测试环境领域到测试环境产品
07-31 311
目前的测试环境实践部分方案是基于当前的现状做了局部最优的选择，并非终态方案。有些在已有的基础上做的升级，有些依赖于架构治理的妥协选择：Stable 环境稳定可靠最核心方案应该是运维等级等同于线上，如与线上一同发布、机器规格、部署策略、操作管控等。这方面能力淘天集团前几年已经完成相关的升级。可观测系统对长尾技术栈需要按部就班的接入，如果所有架构统一，也就无需多余的投入。动态配置产品在分支隔离和使用规范上做到极致，其实也无需配置巡检。
博客
LLM 推理加速：decode 阶段的 Attention 在 GPU 上的优化
07-26 981
随着大语言模型（Large Language Models，LLMs）在各领域的广泛应用，如何以低成本构建高吞吐、低延迟的推理服务成为了一个紧迫的问题。考虑到 LLM 在 GPU 上推理时参数量和计算量较大以致于单流执行就可以充分利用 GPU 资源，我们可以把 LLM 的推理延时分解到 kernel level，因此，进一步的，不考虑时间占比小的 kernel 计算后，LLM 的延时优化也就相应的分解成 GEMM 和 Attention 的 kernel 优化。
博客
什么？for 循环也会出问题？
07-19 713
初来乍到的笃某不假思索，对方法入参内的列表使用了排序大法，通过实现 compare 接口，对应两个 Detail 的修改时间，便很轻松的获取到了想要的值。
博客
微软最新 WiFi 远程代码执行漏洞（CVE-2024-30078）探究
07-17 1120
从函数的名称 Dt11Translate80211ToEthernetNdisPacket 可以推测，这个函数用于处理 802.11 数据包。802.11 是一种无线局域网的标准，而 WiFi 是 802.11 标准的一种产品实现。用 IDA 反编译函数，发现补丁是增加了一处对数值的比较，如果不满足条件则返回 NDIS_STATUS_INVALID_PACKET（0xc001000），即数据包非法。调用层次图表明，函数会在接收到 802.11 数据包时被调用。
博客
异步日志：性能优化的金钥匙
07-12 1289
前面提到了 Log4j2 的高可扩展性，同时 Log4j2 的性能也是极高的，下面是 Log4j2 官方的 benchmark 数据，仅供参考：Log4j2 之所以性能如此之高，其中一个很重要的原因就是其。
博客
FlinkSQL 开发经验分享
07-03 1454
FlinkSQL 的开发是最方便高效的实时数据需求的实现途径，但是它和离线的 ODPS SQL 开发在底层的机制和原理上还是有很大的区别，根本的区别就在于流和批的处理。如果按照我们已经习惯的离线思维来写 FlinkSQL，就可能会出现一些“离奇”的结果，但是遇到问题并不可怕，要始终相信根本不存在任何“离奇”，所有的问题都是可以追溯到原因的，而在这个探索的过程中，也可以学习到许多知识，所以让我们遇到更多的问题，积累更多的经验，熟练地应用 Flink。
博客
奇怪的缓存一致性问题
06-28 931
为了使各应用职责及整体的架构设计更加清晰，Push 中心整体将后台配置端和前台投放端分别部署在了两个应用中，两个应用需要分别配置数据库连接，分别配置缓存。数据一致性问题是我们在工程实践中经常遇到的一种问题，了解常见的解决方案，可以帮助我们有效解决该问题，更好地满足业务诉求。本文讲了那么多，到底哪种方案更好呢？是不是强一致性就是最优解？其实不存在绝对的“哪种方案更好”，只有最适合当前系统特性和业务需求的方案。
博客
一次压测引发的数据库 CPU 飙升
06-21 939
一次压测过程中，当数据库的 qps 和 tps 都正常时，如果 cpu 利用率异常的高，应该如何排查？希望通过这篇文章，给你一些启发...
博客
从源码分析 vllm + Ray 的分布式推理流程
06-12 3472
随着 LLM 模型越来越大，单 GPU 已经无法加载一个模型。以 Qwen-14B-Chat 模型为例，模型权重大概 28GB，但是单个 NVIDIA A10 仅有 24GB 显存。如果想要在 A10 上部署 Qwen-14B-Chat 模型，我们需要将模型切分后部署到 2 个 A10 机器上，每个 A10 卡加载一半的模型，这种方式称之为分布式推理。社区涌现了很多支持分布式推理的框架如 vllm、deepspeed-mii，rtp-llm 等。
博客
Master-Worker 架构的灰度发布难题
06-05 915
Master-Worker 架构是成熟的分布式系统设计模式，具有集中控制、资源利用率高、容错简单等优点。我们数据中心内的几乎所有分布式系统都采用了这样的架构。我们曾经发生过级联故障，造成了整个集群范围的服务中断。这让我们反思到 Master-Worker 架构难以有效的分批灰度发布的问题。本文试图分析其中原因，并尝试提出几种解决方案。防范集群范围的级联故联是分布式系统中的难题。本文提出了三种方法，但它们都有各自的局限。
博客
如何优雅地编写缓存代码
05-22 510
在日常的编码实践中，经常会用到缓存来解决高并发问题，缓存可以说是解决流量洪峰的不二利器。虽然集团中间件团队已经构建了缓存的基础设施，已经帮助我们解决了绝大部分问题，但是在实际的编码使用过程中，应用端调用缓存 API 时还是存在下述几类问题：使用缓存的逻辑非常通用，基本都是先查缓存，有直接返回，没有查 DB，再放入缓存中。这段通用逻辑散落在系统的各个地方，违反了高内聚低耦合的原则。缓存代码和业务逻辑代码深度耦合在一起，不仅降低了代码的可读性，还额外增加了系统复杂度。
博客
上海交大携手阿里巴巴成立人工智能与系统联合实验室
05-15 695
张瓅玶（谷朴）介绍了联合实验室的成立目标与组织架构，表示阿里巴巴将全力支持联合实验室的建设与发展，期待双方共同努力，产出更多具有影响力的科研成果，为阿里巴巴的业务创新提供有力支撑，并成为双方在 AI 与系统领域创新合作与人才交流的桥梁。复旦大学计算机学院薛向阳教授带来了题为《基于重构的组成式视觉场景表示学习》的学术报告，从视觉场景建模和组成式表示推断的角度，分享了基于重构的深度神经网络组成式场景表示学习的当前进展。
博客
浅谈现代消息队列与云存储
05-10 1210
1970 年代末，消息系统用于管理多主机的打印作业，这种削峰解耦的能力逐渐被标准化为“点对点模型”和稍复杂的“发布订阅模型”，实现了数据处理的分布式协同。随着时代的发展，Kafka，Amazon SQS，RocketMQ，Azure Service Bus，Google Pub/Sub，RabbitMQ 等众多产品为开发者在不同业务场景下提供了富有竞争力的解决方案，并扩展出顺序，事务，定时消息，精确一次投递等丰富的语义和特性，让消息系统成为分布式系统中的标准组件。
博客
世界读书日|看看阿里内部的技术大牛们推荐了什么书?
04-24 522
AI 时代，技术呈指数级发展，我们越来越关注，如何持续学习提升，跟上时代的步伐。刚好借着世界读书日的契机，我们邀请了阿里内部的技术大牛们，分享他们在 AI 时代持续学习的过程中，推荐的一些内容。这其中的每一本书，都带有推荐者深刻的感悟与独到的见解。在这个春意正浓的季节，期待与你重逢在阅读的旅程中。
博客
如何爬出 Kotlin 协程死锁的坑？
04-17 1347
/ 这段代码将死锁到天荒地老final ExecutorService executorService = Executors.newSingleThreadExecutor();相比别的死锁问题, 这一类问题的坑点在于, 因为线程池的实现问题, jstack 等 jvm 工具无法对其自动诊断, 只能肉眼看出。在 Kotlin 协程中, 因为底层的线程池申请更加黑盒, 如果不是足够了解, 很容易踩到这类坑。本文不会再去重复 Kotlin 协程的基本语法, 而是专注于死锁的话题。
博客
一些 MaxCompute 日常优化案例分享
04-10 773
MaxCompute 优化是一个多样而又重要的过程，优化过程中若能够深入理解 ODPS 的工作原理和内部机制，才能够更明确的发现运行过程中存在的问题，这样才能更有针对性地进行优化，优化需要不断思考和尝试不同的想法和方法，适当的时候我们可以寻求平台技术人员帮助，以找到最适合的优化方案。以下通过日常几个优化案例，最终优化手段可能非常简单，但其中的分析过程较为重要，希望对他人有所启发。
博客
漫谈测试策略
04-03 1271
测试策略有两层背景叠加：业务大背景和项目小背景。下文提到的测试策略有时指代业务级测试策略，有时指代项目级测试策略，如果无特指强调，则是在探讨两类测试策略的共同特点。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值