แนวทางปฏิบัติที่ดีที่สุดในการทดสอบ

การพัฒนาการดำเนินการสำหรับแพลตฟอร์ม Actions on Google มักเกี่ยวข้องกับการใช้ Dialogflow สำหรับการทำความเข้าใจภาษาที่เป็นธรรมชาติ (NLU) และการตอบสนองของ Dialogflow ซึ่งจะจัดการตรรกะสำหรับการดำเนินการของคุณ การทดสอบในฐานของโค้ดจะช่วยให้การดำเนินการของคุณทำงานได้อย่างที่คาดไว้ในเวอร์ชันที่ใช้งานจริง

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

โฟลว์ชาร์ตจะดำเนินการต่อจากคำค้นหาของผู้ใช้ไปยัง Actions on Google, Dialogflow และเว็บฮุค Fulfillment และกลับไปยังผู้ใช้ในที่สุด

รูปที่ 1 โฟลว์ชาร์ตอธิบายระบบที่ต้องพิจารณาทำการทดสอบ

การทดสอบ Agent ของ Dialogflow

มีการทดสอบ Agent และ Fulfillment ของ Dialogflow เป็นคอมโพเนนต์แยกกัน ส่วนย่อยต่อไปนี้อธิบายวิธีสร้างแนวคิดและทดสอบ Agent ของ Dialogflow สำหรับการดำเนินการของคุณ

Dialogflow เป็นระบบค้นหาขาเข้าและ Intent ออก

Agent ของ Dialogflow จะทำหน้าที่รับคำค้นหาของผู้ใช้ จับคู่กับ Intent และแยกเอนทิตีที่กำหนดไว้ล่วงหน้าออกจากการค้นหา Agent จะโต้ตอบกับ Fulfillment ของคุณโดยส่งข้อความที่มี Intent ที่ตรงกัน พารามิเตอร์ของ Fulfillment และข้อมูลเมตาของ Actions on Google

ในฐานะนักพัฒนาซอฟต์แวร์ คุณสามารถควบคุมการกำหนดค่า Agent ของ Dialogflow ได้ เช่น โครงสร้างของ Intent และเอนทิตี ข้อมูลเมตาของ Actions on Google มาจาก Actions on Google และถือว่ามีข้อมูลที่ถูกต้องสำหรับการทดสอบ

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

Agent ของ Dialogflow สามารถแสดงด้วยการค้นหาข้อความเป็นอินพุตได้ และจะแสดงพารามิเตอร์ Intent ที่ดึงมาเป็นเอาต์พุต

รูปที่ 2 การนำเสนอ Dialogflow ว่าเป็นระบบค้นหาขาเข้าและ Intent ออก

การทดสอบ 1 หน่วย

สำหรับ Agent ของ Dialogflow คุณจะเขียนการทดสอบเมื่อแต่ละกรณีคาดหวังให้การค้นหาข้อความเป็นอินพุตและสร้างข้อมูลเมตาของ Intent เป็นเอาต์พุตได้ ข้อมูลเมตานี้ควรมีชื่อของ Intent ที่ตรงกันและรายการพารามิเตอร์ที่ตรงกัน (เป็นอย่างต่ำ)

ปลายทาง detectIntent ของ Dialogflow API จะใช้การค้นหาข้อความเป็นอินพุตและสร้างเอาต์พุตที่มีโครงสร้างซึ่งมีชื่อของ Intent ที่แก้ไขแล้วและพารามิเตอร์ที่ดึงข้อมูล ผลลัพธ์นี้มีประโยชน์ในการประเมินประสิทธิภาพการจับคู่ Intent ของ Agent ดูข้อมูลอ้างอิงทั้งหมดของช่องที่เป็นประโยชน์อื่นๆ ได้ที่ข้อมูลอ้างอิง QueryResult

การทดสอบตัวอย่างจะมีลักษณะดังนี้

