PHP Pest Testing Automation Script — คู่มือฉบับสมบูรณ์ 2026 | SiamCafe Blog

PHP Pest Testing Automation Script คืออะไร — แนวคิดและหลักการสำคัญ

สวัสดีครับ อ.บอม ที่นี่ SiamCafe Blog หลายคนที่ตามผมมาตลอดจะรู้ว่าผมเล่นหุ้นทองคำและเทรดฟอเร็กซ์กับ XM มากว่า 13 ปี

แต่อีกด้านหนึ่งของชีวิตคือการเขียนโปรแกรมและดูแลระบบไอทีมานานหลายสิบปี วันนี้เลยอยากพาเพื่อน ๆ มารู้จักกับเครื่องมือที่เปลี่ยนวิธีการเขียนโค้ดของผมไปตลอดกาล นั่นคือ PHP Pest Testing Automation Script หรือการเขียนสคริปต์ทดสอบอัตโนมัติด้วยเฟรมเวิร์ก Pest บนภาษา PHP นั่นเอง

Pest เป็นเฟรมเวิร์กทดสอบที่พัฒนาต่อยอดจาก PHPUnit โดยดึงเอาความเรียบง่ายของเครื่องมืออย่าง Jest ในโลกจาวาสคริปต์มาใช้ จุดขายที่ผมชอบที่สุดคือรูปแบบการเขียนแบบ "expectation" ที่อ่านแล้วเหมือนภาษาอังกฤษธรรมดา ไม่ต้องเขียน class และ method ยาว ๆ แบบสมัย PHPUnit เก่า ๆ แค่คำว่า it() และ expect() ก็จบแล้ว ในปี 2026 นี้ระบบซอฟต์แวร์ซับซ้อนขึ้นกว่าเดิมมาก ทั้งเว็บแอปพลิเคชัน ระบบซื้อขายอัตโนมัติ และแอปพลิเคชันที่เชื่อมต่อกับโปรแกรมซื้อขายหุ้น ถ้าเราไม่มีระบบทดสอบอัตโนมัติที่ดี โอกาสที่โค้ดจะพังตอนขึ้นใช้งานจริงสูงมากครับ

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

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

ผมอยากให้คิดภาพตามก่อนครับ สมมติคุณมีโค้ด PHP อยู่ 50,000 บรรทัด มีทีมพัฒนา 5 คน แก้โค้ดวันละ 30 ครั้ง ถ้าไม่มีการทดสอบอัตโนมัติ ทุกครั้งที่แก้

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

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

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

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

ใครควรใช้และใช้ตอนไหน

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

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

เริ่มต้นติดตั้งและเขียนเทสต์ Pest ตัวแรกทีละขั้น

มาลงมือกันเลยครับ สมมติคุณมีโปรเจค PHP อยู่แล้ว ขั้นแรกคือติดตั้ง Pest ผ่านเครื่องมือจัดการแพ็กเกจ Composer ด้วยคำสั่งดังนี้

composer require pestphp/pest --dev --with-all-dependencies ./vendor/bin/pest --init

คำสั่งที่สองจะสร้างไฟล์ตั้งค่าพื้นฐานให้อัตโนมัติ ทั้งไฟล์ Tests/Pest.php และโฟลเดอร์ tests/Feature กับ tests/Unit ก่อนติดตั้ง ให้เช็กก่อนว่าเซิร์ฟเวอร์หรือเครื่องที่พัฒนารองรับเวอร์ชันภาษา PHP ที่ Pest กำหนดในปี 2026 ซึ่งต้องใช้เวอร์ชันแปดขึ้นไป ผมแนะนำให้ใช้เวอร์ชันล่าสุดที่เสถียรเลย เพราะทั้งความเร็วในการประมวลผลและคุณสมบัติใหม่ ๆ อย่างการประกาศชนิดข้อมูลในฟังก์ชันช่วยให้เทสต์แม่นยำขึ้นอีกชั้นหนึ่ง

จากนั้นลองเขียนเทสต์ตัวแรกในไฟล์ tests/Unit/CalculatorTest.php

toBe(35); });

it('คำนวณภาษีมูลค่าเพิ่มเจ็ดเปอร์เซ็นต์', function () { $ราคา = 1000; $ภาษี = $ราคา * 0.07; expect($ภาษี)->toBe(70.0); });

it('ปฏิเสธราคาติดลบ', function () { $คำนวณ = fn($ราคา) => $ราคา < 0 ? throw new InvalidArgumentException('ราคาห้ามติดลบ') : $ราคา * 1.07;

expect(fn() => $คำนวณ(-100)) ->toThrow(InvalidArgumentException::class); });

สังเกตไหมครับว่าโค้ดสั้นและอ่านง่ายมาก ไม่ต้องมี class ครอบ ไม่ต้องเขียนคำอธิบายว่าอะไรอย่างไรเป็นเอกสารแยก จากนั้นรันด้วยคำสั่ง

./vendor/bin/pest

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

คำสั่งที่ใช้บ่อยในงานประจำวัน

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

เทคนิคที่ควรรู้ในระดับถัดไปคือการจัดกลุ่มด้วย describe และการใช้ข้อมูลทดสอบซ้ำแบบ dataset เช่น

it('ตรวจสอบความถูกต้องของอีเมล', function (string $อีเมล, bool $ผลคาดหวัง) { expect(isValidEmail($อีเมล))->toBe($ผลคาดหวัง); })->with([ ['somchai@example.com', true], ['ไม่มีแอท', false], ['', false], ]);

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

ข้อผิดพลาดของมือใหม่ที่เจอบ่อย

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

