ประเภทของการทดสอบที่เกี่ยวข้องกับการเปลี่ยนแปลง การทดสอบควันระหว่างการสร้างซอฟต์แวร์รายวัน

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

การทดสอบควัน:

การทดสอบควันจะดำเนินการเพื่อให้แน่ใจว่าโครงสร้างผลลัพธ์นั้นเหมาะสำหรับการทดสอบ เรียกอีกอย่างว่าการยืนยันแบบ "ศูนย์วัน"

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

การทดสอบด้านสุขอนามัย:

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

ตัวอย่างเพื่อให้เข้าใจถึงความแตกต่างระหว่างการทดสอบควันและการทดสอบด้านสุขอนามัยได้ดีขึ้น:

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

ข้อแตกต่างเพิ่มเติมเล็กน้อยระหว่างการทดสอบควันและการทดสอบด้านสุขอนามัย:

• การทดสอบควันดำเนินการโดยทั้งนักพัฒนาและผู้ทดสอบ
• การทดสอบด้านสุขอนามัยดำเนินการโดยผู้ทดสอบเท่านั้น

• การทดสอบควันครอบคลุมฟังก์ชันหลักทั้งหมดของแอปพลิเคชันตั้งแต่ต้นจนจบ
• การทดสอบด้านสุขอนามัยจะทดสอบเฉพาะส่วนประกอบของการใช้งานเท่านั้น

• การทดสอบควันผ่านทั้งบิลด์ที่เสถียรและไม่เสถียร
• โครงสร้างเวอร์ชันที่ค่อนข้างเสถียรอยู่ระหว่างการทดสอบด้านสุขอนามัย

Kirill Flyagin ผู้ออกแบบเกม หัวหน้าฝ่าย QA

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

• การทดสอบควันในไฟล์ศัพท์เฉพาะ (ภาษาอังกฤษ)

มูลนิธิวิกิมีเดีย 2010.

ดูว่า "การทดสอบควัน" ในพจนานุกรมอื่น ๆ คืออะไร:

การทดสอบควัน- คำนาม วิธีทดสอบรอยรั่วในท่อระบายน้ำหรือปล่องไฟโดยการแนะนำควันหนาทึบ มักใช้ระเบิดควัน รายการหลัก: ควัน … พจนานุกรมภาษาอังกฤษที่มีประโยชน์

การทดสอบควัน- การทดสอบเพื่อตรวจสอบความสมบูรณ์ของการเผาไหม้... พจนานุกรมศัพท์เกี่ยวกับยานยนต์

การทดสอบควัน- 1. คำนาม ก) การทดสอบการรั่วไหลที่เกี่ยวข้องกับการเป่าควันเข้าไปในท่อหรือท่อ b) การทดสอบเบื้องต้นกับชิ้นส่วนอิเล็กทรอนิกส์ที่สร้างขึ้นใหม่ ซึ่งประกอบด้วยการใช้พลังงานไฟฟ้าเพียงอย่างเดียว เพื่อให้แน่ใจว่าไม่มีการเดินสายไฟร้ายแรง… … วิกิพจนานุกรม

การทดสอบควัน- เป็นคำที่ใช้ในงานประปา การซ่อมแซมเครื่องเป่าลมไม้ อิเล็กทรอนิกส์ การพัฒนาซอฟต์แวร์คอมพิวเตอร์ และอุตสาหกรรมบันเทิง หมายถึงการทดสอบครั้งแรกหลังการซ่อมแซมหรือการประกอบครั้งแรกเพื่อให้ความมั่นใจว่าระบบที่ทดสอบจะ... ... Wikipedia

การทดสอบควัน- bzw. Rauchtest ist ein Begriff aus dem Englischen, gebräuchlich im handwerklichen Bereich (z. B. in der Klempnerei, Elektronik หรือ beim Bau von Holzblasinstrumenten) wie auch in der Softwareentwicklung. Es bezeichnet den ersten… … วิกิพีเดียภาษาเยอรมัน

ควัน- คือการสะสมของอนุภาคและก๊าซที่เป็นของแข็งและของเหลวในอากาศ [คู่มือ SFPE ของวิศวกรรมป้องกันอัคคีภัย] ที่ปล่อยออกมาเมื่อวัสดุผ่าน... … Wikipedia

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

