วิธีรัน API Test แบบ Parameterized จาก CSV และ JSON

คุณเขียนการทดสอบการเข้าสู่ระบบ มันผ่านฉลุย จากนั้นเพื่อนร่วมทีมก็ถามคำถามที่ชัดเจนขึ้นมาว่า: มันยังคงผ่านอยู่หรือไม่สำหรับบัญชีที่ถูกล็อก, อีเมลที่ยังไม่ยืนยัน, รหัสผ่านที่มีช่องว่างท้าย, สตริง SQL-injection ที่ใครบางคนอาจจะนำมาวางในฟิลด์นั้น? ตอนนี้คุณมีทางเลือก คือก๊อปปี้การทดสอบนั้นห้าครั้งแล้วเปลี่ยนค่าเพียงหนึ่งค่าในแต่ละครั้ง หรือหาวิธีที่จะป้อนข้อมูลหลายแถวในการทดสอบเดียวกันแล้วปล่อยให้มันทำงานทั้งหมด

วิธีการคัดลอกและวางเป็นสาเหตุที่ชุดทดสอบส่วนใหญ่เสื่อมสภาพ การทดสอบห้าชุดที่เกือบจะเหมือนกันจะแยกจากกันไปเรื่อยๆ ตลอดหนึ่งปี ชุดหนึ่งได้รับการยืนยันใหม่ แต่อีกชุดหนึ่งไม่ได้ การเปลี่ยนชื่อฟิลด์ทำให้สี่ชุดเสียไปโดยไม่มีใครรู้ สุดท้ายคุณต้องดูแลห้าสิ่งซึ่งจริงๆ ควรจะเป็นสิ่งเดียว การทดสอบแบบพารามิเตอร์ช่วยแก้ไขปัญหานี้ตั้งแต่ต้นตอ: คุณเขียนการทดสอบเพียงครั้งเดียว จากนั้นชี้ไปที่ตารางข้อมูลอินพุตและผลลัพธ์ที่คาดหวัง หนึ่งสถานการณ์, หลายร้อยกรณี, แก้ไขที่เดียว

ปุ่มดาวน์โหลดแอป

การทดสอบแบบพารามิเตอร์หมายถึงอะไรกันแน่

การทดสอบแบบพารามิเตอร์ ซึ่งบางครั้งเรียกว่าการทดสอบแบบขับเคลื่อนด้วยข้อมูล (data-driven testing) เป็นการแยกตรรกะของการทดสอบออกจากข้อมูลที่ใช้ทดสอบ ตรรกะคือลำดับขั้นตอน: ส่งคำขอ, ตรวจสอบรหัสสถานะ, ตรวจสอบความถูกต้องของฟิลด์ในการตอบกลับ ข้อมูลคือชุดของอินพุตและความคาดหวังที่คุณต้องการให้ตรรกะนั้นทำงานด้วย

ลองนึกภาพสถานการณ์การทดสอบเดียวสำหรับเอนด์พอยต์รหัสส่วนลด ตรรกะจะเหมือนเดิมเสมอ ส่ง POST /api/orders พร้อมรหัส จากนั้นยืนยันผลการตอบกลับ ข้อมูลจะเปลี่ยนไปตามแต่ละกรณี:

รหัส	ยอดรวมคำสั่งซื้อ	สถานะที่คาดหวัง	ส่วนลดที่คาดหวัง
WELCOME10	100	200	10
WELCOME10	5	422	0
EXPIRED	100	410	0
(ว่าง)	100	400	0
FAKE123	100	404	0

ห้าแถว, ห้าพฤติกรรมที่แตกต่างกัน, หนึ่งการทดสอบ ตัวรันจะวนซ้ำผ่านแต่ละแถว ในการวนซ้ำแต่ละครั้ง มันจะผูกค่าคอลัมน์เข้ากับตัวแปร, ส่งคำขอ, และตรวจสอบการยืนยันกับความคาดหวังของแถวนั้น เมื่อแถวที่ 3 ล้มเหลวเนื่องจากรหัสที่หมดอายุส่งค่า 200 แทนที่จะเป็น 410 คุณจะได้รับการแจ้งความล้มเหลวที่ชัดเจนเพียงจุดเดียวที่ชี้ไปยังแถวนั้น คุณไม่จำเป็นต้องไล่หาผ่านไฟล์ทดสอบที่แยกกันห้าไฟล์เพื่อดูว่าชุดไหนเสีย

