Các mức kiểm thử test levels Các mức kiểm thử là tập hợp các hoạt động test được thực hiện ở một giai đoạnphát triển cụ thể của sản phẩm, ví dụ từ lúc vài chức năng nhỏ được lập trình,
KIỂM THỬ PHẦN MỀM
KIỂM THỬ HỘP TRẮNG
Kiểm thử hộp trắng là gì?
Kiểm thử Hộp Trắng, hay còn gọi là Kiểm thử Hộp Sáng, là một phương pháp kiểm thử phần mềm mà trong đó người kiểm tra nắm rõ cấu trúc nội bộ và thiết kế của mã Phương pháp này yêu cầu tester lựa chọn đầu vào để thực hiện các đường dẫn qua mã và xác định đầu ra phù hợp Để thực hiện kiểm thử Hộp Trắng hiệu quả, kiến thức lập trình và hiểu biết về cách thực hiện mã là rất quan trọng.
Kiểm thử hộp trắng là quy trình phân tích các dòng dữ liệu, điều khiển dòng, và mã thực hành trong hệ thống Quy trình này giúp phát hiện các lỗi trình bày và ngoại lệ, nhằm kiểm tra các hành động của phần mềm mà không được định hướng trước.
1, Đối tượng áp dụng Đối tượng được kiểm thử là 1 thành phần phần mềm (TPPM) TPPM có thể là 1 hàm chức năng, 1 module chức năng, 1 phân hệ chức năng…
Phương pháp Kiểm tra Hộp trắng áp dụng cho các mức độ kiểm tra phần mềm sau đây:
Unit Testing(Kiểm thử đơn vị): Để kiểm tra đường dẫn trong một đơn vị.
Integration Testing(Test tích hợp): Để kiểm tra đường dẫn giữa các đơn vị.
System Testing(Test hệ thống): Để kiểm tra các đường dẫn giữa các hệ thống con.
Tuy nhiên, nó là chủ yếu áp dụng cho các kiểm thử đơn vị
3, Ưu điểm và nhược điểm
Kiểm thử phần mềm sớm hơn là một trong những ưu điểm nổi bật, không cần chờ đợi giao diện người dùng (GUI) để bắt đầu Phương pháp này cho phép kiểm tra kỹ lưỡng, bao phủ hầu hết các đường dẫn và thích hợp cho việc phát hiện lỗi cùng các vấn đề trong mã lệnh Nó cũng giúp tìm kiếm các lỗi ẩn, cho phép lập trình viên tự kiểm tra và tối ưu hóa quá trình mã hóa Việc yêu cầu kiến thức về cấu trúc bên trong của phần mềm giúp kiểm soát lỗi một cách tối đa.
Nhược điểm của phương pháp kiểm tra hộp trắng bao gồm việc phụ thuộc vào quy trình cài đặt kiến trúc, yêu cầu người thực hiện phải có kiến thức sâu sắc về mã nguồn và cấu trúc phần mềm Phương pháp này không thể phát hiện lỗi thiết kế, vì nó chủ yếu tập trung vào kiểm tra mã nguồn mà có thể bỏ qua các vấn đề liên quan đến thiết kế tổng thể Ngoài ra, kiểm tra hộp trắng không phù hợp với các hệ thống kiểm tra lớn, đặc biệt là những hệ thống phức tạp với nhiều tương tác giữa các thành phần, dẫn đến hiệu quả kiểm tra không cao Cuối cùng, kỹ thuật này tiêu tốn nhiều thời gian và tài nguyên, đặc biệt đối với các ứng dụng lớn và phức tạp, vì quá trình kiểm tra phải được thực hiện trên từng dòng mã và đảm bảo bao phủ toàn bộ logic dữ liệu.
Phương pháp thử nghiệm này gắn liền với ứng dụng được kiểm tra, do đó, các công cụ hỗ trợ cho mọi loại triển khai hoặc nền tảng có thể không được cung cấp.
4, So sánh phương pháp kiểm thử hộp trắng với phương pháp kiểm thử hộp đen
Kiểm thử hộp đen là phương pháp kiểm tra phần mềm tập trung vào việc đánh giá chức năng của ứng dụng mà không cần xem xét cấu trúc nội bộ của nó.
Kiểm tra hộp trắng là cách kiểm thử phần mềm, ѕử dụng để kiểm tra phần mềm mà уêu cầu phải biết cấu trúc bên trong của chương trình.
Trách nhiệm Thử nghiệm được thực hiện bên ngoài, không liên quan đến nhà phát triển phần mềm.
Thông thường, các thử nghiệm được thực hiện bởi nhà phát triển phần mềm.
Cấp độ teѕt ѕử dụng Thử nghiệm áp dụng Thử nghiệm được
Kiểm tra hệ thống (System test) và kiểm tra chấp nhận (Acceptance test) là những cấp độ kiểm tra quan trọng, thường áp dụng ở mức độ cao hơn so với các loại thử nghiệm đơn giản như thử nghiệm đơn vị (Unit Test) và thử nghiệm hội nhập (Integration Test) Những phương pháp này giúp đảm bảo chất lượng và tính ổn định của phần mềm trước khi đưa vào sử dụng.
(Integration teѕt) Biết lập trình Không уêu cầu hiểu biết ề Lập trìnhᴠ
Yêu cầu hiểu biết nhất định ề lậpᴠ trình.
Biết iệc thực hiệnᴠ chương trình
Không уêu cầu hiểu ề cấu trúc bên ᴠ trong chức năng, àᴠ không cẩn hiểu làm thế nào để có được chức năng đó
Yêu cầu hiểu cấu trúc bên trong chức năng được thực hiện như nào
Cơ ѕở tạo Teѕt Caѕeѕ Kiểm tra hộp đen được bắt đầu dựa trên tài liệu уêu cầu kỹ thuật
Kiểm tra hộp trắng được bắt đầu dựa trên các tài liệu thiết kế chi tiết
Các dạng kiểm thử hộp trắng
Kiểm thử đơn vị là quá trình kiểm tra từng khối mã trong ứng dụng ngay khi được phát triển, thường do lập trình viên thực hiện Họ sẽ viết một số dòng mã hoặc một chức năng đơn lẻ và tiến hành kiểm tra để đảm bảo mọi thứ hoạt động trơn tru Việc này giúp phát hiện sớm các lỗi trong giai đoạn phát triển phần mềm, trước khi chuyển sang các bước tiếp theo.
2, Kiểm tra rò rỉ bộ nhớ
Một trong những nguyên nhân chính gây ra sự chậm chạp của ứng dụng là rò rỉ bộ nhớ Các chuyên gia kiểm tra chất lượng có kinh nghiệm trong việc phát hiện rò rỉ bộ nhớ đóng vai trò quan trọng, giúp phát hiện sớm các lỗi và cải thiện hiệu suất của phần mềm.
Trong thử nghiệm này, các đối tượng tham gia cần có đầy đủ thông tin về mã nguồn ứng dụng, máy chủ, và các thông tin mạng chi tiết cùng địa chỉ IP Mục tiêu của thử nghiệm là tiến hành tấn công mã từ nhiều góc độ nhằm phát hiện các mối đe dọa bảo mật và từ đó đưa ra các biện pháp xử lý hiệu quả.
4, Kiểm thử đột biến trắng
Kiểm thử đột biến là phương pháp thiết kế bài kiểm tra phần mềm mới và đánh giá chất lượng bài kiểm tra hiện có Nó giúp tìm kiếm kỹ thuật mã hóa tối ưu để mở rộng giải pháp phần mềm Thử nghiệm phát hiện phiên bản đột biến, hay còn gọi là dị nhân, nhằm phát hiện và loại bỏ các lỗi dị nhân trong phần mềm.
Các phương pháp và kỹ thuật kiểm thử hộp trắng
1, Phương pháp kiểm thử đường cơ bản – đồ thị dòng
Kỹ thuật kiểm thử hộp trắng do Tom McCabe phát triển, được gọi là đồ thị dòng, tương tự như đồ thị luồng điều khiển của chương trình.
Phương pháp miêu tả thuật giải là một trong những cách tiếp cận trực quan, giúp chúng ta dễ dàng nhận diện các thành phần của thuật giải và mối quan hệ giữa chúng.
hệ trong việc thực hiện các thành phần này.
Kỹ thuật đường cơ bản - đồ thị dòng có thể giúp những người thiết kế ca kiểm thử nhận được một độ phức tạp của 1 logic thủ tục.
Gồm 2 loại thành phần : các nút và các cung nối kết giữa chúng.
Các loại nút trong đồ thị dòng điều khiển :
Các kiểu cấu trúc thành phần đồ thị dòng :
Đồ thị dòng điều khiển nhị phân là loại đồ thị chỉ chứa các nút quyết định nhị phân Mọi đồ thị dòng điều khiển đều có thể được chi tiết hóa thành đồ thị dòng điều khiển nhị phân.
Độ phức tạp Cyclomatic C, ký hiệu là V(G), được tính toán dựa trên đồ thị dòng điều khiển thông qua các công thức như sau: V(G) = E - N + 2, trong đó E là số cung và N là số nút của đồ thị Đối với đồ thị dòng điều khiển nhị phân, công thức là V(G) = P + 1, với P là số nút quyết định Cyclomatic C đại diện cho số đường thi hành tuyến tính độc lập của TPPM cần được kiểm thử.
2, Phương pháp kiểm thử dựa trên luồng điều khiển
Đường thi hành (Execution path) là kịch bản thực thi của một đơn vị phần mềm, bao gồm danh sách có thứ tự các lệnh được thực hiện trong một lần chạy cụ thể Nó bắt đầu từ điểm nhập và kết thúc tại điểm kết thúc của đơn vị phần mềm.
Mỗi TPPM có từ 1 đến n (có thể rất lớn) đường thi hành khác nhau.
Phương pháp kiểm thử luồng điều khiển nhằm đảm bảo mọi đường thi hành của đơn vị phần mềm được kiểm thử hoạt động chính xác Tuy nhiên, thực tế cho thấy việc đạt được mục tiêu này tốn kém rất nhiều công sức và thời gian, ngay cả đối với những đơn vị phần mềm có quy mô nhỏ.
Thí dụ ₫oạn code sau : for (i=1; i Build Path => Add Libraries…
Sau đó lần lượt chọn Junit và ấn Next => chọn JUnit 5 :
Sau đó ta có cấu trúc project như sau :
Sau đó ta thiết lập lớp kiểm thử cho chương trình máy tính đơn giản ở trên.
Chuột phải vào tên lớp chương trình => New => JUnit Test Case như ảnh :
Sau đó đặt tên cho nó (Ví dụ: MayTinhTest2) và chọn các thuộc tính (nếu muốn):
Chọn New JUnit Jupiter test vì ta sẽ sử dụng JUnit Test 5 => Ấn Next =>
Ta chọn các phương thức cần kiểm thử => Ấn Finish.
Ta được lớp kiểm thử MayTinhText.java.
Bảng các kịch bản test :
STT Kịch bản Các bước thực hiện
1 Người dùng bấm các nút bấm có trên chương trình máy tính
Bấm 1 nút bấm bất kỳ trên chương trình
Màn hình hiển thị đúng giá trị nút bấm mà người dùng chọn (Như số
2 Người dùng thực hiện phép cộng (VD: 5+3)
Màn hình hiển thị kết quả là 8
3 Người dùng thực hiện phép trừ (VD: 9-4)
Màn hình hiển thị kết quả là 5
4 Người dùng thực hiện phép nhân (VD: 3*2)
Màn hình hiển thị kết quả là 6
5 Người dùng thực hiện phép chia (VD: 5/2)
B1: Bấm số 5 B2: Bấm dấu / B3: Bấm số 2 B4: Bấm dấu
Màn hình hiển thị kết quả là 2.5
Màn hình hiển thị kết
35 phép chia cho số 0 (VD:
9/0) dấu / B3: Bấm số 0 B4: Bấm dấu quả là Error
Ta viết code để kiểm thử nó.
Ta khai báo biến frame theo kiểu MayTinh => khởi tạo máy tính để test.
Các phương thức ActionEvent và actionPerformed sẽ nhận sự kiện khi nút được bấm Chúng ta khai báo các nút bấm theo từng trường hợp kiểm thử Sử dụng assertEquals để so sánh kết quả mong đợi với kết quả thực tế từ chương trình, từ đó xác định xem bài kiểm thử có pass hay fail Để thực hiện kiểm thử cho chương trình, bạn chỉ cần chuột phải vào file kiểm thử và chọn Run.
Khi chạy kiểm thử này ta được kết quả :
Ta có bảng kết quả :
STT Trườn Đầu Kết Kết Trạng
41 g hợp kiểm thử vào quả mong đợi quả thực tế thái
5 Kiểm thử ngoại lệ chia cho số
Thành công trên màn hình trên màn hình
*Các nút bấm cho các số khác tương tự nút bấm số 1
Kiểm thử độ bao phủ code (Coverage)
Chuột phải vào chương trình máy tính => Coverage As => Java Application
Khi đó chương trình chạy và ta cần chạy các chức năng của nó => Được kết quả:
Nghĩa là độ bao phủ code của chương trình khá cao, chỉ 1 số dòng code không được thực hiện Ta quay lại phần code kiểm tra: