เครื่องมือทดสอบ LoadRunner – ส่วนประกอบ & Archiเทคเจอร์

LoadRunner คืออะไร?

โหลดรันเนอร์ เป็นเครื่องมือทดสอบประสิทธิภาพที่บุกเบิกโดย Mercury ในปี 1999 LoadRunner ถูกซื้อโดย HPE ในภายหลังในปี 2006 ในปี 2016 LoadRunner ถูกซื้อโดย MicroFocus

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

วิดีโอ LoadRunner

ทำไมต้องโหลดรันเนอร์?

โหลดรันเนอร์ ไม่เพียงแต่เป็นเครื่องมือบุกเบิกในการทดสอบประสิทธิภาพเท่านั้น แต่ยังเป็นผู้นำตลาดในกระบวนทัศน์การทดสอบประสิทธิภาพอีกด้วย ในการประเมินล่าสุด LoadRunner มีส่วนแบ่งตลาดประมาณ 85% ในอุตสาหกรรมการทดสอบประสิทธิภาพ

โดยทั่วไปแล้ว เครื่องมือ LoadRunner รองรับ RIA (Rich Internet Applications), Web 2.0 (HTTP/HTML, Ajax, Flex และ Silverlight ฯลฯ), มือถือ, SAP, Oracle, นางสาว SQL เซิร์ฟเวอร์, Citrix, RTE, Mail และเหนือสิ่งอื่นใด, Windows เบ้า. ไม่มีเครื่องมือของคู่แข่งในตลาดที่สามารถนำเสนอโปรโตคอลที่หลากหลายเช่นนี้รวมอยู่ในเครื่องมือเดียว

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

ซอฟต์แวร์ LoadRunner ได้รับการบูรณาการอย่างแนบแน่นกับเครื่องมือ HP อื่นๆ เช่น Unified Functional Test (QTP) และ ALM (Application Lifecycle Management) โดยช่วยให้คุณสามารถดำเนินกระบวนการทดสอบตั้งแต่ต้นจนจบ

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

ทำไมคุณต้องมีการทดสอบประสิทธิภาพ?

ประมาณ สูญเสียรายได้ 4.4 พันล้านบาท จะถูกบันทึกเป็นประจำทุกปีเนื่องจากประสิทธิภาพของเว็บไม่ดี

ในยุค Web 2.0 ในปัจจุบัน ผู้ใช้จะคลิกออกไปหากเว็บไซต์ไม่ตอบสนองภายใน 8 วินาที ลองนึกภาพว่าคุณต้องรอ 5 วินาทีเมื่อค้นหา Google หรือส่งคำขอเป็นเพื่อนบน Facebook ผลที่ตามมาจากการหยุดให้บริการมักเลวร้ายยิ่งกว่าที่เคยจินตนาการไว้ ตัวอย่างเช่น กรณีที่เพิ่งเกิดขึ้นกับ Bank of America Online Banking Amazon บริการเว็บ, Intuit หรือ Blackberry

ตามข้อมูลของ Dunn & Bradstreet บริษัทในกลุ่ม Fortune 59 จำนวน 500% ประสบปัญหาระบบหยุดทำงานประมาณ 1.6 ชั่วโมงต่อสัปดาห์ หากพิจารณาว่าบริษัทในกลุ่ม Fortune 500 ที่มีพนักงานอย่างน้อย 10,000 คน จ่ายเงิน 56 ดอลลาร์ต่อชั่วโมง ค่าใช้จ่ายด้านแรงงานสำหรับระบบหยุดทำงานขององค์กรดังกล่าวจะอยู่ที่ 896,000 ดอลลาร์ต่อสัปดาห์ ซึ่งคิดเป็นเงินมากกว่า 46 ล้านดอลลาร์ต่อปี

การหยุดทำงานของ Google.com เพียง 5 นาที (19 ส.ค. 13) คาดว่าจะทำให้ยักษ์ใหญ่ด้านการค้นหาต้องเสียค่าใช้จ่ายสูงถึง 545,000 ดอลลาร์

มีการประมาณการว่าบริษัทต่างๆ สูญเสียยอดขายมูลค่า 1100 ดอลลาร์ต่อวินาทีอันเนื่องมาจากเหตุการณ์ล่าสุด Amazon บริการเว็บหยุดทำงาน

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

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

LoadRunner คืออะไร Archiเทคเจอร์?

โดยทั่วไป สถาปัตยกรรมของ HP LoadRunner มีความซับซ้อน แต่เข้าใจได้ง่าย

สมมติว่าคุณได้รับมอบหมายให้ตรวจสอบประสิทธิภาพของ Amazon.com สำหรับผู้ใช้ 5000 คน