รูปแบบนี้มีความสำคัญที่สุดที่ขอบเขต การครอบคลุมกรณีปกติ (happy-path) เขียนได้ง่าย และไม่ค่อยพบข้อผิดพลาดที่ทำให้คุณต้องตื่นกลางดึก ข้อผิดพลาดมักจะอยู่ในกรณีขอบเขต: สตริงว่าง, ตัวเลขติดลบ, ชื่อยูนิโค้ด, โทเค็นที่หมดอายุ, ค่าที่เกินขีดจำกัดไปหนึ่งเซ็นต์ การใช้พารามิเตอร์ทำให้การเพิ่มกรณีขอบเขตทำได้ง่ายพอๆ กับการเพิ่มแถวในสเปรดชีต

ทำไมไฟล์ข้อมูลที่แยกออกมาจึงดีกว่าค่าที่เขียนตายตัว

คุณสามารถเขียนค่าแต่ละกรณีลงในโค้ดทดสอบโดยตรงได้ คนส่วนใหญ่เริ่มต้นจากตรงนั้น ปัญหาจะปรากฏขึ้นในภายหลัง

เมื่อข้อมูลอยู่ในโค้ดทดสอบ ผู้ที่ไม่ใช่โปรแกรมเมอร์ก็ไม่สามารถเพิ่มกรณีทดสอบได้ หัวหน้าฝ่าย QA ของคุณรู้ถึงอินพุตที่ซับซ้อนสิบห้าชนิดที่เคยทำให้เอนด์พอยต์นี้เสียหายมาก่อน แต่พวกเขาไม่สามารถเพิ่มได้หากไม่ได้แก้ไขโค้ดและเปิด pull request เมื่อข้อมูลอยู่ในไฟล์ CSV พวกเขาก็สามารถแก้ไขสเปรดชีตแล้วคอมมิตได้ อุปสรรคก็ลดลงจนเกือบเป็นศูนย์

ไฟล์ที่แยกออกมายังช่วยให้สถานการณ์การทดสอบของคุณอ่านง่ายขึ้น การทดสอบที่วนซ้ำผ่านไฟล์ภายนอกนั้นสั้น: มีคำขอเดียว, การยืนยันไม่กี่อย่าง, ก็เสร็จแล้ว การทดสอบที่มีสามสิบกรณีที่ฝังอยู่ในโค้ดเป็นการทำซ้ำที่ไม่มีใครอยากจะแตะต้อง และเมื่อคุณต้องการสร้างกรณีทดสอบด้วยโปรแกรม เช่น แถวนับพันที่ดึงมาจากบันทึกการผลิต ไฟล์เป็นทางเลือกเดียวที่สมเหตุสมผล คุณไม่สามารถวางกรณีทดสอบเป็นพันๆ กรณีลงในเนื้อหาการทดสอบได้

รูปแบบที่คุณเลือกขึ้นอยู่กับลักษณะข้อมูลของคุณ กรณีที่เป็นตารางแบบเรียบเหมาะกับ CSV เพย์โหลดที่มีโครงสร้างซ้อนกันหรือมีโครงสร้างเหมาะกับ JSON ทั้งสองเป็นอินพุตระดับเฟิร์สคลาสในตัวรันของ Apidog ดังนั้นทางเลือกจึงขึ้นอยู่กับข้อมูลของคุณ ไม่ใช่ข้อจำกัดของเครื่องมือ

การตั้งค่าไฟล์ข้อมูลของคุณ

เริ่มต้นด้วย CSV สำหรับกรณีที่เป็นตาราง แถวส่วนหัวจะตั้งชื่อตัวแปรของคุณ; แต่ละแถวถัดลงมาคือการวนซ้ำหนึ่งครั้ง นี่คือตารางรหัสส่วนลดในรูปแบบไฟล์จริง discount-cases.csv:

code,order_total,expected_status,expected_discount
WELCOME10,100,200,10
WELCOME10,5,422,0
EXPIRED,100,410,0
,100,400,0
FAKE123,100,404,0

