การทดสอบเมนเฟรม – บทช่วยสอนที่สมบูรณ์

ก่อนที่จะเรียนรู้แนวคิดการทดสอบเมนเฟรม เรามาเรียนรู้กันก่อน

เมนเฟรมคืออะไร?

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

การทดสอบเมนเฟรม

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

ในขณะที่ทำการทดสอบเมนเฟรม ผู้ทดสอบจำเป็นต้องทราบเพียงการนำทางของหน้าจอ CICS เท่านั้น สร้างขึ้นเป็นพิเศษสำหรับการใช้งานเฉพาะ การเปลี่ยนแปลงใดๆ ที่เกิดขึ้นกับโค้ดใน COBOL, JCL และอื่นๆ ผู้ทดสอบไม่จำเป็นต้องกังวลเกี่ยวกับโปรแกรมจำลองที่ตั้งค่าไว้ในเครื่อง การเปลี่ยนแปลงที่ทำงานบนโปรแกรมจำลองเทอร์มินัลตัวหนึ่งจะมีผลกับตัวอื่นด้วย

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

คุณสมบัติเมนเฟรม

1. พื้นที่เก็บข้อมูลเสมือน
   1. เป็นเทคนิคที่ช่วยให้โปรเซสเซอร์จำลองพื้นที่เก็บข้อมูลหลักที่มีขนาดใหญ่กว่าจำนวนพื้นที่จัดเก็บจริงจริง
   2. เป็นเทคนิคในการใช้หน่วยความจำอย่างมีประสิทธิภาพเพื่อจัดเก็บและดำเนินงานขนาดต่างๆ
   3. ใช้ที่เก็บข้อมูลดิสก์เป็นส่วนขยายของที่เก็บข้อมูลจริง
2. มัลติโปรแกรมมิ่ง
   1. คอมพิวเตอร์รันโปรแกรมมากกว่าหนึ่งโปรแกรมในเวลาเดียวกัน แต่ในขณะใดก็ตาม มีเพียงโปรแกรมเดียวเท่านั้นที่สามารถควบคุม CPU ได้
   2. เป็นสิ่งอำนวยความสะดวกที่จัดให้มีขึ้นเพื่อใช้งาน CPU อย่างมีประสิทธิภาพ
3. การประมวลผลแบบแบตช์
   1. เป็นเทคนิคที่ทำให้งานใดๆ สำเร็จในหน่วยที่เรียกว่างาน
   2. งานอาจทำให้หนึ่งหรือหลายโปรแกรมดำเนินการตามลำดับ
   3. ตัวกำหนดเวลางานจะตัดสินใจเกี่ยวกับลำดับที่ควรดำเนินการงาน เพื่อเพิ่มปริมาณงานโดยเฉลี่ย งานจะถูกจัดกำหนดการตามลำดับความสำคัญและชั้นเรียน
   4. ข้อมูลที่จำเป็นสำหรับการประมวลผลเป็นชุดมีให้ผ่าน JCL (JOB CONTROL LANGUAGE) JCL อธิบายงานแบบแบตช์ – โปรแกรม ข้อมูล และทรัพยากรที่จำเป็น
4. การแบ่งปันเวลา
   1. ในระบบแบ่งเวลา ผู้ใช้แต่ละคนสามารถเข้าถึงระบบได้ผ่านอุปกรณ์ปลายทาง แทนที่จะส่งงานที่กำหนดไว้สำหรับการดำเนินการในภายหลัง ผู้ใช้จะป้อนคำสั่งที่ประมวลผลทันที
   2. ดังนั้นจึงเรียกว่า "การประมวลผลเชิงโต้ตอบ" ช่วยให้ผู้ใช้สามารถโต้ตอบกับคอมพิวเตอร์ได้โดยตรง
   3. การประมวลผลการแบ่งเวลาเรียกว่า "การประมวลผลเบื้องหน้า" และการประมวลผลงานแบทช์เรียกว่า "การประมวลผลเบื้องหลัง"
5. spooling
   1. SPOOLing ย่อมาจาก อุปกรณ์ต่อพ่วงพร้อมกัน Operaออนไลน์.
   2. อุปกรณ์ SPOOL ใช้สำหรับจัดเก็บเอาต์พุตของโปรแกรม/แอปพลิเคชัน สพูลเอาท์พุตจะถูกส่งไปยังอุปกรณ์เอาท์พุต เช่น เครื่องพิมพ์ (หากจำเป็น)
   3. เป็นอุปกรณ์ที่ใช้ประโยชน์จากข้อดีของการบัฟเฟอร์เพื่อให้ใช้งานอุปกรณ์เอาต์พุตได้อย่างมีประสิทธิภาพ

