การทดสอบอัตโนมัติที่ใช้กันทั่วไปมี 3 ประเภท

เรามาเริ่มที่เรื่องพื้นฐานกันก่อน สํารวจโหมดการทดสอบทั่วไป 2 โหมดและการทดสอบอัตโนมัติทั่วไป 3 ประเภท

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

ตู้เก็บของที่มี 2 ลิ้นชักซึ่งเปิดพร้อมกันไม่ได้

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

ตู้เก็บของเหมือนกันแต่มี 2 ลิ้นชักที่เปิดพร้อมกันได้

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

พูดง่ายๆ คือคุณต้องมีแผนก่อนที่จะเริ่มเขียนโค้ดการทดสอบจริง ในการเริ่มหัวข้อวิธีทดสอบในทางปฏิบัติ ให้เริ่มต้นด้วยแถบสเลทที่ถูกต้องและตอบคำถามพื้นฐาน 2 ข้อ:

  • คุณต้องการทดสอบอย่างไร
  • คุณต้องการทดสอบอะไร

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

เริ่มต้นด้วยโหมดทดสอบทั่วไป

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

การทดสอบด้วยตนเองเทียบกับการทดสอบอัตโนมัติ

หากคุณขอให้วิศวกรการประกันคุณภาพกำหนดการทดสอบ พวกเขาอาจแบ่งการทดสอบออกเป็น 2 "โหมด" ก่อน ได้แก่

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

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

กล่องทึบกับกล่องใส

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

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

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

ประเภทการทดสอบอัตโนมัติ: คุณต้องการทดสอบอย่างไร

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

ตามที่ได้อธิบายไว้ในมีมที่พูดถึงก่อนหน้านี้ คุณมี 2 ประเภท ได้แก่ การทดสอบ 1 หน่วย และการทดสอบการผสานรวม การทดสอบแบบเอนด์ทูเอนด์เป็นการทดสอบที่สำคัญอันดับ 3 ที่ควรคำนึงถึง แต่ยังไม่หมดเพียงเท่านี้ มาดูรายละเอียดกันเลย

การทดสอบ 1 หน่วย

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

ภาพที่เรียบง่ายของการทดสอบ 1 หน่วยซึ่งแสดงอินพุตและเอาต์พุต

การทดสอบการผสานรวม

การทดสอบการผสานรวมจะเน้นที่การโต้ตอบระหว่างคอมโพเนนต์หรือระบบ กล่าวอีกนัยหนึ่งคือ เครื่องมือเหล่านี้ทำงานร่วมกันได้ดีเพียงใด ตัวอย่างทั่วไปของการทดสอบการผสานรวมคือการทดสอบ API หรือการทดสอบองค์ประกอบ

ภาพแบบเข้าใจง่ายของการทดสอบการผสานรวมที่แสดงให้เห็นว่าหน่วย 2 หน่วยทำงานร่วมกันอย่างไร

การทดสอบแบบต้นทางถึงปลายทาง

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

ภาพการทดสอบแบบรอบด้านแบบเรียบง่ายที่แสดงคอมพิวเตอร์เป็นหุ่นยนต์ขณะดูเวิร์กโฟลว์

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

การทดสอบ UI ของภาพ

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

การวิเคราะห์แบบคงที่

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

การทดสอบในทุกรูปแบบ: ทั้งหมดนี้ทำงานร่วมกันอย่างไร

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

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

กลยุทธ์ 5 ข้อที่แสดงในรูปภาพนี้เป็นกลยุทธ์ที่พบบ่อยที่สุด

  • ทดสอบพีระมิด
  • เพชรทดสอบ
  • Test Ice Cone (หรือที่เรียกว่า Test Pizza)
  • ทดสอบ Honeycomb
  • ถ้วยรางวัลสำหรับทดสอบ

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