A3

Trường ĐH Công Nghệ Thông Tin – ĐHQG TP.HCM Khoa Công Nghệ Phần Mềm

BÁO CÁO ĐỀ TÀI A3

PERFORMANCE TEST Dùng LoadRunner Test hiệu năng HP Web Tour Application

Nhóm: - Phạm Long Vân: - Bùi Quốc Vỹ: - Võ Nguyễn Đăng Hải: - Vũ Xuân Vinh: - Nguyễn Thái Hoàng:

06520561 06520586 06520142 06520575 06520181

Môn: Software Testing Giáo viên hướng dẫn ThS. Nguyễn Trần Minh Khuê Nguyễn Công Hoan

Tp Hồ Chí Minh 10/04/2009

1

MỤC LỤC I-GIỚI THIỆU PERFORMANCE TEST 1.Khái niệm 2.Mục tiêu 3.Ví dụ II-TEST HP WEB TOUR APPLICATION III -THUẬN LỢI CỦA VIỆC SỬ DỤNG TOOL PERFOMANCE TESTING IV - PREPARING TEST HP WEB TOUR APPLICATION A. Xây dựng Vuser B. Kiểm tra scripts Vuser (Playback the Scripts) C. Thiết Lập Các Transaction cho mục tiêu Test: V. PHÂN TÍCH KẾT QUẢ TEST HP WEB TOUR APPLICATION 1. Load Test Script 2. Chạy Scenario 3. Khái quát các biểu đồ cơ bản trong loadrunner 4. Định nghĩa mục tiêu 5. Phân tích Analysis Result

3

4 5 6

11

2

I – PERFORMANCE TEST LÀ GÌ 1.Khái Niệm - Được thực hiện nhằm xác định tốc độ, khả năng phân tải và mức độ tin tưởng của phần mềm(PM) trong môi trường nhiều người dùng, có nhiều hoạt động khác nhau. - Dùng công cụ kiểm tra tự động(KTTĐ) để kiểm tra hiệu năng phần mềm ở điều kiện có sự điều chỉnh về mức độ tải. - Trong kiểm chứng phần mềm, kiểm chứng hiệu năng làm kiểm tra hiệu quả hoạt động của phần mềm, khả năng, tốc độ vận hành của hệ thống. Nó cũng có thể dùng để xác minh và xác nhận chất lượng của hệ thống, chẳng hạn như quy mô, độ tin cậy, sử dụng tài nguyên của hệ thống. - Performance test có thể phục vụ nhiều mục đích khác nhau. Có thể dùng để chứng minh rằng hệ thống đáp ứng các tiêu chí hiệu suất. Nó có thể so sánh hai hệ thống để tìm ra hệ thống tốt hơn. Hoặc có thể dùng để tìm ra phần nào của hệ thống kiến hệ thống hoạt động kém.

2.Mục Tiêu - Tìm ra điểm “thắt cổ chai” của PM và từ đó có những cải tiến để tăng khả năng hoạt động của PM. - Đề ra các thông số, tiêu chuẩn về hiệu năng thực thi của PM. Một số thông số đó là: số phiên làm việc, thời gian xử lý của phiên làm việc, và các tài nguyên khác bị chiếm giữ.

3.Ví Dụ: Ví dụ 1: 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 LoadRunner 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.

3

II – TẠI SAO PHẢI SỬ DỤNG PERFORMANCE TESTING Để đảm bảo PM có chất lượng thì người kiểm tra viên (KTV) phải có những cách kiểm tra giả lập gần giống môi trường thực tế nhất. Trong thực tế có rất nhiều PM 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ố thông điệp chuyển giao 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 PM khi có nhiều người dùng trong thời gian dài như: CPU, bộ nhớ, I/O của đĩa cứng, I/O 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, ... • Đề ra cấu hình phần cứng tối thiểu để PM 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 làm giống thao tác. Với những bài toán trên việc dùng công cụ PT là không thể tránh khỏi. Đây đồng thời cũng là đặc điểm để KTV xác định xem những trường hợp nào thì phải áp dụng KTTĐ, và tiêu biểu là dùng công cụ để thực hiện PT. PT giúp chúng ta đoán trước được những lỗi có thể xảy ra khi triển khai PM vào thực tế trong môi trường có nhiều người dùng. Bên cạnh đó còn giúp tìm ra hiệu năng thực thi tối đa của PM và tìm ra nơi cần cải tiến cho PM. PT mang các đặc tính ưu việt của KTTĐ như giảm thời gian kiểm tra hồi qui, thực hiện đo lường các thông số chính xác, giúp giảm thiểu chi phí cho dự án...