การจำแนกประเภทของการทดสอบด้วยตนเองในเมนเฟรม

เมนเฟรม การทดสอบด้วยตนเอง สามารถจำแนกได้เป็น 2 ประเภท :

1. การทดสอบงานเป็นชุด -

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

2. การทดสอบออนไลน์ -

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

วิธีการทดสอบเมนเฟรม

1. ทีมธุรกิจจะจัดเตรียมเอกสารความต้องการ ซึ่งจะกำหนดว่ารายการหรือกระบวนการใดจะถูกปรับเปลี่ยนอย่างไรในรอบการเปิดตัว
2. ทีมทดสอบและทีมพัฒนาจะได้รับเอกสารความต้องการ พวกเขาจะคำนวณว่ากระบวนการต่างๆ กี่กระบวนการจะได้รับผลกระทบจากการเปลี่ยนแปลงนี้ โดยปกติแล้ว ในการเผยแพร่ จะมีเพียง 20-25% ของแอปพลิเคชันเท่านั้นที่ได้รับผลกระทบโดยตรงจากความต้องการที่ปรับแต่ง ส่วนอีก 75% ของการเผยแพร่จะเป็นฟังก์ชันนอกกรอบ เช่น การทดสอบแอปพลิเคชันและกระบวนการ
3. ดังนั้น แอปพลิเคชันเมนเฟรมจึงต้องได้รับการทดสอบเป็นสองส่วน:
   1. ข้อกำหนดในการทดสอบ – การทดสอบแอปพลิเคชันสำหรับฟังก์ชันการทำงานหรือการเปลี่ยนแปลงที่กล่าวถึงในเอกสารข้อกำหนด
   2. การทดสอบบูรณาการ – ทดสอบกระบวนการทั้งหมดหรือแอปพลิเคชันอื่นที่รับหรือส่งข้อมูลไปยังแอปพลิเคชันที่ได้รับผลกระทบ การทดสอบการถดถอย เป็นจุดสนใจหลักของกิจกรรมการทดสอบนี้

เครื่องมือทดสอบระบบเมนเฟรมอัตโนมัติ

ด้านล่างนี้คือรายการเครื่องมือที่สามารถใช้กับเมนเฟรมได้ การทดสอบระบบอัตโนมัติ.

• เรกซ์
• Excel
• คิวทีพี

ระเบียบวิธีในการทดสอบเมนเฟรม

ลองพิจารณาตัวอย่าง: บริษัทประกันภัย XYZ มีโมดูลการลงทะเบียนสมาชิก ใช้ข้อมูลทั้งจากหน้าจอการลงทะเบียนสมาชิกและการลงทะเบียนออฟไลน์ ดังที่เราได้กล่าวไว้ก่อนหน้านี้ การทดสอบเมนเฟรม การทดสอบออนไลน์ และการทดสอบแบบแบตช์ต้องใช้สองวิธี

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

ต่อไปนี้เป็นวิธีการที่ใช้สำหรับการทดสอบเมนเฟรม:

ขั้นตอน 1) เชคดาวน์/การทดสอบควัน

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

ขั้นตอน 2) การทดสอบระบบ

ด้านล่างนี้คือประเภทของการทดสอบที่ทำโดยเป็นส่วนหนึ่งของการทดสอบระบบ

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

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

4. การทดสอบฐานข้อมูล – ฐานข้อมูลที่ข้อมูลจากแอปพลิเคชันเมนเฟรม (IMS, IDMS, DB2, VSAM/ISAM, ชุดข้อมูลตามลำดับ, GDG) ได้รับการตรวจสอบความถูกต้องสำหรับเค้าโครงและการจัดเก็บข้อมูล

ขั้นตอน 3) System การทดสอบการผสานรวม

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

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

ประเภทของการทดสอบที่ทำในขั้นตอนนี้คือ

1. การทดสอบแบทช์
2. การทดสอบออนไลน์
3. ออนไลน์ – การทดสอบการรวมกลุ่ม

ขั้นตอน 4) การทดสอบการถดถอย

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

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

ขั้นตอน 5) การทดสอบประสิทธิภาพ

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

ขั้นตอน 6) การทดสอบความปลอดภัย

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

