การทดสอบอัตโนมัติคืออะไร? คู่มือฉบับสมบูรณ์

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

คู่มือนี้จะอธิบายว่าการทดสอบอัตโนมัติคืออะไร, มีประโยชน์และไม่เป็นประโยชน์ในจุดใดบ้าง, และจะแนะนำวิธีการตั้งค่าการทดสอบ API แบบอัตโนมัติทีละขั้นตอนใน Apidog

การทดสอบอัตโนมัติคืออะไร

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

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

การทดสอบอัตโนมัติสามารถนำไปใช้ได้กับทุกส่วนของระบบ: การทดสอบยูนิต (unit tests) สำหรับฟังก์ชัน, การทดสอบการรวมระบบ (integration tests) สำหรับส่วนประกอบ, การทดสอบ UI สำหรับส่วนติดต่อผู้ใช้, และการทดสอบ API สำหรับปลายทาง (endpoints) การทดสอบ API มักจะเป็นจุดเริ่มต้นที่มีคุณค่าสูงสุด เนื่องจาก API มีความเสถียร, เรียกใช้ได้รวดเร็ว, และมีตรรกะทางธุรกิจหลัก การทดสอบ API ใช้เวลาเพียงมิลลิวินาทีและไม่ต้องต่อสู้กับเบราว์เซอร์ที่ไม่เสถียร

ทำไมทีมถึงทำการทดสอบอัตโนมัติ

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

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

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

ผลตอบรับที่รวดเร็ว เมื่อการทดสอบทำงานโดยอัตโนมัติใน Pipeline นักพัฒนาจะทราบภายในไม่กี่นาทีว่าการเปลี่ยนแปลงทำให้เกิดข้อผิดพลาด ในขณะที่บริบทของงานยังคงสดใหม่ ข้อผิดพลาดที่พบใน Production มีค่าใช้จ่ายในการแก้ไขสูงกว่าข้อผิดพลาดเดียวกันที่พบใน CI มาก

คนทำงานได้ดีขึ้น ระบบอัตโนมัติไม่ได้มาแทนที่ผู้ทดสอบ แต่จะช่วยให้พวกเขาเป็นอิสระจากการคลิกซ้ำซาก เพื่อให้พวกเขาสามารถทำการทดสอบเชิงสำรวจ (exploratory testing), การค้นหาเคสขอบ (edge-case hunting), และการทำงานด้านความสามารถในการใช้งาน (usability work) ซึ่งเป็นสิ่งที่เครื่องจักรทำได้ไม่ดี

สิ่งที่การทดสอบอัตโนมัติไม่สามารถแก้ไขได้

ระบบอัตโนมัติไม่ได้มาฟรี และการแสร้งทำเป็นว่ามันฟรีจะนำไปสู่ความผิดหวัง

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

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

และไม่ใช่ทุกอย่างที่ควรถูกทำให้เป็นอัตโนมัติ การตรวจสอบที่คุณจะรันสองครั้งนั้นไม่คุ้มค่า การตรวจสอบที่คุณจะรันทุกครั้งที่ Commit เป็นเวลาสองปีนั้นคุ้มค่าอย่างแน่นอน ควรทำให้เส้นทางที่มั่นคง ซ้ำซาก และมีมูลค่าสูงเป็นอัตโนมัติก่อน ส่วนงานที่ไม่ค่อยเกิดและเป็นเชิงสำรวจให้คงไว้ในแบบแมนนวล

วิธีตั้งค่าการทดสอบ API แบบอัตโนมัติใน Apidog

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

ขั้นตอนที่ 1: กำหนดหรือนำเข้า API ของคุณ นำเข้าปลายทาง (endpoints) ของคุณจากไฟล์ OpenAPI, คอลเลกชัน Postman, หรือกำหนดโดยตรงใน Apidog แต่ละปลายทางจะประกอบด้วยสคีมาคำขอและสคีมาการตอบกลับ ซึ่งจะเป็นพื้นฐานสำหรับการยืนยัน หากคุณเริ่มต้นจากสเปก สัญญา API และการทดสอบจะซิงค์กันโดยอัตโนมัติ

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

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

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

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

ขั้นตอนที่ 6: จัดระเบียบเป็นชุดทดสอบ รวบรวมสถานการณ์เข้าเป็น ชุดทดสอบ เพื่อให้ API ทั้งหมดสามารถทำงานได้ด้วยการคลิกเพียงครั้งเดียว ชุดทดสอบช่วยให้การจัดการฐานการทดสอบที่กำลังเติบโตสามารถทำได้เมื่อขอบเขตการครอบคลุมขยายตัว