4

III – THUẬN LỢI CỦA VIỆC SỬ DỤNG TOOL PERFOMANCE TESTING

Kiểm tra tự động hiệu quả là một quy tắc nhằm thúc đảy các sản phẩm ,và các tiến trình xử lý để giảm bớt những rủi ro của ứng dụng, bản nâng cấp, hoặc bản vá lỗi . Tại cốt lõi của nó, hiệu suất của hệ thống tự động kiểm tra là về việc áp dụng workloads để sản xuất trước khi triển khai hệ thống, trong khi cùng một lúc hệ thống đo lường hiệu quả và kinh nghiệm người dùng cuối. Một cấu trúc PT hiệu quả sẽ trả lời những câu hỏi sau đây:

➤ Liệu ứng dụng có response một cách nhanh chóng đáp ứng đủ cho người dùng quốc tế? ➤ Liệu việc ứng dụng có thể xử lý kỳ vọng của người sử dụng nạp vào và yêu cầu cao hơn thế ? ➤ Liệu việc ứng dụng có thể xử lý số lượng các giao dịch theo yêu cầu của các nhà kinh doanh không? ➤ Ứng dụng có ổn định theo dự kiến và trong trường hợp người sử dụng tải bất ngờ? ➤ Bạn có chắc chắn rằng người dùng sẽ có một kinh nghiệm tích cực về đi-sống ngày?

Bằng cách trả lời những câu hỏi này, công cụ PT sẽ xác định sự ảnh hưởng của một thay đổi trong điều kiện kinh doanh.Điều này sẽ làm cho rõ ràng những rủi ro của việc triển khai.Một cách hiệu quả hiệu suất của hệ thống tự động kiểm tra quá trình giúp bạn tạo ra thêm những thông tin xác thực, và ngăn chặn hệ thống downtime và các vấn đề khác.

IV - TEST HP WEB TOUR APPLICATION

5

Chúng ta sẽ đi sâu hơn về PT khi kiểm tra hiệu năng của HP Web tour ( có sẵn khi cài công cụ load runner ) bằng tool load runner 9.10 với 4 mục tiêu test sau đây: • • • •

HP tours phải bắt thành công 10 user đăng nhập vào hệ thống sever HP tours phải có thể xử lý được 10 tiến trình đăng ký chuyến bay giả lập (flying bookings ) với thời gian response không quá 90 seconds HP tours phải có thể bắt được 10 user giả lập cùng kiểm tra button itinery với thời gian response không quá 120 seconds HP tours phải bắt được 10 user đăng nhập và đăng xuất khỏi hệ thống với thời gian response không quá 10 seconds

A. Xây dựng Vuser. - Việc xây dựng script Vuse sẽ được thực hiện chủ yếu bằng cách record lại các thao tác của chúng ta và LoadRunner sẽ tự động phát sinh script Vuser - Các bước thực hiện chính như sau: 1. Khởi động chương trình LoadRunner. Vào Start > Programs > LoadRunner > LoadRunner. Mở cửa sổ HP LoadRunner 2. Mở VuGen Click vào LoadTesting tab, click Create/Edit Scripts.Trang VuGen sẽ được mở ra. Tại đây chúng ta có thể bắt đầu recode hoặt tạo ra scripts cho Vuser VD: Chúng ta sẽ xậy dựng một Vuser dựa trên HP Web Tour Application, bao gồm các bước sau.

6

- Click Record Application trong Task pane - Click vào Start Recording->xuất hiện dialog

