Robot Framework มีแนวทางที่ต่างจากเครื่องมือทดสอบที่เน้นโค้ดเป็นหลัก: คุณเขียน test case เป็นตารางของคีย์เวิร์ดที่อ่านง่าย แทนการเขียนเป็นโปรแกรมเต็มรูปแบบ ทำให้ QA, analyst และ engineer อ่าน ตรวจสอบ และบำรุงรักษาชุดทดสอบเดียวกันได้ สำหรับการทดสอบ API ไลบรารี RequestsLibrary จะเปลี่ยน HTTP request ให้เป็นคีย์เวิร์ด เช่น Create Session, GET On Session และ Status Should Be
คู่มือนี้พาคุณทำ API test automation ด้วย Robot Framework แบบลงมือทำ: ติดตั้งเครื่องมือ เขียน test แรก จัดการ session ตรวจสอบ status code และ JSON response สร้างคีย์เวิร์ดที่ reuse ได้ และเตรียมรันใน CI ตัวอย่างทั้งหมดใช้ไวยากรณ์ .robot ที่นำไปปรับใช้ได้ทันที
Robot Framework คืออะไรและทำไมเหมาะกับการทดสอบ API
Robot Framework เป็น open-source automation framework สำหรับ Test Automation และ Robotic Process Automation จุดเด่นคือ keyword-driven syntax: test case ถูกเขียนเป็นตาราง และพฤติกรรมซับซ้อนถูกประกอบจากคีย์เวิร์ดที่มาจากไลบรารี Python หรือ Java
สำหรับ API testing มีข้อดีหลักสองอย่าง:
- อ่านง่ายสำหรับคนที่ไม่เขียนโค้ดเป็นหลัก
- ขยายได้ด้วยไลบรารี เช่น RequestsLibrary, JSONLibrary, database library และอื่น ๆ
RequestsLibrary ห่อหุ้ม Python requests แล้วเปิดให้เรียกผ่านคีย์เวิร์ด เช่น POST On Session หรือ GET On Session หากยังไม่คุ้นกับแนวคิด keyword-driven framework อ่านเพิ่มเติมได้ในคู่มือ เฟรมเวิร์กการทดสอบอัตโนมัติ
การติดตั้ง Robot Framework และไลบรารีที่จำเป็น
แนะนำให้ติดตั้งใน virtual environment เพื่อแยก dependency ของโปรเจกต์:
python -m venv .venv
source .venv/bin/activate
pip install robotframework
pip install robotframework-requests
pip install robotframework-jsonlibrary
บน Windows ใช้คำสั่ง activate แบบนี้:
.venv\Scripts\activate
แพ็กเกจที่ใช้:
-
robotframework— test runner และ engine หลัก -
robotframework-requests— RequestsLibrary สำหรับ HTTP request -
robotframework-jsonlibrary— ใช้ดึงและตรวจสอบค่าใน JSON response
ตรวจสอบการติดตั้ง:
robot --version
อ้างอิงไวยากรณ์เพิ่มเติมได้จาก Robot Framework User Guide
หมายเหตุสำคัญ: Robot Framework แยก keyword และ argument ด้วยช่องว่างอย่างน้อย 2 ช่อง หากใช้ช่องว่างเดียว parser อาจมองว่าเป็น token เดียวกัน เมื่อ test parse ไม่ผ่าน ให้ตรวจสอบ whitespace ก่อนเสมอ
โครงสร้างไฟล์ .robot
ไฟล์ทดสอบใช้ส่วนขยาย .robot และมักแบ่งเป็นส่วนหลัก ๆ ดังนี้:
*** Settings ***
Library RequestsLibrary
Library Collections
*** Variables ***
${BASE_URL} https://api.example.com/v1
*** Test Cases ***
Get User Returns 200
Create Session api ${BASE_URL}
${response}= GET On Session api /users/42
Status Should Be 200 ${response}
ส่วนที่ใช้บ่อย:
-
*** Settings ***— import library หรือ resource file -
*** Variables ***— เก็บค่า config เช่น base URL -
*** Test Cases ***— เขียน test scenario -
*** Keywords ***— สร้าง reusable keyword
รันไฟล์:
robot tests.robot
หลังรัน Robot Framework จะสร้างไฟล์รายงานโดยอัตโนมัติ:
output.xmllog.htmlreport.html
การเขียน API test แรก
ตัวอย่างนี้ตรวจสอบ endpoint /users/42 ว่าคืน 200 และ response มี field ที่คาดไว้:
*** Settings ***
Library RequestsLibrary
Library Collections
*** Variables ***
${BASE_URL} https://api.example.com/v1
*** Test Cases ***
Get User Returns 200
Create Session api ${BASE_URL}
${response}= GET On Session api /users/42
Status Should Be 200 ${response}
Get User Returns Expected Fields
Create Session api ${BASE_URL}
${response}= GET On Session api /users/42
Status Should Be 200 ${response}
${body}= Set Variable ${response.json()}
Should Be Equal As Integers ${body}[id] 42
Should Be Equal ${body}[status] active
สิ่งที่เกิดขึ้นใน test:
-
Create Sessionสร้าง HTTP session ชื่อapi -
GET On Sessionยิง request ไปยัง path/users/42 -
Status Should Beตรวจสอบ HTTP status code -
${response.json()}แปลง response body เป็น object ที่ตรวจสอบต่อได้ -
Should Be EqualและShould Be Equal As Integersใช้ทำ assertion
การทำงานกับ session และ authentication
Create Session ไม่ได้เก็บแค่ base URL แต่ยังใช้ร่วมกับ headers, cookies และ authentication ได้ เหมาะกับ API ที่ต้อง login ก่อนเรียก endpoint อื่น
ตัวอย่าง login แล้วใช้ token เพื่อสร้าง order:
*** Settings ***
Library RequestsLibrary
Library Collections
*** Variables ***
${BASE_URL} https://api.example.com/v1
*** Test Cases ***
Create Order With Authenticated Session
Create Session api ${BASE_URL}
${login}= POST On Session api /auth/login
... json={"email": "qa@example.com", "password": "test-pass"}
Status Should Be 200 ${login}
${token}= Set Variable ${login.json()}[token]
${headers}= Create Dictionary Authorization=Bearer ${token}
${order}= POST On Session api /orders
... json={"product_id": 7, "quantity": 2}
... headers=${headers}
Status Should Be 201 ${order}
ไวยากรณ์ ... ใช้ต่อ keyword call ไปบรรทัดถัดไป ช่วยให้ request ที่มี body หรือ headers อ่านง่ายขึ้น
ดู keyword เพิ่มเติมได้จากเอกสาร RequestsLibrary
การยืนยัน JSON response
การเช็ก status code เป็นแค่ขั้นแรก สำหรับ API test ที่มีประโยชน์ควรตรวจสอบ response body ด้วย เช่น field สำคัญ, type, ค่า business status หรือข้อมูล nested object
ตัวอย่างใช้ JSONLibrary และ Collections:
*** Settings ***
Library RequestsLibrary
Library JSONLibrary
Library Collections
*** Variables ***
${BASE_URL} https://api.example.com/v1
*** Test Cases ***
Order Response Has Correct Shape
Create Session api ${BASE_URL}
${response}= POST On Session api /orders
... json={"product_id": 7, "quantity": 2}
Status Should Be 201 ${response}
${body}= Set Variable ${response.json()}
Dictionary Should Contain Key ${body} total
Dictionary Should Contain Key ${body} status
Should Be Equal As Integers ${body}[quantity] 2
${status}= Get Value From Json ${body} $.status
Should Be Equal ${status}[0] pending
ใช้ keyword ตามประเภท assertion:
-
Dictionary Should Contain Key— ตรวจว่ามี field ที่ต้องการ -
Should Be Equal As Integers— เปรียบเทียบตัวเลขโดยลดปัญหา type mismatch -
Get Value From Json— ดึงข้อมูลด้วย JSONPath -
Should Be Equal— ตรวจค่า string หรือ value ทั่วไป
สำหรับแนวทาง assertion ที่ควรมีใน API test อ่านเพิ่มได้ที่ การยืนยัน API (API assertions)
การสร้างคีย์เวิร์ดที่นำกลับมาใช้ใหม่ได้
ถ้าทุก test ต้อง Create Session, login และสร้าง headers ซ้ำ ๆ ให้ย้ายขั้นตอนเหล่านั้นไปไว้ใน *** Keywords ***
*** Settings ***
Library RequestsLibrary
Library Collections
*** Variables ***
${BASE_URL} https://api.example.com/v1
${EMAIL} qa@example.com
${PASSWORD} test-pass
*** Keywords ***
Authenticate And Open Session
Create Session api ${BASE_URL}
${login}= POST On Session api /auth/login
... json={"email": "${EMAIL}", "password": "${PASSWORD}"}
Status Should Be 200 ${login}
${token}= Set Variable ${login.json()}[token]
${headers}= Create Dictionary Authorization=Bearer ${token}
Set Suite Variable ${AUTH_HEADERS} ${headers}
*** Test Cases ***
Create Order
Authenticate And Open Session
${order}= POST On Session api /orders
... json={"product_id": 7, "quantity": 2}
... headers=${AUTH_HEADERS}
Status Should Be 201 ${order}
ข้อดี:
- แก้ login flow จุดเดียวเมื่อ API เปลี่ยน
- ลด copy-paste
- ทำให้ test case อ่านเหมือน business workflow
- แยก setup logic ออกจาก assertion logic
แนวคิดนี้สอดคล้องกับการเขียนสคริปต์ทดสอบแบบ modular ตามที่อธิบายไว้ในคู่มือ การเขียนสคริปต์การทดสอบอัตโนมัติ
การแยก reusable keyword ไปไว้ใน resource file
เมื่อชุดทดสอบเริ่มใหญ่ขึ้น ให้สร้างไฟล์ resource เช่น common.robot:
*** Settings ***
Library RequestsLibrary
Library Collections
*** Variables ***
${BASE_URL} https://api.example.com/v1
${EMAIL} qa@example.com
${PASSWORD} test-pass
*** Keywords ***
Authenticate And Open Session
Create Session api ${BASE_URL}
${login}= POST On Session api /auth/login
... json={"email": "${EMAIL}", "password": "${PASSWORD}"}
${token}= Set Variable ${login.json()}[token]
${headers}= Create Dictionary Authorization=Bearer ${token}
Set Suite Variable ${AUTH_HEADERS} ${headers}
จากนั้น import ใน test file:
*** Settings ***
Resource common.robot
*** Test Cases ***
Create Order
Authenticate And Open Session
${order}= POST On Session api /orders
... json={"product_id": 7, "quantity": 2}
... headers=${AUTH_HEADERS}
Status Should Be 201 ${order}
โครงสร้างที่ใช้บ่อยในโปรเจกต์ API:
tests/
users.robot
orders.robot
resources/
common.robot
auth.robot
users_keywords.robot
orders_keywords.robot
รูปแบบนี้ช่วยให้ test case สั้นลง และทำให้ keyword แยกตาม API domain ได้ชัดเจน หากต้องการเข้าใจว่าทำไม keyword-driven structure จึง scale ได้ดี ดูคู่มือ เฟรมเวิร์กการทดสอบอัตโนมัติ
การรัน Robot Framework ใน CI
Robot Framework เหมาะกับ CI เพราะรันแบบ headless ได้ และคืน exit code ที่ไม่ใช่ศูนย์เมื่อ test fail ทำให้ pipeline fail ได้ทันที
คำสั่งพื้นฐาน:
robot --outputdir results tests/
ส่งค่า environment-specific เช่น staging URL:
robot --outputdir results --variable BASE_URL:https://staging.example.com/v1 tests/
ใช้ tag เพื่อแยก smoke test และ full regression
เพิ่ม tag ใน test case:
*** Test Cases ***
Get User Returns 200
[Tags] smoke users
Create Session api ${BASE_URL}
${response}= GET On Session api /users/42
Status Should Be 200 ${response}
รันเฉพาะ smoke test:
robot --include smoke --outputdir results tests/
ไม่รัน test ที่ติด tag slow:
robot --exclude slow --outputdir results tests/
แนวทางใน CI/CD โดยทั่วไปคือ:
- ติดตั้ง Python และ dependencies
- รัน
robot - เก็บ
log.html,report.html,output.xmlเป็น artifacts - ให้ pipeline fail เมื่อ Robot Framework คืน exit code fail
รูปแบบนี้เหมือนกับแนวทางในคู่มือ การทดสอบ API ใน CI/CD
เมื่อแพลตฟอร์ม API เฉพาะทางมีประโยชน์กว่า
Robot Framework เหมาะเมื่อทีมต้องการ API test ที่อ่านง่ายแบบ keyword-driven และสามารถร่วมกันดูแลได้ แต่จะไม่สะดวกเท่าแพลตฟอร์มเฉพาะทางเมื่อคุณต้องการ:
- ออกแบบ API
- ทำ mocking
- debug request/response
- ตรวจ schema เทียบกับ OpenAPI spec
- จัดการ environment และ test data แบบ visual
- สร้างรายงานและรันผ่าน CLI โดยไม่ต้องประกอบหลายไลบรารีเอง
Apidog รองรับงานเหล่านี้โดยตรง เช่น visual test builder, การตรวจ OpenAPI schema อัตโนมัติ, data-driven testing จาก CSV และ JSON, environment management, HTML report และ CLI runner สำหรับ CI
หลายทีมใช้ทั้งสองอย่างร่วมกัน: Robot Framework สำหรับ keyword-driven test ที่ต้องอ่านง่าย และ Apidog สำหรับการออกแบบ จำลอง และทดสอบ API แบบครบวงจร คุณสามารถ ดาวน์โหลด Apidog เพื่อสร้างชุดทดสอบ API โดยไม่ต้องเขียน keyword library เอง
คำถามที่พบบ่อย
Robot Framework ใช้สำหรับการทดสอบ UI เท่านั้นหรือไม่?
ไม่ใช่ Robot Framework เป็น automation framework ทั่วไป แม้จะนิยมใช้กับ UI ผ่าน SeleniumLibrary แต่เมื่อใช้ RequestsLibrary ก็เหมาะกับ API testing เช่นกัน และยังมีไลบรารีสำหรับ database, SSH และงาน automation อื่น ๆ
ความแตกต่างระหว่าง Create Session กับ request แบบไม่มี session คืออะไร?
Create Session สร้าง HTTP session ที่มีชื่อและคงอยู่ สามารถเก็บ base URL, headers, cookies และ authentication ได้ จากนั้น keyword เช่น GET On Session หรือ POST On Session จะนำ session นั้นกลับมาใช้ใหม่
Request แบบไม่มี session ไม่เก็บ state ระหว่าง call ดังนั้นคุณต้องส่ง headers, cookies หรือ token ใหม่ทุกครั้ง
จำเป็นต้องรู้ Python เพื่อใช้ Robot Framework หรือไม่?
ไม่จำเป็นสำหรับการเขียน test ทั่วไป ไวยากรณ์แบบตารางและ keyword ถูกออกแบบมาให้คนที่ไม่ใช่โปรแกรมเมอร์อ่านและเขียนได้ ความรู้ Python จะมีประโยชน์เมื่อคุณต้องเขียน custom library หรือ keyword ใหม่ในระดับลึกเท่านั้น
Robot Framework เทียบกับ pytest อย่างไรสำหรับ API testing?
pytest เหมาะกับทีม Python ที่ต้องการเขียน test เป็นโค้ดและอยู่ใกล้กับ application code ส่วน Robot Framework เหมาะกับทีมที่ต้องการ test case แบบอ่านง่าย เป็นตาราง และใช้ร่วมกันได้ระหว่าง QA, developer และ stakeholder
ทั้งสองรันใน CI ได้ การเลือกขึ้นอยู่กับว่าใครเป็นคนเขียนและดูแล test suite มากกว่าความสามารถพื้นฐานของเครื่องมือ
Robot Framework ตรวจ response เทียบกับ OpenAPI schema ได้หรือไม่?
ไม่ได้รองรับโดยตรงตั้งแต่เริ่มต้น คุณสามารถตรวจ field ทีละรายการด้วย built-in keyword และ JSONLibrary หรือใช้ไลบรารีชุมชนเพิ่มเติมสำหรับ schema validation
ถ้า OpenAPI schema validation เป็นส่วนหลักของ workflow แพลตฟอร์มอย่าง Apidog จะช่วยลดงานประกอบไลบรารีและลดภาระ maintenance ได้มากกว่า
Top comments (0)