how-to-api-testing
how-to-api-testing

หลังจากเรียนรู้ว่า QA คือใคร? ทําหน้าที่อะไร? ก็จะรู้แล้วล่ะว่า QA นั้นต้องมีความรู้ค่อนข้างมากเลย ไม่ใช่งานง่ายๆว่าจับใครมาทําก็ได้น่ะ มันต้องรู้ตั้งแต่ต้นนํ้าจนปลายนํ้าเลยล่ะ 🙂

ทีนี้..เรามาสนใจการเทสที่ business layer กันหรือนั้นก็คือส่วนของ API testing นั้นเอง ซึ่งการเทสของ API testing เนี่ยมุมมองจะแตกต่างกับการเทสของ presentation layer มากๆเลยล่ะ เพราะ…ส่วนของ presentation layer มันคือเรื่องของ front logic ในการ display หรือ front logic เท่านั้น

แต่เจ้า business layer เนี่ย มันคือเรื่องของเงินๆทองๆๆเลยน่ะ ถ้าเจ้า layer เนี่ยเป็นอะไรไป มีแต่ตายๆกับตายเท่านั้นอะ เช่น ขออธิบายให้อีกทีน่ะ

  • Web ของเรา เป็นเว็ปขายของ Ecommerce โดยมี traffic อยู่ที่ประมาณ 20,000 requests / นาที
  • โดยมียอด purchase order ต่อนาทีเป็น 500 orders
  • ต่อ order มีค่าเฉลี่ย 500 บาท

Product Owner อันบรรเจิดของเราเห็นว่าใกล้เทศกาลวันแม่แล้ว จึงออก Campaign นึงที่ให้หน้าเว็ปแสดงผลในรูปแบบของวันแม่เพื่อดึงดูดลูกค้าให้ซื้อของเพิ่ม จึงออก stories ให้ Developer คนนึงไป Add Flags ใหม่ขึ้นไป เพื่อที่จะให้ฝั่ง Front และ Back รู้ว่าจะมี items ใหม่ช่วงวันแม่ให้แสดงผลอีกแบบ แต่ด้วยความที่งานเร่งมาก เพราะ PO แทรกงานก่อนหมด sprint 3 วัน เพื่อให้ทันวันแม่

QA ด้วยความที่ไม่มี enviroment ในการเทสที่ดีพอ ทําให้ไม่สามารถให้มันเป็น automate flow ได้หมดทุก layer ทําให้หลุด Flags นี้ไป …. เกิดเป็น!!! Front End และ Back End คุยกันไม่ได้ผลทําให้ server ร่วงไป 🙁 เป็นเวลาราวๆ 30 นาที ไม่สามารถ shopping ได้เลย ผลลัพธ์คือ

  • purchase order drop ลงประมาณ 500 * 30 = 15,000 orders
  • ผลบริษัทเสียเงินเป็น 15,000 * 500  = 7,500,000 บาท ในแค่ 30 นาที!!!!

พูดมาตั้งสองย่อหน้าเนี่ย มันแค่จะบอกว่าการเทสของ API เนี่ยเป็นเรื่องใหญ่มากๆ เงิน 7.5m หายไปใน 30 นาที นั้นอาจจะหมายถึงว่า เราจะไม่ได้โบนัสปีนี้ หรือ แย่กว่านั้นบริษัทอาจจะขาดทุนเลยก็ได้ในเดือนนั้นๆ 🙁

เพราะฉะนั้นแง่มุมของการทํา QA Backend มันมันส์มากกก เราเลยควรที่จะเรียนรู้เรื่องของการทํา API testing และ แง่มุมที่ต้องนึกถึงเมื่อทํางานกับ Developer ว่าเราต้อง concern อะไรบ้าง 🙂

มาเริ่ม API Testing 101 กันดีกว่า

ก่อนจะเริ่มลง API Testing กัน เราต้องเข้าใจก่อนว่า Layer ในการทํา Application แบบคร่าวๆๆมีอะไรบ้าง? โดยแบ่งง่ายๆ 3 อย่างเลยก็คือ