โครงสร้างเทสต์ระดับสูง — Unit, Feature และ Integration

การทดสอบที่ดีต้องมีหลายชั้นเหมือนการเทรดที่ต้องมีการบริหารความเสี่ยงหลายชั้นครับ ผมขอแบ่งเป็นตารางให้เห็นภาพชัด ๆ ดังนี้

ระดับเทสต์	ครอบคลุมอะไร	ความเร็ว	สัดส่วนที่แนะนำ	ตัวอย่างในโปรเจคจริง
Unit Test	ฟังก์ชันหรือคลาสเดี่ยว ไม่ต้องต่อฐานข้อมูล	เร็วมาก ไม่กี่มิลลิวินาที	60-70%	ฟังก์ชันคำนวณดอกเบี้ย ตัดสต็อก แปลงเวลา
Feature Test	เรียกผ่านเส้นทาง HTTP จริง รวมตัวกลางต่าง ๆ	ปานกลาง	20-30%	ยืนยันว่าเส้นทางดึงยอดขายคืนสถานะ 200
Integration Test	เชื่อมฐานข้อมูล บริการภายนอก ระบบคิว	ช้ากว่า	5-10%	ทดสอบเชื่อมต่อเกตเวย์ชำระเงินแบบทดสอบ

เหตุผลที่ต้องมีหลายชั้นเพราะแต่ละชั้นจับปัญหาคนละแบบครับ เทสต์ระดับ Unit จับบั๊กตรรกะได้เร็วที่สุดและระบุจุดผิดได้แม่นที่สุด เทสต์ระดับ Feature จับปัญหาการเชื่อมต่อระหว่างส่วนประกอบ เช่นตัวกลางตรวจสิทธิ์บล็อกคำขอที่ควรผ่าน หรือข้อมูลที่ส่งกลับมาไม่ตรงรูปแบบที่หน้าเว็บคาดหวัง ส่วนเทสต์ระดับ Integration จับปัญหาที่สองระบบคุยกันไม่รู้เรื่อง เช่นเกตเวย์ชำระเงินเปลี่ยนรูปแบบคำตอบแล้วระบบเรายังแปลคำตอบเก่าอยู่

ใน Pest ส่วนที่ต่างกันแค่โฟลเดอร์และวิธีเขียนเท่านั้น เทสต์ระดับ Unit ใส่ไว้ใน tests/Unit จะรันโดยไม่บูตระบบเต็ม เทสต์ระดับ Feature ใส่ไว้ใน tests/Feature สำหรับโปรเจคลาราเวลจะมีเครื่องมือช่วยอย่าง refreshDatabase และ factory ที่สร้างข้อมูลปลอมได้เร็ว เช่น

it('สร้างรายการสั่งซื้อสำเร็จ', function () { $ผู้ใช้ = User::factory()->create(); $ผล = $this->actingAs($ผู้ใช้) ->post('/api/orders', ['item_id' => 5, 'qty' => 2]);

$ผล->assertStatus(201) ->assertJsonPath('data.qty', 2); $this->assertDatabaseHas('orders', ['item_id' => 5]); });

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

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

คำถามที่พบบ่อย

PHP Pest Testing Automation Script คืออะไร และต่างจาก PHPUnit อย่างไร?

PHP Pest Testing Automation Script คือการเขียนสคริปต์ทดสอบอัตโนมัติด้วยเฟรมเวิร์ก Pest บนภาษา PHP โดย Pest พัฒนาต่อยอดมาจาก PHPUnit และดึงเอาความเรียบง่ายของเครื่องมืออย่าง Jest ในโลกจาวาสคริปต์มาใช้ จุดเด่นที่สำคัญที่สุดคือรูปแบบการเขียนแบบ "expectation" ที่อ่านแล้วเหมือนภาษาอังกฤษธรรมดา นักพัฒนาไม่ต้องเขียน class และ method ยาว ๆ แบบสมัย PHPUnit เก่า ๆ อีกต่อไป แค่ใช้คำสั่ง it() และ expect() ก็สามารถเขียนเทสต์ได้จบในตัว ทำให้โค้ดทดสอบสั้นลง อ่านง่ายขึ้น และผู้ที่เข้ามาต่อทีมใหม่ก็เข้าใจได้เร็ว ในบริบทปี 2026 ที่ระบบซอฟต์แวร์ซับซ้อนขึ้นมาก ทั้งเว็บแอปพลิเคชัน ระบบซื้อขายอัตโนมัติ และแอปที่เชื่อมต่อกับโปรแกรมซื้อขายหุ้น การมีเทสต์อัตโนมัติที่ดีถือเป็นโครงสร้างพื้นฐานจำเป็น ไม่ใช่ของฟุ่มเฟือยอีกต่อไปครับ

หลักการสำคัญของการทำสคริปต์ทดสอบอัตโนมัติมีอะไรบ้าง?

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

ใครบ้างที่ควรใช้สคริปต์ทดสอบอัตโนมัติของ Pest และควรเริ่มใช้ตอนไหน?

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

การเขียนเทสต์อัตโนมัติให้ประโยชน์ที่จับต้องได้จริงอะไรบ้าง?

ประโยชน์ที่จับต้องไ

แนะนำเพิ่มเติม

🎯 เปิดบัญชี XM Forex → สมัคร

📱 แอป iCafeFX → ดาวน์โหลด

📊 สัญญาณฟรี → รับสัญญาณ

📚 คู่มือเทรด → SiamCafeBook

🤝 สมัคร Partner XM → pipaffiliates.com/c?c=72816&l=th&p=6