相关操作 配置主机授权后，您可以取消主机授权，取消主机授权后，将不能完全扫描出主机的安全风险。有关取消主机授权的详细操作，请参见取消主机授权。 Windows主机 漏洞扫描 依赖于WinRM服务开启，如何开启请参见如何开启WinRM服务。开启WinRM服务后，请将如下IP加入可访问您主机上WinRM（HTTPS是5986端口，HTTP是5985端口）的白名单列表中： 119.3.232.114，119.3.237.223，124.70.102.147，121.36.13.144，124.70.109.117，139.9.114.20，119.3.176.1，121.37.207.185，116.205.135.49，110.41.36.44，139.9.57.171，139.9.1.44，121.37.200.40

benchmark方法介绍 性能benchmark包括两部分。 静态性能测试：评估在固定输入、固定输出和固定并发下，模型的吞吐与首token延迟。该方式实现简单，能比较清楚的看出模型的性能和输入输出长度、以及并发的关系。 动态性能测试：评估在请求并发在一定范围内波动，且输入输出长度也在一定范围内变化时，模型的延迟和吞吐。该场景能模拟实际业务下动态的发送不同长度请求，能评估推理框架在实际业务中能支持的并发数。 性能benchmark验证使用到的脚本存放在代码包AscendCloud-LLM-xxx.zip的llm_tools/llm_evaluation目录下。 代码目录如下: benchmark_tools |--- modal_benchmark |--- modal_benchmark_parallel.py # modal 评测静态性能脚本 |--- utils.py ├── benchmark_parallel.py # 评测静态性能脚本 ├── benchmark_serving.py # 评测动态性能脚本 ├── generate_dataset.py # 生成自定义数据集的脚本 ├── benchmark_utils.py # 工具函数集 ├── benchmark.py # 执行静态、动态性能评测脚本 ├── requirements.txt # 第三方依赖

动态benchmark 本章节介绍如何进行动态benchmark验证。 获取数据集。动态benchmark需要使用数据集进行测试，可以使用公开数据集，例如Alpaca、ShareGPT。也可以根据业务实际情况，使用generate_datasets.py脚本生成和业务数据分布接近的数据集。 方法一：使用公开数据集 ShareGPT下载地址: https://huggingface.co/datasets/anon8231489123/ShareGPT_Vicuna_unfiltered/resolve/main/ShareGPT_V3_unfiltered_cleaned_split.json Alpaca下载地址: https://github.com/tatsu-lab/stanford_alpaca/blob/main/alpaca_data.json 方法二：使用generate_dataset.py脚本生成数据集方法： 客户通过业务数据，在generate_dataset.py脚本，指定输入输出长度的均值和标准差，生成一定数量的正态分布的数据。具体操作命令如下，可以根据参数说明修改参数。 cd benchmark_tools python generate_dataset.py --dataset custom_datasets.json --tokenizer /path/to/tokenizer \ --min-input 100 --max-input 3600 --avg-input 1800 --std-input 500 \ --min-output 40 --max-output 256 --avg-output 160 --std-output 30 --num-requests 1000 generate_dataset.py脚本执行参数说明如下： --dataset：数据集保存路径，如custom_datasets.json。 --tokenizer：tokenizer路径，可以是HuggingFace的权重路径。backend取值是openai时，tokenizer路径需要和推理服务启动时--model路径保持一致，比如--model /data/nfs/model/llama_7b， --tokenizer也需要为/data/nfs/model/llama_7b，两者要完全一致。 --min-input：输入tokens最小长度，可以根据实际需求设置。 --max-input：输入tokens最大长度，可以根据实际需求设置。 --avg-input：输入tokens长度平均值，可以根据实际需求设置。 --std-input：输入tokens长度方差，可以根据实际需求设置。 --min-output：最小输出tokens长度，可以根据实际需求设置。 --max-output：最大输出tokens长度，可以根据实际需求设置。 --avg-output：输出tokens长度平均值，可以根据实际需求设置。 --std-output：输出tokens长度标准差，可以根据实际需求设置。 --num-requests：输出数据集的数量，可以根据实际需求设置。 进入benchmark_tools目录下，切换一个conda环境。 cd benchmark_tools conda activate python-3.9.10 执行脚本benchmark_serving.py测试动态benchmark。具体操作命令如下，可以根据参数说明修改参数。 python benchmark_serving.py --backend vllm --host ${docker_ip} --port 8080 --dataset custom_datasets.json --dataset-type custom \ --tokenizer /path/to/tokenizer --request-rate 0.01 1 2 4 8 10 20 --num-prompts 10 1000 1000 1000 1000 1000 1000 \ --max-tokens 4096 --max-prompt-tokens 3768 --benchmark-csv benchmark_serving.csv --backend：服务类型，如tgi，vllm，mindspore、openai。 --host ${docker_ip}：服务部署的IP地址，${docker_ip}替换为宿主机实际的IP地址。 --port：推理服务端口。 --dataset：数据集路径。 --dataset-type：支持三种 "alpaca"，"sharegpt"，"custom"。custom为自定义数据集。 --tokenizer：tokenizer路径，可以是HuggingFace的权重路径，backend取值是openai时，tokenizer路径需要和推理服务启动时--model路径保持一致，比如--model /data/nfs/model/llama_7b， --tokenizer也需要为/data/nfs/model/llama_7b，两者要完全一致。 --request-rate：请求频率，支持多个，如 0.1 1 2。实际测试时，会根据request-rate为均值的指数分布来发送请求以模拟真实业务场景。 --num-prompts：某个频率下请求数，支持多个，如 10 100 100，数量需和--request-rate的数量对应。 --max-tokens：输入+输出限制的最大长度，模型启动参数--max-input-length值需要大于该值。 --max-prompt-tokens：输入限制的最大长度，推理时最大输入tokens数量，模型启动参数--max-total-tokens值需要大于该值，tokenizer建议带tokenizer.json的FastTokenizer。 --benchmark-csv：结果保存路径，如benchmark_serving.csv。 --served-model-name： 选择性添加， 选择性添加，在接口中使用的模型名；如果没有配置，则默认为tokenizer。 --num-scheduler-steps: 需和服务启动时配置的num-scheduler-steps一致。默认为1。 脚本运行完后，测试结果保存在benchmark_serving.csv中，示例如下图所示。 图2 动态benchmark测试结果（示意图）

