การทดสอบ: การอัปเดตและ Plugin

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

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

สิ่งที่เราปกป้อง

• tarball ของแพ็กเกจมีเนื้อหาครบถ้วน มี dist/postinstall-inventory.json ที่ถูกต้อง และไม่พึ่งพาไฟล์ในรีโพที่ไม่ได้บรรจุมา
• ผู้ใช้สามารถย้ายจากแพ็กเกจรุ่นเก่าที่เผยแพร่แล้วไปยังแพ็กเกจตัวเลือก โดยไม่สูญเสียการกำหนดค่า เอเจนต์ เซสชัน เวิร์กสเปซ รายการอนุญาตของ Plugin หรือ การกำหนดค่าช่องทาง
• openclaw doctor --fix --non-interactive เป็นเจ้าของเส้นทางการล้างและซ่อมแซม ข้อมูลเก่า การเริ่มต้นระบบไม่ควรเพิ่มการย้ายข้อมูลเพื่อความเข้ากันได้แบบซ่อนสำหรับสถานะ Plugin ที่ค้างอยู่
• การติดตั้ง Plugin ทำงานได้จากไดเรกทอรีภายในเครื่อง รีโพ git แพ็กเกจ npm และ เส้นทางรีจิสทรี ClawHub
• การติดตั้งการขึ้นต่อกันของ npm สำหรับ Plugin แต่ละรายการเกิดขึ้นในโปรเจกต์ npm ที่มีการจัดการหนึ่งโปรเจกต์ต่อ Plugin ถูกสแกนก่อนให้ความเชื่อถือ และถูกนำออกผ่าน npm uninstall ระหว่าง การถอนการติดตั้ง Plugin เพื่อไม่ให้การขึ้นต่อกันที่ถูกยกระดับขึ้นไปยังระดับบนค้างอยู่
• การอัปเดต Plugin จะไม่ดำเนินการใดเมื่อไม่มีสิ่งเปลี่ยนแปลง: ระเบียนการติดตั้ง แหล่งที่มา ที่แก้ไขแล้ว โครงสร้างการขึ้นต่อกันที่ติดตั้ง และสถานะการเปิดใช้งานยังคงเดิม

การพิสูจน์ภายในเครื่องระหว่างการพัฒนา

เริ่มจากขอบเขตแคบ:

pnpm changed:lanes --jsonpnpm check:changedpnpm test:changed

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

pnpm test src/plugins/uninstall.test.ts src/infra/package-dist-inventory.test.ts test/scripts/package-acceptance-workflow.test.ts

ก่อนที่เลน Docker ของแพ็กเกจใดจะใช้ tarball ให้พิสูจน์อาร์ติแฟกต์แพ็กเกจก่อน:

pnpm release:check

release:check รันการตรวจสอบความคลาดเคลื่อนของการกำหนดค่า/เอกสาร/API (สคีมาการกำหนดค่า เส้นฐานเอกสาร การกำหนดค่า เส้นฐานและการส่งออก API ของ Plugin SDK รุ่น/คลังรายการ Plugin) เขียนคลังรายการ dist ของแพ็กเกจ รัน npm pack --dry-run ปฏิเสธไฟล์ต้องห้าม ที่ถูกบรรจุ ติดตั้ง tarball ลงในคำนำหน้าชั่วคราว รัน postinstall และ ทดสอบเบื้องต้นกับจุดเข้าของช่องทางที่รวมมา

เลน Docker

เลน Docker คือหลักฐานระดับผลิตภัณฑ์ โดยติดตั้งหรืออัปเดตแพ็กเกจจริง ภายในคอนเทนเนอร์ Linux และยืนยันพฤติกรรมผ่านคำสั่ง CLI การเริ่มต้น Gateway การตรวจสอบ HTTP สถานะ RPC และสถานะระบบไฟล์

ใช้เลนเฉพาะจุดระหว่างการปรับแก้:

pnpm test:docker:pluginspnpm test:docker:plugin-lifecycle-matrixpnpm test:docker:plugin-updatepnpm test:docker:upgrade-survivorpnpm test:docker:published-upgrade-survivorpnpm test:docker:update-restart-authpnpm test:docker:update-migration

เลนสำคัญ:

• test:docker:plugins ครอบคลุมการทดสอบเบื้องต้นของการติดตั้ง Plugin การติดตั้งจากโฟลเดอร์ภายในเครื่อง พฤติกรรมข้ามการอัปเดตโฟลเดอร์ภายในเครื่อง โฟลเดอร์ภายในเครื่องที่มี การขึ้นต่อกันติดตั้งไว้ล่วงหน้า การติดตั้งแพ็กเกจ file: การติดตั้งจาก git พร้อมการเรียกใช้ CLI การอัปเดต ref ของ git ที่เคลื่อนที่ได้ การติดตั้งจากรีจิสทรี npm ที่มีการขึ้นต่อกันทางอ้อม ซึ่งถูกยกระดับขึ้นไปยังระดับบน การไม่ดำเนินการเมื่ออัปเดต npm การปฏิเสธเมทาดาทาของแพ็กเกจ npm ที่ผิดรูปแบบ การติดตั้งจากฟิกซ์เจอร์ ClawHub ภายในเครื่องและการไม่ดำเนินการเมื่ออัปเดต พฤติกรรมการอัปเดตมาร์เก็ตเพลส และการเปิดใช้งาน/ตรวจสอบบันเดิล Claude ตั้งค่า OPENCLAW_PLUGINS_E2E_CLAWHUB=0 เพื่อ ให้บล็อก ClawHub ทำงานแบบปิดและออฟไลน์
• test:docker:plugin-lifecycle-matrix ติดตั้งแพ็กเกจตัวเลือกในคอนเทนเนอร์เปล่า รัน Plugin npm ผ่านการติดตั้ง ตรวจสอบ ปิดใช้งาน เปิดใช้งาน อัปเกรดแบบระบุชัด ดาวน์เกรดแบบระบุชัด และถอนการติดตั้งหลังจากลบโค้ด Plugin โดยบันทึกเมตริก RSS และ CPU ในแต่ละระยะ
• test:docker:plugin-update ตรวจสอบว่า Plugin ที่ติดตั้งแล้วและไม่มีการเปลี่ยนแปลง จะไม่ถูกติดตั้งซ้ำหรือสูญเสียเมทาดาทาการติดตั้งระหว่าง openclaw plugins update
• test:docker:upgrade-survivor ติดตั้ง tarball ตัวเลือกทับฟิกซ์เจอร์ผู้ใช้เก่า ที่มีข้อมูลค้าง รันการอัปเดตแพ็กเกจพร้อม doctor แบบไม่โต้ตอบ จากนั้นเริ่ม Gateway แบบ local loopback และตรวจสอบการรักษาสถานะ
• test:docker:published-upgrade-survivor ติดตั้งเส้นฐานที่เผยแพร่แล้วก่อน กำหนดค่าผ่านสูตร openclaw config set ที่ฝังไว้ อัปเดตเป็น tarball ตัวเลือก รัน doctor ตรวจสอบการล้างข้อมูลเก่า เริ่ม Gateway และ ตรวจสอบ /healthz, /readyz และสถานะ RPC
• test:docker:update-restart-auth ติดตั้งแพ็กเกจตัวเลือก เริ่ม Gateway ที่จัดการด้วยการตรวจสอบสิทธิ์แบบโทเค็น ยกเลิกการตั้งค่า env การตรวจสอบสิทธิ์ Gateway ของผู้เรียกสำหรับ openclaw update --yes --json และกำหนดให้คำสั่งอัปเดตตัวเลือก รีสตาร์ต Gateway ก่อนการตรวจสอบตามปกติ
• test:docker:update-migration คือเลนอัปเดตจากรุ่นเผยแพร่ที่เน้นการล้างข้อมูล โดยเริ่มจากสถานะผู้ใช้ที่กำหนดค่าในรูปแบบ Discord/Telegram รัน doctor เส้นฐานเพื่อให้การขึ้นต่อกันของ Plugin ที่กำหนดค่ามีโอกาสถูกสร้างขึ้น เติม เศษการขึ้นต่อกันเก่าของ Plugin สำหรับ Plugin แบบแพ็กเกจที่กำหนดค่าไว้ อัปเดตเป็น tarball ตัวเลือก และกำหนดให้ doctor หลังอัปเดตนำรากการขึ้นต่อกันเก่าออก

รูปแบบทางเลือกที่มีประโยชน์ของการทดสอบการอัปเกรดจากรุ่นเผยแพร่:

OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPEC=openclaw@2026.4.23 \OPENCLAW_UPGRADE_SURVIVOR_SCENARIO=versioned-runtime-deps \pnpm test:docker:published-upgrade-survivor OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPEC=openclaw@latest \OPENCLAW_UPGRADE_SURVIVOR_SCENARIO=bootstrap-persona \pnpm test:docker:published-upgrade-survivor

