API ტესტირება: Postman/Newman
1) რატომ Postman/Newman
Postman არის მოსახერხებელი IDE სკრიპტებისა და მოთხოვნის კოლექციებისთვის. Newman არის CLI ძრავა, რომელიც იწყებს იმავე კოლექციებს GUI- ს გარეშე CI/CD- ში. ერთად ისინი აძლევენ:- განმეორებითი რეგრესები და სწრაფი ტუმბოები;
- გარემოს/საიდუმლოებების პარამეტრიზაცია;
- ხარისხის მეტრიკა და მანქანების წაკითხული ცნობები.
2) ბაზის მოდელი
კოლექცია არის შეკითხვის ხე და საქაღალდეები საერთო სკრიპტებით.
გარემო - ნაკრები '{{vars}}' dev/stage/URL (URL, გასაღებები).
Pre-request script - მომზადება: ხელმოწერები, ნიშნები, მონაცემთა კორელაცია.
Tests - ცვლადი/არტეფაქტების განცხადებები და შენარჩუნება.
Data files - CSV/JSON მონაცემთა წამყვანი პროგონისთვის.
Mock/Monitor - სტაბილური და პერიოდული შემოწმება.
<API v1>
├─ _bootstrap (auth, health, seeds)
├─ Public
├─ Authenticated
│ ├─ Accounts
│ ├─ Payments
│ └─ Reports
└─ _teardown (cleanup)
3) ცვლადი და საიდუმლოებები
უწოდეთ ცვლადების აშკარა პრეფიქსი: 'baseUrl', 'tenant', 'clientId'.
შეინახეთ საიდუმლოებები (პაროლები, client _ secret, HMAC გასაღებები) CI გარემოში ცვლადი, ნუ დაუკავშირდებით საცავებში.
გამოიყენეთ შეკუმშვა: ადგილობრივი შეგროვება - environment globals (მინიმალური შესაძლო).
json
{
"name": "stage-eu",
"values": [
{"key":"baseUrl","value":"https://api. stage. example. com","type":"text","enabled":true},
{"key":"tenant","value":"eu-1","type":"text","enabled":true}
]
}
4) ავთენტიფიკაცია: შაბლონები
4. 1 OAuth2/OIDC (Client Credentials)
Pre-request:js if (!pm.environment. get("access_token") Date. now() > pm. environment. get("token_exp")) {
pm. sendRequest({
url: pm. environment. get("authUrl"),
method: 'POST',
header: {'Content-Type':'application/x-www-form-urlencoded'},
body: { mode:'urlencoded', urlencoded:[
{key:'grant_type',value:'client_credentials'},
{key:'client_id',value:pm. environment. get('clientId')},
{key:'client_secret',value:pm. environment. get('clientSecret')},
{key:'scope',value:'payments:read payments:write'}
]}
}, (err, res) => {
pm. environment. set("access_token", res. json(). access_token);
pm. environment. set("token_exp", Date. now()+ (res. json(). expires_in-30)1000);
});
}
თხოვნით: 'Authorization: Bearer {access _ token}'.
4. 2 HMAC (ვებჰუკი/პარტნიორები)
Pre-request:js const body = pm. request. body? pm. request. body. raw '': '';
const ts = Math. floor(Date. now()/1000);
const msg = `${ts}.${body}`;
const sig = CryptoJS. HmacSHA256(msg, pm. environment. get('hmacSecret')). toString();
pm. variables. set('ts', ts);
pm. variables. set('sig', sig);
სათაურები: 'X-Timestamp: {ts}', 'X-Signature: {{sig}'.
5) ტესტები: განცხადებები და კორელაცია
გამოიყენეთ 'pm. expect(...)` и `pm. test("...", fn)`.
შეინარჩუნეთ იდენტიფიკატორები შემდგომი ნაბიჯებისთვის 'pm. collectionVariables. set`.
js pm. test("HTTP 200", () => pm. response. to. have. status(200));
pm. test ("Scheme is valid," () => {
const schema = pm. collectionVariables. get("schema_wallet");
pm. expect(tv4. validate(pm. response. json(), JSON. parse(schema))). to. be. true;
});
pm. test ("Contains id," () => {
const id = pm. response. json(). id;
pm. expect(id). to. be. a('string');
pm. collectionVariables. set("wallet_id", id);
});
6) სქემის შესაბამისობა (OpenAPI/JSON Schema)
შეინახეთ JSON Schema კოლექციის ცვლაში ან ცალკეულ ფაილში.
OpenAPI- სთვის: გამოიყენეთ მზა ლიბიები pre-request/test (ajv, tv4) - 'pm მეშვეობით. sendRequest 'raw ფაილი ან JSON inline.
js pm. collectionVariables. set("schema_wallet", JSON. stringify({
"type":"object",
"required":["id","currency","balance"],
"properties":{
"id":{"type":"string"},
"currency":{"type":"string","pattern":"^[A-Z]{3}$"},
"balance":{"type":"number","minimum":0}
}
}));
7) მონაცემთა წამყვანი სცენარი
CSV:
email, password, currency u1@example. com, P@ss1, EUR u2@example. com, P@ss2, USD
თხოვნა იყენებს '{e email}}', '{currency}'.
გაშვება:
newman run collection. json -e stage-eu. json -d users. csv
JSON (ობიექტების მასივი) მოსახერხებელია რთული შემთხვევების/სტრუქტურებისთვის.
8) უარყოფითი შემთხვევები და სტაბილურობა
დაფარეთ:- 401/403 (ნიშნის გარეშე/არასწორი სკოპი/როლი).
- 400/422 (სქემის შესაბამისობა, სავალდებულო ველები, საზღვრები).
- 404 (BOLA/სხვისი რესურსი).
- 409 (კონფლიქტები, იდემპოტენტური გასაღებები).
- 429 (ლიმიტები) - შეამოწმეთ 'Retry-After'.
- 5xx არის კლიენტის სწორი დეგრადაცია და რეტრაჟი.
js pm. test ("There is Retry-After at 429," () => {
if (pm. response. code === 429) pm. expect(pm. response. headers. has('Retry-After')). to. be. true;
});
9) Idempotence, retrai, pagination
გადაიტანეთ 'Idempotency-Key' და დარწმუნდით, რომ გამეორება იძლევა იგივე 'id/status'.
შეამოწმეთ პაგინაცია: 'limit/offset '/' cursor', დუბლიკატების და პასაჟების დეტალი.
Test სკრიპტში რეაგირების იმიტაცია: თანმიმდევრული გამოწვევები იმავე კლავიშით.
js pm. test ("Idempotent repetition," () => {
pm. sendRequest(pm. request, (err, res2) => {
pm. expect(res2. code). to. eql(pm. response. code);
pm. expect(res2. json(). id). to. eql(pm. response. json(). id);
});
});
10) Newman в CI/CD
10. 1 გაშვება
newman run collection. json \
-e stage-eu. json \
-d data. csv \
--timeout-request 30000 \
--reporters cli,htmlextra,junit \
--reporter-htmlextra-export./reports/report. html \
--reporter-junit-export./reports/junit. xml
10. 2 GitHub Actions (ფრაგმენტი)
yaml
- uses: actions/setup-node@v4 with: { node-version: '20' }
- run: npm i -g newman newman-reporter-htmlextra
- run: newman run collection. json -e stage-eu. json --reporters cli,junit --reporter-junit-export reports/junit. xml
- uses: actions/upload-artifact@v4 with: { name: newman-reports, path: reports }
10. 3 Jenkins/GitLab CI
ექსპორტზე JUnit ('-reporter-junit-export') მშობლიური ვიზუალიზაციისთვის.
Paypline- ში გაიზიარეთ ჯობი: smoke (სწრაფი), regression (სრული), უსაფრთხოება (უარყოფითი/საზღვრები).
10. 4 Docker
docker run --rm -v $PWD:/etc/newman postman/newman \
run collection. json -e stage-eu. json
11) მოკი და მონიტორინგი
Mock servers Postman არის სწრაფი სტაბილურობა წინა და კონტრაქტებისთვის.
Monitors არის პერიოდული ღრუბლისგან ნაყარი (latency, 5xx, SSL).
საცავებში შეინახეთ პასუხების მაგალითები დეტერმინის ხიდებისთვის.
12) ტესტის მონაცემები და დასუფთავება
შექმენით/ამოიღეთ არსებები (_ bootstrap/_ teardown).
ჩაანაცვლეთ სატესტო ობიექტები პრეფიქსი „e2e _“ და TTL.
js pm. collectionVariables. set("uniq", Date. now()+"_"+Math. floor(Math. random()1e6));
13) პროდუქტიულობა „მუხლებზე“
Postman არ არის დატვირთული ინსტრუმენტი, არამედ:- გაზომეთ 'pm. response. responseTime`;
- გაატარეთ 5-10 გამეორება და დააფიქსირეთ r95/ბარიერი;
- მძიმე სპექტაკლები - JMeter/k6/Gatling (ამ სტატიის მიღმა).
14) ლოკალიზაცია და მრავალფეროვნება
ცვლადი 'tenant', 'region', 'lang'; გადაინაცვლეთ გარემოში.
ტესტებმა უნდა შეამოწმოს, რომ მონაცემები არ „მიედინება“ ტენანტებს შორის (BOLA-read, ჯვარედინი აკრძალვები).
ცალკეული კოლექციები/საქაღალდეები რეგიონალურ მახასიათებლებზე (შეზღუდვები, ვალუტები).
15) მოხსენებები და არტეფაქტები
შეინახეთ CI ნივთები: HTML რეპორტები, 'junit. xml ', წარუმატებელი პასუხების ლოგები.
დააკავშირეთ Slack/Teams შეტყობინებები პუნქციის ვარდნის შესახებ.
16) ხარისხი და საფარი
საფარის მატრიცა:- CRUD პერის რესურსი (200/201/204 + უარყოფითი).
- ავტორიზაცია: როლები/სკუპები/მულტფილმი-ტენანტი.
- პაგინაცია/ფილტრები/დახარისხება.
- Idempotence და retrai.
- ლიმიტები: 413/414/431/429.
- ფორმატები და სქემები (JSON Schema/OpenAPI).
- ინტეგრაცია (ვებჰუკები HMAC/mTLS) - anti-replay.
17) ანტიპატერები
ერთი „ბედნიერი გზა“ უარყოფითი ტესტების გარეშე.
გრძელი ნიშნები კოლექციაში/საცავებში.
ტესტის მონაცემების შერევა პროტო მონაცემებთან.
ტესტის პროცედურის ფარული დამოკიდებულება აშკარა კორელაციის გარეშე.
გიგანტური მონაცემთა ფილები ნიმუშის გარეშე.
JUnit/HTML ანგარიშების არარსებობა CI- ში არ ჩანს.
18) მზადყოფნის ჩეკის სია
- კოლექციები იყოფა დომენებად, არის '_ bootstrap/_ teardown'.
- გარემო dev/stage/country; საიდუმლოებები CI საიდუმლო საცავიდან.
- Pre-request для auth (OAuth2/HMAC); ნიშნები იშლება და იჭრება.
- ტესტები: პოზიტიური + ნეგატივი, სქემები (JSON Schema), პაგინაცია, 429/Retry-After.
- Idempotence: შემოწმება 'Idempotency-Key ", ორმაგი ზარი ექვივალენტურია.
- მონაცემთა დისკი CSV/JSON, შემთხვევითი სუფიქსები უნიკალურობისთვის.
- Newman in CI: JUnit/HTML მოხსენებები, არტეფაქტები, როგორიცაა build outputs.
- მოკი/მონიტორები საკვანძო მარშრუტებისთვის; SLA პუნქცია.
- დოკუმენტაცია ცვლადი, ჭდეები და გაშვების წესი.
19) TL; DR
შეინახეთ ტესტის ლოგიკა Postman- ის კოლექციებში, პარამეტრები - წრეებში და გაიკეთეთ CI- ში Newman- ის საშუალებით JUnit/HTML ანგარიშებით. დაფარეთ უარყოფითი მხარეები, სქემები, იდემპოტენტობა, პაგინაცია და ლიმიტები. დაუკავშირეთ ნაბიჯები ცვლადი, გამოიყენეთ მონაცემთა წამყვანი შეყვანა და პარკები/მონიტორები. საიდუმლოებები - მხოლოდ CI- დან, მოხსენებები - ბილეთის ნივთები.