หัวข้อคอลัมน์แต่ละอันจะกลายเป็นตัวแปรที่คุณใช้อ้างอิงภายในโค้ดทดสอบ ในเนื้อหาคำขอ คุณจะเขียน {{code}} และ {{order_total}}; ในการยืนยัน คุณจะเปรียบเทียบกับ {{expected_status}} และ {{expected_discount}} ตัวรันจะทำการผูกค่าทีละแถว

เมื่ออินพุตของคุณเป็นแบบซ้อนกัน ให้ใช้ JSON อาร์เรย์ของออบเจกต์ ซึ่งแต่ละออบเจกต์คือการวนซ้ำหนึ่งครั้ง ทำให้แต่ละกรณีสามารถบรรจุข้อมูลที่มีโครงสร้างซึ่งยากที่จะทำให้เป็นคอลัมน์แบบเรียบได้ นี่คือ user-cases.json สำหรับเอนด์พอยต์การสร้างผู้ใช้ที่เพย์โหลดมีฟิลด์ซ้อนกัน:

[
  {
    "scenario": "valid full profile",
    "user": {
      "email": "ada@example.com",
      "roles": ["admin", "billing"],
      "profile": { "country": "US", "timezone": "America/New_York" }
    },
    "expected_status": 201
  },
  {
    "scenario": "missing email",
    "user": {
      "email": "",
      "roles": ["viewer"],
      "profile": { "country": "GB", "timezone": "Europe/London" }
    },
    "expected_status": 400
  },
  {
    "scenario": "unknown role",
    "user": {
      "email": "grace@example.com",
      "roles": ["wizard"],
      "profile": { "country": "CA", "timezone": "America/Toronto" }
    },
    "expected_status": 422
  }
]

ภายในโค้ดทดสอบ คุณอ้างอิงค่าที่มีโครงสร้างด้วยไวยากรณ์ {{user}}, {{expected_status}} แบบเดียวกัน และ Apidog จะส่งฟิลด์ของแต่ละออบเจกต์ไปยังการวนซ้ำ คอลัมน์ scenario เป็นป้ายกำกับสำหรับตัวคุณเอง; มันจะปรากฏในรายงานเพื่อให้การวนซ้ำที่ล้มเหลวอ่านว่า “unknown role” แทนที่จะเป็น “iteration 3”

กฎบางข้อจะช่วยป้องกันไฟล์ข้อมูลไม่ให้สร้างปัญหาให้คุณ:

เก็บแต่ละเรื่องไว้ในไฟล์เดียว ไฟล์รหัสส่วนลดและไฟล์การสร้างผู้ใช้ควรเป็นสองไฟล์ ไม่ใช่ไฟล์เดียวที่มีคอลัมน์ปะปนกัน
ใส่ผลลัพธ์ที่คาดหวังไว้ในข้อมูล ไม่ใช่ในโค้ดทดสอบ จุดประสงค์ทั้งหมดคือแถวที่ 2 คาดหวัง 422 ในขณะที่แถวที่ 1 คาดหวัง 200 หากความคาดหวังถูกเขียนตายตัว คุณก็จะกลับไปสู่การทดสอบหนึ่งครั้งต่อหนึ่งกรณี
ใส่เครื่องหมายอัญประกาศสำหรับสิ่งใดๆ ที่มีเครื่องหมายจุลภาคใน CSV หรือเปลี่ยนไฟล์นั้นเป็น JSON ฟิลด์ข้อความอิสระที่มีเครื่องหมายจุลภาคเป็นปัญหาสุดคลาสสิกของ CSV
จัดเก็บไฟล์เหล่านี้ใน repo ของคุณถัดจากไฟล์คอนฟิกการทดสอบอื่นๆ เพื่อให้มีการควบคุมเวอร์ชันไปพร้อมกับโค้ดที่พวกเขาทดสอบ

การสร้างสถานการณ์แบบพารามิเตอร์ใน Apidog

ในแอป Apidog ให้สร้างสถานการณ์การทดสอบเพียงครั้งเดียวเหมือนกับสถานการณ์อื่นๆ เพิ่มคำขอไปยังเอนด์พอยต์ของคุณ ในส่วนเนื้อหา ให้แทนที่ค่าที่ระบุตรงๆ ด้วยการอ้างอิงตัวแปร: {{code}}, {{order_total}} และอื่นๆ สิ่งเหล่านี้คือคอลัมน์จากไฟล์ข้อมูลของคุณ

