Ứng dụng phần mềm webload trong kiểm tra hiệu năng website

Việc kiểm tra hiệu suất phần mềm cần được thực hiện liên tục ngay mỗi khi một modun nào đó được hoàn thành để nếu phát hiện thấy hiệu suất không đảm bảo thì có biện pháp điều chỉnh hợp l

TRƯỜNG ĐẠI HỌC VINH KHOA CÔNG NGHỆ THÔNG TIN

Sinh viên thực hiện : Nguyễn Thị Uyên

Vinh, 5/2009

LỜI CẢM ƠN

Trước hết em xin cảm ơn các Thầy, Cô giáo khoa CNTT-

trường Đại học Vinh đã truyền thụ cho em các kiến thức quý báu trong 4 năm học

Em xin chân thành cảm ơn cô giáo TS.Phan Lê Na là người

trực tiếp hướng dẫn khóa luận Trong suốt thời gian thực hiện đề tài, Cô luôn giúp đỡ và hướng dẫn tận tình để em hoàn thành đề tài

Qua đây em cũng xin chân thành cảm ơn các bạn trong lớp 46A - khoa CNTT đã giúp đỡ và đóng góp ý kiến trong quá trình thực hiện đề tài

Và cuối cùng em muốn gửi lời cảm ơn sâu sắc nhất tới những người thân yêu trong gia đình em Con xin cảm ơn bố mẹ, anh chị và người chồng yêu quý đã luôn động viên, giúp đỡ em trong suốt thời gian qua để em hoàn thành được khóa luận tốt nghiệp

Vinh, 10 tháng 5 năm 2009

Sinh viên thực hiện Nguyễn Thị Uyên

LỜI MỞ ĐẦU

Hiện nay trên thế giới cùng với sự phát triển rất nhanh chóng trong lĩnh vực khoa học và công nghệ thì ngành Công nghệ thông tin ở Việt Nam cũng đang từng bước phát triển mạnh mẽ và có nhiều thành tựu nổi bật, trong đó phải kể đến xu hướng phát triển của ngành kiểm

định phần mềm (software testing) ở Việt Nam đã góp phần thúc đẩy sự

phát triển chung của ngành sản xuất phầm mềm trên thế giới Software testing đã phát triển từ lâu trên thế giới nhưng ở Việt Nam chưa được chú trọng và đầu tư phát triển Tuy nhiên hiện nay, công việc kiểm định phần mềm đang có xu hướng chuyển về các quốc gia đang phát triển, trong đó có Việt Nam Hiện nay các doanh nghiệp phần mềm trong nước

đã và đang thực hiện thành công nhiều dự án gia công và kiểm định phần mềm với các đối tác nước ngoài như Nhật Bản, Mỹ vv Chính vì thế bất

kỳ một sản phẩm nào, trước khi đưa đến tay người dùng đều cần phải trải qua một quá trình kiểm thử để đảm bảo chất lượng và sự ổn định của sản phẩm Một sản phẩm phần mềm cũng không ngoại lệ Một phần mềm trước khi đưa ra sử dụng thì cũng cần phải trải qua quá trình kiểm thử - gọi là kiểm tra hiệu năng phần mềm (Performance Test – PT) Hiệu suất hoạt động của phần mềm sẽ ảnh hưởng rất lớn đến tốc độ và hiệu suất của toàn bộ hệ thống Việc kiểm tra hiệu suất phần mềm cần được thực hiện liên tục ngay mỗi khi một modun nào đó được hoàn thành để nếu phát hiện thấy hiệu suất không đảm bảo thì có biện pháp điều chỉnh hợp

lý Ngoài ra, các kết quả từ các hoạt động kiểm tra và phân tích có thể giúp cho việc đưa ra cấu hình phần cứng cần thiết để triển khai ứng dụng

Trong việc lĩnh vực công nghệ phần mềm, việc kiểm tra hiệu năng phần mềm là hoạt động thử nghiệm nhằm đánh giá tốc độ thực thi của

ứng dụng và nó cũng có thể phục vụ cho việc kiểm tra các thuộc tính của

hệ thống, chẳng hạn như quy mô, độ tin cậy và mức độ sử dụng tài nguyên Kiểm tra hiệu năng có thể phục vụ cho những mục đích khác nhau Nó có thể chứng minh rằng hệ thống đáp ứng được các tiêu chí hiệu suất nào đó Nó có thể dùng để so sánh hai hệ thống để tìm ra hệ thống nào thực hiện tốt hơn khi cùng được cài đặt cùng một ứng dụng

Trong quá trình kiểm thử hiệu năng phần mềm, các nhà phát triển phần mềm phải thiết kế được các kịch bản cho việc kiểm thử và sử dụng các phần mềm tự động kiểm tra hiệu năng chuyên dụng như: LoadRunner, WebLoad, Open SATA vv để thực hiện các kịch bản đó

Từ kết quả thực hiện các kịch bản đó, nhà phát triển ứng dụng sẽ có được những đánh giá cơ bản về sản phẩm phần mềm mà họ đang xây dựng

Giai đoạn kiểm thử phần mềm là một giai đoạn đòi hỏi tốn thời gian, công sức và kinh nghiệm Chính vì thế việc kiểm tra phần mềm nói chung và kiểm tra hiệu năng nói riêng chưa thật sự thông dụng và phổ biến đối với các công ty phát triển phần mềm ở nước ta Công việc này đang gặp những khó khăn về kinh nghiệm và trình độ Test của các nhà kiểm tra phần mềm Hiện nay ở Việt Nam chưa có một đội ngũ chuyên nghiệp về lĩnh vực Test phần mềm mà việc Test phần mềm đang được xem là một khâu nhỏ quá trình xây dựng phần mềm

Một vấn đề tương đối khó khăn đối với những người bắt đầu với công việc kiểm tra phần mềm là không có nhiều người biết về nghề này, nên khó có thể học hỏi từ những người đi trước Một người kiểm tra phần mềm không chỉ đơn giản là kiểm tra sản phẩm có đạt chất lượng hay không mà cần phải đứng ở góc độ của người sử dụng cuối để tìm hiểu các chức năng và kiểm tra hiệu năng của sản phẩm Người kiểm tra phần mềm không chỉ hiểu biết và nắm vững kỹ thuật kiểm tra mà cần

phải cập nhật kiến thức mới để áp dụng vào quy trình kiểm tra ngày một tốt hơn và hiệu quả hơn

