ชื่อที่กำหนดให้กับการทดสอบประเภทต่างๆ มีแนวโน้มที่จะมีธีมร่วมกันในฐานของโค้ด แต่ไม่มีคำจำกัดความที่เข้มงวดเป็นพิเศษ หลักสูตรนี้มีหลักเกณฑ์บางอย่างเกี่ยวกับความหมายของการทดสอบแต่ละประเภท แต่แหล่งข้อมูลอื่นๆ อาจมีคำจำกัดความที่แตกต่างกัน
ในหน้าก่อนๆ มีตัวอย่างของทั้งการทดสอบ 1 หน่วยและการทดสอบคอมโพเนนต์ (ในตัวอย่างนี้หมายถึงคอมโพเนนต์รีแอ็กชัน) เราสามารถวางทั้ง 2 แบบให้อยู่ในระดับต่ำในพีระมิดทดสอบ (หรือรูปทรงอื่นๆ) ได้เนื่องจากมีความซับซ้อนต่ำและใช้งานได้เร็ว แต่อาจไม่มีประโยชน์มากเท่ากับการทดสอบการผสานรวมที่ซับซ้อนกว่า
ประเภทการทดสอบที่พบบ่อย
แบบทดสอบ 1 หน่วย
การทดสอบ 1 หน่วยมีขนาดเล็กที่สุดในขอบเขต อัลกอริทึมเหล่านี้มักใช้ในการทดสอบส่วนเล็กๆ ของโค้ด หรือโค้ดแบบไม่เก็บสถานะทั้งหมด ในลักษณะที่เกือบในทางคณิตศาสตร์คือ หากฉันใส่โค้ดที่มีอินพุต X, Y และ Z เอาต์พุตควรเป็น A, B และ C
โดยปกติโค้ดที่มีการทดสอบ 1 หน่วยจะไม่มีทรัพยากร Dependency ภายนอก เช่น การดึงข้อมูลจากเครือข่ายหรือการใช้ฟังก์ชันหรือไลบรารีอื่นๆ โดยปริยาย ซึ่งจะเป็นโหนดต้นไม้ของโค้ดที่คุณ "ตัดออก" และทดสอบได้ด้วยตัวเอง
แม้ว่าการทดสอบ 1 หน่วยจะเป็นเรื่องง่ายๆ ที่จะเขียนและทำการทดสอบ แต่ก็เป็นไปได้ที่การทดสอบโค้ดหน่วยเล็กๆ อาจไม่ได้ให้ข้อมูลที่เป็นประโยชน์ บ่อยครั้งที่หน่วยโค้ดไม่มีการโต้ตอบกับโค้ดอื่นๆ หมายความว่าคุณควรทดสอบในระดับที่สูงกว่าเพื่อลดความเสี่ยง
การทดสอบคอมโพเนนต์
สำหรับนักพัฒนาเว็บ ชื่อ "คอมโพเนนต์" จะมีปริมาณมากเกินไป ซึ่งมักจะหมายถึงคอมโพเนนต์ที่ผู้ใช้มองเห็นได้ เช่น คอมโพเนนต์รีแอ็กชันหรือคอมโพเนนต์เว็บ แต่คำจำกัดความที่กว้างกว่าคือส่วนของงานที่ทดสอบได้ เช่น คลาสที่มีทรัพยากร Dependency ภายนอก เพื่อให้ทดสอบได้อย่างมีประสิทธิภาพ คอมโพเนนต์นี้ต้องจำลองหรือข้ามการขึ้นต่อกันของคอมโพเนนต์
เนื่องจากแนวทางปฏิบัติในการพัฒนาเว็บสมัยใหม่มีพื้นฐานมาจากแนวคิดของคอมโพเนนต์ การทดสอบคอมโพเนนต์จึงเป็นวิธีที่ควรพิจารณาเกี่ยวกับการทดสอบ เช่น คุณอาจตัดสินใจว่าองค์ประกอบแต่ละอย่างจะต้องการทดสอบ คุณสามารถติดตามผลการทดสอบคอมโพเนนต์ได้ง่ายๆ ในบริบทที่นักพัฒนาซอฟต์แวร์คนเดียวหรือทีมขนาดเล็กอ้างสิทธิ์การเป็นเจ้าของคอมโพเนนต์อย่างชัดเจน แต่การจำลองการอ้างอิงที่ซับซ้อน อาจเป็นเรื่องยาก
การทดสอบการผสานรวม
การทดสอบเหล่านี้มักจะทดสอบการจัดกลุ่มคอมโพเนนต์ โมดูล ระบบย่อย หรือส่วนอื่นๆ ที่มีความหมายของโค้ดไว้ด้วยกันในกลุ่มเล็กๆ รวมกันเพื่อให้แน่ใจว่าทำงานได้อย่างถูกต้อง นี่เป็นคำจำกัดความที่คลุมเครือมาก สำหรับนักพัฒนาเว็บ ลองจินตนาการว่าโค้ดที่คุณกำลังทดสอบไม่ใช่เวอร์ชันจริงของเว็บไซต์ (หรือแม้แต่ปิด) แต่ยังคงเชื่อมต่อองค์ประกอบต่างๆ ที่เกี่ยวข้องในระบบของคุณ
ซึ่งอาจรวมถึงทรัพยากร Dependency "จริง" เช่น ฐานข้อมูลภายนอกในโหมดทดสอบ แทนที่จะเป็นการจำลองเพียงอย่างเดียว ตัวอย่างเช่น แทนที่จะระบุว่า query() จะแสดงผล 2 รายการที่เหมือนกันเสมอ การทดสอบการผสานรวมสามารถยืนยันได้ว่าฐานข้อมูลทดสอบมีบางอย่างอยู่ในนั้น ข้อมูลจะมีความสำคัญน้อยกว่า แต่ตอนนี้คุณกำลังทดสอบว่าฐานข้อมูลสามารถเชื่อมต่อและค้นหาได้อย่างประสบความสำเร็จ
คุณอาจเขียนการทดสอบการผสานรวมที่ค่อนข้างง่ายซึ่งมีผลกระทบในวงกว้าง ซึ่งสามารถตรวจสอบได้โดยใช้การยืนยัน เนื่องจากการดำเนินการเดียวที่เชื่อมโยงกับองค์ประกอบหลายรายการอาจทำให้เกิดผลกระทบที่วัดได้
ด้วยเหตุนี้ การทดสอบการผสานรวมสามารถแสดงให้เห็นได้อย่างมีประสิทธิภาพว่าระบบที่ซับซ้อนของคุณจะทำงานตามที่ต้องการ แต่การเขียนและดูแลรักษาเป็นเรื่องยาก
และอาจสร้างความซับซ้อนโดยไม่จำเป็น เช่น การเขียน FakeUserService สำหรับการทดสอบการผสานรวมจะเพิ่มข้อกำหนดว่าทั้งเมธอดและ RealUserService จะต้องใช้ UserService
การทดสอบควัน
การทดสอบเหล่านี้ควรเสร็จสิ้นอย่างรวดเร็วและพิจารณาว่าโค้ดเบสของคุณอยู่ในสถานะที่เหมาะสมหรือไม่ ในทางปฏิบัติแล้ว โดยส่วนใหญ่แล้วจะหมายถึงการทดสอบโค้ดง่ายๆ ที่ส่งผลต่อประสบการณ์การใช้งานในวงกว้าง
ตัวอย่างเช่น ในเว็บแอปขนาดใหญ่ที่มีการลงชื่อเข้าใช้ วิธีนี้ช่วยดูแลให้ระบบเข้าสู่ระบบและการตรวจสอบสิทธิ์ทำงานได้ เพราะหากไม่มีแอปก็จะใช้งานไม่ได้และการทดสอบอื่นๆ ก็ไม่เกี่ยวข้อง
การทดสอบแบบ Smoke เป็นฟีเจอร์ที่เหมาะสมซึ่งควรใช้ใต้สคริปต์ test ของ package.json ในฐานของโค้ดขนาดใหญ่ การทดสอบด้วยตนเองอาจทำหน้าที่เป็นการทดสอบควันประเภทหนึ่งด้วย
การทดสอบการถดถอย
การทดสอบการถดถอยเป็นการทดสอบควันประเภทหนึ่งที่ช่วยให้มั่นใจว่าฟีเจอร์ที่มีอยู่จะยังคงทำงานต่อไป หรือว่าข้อบกพร่องเดิมจะไม่ถูกนำกลับมาใช้อีก หลังจากเปิดตัวใหม่หรือการพัฒนาฟีเจอร์อื่นๆ
ซึ่งเกี่ยวข้องกับแนวคิดการพัฒนาที่ขับเคลื่อนด้วยการทดสอบ (TDD) กรอบการทดสอบที่เขียนขึ้นเพื่อทริกเกอร์ข้อบกพร่องอย่างชัดเจน แล้วนำมาใช้ในภายหลังเพื่อตรวจสอบว่าข้อบกพร่องดังกล่าวได้รับการแก้ไขแล้ว จะถือว่าเป็นกรอบการทดสอบการถดถอย เนื่องจากการมีอยู่ของเคสนั้นๆ จะป้องกันไม่ให้ข้อบกพร่องเดียวกันนั้นกลับมา
อย่างไรก็ตาม การทดสอบการถดถอยอาจเป็นปัญหาได้หากไม่มีวิธีแก้ปัญหาที่ดี คำนี้เป็นคำที่มักอ้างอิงถึงความต้องการทางธุรกิจ เพราะเมื่อมีการพัฒนาฟีเจอร์ คุณลักษณะเดิมๆ ก็สำคัญไม่แพ้กัน Codebase ที่ผ่านการทดสอบมาเป็นอย่างดีควรสามารถรักษาสิ่งนี้ไว้ได้ แต่ฐานของโค้ดจริงก็อาจไม่ได้ตอบโจทย์ความต้องการนั้นเสมอไป เราจะกล่าวถึงเรื่องนี้มากขึ้นในส่วนต่อๆ ไป
การทดสอบด้วยภาพ
การทดสอบภาพเกี่ยวข้องกับการจับภาพหน้าจอหรือวิดีโอสถานะของเว็บไซต์เพื่อตรวจสอบสถานะที่ดีซึ่งเป็นที่รู้จักแล้ว (เช่น ภาพหน้าจอก่อนหน้า) เทียบกับการทดสอบปัจจุบัน โดยปกติแล้ว เบราว์เซอร์ต้องเรียกใช้เพื่อให้แสดงผล HTML, CSS และส่วนอื่นๆ ของเว็บไซต์ได้
แทนที่จะทดสอบการทดสอบแบบปลายทางถึงปลายทางด้วยภาพซึ่งเรียกใช้ฐานของโค้ดทั้งหมด การสร้าง "สายรัด" ของ HTML ที่แสดงเฉพาะองค์ประกอบบางอย่างเท่านั้น โดยเฉพาะในขนาดหน้าจอที่ต่างกันเพื่อให้เรียก UI ที่ปรับเปลี่ยนตามอุปกรณ์ได้ ซึ่งมีความซับซ้อนมากกว่าการใช้ JSDOM หรือเฟรมเวิร์กที่คล้ายกันเพียงอย่างเดียว
การทดสอบภาพที่ไม่ผ่านการตรวจสอบอาจเป็นสัญญาณที่ดีของความเสียหายประเภทอื่นๆ อย่างไรก็ตาม UI ที่ซับซ้อนอาจทดสอบภาพไม่สำเร็จด้วยเหตุผลที่ไม่เกี่ยวข้องกับฟีเจอร์ที่คุณพยายามทดสอบ เช่น ฟีเจอร์ใหม่อื่นๆ ที่เปลี่ยนรูปลักษณ์ของ UI หรือแม้กระทั่งอีโมจิเวอร์ชันใหม่ของระบบปฏิบัติการให้แสดงผลแตกต่างจากเวอร์ชันก่อนหน้า
การทดสอบแบบต้นทางถึงปลายทาง
การทดสอบแบบเอนด์ทูเอนด์มักจะอยู่ที่ด้านบนสุดของพีระมิดทดสอบ ซึ่งจะอธิบายประสบการณ์การโต้ตอบโดยรวมกับเว็บแอปหรือเว็บไซต์ของคุณ อาจมีจุดศูนย์กลางอยู่ที่บางฟีเจอร์ และโดยปกติจะทำงานภายในเบราว์เซอร์ที่ควบคุมโดย Agent เช่น WebdriverIO, Selenium หรือ Puppeteer ซึ่งเรียกใช้ฐานของโค้ดมากขึ้นหรือน้อยลงตามที่มีการนำไปใช้ในเวอร์ชันที่ใช้งานจริง (แม้ว่ามักจะแสดงใน localhost)
ซึ่งอาจรวมถึงการเข้าสู่ระบบในฐานะผู้ใช้ทดสอบ การดำเนินการหลัก และการยืนยันว่าเว็บไซต์หรือระบบของคุณอยู่ในสถานะที่ถูกต้อง ทั้งนี้ขึ้นอยู่กับเว็บไซต์ของคุณ เราจะกล่าวถึงตัวอย่างการทดสอบประเภทนี้เพิ่มเติมในส่วนอื่นๆ เพิ่มเติม เนื่องจากการทดสอบอาจมีประสิทธิภาพมาก แต่ในบางครั้งก็ยากต่อการจัดการ
กลยุทธ์บางอย่างในการลดความซับซ้อนของธุรกิจอาจรวมถึงการลดขอบเขต หรือล้อเลียนองค์ประกอบที่เฉพาะเจาะจงในส่วนที่เกี่ยวข้อง ตัวอย่างเช่น หากผู้ใช้จำเป็นต้องลงชื่อเข้าใช้เว็บไซต์ แต่การลงชื่อเข้าใช้ไม่ใช่ฟีเจอร์ที่คุณกำลังทดสอบ คุณอาจต้องตั้งค่าธงสำหรับสภาพแวดล้อมการทดสอบที่อนุญาตให้ตัวควบคุมการทดสอบทำหน้าที่เป็นผู้ใช้โดยไม่ต้องลงชื่อเข้าใช้หรือสร้างคุกกี้ที่เชื่อมโยง
แม้ว่าการทดสอบแบบเอนด์ทูเอนด์จะเป็นวิธีที่มีประสิทธิภาพมากในการทดสอบกับฐานของโค้ดแบบข้ามส่วนขนาดใหญ่พร้อมๆ กัน แต่การทดสอบขนาดใหญ่ดังกล่าวมีความเสี่ยงที่ไม่น่าเชื่อถือหรือไม่น่าเชื่อถือเนื่องจากต้องอาศัยระบบภายนอก นอกจากนี้ยังอาจปล่อยข้อมูลการทดสอบจำนวนมากไว้ในฐานข้อมูล เช่น หากการทดสอบทุกครั้งสร้างหรือแก้ไขข้อมูล การสะสมข้อมูลที่เหลือเช่นนี้ทำให้ยากต่อการพิจารณาการทดสอบ
การทดสอบ API
การทดสอบ API อาจหมายถึงการยืนยันการทำงานของ API ที่ซอฟต์แวร์มีให้ หรือการเข้าถึง API ในชีวิตจริง (อาจเผยแพร่อยู่) เพื่อยืนยันลักษณะการทำงาน ไม่ว่าจะเป็นลักษณะใดก็ตาม วิธีนี้มักจะทดสอบนามธรรมระหว่างระบบต่างๆ ว่าจะสื่อสารถึงกันอย่างไรในท้ายที่สุด โดยไม่ต้องผสานรวมระบบทั้งสองเข้าด้วยกันเหมือนในการทดสอบการผสานรวม
การทดสอบเหล่านี้จะเป็นข้อมูลเบื้องต้นของการทดสอบการผสานรวมโดยไม่ต้องมีค่าใช้จ่ายในการเรียกใช้ระบบที่คุณกำลังทดสอบการเชื่อมต่อ แต่การทดสอบระบบในชีวิตจริงอาจไม่น่าเชื่อถือ
ประเภทอื่นๆ
มีวิธีอื่นๆ ในการทดสอบที่อาจเป็นประโยชน์โดยขึ้นอยู่กับแหล่งที่มา ตัวอย่างที่น่าสนใจมีดังนี้
- การทดสอบด้วยตนเอง
- การทดสอบการยอมรับ ซึ่งเป็นการทดสอบด้วยตนเองประเภทหนึ่งที่ Agile ได้รับความนิยม ช่วยยืนยันว่าผลิตภัณฑ์ "ตรงตามความต้องการของผู้ใช้"
- การทดสอบความวุ่นวายหมายถึงการป้อนข้อมูลแบบสุ่มเพื่อดูสิ่งที่เกิดขึ้น เพื่อให้แน่ใจว่าเว็บไซต์จะไม่ขัดข้องหากป้อนข้อมูลไม่ถูกต้อง
- การทดสอบที่ไม่สำเร็จโดยเจตนาจะจำลองความล้มเหลวในระบบที่ซับซ้อน เช่น ความล้มเหลวของเครือข่าย เพื่อให้แน่ใจว่าโค้ดภายใต้การทดสอบจะตอบสนองด้วยวิธีที่มีการควบคุม
- การทดสอบบิลด์จะยืนยันว่าสามารถสร้างอาร์ติแฟกต์ของบิลด์ของ Codebase ได้ โดยตรวจสอบว่ามีอาร์ติแฟกต์อยู่หรือเนื้อหาคืออะไร การทดสอบประเภทนี้อาจมีประโยชน์สำหรับการตรวจสอบเอาต์พุตของ CMS ที่ซับซ้อน
การครอบคลุมของโค้ด
คุณสามารถวัดเปอร์เซ็นต์ของโค้ดที่มีการทดสอบโดยการทดสอบอัตโนมัติ แล้วรายงานไว้เป็นสถิติเมื่อเวลาผ่านไป เราไม่แนะนำให้กำหนดเป้าหมายการครอบคลุมของโค้ด 100% เนื่องจากอาจทำให้เกิดค่าใช้จ่ายที่ไม่จำเป็น รวมถึงการทดสอบที่ง่ายดายหรือออกแบบมาไม่ดีซึ่งไม่ครอบคลุมกรณีการใช้งานหลักๆ
การครอบคลุมก็เป็นเครื่องมือที่มีประโยชน์เมื่อเขียนหรือทำการทดสอบ โดยเฉพาะอย่างยิ่งการทดสอบการผสานรวม การแสดงรายละเอียดแบบเปอร์เซ็นต์หรือแบบบรรทัดต่อบรรทัดของโค้ดที่ทดสอบโดยการทดสอบรายการเดียว จะทำให้คุณได้ข้อมูลเชิงลึกเกี่ยวกับสิ่งที่ยังขาดไปหรือสิ่งที่สามารถทดสอบต่อไปได้
แหล่งข้อมูล
ทดสอบความเข้าใจ
ข้อใดต่อไปนี้เป็นประเภทการทดสอบที่ทราบ