จากนั้นเพิ่มการยืนยันที่อ่านจากไฟล์เดียวกัน สำหรับตัวอย่างส่วนลด คุณจะยืนยันว่าสถานะการตอบกลับเท่ากับ {{expected_status}} และฟิลด์ส่วนลดในเนื้อหา JSON เท่ากับ {{expected_discount}} เนื่องจากทั้งอินพุตและผลลัพธ์ที่คาดหวังมาจากแถวเดียวกัน ตรรกะการยืนยันเดียวกันจึงตรวจสอบแต่ละกรณีได้อย่างถูกต้อง หากคุณไม่เคยเขียนการยืนยันใน Apidog มาก่อน การยืนยัน API: คู่มือเชิงปฏิบัติ จะครอบคลุมรูปแบบต่างๆ และ วิธีการตั้งค่าการยืนยันและดึงตัวแปรจากผลตอบกลับ JSON จะแสดงรายละเอียดของ JSONPath

ในการเชื่อมต่อข้อมูล ให้เปิดการตั้งค่าการรันสถานการณ์การทดสอบและแนบไฟล์ CSV หรือ JSON ของคุณเป็นแหล่งข้อมูลการวนซ้ำ Apidog จะอ่านไฟล์, นับจำนวนแถว, และรันสถานการณ์หนึ่งครั้งต่อหนึ่งแถว โดยจะผูกคอลัมน์ของแต่ละแถวเข้ากับตัวแปรที่ตรงกัน รันมันภายในแอป แล้วคุณจะได้รับการวิเคราะห์แยกตามการวนซ้ำ: แถวใดผ่าน, แถวใดล้มเหลว, และค่าจริงเทียบกับค่าที่คาดหวังสำหรับการยืนยันที่ล้มเหลวแต่ละครั้ง

นี่คือจุดที่การใช้พารามิเตอร์สามารถทำงานร่วมกับชุดทดสอบที่เหลือของคุณได้ สถานการณ์แบบพารามิเตอร์ก็ยังคงเป็นสถานการณ์อยู่ดี ดังนั้นคุณจึงสามารถจัดกลุ่มหลายๆ สถานการณ์เข้าเป็น ชุดทดสอบ และรันทั้งหมดเป็นงานเดียวได้ การวนซ้ำแบบขับเคลื่อนด้วยข้อมูลจะจัดการความครอบคลุมภายในเอนด์พอยต์เดียว; ชุดทดสอบจะจัดการความครอบคลุมข้ามเอนด์พอยต์

การรันจากบรรทัดคำสั่ง

แอปเป็นที่ที่คุณสร้างและดีบัก CI คือที่ที่การทดสอบสร้างคุณค่า โดยจะรันทุกครั้งที่มี pull request โดยไม่ต้องมีใครกดปุ่ม การส่งต่อนี้คือสิ่งที่ Apidog CLI มีไว้เพื่อ มันนำสถานการณ์ที่คุณสร้างในแอปไปรันโดยไม่มี UI จากเทอร์มินัล พร้อมข้อมูลการวนซ้ำเดียวกัน

npm install -g apidog-cli

ไบนารีคือ apidog ดังนั้นทุกคำสั่งจะเริ่มต้นด้วย apidog run การรันพื้นฐานจะชี้ไปยังสถานการณ์ด้วย ID และสภาพแวดล้อมด้วย ID:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -e 1629989 -r cli

ในการขับเคลื่อนสถานการณ์นั้นจากไฟล์ข้อมูล ให้เพิ่มแฟล็ก iteration-data มันยอมรับพาธไปยังไฟล์ JSON หรือ CSV:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -e 1629989 \
  -d ./discount-cases.csv -r cli,junit --out-dir ./test-reports