ขั้นตอนที่ 7: เชื่อมโยงเข้ากับ CI/CD นี่คือขั้นตอนที่เปลี่ยนชุดทดสอบให้เป็นการทดสอบอัตโนมัติ เรียกใช้ชุดทดสอบทุกครั้งที่มีการคอมมิตหรือพูลรีเควสต์ เพื่อให้ข้อบกพร่องถดถอยปรากฏก่อนการผสานรวม Apidog ทำงานได้ในทุก Pipeline; การทำให้การทดสอบ API เป็นอัตโนมัติใน CI/CD จะอธิบายรายละเอียด และ การรันการทดสอบ API ใน GitHub Actions จะครอบคลุมแพลตฟอร์มนั้นโดยเฉพาะ

ดาวน์โหลด Apidog เพื่อสร้างสถานการณ์อัตโนมัติครั้งแรกของคุณและดูว่ามันทำงานอย่างไร

ประเภทหลักของการทดสอบอัตโนมัติ

การทดสอบอัตโนมัติไม่ใช่สิ่งเดียว แต่เป็นชุดของประเภทการทดสอบที่แบ่งเป็นชั้นๆ ซึ่งแต่ละประเภทจะตรวจจับข้อผิดพลาดคนละประเภทด้วยต้นทุนที่แตกต่างกัน

การทดสอบยูนิต (Unit tests) ตรวจสอบฟังก์ชันหรือคลาสเดียวแบบแยกส่วน มันรวดเร็ว, มีค่าใช้จ่ายต่ำ, และสามารถรันได้หลายพันครั้ง แต่ไม่สามารถตรวจจับปัญหาที่ปรากฏขึ้นเมื่อส่วนประกอบต่างๆ ทำงานร่วมกันได้

การทดสอบการรวมระบบ (Integration tests) ตรวจสอบว่าส่วนประกอบต่างๆ ทำงานร่วมกันได้ดี: บริการกับฐานข้อมูล หรือสองบริการที่อยู่ข้ามเครือข่าย พวกมันสามารถตรวจจับข้อผิดพลาดในการเชื่อมต่อที่การทดสอบยูนิตพลาดไป แต่มีข้อเสียคือช้ากว่าและต้องการการตั้งค่าที่ซับซ้อนกว่า

การทดสอบ API (API tests) อยู่ในจุดที่สมดุล พวกมันจะทดสอบปลายทาง (endpoint) ผ่าน HTTP ในลักษณะเดียวกับที่ไคลเอนต์จริงทำ ดังนั้นจึงตรวจสอบสัญญาจริง พวกมันทำงานได้รวดเร็ว, ไม่ต้องใช้เบราว์เซอร์, และครอบคลุมตรรกะทางธุรกิจที่สำคัญที่สุด สำหรับทีมส่วนใหญ่ นี่คือชั้นที่มีผลตอบแทนสูงสุดเมื่อเทียบกับความพยายามที่ใช้ไป

การทดสอบแบบ End-to-end (End-to-end tests) ขับเคลื่อนเวิร์กโฟลว์ทั้งหมดผ่านระบบจริง ซึ่งมักจะรวมถึง UI พวกมันมีความสมจริงที่สุดและช้าที่สุด และมักจะไม่เสถียรที่สุด ดังนั้นทีมจึงรักษามันให้มีจำนวนน้อยและเน้นไปที่การเดินทางที่สำคัญเท่านั้น

พีระมิดการทดสอบที่ถูกอ้างถึงอย่างกว้างขวางแสดงให้เห็นถึงความสมดุล: การทดสอบยูนิตที่รวดเร็วจำนวนมากเป็นฐาน, การทดสอบการรวมระบบและการทดสอบ API ที่น้อยลงในส่วนกลาง, และการทดสอบแบบ End-to-end ที่บางเบาอยู่ด้านบน ชุดการทดสอบที่มีรูปร่างกลับด้าน ซึ่งส่วนใหญ่เป็นการทดสอบแบบ End-to-end ที่ช้า จะทำงานช้าและล้มเหลวโดยไม่คาดคิด การทดสอบ API เป็นจุดที่ทีมได้รับการครอบคลุมที่กว้างขวางและเชื่อถือได้โดยไม่ต้องเสียค่าใช้จ่ายแบบ End-to-end ซึ่งเป็นเหตุผลที่พวกมันเป็นจุดเริ่มต้นที่แนะนำ

การทำให้ระบบอัตโนมัติให้ผลตอบแทน

นิสัยบางอย่างที่แยกชุดการทดสอบที่สร้างผลตอบแทนออกจากชุดการทดสอบที่เน่าเสีย