静态benchmark验证 本章节介绍如何进行静态benchmark验证。 已经上传benchmark验证脚本到推理容器中。如果在步骤四 制作推理镜像步骤中已经上传过AscendCloud-LLM-x.x.x.zip并解压，无需重复执行。 进入benchmark_tools目录下，运行静态benchmark验证。 cd benchmark_tools 语言模型脚本相对路径是tools/llm_evaluation/benchmark_tools/benchmark_parallel.py，具体操作命令如下，可以根据参数说明修改参数。 python benchmark_parallel.py --backend openai --host ${docker_ip} --port ${port} --tokenizer /path/to/tokenizer --epochs 5 --num-scheduler-steps 8 \ --parallel-num 1 4 8 16 32 --prompt-tokens 1024 2048 --output-tokens 128 256 --benchmark-csv benchmark_parallel.csv 参数说明 --backend：服务类型，支持tgi、vllm、mindspore、openai等后端。本文档使用的推理接口是openai。 --host：服务部署的IP，${docker_ip}替换为宿主机实 际的IP地址。 --port：推理服务端口。 --tokenizer：tokenizer路径，HuggingFace的权重路径。 --epochs：测试轮数，默认取值为5。 --parallel-num：每轮并发数，支持多个，如 1 4 8 16 32。 --prompt-tokens：输入长度，支持多个，如 128 128 2048 2048，数量需和--output-tokens的数量对应。 --output-tokens：输出长度，支持多个，如 128 2048 128 2048，数量需和--prompt-tokens的数量对应。 --benchmark-csv：结果保存文件，如benchmark_parallel.csv。 --num-scheduler-steps: 需和服务启动时配置的num-scheduler-steps一致。默认为1。 --served-model-name： 选择性添加，在接口中使用的模型名；如果没有配置，则默认为tokenizer。 --enable-prefix-caching：服务端是否启用enable-prefix-caching特性，默认为false。 脚本运行完成后，测试结果保存在benchmark_parallel.csv中，示例如下图所示。 图1 静态benchmark测试结果（示意图）

单条请求性能测试 针对openai的/v1/completions以及/v1/chat/completions两个非流式接口，请求体中可以添加可选参数"return_latency"，默认为false，若指定该参数为true，则会在相应请求的返回体中返回字段"latency"，返回内容如下： prefill_latency（首token时延）：请求从到达服务开始到生成首token的耗时 model_prefill_latency（模型计算首token时延）：服务从开始计算首token到生成首token的耗时 avg_decode_latency（平均增量token时延）：服务计算增量token的平均耗时 time_in_queue（请求排队时间）：请求从到达服务开始到开始被调度的耗时 request_latency（请求总时延）：请求从到达服务开始到结束的耗时 以上指标单位均是ms，保留2位小数。