it('choose_fact', async function() {
  // The `dialogflow` variable is an abstraction around the API that creates
  // and sends payloads to Dialogflow.
  const resJson = await dialogflow.detectIntent(
    'Tell me about the history of Google');
  expect(resJson.queryResult).to.include.deep.keys('parameters');
  // Check that Dialogflow extracted required entities from the query.
  expect(resJson.queryResult.parameters).to.deep.equal({
    'category': 'history',
    // Put any other parameters you wish were extracted
  });
  expect(resJson.queryResult.intent.displayName).to.equal('choose_fact');
});

ข้อมูลโค้ดนี้ใช้ Mocha และ Chai ดูตัวอย่างที่สมบูรณ์ของการทดสอบหน่วย Dialogflow ที่เขียนขึ้นใน Node.js สำหรับข้อเท็จจริงเกี่ยวกับ Google

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

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

การทดสอบการผสานรวม

ปลายทาง detectIntent ของ Dialogflow API จะทริกเกอร์ Fulfillment ของบุคคลที่สามด้วย ด้วยเหตุนี้ จึงมีโอกาสเขียนกรอบการทดสอบที่ครอบคลุมการผสานรวมระหว่าง Agent ของ Dialogflow กับ Fulfillment ของ Dialogflow ได้

ความแตกต่างที่สำคัญระหว่างการผสานรวมการเขียนและการทดสอบหน่วยสำหรับ Dialogflow คือ ในการทดสอบการผสานรวม คุณสามารถยืนยันการตอบกลับที่มาจากเว็บฮุคได้ รวมถึงความตั้งใจและการแยกเอนทิตีของ Dialogflow

ดูตัวอย่างที่ใช้งานได้ทั้งหมดของการทดสอบการผสานรวมที่เขียนขึ้นใน Node.js ในที่เก็บข้อเท็จจริงเกี่ยวกับ Google

การทดสอบเว็บฮุค Fulfillment ของ Dialogflow

มีการทดสอบ Agent ของ Dialogflow และ Dialogflow ของ Dialogflow โดยเป็นคอมโพเนนต์แยกกัน ส่วนย่อยต่อไปนี้อธิบายวิธีสร้างแนวคิดและทดสอบ Fulfillment สำหรับการดำเนินการของคุณ

Fulfillment เป็นระบบ JSON-in และ JSON-out

โค้ด Fulfillment ของ Dialogflow ต่างก็ต้องการคำขอและสร้างการตอบกลับในรูปแบบ JSON ด้วยเหตุนี้ คุณทดสอบโค้ด Fulfillment ได้โดยมองว่าเป็นระบบ JSON-in และ JSON-out คำขอมีข้อมูลเมตาทั้งจาก Dialogflow และ Actions on Google จึงมีข้อมูลทุกอย่างที่จำเป็นต่อการทริกเกอร์ตัวแฮนเดิล Intent ที่เฉพาะเจาะจงใน Fulfillment ของคุณ

หากต้องการทดสอบทริกเกอร์ตัวแฮนเดิล Intent ให้ส่งคำขอ JSON (อินพุต) ไปยังการดำเนินการของคุณ คำขอนี้จะส่งไปยังการดำเนินการตามคำสั่งซื้อซึ่งเข้าถึงได้บนอินเทอร์เน็ต จากนั้น Fulfillment จะสร้างการตอบสนอง JSON (เอาต์พุต) ซึ่งประเมินเพื่อตรวจสอบได้

Fulfillment อาจแสดงด้วยอินพุตคำขอ JSON และเอาต์พุตการตอบกลับ JSON ของเว็บฮุคได้

รูปที่ 3 การนำเสนอ Fulfillment เป็นระบบ JSON-in และ JSON-out

การทดสอบ 1 หน่วย

