Đã đăng vào thg 9 30, 7:29 SA 16 phút đọc

Kiểm thử hộp đen- Kiểm thử hộp trắng

Trong quá trình nghiên cứu và phát triển ứng dụng hoặc phần mềm mới thì bạn không thể nào đảm bảo sẽ không có bất kỳ lỗi nào xảy ra. Do đó, kiểm thử chính là phương thức hiệu quả nhất để giúp bạn có thể nhanh chóng kiểm tra lỗi và đem tới sản phẩm hoàn chỉnh nhất. Hiện nay có 2 phương pháp kiểm thử chính là kiểm thử hộp trắng và kiểm thử hộp đen.

1. Kiểm thử hộp đen( Black box testing)

Kiểm thử hộp đen( Black box testing) là một phương pháp kiểm thử phần mềm mà việc kiểm tra các chức năng của một ứng dụng không cần quan tâm tới cấu trúc nội bộ hoặc hoạt động của nó. Kiểm thử hộp đen không yêu cầu kỹ sư kiểm thử cần phải có bất kỳ kiến thức về mã hoặc thuật toán của chương trình. Nó kiểm tra các chức năng của hệ thống tức là những gì hệ thống được cho là cần phải làm dựa trên các Đặc tả yêu cầu. Các trường hợp kiểm thử thường được xây dựng xung quanh đó.

Phân loại:

1.1 Phân vùng tương đương (Equivalence partitioning - EP)

Phân vùng tương đương là phương pháp chia các điều kiện đầu vào thành những vùng tương đương nhau. Tất cả các giá trị trong một vùng tương đương sẽ cho một kết quả đầu ra giống nhau. Vì vậy chúng ta có thể test một giá trị đại diện trong vùng tương đương. Các lớp tương đương được xác định bằng bằng cách lấy mỗi trạng thái đầu vào (thường là 1 câu hay 1 cụm từ trong đặc tả) và phân chia nó thành 2 hay nhiều nhóm.

Ví dụ: Nhập form thông tin người dùng

Thiết kế testcase sao cho người dùng nhập vào text-box chỉ cho nhập số nguyên, độ dài ký tự 9 số:

Có các lớp tương đương(phân vùng) sau:

Phân vùng 1: Nhập giá trị hợp lệ( đủ 9 ký tự)
Phân vùng 2: Nhập giá trị không hợp lệ ( < 9 ký tự)
Phân vùng 3: Nhập giá trị không hợp lệ ( >9 ký tự)
phân vùng 4: Trường hợp để trống không nhập gì hay nhập ký tự không phải dạng số

Sau khi áp dụng phân vùng tương đương có thể chọn được các ca kiểm thử (test case) sau:

Case 1: Nhập 9 ký tự số => pass
Case 2: Nhập < 9 ký tự => hiển thị lỗi
Case 3: Nhập > 9 ký tự => hiển thị lỗi
Case 4: Để trống không nhập gì hay nhập ký tự không phải dạng số => hiển thị lỗi

1.2 Phân tích giá trị biên (Boundary value analysis - BVA)

Phân tích giá trị biên là một kỹ thuật thiết kế trường hợp thử nghiệm để kiểm tra ranh giới giữa các phân vùng ( kể cả ranh giới hợp lệ và ranh giới không hợp lệ). Lý do là các lỗi thường xảy ra ở các giá trị biên này. Thay vì chọn nhiều giá trị trong vùng tương đương để test thì chúng ta chọn các giá trị biên của các lớp tương đường để test. Nó vẫn bao quát toàn bộ trường hợp kiểm thử. Phân tích giá trị biên là phương pháp thiết kế ca kiểm thử bổ sung thêm cho phân lớp tương đương.

Các case chuẩn được lựa chọn dựa vào quy tắc sau:

Giá trị biên nhỏ nhất – 1
Giá trị biên nhỏ nhất
Giá trị biên nhỏ nhất + 1
Giá trị biên lớn nhất – 1
Giá trị biên lớn nhất
Giá trị biên lớn nhất + 1

Ví dụ: Nhập form thông tin người dùng.

Áp dụng Phân tích giá trị biên ta chọn được các ca kiểm thử (test case) sau:

Case 1: Nhập 8 ký tự số => hiển thị lỗi
Case 2: Nhập 10 ký tự số => hiển thị lỗi
Case 2: Nhập khoảng trắng=> hiển thị lỗi
Case 3: Nhập space ký tự đầu cuối => hiển thị lỗi
Case 4: Để trống không nhập gì hay nhập ký tự không phải dạng số => hiển thị lỗi

1.3 Bảng quyết định (Decision table - test matrix)