Qua những tìm hiểu về việc kiểm tra hiệu năng phần mềm, chúng

ta có thể thấy được tầm quan trọng và vai trò của công việc này trong quy trình phát triển phần mềm, nhất là đối với những phần mềm ứng dụng lớn, có nhiều người sử dụng cùng một thời điểm như những ứng dụng Website, phần mềm quản lý tài chính, ngân hàng vv Chính vì thế,

chúng tôi đã chọn đề tài: “Ứng dụng phần mềm WebLOAD trong kiểm tra hiệu năng WebSite”

Mục đích chính của đề tài:

 Tìm hiểu về quy trình kiểm tra hiệu năng phần mềm

 Tìm hiểu về cách sử dụng phần mềm mã nguồn mở WebLOAD

 Xây dựng kịch bản kiểm tra hiệu năng cho Website đăng ký học tín chỉ của trường Đại học Vinh

Đề tài bao gồm các nội dung sau:

 Lời mở đầu

 Chương I: Quy trình kiểm tra hiệu năng phần mềm

 Chương II: Sử dụng phần mềm WebLOAD

 Chương III: Ứng dụng phần mềm WebLOAD trong kiểm tra hiệu

năng Website

 Kết luận

Trong khuôn khổ một khóa luận tốt nghiệp, chúng tôi chỉ tìm hiểu một cách tổng quan về kiểm tra hiệu năng phần mềm, các bước trong quy trình kiểm tra hiệu năng phần mềm và giới thiệu phần mềm WebLOAD để thực thi các kịch bản trong quá trình kiểm thử hiệu năng phần mềm Cụ thể là kiểm tra hiệu năng của WebSite đăng ký học tín chỉ

của trường Đại học Vinh Tuy nhiên với kiến thức còn hạn chế của bản thân và không có nhiều tài liệu tiếng Việt về lĩnh vực này (hầu hết các tài liệu đều ở dạng tiếng Anh) nên đề tài chưa nghiên cứu được hết các khía cạnh trong qui trình kiểm tra hiệu năng phần mềm Chúng tôi hy vọng sẽ nhận được những ý kiến đóng góp quý báu từ phía các thầy cô và bạn bè

để khóa luận được hoàn thiện hơn Hy vọng Performance Test sẽ phát triển mạnh trong tương lai ở Việt Nam, góp phần mang lại cho nền công nghệ phần mềm nước nhà những sản phẩm phần mềm đạt tiêu chuẩn và đáp ứng được nhu cầu ứng dụng công nghệ thông tin vào cuộc sống

CHƯƠNG I QUY TRÌNH KIỂM TRA HIỆU NĂNG PHẦN MỀM

1.1 Tổng quan

Kiểm tra hiệu năng phần mềm (Performmance Test-PT) là một dạng kiểm tra tự động, để tìm ra điểm chưa hoàn thiện của phần mềm cần kiểm tra, qua đó giúp cho người làm phần mềm có sự thay đổi thích hợp để tăng khả năng thực thi của phần mềm Bên cạnh đó cũng giúp người kiểm tra biết được những thông số ngưỡng của phần mềm, để đưa

ra các tiêu chuẩn cho những lần kiểm tra sau

Khi thực hiện Performmance Test, người kiểm tra phải đề ra kết

quả mong đợi một cách rõ ràng Ví dụ: đối với ứng dụng website, chúng

ta cần biết thông số quan trọng là: số lượng kết nối (session) đồng thời

mà server có thể phục vụ, thời gian mà trình duyệt nhận được kết quả từ server (response time)

Khi thực hiện Performmance Test người ta thường chọn thời điểm

mà chương trình tương đối ổn định Thông thường chức năng nằm trong tình huống cần kiểm tra hiệu năng đã được đảm bảo tính đúng đắn Điều này sẽ giúp cho việc phân tích đánh giá kết quả của Performmance Test

dễ dàng và đúng đắn

Thực hiện kiểm thử của phần mềm sẽ cho phép:

 Dự đoán trước hoặc đánh giá trước những đặc trưng của một ứng dụng, đánh giá ứng dụng đó có thực hiện được hay không thực hiện đựợc Những dự đoán này có ý nghĩa rất quan trọng tới người phát triển ứng dụng, họ sẽ quyết định xem ứng dụng đó có phát triển được trong

tương lai hay không, yêu cầu phần cứng để phát triển ứng dụng đó là như thế nào

 Cung cấp dữ liệu nhằm giúp dự đoán trước những rủi ro của hệ thống khi không đáp ứng được những yêu cầu của người dùng

 Đánh giá được khả năng của ứng dụng tại thời điểm thử nghiệm Xác định được hiệu năng có thể chấp nhận được của ứng dụng:

Để đảm bảo phần mềm có chất lượng thì người kiểm tra viên phải

có những kịch bản giả lập gần giống với môi trường thực tế nhất Trong thực tế có rất nhiều phần mềm theo mô hình client-server đáp ứng nhiều người dùng cùng một lúc Một số yêu cầu thực tế rất hay đặt ra là:

 Xác định thời gian đáp ứng khi có nhiều người dùng như: số yêu cầu trên giây, số giao dịch thành công trên giây, số gói tin trên giây

 Xác định biểu đồ tài nguyên chiếm giữ của phần mềm khi có nhiều người dùng trong thời gian dài như: CPU, bộ nhớ, thông tin dữ liệu vào/ra của đĩa cứng, thông tin dữ liệu vào/ra của mạng

 Xác định khả năng phân tải, khả năng phục hồi dữ liệu khi có sự

cố vì quá nhiều người dùng cùng một lúc

 Đề ra cấu hình phần cứng tối thiểu để phần mềm có thể hoạt động

 Kiểm tra việc thực hiện giao dịch có bị sai lệch khi có nhiều người cùng sử dụng một chức năng của phần mềm

Ví dụ: Có ứng dụng web, yêu cầu cần tìm thông số về hiệu năng

thực thi của ứng dụng

Dùng phần mềm kiểm tra hiệu năng tạo tình huống khởi đầu có 10 người dùng, cứ 2 phút tăng thêm 10 người, tăng tối đa là 2000 người Quan sát: Biểu đồ thời gian đáp ứng với kết quả xử lý đúng và kết quả sai, có bao nhiêu yêu cầu không được xử lý, tài nguyên sử dụng như

RAM, CPU, Thông qua đó giúp xác định ứng dụng hoạt động tốt nhất trong điều kiện nào

