微服务架构的云原生测试技术

如果无法正常显示,请先停止浏览器的去广告插件。
分享至:
1. 微服务架构的云原生测试 张伟
2. 讲师简介 请插入 您的照片 张伟 测试开发专家 ee.msup.com.cn 阿里云云原生团队测试开发专家 云原生测试白皮书编写组成员 曾担任蚂蚁中间件测试团队负责人 带领团队保障了蚂蚁中间件大促千万级峰值交 易的稳定性,保障了蚂蚁金服 Service Mesh 大规模落地(生产 Mesh 化容器几十万台)的 平稳顺畅以及antstack的对外输出质量。
3. 目录 • • • • • • • • • • • • • ee.msup.com.cn 总述 软件测试云化的发展趋势 传统系统稳定性保障痛点 微服务架构带来的系统稳定性保障痛点 云化后系统稳定性保障的新痛点 阿里云云原生质量保障解决方案 云原生测试实践-测试环境一键拉起,即用即抛 云原生测试实践-云原生的流量录制 云原生测试实践-流量分层自动化测试 云原生测试实践-流量分层性能测试 云原生测试实践-微服务链路问题排查 云原生测试实践-微服务线上问题复现 云原生测试实践- CICD平台集成
4. 总述 随着云原生技术的兴起,也给测试领域也带来了新的技术思路,基于云原生的 测试技术百花齐放。本次分享给大家带来阿里云在云原生方面的测试技术创新 和实践,本次分享给大家带来测试领域向云上发展带来的优缺点,从微服务架 构的应用在测试环境构建、运维、持续构建,测试活动开展,测试资源回收的 完整测试活动周期来看云上测试的优劣势,为大家服务上云后的测试上云提供 技术解决思路,以及为大家带来阿里云云原生测试在解决这些问题的相关技术 方案与实践。 ee.msup.com.cn
5. 软件测试技术云化的发展趋势 软件测试的技术发展主要分为以下几个阶段:传统时代的测试、互联网时代的 测试、移动互联网时代的测试、云原生时代的测试 阶段 特点 ee.msup.com.cn 瀑布模型 分工和角色明确 交付验收 测试工具简单稀少 测试人员研发技能弱 敏捷模型 CI 弱化角色 测试人员编码能力提升 测试工具蓬勃发展 CICD 发布实时性要求高 全栈 流量碎片化 移动端测试蓬勃发展 云化 容器 可以低成本使用先进的测试工具 质量技术向线上稳定性发展 测试工具更加创新、智能
6. 传统系统稳定性保障痛点 稳定性较差 人力投入大 对依赖环境和依服务稳定性要求高 编码 手工 时间长 硬件资源成本高 对测试人员能力要求高 工具开发 工具部署运维 测试数据构造难 难以模拟生产真实用户场景 测试动作 UI 集成 单元/接口 系统 测试管理和工具基础平台 测试环境 测试环境硬件成本高 申请购买测 试资源 硬件资源准备周期长 环境配置 应用部署 环境搭建复杂耗时长 测试环境搭建和使用低效 ee.msup.com.cn 机器资源释 放 机器资源协 调 机器资源重 置 环境资源共用协调难
7. 微服务架构应用的系统稳定性保障痛点 Html、Android、IOS • • • • • 微服务依赖多,测试环境搭建困难 微服务应用的接口测试覆盖难度大 微服务应用难以针对每个应用做场景类测试 微服务应用线上问题,线下难以复现 故障或问题排查难 gateway S1 Redis ee.msup.com.cn S2 S… DB
8. 云化后系统稳定性保障新痛点 典型的企业上云后测试工作挑战 云上测试开发 云下测试开发 API调试/自动化:postman/yapi 由于网络和安全组的限制,开源测试工具都需要下沉 使用和部署难度大大提升 开源工具大多只支持HTTP,需要二次开发 压测:jmeter, wrk, locust... UI测试: 手动/自动化 办公网 业务上云 办公网 网络打通 测试环境 HTTP VPC 被测应用 网络隔离 微服务(SPRINGCLOUD/DUBBO/...) API调试/自动化:postman/yapi 压测:jmeter, wrk, locust... 被测应用 ee.msup.com.cn
9. 分布式架构系统稳定性保障痛点总结 • • • • • ee.msup.com.cn 测试脚步和工具开发投入人力资源成本大 测试环境构建部署运维,资源利用率低,环境利用低效 测试数据构造难,难以覆盖真实用户操作场景。 微服务架构,服务多,依赖多,链路长,测试、复现、排查问题难。 云上网络复杂,测试工具部署运维成本高,打通网络成本高。
10. 阿里云云原生的质量解决方案(OneTest) 用户业务稳定性保障——典型使用场景 技术红利 生产环境 使用场景 线上稳定性保障 上线验证 链路追踪 业务巡检/告警 测试流量真实 API/微服务接口 回归测试 线上应用 环境即用即抛 线上应用 性能测试 执行全自动化 沉淀测试方案 生产/测试流量 录制 阿里云智 能流量测 试 完美适应云原生 研发环境 测试环境 接口调试 快速压测 故障重现 API/微服务接口 被测应用 故障重现 压测 自动化回归 API/微服务接口 被测应用 被测应用 被测应用 测试资源 测试环境一键拉起 ee.msup.com.cn 测试资源即测即用 测试资源用完即抛
11. 测试环境的一键拉起、用完即抛 容器化部署,测试环境一键拉起,用完即抛 apiVersion: apps/v1 kind: Deployment metadata: annotations: deployment.kubernetes.io/revision: "63" creationTimestamp: null generation: 1 labels: app: productservice1 name: productservice1 selfLink: /apis/apps/v1/namespaces/default/de ployments/productservice1 spec: progressDeadlineSeconds: 600 replicas: 2 revisionHistoryLimit: 10 selector: matchLabels: app: productservice1 strategy: rollingUpdate: maxSurge: 25% maxUnavailable: 25% type: RollingUpdate template: metadata: annotations: alicloud.service.tag: tag1 armsPilotAutoEnable: "on" armsPilotCreateAppName: {{ .Values.application.name.prefix}}pro ductservice1 ee.msup.com.cn labels: app: productservice1 spec: containers: - env: - name: micro.service.shutdown.wait.time value: "5000" - name: spring.cloud.nacos.discovery.server-addr value: {{ .Values.mse.address.springcloud}} - name: dubbo.registry.address value: {{ .Values.mse.address.dubbo}} - name: JAVA_TOOL_OPTIONS value: ' - agentlib:jdwp=transport=dt_socket,serve r=y,suspend=n,address=5005 ' - name: dubbo.consumer.check value: "false" image: registry.cn- hangzhou.aliyuncs.com/mse- hz/productservice:{{ .Values.images.versi on}} imagePullPolicy: Always name: productservice1 ports: - containerPort: 8080 protocol: TCP resources: requests: cpu: 250m memory: 512Mi terminationMessagePath: /dev/termination-log terminationMessagePolicy: File dnsPolicy: ClusterFirst restartPolicy: Always schedulerName: default-scheduler securityContext: {
12. 测试环境的一键拉起、用完即抛的实现 问题: 1.K8S集群部署运维难,集群稳定性比较差 2.helm-char配置文件编写,需要理清服务以来,配置相对比较复杂 ee.msup.com.cn
13. 云原生测试实践(OneTest) -云原生流量录制 特性 阿里云流量录制的4个主要特点 ee.msup.com.cn 01 02 03 04 0业务改造0接入 0运维 技术能力 开放 不需要业务系统做任何改造、 接入 不需要业务系统做任何agent的 运维 支持后端服务多种协议录制回 放、事务录制与回放 支持跟主流开源测试工具集成, 支持跟已有的测试系统集成, 数据开放,支持接口流量数据 导出
14. 云原生测试实践(OneTest) -流量录制 即用即录,自主可控 支持多种协议(springcloud、dubbo、http…) 支持用户场景事务化录制 跨VPC网络 ee.msup.com.cn
15. 云原生测试实践(OneTest) -流量录制技术 问题: 1.网络层采集需要解析匹配相应协议,如果不用mesh化,复杂协议需要做 代理服务。 2.流量降噪,没有最好,只有更好 3.不同场景,选用不同方式的流量录制 ee.msup.com.cn
16. 云原生测试实践(OneTest) -微服务应用分层 自动化测试 • 微服务单应用接口流量测试自动生成用例 • 以用户使用视角进行单个微服务的测试 • 支持http、dubbo、spring cloud等多种协议 ee.msup.com.cn
17. 云原生测试实践(OneTest) -微服务应用分层 性能压测 • 微服务单应用接口流量自动生成性能压测场景和脚本 • 自动化生成海量生产环境的用户真实请求数据进行压测 • 支持http、dubbo、spring cloud等多种协议 ee.msup.com.cn
18. 云原生测试实践(OneTest) - 链路问题排查 生产或测试环境,系统的全部应用流量链路追踪流量录制开启后, 即可通过录制到的请求里面链路ID,搜索到上下游的应用请求出 餐和入参情况,方便排查和定位问题 ee.msup.com.cn
19. 云原生测试实践(OneTest) - 链路问题排查 需要关注的问题: 1.链路分析流量采样率要设置比较低,采样时间要设置长 2.链路学习和更正要根据代码覆盖量来判断是否足够 3.Tracid id传输不丢 ee.msup.com.cn
20. 云原生测试实践(OneTest) - 线上问题重现 选择线上出问题的场景(不确定应用,选择场景涉及的所有应用)或者出问 题应用开启流量录制,线下选择回放和mock调不需要的应用,则可重新故障 请求。 ee.msup.com.cn
21. 云原生测试实践- CI/CD平台集成 • 可以被CICD平台定制和集成 • 支持主流的可持续集成平台 • 提供私有可持续集成平台对接接口 ee.msup.com.cn
22. 总结 • 测试环境一键部署,减少测试环境构建成本,测试环境用完即抛,节约测试 资源硬件成本。 • 云原生的测试解决方案使用使用可以节约测试工具开发,脚步开发等测试 人力投入成本。 • 事务性流量录制和转化为自动化和性能测试,解决了微服务测试数据构造难, 难以覆盖真实用户操作场景的问题,让系统更加稳定。 • 链路追踪和生产故障线下重现,解决了微服务架构,依赖多,链路长,测试、 复现、排查问题难。 • 云原生化的能力,减少了网路打通和测试工具运维成本 ee.msup.com.cn
23. 展望 数据驱动 云原生时代,海量的数据存储在云端,为我们测试数据挖掘提供了便利,我们可以方便的构建我们的 数据仓库和数据清洗逻辑,这些海量的测试数据挖掘,可以为应用的测试提供广阔的想象空间,例如 通过对功能测试数据挖掘,可以找到我们功能测试低效的具体点,并提供解决思路,持续提升测试效 能。通过对性能数据挖掘,可以提前预判系统性能瓶颈,实时根据生产流量变化自动化扩缩容服务容 量。 云上AI 现在云原生时代,我们认为测试需要走向智能化,可以解决如下几个问题。 •增强的准确性——人肯定会犯错,AI和机器学习该上场了 •效率更高——AI无需手动处理成千上万的代码,在几秒钟内扫描代码并在更短的时间内检测到错误。通过 将人工智能纳入重复测试中,质量检查工程师可以专注于测试新功能或关注软件的重要部分。 •成本更低,更加自动化——人工智能程序可以随着代码的更改而发展。他们可以适应并学会识别新功能。 •正确理解客户需求——AI可以检测类似的网站和应用程序,以确定哪些因素能帮助赢得目标受众,也可以 帮助研究大量竞争产品以确定其优势。通过正确理解客户的需求,他们可以创建测试用例,以确保产品在实 现这些特定目标时不会损坏。 ee.msup.com.cn
24. 关注msup公众号 获取更多工程效能实践案例

首页 - Wiki
Copyright © 2011-2024 iteam. Current version is 2.137.1. UTC+08:00, 2024-11-24 09:36
浙ICP备14020137号-1 $访客地图$