เฮ้ ฮับ!
ฉันชื่อ Maxim Ponomarenko เป็นนักพัฒนาของ Sportmaster ฉันมีประสบการณ์ 10 ปีในสาขาไอที เขาเริ่มต้นอาชีพด้วยการทดสอบด้วยตนเอง จากนั้นจึงเปลี่ยนมาพัฒนาฐานข้อมูล ในช่วง 4 ปีที่ผ่านมา ฉันสั่งสมความรู้ที่ได้รับจากการทดสอบและพัฒนาและทำการทดสอบอัตโนมัติในระดับ DBMS
ฉันอยู่ในทีม Sportmaster มาได้ปีกว่าแล้ว และกำลังพัฒนาการทดสอบอัตโนมัติในโครงการสำคัญโครงการหนึ่ง ในเดือนเมษายน ฉันกับทีมงานจาก Sportmaster Lab ได้พูดคุยกันในการประชุมที่ครัสโนดาร์ รายงานของฉันมีชื่อว่า "การทดสอบหน่วยใน DBMS" และตอนนี้ฉันต้องการแบ่งปันกับคุณ ข้อความจะเยอะมาก เลยตัดสินใจแยกรายงานออกเป็นสองโพสต์ ในตอนแรก เราจะพูดถึงการทดสอบอัตโนมัติและการทดสอบโดยทั่วไป และในส่วนที่สอง ผมจะกล่าวถึงรายละเอียดเพิ่มเติมเกี่ยวกับระบบการทดสอบหน่วยของเราและผลลัพธ์ของการใช้งาน
ประการแรก ทฤษฎีที่น่าเบื่อเล็กน้อย การทดสอบอัตโนมัติคืออะไร? นี่คือการทดสอบที่ดำเนินการโดยซอฟต์แวร์ และในไอทีสมัยใหม่มีการใช้มากขึ้นในการพัฒนาซอฟต์แวร์ นี่เป็นเพราะความจริงที่ว่าบริษัทต่างๆ กำลังเติบโต ระบบข้อมูลของพวกเขากำลังเติบโต และจำนวนฟังก์ชันที่ต้องทดสอบก็เพิ่มขึ้นตามไปด้วย การทำการทดสอบด้วยตนเองมีราคาแพงขึ้นเรื่อยๆ
ฉันทำงานให้กับบริษัทขนาดใหญ่ซึ่งมีผลงานออกทุกๆ สองเดือน ในขณะเดียวกันก็ใช้เวลาทั้งเดือนในการให้ผู้ทดสอบหลายสิบคนตรวจสอบฟังก์ชันการทำงานด้วยตนเอง ต้องขอบคุณการนำระบบอัตโนมัติไปใช้โดยทีมนักพัฒนากลุ่มเล็กๆ เราจึงสามารถลดเวลาการทดสอบลงเหลือ 2 สัปดาห์ในหนึ่งปีครึ่ง เราไม่เพียงแต่เพิ่มความเร็วในการทดสอบเท่านั้น แต่ยังปรับปรุงคุณภาพอีกด้วย การทดสอบอัตโนมัติเปิดตัวเป็นประจำและจะดำเนินการตรวจสอบทั้งหมดที่รวมอยู่ในการทดสอบเสมอ นั่นคือเราไม่รวมปัจจัยด้านมนุษย์
ไอทียุคใหม่โดดเด่นด้วยความจริงที่ว่านักพัฒนาอาจไม่เพียงจำเป็นต้องเขียนรหัสผลิตภัณฑ์เท่านั้น แต่ยังต้องเขียนการทดสอบหน่วยที่ตรวจสอบรหัสนี้ด้วย
แต่จะเกิดอะไรขึ้นถ้าระบบของคุณใช้ตรรกะของเซิร์ฟเวอร์เป็นหลัก? ไม่มีวิธีแก้ปัญหาที่เป็นสากลหรือแนวทางปฏิบัติที่ดีที่สุดในตลาด ตามกฎแล้ว บริษัทต่างๆ จะแก้ไขปัญหานี้ด้วยการสร้างระบบการทดสอบที่เขียนขึ้นเอง นี่คือระบบทดสอบอัตโนมัติที่เขียนขึ้นเองของเราซึ่งสร้างขึ้นในโครงการของเรา และฉันจะพูดถึงมันในรายงานของฉัน
การทดสอบความภักดี
ก่อนอื่น เรามาพูดถึงโปรเจ็กต์ที่เราปรับใช้ระบบทดสอบอัตโนมัติกันก่อน โครงการของเราคือระบบความภักดีของ Sportmaster (โดยวิธีการที่เราได้เขียนเกี่ยวกับมันไปแล้ว) ).
หากบริษัทของคุณมีขนาดใหญ่เพียงพอ ระบบสมาชิกของคุณจะมีคุณสมบัติมาตรฐานสามประการ:
- ระบบของคุณจะถูกโหลดอย่างมาก
- ระบบของคุณจะมีกระบวนการคำนวณที่ซับซ้อน
- ระบบของคุณจะได้รับการปรับปรุงอย่างแข็งขัน
ตามลำดับ... โดยรวมแล้วหากเราพิจารณาแบรนด์ Sportmaster ทั้งหมด เราก็จะมีร้านค้ามากกว่า 1000 แห่งในรัสเซีย ยูเครน จีน คาซัคสถาน และเบลารุส มีการซื้อประมาณ 300 รายการในร้านค้าเหล่านี้ทุกวัน นั่นคือทุก ๆ 000-3 เช็คจะเข้าสู่ระบบของเรา แน่นอนว่าระบบความภักดีของเรามีภาระงานสูง และเนื่องจากมีการใช้งานอย่างต่อเนื่อง เราจึงต้องจัดให้มีมาตรฐานคุณภาพสูงสุด เนื่องจากข้อผิดพลาดใดๆ ในซอฟต์แวร์จะส่งผลให้เกิดการสูญเสียทางการเงิน ชื่อเสียง และอื่นๆ จำนวนมาก
ในเวลาเดียวกัน Sportmaster มีโปรโมชั่นที่แตกต่างกันมากกว่าร้อยรายการ มีโปรโมชั่นหลากหลาย: มีโปรโมชั่นสินค้า, มีโปรโมชั่นเฉพาะวันในสัปดาห์, มีโปรโมชั่นเฉพาะร้านค้า, มีโปรโมชั่นตามจำนวนใบเสร็จ, มีตามจำนวนสินค้า โดยทั่วไปแล้วก็ไม่เลว ลูกค้ามีโบนัสและรหัสส่งเสริมการขายที่ใช้ในการซื้อสินค้า ทั้งหมดนี้นำไปสู่ความจริงที่ว่าการคำนวณคำสั่งซื้อใด ๆ นั้นเป็นงานที่ไม่สำคัญมาก
อัลกอริธึมที่ใช้การประมวลผลคำสั่งนั้นแย่มากและซับซ้อนอย่างแท้จริง และการเปลี่ยนแปลงใด ๆ ในอัลกอริทึมนี้ค่อนข้างมีความเสี่ยง ดูเหมือนว่าการเปลี่ยนแปลงที่ไม่มีนัยสำคัญที่สุดอาจนำไปสู่ผลกระทบที่ไม่อาจคาดเดาได้ แต่กระบวนการทางคอมพิวเตอร์ที่ซับซ้อนเช่นนี้ โดยเฉพาะอย่างยิ่งกระบวนการที่ใช้ฟังก์ชันการทำงานที่สำคัญ คือตัวเลือกที่ดีที่สุดสำหรับระบบอัตโนมัติ การตรวจสอบกรณีที่คล้ายกันหลายสิบกรณีด้วยตนเองนั้นใช้เวลานานมาก และเนื่องจากจุดเข้าสู่กระบวนการไม่มีการเปลี่ยนแปลง เมื่ออธิบายไปแล้วครั้งหนึ่ง คุณจึงสามารถสร้างการทดสอบอัตโนมัติได้อย่างรวดเร็วและมั่นใจได้ว่าฟังก์ชันการทำงานจะทำงานได้
เนื่องจากระบบของเรามีการใช้งานอย่างต่อเนื่อง ธุรกิจจึงต้องการสิ่งใหม่ๆ จากคุณ ตรงต่อเวลา และให้ความสำคัญกับลูกค้าเป็นหลัก ในระบบสมาชิกของเรา การเผยแพร่จะออกมาทุกๆ สองเดือน ซึ่งหมายความว่าทุกๆ สองเดือน เราจำเป็นต้องดำเนินการถดถอยโดยสมบูรณ์ของทั้งระบบ ในขณะเดียวกัน เช่นเดียวกับในไอทียุคใหม่ การพัฒนาไม่ได้เปลี่ยนจากนักพัฒนาไปสู่การผลิตในทันที มันเริ่มต้นจากวงจรของนักพัฒนา จากนั้นจึงผ่านม้านั่งทดสอบ ปล่อย ยอมรับ และจากนั้นก็จบลงที่การใช้งานจริงเท่านั้น อย่างน้อยที่สุดในวงจรทดสอบและปล่อย เราจำเป็นต้องดำเนินการถดถอยโดยสมบูรณ์ของทั้งระบบ
คุณสมบัติที่อธิบายไว้เป็นมาตรฐานสำหรับระบบสมาชิกเกือบทุกระบบ พูดคุยเกี่ยวกับคุณสมบัติของโครงการของเรา
ในทางเทคโนโลยี 90% ของตรรกะของระบบสมาชิกของเรานั้นใช้เซิร์ฟเวอร์และใช้งานบน Oracle มีลูกค้ารายหนึ่งถูกเปิดเผยใน Delphi ซึ่งทำหน้าที่ของผู้ดูแลระบบที่ทำงานอัตโนมัติ มีบริการเว็บแบบเปิดเผยสำหรับแอปพลิเคชันภายนอก (เช่น เว็บไซต์) ดังนั้นจึงสมเหตุสมผลอย่างยิ่งที่หากเราปรับใช้ระบบทดสอบอัตโนมัติ เราจะดำเนินการดังกล่าวบน Oracle
ระบบความภักดีใน Sportmaster มีมานานกว่า 7 ปีและถูกสร้างขึ้นโดยนักพัฒนารายเดียว... จำนวนนักพัฒนาโดยเฉลี่ยในโครงการของเราในช่วง 7 ปีนี้คือ 3-4 คน แต่ในปีที่ผ่านมา ทีมของเราเติบโตขึ้นอย่างมาก และขณะนี้มีคนทำงานในโปรเจ็กต์นี้ถึง 10 คน กล่าวคือ ผู้คนมาที่โปรเจ็กต์ซึ่งไม่คุ้นเคยกับงาน กระบวนการ และสถาปัตยกรรมทั่วไป และมีความเสี่ยงเพิ่มขึ้นที่เราจะพลาดข้อผิดพลาด
โครงการนี้มีลักษณะเฉพาะคือไม่มีผู้ทดสอบโดยเฉพาะเป็นหน่วยงาน แน่นอนว่ามีการทดสอบ แต่การทดสอบดำเนินการโดยนักวิเคราะห์ นอกเหนือจากความรับผิดชอบหลักอื่นๆ ได้แก่ การสื่อสารกับลูกค้าทางธุรกิจ ผู้ใช้ การพัฒนาข้อกำหนดของระบบ ฯลฯ ฯลฯ... แม้ว่าการทดสอบจะดำเนินการอย่างมีคุณภาพสูงมาก (ซึ่งเหมาะสมอย่างยิ่งที่จะกล่าวถึง เนื่องจากนักวิเคราะห์บางคนอาจจับตาดูรายงานนี้) ประสิทธิผลของความเชี่ยวชาญเฉพาะทางและการมุ่งเน้นในสิ่งหนึ่งยังไม่ถูกยกเลิก .
เมื่อพิจารณาทั้งหมดข้างต้น เพื่อปรับปรุงคุณภาพของผลิตภัณฑ์ที่ส่งมอบและลดเวลาในการพัฒนา แนวคิดในการทำการทดสอบอัตโนมัติในโครงการจึงดูสมเหตุสมผลมาก และในขั้นตอนต่างๆ ของระบบความภักดี นักพัฒนาแต่ละรายได้พยายามครอบคลุมโค้ดของตนด้วยการทดสอบหน่วย โดยรวมแล้วมันเป็นกระบวนการที่ค่อนข้างไม่ปะติดปะต่อกัน โดยทุกคนใช้สถาปัตยกรรมและวิธีการของตนเอง ผลลัพธ์สุดท้ายเป็นเรื่องปกติสำหรับการทดสอบหน่วย: การทดสอบได้รับการพัฒนา ใช้มาระยะหนึ่ง เก็บไว้ในที่เก็บไฟล์ตามเวอร์ชัน แต่เมื่อถึงจุดหนึ่ง การทดสอบเหล่านั้นหยุดทำงานและถูกลืมไป ประการแรก นี่เป็นเพราะว่าการทดสอบเชื่อมโยงกับนักแสดงที่เฉพาะเจาะจงมากกว่า ไม่ใช่กับโปรเจ็กต์
utPLSQL มาช่วยเหลือ
คุณรู้อะไรเกี่ยวกับ Stephen Feuerstein บ้างไหม?
นี่คือคนฉลาดที่อุทิศชีวิตการทำงานให้กับ Oracle และ PL/SQL มายาวนาน และได้เขียนผลงานในหัวข้อนี้ค่อนข้างมาก หนังสือที่มีชื่อเสียงเล่มหนึ่งของเขาชื่อ: “Oracle PL/SQL สำหรับมืออาชีพ” Stephen เป็นผู้พัฒนาโซลูชัน utPLSQL หรือที่ย่อมาจาก Unit Testing Framework สำหรับ Oracle PL/SQL โซลูชัน utPLSQL ถูกสร้างขึ้นในปี 2016 แต่ยังคงทำงานอย่างต่อเนื่องและมีเวอร์ชันใหม่ๆ ออกมา ในขณะที่รายงาน เวอร์ชันล่าสุดคือวันที่ 24 มีนาคม 2019
มันคืออะไร. นี่เป็นโครงการโอเพ่นซอร์สแยกต่างหาก มีน้ำหนักสองสามเมกะไบต์ รวมถึงตัวอย่างและเอกสารประกอบ ในเชิงกายภาพ มันเป็นสคีมาแยกต่างหากในฐานข้อมูล ORACLE พร้อมด้วยชุดแพ็คเกจและตารางสำหรับจัดการการทดสอบหน่วย การติดตั้งใช้เวลาไม่กี่วินาที คุณสมบัติที่โดดเด่นของ utPLSQL คือใช้งานง่าย
utPLSQL ทั่วโลกเป็นกลไกสำหรับการรันการทดสอบหน่วย โดยที่การทดสอบหน่วยเข้าใจว่าเป็นขั้นตอนแบตช์ทั่วไปของ Oracle ซึ่งมีองค์กรที่ปฏิบัติตามกฎบางอย่าง นอกเหนือจากการเปิดตัวแล้ว utPLSQL ยังจัดเก็บบันทึกการดำเนินการทดสอบทั้งหมดของคุณ และยังมีระบบการรายงานภายในอีกด้วย
ลองดูตัวอย่างว่าโค้ดการทดสอบหน่วยมีลักษณะอย่างไร ซึ่งนำไปใช้งานโดยใช้เทคนิคนี้
ดังนั้นหน้าจอจะแสดงรหัสสำหรับข้อกำหนดแพ็คเกจทั่วไปพร้อมการทดสอบหน่วย ข้อกำหนดบังคับมีอะไรบ้าง? แพ็กเก็ตจะต้องขึ้นต้นด้วย "utp_" ขั้นตอนทั้งหมดที่มีการทดสอบต้องมีคำนำหน้าเหมือนกันทุกประการ แพ็คเกจจะต้องมีสองขั้นตอนมาตรฐาน: “utp_setup” และ “utp_teardown” ขั้นตอนแรกถูกเรียกโดยการรีสตาร์ทแต่ละการทดสอบหน่วย ครั้งที่สอง - หลังจากการเปิดตัว
ตามกฎแล้ว “utp_setup” จะเตรียมระบบของเราให้ทำการทดสอบหน่วย เช่น การสร้างข้อมูลการทดสอบ “utp_teardown” - ตรงกันข้ามทุกอย่างจะกลับสู่การตั้งค่าดั้งเดิมและรีเซ็ตผลการเปิดตัว
นี่คือตัวอย่างของการทดสอบหน่วยที่ง่ายที่สุดที่จะตรวจสอบการทำให้หมายเลขโทรศัพท์ของลูกค้าที่ป้อนเป็นมาตรฐานให้เป็นแบบฟอร์มมาตรฐานสำหรับระบบสมาชิกของเรา ไม่มีมาตรฐานบังคับในการเขียนขั้นตอนด้วยการทดสอบหน่วย ตามกฎแล้ว มีการเรียกเมธอดของระบบที่ทดสอบ และผลลัพธ์ที่ส่งคืนโดยเมธอดนี้จะถูกเปรียบเทียบกับเมธอดอ้างอิง สิ่งสำคัญคือการเปรียบเทียบผลลัพธ์อ้างอิงกับผลที่ได้รับจะต้องดำเนินการผ่านวิธี utPLSQL มาตรฐาน
การทดสอบหน่วยสามารถมีการตรวจสอบจำนวนเท่าใดก็ได้ ดังที่เห็นได้จากตัวอย่าง เราทำการเรียกวิธีที่ทดสอบติดต่อกันสี่ครั้งเพื่อทำให้หมายเลขโทรศัพท์เป็นมาตรฐานและประเมินผลลัพธ์หลังจากการโทรแต่ละครั้ง เมื่อพัฒนาการทดสอบหน่วย คุณต้องคำนึงว่ามีการตรวจสอบที่ไม่ส่งผลกระทบต่อระบบ แต่อย่างใด และหลังจากนั้นคุณต้องย้อนกลับไปสู่สถานะดั้งเดิมของระบบ
ตัวอย่างเช่น ในการทดสอบหน่วยที่นำเสนอ เราเพียงแค่จัดรูปแบบหมายเลขโทรศัพท์ที่ป้อน ซึ่งไม่มีผลกระทบต่อระบบความภักดีแต่อย่างใด
และหากเราเขียนการทดสอบหน่วยโดยใช้วิธีสร้างไคลเอนต์ใหม่ หลังจากการทดสอบแต่ละครั้งจะมีการสร้างไคลเอนต์ใหม่ในระบบซึ่งอาจส่งผลต่อการเปิดตัวการทดสอบในภายหลัง
นี่คือวิธีการรันการทดสอบหน่วย มีสองตัวเลือกในการเรียกใช้ที่เป็นไปได้: การรันการทดสอบหน่วยทั้งหมดจากแพ็คเกจเฉพาะหรือการรันการทดสอบหน่วยเฉพาะในแพ็คเกจเฉพาะ
นี่คือตัวอย่างของระบบการรายงานภายใน จากผลการทดสอบหน่วย utPLSQL จะสร้างรายงานขนาดเล็ก ในนั้นเราจะเห็นผลของการตรวจสอบเฉพาะแต่ละรายการและผลลัพธ์โดยรวมของการทดสอบหน่วย
กฎการทดสอบอัตโนมัติ 6 ข้อ
ก่อนที่จะเริ่มสร้างระบบใหม่สำหรับการทดสอบระบบความภักดีแบบอัตโนมัติ ร่วมกับฝ่ายบริหาร เราได้กำหนดหลักการที่การทดสอบอัตโนมัติในอนาคตของเราควรปฏิบัติตาม
- การทดสอบอัตโนมัติต้องมีประสิทธิภาพและมีประโยชน์ เรามีนักพัฒนาที่ยอดเยี่ยมซึ่งจำเป็นต้องได้รับการกล่าวถึงอย่างแน่นอน เพราะบางคนอาจจะเห็นรายงานนี้ และพวกเขาก็เขียนโค้ดที่ยอดเยี่ยม แต่ถึงแม้รหัสที่ยอดเยี่ยมของพวกเขาจะไม่สมบูรณ์แบบและมี มี และจะมีข้อผิดพลาดต่อไป จำเป็นต้องมีการทดสอบอัตโนมัติเพื่อค้นหาข้อผิดพลาดเหล่านี้ หากไม่เป็นเช่นนั้น แสดงว่าเรากำลังเขียนการทดสอบอัตโนมัติที่ไม่ดี หรือเรามาถึงจุดอับจนซึ่งโดยหลักการแล้วยังไม่ได้รับการพัฒนา ในทั้งสองกรณี เรากำลังทำอะไรผิด และวิธีการของเราก็ไม่สมเหตุสมผล
- ควรใช้การทดสอบอัตโนมัติ มันไม่สมเหตุสมผลเลยที่จะใช้เวลาและความพยายามอย่างมากในการเขียนผลิตภัณฑ์ซอฟต์แวร์ ใส่ไว้ในที่เก็บข้อมูลและลืมมันไป ควรทำการทดสอบและดำเนินการอย่างสม่ำเสมอที่สุด
- การทดสอบอัตโนมัติควรทำงานได้อย่างเสถียร ไม่ว่าเวลาใดของวัน แท่นปล่อยจรวดและการตั้งค่าระบบอื่นๆ การทดสอบการทำงานควรให้ผลลัพธ์เดียวกัน ตามกฎแล้วสิ่งนี้มั่นใจได้จากข้อเท็จจริงที่ว่าการทดสอบอัตโนมัติทำงานกับข้อมูลการทดสอบพิเศษพร้อมการตั้งค่าระบบคงที่
- การทดสอบอัตโนมัติควรทำงานด้วยความเร็วที่ยอมรับได้สำหรับโปรเจ็กต์ของคุณ เวลานี้จะถูกกำหนดเป็นรายบุคคลสำหรับแต่ละระบบ บางคนสามารถทำงานได้ทั้งวัน ในขณะที่บางคนพบว่าการทำงานภายในไม่กี่วินาทีเป็นเรื่องสำคัญ ฉันจะบอกคุณในภายหลังว่าเราได้มาตรฐานความเร็วอะไรในโครงการของเรา
- การพัฒนาการทดสอบอัตโนมัติควรมีความยืดหยุ่น ไม่แนะนำให้ปฏิเสธที่จะทดสอบการทำงานใดๆ เพียงเพราะเราไม่เคยทำมาก่อนหรือด้วยเหตุผลอื่นใด utPLSQL ไม่ได้กำหนดข้อจำกัดใดๆ ในการพัฒนา และโดยหลักการแล้ว Oracle อนุญาตให้คุณนำไปใช้งานได้หลากหลาย ปัญหาส่วนใหญ่มีทางแก้ มันเป็นเพียงเรื่องของเวลาและความพยายาม
- ความสามารถในการปรับใช้ เรามีจุดยืนหลายแห่งที่เราต้องทำการทดสอบ ในแต่ละจุด สามารถอัปเดตการถ่ายโอนข้อมูลได้ตลอดเวลา มีความจำเป็นต้องดำเนินโครงการที่มีการทดสอบอัตโนมัติในลักษณะที่คุณสามารถดำเนินการติดตั้งทั้งหมดหรือบางส่วนได้อย่างง่ายดาย
และในโพสต์ที่สองในอีกสองสามวันข้างหน้า ฉันจะบอกคุณว่าเราทำอะไรและผลลัพธ์ที่เราประสบความสำเร็จคืออะไร
ที่มา: will.com