Kiểm thử hiệu năng và ứng dụng đảm bảo chất lượng cho các ứng dụng web luận văn ths công nghệ thông tin
Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (1.01 MB, 57 trang )
ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƢỜNG ĐẠI HỌC CÔNG NGHỆ
HOÀNG THỊ LUY
KIỂM THỬ HIỆU NĂNG VÀ ỨNG DỤNG ĐẢM BẢO
CHẤT LƢỢNG CHO CÁC ỨNG DỤNG WEB
LUẬN VĂN THẠC SĨ
Hà Nội – 2015
ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƢỜNG ĐẠI HỌC CÔNG NGHỆ
HOÀNG THỊ LUY
KIỂM THỬ HIỆU NĂNG VÀ ỨNG DỤNG ĐẢM BẢO
CHẤT LƢỢNG CHO CÁC ỨNG DỤNG WEB
Ngành: Công nghệ Thông tin
Chuyên ngành: Kỹ thuật Phần mềm
Mã Số: 60480103
LUẬN VĂN THẠC SĨ
NGƢỜI HƢỚNG DẪN KHOA HỌC: TS. PHẠM NGỌC HÙNG
Hà Nội – 2015
1
Mục lục
LỜI CẢM ƠN ............................................................................................................ 3
LỜI CAM ĐOAN ...................................................................................................... 4
DANH MỤC HÌNH VẼ, BẢNG BIỂU ..................................................................... 5
Chƣơng 1: Giới thiệu ................................................................................................ 6
Chƣơng 2: Tổng quan về kiểm thử hiệu năng .......................................................... 10
2.1
2.2
2.3
Định nghĩa kiểm thử hiệu năng .......................................................... 10
Phân loại kiểm thử hiệu năng............................................................. 11
Các thuật ngữ ..................................................................................... 14
Chƣơng 3: Phƣơng pháp kiểm thử hiệu năng và công cụ ........................................ 16
3.1
3.2
3.3
Kiểm thử hiệu năng trong vòng đời phát triển phần mềm ................. 16
Các dạng yêu cầu kiểm thử hiệu năng trong thực tế .......................... 20
Quy trình thực hiện kiểm thử hiệu năng ............................................ 22
3.3.1 Lập kế hoạch và kiểm soát kiểm thử ........................................ 23
3.3.2 Phân tích và thiết kế kiểm thử................................................... 24
3.3.3 Triển khai (Implementation) và thực thi (Execution) kiểm thử 26
3.3.4 Đánh giá các kết quả đầu ra và báo cáo .................................... 27
3.3.5 Các hoạt động kết thúc kiểm thử .............................................. 27
3.4
Một số công cụ kiểm thử hiệu năng ................................................... 28
Chƣơng 4: Ứng dụng kiểm thử hiệu năng vào dự án của đơn vị ............................. 34
4.1
4.2
4.3
4.4
Giới thiệu về dự án............................................................................. 34
Kế hoạch tổng thể của dự án .............................................................. 35
Lập kế hoạch kiểm thử hiệu năng ...................................................... 38
Thiết kế kiểm thử hiệu năng .............................................................. 42
4.4.1 Thiết kế môi trƣờng .................................................................. 42
4.4.2 Thiết kế các kịch bản kiểm thử ................................................. 44
4.5
Triển khai và thực thi kiểm thử hiệu năng ......................................... 47
4.5.1 Cài đặt môi trƣờng, công cụ...................................................... 47
4.5.2 Tạo các kịch bản kiểm thử bằng JMeter ................................... 48
4.5.3 Chạy các kịch bản ..................................................................... 50
4.6
Đánh giá kết quả đầu ra và báo cáo ................................................... 51
2
KẾT LUẬN .............................................................................................................. 53
TÀI LIỆU THAM KHẢO........................................................................................ 55
3
LỜI CẢM ƠN
Trƣớc tiên tôi xin gửi lời cảm ơn chân thành và sâu sắc đến thầy giáo, Tiến sĩ
Phạm Ngọc Hùng – ngƣời đã hƣớng dẫn, khuyến khích và tạo điều kiện tốt nhất
cho tôi thực hiện đề tài này. Bằng niềm đam mê và kinh nghiệm tuyệt vời về kiểm
thử, thầy luôn là ngƣời đồng hành và truyền cảm hứng cho tôi trong suốt quá trình
thực hiện nghiên cứu này.
Tôi xin gửi lời cảm ơn chân thành tới các thầy, cô giáo trong khoa Công nghệ
Thông tin, Trƣờng Đại học Công nghệ, Đại học Quốc Gia Hà Nội đã tận tình đào
tạo, trang bị cho tôi những kiến thức vô cùng quý giá trong suốt quá trình học tập,
nghiên cứu tại trƣờng.
Đồng thời tôi xin cảm ơn tất cả những ngƣời thân yêu trong gia đình tôi cùng
toàn thể bạn bè những ngƣời đã luôn giúp đỡ, động viên tôi những khi tôi gặp khó
khăn, bế tắc trong nghiên cứu.
Cuối cùng, tôi xin chân thành cảm ơn các đồng nghiệp của tôi tại Công ty Trách
Nhiệm Hữu Hạn Phần Mềm FPT, đặc biệt các anh chị em trong đội kiểm thử, đã
giúp đỡ, tạo điều kiện thuận lợi cho tôi học tập và nghiên cứu chƣơng trình thạc sĩ
tại Đại học Công nghệ, Đại học Quốc Gia Hà Nội.
4
LỜI CAM ĐOAN
Tôi xin cam đoan rằng luận văn thạc sĩ công nghệ thông tin “Kiểm thử hiệu
năng và ứng dụng đảm bảo chất lƣợng cho các ứng dụng Web” là công trình nghiên
cứu của riêng tôi, không sao chép lại của ngƣời khác. Trong toàn bộ nội dung của
luận văn, những điều đã đƣợc trình bày hoặc là của chính cá nhân tôi hoặc là đƣợc
tổng hợp từ nhiều nguồn tài liệu. Tất cả các nguồn tài liệu tham khảo đều có xuất
xứ rõ ràng và hợp pháp.
Tôi xin hoàn toàn chịu trách nhiệm và chịu mọi hình thức kỷ luật theo quy định
cho lời cam đoan này.
Hà Nội, ngày 09 tháng 05 năm 2015
Hoàng Thị Luy
5
DANH MỤC HÌNH VẼ, BẢNG BIỂU
Hình 3.1. Kiểm thử hiệu năng nằm trong các mức độ kiểm thử của hệ thống ........ 16
Hình 3.2. Kiểm thử hiệu năng trong mô hình thác nƣớc ......................................... 17
Hình 3.3. Kiểm thử hiệu năng trong mô hình chữ V ............................................... 19
Hình 3.4. Kiểm thử hiệu năng trong mô hình Agile – Scrum .................................. 20
Bảng 3.6. Tài liệu đầu vào và đầu ra của giai đoạn lập kế hoạch ............................ 23
Bảng 3.7. Tài liệu đầu vào và đầu ra của giai đoạn lập phân tích và thiết kế kiểm
thử............................................................................................................................. 25
Bảng 3.8. Tài liệu đầu vào và đầu ra của giai đoạn triển khai kiểm thử .................. 26
Bảng 3.9 So sánh một số công cụ tính phí phổ biến ................................................ 29
Bảng 3.10 So sánh một số công cụ mã nguồn mở phổ biến .................................... 31
Bảng 4.1. Tỉ lệ phân bổ thời gian giữa các công đoạn ............................................. 35
Bảng 4.2. Tỉ lệ phân bổ thời gian giữa các công đoạn (tính theo ngày làm việc) ... 35
Hình 4.3. Chi tiết công việc trong từng giai đoạn .................................................... 37
Bảng 4.4. Các thành viên tham gia vào dự án.......................................................... 38
Hình 4.5. Kế hoạch thời gian kiểm thử hiệu năng (Đơn vị tính: Ngày làm việc) .... 41
Hình 4.6. Tƣơng tác giữa Maven, Jenkins và JMeter .............................................. 44
Bảng 4.7. Các kịch bản kiểm thử ............................................................................. 45
Hình 4.8. Maven sau khi cài đặt............................................................................... 47
Hình 4.9. JMeter sau khi cài đặt............................................................................... 47
Hình 4.10. Jenkins sau khi cài đặt ............................................................................ 48
Hình 4.11. Cấu trúc thƣ mục dự án .......................................................................... 48
Hình 4.12. Các kịch bản kiểm thử............................................................................ 49
Hình 4.13. Dữ liệu kiểm thử .................................................................................... 50
Hình 4.14. Kết quả chạy với 10 ngƣời dùng đồng thời............................................ 50
Hình 4.15. Kết quả chạy với 80 ngƣời dùng đồng thời............................................ 50
Hình 4.16. Kết quả chạy với 100 ngƣời dùng đồng thời.......................................... 51
Hình 4.17. Kết quả chạy với 100 ngƣời dùng đồng thời.......................................... 51
6
Chƣơng 1: Giới thiệu
Kiểm thử hiệu năng (Performance test) là một phần rất quan trọng trong việc
đảm bảo chất lƣợng phần mềm. Đặc biệt đối với các ứng dụng Web, kiểm thử hiệu
năng ảnh hƣởng trực tiếp đến ngƣời sử dụng hệ thống cũng nhƣ các bên liên quan.
Chẳng hạn nhƣ, khách hàng truy cập một trang Web bán hàng trực tuyến của
một công ty. Sau một vài phút hoặc lâu hơn nữa, hệ thống mới tải xong ảnh sản
phẩm mà họ cần tìm. Việc này chắc hẳn sẽ ảnh hƣởng đến thái độ của khách hàng
đối với công ty đó. Họ cảm thấy khó chịu, mất thời gian. Những lần sau, họ sẽ đắn
đo hoặc có thể không bao giờ quay trở lại trang này nữa. Điều này đồng nghĩa với
việc công ty mất quan hệ khách hàng, mất doanh thu. Ở mức độ nghiêm trọng hơn,
khách hàng có thể mất tiền, thậm chí rất nhiều tiền do lỗi hiệu năng của hệ thống.
Dƣới đây, có thể kể ra một số thảm họa về hiệu năng của ứng dụng Web đã từng
xảy ra và mức độ thiệt hại mà nó gây ra.
Trang Web của Nectar1
Ngay khi ra mắt năm 2002, chƣơng trình thẻ tri ân khách hàng của Nectar đã rất
nỗ lực quảng cáo trên truyền hình và tiếp thị trực tiếp qua thƣ điện tử tới trên mƣời
triệu hộ gia đình, hƣớng mọi ngƣời tới dịch vụ mới ra mắt của họ. Mặc dù, đã có
phƣơng tiện đăng kí qua đƣờng điện thoại và thƣ điện tử trực tiếp, Nectar vẫn cố
gắng tiết kiệm chi phí bằng cách cung cấp một phần thƣởng khuyến khích mọi
ngƣời đăng kí trực tuyến qua trang Web. Trong khi Nectar đã chuẩn bị cho sự kiện
này bằng cách tăng dung lƣợng máy chủ lên gấp sáu lần, thì tại thời điểm đỉnh điểm
với mƣời nghìn lƣợt khách truy cập trong vòng một giờ đã đủ để trang Web bị chết
trong vòng ba ngày. Nectar đã dẫn ra độ phức tạp của quá trình đăng kí (bảo mật và
mã hóa) nhƣ là một nút thắt cổ chai [1].
Trang Web Bản đồ tội phạm của cảnh sát Anh2
Trong một động thái nhằm tăng tính minh bạch trong thống kê tội phạm, Chính
phủ Anh đƣa ra một trang Web trong tháng hai năm 2011, cho phép các thành viên
1
2
Đƣờng dẫn truy cập: />Đƣờng dẫn truy cập:
7
của công chúng có quyền truy cập vào thông tin về tỉ lệ tội phạm ở khu vực của họ
thông qua các điểm đánh dấu trên bản đồ tƣơng tác. Điều này đã nhận đƣợc những
tin tức chính thống, với những câu hỏi đƣợc đặt ra về độ chính xác và sự tác động
của các báo cáo, ví dụ, ảnh hƣởng đến tỉ lệ bảo hiểm hoặc giá nhà. Các bản đồ tội
phạm đã nhận đƣợc sự quan tâm rất lớn của công chúng. Nó nhận đƣợc mƣời tám
triệu hit một giờ trong ngày đầu tiên (Hit: là đơn vị dùng để đo lƣợng truy cập của
trang Web, mỗi tập tin gửi đến máy chủ đƣợc tính là 1 hit. Ví dụ, một trang Web có
20 hình ảnh mà ngƣời dùng có thể chọn để xem mỗi cái một lần, đƣợc tính là 20
hit). Điều này làm nó sập xuống trong vòng vài giờ theo kiểu rất công khai. Dƣờng
nhƣ có lý khi một trang Web bị sập dƣới mƣời tám triệu hit một giờ. Rõ ràng là
trang Web đơn giản là không thiết kế để có thể hoạt động đƣợc ở bất kì quy mô
nào, mặc dù nó đã dùng máy chủ Amazon EC2 để tăng thêm dung lƣợng. Nhƣ vậy
bạn vẫn cần xây dựng một trang Web mà dung lƣợng của nó không cần đến 1000
lần máy chủ [2].
Trang Web bán vé Thế vận hội London năm 20123
Có quá nhiều bài viết về sự kiện này. Tháng tƣ năm 2011, sau lƣợt bán vé đầu
tiên kết thúc, 6.6 triệu vé đã đƣợc bán trực tuyến. Vấn đề là vé không đƣợc bán ra
lần lƣợt, không phải là ngƣời đến trƣớc đƣợc phục vụ trƣớc, mà nhiều ngƣời đợi
đến phút cuối mới quyết định đặt mua. Trang Web đã chậm nhƣ rùa bò vì quá tải.
Họ đã phải chặn các cửa sổ để có thể tồn tại thêm vài giờ. Vài tháng sau, trang bán
vé của Thế vận hội đƣợc mở trở lại, cho phép ngƣời ta mua và bán vé chính thức
với nhau. Nhƣng nó vẫn không thể đối phó với nhu cầu, vẫn chậm. Nhiều vấn đề
xảy ra trong tháng mƣời hai và tháng một, với càng nhiều sự gián đoạn của trang
Web bán vé, dẫn đến nhiều sự kiện đã bị bán giảm giá [3].
Thông qua các ví dụ trên, ta có thể thấy tầm quan trọng về hiệu năng của các
ứng dụng Web, cũng nhƣ mức độ thiệt hại mà nó gây ra nếu nhƣ hệ thống không
đƣợc kiểm thử đầy đủ trƣớc khi đƣa vào vận hành. Việc cân bằng giữa công nghệ,
thời gian và tiền bạc để đạt đƣợc hiệu suất cao nhất của hệ thống cũng là một chủ
3
Đƣờng dẫn truy cập:
8
đề chính của Hội nghị thƣờng niên O‟Reilly4, một trong những hội nghị uy tín bàn
về các vấn đề nóng trong lĩnh vực công nghệ thông tin diễn ra hàng năm, tháng ba
năm 2014 tại San Francisco.
Trong bối cảnh Internet ngày càng chi phối sâu sắc tới các hoạt động sản xuất
kinh doanh cũng nhƣ đời sống xã hội, xu hƣớng dung lƣợng phần cứng ngày càng
tăng mạnh với giá thành rẻ đáp ứng quy mô của ứng dụng, bài toán kiểm thử hiệu
năng trở nên cấp thiết hơn bao giờ hết. Trên thế giới, nhiều tác giả với nhiều công
trình nghiên cứu đã đƣa ra nhiều phƣơng pháp tiếp cận và giải quyết bài toán kiểm
thử hiệu năng cho các ứng dụng Web. Các doanh nghiệp và cộng đồng yêu thích
kiểm thử hiệu năng cũng ra mắt nhiều công cụ hỗ trợ kiểm thử hiệu năng hiệu quả
loại ứng dụng này. Tuy nhiên, đối với thị trƣờng phần mềm non trẻ của Việt Nam,
không phải lúc nào việc kiểm thử hiệu năng của các ứng dụng Web cũng đƣợc quan
tâm một cách đúng mức. Nó có thể bị bỏ qua hoặc không đƣợc thực hiện một cách
đúng đắn, kỹ lƣỡng trƣớc khi triển khai sản phẩm. Kết quả là, các ứng dụng thƣờng
có độ tin cậy thấp và khả năng chịu tải kém. Một số nguyên nhân có thể kể đến là:
Một là, bản thân doanh nghiệp phát triển, doanh nghiệp đầu tƣ chƣa ý thức đƣợc
tầm quan trọng của kiểm thử hiệu năng; Hai là, chƣa có phƣơng pháp kiểm thử hiệu
năng một cách đúng đắn; Cuối cùng là, chi phí kiểm thử tốn kém (chi phí mua công
cụ, đào tạo kiểm thử viên, thực hiện kiểm thử, v.v.). Kiểm thử hiệu năng vẫn là bài
toán khó. Vì vậy, tôi quyết định chọn đề tài “Kiểm thử hiệu năng và ứng dụng
đảm bảo chất lượng cho các ứng dụng Web”.
Đề tài này nhằm cung cấp cái nhìn tổng thể về kiểm thử hiệu năng, đƣa ra
phƣơng pháp, công cụ cũng nhƣ cách thức giải quyết bài toán kiểm thử hiệu năng
của các ứng dụng Web, trong điều kiện thực tế của doanh nghiệp phần mềm ở Việt
Nam. Đặc biệt, phƣơng pháp sử dụng trong đề tài áp dụng cho mô hình phát triển
phần mềm nhanh – Agile, một trong những mô hình phát triển phần mềm mới và
hiệu quả hiện nay.
Luận văn bao gồm bốn chƣơng và một phần kết luận. Chƣơng 1 giới thiệu đề
tài. Chƣơng này giúp ngƣời đọc hiểu bối cảnh của đề tài, lý do chọn đề tài, mục
4
Đƣờng dẫn truy cập: />
9
đích của đề tài và cấu trúc luận văn. Chƣơng 2 trình bày tổng quan về kiểm thử
hiệu năng. Chƣơng này mô tả các khái niệm, thuật ngữ và các phân loại cơ bản
trong kiểm thử hiệu năng. Chƣơng 3 trình bày các phƣơng pháp kiểm thử hiệu năng
và công cụ. Một số cách tiếp cận bài toán kiểm thử hiện nay và các công cụ phổ
biến đƣợc phân tích kĩ lƣỡng ở chƣơng này. Chƣơng 4 trình bày ứng dụng kiểm thử
hiệu năng vào dự án của đơn vị. Ở chƣơng này, ngƣời đọc đƣợc tiếp cận với một
bài toán kiểm thử hiệu năng trọn vẹn theo mô hình phát triển phần mềm Agile –
Scrum thực tế trong một doanh nghiệp phần mềm - đƣợc cho là lớn nhất Việt Nam
hiện nay. Cuối cùng là phần kết luận. Phần này đánh giá kết quả đạt đƣợc của luận
văn, hƣớng mở rộng và tài liệu tham khảo.
10
Chƣơng 2: Tổng quan về kiểm thử hiệu năng
Chƣơng này đƣa ra các khái niệm, thuật ngữ cơ bản của kiểm thử hiệu năng và một
số phân loại kiểm thử hiệu năng. Việc hiểu đúng các khái niệm cũng nhƣ phân loại
kiểm thử hiệu năng giúp các nhóm kiểm thử chọn đƣợc phƣơng pháp kiểm thử hiệu
năng tối ƣu cho đơn vị mình.
2.1 Định nghĩa kiểm thử hiệu năng
Kiểm thử hiệu năng đƣợc định nghĩa theo nhiều cách khác nhau.
Theo [4], “Hiệu năng là mức độ mà một hệ thống hay thành phần thực hiện các
chức năng xác định của nó trong các ràng buộc nhất định, nhƣ tốc độ, độ chính xác
hay khả năng sử dụng bộ nhớ. Kiểm thử hiệu năng là kiểm thử đƣợc tiến hành để
đánh giá việc tuân thủ đúng của một hệ thống hoặc thành phần theo các yêu cầu
hiệu năng xác định.”
Theo [5], Kiểm thử hiệu năng nói chung là một loại kiểm thử với với ý định là
để xác định khả năng phản hồi, thông lƣợng, độ tin cậy và/hoặc khả năng mở rộng
của hệ thống dƣới lƣợng tải công việc (workload) xác định. Theo đó, các tác giả
cũng cho rằng các hoạt động liên quan đến hiệu năng, nhƣ kiểm tra và chỉnh sửa,
quan tâm đến việc đạt đƣợc thời gian phản hồi (response times), thông lƣợng
(throughput) và các mức độ tối ƣu hóa tài nguyên (resource-utilization) phù hợp với
các mục tiêu hiệu năng đối với ứng dụng cần kiểm tra.
Hai định nghĩa ở trên là hai định nghĩa chính thống, đƣợc đƣa ra bởi các tổ chức
uy tín và đƣợc công nhận, sử dụng rộng rãi. Ngoài ra, kiểm thử hiệu năng còn tồn
tại nhiều cách hiểu khác nhau. Mặc dù nó đƣợc mô tả theo các cách thức khác
nhau, nhƣng trong các định nghĩa, một số điểm chung của nó vẫn đƣợc làm nổi bật
nhƣ: Nó là một loại kiểm thử phi chức năng của hệ thống (non-functional), do các
bên liên quan đƣa ra hoặc chính đội phát triển phần mềm có nhu cầu kiểm tra sản
phẩm của mình, nhằm kiểm tra các đặc tính của ứng dụng nhƣ tốc độ, khả năng mở
rộng, tính ổn định, trong một điều kiện nhất định (môi trƣờng kiểm thử). Việc thực
hiện kiểm thử hiệu năng thƣờng tốn nhiều thời gian và cần phải đƣợc thực hiện
11
thƣờng xuyên. Đặc biệt, để lấy đƣợc chính xác các thông số hiệu năng quan trọng,
nó thƣờng đƣợc thực hiện bằng công cụ.
2.2 Phân loại kiểm thử hiệu năng
Theo [5], kiểm thử hiệu năng là một hoạt động rộng và phức tạp, nó có thể thực
hiện ở nhiều dạng dẫn đến nhiều rủi ro, và cung cấp một loạt các giá trị cho một tổ
chức. Việc quan trọng là hiểu đƣợc các loại kiểm thử hiệu năng khác nhau để giảm
rủi ro, giảm thiểu chi phí và để biết khi nào áp dụng kiểm thử hiệu năng trong một
dự án kiểm thử hiệu năng xác định. Để áp dụng các loại kiểm thử hiệu năng khác
nhau, đội kiểm thử cần đánh giá đƣợc một số điểm chính nhƣ đƣợc trình bày dƣới
đây.
Thứ nhất, các mục tiêu của việc kiểm thử hiệu năng phải đƣợc xác định rõ
ràng. Đối với hầu hết các ứng dụng Web, các mối quan tâm về hiệu năng
thƣờng đƣợc đặt ra nhƣ “Nó có đủ nhanh không?”, “Nó phục vụ đƣợc tất cả
các khách hàng không?”, “Điều gì xảy ra nếu nó hoạt động sai?”, và “Tôi
cần có kế hoạch gì khi tôi có thêm nhiều khách hàng nữa?”. Ở mức độ thông
thƣờng, mọi ngƣời liên hệ việc “đủ nhanh” với kiểm thử hiệu năng, “đáp
ứng mức chuẩn ngƣời dùng hiện tại/kỳ vọng” với kiểm thử tải, “một cái gì
đó chạy sai” (something going wrong) với kiểm thử áp lực, và “lập kế hoạch
cho sự phát triển tƣơng lai” với kiểm thử dung lƣợng.
Thứ hai, ngữ cảnh kiểm thử hiệu năng, ví dụ, các tài nguyên liên quan, chi
phí và các giá trị tiềm năng về mặt công sức kiểm thử cũng phải đƣợc đánh
giá cụ thể. Kiểm thử hiệu năng phụ thuộc rất lớn vào yếu tố môi trƣờng nhƣ
phần cứng, phần mềm, hệ thống mạng và kinh nghiệm của ngƣời thực hiện.
Để lấy đƣợc các số liệu quan trọng, nó đòi hỏi phải thực hiện lặp lại trong
một thời gian dài. Do vậy, chi phí kiểm thử hiệu năng thƣờng rất tốn kém.
Từ việc xác định rõ mục tiêu, đội kiểm thử cần đánh giá chi tiết ngữ cảnh
kiểm thử để cân đối giữa giá trị đạt đƣợc và chi phí tiêu tốn.
12
Theo [7], kiểm thử hiệu năng (Performance test) là một thuật ngữ chung. Nó
bao gồm các loại kiểm thử nhỏ hơn: kiểm thử tải (Load test), kiểm thử áp lực
(Stress test).
Kiểm thử tải: Phân loại nhỏ của kiểm thử hiệu năng, tập trung vào xác định
hoặc kiểm tra các đặc tính hiệu năng của hệ thống hoặc ứng dụng cần kiểm thử khi
chịu tải công việc và khối lƣợng tải cho trƣớc trong các hoạt động của sản phẩm.
Kiểm thử tải để kiểm tra khả năng xử lý của ứng dụng ở các điều kiện tải bình
thƣờng hoặc điều kiện tải tối đa.
Kiểm thử áp lực: Phân loại nhỏ của kiểm thử hiệu năng, tập trung xác định
hoặc kiểm tra các đặc tính hiệu năng của hệ thống hoặc ứng dụng cần kiểm thử
trong những điều kiện vƣợt ra ngoài những điều kiện dự đoán trƣớc trong các hoạt
động của sản phẩm. Kiểm thử áp lực cũng có thể bao gồm những kiểm thử tập
trung vào xác định hoặc kiểm tra các đặc tính hiệu năng của hệ thống hay ứng dụng
cần test khi chịu các điều kiện về áp lực, nhƣ bộ nhớ bị giới hạn, không gian ổ đĩa
không đủ, lỗi máy chủ. Những kiểm thử này đƣợc thiết kế để xác định dƣới những
điều kiện gì mà ứng dụng bị lỗi, lỗi nhƣ thế nào và những chỉ số gì có thể đƣợc
kiểm soát để đƣa ra cảnh báo về lỗi sắp xảy ra. Kiểm thử áp lực để xác định hoặc
kiểm tra hành vi của một ứng dụng khi đẩy nó vƣợt ra ngoài các điều kiện tải bình
thƣờng hoặc tối đa.
Ngoài hai loại kiểm thử hiệu năng phổ biến gồm kiểm thử tải và kiểm thử áp
lực, một số tác giả còn đƣa ra nhiều loại nhỏ khác nhau:
Kiểm thử dung lƣợng (Capacity test): kiểm thử dung lƣợng bổ sung cho kiểm
thử tải bằng cách xác định điểm lỗi cuối cùng của máy chủ, trong khi kiểm thử tải
theo dõi các kết quả ở các mức độ khác nhau của các mẫu lƣu lƣợng và tải. Kiểm
thử dung lƣợng đƣợc thực hiện cùng với các kế hoạch về dung lƣợng, cái đƣợc sử
dụng để lập kế hoạch cho sự tăng trƣởng trong tƣơng lai, nhƣ tăng số lƣợng ngƣời
dùng cơ bản hoặc tăng khối lƣợng dữ liệu. Ví dụ, để phù hợp với lƣợng tải trong
tƣơng lai, bạn cần biết có bao nhiêu tài nguyên cần thiết đƣợc thêm vào để hỗ trợ
các mức độ sử dụng trong tƣơng lai nhƣ dung lƣợng bộ vi xử lý, khả năng sử dụng
bộ nhớ, dung lƣợng ổ đĩa hoặc băng thông mạng. Kiểm thử dung lƣợng giúp bạn
13
xác định đƣợc một chiến lƣợc mở rộng quy mô để xác định nên mở rộng theo chiều
dọc hoặc chiều ngang (scale up hoặc scale out) [5].
Kiểm thử sức bền (Endurance test): Kiểm thử sức bền là một loại kiểm thử
hiệu năng tập trung vào xác định hoặc kiểm tra các đặc tính hiệu năng của ứng
dụng khi chịu các mô phỏng tải làm việc hoặc khối lƣợng tải cho trƣớc trong một
khoảng thời gian dài. Kiểm thử sức chịu đựng là một tập con của kiểm thử tải [5].
Kiểm thử tăng đột ngột (Spike test): Kiểm thử tăng đột ngột là một loại kiểm
thử tập trung vào xác định hoặc kiểm tra các đặc tính hiệu năng của sản phẩm cần
kiểm thử khi chịu các mô phỏng tải làm việc và khối lƣợng tải tăng liên tục, vƣợt
qua các hoạt động định trƣớc trong một khoảng thời gian ngắn. Kiểm thử tăng đột
ngột là một tập con của kiểm thử áp lực [5].
Kiểm thử mức cơ sở (Baseline test): Việc kiểm thử này thiết lập một điểm so
sánh cho thử nghiệm chạy, đặc trƣng cho việc đo đạc thời gian phản hồi của giao
dịch (transaction). Kiểm thử này thƣờng đƣợc thực hiện trong một giao dịch đơn lẻ
cũng nhƣ một ngƣời dùng ảo đơn lẻ trong một khoảng thời gian cố định hoặc một
số lƣợng lặp các giao dịch cố định. Việc này nên đƣợc thực hiện mà không có bất
kì gi hoạt động nào khác trong hệ thống nhằm cung cấp một số đo trong “trƣờng
hợp tốt nhất”. Giá trị thu đƣợc có thể đƣợc sử dụng để xác định lƣợng suy giảm
hiệu suất xảy ra trong phản hồi để tăng số lƣợng ngƣời dùng hoặc thông lƣợng [7].
Việc kiểm thử này sẽ giúp phát hiện vấn đề và cô lập nó trong một kịch bản.
Chúng ta sẽ không mất thời gian lãng phí để xây dựng và chuẩn bị một kiểm thử tải
đầy đủ với nhiều kịch bản và tốn nhiều thời gian để cô lập nguyên nhân gây ra.
Mục đích của nó là để giải quyết các vấn đề sớm và có một kiểm thử chạy rõ ràng
(clear run) khi kiểm thử tải đầy đủ đầu tiên đƣợc thực hiện. Nó làm giảm thất bại
trong việc tìm nguyên nhân gây ra vấn đề hoặc nút thắt cổ chai so với việc giám sát
nhiều ngƣời dùng và giao dịch ở cùng một thời điểm [8].
Kiểm thử dài (Soak test): Một kiểm thử dài là một kiểm thử tải chạy trong
khoảng thời gian dài. Những rò rỉ của bộ nhớ có lẽ là vấn đề đƣợc phát hiện phổ
biến nhất trong suốt quá trình kiểm thử dài, nhƣng việc mất kết nối cũng đƣợc phát
hiện và việc tăng cơ sở dữ liệu cũng đƣợc kiểm soát. Những ngƣời liên quan sẽ
14
tham gia vào lập kế hoạch kiểm thử dài và hỏi họ muốn kiểm soát những gì trong
lĩnh vực cụ thể của họ. Thời gian và các vấn đề cần thiết khác nhƣ dữ liệu kiểm thử
cũng là một số vấn đề chính cần giải quyết khi lập kế hoạch và thực hiện một kiểm
thử dài đúng đắn. Kiểm thử nên chạy trong thời gian dài nhất có thể hoặc đến khi
xác định đƣợc xu hƣớng cụ thể qua một số giám sát. Quá trình kiểm thử dài có lẽ
đã phát hiện ra nhiều nhất các lỗi nghiêm trọng [8].
Kiểm thử khối lƣợng (Volume test): Kiểm thử khối lƣợng đề cập đến kích cỡ
hay cụ thể hơn là các kích thƣớc của tập tin và cơ sở dữ liệu. Kiểm thử này thƣờng
không có yêu cầu, nhƣng quan trọng, phụ thuộc vào loại ứng dụng đƣợc kiểm thử.
Kích cỡ của cơ sở dữ liệu ảnh hƣởng lớn đến hiệu năng và nó nên đƣợc đƣa ra nhƣ
một rủi ro khi kiểm thử hiệu năng đƣợc thực hiện đối với cơ sở một cơ sở dữ liệu
nhỏ so sánh với kích thƣớc thật trên môi trƣờng vận hành sản phẩm. Với kiểm thử
khối lƣợng, tải không đòi hỏi số lƣợng ngƣời dùng cao mà việc lập kế hoạch cẩn
thận về cách thực hiện test nhƣ thế nào mới là cần thiết [8].
2.3 Các thuật ngữ
Để tìm hiểu kiểm thử hiệu năng, các thuật ngữ cơ bản cần phải đƣợc hiểu rõ.
Một số thuật ngữ chính đƣợc trình bày nhƣ dƣới dây.
Dung lƣợng (capacity): Dung lƣợng của hệ thống là tổng các tải làm việc nó
xử lý mà không gây xung đột với tiêu chí chính chấp nhận về hiệu năng cho trƣớc
[5].
Thời gian nghĩ (Think time): Là thời gian thể hiện độ trễ hoặc tạm dừng mà
một ngƣời dùng nào đó thực hiện trong khi tƣơng tác với một ứng dụng [7].
Tải công việc (Work load): Tải công việc là một tác nhân kích thích đƣợc sử
dụng cho một hệ thống, ứng dụng hoặc thành phần mô phỏng một mẫu sử dụng,
liên quan đến tính đồng thời và/hoặc dữ liệu nhập. Tải làm việc bao gồm tổng số
lƣợng ngƣời dùng, ngƣời dùng đồng thời, khối lƣợng dữ liệu và khối lƣợng giao
dịch đi kèm với giao dịch. Đối với mô hình hiệu năng, bạn kết hợp một tải công
việc với một kịch bản riêng [5].
15
Thời gian phản hồi (Response time): Là việc đo đạc một ứng dụng hoặc hệ
thống con đáp ứng nhƣ thế nào đối với một yêu cầu từ máy khách (client) [5].
Thông lƣợng (Throughput): Là số lƣợng đơn vị công việc đƣợc xử lí trong
một đơn vị thời gian. Ví dụ, số yêu cầu trên giây, số cuộc gọi trong một ngày, số hit
trong một giây, v.v [5].
Ngƣời dùng đồng thời (concurrent user): Là ngƣời sử dụng hệ thống ở cùng
một thời điểm.
16
Chƣơng 3: Phƣơng pháp kiểm thử hiệu năng và
công cụ
Sau khi hiểu các khái niệm cơ bản cũng nhƣ một số loại kiểm thử hiệu năng ở
chƣơng 2, chƣơng này sẽ cung cấp phƣơng pháp tiếp cận và giải quyết bài toán
kiếm thử hiệu năng và phân tích một số công cụ kiểm thử hiệu năng phổ biến trên
thị trƣờng.
3.1 Kiểm thử hiệu năng trong vòng đời phát triển phần
mềm
Xem xét ở mức độ kiểm thử, theo [6], nếu chia kiểm thử thành các cấp độ:
Kiểm thử đơn vị, kiểm thử tích hợp, kiểm thử hệ thống, kiểm thử cài đặt/triển khai,
kiểm thử chấp nhận, thì kiểm thử hiệu năng bắt đầu đƣợc thực thi từ giai đoạn kiểm
thử tích hợp. Hình 3.1 mô tả giai đoạn mà kiểm thử hiệu năng đƣợc thực hiện. Dễ
thấy, kiểm thử hiệu năng là một phần của kiểm thử tích hợp. Thông thƣờng, kiểm
thử hiệu năng đƣợc tiến hành ngay khi tích hợp các thành phần phần mềm. Ở mức
độ này, các thành phần của hệ thống đủ nhỏ để tiến hành kiểm thử. Các thông số và
lỗi hiệu năng đƣợc phát hiện sớm, dẫn đến việc phân tích vấn đề và sửa lỗi đƣợc dễ
dàng.
Kiểm thử chấp nhận
Kiểm thử cài đặt/
triển khai
Kiểm thử hệ thống
Kiểm thử tích hợp
Kiểm thử h
iệu năng
Kiểm thử đơn vị
Hình 3.1. Kiểm thử hiệu năng nằm trong các mức độ kiểm thử của hệ thống
Xem xét ở cấp độ cao hơn, trong vòng đời phát triển phần mềm, việc tiến hành
kiểm thử hiệu năng phụ thuộc vào mô hình phát triển phần mềm đƣợc định nghĩa ở
17
giai đoạn đầu của dự án. Mỗi mô hình sẽ áp dụng kiểm thử hiệu năng theo một cách
riêng biệt và phù hợp. Dƣới đây, kiểm thử hiệu năng đƣợc áp dụng cho ba mô hình
phát triển phần mềm nổi tiếng là mô hình thác nƣớc truyền thống, mô hình phát
triển hình chữ V và mô hình phát triển nhanh – Agile –Scrum. Những phân tích này
sẽ giúp đội kiểm thử dự đoán đƣợc những thuận lợi và khó khăn, đồng thời nhanh
chóng tìm ra những giải pháp tốt nhất giải quyết những vấn đề gặp phải.
Với dự án áp dụng mô hình thác nước truyền thống: Các bƣớc của hoạt động
kiểm thử hiệu năng đƣợc tiến hành trọn vẹn ở giai đoạn kiểm thử. Hình 3.2 thể hiện
các hoạt động kiểm thử hiệu năng đƣợc thực hiện trong pha kiểm thử của mô hình
thác nƣớc. Mũi tên đi xuống thể hiện thứ tự hoàn thành của từng pha. Ƣu nhƣợc
điểm của việc kiểm thử này cũng tƣơng tự nhƣ ƣu nhƣợc điểm của mô hình truyền
thống. Kiểm thử hiệu năng đƣợc gói gọn trong một pha. Nên quá trình kiểm thử
này dễ dàng đƣợc phân công, phân bổ chi phí và kiểm soát. Tuy nhiên, nhƣợc điểm
của việc áp dụng kiểm thử hiệu năng trong mô hình này cũng khá lớn. Các giai
đoạn phát triển đƣợc tiến hành tuần tự, xong giai đoạn này mới đến giai đoạn tiếp
theo. Trong trƣờng hợp lý tƣởng, các yêu cầu kiểm thử hiệu năng đúng đắn và rõ
ràng ngay từ đầu. Một khi quá trình kiểm thử phát hiện ra lỗi ở pha kiểm thử, đội
phát triển lại tiến hành phân tích ngƣợc lại pha lập trình, thiết kế và phân tích yêu
cầu để tìm ra vấn đề. Lỗi càng đƣợc tìm ra muộn, thì chi phí sửa lỗi càng cao.
Trong một trƣờng hợp khác – trƣờng hợp phổ biến, khi phân tích yêu cầu về hiệu
năng ở giai đoạn kiểm thử, đội kiểm thử phát hiện ra những yêu cầu chƣa phù hợp
và quyết định thay đổi. Đội phát triển phải phân tích yêu cầu lại, thiết kế lại, và lập
trình lại. Vậy, thời gian dự án kéo dài, khả năng thất bại cao.
Phân tích yêu
cầu
Thiết kế
Lập trình
Thực hiện kiểm
thử hiệu năng
Kiểm thử
Hình 3.2. Kiểm thử hiệu năng trong mô hình thác nƣớc
Bƣớc 1,
Bƣớc 2,
…
Bƣớc n
18
Với dự án áp dụng mô hình chữ V (V-Model): Các bƣớc kiểm thử hiệu năng
đƣợc tiến hành song song với các giai đoạn của dự án. Hình 3.3 minh họa các bƣớc
của kiểm thử hiệu năng đƣợc thực hiện trong mô hình phát triển phần mềm hình
chữ V. Hƣớng mũi tên thể hiện các hoạt động theo trình tự thời gian từ trái sang
phải. Mỗi giai đoạn phát triển ở nửa chữ V bên trái tƣơng ứng với một số hoạt động
của các mức độ kiểm thử ở nửa chữ V bên phải và cột các hoạt động kiểm thử hiệu
năng. Cụ thể là, ngay ở giai đoạn phân tích yêu cầu, kiểm thử viên đƣợc tham gia
phân tích và đƣa ra các tiêu chí đầu ra chấp nhận của kiểm thử chấp nhận, trong đó,
các tiêu chí chấp nhận của kiểm thử hiệu năng đƣợc xác định. Ở giai đoạn này, đối
với kiểm thử chức năng, tài liệu liên quan đến các ca kiểm thử chấp nhận đƣợc tạo
ra, đối với kiểm thử hiệu năng, một bản kế hoạch chi tiết đƣợc hoàn thành. Tiếp
theo, ở giai đoạn thiết kế kiến trúc, đội phát triển sẽ thiết kế tổng quát cấu trúc các
thành phần hệ thống. Tƣơng ứng với hoạt động kiểm thử chức năng, các kiểm thử
viên sẽ phân tích và tạo ra tài liệu về các ca kiểm thử mức hệ thống. Hoạt động
kiểm thử hiệu năng sẽ là phân tích, thiết kế tổng quát các kịch bản kiểm thử, thiết
kế môi trƣờng. Ở giai đoạn thiết kế chi tiết, các thiết kế kiểm thử hiệu năng sẽ đƣợc
triển khai chi tiết thành các ca kiểm thử. Đội kiểm thử sẽ cài đặt công cụ, môi
trƣờng để chuyển các ca kiểm thử dạng ngôn ngữ tự nhiên sang các kịch bản của
công cụ. Sau đó, các kịch bản đƣợc chạy, thu thập kết quả và phân tích đánh giá.
Nhƣ vậy, các hoạt động kiểm thử hiệu năng đƣợc thực hiện song song với các hoạt
động kiểm thử khác. Các tài liệu tạo ra tƣơng ứng với quá trình phát triển dự án.
Điều này giúp cho đội kiểm thử phát hiện lỗi sớm, làm cho chi phí điều tra lỗi và
sửa lỗi giảm xuống. Tuy nhiên, dễ dàng nhận thấy các hoạt động kiểm thử hiệu
năng đƣợc thực hiện đan xen với các hoạt động kiểm thử chức năng trong các pha
của dự án. Các tài liệu đƣợc tạo ra cho từng giai đoạn. Đây chính là những khó
khăn khi áp dụng kiểm thử hiệu năng cho mô hình này. Việc quản lý, phân công
công việc và kiểm soát các hoạt động trở nên phức tạp.
19
Thực hiện kiểm thử
hiệu năng
Kiểm thử chấp
nhận
Phân tích yêu cầu
Thiết kế kiến trúc
Kiểm thử hệ thống
Thiết kế chi tiết Kiểm thử tích hợp
Bƣớc 1
Bƣớc 2
...
Bƣớc n
Lập trình & Kiểm
thử đơn vị
Hình 3.3. Kiểm thử hiệu năng trong mô hình chữ V
Với dự án áp dụng mô hình phát triển nhanh – Agile-Scrum: Có sự khác biệt
trong việc ứng dụng kiểm thử hiệu năng vào mô hình phát triển phần mềm nhanh –
Agile-Scrum. Trong mô hình Agile - Scrum, dự án đƣợc chia thành các giai đoạn
nhỏ (gọi là Sprint), yêu cầu của ngƣời dùng đƣợc chia thành các nhiệm vụ nhỏ,
thực hiện một nghiệp vụ tƣơng đối độc lập trong hệ thống (gọi là các User Story).
Mỗi Sprint kéo dài khoảng 2 tuần và thực hiện một hoặc vài User Story. Mỗi Sprint
hoàn thành bao gồm phần hệ thống đƣợc phát triển trong Sprint đó cộng với phần
đƣợc phát triển trong các Sprint trƣớc đó. Ứng dụng đƣợc tích hợp các phần mới
liên tục qua các Sprint. Việc kiểm thử hiệu năng trong mô hình này đòi hỏi phải
phù hợp.
Thuận lợi của việc áp dụng kiểm thử hiệu năng trong mô hình này là các yêu
cầu đƣợc chia nhỏ, thời gian ngắn dễ quản lý và và kiểm soát thực hiện. Sau mỗi
Sprint, đội phát triển sẽ bàn giao phần hoàn thiện của Sprint đó và các tài liệu liên
quan cho khách hàng của họ. Điều này giúp cho tƣơng tác giữa khách hàng và đội
phát triển tăng lên. Khách hàng phản hồi sớm đồng nghĩa với việc các yêu cầu đƣợc
thay đổi và cập nhật nhanh, đáp ứng sự hài lòng của khách hàng. Khó khăn trong
mô hình này là khi tích hợp các Sprint đã hoàn thiện vào với nhau. Lỗi gặp phải lúc
này thƣờng tốn thời gian tìm và sửa. Do vậy các đội phát triển đã chọn phƣơng án
tích hợp dần, tích hợp liên tục từng phần ngay khi Sprint đƣợc hoàn thiện. Mặc dù
vậy, kiểm thử hiệu năng vẫn gặp những khó khăn: các thông số hiệu năng đã đạt
yêu cầu ở Sprint trƣớc, nhƣng khi tích hợp với phần hệ thống của Sprint sau, nó lại
20
không thỏa mãn yêu cầu khách hàng nữa. Nếu đội kiểm thử không có phƣơng pháp
tốt, họ rất dễ phải đập đi làm lại. Và, càng ở các Sprint cuối, khi hệ thống càng
hoàn thiện, các vấn đề liên quan đến hiệu năng càng phát sinh. Theo minh họa ở
Hình 3.4, để đạt đƣợc hiệu quả của việc kiểm thử hiệu năng, việc kiểm thử ở Sprint
2 phải bao gồm phần mới ở Sprint 2 mà không ảnh hƣởng đến phần đã kiểm tra ở
Sprint 1. Do vậy, cách tốt nhất là thực hiện lại các kiểm thử đã chạy ở Sprint 1, vừa
chạy song song với cái mới ở Sprint 2.
Sprint 1
Sprint 2
Phân tích
Phân tích
Thiết kế Lập trình Kiểm thử
yêu cầu
yêu cầu
Kiểm thử hiệu năng
Bƣớc 1,
Bƣớc 2,
(v.v.)
Thiết
Lập trình Kiểm thử
kế
Sprint n
...
Kiểm thử hiệu năng
Bƣớc 1,
Bƣớc 2,
(v.v.)
...
...
...
Kiểm thử hiệu năng
Bƣớc 1,
Bƣớc 2,
(v.v.)
Hình 3.4. Kiểm thử hiệu năng trong mô hình Agile – Scrum
3.2 Các dạng yêu cầu kiểm thử hiệu năng trong thực tế
Kiểm thử hiệu năng là một bài toán đặc thù. Về lý thuyết, tất cả các ứng dụng
Web trƣớc khi đƣợc đƣa vào vận hành đều phải đƣợc kiểm thử đầy đủ, trong đó có
kiểm thử hiệu năng. Tuy nhiên, không phải ứng dụng nào hay đơn vị sản xuất phần
mềm nào cũng thực hiện một bài toán kiểm thử nhƣ nhau. Các bên liên quan luôn
phải cân đối giữa công nghệ, thời gian và chi phí. Do đó, các bài toán kiểm thử hiệu
năng trên thực tế cũng có nhiều màu sắc đa dạng khác nhau.
Qua khảo sát các dự án có yêu cầu về kiểm thử hiệu năng tại nhiều Công ty
phần mềm lớn tại Việt Nam, nhiều dạng yêu cầu về bài toán kiểm thử hiệu năng
đƣợc ghi nhận trên thực tế. Nếu theo thời gian phát sinh yêu cầu kiểm thử hiệu
năng, các bài toán đƣợc chia làm hai dạng: dạng có yêu cầu rõ ràng từ đầu và dạng
phát sinh.
Dạng 1 - Loại bài toán có yêu cầu rõ ràng từ đầu: Thƣờng gặp đối với các hệ
thống lớn nhƣ trang Web của các hệ thống ngân hàng, các trang nhận gửi hàng đa
quốc gia, các sàn giao dịch chứng khoán, v.v. Đối tác nắm rõ lƣu lƣợng ngƣời dùng
21
cuối truy cập trang Web của mình. Họ có yêu cầu chi tiết về kiểm thử hiệu năng đối
với đội phát triển ngay từ khi bắt đầu dự án. Khi hệ thống đƣợc đƣa vào vận hành,
họ có các giai đoạn bảo trì hoặc nâng cấp thêm. Song song với các giai đoạn này,
họ cũng cập nhật thêm các yêu cầu về kiểm thử hiệu năng. Với loại này, các bƣớc
thực hiện kiểm thử sẽ đƣợc tiến hành nhƣ ở mục 3.3.
Dạng 2 - Loại bài toán phát sinh: Loại này thƣờng gặp đối với các dự án nhỏ
hoặc các dự án mà ngay từ đầu các bên liên quan nhƣ đối tác và đội phát triển phần
mềm không xác định rõ đƣợc các yêu cầu về hiệu năng. Sau đó, trong giai đoạn
phát triển, tích hợp, kiểm thử, v.v. thậm chí cả khi vận hành, hệ thống gặp vấn đề
về hiệu suất (tải chậm, treo, v.v.). Lúc này, yêu cầu về kiểm thử hiệu năng mới phát
sinh. Với bài toán này, việc tiến hành thực hiện kiểm thử hiệu năng trở nên khó
khăn hơn. Đội phát triển phải dựa vào giai đoạn phát sinh yêu cầu kiểm thử để đánh
giá đƣợc hệ thống trong các điều kiện ràng buộc (tốc độ mạng, dung lƣợng phần
cứng, lƣu lƣợng truy cập, v.v.). Từ đó, định mức các thông số hiệu năng của hệ
thống và thực hiện các bƣớc kiểm thử nhƣ trình bày ở mục 3.3.
Sự phân chia bên trên chỉ là tƣơng đối. Ngay cả đối với bài toán đã có yêu cầu
kiểm thử hiệu năng rõ ràng từ đầu, thì trong các giai đoạn phát triển sau, các yêu
cầu kiểm thử hiệu năng vẫn phát sinh.
Đặc thù của yêu cầu kiểm thử hiệu năng thƣờng rất chi tiết, cụ thể. Tuy nhiên,
trong thực tế, bên đƣa yêu cầu kiểm thử hiệu năng thƣờng không mô tả đầy đủ, chi
tiết yêu cầu của họ đƣợc. Thậm chí việc xác định đúng, rõ yêu cầu phải đƣợc tham
gia thảo luận, đánh giá của nhiều bên liên quan. Đặc biệt với đội tham gia thực hiện
kiểm thử hiệu năng. Do vậy, việc hiểu đúng ngữ cảnh xuất phát yêu cầu kiểm thử
hiệu năng nhƣ trên giúp đội phát triển xác định nhanh chóng và rõ ràng các yêu cầu
về đặc tính hiệu năng của hệ thống.
Với bài toán dạng 1, khi phân tích yêu cầu, đội phát triển phải dựa vào điều kiện
thực tế khi vận hành sản phẩm để cụ thể hóa các yêu cầu. Chẳng hạn, công ty
chứng khoán A muốn xây dựng một trang Web giống nhƣ một sàn giao dịch trực
tuyến. Hiện tại công ty họ có 15000 khách hàng. Khi mô tả yêu cầu về hiệu năng
của mình, họ nói muốn trang Web hoạt động bình thƣờng với 15000 tài khoản truy
22
cập cùng một lúc. Rõ ràng, với yêu cầu này, đội phát triển phải khảo sát đƣợc thực
trạng hạ tầng công nghệ thông tin của công ty A nhƣ máy chủ, cơ sở dữ liệu, hệ
thống mạng, v.v. Từ đó, đƣa ra các yêu cầu kiểm thử hiệu năng chính xác nhất.
Với dạng bài toán thứ hai, đội phát triển phải khoanh vùng đƣợc vấn đề, tìm ra
nguyên nhân có khả năng ảnh hƣởng đến hiệu năng của trang Web, sau đó đƣa ra
các yêu cầu kiểm thử hiệu năng chi tiết.
3.3 Quy trình thực hiện kiểm thử hiệu năng
Kiểm thử hiệu năng là một loại kiểm thử phi chức năng. Các yêu cầu thƣờng rất
cụ thể. Quy trình thực hiện kiểm thử hiệu năng cũng tuân theo quy trình kiểm thử
nói chung. Dựa vào quy trình kiểm thử cơ bản của [9], chƣơng 1, mục 1.4, ta có thể
áp dụng cho bài toán kiểm thử hiệu năng, thực hiện kiểm thử hiệu năng gồm các
hoạt động nhƣ sau:
Lập kế hoạch và kiểm soát kiểm thử
Phân tích và thiết kế kiểm thử
Triển khai và thực thi kiểm thử
Đánh giá các kết quả đầu ra và báo cáo
Các hoạt động kết thúc kiểm thử
Hình 3.5 mô tả trình tự các hoạt động trong kiểm thử hiệu năng. Trong đó, hoạt
động kiểm soát và điều chỉnh kiểm thử nằm trong hoạt động lập kế hoạch nhƣng
đƣợc kéo dài từ lúc bắt đầu đến khi kết thúc kiểm thử hiệu năng. Điều này cho thấy,
việc lập kế hoạch luôn phải gắn liền với việc kiểm soát các hoạt động. Trong quá
trình thực hiện kiểm thử hiệu năng, các vấn đề phát sinh sẽ đƣợc xem xét, đánh giá
và điều chỉnh cho phù hợp.
Lập kế hoạch
Phân tích và
thiết kế
Triển khai và Đánh giá kết
thực thi
quả và báo cáo
Kiểm soát và điều chỉnh
Hình 3.5. Các hoạt động kiểm thử hiệu năng
Kết thúc
23
3.3.1 Lập kế hoạch và kiểm soát kiểm thử
Trong giai đoạn này, chúng ta phải đảm bảo chúng ta hiểu đƣợc mục đích của
việc kiểm thử hiệu năng, mong muốn của khách hàng và các bên liên quan cũng
nhƣ dự đoán các rủi ro của quá trình thực hiện kiểm thử.
Lập kế hoạch kiểm thử :
Tài liệu đầu vào và đầu ra của giai đoạn này đƣợc thể hiện trong bảng 3.6.
Bảng 3.6. Tài liệu đầu vào và đầu ra của giai đoạn lập kế hoạch
Tài liệu đầu vào
Bản đặc tả yêu cầu dự án
Tài liệu đầu ra
Bản kế hoạch kiểm thử hiệu năng
Bản kế hoạch tổng thể của dự án
Dựa vào bản đặc tả yêu cầu của dự án, trong đó có đặc tả yêu cầu phi chức năng
– yêu cầu về kiểm thử hiệu năng và bản kế hoạch tổng thể của dự án, đội kiểm thử
sẽ tham gia vào lập kế hoạch kiểm thử hiệu năng. Bản kế hoạch này sau đó sẽ đƣợc
xem xét đánh giá và đồng thuận của các bên liên quan. Các hoạt động bao gồm:
Xác định phạm vi, rủi ro và mục tiêu của việc kiểm thử hiệu năng. Chẳng
hạn nhƣ, kiểm thử hiệu năng toàn bộ trang Web hay một phần nào đó của
trang, thời gian cho kiểm thử hiệu năng là bao lâu, các rủi ro là gì và mục
tiêu của việc kiểm thử hiệu năng liên quan đến yêu cầu khách hàng, chất
lƣợng của trang Web, v.v.
Xác định các phƣơng pháp kiểm thử. Việc xác định phƣơng pháp kiểm thử
hiệu năng nhằm xác định xem việc kiểm thử hiệu năng đƣợc tiến hành nhƣ
thế nào. Nó bao gồm xác định loại kiểm thử hiệu năng sẽ đƣợc sử dụng
(Kiểm thử áp lực, kiểm thử tải, v.v.), công cụ sử dụng (công cụ mã nguồn
mở hay công cụ tính phí), v.v.
Xác định các tài nguyên kiểm thử (con ngƣời, môi trƣờng, thời gian, v.v.). Ở
giai đoạn lập kế hoạch, việc xác định các nguồn lực cho kiểm thử hiệu năng
rất quan trọng. Tùy vào mục tiêu của dự án, mục tiêu và phƣơng pháp kiểm