Thông thường, việc kiểm tra các chức năng trên thường được thực hiện một cách tự động thông qua các phần mềm chuyên dùng cho công việc này Nhưng một điều quan trọng là: các nhà kiểm thử phần mềm phải xây dựng được các kịch bản và các kết quả phản hồi theo mong muốn Nếu kết quả phản hồi không như mong muốn thì phần mềm cần được xem xét lại Việc kiểm tra tự động là một phương pháp được dùng phổ biến hiện nay đối với các công ty phát triển phần mềm chuyên nghiệp trên thế giới

1.2 Các mức độ trong kiểm tra phần mềm

Kiểm tra phần mềm là công việc mà bất cứ người nào từng tham gia phát triển phần mềm đều biết và từng làm Theo nghĩa thông thường nhất, kiểm tra phần mềm bao gồm việc "chạy thử" phần mềm hay một chức năng của phần mềm, xem nó "chạy" đúng như mong muốn hay không Việc kiểm tra này có thể thực hiện từng chặng, sau mỗi chức năng hoặc module được phát triển, hoặc thực hiện sau cùng, khi phần mềm đã được phát triển hoàn tất

Thực tế, kiểm tra phần mềm không đơn giản như nhiều người thường nghĩ công việc này có nhiều mức độ khác nhau và có mối tương quan với các chặng phát triển trong dự án phát triển phần mềm Kiểm tra phần mềm nói chung có 4 mức độ sau đây:

1.2.1 Kiểm tra mức đơn vị (Unit Test)

Một đơn vị phần mềm (Unit) là thành phần nhỏ nhất mà ta có thể kiểm tra được Nó có thể là: các hàm (Function), thủ tục (Procedure), lớp (Class), hoặc các phương thức (Method) đều có thể được xem là Unit

Unit Test thường do lập trình viên thực hiện Công đoạn này cần được thực hiện càng sớm càng tốt trong giai đoạn viết code và xuyên suốt chu kỳ phát triển phần mềm Thông thường, Unit Test đòi hỏi kiểm tra viên có kiến thức về thiết kế và code của chương trình Mục đích của Unit Test là bảo đảm thông tin được xử lý và xuất ra là chính xác, trong mối tương quan với dữ liệu nhập và chức năng của Unit Điều này thường đòi hỏi tất cả các nhánh bên trong Unit đều phải được kiểm tra để phát hiện nhánh phát sinh lỗi Unit Test cũng đòi hỏi phải chuẩn bị trước các tình huống (test case) hoặc kịch bản (script), trong đó xác định rõ dữ liệu vào, các bước thực hiện và dữ liệu mong chờ sẽ xuất ra Các test case và script này nên được giữ lại để tái sử dụng

Hình 1.1 Các mức độ cơ bản của kiểm tra phần mềm

Kiểm tra mức tích hợp các

đơn vị (Integration Test)

Kiểm tra mức đơn vị lập trình

(Unit Test)

Kiểm tra mức hệ thống sau khi tích hợp(System Test)

Kiểm tra để chấp nhận sản phầm (Acceptance Test)

Các bộ phận đơn lẻ

Các nhóm bộ phận

Toàn bộ hệ thống

Toàn bộ hệ thống nhìn từ khách hàng

1.2.2 Kiểm tra tích hợp (Integration Test)

Integration test kết hợp các thành phần của một ứng dụng và kiểm tra như một ứng dụng đã hoàn thành Trong khi Unit Test kiểm tra các thành phần và Unit riêng lẻ thì Intgration Test kết hợp chúng lại với nhau

và kiểm tra sự giao tiếp giữa chúng

Integration Test có 2 mục tiêu chính:

 Phát hiện lỗi giao tiếp xảy ra giữa các Unit

 Tích hợp các Unit đơn lẻ thành các hệ thống nhỏ (subsystem) và cuối cùng là hệ thống hoàn chỉnh (system) chuẩn bị cho kiểm tra ở mức

hệ thống (System Test)

Trong Unit Test, lập trình viên cố gắng phát hiện lỗi liên quan đến chức năng và cấu trúc nội tại của Unit Có một số phép kiểm tra đơn giản trên giao tiếp giữa Unit với các thành phần liên quan khác, tuy nhiên mọi giao tiếp liên quan đến Unit thật sự được kiểm tra đầy đủ khi các Unit

tích hợp với nhau trong khi thực hiện Integration Test

Integration Test chỉ nên thực hiện trên những Unit đã được kiểm tra cẩn thận trước đó bằng Unit Test, và tất cả các lỗi mức Unit đã được

sửa chữa trong một số tình huống

Một chiến lược cần quan tâm trong Integration Test là nên tích hợp dần từng Unit Một Unit tại một thời điểm được tích hợp vào một nhóm các Unit khác đã tích hợp trước đó và đã hoàn tất các đợt Integration Test trước đó Lúc này, ta chỉ cần kiểm tra giao tiếp của Unit mới thêm vào với hệ thống các Unit đã tích hợp trước đó, điều này làm

cho số lượng kiểm tra sẽ giảm đi rất nhiều, sai sót sẽ giảm đáng kể

Có 4 loại kiểm tra trong Integration Test:

 Kiểm tra cấu trúc (structure): Tương tự White Box Test (kiểm tra nhằm bảo đảm các thành phần bên trong của một chương trình chạy đúng), chú trọng đến hoạt động của các thành phần cấu trúc nội tại của chương trình chẳng hạn các lệnh và nhánh bên trong

 Kiểm tra chức năng (functional): Tương tự Black Box Test (kiểm tra chỉ chú trọng đến chức năng của chương trình, không quan tâm đến cấu trúc bên trong), chỉ khảo sát chức năng của chương trình theo yêu cầu kỹ thuật

 Kiểm tra hiệu năng (performance): Kiểm tra việc vận hành của hệ thống

 Kiểm tra khả năng chịu tải (stress): Kiểm tra các giới hạn của hệ thống

1.2.3 Kiểm tra mức hệ thống (System Test)

Mục đích System Test là kiểm tra thiết kế và toàn bộ hệ thống (sau khi tích hợp) có thỏa mãn yêu cầu đặt ra hay không System Test bắt đầu khi tất cả các bộ phận của phần mềm đã được tích hợp thành công Thông thường loại kiểm tra này tốn rất nhiều công sức và thời gian Trong nhiều trường hợp, việc kiểm tra đòi hỏi một số thiết bị phụ trợ, phần mềm hoặc phần cứng đặc thù, đặc biệt là các ứng dụng thời gian thực, hệ thống phân bố, hoặc hệ thống nhúng Ở mức độ hệ thống, người kiểm tra cũng tìm kiếm các lỗi, nhưng trọng tâm là đánh giá về hoạt động, thao tác, sự tin cậy và các yêu cầu khác liên quan đến chất lượng của toàn hệ thống

