แนวทางปฏิบัติแนะนำในการทดสอบ (Dialogflow)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ปลายทาง detectIntent ของ Dialogflow API จะนำการค้นหาข้อความเป็นอินพุตและสร้างเอาต์พุตที่มีโครงสร้างซึ่งมี ชื่อของ Intent ที่แก้ไขแล้วและพารามิเตอร์ที่ดึงข้อมูล เอาต์พุตนี้มีประโยชน์ สำหรับการประเมินประสิทธิภาพการจับคู่ Intent ของตัวแทน เพื่อการเรียนรู้ที่สมบูรณ์ ข้อมูลอ้างอิงของช่องอื่นๆ ที่มีประโยชน์ โปรดดูข้อมูลอ้างอิง 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 1 หน่วยที่เขียนใน Node.js สำหรับ ข้อเท็จจริงเกี่ยวกับ Google

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

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

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

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

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

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

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

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

การดำเนินการตามคำสั่งซื้อเป็นระบบ JSON-in และ JSON-out

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

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

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

รูปที่ 3 การแสดง Fulfillment ในรูปแบบระบบ JSON-in และ JSON-out

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

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

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

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

ข้อมูลคร่าวๆ ของขั้นตอนการทดสอบมีดังนี้

  1. ใช้เครื่องมือจำลองในคอนโซล Actions เพื่อรับคำขอ JSON สำหรับ แต่ละขั้นตอนในกรณีการใช้งาน บันทึกไฟล์เหล่านี้เป็นไฟล์ 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 ที่เก็บได้

การออกแบบการดำเนินการตามหน่วยที่ทดสอบได้

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

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

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

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

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

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

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

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

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

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

ระบุสถานการณ์ที่ระบบเรียกเว็บฮุคและผลการตรวจสอบ การดำเนินการที่ใช้ทรัพยากรจำนวนมาก การดำเนินการที่ใช้ทรัพยากรจำนวนมากโดยทั่วไปมีดังนี้ การค้นหาฐานข้อมูล การเรียก 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 ต่อไปนี้เพื่อส่งคำขอ 1200 ด้วยค่า 10 คำขอพร้อมกันทุกวินาที:

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

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

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

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

การทดสอบแบบเอนด์ทูเอนด์

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