ระเบิดควัน- ระเบิดควันคือพลุที่ออกแบบมาเพื่อสร้างควันเมื่อจุดไฟ แม้ว่าจะมีอุปกรณ์สร้างควันที่ตกลงมาจากเครื่องบิน คำว่า ระเบิดควัน ใช้เพื่ออธิบายอุปกรณ์สามประเภท:# ลูกบอลควันเป็นรูปเชอร์รี่กลวง… … Wikipedia

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

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

ข้อดี. กระบวนการง่ายๆ นี้ให้ประโยชน์ที่สำคัญหลายประการ

การลดความเสี่ยงระหว่างการรวมระบบ

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

การประกอบและการทดสอบควันในแต่ละวันช่วยลดความเสี่ยงของข้อผิดพลาดในการรวมระบบ ตอบสนองต่อข้อผิดพลาดได้ทันท่วงที และป้องกันการสะสม

การลดความเสี่ยงของผลิตภัณฑ์ซอฟต์แวร์คุณภาพต่ำ

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

ช่วยในการวินิจฉัยข้อผิดพลาด

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

ขวัญกำลังใจดีขึ้น

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

ใช้การทดสอบบิลด์และควันรายวัน

นี่คือรายละเอียดบางส่วนของหลักการนี้

การสร้างแอปพลิเคชันรายวัน

ส่วนพื้นฐานของการประกอบในแต่ละวันคือการประกอบชิ้นส่วนที่เสร็จสมบูรณ์ครั้งล่าสุด Jim McCarthy เขียนใน Dynamics of Software Development (Microsoft Press, 1995) เรียกการสร้างโครงการรายวันว่าเป็นหัวใจสำคัญของโครงการ ถ้าไม่มีหัวใจ ไม่มีโปรเจ็กต์ ก็ตายไป หากเปรียบเปรยน้อยกว่า Michael Cusumano และ Richard W. Selby บรรยายถึงการสร้างในแต่ละวันว่าเป็นแรงกระตุ้นที่ประสานกันของโครงการ (Microsoft Secrets, The Free Press, 1995) นักพัฒนาแต่ละคนเขียนโค้ดด้วยวิธีของตนเอง และโค้ดอาจไปไกลกว่ากรอบงานที่ยอมรับโดยทั่วไปสำหรับโครงการ ซึ่งเป็นเรื่องปกติ แต่เมื่อสัมผัสกับพัลส์ที่ซิงโครไนซ์แต่ละครั้ง โค้ดจะกลับสู่มาตรฐาน ด้วยการยืนกรานในการพัฒนาโดยใช้พัลส์การซิงโครไนซ์อย่างต่อเนื่อง คุณจะป้องกันไม่ให้โปรเจ็กต์ออกจากการซิงโครไนซ์โดยสิ้นเชิง

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

กำลังตรวจสอบบิลด์ที่ล้มเหลว

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

แต่ละโครงการมีมาตรฐานของตัวเองและมีสัญลักษณ์ที่เรียกว่า "การแตกหักระหว่างการประกอบ" มาตรฐานนี้ควรกำหนดระดับคุณภาพที่เพียงพอในการติดตามข้อบกพร่องเล็กๆ น้อยๆ และไม่มองข้ามข้อบกพร่องที่ "ขัดขวาง" โครงการ

โครงสร้างที่ดีคือโครงสร้างที่มีอย่างน้อย:

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

การทดสอบควันทุกวัน

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

จุดประกอบรายวันจะหายไปหากไม่มีการทดสอบควัน กระบวนการนี้ปกป้องคุณภาพของผลิตภัณฑ์และไม่อนุญาตให้เกิดปัญหาในการรวมระบบใดๆ หากไม่มีสิ่งนี้ กระบวนการสร้างรายวันจะเสียเวลา โดยมีจุดประสงค์เพื่อตรวจสอบการคอมไพล์

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

การกำหนดกลุ่มบิลด์