Điểm khác nhau then chốt giữa Integration Test và System Test là System Test chú trọng các hành vi và lỗi trên toàn hệ thống, còn Integration Test chú trọng sự giao tiếp giữa các đơn thể hoặc đối tượng

khi chúng làm việc cùng nhau Thông thường ta phải thực hiện Unit Test

và Integration Test để bảo đảm mọi Unit và sự tương tác giữa chúng hoạt động chính xác trước khi thực hiện System Test

Sau khi hoàn thành Integration Test, một hệ thống phần mềm đã được hình thành cùng với các thành phần đã được kiểm tra đầy đủ Tại thời điểm này, lập trình viên hoặc kiểm tra viên (tester) bắt đầu kiểm tra phần mềm như một hệ thống hoàn chỉnh Việc lập kế hoạch cho System Test nên bắt đầu từ giai đoạn hình thành và phân tích các yêu cầu

System Test kiểm tra cả các hành vi chức năng của phần mềm lẫn các yêu cầu về chất lượng như độ tin cậy, tính tiện lợi khi sử dụng, hiệu năng và bảo mật Mức kiểm tra này đặc biệt thích hợp cho việc phát hiện lỗi giao tiếp với phần mềm hoặc phần cứng bên ngoài, chẳng hạn các lỗi

"tắc nghẽn" hoặc chiếm dụng bộ nhớ Sau giai đoạn System Test, phần mềm thường đã sẵn sàng cho khách hàng hoặc người dùng cuối cùng kiểm tra để chấp nhận (Acceptance Test) hoặc dùng thử (Alpha/Beta Test)

Đòi hỏi nhiều công sức, thời gian và tính chính xác, khách quan, System Test thường được thực hiện bởi một nhóm kiểm tra viên hoàn toàn độc lập với nhóm phát triển dự án Bản thân System Test lại gồm nhiều loại kiểm tra khác nhau bao gồm:

 Kiểm tra chức năng (Functional Test): bảo đảm các hành vi của hệ thống thỏa mãn đúng yêu cầu thiết kế

 Kiểm tra khả năng vận hành (Performance Test): bảo đảm tối ưu việc phân bổ tài nguyên hệ thống (ví dụ bộ nhớ) nhằm đạt các chỉ tiêu như thời gian xử lý hay đáp ứng câu truy vấn

 Kiểm tra khả năng chịu tải (Stress Test hay Load Test): bảo đảm

hệ thống vận hành đúng dưới áp lực cao (ví dụ nhiều người truy xuất

cùng lúc) Stress Test tập trung vào các trạng thái tới hạn, các "điểm chết", các tình huống bất thường

 Kiểm tra cấu hình (Configuration Test)

 Kiểm tra khả năng bảo mật (Security Test): bảo đảm tính toàn vẹn, bảo mật của dữ liệu và của hệ thống

 Kiểm tra khả năng phục hồi (Recovery Test): bảo đảm hệ thống có khả năng khôi phục trạng thái ổn định trước đó trong tình huống mất tài nguyên hoặc dữ liệu; đặc biệt quan trọng đối với các hệ thống giao dịch như ngân hàng trực tuyến

1.2.4 Kiểm tra chấp nhận sản phẩm (Acceptance Test)

Thông thường, sau giai đoạn System Test là Acceptance Test, được khách hàng thực hiện (hoặc ủy quyền cho một nhóm thứ ba thực hiện) Mục đích của Acceptance Test là để chứng minh phần mềm thỏa mãn tất cả yêu cầu của khách hàng và khách hàng chấp nhận sản phẩm (và trả tiền thanh toán hợp đồng) Acceptance Test có ý nghĩa hết sức quan trọng, mặc dù trong hầu hết mọi trường hợp, các phép kiểm tra của System Test và Accepatnce Test gần như tương tự, nhưng bản chất và cách thức thực hiện lại rất khác biệt

Đối với những sản phẩm bán rộng rãi trên thị trường dành cho nhiều người sử dụng, thông thường sẽ thông qua hai loại kiểm tra gọi là Alpha Test và Beta Test Với Alpha Test, người sử dụng kiểm tra phần mềm ngay tại nơi phát triển phần mềm, lập trình viên sẽ ghi nhận các lỗi hoặc phản hồi, và lên kế hoạch sửa chữa Với Beta Test, phần mềm sẽ được gửi tới cho người sử dụng để kiểm tra ngay trong môi trường thực, lỗi hoặc phản hồi cũng sẽ gửi ngược lại cho lập trình viên để sửa chữa

Thực tế cho thấy, nếu khách hàng không quan tâm và không tham gia vào quá trình phát triển phần mềm thì kết quả Acceptance Test sẽ sai

lệch rất lớn, mặc dù phần mềm đã trải qua tất cả các kiểm tra trước đó

Sự sai lệch này liên quan đến việc hiểu sai yêu cầu cũng như sự mong

chờ của khách hàng Ví dụ: đôi khi một phần mềm xuất sắc vượt qua các

phép kiểm tra về chức năng thực hiện bởi nhóm thực hiện dự án, nhưng khách hàng khi kiểm tra sau cùng vẫn thất vọng vì bố cục màn hình nghèo nàn, thao tác không tự nhiên, không theo tập quán sử dụng của khách hàng v.v

Gắn liền với giai đoạn Acceptance Test thường là một nhóm những dịch vụ và tài liệu đi kèm, phổ biến như hướng dẫn cài đặt, sử dụng v.v Tất cả tài liệu đi kèm phải được cập nhật và kiểm tra chặt chẽ

1.3 Các kiểu kiểm tra hiệu năng phần mềm

Kiểm tra hiệu năng phần mềm là một trong những dạng của phần kiểm tra tích hợp (Integration Test) Thông thường, kiểm tra hiệu năng phần mềm có 2 kiểu: Load Test, Stress Test

1.3.1 Load Test

Load Test đôi khi còn gọi là Volume Test Dùng công cụ kiểm tra

tự động để kiểm tra phần mềm ở điều kiện liên tục tăng mức độ chịu tải