ให้ลองคิดว่าโค้ดเว็บฮุค Fulfillment เป็นระบบที่ยอมรับอินพุต JSON และสร้างเอาต์พุต JSON จากนั้นกระบวนการทดสอบการดำเนินการก็จะง่ายขึ้นในการส่งคำขอไปยัง Fulfillment และตรวจสอบ JSON ของเอาต์พุตที่ได้

ซึ่งให้อิสระแก่คุณในการโฮสต์ Fulfillment ภายในเครื่องและส่งคำขอ HTTP ภายในเครื่องเพื่อทำการทดสอบ หากใช้ไลบรารีไคลเอ็นต์ Actions on Google Node.js คุณจะส่งคำขอ JSON ไปยังเลเยอร์มิดเดิลแวร์ไลบรารีไคลเอ็นต์ได้โดยตรงด้วย

หากคุณทดสอบโค้ดเว็บฮุคด้วยอินพุต JSON และได้รับเอาต์พุต JSON ที่คาดหวังแล้ว คุณสามารถพูดได้อย่างสมเหตุสมผลว่าส่วนที่คุณควบคุมทำงานได้อย่างถูกต้อง คุณสามารถสันนิษฐานได้ว่า Dialogflow และ Actions on Google ทำงานอย่างถูกต้อง เพราะสร้างเพย์โหลด JSON ที่ถูกต้อง การแยกส่วนนี้จะทำให้โมเดลการเขียนโปรแกรมแบบง่ายๆ สำหรับการทดสอบการเขียน

ภาพรวมทั่วไปของกระบวนการทดสอบมีดังนี้

  1. ใช้เครื่องจำลองในคอนโซล Actions เพื่อรับคำขอ JSON สำหรับแต่ละขั้นตอนใน Use Case บันทึกรายการเหล่านี้เป็นไฟล์ JSON หรือคุณจะสร้างคำขอเหล่านั้นด้วยตนเองโดยใช้ข้อมูลจากเอกสารอ้างอิงของเว็บฮุคก็ได้
  2. เขียนการทดสอบเพื่อเรียกใช้เว็บฮุคด้วยเพย์โหลดเหล่านี้
  3. สำหรับการทดสอบแต่ละครั้ง ให้ตรวจสอบว่า JSON ของการตอบกลับมีรายการที่คาดไว้

นอกจากนี้ โมเดลนี้ยังช่วยให้คุณทดสอบ Fulfillment ของ Dialogflow ในการตั้งค่าการผสานรวมอย่างต่อเนื่องได้ เนื่องจากปลายทาง Fulfillment แบบต่อเนื่องสามารถทำงานได้ในเครื่อง และ Dialogflow API มีแนวคิดของเซสชันในตัว

ตัวอย่างการทดสอบจะมีลักษณะดังนี้

it('yes-history', function() {
  expect(jsonRes.payload).to.have.deep.keys('google');
  expect(jsonRes.payload.google.expectUserResponse).to.be.true;
  expect(jsonRes.payload.google.richResponse.items).to.have.lengthOf(3);
  expect(jsonRes.payload.google.richResponse.suggestions).to.have
    .deep.members([
      {'title': 'Sure'}, {'title': 'No thanks'},
    ]);
});

ข้อมูลโค้ดด้านบนใช้ Mocha และ Chai ดูตัวอย่างการทำงานแบบเต็มซึ่งเขียนไว้ใน Node.js ในที่เก็บข้อเท็จจริงเกี่ยวกับ Google

การออกแบบ Fulfillment ที่ทดสอบหน่วยได้

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

ในการปรับปรุงรายละเอียดของการทดสอบ 1 หน่วยสำหรับโค้ด Fulfillment แนวทางปฏิบัติที่ดีคือการจัดระเบียบโค้ดให้แยกตรรกะทางธุรกิจออกจากกิจวัตรการจัดการ Intent ซึ่งหมายความว่าคุณจะต้องมีตัวแฮนเดิล Intent และตรรกะทางธุรกิจอยู่ในโมดูลแยกกัน เพื่อให้ทดสอบแต่ละส่วนได้อย่างอิสระ

