ฉันต้องการเริ่มต้นด้วยการพูดทุกอย่างที่ฉันทำคือ SQL Server ดังนั้นนี่คือตัวอย่างที่ฉันให้ โดยทั่วไปอย่างไรก็ตามสิ่งนี้ใช้กับรหัสรูปแบบใด ๆ โดยไม่คำนึงถึงระบบ
มาเริ่มกันที่การทำลายอันนี้กันหน่อย
อัพเกรด
คุณมีระบบและกำลังจะอัพเกรดบางส่วนหรือทั้งหมด ตัวอย่างเช่นการอัพเกรดอินสแตนซ์จาก SQL Server 2012 เป็น 2014 ณ จุดนี้การทดสอบเป็นสิ่งจำเป็น น่าเสียดายที่การทดสอบทุกส่วนของแอปพลิเคชั่นขนาดเล็กอาจไม่สามารถทำได้ ณ จุดนี้ฉันจะทำสิ่งที่ฉันจะเรียกว่าการทดสอบ "ทำงาน" เป็นระบบพื้นฐานที่ใช้งานได้ วิ่งผ่านงานทั่วไปของคุณเริ่มต้นให้เสร็จ อย่าทดสอบทุกตัวเลือกเพียงแค่เส้นทางหลัก
เมื่อทำการอัพเกรด SQL Server นอกจากนี้ยังมีบางส่วนที่ต้องอ่าน โดยทั่วไปคุณต้องการอ่านBackward Compatibilityรายการสำหรับเวอร์ชั่นใหม่ ( นี่คือ 2014 ) และตรวจสอบให้แน่ใจว่าคุณไม่มีอะไรในรายการใด ๆ (ทำลายการเปลี่ยนแปลงการเปลี่ยนแปลงพฤติกรรม ฯลฯ )
รหัสแอปพลิเคชัน
ที่นี่เรากำลังมองหาใหม่ / เปลี่ยนรหัสแอปพลิเคชัน (เพราะแน่นอนสิ่งที่มีอยู่แล้วได้รับการทดสอบใช่ไหม?) ในกรณีนี้ควรทดสอบทุกอย่าง คุณควรมีการตั้งค่ากรณีทดสอบล่วงหน้าและดำเนินการผ่านคุณสมบัติส่วนใหญ่ที่ได้รับผลกระทบอย่างน้อย เมื่อถึงจุดนี้คุณควรให้คนอื่นตรวจสอบคล้ายกัน รหัสนี้จะถูกนำมาใช้อาจเป็นเวลานานพอสมควรและถูกใช้โดยคนจำนวนมาก คุณต้องการทำให้แน่ใจว่ามันใช้งานได้และทำงานได้ดี
หนึ่งในสิ่งที่สามารถช่วยได้จริงๆคือสร้างชุดunit testsที่สามารถทำซ้ำได้อย่างง่ายดาย Steve Jones แนะนำให้ใช้tSQLtเพื่อทดสอบรหัส TSQL ของคุณ (SQL Server เท่านั้นที่ฉันกลัว) แต่ด้วยการทำเช่นนี้คุณสามารถเรียกใช้ชุดการทดสอบที่กำหนดตายตัวได้อย่างรวดเร็วและจะช่วยในการทดสอบการถดถอย (การทดสอบทุกอย่างก่อนที่จะทำการอัปเกรด)
คุณสมบัติ / การตั้งค่า
มากกว่าการเปลี่ยนแปลงรหัสแอปพลิเคชันที่คุณต้องการทดสอบคุณสมบัติใหม่และการเปลี่ยนแปลงการกำหนดค่าอย่างละเอียด ถ้าเช่นคุณตัดสินใจที่จะเริ่มทำงานกับดัชนี columnstoreเป็นครั้งแรกที่คุณจะต้องทดสอบโค้ดทุกชิ้นที่สัมผัสกับตารางที่ได้รับผลกระทบ ใช้การทดสอบหน่วยที่คุณสร้างขึ้นเพื่อทดสอบแอปพลิเคชันของคุณ คุณสมบัติเหล่านี้อาจเป็นสิ่งใหม่สำหรับคุณ (และอาจเป็นสิ่งใหม่ในแพลตฟอร์ม) และอาจมีบางส่วนที่คุณไม่คาดคิด สำหรับการเปลี่ยนแปลงการกำหนดค่าคุณกำลังพูดถึงบางสิ่งที่อาจส่งผลกระทบต่อทั้งระบบของคุณ กฎง่ายๆคือการทดสอบและทดสอบอย่างระมัดระวัง มีการเปลี่ยนแปลงบางอย่างที่คุณจะไม่เห็นจริง ๆ จนกว่าคุณจะเข้าสู่ระบบที่ใช้งานอยู่ (อาจเป็นเพียงระบบการผลิตของคุณ) แต่นั่นไม่ใช่ข้อแก้ตัวที่จะไม่ลองใช้ในสภาพแวดล้อมการทดสอบก่อน
Ad hoc สอบถามที่อ้างอิง / ส่งผลกระทบต่อข้อมูลผู้ใช้
Ad Hocเมื่อคุณมีรหัสที่ส่งผลกระทบต่อข้อมูลของผู้ใช้ของคุณที่คุณต้องการโดยทั่วไปในการทดสอบนั้นได้และบางทีอาจจะเป็นโดยเฉพาะอย่างยิ่งเพราะมันเป็น ตอนนี้มีคนกล่าวว่าหากคุณกำลังรันโค้ดเดียวกันซ้ำแล้วซ้ำอีกเพียงแค่ใช้พารามิเตอร์ที่แตกต่างกันคุณอาจไม่ต้องกังวลเกี่ยวกับการทดสอบในแต่ละครั้ง
ตัวอย่างเช่นคุณต้องลบโฆษณาหนึ่งรายการขึ้นไปจากตาราง AdList ทุกไตรมาส
DELETE FROM AdList WHERE AdName IN ('January 2015 Ads','February 2015 Ads','March 2015 Ads')
ณ จุดนี้คุณได้ทดสอบโค้ดแล้ว (คุณเพิ่งเปลี่ยนสตริงคงที่) และอาจปลอดภัยพอที่จะรันโค้ด (สมมติว่าคุณมีการสำรองข้อมูลที่ดีในกรณีนี้)
วิธีการหนึ่งที่ง่ายต่อการทดสอบDELETE, UPDATEหรือINSERTคือการเปลี่ยนพวกเขาที่จะเลือกและเรียกพวกเขาแล้วยืนยันว่าจำนวนและประเภทของแถวที่คุณคาดว่าจะถูกส่งกลับ
คุณอาจคิดว่าคุณไม่จำเป็นต้องทดสอบSELECTเพราะพวกเขาไม่ได้เปลี่ยนแปลงข้อมูลใด ๆ อย่างไรก็ตามคุณใช้รหัสด้วยเหตุผลใช่ไหม? สมมติว่าคุณกำลังทำการวิจัยสำหรับผู้จัดการของคุณซึ่งจะส่งข้อมูลนี้ให้กับผู้จัดการของพวกเขาและอื่น ๆ คุณทดสอบเพื่อให้แน่ใจว่าคุณไม่ได้รับข้อมูลที่ผิด (หรือบล็อกผู้อื่นจากการรวบรวมข้อมูล)
แบบสอบถามเฉพาะกิจที่อ้างอิง / ส่งผลกระทบต่อข้อมูลระบบ
นี่อาจเป็นข้อยกเว้นอย่างหนึ่งสำหรับกฎ "ทดสอบทุกอย่าง" คุณกำลังเรียกใช้แบบสอบถามข้อมูลในข้อมูลระบบ สิ่งสำคัญที่นี่คือการเรียกคืนข้อมูลที่คุณคาดหวัง หากการสืบค้นเป็นสิ่งที่เรียบง่าย (การสอบถามมุมมองระบบ) คุณอาจจะตกลงตราบใดที่คุณได้ตรวจสอบความหมายของมุมมอง / คอลัมน์จริงๆ หากแบบสอบถามมีความซับซ้อน (กล่าวว่าการกดปุ่มการดู 3 หรือ 4 ระบบพร้อมการคำนวณในคอลัมน์ที่ส่งคืน) จากนั้นคุณอาจต้องการทดสอบสองสามครั้งเพื่อให้แน่ใจว่าคุณจะได้รับข้อมูลที่คุณต้องการคืน
สรุป
โดยสรุปใช่คุณต้องการทดสอบทุกอย่าง ถ้ามันสำคัญพอที่คุณจะเขียนและเรียกใช้มันก็สำคัญที่คุณจะต้องทำการทดสอบ นั่นไม่ได้หมายความว่าคุณจะต้องใช้เวลาจำนวนมหาศาลในการทดสอบทุกสาขาของโค้ดทุกบรรทัด แต่ต้องทำการทดสอบในระดับหนึ่ง
การทดสอบหน่วยอัตโนมัติเป็นเพื่อนของคุณที่นี่ ด้วยการกำเนิดของDevOpsและContinuous Integrationคุณจะเห็นแอปพลิเคชันและวิธีการทดสอบโค้ดของคุณอย่างรวดเร็วและง่ายดายมากขึ้น แน่นอนว่าต้องมีสภาพแวดล้อมการทดสอบและข้อมูลที่ดีเพื่อให้สอดคล้องกับมัน แต่นั่นเป็นการอภิปรายที่แตกต่างกันโดยสิ้นเชิง