单点登录测试 应用凭证申请。 服务器接口调测成功后，集成联营Kit前，服务商需要申请应用凭证，该凭证在发布商品、Kit集成阶段均会使用，具体操作步骤请参见《云商店 接入指南》的应用凭证申请。 应用测试账号获取。 服务商成功申请应用凭证并完成如上的接口开发后，为了测试已调试好的应用的可用性，可以申请测试账号进行测试验证，具体操作步骤请参见《云商店 接入指南》的应用测试账号获取。 父主题： 单点登录改造和测试

创建测试套件 自动化测试套件，实现用例串行/并行执行的策略，测试用例分块加速能力，有效提高资源池利用率，减少任务阻塞情况。并且可提前拦截产品缺陷，更加快速地发现问题。 可通过以下两种入口新建测试套件。 入口一：单击主页面的“新建测试套件”选项。 入口二：单击左侧测试用例旁边的，选择下拉选项中的“新建测试套件”选项。 在“新建测试套件”页面，填写用例名称与描述。 单击，弹出“添加测试用例”对话框，选择需要添加到测试套件的测试用例，单击“确定”。 单击，弹出“执行策略”对话框，根据需要配置执行策略，单击“确定”。 定时类型：执行一次、周期性重复执行，周期性指设置一个执行频率，测试套按照这个频率周期重复执行。 任务开始时间：立即执行、指定开始时间。 执行时间区间：全天执行、指定执行区间，即指定套件执行的时间段。 用例超时时间：设置每个用例的最长执行时间，超过时间，用例则超时失败。 任务继续执行，直到最后一个用例执行完毕。可设置分钟级，小时级，天级。 回到当前测试套件页面，单击右上角“保存“，完成自动化测试套件创建。 父主题： 测试套件管理

测试脚本 ./kafka-producer-perf-test.sh --producer-props bootstrap.servers=${连接地址} acks=1 batch.size=16384 linger.ms=10 --topic ${Topic名称} --num-records 10000000 --record-size 1024 --throughput -1 --producer.config ../config/producer.properties bootstrap.servers：购买Kafka实例后，获取的Kafka实例的地址。 acks：消息主从同步策略，acks=1表示异步复制消息，acks=-1表示同步复制消息。 batch.size：每次批量发送消息的大小（单位为字节）。 linger.ms：两次发送时间间隔。 topic：创建Topic中设置的Topic名称。 num-records：总共需要发送的消息数。 record-size：每条消息的大小。 throughput：每秒发送的消息数。

测试结果 测试场景一（实例是否开启SASL）：相同的Topic（30分区、3副本、异步复制、异步落盘），实例分为开启SASL和未开启SASL，测试结果如下： 表3 测试结果 实例规格 磁盘类型 代理数量 TPS（开启SASL） TPS（未开启SASL） kafka.2u4g.cluster 超高I/O 3 100000 280000 kafka.4u8g.cluster 超高I/O 3 170000 496000 kafka.8u16g.cluster 超高I/O 3 200000‬ 730000 kafka.12u24g.cluster 超高I/O 3 320000 790000 kafka.16u32g.cluster 超高I/O 3 360000 1000000 结论：在Topic相同的情况下，生产消息到规格相同、接入方式不同的Kafka实例，未开启SASL的实例TPS高于开启SASL的实例TPS。 测试场景二（同步/异步复制）：相同的实例（超高I/O、3个代理、未开启SASL），不同复制机制的Topic，生产者进程数为3时，测试结果如下： 表4 测试结果 实例规格 是否同步落盘 副本数 分区数 TPS（同步复制） TPS（异步复制） kafka.2u4g.cluster 否 3 30 100000 280000 kafka.4u8g.cluster 否 3 30 230000 496000 kafka.8u16g.cluster 否 3 30 342000 730000 kafka.12u24g.cluster 否 3 30 383000 790000 kafka.16u32g.cluster 否 3 30 485000 1000000 结论：生产消息到同一个Kafka实例的不同Topic中，Topic除了复制机制，其他参数相同，异步复制Topic的TPS高于同步复制Topic的TPS。 测试场景三（是否同步落盘）：相同的实例（超高I/O、3个代理、未开启SASL），不同落盘机制的Topic，测试结果如下： 表5 测试结果 实例规格 是否同步复制 副本数 分区数 TPS（同步落盘） TPS（异步落盘） kafka.2u4g.cluster 否 3 30 30000 280000 kafka.4u8g.cluster 否 3 30 32500 496000 kafka.8u16g.cluster 否 3 30 36100 730000 kafka.12u24g.cluster 否 3 30 37400 790000 kafka.16u32g.cluster 否 3 30 40400 1000000 结论：生产消息到同一个Kafka实例的不同Topic中，Topic除了落盘机制，其他参数相同，异步落盘Topic的TPS远远高于同步落盘Topic的TPS。 测试场景四（不同磁盘类型）：相同的Topic（30分区、3副本、异步复制、异步落盘），不同磁盘类型的实例，测试结果如下： 表6 测试结果 实例规格 代理数量 是否开启SASL TPS（高I/O） TPS（超高I/O） kafka.2u4g.cluster 3 否 110000 250000 kafka.4u8g.cluster 3 否 135000 380000 kafka.8u16g.cluster 3 否 213000 480000 kafka.12u24g.cluster 3 否 240000 577000 kafka.16u32g.cluster 3 否 280000 840000 结论：在Topic相同的情况下，生产消息到规格相同、磁盘类型不同的Kafka实例，超高I/O的实例TPS高于高I/O的实例TPS。 测试场景五（不同分区数）：相同的实例（超高I/O、3个代理、未开启SASL），不同分区数的Topic，测试结果如下： 表7 测试结果 实例规格 是否同步落盘 是否同步复制 副本数 TPS（3分区） TPS（12分区） TPS（100分区） kafka.2u4g.cluster 否 否 3 250000 260000 250000 kafka.4u8g.cluster 否 否 3 330000 280000 260000 kafka.8u16g.cluster 否 否 3 480000 410000 340000 kafka.12u24g.cluster 否 否 3 570000 750000 520000 kafka.16u32g.cluster 否 否 3 840000 1000000 630000 结论：生产消息到同一个Kafka实例的不同Topic中，Topic除了分区数量，其他参数相同。随着分区数的增加，Kafka的性能通常会随之增加，当分区数达到一定程度后，继续增加分区数可能会导致性能下降。