ควรทำการทดสอบความปลอดภัยสองเท่าบนระบบ - ความปลอดภัยของเมนเฟรมและความปลอดภัยของเครือข่าย

คุณสมบัติที่ต้องทดสอบคือ

1. Integrity
2. ความลับ
3. การอนุญาต
4. การยืนยันตัวตน
5. ความพร้อมที่จะให้บริการ

ขั้นตอนที่เกี่ยวข้องกับการทดสอบแบบแบตช์

1. หลังจากที่ทีม QA ได้รับแพ็คเกจที่ได้รับการอนุมัติ (แพ็คเกจประกอบด้วยขั้นตอน, JCL, การ์ดควบคุม, โมดูล ฯลฯ) ผู้ทดสอบควรดูตัวอย่างและดึงเนื้อหาลงใน PDS ตามที่ต้องการ
2. แปลง JCL การผลิตหรือ JCL การพัฒนาเป็น JCL QA หรือเรียกอีกอย่างว่า การตั้งค่างาน
3. การคัดลอกไฟล์การผลิตและการเตรียมไฟล์ทดสอบ
4. สำหรับทุกฟังก์ชันจะมีลำดับงานที่กำหนดไว้ (ตามที่อธิบายไว้ในตัวอย่างในระเบียบวิธีในส่วนเมนเฟรม) งานควรถูกส่งโดยใช้คำสั่ง SUB พร้อมกับไฟล์ข้อมูลทดสอบ
5. ตรวจสอบไฟล์ระดับกลางเพื่อระบุสาเหตุของข้อมูลสูญหายหรือเกิดข้อผิดพลาด
6. ตรวจสอบไฟล์เอาต์พุตสุดท้าย ฐานข้อมูล และ Spool เพื่อตรวจสอบผลการทดสอบ
7. หากงานล้มเหลว สปูลจะมีสาเหตุของความล้มเหลวของงาน แก้ไขข้อผิดพลาดและส่งงานอีกครั้ง

รายงานผลการทดสอบ – ข้อบกพร่อง ควรบันทึกไว้หากผลลัพธ์จริงเบี่ยงเบนไปจากที่คาดไว้

ขั้นตอนที่เกี่ยวข้องกับการทดสอบออนไลน์

1. เลือกหน้าจอออนไลน์ในสภาพแวดล้อมการทดสอบ
2. ทดสอบแต่ละฟิลด์เพื่อหาข้อมูลที่ยอมรับได้
3. ทดสอบไฟล์ สถานการณ์ทดสอบ บนหน้าจอ.
4. ตรวจสอบฐานข้อมูลสำหรับการอัพเดตข้อมูลจากหน้าจอออนไลน์

การรายงานการทดสอบ – ควรบันทึกข้อบกพร่องหากผลลัพธ์จริงเบี่ยงเบนไปจากที่คาดไว้

ขั้นตอนที่เกี่ยวข้องทางออนไลน์ – การทดสอบการรวมกลุ่ม

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

คำสั่งที่ใช้ในการทดสอบเมนเฟรม

1. ส่ง – ส่งงานพื้นหลัง
2. CANCEL – ยกเลิกงานพื้นหลัง
3. จัดสรร – จัดสรรชุดข้อมูล
4. คัดลอก – คัดลอกชุดข้อมูล
5. RENAME – เปลี่ยนชื่อชุดข้อมูล
6. ลบ – ลบชุดข้อมูล
7. JOB SCAN –เพื่อผูก JCL กับโปรแกรม ไลบรารี ไฟล์ ฯลฯ โดยไม่ต้องดำเนินการ

มีคำสั่งอื่นๆ อีกมากมายที่ใช้เมื่อจำเป็น แต่ก็ไม่บ่อยนัก

ข้อกำหนดเบื้องต้นเพื่อเริ่มการทดสอบเมนเฟรม

รายละเอียดพื้นฐานที่จำเป็นสำหรับการทดสอบเมนเฟรมมีดังนี้:

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

ก่อนที่จะเริ่มการทดสอบเมนเฟรม ควรตรวจสอบประเด็นด้านล่างนี้ก่อน