basic-application-layer
basic-application-layer
  1. Presentation Layer
    • ทําหน้าที่แสดงผล application เรา พูดง่ายๆก็อารมณ์แบบ หน้าเว็ป, แอพบนมือถือ front-end ต่างๆๆนาๆ ซึ่งตอนนี้มีเยอะมากๆเลย
  2. Business Layer
    • ส่วนสําคัญของธุรกิจเลยล่ะ เพราะว่าเดี๋ยวนี้ไม่มีใครทํา business logic ในฝั่งของ presentation layer อีกแล้ว ทุกอย่างมาอยู่ในฝั่ง Business layer ล่ะ ซึ่งส่วนใหญ่ก็จะอยู่บน server backend นั้น
  3. Database Layer
    • ทุก application ต้องมี database ไว้เก็บข้อมูลของลูกค้าอยู่แล้วล่ะ layer นี้ก็เป็น layer ที่ Business layer จะ query ข้อมูลจาก database เอาขึ้นมาโชว์ พวก c*, mongodb, mysql server แบบนั้น

เจ้าสามส่วนนี้แหละ คือส่วนหลักของการทํางานของ application เลยล่ะ 🙂 ถ้าเราสามารถแยกแต่ละ Layer ออกจากกันได้ เราก็จะเข้าใจว่า เราต้องทําการเทสอะไรบ้าง เทสส่วนไหนบ้างนั้นเอง

ซึ่งส่วนใหญ่บทความที่เขียนไปพวก Robot Framework 101 มันก็จะเป็นการทํา testing ฝั่ง Presentation Layer ซะส่วนใหญ่ ซึ่งหลักๆของการทําเทสพวกนั้นจะมีเรื่องของการเช็ค Presentation logic เพียงอย่างเดียว ซึ่งพอทําเทสไปซักระยะ จะเข้าใจว่ามันไม่มีอะไรมากนั้นเอง ก็จะใช้ selenium จับไปเรื่อย, validate ค่าซะส่วนใหญ่, look & feel อาจจะมีบ้างในจุดที่สําคัญๆๆ แต่สุดท้ายก็จะวนอยู่เพียงแค่นั้นเอง  นั้นเป็นเพราะตัว Logic จริงๆในฝั่ง Front-end ไม่มี มันจะถูกย้ายไปอยู่ในส่วนของ Back-end หรือ Business Layer ทั้งหมด เพื่อความ consistency ของ Logic เองด้วย และเรื่องของ Performance ด้วยนั้นเอง

ทีนี้จะเห็นได้ว่าบทความก่อนๆอย่างพวก Gatling Performance testing หรือบทความแปลของ Performance Testing 101 จะมีรายละเอียดที่ต้องสนใจหลายอย่าง และ การคิดก็จะไม่เหมือนกับการเทสบนฝั่งของ Presentation Logic เลย เรียกได้ว่ามีความท้าทายมากกว่าฝั่ง Presentation ค่อนข้างเยอะทีเดียว

ความแตกต่างในการ Test  2 layers นี้

ความแตกต่างหลักๆเลยในการเทส Presentation กับ Business เลย ก็คือเรื่องของ concern ที่แตกต่างกัน

ในฝั่งของ Presentation

จะเป็นเรื่องของ Look and Feel หรือ Business logic ไม่มากนัก การเปลี่ยนแปลงจากฝั่ง Presentation layer ก็มักจะเป็นเรื่องของ Input control ที่เปลี่ยนไป หรือ เรื่องของ Logic ในการแสดงผล เช่น ถ้าเรากด dropdown จังหวัด dropdown ถัดไปต้องเป็นเขต เป็นต้น