Ở mức độ chịu tải nào đó, thông qua phần mềm kiểm tra hiệu năng sẽ cho phép:

 Giám sát việc phần mềm quản lý tài nguyên khi chạy trong thời gian dài

 Giám sát thông số đề ra trong Performance Test như thời gian xử

lý, số yêu cầu đến máy chủ, khi chạy trong thời gian dài

Ví dụ: Ứng dụng web chỉ hoạt động tốt với tối đa là 1000 người

dùng Yêu cầu kiểm tra khả năng của web khi hoạt động ở ngưỡng đáp ứng với thời gian dài 2 ngày

1.3.2 Stress Test

Đây là cách thực hiện nhằm làm cho phần mềm không còn chạy được nữa Phương pháp này rất hay áp dụng để kiểm tra phần mềm và phần cứng Kiểm tra khả năng phục hồi của phần mềm sau khi có sự cố Kiểm tra khả năng chịu tải cho một máy khác khi máy đó gặp sự cố do không có khả năng chịu tải được nữa

Ví dụ: Ứng dụng web chỉ có thể quản lý, đáp ứng tối đa 1000 yêu

cầu Yêu cầu cần kiểm tra ứng xử của web khi gặp sự cố quá ngưỡng số người sử dụng

Dùng phần mềm kiểm tra hiệu năng tạo tình huống có 1100 người truy cập, khi đạt đến ngưỡng đó phần mềm ngừng tải Quan sát: Kết quả

xử lý 1000 yêu cầu đầu, 100 yêu cầu sau đó bị từ chối ra sao, webserver

có khả năng bị khởi động lại hay không, Từ đó giúp đưa ra kết luận ứng dụng sẽ ứng xử như thế nào khi đạt hoặc vượt ngưỡng chịu tải tối đa

1.4 Các bước trong quy trình kiểm tra hiệu năng

Trước khi tìm hiểu một quy trình kiểm tra phần mềm cơ bản, thì

cần hiểu hai khái niệm sau: Test Case và Test Script

 Test Case: Một Test Case là một tình huống kiểm tra, được thiết

kế để kiểm tra một đối tượng có thỏa mãn yêu cầu đặt ra hay không Một Test Case thường bao gồm 3 phần cơ bản:

 Mô tả: đặc tả các điều kiện cần có để tiến hành kiểm tra

 Nhập: đặc tả đối tượng hay dữ liệu cần thiết, được sử dụng làm đầu vào để thực hiện việc kiểm tra

 Kết quả mong chờ: kết quả trả về từ đối tượng kiểm tra, chứng

tỏ đối tượng đạt yêu cầu

 Test Script: Một Test Script là một nhóm mã lệnh dạng đặc tả kịch bản dùng để tự động hóa một trình tự kiểm tra, giúp cho việc kiểm tra nhanh hơn, hoặc cho những trường hợp mà kiểm tra bằng tay sẽ rất khó khăn hoặc không khả thi Các Test Script có thể tạo thủ công hoặc tạo tự động dùng công cụ kiểm tra tự động

Quy trình kiểm tra hiệu năng phần mềm nói chung có 7 bước:

Hình 1.2 Các hoạt động chính trong kiểm tra hiệu năng

1.4.1 Xác định môi trường kiểm thử (Indentify Test Environment)

Ở bước này, kiểm tra viên cần làm các công việc sau:

 Xác định được các chức năng chính của phần mềm cần kiểm thử, qua đó xây dựng các tiêu chuẩn đầu ra khi áp dụng các kịch bản khác nhau

 Xác định các thao tác chính của người dùng để từ đó cho chạy thử nghiệm phần mềm khi các thao tác đó được thực hiện

 Xác định kiến trúc vật lý và kiến trúc logic của hệ thống

1 Xác định môi trường kiểm thử

2 Xác định tiêu chuẩn kiểm thử

3 Lập kế hoạch và thiết kế kiểm thử

4 Cấu hình môi trường kiểm thử

5 Xây dựng kịch bản kiểm thử

6 Thực thi kịch bản kiểm thử

7 Phân tích, đánh giá báo cáo và kiểm tra lại

1.4.2 Xác định tiêu chuẩn kiểm thử (Indentify Performance Acceptance Criteria)

Ở bước này, kiểm tra viên cần làm các công việc sau:

 Xác định các tiêu chuẩn đầu ra thỏa mãn yêu cầu của việc kiểm tra, ví dụ như: thời gian phản hồi, mức độ chiếm dụng tài nguyên hệ thống, ngưỡng chịu tải của hệ thống vv

 Ước lượng được chi phí cần thiết cho việc triển khai hệ thống

1.4.3 Lập kế hoạch và thiết kế kiểm thử (Plan and Design Tests)

Mục đích: Nhằm chỉ định và mô tả các loại kiểm tra sẽ được triển khai và thực hiện Kết quả của bước lập kế hoạch là bản tài liệu kế hoạch kiểm tra phần mềm, bao gồm nhiều chi tiết từ các loại kiểm tra, chiến lược kiểm tra, cho đến thời gian và phân định lực lượng kiểm tra viên

Các bước lập kế hoạch:

 Xác định yêu cầu kiểm tra: chỉ định bộ phận, thành phần của phần mềm (PM) sẽ được kiểm tra, phạm vi hoặc giới hạn của việc kiểm tra Yêu cầu kiểm tra cũng được dùng để xác định nhu cầu nhân lực

 Khảo sát rủi ro: Các rủi ro có khả năng xảy ra làm chậm hoặc cản

trở quá trình cũng như chất lượng kiểm tra.Ví dụ: kỹ năng và kinh

nghiệm của kiểm tra viên chưa tốt, không hiểu rõ yêu cầu

 Xác định chiến lược kiểm tra: chỉ định phương pháp tiếp cận để thực hiện việc kiểm tra trên PM, chỉ định các kỹ thuật và công cụ hỗ trợ kiểm tra, chỉ định các phương pháp dùng để đánh giá chất lượng kiểm tra cũng như điều kiện để xác định thời gian kiểm tra

 Xác định nhân lực, vật lực: kỹ năng, kinh nghiệm của kiểm tra viên; phần cứng, phần mềm, công cụ, thiết bị giả lập

 Lập kế hoạch chi tiết: ước lượng thời gian, khối lượng công việc, xác định chi tiết các phần công việc, người thực hiện, thời gian

 Xem xét các kế hoạch kiểm tra: phải có sự tham gia của tất cả những người có liên quan, kể cả trưởng dự án và có thể cả khách hàng Việc xem xét nhằm bảo đảm các kế hoạch là khả thi, cũng như để phát hiện các sai sót trong các bản kế hoạch

