Nghiên cứu và ứng dụng công cụ kiểm thử tự động Jmeter vào kiểm thử hiệu năng Website Kiểm thử phần mềmHiện nay, Internet đã trở thành một phần không thể thiếu trong cuộc sống với hàng tỉ website cung cấp các dịch vụ thiết yếu như tìm kiếm thông tin, giải trí, học tập, mua bán hàng hóa,… Bên cạnh những yếu tố ảnh hưởng tới chất lượng website như giao diện, khả năng tương thích, chức năng của ứng dụng web và bảo mật thì yếu tố hiệu năng là một trong những vấn đề rất quan trọng để đánh giá hệ thống và khả năng mở rộng của web.Việc xác định số người dùng tối đa, sức tải công việc cũng như thời gian xử lý các thao tác của các ứng dụng web là rất quan trọng trong quá trình xây dựng và phát triển web. Kiểm thử hiệu năng nhằm xác định tốc độ, khả năng phân tải và mức độ tin tưởng của ứng dụng trong môi trường nhiều người dùng, có nhiều hoạt động khác nhau. Công cụ kiểm tra tự động để kiểm tra hiệu năng ứng dụng web ở điều kiện có sự điều chỉnh về mức độ tải có thể kể đến như: LoadRunner, Jmeter Apache, LoadStorm, Pylot, The Grinder,… tuy nhiên, với khả năng chạy trên nhiều hệ điều hành, hỗ trợ đa giao thức và hoàn toàn miễn phí nên Jmeter được xem là nổi trội hơn.
Trang 1MỤC LỤC
MỤC LỤC 1
DANH MỤC CÁC HÌNH VẼ 4
DANH MỤC CÁC BẢNG BIỂU 5
THÔNG TIN KẾT QUẢ NGHIÊN CỨU 6
MỞ ĐẦU 8
LỜI CẢM ƠN 9
CHƯƠNG 1: TỔNG QUAN VỀ CHẤT LƯỢNG PHẦN MỀM VÀ KIỂM THỬ PHẦN MỀM 10
1.1 Chất lượng phần mềm 10
1.1.1 Định nghĩa chất lượng phần mềm 10
1.1.2 Định nghĩa đảm bảo chất lượng phần mềm 10
1.2 Lỗi phần mềm 11
1.2.1 Định nghĩa lỗi phần mềm và phân loại lỗi phần mềm [10] 11
1.2.2 Các nguyên nhân gây lỗi phần mềm [4] 11
1.2.3 Chi phí cho việc sửa lỗi phần mềm 13
1.2.4 Quy trình xử lý lỗi phần mềm [10] 13
1.3 Kiểm thử phần mềm 14
1.3.1 Khái niệm Kiểm thử phần mềm 14
1.3.2 Lý do cần kiểm thử phần mềm 14
1.3.3 Mục tiêu của Kiểm thử phần mềm 14
1.3.4 Các nguyên tắc cơ bản của Kiểm thử phần mềm [7] 15
1.4 Các phương pháp kiểm thử phần mềm 16
1.4.1 Kiểm thử tĩnh – Static testing [5] 16
1.4.2 Kiểm thử động – Dynamic testing [5] 16
1.5 Các kỹ thuật cơ bản của kiểm thử phần mềm [4] 17
1.5.1 Kiểm thử hộp đen (Black Box Testing – BBT) 17
1.5.2 Kiểm thử hộp trắng (White Box Testing – WBT) 21
Trang 21.6 Quy trình kiểm thử phần mềm [4] 25
1.6.1 Các bước trong một quy trình kiểm thử phần mềm 25
1.6.2 Mô hình phát triển và kiểm thử phần mềm hình chữ V 27
1.6.3 Quy trình xây dựng kế hoạch kiểm thử 28
CHƯƠNG 2: KIỂM THỬ TỰ ĐỘNG VÀ KIỂM THỬ HIỆU NĂNG 30
2.1 Kiểm thử tự động (Automate Testing) [7] 30
2.1.1 Tổng quan về kiểm thử tự động 30
2.1.2 Lý do cần phải kiểm thử tự động [7] 31
2.1.3 Ưu điểm và nhược điểm của kiểm thử tự động [7] 31
2.1.4 Các trường hợp nên áp dụng kiểm thử tự động [7] 31
2.1.5 So sánh Kiểm thử tự động với Kiểm thử thủ công 32
2.1.6 Quy trình kiểm thử tự động [4] 33
2.2 Kiểm thử hiệu năng 38
2.2.1 Khái niệm về kiểm thử hiệu năng [7] 38
2.2.2 Các tiêu chí của kiểm thử hiệu năng [9] 38
2.2.3 Các yếu tố ảnh hưởng đến kiểm thử hiệu năng [9] 39
2.2.4 Quy trình kiểm thử hiệu năng [9] 40
CHƯƠNG 3: NGHIÊN CỨU CÔNG CỤ KIỂM THỬ HIỆU NĂNG JMETER 43
3.1 Giới thiệu chung về JMeter [8] 43
3.2 Đặc trưng của Jmeter [8] 44
3.3 Download Jmeter 45
3.4 Các thành phần chính của Jmeter [2][6] 45
3.4.1 Test Plan 45
3.4.2 Các thành phần của Test Plan [3] 50
3.4.3 Thứ tự thực hiện của một test plan 52
3.5 Webservice 53
3.6 JDBC REQUEST [2][6] 56
3.7 FTP REQUEST [2] 61
CHƯƠNG 4: ỨNG DỤNG CÔNG CỤ JMETER VÀO KIỂM THỬ HIỆU NĂNG HỆ THỐNG QUẢN TRỊ TÀI LIỆU DOCPRO 63
Trang 34.1 Giới thiệu về Hệ thống quản trị tài liệu Docpro 63
4.1.1 Hệ thống quản trị tài liệu Docpro là gì ? 63
4.1.2 Các tính năng chính của hệ thống quản trị tài liệu Docpro 64
4.2 Mô tả nghiệp vụ 65
4.2.1 Nghiệp vụ: Xuất file excel 65
4.2.2 Nghiệp vụ: Tìm kiếm tài liệu theo số ký hiệu 65
4.2.3 Nghiệp vụ: Thống kê kho tài liệu theo năm 66
4.2.4 Nghiệp vụ: Tải tài liệu lên 67
4.3 Lập kế hoạch kiểm thử 67
4.3.1 Mục tiêu kiểm thử 67
4.3.2 Môi trường kiểm thử 68
4.3.3 Kịch bản kiểm thử 69
4.3.4 Phương pháp kiểm thử 72
4.4 Thực hiện cấu hình và chạy trên Jmeter 72
4.4.1 Cấu hình 72
4.4.2 Chạy để lấy kết quả 74
4.3 Phân tích, báo cáo, đánh giá kết quả kiểm thử 75
4.3.1 Phân tích 75
4.3.2 Kết quả báo cáo kiểm thử hiệu năng 76
4.3.1 Đánh giá, kết luận 84
KẾT LUẬN 86
5.1 Kết quả đạt được và hạn chế 86
5.2 Hướng phát triển 86
TÀI LIỆU THAM KHẢO 87
DANH MỤC CÁC HÌNH VẼ Hình 1-1 Kiểm thử hộp đen 17
Hình 1-2 Bao phủ điều kiện trong kiểm thử hộp trắng 23
Hình 1-3 Bao phủ nhánh trong kiểm thử hộp trắng 23
Trang 4Hình 1-4 Quy trình kiểm thử phần mềm 27
Hình 1-5 Mô hình phát triển và kiểm thử phần mềm hình chữ V 27
Hình 2-1 Quy trình kiểm thử tự động 33
Hình 2-2 Bản kế hoạch chính và các bản kế hoạch chi tiết 34
Hình 2-3 Thời điểm phù hợp để thiết lập các kế hoạch kiểm tra 35
Hình 3-1 Mô phỏng tải trọng lớn trong Jmeter 44
Hình 3-2 Download Apache Jmeter 45
Hình 3-3 Mở file chạy tool Jmeter 46
Hình 3-4 Giao diện của Jmeter 46
Hình 3-5 Chọn template 47
Hình 3-6 Đặt tên các bước 47
Hình 3-7 Thêm các Listener 48
Hình 3-8 Chỉnh sửa HTTP Proxy Server 49
Hình 3-9 Lưu kế hoạch kiểm thử 49
Hình 3-10 Thực hiện chạy Test Plan 50
Hình 4-1 Mô hình quản lý văn bản tài liệu và điều hành Docpro 63
Hình 4-2 Tính năng của hệ thống quản trị tài liệu và điều hành Docpro 64
Hình 4-3 Ghi script 73
Hình 4-4 Đặt Assertion, Timer, Listener 74
Hình 4-5 Cấu hình và chạy lấy kết quả 75
Hình 4-6 Thông tin trả về 76
DANH MỤC CÁC BẢNG BIỂU Bảng 4-1 Môi trường máy chịu tải 67
Bảng 4-2 Môi trường máy đẩy tải 67
Bảng 4-3 Kịch bản kiểm thử 68
Bảng 4-4 Báo cáo kết quả 76
Trang 5THÔNG TIN KẾT QUẢ NGHIÊN CỨU
1 Thông tin chung
Tên đề tài: Nghiên cứu và ứng dụng công cụ kiểm thử tự động Jmeter
vào kiểm thử hiệu năng Website
Sinh viên thực hiện: Nguyễn Thị Q
Mục tiêu chính của đề tài là:
- Nghiên cứu giai đoạn nào cần áp dụng công cụ kiểm thử tự động, các yếu tốnào cần kiểm thử hiệu năng
- Hiểu rõ về các thành phần của bộ công cụ Jmeter
- Ứng dụng các kiến thức kiểm thử phần mềm và kiến thức về Jmeter để viếtkịch bản kiểm thử cho một ứng dụng cụ thể
3 Nội dung chính
Đồ án được chia thành 4 phần như sau:
Trang 6Chương 1: Tổng quan về chất lượng phần mềm và kiểm thử phần mềm:
Chương này trình bày những kiến thức cơ bản về chất lượng phần mềm, kiểm thửphần mềm như các nguyên tắc kiểm thử, các phương pháp kiểm thử, các giai đoạnkiểm thử phần mềm
Chương 2: Kiểm thử tự động và kiểm thử hiệu năng: Trình bày các khái
niệm, quy trình, ưu nhược điểm của kiểm thử tự động và kiểm thử hiệu năng
Chương 3: Nghiên cứu công cụ kiểm thử hiệu năng Jmeter: Chương này
trình bày tổng quan về công cụ Jmeter, cách cài đặt, sử dụng Jmeter, tạo một test
plan, các thành phần trong jmeter, khái niệm về webservice, tạo test planwebservice, tạo test plan cho JDBC
Chương 4: Ứng dụng công cụ Jmeter vào kiểm thử hiệu năng hệ thống quản trị tài liệu Docpro: giới thiệu hệ thống quản trị tài liệu Docpro, các chức năng
chính của hệ thống, mô tả nghiệp vụ, lập kế hoạch kiểm thử, thực hiện cấu hình vàchạy Jmeter, phân tích báo cáo đánh giá kết quả
Tìm hiểu công cụ kiểm thử Jmeter và áp dụng nó vào việc kiểm thử hiệunăng cho website
Trang 7 Chưa sử dụng công cụ kiểm thử Jmeter một cách triệt để.
Trong quá trình chạy phần mềm, chất lượng mạng còn kém và không ổnđịnh nên kết quả test chỉ mang tính tương đối
MỞ ĐẦU
1 Lý do chọn đề tài
Hiện nay, Internet đã trở thành một phần không thể thiếu trong cuộc sống vớihàng tỉ website cung cấp các dịch vụ thiết yếu như tìm kiếm thông tin, giải trí, họctập, mua bán hàng hóa,… Bên cạnh những yếu tố ảnh hưởng tới chất lượng websitenhư giao diện, khả năng tương thích, chức năng của ứng dụng web và bảo mật thìyếu tố hiệu năng là một trong những vấn đề rất quan trọng để đánh giá hệ thống vàkhả năng mở rộng của web
Việc xác định số người dùng tối đa, sức tải công việc cũng như thời gian xử lýcác thao tác của các ứng dụng web là rất quan trọng trong quá trình xây dựng vàphát triển web Kiểm thử hiệu năng nhằm xác định tốc độ, khả năng phân tải vàmức độ tin tưởng của ứng dụng trong môi trường nhiều người dùng, có nhiều hoạtđộng khác nhau Công cụ kiểm tra tự động để kiểm tra hiệu năng ứng dụng web ởđiều kiện có sự điều chỉnh về mức độ tải có thể kể đến như: LoadRunner, JmeterApache, LoadStorm, Pylot, The Grinder,… tuy nhiên, với khả năng chạy trên nhiều
hệ điều hành, hỗ trợ đa giao thức và hoàn toàn miễn phí nên Jmeter được xem là nổitrội hơn
Vì vậy, xuất phát từ nhu cầu thực tiễn, em chọn đề tài đồ án tốt nghiệp là :
“Nghiên cứu và ứng dụng công cụ kiểm thử tự động Jmeter vào kiểm thử hiệu năng Website”
2 Ý nghĩa lý luận thực tiễn
Trang 8Phần nghiên cứu lý thuyết sẽ cung cấp một cách nhìn tổng quát về quá trìnhkiểm thử phần mềm và kiểm thử hiệu năng.
Đề tài đã ứng dụng những kiến thức đã học trong công nghệ phần mềm, kiểmthử phần mềm góp phần nghiên cứu hiệu năng của các ứng dụng web ở môi trường
có những hoạt động với số lượng người dùng lớn
Trang 9LỜI CẢM ƠN
Trong quá trình thực hiện đề tài, em đã nhận được sự giúp đỡ và chỉ bảo tận
tình của thầy giáo hướng dẫn TS.Lê Hồng Anh Em xin chân thành cảm ơn thầy đã
giúp em hoàn thành đồ án tốt nghiệp này
Mặc dù đã cố gắng hoàn thiện đề tài nhưng trong quá trình thực hiện có thể cònnhiều thiếu sót mong quý thầy cô tận tình chỉ bảo Em xin chân thành cảm ơn!
Hà Nội, ngày 12 tháng 6 năm 2017
Sinh viên thực hiện
Nguyễn Thị Q
Trang 10CHƯƠNG 1: TỔNG QUAN VỀ CHẤT LƯỢNG PHẦN MỀM VÀ
KIỂM THỬ PHẦN MỀM
1.1 Chất lượng phần mềm
1.1.1 Định nghĩa chất lượng phần mềm
Có rất nhiều định nghĩa về chất lượng phần mềm được đưa ra bởi các tổ chức,
cá nhân khác nhau Trong phạm vi của đồ án này trình bày một số định nghĩa tiêubiểu
Định nghĩa theo IEEE (1991)[10]:
Định nghĩa theo Pressman[10]: Chất lượng phần mềm là sự phù hợp của
các yêu cầu cụ thể về hiệu năng và chức năng, các tiêu chuẩn phát triển phầnmềm được ghi lại rõ dàng bằng tài liệu với các đặc tính ngầm định của tất cảcác phần mềm được phát triển chuyên nghiệp
1.1.2 Định nghĩa đảm bảo chất lượng phần mềm
Định nghĩa theo Daniel Galin[10]: Đảm bảo chất lượng phần mềm (Soft are
QualityAssure) là một tập hợp các hành động cần thiết được lên kế hoạch một cách
hệ thống để cung cấp đầy đủ niềm tin rằng quá trình phát triển phần mềm phù hợp
Trang 11để thành lập các yêu cầu chức năng kỹ thuật cũng như các yêu cầu quản lý theo lịchtrình và hoạt động trong giới hạn ngân sách.
1.2 Lỗi phần mềm
1.2.1 Định nghĩa lỗi phần mềm và phân loại lỗi phần mềm [10]
- Định nghĩa lỗi phần mềm: Có rất nhiều định nghĩa về lỗi phần mềmnhưng có thể hiểu và phát biểu một cách đơn giản thì "Lỗi phần mềm là
sự không khớp giữa chương trình và đặc tả của nó"
- Dựa vào định nghĩa, ta có thể phân loại lỗi phần mềm thành 3 dạng:
+ Lỗi sai: Sản phẩm phần mềm được xây dựng khác với đặc tả
+ Lỗi thiếu: Các yêu cầu của sản phẩm phần mềm đã có trong đặc tảnhưng lại không có trong sản phẩm thực tế
+ Lỗi thừa: Sản phẩm thực tế có những tính năng không có trong tài liệuđặc tả
1.2.2 Các nguyên nhân gây lỗi phần mềm [4]
Lỗi phần mềm có thể đến từ nhiều nguyên nhân khác nhau, trong đó có cảcác nguyên nhân chủ quan và các nguyên nhân khách quan Dưới đây là chínnguyên nhân chủ yếu gây ra lỗi phần mềm:
Định nghĩa các yêu cầu bị lỗi: Những lỗi trong việc xác định yêu cầuthường nằm ở phía khách hàng
Các lỗi trong giao tiếp giữa khách hàng và nhà phát triển: Những lỗi này
Trang 12hiểu sai chỉ dẫn trong tài liệu yêu cầu, hiểu sai thay đổi khi khách hàngtrình bày bằng lời nói và tài liệu, hiểu sai về phản hồi và thiếu quan tâmđến những đề cập của khách hàng.
Giải pháp khắc phục: Cần có ủy ban liên kết giữa khách hàng và
nhà cung cấp để tránh lỗi trong giao tiếp Ủy ban do quản trị dự ánđứng đầu và khách hàng phải giới thiệu những người hiểu về mặtnghiệp vụ vào ủy ban đó
Sai lệch có chủ ý với các yêu cầu phần mềm: Trong một số trường hợpcác nhà phát triển cố tình làm sai lệnh các yêu cầu trong tài liệu đặc tả.Nguyên nhân của việc này đến từ các áp lực thời gian, ngân sách, hay cốtình sử dụng lại các mô-đun từ các dự án trước mà chưa phân tích đầy đủnhững thay đổi để thích nghi với các yêu cầu mới
Giải pháp khắc phục: Dựa trên những thống kê để quyết định xem
giải pháp như thế nào, sắp xếp ưu tiên xem bỏ được yêu cầu nào hay
sử dụng lại được mô-đun nào
Các lỗi thiết kế logic: Lỗi phần mềm xảy ra trong quá trình các chuyêngia thiết kế hệ thống, các kiến trúc sư hệ thống, kỹ sư phần mềm, các nhàphân tích xây dựng phần mềm theo yêu cầu Các lỗi điển hình bao gồm:+ Định nghĩa các yêu cầu phần mềm bằng các thuật toán sai
+ Quy trình định nghĩa có chứa trình tự lỗi
+ Sai sót trong các định nghĩa biên như > 3 hay ≥ 3
Trang 13+ Thiếu sót các trạng thái hệ thống phần mềm được yêu cầu.
+ Các lỗi lập trình: Có rất nhiều lý do dẫn đến việc các lập trình viêngây ra các lỗi lập trình Những lý do này bao gồm: Sự hiểu sai cáctài liệu thiết kế, ngôn ngữ; sai sót trong ngôn ngữ lập trình; sai sóttrong việc áp dụng các công cụ phát triển; sai sót trong lựa chọn dữliệu
+ Không tuân thủ theo các tài liệu hướng dẫn và tiêu chuẩn lập trình:Các lỗi phần mềm có thể đến từ việc không tuân thủ các tài liệu vàtiêu chuẩn lập trình của các tổ chức phát triển phần mềm
+ Thiếu sót trong quá trình kiểm thử: Lỗi phần mềm có thể đến từchính quá trình kiểm thử khi mà người kiểm thử để lọt lỗi
Những lỗi này đến từ các nguyên nhân sau đây:
+ Kế hoạch kiểm thử chưa hoàn chỉnh, để sót yêu cầu cần kiểm thử.+ Lỗi trong tài liệu và báo cáo kiểm thử
+ Việc sửa chữa các lỗi được phát hiện không hoàn chỉnh do áp lựcthời gian hay do thiếu cẩn thận
Giải pháp khắc phục: Lên kế hoạch kiểm thử cụ thể tại giai đoạn đầu
của dự án
Trang 14 Các lỗi thủ tục: Các thủ tục hướng dẫn cho người sử dụng tại từng bước củatiến trình Chúng có tầm quan trọng đặc biệt trong các hệ thống phần mềmphức tạp mà các tiến trình được thực bằng nhiều bước, mỗi bước có thể cónhiều kiểu dữ liệu và cho phép kiểm tra các kết quả trung gian Các lỗi có thểđến từ việc viết các thủ tục.
Các lỗi về tài liệu: Các lỗi về tài liệu là vấn đề của các đội phát triển và bảotrì khi có nhữ ng sai sót trong các tài liệu liên quan Những lỗi này có thể lànguyên nhân gây ra lỗi trong giai đoạn phát triển kế tiếp và giai đoạn bảo trì
1.2.3 Chi phí cho việc sửa lỗi phần mềm
Việc kiểm thử và sửa lỗi phần mềm có thể thực hiện trong bất cứ giai đoạnnào của vòng đời phần mềm.Tuy nhiên công việc này nên được thực hiện càng sớmcàng tốt vì càng về giai đoạn sau của vòng đời phần mềm, chi phí cho việc tìm vàsửa lỗi càng tăng, đặc biệt là đến giai đoạn đã triển khai phần mềm thì chi phí chosửa lỗi sẽ trở nên rất lớn và ảnh hưởng trực tiếp đến uy tín của tổ chức phát triểnphần mềm
1.2.4 Quy trình xử lý lỗi phần mềm [10]
Quy trình xử lý lỗi có thể bao gồm 6 bước chính:
Bước 0_Bắt đầu: Phát hiện phần mềm có lỗi
Bước 1_Đưa lỗi lên hệ thống quản lý lỗi
Bước 2_Gán lỗi cho nhân viên phát triển
Bước 3_Xử lý lỗi
Bước 4_Kiểm thử lại
Bước 5_Đóng lỗi
Trang 151.3 Kiểm thử phần mềm
1.3.1 Khái niệm Kiểm thử phần mềm
Kiểm thử phần mềm là quy trình được sử dụng để đánh giá, kiểm tra chấtlượng phần mềm ở nhiều khía cạnh khác nhau dựa trên các yêu cầu của người sửdụng đối với sản phẩm phần mềm, nhằm đảm bảo phần mềm hoạt động tốt trongcác môi trường, các trường hợp khác nhau
Có thể định nghĩa một cách dễ hiểu như sau [5]:
Kiểm thử phần mềm là một tiến trình hay một tập hợp các tiến trình được thiết kế để đảm bảo mã hóa máy tính thực hiện theo cái mà chúng đã được thiết kế
để làm, và không thực hiện bất cứ thứ gì không mong muốn Đây là một pha quan trọng trong quá trình phát triển hệ thống, giúp cho người xây dựng hệ thống và khách hàng thấy được hệ thống mới đã đáp ứng yêu cầu đặt ra hay chưa?
1.3.2 Lý do cần kiểm thử phần mềm
+ Phần mềm nào cũng có lỗi bởi vì nó do con người làm ra
+ Kiểm thử độ tin cậy của phần mềm
+ Các lỗi đang dùng trong thực tế có thể rất tốn chi phí cũng như gây nguyhiểm đến con người
+ Tránh kiện tụng của khách hàng
+ Phát triển doanh nghiệp
+ Lỗi phát hiện càng sớm thì chi phí khắc phục càng nhỏ
Trang 161.3.3 Mục tiêu của Kiểm thử phần mềm
- Phát hiện và xác định càng nhiều lỗi càng tốt ở các phần mềm được kiểmthử
- Tiến hành sửa lỗi ở các phần mềm được kiểm thử và kiểm thử lại cho đếnkhi đạt một mức độ chất lượng phần mềm chấp nhận được
- Thực thi những trường hợp kiểm thử một cách hiệu quả trong một giớihạn ngân sách và lịch trình cho phép
1.3.4 Các nguyên tắc cơ bản của Kiểm thử phần mềm [7]
Có 7 nguyên tắc cơ bản cần chú ý khi kiểm thử phần mềm, các nguyên tắc đó là:
- Kiểm thử để chứng minh sự có mặt của lỗi và không chứng minh điềungược lại: Kiểm thử có thể cho thấy sự có mặt của lỗi nhưng không thểchứng minh điều ngược lại là chương trình không có lỗi Việc kiểm thửgiảm nguy cơ không tìm thấy lỗi trong phần mềm nhưng ngay cả khikhông tìm thấy lỗi thì cũng không thể chứng minh được sản phẩm phầnmềm được phát triển hoàn toàn chính xác
- Không thể kiểm thử vét cạn: Việc kiểm thử không thể thực hiện được chotất mọi trường hợp kiểm thử Do vậy thay vì kiểm thử mọi khía cạnh, taphải tập trung vào kiểm thử nhữ ng yếu tố quan trọng và nhiều rủi do
- Kiểm thử sớm: Các hoạt động kiểm thử nên bắt đầu càng sớm càng tốttrong vòng đời phát triển phần mềm, và nên tập trung và những mục tiêukiểm thử nhất định
Trang 17- Phân cụm lỗi: Một số lượng nhỏ các mô-đun phần mềm có thể chứa hầuhết các lỗi được phát hiện ra trong suốt quá trình kiểm thử hoặc tập trunghầu hết các lỗi vận hành.
- Kiểm thử ngược: Nếu một phương pháp kiểm thử được lặp đi lặp lạinhiều lần, các trường hợp kiểm thử giống nhau sẽ không phát hiện đượctriệt để lỗi mới Để khắc phục điều này ta có thể sử dụng nguyên tắc
"kiểm thử ngược", các trường hợp kiểm thử cần phải được xem xét vàduyệt lại một cách đều đặn, và việc kiểm thử mới cần phải được viết lại
để thực thi nhữ ng phần khác của phần mềm hay hệ thống để tìm ra nhữ
1.4 Các phương pháp kiểm thử phần mềm
Có rất nhiều phương pháp để kiểm thử phần mềm Đánh giá, định hướng hoặckiểm tra được gọi là kiểm thử tĩnh, trong khi việc chạy mã lập trình thực tế trongcác tình huống được gọi là kiểm thử động Kiểm thử tĩnh thông thường có thể được
bỏ qua khi thực hành nhưng kiểm thử động diễn ra khi bản thân chương trình đóđang được sử dụng
1.4.1 Kiểm thử tĩnh – Static testing [5]
Là phương pháp kiểm thử phần mềm đòi hỏi phải duyệt lại các yêu cầu và
Trang 18tiết mà không cần chạy chương trình Kiểu kiểm thử này thường được sử dụng bởichuyên viên thiết kế người mà viết mã lệnh một mình.
Kiểm thử tĩnh cũng có thể được tự động hóa Nó sẽ thực hiện kiểm tra toàn
bộ bao gồm các chương trình được phân tích bởi một trình thông dịch hoặc biêndịch mà xác nhận tính hợp lệ về cú pháp của chương trình
1.4.2 Kiểm thử động – Dynamic testing [5]
Là phương pháp kiểm thử phần mềm thông qua việc dùng máy chạy chươngtrình để điều tra trạng thái tác động của chương trình Đó là kiểm thử dựa trên các
ca kiểm thử xác định bằng sự thực hiện của đối tượng kiểm thử hay chạy cácchương trình Kiểm thử động kiểm tra cách thức hoạt động động của mã lệnh, tức làkiểm tra sự phản ứng vật lý từ hệ thống tới các biến luôn thay đổi theo thời gian.Trong kiểm thử động, phần mềm phải thực sự được biên dịch và chạy Kiểm thửđộng thực sự bao gồm làm việc với phần mềm, nhập các giá trị đầu vào và kiểm traxem liệu đầu ra có như mong muốn hay không
Kiểm thử động có thể bắt đầu trước khi chương trình đã hoàn tất 100% đểkiểm thử các phần cụ thể của mã và được áp dụng cho các chức năng riêng biệthoặc Module Kỹ thuật điển hình cho điều này được sử dụng trong cả mạchnhánh/trình điều khiển hoặc được thực hiện trong một môi trường gỡ lỗi nhất định
1.5 Các kỹ thuật cơ bản của kiểm thử phần mềm [4]
1.5.1 Kiểm thử hộp đen (Black Box Testing – BBT)
Định nghĩa
Kiểm thử hộp đen hay còn gọi là kiểm tra chức năng và thử nghiệm hành vi.Xem chương trình như là một “hộp đen”, hoàn toàn không quan tâm về cách cư xử
Trang 19và cấu trúc bên trong của chương trình Thay vào đó, tập trung vào tìm các trườnghợp mà chương trình không thực hiện theo đặc tả của nó.
Hình 1-1 Kiểm thử hộp đen
Phương pháp này được đặt tên như vậy bởi vì các chương trình phần mềm,trong con mắt của các tester, giống như một hộp đen; bên trong mà người ta khôngthể nhìn thấy Phương pháp này cố gắng tìm ra các lỗi trong các loại sau:
Chức năng không chính xác hoặc thiếu
Lỗi giao diện
Lỗi trong cấu trúc dữ liệu hoặc truy cập cơ sở dữ liệu bên ngoài
Hành vi hoặc hiệu suất lỗi
Khởi tạo và chấm dứt các lỗi
Trang 20 Các phương pháp kiểm thử hộp đen
Đoán lỗi: là một kỹ năng quan trọng của tester, thậm chí có thể gọi là nghệ
thuật, một kiệt tác của trực giác Phương pháp này đặc biệt dựa vào kinh nghiệm vàkiến thức của tester Nhiều tester cố gắng đoán xem phần nào của hệ thống mà cókhả năng ẩn chứa lỗi Với phương pháp này, họ không cần một công cụ hay mộtkịch bản kiểm thử nào khi bắt đầu vào việc
Kiểm thử dựa vào đồ thị nguyên nhân - kết quả (Cause Effect Graphing):
là một kỹ thuật thiết kế kiểm thử phần mềm liên quan đến việc xác định các trườnghợp (điều kiện đầu vào) và các hiệu ứng (điều kiện đầu ra) Vì các hệ thống hiện nayđều được phát triển trên nền tảng OOP, do đó, chúng ta có thể có được một đồ thịcác đối tượng mà hệ thống định nghĩa và kết nối Từ đồ thị này, chúng ta dễ dàngbiết các mối quan hệ của những đối tượng mà hệ thống xử lý, từ đó sẽ cho chúng tacác kịch bản kiểm thử phù hợp
Phân vùng tương đương (Equivalence Class): là một kỹ thuật kiểm thử phần
mềm có liên quan đến phân chia các giá trị đầu vào thành các phân vùng hợp lệ vàkhông hợp lệ, sau đó chúng ta sẽ viết ra các kịch bản kiểm thử cho từng phần, chọngiá trị đại diện từ mỗi phân vùng làm dữ liệu thử nghiệm
- Phân vùng tương đương: là kỹ thuật thực hiện test theo từng class đồnggiá trị (tập hợp điều kiện cùng một thao tác)
- Tập hợp giá trị input có cùng một kết quả xử lý, tập hợp thời gian có cùngmột kết quả xử lý, tập hợp kết quả export được xử lý cùng một giá trị nhập
- Mục đích: Giảm đáng kể số lượng test case cần phải thiết kế vì với mỗilớp tương đương ta chỉ cần test trên các phần tử đại diện
- Chọn tối thiểu một giá trị đại diện từ các class đồng giá trị để tiến hànhtest
Trang 21Nếu có lỗi xảy ra thì các giá trị khác trong class đồng giá trị cũng sẽ cólỗi giống nhau.
Phân tích giá trị biên (Boundary Value Analysis): là một kỹ thuật kiểm thử
phần mềm có liên quan đến việc xác định biên (ranh giới) của điều kiện mô tả chocác giá trị đầu vào và chọn giá trị ở biên và bên cạnh giá trị biên làm dữ liệu kiểmthử Phương pháp phân tích giá trị biên sẽ đưa ra các giá trị đặc biệt, bao gồm loại dữliệu, giá trị lỗi, bên trong, bên ngoài biên giá trị, lớn nhất và nhỏ nhất
Test giá trị biên được thực hiện theo trình tự dưới đây:
1 Tìm ra đường biên
2 Quyết định giá trị biên
3 Quyết định giá trị để test
Giá trị biên
Dưới giá trị biên (Nếu là class đồng giá trị)
Trên 1 giá trị biên (Nếu là class đồng giá trị)
Sử dụng bảng quyết định (Decision Tables)
Là dùng bảng để hiển thị danh sách các thao tác phần mềm đượcquyết định trên các điều kiện khác nhau
Decision table testing chú trọng vào nhiều điều kiện để thực hiện test.Ngoài ra, kiểm thử hộp đen còn có một số kỹ thuật như: Domain Tests,Orthogonal Arrays, State Models, Exploratory Testing (kiểm thử chủ yếu dựa vàokinh nghiệm và khả năng focus vào việc test các chức năng của tester), All-pairstesting (kiểm thử tất cả các cặp),
Ưu nhược điểm của kiểm thử hộp đen
Ưu điểm
Trang 22- Các tester được thực hiện từ quan điểm của người dùng và sẽ giúp đỡtrong việc sáng tỏ sự chênh lệch về thông số kỹ thuật.
- Các tester theo phương pháp black box không có “mối ràng buộc” nào vớicode, và nhận thức của một tester rất đơn giản: một source code có nhiềulỗi, sử dụng nguyên tắc: "Hỏi và bạn sẽ nhận" các tester black box tìmđược nhiều bug ở nơi mà các DEV không tìm thấy
- Tester có thể không phải IT chuyên nghiệp, không cần phải biết ngôn ngữlập trình hoặc làm thế nào các phần mềm đã được thực hiện
- Các tester có thể được thực hiện bởi một cơ quan độc lập từ các developer,cho phép một cái nhìn khách quan và tránh sự phát triển thiên vị
- Hệ thống thật sự với toàn bộ yêu cầu của nó được kiểm thử chính xác
- Thiết kế kịch bản kiểm thử khá nhanh, ngay khi mà các yêu cầu chức năngđược xác định
Nhược điểm
- Dữ liệu đầu vào yêu cầu một khối lượng mẫu (sample) khá lớn
- Khó viết kịch bản kiểm thử do cần xác định tất cả các yếu tố đầu vào, vàthiếu cả thời gian cho việc tập hợp này
- Khả năng để bản thân kỹ sư lạc lối trong khi kiểm thử là khá cao
1.5.2 Kiểm thử hộp trắng (White Box Testing – WBT)
Kiểm thử hộp trắng là phương pháp kiểm nghiệm dựa vào cấu trúc/mã lệnhchương trình WBT kiểm nghiệm một chương trình (một phần chương trình, haymột hệ thống, một phần của hệ thống) đáp ứng tốt tất cả các giá trị input bao gồm cảcác giá trị không đúng hay không theo dự định của chương trình Chiến lược này
Trang 23xuất phát từ dữ liệu kiểm thử bằng sự kiểm thử tính logic của chương trình Kiểmthử viên sẽ truy cập vào cấu trúc dữ liệu và giải thuật bên trong chương trình (và cả
vị Trong lập trình hướng đối tượng, kiểm thử đơn vị là kiểm thử từng tác vụ của 1class chức năng nào đó
Có 2 hoạt động kiểm thử hộp trắng :
Kiểm thử luồng điều khiển: tập trung kiểm thử thuật giải chức năng
Kiểm thử dòng dữ liệu: tập trung kiểm thử đời sống của từng biến dữ liệuđược dùng trong thuật giải
Các phương pháp kiểm thử hộp trắng
Khi thực hiện kiểm thử bằng whitebox testing thì ta phải có một bộ test chochương trình đó Tuy nhiên để biết chắc chắn được là bộ test của chúng ta đã đầy đủcho tất cả các trường hợp hay chưa, ta sẽ áp dụng các kiến thức của coverage tesing
để đo đạc kết quả của chương trình khi thực hiện bộ kiểm thử
Coverage testing có thể hiểu là tỉ lệ (tính theo %) test case đã được thực hiệntrên tổng số test case cần thiết cho ứng dụng Nếu tỉ lệ này càng cao thì ứng dụngcàng được test kỹ Mặc dù việc đảm bảo ứng dụng có test coverage là 100% trongmột số trường hợp là bất khả thi, nhưng ta vẫn sẽ luôn cố gắng để đạt được kết quảgần với con số đó nhất
Có 3 kĩ thuật kiếm thử hộp trắng là:
Trang 24 Bao phủ câu lệnh (Statement Coverage) : Kiểm thử sao cho mỗi câu lệnhđược thực thi ít nhất 1 lần Ví dụ đoạn mã:
Public int foo(int x, int y) Int z = 0; If (x > 0 && y > 0) { z = x; } Return z; }Nếu ta gọi foo(1,1) thì dòng z = x sẽ được thực hiện, còn nếu gọi foo(0,1) thìdòng z = x sẽ không được thực hiện, lúc đó test case của ta sẽ không thỏa điều kiệnbao phủ câu lệnh
Bao phủ điều kiện (Branch Coverage, Decision coverage): Kiểm thử đòi hỏiphải đủ trường hợp thử nghiệm như vậy mà mỗi điều kiện trong một quyết định cótrên tất cả các kết quả có thể ít nhất một lần Đó là các nhánh (quyết định) lấy cả 2trường hợp đúng và sai Nó giúp trong việc chứng thực tất cả các ngành có mã đảmbảo rằng đó không có chi nhánh dẫn đến hành vi bất thường của ứng dụng Ví dụđoạn mã:
Ta có thể sinh các test case bao phủ các điều kiện của nhánh:
Hình 1-2 Bao phủ điều kiện trong kiểm thử hộp trắng
Bao phủ nhánh (Path Coverage): Trong các trường hợp kiểm thử được thựchiện trong một cách mà mọi con đường được thực hiện ít nhất một lần Tất cả cáccon đường kiểm soát có thể được thực hiện, bao gồm tất cả những con đường vònglấy bằng không, một lần, và nhiều (lý tưởng là tối đa) các trường hợp thử nghiệmđược chuẩn bị dựa trên các biện pháp phức tạp logic của một thiết kế thủ tục Để
Trang 25hoàn thiện bao phủ nhánh, chúng ta phải xét thêm 2 trường hợp bug(a) khi đúng vàkhi sai.
Hình 1-3 Bao phủ nhánh trong kiểm thử hộp trắng
Ưu nhược điểm của kiểm thử hộp trắng
Ưu điểm
- Kiểm tra được toàn bộ chương trình nguồn
- Phát hiện lỗi tại chỗ
- Tự động hóa kiểm thử
Nhược điểm
- Yêu cầu người kiểm thử phải am hiểu cấu trúc mã lệnh chương trình
Do dó đòi hỏi tài nguyên nhân lực và máy tốn kém
- Có khả năng tồn tại các tổ hợp lệnh khác nhau gây lỗi
- Không kiểm thử hết đường đi với các vòng lặp lớn, phức tạp
- Khó thực hiện và chi phí thực hiện cao
Trang 261.5.3 Kiểm thử hộp xám (Gray Box Testing – GBT)
Kiểm thử hộp xám là một phương pháp kiểm thử phần mềm được kết hợpgiữa kiểm thử hộp đen và kiểm thử hộp trắng Trong kiểm thử hộp đen, tester kiểmthử các hàng mục mà không cần biết cấu trúc bên trong của nó, còn trong kiểm thửhộp trắng thì tester biết được cấu trúc bên trong của chương trình Trong kiểm thửhộp xám, cấu trúc bên trong sản phẩm chỉ được biết một phần Tester có thể truycập vào cấu trúc dữ liệu bên trong và thuật toán của chương trình với mục đích là đểthiết kế test case, nhưng khi test thì test như là người dùng cuối hoặc mức hộp đen.Được gọi là kiếm thử hộp xám vì trong chương trình phần mềm, mắt của testergiống như hộp xám/bán trong suốt – nhìn qua hộp này ta chỉ có thể thấy được mộtphần
Mặc dù phương pháp kiểm thử hộp xám có thể ứng dụng vào nhiều mức testkhác nhau nhưng chủ yếu nó hữu dụng trong mức Intergration Testing – kiểm thửtích hợp
Ưu nhược điểm của kiểm thử hộp xám
Ưu điểm và nhược điểm của Kiểm thử hộp xám được quyết định dựa vào sự kếthợp các ưu nhược điểm của kiểm thử hộp đen và hộp trắng
Trang 271.6 Quy trình kiểm thử phần mềm [4]
1.6.1 Các bước trong một quy trình kiểm thử phần mềm
Thuật ngữ: Software Test Process là 1 chuỗi các hoạt động, phương thứcthực hiện mà con người phải làm để thực hiện kiểm thử cho hệ thống phần mềm Quy trình kiểm thử phần mềm bao gồm các bước :
Lập kế hoạch kiểm tra
Phân tích, thiết kế test case
Phát triển test script
Trang 28- Nguồn lực kiểm thử
- Tài nguyên môi trường kiểm thử, bao gồm các tài nguyên phầncứng và phần mềm
- Mốc bàn giao các tài liệu kiểm thử
- 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ạchKTPM bao gồm nhiều chi tiết từ các loại kiểm tra, chiến lượckiểm tra, cho đến thời gian và phân định lực lượng kiểm tra viên,xác định tiêu chí kết thúc kiểm thử
b Phân tích và thiết kế test
Nhằm chỉ định các test case và các bước kiểm tra chi tiết cho mỗi phiên PM.Giai đoạn thiết kế test là hết sức quan trọng, nó đảm bảo tất cả các tình huống kiểmtra hết tất cả các yêu cầu
Các bước thiết kế test :
- Xác định và mô tả test case
- Mô tả các bước chi tiết để kiếm tra
- Xem xét và khảo sát độ bao phủ của việc kiểm tra
Trang 29- Xem xét test case và các bước kiểm tra
c Phát triển test Script
Bước này thường không bắt buộc trong các loại và mức kiểm tra, chỉ yêu cầutrong những trường hợp đặc thù cần thiết kế, tạo ra các test script có khả năng chạytrên máy tính giúp tự động hoá việc thực thi các bước kiểm tra đã định nghĩa ở cácbước thiết kế test
Trang 30Hình 1-5 Mô hình phát triển và kiểm thử phần mềm hình chữ V
Các hoạt động hiện thực và các hoạt động kiểm thử được tách biệt nhưng độquan trọng là như nhau
Chữ V minh họa các khía cạnh của hoạt động Verification và Validation
Cần phân biệt giữa các mức độ kiểm thử ở đó mỗi mức kiểm thử là kiểm thửtrên mức phát triển phần mềm tương ứng
Mô hình phát triển tăng tiến - tương tác :
Quy trình thiết lập các yêu cầu phần mềm, thiết kế, xây dựng, kiểm thử hệthống phần mềm được thực hiện như 1 chuỗi các chu kỳ phát triển ngắn hơn
Hệ thống có được từ 1 bước lặp được kiểm thử ở nhiều cấp trong việc pháttriển hệ thống đó
Kiểm thử hồi quy có độ quan trọng tăng dần theo các bước lặp (không cầntrong bước đầu tiên)
Thanh kiểm tra và kiểm định có thể ₫ược thực hiện theo kiểu tăng dần trêntừng bước lặp
Trang 31Các tính chất của quy trình kiểm thử tốt :
Cần có 1 mức độ kiểm thử cho mỗi công đoạn phát triển phần mềm
Các mục tiêu kiểm thử sẽ bị thay đổi, mỗi mức kiểm thử nên có các mục tiêuđặc thù của mình
Việc phân tích và thiết kế testcase cho 1 mức độ kiểm thử nên bắt đầu sớmnhất như có thể có
Các tester nên xem xét các tài liệu sớm như có thể có, ngay sau khi các tàiliệu này được tạo ra trong chu kỳ phát triển phần mềm
Số lượng và cường độ của các mức kiểm thử được điều khiển theo các yêucầu đặc thù của project phần mềm đó
Sơ đồ tổ chức phổ biến của đội kiểm thử
1.6.3 Quy trình xây dựng kế hoạch kiểm thử
Sau khi xây dựng xong kế hoạch kiểm thử, ta có thể thay đổi nó nhưng phảituân thủ quy trình yêu cầu thay đổi
Các hoạt động chính trong việc xây dựng kế hoạch kiểm thử:
- Định nghĩa mục đích, phạm vi, chiến lược, cách tiếp cận, các điều kiệnchuyển, các rủi ro, kế hoạch giảm nhẹ và tiêu chí chấp thuận
- Định nghĩa cách thức thiết lập môi trường và các tài nguyên được dùngcho việc kiểm thử
Trang 32- Chuẩn bị ma trận theo dõi bao phủ mọi yêu cầu phần mềm.
- Báo cáo trạng thái kiểm thử
- Phát hành leo thang (Escalating Issues)
Trang 33CHƯƠNG 2: KIỂM THỬ TỰ ĐỘNG VÀ KIỂM THỬ HIỆU NĂNG
2.1 Kiểm thử tự động (Automate Testing) [7]
Kiểm thử đang được xem là giải pháp chủ yếu nhằm đảm bảo chấtlượng cho các sản phẩm phần mềm Tuy nhiên, các hoạt động kiểm thử hiệnnay chủ yếu được thực hiện một cách thủ công và tiêu tốn khoảng 30-50%tài nguyên (thời gian, nhân lực và chi phí) của quá trình phát triển sản phẩmphần mềm Hơn nữa, độ phức tạp của các phần mềm ngày càng tăng và
Trang 34phải áp dụng các phương pháp và công cụ nhằm tự động hóa các hoạt độngkiểm thử.
2.1.1 Tổng quan về kiểm thử tự động
Kiểm thử tự động là quá trình thực hiện một cách tự động các bước trongmột kịch bản kiểm thử Kiểm thử tự động bằng một công cụ nhằm rút ngắnthời gian kiểm thử
Mục đích của kiểm thử tự động là giảm thiểu thời gian, công sức và kinhphí, tăng độ tin cậy, tăng tính hiệu quả và giảm sự nhàm chán cho ngườikiểm thử trong quá trình kiểm thử sản phẩm phần mềm
Kiểm thử tự động sẽ được sử dụng khi dự án không đủ tài nguyên (thờigian, nhân lực và chi phí), phải thực hiện kiểm thử hồi quy khi sản phẩmđược sửa đổi hoặc nâng cấp và cần kiểm thử lại các tính năng đã thực hiệntốt trước đó, kiểm tra khả năng vận hành của sản phẩm trong các môi trườngđặc biệt (đo tốc độ xử lý trung bình ứng với mỗi yêu cầu, xác định khả năngchịu tải tối đa, xác định cấu hình tối thiểu để thực thi hệ thống, kiểm tra các
cơ chế an ninh và an toàn, )
2.1.2 Lý do cần phải kiểm thử tự động [7]
Kiểm thử phần mềm tự động với mục đích:
- Giảm bớt công sức và thời gian thực hiện quá trình kiểm thử
- Tăng độ tin cậy
- Giảm sự nhàm chán cho con người
Trang 35- Rèn luyện kỹ năng lập trình cho kiểm thử viên
- Giảm chi phí cho tổng quá trình kiểm thử
2.1.3 Ưu điểm và nhược điểm của kiểm thử tự động [7]
Ưu điểm:
- Kiểm thử chính xác và có thể bao quát thông tin
- Theo dõi được chính xác kết quả từng giai đoạn và các báo cáo tổng hợp
- Cần ít nhân lực trong quá trình kiểm thử
- Chu kỳ kiểm thử diễn ra trong thời gian ngắn
- Hiệu năng của kiểm thử các lớp vượt xa tầm với của kiểm thử thủ công
Nhược điểm:
- Chi phí cao cho việc chuyển giao công nghệ và đào tạo nhân viên
- Tốn chi phí đầu tư lớn cho việc phát triển công cụ kiểm thử tự động
- Tốn chi phí và thời gian cho việc tạo các kịch bản kiểm thử và bảo trì cáckịch bản kiểm thử
- Giai đoạn chuẩn bị kiểm thử yêu cầu nhiều nhân lực
- Khu vực kiểm thử tự động có thể không bao quát đầy đủ, không áp dụng
Trang 362.1.4 Các trường hợp nên áp dụng kiểm thử tự động [7]
Không phải lúc nào cũng nên áp dụng kiểm thử tự động trong việc kiểm thửphần mềm, vì nhiều khi chi phí và thời gian cho việc kiểm thử tự động còn lớn hơnnhiều so với kiểm thử thủ công Dưới đây là một số trường hợp nên áp dụngphương pháp kiểm thử tự động để đạt được hiệu quả cao về thời gian, chi phí cũngnhư chất lượng
Trường hợp không đủ tài nguyên: Là khi số lượng trường hợp kiểm thử lặplại quá nhiều trên nhiều môi trường kiểm thử khác nhau, không có đủ nguồnnhân lực để kiểm thử thủ công trong một giới hạn thời gian nào đó
Trường hợp kiểm thử hồi qui: Trong quá trình phát triển phần mềm, nhómlập trình thường đưa ra nhiều phiên bản phần mềm liên tiếp để kiểm thử.Thực tế cho thấy việc đưa ra các phiên bản phần mềm có thể là hàng ngày,mỗi phiên bản bao gồm những tính năng mới, hoặc tính năng cũ được sửa lỗihay nâng cấp Việc bổ sung hoặc sửa lỗi mã chương trình cho những tínhnăng ở phiên bản mới có thể làm cho những tính năng khác đã kiểm tra tốtchạy sai mặc dù phần mã chương trình của nó không hề chỉnh sửa
Trường hợp kiểm thử khả năng vận hành phần mềm trong môi trường đặc biệt
2.1.5 So sánh Kiểm thử tự động với Kiểm thử thủ công
Không phải mọi kiểm thử đều có thể thực hiện tự động và sẽ khó khăn khi lựa chọn kiểm thử theo cách nào Những điểm mạnh và điểm yếu được liệt kê dưới đây sẽ giúp chúng ta dễ dàng hơn khi lựa chọn giải pháp kiểm thử tự động hay kiểmthử thủ công
Điểm mạnh:
- Kiểm thử tự động:
Trang 37 Nếu ta phải thực hiện một loạt các kiểm tra liên tục và lặp lại thì tựđộng hóa là một lợi lớn Giúp thực hiện "kiểm tra khả năng tươngthích" - kiểm thử phần mềm trên cấu hình khác nhau.
Nó cung cấp cho chúng ta khả năng để thực hiện tự động hóa các kiểmthử hồi quy trong một thời gian ngắn
Nó cung cấp cho chúng ta khả năng để thực hiện kiểm thử hồi quy trênmột đoạn code liên tục thay đổi
Có thể chạy đồng thời trên các máy khác nhau do đó giảm thời gian kiểm thử
Giảm được chi phí dài hạn
- Kiểm thử thủ công:
Nếu các Test Cases chỉ thực hiện một số ít lần thì có nhiều khả năng đểthực hiện kiểm tra thủ công
Nó cho phép tester thực hiện việc kiểm thử khám phá
Thích hợp khi kiểm tra sản phẩm lần đầu tiên
Giảm được chi phí ngắn hạn
Điểm yếu:
- Kiểm thử tự động:
Sẽ tốn kém hơn để thực hiện kiểm thử tự động, đầu tư ban đầu nhiềuhơn kiểm thử thủ công.Chúng ta không thể tự động hóa mọi thứ, nhiềukiểm thử vẫn tiếp tục phải thực hiện thủ công
- Kiểm thử thủ công:
Kiểm thử thủ công tốn thời gian hơn
Đối với mỗi bản phát hành (release), chúng ta phải chạy lại cùng mộttập hợp các kiểm thử đã làm có thể dẫn đễn sự mệt mỏi và lãng phí
Trang 382.1.6 Quy trình kiểm thử tự động [4]
Hình 2-6 Quy trình kiểm thử tự động
Lập kế hoạch kiểm tra
- 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 thử phầnmề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
Hình 2-7 Bản kế hoạch chính và các bản kế hoạch chi tiết
- 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
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ểmtra cũng được dùng để xác định nhu cầu nhân lực
Trang 39 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ủakiểm tra viên quá yếu, 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ệnviệc kiểm tra trên phần mềm, 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 tracũ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ầncứng, phần mềm, công cụ, thiết bị giả lập cần thiết cho việc kiểm tra
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 tất cả cácđiểm mốc của quá trình kiểm tra
Tổng hợp và tạo các bản kế hoạch kiểm tra: kế hoạch chung và kế hoạchchi tiết
Xem xét các kế hoạch kiểm tra: phải có sự tham gia của tất cả nhữngngười có liên quan, kể cả trưởng dự án và có thể cả khách hàng Việc xemxét nhằm bảo đảm các kế hoạch là khả thi, cũng như để phát hiện (và sữachữa sau đó) các sai sót trong các bản kế hoạch
Thiết kế Test
- Mục đích: Nhằm chỉ định các Test Case và các bước kiểm tra chi tiết chomỗi phiên bản phần mềm Giai đoạn thiết kế test là hết sức quan trọng, nóbảo đảm tất cả các tình huống kiểm tra "quét" hết tất cả yêu cầu cần kiểmtra Thiết kế test không phải chỉ làm một lần, nó sẽ được sửa chữa, cập nhật,thêm hoặc bớt xuyên suốt chu kỳ phát triển phần mềm, vào bất cứ lúc nào có
sự thay đổi yêu cầu, hoặc sau khi phân tích thấy cần được sửa chữa hoặc bổsung
Trang 40Hình 2-8 Thời điểm phù hợp để thiết lập các kế hoạch kiểm tra
- Các bước thiết kế test bao gồm:
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ếtquả 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ànthà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ướccủa một Test Case, cũng như chỉ định các loại dữ liệu nào cần có để thựcthi 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ầntrăm phần mềm đã được kiểm tra? Để xác định điều này có hai phươngphá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ự thamgia 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