รักษาการทดสอบให้ใกล้เคียงกับการออกแบบ API เมื่อสัญญาและการทดสอบอยู่ในที่เดียวกัน การเปลี่ยนแปลงสัญญาจึงยากที่จะลืมในการทดสอบ การเปลี่ยนแปลงที่ไม่ตรงกันคือสาเหตุหลักที่ทำให้ชุดการทดสอบเสื่อมสภาพ

ยืนยันผลลัพธ์ที่แท้จริง ไม่ใช่แค่รหัสสถานะ การทดสอบอัตโนมัติที่ตรวจสอบเฉพาะรหัส 200 จะผ่านได้แม้ว่าจะส่งคืนข้อมูลที่ไร้ประโยชน์ ทำให้เกิดความรู้สึกปลอดภัยที่ผิดพลาด

ทำให้ความล้มเหลวอ่านเข้าใจได้ รายงานที่ดีจะระบุการยืนยันที่ล้มเหลว ไม่ใช่แค่การทดสอบที่ล้มเหลว ยิ่งนักพัฒนาอ่านความล้มเหลวได้เร็วเท่าไหร่ ทีมก็จะยิ่งเชื่อมั่นในชุดการทดสอบมากขึ้นเท่านั้น

รันในจุดที่มีการตัดสินใจ ชุดการทดสอบที่รันเฉพาะเมื่อมีคนจำได้ว่าต้องรัน ไม่ถือว่าเป็นอัตโนมัติ ใส่ไว้ใน Pipeline เพื่อให้มันทำงานได้โดยไม่ต้องมีการร้องขอ

ใช้ AI ช่วยในส่วนที่น่าเบื่อหน่าย การสร้างร่างแรกของกรณีทดสอบจากสเปก หรือการขยายกรณีขอบ (edge cases) เหมาะสมกับการช่วยเหลืออย่างยิ่ง; การทดสอบ API อัตโนมัติที่เสริมด้วย AI แสดงให้เห็นว่ามันช่วยได้อย่างไรและยังคงต้องการการตรวจสอบจากมนุษย์ในจุดใดบ้าง

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

การทดสอบอัตโนมัติดีกว่าการทดสอบด้วยตนเองหรือไม่? ไม่มีสิ่งใดมาแทนที่กันได้ ควรทำให้การตรวจสอบที่เสถียร, ซ้ำๆ, และมีมูลค่าสูงเป็นอัตโนมัติ ส่วนการทดสอบเชิงสำรวจ, การทบทวนความสามารถในการใช้งาน, และงานที่ต้องใช้การตัดสินใจจำนวนมาก ให้ยังคงทำด้วยตนเอง ทีมที่ดีที่สุดจะทำทั้งสองอย่าง

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

ทีมควรเริ่มต้นการทำระบบอัตโนมัติจากจุดใด? การทดสอบ API พวกมันรวดเร็ว, เสถียร, และครอบคลุมตรรกะหลัก โดยไม่มีความไม่แน่นอนเหมือนระบบอัตโนมัติ UI เริ่มต้นด้วยปลายทางที่สำคัญและค่อยๆ ขยายออกไป

การทดสอบอัตโนมัติต้องการการบำรุงรักษามากแค่ไหน? พวกมันจะเปลี่ยนแปลงเมื่อ API เปลี่ยนแปลง การรักษาการทดสอบให้อยู่ใกล้กับการออกแบบ API ช่วยลดความประหลาดใจ แต่ก็ต้องจัดงบประมาณเวลาอย่างต่อเนื่อง เพราะชุดการทดสอบที่ไม่ได้รับการบำรุงรักษาจะหยุดเป็นที่น่าเชื่อถือ

อะไรที่ทำให้การทดสอบอัตโนมัติไม่เสถียร และจะแก้ไขได้อย่างไร? ความไม่เสถียรมักจะมาจากข้อสันนิษฐานเรื่องเวลา, สถานะที่ใช้ร่วมกันระหว่างการทดสอบ, หรือการยืนยันข้อมูลที่ไม่แน่นอน เช่น การประทับเวลา แก้ไขได้โดยการแยกข้อมูลการทดสอบ, การยืนยันโครงสร้างแทนค่าที่ไม่แน่นอนที่แน่นอน, และการลบการเรียงลำดับโดยนัยระหว่างการทดสอบ ชุดการทดสอบที่ไม่เสถียรจะฝึกทีมให้เพิกเฉยต่อความล้มเหลว ดังนั้นจึงควรจัดการกับความไม่เสถียรให้เหมือนข้อบกพร่องจริง

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