บทช่วยสอนการทดสอบฐานข้อมูล (ข้อมูล)

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

ลองพิจารณาแอปพลิเคชันการธนาคารที่ผู้ใช้ทำธุรกรรม จากมุมมองการทดสอบฐานข้อมูลหรือการทดสอบ DB ต่อไปนี้ สิ่งสำคัญคือ:

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

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

ความแตกต่างระหว่างการทดสอบส่วนต่อประสานกับผู้ใช้และการทดสอบข้อมูล

การทดสอบส่วนต่อประสานกับผู้ใช้	การทดสอบฐานข้อมูลหรือข้อมูล
การทดสอบประเภทนี้เรียกอีกอย่างว่าการทดสอบส่วนต่อประสานกับผู้ใช้แบบกราฟิกหรือการทดสอบส่วนหน้า	การทดสอบประเภทนี้เรียกอีกอย่างว่าการทดสอบแบ็กเอนด์หรือการทดสอบข้อมูล
การทดสอบประเภทนี้ส่วนใหญ่เกี่ยวข้องกับรายการทดสอบทั้งหมดที่เปิดให้ผู้ใช้รับชมและการโต้ตอบ เช่น แบบฟอร์ม การนำเสนอ กราฟ เมนู และรายงาน ฯลฯ (สร้างผ่าน VB, VB.net, VC++, Delphi – เครื่องมือส่วนหน้า)	การทดสอบประเภทนี้ส่วนใหญ่เกี่ยวข้องกับรายการทดสอบทั้งหมดซึ่งโดยทั่วไปแล้วจะซ่อนไม่ให้ผู้ใช้เห็นเพื่อการดู ซึ่งรวมถึงกระบวนการภายในและการจัดเก็บข้อมูลเช่น Assembly, DBMS ชอบ Oracle, SQL Server, MYSQL ฯลฯ.
การทดสอบประเภทนี้รวมถึงการตรวจสอบความถูกต้องของ กล่องข้อความ เลือกดรอปดาวน์ ปฏิทินและปุ่มต่างๆ การนำทางหน้า การแสดงภาพ รูปลักษณ์และความรู้สึกของการใช้งานโดยรวม	การทดสอบประเภทนี้เกี่ยวข้องกับการตรวจสอบความถูกต้อง: สคีมา ตารางฐานข้อมูล คอลัมน์ คีย์และดัชนี ทริกเกอร์ขั้นตอนการจัดเก็บ การตรวจสอบเซิร์ฟเวอร์ฐานข้อมูล ตรวจสอบความซ้ำซ้อนของข้อมูล
ผู้ทดสอบจะต้องมีความรู้อย่างถ่องแท้เกี่ยวกับข้อกำหนดทางธุรกิจ ตลอดจนการใช้เครื่องมือการพัฒนา ตลอดจนการใช้เฟรมเวิร์กและเครื่องมืออัตโนมัติ	เพื่อจะสามารถทำการทดสอบแบ็คเอนด์ได้ ผู้ทดสอบจะต้องมีความรู้พื้นฐานที่แข็งแกร่งในเซิร์ฟเวอร์ฐานข้อมูลและแนวคิดของ Structured Query Language

ประเภทของการทดสอบฐานข้อมูล

การทดสอบฐานข้อมูลมี 3 ประเภท คือ

1. การทดสอบโครงสร้าง
2. การทดสอบสมรรถนะ
3. การทดสอบที่ไม่ใช้งาน

ในบทช่วยสอนการทดสอบฐานข้อมูลนี้ เราจะดูแต่ละประเภทและประเภทย่อยทีละรายการ

การทดสอบสคีมาคืออะไร?

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

ให้เราหารือเกี่ยวกับจุดตรวจสอบที่สำคัญที่สุดสำหรับการทดสอบสคีมา

1. การตรวจสอบความถูกต้องของรูปแบบสคีมาต่างๆ ที่เกี่ยวข้องกับฐานข้อมูล หลายครั้งที่รูปแบบการแมปของตารางอาจเข้ากันไม่ได้กับรูปแบบการแมปที่มีอยู่ในระดับส่วนต่อประสานผู้ใช้ของแอปพลิเคชัน
2. จำเป็นต้องมีการตรวจสอบในกรณีของตาราง/มุมมอง/คอลัมน์ที่ไม่ได้แมป
3. นอกจากนี้ ยังจำเป็นต้องตรวจสอบว่าฐานข้อมูลที่มีความหลากหลายในสภาพแวดล้อมสอดคล้องกับการแมปแอปพลิเคชันโดยรวมหรือไม่

