ส่วนที่หนึ่ง - .
ลองนึกภาพสถานการณ์ คุณกำลังเผชิญกับงานในการพัฒนาฟังก์ชันใหม่ คุณมีประสบการณ์จากบรรพบุรุษของคุณ สมมติว่าคุณไม่มีพันธะทางศีลธรรม คุณจะทำอย่างไร
บ่อยครั้งที่การพัฒนาเก่าทั้งหมดถูกลืมและทุกอย่างเริ่มต้นใหม่อีกครั้ง ไม่มีใครชอบขุดคุ้ยโค้ดของคนอื่น และถ้าคุณมีเวลา ทำไมไม่ลองสร้างระบบของคุณเองดูล่ะ นี่เป็นแนวทางทั่วไป และถูกต้องในหลายๆ ประการ แต่ในโครงการของเรา เราทำแตกต่างออกไป เราใช้ระบบการทดสอบอัตโนมัติในอนาคตจากการพัฒนาในการทดสอบหน่วยบน utPLSQL จากรุ่นก่อนหน้าของเรา จากนั้นจึงไปทำงานในหลายๆ ทิศทางแบบคู่ขนานกัน
- การกู้คืนการทดสอบหน่วยเก่า การกู้คืนหมายถึงการปรับการทดสอบให้เข้ากับสถานะที่มีอยู่ของระบบสมาชิก และการปรับการทดสอบให้เป็นมาตรฐาน utPLSQL
- แก้ปัญหาด้วยความเข้าใจ อะไรกันแน่ วิธีการและกระบวนการใดที่เราครอบคลุมด้วยการทดสอบอัตโนมัติ คุณต้องเก็บข้อมูลนี้ไว้ในหัวของคุณ หรือสรุปผลโดยตรงจากรหัสการทดสอบอัตโนมัติ ดังนั้นเราจึงตัดสินใจสร้างแคตตาล็อก เรากำหนดรหัสช่วยจำที่ไม่ซ้ำกันให้กับการทดสอบอัตโนมัติแต่ละครั้ง สร้างคำอธิบาย และแก้ไขการตั้งค่า (ตัวอย่างเช่น ภายใต้เงื่อนไขใดที่ควรเรียกใช้ หรือสิ่งที่จะเกิดขึ้นหากการทดสอบล้มเหลว) โดยพื้นฐานแล้ว เราได้กรอกข้อมูลเมตาเกี่ยวกับการทดสอบอัตโนมัติและวางข้อมูลเมตานี้ในตารางมาตรฐานของสคีมา utPLSQL
- คำจำกัดความของกลยุทธ์การขยายตัวเช่น การเลือกฟังก์ชันที่ต้องตรวจสอบโดยการทดสอบอัตโนมัติ เราตัดสินใจที่จะให้ความสนใจกับสามสิ่ง: การปรับปรุงใหม่ของระบบ เหตุการณ์จากการผลิต และกระบวนการที่สำคัญของระบบ ดังนั้นเราจึงพัฒนาควบคู่ไปกับการเปิดตัวเพื่อให้มั่นใจว่ามีคุณภาพที่สูงขึ้น พร้อมขยายขอบเขตของการถดถอยและรับประกันความน่าเชื่อถือของระบบในจุดวิกฤต ปัญหาคอขวดประการแรกคือกระบวนการแจกจ่ายส่วนลดและโบนัสด้วยเช็ค
- แน่นอน เราเริ่มพัฒนาการทดสอบอัตโนมัติใหม่ หนึ่งในภารกิจแรกของการเปิดตัวคือการประเมินประสิทธิภาพของตัวอย่างที่กำหนดไว้ล่วงหน้าของระบบสมาชิก โครงการของเรามีบล็อกของแบบสอบถาม sql ที่ตายตัวซึ่งเลือกลูกค้าตามเงื่อนไข ตัวอย่างเช่น รับรายชื่อลูกค้าทั้งหมดที่มีการซื้อครั้งล่าสุดในเมืองใดเมืองหนึ่ง หรือรายชื่อลูกค้าที่มียอดซื้อเฉลี่ยสูงกว่าค่าที่กำหนด หลังจากทำการทดสอบอัตโนมัติเป็นลายลักษณ์อักษรแล้ว เราได้ตรวจสอบตัวอย่างที่กำหนดไว้ล่วงหน้า พารามิเตอร์ประสิทธิภาพของเกณฑ์มาตรฐานคงที่ และนอกจากนี้เรายังได้รับการทดสอบโหลดอีกด้วย
- การทำงานกับ autotests น่าจะสะดวก. การกระทำที่พบบ่อยที่สุดสองอย่างคือการเรียกใช้การทดสอบอัตโนมัติและการสร้างข้อมูลการทดสอบ นี่คือลักษณะของโมดูลเสริมสองโมดูลที่ปรากฏในระบบของเรา: โมดูลเปิดใช้และโมดูลสร้างข้อมูล
ตัวเรียกใช้งานแสดงเป็นขั้นตอนทั่วไปหนึ่งรายการพร้อมพารามิเตอร์ข้อความป้อนเข้าหนึ่งรายการ ในฐานะพารามิเตอร์ คุณสามารถส่งรหัสช่วยจำ autotest ชื่อแพ็คเกจ ชื่อทดสอบ การตั้งค่า autotest หรือคำหลักที่สงวนไว้ ขั้นตอนจะเลือกและรันการทดสอบอัตโนมัติทั้งหมดที่ตรงตามเงื่อนไข
โมดูลการสร้างข้อมูลแสดงเป็นแพ็คเกจซึ่งสำหรับแต่ละออบเจ็กต์ของระบบภายใต้การทดสอบ (ตารางในฐานข้อมูล) มีการสร้างขั้นตอนพิเศษเพื่อแทรกข้อมูลที่นั่น ในขั้นตอนนี้ค่าเริ่มต้นจะถูกเติมให้สูงสุดซึ่งทำให้สามารถสร้างวัตถุได้อย่างแท้จริงด้วยการคลิกเพียงนิ้วเดียว และเพื่อความสะดวกในการใช้งาน จึงได้สร้างเทมเพลตสำหรับข้อมูลที่สร้างขึ้น ตัวอย่างเช่น สร้างลูกค้าอายุหนึ่งด้วยโทรศัพท์ทดสอบและการซื้อที่เสร็จสมบูรณ์
- การทดสอบอัตโนมัติควรรันและรันภายในเวลาที่เหมาะสมสำหรับระบบของคุณ ดังนั้นจึงมีการจัดงานเปิดตัวในตอนกลางคืนทุกวันโดยอิงตามผลลัพธ์ที่มีการสร้างรายงานเกี่ยวกับผลลัพธ์และส่งไปยังทีมพัฒนาทั้งหมดทางไปรษณีย์ขององค์กร หลังจากคืนค่าการทดสอบอัตโนมัติเก่าและสร้างการทดสอบใหม่ เวลาดำเนินการทั้งหมดคือ 30 นาที ประสิทธิภาพดังกล่าวเหมาะกับทุกคน เนื่องจากการเปิดตัวเกิดขึ้นในช่วงนอกเวลาทำการ
แต่เราต้องทำงานเพื่อเพิ่มประสิทธิภาพความเร็วของงาน ระบบความภักดีของการผลิตได้รับการปรับปรุงในเวลากลางคืน ในส่วนหนึ่งของการเผยแพร่ เราต้องทำการเปลี่ยนแปลงอย่างเร่งด่วนในตอนกลางคืน การรอผลการทดสอบอัตโนมัติครึ่งชั่วโมงตอนตีสามไม่ได้ทำให้ผู้รับผิดชอบการปล่อยตัวมีความสุข (ทักทายอย่างกระตือรือร้นต่อ Alexei Vasyukov!) และเช้าวันต่อมาก็มีคำพูดที่อบอุ่นมากมายต่อระบบของเรา แต่ด้วยเหตุนี้จึงมีการกำหนดมาตรฐานการทำงาน 5 นาที
เพื่อเร่งประสิทธิภาพ เราใช้สองวิธี: เราเริ่มเรียกใช้การทดสอบอัตโนมัติในสามเธรดแบบขนาน เนื่องจากวิธีนี้สะดวกมากเนื่องจากสถาปัตยกรรมของระบบสมาชิกของเรา และเราละทิ้งแนวทางเมื่อการทดสอบอัตโนมัติไม่ได้สร้างข้อมูลการทดสอบสำหรับตัวมันเอง แต่พยายามค้นหาสิ่งที่เหมาะสมในระบบ หลังจากทำการเปลี่ยนแปลง เวลาในการทำงานทั้งหมดก็ลดลงเหลือ 3-4 นาที
- โปรเจ็กต์ที่มีการทดสอบอัตโนมัติควรจะปรับใช้บนสแตนด์ต่างๆ ได้ ในช่วงเริ่มต้นของการเดินทาง มีความพยายามที่จะเขียนแบตช์ไฟล์ของเราเอง แต่เป็นที่ชัดเจนว่าการติดตั้งแบบอัตโนมัติที่เขียนขึ้นเองนั้นเป็นเรื่องที่น่าสยดสยองอย่างสิ้นเชิง และเราหันไปหาโซลูชันทางอุตสาหกรรม เนื่องจากโปรเจ็กต์มีโค้ดโดยตรงจำนวนมาก (ก่อนอื่น เราเก็บโค้ดของการทดสอบอัตโนมัติ) และข้อมูลน้อยมาก (ข้อมูลหลักคือข้อมูลเมตาเกี่ยวกับการทดสอบอัตโนมัติ) จึงกลายเป็นเรื่องง่ายมากที่จะรวมเข้ากับ โครงการ Liquibase
เป็นไลบรารีอิสระของฐานข้อมูลโอเพ่นซอร์สสำหรับการติดตาม จัดการ และปรับใช้การเปลี่ยนแปลงสคีมาของฐานข้อมูล จัดการผ่านบรรทัดคำสั่งหรือเฟรมเวิร์กเช่น Apache Maven หลักการทำงานของ Liquibase นั้นค่อนข้างง่าย เรามีโครงการที่มีการจัดระเบียบในลักษณะหนึ่ง ซึ่งประกอบด้วยการเปลี่ยนแปลงหรือสคริปต์ที่จำเป็นต้องรีดไปยังเซิร์ฟเวอร์เป้าหมาย และไฟล์ควบคุมที่กำหนดว่าการเปลี่ยนแปลงเหล่านี้ควรติดตั้งในลำดับใดและด้วยพารามิเตอร์ใด
ที่ระดับ DBMS จะมีการสร้างตารางพิเศษซึ่ง Liquibase เก็บบันทึกการย้อนกลับ การเปลี่ยนแปลงแต่ละครั้งมีแฮชที่คำนวณได้ซึ่งจะเปรียบเทียบระหว่างโครงการและสถานะในฐานข้อมูลในแต่ละครั้ง ต้องขอบคุณ Liquibase ที่ทำให้เราสามารถเปลี่ยนระบบของเราไปยังวงจรใดๆ ได้อย่างง่ายดาย ขณะนี้การทดสอบอัตโนมัติทำงานในลูปทดสอบและรีลีส เช่นเดียวกับคอนเทนเนอร์ (ลูปส่วนตัวของนักพัฒนาซอฟต์แวร์)
เรามาพูดถึงผลลัพธ์ของการใช้ระบบการทดสอบหน่วยของเรากัน
- แน่นอน ก่อนอื่น เรามั่นใจว่าเราเริ่มพัฒนาซอฟต์แวร์ที่ดีขึ้น การทดสอบอัตโนมัติทำงานทุกวันและพบข้อบกพร่องมากมายในทุกรุ่น นอกจากนี้ ข้อผิดพลาดเหล่านี้บางส่วนเกี่ยวข้องทางอ้อมกับฟังก์ชันการทำงานที่เราต้องการเปลี่ยนแปลงจริงๆ เท่านั้น มีข้อสงสัยอย่างมากว่าพบข้อผิดพลาดเหล่านี้จากการทดสอบด้วยตนเอง
- ทีมงานได้รับความเชื่อมั่นว่าฟังก์ชันบางอย่างทำงานได้อย่างถูกต้อง... ก่อนอื่น สิ่งนี้เกี่ยวข้องกับกระบวนการที่สำคัญของเรา ตัวอย่างเช่น ในช่วงหกเดือนที่ผ่านมา เราไม่มีปัญหากับการกระจายส่วนลดและโบนัสด้วยเช็ค แม้ว่าการเปลี่ยนแปลงจะเกิดขึ้นทุกครั้ง แม้ว่าในช่วงก่อนหน้านี้จะมีข้อผิดพลาดเกิดขึ้นกับความถี่บ้าง
- เราจัดการเพื่อลดจำนวนการทดสอบซ้ำ เนื่องจากการทดสอบอัตโนมัติถูกเขียนขึ้นสำหรับฟังก์ชันใหม่ นักวิเคราะห์และผู้ทดสอบนอกเวลาจึงได้รับโค้ดที่มีคุณภาพสูงขึ้นเนื่องจาก มันได้รับการยืนยันแล้ว
- นักพัฒนาใช้ส่วนหนึ่งของการพัฒนาการทดสอบอัตโนมัติ ตัวอย่างเช่น ข้อมูลทดสอบบนคอนเทนเนอร์ถูกสร้างขึ้นโดยใช้โมดูลการสร้างวัตถุ
- สิ่งสำคัญคือเราต้องพัฒนา "การยอมรับ" ของระบบการทดสอบอัตโนมัติโดยนักพัฒนา มีความเข้าใจว่าสิ่งนี้สำคัญและมีประโยชน์ และจากประสบการณ์ของฉันเอง ฉันสามารถพูดได้ว่าสิ่งนี้ยังห่างไกลจากกรณีนี้ จำเป็นต้องเขียนการทดสอบอัตโนมัติ ต้องได้รับการบำรุงรักษาและพัฒนา ต้องวิเคราะห์ผลลัพธ์ และบ่อยครั้งที่ต้นทุนเวลาเหล่านี้ไม่คุ้มค่า ไปที่การผลิตและจัดการกับปัญหาที่นั่นง่ายกว่ามาก ในประเทศของเรา นักพัฒนาเข้าแถวและขอให้ครอบคลุมการทำงานด้วยการทดสอบอัตโนมัติ
มีอะไรต่อไป
พูดคุยเกี่ยวกับแผนการพัฒนาของโครงการทดสอบอัตโนมัติ
แน่นอน ตราบใดที่ระบบความภักดีของ Sportmaster ยังคงอยู่และพัฒนาต่อไป การทดสอบอัตโนมัติก็สามารถพัฒนาได้แทบจะไม่มีที่สิ้นสุด ดังนั้นทิศทางหลักของการพัฒนาคือการขยายพื้นที่ให้ครอบคลุม
เมื่อจำนวนการทดสอบอัตโนมัติเพิ่มขึ้น เวลารวมของงานจะเพิ่มขึ้นเรื่อย ๆ และเราจะต้องกลับไปที่ปัญหาประสิทธิภาพอีกครั้ง เป็นไปได้มากว่าการแก้ปัญหาคือการเพิ่มจำนวนเธรดแบบขนาน
แต่สิ่งเหล่านี้คือแนวทางการพัฒนาที่ชัดเจน หากเราพูดถึงเรื่องที่ไม่สำคัญ เราเน้นสิ่งต่อไปนี้:
- ขณะนี้การทดสอบอัตโนมัติได้รับการจัดการที่ระดับ DBMS เช่น จำเป็นต้องมีความรู้เกี่ยวกับ PL/SQL เพื่อการทำงานให้ประสบความสำเร็จ หากจำเป็น การจัดการระบบ (เช่น การเปิดใช้งานหรือการสร้างข้อมูลเมตา) สามารถนำออกโดยแผงการดูแลระบบบางประเภทโดยใช้ Jenkins หรือสิ่งที่คล้ายกัน
- ทุกคนชอบตัวบ่งชี้เชิงปริมาณและคุณภาพ สำหรับการทดสอบอัตโนมัติ ตัวบ่งชี้สากลดังกล่าวคือ Code Coverage หรือเมตริกความครอบคลุมของโค้ด เมื่อใช้ตัวบ่งชี้นี้ เราสามารถกำหนดเปอร์เซ็นต์ของโค้ดของระบบภายใต้การทดสอบที่ครอบคลุมโดยการทดสอบอัตโนมัติ ตั้งแต่เวอร์ชัน 12.2 เป็นต้นมา Oracle ให้ความสามารถในการคำนวณเมตริกนี้และแนะนำให้ใช้แพ็คเกจ DBMS_PLSQL_CODE_COVERAGE มาตรฐาน
ระบบทดสอบอัตโนมัติของเรามีอายุเพียง 1 ปี และอาจถึงเวลาประเมินความครอบคลุม ในโครงการสุดท้ายของฉัน (โครงการที่ไม่ใช่ของ Sportmaster) สิ่งนี้เกิดขึ้น หนึ่งปีหลังจากดำเนินการทดสอบอัตโนมัติ ฝ่ายบริหารได้กำหนดงานประเมินเปอร์เซ็นต์ของรหัสที่เราครอบคลุม ด้วยความคุ้มครองมากกว่า 10% ผู้บริหารจะมีความสุข เราซึ่งเป็นนักพัฒนาคาดหวังผลลัพธ์ประมาณ 20% เราแก้ไขความครอบคลุมของโค้ด วัดผลได้ XNUMX% เพื่อเป็นการเฉลิมฉลอง เราไปเพื่อรับรางวัล แต่วิธีที่เราไปรับรางวัลและที่ที่เราไปในภายหลังนั้นแตกต่างกันอย่างสิ้นเชิง
- การทดสอบอัตโนมัติสามารถทดสอบบริการบนเว็บที่เปิดเผยได้ Oracle อนุญาตให้คุณทำเช่นนี้ และเราจะไม่พบปัญหามากมายอีกต่อไป
- และแน่นอน ระบบทดสอบอัตโนมัติของเราสามารถนำไปใช้กับโครงการอื่นได้ โซลูชันที่เราได้รับเป็นแบบสากลและต้องใช้ Oracle เท่านั้น ฉันได้ยินมาว่ามีความสนใจในการทดสอบอัตโนมัติในโครงการ Sportmaster อื่น ๆ และบางทีเราจะไปหาพวกเขา
ผลการวิจัย
มาสรุปกัน ในโครงการระบบความภักดีใน Sportmaster เราได้ใช้ระบบทดสอบอัตโนมัติ พื้นฐานของมันคือโซลูชัน utPLSQL จาก Stephen Feuerstein รอบๆ utPLSQL คือโค้ดสำหรับการทดสอบอัตโนมัติและโมดูลเสริมที่เขียนขึ้นเอง: ลอนเชอร์ โมดูลการสร้างข้อมูล และอื่นๆ การทดสอบอัตโนมัติทำงานทุกวัน และที่สำคัญที่สุดคือการทำงานและผลประโยชน์ เราเชื่อมั่นว่าเราได้เริ่มเผยแพร่ซอฟต์แวร์ที่มีคุณภาพสูงขึ้นแล้ว ในเวลาเดียวกัน โซลูชันที่ได้จะเป็นแบบสากลและสามารถนำไปใช้กับโครงการใดๆ ได้อย่างอิสระที่จำเป็นต้องจัดระเบียบการทดสอบอัตโนมัติบน Oracle DBMS
ป.ล. บทความนี้ไม่เจาะจงมาก: มีข้อความจำนวนมากและไม่มีตัวอย่างทางเทคนิค หากหัวข้อนี้น่าสนใจทั่วโลก เราก็พร้อมที่จะดำเนินการต่อและกลับมาดำเนินการต่อ โดยเราจะบอกคุณว่ามีการเปลี่ยนแปลงอะไรบ้างในช่วงหกเดือนที่ผ่านมาและให้ตัวอย่างโค้ด
เขียนความคิดเห็นหากมีจุดที่ควรเน้นย้ำในอนาคต หรือคำถามที่ต้องมีการเปิดเผย
เฉพาะผู้ใช้ที่ลงทะเบียนเท่านั้นที่สามารถเข้าร่วมในการสำรวจได้ , โปรด.
เราจะเขียนเพิ่มเติมเกี่ยวกับเรื่องนี้หรือไม่?
-
ใช่แน่นอน
-
ไม่เป็นไรขอบคุณ
ผู้ใช้ 12 คนโหวต ผู้ใช้ 4 รายงดออกเสียง
ที่มา: will.com