Bảng quyết định là một kỹ thuật test được sử dụng để kiểm tra các hành vi hệ thống (system behavior) với các cách kết hợp input đầu vào khác nhau. Đây là một cách tiếp cận có hệ thống, kết quả của các kết hợp đó và hành vi hệ thống tương ứng của chúng (output) sẽ được ghi lại dưới dạng bảng. Đó cũng là lý do tại sao bảng quyết định còn được gọi là Bảng hiệu ứng nguyên nhân - Cause-Effect table.

Số lượng các cột trường hợp trong bảng được tính bằng công thức 2^n ( n là số lượng input đầu vào)

Ví dụ: Với các yêu cầu của form đăng nhập:

Người dùng nhập đúng email & mật khẩu khi đăng nhập thành công sẽ đucợ điều hướng dang trang chỉ của Website
Nếu nhập email/ mật khẩu không đúng khi đăng nhập hệ thống sẽ hiển thị thông báo lỗi tương đương.jirajira

Chúng ta sẽ có được bảng quyết định các hành vi hệ thống cho form đăng nhập như sau:

❁ Chú thích:

T - True: Nhập đúng email và mật khẩu. F - False: Email hoặc mật khẩu bị sai. E - Error: Hiển thị lỗi. H - Home: Hiển thị trang chủ. ❁ Diễn giải:

Trường hợp 1: Email và mật khẩu đúng, người dùng sẽ được chuyển hướng đến trang chủ. Trường hợp 2: Email đúng, mật khẩu sai; người dùng sẽ nhận được thông báo lỗi. Trường hợp 3: Email sai, mật khẩu đúng; người dùng sẽ nhận được thông báo lỗi. Trường hợp 4: Email và mật khẩu sai, người dùng sẽ nhận được thông báo lỗi.

1.4 Kỹ thuật đoán lỗi

Đoán lỗi (Error Guessing) là một kỹ thuật kiểm thử phần mềm, về cơ bản, đây là một kỹ thuật kiểm thử dựa trên kinh nghiệm để đưa ra một phỏng đoán có chứng cứ về các lỗi có thể xảy ra của phần mềm. Kỹ thuật này nhất thiết đòi hỏi tester có năng khiếu và kinh nghiệm.

Các test case sử dụng để tìm lỗi được tạo ra dựa trên trải nghiệm kiểm thử trước đó với các ứng dụng tương tự, có kiến thức liên quan, dựa vào trực giác để xác định những tình huống thường gây ra lỗi trong phần mềm.

Vì thế, kỹ thuật đoán lỗi không tuân theo bất kỳ quy tắc cụ thể nào, test case có thể được thiết kế tùy thuộc vào đặc trưng, luồng hoạt động của phần mềm theo các tài liệu mô tả chức năng hoặc khi một lỗi không mong muốn mà không được mô tả trong tài liệu được tìm thấy trước đó, hoặc làm việc với một dev đã để xảy ra lỗi nào đó nhiều lần,...

Ví dụ: Giả sử có 1 yêu cầu nói rằng số điện thoại di động phải là số và không ít hơn 10 ký tự.

=> Sừ dụng Kỹ thuật đoán lỗi

không có số điện thoại di động -> để trống?
ký tự ngoài số được nhập vào?
Nhập ít hơn 10 số ?

2. Kiểm thử hộp trắng (White-box Testing)

Là hình thức kiểm thử mà kiểm thử viên biết được các cấu trúc bên trong của chương trình (mã nguồn, xử lý dữ liệu, …). Việc kiểm thử được dựa trên các phân tích về cấu trúc bên trong của thành phần/hệ thống. Kiểm tra mã nguồn các chi tiết thủ tục (thuật toán), các con đường logic (luồng điều khiển), các trạng thái của chương trình (dữ liệu)

Đặc trưng:

Kiểm thử hộp trắng dựa vào thuật giải cụ thể, vào cấu trúc dữ liệu bên trong của đơn vị phần mềm cần kiểm thử để xác định đơn vị phần mềm đó có thực hiện đúng không.
Người kiểm thử hộp trắng phải có kỹ năng, kiến thức nhất định để có thể hiểu chi tiết về đoạn code cần kiểm thử.
Thường tốn rất nhiều thời gian và công sức nếu mức độ kiểm thử được nâng lên ở cấp kiểm thử tích hợp hay kiểm thử hệ thống.
Do đó kỹ thuật này chủ yếu được dùng để kiểm thử đơn 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 1 class 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 và kiểm thử dòng dữ liệu.

Phân loại:

2.1 Kỹ thuật kiểm thử đường cơ bản- Đồ thị dòng