ในสถานการณ์จริง ผู้ใช้ 5000 รายนี้จะไม่ได้อยู่ที่หน้าแรกแต่จะอยู่ในส่วนอื่นของเว็บไซต์ เราจะจำลองต่างกันได้อย่างไร

วูเจน

VUGen หรือผู้ใช้เสมือน Generator เป็น IDE (Integrated Development Environment) หรือโปรแกรมแก้ไขการเขียนโค้ดที่หลากหลาย VUGen ใช้เพื่อจำลองพฤติกรรม System Under Load (SUL) VUGen นำเสนอคุณสมบัติ "การบันทึก" ซึ่งจะบันทึกการสื่อสารไปยังและจากไคลเอนต์และเซิร์ฟเวอร์ในรูปแบบของสคริปต์ที่เข้ารหัส - หรือที่เรียกว่าสคริปต์ VUser

เมื่อพิจารณาจากตัวอย่างข้างต้น VUGen สามารถบันทึกเพื่อจำลองกระบวนการทางธุรกิจต่อไปนี้:

1. ท่องหน้าผลิตภัณฑ์ของ Amazonด้วย.
2. Checkout
3. การประมวลผลการชำระเงิน
4. กำลังตรวจสอบหน้า MyAccount

ตัวควบคุม

เมื่อสคริปต์ VUser ได้รับการสรุปแล้ว คอนโทรลเลอร์จะเป็นหนึ่งในองค์ประกอบหลักของ LoadRunner ซึ่งควบคุมการจำลองโหลดโดยการจัดการ เช่น:

• จำนวน VUsers ที่จะจำลองเทียบกับแต่ละกระบวนการทางธุรกิจหรือกลุ่ม VUser
• พฤติกรรมของ VUser (เพิ่มขึ้น, ลดลง, พร้อมกันหรือพร้อมกัน ฯลฯ)
• ลักษณะของสถานการณ์โหลด เช่น ชีวิตจริงหรือมุ่งเน้นเป้าหมาย หรือการตรวจสอบ SLA
• ควรใช้หัวฉีดตัวไหน จำนวน VUsers ต่อหัวฉีดแต่ละตัว
• เรียงผลเป็นระยะ
• การปลอมแปลง IP
• การรายงานข้อผิดพลาด
• การรายงานธุรกรรม ฯลฯ

หากใช้การเปรียบเทียบจากตัวควบคุมตัวอย่างของเรา จะเพิ่มพารามิเตอร์ต่อไปนี้ลงในสคริปต์ VUGen

1) มีผู้ใช้งาน 3500 ราย ท่องหน้าผลิตภัณฑ์ของ Amazonด้วย.

2) มีผู้ใช้งาน 750 ราย Checkout

3) มีผู้ใช้งาน 500 ราย ดำเนินการประมวลผลการชำระเงิน

4) มีผู้ใช้งาน 250 ราย ตรวจสอบหน้า MyAccount หลังจากผู้ใช้ 500 รายเสร็จสิ้นการประมวลผลการชำระเงินแล้วเท่านั้น

สถานการณ์ที่ซับซ้อนยิ่งขึ้นก็เป็นไปได้

1. เริ่มต้น 5 VUsers ทุกๆ 2 วินาทีจนกระทั่งโหลดได้ 3500 VUsers (surfing Amazon หน้าผลิตภัณฑ์) ได้แล้ว
2. ทำซ้ำเป็นเวลา 30 นาที
3. ระงับการวนซ้ำสำหรับ 25 VUsers
4. รีสตาร์ท 20 VUSers
5. เริ่มต้นผู้ใช้ 2 คน (ในการชำระเงิน การประมวลผลการชำระเงิน หน้าบัญชีของฉัน) ทุกวินาที
6. 2500 VUsers จะถูกสร้างขึ้นที่เครื่อง A
7. 2500 VUsers จะถูกสร้างขึ้นที่ Machine B

เครื่องจักรตัวแทน/โหลด Generators/หัวฉีด

HP LoadRunner Controller มีหน้าที่จำลอง VUser นับพัน โดย VUser เหล่านี้ใช้ทรัพยากรฮาร์ดแวร์ เช่น โปรเซสเซอร์และหน่วยความจำ ดังนั้นจึงเป็นการจำกัดจำนวนเครื่องที่กำลังจำลอง นอกจากนี้ คอนโทรลเลอร์ยังจำลอง VUsers เหล่านี้จากเครื่องเดียวกัน (ซึ่งมีคอนโทรลเลอร์อยู่) และผลลัพธ์อาจไม่แม่นยำ เพื่อจัดการกับข้อกังวลนี้ VUsers ทั้งหมดจะกระจายไปตามเครื่องต่างๆ ที่เรียกว่า โหลด Generators หรือโหลดหัวฉีด