1. การสัมภาษณ์
   1. ทำการสแกนงาน (Command – JOBSCAN) เพื่อตรวจสอบข้อผิดพลาดก่อนดำเนินการ
   2. พารามิเตอร์ CLASS ควรชี้ไปที่คลาสทดสอบ
   3. กำหนดเอาต์พุตงานลงในสปูลหรือ JHS หรือตามต้องการโดยใช้พารามิเตอร์ MSGCLASS
   4. เปลี่ยนเส้นทางอีเมลในงานไปยังสปูลหรือรหัสอีเมลทดสอบ
   5. แสดงความคิดเห็นขั้นตอน FTP สำหรับการทดสอบเบื้องต้น จากนั้นชี้งานไปยังเซิร์ฟเวอร์ทดสอบ
   6. ในกรณีที่มีการสร้าง IMR (บันทึกการจัดการเหตุการณ์) ในงาน เพียงเพิ่มความคิดเห็น "วัตถุประสงค์ในการทดสอบ" ในงานหรือการ์ดพารามิเตอร์
   7. ไลบรารีการผลิตทั้งหมดในงานควรมีการเปลี่ยนแปลงและชี้ไปที่ไลบรารีทดสอบ
   8. ไม่ควรปล่อยงานทิ้งไว้โดยไม่มีใครดูแล
   9. เพื่อป้องกันไม่ให้งานรันในวงวนไม่สิ้นสุดในกรณีที่เกิดข้อผิดพลาด ควรเพิ่มพารามิเตอร์ TIME ตามเวลาที่กำหนด
   10. บันทึกเอาต์พุตของงานรวมถึงสปูลด้วย สามารถบันทึกสปูลได้โดยใช้ XDC

2. เนื้อไม่มีมัน
   1. สร้างไฟล์ทดสอบที่มีขนาดตามต้องการเท่านั้น ใช้ GDG (Generation Data Groups – ไฟล์ที่มีชื่อเดียวกันแต่มีหมายเลขเวอร์ชันเรียงตามลำดับ เช่น MYLIB.LIB.TEST.G0001V00, MYLIB.LIB.TEST.G0002V00 เป็นต้น) เมื่อจำเป็นต้องจัดเก็บข้อมูลในไฟล์ที่ต่อเนื่องกันที่มีชื่อเดียวกัน
   2. DISP (การจัดการ – อธิบายระบบในการดำเนินการเก็บหรือลบชุดข้อมูลหลังจากการยุติขั้นตอนหรืองานตามปกติหรือผิดปกติ) สำหรับไฟล์ควรมีการเข้ารหัสอย่างถูกต้อง
   3. ตรวจสอบให้แน่ใจว่าไฟล์ทั้งหมดที่ใช้สำหรับการดำเนินงานได้รับการบันทึกและปิดอย่างถูกต้องเพื่อป้องกันไม่ให้งานเข้าสู่ HOLD
   4. ในขณะที่ทดสอบโดยใช้ GDG ตรวจสอบให้แน่ใจว่าได้ชี้ไปที่เวอร์ชันที่ถูกต้อง
3. ฐานข้อมูล
   1. ขณะดำเนินงานหรือโปรแกรมออนไลน์ ตรวจสอบให้แน่ใจว่าไม่มีการแทรก อัปเดต หรือลบข้อมูลที่ไม่ได้ตั้งใจ
   2. นอกจากนี้ ตรวจสอบให้แน่ใจว่าใช้ขอบเขต DB2 ที่ถูกต้องสำหรับการทดสอบ
4. กรณีทดสอบ
   1. ทดสอบเงื่อนไขขอบเขตเสมอ เช่น – ไฟล์ว่างเปล่า การประมวลผลบันทึกครั้งแรก การประมวลผลบันทึกล่าสุด ฯลฯ
   2. รวมเงื่อนไขการทดสอบทั้งเชิงบวกและเชิงลบเสมอ
   3. ในกรณีที่มีการใช้ขั้นตอนมาตรฐานในโปรแกรม เช่น Check point restart, Abend Modules, Control files ฯลฯ ให้รวมกรณีทดสอบเพื่อตรวจสอบว่ามีการใช้งานโมดูลอย่างถูกต้องหรือไม่
5. ข้อมูลการทดสอบ
   1. ควรตั้งค่าข้อมูลทดสอบก่อนเริ่มการทดสอบ
   2. ห้ามแก้ไขข้อมูลในพื้นที่ทดสอบโดยไม่แจ้งให้ทราบ อาจมีทีมอื่นที่ทำงานโดยใช้ข้อมูลเดียวกัน และการทดสอบของพวกเขาอาจล้มเหลว
   3. ในกรณีที่จำเป็นต้องใช้ไฟล์ที่ใช้งานจริงในระหว่างดำเนินการ ควรได้รับอนุญาตอย่างเหมาะสมก่อนที่จะคัดลอกหรือใช้งาน

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

