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

เริ่มต้นจากเป้าหมายของการทดสอบ ประกอบไปด้วย

  • Fast feedback loop เพื่อให้เรารู้ปัญหาจากทุก ๆ การเปลี่ยนแปลง
  • High quality คือคุณภาพที่สูงขึ้น ไม่สามารถต่อรองได้
  • เพิ่มความเชื่อมั่นให้สูงขึ้น

สิ่งที่สำคัญมาก ๆ คือ regression test
ดังนั้นถ้าเราใช้ Postman แล้ว จะช่วยให้เราเข้าถึงเป้าหมายเหล่านี้หรือไม่ ?
ถ้าไม่ น่าจะใช้เครื่องมือผิดวิธีแน่นอน
มาเริ่มกัน

Postman นั้นมีความสามารถเยอะมาก ๆ

ยกตัวอย่างเช่น

  • ทดสอบผ่าน protocol ต่าง ๆ เช่น HTTP, MQTT (beta), WebSocket, Socket.io, GraphQL, gRPC
  • เขียน test script สำหรับตรวจสอบ response ว่าเป้นไปตามที่คาดหวังหรือไม่ และจัดการ request ต่าง ๆ ก่อนส่ง request ด้วย pre-request script โดยเขียนในรูปแบบของภาษา JavaScript
  • ทำการจัดการสร้าง request สำหรับทดสอบ protocol ต่าง ๆ ด้วย Collection และ folder
  • โดยปกติจะให้แต่ละ collection มีจำนวน request ไม่เยอะ หรือ แยกตาม flow หรือ scenario เลย ทำให้จัดการง่ายขึ้น
  • อีกอย่าง Postman นั้นมี workspace ให้อีกด้วย
  • การใช้งาน variables สำหรับการจัดการข้อมูลต่าง ๆ ใน Postman ซึ่งมีทั้ง request variable, collection variable และ global variable
  • ชนิดของ variable มีทั้ง plain text และ secret
  • การใช้งาน environment สำหรับจัดการ variable ตาม environment ต่าง ๆ ของระบบที่จะทดสอบเช่น dev, test, staging และ prod เป็นต้น
  • สามารถทำการออกแบบ HTTP Request API ก่อนที่จะพัฒนาได้ รวมทั้งสามารถเขียนเอกสารในรูปแบบ markdown ของ collection และ request ได้เลย ดังนั้นทำให้เราพัฒนาในรูปแบบของ API-first ได้
  • ในส่วนของการออกแบบ API นั้น สามารถกำหนดในส่วนของ response ตามแต่ละรูปแบบ เช่น success และ fail ด้วยการเพิ่ม example เข้าไปในแต่ละ request ได้เลย
  • การกำหนด working directory สำหรับ postman ในการจัดการเกี่ยวกับ data file ต่าง ๆ ที่ใช้ใน postman เพื่อให้ทุกคนในทีมสามารถใช้งานได้เหมือนกัน เพื่อตัดปัญหาเรื่อง path ของ file
  • หลังจากการออกแบบแล้วนั้น สามารถทำการสร้าง Mock Server ผ่าน collection (จะมี request อยู่ใน collection) ที่เราสร้างขึ้นมาได้
  • สิ่งที่เจอปัญหาคือ Mock Server ทำงานแปลก ๆ เรื่องของการ matching example ซึ่งมีแนวคิดและขั้นตอนใน Understanding example matching
  • สามารถ export collection ต่าง ๆ ออกมาเป็นไฟล์ แล้วจัดเก็บใน version control system เพื่อ share กันในทีม (ใช้เมื่อไม่ต้องการใช้งานผ่าน postman team)
  • ในการทดสอบนั้น จะใช้ newman เข้ามาใช้งาน เพื่อ run collection ผ่าน command line ได้ เพื่อให้สามารถทดสอบได้บ่อย และ ง่ายขึ้น รวมทั้งไป integrate เข้ากับ CI/CD ได้อีกด้วย
  • มี API platform สามารถทำงานร่วมกับ Swagger หรือ Open API Specification ได้เลย
  • คร่าว ๆ น่าจะประมาณนี้

รูปแบบของการทดสอบนั้นสำคัญมาก ๆ

ประกอบไปด้วย

  • Integration test
  • Component test (mock/fake dependencies)
  • Contract test ทั้ง Postman และ Pact

ซึ่งต้องรุปตั้งแต่ architecture ของระบบงาน
เพื่อวาง test strategy ต่าง ๆ ออกมา
เพื่อให้ออกแบบระบบให้รองรับกับแนวทางในการทดสอบต่อไป
มันคือ กระบวนการคิดก่อนทำ

ในการทดสอบจะทำทั้ง functional test และ non-functional test

โดย non-functional test คือ performance test
ซึ่ง postman สนับสนุนด้วย
แต่ถ้าอยากทดสอบด้วยเครื่องมืออื่น ๆ
ก็สามารถทำการ convert จาก postman collection ไปยัง script ของเครื่องมืออื่น ๆ ได้
ยกตัวอย่างเช่น

สิ่งที่สำคัญคือ load type ของการทดสอบว่าต้องการอย่างไรบ้าง

ไว้เจอกันการ sharing ต่อ ๆ ไป

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

Tags:,,,,