ตัวอย่างเช่น โปรดดูการดำเนินการตัวอย่าง Shiritori ใน GitHub ในตัวอย่างนี้ functions/index.js และ functions/shiritori/*.js จะมีตัวแฮนเดิล Intent และตรรกะทางธุรกิจแยกกัน ซึ่งช่วยให้ชุดทดสอบมีประสิทธิภาพมากขึ้น

การทดสอบการผสานรวม

สำหรับการเขียนกรอบการทดสอบที่ครอบคลุมการผสานรวมระหว่าง Dialogflow กับโค้ดเว็บฮุคสำหรับการดำเนินการ โปรดอ่านส่วนการทดสอบการผสานรวมสำหรับ Dialogflow ด้านบน

การทดสอบการโหลด

ก่อนจะนำการดำเนินการของคุณไปใช้กับเวอร์ชันที่ใช้งานจริง เราขอแนะนำให้โหลดการทดสอบ Fulfillment เว็บฮุคด้วย เพื่อแสดงปัญหาด้านประสิทธิภาพที่ส่งผลให้บริการ Fulfillment ลดลงหรือหยุดชะงัก

ตัวอย่างบางส่วนของปัญหาด้านประสิทธิภาพที่คุณอาจพบในการทดสอบโหลดมีดังนี้

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

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

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

สำหรับสถานการณ์เหล่านี้ คุณจะบันทึกคำขอที่ส่งโดย Actions on Google ไปยังเว็บฮุคจากบันทึกเว็บฮุคหรือบันทึก Stackdriver ได้ คุณยังรับคำขอจากเครื่องจำลองคอนโซล Actions ได้ด้วย

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

การทดสอบการเพิ่มขึ้น

การทดสอบการเพิ่มขึ้นอย่างรวดเร็วกำหนดให้คุณส่งคำขอตามจำนวนคงที่ไปยังเว็บฮุคเป็นระยะเวลาหนึ่ง แล้วทำให้โหลดเพิ่มขึ้นอย่างกะทันหัน เช่น คุณอาจตั้งค่าการทดสอบที่ส่งโหลดของคำค้นหา 10 รายการต่อวินาที (QPS) โดยมีการเพิ่มขึ้นเล็กน้อยที่ 60 QPS

คุณสามารถเรียกใช้คำสั่ง ApacheBench ต่อไปนี้เพื่อส่งคำขอพร้อมกัน 60 รายการไปยังเว็บฮุคของคุณ

ab -n 60 -c 60 -p ActionRequest.json -T 'application/json' https://example.com/webhookFunctionName

สมมติว่าไฟล์ ActionRequest.json มีเพย์โหลดคำขอที่บันทึกไว้ซึ่งส่งไปยังเว็บฮุค

การทดสอบการแช่น้ำ

การทดสอบการแช่แข็งกำหนดให้คุณต้องส่งคำขอตามจำนวนคงที่ไปยังเว็บฮุคและสังเกตการตอบสนอง ตัวอย่างเช่น คุณอาจตั้งค่าการทดสอบที่ส่งโหลดคงที่ 10-20 QPS เป็นเวลาหลายนาทีเพื่อดูว่าเวลาในการตอบสนองเพิ่มขึ้นหรือไม่

คุณสามารถเรียกใช้คำสั่ง ApacheBench ต่อไปนี้เพื่อส่งคำขอ 1, 200 รายการ โดยให้มีคำขอ 10 รายการพร้อมกันทุกวินาที

ab -t 120 -n 1200 -p ActionRequest.json -T 'application/json' https://example.com/webhookFunctionName

สมมติว่าไฟล์ ActionRequest.json มีเพย์โหลดคำขอที่บันทึกไว้ซึ่งส่งไปยังเว็บฮุค

กำลังวิเคราะห์ผลการทดสอบภาระงาน

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

การทดสอบแบบต้นทางถึงปลายทาง

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