แฟล็ก -d (รูปแบบเต็ม --iteration-data) เป็นหัวใจสำคัญของการรันแบบพารามิเตอร์จากบรรทัดคำสั่ง Apidog จะอ่านไฟล์, รันสถานการณ์หนึ่งครั้งต่อหนึ่งแถว, และรายงานผลของการวนซ้ำแต่ละครั้ง สลับ discount-cases.csv เป็น user-cases.json และแฟล็กเดียวกันก็จะจัดการกับอาร์เรย์ JSON; ตัวรันจะรับรู้รูปแบบจากไฟล์ ปฏิบัติต่อโทเค็นการเข้าถึงเหมือนรหัสผ่านและจัดเก็บเป็นความลับใน CI ห้ามเก็บไว้ในไฟล์ที่คอมมิต นั่นคือเหตุผลที่ทุกตัวอย่างอ้างอิงถึง $APIDOG_ACCESS_TOKEN แทนที่จะเป็นค่าที่ระบุตรงๆ

แฟล็กบางตัวที่มักใช้คู่กับการรันแบบพารามิเตอร์:

-d, --iteration-data <path> ชี้การรันไปยังไฟล์ CSV หรือ JSON ของคุณ นี่คือตัวที่เปลี่ยนการรันแบบครั้งเดียวเป็นการรันแบบขับเคลื่อนด้วยข้อมูล
-n, --iteration-count <n> รันสถานการณ์ตามจำนวนครั้งที่กำหนด เมื่อคุณให้ไฟล์ข้อมูล จำนวนแถวมักจะเป็นตัวกำหนดการวนซ้ำ ดังนั้นคุณจะใช้ -n เป็นหลักสำหรับกรณีที่ทำซ้ำโดยไม่มีข้อมูล เช่น soak tests
-r, --reporters <list> เลือกรูปแบบเอาต์พุต ใช้ cli สำหรับเอาต์พุตบันทึกบิลด์ที่อ่านง่าย และ junit เพื่อส่งออก XML ที่แดชบอร์ด CI จะนำไปวิเคราะห์เป็นแผนผังผ่าน/ไม่ผ่านต่อการวนซ้ำ
--out-dir <path> กำหนดตำแหน่งที่รายงานจะถูกจัดเก็บ เพื่อให้คุณสามารถเก็บถาวรเป็น build artifacts ได้

หากคุณต้องการรายการแฟล็กที่เป็นทางการและเป็นปัจจุบันสำหรับเวอร์ชันที่คุณติดตั้ง ให้รัน apidog run --help CLI จะแสดงทุกตัวเลือกพร้อมรูปแบบย่อและรูปแบบเต็ม

การเชื่อมต่อการรันแบบพารามิเตอร์เข้ากับ CI

เหตุผลที่ควรลงทุนในการทดสอบแบบพารามิเตอร์ก็คือมันจะให้ผลตอบแทนโดยอัตโนมัติ นี่คือ GitHub Actions job ที่ติดตั้ง CLI และรันสถานการณ์ที่ขับเคลื่อนด้วย CSV ทุกครั้งที่มี pull request:

name: API tests
on: [pull_request]

jobs:
  api-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - name: Install Apidog CLI
        run: npm install -g apidog-cli
      - name: Run parameterized API tests
        env:
          APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}
        run: |
          apidog run --access-token $APIDOG_ACCESS_TOKEN \
            -t 605067 -e 1629989 \
            -d ./tests/discount-cases.csv \
            -r cli,junit --out-dir ./test-reports
      - name: Upload report
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: api-test-report
          path: ./test-reports

โทเค็นมาจาก secrets.APIDOG_ACCESS_TOKEN ซึ่งถูกตั้งค่าเพียงครั้งเดียวในการตั้งค่า repo ของคุณ ตัวรายงาน junit จะเขียน XML ที่แดชบอร์ด CI ส่วนใหญ่จะเปลี่ยนให้เป็นแผนผังผลลัพธ์ต่อการวนซ้ำ ดังนั้นแถวที่ล้มเหลวจะปรากฏเป็นการทดสอบที่ล้มเหลวที่มีชื่อ แทนที่จะเป็นเพียงข้อความบันทึกจำนวนมาก การใช้ if: always() ในขั้นตอนการอัปโหลดหมายความว่าคุณจะยังคงรายงานไว้แม้ว่าการรันจะล้มเหลว ซึ่งเป็นสิ่งที่คุณต้องการมากที่สุดในสถานการณ์นั้น สำหรับการเจาะลึกด้าน Actions เพิ่มเติม โปรดดู วิธีการทำให้ API tests เป็นอัตโนมัติใน GitHub Actions