- Trong URL Address gõ vào http://localhost:1080/WebTours, trong Record into Action chọn action - Click OK 7

- Một Web browser sẽ mở và hiển thị trang web HP Tour. Và thanh Record hiển thị

- Thực hiện các thao tác đăng ký chuyến bay và việc record đã hoàn tất

B. Kiểm tra scripts Vuser (Playback the Scripts) 1. Hiệu chỉnh các chức năng Vuser (Run-time setting) - Mở dialog run-time setting bằng cách click vào hyperlink Open Run-time settings trong task pane - Chúng ta sẽ hiệu chỉ các chức năng sau để mô phỏng Vuser giống thực hơn a. Run logic settings: Trong run logic chúng ta sẽ hiệu chỉnh interation: số lần thực hiện lặp lại b. Pacing settings: Dùng hiệu chỉnh khoảng thời gian nghĩ giửa hai phiên thực hiện c. Log settings: Ghi nhận lại log

8

d. Think time settings: Sử dụng ignore think time 2. Xem script chạy thời gian thực với LoadRunner - Thực hiện các bước sau: a. Vào Tool > General Option chọn thẻ Display. b. Chọn Show browser during replay và Auto arrange window c. Click OK d. Click Verify Replay trong task pane sau đó click Start Replay để xem script mô phỏng lại các động tác chúng ta đã làm

C. Thiết Lập Các Transaction cho mục tiêu Test: Khi chạy Replay Cript xong và không bị lỗi ta chuyển xuống mục 3 Enhancements>Transaction . Như hình sau:

9

Phía bên phải cua pane ta chọn new transaction , sau đó chọn những mục chúng ta muốn tạo thành transaction đó.Như hình trên ta đã tạo 2 transaction login_out chạy page home cho tới sign out của chương trình.Còn transaction in_out chỉ chạy từ 2 mục sign in và sign out.

10

V. PHÂN TÍCH KẾT QUẢ TEST HP WEB TOUR APPLICATION

1.

Load script : Mở loadrunner , chọn run load test , chon browser tìm script vừa tạo

Sau đó add vào script in scenario.Cuối cùng bấm ok

11

2. Chạy Scenario: Trong controller chuyển từ tab design sang tab run : (Xin lưu ý vì Scenario được chạy trên server có cấu hình như sau:

Vì vậy nếu test phần mềm trên server khác có thể có những lỗi phát sinh của server ngoài ý muốn và khác với mô tả trong báo cáo )

12

Bấm start scenario và đợi các user hoàn thành 3. KHÁI QUÁT CÁC BIỂU ĐỒ CƠ BẢN TRONG LOADRUNNER - Để phân tích kết quả testing từ LoadRunner chúng ta dựa vào các biểu đồ cơ bản sao 1. BIỂU ĐỒ RUNNING VUSER – WHOLE SCENARIO: - Dùng theo dõi số lượng Vuser đang tham gia test, chẳng hạn như biểu đồ sau chúng ta thấy có mỗi 2 Vuser tham gia test sao mỗi 1 phút

13

2. BIỂU ĐỒ TRANSACTION RESPONSE TIME – WHOLE SCENARIO - Dùng theo dõi lượng thời gian hoàn thành của mỗi transaction, Qua biểu đồ sau bạn có thể thấy được thời gian một vuser đang nhập, tìm chuyến bay, đặt vé, kiểm tra và log out khỏi hệ thống

3. BIỂU ĐỒ HIT PER SECOND – WHOLE SCENARIO - Dùng theo dõi số lượng hit (HTTP Requests) của Vuser trên web server theo mõi giây. Như thế bạn có thể dựa vào đây để biết được hoạt động của server

14

HTTP 200: Sever chạy thành công không có vấn đề. HTTP 302: Chuyển Server sang 1 địa chỉ tạm, một sự kiện bình thường , sever không có vấn đề HTTP 404: Lỗi không tìm thấy tài nguyên. HTTP 500: Server đang quá tải HTTP 503: Server không thể nào đáp ứng yêu cầu đặt ra

15