ให้เราดูเครื่องมือทดสอบฐานข้อมูลที่น่าสนใจสำหรับการตรวจสอบความถูกต้องของสคีมาฐานข้อมูล

• DBUnit ที่รวมเข้ากับ Ant เหมาะมากสำหรับการทดสอบการทำแผนที่
• SQL Server ช่วยให้ผู้ทดสอบสามารถตรวจสอบและสืบค้นสคีมาของฐานข้อมูลโดยการเขียนคำสั่งง่ายๆ ไม่ใช่ผ่านโค้ด

ตัวอย่างเช่น หากนักพัฒนาต้องการเปลี่ยนโครงสร้างตารางหรือลบออก ผู้ทดสอบจะต้องการให้แน่ใจว่า Stored Procedures และ Views ทั้งหมดที่ใช้ตารางนั้นเข้ากันได้กับการเปลี่ยนแปลงนั้นๆ อีกตัวอย่างหนึ่งอาจเป็นได้ว่าหากผู้ทดสอบต้องการตรวจสอบการเปลี่ยนแปลงสคีมาระหว่าง 2 ฐานข้อมูล พวกเขาสามารถทำได้โดยใช้แบบสอบถามง่ายๆ

ตารางฐานข้อมูล การทดสอบคอลัมน์

ให้เราดูการตรวจสอบต่างๆ สำหรับการทดสอบฐานข้อมูลและคอลัมน์

1. การแมปฟิลด์ฐานข้อมูลและคอลัมน์ในแบ็กเอนด์เข้ากันได้กับการแมปเหล่านั้นในฟรอนต์เอนด์หรือไม่
2. การตรวจสอบความถูกต้องของความยาวและการตั้งชื่อของฟิลด์ฐานข้อมูลและคอลัมน์ตามที่ระบุโดยข้อกำหนด
3. การตรวจสอบความถูกต้องของการมีอยู่ของตาราง/คอลัมน์ฐานข้อมูลที่ไม่ได้ใช้/ไม่ได้แมป
4. การตรวจสอบความเข้ากันได้ของ

• ประเภทข้อมูล
• ความยาวสนาม

ของคอลัมน์ฐานข้อมูลส่วนหลังโดยมีคอลัมน์อยู่ที่ส่วนหน้าของแอปพลิเคชัน

5. ไม่ว่าฟิลด์ฐานข้อมูลจะอนุญาตให้ผู้ใช้ป้อนข้อมูลผู้ใช้ที่ต้องการตามที่กำหนดในเอกสารข้อกำหนดข้อกำหนดทางธุรกิจหรือไม่

การทดสอบคีย์และดัชนี

การตรวจสอบคีย์และดัชนีที่สำคัญ –

1. ตรวจสอบว่าจำเป็นหรือไม่

• คีย์หลัก
• ต่างประเทศที่สำคัญ

มีการสร้างข้อจำกัดในตารางที่ต้องการ

2. ตรวจสอบว่าการอ้างอิงสำหรับคีย์ต่างประเทศนั้นถูกต้องหรือไม่
3. ตรวจสอบว่าชนิดข้อมูลของคีย์หลักและคีย์ต่างประเทศที่เกี่ยวข้องเหมือนกันในทั้งสองตารางหรือไม่
4. ตรวจสอบว่ามีการปฏิบัติตามหลักการตั้งชื่อที่จำเป็นสำหรับคีย์และดัชนีทั้งหมดหรือไม่
5. ตรวจสอบขนาดและความยาวของฟิลด์และดัชนีที่จำเป็น
6. ไม่ว่าจะจำเป็นก็ตาม

• Clusterดัชนีเอ็ด
• ไม่ Clusterดัชนีเอ็ด

ได้ถูกสร้างขึ้นบนตารางที่จำเป็นตามที่กำหนดโดยข้อกำหนดทางธุรกิจ

การทดสอบขั้นตอนการจัดเก็บ

การทดสอบที่สำคัญในการตรวจสอบขั้นตอนการจัดเก็บคือ:

1. ไม่ว่าทีมพัฒนาจะใช้ข้อกำหนด A) แบบแผนมาตรฐานการเข้ารหัส และ B) การจัดการข้อยกเว้นและข้อผิดพลาดหรือไม่ สำหรับขั้นตอนการจัดเก็บทั้งหมดสำหรับโมดูลทั้งหมดสำหรับแอปพลิเคชันภายใต้การทดสอบ
2. ทีมพัฒนาได้ครอบคลุมเงื่อนไข/ลูปทั้งหมดโดยการนำข้อมูลอินพุตที่จำเป็นไปใช้กับแอปพลิเคชันที่กำลังทดสอบหรือไม่
3. ทีมพัฒนาได้ใช้การดำเนินการ TRIM อย่างถูกต้องหรือไม่ทุกครั้งที่ดึงข้อมูลจากตารางที่ต้องการในฐานข้อมูล
4. การดำเนินการด้วยตนเองของ Stored Procedure จะให้ผลลัพธ์ที่ต้องการแก่ผู้ใช้ปลายทางหรือไม่
5. การดำเนินการด้วยตนเองของ Stored Procedure ช่วยให้มั่นใจได้ว่าฟิลด์ตารางได้รับการอัปเดตตามที่แอปพลิเคชันภายใต้การทดสอบต้องการหรือไม่
6. ไม่ว่าการดำเนินการของ Stored Procedures จะเปิดใช้งานการเรียกใช้ทริกเกอร์ที่จำเป็นโดยนัยหรือไม่
7. การตรวจสอบความถูกต้องของการมีอยู่ของขั้นตอนการจัดเก็บที่ไม่ได้ใช้
8. การตรวจสอบเงื่อนไข Allow Null ซึ่งสามารถทำได้ในระดับฐานข้อมูล
9. การตรวจสอบความถูกต้องของข้อเท็จจริงที่ว่าขั้นตอนและฟังก์ชันที่เก็บไว้ทั้งหมดได้รับการดำเนินการเรียบร้อยแล้วเมื่อฐานข้อมูลที่อยู่ระหว่างการทดสอบว่างเปล่า
10. การตรวจสอบความถูกต้องของการบูรณาการโดยรวมของโมดูลขั้นตอนการจัดเก็บตามข้อกำหนดของแอปพลิเคชันภายใต้การทดสอบ

เครื่องมือทดสอบฐานข้อมูลที่มีประโยชน์บางส่วนสำหรับการทดสอบขั้นตอนการจัดเก็บ ได้แก่ LINQ , เครื่องมือทดสอบ SP เป็นต้น

การทดสอบทริกเกอร์

1. มีการปฏิบัติตามแบบแผนการเข้ารหัสที่จำเป็นในระหว่างขั้นตอนการเข้ารหัสของทริกเกอร์หรือไม่
2. ตรวจสอบว่าทริกเกอร์ที่ดำเนินการสำหรับธุรกรรม DML ที่เกี่ยวข้องนั้นตรงตามเงื่อนไขที่กำหนดหรือไม่
3. ทริกเกอร์จะอัปเดตข้อมูลอย่างถูกต้องหรือไม่เมื่อดำเนินการแล้ว
4. การตรวจสอบความถูกต้องของการอัปเดต/แทรก/ลบที่จำเป็นจะทำให้เกิดฟังก์ชันการทำงานในขอบเขตของแอปพลิเคชันที่อยู่ระหว่างการทดสอบ

การตรวจสอบเซิร์ฟเวอร์ฐานข้อมูล

1. ตรวจสอบการกำหนดค่าเซิร์ฟเวอร์ฐานข้อมูลตามที่ระบุไว้ในข้อกำหนดทางธุรกิจ
2. ตรวจสอบการอนุญาตของผู้ใช้ที่ต้องการเพื่อดำเนินการเฉพาะระดับที่แอปพลิเคชันกำหนดเท่านั้น
3. ตรวจสอบว่าเซิร์ฟเวอร์ฐานข้อมูลสามารถตอบสนองความต้องการของจำนวนการทำธุรกรรมของผู้ใช้สูงสุดที่อนุญาตตามที่ระบุไว้ในข้อกำหนดข้อกำหนดทางธุรกิจ