สถานการณ์ที่ใช้ได้: base, acpx-openclaw-tools-bridge, feishu-channel, bootstrap-persona, channel-post-core-restore, plugin-deps-cleanup, configured-plugin-installs, stale-source-plugin-shadow, tilde-log-path และ versioned-runtime-deps ในการรันแบบรวม OPENCLAW_UPGRADE_SURVIVOR_SCENARIOS=reported-issues (นามแฝง far-reaching) จะขยายเป็นทุกสถานการณ์ รวมถึง การย้ายข้อมูลการติดตั้ง Plugin ที่กำหนดค่าไว้

การย้ายข้อมูลการอัปเดตแบบเต็มถูกแยกออกจาก CI การเผยแพร่แบบเต็มโดยตั้งใจ ใช้ เวิร์กโฟลว์ Update Migration แบบเรียกเองเมื่อคำถามสำหรับการเผยแพร่คือ "รุ่นเสถียร ที่เผยแพร่ทุกรุ่นตั้งแต่ 2026.4.23 เป็นต้นมาสามารถอัปเดตเป็นตัวเลือกนี้และ ล้างเศษการขึ้นต่อกันของ Plugin ได้หรือไม่":

gh workflow run update-migration.yml \  --ref main \  -f workflow_ref=main \  -f package_ref=main \  -f baselines=all-since-2026.4.23 \  -f scenarios=plugin-deps-cleanup

การยอมรับแพ็กเกจ

การยอมรับแพ็กเกจคือเกตแพ็กเกจที่ทำงานบน GitHub โดยจะแก้ไขแพ็กเกจตัวเลือกหนึ่งรายการ เป็น tarball package-under-test บันทึกรุ่นและ SHA-256 จากนั้น รันเลน Docker E2E ที่ใช้ซ้ำได้กับ tarball เดียวกันนั้น ref ของชุดควบคุมเวิร์กโฟลว์ แยกจาก ref แหล่งที่มาของแพ็กเกจ เพื่อให้ตรรกะการทดสอบปัจจุบันสามารถตรวจสอบ รุ่นที่เชื่อถือได้ซึ่งเก่ากว่า

แหล่งที่มาของตัวเลือก:

• source=npm: ตรวจสอบ openclaw@extended-stable, openclaw@beta, openclaw@latest หรือรุ่นที่เผยแพร่แบบระบุชัด
• source=ref: บรรจุสาขา แท็ก หรือคอมมิตที่เชื่อถือได้ด้วยชุดควบคุมปัจจุบัน ที่เลือก
• source=url: ตรวจสอบ tarball HTTPS สาธารณะที่ต้องมี package_sha256 เส้นทางนี้ปฏิเสธข้อมูลรับรองใน URL พอร์ต HTTPS ที่ไม่ใช่ค่าเริ่มต้น ชื่อโฮสต์หรือ ผลลัพธ์ DNS/IP แบบส่วนตัว/ภายใน พื้นที่ IP สำหรับการใช้งานพิเศษ และการเปลี่ยนเส้นทางที่ไม่ปลอดภัย
• source=trusted-url: ตรวจสอบ tarball HTTPS ที่ต้องมี package_sha256 และ trusted_source_id ตามนโยบายที่ผู้ดูแลเป็นเจ้าของ ใน .github/package-trusted-sources.json ใช้ตัวเลือกนี้สำหรับมิเรอร์ระดับองค์กร/ส่วนตัว แทนการทำให้ source=url อ่อนแอลงด้วยสวิตช์อนุญาตเครือข่ายส่วนตัวระดับอินพุต การตรวจสอบสิทธิ์แบบ Bearer เมื่อกำหนดค่าโดยนโยบาย จะใช้ซีเคร็ต OPENCLAW_TRUSTED_PACKAGE_TOKEN แบบคงที่
• source=artifact: ใช้ tarball ที่อัปโหลดโดยการรัน Actions อื่นซ้ำ

การตรวจสอบความถูกต้องของการเผยแพร่แบบเต็มใช้ source=artifact เป็นค่าเริ่มต้น โดยสร้างจาก SHA ของรุ่นเผยแพร่ที่แก้ไขแล้ว สำหรับการพิสูจน์หลังเผยแพร่ ให้ส่ง package_acceptance_package_spec=openclaw@YYYY.M.PATCH เพื่อให้เมทริกซ์การอัปเกรดเดียวกัน มุ่งไปที่แพ็กเกจ npm ที่เผยแพร่แล้วแทน

การตรวจสอบรุ่นเผยแพร่เรียกการยอมรับแพ็กเกจด้วยชุดแพ็กเกจ/อัปเดต/รีสตาร์ต/Plugin:

doctor-switch update-channel-switch skill-install update-corrupt-plugin upgrade-survivor published-upgrade-survivor root-managed-vps-upgrade update-restart-auth plugins-offline plugin-update plugin-binding-command-escape

เมื่อเปิดใช้การแช่ทดสอบรุ่นเผยแพร่ (บังคับเปิดสำหรับ release_profile=stable และ full) ระบบจะส่งค่าเหล่านี้เพิ่มเติม:

published_upgrade_survivor_baselines=last-stable-4 2026.4.23 2026.5.2 2026.4.15published_upgrade_survivor_scenarios=reported-issuestelegram_mode=mock-openai

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

last-stable-4 จะแก้ไขเป็น OpenClaw รุ่นเสถียรสี่รุ่นล่าสุด ที่เผยแพร่บน npm การยอมรับแพ็กเกจรุ่นเผยแพร่ปักหมุด 2026.4.23 เป็นขอบเขตความเข้ากันได้ แรกสำหรับการอัปเดต Plugin, 2026.5.2 เป็นขอบเขตที่สถาปัตยกรรม Plugin เปลี่ยนแปลงมาก และ 2026.4.15 เป็นเส้นฐานการอัปเดตจากรุ่นเผยแพร่ 2026.4.1x ที่เก่ากว่า ตัวแก้ไข จะตัดหมุดที่มีอยู่แล้วในสี่รุ่นล่าสุดออก สำหรับความครอบคลุมการย้ายข้อมูล การอัปเดตจากรุ่นเผยแพร่แบบครบถ้วน ให้ใช้ all-since-2026.4.23 ในเวิร์กโฟลว์ Update Migration ที่แยกต่างหากแทน CI การเผยแพร่แบบเต็ม release-history ยังคง ใช้ได้สำหรับการสุ่มตัวอย่างที่กว้างขึ้นแบบเรียกเอง เมื่อคุณต้องการจุดยึดเก่าก่อนวันที่กำหนดด้วย

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

รันโปรไฟล์แพ็กเกจด้วยตนเองเมื่อตรวจสอบตัวเลือกก่อนเผยแพร่:

gh workflow run package-acceptance.yml \  --ref main \  -f workflow_ref=main \  -f source=npm \  -f package_spec=openclaw@beta \  -f suite_profile=package \  -f published_upgrade_survivor_baselines="last-stable-4 2026.4.23 2026.5.2 2026.4.15" \  -f published_upgrade_survivor_scenarios=reported-issues \  -f telegram_mode=mock-openai

สำหรับคานารี extended-stable ที่เผยแพร่แล้ว ให้ตั้งค่า package_spec=openclaw@extended-stable การยอมรับแพ็กเกจจะแก้ไข ตัวเลือกนั้นเป็น tarball ที่ระบุชัดก่อนที่เลน Docker จะรัน

ใช้ suite_profile=product เมื่อคำถามสำหรับการเผยแพร่ครอบคลุมช่องทาง MCP การล้าง Cron/เอเจนต์ย่อย การค้นหาเว็บของ OpenAI หรือ OpenWebUI ใช้ suite_profile=full เฉพาะเมื่อต้องการความครอบคลุมเส้นทางการเผยแพร่ Docker แบบเต็ม

ค่าเริ่มต้นสำหรับการเผยแพร่

สำหรับตัวเลือกรุ่นเผยแพร่ สแต็กการพิสูจน์เริ่มต้นคือ:

1. pnpm check:changed และ pnpm test:changed สำหรับการถดถอยระดับซอร์ส
2. pnpm release:check สำหรับความสมบูรณ์ของอาร์ติแฟกต์แพ็กเกจ
3. โปรไฟล์ package ของการยอมรับแพ็กเกจ หรือเลนแพ็กเกจแบบกำหนดเองของการตรวจสอบ รุ่นเผยแพร่ สำหรับสัญญาการติดตั้ง/อัปเดต/รีสตาร์ต/Plugin
4. การตรวจสอบรุ่นเผยแพร่ข้ามระบบปฏิบัติการสำหรับตัวติดตั้ง การเริ่มต้นใช้งาน และพฤติกรรม เฉพาะแพลตฟอร์ม
5. ชุดทดสอบแบบใช้งานจริงเฉพาะเมื่อพื้นผิวที่เปลี่ยนแปลงเกี่ยวข้องกับพฤติกรรมของผู้ให้บริการหรือ บริการที่โฮสต์