ในโครงการส่วนใหญ่ จะมีบุคคลเฉพาะที่รับผิดชอบในการตรวจสอบการสร้างระบบรายวันและดำเนินการทดสอบควัน งานนี้เป็นส่วนหนึ่งของหน้าที่ของพนักงานคนนี้ แต่ในโครงการขนาดใหญ่ อาจมีพนักงานประเภทนี้มากกว่านี้และงานดังกล่าวถือเป็นความรับผิดชอบหลักของพวกเขา ตัวอย่างเช่น ทีมงานสร้างโครงการ Windows NT 3.0 มีสี่คน (Pascal Zachary, โชว์สต็อปเปอร์!, The Free Press, 1994)

เพิ่มการแก้ไขให้กับบิลด์หากสมเหตุสมผลเท่านั้น

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

แนะนำระบบบทลงโทษสำหรับความล้มเหลวในการปล่อยบิลด์ถัดไป (การรีลีสของบิลด์ที่ไม่ทำงาน)

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

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

แต่ในบางโครงการก็มีบทลงโทษที่ร้ายแรงกว่านี้ ตัวอย่างเช่น นักพัฒนา Microsoft ที่ทำงานในโครงการที่มีลำดับความสำคัญสูง (Windows NT, Windows 95, Excel) สวมเพจเจอร์ และหากตรวจพบการตรวจสอบ พวกเขาจะต้องรายงานการทำงาน แม้จะพบเหตุขัดข้องหรือข้อผิดพลาดในเวลาตี 3 ก็ตาม

ประกอบระบบและ "รมควัน" แม้อยู่ภายใต้ความกดดัน

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

ใครได้ประโยชน์จากกระบวนการนี้? นักพัฒนาซอฟต์แวร์บางรายประท้วงต่อต้านการสร้างรายวัน โดยอ้างเหตุผลในการประท้วงเนื่องจากกิจกรรมนี้ทำไม่ได้และการลงทุนครั้งใหญ่ แต่ระบบที่ซับซ้อนทั้งหมดในยุคหลังนั้นต้องผ่านการประกอบและการทดสอบควันทุกวัน เมื่อถึงเวลาออกพรรษา ไมโครซอฟต์ วินโดวส์ NT 3.0 มี 5.6 ล้านบรรทัดใน 40,000 ไฟล์ การสร้างเสร็จสมบูรณ์ใช้เวลา 19 ชั่วโมงและดำเนินการบนคอมพิวเตอร์หลายเครื่อง อย่างไรก็ตาม นักพัฒนาก็สามารถประกอบระบบได้ทุกวัน ในฐานะทีมงานมืออาชีพ ทีมพัฒนา NT ประสบความสำเร็จอย่างมากจากการสร้างในแต่ละวัน นักพัฒนาที่ทำงานในโครงการที่ซับซ้อนน้อยกว่าและไม่ได้ใช้ประโยชน์จากกระบวนการสร้างรายวันควรพิจารณาหาคำอธิบายที่สมเหตุสมผล

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

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

การทดสอบควันคืออะไร

คำนี้ใช้ครั้งแรกโดยคนทำเตา โดยประกอบเตาแล้วปิดปลั๊กทั้งหมด เติมให้ท่วม และตรวจดูให้แน่ใจว่าควันมาจากที่ที่กำหนดเท่านั้น วิกิพีเดีย

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

ลองดูตัวอย่างง่ายๆ แอปพลิเคชันของเราเวอร์ชันก่อนการผลิตอยู่ที่ bryak.com (ความคล้ายคลึงกับไซต์จริงใด ๆ จะเป็นแบบสุ่ม) เราได้เตรียมและอัปโหลดรุ่นใหม่สำหรับการทดสอบที่นั่น สิ่งที่คุณควรตรวจสอบก่อน? ฉันจะเริ่มต้นด้วยการตรวจสอบว่าแอปพลิเคชันยังคงเปิดอยู่ หากเว็บเซิร์ฟเวอร์ตอบเราว่า "200" แสดงว่าทุกอย่างเรียบร้อยดีและเราสามารถเริ่มตรวจสอบการทำงานได้

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

การทดสอบควันครั้งแรกของเรา