1. ในกรณีที่รัน Batch Job MAX CC 0 จะเป็นตัวบ่งชี้ว่างานรันสำเร็จ ไม่ได้หมายความว่าฟังก์ชันการทำงานทำงานได้ดี งานจะดำเนินการได้สำเร็จแม้ว่าเอาต์พุตจะว่างเปล่าหรือไม่เป็นไปตามที่คาดไว้ ดังนั้นจึงคาดหวังให้ตรวจสอบผลลัพธ์ทั้งหมดก่อนที่จะประกาศงานสำเร็จเสมอ
2. ถือเป็นแนวปฏิบัติที่ดีเสมอที่จะทดสอบการทำงานแบบแห้ง การทดลองรันเสร็จสิ้นด้วยไฟล์อินพุตเปล่า ควรปฏิบัติตามกระบวนการนี้สำหรับงานที่ได้รับผลกระทบจากการเปลี่ยนแปลงที่ทำขึ้นสำหรับรอบการทดสอบ
3. ก่อนที่รอบการทดสอบจะเริ่มขึ้น ควรตั้งค่างานทดสอบไว้ล่วงหน้า ซึ่งจะช่วยในการค้นหาข้อผิดพลาดของ JCL ล่วงหน้า ซึ่งจะช่วยประหยัดเวลาระหว่างการดำเนินการ
4. ขณะเข้าถึงตาราง DB2 ผ่าน SPUFI (ตัวเลือกบนโปรแกรมจำลองเพื่อเข้าถึงตาราง DB2) ให้ตั้งค่าการคอมมิตอัตโนมัติเป็น "ไม่" เสมอเพื่อหลีกเลี่ยงการอัปเดตโดยไม่ตั้งใจ
5. ความพร้อมใช้งานของข้อมูลทดสอบถือเป็นความท้าทายหลักในการทดสอบเป็นชุด ข้อมูลที่จำเป็นควรถูกสร้างขึ้นล่วงหน้าก่อนรอบการทดสอบ และควรได้รับการตรวจสอบเพื่อความครบถ้วน
6. ธุรกรรมออนไลน์และงานแบตช์บางอย่างอาจเขียนข้อมูลลงใน MQ (คิวข้อความ) เพื่อส่งข้อมูลไปยังแอปพลิเคชันอื่น หากข้อมูลไม่ถูกต้อง อาจปิดใช้งาน/หยุด MQ ซึ่งจะส่งผลต่อกระบวนการทดสอบทั้งหมด แนวทางปฏิบัติที่ดีในการตรวจสอบว่า MQ ทำงานได้ดีหลังจากการทดสอบ

ความท้าทายในการทดสอบเมนเฟรมและการแก้ไขปัญหา