การทดสอบฐานข้อมูลเชิงฟังก์ชัน

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

ต่อไปนี้เป็นเงื่อนไขพื้นฐานที่จำเป็นต้องปฏิบัติตามสำหรับการตรวจสอบฐานข้อมูล

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

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

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

การตรวจสอบความสมบูรณ์และความสอดคล้องของข้อมูล

การตรวจสอบต่อไปนี้มีความสำคัญ

1. ข้อมูลได้รับการจัดระเบียบอย่างดีตามตรรกะหรือไม่?
2. ข้อมูลที่จัดเก็บไว้ในตารางนั้นถูกต้องและเป็นไปตามข้อกำหนดทางธุรกิจหรือไม่?
3. มีข้อมูลที่ไม่จำเป็นใดๆ ปรากฏอยู่ในแอปพลิเคชันที่อยู่ระหว่างการทดสอบหรือไม่
4. ข้อมูลถูกจัดเก็บตามข้อกำหนดเกี่ยวกับข้อมูลที่อัปเดตจากอินเทอร์เฟซผู้ใช้หรือไม่
5. การดำเนินการ TRIM ได้ดำเนินการกับข้อมูลก่อนที่จะแทรกข้อมูลลงในฐานข้อมูลภายใต้การทดสอบหรือไม่
6. ธุรกรรมได้ดำเนินการตามข้อกำหนดข้อกำหนดทางธุรกิจหรือไม่ และผลลัพธ์ถูกต้องหรือไม่?
7. ข้อมูลมีความมุ่งมั่นอย่างถูกต้องหรือไม่หากธุรกรรมได้รับการดำเนินการสำเร็จหรือไม่?
8. ข้อมูลได้รับการย้อนกลับสำเร็จหรือไม่ หากผู้ใช้ปลายทางดำเนินการธุรกรรมไม่สำเร็จ
9. หากธุรกรรมไม่ได้ดำเนินการสำเร็จและมีฐานข้อมูลที่แตกต่างกันหลายฐานเกี่ยวข้องในธุรกรรมที่เกี่ยวข้อง ข้อมูลจะได้รับการย้อนกลับหรือไม่?
10. ธุรกรรมทั้งหมดได้ดำเนินการโดยใช้ขั้นตอนการออกแบบที่จำเป็นตามที่ระบุไว้ในข้อกำหนดทางธุรกิจของระบบหรือไม่

การเข้าสู่ระบบและความปลอดภัยของผู้ใช้

การตรวจสอบข้อมูลประจำตัวในการเข้าสู่ระบบและความปลอดภัยของผู้ใช้จะต้องคำนึงถึงสิ่งต่อไปนี้

1. ไม่ว่าแอปพลิเคชันจะป้องกันไม่ให้ผู้ใช้ดำเนินการต่อไปในแอปพลิเคชันหรือไม่ในกรณีของ

• ชื่อผู้ใช้ไม่ถูกต้องแต่รหัสผ่านที่ถูกต้อง
• ชื่อผู้ใช้ที่ถูกต้องแต่รหัสผ่านไม่ถูกต้อง
• ชื่อผู้ใช้และรหัสผ่านไม่ถูกต้อง

2. ผู้ใช้จะได้รับอนุญาตให้ดำเนินการเฉพาะตามที่กำหนดโดยข้อกำหนดทางธุรกิจหรือไม่
3. ข้อมูลมีความปลอดภัยจากการเข้าถึงโดยไม่ได้รับอนุญาตหรือไม่?
4. มีบทบาทผู้ใช้ที่แตกต่างกันซึ่งสร้างด้วยสิทธิ์ที่แตกต่างกันหรือไม่
5. ผู้ใช้ทั้งหมดมีระดับการเข้าถึงฐานข้อมูลที่ระบุตามที่กำหนดโดยข้อกำหนดทางธุรกิจหรือไม่
6. ตรวจสอบว่าข้อมูลสำคัญ เช่น รหัสผ่าน หมายเลขบัตรเครดิต ได้รับการเข้ารหัสและไม่ได้จัดเก็บเป็นข้อความธรรมดาในฐานข้อมูล ควรตรวจสอบให้ดีว่าบัญชีทั้งหมดควรมีรหัสผ่านที่ซับซ้อนและเดาได้ยาก