บนเครื่องของผู้ดูแล เกตกว้างและการพิสูจน์ผลิตภัณฑ์ Docker/แพ็กเกจควรรัน ใน Testbox เว้นแต่กำลังทำการพิสูจน์ภายในเครื่องอย่างชัดเจน

ความเข้ากันได้กับรุ่นเก่า

การผ่อนปรนด้านความเข้ากันได้มีขอบเขตแคบและจำกัดเวลา:

• แพ็กเกจจนถึง 2026.4.25 รวมถึง 2026.4.25-beta.* อาจยอมรับ ช่องว่างของเมทาดาทาแพ็กเกจที่เผยแพร่ไปแล้วในการยอมรับแพ็กเกจ
• แพ็กเกจ 2026.4.26 ที่เผยแพร่แล้วอาจแสดงคำเตือนสำหรับไฟล์ตราประทับเมทาดาทา การบิลด์ภายในเครื่องที่เผยแพร่ไปแล้ว
• แพ็กเกจที่ใหม่กว่าต้องเป็นไปตามสัญญาสมัยใหม่ ช่องว่างเดียวกันจะทำให้ล้มเหลวแทนที่จะ เตือนหรือข้าม

อย่าเพิ่มการย้ายข้อมูลใหม่ระหว่างการเริ่มต้นสำหรับรูปแบบเก่าเหล่านี้ ให้เพิ่มหรือขยายการซ่อมแซมของ doctor จากนั้นพิสูจน์ด้วย upgrade-survivor, published-upgrade-survivor หรือ update-restart-auth เมื่อคำสั่งอัปเดตเป็นเจ้าของการรีสตาร์ต

การเพิ่มความครอบคลุม

เมื่อเปลี่ยนพฤติกรรมการอัปเดตหรือ Plugin ให้เพิ่มความครอบคลุมที่ชั้นต่ำที่สุดซึ่ง สามารถล้มเหลวด้วยเหตุผลที่ถูกต้อง:

• ตรรกะเกี่ยวกับพาธหรือเมทาดาทาล้วน ๆ: ทดสอบหน่วยไว้ข้างซอร์ส
• พฤติกรรมของรายการไฟล์ในแพ็กเกจหรือไฟล์ที่ถูกแพ็ก: การทดสอบ package-dist-inventory หรือตัวตรวจสอบ tarball
• พฤติกรรมการติดตั้ง/อัปเดตผ่าน CLI: การยืนยันผลในเลน Docker หรือฟิกซ์เจอร์
• พฤติกรรมการย้ายข้อมูลของรุ่นที่เผยแพร่แล้ว: สถานการณ์ published-upgrade-survivor
• พฤติกรรมการรีสตาร์ตที่การอัปเดตเป็นผู้รับผิดชอบ: update-restart-auth
• พฤติกรรมของรีจิสทรี/แหล่งแพ็กเกจ: ฟิกซ์เจอร์ test:docker:plugins หรือเซิร์ฟเวอร์ฟิกซ์เจอร์ ClawHub
• พฤติกรรมของโครงสร้างการจัดวางหรือการล้างข้อมูลของการขึ้นต่อกัน: ยืนยันทั้งการทำงานขณะรันไทม์และขอบเขตระบบไฟล์ การขึ้นต่อกันของ npm อาจถูกยกระดับไว้ภายในโปรเจกต์ npm ที่ Plugin จัดการ ดังนั้นการทดสอบควรพิสูจน์ว่าโปรเจกต์ดังกล่าวได้รับการสแกน/ล้างข้อมูล แทนที่จะสมมติว่ามีเพียงโครงสร้าง node_modules ภายในแพ็กเกจของ Plugin

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

การคัดแยกความล้มเหลว

เริ่มจากข้อมูลระบุอาร์ติแฟกต์:

• สรุป resolve_package ของการตรวจรับแพ็กเกจ: แหล่งที่มา เวอร์ชัน SHA-256 และชื่ออาร์ติแฟกต์
• อาร์ติแฟกต์ Docker: .artifacts/docker-tests/**/summary.json, failures.json, บันทึกของเลน และคำสั่งสำหรับรันซ้ำ
• สรุปการคงอยู่หลังอัปเกรด: .artifacts/upgrade-survivor/summary.json ซึ่งรวมถึงเวอร์ชันฐาน เวอร์ชันที่เสนอ สถานการณ์ ระยะเวลาของแต่ละเฟส และความครอบคลุมของสูตรการกำหนดค่า

ควรรันซ้ำเฉพาะเลนที่ล้มเหลวโดยใช้อาร์ติแฟกต์แพ็กเกจเดิม แทนการรันชุดการทดสอบรุ่นทั้งหมดซ้ำ