Skip to content
Home » Black Box Testing Là Gì | Black Box Test (Kiểm Tra Hộp Đen)

Black Box Testing Là Gì | Black Box Test (Kiểm Tra Hộp Đen)

Phân biệt BlackBox và Whitebox

WHITE BOX TEST (Kiểm tra hộp trắng)

Định nghĩa

Thử nghiệm kết cấu là loại thử nghiệm được thực hiện để kiểm tra cấu trúc code. Nó còn được gọi là thử nghiệm hộp trắng hoặc thử nghiệm hộp kính. Loại thử nghiệm này đòi hỏi người test phải có kiến thức về code. Do đó, phần lớn là do các lập trình viên, nhà phát triển phần mềm thực hiện.

Đặc điểm

  • Kiểm thử hộp trắng quan tâm đến việc hệ thống vận hành như thế nào chứ không phải chứ năng của hệ thống. Vì nó dựa vào những giải thuật cụ thể, vào những cấu trúc dữ liệu bên trong của TPPM.
  • Trong kiểm tra này, đòi hỏi người tester phải có kiến thức và kỹ năng nhất định về ngôn ngữ lập trình được dùng, hiểu thuật giải trong thành phần phần mềm, để có thể hiểu được chi tiết về đoạn code cần kiểm thử .
  • Mức test này thường yêu cầu các tester phải viết test case đầy đủ các nhánh trong code; khi test, sẽ set điều kiện và data để chạy vào đủ tất cả các nhánh trong giải thuật, đảm bảo thực hiện đầy đủ.

Đối tượng kiểm thử

Là 1 thành phần của phần mềm (1 chức năng, 1 module chức năng, 1 phân hệ chức năng….)

Phương pháp thử nghiệm phù hợp


Kỹ thuật white box test

thích hợp dùng để kiểm thử đơn vị (Unit test). Còn với những TPPM quá lớn thì không nên sử dụng kiểu test này bởi sẽ tốn rất nhiều thời gian và công sức, hiệu quả công việc lại không cao. Nó không thích hợp kiểm thử hệ thống hay kiểm thử chấp nhận.


Xem thêm:


Quy trình kiểm thử phần mềm