การทดสอบที่ไม่ใช้งาน

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

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

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

โหลดการทดสอบ

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

1. ธุรกรรมของผู้ใช้ที่ใช้บ่อยที่สุดมีแนวโน้มที่จะส่งผลกระทบต่อประสิทธิภาพของธุรกรรมอื่นๆ ทั้งหมด หากธุรกรรมเหล่านั้นไม่มีประสิทธิภาพ
2. ควรจะรวมธุรกรรมผู้ใช้ที่ไม่มีการแก้ไขอย่างน้อยหนึ่งรายการในชุดการทดสอบขั้นสุดท้าย เพื่อให้ประสิทธิภาพของธุรกรรมดังกล่าวสามารถแยกแยะความแตกต่างจากธุรกรรมอื่นๆ ที่ซับซ้อนกว่าได้
3. ควรรวมธุรกรรมที่สำคัญกว่าที่เอื้อต่อวัตถุประสงค์หลักของระบบ เนื่องจากความล้มเหลวภายใต้ภาระของธุรกรรมเหล่านี้มีผลกระทบที่ยิ่งใหญ่ที่สุดตามคำนิยาม
4. ควรรวมธุรกรรมที่แก้ไขได้อย่างน้อยหนึ่งรายการไว้ด้วย การปฏิบัติ ของธุรกรรมดังกล่าวสามารถแยกความแตกต่างจากธุรกรรมอื่นๆ ได้
5. เวลาตอบสนองที่เหมาะสมที่สุดภายใต้จำนวนผู้ใช้เสมือนจริงจำนวนมากสำหรับความต้องการในอนาคตทั้งหมด
6. เวลาที่มีประสิทธิภาพในการดึงข้อมูลบันทึกต่างๆ

เครื่องมือทดสอบโหลดที่สำคัญได้แก่ โหลดรันเนอร์มืออาชีพ, ชนะนักวิ่ง และ JMeter.

เครื่องมือทดสอบความเครียดที่สำคัญคือ โหลดรันเนอร์มืออาชีพ and JMeter.

ปัญหาที่พบบ่อยที่สุดระหว่างการทดสอบฐานข้อมูล

A significant amount of overhead could be involved to determine the state of the database transactions

วิธีการแก้: การวางแผนกระบวนการและเวลาโดยรวมควรได้รับการจัดระเบียบเพื่อไม่ให้เกิดปัญหาด้านเวลาและต้นทุนปรากฏขึ้น

New test data have to be designed after cleaning up of the old test data.

วิธีการแก้: แผนและวิธีการก่อนหน้าสำหรับการสร้างข้อมูลทดสอบควรอยู่ในมือ

An SQL generator is required to transform SQL validators in order to ensure the SQL queries are apt for handling the required database test cases.

วิธีการแก้: การบำรุงรักษาคำสั่ง SQL และการอัปเดตอย่างต่อเนื่องเป็นส่วนสำคัญของกระบวนการทดสอบโดยรวมซึ่งควรเป็นส่วนหนึ่งของภาพรวม กลยุทธ์การทดสอบ.

The above mentioned prerequisite ensure that the set-up of the database testing procedure could be costly as well as time consuming.

วิธีการแก้: ควรมีความสมดุลที่ดีระหว่างคุณภาพและระยะเวลากำหนดการโครงการโดยรวม

ตำนานหรือความเข้าใจผิดที่เกี่ยวข้องกับการทดสอบฐานข้อมูล

Database Testing requires plenty of expertise and it is a very tedious job

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

Database testing adds extra work bottleneck

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

Database testing slows down the overall development process

ความจริง: การทดสอบฐานข้อมูลจำนวนมากช่วยในการปรับปรุงคุณภาพโดยรวมสำหรับแอปพลิเคชันฐานข้อมูล

Database testing could be excessively costly

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

ปฏิบัติที่ดีที่สุด

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

ตรวจสอบด้วย- คำถามและคำตอบสัมภาษณ์การทดสอบฐานข้อมูล