Các bước thiết kế:

 Xác định và mô tả Test Case: xác định các điều kiện cần thiết lập trước và trong lúc kiểm tra Mô tả đối tượng hoặc dữ liệu đầu vào, mô tả các kết quả mong chờ sau khi kiểm tra

 Mô tả các bước chi tiết để kiểm tra: các bước này mô tả chi tiết để hoàn thành một Test Case khi thực hiện kiểm tra Các Test Case như đã nói ở trên thường chỉ mô tả đầu vào, đầu ra, còn cách thức tiến hành như thế nào thì không được định nghĩa Thao tác này nhằm chi tiết hóa các bước của một Test Case, cũng như chỉ định các loại dữ liệu nào cần có

để thực thi các Test Case, chúng bao gồm các loại dữ liệu trực tiếp, gián tiếp, trung gian, hệ thống

 Xem xét và khảo sát độ bao phủ của việc kiểm tra: mô tả các chỉ

số và cách thức xác định việc kiểm tra đã hoàn thành hay chưa? bao nhiêu phần trăm PM đã được kiểm tra? Để xác định điều này có hai phương pháp: căn cứ trên yêu cầu của phần mềm hoặc căn cứ trên số lượng code đã viết

 Xem xét Test Case và các bước kiểm tra: Việc xem xét cần có sự tham gia của tất cả những người có liên quan, kể cả trưởng dự án nhằm bảo đảm các Test Case và dữ liệu yêu cầu là đủ và phản ánh đúng các yêu cầu cần kiểm tra, độ bao phủ đạt yêu cầu, cũng như để phát hiện (và sữa chữa) các sai sót

1.4.4 Cấu hình môi trường kiểm thử (Configure Test Design)

Ở bước này, kiểm tra viên cần làm các công việc sau:

 Lựa chọn phần mềm được sử dụng làm công cụ kiểm thử Việc lựa chọn này cần dựa vào cấu hình phần cứng và cấu hình phần mềm của hệ thống

 Cấu hình phần mềm để sử dụng các kịch bản đã được tạo ra ở các bước trước đó

1.4.5 Xây dựng kịch bản kiểm thử (Implement Test Design)

Ở bước này kiểm tra viên cần làm những công việc sau:

 Xây dựng các kịch bản để tạo môi trường giả lập giống trong thực

tế để kiểm thử phần mềm

 Ghi lại kịch bản, chỉnh sửa và tiến hành gỡ lỗi

1.4.6 Thực thi kịch bản kiểm thử (Execute Tests)

Tiến hành chạy thử và theo dõi quá trình kiểm thử thông qua các kịch bản đã tạo ra Quá trình này làm cho việc kiểm tra có hiệu lực hơn

vì nó kiểm tra các dữ liệu, và tập hợp các kết quả trả về để phân tích Thực hiện kiểm tra có hiệu quả trong quá trình theo dõi và phân tích ở môi trường kiểm thử

1.4.7 Phân tích, báo cáo và kiểm tra lại (Analyze, Report, and Retest)

Phân tích các dữ liệu từ các chức năng riêng rẽ và nhóm các dữ liệu đó thành một tập hợp tạo thành một hệ thống Tiến hành thực hiện lặp lại việc kiểm tra trong trường hợp nếu ứng dụng chưa đáp ứng chức năng mà người dùng yêu cầu Khi tất cả các giá trị kiểm thử được chấp nhận trong vòng giới hạn cho phép của ứng dụng và không có trường hợp nào vượt ngưỡng hay quá tải Điều đó chứng tỏ ứng dụng đã đáp

ứng được như mong muốn của người dùng Khi đó quá trình kiểm thử đã hoàn thành và người phát triển phần mềm có thể đưa ra cấu hình cụ thể dựa vào các kết quả đã kiểm tra được để phát triển và triển khai ứng dụng trong thực tế

CHƯƠNG II TÌM HIỂU PHẦN MỀM WEBLOAD

2.1 Giới thiệu phần mềm WebLOAD

WebLOAD là phần mềm mã nguồn mở cung cấp một môi trường toàn diện và mạnh mẽ để kiểm tra hiệu năng của WebSite Vì đây là một phần mềm mã nguồn mở nên mã nguồn được công bố và sử dụng một giấy phép nguồn mở Giấy phép này cho phép bất cứ ai cũng có thể nghiên cứu, thay đổi và cải tiến phần mềm, và phân phối phần mềm ở dạng chưa thay đổi hoặc đã thay đổi Giấy phép (GPL- General Public License) cho phép mọi người làm các công việc sau:

 Tự do chạy chương trình

 Tự do tìm hiểu cách hoạt động của chương trình

 Tự do cải tiến chương trình, và phát hành những gì cải tiến ra cộng đồng

WebLOAD bao gồm một số thành phần như được mô tả như sau:

Hình 2.1 Mô hình hoạt động WebLOAD

(Nguồn: www.webload.org)

Trong đó:

 Môi trường quản lý kịch bản (Script): dùng cho việc ghi lại, chỉnh sửa và gỡ lỗi các script WebLOAD sử dụng mã JavaScript trong việc tạo các kịch bản Việc sử dụng mã JavaScript cho phép người dùng hiệu chỉnh lại các đoạn mã trong kịch bản WebLOAD cung cấp môi trường cho phép người dùng lựa chọn các dạng hiện thị khác nhau: hiện thị dạng HTML, dạng trình duyệt, dạng tiêu đề thông tin

 Môi trường thực hiện kiểm tra (Excution Environment): WebLOAD cho phép tạo ra môi trường kiểm thử giống như trong thực

tế Chương trình cho phép tạo ra nhiều người dùng ảo để kiểm tra khả năng chịu tải của hệ thống WebLOAD còn cho phép đo lường thời gian phản hồi dưới những điều kiện truy cập khác nhau

 Công cụ báo cáo: Các WebLOAD sẽ cung cấp các báo cáo trực tuyến để hiển thị các số liệu thống kê được trong quá trình kiểm thử WebLOAD cũng tập hợp các số liệu thống kê này, lưu lại, sau đó cho phép người dùng tùy chỉnh để xác định các nhóm dữ liệu cần phân tích Người sử dụng có thể thêm hoặc xóa các số liệu thống kê thu được tại bất kỳ thời gian nào trong quá trình xem báo cáo Sau khi báo cáo được tạo ra WebLoad có thể xuất thành các File dưới dạng : HTML, Excel