测试环境 进行TPS测试前，您需要先构建如下的测试环境： 购买如表1所示实例，购买步骤请参考购买Kafka实例。 表1 实例参数 名称 代理数量 规格 是否开启SASL 磁盘类型 kafka-01 3 kafka.2u4g.cluster 是 超高I/O kafka-02 3 kafka.4u8g.cluster 是 超高I/O kafka-03 3 kafka.8u16g.cluster 是 超高I/O kafka-04 3 kafka.12u24g.cluster 是 超高I/O kafka-05 3 kafka.16u32g.cluster 是 超高I/O kafka-06 3 kafka.2u4g.cluster 否 超高I/O kafka-07 3 kafka.4u8g.cluster 否 超高I/O kafka-08 3 kafka.8u16g.cluster 否 超高I/O kafka-09 3 kafka.12u24g.cluster 否 超高I/O kafka-10 3 kafka.16u32g.cluster 否 超高I/O kafka-11 3 kafka.2u4g.cluster 否 高I/O kafka-12 3 kafka.4u8g.cluster 否 高I/O kafka-13 3 kafka.8u16g.cluster 否 高I/O kafka-14 3 kafka.12u24g.cluster 否 高I/O kafka-15 3 kafka.16u32g.cluster 否 高I/O 购买完成后，在实例详情页获取Kafka实例的内网明文连接地址。 购买实例后，创建如表2所示Topic，创建步骤请参考创建Kafka Topic。 表2 Topic参数 名称 是否同步复制 是否同步落盘 副本数 分区数 topic-01 否 否 3 30 topic-02 是 否 3 30 topic-03 否 是 3 30 topic-04 否 否 3 3 topic-05 否 否 3 12 topic-06 否 否 3 100 获取测试工具。 获取Kafka命令行工具2.7.2版本。 购买客户端服务器。 购买1台E CS 服务器（区域、可用区、虚拟私有云、子网、安全组与Kafka实例保持一致，Linux系统），具体步骤请参考购买弹性云服务器。 购买完成ECS后，需要在ECS中完成以下配置： 安装Java JDK，并配置JAVA_HOME与PATH环境变量。 export JAVA_HOME=/root/jdk1.8.0_231 export PATH=$JAVA_HOME/bin:$PATH 下载Kafka命令行工具2.7.2版本，并解压。 tar -zxf kafka_2.12-2.7.2.tgz

