การทดสอบและการตรวจสอบแอปพลิเคชัน
OpenFactory มีพื้นผิวที่เกี่ยวข้องสองแบบ:
- สถานการณ์อิมเมจที่บูตสิ่งประดิษฐ์ที่สร้างขึ้นและดำเนินการยืนยันแขกแบบมีขอบเขต และ
- การแสดงตัวอย่างแพลตฟอร์มแอปที่สร้างตัวแปรแอปที่ไม่เปลี่ยนรูปแบบ รวมถึงการทดสอบ UI และเวิร์กโฟลว์วอล์คเกอร์
ความพร้อมใช้งานแตกต่างกันอย่างมากในโมดูลแพลตฟอร์มแอป อ่านสถานะในแต่ละหน้าก่อนใช้งาน
ความพร้อมใช้งานของแพลตฟอร์มแอป
| หัวข้อ | ขอบเขตปัจจุบัน |
|---|---|
| App Deployment | จัดคิวแหล่งที่มา Git ผ่านไปป์ไลน์ตัวแปรที่ไม่เปลี่ยนรูปแบบ ติดตามการใช้งานแบบอะซิงโครนัสและหลักฐานด้านสุขภาพ |
| App UI Testing | จัดเก็บและรันสถานการณ์จำลองความหมายแบบมีขอบเขตกับเป้าหมายที่เข้าถึงได้ ผลลัพธ์พิสูจน์เฉพาะการกระทำและการยืนยันที่ระบุไว้เท่านั้น |
| Prompt-assisted deployment | ต้องมีเทมเพลต Git URL ที่มีอยู่ บรีฟคือที่มา ไม่ใช่การสร้างแหล่งที่มา |
| App environment variables | พื้นที่จัดเก็บข้อมูลที่เข้ารหัสและแฮนด์ออฟการปรับใช้จะถูกนำไปใช้เมื่อมีการกำหนดค่าคีย์/โทเค็นที่จำเป็น หลักฐานการหมุนเวียนและรันไทม์ยังคงเป็นข้อกังวลของผู้ปฏิบัติงาน |
| Managed Databases | สัญญาต้นขั้วเท่านั้น ไม่มีการจัดเตรียมฐานข้อมูล |
| Object Storage | สัญญาต้นขั้วเท่านั้น ไม่มีการจัดสรรที่เก็บข้อมูล |
| Custom Domains | Public-DNS การตรวจสอบความเป็นเจ้าของเท่านั้น TLS การให้บริการ/การกำหนดเส้นทางแบบกำหนดเองไม่ทำงาน |
| Checkpoints | ตัวระบุ Stub เท่านั้น ไม่มีสแน็ปช็อตที่สามารถกู้คืนได้ |
| Observability | การจัดเก็บเหตุการณ์ด้วยตนเองและการจัดสรร VM เป็นเรื่องจริง การนำเข้า การสอบสวน ตัวอย่าง บันทึก และแดชบอร์ดไม่สมบูรณ์ |
| Web IDE | การผูกมัดเท่านั้น ไม่มีการจัดเตรียมตัวแก้ไขหรือเส้นทางส่วนตัว |
| App Auth | การผูกมัดเท่านั้น ไม่มีการจัดหาผู้ให้บริการข้อมูลประจำตัว ผู้ออก หรือโฟลว์โทเค็นจริง |
| Templates and Remix | สร้างบันทึกแอปจากรายการหรือเชื้อสายแหล่งที่มาที่มีสิทธิ์ ไม่ปรับใช้หรือสร้างบริการที่ประกาศโดยอัตโนมัติ |
| Autonomous Walker | การค้นพบ UI แบบมีขอบเขตพร้อมการครอบคลุมที่สำคัญ การอนุญาต และขีดจำกัดผลข้างเคียง |
| Walker Diffs | เปรียบเทียบการเดินที่เก็บไว้และส่งออกน้ำหนักบรรทุกตามตั๋ว มันไม่ได้ยื่นตั๋วภายนอกด้วยตัวเอง |
| Walk and Fix | สร้างเจตนาแก้ไข การแพตช์ live-VM แบบเดิมขัดแย้งกับโมเดลการปรับใช้ที่ไม่เปลี่ยนรูป |
อย่าโยงอะแดปเตอร์ Stub เข้ากับเวิร์กโฟลว์ที่ใช้งานจริงเนื่องจาก API ของอะแดปเตอร์ส่งกลับความสำเร็จ
สถานการณ์รูปภาพ
การทดสอบอิมเมจจะทำงานเฉพาะเมื่อบิลด์/สถานการณ์ที่เลือกเปิดใช้งานและโครงสร้างพื้นฐานการทดสอบที่จำเป็นพร้อมใช้งาน แยกสถานะเหล่านี้ออกจากกัน:
- การก่อสร้างสิ่งประดิษฐ์
- การจัดเตรียมแขกและการบูต;
- การดำเนินการยืนยัน;
- การสรุปหลักฐาน และ
- นโยบายการรับรองหรือการตีพิมพ์
การสร้างสามารถทำได้สำเร็จในขณะที่การทดสอบถูกปิดใช้งาน รอดำเนินการ ล้มเหลว หรือไม่สมบูรณ์
ทดสอบการออกแบบ
การทดสอบในตัว
ชื่อในตัว เช่น boot, login, packages, network และ services จัดเตรียมข้อมูลพื้นฐาน ตรวจสอบ Default Tests เพื่อดูข้อจำกัดที่แม่นยำ
การยืนยันที่กำหนดเอง
ใช้ Custom Assertions สำหรับบริการ, พอร์ต, HTTP, ไฟล์, คำสั่ง, กระบวนการ และการสังเกต GUI ที่รองรับ การยืนยันทุกครั้งควรมีคำอธิบาย ผลลัพธ์ที่คาดหวัง เป้าหมาย การหมดเวลา และความหมายของความล้มเหลว
เกณฑ์มาตรฐาน
แค็ตตาล็อกเกณฑ์มาตรฐานเป็นชุดการตรวจสอบที่มีโครงสร้าง ไม่ใช่การพิจารณาการปฏิบัติตามข้อกำหนด จับคู่ระบบปฏิบัติการ/เวอร์ชันที่แน่นอน รักษาความเกี่ยวข้องและความล้มเหลว และอ่าน CIS benchmark evidence
รายการตรวจสอบหลักฐาน
สำหรับการดำเนินการที่ต้องตัดสินใจ ให้คงไว้:
- สูตร แหล่งที่มา บิลด์ อาร์ติแฟกต์ VM สถานการณ์ และรหัสการรัน
- สิ่งประดิษฐ์ที่แน่นอนและการย่อยแหล่งที่มา
- สภาพแวดล้อมการทดสอบและเวอร์ชันนักวิ่ง
- ทุกผลการยืนยันและผลลัพธ์ดิบ
- ภาพหน้าจอเฉพาะในกรณีที่สมเหตุสมผลและจัดการอย่างปลอดภัยเท่านั้น
- เช็คขาดหาย ข้าม หรือเช็คที่ใช้ไม่ได้
- การประทับเวลาและสถานะเทอร์มินัล และ
- การจัดการของผู้ตรวจสอบและการอนุมัติสำหรับการตัดสินใจดังกล่าว
เมื่อการทดสอบล้มเหลว ให้วินิจฉัยเลเยอร์ที่ล้มเหลวก่อนสร้างใหม่ การสร้างที่ซ้ำกันสามารถซ่อนความเป็นเจ้าของ การนำไปใช้งาน ผู้ทดสอบ หรือข้อบกพร่องในการสรุปหลักฐาน แทนที่จะแก้ไข