Đang tải... (xem toàn văn)
Đây là tài liệu mình tổng hợp từ tài liệu Paperwhite của IBM Performance Test Best Practices và thực kế công việc tại công ty mình đang làm việc. Hi vọng nó sẽ mang đến những cái nhìn khác với các tài liệu về KTHN tiếng việt đang mạng hiện nay, cũng như hữu ích cho công việc thực tế của của các bạn. Nội dung chính của tài liệu bao gồm: I. Kiểm thử hiêu năng 1. Muc đích kiểm thử hiệu năng 2. Các loại kiểm thử hiêu năng 2.1. Kiểm thử baseline 2.2. Kiểm thử Performance Load Tests 2.3. Kiểm thử Stress Tests 2.4. Kiểm thử Endurance Tests 2.5. Kiểm thử năng lực và sizing (Sizing and Capacity Tests). 2.6. Thực thi Debug và Turing (Performance Tuning and Debugging). 2.7. Batch Testing. 3. Các bước kiểm thử hiệu năng 3.1. Đánh giá 3.2. Lập kế hoạch 3.3. Tạo Testcase, testscript 3.4. Thực hiện kiểm thử hiệu năng 3.5. Tổng hơp và phân tích kết quả
TÀI LIỆU: KIỂM THỬ HIỆU NĂNG NGƯỜI THỰC HIỆN: NGUYỄN THỊ DOAN Kiểm thử hiêu Muc đích kiểm thử hiệu Theo tài liêu Paperwhite IBM lý phổ biến để kiểm thử hiêu năng: Để phuc cụ công tác sizing thống, dự đoán thiết kế xây dưng cấu hình server, đường I 2.1 truyền cho phù hơp Đảm bảo đáp ứng yêu cầu phi chức hiêu thống khách hàng Để kiểm tra, phát hiên phân tích “điểm thắt cổ chai” chức găp phải đươc thực lượng người dùng lớn Các loại kiểm thử hiêu Kiểm thử baseline Các phép đo (Baseline testing) nên thực trước thưc thi tiến trình kiểm thử đẩy tải Mục đích dạng kiểm tra để xác minh script chạy mong muốn cho phép bạn xác định khía cạnh ứng dụng hoạt động không tốt, có người dùng sử dụng Nếu ứng dụng không đáp ứng yêu cầu bạn tình này, rõ ràng vấn đề phải giải trước bạn chay script thêm lần Khi tập hợp phép đo hoàn thành với kết đạt yêu cầu, "điểm chuẩn tải" (Benchmark under load) thử nghiệm thực 2.2 Kiểm thử Performance Load Tests Sau kiểm tra baseline benchmark -under-load hoàn thành, viêc kiểm thử đẩy tải bắt đầu Đối với case kiểm thử tải trọng (Load test) nhân viên kiểm thử nên chạy điểm tải, bao gồm mô 50%, 75%, 100%, 125% 150% tải hệ thống dự kiến Bằng cách này, nhân viên kiểm thử xác định đươc ngưỡng đáp ứng hệ thống so với dư kiến => Mục tiêu việc kiểm tra tải trọng để đo thời gian đáp ứng giao dịch, số người dùng đồng thời mà thống đáp ứng đươc Đồng thời cách theo dõi tỷ lệ thất bại giao dịch, nhân viên kiểm thử xác định xem ứng dụng thực dự kiến xác định điểm gây tắt nghẽn chức 2.3 Kiểm thử Stress Tests Kiểm tra tải (Stress testing) tập trung vào việc xác định điểm break máy chủ Đối với loai kiểm thử này, bạn tăng số lượng người dùng đồng thời, làm chết máy chủ Thời gian (Response time) của case test Stress không xác định trước, bạn tăng người dùng đồng thời dần dần, đến điểm mà tất tài nguyên máy chủ cạn kiệt Bằng cách giám sát tài nguyên máy chủ thời gian stress test phân tích ghi hệ thống sau thất bại xác định 2.4 điều kiện gây cố trình kiểm thử Kiểm thử Endurance Tests Kiểm tra độ bền khác kiểm tra tải Load Testing Stress Testing, kiểm tra độ bền kiểm tra cách thức ứng dụng thực chạy số lượng đáng kể người dùng đồng thời thời gian dài thời gian Mục đích việc kiểm tra sức chịu đựng xác định rò rỉ nhớ, suy giảm hiệu suất theo thời gian, ổn định toàn hệ thống Nó phổ biến cho casetest thực khoảng thời gian khác nhau, từ 12 đến tuần Chỉ số quan trọng để theo dõi lần test tải đô bền là: thời gian đáp ứng giao dịch, thống số nhớ, CPU, thông lượng Ngoài cần tìm hiểu thêm số loại kiểm thử hiệu khác, quan trọng: 2.5 2.6 2.7 Kiểm thử lực sizing (Sizing and Capacity Tests) Thực thi Debug Turing (Performance Tuning and Debugging) Batch Testing Tham khảo thêm: Tài liệu lý thuyết kiểm thử hiệu thường chia thành loại sau: Load test - Xác định hành vi hệ thống điều kiện tải thường cao tải - Cho phép đo thông số: response time, throughput rate, bandwidth, mức độ sử dụng tài nguyên ( CPU, RAM ) - Xác định điểm break hệ thống: không cố ý làm break - Endurance testing (kiểm thử sức chịu đựng): xác định đặc tính hiệu hệ thống hoạt động đưới điều kiện khối lượng tải dự kiến thời kỳ Stress test - Tìm lỗi hệ thống xuất trường hợp tải khắc nghiệt , cạnh tranh tài nguyên: rò rỉ nhớ, thiếu dung lượng đĩa, thiếu băng thông mạng - Xác định điểm gãy server hành vi hệ thống xảy cố Chẳng hạn, hệ thống chịu đựng 30 người dùng đồng thời Thực stress test thực kiểm thử với tình 30 người đăng nhập lúc hành xử hệ thống có người thứ 31 cố gắng đăng nhập? - Kết stress test: hệ thống hoạt động bình thường hiệu suất giảm xuống xảy cố Từ xác định ngưỡng hệ thống - Chú ý: trình stress test không xác định trước, người kiểm thử phải tang người dùng đồng thời, cạnh tranh tài nguyên bị cạn kiệt Người kiểm thử xác định điều kiện dẫn đến lỗi cách giám sát tài nguyên server suốt trình kiểm thử stress test phân tích log hệ thống sau failure - Spike testing: xác định đặc tính hiệu hệ thống hoạt động đưới điều kiện khối lượng tải tăng liên tục vượt dự kiến thời gian ngắn Volumn test - Xác định giới hạn độ lớn liệu hệ thống - Số lượng lớn kết nối thực chức nghiệp vụ chu kỳ mở rộng ( stress test chu kỳ rộng) - Ví dụ: kiểm thử hiệu việc import/ insert khoảng 20MB liệu vào DB lúc Việc thực kiểm thử hiệu TTPM chia lại thành loại: Test đáp ứng: Kiểm thử khả đáp ứng số lượng người dùng đồng thời (CCU) mong muốn Số CCU đội dự án cung cấp Test ngưỡng: tìm ngưỡng chịu đựng hệ thống ( test đến hệ thống chết) Các bước kiểm thử hiệu năng` Quy trình thưc kiểm thử hiệu trải qua bước Đánh giá Tao Testcase, Thưc hiên kiểm thử Tổng hơp phân tích thử 3.1 Lâp kế hoạch kiểm testscript hiệu kết kiểm thử Đánh giá Môt kết đánh giá đắn thích hợp giúp cho viêc tối ưu hóa, hiệu hóa cách tiếp cân việc kiểm thử hiệu trước thống Để đánh giá tốt, người thưc cần phải nắm rõ đươc số nôi dung sau: - Nỗ lực cần dành cho công việc - Các công cụ sử dụng để kiểm thử hiêu hệ thống - Các yêu cầu buôc liệu hệ thống - Các yêu cầu thực kiểm thử - Kết mong muốn 3.2 Lập kế hoạch Môt kế hoạch kiểm thử/chiến lược kiểm thử giúp ban xây dưng đầy đủ, chi tiết khoa học thành phần tham gia, thời gian, kế hoach, yêu cầu trước thực kiểm thử Tài liệu kế hoạch kiểm thử bao gồm nội dung quan trọng sau: o Danh sách chức thưc hiên kiểm thử o Người tham gia thưc kiểm thử, nỗ lưc tham gia o Thời gian bắt đầu, kết thúc công việc o Các yêu cầu buôc hệ thống o Thiết kê bảng workload 3.3 Tạo Testcase, testscript Từ tài liệu kế hoạch kiểm thử (test plan), nhân viên kiểm thử tạo kich kiểm thử cho trường hơp thưc kiểm thử hiệu (tương tự kiểm thử chức năng, nhiên bổ sung thêm phần buộc liệu, kết mong muốn hiệu năng: CCU, Response time, Throught, Pass/Fail … Sau hoàn thành testcase, nhân viên kiểm thử sử dung công cụ để tao kịch (Script) mô lại chức kiểm thử Với hầu hết công cu, công việc cần thao tác để toàn script hoàn chỉnh, sử dung để đẩy tải bao gồm: o Record thao tác thống o Thưc hiên chèn transaction, comment, thành phần khác trình o record Sau công cụ thực hiên gencode, thực tham biến (Correlation data, userdata) Tạo liêu (test data) để thưc hiên kiểm thử giả lâp Thực hiên chèn checkpoint Ngoài thực config giá trị: thinktime… 3.4 Thực kiểm thử hiệu Thưc hiên kiểm thử bao gồm giai đoạn: Giai đoan 1: Kiểm thử baseline: Viêc chạy thử nghiệm đẩy tải tất vấn đề tìm thấy tiến trình o o o chay playback (Test baseline) giải sửa chữa, người thưc hiên kiểm thử thưc sư hiểu cách hệ thống phản hồi lần chay (Request & Response server…) Giai đoan 2: Kiểm thử giả lâp nhiều người dùng: Giai đoan bao gồm tiến trình: - Kiểm thử đẩy tải đơn lẻ chức năng: Viêc kiểm thử tải đơn lẻ chức giúp cho viêc phát hiên điểm “thắt cổ chai” thống Nghĩa phát hiên phân hê/ module có tiến trình chay lỗi chức năng/ hoăc không đáp ứng mong muốn hiêu người dùng => phuc vu cụ thể cho công tác tối hóa hiệu hệ thống - Kiểm thử đẩy tải theo workload (Kiểm thử tích hơp chức năng): Dưa vào phân tích từ kế hoạch/ chiến lươc kiểm thử Nhân viên kiểm thử xây dựng lich biểu (Schedule) để mô bảng workload thiết kế ( Mỗi workload có nhiều chức khác nhau, số lương CCU phân bổ khác nhau) Viêc kiểm thử mô đươc gần tác vụ nghiêp vu thưc tê khách hàng đưa thống thức đươc sử dung Từ đó, cho đôi dự án nhìn thấy đươc kết đáp ứng/ chưa đáp ứng hiệu mong muốn với số CCU, Response time, Throughput, tài nguyên chiếm dụng hệ thống chiu tải Các điểm cần lưu ý thưc kiểm thử đẩy tải: o Kết nối để lấy resource monitoring o Cấu hình nâng cao schedule 3.5 Tổng hơp phân tích kết Từ kết kiểm thử trích xuất công cu, nhân viên kiểm thử thưc hiên tổng hợp báo cáo lần kiểm thử từ kiểm thử baseline, đẩy tải để đôi dư án phân tích kĩ hơn, chứng để nhiêm vụ hệ thống với khách hàng Trong báo cáo cần tổng hơp thông số thiết yếu sau: Thời gian phản hồi (Response time) thời gian từ lúc client gửi request tới server client nhận response từ server trả Response time = Transfering time + Waiting time + Processing time Trong Transfering time thời gian truyền tải liệu đường truyền, Waiting time thời gian request chờ queue, Processing time thời gian request xử lý thực Throughput: Thông lượng hệ thống, tính số giao dịch (transaction) hệ thống đáp ứng khoảng thời gian Đơn vị tổng quát transaction per time_period vd: transactions per second, calls per day Concurrency: Số giao dịch đồng thời thực hiện, tính số giao dịch đồng thời hệ thống đáp ứng Capacity Measure: số lượng người dùng truy cập lớn mà ứng dụng đáp ứng thời điểm Về ta thực kiểm thử khoảng thời gian T1 định (thời gian đáp ứng) tăng dần số lượng người dùng thực chức sever nghẽn/chết -> ta lấy số lượng người dùng truy cập trước thời điểm server nghẽn/chết mà thỏa mãn chưa vượt thời gian T1 (response time) tỷ lệ fail chưa vượt 10% CPU usage: Hiệu suất sử dụng CPU RAM usage: Hiệu suất sử dụng RAM Tỉ lê Fail/Pass: Tỉ lệ lỗi, tính số giao dịch không thực thành công tổng số giao dịch thực Giá trị dùng để làm điều kiện cần cho mục tiêu Đơn vị % Ngoài báo cáo Rational Performance Tester, nhiều thông II số cần tìm hiểu thêm Công cu kiểm thử hiệu Một số công cụ kiểm thử hiêu Công cụ kiểm thử hiêu phần mềm hỗ trợ viêc tạo kich kiểm thử giả lập người dùng với số lương lớn để thưc thi trường hơp kiểm thử tải Có nhiều phần mềm kiểm thử hiệu thị trường Nó chia thành hai loại chính: phần mềm mã nguồn mở phần mềm có quyền