ตามแนวทางปฏิบัติทั่วไป คอนโทรลเลอร์จะอยู่บนเครื่องอื่นและมีการจำลองโหลดจากเครื่องอื่น ขึ้นอยู่กับโปรโตคอลของสคริปต์ VUser และข้อมูลจำเพาะของเครื่อง อาจจำเป็นต้องใช้ Load Injector จำนวนหนึ่งสำหรับการจำลองแบบเต็มรูปแบบ ตัวอย่างเช่น VUsers สำหรับสคริปต์ HTTP จะต้องใช้ 2-4MB ต่อ VUser สำหรับการจำลอง ดังนั้น เครื่อง 4 เครื่องที่มี RAM 4 GB แต่ละเครื่องจะต้องจำลองโหลด 10,000 VUsers

นำการเปรียบเทียบจากเรา Amazon ตัวอย่าง ผลลัพธ์ของส่วนประกอบนี้จะเป็น

การวิเคราะห์

เมื่อดำเนินการสถานการณ์โหลดแล้ว บทบาทของ "การวิเคราะห์” ส่วนประกอบของ LoadRunner เข้ามา

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

ข้อผิดพลาดและข้อยกเว้นทั้งหมดจะถูกบันทึกไว้ใน Microsoft เข้าถึงฐานข้อมูลชื่อ output.mdb องค์ประกอบ “การวิเคราะห์” อ่านไฟล์ฐานข้อมูลนี้เพื่อทำการวิเคราะห์ประเภทต่างๆ และสร้างกราฟ

กราฟเหล่านี้แสดงแนวโน้มต่างๆ เพื่อทำความเข้าใจสาเหตุของข้อผิดพลาดและความล้มเหลวภายใต้ภาระงาน จึงช่วยพิจารณาว่าจำเป็นต้องมีการปรับให้เหมาะสมใน SUL, Server (เช่น JBoss, Oracle) หรือโครงสร้างพื้นฐาน

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

วิธีทำการทดสอบประสิทธิภาพ

แผนงานการทดสอบประสิทธิภาพสามารถแบ่งกว้างๆ ได้เป็น 5 ขั้นตอน:

• การวางแผนสำหรับการทดสอบโหลด
• สร้างสคริปต์ VUGen
• การสร้างสถานการณ์
• การดำเนินการตามสถานการณ์
• การวิเคราะห์ผลลัพธ์ (ตามด้วยการปรับแต่งระบบ)

เมื่อคุณได้ติดตั้ง LoadRunner แล้ว เรามาทำความเข้าใจขั้นตอนที่เกี่ยวข้องในกระบวนการทีละขั้นตอนกันดีกว่า

ขั้นตอนที่เกี่ยวข้องกับกระบวนการทดสอบประสิทธิภาพ

ขั้นตอนที่ 1) การวางแผนสำหรับการทดสอบโหลด

การวางแผนการทดสอบประสิทธิภาพแตกต่างจากการวางแผนก SIT (การทดสอบการรวมระบบ) or UAT (การทดสอบการยอมรับของผู้ใช้)- การวางแผนสามารถแบ่งออกเป็นขั้นตอนย่อยๆ ได้ดังนี้

รวบรวมทีมของคุณ

เมื่อเริ่มต้นการทดสอบ LoadRunner วิธีที่ดีที่สุดคือบันทึกว่าใครจะมีส่วนร่วมในกิจกรรมจากแต่ละทีมที่เกี่ยวข้องในระหว่างกระบวนการ

ผู้จัดการโครงการ:

เสนอชื่อผู้จัดการโครงการที่จะเป็นเจ้าของกิจกรรมนี้และทำหน้าที่เป็นผู้ชี้ประเด็นในการยกระดับปัญหา

ผู้เชี่ยวชาญด้านสายงาน/ นักวิเคราะห์ธุรกิจ:

ให้การวิเคราะห์การใช้งานของ SUL และให้ความเชี่ยวชาญในการทำงานทางธุรกิจของเว็บไซต์/SUL

ผู้เชี่ยวชาญด้านการทดสอบประสิทธิภาพ:

สร้างการทดสอบประสิทธิภาพอัตโนมัติและดำเนินการสถานการณ์โหลด

System Archiเทค:

จัดทำพิมพ์เขียวของ SUL

นักพัฒนาเว็บและ SME:

• ดูแลรักษาเว็บไซต์และให้ด้านการตรวจสอบ
• พัฒนาเว็บไซต์และแก้ไขข้อบกพร่อง

ผู้ดูแลระบบ:

• รักษาเซิร์ฟเวอร์ที่เกี่ยวข้องตลอดโครงการทดสอบ

