tencent cloud

Tencent Cloud Observability Platform

Release Notes and Announcements
Release Notes
Product Introduction
Overview
Strengths
Basic Features
Basic Concepts
Use Cases
Use Limits
Purchase Guide
Tencent Cloud Product Monitoring
Application Performance Management
Mobile App Performance Monitoring
Real User Monitoring
Cloud Automated Testing
Prometheus Monitoring
Grafana
EventBridge
PTS
Quick Start
Monitoring Overview
Instance Group
Tencent Cloud Product Monitoring
Application Performance Management
Real User Monitoring
Cloud Automated Testing
Performance Testing Service
Prometheus Getting Started
Grafana
Dashboard Creation
EventBridge
Alarm Service
Cloud Product Monitoring
Tencent Cloud Service Metrics
Operation Guide
CVM Agents
Cloud Product Monitoring Integration with Grafana
Troubleshooting
Practical Tutorial
Application Performance Management
Product Introduction
Access Guide
Operation Guide
Practical Tutorial
Parameter Information
FAQs
Mobile App Performance Monitoring
Overview
Operation Guide
Access Guide
Practical Tutorial
Tencent Cloud Real User Monitoring
Product Introduction
Operation Guide
Connection Guide
FAQs
Cloud Automated Testing
Product Introduction
Operation Guide
FAQs
Performance Testing Service
Overview
Operation Guide
Practice Tutorial
JavaScript API List
FAQs
Prometheus Monitoring
Product Introduction
Access Guide
Operation Guide
Practical Tutorial
Terraform
FAQs
Grafana
Product Introduction
Operation Guide
Guide on Grafana Common Features
FAQs
Dashboard
Overview
Operation Guide
Alarm Management
Console Operation Guide
Troubleshooting
FAQs
EventBridge
Product Introduction
Operation Guide
Practical Tutorial
FAQs
Report Management
FAQs
General
Alarm Service
Concepts
Monitoring Charts
CVM Agents
Dynamic Alarm Threshold
CM Connection to Grafana
Documentation Guide
Related Agreements
Application Performance Management Service Level Agreement
APM Privacy Policy
APM Data Processing And Security Agreement
RUM Service Level Agreement
Mobile Performance Monitoring Service Level Agreement
Cloud Automated Testing Service Level Agreement
Prometheus Service Level Agreement
TCMG Service Level Agreements
PTS Service Level Agreement
PTS Use Limits
Cloud Monitor Service Level Agreement
API Documentation
History
Introduction
API Category
Making API Requests
Monitoring Data Query APIs
Alarm APIs
Legacy Alert APIs
Notification Template APIs
TMP APIs
Grafana Service APIs
Event Center APIs
TencentCloud Managed Service for Prometheus APIs
Monitoring APIs
Data Types
Error Codes
Glossary

Script Overview

PDF
フォーカスモード
フォントサイズ
最終更新日: 2025-03-10 22:14:18
PTS is compatible with JavaScript ES2015 (ES6)+ syntax and provides additional functions to help you quickly orchestrate performance testing scenarios in script mode.
You can describe the request orchestration, variable definition, result assertion, common functions, and other logic required for your performance testing scenario by using JavaScript code in the online editor of the console. For detailed API documentation, see PTS API.
PTS also provides various types of script templates (such as common usage of various protocols and some common functions) in Sample Templates for Common Scripts on the right side of the script editor in the console for your reference to write your own scripts.

Script Structure

A PTS scenario script can consist of importing dependency modules, defining global variables, defining global Options, defining functions, and defining checkpoints. For detailed script content, see the following section.

Importing Dependency Modules

After importing the required modules, you can use the APIs in the modules.
import http from 'pts/http';
import { check, sleep } from 'pts';

Defining Global Variables

If global variables are needed, they can be defined outside the functions. For example:
const globalVar = "var"
const globalObj = {
"k": "v",
}

export default function () {
console.log(globalVar); // var
console.log(globalObj.k); // v
};

Defining Global Options

You can control the default behavior of the engine through global Options.
export const option = {
http: {
http2: true,
maxIdleConns: 50,
basicAuth: {
username: 'user',
password: 'passwd',
}
},
tlsConfig: {
'localhost': {
insecureSkipVerify: false,
//Users need to upload the request file ca.crt in the scenario.
rootCAs: [open('ca.crt')],
//Users need to upload the request files client.crt and client.key in the scenario.
certificates: [{cert: open('client.crt'), key: open('client.key')}]
}
}
}

Defining Functions

The logic executed by each concurrent user (VU) in each iteration is defined in the main function (default function).
In addition to the main functions, you can also define the preprocessing (setup) and post-processing (teardown) functions, as shown below:
The preprocessing function runs once after each performance testing starts.
The post-processing function runs once before each performance testing ends.
// Global variable, which is defined outside the function.
const global = { stage: "global" };

// Use the setup function for preprocessing to return custom key-value pairs.
export function setup() {
return { stage: "setup" };
}

// Main function (input parameters can receive key-value pairs returned by the setup function).
export default function(data) {
console.log(JSON.stringify(global)); // {"stage":"global"}
console.log(JSON.stringify(data)); // {"stage":"setup"}
}

// Use the teardown function for post-processing.
export function teardown(data) {
console.log(JSON.stringify(global)); // {"stage":"global"}
console.log(JSON.stringify(data)); // {"stage":"setup"}
}

Defining Checkpoints

You can determine whether a request is successful from a business perspective by configuring checkpoints.
import http from 'pts/http';
import { check } from 'pts';

export default function () {
// get request with headers and parameters
const resp1 = http.get('http://httpbin.org/get', {
headers: {
Connection: 'keep-alive',
'User-Agent': 'pts-engine',
},
query: {
name1: 'value1',
name2: 'value2',
},
});
console.log(resp1.json().args.name1); // 'value1'
check('status is 200', () => resp1.statusCode === 200);
check('body.args.name1 equals value1', () => resp1.json().args.name1 === 'value1');
}

Lifecycle

Preprocessing (setup) and post-processing (teardown) functions: They run once per performance testing machine.
Code for defining global variables: It runs once per VU. Some static file reading and other operations are recommended to be defined in global, so that each concurrency only needs to read the file once. This avoids opening files repeatedly during the scenario iteration.
Code for the main function (default): It runs once per iteration for each VU, and each VU will continuously iterate until it reaches the duration limit or iteration limit configured in the current performance testing.
For example, when there are two VUs on a performance testing machine, the flowchart is as follows:

Note:
For the concept of VU, see FAQs.


ヘルプとサポート

この記事はお役に立ちましたか?

フィードバック