DevOps敏捷测试之道 本文主要以华为云的演变历程为案例，从工具角度为大家简要讲解敏捷转型过程中测试人员及测试团队都会经历哪些转变。 在2008年左右的时候，华为的项目还是采用传统的交付方式，例如在年初开始一个项目，在项目立项之初就会把客户的需求全部收集好，包括一些用户的反馈，并把需求做了全年的排序。年中的时候发布产品给用户，两个月之后再出一个补丁，最终年底出一个正式的版本。当时版本交付的节奏还是比较慢的，但是对质量要求比较强。因为产品发布给客户以后，下一个补丁需要两个月，如果用户在这个期间发现产品问题，他们只能再等两个月，而在这期间如果用户不接受我们的产品，会导致项目前功尽弃，所以就对产品的质量有严格的要求。 在2008年到2011年期间，产品逐渐向敏捷方向发展，这时有一部分研发工具平台已经陆陆续续转到云上去了，一些测试类的工具也需要转型。之前产品的交付是半年、两个月发一次，转型之后变成一个月，甚至两周发一次，但这时的转变并不彻底，与客户的交付过程仍然存在一些问题。 在2011年到2014年，华为全面把工具向平台化、服务化方向转型，这个时候一些商业模式才发生了根本性的变化，也就是说当需求上云了以后，用户才更加快速的介入进来。以前的项目是，每年年初接一次需求，而上云之后是时刻反馈需求，基于云平台，把一些功能快速的开发出来，然后频繁的和用户去商量，听取客户意见，牵引产品做快速迭代，这种交付方法使得交付周期一下变快了，之前是半年交付一次，现在是一周、两周，更有甚者，可能一两天就把功能发布出去了。从需求的角度来说发生了巨大变化，基本做到了小步快跑，快速试错。 需求变化了，产品的架构也发生了变化。CS的时候产品是单点的架构，后来慢慢转型到了SOA，到现在微服务的架构。第一轮敏捷升级，华为把业务部门和研发部门合到一起，在DevOps微服务转型的时候，把运营和运维合到一起。 然而需求变化了，架构变化了，团队也变了，这就导致了项目在过程中遗留了很多债务。从测试角度来说，这些债务主要有这么几类。第一类就是人。团队和个人、各个角色对测试的意识是不同的。比如说全功能团队对开发很重视，因为项目必须要交付产品，但是对测试方面不重视。所以测试人员自己会觉得是否自身发展到了瓶颈，没有办法再朝着测试的方向继续发展。测试人员最开始有些专项的能力，包括行动可靠性等等，他们会写一些自动化的脚本，拥有一些自动化的能力，但是在转型的过程中，他们会面临一些自动化的开发工具，需要对接自动化平台，需要有一定的开发能力，这对测试人员的自身素质提出了更高的要求。而对开发人员来说，首先是质量意识不足，第二是对于大部分开发人员来说白盒测试用例会写，但是黑盒测试用例不会写。另一方面开发在转型的过程中往往忽视了敏捷价值观，他们的思想还停留在传统的开发思想，开发做开发的事，质量跟我无关。这些其实并不是技能的问题，更多的还是思想意识上的欠缺。除了人的意识之外，前面还提到了技能意识，流程意识，例如过度依赖黑盒功能测试，我们在流程里面对测试的保障就是依赖黑盒子，结果测试、前端的UI测试，认为做到这些就能保证质量。还有一些问题，例如迭代速度很快，测试时间留得很少，所有工作量的评估只评估开发完的事情，没有评估从开发到测试，乃至上线的时间点。环境本身也有问题，测试环境部署时间比较长，测试人员在α、β生产各个节点上面做部署，然后做验证，使得部署耗费了很多时间。 下面让我们再看看测试，测试最重要的是要做什么。这里有两个关键的焦点： 第一点，测试就是一个质量活动，做测试就是要保证质量。 第二点，业务价值。测试要围绕业务价值去做，而不是说一个测试上来之后，就把测试相关的关系点、关联点全部做一遍。 让我们来看几个例子：例如现在正在做一个线上支付的功能，对这个功能最关心的方面肯定是安全，所以相关的测试用例关键点就应该围绕安全大做文章，一定把安全保证好。再比如，现在要做一个线上商城，面向用户是老百姓，不仅要让年轻人会用，也要让妈妈、婆婆都会用，那么就要关注易用性。除此之外，在双十一、双十二要举办促销活动，那就还需要关注性能。所以测试也要求瞄准了产品本身的业务价值，确定产品的目标，相应的制定质量关键点，制订相关的测试策略，然后实践落地。落地之后还要基于一些不良的效果不断的进行反馈、循环，校验整体的测试过程是否达到预期结果。这就是我们的测试焦点。 自动化测试金字塔 从这个金字塔可以看出在测试方面每一个环节的自动化能力和投入，在最底层单元测试方面，这个金字塔不代表测试用例的数量，而更应该关心单元测试的质量。例如项目中有一个非常重要的模块，要保证重要模块对应的覆盖率要达到标准。所以单元测试的重点不是在用例的数量上，一定要关心它本身的质量。在金字塔越底层做的事情，发现问题并将其解决的成本越低。而越向上一层，解决成本越高，效率也会越低。例如在界面测试层面发现了问题，对问题的定位要从界面到网络、模块A、模块B等等，需要涉及很多工作人员做问题定位。如果在单元测试层面发现问题，那么就是模块本身的问题了。对于金字塔里面所有基于代码、到单元测试、接口测试、界面测试、UI，还要尽量做到自动化。提交一行代码，能够自动把整个测试流程走遍，出去喝一杯咖啡之后，回来看到所有的测试结果在开发者眼前呈现。 常规安全与弹性安全 在我们常规的设想中，通常是哪个地方不安全，就一定要把所有不安全的因素找出来，清除掉。这是常规的做法，也就是Safety-Ⅰ的小天平，指针在绿色一边是安全，在红色一边不安全。第一个做法是把不安全的红色因素一一剔除，这是一种非常理想的方法，但在实际工作中是不可能把整个系统中不安全的因子全部识别到的，这其中涉及能力、架构等各方面的原因。因而在此基础上演变出了弹性安全，就是通过场景模拟的方式将不安全因素尽量展现出来，从而基于这种不安全场景，给出快速的修复方案弥补这个不安全因素，从用户角度来讲是感知不到的。从产品来讲，它的商业目的和质量目的都可以达到，这就是所谓的弹性安全，即便发生了错误，能够及时快速的修复漏洞或者自我修复，达到正常工作的目的。 测试左移和测试右移 左移就是前移，尽量把活动向前移。例如BDD行为开发，基于场景直接设计出符合这个场景的用例，来匹配这个设计；契约测试，服务和服务本身之间有耦合，我们可以通过契约测试解耦，以防导致问题。 测试右移是指要把测试活动的覆盖范围尽量向后蔓延。我们现在的测试只进行到了版本发布之前，测好之后发布一个软件包，而测试右移就要求我们要把软件包发布到生产环境，以及到线上运营环节，都要去做测试。 在这两个方面也有一些相应的实践，例如线上拨测，主动线上监控用户的一些行为，并从行为轨迹里面快速捕捉相应的问题，主动推送给相关的责任人，让他去关注并且解决。所以线上的过程可以通过一些测试手段，不断的反馈给真正的开发人员，让他知道当前产品的整体表现，开发人员就会快速的针对产品作出应对方案。 不同时期的测试策略 前面讲了这么多的测试活动，那么是否这个团队组建之初，就要把整个自动化测试的能力构建起来呢？其实这也是一个过程，下面从软件的成熟周期的角度，看一下如何构建测试自动化的能力。 在软件初期探索阶段，产品是一个不确定的状态，从前端的风格和整体的布局到后端的API都时刻在变化当中，而且变化比较频繁，因为自动化用例的生命周期比较短，所以在这个时候创建一些自动化测试用例是不太划算的。而这个时间段产品，往往特性是可控制的，只有几个测试，所以可以以手动为主，不考虑自动化，让产品能够快速识别错误点，让用户能用起来。 到了产品扩张阶段，用户认可产品，这时候会出现两个现象。第一是用户量增长，第二是需求数量增长。这时候必须要考虑自动化。因为在这个阶段每一次迭代的全量验证成本会越来越大，而交付的速度也会越来越快。我们不可能每一轮上线的时候都做全部的测试，这时候旧的模块就需要自动化用例去保证。 到提取阶段，产品已经到了需求的饱和期，产品的利益增长也到了饱和期，这时候要严格控制产品需求，自动化用例的职责变成守护，不允许变动引入额外的风险点、大的特性变动，导致对成熟的用户造成攻击。 团队规模对测试建设的影响 如果说团队规模在5个人以下，团队处于探索阶段，这时质量活动可以仅仅局限于测试的自组织阶段，只是做一些基础类测试管理活动，把缺陷管理起来，做一些回归测试。在这个阶段主要是建立一个测试管理的流程和机制，并没有接触到自动化测试。 随着项目的进一步扩大，逐渐增长到5-10人的团队规模，这时测试工作量突然增加，可能会有专门的测试人员进来，这个测试人员就会去和开发人员进行串联，把需求转化成自动化测试的用例，搭建持续集成，逐步演进一些测试手段。这个阶段已经开始做一些自动化的尝试。 团队进一步增大，一个人可能搞不定工作量的时候，会招聘更多的测试人员，成立专门的测试团队，这个团队就从自动化测试转向测试自动化，把更多的管理工作做进来。在这个管理过程中，我们会做一些产品的对接，包括开发专门的工具，实现自动化的整体能力，不仅仅是自动化执行了。 经过上面几个演进周期之后，测试团队具备了很多的测试自动化经验，这个时候可以进行面向云化的转型，现在很多团队都在进行DevOps转型，最关心的方面就是组建DevOps的全功能团队。那么之前转型的这些人在做什么？原有10-15人的测试专项团队做什么？在这个阶段团队要把测试专项能力向服务化能力转型。这时候测试专员就会在团队创建初期进行赋能，包括测试工程搭建，早期的测试用例怎么写，标准化模板的编制，针对非功能性测试的专项能力的赋能，所有团队进行测试流程的评审，包括测试策略、测试计划、测试用例的评审，再看一下整个团队里面流程上还有哪些改进的。从各个方面整个专项测试团队向服务化进行转型，帮助所有团队完成自动化转型。 在这里要澄清一个理念，就是测试自动化。测试自动化的目的是减少手工测试和手工操作。测试自动化不仅仅包括自动化测试执行，还包括其他所有可以减人力投入的活动，例如自动化环境创建、自动化部署、自动化监控、自动化数据分析等。刚才讲了很多自动化测试，这是测试的执行部分，例如把一些测试执行的人工测试手段做成自动化测试，但是测试自动化不仅仅是只是执行，还包括了从环境的获取到生成测试数据、执行自动化测试，最终生成结果。如果有问题，会自动推送给相关的人，对应的组织解决。自动生成测试报告，测试人员直接拿到测试结果。 契约测试的价值 团队之间一定要引入契约测试，这描述起来比较简单，它既是一种测试技术，也是一种测试规范。例如有两个服务分别是服务A和服务B，服务A依赖服务B的结构。这时签订一个契约，服务A基于这个Mock开发自己的业务逻辑，服务B基于测试来保证给A提供的结构是可用的，最终两个服务可以独立上线，A和B可以做远调。这就好像我们生活中的螺母和螺丝，它们分别由A和B厂商制造，但是他们会遵循一些契约，保证螺丝的长度、宽度、对应的型号和间距都会对应标准，最终两个厂商生产的螺丝和螺母能够正常工作，严丝合缝的合在一起。这就是契约测试的价值。 下面我们来看看在CodeArts中的几个实践。针对CodeArts，团队内部有几个专项的试点。第一是视角，测试本身不仅仅是某个细节功能点的测试，还要基于场景做测试用例，而且在必要的情况下，会有一些专门的人去对这些场景做手工测试，检验是否有问题。CodeArts本身就是打造开发者一站式的云上开发平台，提供整套的工具链，所以CodeArts团队内部追寻的DevOps下的开发实践就是狗粮文化，自己的狗粮自己吃，所有的测试活动、软件开发活动都在CodeArts里面进行，这样开发人员既是开发人员又是测试人员，他自己的思维会一直在转变，不断的打磨自己的产品，最终使产品精益求精。还有一个实践是分层自动化，CodeArts团队把所有的自动化专项流程打散，放到流水线里面，在编码或者再向前的环节，做一些安全的分析，在编码过程中做编码检视，还有单元测试用例来保证单元测试本身的用例指标。在后面的阶段，还有华为云的代码静态检查，会预先识别代码里面的规范，包括隐含的内存，通过对语句的分析能够找到问题，进行拦截。在部署到Alpha、Beta测试阶段，用CodeArts的 API服务 构造一些针对可靠性和安全的测试用例。针对生产环境的在线测试，进行在线拨测，还有后台的主动检测手段，包括前端、后端接口的检测。以及用户业务流下面关键分支上的日志，有异常日志要记录下来，然后基于日志进行分析，这些在使用过程中也会给我们进行一些质量的反馈。 最后，简单介绍一下华为云的测试服务。华为云的测试服务最开始是对内部的，有很多的测试工具。做到一定程度，也积累了很多的测试经验之后，对外发布了一些比较好的实践所带来的工具，例如现在已经上线的CodeArts的测试计划和 移动应用测试 以及解决方案，包括整体测试流程管理、测试的用例和需求双向可追溯，能够看到这个需求的测试状态；提供相应的自动化的能力，例如对安卓和IOS的测试，将软件包放在后台，对它进行系统化的兼容性测试，检测是否有兼容性的问题，能够涵概多少用户；接口测试，能够涵盖接口一层的自动化测试，APITest可以让开发人员投入到写测试用例，你可以通过鼠标加一些必要的参数进行编排，可以通过接口把场景构造出来；性能测试，模拟一些大并发的场景，会提供多种加压策略，能够实现在测试过程中对于用户的吞吐量、响应时间、负载能力，进行整体的分析。测试总览还提供完全可视化的看板，能够提供测试用例执行的情况汇总，帮助团队迅速掌握当前项目的需求和用例执行情况。 小结：本文结合华为云CodeArts团队内部近几年的测试能力发展的角度简单剖析了项目团队在DevOps转型过程中会遇到的问题，以及需要提升的能力。希望通过本文的解读能为各位在DevOps转型中迷失的从事测试工作的朋友们带来一定的启发。 父主题： 持续测试与反馈