สถานการณ์เดียวกันและไฟล์ข้อมูลเดียวกันสามารถรันได้ในระบบ CI ใดก็ได้ GitLab CI, Jenkins, CircleCI และอื่นๆ ทั้งหมดล้วนลดขั้นตอนลงเหลือสามอย่าง: ติดตั้ง Node และ CLI, เปิดเผยโทเค็นเป็นตัวแปรสภาพแวดล้อม, เรียกใช้ apidog run ด้วย -d ไม่มีการเขียนการทดสอบใหม่สำหรับแต่ละแพลตฟอร์ม

การเปรียบเทียบวิธีการทดสอบแบบพารามิเตอร์

Apidog ไม่ใช่วิธีเดียวในการรัน API tests แบบขับเคลื่อนด้วยข้อมูล ควรทำความเข้าใจภาพรวมเพื่อที่คุณจะได้เลือกสิ่งที่เหมาะสม

Postman และตัวรันของมันก็รองรับไฟล์ข้อมูลด้วยเช่นกัน ด้วย Postman’s Collection Runner หรือเครื่องมือบรรทัดคำสั่ง Newman คุณสามารถแนบไฟล์ CSV หรือ JSON และอ้างอิงตัวแปร {{column}} ในคำขอได้ คล้ายกับรูปแบบในที่นี้ เป็นแนวทางที่มีประสิทธิภาพและมีเอกสารประกอบอย่างดี ข้อเสียคือตรรกะการทดสอบของคุณจะอยู่ใน JavaScript pre-request และ test scripts ดังนั้นเมื่อการยืนยันของคุณเพิ่มขึ้น คุณก็ต้องดูแลโค้ดมากขึ้น หากคุณกำลังพิจารณาตัวรันแบบบรรทัดคำสั่งโดยเฉพาะ Postman CLI vs Newman จะอธิบายความแตกต่างอย่างละเอียด

เฟรมเวิร์กที่เน้นโค้ดเป็นหลัก เช่น pytest ที่มี @pytest.mark.parametrize, JUnit’s @ParameterizedTest, หรือ REST Assured ให้คุณควบคุมด้วยภาษาโปรแกรมได้อย่างเต็มที่ เป็นตัวเลือกที่เหมาะสมเมื่อตรรกะการทดสอบของคุณต้องการโค้ดจริงๆ: การตั้งค่าที่ซับซ้อน, การสร้างข้อมูลแบบกำหนดเอง, การเชื่อมโยงอย่างแน่นหนากับ codebase การทดสอบที่มีอยู่ ค่าใช้จ่ายคือทุกกรณีอยู่ในโค้ด ดังนั้นผู้ที่ไม่ใช่โปรแกรมเมอร์จึงไม่สามารถมีส่วนร่วมได้ และคุณต้องดูแลระบบ HTTP เอง

มุมมองของ Apidog คือสถานการณ์เป็นแบบภาพและข้อมูลเป็นภายนอก ดังนั้นตรรกะจึงยังคงอ่านง่ายและกรณีต่างๆ ยังคงเปิดกว้างสำหรับใครก็ตามที่สามารถแก้ไขสเปรดชีตได้ ในขณะที่สถานการณ์เดียวกันยังคงรันแบบ headlessly ใน CI หากคุณกำลังเลือกเครื่องมือสำหรับการรันแบบขับเคลื่อนด้วยข้อมูล CSV และ JSON โดยเฉพาะ การเปรียบเทียบใน เครื่องมือใดสำหรับการทดสอบ API แบบขับเคลื่อนด้วยข้อมูลด้วย CSV หรือ JSON จะเจาะลึกถึงข้อดีข้อเสีย ไม่มีวิธีใดผิด จับคู่แนวทางกับผู้ที่เขียนกรณีทดสอบและปริมาณตรรกะที่กำหนดเองที่แต่ละกรณีต้องการ

เวิร์กโฟลว์เชิงปฏิบัติที่ปรับขนาดได้

นี่คือลักษณะที่เวิร์กโฟลว์นี้จะเป็นเมื่อมันกลายเป็นส่วนหนึ่งของกิจวัตรของทีมคุณ

