Một số phương pháp kiểm thử

Kiểm thử phần mềm là công việc nhằm đảm bảo hoạt động của ứng dụng vừa được phát triển. Để thực hiện công việc này tùy theo khả năng, kinh nghiệm mà kiểm thử viên có thể áp dụng các phương pháp kiểm thử phần mềm cơ bản sau: White box testing, Black box testing, Grey box testing.

I. Các Kỹ Thuật Kiểm Thử Phần Mềm

Trong bài học kiểm thử phần mềm này, Tehcacademy giới thiệu 3 kỹ thuật kiểm thử phần mềm phổ biến và thông dụng nhất hiện nay.

1. Phương pháp kiểm thử phần mềm White box testing

White box testing (Kiểm tra hộp màu trắng) là một kỹ thuật kiểm tra cấu trúc bên trong của phần mềm và lấy dữ liệu thử nghiệm từ logic / mã chương trình. Là phương pháp kiểm thử mà các chuyên gia tester tập trung vào các dữ liệu đầu vào và ra, truy cập thẳng vào bên trong source code. Các tên khác của thử nghiệm hộp trắng là thử nghiệm hộp mở, kiểm tra theo hướng logic hoặc thử nghiệm điều khiển đường dẫn hoặc thử nghiệm cấu trúc.

Phương pháp kiểm thử phần mềm White box testing

Các loại white box testing:

API testing (application programming interface) Kiểm thử ứng dụng bằng cách sử dụng các hàm API public và private.

Code coverage Là việc tạo các trường hợp test để thỏa mãn một số điều kiện bao phủ code code coverage (ví dụ như, người thiết kế test có thể tạo ra các trường hợp test sao cho tất cả các câu lệnh của chương trình đều được thực thi ít nhất 1 lần).

Fault injection methods cải tiến bao phủ một trường hợp bằng cách đưa một số lỗi vào để test các đường dẫn code.

Mutation testing methods.

Static testing White box testing bao gồm tất cả các phương pháp kiểm thử tĩnh (ví dụ review code).

Với phương pháp kiểm thử này, kiểm thử viên không cần hiểu biết về mã lệnh để xử lý chức năng đó thế nào. Các kiểm thử viên sẽ căn cứ vào tài liệu đặc tả, bản prototype của phần mềm cũng như dựa trên các testcase đã viết để kiểm tra chức năng. Cả hai hình thức trên đề trả về một cách đo độ bao phủ code, sự đo lường được tính bằng phần trăm %.

Ưu điểm:

• Dễ dàng tự động hóa
• Cung cấp các quy tắc dựa trên kỹ thuật rõ ràng cho thời điểm ngừng thử nghiệm.
• Buộc các chuyên gia thử nghiệm phải suy luận cẩn thận về việc test lỗi vì vậy lỗi sẽ được triệt để.

Nhược điểm:

• Khá tốn thời gian và công sức.
• Vẫn sẽ tồn tại lỗi.
• Để kiểm tra được bằng phương pháp này cần có kinh nghiệm và trình độ chuyên sâu về kiểm thử.

2. Phương pháp kiểm thử phần mềm Black box testing

Black box testing (Kiểm thử hộp đen) là một phương pháp kiểm thử phần mềm kiểm tra chức năng của ứng dụng dựa trên các đặc điểm kỹ thuật của nó. Nó còn được gọi là thử nghiệm dựa trên thông số kỹ thuật.

Phương pháp kiểm thử phần mềm Black box testing

Các loại kiểm thử Black box:

• Equivalence partitioning (phân vùng tương đương)
• Boundary value analysis (phân tích giá trị biên)
• All-pairs testing (kiểm thử tất cả các cặp)
• Fuzz testing (cách test: nhập vào các điều kiện sai hoặc data một cách ngẫu nhiên)
• Model-based testing (Kiểm thử dựa trên model)
• Traceability matrix (các chức năng của chương trình được tạo thành một ma trận, các trường hợp test là sự kết hợp các dòng hoặc các cột có liên quan)
• Exploratory testing (kiểm thử chủ yếu dựa vào kinh nghiệm và khả năng focus vào việc test các chức năng của tester)
• Specification-based testing (kiểm thử dựa vào chức năng).