Sau khi các user ảo chạy xong sẽ như sau:

Sau đó Từ menu Result chọn Analysis Result sẽ ra cac biểu đồ tổng hợp thuận lợi cho việc phân tích các mục tiêu đặt ra ở trên.

16

4. Định nghĩa mục tiêu a Mở SLA Configuration Wizard. Chọn Tools > Configure SLA Rules. Một hộp thoại The Service Level Agreement được mở. Click New để mở the wizard.

17

chọn một kiểu mục tiêu. phía dưới check box SLA status determined at time intervals over a timeline, chọn Average Transaction Response Time. Click Next.

18

b Chọn Transaction. Trong bước này, chúng ta chọn the transactions mà bạn muốn tại danh sách transactions.Click Next.

c-Thiết lập the load criteria. Tại bước này, chúng ta instruct the SLA to take different load scenarios into account. Chọn Running Vusers từ danh sách Load Criteria và thiết lập giá trị Load Values như sau:

19

➤ Light load. Between 0 and 19 Vusers ➤ Average load. Between 20 and 49 Vusers ➤ Heavy load. More than 50 Vusers d. Set Threshold Values. In this step, you will define the acceptable Average transaction response times for these load scenarios for the book_flight and search_flight transactions. Set the threshold values to look as below:

20

You have just determined that for both selected transactions, the following average transaction response times are acceptable: ➤ Light load. 5 seconds or less ➤ Average load. 10 seconds or less ➤ Heavy load. 15 seconds or less Note: Threshold values for selected transactions do not have to be the same. You can assign different values for each transaction. e. Save the SLA. Click Next then Finish then Close on the pages that follow to save the SLA and close the wizard. Analysis then applies your SLA settings to the default Summary Report. The report is then updated to include all the relevant SLA information.

5. Phân tích Analysis Result 21

A.Mục tiêu 10 user có thể chạy cùng lúc trên hệ thống : Sau khi đã định nghĩa các SLA cần thiết ta sẽ quan sát các biểu đồ.

Chọn biểu đồ Running User như hình dưới

Nhìn vào biểu đồ running user ta có thể thấy cứ sau 15s thì sẽ có 2 user đăng nhập vào hệ thống.Và lúc này sau hơn 1p 10 user đã đăng nhập và chạy trên hệ thống thành công.Tới 01:05 đã có 10 user đang chạy.Và tới phút 06:40 các user đã thoát khỏi hệ thống.Như vậy mục tiêu có 10 user được sever bắt thành công (Pass).Như vậy nếu muốn biết sever có khả năng chịu tải tối đa bao nhiêu user ta sẽ cho chạy lại script và nâng mức user lên mức mà chúng ta nghĩ rằng có thể.

22

B. Mục tiêu 10 user đăng nhập và đăng xuất khỏi hệ thống cùng lúc với thời gian response không quá 10 giây: Ta hãy xem biểu đồ dưới đây:

Ở đây ta thấy rằng transaction in_out ( gồm 2 trạng thái sign in và sign out của user ) có thời gian response trung bình của server là 1.369 giây (<10 giây) vì vậy khi thiết lập mục tiêu sla sẽ có kết quả là pass :

23

C. HP tours phải có thể xử lý được 10 tiến trình đăng ký chuyến bay giả lập (flying bookings ) với thời gian response không quá 90 seconds và HP tours phải có thể bắt được 10 user giả lập cùng kiểm tra button itinery với thời gian response không quá 120 seconds Tương tự như mục tiêu ở phần B ta cung thiết lập SLA và thu được kết quả như sau:

24

Kết quả 2 mục tiêu của phần C đều là pass

D. Kết Luận: Các SLA pass và đều thấp hơn nhiều so với mục tiêu đặt ra, điều này cho thấy rằng server hoạt động tốt và ổn định , có khả năng đáp ứng nhiều hơn kết quả test ở trên (HTTP 200 cho thấy server luôn ở tình trạng sẵn sàng xử lý các transactions một cách nhanh chóng và request của Vuser đêù được đáp ứng đầy đủ )

25