ทดสอบส่วนที่เหมาะสมของผลิตภัณฑ์
โดยอัตโนมัติ
Zof สร้าง ดำเนินการ และดูแลการทดสอบกระบวนการใช้งาน API และการผสานรวมต่าง ๆ เมื่อผลิตภัณฑ์ของคุณเปลี่ยนแปลง
19
ขอบเขตการตรวจสอบยืนยัน
เฉพาะจุด
เลือกหลักฐานตามการเปลี่ยนแปลงแต่ละครั้ง ไม่ใช่รันทุกการทดสอบทุกครั้ง
CI
การรันและด่านควบคุมที่ผสานเข้ากับระบบโดยตรง
พิจารณา
หลักฐานการตรวจสอบยืนยัน
Verification Engine ทำงานอย่างไร
Zof พิจารณาว่าการตรวจสอบยืนยันใดเหมาะสมจากการเปลี่ยนแปลง System Graph ความเสี่ยง และนโยบายองค์กร โดยไม่ได้รันการทดสอบที่เป็นไปได้ทั้งหมดในทุกการเปลี่ยนแปลง

- 01
วิเคราะห์การเปลี่ยนแปลง
System Graph ระบุระบบที่ได้รับผลกระทบ ระดับความสำคัญ มาตรการควบคุมที่เกี่ยวข้อง และประวัติเหตุขัดข้อง
- 02
เลือกหลักฐานที่จำเป็น
นโยบายและความเสี่ยงเป็นตัวกำหนดว่าขอบเขตการตรวจสอบยืนยันใดต้องสร้างหลักฐานสำหรับการเปลี่ยนแปลงนี้
- 03
รันและรวบรวม
เครื่องมือที่ให้ผลแน่นอนตามกฎ ระบบตรวจสอบยืนยันเฉพาะทาง เครื่องมือตรวจสอบของลูกค้า ผล CI ที่มีอยู่ และโมเดลที่ได้รับอนุมัติ เป็นผู้สร้างหลักฐาน
- 04
ปิดผนึกและตัดสินใจ
ผลลัพธ์จะถูกปิดผนึกเป็นชุดหลักฐานและส่งต่อให้ Control Plane เพื่อออกคำตัดสินที่บังคับใช้ได้
การทดสอบในฐานะการตรวจสอบยืนยันที่สร้างหลักฐาน
การทดสอบยังคงเป็นจุดเริ่มต้น ภายใน Zof ทุกการทดสอบจะกลายเป็นหลักฐานที่คำตัดสินด้านการควบคุมสามารถใช้อ้างอิงได้
- 01
เลือกโดยคำนึงถึงการเปลี่ยนแปลง
การตรวจสอบยืนยันมุ่งเน้นสิ่งที่การเปลี่ยนแปลงอาจส่งผลกระทบ จึงสร้างหลักฐานที่เหมาะสมได้โดยไม่ต้องรันทุกอย่างทุกครั้ง
- 02
ขอบเขตการตรวจสอบยืนยันสิบเก้าด้าน
การทดสอบหน่วย การเชื่อมต่อ ตั้งแต่ต้นจนจบ API ความปลอดภัย ประสิทธิภาพ โหลด ภาวะกดดัน ความทนทาน การขยายขนาด การฟื้นตัว การปฏิบัติตามข้อกำหนด การถดถอย การเข้าถึง และอีกมากมาย ภายใต้สถาปัตยกรรมเดียว
- 03
ใช้เครื่องมือที่ให้ผลแน่นอนก่อน ใช้ AI เมื่อได้รับอนุมัติ
เครื่องมือที่ให้ผลแน่นอนตามกฎและระบบตรวจสอบยืนยันเฉพาะทางเป็นแหล่งหลักฐาน โมเดล AI ที่ได้รับอนุมัติจะใช้เหตุผลวิเคราะห์ผลลัพธ์และช่องว่างเฉพาะในกรณีที่นโยบายอนุญาตเท่านั้น
- 04
หลักฐาน ไม่ใช่เพียงเครื่องหมายถูกสีเขียว
ผลลัพธ์ที่มีโครงสร้าง อาร์ติแฟกต์ ข้อมูลติดตาม และบันทึก จะถูกปิดผนึกเป็นชุดหลักฐานและแนบกับคำตัดสิน
ผลลัพธ์ที่ทีมวัด
ทดสอบแอปพลิเคชันนี้
ระบุแอปพลิเคชันให้ Zof แล้วระบบจะสร้าง รัน และดูแลการตรวจสอบยืนยันครอบคลุมขั้นตอนการใช้งานของผู้ใช้ APIs และการเชื่อมต่อ
19
ขอบเขตการตรวจสอบยืนยันตรวจสอบยืนยันรุ่นที่จะปล่อยนี้
ทุกการเปลี่ยนแปลงที่มีนัยสำคัญจะสร้างหลักฐานตามที่นโยบายกำหนด ก่อนที่ด่านควบคุมการนำขึ้นใช้งานจะเปิด
พิจารณา
หลักฐานต่อการรันทดสอบบริการนี้ภายใต้ภาวะกดดัน
การตรวจสอบโหลด ภาวะกดดัน ความทนทาน และการฟื้นตัว จะทดสอบรูปแบบความล้มเหลวที่การทดสอบปกติไม่เคยเข้าถึง
CI
การรันที่ผสานเข้ากับระบบโดยตรงตรวจสอบความถูกต้องก่อนขึ้นระบบจริง
การตรวจสอบข้อกำหนดและนโยบายจะรันควบคู่กับการตรวจสอบฟังก์ชัน เพื่อให้การเปลี่ยนแปลงที่อยู่ภายใต้กฎระเบียบมีหลักฐานของตนเอง
นโยบาย
เลือกสิ่งที่จะรัน
รันในที่ที่ทีมของคุณทำงานอยู่แล้ว
Verification Engine เชื่อมต่อกับคลังโค้ด ไปป์ไลน์ CI/CD และเครื่องมือทำงานร่วมกัน ชุดทดสอบที่มีอยู่และผล CI นับเป็นหลักฐานได้
ไปป์ไลน์ CI/CD
GitHub Actions, GitLab CI, Jenkins, CircleCI และ Azure DevOps เรียกใช้การตรวจสอบยืนยันและบังคับใช้คำตัดสินด้านการควบคุม
ชุดทดสอบที่มีอยู่
Playwright, Cypress, Selenium และเฟรมเวิร์กทดสอบหน่วยยังคงรันต่อไป โดยผลลัพธ์จะกลายเป็นหลักฐาน
System Graph
ทุกการรันอ้างอิงบริบทสถาปัตยกรรมปัจจุบัน ทำให้ Zof รู้ว่าต้องตรวจสอบยืนยันอะไรและเพราะเหตุใด
การตรวจยืนยันภายใต้การกำกับดูแล พร้อมการอนุมัติโดยมนุษย์ในทุกขั้นตอนสำคัญ
- การตรวจยืนยันอย่างต่อเนื่องภายใต้ชั้นการควบคุมของคุณ
- System Graph ทำแผนที่ความสัมพันธ์ที่พึ่งพากันก่อนปล่อยการเปลี่ยนแปลง
- หลักฐานระดับการตรวจสอบสำหรับการทบทวนการปฏิบัติตามข้อกำหนด
ดู Verification Engine บนสแตกของคุณ
จอง Reliability Sprint: หนึ่งระบบ พร้อมหลักฐานว่าจุดใดล้มเหลวและจุดใดยังทำงานได้ดี
- ให้มนุษย์อนุมัติเมื่อมีข้อกำหนดในนโยบาย
- ทำงานร่วมกับ Playwright, Cypress, Selenium
- RBAC ระดับองค์กร
รันการทดสอบและเข้าใจว่าทำไมจึงล้มเหลว
ทุกการรันจะคืนค่าเทเลเมทรี อาร์ติแฟกต์ และการวิเคราะห์หาสาเหตุที่แท้จริง ไม่ใช่แค่เครื่องหมายถูกสีเขียว
ก้าวข้ามผ่าน/ไม่ผ่านด้วยการวิเคราะห์ความน่าเชื่อถือ