แอปพลิเคชันโครงร่างและกระบวนการทางธุรกิจที่เกี่ยวข้อง:

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

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

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

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

ข้อเท็จจริง 2 ประการข้างต้นรวมกันทำให้เราทราบจำนวนผู้ใช้ทั้งหมดที่เราต้องทดสอบระบบเพื่อประสิทธิภาพ

กำหนดขั้นตอนการจัดการข้อมูลการทดสอบ

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

• ผู้ใช้ 'A' สร้างสัญญาทางการเงินและส่งเพื่อรับการตรวจสอบ
• ผู้ใช้รายอื่น 'B' อนุมัติสัญญา 200 ฉบับต่อวันที่สร้างโดยผู้ใช้ 'A'
• ผู้ใช้รายอื่น 'C' จ่ายประมาณ 150 สัญญาต่อวันซึ่งได้รับการอนุมัติโดยผู้ใช้ 'B'

ในสถานการณ์นี้ ผู้ใช้ B จำเป็นต้องมี 'สร้าง' สัญญา 200 สัญญาในระบบ นอกจากนี้ ผู้ใช้ C ต้องการสัญญา 150 สัญญาเมื่อ "อนุมัติ" เพื่อจำลองการโหลดผู้ใช้ 150 ราย

ซึ่งหมายความว่าคุณต้องสร้างสัญญาอย่างน้อย 200+150= 350 สัญญา

หลังจากนั้น อนุมัติสัญญา 150 สัญญาเพื่อใช้เป็นข้อมูลทดสอบสำหรับผู้ใช้ C - สัญญาที่เหลืออีก 200 สัญญาจะทำหน้าที่เป็นข้อมูลทดสอบสำหรับผู้ใช้ B

จอภาพโครงร่าง

คาดเดาแต่ละปัจจัยที่อาจส่งผลต่อประสิทธิภาพของระบบ ตัวอย่างเช่น การลดฮาร์ดแวร์ลงอาจส่งผลต่อประสิทธิภาพของ SUL (System Under Load)

รวบรวมปัจจัยทั้งหมดและตั้งค่าจอภาพเพื่อให้คุณสามารถวัดได้ นี่เป็นตัวอย่างบางส่วน:

• ตัวประมวลผล (สำหรับเว็บเซิร์ฟเวอร์ แอปพลิเคชันเซิร์ฟเวอร์ เซิร์ฟเวอร์ฐานข้อมูล และหัวฉีด)
• RAM (สำหรับเว็บเซิร์ฟเวอร์, เซิร์ฟเวอร์แอปพลิเคชัน, เซิร์ฟเวอร์ฐานข้อมูล และหัวฉีด)
• เซิร์ฟเวอร์เว็บ/แอป (เช่น IIS, JBoss, Jaguar Server, Tomcat ฯลฯ)
• DB Server (ขนาด PGA และ SGA ในกรณีของ Oracle และเซิร์ฟเวอร์ MSSQL, SP เป็นต้น)
• การใช้แบนด์วิธเครือข่าย
• NIC ภายในและภายนอกในกรณีที่มีการคลัสเตอร์
• Load Balancer (และกระจายโหลดอย่างเท่าเทียมกันบนโหนดทั้งหมดของคลัสเตอร์)
• ฟลักซ์ข้อมูล (คำนวณจำนวนข้อมูลที่ย้ายเข้าและออกจากไคลเอนต์และเซิร์ฟเวอร์ จากนั้นคำนวณว่าความจุของ NIC เพียงพอที่จะจำลองผู้ใช้ X จำนวนหรือไม่)

ขั้นตอนที่ 2) สร้างสคริปต์ VUGen

ขั้นตอนต่อไปหลังจากการวางแผนคือการสร้าง สคริปต์ VUser

ขั้นตอนที่ 3) การสร้างสถานการณ์

ขั้นตอนต่อไปคือการสร้างสถานการณ์การโหลดของคุณ

ขั้นตอนที่ 4) การดำเนินการตามสถานการณ์

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

คุณสามารถกำหนดระดับการโหลดได้โดยการเพิ่มและลดจำนวน VUsers ที่ทำงานพร้อมกัน

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

ขั้นตอนที่ 5) การวิเคราะห์ผลลัพธ์ (ตามด้วยการปรับแต่งระบบ)

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

กราฟบางส่วนที่ได้รับได้แก่:

• เวลาถึงบัฟเฟอร์แรก
• เวลาตอบสนองธุรกรรม
• เวลาตอบสนองธุรกรรมโดยเฉลี่ย
• จำนวนการเข้าชมต่อวินาที
• Windows แหล่งข้อมูล
• สถิติข้อผิดพลาด
• สรุปธุรกรรม

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