测试步骤 创建Redis缓存实例。 创建3台弹性云服务器（ECS），ECS选择与实例相同可用区、VPC、子网和安全组。 如果是测试单机或主备实例，创建1台ECS即可。 在每台ECS上安装redis-benchmark。可通过以下两种方式安装Redis-server，安装Redis-server的同时，会同步安装benchmark。 安装方法一： 下载redis客户端，此处以redis-6.0.9版本为例。 wget http://download.redis.io/releases/redis-6.0.9.tar.gz 解压客户端压缩包。 tar xzf redis-6.0.9.tar.gz 进入redis-6.0.9的src目录下。 cd redis-6.0.9/src 编译源码。 make 编译完成后，工具一般在redis-x.x.x的src目录下。 查看是否有redis-benchmark可执行文件。 ls 将工具安装到系统中。 make install 安装方法二： 根据ECS的不同的操作系统直接安装Redis-server，下面以ubuntu和CentOS系统为例： ubuntu系统 sudo apt update sudo apt install redis-server CentOS系统 sudo yum install epel-release sudo yum update sudo yum -y install redis 每台ECS上执行测试命令。 redis-benchmark -h {IP} -p {Port} -a {password} -n {nreqs} -r {randomkeys} -c {connect_number} -d {datasize} -t {command} 参数参考值：-c {connect_number}：200，-n {nreqs}：10000000，-r {randomkeys}：1000000，-d {datasize}：32。 -h表示实例的 域名 连接地址或IP地址。 -p表示实例的端口，默认为6379。 -a表示实例的连接密码，免密连接的实例无需输入-a {password}。 -t表示执行具体测试命令合集。例如只测试set命令时，使用-t set；如果要测试ping、get、set命令，则使用 -t ping,set,get，命令间使用“,”分隔。 -c表示客户端连接数。 -d表示单条数据大小，单位Byte。 -n表示测试包数量。 -r表示使用随机key数量。 不断调整客户端连接数，执行4，得到最大的QPS（Query Per Second，表示每秒处理的读写操作数，单位：次/秒）。 取3台测试ECS得到的每秒操作数总和，即为对应规格的性能数据。 如果测试Redis集群，建议每台测试ECS各开启两个benchmark客户端。 redis-benchmark 测试cluster集群实例时需要加 --cluster 参数，其他实例类型不需要加。 如果想对cluster集群的最大连接数进行性能压测，但是压测到1万连接时程序退出，或者报错 Cannot assign requested address。这说明是测试用的ECS本机性能不足，请先检查自己是否只用了1台ECS进行压测。想要对集群压测，建议准备3台ECS，每台ECS起3个redis-benchmark来测试redis实例的最大连接数。