Việc kiểm thử được tiến hành dựa vào việc kiểm thử chức năng của phần mềm xem nó có phù hợp với yêu cầu của người dùng hay không. Vì vậy, các tester nhập data vào phần mềm và chỉ cần xem kết quả của phần mềm và các mục tiêu test.

Ưu điểm:

• Các tester khi dùng phương pháp này sẽ không cần liên quan đến code.
• Có thể tìm được nhiều bug hơn.
• Việc kiểm thử được thực hiện bởi một cách độc lập với các Dev, cho phép quan điểm khách quan và tránh sự thiên vị.

Nhược điểm:

• Chỉ có một số lượng nhỏ các đầu vào có thể được kiểm tra và nhiều đường dẫn chương trình hoặc 1 vài phần cuối sẽ không được kiểm tra.
• Các thử nghiệm có thể thừa nếu nhà thiết kế / nhà phát triển phần mềm đã chạy thử nghiệm.

Vì vậy, black box testing có ưu điểm là sản phẩm phần mềm được kiểm tra theo một quan điểm độc lập tuy vậy vẫn còn khá nhiều nhược điểm đáng lưu ý.

3. Grey box testing

Phương pháp Gray box testing là một trong các phương pháp test phần mềm phổ biến nhất hiện nay. Có thể nói phương pháp Gray Box testing là phương pháp của sự kết hợp giữa White box testing và Black box testing. Kiểm tra hộp màu xám cho khả năng kiểm tra cả hai mặt của một ứng dụng, lớp trình bày cũng như phần mã. Nó chủ yếu là hữu ích trong kiểm thử tích hợp và kiểm tra thâm nhập. 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ể truy cậ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 là ở mức hộp đen.

Grey box testing

Kỹ thuật kiểm tra hộp xám:

Kiểm tra ma trận: báo cáo trạng thái của dự án.

Kiểm tra hồi quy : nó ngụ ý chạy lại các trường hợp thử nghiệm nếu các thay đổi mới được thực hiện.

Kiểm tra mẫu: xác minh ứng dụng tốt cho thiết kế hoặc kiến ​​trúc và các mẫu của nó.

Kiểm tra mảng trực giao : được sử dụng làm tập hợp con của tất cả các kết hợp có thể.

Ưu điểm:

Là sự kết hợp của kiểm thử hộp đen và hộp trắng nên sẽ tối ưu hơn.

Kiểm tra bằng phương pháp hộp màu xám có thể thiết kế kịch bản thử nghiệm phức tạp một cách thông minh hơn.

Nhược điểm:

Rất khó để liên kết lỗi khi thực hiện kiểm tra hộp xám cho một ứng dụng có hệ thống phân tán.

Trên đây là 3 phương pháp kiểm thử phần mềm cơ bản nhất mà bất cứ một lập trình viên nào cũng cần nắm được. Việc lựa chọn phương pháp nào phụ thuộc vào khả năng cũng như dự án mà bạn thực hiện.

2. Nguyên lý kiểm thử phần mềm

Để đạt được kết quả kiểm thử tối ưu trong khi tiến hành kiểm thử phần mềm mà không đi lệch khỏi mục tiêu là điều cực kì quan trọng, làm thế nào để xác định rằng bạn đang theo đúng chiến lược kiểm thử? Để làm được điều đó, bạn cần tuân thủ một số nguyên lý kiểm thử cơ bản. Dưới đây là bảy nguyên lý kiểm thử phổ biến được áp dụng rộng rãi trong ngành công nghiệp phần mềm.

+ Kiểm thử đưa ra lỗi
+ Kiểm thử cạn kiệt là không thể
+ Kiểm thử càng sớm càng tốt
+ Sự tập trung của lỗi
+ Nghịch lý thuốc trừ sâu
+ Kiểm thử phụ thuộc vào ngữ cảnh
+ Không có lỗi Sai lầm

