Git - Xóa remote repository 
Kỹ thuật Phân tích giá trị biên và phân vùng tương đương 
Git - thao tác thư mục 
Git - Lệnh merge branch - Xử lý conflict 
Git - Cấu hình username và email 
Git - Lệnh tạo Branch 
Git - Amend, thay đổi commit cuối cùng 
Cách khai báo biến trong PHP, các loại biến thường gặp 
Download và cài đặt Vertrigo Server 
Thẻ li trong HTML 
Thẻ article trong HTML5 
Cấu trúc HTML5: Cách tạo template HTML5 đầu tiên 
Cách dùng thẻ img trong HTML và các thuộc tính của img 
Thẻ a trong HTML và các thuộc tính của thẻ a thường dùng Các phương pháp kiểm thử
Có nhiều phương pháp kiểm thử khác nhau có thể được các testers sử dụng trong kiểm thử phần mềm. Bài viết này sẽ mô tả ngắn gọn các phương pháp truyền thống, đó là các phương pháp: Kiểm thử hộp đen (Black-Box Testing), Kiểm thử hộp trắng (White-Box Testing) và Kiểm thử hộp xám (Grey-Box Testing).
1. Kiểm thử hộp đen
Khi thực hiện kỹ thuật kiểm thử này, tester không cần quan tâm bên trong hệ thống hoạt động ra sao, không cần hiểu source code thế nào. Thông thường, trong khi thực hiện kiểm thử hộp đen, tester sẽ tương tác với giao diện người dùng của hệ thống bằng cách cung cấp đầu vào và kiểm tra kết quả đầu ra mà không cần biết cách thức làm việc bên trong của hệ thống.
Bảng sau đây liệt kê những ưu điểm và nhược điểm của kiểm thử hộp đen:
| Ưu điểm | Nhược điểm |
| Phù hợp và hiệu quả khi số lượng các dòng lệnh của hệ thống là lớn. | Bị giới hạn bởi độ bao phủ của các trường hợp kiểm thử |
| Không cần truy cập mã nguồn. | Kiểm thử không hiệu quả, do thực tế tester bị hạn chế kiến thức về hệ thống. |
| Phân biệt rõ ràng quan điểm của người dùng với quan điểm của nhà phát triển thông qua các vai trò được xác định rõ ràng. | Không có độ bao phủ, vì người kiểm thử không thể kiểm tra các đoạn mã nguồn hoặc tập trung vào các đoạn mã bị lỗi. |
| Một số lượng lớn tester có kỹ năng vừa phải có thể kiểm tra ứng dụng mà không cần có nhiều kiến thức, ngôn ngữ lập trình hoặc hệ điều hành. | Rất khó để thiết kế được đầy đủ các trường hợp kiểm thử cho hệ thống. |
2. Kiểm thử hộp trắng
Kiểm thử hộp trắng là kiểm tra chi tiết về logic luồng hoạt động cũng như source code. Kiểm thử hộp trắng cũng được gọi là Glass testing hay open-box testing. Để thực hiện kiểm thử hộp trắng trên một phần mềm, tester cần phải nghiên cứu hoạt động bên trong của phần mềm cũng như source code để tìm ra đơn vị / đoạn mã nào đang hoạt động không thích hợp.
Bảng sau đây liệt kê những ưu điểm và nhược điểm của kiểm thử hộp trắng:
| Ưu điểm | Nhược điểm |
| Khi tester có kiến thức về mã nguồn cũng như ngôn ngữ lập trình, sẽ trở nên rất dễ dàng để tìm ra loại dữ liệu nào có thể giúp kiểm thử phần mềm một cách hiệu quả. | Do thực tế, tester có tay nghề cao là cần thiết để thực hiện kiểm thử hộp trắng, chi phí được tăng lên. |
| Giúp tối ưu hóa source code trong hệ thống. | Đôi khi không thể khả thi khi kiểm tra chi tiết từng dòng source code để tìm ra các lỗi tiềm ẩn có thể gây ra vấn đề cho hệ thống, vì nhiều luồng sẽ không được kiểm tra. |
| Các dòng lệnh không cần thiết hoặc những dòng lệnh có khả năng gây ra các lỗi tiềm ẩn có thể được gỡ bỏ. | Rất khó để duy trì kiểm thử hộp trắng, vì nó đòi hỏi các công cụ chuyên biệt như phân tích source code và công cụ sửa lỗi. |
| Tester có kiến thức về ngôn ngữ lập trình sẽ dễ dàng để đạt được độ bao phủ cao nhất trong quá trình viết kịch bản kiểm thử. |
3. Kiểm thử hộp xám
Kiểm thử hộp màu xám là một kỹ thuật để kiểm thử phần mềm đòi hỏi tester có kiến thức nhất định về các luồng hoạt động bên trong của phần mềm.
Nắm vững domain của một hệ thống luôn mang lại cho tester một lợi thế lớn hơn một tester có kiến thức về domain hạn chế. Không giống như kiểm thử hộp đen, phương pháp mà tester quan tâm duy nhất là kiểm thử thông qua giao diện người dung thì trong kiểm thử hộp xám, tester có quyền truy cập vào tài liệu thiết kế và cơ sở dữ liệu. Do đó, một tester có thể chuẩn bị dữ liệu kiểm thử cũng như chuẩn bị các kịch bản kiểm thử tốt hơn trong quá trình thực hiện kế hoạch kiểm thử hệ thống.
| Ưu điểm | Nhược điểm |
| Là sự kết hợp của kiểm thử hộp đen và kiểm thử hộp trắng nên có được ưu điểm của cả hai phương pháp này. | Vì không dựa trên việc truy cập vào mã nguồn của hệ thống nên độ bao phủ của các trường hợp kiểm thử bị giới hạn. |
| Kiểm thử hộp xám không dựa vào mã nguồn; thay vào đó chúng dựa vào tài liệu thiết kế giao diện và các tài liệu đặc tả chức năng. | Các trường hợp kiểm thử có thể bị dư thừa nếu nhà thiết kế phần mềm đã chạy một số trường hợp kiểm thử. |
| Một tester kiểm thử hộp xám có thể thiết kế các kịch bản kiểm thử thông qua các giao thức kết nối và các kiểu dữ liệu khác nhau. | Kiểm thử mọi luồng đầu vào là không thể bởi vì nó sẽ mất một khoảng thời gian lớn; do đó, nhiều luồng hoạt động sẽ không được kiểm thử. |
| Việc kiểm thử được thực hiện từ quan điểm của người dùng chứ không phải người thiết kế. |
4. So sánh các phương pháp kiểm thử
Bảng sau đây liệt kê các điểm phân biệt kiểm thử hộp đen, kiểm thử hộp xám và kiểm thử hộp trắng:
| Kiểm thử hộp đen | Kiểm thử hộp xám | Kiểm thử hộp trắng |
| Không cần quan tâm đến các luồng hoạt động trong hệ thống. | Tester có kiến thức nhất định về luồng hoạt động trong hệ thống. | Tester có kiến thức đầy đủ về luồng hoạt động trong hệ thống. |
| Còn có các tên gọi khác như: Closed-box testing, Data-driven testing hoặc Functional testing. | Còn có tên gọi khác như: Translucent testing. | Còn có các tên gọi khác như: Clear-box testing hoặc Code-based testing. |
| Được thực hiện bởi end-user, tester và developer. | Được thực hiện bởi end-user, tester và developer. | Thường được thực hiện bởi tester và developer. |
| Kiểm thử dựa trên kết quả mong muốn và kết quả thực tế mà hệ thống trả về. | Việc kiểm thử dựa trên các sơ đồ về cơ sở dữ liệu và sơ đồ về các luồng dữ liệu.. | Việc kiểm thử dựa trên toàn bộ kiến thức về các luồng hoạt động bên trong hệ thống và các bộ dữ liệu kiểm thử phù hợp mà các testers tự thiết kế. |
| Là phương pháp có độ bao phủ hạn chế nhất và tốn ít thời gian nhất. | Là phương pháp có độ bao phủ trung bình và mức độ tốn thời gian là vừa phải. | Là phương pháp có độ bao phủ nhiều nhất và tốn nhiều thời gian nhất. |
| Không thích hợp để kiểm thử thuật toán. | Không thích hợp để kiểm thử thuật toán. | Phù hợp để kiểm thử thuật toán. |
| Chỉ có thể được thực hiện bằng cơ chế phát hiện lỗi. | Domain và các giá trị biên có thể được kiểm thử nếu các tester có kiến thức. | Domain và các giá trị biên có thể được kiểm thử tốt hơn. |