Tạo testcase và thực hiện test

  • Khi viết test case: Dựa vào yêu cầu và nội dung Source Code (can thiệp vào bên trong Code của chương trình)
  • Khi thực hiện test: Thực thi test trong code (không cần thực thi chương trình, vì thực hiện test white box sẽ sử dụng framework nào đó hỗ trợ (Ví dụ như test kiểu debug)

Phương pháp kiểm thử hộp xám (Gray box testing)

Kiểm thử hộp xám (Gray box testing) là phương pháp kiểm thử phần mềm kết hợp giữa kiểm thử hộp đen và kiểm thử hộp trắng. Hộp xám trong kiểm thử phần mềm giống như bán trong suốt, nhìn vào sẽ thấy lớp vỏ bên ngoài và một phần cấu trúc bên trong.

Trong kiểm thử hộp xám, 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.

Ưu điểm của kiểm thử hộp xám là sử dụng kỹ thuật đơn giản của kiểm thử hộp đen kết nối với mã code hệ thống kiểm thử hộp trắng để tìm ra vấn đề của sản phẩm. Các tester được quyền truy cập vào cấu trúc dữ liệu bên trong cũng như các thuật toán được sử dụng trong sản phẩm.

Kiểm thử hộp xám (Gray box testing).

Phân biệt BlackBox và Whitebox
Phân biệt BlackBox và Whitebox

Nguyên tắc và quy trình thực hiện Black box testing

Nguyên tắc của Black box testing:

  • Độc lập với cấu trúc nội bộ: Black box testing tập trung vào hành vi bên ngoài của ứng dụng mà không quan tâm đến cấu trúc nội bộ hay chi tiết cài đặt. Người kiểm thử chỉ nhìn vào ứng dụng như một “hộp đen” và kiểm tra các đầu vào và đầu ra của nó.
  • Tập trung vào đầu vào và đầu ra: Black box testing xác định các kịch bản kiểm thử dựa trên các đầu vào khác nhau và kiểm tra các đầu ra tương ứng để đảm bảo tính đúng đắn và đáp ứng yêu cầu của ứng dụng.

Quy trình thực hiện Black box testing:

Bước 1 – Xác định yêu cầu: Hiểu rõ yêu cầu và mong đợi của ứng dụng từ góc nhìn người dùng cuối. Điều này đảm bảo rằng các ca kiểm thử được tạo ra dựa trên các yêu cầu và chức năng cần kiểm tra.

Bước 2 – Thiết kế kiểm thử: Xác định các kịch bản kiểm thử dựa trên yêu cầu và chức năng của ứng dụng. Xác định các bộ dữ liệu đầu vào và kết quả mong đợi tương ứng cho mỗi kịch bản.

Bước 3 – Lựa chọn ca kiểm thử: Chọn các ca kiểm thử quan trọng và đại diện để đảm bảo việc kiểm thử toàn diện và hiệu quả. Các ca kiểm thử có thể được chọn dựa trên mức độ ưu tiên, tần suất sử dụng và tiềm năng gây lỗi.

Bước 4 – Chuẩn bị dữ liệu: Chuẩn bị dữ liệu đầu vào cần thiết cho các ca kiểm thử. Dữ liệu này phải phù hợp với yêu cầu và điều kiện biên của ứng dụng.

Bước 5 – Thực hiện kiểm thử: Thực hiện các ca kiểm thử dựa trên kịch bản đã thiết kế và sử dụng dữ liệu đầu vào đã chuẩn bị. Ghi lại kết quả kiểm thử và các lỗi phát hiện được.

Bước 6 – Đánh giá kết quả: Đánh giá kết quả kiểm thử và so sánh với kết quả mong đợi.

BLACK BOX TEST (Kiểm tra hộp đen)

Định nghĩa

Kiểm tra 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 vào cấu trúc nội bộ hoặc hoạt động của nó. Mục đích chính của kiểm tra hộp đen chỉ là để xem phần mềm có hoạt động như dự kiến trong tài liệu yêu cầu và liệu nó có đáp ứng được sự mong đợi của người dùng hay không.

Đặc điểm

  • Đây là kiểu kiểm thử thành phần phần mềm (TPPM) và chỉ dựa vào các thông tin đặc tả về yêu cầu, chức năng của TTPM tương ứng.
  • Việc kiểm thử được thực hiện bên ngoài, không liên quan đến nhà phát triển phần mềm. Vì thế người kiểm thử cũng không cần thiết phải biết về cấu trúc bên trong của TPPM cũng như các kiến thức về lập trình.
  • Mức test này thường yêu cầu các tester phải viết test case đầy đủ trước khi test; Các bước tiến hành test khá đơn giản, chỉ cần thực hiện theo các mô tả trong test case, thực hiện nhập dữ liệu vào, đợi kết quả trả về và so sánh với kết quả dự kiến trong test case.

Đối tượng được kiểm thử

Là thành phần phần mền (TPPM) có thể là 1 hàm chức năng, 1 modul chức năng, 1 phân hệ chức năng.

Phương pháp thử nghiệm

Black box test được sử dụng thích hợp nhất trong kiểm thử hệ thống (System test) và Kiểm thử chấp nhận (Acceptance test). Ngoài ra kiểu test này còn được sử dụng trong nhiều cấp độ khác của kiểm thử phần mềm như : Kiểm thử đơn vị, kiểm thử tích hợp,….

Tạo test case và Thực hiện test case

  • Khi viết test case: Dựa vào yêu cầu và giao diện bên ngoài của chương trình (Không can thiệp vào bên trong code của chương trình)
  • Khi thực hiện test: Thực hiện trên giao diện của chương trình (yêu cầu chương trình phải chạy được mới test được, không can thiệp vào code)
[Lesson 4]-  Blackbox và các kỹ thuật thiết kế test case cơ bản
[Lesson 4]- Blackbox và các kỹ thuật thiết kế test case cơ bản

Tạm kết

Với những thông tin trên đây, chắc hẳn các bạn đã có cho mình câu trả lời thỏa đáng cho câu hỏi “Black box testing là gì?”. Nếu như muốn phát triển website của mình, đừng quên theo dõi các bài viết trong chuyên mục Blog của Stringee nhé!

Stringee API cung cấp các tính năng như gọi thoại, gọi video, tin nhắn chat, SMS hay tổng đài chăm sóc khách hàng (CSKH) có thể được nhúng trực tiếp vào các ứng dụng/website của doanh nghiệp nhanh chóng. Điều này giúp tiết kiệm đến 80% thời gian và chi phí cho doanh nghiệp, trong khi nếu tự phát triển các tính năng này có thể mất từ 1 – 3 năm.

  • Tổng đài: (028) 7303 6066
  • Vào Quản lý

Trong lĩnh vực khoa học công nghệ, điện toán và kỹ thuật thì hộp đen được hiểu là một thiết bị, hệ thống hoặc là đối tượng được xem xét theo các yếu tố đầu vào và đầu ra của nó. Không có bất cứ kiến thức nào về hoạt động bên trong của nó. Để có thể hiểu chi tiết hơn về Black Box là gì và Black Box Testing là gì, cùng chúng tôi lý giải ở bài viết dưới đây nhé!

Hộp đen là tên gọi của 1 loại thiết bị lưu trữ thông tin dữ liệu thường được gắn trên các phương tiện giao thông. Chúng được thiết kế đặc biệt phù hợp riêng với các loại phương tiện khác nhau.

Khi nói tới hộp đen Black Box là gì có nghĩa là nhắc tới 1 chiếc hộp viễn thông có chứa toàn bộ các tính năng kỹ thuật cần thiết để kết nối Internet. Đồng thời theo dõi, phát hiện cũng như ghi lại lịch sử toàn bộ dữ liệu của chiếc xe, tàu thủy, máy bay mà nó thu thập, lưu trữ và truyền tải cơ sở dữ liệu.

Bộ lưu chuyến bay gồm có 2 thiết bị thường được tích hợp làm 1 bộ lưu trữ dữ liệu chuyến bay (fight data recorder-FDR) và cockpit voice recorder-CVR (bộ ghi âm buồng lái). Những thiết bị này thường được gọi là hộp đen.

Kiểm thử hộp đen là 1 phương pháp kiểm thử phần mềm được thực hiện không biết được cấu tạo bên trong chúng. Đây là cách mà tester sử dụng để kiểm tra xem hệ thống như 1 chiếc hộp đen khi không có cách nào nhìn thấy bên trong của nó. Quá trình đó còn được gọi là kiểm thử hướng dữ liệu hoặc kiểm thử hướng in/out.

Những người kiểm thử nên xây dựng các nhóm giá trị đầu vào mà mình sẽ thực thi đầy đủ các yêu cầu về chức năng của chương trình. Cách thức mà các tester tiếp cận với hệ thống đó là không sử dụng bất kỳ một kiến thức về cấu trúc lập trình bên trong hệ thống. Khi sử dụng Black Box, người dùng hãy xem hệ thống là 1 cấu trúc hoàn chỉnh và không thể can thiệp vào bên trong.

Black Box Testing được thực hiện chủ yếu trong Function test và System test. Sở dĩ phương pháp này được đặt tên như vậy do các chương trình phần mềm trong con mắt của các tester giống như 1 hộp đen. Bên trong đó không thể nhìn thấy được, vì vậy phương pháp này cố gắng tìm ra các lỗi trong những loại sau:

Black Box Testing là kiểu kiểm thử thành phần phần mềm (TPPM) và chỉ dựa vào những thông tin đặc tả yêu cầu và chức năng của TTPM tương ứng. Công việc kiểm thử được thực hiện bên ngoài và không liên quan tới các nhà phát triển phần mềm. Vì vậy, người kiểm thử không nhất thiết phải biết về cấu trúc bên trong của TPPM cũng như có nhiều kiến thức về lập trình.

Mức test này thường yêu cầu các tester phải viết test case một cách đầy đủ trước. Các bước thực hiện việc test hộp đen khá đơn giản, chỉ cần làm theo các mô tả trong phần test case. Tiến hành nhập dữ liệu và đợi kết quả trả về. Sau đó so sánh với các kết quả dự kiến trong phần test case.

Đối tượng được kiểm thử hộp đen là thành phần của phần mềm TPPM có thể là: 1 hàm chức năng, 1 phân hệ chức năng hoặc 1 modul chức năng.

Bất kỳ một kỹ thuật nào cũng có ưu điểm và nhược điểm của nó, Black Box Testing cũng không phải ngoại lệ. Các hệ thống phải được sử dụng rất nhiều phương pháp kiểm thử khác nhau để có thể đảm bảo chất lượng của hệ thống khi tới tay người dùng.

Những tester được thực hiện từ quan điểm của người dùng và sẽ giúp đỡ họ trong việc làm sáng tỏ sự chênh lệch về thông số kỹ thuật. Phương pháp Black Box không có mối ràng buộc nào với code và nhận thức của một testet vô cùng đơn giản đó là: một source code có rất nhiều lỗi. Lúc này, bạn hãy sử dụng nguyên tắc “Hỏi và bạn sẽ nhận” những tester hộp đen sẽ tìm được nhiều bug ở nơi mà các dev không tìm thấy.

Các tester có thể không phải là IT chuyên nghiệp và không cần phải biết ngôn ngữ lập trình hoặc làm sao các phần mềm được thực hiện. Những tester còn có thể được thực hiện bởi 1 cơ quan độc lập từ các developer, cho phép người dùng có cái nhìn khách quan và tránh được sự phát triển thiên vụ. Toàn bộ yêu cầu của hệ thống sẽ được kiểm thử một cách chính xác. Thiết kế kịch bản nhanh ngay cả khi các yêu cầu chức năng được xác định.

Toàn bộ dữ liệu đầu vào yêu cầu 1 khối lượng mẫu (sample) khá là lớn. Rất nhiều dự án không có các thông số rõ ràng thì việc thiết kế test case sẽ vô cùng khó khăn. Do đó người dùng sẽ khó khăn hơn trong việc viết kịch bản kiểm thử. Lúc này bạn cần phải xác định toàn bộ các yếu tố đầu vào và thiếu cả thời gian cho quá trình tập hơn này.

Khả năng bản thân các kỹ sư lạc lối trong quá trình kiểm thử là rất cao. Chỉ có 1 số lượng nhỏ các đầu vào có thể được kiểm tra và rất nhiều đường dẫn chương trình sẽ được để lại chưa được check.

Black box test được dùng thích hợp nhất trong việc kiểm thử hệ thống (System test) và Acceptance test (kiểm thử chấp nhận). Bên cạnh đó kiểu test này còn được sử dụng trong nhiều cấp độ khác nhau như là: kiểm thử đơn vị, kiểm thử tích hợp.

Dưới đây, chúng tôi xin giới thiệu một số kỹ thuật trong kiểm thử hộp đen, cùng theo dõi nhé!

Với những thông tin trên đây, chắc hẳn các bạn đã có cho mình câu trả lời thỏa đáng cho câu hỏi: Black box là gì và Black box test là gì? Nếu như muốn phát triển website của mình, đừng quên theo dõi các bài viết tiếp sau của BKHOST để hiểu hơn về các dịch vụ hỗ trợ hữu ích như dịch vụ host giá rẻ, dịch vụ VPS.. của chúng tôi nhé!

Thuê Server Vật Lý tại BKHOST

Giảm giá cực sâu, chất lượng hàng đầu. Đăng ký ngay hôm nay:

Kỹ thuật kiểm thử hộp đen – Black box Testing

Bài đăng này đã không được cập nhật trong 2 năm

Khác Nhau Giữa Kiểm Thử Hộp Đen Và Hộp Trắng

1. Định nghĩa – Kiểm tra hộp đen là phương pháp thử nghiệm phần mềm được ѕử dụng để đánh giá những phần mềm mà không quan tâm tới cấu trúc bên trong của chương trình. – Kiểm tra hộp trắng là phương pháp 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.
2. 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.
3. Cấp độ teѕt ѕử dụng – Thử nghiệm áp dụng ở cấp độ cao như: đánh giá hệ thống (Sуѕtem teѕt), kiểm tra chấp nhận (Acceptance teѕt) – Thử nghiệm được áp dụng ở mức độ thấp hơn như thử nghiệm đơn ᴠị (Unit Teѕt), thử nghiệm hội nhập (Integration teѕt)
4. 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.
5. 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.
6. 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
Hướng dẫn làm bài tập chương 4- Black-Box Test Techniques
Hướng dẫn làm bài tập chương 4- Black-Box Test Techniques

Bài Tập Kiểm Thử Hộp Đen

Câu hỏi: Một máy in có thể in tối đa là 300 nhãn vở 1 lần và tối đa 100 nhãn/1trang. Để thực hiện in, người dùng cần nhập số nhãn vở muốn in trên 1 trang vào máy.

Nếu mà nó hoạt động theo nguyên tắc là 1 trang phải đầy thì mới in sang trang tiếp theo được thì chỉ cần nhập

Positive: 1, 100, 101, 200, 201, 300

Negative: 0, 301

=> 8 lần thử.

Nếu mà 3 trang hoạt động độc lập (giả sử in 3 nhãn thì mỗi trang in một nhãn cũng được) thì nhập vào từng trang.

Positive: 1, 100

Negative: 0, 101

=> 4 mẫu này cho mỗi trang.

Mình chưa được học phân vùng tương đương với giá trị biên nên chỉ nghĩ ra được vậy chứ ko có công thức gì cả.

Tìm hiểu về Black box testing (Kiểm thử hộp đen)

Bài đăng này đã không được cập nhật trong 5 năm

Chào các bạn,lại là mình đây .Trong bài viết lần này, mình sẽ giới thiệu cho các bạn những kỹ thuật kiểm thử đầu tiên và gần như đây là những kỹ thuật quan trọng nhất bạn cần phải nắm chắc nếu bạn muốn theo ngành kiểm thử phần mềm. Bắt đầu thôi nào

Nhược điểm của kiểm thử hộp đen

  • Dữ liệu đầu vào yêu cầu một khối lượng mẫu (sample) khá lớn

  • Nhiều dự án không có thông số rõ ràng thì việc thiết kế test case rất khó và do đó 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.

  • Chỉ có một số nhỏ các đầu vào có thể được kiểm tra và nhiều đường dẫn chương trình sẽ được để lại chưa được kiểm tra.

  • Kiểm thử black box được xem như “là bước đi trong mê cung tối đen mà không mang đèn pin” bởi vì tester không biết phần mềm đang test đã được xây dựng như thế nào. Có nhiều trường hợp khi một tester viết rất nhiều trường hợp test để kiểm tra một số thứ có thể chỉ được test bằng một trường hợp test và/hoặc một vài phần cuối cùng không được test hết.

Kiểm thử và Đảm bảo chất lượng phần mềm: Kỹ thuật kiểm thử hộp đen -  phân lớp tương đương
Kiểm thử và Đảm bảo chất lượng phần mềm: Kỹ thuật kiểm thử hộp đen – phân lớp tương đương

Flow của Black box Testing

Hình 1: Phase test trong công đoạn test

4.Nội dung công việc trong công đoạn test

  • Công đoạn test có lần lượt các phase sau: Kế hoạch test, thiết kế test, tạo testcase, thực hiện test, báo cáo test.
  • Trong đó: “kế hoạch test” và “thiết kế test” là phase quan trọng để phát hiện ra lỗi và xác nhận chất lượng.

4.Nội dung công việc trong công đoạn test

Kế hoạch test: Chỉ ra rõ ràng mục đích và phạm vi của công đoạn test để kiểm tra xem là test bằng approach như thế nào. Điều chỉnh resource thành viên và quyết định cả schedule.

Thiết kế test: Quyết định xem là sẽ sử dụng cái gì cho mục đích và loại test càn được thực hiện trong công đoạn test đó, chức năng đối tượng test, phương pháp test, import và export test. Ngoài ra cũng quyết định cụ thể hơn nguyên liệu cần thiết để thực hiện test hay tiêu chuẩn quyết định thành công/ không thành công.

Tạo testcase: Tạo document ghi trạng thái trước khi bắt đầu test và kết quả mong đợi (kết quả chạy đối tượng test theo điều kiện và trình tự thao tác khi thực hiện test sẽ như thế nào) và cột trạng thái (cột ghi lại kết quả thao tác của đối tượng test).

Thực hiện test: Vừa xem testcase vừa cho chạy phần mềm thực tế để tiến hành test, sau đó đánh dấu kết quả bằng dấu pass hoặc fail vào cột trạng thái testcase. Trường hợp có testcase khác với kết quả mong đợi thì ghi dấu fail vào cột trạng thái, rồi tạo bản báo cáo lỗi. Trong bản báo cáo lỗi: trình bày nội dung mô tả hiện tượng khác với kết quả mong đợi và hiện tượng đó phát sinh trong trường hợp như thế nào (thao tác, giả nhập, điều kiện,…)

Báo cáo test: Tóm tắt kết quả để báo cáo. Căn cứ vào các loại dữ liệu (mục thực hiện, hiệu quả của việc test, công số thực hiện,…) và dữ liệu lỗi (số lỗi được tìm ra, số lỗi theo mức độ quan trọng,…) để đánh giá xem có thỏa mãn tiêu chuẩn pass/ fail của test không? Ngoài ra cũng đề xuất thêm risk có thể sinh ra sau khi release và mục cần bổ sung trong dự án cho giai đoạn tiếp theo.

4.Flow của Test plan và thiết kế test

Hình 2: Flow kế hoạch test và thiết kế test
(1) Xác nhận mục đích của test
  • Xem bản kế hoạch tổng thể test để xác nhận mục đích của test(đặc tính chất lượng, những điểm quan trọng …).
  • Quyết định phạm vi của test, nội dung của test, phương pháp test.
(2) Tạo danh sách chức năng
  • Đưa ra toàn bộ chức năng làm đối tượng test.
  • Cần hiểu trước về phần lớn các hoạt động của chức năng.
  • Không phán đoán đối tượng hoặc phi đối tượng của test.
(3) Đưa ra qua điểm test
  • Quan điểm test là ” cánh cửa của Test “.
  • Ví dụ: Xác nhận sự chính xác của kết quả tính toán được hiển thị trên màn hình, xác nhận chức năng check mục nhập, xác nhận thời gian xử lý ==> quan điểm test.
  • Quan điểm test đã đáp ứng được đúng mục đích test?
(4) Phân chia chức năng cho từng quan điểm test
  • Áp dụng quan điểm test cho từng chức năng để tránh bị quên.
  • Có thể hình dung việc test một cách cụ thể.
  • Có thể nắm bắt được quy mô test và mức độ quan trọng của các quan điểm test.
(5) Kiểm tra vận dụng phương pháp và kỹ thuật test
  • Tiến hành thiết kế test dối với lần lượt từng kết hợp.
  • Lựa chọn và quyết định phương pháp test có thể phát hiện ra lỗi một cách hiệu quả nhất từ một trong số các phương pháp test.
Các mục kiểm tra khác
  • Resouce cần thiết.
  • Schedule.
  • Cơ cấu & tổ chức, vai trò khi thực hiện test.
  • Thiết bị, môi trường, địa điểm làm việc cần để thực hiện test.

Kiểm Thử Hộp Đen Là Gì

Kiểm thử hộp đen: là 1 phương pháp kiểm thử phần mềm được thực hiện mà không biết được cấu tạo bên trong của phần mềm, là cách mà các tester kiểm tra xem hệ thống như một chiếc hộp đen, không có cách nào nhìn thấy bên trong của cái hộp.

  • Nó còn được gọi là kiểm thử hướng dữ liệu hay là kiểm thử hướng in/out.
  • Người kiểm thử nên xây dựng những nhóm giá trị đầu vào mà sẽ thực thi hầu hết đa số các yêu cầu chức năng của chương trình.
  • Cách tiếp cận của những tester đối với hệ thống là không dùng bất kỳ một kiến thức về cấu trúc lập trình bên trong hệ thống, xem hệ thống là 1 cấu trúc hoàn chỉnh, không thể can thiệp vào bên trong.

Black Box Testing chủ yếu là được thực hiện trong Function test và System test.

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ông thể 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.

Mọi kỹ thuật nào cũng có ưu điểm và nhược điểm của nó. Các hệ thống thường phải được sử dụng nhiều phương pháp kiểm thử khác nhau để bảo đảm được chất lượng của hệ thống khi đến tay người dùng.

ISTQB foundation   Bài 45 Tổng quan Test Technique Black box, White Box, Experience Based
ISTQB foundation Bài 45 Tổng quan Test Technique Black box, White Box, Experience Based

Phương pháp kiểm thử hộp trắng (White box testing)

Kiểm thử hộp trắng (White box testing) là phương pháp kiểm thử phần mềm nhằm kiểm tra thuật toán, cấu trúc code bên trong của sản phẩm. Hộp trắng tượng trưng cho khả năng nhìn xuyên qua lớp vỏ bên ngoài của phần mềm để thấy được hoạt động bên trong của chúng.

Mục đích của White box testing là đảm bảo tất cả các câu lệnh và điều kiện sẽ được thực hiện đúng, kết quả đầu ra như mong đợi. Tester sẽ xác minh luồng hoạt động cho ứng dụng bằng cách kiểm tra một loạt đầu vào (Input) đã được xác định từ trước có dẫn đến đầu ra (Output) như dự kiến không? Nếu Output không khớp với kỳ vọng, có nghĩa là sản phẩm đang bị lỗi.

Am hiểu về lập trình, có kiến thức về công nghệ thông tin là điều kiện tiên quyết để tester có thể tiến hành kiểm thử hộp trắng. Thông thường, nhiệm vụ thực thi White box Testing sẽ do chính các Developers đảm nhiệm.

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

Các loại kiểm thử hộp đen

Kiểm thử hộp đen bao gồm 3 loại: Functional testing (Kiểm thử chức năng), Non-Functional testing (Kiểm thử phi chức năng) và Regression testing (Kiểm thử hồi quy).

  • Functional testing kiểm tra chức năng của ứng dụng đó có hoạt động đúng như khách hàng mong đợi không.
  • Non-Functional testing xem xét các hành vi bên ngoài của phần mềm dựa trên kinh nghiệm người dùng và mong đợi của khách hàng để kiểm tra phản hồi của hệ thống.
  • Regression testing kiểm tra lại tính năng đã hoàn thiện nhằm chắc chắn rằng phần tính năng mới được thêm vào không phá hỏng các phần khác của ứng dụng.

Regression testing là một loại kiểm thử thuộc Black box testing.

ISTQB - 12 - Test Techniques - Blackbox - Decision Table - Bảng Quyết Định
ISTQB – 12 – Test Techniques – Blackbox – Decision Table – Bảng Quyết Định

Công cụ sử dụng Black Box Testing

Các công cụ được sử dụng để kiểm thử hộp đen phần lớn phụ thuộc vào loại kiểm thử hộp đen mà bạn đang thực hiện.

Đối với chức năng / kiểm thử hồi quy(Regression) – QTP (HP QuickTest Professional ), Selenium
Đối với các bài kiểm tra phi chức năng, bạn có thể sử dụng – LoadRunner , Jmeter

Hi vọng bài viết trên giúp bạn hiểu hơn về Black Box test

Ngoài ra bạn có thể tham khảo thêm các bài viết khác tại trang https://kb.pavietnam.vn cũng như các ưu đãi liên quan tới sản phẩm dịch vụ tại P.A Việt Nam

Tham khảo các ưu đãi: https://www.pavietnam.vn/vn/tin-tuc-chuong-trinh-khuyen-mai-ten-mien-hosting.html

Trong quá trình kiểm thử phần mềm, Black box testing (kiểm thử hộp đen) đã trở thành một phương pháp quan trọng để đánh giá tính hoạt động và chức năng của một ứng dụng. Khác với White box testing, Black box testing tập trung vào việc kiểm tra ứng dụng từ góc độ người dùng mà không quan tâm đến cấu trúc hay cách thức triển khai bên trong.

BLACK BOX TEST (Kiểm tra hộp đen)

Định nghĩa

Kiểm tra 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 vào cấu trúc nội bộ hoặc hoạt động của nó. Mục đích chính của kiểm tra hộp đen chỉ là để xem phần mềm có hoạt động như dự kiến trong tài liệu yêu cầu và liệu nó có đáp ứng được sự mong đợi của người dùng hay không.

Đặc điểm

  • Đây là kiểu kiểm thử thành phần phần mềm (TPPM) và chỉ dựa vào các thông tin đặc tả về yêu cầu, chức năng của TTPM tương ứng.
  • Việc kiểm thử được thực hiện bên ngoài, không liên quan đến nhà phát triển phần mềm. Vì thế người kiểm thử cũng không cần thiết phải biết về cấu trúc bên trong của TPPM cũng như các kiến thức về lập trình.
  • Mức test này thường yêu cầu các tester phải viết test case đầy đủ trước khi test; Các bước tiến hành test khá đơn giản, chỉ cần thực hiện theo các mô tả trong test case, thực hiện nhập dữ liệu vào, đợi kết quả trả về và so sánh với kết quả dự kiến trong test case.

Đối tượng được kiểm thử

Là thành phần phần mền (TPPM) có thể là 1 hàm chức năng, 1 modul chức năng, 1 phân hệ chức năng.

Phương pháp thử nghiệm

Black box test được sử dụng thích hợp nhất trong kiểm thử hệ thống (System test) và Kiểm thử chấp nhận (Acceptance test). Ngoài ra kiểu test này còn được sử dụng trong nhiều cấp độ khác của kiểm thử phần mềm như : Kiểm thử đơn vị, kiểm thử tích hợp,….

Tạo test case và Thực hiện test case

  • Khi viết test case: Dựa vào yêu cầu và giao diện bên ngoài của chương trình (Không can thiệp vào bên trong code của chương trình)
  • Khi thực hiện test: Thực hiện trên giao diện của chương trình (yêu cầu chương trình phải chạy được mới test được, không can thiệp vào code)
ISTQB - 10 - Test Techniques - Blackbox - Equivalence Partitioning - Phân Vùng Tương Đương
ISTQB – 10 – Test Techniques – Blackbox – Equivalence Partitioning – Phân Vùng Tương Đương

Tại sao cần phải thực hiện Black box testing?

Ý nghĩa của việc Black box testing trong quá trình phát triển phần mềm:

  • Phát hiện lỗi không mong muốn: Black box testing giúp phát hiện các lỗi, sự cố và điểm yếu của ứng dụng từ góc nhìn của người dùng cuối mà không cần biết chi tiết về cấu trúc nội bộ của nó. Điều này giúp đảm bảo rằng ứng dụng hoạt động đúng theo yêu cầu và đáp ứng mong đợi của người dùng.
  • Đảm bảo tính tương tác và trải nghiệm người dùng: Black box testing tập trung vào giao diện và tương tác với người dùng. Qua việc kiểm tra hành vi bên ngoài của ứng dụng, nó đảm bảo tính tương tác mượt mà, đáp ứng nhanh chóng và trải nghiệm người dùng tốt.
  • Độc lập với cấu trúc nội bộ: Black box testing không quan tâm đến cách hoạt động bên trong ứng dụng, giúp giữ cho quá trình kiểm thử độc lập với cấu trúc nội bộ và phân tách rõ ràng giữa vai trò người kiểm thử và nhà phát triển.
  • Phù hợp với các công ty phát triển phần mềm lớn: Trong các dự án phức tạp và lớn, việc có một nhóm riêng biệt chịu trách nhiệm kiểm thử ứng dụng theo phương pháp Black box testing giúp đảm bảo tính chuyên nghiệp và độc lập của quá trình kiểm thử.
  • Tiết kiệm thời gian và nguồn lực: Black box testing cho phép những người không phải là nhà phát triển thực hiện kiểm thử mà không cần biết chi tiết về mã nguồn. Điều này giúp tiết kiệm thời gian và nguồn lực cho việc phát triển và kiểm thử phần mềm.

Như vậy, Black box testing đóng vai trò quan trọng trong việc đảm bảo chất lượng phần mềm bằng cách phát hiện lỗi, đảm bảo tính tương tác và trải nghiệm người dùng tốt, và độc lập với cấu trúc nội bộ. Nó giúp cải thiện đáng kể sự tin cậy và hiệu quả của ứng dụng trước.

Black box testing là gì?

Black box testing (Kiểm thử hộp đen) là một phương pháp kiểm thử phần mềm tập trung vào việc kiểm tra hành vi bên ngoài của một ứng dụng mà không quan tâm đến cấu trúc nội bộ hay chi tiết cài đặt của nó. Trong Black box testing, người kiểm thử chỉ xem ứng dụng như một “hộp đen” và tập trung vào đầu vào và đầu ra của ứng dụng, cũng như các tình huống và điều kiện biên.

So với các phương pháp kiểm thử khác, Black box testing có những ưu điểm như độc lập với cấu trúc nội bộ, tập trung vào hành vi người dùng và dễ thực hiện bởi những người không cần biết chi tiết về mã nguồn. Tuy nhiên, nó có hạn chế là không tiết lộ các lỗi nội bộ và không thể kiểm tra được mọi khía cạnh của ứng dụng. Do đó, sự kết hợp với các phương pháp khác như White box testing và Gray box testing sẽ mang lại kết quả kiểm thử toàn diện và đáng tin cậy hơn.

Cụ thể:

White box testing (Kiểm thử hộp trắng): Khác với Black box testing, White box testing tập trung vào kiểm tra cấu trúc nội bộ của ứng dụng, bao gồm việc kiểm tra mã nguồn, biến đổi dữ liệu và luồng điều khiển. Người kiểm thử có kiến thức về cấu trúc nội bộ để lựa chọn các ca kiểm thử phù hợp.

Gray box testing (Kiểm thử hộp xám): Gray box testing kết hợp cả hai phương pháp black box và White box testing. Người kiểm thử có một số thông tin về cấu trúc nội bộ của ứng dụng, nhưng không hoàn toàn biết rõ chi tiết. Điều này cho phép họ tạo ra các ca kiểm thử dựa trên cả góc nhìn bên ngoài và bên trong của ứng dụng.

Kỹ thuật thiết kế TestCase cơ bản - Bài 1 - Phân lớp tương đương, giá trị biên
Kỹ thuật thiết kế TestCase cơ bản – Bài 1 – Phân lớp tương đương, giá trị biên

Quy trình kiểm thử hộp đen

Quy trình kiểm thử hộp đen có thể áp dụng theo 4 bước: Lập kế hoạch kiểm thử, thiết kế Test Case, thực hiện test và báo cáo kiểm thử.

Lập kế hoạch test

Tester tiến hành phân tích yêu cầu và lập tài liệu tổng quan về việc kiểm thử dự án bao gồm những thông tin sau:

  • Phạm vi kiểm thử, hướng tiếp cận, quy trình kiểm thử, tài nguyên và nhân lực test.
  • Các chức năng/module cần được kiểm tra; các công cụ và môi trường kiểm thử cần có.
  • Ai test chức năng nào? – Khi nào bắt đầu thực hiện viết và hoàn thành test case? – Khi nào bắt đầu thực hiện và hoàn thành test?

Lập kế hoạch test là bước đầu của kiểm thử hộp đen

Thiết kế Test case

Sau khi có được Test Plan, Tester bắt đầu xây dựng bộ Test Case dựa trên yêu cầu của phần mềm. Test Case cần mô tả được chi tiết dữ liệu đầu vào, hành động, kết quả mong đợi để xác định một chức năng của ứng dụng phần mềm có hoạt động đúng hay không.

Template của Test Case có nhiều trường hợp nhưng bắt buộc phải có 5 mục chính: ID, mục đích kiểm thử, các bước thực hiện, kết quả mong đợi & kết quả thực tế.

Thực hiện kiểm thử

Khi developers đã code và đưa sản phẩm lên môi trường kiểm thử, tester sẽ thực thi dựa trên Test Case đã viết. Trong quá trình test, nếu phát hiện ra bug (lỗi) thì tester sẽ log (viết) lên các tool quản lý lỗi. Bug của lập trình viên nào sẽ giao lại cho người đấy xử lý. Khi nào developers fix bug xong, tester sẽ nhận lại và tiến hành kiểm thử.

Báo cáo kiểm thử

Ở giai đoạn này, tester chuẩn bị báo cáo kết thúc kiểm thử, tổng hợp lại các chỉ số trong quá trình test. Cả team phát triển sẽ ngồi họp để đánh giá toàn bộ các tiêu chí xác định có thể kết thúc quy trình kiểm thử hay chưa. Những tiêu chí này khác nhau tùy theo từng dự án, thông thường bao gồm:

  • Số lượng test case tối đa được thực thi Passed.
  • Tỷ lệ lỗi giảm xuống dưới mức nhất định.
  • Deadline được chốt từ giai đoạn làm kế hoạch kiểm thử.

Kết luận

Qua các thông tin chia sẻ trên, các tester cũng đã hiểu rõ hơn về kiểm thử hộp đen để lựa chọn cho mình hướng đi trong tương lai. Ưu điểm của kiểm thử hộp đen chính là các tester không cần có nền tảng công nghệ thông tin đều có thể thực hiện test được. Đặc biệt, 4 kỹ thuật kiểm thử hộp đen giúp Manual tester xử lý được các bộ Test Case chất lượng.

Mở rộng ngay cơ hội việc làm Tester tại ITNavi – Nền tảng kết nối việc làm IT với hơn 1000++ jobs cập nhật mỗi ngày.

Xem thêm:

1000 việc làm IT tại Nền tảng kết nối việc làm ITNavi

6 giai đoạn của quy trình kiểm thử phần mềm

Từ A-Z về kiểm thử hộp trắng

ITNavi – Nền tảng kết nối việc làm IT

Nguồn: Từ A – Z về kiểm thử hộp đen dành cho Manual Tester – ITNavi

Xin các bạn giúp mình với.

Thanks.

Tạm thời forum ngưng nhận đăng ký tài khoản mới. vui lòng tham khảo thêm bài viết mới ở đây >> Testing VN Hoặc xem lịch khai giảng khoá mới tại đây fb/testingvn

Không thể bắt đầu code khi chưa có tài liệu thiết kế. Có thể là do thiết kế chưa tốt nên phải thay đổi.trongnhantvu wrote:Tại sao các lập trình viên thường hay bắt đầu công việc lập trình quá sớm, khi chưa hoàn tất việc thiết kế hệ thống và modun. Những vấn đề nảy sinh?

Việc tạo test plan (kế hoạch kiểm thử) là không phải do lập trình viên làm, mà là do QC Leader của dự án lập ra. Sau đó trình lên cho Projet Leader hoặc Project Manager xem, trong test plan có mô tả phạm vi, chức năng nào sẽ phải test, phần nào sẽ không test, chức năng nào cần phải test cái gì – ví dụ test giao diện, chức năng, hiệu năng,…trongnhantvu wrote:Tại sao lập trình viên phải đặt kế hoạch kiểm thử modun trước khi viết chương trình?

Các phương pháp kiểm thử phần mềm và sự khác biệt? – ITNavi

Kiểm thử phần mềm là công việc nhằm đảm bảo hoạt động của sản phẩm đúng theo yêu cầu khách hàng. Công việc này được phân loại thành 3 hình thức: Kiểm thử hộp trắng, kiểm thử hộp đen và kiểm thử hộp xám. Tuy chỉ có 3 phương thức nhưng không phải tester nào cũng nắm được sự khác biệt giữa chúng. Tại bài viết này, ITNavi sẽ so sánh các phương pháp kiểm thử phần mềm để các tester hiểu được rõ ràng.

So sánh các phương pháp kiểm thử phần mềm.

Các bước kiểm thử hộp đen

Dưới đây là các bước làm chung để thực hiện kỹ thuật kiểm thử hộp đen:

  • Kiểm tra sơ bộ yêu cầu và đặc tả của hệ thống.
  • Chọn các giá trị đầu vào hợp lệ để xác định xem phần mềm có hoạt động đúng hay không. Đồng thời chúng ta cũng chọn cả các giá trị không hợp lệ để kiểm tra các thông báo lỗi của hệ thống.
  • Tester xác định các kết quả mong đợi của đầu ra tương ứng với các giá trị đầu vào.
  • Xây dựng testcase hoặc test checklist tương ứng với các giá trị đầu vào và đầu ra đã chọn.
  • Thực hiện chạy các testcase.
  • So sánh các kết quả thực tế khi chạy trên hệ thống so với kết quả mong đợi.
  • Log bug lên hệ thống quản lý lỗi ( nếu tìm thấy lỗi).
Chia sẻ về kiểm thử hộp trắng hộp đen | 2 loại kiểm thử căn bản trong phần mềm #testmentor #manual
Chia sẻ về kiểm thử hộp trắng hộp đen | 2 loại kiểm thử căn bản trong phần mềm #testmentor #manual

Tài liệu tham khảo

All rights reserved

Từ A – Z về kiểm thử hộp đen dành cho Manual Tester – ITNavi

Kiểm thử hộp đen là kỹ thuật kiểm thử được các tester sử dụng phổ biến nhất hiện nay. Không cần có kiến thức chuyên sâu về IT, những người trái ngành vẫn có thể chuyển sang làm tester được ở mảng trên. Vậy kiểm thử hộp đen là gì? Cùng ITNavi tìm hiểu tất tần tật thông tin tại bài viết dưới đây nhé!

Kiểm thử hộp đen là xu hướng nghề nghiệp của các tester trái ngành.

Các phương pháp được sử dụng trong Black box testing

Có nhiều kỹ thuật và phương pháp được sử dụng trong Black box testing để đảm bảo việc kiểm thử toàn diện và hiệu quả. Dưới đây là một số kỹ thuật và phương pháp phổ biến:

Equivalence Partitioning (Phân loại tương đương): Kỹ thuật này chia các giá trị đầu vào thành các nhóm tương đương và chỉ kiểm tra một giá trị trong mỗi nhóm. Điều này giúp giảm số lượng ca kiểm thử cần thực hiện mà vẫn đảm bảo kiểm thử các trường hợp quan trọng.

Boundary Value Analysis (Phân tích giá trị biên): Kỹ thuật này tập trung vào việc kiểm tra các giá trị biên và điều kiện biên của ứng dụng. Kiểm thử được thực hiện với các giá trị gần biên và trên biên để phát hiện lỗi có thể xảy ra.

Decision Table Testing (Kiểm thử bảng quyết định): Phương pháp này sử dụng các bảng quyết định để xác định các điều kiện và hành động tương ứng của ứng dụng. Các ca kiểm thử được tạo dựa trên các kết hợp của các điều kiện và hành động trong bảng quyết định.

State Transition Testing (Kiểm thử chuyển trạng thái): Kỹ thuật này tập trung vào việc kiểm thử các chuyển đổi trạng thái của ứng dụng. Các ca kiểm thử được tạo dựa trên các trạng thái và các sự kiện chuyển trạng thái.

Error Guessing (Đoán lỗi): Phương pháp này dựa trên kinh nghiệm và sự sáng tạo của người kiểm thử để đoán các lỗi có thể xảy ra trong ứng dụng. Các ca kiểm thử được tạo dựa trên các giả định và dự đoán về các điểm yếu tiềm năng của hệ thống.

Exploratory Testing (Kiểm thử khám phá): Phương pháp này tập trung vào việc khám phá và kiểm thử ngẫu nhiên mà không dựa trên kịch bản hay kế hoạch cụ thể. Người kiểm thử sử dụng sự sáng tạo và trực giác để tìm kiếm lỗi và điều kiện biên không dự đoán trước.

Regression Testing (Kiểm thử hồi quy): Phương pháp này đảm bảo rằng các thay đổi trong ứng dụng không gây ảnh hưởng đến các chức năng và tính năng đã được kiểm thử trước đó. Các ca kiểm thử được chọn để tái kiểm tra và đảm bảo tính ổn định của ứng dụng.

Các kỹ thuật và phương pháp này có thể được sử dụng độc lập hoặc kết hợp với nhau để đạt được hiệu quả kiểm thử cao và phát hiện nhiều lỗi tiềm ẩn trong ứng dụng.

Tester là làm gì, Test case, Manual Test, Automation test là làm gì
Tester là làm gì, Test case, Manual Test, Automation test là làm gì

Những thách thức khi thực hiện Black box testing

Black box testing có nhiều ưu điểm, nhưng cũng tồn tại một số hạn chế. Dưới đây là một số hạn chế khi thực hiện Black box testing:

  • Hạn chế độ phủ: Black box testing không thể kiểm tra toàn bộ mã nguồn hay cấu trúc nội bộ của ứng dụng. Do đó, không thể đảm bảo độ phủ kiểm thử cao như White box testing.
  • Khả năng phát hiện lỗi bị giới hạn: Vì không có kiến thức về cấu trúc nội bộ, Black box testing có thể bỏ qua các lỗi nằm sâu trong hệ thống như lỗi logic hoặc lỗi thiết kế.
  • Hiệu suất thấp: Black box testing có thể mất nhiều thời gian và công sức để tạo ra các ca kiểm thử đầy đủ và đáng tin cậy. Việc tìm hiểu và hiểu đúng yêu cầu của ứng dụng cũng đòi hỏi nỗ lực lớn.
  • Không thể kiểm tra các tình huống phức tạp: Trong một số trường hợp, Black box testing có thể gặp khó khăn trong việc kiểm thử các tình huống phức tạp hoặc các kịch bản khó đoán trước được. Điều này có thể làm giảm khả năng phát hiện lỗi.
  • Phụ thuộc vào người kiểm thử: Kết quả kiểm thử Black box phụ thuộc vào khả năng và kinh nghiệm của người kiểm thử. Sự thiếu sót hoặc thiếu kỹ năng của người kiểm thử có thể dẫn đến việc bỏ qua lỗi.

Phương pháp truy xuất và tính cần thiết của quan điểm Test

5.Danh sách quan điểm test

Khái niệm: Danh sách quan điểm test là danh sách tóm tắt quan điểm test theo hình thức có thể tái sử dụng.

  • Có thể thực hiện test hệ thống, mà không phải test nhờ vào kinh nghiệm cá nhân.
  • Có thể giảm nhẹ được sự chênh lệch kỹ năng cá nhân. (chênh lệch giữa người mới và chuyên gia,…).
  • Có thể tránh trùng, hoặc thiếu sót quan điểm phải test.
  • Phán đoán mức độ quan trọng trong dự án dễ dàng.

5.Phương pháp tạo danh sách quan điểm Test

  • Tạo danh sách quan điểm test, phân quan điểm test thành các giai đoạn, tiếp tục phân quan điểm test lớn thành các quan điểm test bé hơn.
  • Nếu có tiêu chuẩn phân loại, thì công việc trở nên dễ dàng hơn.
  • Ví dụ: Lấy các tiêu chí dưới đây làm tiêu chuẩn phân loại.
  • Ví dụ phân loại quan điểm test
  • Ví dụ danh sách quan điểm Test
What is White vs. Grey vs. Black Box Testing?
What is White vs. Grey vs. Black Box Testing?

Kiểm thử hộp đen là gì?

Trái ngược với kiểm thử hộp trắng, kiểm thử hộp đen (Black box testing) là phương pháp test dựa trên đầu vào và đầu ra của chương trình mà không quan tâm tới code bên trong được viết ra sao. Tester sẽ xem phần mềm như là một hộp đen, chỉ nhìn được lớp vỏ bên ngoài mà không nhìn được cấu trúc bên trong.

Ví dụ: Ta có sản phẩm app thương mại điện tử:

  • Kiểm thử hộp trắng sẽ test mã code mà developers đã lập trình tạo nên sản phẩm.
  • Kiểm thử hộp đen sẽ test các chức năng như: Mua sắm, đăng sản phẩm, tạo tài khoản… hoặc hiệu suất làm việc của app.

Ưu điểm của kiểm thử hộp đen chính là các tester không cần có nền tảng công nghệ, không cần biết ngôn ngữ lập trình đều có thể thực hiện test được. Người kiểm thử khi vận dụng Black box testing sẽ là một phương diện độc lập, có cái nhìn khách quan về sản phẩm.

Phương pháp kiểm thử hộp đen sẽ cố gắng tìm ra lỗi ở các vấn đề 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ở bên ngoài, lỗi về hiệu suất…

5.Các kỹ thuật kiểm thử hộp đen

Có rất nhiều phương pháp kiểm thử hộp đen nhưng trong bài viết này, mình sẽ giới thiệu cho các bạn 4 phương pháp quan trọng và phổ biến nhất đó là : Phân vùng tương đương, phân tích giá trị biên, bảng quyết định và đoán lỗi.

5.Phân vùng tương đương

Đây là một kỹ thuật kiểm thử phần mềm liên quan đến việc chia các giá trị đầu vào thành các vùng tương đương hợp lệ và không hợp lệ. Với mỗi miền giá trị , chúng ta sẽ chọn một vài giá trị đại diện làm dữ liệu để test.

Ví dụ : Cho 1 ô textbox yêu cầu nhập password trong [6, 12] kí tự. Trong ví dụ này, chúng ta có thể chia thành các vùng tương đương như sau: Vùng tương đương hợp lệ: 6<= password<= 12 kí tự Vùng tương đương không hợp lệ: <6 kí tự, >12 kí tự và để trống.

Từ đó chúng ta có thể xây dựng được các testcase như sau:

  • Nhập vào password với 10 kí tự.
  • Nhập vào password với 3 kí tự.
  • Nhập vào password với 15 kí tự.
  • Để trống password.

5.Phân tích giá trị biên

Việc lựa chọn các giá trị bất kỳ trong các cùng tương đương hợp lệ và không hợp lệ có thể dẫn tới việc chúng ta sẽ bị lack lỗi ở biên. Do đó phương pháp phân tích giá trị biên được ra đời. Xét với cùng ví dụ bên trên, trong phương pháp này, chúng ta sẽ chọn tập các giá trị biên để làm dữ liệu test như sau:

  • Giá trị lớn nhất
  • Giá trị nhỏ nhất
  • Giá trị lớn nhất + 1
  • Giá trị nhỏ nhất -1
  • Giá trị bình thường

Tương tự chúng ta sẽ được các testcase:

  • Nhập vào password gồm 6 kí tự.
  • Nhập vào password gồm 12 kí tự.
  • Nhập vào password gồm 13 kí tự.
  • Nhập vào password gồm 5 kí tự.
  • Nhập vào password gồm 10 kí tự.

5.Bảng quyết định

Đây là 1 phương pháp khá tốt khi các giá trị đầu vào có nhiều sự kết hợp. Các bước để xây dựng bảng quyết định:

  • Liệt kê tất cả các điều kiện đầu vào.
  • Tính số các trường hợp kết hợp có thể ( Rules).
  • Giảm thiểu các case kết hợp và quyết định các testcase.

Ví dụ: Tạo bảng quyết định cho chức năng Login với 2 điều kiện đầu vào là Email và Password. Mỗi điều kiện đầu vào có 2 kết quả trả về là True hoặc Fail.
Số trường hợp ( Rules) = 2^ (Số điều kiện đầu vào) = 2^2 = 4.
Chúng ta sẽ xây dựng được bảng quyết định như sau:

5.Đoán lỗi

Đây là 1 kỹ thuật kiểm thử mà tester không cần tuân theo 1 luật chung nào , lỗi được tìm ra chủ yếu dựa vào kinh nghiệm của người kiểm thử.

6.Các ưu và nhược điểm của kiểm thử hộp đen

Ưu điểm :

Việc kiểm thử phần mềm trở nên khách quan hơn vì đội kiểm thử và đội phát triển làm việc độc lập.

Tester chỉ thực hiện test dưới cái nhìn của người dùng, dựa hoàn toàn theo bản đặc tả yêu cầu mà không yêu cầu phải hiểu biết về code.

Thiết kế kịch bản kiểm thử nhanh, ngay khi các yêu cầu chức năng được xác định.

Nhược điểm:

  • Tester khó có thể hiểu được cấu trúc chương trình được xây dựng ra sao.
  • Dữ liệu đầu vào là 1 khối lượng mẫu (sample) khá lớn.
  • Khó khăn trong việc xác định các yếu tố đầu vào.
  • Tester dễ bị rơi vào tình trạng khám phá mù, tức là họ sẽ đi tìm những lỗi mà không biết khi nào mới tìm ra.
Bạn có bị lừa ? Iphone Bypass 2023 Bá Đạo cỡ nào - Có giới hạn gì không ?
Bạn có bị lừa ? Iphone Bypass 2023 Bá Đạo cỡ nào – Có giới hạn gì không ?

Ưu điểm và nhược điểm

Bảng sau đây liệt kê các ư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 hầu hết các trường hợp kiểm thử cho hệ thống.

So sánh các phương pháp kiểm thử phần mềm

Để giúp các bạn hiểu rõ hơn về sự khác biệt giữa các phương pháp kiểm thử phần mềm. ITNavi sẽ so sánh 3 phương pháp trên với các tiêu chí: Hành động, đối tượng, mục đích, nhân lực, phân loại, kỹ thuật.

Kiểm thử hộp trắng

Kiểm thử hộp đen

Kiểm thử hộp xám

Hành động

Kiểm tra thuật toán, cấu trúc code bên trong của sản phẩm.

Không quan tâm đến cấu trúc code bên trong, tập trung tìm ra lỗi ở các vấn đề 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ở bên ngoài, lỗi về hiệu suất…

Tìm kiếm và xác định các khiếm khuyết do cấu trúc mã không phù hợp hoặc sử dụng ứng dụng không đúng cách.

Đối tượng kiểm tra

Mã code, câu lệnh

Giao diện, chức năng, hiệu suất…

Cấu trúc mã, cách sử dụng ứng dụng

Mục đích

Đảm bảo tất cả các câu lệnh và điều kiện sẽ được thực hiện đúng, kết quả đầu ra như mong đợi.

Đảm bảo phần mềm hoạt động đúng như dự kiến và đáp ứng được sự mong đợi của khách hàng.

Đảm bảo cấu trúc mã của sản phẩm phù hợp và ứng dụng được sử dụng đúng cách đem lại hiệu quả.

Nhân lực

Thường là Developers

Tester (Không cần có nền tảng IT vẫn có thể test được)

Tester có nền tảng IT

Các loại kiểu thử

Kỹ thuật

Phân tích độ phủ mã (Coverage Testing)

Kết luận

Qua những thông tin trên, các tester cũng đã hiểu rõ về các phương pháp kiểm thử phần mềm trên nhiều phương diện như: Hành động, mục tiêu, kỹ thuật… Nắm chắc về sự khác biệt giữa 3 phương pháp giúp các tester nhận định được hướng đi trong công việc test tương lai.

Mở rộng ngay cơ hội việc làm Tester tại ITNavi – Nền tảng kết nối việc làm IT với hơn 1000++ jobs cập nhật mỗi ngày.

Xem thêm:

1000 việc làm IT tại Nền tảng kết nối việc làm ITNavi

Kiểm thử hộp đen – Kỹ thuật kiểm thử hộp đen

Từ A-Z về kiểm thử hộp trắng

ITNavi – Nền tảng kết nối việc làm IT

Nguồn: Các phương pháp kiểm thử phần mềm và sự khác biệt? – ITNavi

7 Black Box Testing Techniques That Every QA Should know ( Explained with demo)
7 Black Box Testing Techniques That Every QA Should know ( Explained with demo)

3.Các loại kiểm thử hộp đen

Có rất nhiều loại trong phương pháp kiểm thử hộp đen , dưới đây là 1 vài phương pháp nổi bật:

3.1. Kiểm thử chức năng

Đây là loại kiểm thử liên quan đến các yêu cầu chức năng của hệ thống , được thực hiện bởi các kỹ sư kiểm thử phần mềm.

3.2. Kiểm thử phi chức năng

Các loại kiểm thử phi chức năng phổ biến thường là kiểm thử hiệu suất , kiểm thử khả năng mở rộng, kiểm thử tính khả dụng.

3.3. Kiểm thử hồi quy

Là một dạng kiểm thử phần mềm để xác minh rằng phần mềm vốn đã được phát triển và kiểm thử từ trước vẫn sẽ hoạt động chính xác sau khi bị thay đổi hoặc giao tiếp với các phần mềm khác.( Wikipedia)

Mình sẽ lấy ví dụ cho các bạn dễ hiểu hơn về loại kiểm thử này nhé . Ví dụ phần mềm của chúng ta có 3 chức năng là A, B và C đã làm xong và đã được kiểm thử cẩn thận. Nhưng cho đến một ngày đẹp trời, spec của chức năng C bị thay đổi và có lẽ việc sửa ở chức năng C sẽ ít nhiều ảnh hưởng đến chức năng A và B. Do đó, ngoài việc test chức năng C thì chúng ta cũng cần test lại chức năng A và B nữa. Việc test lại các chức năng đã được test rồi như thế này được gọi là kiểm thử hồi quy.

GREY BOX TEST (Kiểm thử hộp xám)

Định nghĩa

Ngoài hai kỹ thuật được nhắc đến bên trên thì có 1 kỹ thuật kiểm thử khác là Grey box test , hay còn gọi là Gray box test nó là sự kết hợp giữa black box test và white box test. Kiểu kiểm thử này còn có tên gọi khác là Gray. Với phương pháp này cấu trúc bên trong sản phẩn được biết một phần.

Phương pháp thử nghiệm

Kiểm thử hộ xám thường được sử dụng trong Kiểm thử tích hợp.Tuy nhiên, dựa vào giải thuật và chức năng, nó cũng có thể được sử dụng ở nhiều mức kiểm thử khác nhau

Tạo testcase và thực hiện test

  • Khi viết test case: Dựa vào yêu cầu và nội dung Source Code (can thiệp vào bên trong Code của chương trình)
  • Khi thực hiện test: Thực hiện trên giao diện của chương trình (yêu cầu chương trình phải chạy được mới test được, không can thiệp vào code)

Trên đây là một số

sự


khác nhau giữa các kiểu kiểm

thử hộp trắng, hộp đen và hộp xám. Mỗi kiểu lại có mục đích và  ưu – nhược điểm khác nhau. Hi vọng bài viết này sẽ giúp ích cho bạn. Nếu bạn quan tâm đến vấn đề kiểm thử hãy tiếp tục theo dõi những bài viết tiếp theo của chúng tôi nhé.

>>

Đọc thêm:


11 công cụ hỗ trợ kiểm thử


Thông thường, có hai kiểu kiểm thử chính : Kiểm tra hộp trắng (White box testing) và kiểm tra hộp đen (Black box testing). Bên cạch đó, chúng ta cũng có một kiểu nữa kết hợp hai kiểu trên, đó là kiểm tra hộp xám (Grey box testing). Bạn có biết chúng được dùng khi nào và sự khác nhau giữa các kiểu kiểm thử này là gì không?? Hãy cùng tìm hiểu với chúng tôi trong bài viết dưới đây.

Equivalence Partitioning In Testing-Boundary Value Analysis In Testing With Example-Software Testing
Equivalence Partitioning In Testing-Boundary Value Analysis In Testing With Example-Software Testing

Khái niệm

Kiểm thử hộp đen: là một phương pháp kiểm thử phần mềm được thực hiện mà không biết được cấu tạo bên trong của phần mềm, là cách mà các tester kiểm tra xem hệ thống như một chiếc hộp đen, không có cách nào nhìn thấy bên trong của cái hộp.

  • Nó còn được gọi là kiểm thử hướng dữ liệu hay là kiểm thử hướng in/out.

  • Người kiểm thử nên xây dựng các nhóm giá trị đầu vào mà sẽ thực thi đầy đủ tất cả các yêu cầu chức năng của chương trình.

  • Cách tiếp cận của các tester đối với hệ thống là không dùng bất kỳ một kiến thức về cấu trúc lập trình bên trong hệ thống, xem hệ thống là một cấu trúc hoàn chỉnh, không thể can thiệp vào bên trong.

Black Box Testing chủ yếu là được thực hiện trong Function test và System test.

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ông thể 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.

Mọi kỹ thuật nào cũng có ưu điểm và nhược điểm của nó. Các hệ thống thường phải được sử dụng nhiều phương pháp kiểm thử khác nhau để đảm bảo được chất lượng của hệ thống khi đến tay người dùng.

Phương pháp kiểm thử hộp đen (Black box testing)

Trái ngược với kiểm thử hộp trắng, kiểm thử hộp đen (Black box testing) là phương pháp test dựa trên đầu vào và đầu ra của chương trình mà không quan tâm tới code bên trong được viết ra sao. Tester sẽ xem phần mềm như là một hộp đen, chỉ nhìn được lớp vỏ bên ngoài mà không nhìn được cấu trúc bên trong.

Ưu điểm của kiểm thử hộp đen chính là các tester không cần có nền tảng công nghệ, không cần biết ngôn ngữ lập trình đều có thể thực hiện test được. Người kiểm thử khi vận dụng Black box testing sẽ là một phương diện độc lập, có cái nhìn khách quan về sản phẩm.

Phương pháp kiểm thử hộp đen sẽ cố gắng tìm ra lỗi ở các vấn đề 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ở bên ngoài, lỗi về hiệu suất…

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

Hạ iOS 14.4 về iOS đã khóa sign bằng Futurerestore có SHSH Blobs
Hạ iOS 14.4 về iOS đã khóa sign bằng Futurerestore có SHSH Blobs

Ưu điểm của kiểm thử hộp đen

  • 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ới code, và nhận thức của một tester rất đơn giản: một source code có nhiều lỗ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.

GREY BOX TEST (Kiểm thử hộp xám)

Định nghĩa

Ngoài hai kỹ thuật được nhắc đến bên trên thì có 1 kỹ thuật kiểm thử khác là Grey box test , hay còn gọi là Gray box test nó là sự kết hợp giữa black box test và white box test. Kiểu kiểm thử này còn có tên gọi khác là Gray. Với phương pháp này cấu trúc bên trong sản phẩn được biết một phần.

Phương pháp thử nghiệm

Kiểm thử hộ xám thường được sử dụng trong Kiểm thử tích hợp.Tuy nhiên, dựa vào giải thuật và chức năng, nó cũng có thể được sử dụng ở nhiều mức kiểm thử khác nhau

Tạo testcase và thực hiện test

  • Khi viết test case: Dựa vào yêu cầu và nội dung Source Code (can thiệp vào bên trong Code của chương trình)
  • Khi thực hiện test: Thực hiện trên giao diện của chương trình (yêu cầu chương trình phải chạy được mới test được, không can thiệp vào code)

Trên đây là một số

sự


khác nhau giữa các kiểu kiểm

thử hộp trắng, hộp đen và hộp xám. Mỗi kiểu lại có mục đích và  ưu – nhược điểm khác nhau. Hi vọng bài viết này sẽ giúp ích cho bạn. Nếu bạn quan tâm đến vấn đề kiểm thử hãy tiếp tục theo dõi những bài viết tiếp theo của chúng tôi nhé.

>>

Đọc thêm:


11 công cụ hỗ trợ kiểm thử

Trong lĩnh vực khoa học công nghệ, điện toán và kỹ thuật thì hộp đen được hiểu là một thiết bị, hệ thống hoặc là đối tượng được xem xét theo các yếu tố đầu vào và đầu ra của nó. Không có bất cứ kiến thức nào về hoạt động bên trong của nó. Để có thể hiểu chi tiết hơn về Black Box là gì và Black Box Testing là gì, cùng chúng tôi lý giải ở bài viết dưới đây nhé!

Danh Mục Bài Viết

Code không bug cùng với Unit Test và Automation Testing - Code Cùng Code Dạo
Code không bug cùng với Unit Test và Automation Testing – Code Cùng Code Dạo

Phương pháp thử nghiệm

Dựa vào chức năng Kiểm thử hộp đen (Black box test) có thể được áp dụng hầu như đến mọi cấp độ của kiểm thử phần mềm:

  • Kiểm thử đơn vị (Unit test)
  • Kiểm thử tích hợp (Intergration test)
  • Kiểm thử hệ thống (System test)
  • Kiểm thử chấp nhận (Acceptance test).

Tuy nhiên, Black box test được sử dụng thích hợp nhất trong kiểm thử hệ thống (System test) và Kiểm thử chấp nhận (Acceptance test)

Ví Dụ Kiểm Thử Hộp Đen

Cho 1 ô test box nhập vào giá trị nguyên từ 1 đến 100

Giải thích:

Áp dụng phân tích giá trị biên vào cho bài toán sẽ có 2 cách lấy giá trí biên là 2 biên và 3 biên.

+ Trường hợp 2 biên (nghĩa là tại mỗi giá trị biên sẽ lấy 2 giá trị) và sẽ có các biên:

  • Tại min: min -1, min
  • Tại max: max, max + 1

Vậy áp dụng cho bài toán ta có các giá trị biên như sau: 0;1;100;101

+ Trường hợp 3 biên (nghĩa là tại mỗi giá trị ta sẽ lấy 3 giá trị) ta sẽ có các biên:

  • Tại min: min -1, min , min + 1
  • Tại max: max – 1, max, max + 1

Vậy áp dụng cho bài toán ta có các giá trị biên như sau: 0;1;2;99;100;101

Chú ý: Thường thì sẽ sử dụng kết hợp 2 kỹ thuật phân vùng tương đương và phân tích giá trị biên cùng với nhau để cho bài toán không bị thiếu case hoặc dư thừa case. Với bài toán trên áp dụng cả phân vùng tương đương và giá trị biên thì cần test các case:

  • Case hợp lệ: 1;50;100
  • Case không hợp lệ: 0;101
Software Testing Methodologies | Software Testing Techniques | Software Testing Tutorial | Edureka
Software Testing Methodologies | Software Testing Techniques | Software Testing Tutorial | Edureka

Đặc điểm Black box test

  • Là chiến lược kiểm thử TPPM dựa vào thông tin duy nhất là các đặc tả về yêu cầu chức năng của TPPM tương ứng.
  • Người kiểm thử không cần thiết phải có kiến thức về việc mã hoá, cấu trúc bên trong của TPPM, cũng như không yêu cầu phải biết lâp trình phần mềm.
  • Việc kiểm thử được tiến hành dựa vào việc kiểm thử TPPM làm được gì, có phù hợp với yêu cầu của người dùng hay không. Các tester nhập số liệu 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 kiểm tra.
  • Mức test này thường yêu cầu các tester phải viết test case đầy đủ trước khi test; khi test, đơn giản chỉ cần thực hiện theo các bước mô tả trong test case thao tác và nhập data vào, sau đó xem kết quả trả về hoặc hành vi của phần mềm, rồi so sánh với kết quả mong đọi được viết trong testcase

WHITE BOX TEST (Kiểm tra hộp trắng)

Định nghĩa

Thử nghiệm kết cấu là loại thử nghiệm được thực hiện để kiểm tra cấu trúc code. Nó còn được gọi là thử nghiệm hộp trắng hoặc thử nghiệm hộp kính. Loại thử nghiệm này đòi hỏi người test phải có kiến thức về code. Do đó, phần lớn là do các lập trình viên, nhà phát triển phần mềm thực hiện.

Đặc điểm

  • Kiểm thử hộp trắng quan tâm đến việc hệ thống vận hành như thế nào chứ không phải chứ năng của hệ thống. Vì nó dựa vào những giải thuật cụ thể, vào những cấu trúc dữ liệu bên trong của TPPM.
  • Trong kiểm tra này, đòi hỏi người tester phải có kiến thức và kỹ năng nhất định về ngôn ngữ lập trình được dùng, hiểu thuật giải trong thành phần phần mềm, để có thể hiểu được chi tiết về đoạn code cần kiểm thử .
  • Mức test này thường yêu cầu các tester phải viết test case đầy đủ các nhánh trong code; khi test, sẽ set điều kiện và data để chạy vào đủ tất cả các nhánh trong giải thuật, đảm bảo thực hiện đầy đủ.

Đối tượng kiểm thử

Là 1 thành phần của phần mềm (1 chức năng, 1 module chức năng, 1 phân hệ chức năng….)

Phương pháp thử nghiệm phù hợp


Kỹ thuật white box test

thích hợp dùng để kiểm thử đơn vị (Unit test). Còn với những TPPM quá lớn thì không nên sử dụng kiểu test này bởi sẽ tốn rất nhiều thời gian và công sức, hiệu quả công việc lại không cao. Nó không thích hợp kiểm thử hệ thống hay kiểm thử chấp nhận.


Xem thêm:


Quy trình kiểm thử phần mềm

Tạo testcase và thực hiện test

  • Khi viết test case: Dựa vào yêu cầu và nội dung Source Code (can thiệp vào bên trong Code của chương trình)
  • Khi thực hiện test: Thực thi test trong code (không cần thực thi chương trình, vì thực hiện test white box sẽ sử dụng framework nào đó hỗ trợ (Ví dụ như test kiểu debug)
My first time using a tube screamer
My first time using a tube screamer

Các kỹ thuật kiểm thử hộp đen

4 kỹ thuật kiểm thử hộp đen phổ biến nhất: Phân vùng tương đương (Equivalence partitioning), Phân tích giá trị biên (Boundary value analysis), Bảng quyết định (Decision Tables) và Đoán lỗi (Error guessing)

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

Phân vùng tương đương là kỹ thuật chia đầu vào thành những nhóm tương đương nhau. Nếu một giá trị trong nhóm hoạt động đúng thì tất cả các giá trị trong nhóm đó cũng hoạt động đúng và ngược lại. Mục đích của phương pháp này là giúp giảm đáng kể số lượng Test Case cần phải thiết kế vì mỗi lớp tương đương ta chỉ cần test trên các phần tử đại diện.

Thiết kế Test-case bằng phân vùng tương đương tiến hành theo 2 bước: Xác định các lớp tương đương và xác định các ca kiểm thử. Khi thực hiện kỹ thuật Equivalence partitioning, đầu vào sẽ được chia theo nguyên tắc:

  • 1 lớp các giá trị lớn hơn.
  • 1 lớp các giá trị nhỏ hơn.
  • 1 lớp các giá trị hợp lệ.

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

Phân tích giá trị biên là phương pháp test tất cả các giá trị ở vùng biên của dữ liệu vào và dữ liệu ra. Các tester sẽ tập trung vào các giá trị biên chứ không test toàn bộ dữ liệu. Do đó, thay vì phải kiểm thử toàn bộ dữ liệu vào và ra, ta có thể test từ 4 – 6 case mà vẫn đảm bảo hệ thống hoạt động tốt.

Boundary conditions là các vị trí ở giữa, trên và dưới các biên của lớp tương đương. Khi áp dụng kỹ thuật phân tích giá trị biên, người kiểm thử sẽ chọn các giá trị:

  • Giá trị nhỏ nhất
  • Giá trị ngay dưới giá trị nhỏ nhất
  • Giá trị bình thường
  • Giá trị ngay trên giá trị lớn nhất
  • Giá trị lớn nhất

Kỹ thuật phân tích giá trị biên sẽ chọn 5 giá trị để kiểm thử.

Bảng quyết định (Decision Tables)

Trong các kỹ thuật viết Test Case, đối với các trường dữ liệu đơn như textbox, các tester thường sử dụng các phương pháp phân vùng tương đương hay phân tích giá trị biên. Đối với kiểm thử hành vi của hệ thống với nhiều trường dữ liệu, Bảng quyết định (Decision table) sẽ giúp chúng ta phân loại và định hình được kịch bản kiểm thử một cách chính xác và rõ ràng hơn.

Bảng quyết định là một kỹ thuật tốt để áp dụng cho những trường hợp cần nhiều sự kết hợp. Kỹ thuật này hỗ trợ việc lựa chọn Test Case tối thiểu một cách có hệ thống kỹ thuật với độ bao phủ tối đa.

Có 4 bước để người kiểm thử tạo được Decision Tables:

  • Liệt kê tất cả Conditions/Inputs.
  • Tính số lượng kết hợp có thể (Rules).
  • Đặt tất cả các kết hợp trong bảng.
  • Giảm thiểu các case kết hợp và quyết định Test Case.

Đoán lỗi (Error guessing)

Đoán lỗi là kỹ thuật mô tả hành động phỏng đoán lỗi thường gặp của hệ thống dựa trên trực giác và kinh nghiệm của các tester. Người kiểm thử sẽ liệt kê các loại lỗi có thể xảy ra và cho vào Test Case để kiểm tra xác minh vấn đề.

Phương pháp này đặc biệt dựa vào kinh nghiệm và kiến thức của tester. 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 nhiều yếu tố như: Đặc trưng hoạt động của phần mềm, lỗi đã xuất hiện ở các dự án tương tự khác…

Các yếu tố mà người kiểm thử hay sử dụng để đoán lỗi:

  • Trực giác kiểm thử.
  • Có kiến thức liên quan, hiểu rõ về hệ thống.
  • Bài học rút ra từ các lần kiểm thử phần mềm trước, các lỗi thường gặp…
  • Tập trung test theo từng phần, từng chức năng sẽ giúp tester chú trọng và lý giải những vấn đề xảy ra ở vùng nào.

Phương pháp kiểm thử hộp đen

Sau đây tôi xin giới thiệu chung một vài kỹ thuật trong kiểm thử hộp đen, chi tiết hơn sẽ được nghiên cứu trong những bài viết sau.

Đ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ột kị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ường hợ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àng biế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 ta cá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ọn giá 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 đồng giá 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ùng mộ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ỗi lớ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ành test.

–> Nế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.

Ví dụ

Spec yêu cầu nhập 4 <= password <= 15

  1. Nhập đúng đưa ra mess hoàn thành thiết lập.

  2. Nhập sai: mess yêu cầu nhập lại.

Như vậy ta sẽ thực hiện 2 testcase: một giá trị cho phần thông báo hoàn thành Setting và một giá trị phần thông báo lỗi.

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ả cho cá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ểm thử. 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.

Những kỹ sư nhiều kinh nghiệm chắc chắn đã từng gặp phải các lỗi của hệ thống ngay tại giá trị biên. Đó là lý do tại sao phân tích giá trị biên lại quan trọng khi kiểm thử hệ thống.

  • 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ị)
Ví dụ

Spec yêu cầu nhập 4 <= password <= 15 Giá trị được test sẽ như sau:

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 được quyế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ào kinh nghiệm và khả năng focus vào việc test các chức năng của tester), All-pairs testing (kiểm thử tất cả các cặp), …