Là một kỹ thuật dùng trong kiểm thử hộp trắng được Tom McCabe đưa ra đầu tiên. Đồ thị dòng gần giống đồ thị luồng điều khiển của chương trình.

Là một trong nhiều phương pháp miêu tả thuật giải. Đây là phương pháp trực quan cho chúng ta thấy dễ dàng các thành phần của thuật giải và mối quan

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.

2.2 Kiểm thử dựa trên luồng điều khiển

Kiểm thử luồng điều khiển là quá trình kiểm thử tương xứng giữa các nhóm câu lệnh với các cạnh điều khiển. Các yếu tố quyết định trong luồng điều khiển:

– Là điểm bắt đầu trong 1 đơn vị, chương trình bất kỳ

– Thông thường các câu lệnh có chứa trong khối xử lý sẽ được khai báo chính xác.

– Các điểm có chức năng quyết định trong luồng điều khiển sẽ được tương ứng với các câu lệnh có trong điều kiện của các khối lặp lại hoặc rẽ nhánh.

– Sau các câu lệnh rẽ nhánh sẽ là các điểm nối tương ứng với nó. – Cuối cùng, điểm kết thúc trong đơn vị chương trình sẽ tương ứng với điểm kết thúc trên luồng điều khiển.

Bên cạnh đó, mục đích của kiểm thử dựa trên luồng điều khiển là để mọi hoạt động đang thi hành trong 1 đơn vị phần mềm bất kỳ đang diễn ra đúng theo kế hoặc hoặc dự kiến ban đầu,

2.3 Kiểm thử dựa trên luồng dữ liệu ( Data – flow Testing)

Với quá trình kiểm thử này thông thường sẽ bao gồm quá trình xây dựng phần mềm từ đó kiểm tra các vấn đề xảy ra có liên quan. Sẽ có 2 cách kiểm tra tích hợp trên hệ thống phần mềm đó là:

– Kiểm tra tích hợp theo thứ tự từ trên xuống dưới: Quá trình này bao gồm việc xây dựng hệ thống khung bên trong và quá trình đưa toàn bộ thành phần vào bên trong đó.

– Kiểm tra tích hợp theo thứ tự từ dưới lên trên: Là quá trình kiểm tra các thành phần trong cơ sở và từ đó có thể bổ sung thêm các thành phần khác có liên quan đến chức năng.

Quy trình thực hiện kiểm tra dựa trên luồng dữ liệu:

– Xây dựng ý tưởng và thực hiện vẽ luồng dữ liệu chính trong chương trình phần mềm.

– Xác định tiêu chuẩn phù hợp cho việc kiểm thử luồng dữ liệu.

– Tìm và chọn đường đi cho dữ liệu dựa và điều kiện cho trước để thỏa mãn được tiêu chuẩn đặt ra.

– Tạo và tiến hành thực hiện kiểm thử cho đường đi xác định.

2.4 Kiểm thử đột biến ( Mutation Testing)

Mutation testing là 1 loại kiểm thử phần mềm, nơi mà chúng ta thay đổi câu lệnh trong source code và check xem test case có thể tìm thấy lỗi hay không.

Là một kiểu white box testing được sử dụng chủ yếu trong unit testing. Những thay đổi này là những thay đổi nhỏ để đảm bảo không ảnh hưởng tới tổng thể hệ thống.
Mutation testing dùng để kiểm tra hiệu năng và độ chính xác của chương trình test. Phương pháp này giúp kiểm tra những thiếu sót của chương trình trong khi test. Nó cũng giúp cho việc ước lượng và hoàn thiện bộ test case.

Why It Is Named As Mutation Testing?

Mutation testing được gọi như vậy vì nó có chứa các đột biến, những thay đổi nhỏ trong code được cố ý đưa vào chương trình. Chiến lược này còn được gọi là fault-based testing method vì các đột biến được tạo ra để đưa vào một lỗi nhỏ vào trong code chương trình gốc.

Why mutation testing need to be performed

Độ bao phủ của test case, được cho là một nhân tố quan trọng trong kiểm thử phần mềm.
Mutation testing giúp trong việc phân tích xem một bộ chiến lược test có đủ để đảm bảo sản phẩm đầu ra có đạt các yêu cầu hay không. Nếu ta không thể nắm giữ được bất kì vấn đề nào, ta cũng không thể chắc chắn rằng hệ thống sẽ không có bug.
Trong Mutation testing, một thay đổi nhỏ sẽ được đặt vào trong code. Sau đó, một bộ test case sẽ được triển khai trên phần mềm đã được thay đổi. Một bộ unit testing tốt sẽ có khả năng nhận diện ra lỗi trong chương trình.