redis-benchmark常用命令举例 单机、主备、读写分离和proxy集群的测试命令： ./redis-benchmark -h {IP或域名} -p 6379 -a {password} --threads {num} -n { nreqs } -r { randomkeys } -c {clients} -d {datasize} -t {command} cluster集群测试命令： ./redis-benchmark -h {IP或域名} -p 6379 -a {password} --threads {num} -n { nreqs } -r { randomkeys } -c {clients} -d {datasize} --cluster -t {command} 测试短连接： ./redis-benchmark -h {IP或域名} -p 6379 -a {password} --threads {num} -n { nreqs } -r { randomkeys } -c {clients} -d {datasize} -k 0 -t {command} 测试空闲连接： ./redis-benchmark -h {IP或域名} -p 6379 -a {pwd} -c {clients} -I

redis-cli常用命令举例 连接实例： ./redis-cli -h {IP} -p 6379 指定连接某个DB： ./redis-cli -h {IP} -p 6379 -n 10 连接cluster集群实例： ./redis-cli -h {IP} -p 6379 -c 测试时延（原理是发ping命令）： ./redis-cli -h {IP} -p 6379 --latency 执行scan扫描匹配指定模式的key： ./redis-cli -h {IP} -p 6379 --scan --pattern '*:12345*'

在线拨测按需 表2 在线拨测按需增值特性 计费方式 按需 适用场景 测试计划服务提供了在线拨测能力，提供7*24小时现网拨测，支持告警，实时看护及主动拨测式应用检测。 计费项 次数 购买限制 开通在线拨测按需，须完成CodeArts基础版及以上规格套餐或CodeArts TestPlan套餐的购买，购买的套餐到期后，在线拨测按需将无法继续使用。 计费公式 单价*次数。 计费场景 根据在线拨测的调用次数进行计费。计费的起点是您开通在线拨测按需的时间，终点则是到您关闭按需的时间，每天整点结算一次费用。 购买须知 当超出在线拨测按需套餐包的配额产生的用量，将自动转为按需付费。 当用户的账户余额不足以抵扣产生的按需费用，在线拨测功能将无法正常使用。 在线拨测按需套餐包不支持即时变更，支持关闭按需。