Tài liệu tham khảo

http://www.tutorialspoint.com/software_testing_dictionary/black_box_testing.htm

http://softwaretestingfundamentals.com/black-box-testing/

https://vntesters.com/kiem-thu-hop-den/

http://www.testingvn.com/viewtopic.php?t=4

https://www.wattpad.com/1982587-thế-nào-là-kiểm-thử-hộp-đen-có-những-loại-kiểm-thử

All rights reserved


Thông thường, có hai kiểu kiểm thử chính : Kiểm tra hộp trắng (White box testing) và kiểm tra hộp đen (Black box testing). Bên cạch đó, chúng ta cũng có một kiểu nữa kết hợp hai kiểu trên, đó là kiểm tra hộp xám (Grey box testing). Bạn có biết chúng được dùng khi nào và sự khác nhau giữa các kiểu kiểm thử này là gì không?? Hãy cùng tìm hiểu với chúng tôi trong bài viết dưới đây.

Blackbox and Whitebox Testing
Blackbox and Whitebox Testing

Cách 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 lúc 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ê các ư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 hầu hết các trường hợp kiểm thử cho hệ thống.

Keywords searched by users: black box testing là gì

Black Box Testing Là Gì? Các Phương Pháp Được Sử Dụng Trong Black Box  Testing
Black Box Testing Là Gì? Các Phương Pháp Được Sử Dụng Trong Black Box Testing
Phân Biệt Black Box Test Và White Box Test, Sơ Lược Một Số Kỹ Thuật Trong Black  Box Test
Phân Biệt Black Box Test Và White Box Test, Sơ Lược Một Số Kỹ Thuật Trong Black Box Test
Black Box Testing Là Gì? Kỹ Thuật, Ví Dụ Và Phân Loại - Hoc11.Vn
Black Box Testing Là Gì? Kỹ Thuật, Ví Dụ Và Phân Loại – Hoc11.Vn
Kỹ Thuật Kiểm Thử Hộp Đen - Black Box Testing
Kỹ Thuật Kiểm Thử Hộp Đen – Black Box Testing
Từ A - Z Về Kiểm Thử Hộp Đen Dành Cho Manual Tester - Itnavi
Từ A – Z Về Kiểm Thử Hộp Đen Dành Cho Manual Tester – Itnavi
Black Box Test - Sự Khác Nhau Giữa Black Box Test Và White Box Test
Black Box Test – Sự Khác Nhau Giữa Black Box Test Và White Box Test
Tổng Quan Về Testing – Phần 2: Phân Biệt Các Loại Testing Và Thuật Ngữ  Chuyên Ngành Test | Từ Coder Đến Developer – Tôi Đi Code Dạo
Tổng Quan Về Testing – Phần 2: Phân Biệt Các Loại Testing Và Thuật Ngữ Chuyên Ngành Test | Từ Coder Đến Developer – Tôi Đi Code Dạo
Black Box Testing Là Gì? Các Phương Pháp Được Sử Dụng Trong Black Box  Testing
Black Box Testing Là Gì? Các Phương Pháp Được Sử Dụng Trong Black Box Testing
Software Testing Method 1: Kiểm Thử Hộp Đen - Black Box Testing.
Software Testing Method 1: Kiểm Thử Hộp Đen – Black Box Testing.
Phân Biệt Black Box Test Và White Box Test, Sơ Lược Một Số Kỹ Thuật Trong Black  Box Test
Phân Biệt Black Box Test Và White Box Test, Sơ Lược Một Số Kỹ Thuật Trong Black Box Test
Phân Biệt Các Kỹ Thuật Kiểm Thử Trong Kiểm Thử Phần Mềm - Iviettech -  Iviettech
Phân Biệt Các Kỹ Thuật Kiểm Thử Trong Kiểm Thử Phần Mềm – Iviettech – Iviettech
Phân Biệt Các Kỹ Thuật Kiểm Thử Trong Kiểm Thử Phần Mềm - Iviettech -  Iviettech
Phân Biệt Các Kỹ Thuật Kiểm Thử Trong Kiểm Thử Phần Mềm – Iviettech – Iviettech
100+ Khái Niệm Testing Dành Cho Tester | Anh Tester
100+ Khái Niệm Testing Dành Cho Tester | Anh Tester
Kỹ Thuật Kiểm Thử Hộp Đen - Black Box Testing
Kỹ Thuật Kiểm Thử Hộp Đen – Black Box Testing
Các Phương Pháp Kiểm Thử Phần Mềm Và Sự Khác Biệt? - Itnavi
Các Phương Pháp Kiểm Thử Phần Mềm Và Sự Khác Biệt? – Itnavi
Black Box Testing Là Gì? Các Phương Pháp Được Sử Dụng Trong Black Box  Testing
Black Box Testing Là Gì? Các Phương Pháp Được Sử Dụng Trong Black Box Testing
Kỹ Thuật Kiểm Thử Hộp Đen - Black Box Testing
Kỹ Thuật Kiểm Thử Hộp Đen – Black Box Testing
Phân Biệt Các Kỹ Thuật Kiểm Thử Trong Kiểm Thử Phần Mềm - Iviettech -  Iviettech
Phân Biệt Các Kỹ Thuật Kiểm Thử Trong Kiểm Thử Phần Mềm – Iviettech – Iviettech
Kháng Cự Archives - Trang 9 Trên 23 - Happy Live
Kháng Cự Archives – Trang 9 Trên 23 – Happy Live
Kiểm Thử Hộp Đen Là Gì ? (What Is Black-Box Testing ?) - Techacademy
Kiểm Thử Hộp Đen Là Gì ? (What Is Black-Box Testing ?) – Techacademy
Kỹ Thuật Kiểm Thử Hộp Đen - Black Box Testing
Kỹ Thuật Kiểm Thử Hộp Đen – Black Box Testing
Black Box Testing- Kiểm Thử Hộp Đen - W3Seo Testing Software
Black Box Testing- Kiểm Thử Hộp Đen – W3Seo Testing Software
Kiểm Thử Phần Mềm: Các Kỹ Thuật Thiết Kế Kiểm Thử (Phần 2).
Kiểm Thử Phần Mềm: Các Kỹ Thuật Thiết Kế Kiểm Thử (Phần 2).
Tổng Hợp Bài Viết - Testerviet - Kiểm Thử Phần Mềm Chuyên Nghiệp ✓
Tổng Hợp Bài Viết – Testerviet – Kiểm Thử Phần Mềm Chuyên Nghiệp ✓
Black Box Testing Technique - Kỹ Thuật Kiểm Thử Hộp Đen
Black Box Testing Technique – Kỹ Thuật Kiểm Thử Hộp Đen
Một Số Khái Niệm Trong Kiểm Thử Phần Mềm | Anh Tester
Một Số Khái Niệm Trong Kiểm Thử Phần Mềm | Anh Tester

See more here: kientrucannam.vn

Leave a Reply

Your email address will not be published. Required fields are marked *