เริ่มต้นจากแคบๆ เลือกเอนด์พอยต์หนึ่งที่เคยสร้างปัญหาให้กับคุณมาก่อน เขียนสถานการณ์เดียวใน Apidog โดยมีการอ้างอิงตัวแปรในคำขอและผลลัพธ์ที่คาดหวังในการยืนยัน สร้างไฟล์ CSV ที่มีสามแถว: หนึ่งกรณีปกติ (happy path), หนึ่งกรณีที่ล้มเหลวที่ทราบ, หนึ่งกรณีขอบเขต รันมันในแอปจนกว่าการวนซ้ำทั้งสามจะทำงานตามที่คาดหวัง

จากนั้นเพิ่มข้อมูล ไม่ใช่การทดสอบ ทุกครั้งที่มีรายงานบั๊กเข้ามา ให้เพิ่มอินพุตที่ทำให้เกิดปัญหานั้นเป็นแถวใหม่พร้อมกับผลลัพธ์ที่คาดหวังที่ถูกต้อง บั๊กนั้นจะกลายเป็นกรณีการถดถอยถาวร และคุณไม่เคยเขียนการทดสอบใหม่ คุณเพียงแค่เพิ่มบรรทัดลงในไฟล์ ในอีกไม่กี่เดือน ไฟล์นั้นก็จะสะสมความซับซ้อนในโลกแห่งความเป็นจริงที่เอนด์พอยต์ของคุณต้องเผชิญ

สุดท้าย ทำให้เป็นอัตโนมัติ ใส่คำสั่ง apidog run -d ลงใน CI เพื่อให้ตารางทั้งหมดทำงานทุกครั้งที่มี pull request ตอนนี้การเปลี่ยนแปลงที่ทำให้เส้นทางรหัสที่หมดอายุเสีย จะทำให้บิลด์ล้มเหลวทันทีที่ถูกพุช โดยมีการวนซ้ำที่ระบุชื่อชี้ตรงไปยังแถวที่เสียหาย

ผลลัพธ์ที่เพิ่มขึ้นคือการบำรุงรักษา เมื่อรูปแบบการตอบสนองของเอนด์พอยต์เปลี่ยนไป คุณแก้ไขการยืนยันเพียงครั้งเดียวและทุกกรณีก็จะได้รับการแก้ไขนั้น เมื่อคุณต้องการอีกห้าสิบกรณี คุณก็เพิ่มห้าสิบแถว ตรรกะการทดสอบยังคงเป็นสิ่งเดียว เล็ก และอ่านง่าย ไม่ว่าความครอบคลุมของคุณจะกว้างแค่ไหนก็ตาม

คำถามที่พบบ่อย

การทดสอบแบบพารามิเตอร์และการทดสอบแบบขับเคลื่อนด้วยข้อมูลแตกต่างกันอย่างไร? ทั้งสองอธิบายแนวคิดเดียวกันและผู้คนใช้คำเหล่านี้สลับกันได้ ทั้งสองหมายถึงการรันการทดสอบหนึ่งครั้งซ้ำๆ ด้วยอินพุตและผลลัพธ์ที่คาดหวังที่แตกต่างกันซึ่งจัดหามาจากภายนอกการทดสอบ คำว่า “Parameterized” เน้นที่กลไกการผูกพารามิเตอร์; ส่วน “data-driven” เน้นที่แหล่งข้อมูลภายนอก ในทางปฏิบัติ ให้ถือว่าคำเหล่านี้เป็นคำพ้องความหมาย

ฉันควรใช้ CSV หรือ JSON สำหรับไฟล์ข้อมูลของฉัน? จับคู่รูปแบบกับลักษณะข้อมูลของคุณ กรณีที่เป็นตารางแบบเรียบที่ทุกแถวมีคอลัมน์ง่ายๆ เหมือนกันเหมาะกับ CSV และ CSV ก็แก้ไขได้ง่ายกว่าสำหรับผู้ที่ไม่ใช่โปรแกรมเมอร์ในสเปรดชีต เพย์โหลดที่มีโครงสร้างซ้อนกัน เช่น เนื้อหาคำขอที่มีอาร์เรย์และออบเจกต์ย่อยๆ เหมาะกับ JSON Apidog อ่านทั้งสองรูปแบบเป็นข้อมูลการวนซ้ำ ดังนั้นเลือกรูปแบบใดก็ได้ที่แสดงกรณีของคุณโดยไม่มีความยุ่งยาก