2.3 Cài đặt WebLOAD

Không gian trống của đĩa phải có ít nhất 260 MB Tải phần mềm

WebLOAD từ địa chỉ: www.webload.org/ Khi cài đặt trên máy tính,

chương trình cài đặt sẽ cho phép chọn các thành phần để cài đặt

WebLoad có hai phần chính: WebLoad IDE và WebLoad Console WebLoad IDE được dùng để ghi lại, chỉnh sửa và gỡ lỗi các kịch bản được tạo ra dưới dạng các đoạn mã JavaScript WebLoad Console được dùng để chạy kịch bản mà đã được tạo ở phần WebLoad IDE Sử dụng WebLoad sẽ cho phép kiểm tra tải (Load testing), kiểm tra

mức độ chịu tải (Stress testing) và tạo ra các báo cáo cho quá trình kiểm

tra (Reports) Load testing kiểm tra tốc độ phản hồi của máy chủ khi có yêu cầu của máy khách Stress testing kiểm tra sự hoạt động của hệ

thống khi gửi các yêu cầu vượt quá khả năng đáp ứng của hệ thống, chẳng hạn như số lượng người dùng lớn, yêu cầu dữ liệu lớn vv

 Bao nhiêu người dùng ảo sẽ chạy trong quá trình kiểm tra

 Cần kiểm tra những chức năng nào

 Kiểu người dùng nào ta muốn giả lập: Người dùng khi dùng ứng dụng lần đầu tiên sẽ khác khi họ dùng những lần sau Thời

gian ngắt quãng giữa các thao tác sẽ khác nhau cho từng người dùng

 Thời gian phản hồi như thế nào là đạt yêu cầu

 Mức độ lỗi như thế nào là chấp nhận được

 Kiểm tra ở các tốc độ kết nối khác nhau cho từng người dùng ảo

 Xác định kiểu cần kiểm tra:

 Load Test: là kiểu kiểm tra độ chịu tải của hệ thống khi có nhiều người dùng cùng truy cập đồng thời

 Stress Test: là kiểu kiểm tra phần mềm khi cho nó chạy với mức độ chịu tải cao nhất

2.4.2 Tạo kịch bản bằng WebLoad IDE

Kịch bản là những hành động mà người dùng sẽ tương tác với WebSite cần kiểm tra Thông thường khi tạo Agenda, ta sẽ dùng WebLoad IDE để ghi lại các hành động dưới dạng các đoạn mã Javascript Sau khi tạo kịch bản, ta phải đảm bảo kịch bản sẽ hoạt động bình thường giống như khi ta thực hiện đối với trang Web cần kiểm tra

Phần mềm được thiết kế với giao diện đồ họa, trực quan để người dùng có thể sử dụng để tạo ra hoặc chỉnh sửa các kịch bản kiểm thử một cách dễ dàng Một kịch bản kiểm thử được xem như là một Project, được lưu lại và cho phép chỉnh sửa

Hình 2.2 Giao diện WebLoad IDE

Nút ghi kịch bản được sử dụng để lưu lại các hành động trong trình duyệt và ghi lại dưới dạng các đoạn mã JavaScript Sau khi nhấn nút ghi kịch bản thì trình duyệt Web sẽ được tự động mở ra cho phép ta

gõ địa chỉ của trang Web cần kiểm tra Giả sử ta sẽ kiểm tra trang

http://www.webloadmpstore.com/ Đây là trang Web mua hàng trực

tuyến Ta sẽ thực hiện một số thao tác trên trang Web nay, các thao tác này sẽ được ghi lại để dùng cho việc đánh giá sau này

Đầu tiên là thao tác Login

Hình 2.3 Trang Login Hộp thoại thông báo quá trình Login đã thành công

Hình 2.4 Giao diện đăng nhập thành công

Ở bên cửa số JavaScript xuất hiện đoạn mã ghi lại thao tác Login

Hình 2.5 Mã kịch bản cho thao tác Login

Nhấn chuột vào mục ADD TO CART để đặt mua hàng

Ta sẽ dừng ở đây và lưu lại các công việc đã thực hiện bằng cách nhấn vào nút Stop Record

Toàn bộ các hoạt động sẽ được lưu ở cửa sổ Agenda Tree

Hình 2.6 Giao diện Agenda Tree

WebLoad sẽ lưu lại toàn bộ các hành động có sự truyền dữ liệu theo giao thức HTTP Để kiểm soát từng phần của các hành động, WebLoad cho

phép tạo ra các transaction (giao dịch) Để tạo giao dịch, chọn mục Load

ở cửa sổ ToolBox

Kéo và thả biểu tượng BeginTransaction vào

hành động mà ta muốn bắt đầu quá trình kiểm tra ở cửa sổ Agenda Tree để bắt đầu một giao dịch Hiện thị hộp thoại cho phép đặt tên giao dịch

Hình 2.7 Tạo giao dịch Kéo và thả biểu tượng EndTransaction vào hành động cuối cùng trong

quá trình kiểm tra

Hình 2.8 Giao dịch đã tạo Đến đây ta ghi lại Project bằng cách chọn File/Save Như vậy ta đã tạo

được một kịch bản kiểm thử tuy nhiên kịch bản này chưa hoàn hảo, nó cần được chỉnh sửa

2.4.3 Hiệu chỉnh kịch bản

Sau khi đã khởi tạo kịch bản thì công việc tiếp theo là phải kiểm tra lại kịch bản để xử lý các đoạn mã Script bị lỗi, có thể ảnh hưởng đến kết quả kiểm thử Khi ta ghi lại kịch bản là các tệp HTML thì có một số giá trị của biến cũng được ghi lại Những biến đó có thể là SessionID, hoặc biến ẩn của Form Những giá trị của biến này sẽ khác nhau tại

những thời điểm ghi khác nhau, vì thế sẽ xẩy ra lỗi khi chạy các kịch bản Bây giờ ta sẽ sửa lỗi cho kịch bản mà ta vừa khởi tạo

Mở kịch bản đã lưu ở bước trên (Chọn File/Open) Ở cửa số Java

Script, nếu ta muốn ngắt quá trình kiểm thử ở dòng mã nào thì đưa chuột vào đầu dòng và nhấn chuột vào dòng mã đó Dòng mã đó sẽ có nền màu

đỏ cùng với một chấm tròn màu đỏ phía trước Bây giờ ta sẽ cho chạy