example-multiple-input
example-multiple-input (http://www.itangmo.com/file/demo/21082013/dropdown/)

ซึ่งการเทสพวกนี้ก็จะไม่พ้นพวก Selenium เข้ามาช่วยในการเขียนจับ elements แต่ละตัว แล้ว validate logic นั้นเอง อาจจะมีปัญหาเรื่องของ Selenium ที่ไม่สามารถจับ element ได้ หรือ page load เร็วเกินไป หรือ driver ไม่ stable หรือ ถ้าทําบน mobile devices ก็จะหนีไม่พ้นเรื่องของ platform แต่ละ platform เช่น android หรือ ios ทํางานไม่เหมือนกัน ทําให้การจับ element แตกต่างกัน application นั้นเป็น native,web app หรือ hybrid ก็ว่ากันไป แต่ทุกอย่างก็หนีไม่พ้น รายละเอียดงานต่อไปนี้คือ

  1. เตรียม driver ที่เป็นตัวกลางในการคุยกันระหว่าง test code กับ application ซึ่งส่วนมากก็จะเป็น selenium, appium ที่นํามาใช้ อาจจะมีตัวอื่นบ้าง แต่หลักการไม่ต่าง
  2. Test cases ที่ทําการเน้น validate logic อย่างที่ยกตัวอย่างให้ดู
  3. เขียน Library สําหรับการจับ element หรือ validate elements เอง
  4. Investigate Issues ก็มักจะไม่พ้นเรื่องของการทํางานผ่าน UI เป็นหลักแล้วก็จะวิ่งไปหา Backend อีกที ว่าทําไมค่าไม่ตรง ทําไมตรงนั้นเปลี่ยนเป็นต้น
  5. Performance testing ก็อาจจะมีบ้างเล็กๆๆๆๆๆๆน้อยๆๆๆๆๆๆๆๆๆมากๆๆๆๆๆ ประเภททําไมหน้า Page load ช้า เราสามารถ encrypt หรือหาวิธีให้มันเล็กลงได้มั้ย แบบนั้น

ส่วนของทาง Business Layer

จะต้องเข้าใจก่อนเลยว่ามันไม่มี User Interface อะไรแบบนั้นน่ะ สิ่งที่เราเห็นเป็น UI มากสุดก็น่าจะเป็น terminal เนี่ยแหละ เพราะฉะนั้นตัดเรื่องของ Selenium ออกไปได้เลย เรียกได้ว่าทิ้งลงถังได้เลยล่ะ แทบสะกดไม่เป็นเลย เพราะฝั่งของ Backend ไม่มี UI นั้นเอง

cmd-terminal
cmd-terminal

สิ่งที่ฝั่ง Business Layer สนใจในการทดสอบจะเป็นเรื่องของพวกนี้มากกว่า เป็นเรื่องหลักๆๆ ที่เราต้อง Provide concern ให้กับทาง Product owner หรือ Developer เลยก็คือ 🙂

  1. Database configuration rules / configuration files
    • อย่างแรกเมื่อก้าวมาฝั่ง Business Layer เลยน่ะ ทุกอย่างมันจะเป็นเรื่องของ database or configuration ทั้งนั้นแหละ เช่น logic rules ที่ใส่ไว้ใน db conf. / conf. เพื่อให้ business ทํางานได้ถูกต้อง  โดยพวกสิ่งที่เราต้องเทสก็คือเรื่องของการลอง request ดูว่าเข้า rules พวกนั้นรึเปล่า
  2. Flags in request-response
    • Presentation layer ก็คงจะทำ Input control ตัวใหม่เข้ามา เพิ่มหลายๆอย่างเข้ามา แต่ถ้าเป็นเรื่องของ Business layer ก็ไม่พ้นเพิ่ม Flags ขึ้นมาใน request-response เพื่อให้ฝั่ง Front-end หรือ Services ตัวต่อไปรับไปประมวลผลต่อ ซึ่งสิ่งที่เราต้องเช็คก็คือว่า flag นั้นมารึเปล่านั้นเอง (หรือในบางกรณ์เราต้องเช็คเรื่องของ object ใหม่ มีการ serialize ข้อมูลได้ตรงกันรึเปล่าด้วย เชิง data structure)
  3. Performance testing
    • เรื่องหลักกกกก ในการทํางานเลยล่ะ เพราะ performance สําหรับ Business layer คือทุกอย่าง เราต้องส่งข้อมูลที่ประมวล Business logic แล้วให้กับฝั่ง Front-end นั้นเอง ถ้าตอบช้า มันจะทําให้ฝั่ง presentation layer มีปัญหากับลูกค้าอีก เพราะฉะนั้นก่อน release ทุกครั้งต้องทํา Load testing ก่อนเพื่อดู response ให้กับฝั่ง Front-end นั้นเอง
  4. Break compatibility
    • ทุกครั้งที่มีการเปลี่ยนแปลงใน Business layer มันจะเกิดผลกระทบเสมอๆ ลองคิดดูน่ะ สมมุติมี services A ของเรามีการส่งค่า X ออกไปให้กับทุก client services A ที่ request เข้ามา แต่วันนึงเรามา update services A ของเรา โดยเพิ่มค่าที่เป็น requires เข้าไป ทําให้ client services A พังเลยยยย ทีนี้มีบาง services ตายแน่ๆ สิ่งนี้เราต้อง concern เสมอเลยล่ะ ว่าเราต้องคิดถึงเรื่อง Break compatibility รึเปล่า
  5. Business logic in API services
    • แน่นอนแหละ logic เปลี่ยนเรื่อยๆ เพื่อ update ตาม business นั้นเอง อันนี้ไม่ยากเลย ก็แค่เทสตาม business logic อารมณ์เป็น functional test ทั่วไปเนี่ยแหละ 🙂 แค่ให้ผลลัพธ์ถูกต้องนั้นเอง
  6. Integration testing
    • สมัยนี้ทุกอย่างเป็น mircroservices system ทั้งนั้น เพราะฉะนั้นการเปลี่ยนแปลฝั่ง Business Layer ย่อมอาจจะมีผลกระทบกับอีก services นึง เช่น การที่จะ response ลูกค้าได้ จาก services A ของเราต้องไปเรียก B และ C แต่ถ้าเราไม่คํานึงถึงตรงนี้มันจะส่งผลให้ เมื่อเรามีการเปลี่ยนแปลง Business Logic ของเรา มันจะทําให้ A ไม่ compatibility กับ B และส่งผลให้ request failed ได้

นี้เป็นเรื่องหลักๆเลยของการทําเทสฝั่ง Business Layer ถ้าสังเกตุจะเห็นว่ามันค่อนข้างแตกต่างมากๆๆกับ Presentation layer เรียกได้ว่าแทบหนังสือคนล่ะเล่มเลยล่ะ 😀

ยิ่งถ้าเป็นเทคโนโลยี ยิ่งไม่ต้องพูดถึงน่ะ ยิ่งแตกต่าง ในส่วนของ Presentation layer เราก็จะนิยมใช้ Selenium ในการจัดการ element และ Validate แต่พอมาเป็น Business Layer สิ่งที่เราต้องรู้มีหลายอย่างสุดๆ หลากหลายมาก เช่น

  1. SQL command
    • อย่างที่บอก Business Layer ต้องเชื่อมต่อกับ Database Layer เพื่อตรวจสอบ Database configuration เพราะฉะนั้นถ้ามันเชื่อมต่อ แปลว่าเราต้องรู้ command ในการที่จะเข้าไป query database ต่างๆดู อาจจะรวมถึงการเขียน Store procedure ทิ้งไว้ใน Database เพื่อใช้ในการจัดการข้อมูลต่างๆอย่างรวดเร็ว (store procedure อารมณ์ประมาณว่า sql function ที่ resuable นั้นเอง)
    • อารมณ์พวก Extract data ออกจาก Big Data เดี๋ยวนี้ยิ่งฮิตเลยล่ะ เพราะเดี๋ยวนี้บริษัทส่วนใหญ่นี้ Hadoop มาก่อนเลยล่ะ
  2. Programming / Scripting
    • จริงๆๆข้อนี้ฝั่ง Presentation layer ก็ต้องรู้นะ QA ต้องเขียนโค้ด้ได้บอกเลย 🙂 เพียงแต่ฝั่งของ Business Layer อาจจะต้องเขียนมากหน่อยเพื่อใช้ในการทํา integration test (ยิ่งเดี๋ยวนี้เป็น mircroservices system ทุกอย่าง เรายิ่งต้อง concern เรื่อง integration มากๆเลย) / regression test หรือ แม้แต่ test tools เพื่อช่วยให้เราสามารถตรวจสอบความถูกต้องของระบบได้นั้นเอง
    • ไม่มีการยึดติดกับภาษาใดๆ หรือ Framework ใดๆ น่ะ เพราะแต่ละภาษามีข้อดีข้อเสีย จุดมุ่งหมายแตกต่างกันไปในแต่ละส่วนน่ะ บางทีอาจจะต้องเขียน Script เพื่อให้ Jenkins เอาไปใช้้ในการ Prepare test data ก็เป็นได้ C#, Python มาหมด (แตกต่างกับทางฝั่ง Front อันนี้ Selenium มารัวๆ แทบขาดไม่ได้)
  3. Request generator tools (Postman)
    • API services ก็น่ะ เราต้องจําลอง request เข้าไปเพื่อทดสอบระบบอยู่แล้วล่ะ เพราะฉะนั้น tools ต่างๆอย่าง Postman เราควรที่จะรู้ไว้อยู่แล้วล่ะ ซึ่งในบทความถ้าได้อ่านจะเห็นว่าเจ้า Postman เนี่ยมันสามารถช่วยจัดการ generate scripts ให้เราใช้ในการ test ได้ด้วยน่ะ ช่วยประหยัดเวลมากๆ หรือจะเขียน Script testing สั้นๆบน Postman ยังได้เลย
    • ส่วนใหญ่เราเอามาใช้การวิเคราะห์ request – response ไปที่ services ใดๆกัน
  4. Unix command
    • แน่นอนแหละ Business Layer มันก็เป็นเรื่องของ server กับ cluster อยู่แล้วล่ะ ทีนี้แปลว่าไร? แปลว่าเราเข้าไป Investigate อะไรบน server เราคงไม่คาดหวังว่ามันจะเป็น window server เนอะ แบบมี UI ให้เราเลือกกดจิ้มๆๆอย่างสนุกสนานนั้นเอง มันเป็น Unix หมดอยู่แล้วล่ะ เพราะฉะนั้นไปอ่านบทความนี้เลย Unix for beginner 101 หรือแม้แต่เรื่องของ VIM ที่เราต้องใช้ในการดู conf. file

สรุปแล้ว ยาวไปละ

บทความนี้ก็แสดงให้เห็นว่าความแตกต่างระหว่างการเทส Presentation Layer กับ Business Layer แล้ว ซึ่งเวลาเราทํางานในส่วนไหนๆ เราต้องคํานึงถึงจุดที่กล่าวไปทั้งหมด เพราะมันจะช่วยให้เราสามารถตี scope งานของเราได้นั้นเอง 🙂

แต่อย่าลืมน่ะงานแบบนี้ไม่ควรจะเป็น manual ให้คนมานั่งทําน่ะ เราควรจะพยายามทําทุกอย่างที่เป็น repeated work ให้กลายเป็น automate มากที่สุดที่ทําได้เลย แล้วสิ่งที่ QA ควรจะทําคือแค่ Provide concern ให้กับทาง PO หรือ dev. มากกว่า 🙂

2
Leave a Reply

avatar
1 Comment threads
1 Thread replies
0 Followers
 
Most reacted comment
Hottest comment thread
2 Comment authors
Martaaa Recent comment authors

This site uses Akismet to reduce spam. Learn how your comment data is processed.

newest oldest most voted
aaa
aaa

5,000 * 30 = 15,000 ???