ที่ Badoo ฝั่งเซิร์ฟเวอร์จะเขียนด้วย PHP เป็นส่วนใหญ่ ด้วยเหตุผลที่ชัดเจนจึงมีการเขียน Unit Tests ลงไป ดังนั้นเราจึงมี PHPUnit อยู่แล้ว เพื่อไม่ให้เทคโนโลยีทวีคูณโดยไม่จำเป็น เราจึงตัดสินใจเขียนการทดสอบควันใน PHP ด้วย นอกจาก PHPUnit แล้ว เรายังต้องการไลบรารีไคลเอนต์สำหรับการทำงานกับ URL (libcurl) และส่วนขยาย PHP สำหรับการทำงานกับมัน - cURL

โดยพื้นฐานแล้ว การทดสอบเพียงส่งคำขอที่เราต้องการไปยังเซิร์ฟเวอร์และตรวจสอบคำตอบ ทุกอย่างเชื่อมโยงกับเมธอด getCurlResponse() และการยืนยันหลายประเภท

วิธีการนั้นมีลักษณะดังนี้:

ฟังก์ชั่นสาธารณะ getCurlResponse($url, array $params = [ 'cookies' => , 'post_data' => , 'headers' => , 'user_agent' => , 'proxy' => , ], $follow_location = true, $ คาดหวัง_ตอบกลับ = '200 ตกลง') ( $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, $url); curl_setopt($ch, CURLOPT_HEADER, 1); curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); if (isset( $params['cookies']) && $params['cookies']) ( $cookie_line = $this->prepareCookiesDataByArray($params['cookies']); curl_setopt($ch, CURLOPT_COOKIE, $cookie_line); ) ถ้า ( isset($params['headers']) && $params['headers']) ( curl_setopt($ch, CURLOPT_HTTPHEADER, $params['headers']); ) if (isset($params['post_data']) && $params['post_data']) ( $post_line = $this->preparePostDataByArray($params['post_data']); curl_setopt($ch, CURLOPT_POST, 1); curl_setopt($ch, CURLOPT_POSTFIELDS, $post_line); ) ถ้า ($follow_location) ( curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1); ) if (isset($params['proxy']) && $params['proxy']) ( curl_setopt($ch, CURLOPT_PROXY, $params['proxy) ']); ) if (isset($params['user_agent']) && $params['user_agent']) ( $user_agent = $params['user_agent']; ) else ( $user_agent = USER_AGENT_DEFAULT; ) curl_setopt($ch, CURLOPT_USERAGENT, $user_agent); curl_setopt($ch, CURLOPT_AUTOREFERER, 1); $response = curl_exec($ch); $this->logActionToDB($url, $user_agent, $params); if ($follow_location) ($this->assertTrue((bool)$response, "ได้รับการตอบกลับที่ว่างเปล่า ข้อผิดพลาด Curl: " .curl_error($ch) . ", errno: " .curl_errno($ch)); $this ->assertServerResponseCode($ตอบกลับ, $expected_response ) curl_close($ch); ส่งคืน $ ตอบกลับ; -
วิธีการนี้สามารถส่งคืนการตอบสนองของเซิร์ฟเวอร์ตาม URL ที่กำหนด ยอมรับพารามิเตอร์เป็นอินพุต เช่น คุกกี้ ส่วนหัว ตัวแทนผู้ใช้ และข้อมูลอื่น ๆ ที่จำเป็นในการสร้างคำขอ เมื่อได้รับการตอบกลับจากเซิร์ฟเวอร์ วิธีการจะตรวจสอบว่ารหัสตอบกลับตรงกับที่คาดไว้ หากไม่เป็นเช่นนั้น การทดสอบจะล้มเหลวโดยมีข้อผิดพลาดระบุสิ่งนี้ ซึ่งทำเพื่อให้ระบุสาเหตุของการล้มได้ง่ายขึ้น หากการทดสอบล้มเหลวในการยืนยันบางอย่าง โดยแจ้งให้เราทราบว่าไม่มีองค์ประกอบใดในหน้าเว็บ ข้อผิดพลาดจะมีข้อมูลน้อยกว่าข้อความที่โค้ดตอบกลับ เช่น "404" แทนที่จะเป็น "200" ที่คาดไว้

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

การทดสอบที่ง่ายที่สุดมีลักษณะดังนี้:

ฟังก์ชั่นสาธารณะ testStartPage() ( $url = 'bryak.com'; $response = $this->getCurlResponse($url); $this->assertHTMLPresent("
การทดสอบนี้ใช้เวลาไม่ถึงหนึ่งวินาที ในระหว่างนี้ เราได้ตรวจสอบแล้วว่าหน้าเริ่มต้นตอบสนองด้วย "200" และมีองค์ประกอบเนื้อหา ด้วยความสำเร็จเดียวกัน เราสามารถทดสอบองค์ประกอบจำนวนเท่าใดก็ได้บนหน้าเว็บ ระยะเวลาของการทดสอบจะไม่เปลี่ยนแปลงอย่างมีนัยสำคัญ

ข้อดีของการทดสอบดังกล่าว:

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

ว่าด้วยประเด็นสุดท้าย. ฉันหมายถึงไม่มั่นคงน้อยกว่าตัวโครงการเอง

การอนุญาต

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

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

เราสนใจแบบฟอร์มที่เราต้องป้อนข้อมูลเข้าสู่ระบบและรหัสผ่านของผู้ใช้

เปิดหน้านี้ในเบราว์เซอร์ใดก็ได้แล้วเปิดตัวตรวจสอบ ป้อนข้อมูลผู้ใช้และส่งแบบฟอร์ม

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

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

เพื่อตอบสนองต่อคำขอดังกล่าว เซิร์ฟเวอร์จะส่งคุกกี้กลับมาให้เรา ซึ่งเราจะเพิ่มลงในคำขอเพิ่มเติมเพื่อทดสอบหน้าที่ได้รับอนุญาต

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

ฟังก์ชั่นสาธารณะ testAuthPage() ( $url = 'bryak.com'; $cookies = $this->getAuthCookies(' [ป้องกันอีเมล]', '12345'); $response = $this->getCurlResponse($url, ['คุกกี้' => $cookies]); $นี่->assertHTMLPresent(" ", $response, "ข้อผิดพลาด: การทดสอบไม่พบองค์ประกอบเนื้อหาบนเพจ"); )
ดังที่เราเห็น มีการเพิ่มวิธีการที่ได้รับคุกกี้การอนุญาตและเพิ่มลงในคำขอเพิ่มเติม วิธีการนั้นถูกนำไปใช้ค่อนข้างง่าย:

ฟังก์ชั่นสาธารณะ getAuthCookies($email, $password) ( // ตรวจสอบว่าได้รับคุกกี้แล้วหรือยัง If (array_key_exist($email, self::$known_cookies)) ( return self::$known_cookies[$email]; ) $url = self::DOMAIN_STAGING . '/auth_page_adds'; $post_data = ['email' => $email, 'password' => $password]; $response = $this->getCurlResponse($url, ['post_data' => $ post_data]); $cookies = $this->parseCookiesFromResponse($response); // บันทึกคุกกี้เพื่อใช้ด้วยตนเอง::$known_cookies[$email] = $cookies;
วิธีแรกจะตรวจสอบว่าอีเมลที่ระบุ (ในกรณีของคุณอาจเป็นข้อมูลเข้าสู่ระบบหรืออย่างอื่น) มีคุกกี้การอนุญาตที่ได้รับก่อนหน้านี้หรือไม่ ถ้ามีก็คืนให้ หากไม่เป็นเช่นนั้น ระบบจะส่งคำขอไปยังหน้าการอนุญาต (เช่น bryak.com/auth_page_adds) พร้อมพารามิเตอร์ที่จำเป็น: อีเมลผู้ใช้และรหัสผ่าน เพื่อตอบสนองต่อคำขอนี้ เซิร์ฟเวอร์จะส่งส่วนหัว ซึ่งได้แก่คุกกี้ที่เราสนใจ มีลักษณะดังนี้:

HTTP/1.1 200 ตกลง เซิร์ฟเวอร์: nginx ประเภทเนื้อหา: ข้อความ/html; charset=utf-8 การเข้ารหัสการถ่ายโอน: การเชื่อมต่อแบบก้อน: ชุดคุกกี้แบบ Keep-alive: ชื่อ = ค่า; หมดอายุ=พุธ 30 พ.ย.-2559 10:06:24 GMT; อายุสูงสุด=-86400; เส้นทาง=/; โดเมน=bryak.com
จากส่วนหัวเหล่านี้ เมื่อใช้นิพจน์ทั่วไปอย่างง่าย เราจำเป็นต้องได้รับชื่อของคุกกี้และค่าของมัน (ในตัวอย่างของเราคือ name=value) วิธีการของเราที่แยกวิเคราะห์การตอบสนองมีลักษณะดังนี้:

$this->assertTrue((bool)preg_match_all("/Set-Cookie: (([^=]+)=([^;]+);.*)\n/", $ตอบกลับ, $mch1), " ไม่สามารถรับ "คุกกี้" จากการตอบกลับของเซิร์ฟเวอร์: " . $response);
เมื่อได้รับคุกกี้แล้ว เราก็สามารถเพิ่มคุกกี้เหล่านั้นลงในคำขอใดๆ เพื่ออนุมัติได้อย่างปลอดภัย

การวิเคราะห์การทดสอบที่ล้มเหลว

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

ก่อนอื่น ฉันอยากจะแนะนำการทดสอบการทำให้เป็นอะตอมให้มากที่สุด คุณไม่ควรทดสอบ 50 กรณีที่แตกต่างกันในการทดสอบครั้งเดียว ยิ่งการทดสอบง่ายขึ้นก็จะยิ่งง่ายขึ้นในอนาคต

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

ตัวอย่างเช่น การทดสอบของเราล้มเหลวเนื่องจากไม่พบส่วน HTML บนหน้าเว็บ:

ลิงค์
เราไปที่ตัวสะสมของเราและเปิดหน้าที่เกี่ยวข้อง:

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

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

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

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

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

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

ผลลัพธ์

บน ช่วงเวลานี้เรามี *เปิด TimCity* ว้าว มีการทดสอบไปแล้ว 605 ครั้ง การทดสอบทั้งหมด หากไม่ได้ทำแบบคู่ขนาน ให้ผ่านภายในเวลาไม่ถึงสี่นาทีเล็กน้อย

ในช่วงเวลานี้เราตรวจสอบให้แน่ใจว่า:

• โครงการของเราเปิดในทุกภาษา (ซึ่งเรามีมากกว่า 40 ภาษาในการผลิต)
• สำหรับประเทศหลัก รูปแบบการชำระเงินที่ถูกต้องจะแสดงพร้อมชุดวิธีการชำระเงินที่เกี่ยวข้อง
• คำขอ API พื้นฐานทำงานอย่างถูกต้อง
• หน้า Landing Page สำหรับการเปลี่ยนเส้นทางทำงานอย่างถูกต้อง (รวมถึงไซต์บนมือถือที่มีตัวแทนผู้ใช้ที่เหมาะสม)
• โครงการภายในทั้งหมดจะแสดงอย่างถูกต้อง

การทดสอบ Selenium WebDriver ทั้งหมดนี้ต้องใช้เวลาและทรัพยากรมากขึ้นหลายเท่า เพิ่มแท็ก

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

- การทดสอบควัน(การทดสอบควัน)

- การทดสอบการถดถอย(การทดสอบการถดถอย)

- การทดสอบการสร้าง(การทดสอบการตรวจสอบการสร้าง)

- การทดสอบด้านสุขอนามัยหรือการตรวจสอบความสม่ำเสมอ/การทำงาน(การทดสอบสติ)

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

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

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

คำว่า “การทดสอบการถดถอย” นั้นเอง ขึ้นอยู่กับบริบทของการใช้งาน อาจมีความหมายที่แตกต่างกันได้ ตัวอย่างเช่น Sam Kaner อธิบายไว้ 3 ประเภทหลักการทดสอบการถดถอย:

- การถดถอยข้อผิดพลาด– ความพยายามที่จะพิสูจน์ว่าข้อผิดพลาดที่แก้ไขแล้วไม่ได้รับการแก้ไขจริง

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

- การถดถอยผลข้างเคียง– ความพยายามที่จะพิสูจน์ว่าการเปลี่ยนแปลงล่าสุดในรหัสหรือข้อมูลทำให้ส่วนอื่น ๆ ของแอปพลิเคชันที่กำลังพัฒนาเสียหาย

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

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

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

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

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