การวนซ้ำหลายร้อยครั้งจะทำให้ pipeline ของฉันช้าลงหรือไม่? แต่ละแถวคือการรันสถานการณ์หนึ่งครั้ง ดังนั้นเวลาทั้งหมดจะเพิ่มขึ้นตามจำนวนแถวคูณด้วยความล่าช้าต่อคำขอ สำหรับการทดสอบ API ส่วนใหญ่ ใช้เวลาเพียงไม่กี่วินาที ไม่ใช่หลายนาที หากชุดข้อมูลขนาดใหญ่ทำให้บิลด์ของคุณใช้เวลานาน ให้แบ่งมัน: รันชุดย่อยแบบ smoke test อย่างรวดเร็วทุกครั้งที่มี pull request และรันตารางทั้งหมดในงานตอนกลางคืนหรือก่อนการเผยแพร่ สถานการณ์และไฟล์เดียวกันนี้ใช้ได้กับทั้งสองกรณี; มีเพียงชุดย่อยของข้อมูลเท่านั้นที่เปลี่ยนไป

ฉันจะเก็บความลับออกจากไฟล์ข้อมูลและการตั้งค่าการทดสอบของฉันได้อย่างไร? เก็บข้อมูลรับรองออกจากไฟล์ข้อมูลโดยสิ้นเชิง โทเค็นและรหัสผ่านควรอยู่ในตัวแปรสภาพแวดล้อมหรือที่เก็บความลับของระบบ CI ของคุณ โดยอ้างอิงเป็น $APIDOG_ACCESS_TOKEN และอื่นๆ ไฟล์ข้อมูลควรเก็บอินพุตการทดสอบและผลลัพธ์ที่คาดหวัง ไม่ใช่ข้อมูลการยืนยันตัวตน ใครก็ตามที่สามารถอ่าน repo ได้ก็สามารถอ่าน CSV ได้ ดังนั้นให้ปฏิบัติกับมันในลักษณะนั้น

ฉันสามารถรันสถานการณ์แบบพารามิเตอร์เดียวกันกับ staging และ production ได้หรือไม่? ได้ ให้สถานการณ์และไฟล์ข้อมูลคงที่ และสลับสภาพแวดล้อมด้วยแฟล็ก -e ชี้การตรวจสอบ pull-request ไปยัง staging และ smoke test หลังการปรับใช้ไปยัง production โดยใช้ Scenario ID และข้อมูลเดียวกัน เพียงแต่เป็น Environment ID ที่แตกต่างกัน นั่นคือเหตุผลทั้งหมดที่สภาพแวดล้อมและข้อมูลเป็นอินพุตที่แยกกัน

สรุป

การทดสอบ API แบบพารามิเตอร์เปลี่ยนการครอบคลุมจากการคัดลอก-วางที่น่าเบื่อให้กลายเป็นงานป้อนข้อมูล คุณเขียนการทดสอบเพียงครั้งเดียว อธิบายแต่ละกรณีเป็นแถวในไฟล์ CSV หรือ JSON และปล่อยให้ตัวรันจัดการที่เหลือ ตรรกะยังคงเล็กและอ่านง่าย กรณีต่างๆ ยังคงเปิดกว้างสำหรับทุกคนในทีม และ CI จะรันตารางทั้งหมดทุกครั้งที่มีการเปลี่ยนแปลง

Apidog มอบเครื่องมือสร้างสถานการณ์แบบภาพสำหรับการเขียน, ไฟล์ CSV และ JSON ภายนอกสำหรับข้อมูล, และคำสั่ง apidog run -d สำหรับการรันแบบ headlessly ในระบบ CI ใดก็ได้ สร้างสถานการณ์เดียว, ชี้ไปที่ตารางกรณีที่เพิ่มขึ้น, และความครอบคลุมการทดสอบของคุณก็จะขยายวงกว้างขึ้นทุกครั้งที่มีคนเพิ่มแถว ดาวน์โหลด Apidog และเปลี่ยนการทดสอบแบบครั้งเดียวที่ไม่เสถียรของคุณให้เป็นสถานการณ์แบบพารามิเตอร์ที่ปรับขนาดได้

ปุ่มดาวน์โหลดแอป