ชาเลนจ์ (Challenge)	เข้าใกล้
ข้อกำหนดที่ไม่สมบูรณ์/ไม่ชัดเจน อาจมีการเข้าถึงคู่มือผู้ใช้/คู่มือการฝึกอบรม แต่ไม่เหมือนกับข้อกำหนดที่บันทึกไว้	ผู้ทดสอบควรมีส่วนร่วมใน SDLC ตั้งแต่ระยะข้อกำหนดเป็นต้นไป สิ่งนี้จะช่วยตรวจสอบว่าข้อกำหนดสามารถทดสอบได้หรือไม่
การตั้งค่าข้อมูล/การระบุตัวตน อาจมีสถานการณ์ที่ข้อมูลที่มีอยู่ควรถูกนำมาใช้ซ้ำตามข้อกำหนด บางครั้งการระบุข้อมูลที่ต้องการจากข้อมูลที่มีอยู่เป็นเรื่องยาก	สำหรับการตั้งค่าข้อมูล สามารถใช้เครื่องมือพื้นบ้านได้ตามความต้องการ สำหรับการดึงข้อมูลที่มีอยู่ ควรสร้างแบบสอบถามไว้ล่วงหน้า ในกรณีที่เกิดปัญหาใดๆ สามารถส่งคำขอไปยังทีมจัดการข้อมูลเพื่อสร้างหรือโคลนข้อมูลที่ต้องการได้
การตั้งค่างาน เมื่องานถูกดึงข้อมูลเข้าสู่ PDS แล้ว งานจะต้องได้รับการตั้งค่าในภูมิภาค QA เพื่อไม่ให้งานถูกส่งพร้อมกับตัวระบุการผลิตหรือรายละเอียดเส้นทาง	ควรใช้เครื่องมือจัดเตรียมงานเพื่อแก้ไขข้อผิดพลาดของมนุษย์ที่เกิดขึ้นระหว่างการตั้งค่า
คำขอเฉพาะกิจ อาจมีบางสถานการณ์ที่จำเป็นต้องได้รับการสนับสนุนการทดสอบตั้งแต่ต้นจนจบเนื่องจากปัญหาในปัญหาแอปพลิเคชันต้นน้ำหรือปลายน้ำ คำขอเหล่านี้จะเพิ่มเวลาและความพยายามในรอบการดำเนินการ	การใช้สคริปต์อัตโนมัติ สคริปต์การถดถอย และสคริปต์โครงร่างสามารถช่วยลดเวลาและค่าใช้จ่ายด้านความพยายามได้
การเผยแพร่ตรงเวลาสำหรับการเปลี่ยนแปลงขอบเขต อาจมีสถานการณ์ที่ผลกระทบของโค้ดอาจเปลี่ยนรูปลักษณ์ของระบบไปโดยสิ้นเชิง ซึ่งอาจจำเป็นต้องเปลี่ยนแปลงกรณีทดสอบ สคริปต์ และข้อมูล	ควรจัดให้มีกระบวนการจัดการการเปลี่ยนแปลงขอบเขตและการวิเคราะห์ผลกระทบ

พบความผิดปกติทั่วไป

1. S001 – เกิดข้อผิดพลาด I/O

   เหตุผล – การอ่านตอนท้ายไฟล์ ความยาวไฟล์ผิดพลาด พยายามเขียนลงในไฟล์แบบอ่านอย่างเดียว

2. S002 – บันทึก I/O ไม่ถูกต้อง

   เหตุผล – พยายามเขียนบันทึกที่ยาวเกินความยาวของบันทึก

3. S004 – เกิดข้อผิดพลาดระหว่างเปิด

   เหตุผล - DCB ไม่ถูกต้อง

4. S013 – เกิดข้อผิดพลาดในการเปิดชุดข้อมูล

   เหตุผล – ไม่มีสมาชิก PDS ความยาวบันทึกในโปรแกรมไม่ตรงกับความยาวบันทึกจริง

5. S0C1 – Operaข้อยกเว้น

   เหตุผล –ไม่สามารถเปิดไฟล์ได้ DD card หายไป

6. S0C4 – ข้อยกเว้นการป้องกัน/การละเมิดการจัดเก็บ
7. เหตุผล – การพยายามเข้าถึงที่เก็บข้อมูลไม่พร้อมใช้งานสำหรับโปรแกรม
8. S0C7 - ข้อยกเว้นการตรวจสอบโปรแกรม - ข้อมูล
9. เหตุผล – การเปลี่ยนแปลงเค้าโครงเรคคอร์ดหรือเค้าโครงไฟล์
10. Sx22 – งานถูกยกเลิกแล้ว
11. S222 – งานถูกยกเลิกโดยผู้ใช้โดยไม่มีดัมพ์
12. S322 – เวลางานหรือขั้นตอนเกินขีดจำกัดที่ระบุ หรือโปรแกรมอยู่ในลูปหรือพารามิเตอร์เวลาไม่เพียงพอ
13. S522 – หมดเวลาเซสชัน TSO
14. S806 – ไม่สามารถลิงก์หรือโหลดได้

    เหตุผล – รหัสงานไม่พบโมดูลโหลดที่ระบุ

15. S80A - พื้นที่เก็บข้อมูลเสมือนไม่เพียงพอที่จะตอบสนองคำขอ GETMAIN หรือ FREEMAIN
16. S913 – พยายามเข้าถึงชุดข้อมูลที่ผู้ใช้ไม่ได้รับอนุญาต
17. Sx37 – ไม่สามารถจัดสรรพื้นที่เก็บข้อมูลเพียงพอให้กับชุดข้อมูลได้

Error Assist – เครื่องมือยอดนิยมในการรับข้อมูลโดยละเอียดเกี่ยวกับการผิดปกติประเภทต่างๆ

ปัญหาทั่วไปที่พบในระหว่างการทดสอบเมนเฟรม

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

สรุป

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