7 Nguyên Lý Kiểm Thử Phần Mềm

2.1 Kiểm thử đưa ra lỗi

Kiểm thử có thể cho thấy rằng phần mềm đang có lỗi, nhưng không thể chứng minh rằng phần mềm không có lỗi. Kiểm thử được thực hiện bằng những kĩ thuật khác nhau. Kiểm thử làm giảm xác suất lỗi chưa tìm thấy vẫn còn trong phần mềm, ngay cả khi đã kiểm thử nghiêm ngặt phần mềm vẫn có thể còn lỗi. Vì vậy chúng ta phải tìm được càng nhiều lỗi càng tốt.

2.2 Kiểm thử cạn kiệt là không thể

Nguyên lý này nói rằng, kiểm tra mọi thứ trong phần mềm một cách trọn vẹn là không thể. Kiểm thử với tất cả các kết hợp đầu vào và đầu ra, với tất cả các kịch bản là không thể trừ phi nó chỉ bao gồm ít trường hợp thì có thể kiểm thử toàn bộ. Thay vì kiểm thử toàn bộ, việc phân tích rủi ro và dựa trên sự mức độ ưu tiên chúng ta có thể tập trung việc kiểm thử vào một số điểm cần thiết, có nguy cơ lỗi cao hơn.

2.3 Kiểm thử càng sớm càng tốt

Nguyên lý này yêu cầu bắt đầu thử nghiệm phần mềm trong giai đoạn đầu của vòng đời phát triển phần mềm. Các hoạt động kiểm thử phần mềm từ giai đoạn đầu sẽ giúp phát hiện bug sớm hơn. Nó cho phép chuyển giao phần mềm theo yêu cầu đúng thời gian với chất lượng dự kiến.

2.4 Sự tập trung của lỗi

Thông thường, lỗi tập trung vào những module, thành phần chức năng chính của hệ thống. Nếu xác định được điều này bạn sẽ tập trung vào tìm kiếm lỗi quanh khu vực được xác định. Nó được coi là một trong những cách hiệu quả nhất để thực hiện kiểm tra hiệu quả.

2.5 Nghịch lý thuốc trừ sâu

Nếu bạn sử dụng cùng một tập hợp các trường hợp kiểm thử liên tục, sau đó một thời gian các trường hợp kiểm thử không tìm thấy lỗi nào mới. Hiệu quả của các trường hợp kiểm thử bắt đầu giảm xuống sau một số lần thực hiện, vì vậy luôn luôn chúng ta phải luôn xem xét và sửa đổi các trường hợp kiểm thử trên một khoảng thời gian thường xuyên.

2.6 Kiểm thử phụ thuộc vào ngữ cảnh

Theo nguyên tắc này thì việc kiểm thử phụ thuộc vào ngữ cảnh và chúng ta phải tiếp cận kiểm thử theo nhiều ngữ cảnh khác nhau.

Nếu bạn đang kiểm thử ứng dụng web và ứng dụng di động bằng cách sử dụng chiến lược kiểm thử giống nhau, thì đó là sai. Chiến lược để kiểm thử ứng dụng web sẽ khác với kiểm thử ứng dụng cho thiết bị di động của Android.

2.7 Không có lỗi Sai lầm

Việc không tìm thấy lỗi trên sản phẩm không đồng nghĩa với việc sản phẩm đã sẵn sàng để tung ra thị trường. Việc không tìm thấy lỗi cũng có thể là do bộ trường hợp kiểm thử được tạo ra chỉ nhằm kiểm tra những tính năng được làm đúng theo yêu cầu thay vì nhằm tìm kiếm lỗi mới.

Bài viết này chỉ hy vọng giúp các bạn hiểu cơ bản về Phương pháp kiểm thử phần mềm và Nguyên lý kiểm thử phần mềm .Bạn cần tìm hiểu thêm để có thể hiểu sâu hơn về các phương pháp cũng như những nguyên lý này cũng như áp dụng hiệu quả nó vào công việc của bạn.