thử kịch bản bằng cách nhấn chuột vào biểu tượng Run Test Trước

khi WebLoad chạy kịch bản thì nó sẽ đưa ra hộp thoại xác nhận lưu lại các thay đổi trong kịch bản Cửa sổ Execution Tree sẽ hiện thị các bước thực hiện các hành động Quá trình thực hiện sẽ dừng ở điểm bị ngắt (Break Point)

Hình 2.9 Điểm ngắt

Ở ví dụ này, khi WebLoad tự động vào trang login thi sẽ xẩy ra lỗi về biến SessionId vì khi trình duyệt gửi yêu cầu dữ liệu đến máy chủ thì máy chủ sẽ tự động cấp cho trình duyệt đó một giá trị được lưu trong biến SessionID Lần khác WebLoad thực hiện thì giá trị của hai biến sẽ khác nhau nên gây ra lỗi

Hình 2.10 Lỗi đăng nhập vì SessionID không khớp

ĐỂ sửa lỗi này thì ta phải thiết lập cho biến SessionID phải có khả năng

tự động cập nhật Mở cửa sổ DOM View

Tìm đến mã có biến session, giá trị của biến này tại mỗi lần truy cập

khác nhau sẽ khác nhau Chọn Edit/Java Script Editing, thêm đoạn mã

vào cửa sổ Java Script

Session_id = document.forms[1].elements[2].value

Thay thế đoạn mã wlHttp.FormData["sessionID"] =

"webloadmpstore.123.18.140.11.d3dff78381f4d4da8e6d88c5650ab53b" bởi đoạn mã : wlHttp.FormData["sessionID"] = Session_id

Nghĩa là lúc này biến sessionID sẽ được tự động cập nhật Và lúc này sẽ không có lỗi nữa

Hình 2.11 Sau khi tạo SessionID động 2.4.4 Tạo tham số

Nếu kịch bản kiểm thử có chứa các trường mà có giá trị được nhập bởi người dùng, thì chúng ta có thể cần dùng đến một cơ sở dữ liệu để cho WebLoad có thể thực hiện kịch bản(Agenda) với các giá trị khác nhau ở mỗi lần thực hiện

Kéo và thả biểu tượng GlobalInputFile ở cửa sổ ToolBox vào cửa sổ Agenda Tree, xuất hiện cửa sổ

Hình 2.12 Tạo tham số Chọn biểu tượng Create new Data file để tạo file cơ sở dữ liệu

Hình 2.13.Tạo 3 tài khoản cho 3 lần chạy

Ở ví dụ này thì ta sẽ tạo cơ sở dữ liệu chứa 3 tài khoản Login, để WebLoad sử dụng cho quá trình tự động kiểm thử Có 2 tài khoản đúng (demo và 123) - có thể Login vào được, tài khoản abc là sai – không thể Login vào được

Chọn OK để ghi lại tệp, hiện thị hộp thoại

Chọn Yes để thiết lập file vừa tạo là Global Input File

Đánh dấu vào ô Use first row as title row để thiết lập dòng đầu tiên là

tên của tham số

Chọn biểu tượng Save and Close để ghi và đóng cửa sổ Global Input File

JavaScript với hai biến được khai báo thêm và giá trị của chúng được lấy

từ tệp Global Input File

Ở cửa sổ Agenda Tree, nhấn chuột vào hành động Login để mở dòng

mã tương ứng

Hình 2.14 Đoạn mã với tài khoản Demo

Hành động Login lúc đầu ta chạy với tài khoản là: username = demo, password = demo Bây giờ ta thay thế các giá trị cố định này bằng biến

mà ta đã khai báo ở tệp Global Input File Đoạn mã sau khi thay thế sẽ như sau:

Hình 2.15.Tạo biến động cho cho tài khoản

Vì có 3 tài khoản Login, nên ta sẽ cho kịch bản chạy 3 lần, mỗi lần sẽ sử

dụng một tài khoản khác nhau Để thay đổi số lần chạy kịch bản: chọn

Tool/Settings

Hình 2.16 Chọn số lần chạy kịch bản

Bây giờ ta sẽ cho chạy kịch bản với tham số đầu vào là 3 tài khoản Login

khác nhau Nhấn nút chạy kịch bản

Bây giờ kịch bản sẽ chạy 3 lần Kết quả sẽ được như hình sau:

Hình 2.17 Chạy với tài khoản abc

Ta có thể thấy rằng, ở lần chạy thứ hai, với tài khoản là abc thì sẽ không

Login vào được Còn với hai tài khoản khác thì quá trình Login thành

công

Hình 2.18 Chạy với 2 tài khoản Demo và 123 2.4.5 Tạo khuôn mẫu tải

Bây giờ ta sẽ dùng WebLOAD Console để tiến hành kiểm tra hiệu năng của WebSite Khi ta chạy WebLOAD Console thì sẽ kích

hoạt chương trình TestTalk, đây là chương trình quản lý các máy ảo tham gia vào quá trình Test Bước này là bước xác định các yếu tố cần kiểm tra vd: số lượng máy ảo, tốc độ xử lý, thời gian phản hồi …

Các bước của việc tạo khuôn mẫu tải sử dụng WebLOAD Wizard:

Chọn kịch bản (Agenda)

Mix Agenda Chọn máy để tạo các máy ảo

Lập lịch trình Load Machine Test

Kết thúc

Single Agenda

Sử dụng WebLoad Console để mở kịch bản và thêm các thông số

cần kiểm tra

Chạy WebLoad Console:

Hình 2.19 Tạo khuôn mẫu kiểm thử Chọn Create a new template using WebLOAD Wizard, chọn OK

Hình 2.20 Giao diện chọn Agenda để kiểm thử

Chọn Next, chọn Single Agenda để kiểm tra một kịch bản

Hình 2.21 Giao diện chọn kịch bản sau khi chọn Single Agenda

Chọn kịch bản đã lưu ở các bước trước (.wlp file) Sau đó chọn

Measuremets Manager

Hình 2.22 Giao diện thiết lập các thông số kiểm tra tải

Hình 2.23 Giao diện Measurements Manager

Chọn Add data source để thiết lập các thông số cần kiểm tra tải

như: thiết lập máy chủ, máy ảo, hệ điều hành vv

Hình 2.24 Chọn Next để tiếp tục

Trong nhóm System cũng có nhiều hệ điều hành để thiết lập như:

Windows platform, Unix/Linux UC- Davis vv

Hình 2.25 Chọn System để thiết lập hệ thống