14

Trong một nhóm rất nhỏ, trong đó việc kiểm tra hộp đen và hộp trắng được thực hiện bởi cùng một người, người kiểm tra nên làm gì trước?

testing

— Trụ cột muối
nguồn

1

Tôi nghĩ rằng điều này phụ thuộc vào bối cảnh. Bạn đã hoàn thành việc thực hiện các thông số kỹ thuật chủ yếu và muốn bắt đầu thử nghiệm cuối cùng của mình hay bạn đang nói về bất cứ lúc nào trong chu kỳ phát triển? Như một số đề cập trong câu trả lời, những người triển khai của bạn thường sẽ viết các bài kiểm tra đơn vị có thể được coi là một phần của kiểm tra hộp roi của bạn vì những lập trình viên này hiểu được hoạt động bên trong và muốn khẳng định chức năng thực hiện của họ trước khi cam kết.

— Chris

11

Bất cứ điều gì phải chính xác nhất.

Nghiêm túc, kiểm thử hộp trắng (nghĩa là kiểm tra các phần bên trong của mã) nên được thực hiện một cách lý tưởng với các kiểm thử đơn vị của nhà phát triển đã viết mã. Các bài kiểm tra đơn vị sẽ được xây dựng theo thời gian và là một phần của quá trình xây dựng để chúng tôi không lãng phí thời gian của người kiểm tra kém với mã mà chúng tôi biết không hoạt động như bình thường. Kiểm tra đơn vị trở nên quan trọng hơn khi nhóm của bạn nhỏ hơn - đặc biệt vì bạn không có một đội quân kiểm tra để giải quyết vấn đề.

Kiểm thử hộp đen (tức là kiểm tra qua giao diện người dùng / hệ thống) thường là những gì hầu hết người kiểm tra làm.

Tất cả các thử nghiệm cần được ưu tiên về mức độ quan trọng của một chức năng đối với sản phẩm hoàn chỉnh. Nếu nhiệm vụ là cung cấp một công cụ để thực hiện X và sản phẩm không làm X, thì đó là một vấn đề lớn.

— Berin Loritsch
nguồn

1

Vâng nói, câu trả lời tốt nhất tôi đọc cho đến nay.

— Chris

5

Đen

Kiểm tra hộp đen để xác minh các tính năng. Kiểm tra hộp trắng khi cần thiết nếu mọi thứ bị hỏng. Nếu tất cả các thử nghiệm hộp đen vượt qua và phạm vi bảo hiểm tốt, thử nghiệm hộp trắng là không cần thiết.

— Steven A. Lowe
nguồn

2

Trừ khi, tất nhiên, các bài kiểm tra hộp đen bỏ lỡ thử nghiệm một mảnh quan trọng của chức năng hoặc cấu hình:}

— Alan

3

@Alan: lập luận tương tự áp dụng cho thử nghiệm hộp trắng, do đó, 'phạm vi bảo hiểm là tốt'

— Steven A. Lowe

1

Đồng ý - Tôi đoán tuyên bố của tôi phụ thuộc vào định nghĩa của bạn về bảo hiểm tốt.

— Alan

1

@DocBrown Tôi hoàn toàn không thấy những gì bạn giải thích là bất cứ điều gì từ xa như thử nghiệm whitebox. Kiểm tra Whitebox là về việc đi theo các đường dẫn nhánh của một triển khai đã cho và viết các trường hợp kiểm thử sẽ thực hiện tất cả các đường dẫn. Nếu bạn chưa có triển khai, thì bạn không thể định nghĩa các bài kiểm tra whitebox. Với TDD và BDD, bạn viết các bài kiểm tra về hình dạng chung được đưa ra khi đó. Bạn thiết lập dữ liệu đầu vào hoặc trạng thái tiền điều kiện, kích hoạt thiết bị và thực hiện kiểm tra dữ liệu đầu ra hoặc kết thúc cuộc gọi hoặc cuộc gọi của bên thứ ba. Đây là định nghĩa của thử nghiệm hộp đen.

— Sammi

1

@SamJudge: theo hiểu biết của tôi, khi bạn nhìn vào bên trong mã triển khai và sử dụng thông tin đó để thiết kế dữ liệu thử nghiệm rất cụ thể (sau đó được chuyển qua giao diện công cộng), thì nó sẽ được gọi là thử nghiệm hộp trắng này. Thử nghiệm như vậy cũng thất bại nếu kết quả không như mong đợi. Nếu sau này bạn chỉ nhìn vào bài kiểm tra, bạn có thể không thể nói rõ ràng "bài kiểm tra này được tạo ra bởi phương pháp hộp trắng (hoặc hộp đen)", tất nhiên.

— Doc Brown

3

Hộp đen.

Các thành phần hộp trắng thường phụ thuộc vào các thành phần hộp đen, vì vậy tôi muốn kiểm tra hộp đen trước và sau đó chuyển sang hộp trắng.

— Walter
nguồn

2

Tôi không chắc ý của bạn về "thành phần hộp đen" và "thành phần hộp trắng" - với tôi chúng chỉ là "thành phần" (có thể được kiểm tra có hoặc không có kiến thức về mã hoặc kiến trúc cơ bản.

— Alan

Tôi không hiểu mối quan hệ "phụ thuộc" mà bạn đang đề xuất ở đây. Hộp đen trắng không phải là thành phần, nhiều hơn một phong cách thử nghiệm bất kỳ thành phần nào như Alan đề cập. Sự khác biệt là trong cách tiếp cận được thực hiện để kiểm tra thành phần được đề cập.

— Chris

2

Trước tiên, bạn thực hiện tư duy kiểm tra trắng với tư cách là một lập trình viên / nhà phát triển để đảm bảo mọi thứ sẽ hoạt động tốt. Sau đó, bạn thực hiện kiểm tra hộp đen thường cố gắng suy nghĩ như thể bạn là người dùng cuối, mà không suy nghĩ về cấu trúc bên trong của chương trình. Đôi khi bạn cần suy nghĩ như một lập trình viên / nhà phát triển ngay cả khi bạn đang thực hiện kiểm tra đen vì bạn có thể đang kiểm tra một mô-đun nội bộ được viết bởi người khác và bạn không có quyền truy cập vào mã.

— Enrique
nguồn

2

Nếu bạn muốn có một chu kỳ kiểm tra tốt, bạn nên có những người khác nhau thực hiện Cả hai :

Một nhà phát triển tập trung chủ yếu vào kiểm thử hộp trắng biết những gì đã thay đổi trong mã gần đây, khu vực nào phức tạp hơn (và do đó có khả năng bị phá vỡ), v.v. và có thể tập trung nỗ lực phù hợp vào những lĩnh vực này có khả năng đưa ra các khiếm khuyết mới.
Mặt khác, một người kiểm tra QA tập trung vào kiểm tra hộp đen có thể dễ dàng tiếp cận kiểm tra hơn như người dùng cuối. Không có bất kỳ kiến thức nội bộ nào về mã, họ có thể có một cách tiếp cận mới và không bị thiên vị bởi kiến thức về cách các phần khác nhau của giải pháp được thực hiện. Họ sẽ bắt các lỗi mà nhà phát triển có thể đã bỏ qua hoặc hồi quy từ các thay đổi mã vô tình phá vỡ các khu vực khác của ứng dụng.

Để trả lời câu hỏi của bạn, việc kiểm tra hộp trắng nên được thực hiện trước tiên. Nhưng bạn thực sự cần phải có một người khác thực hiện kiểm tra hộp đen nếu bạn muốn nó có hiệu quả.

— Justin Ethier
nguồn

1

Tôi thích bắt đầu với thử nghiệm hộp đen, sau đó sử dụng thông tin bảo hiểm mã hoặc trình gỡ lỗi để tìm hiểu những gì tôi đang làm và phân tích những gì đang xảy ra.

Nhưng câu trả lời thực sự là nó phụ thuộc . Tôi có khả năng đi sâu vào mã sớm hơn (ngay cả trước tiên) nếu tôi đang thử nghiệm API, nhưng muộn hơn nữa nếu mục tiêu của tôi là xem xét một số kịch bản kết thúc lớn để kết thúc.

— Alan
nguồn

1

Tôi muốn nói thử nghiệm Hộp đen trước tiên, đơn giản vì là người đề xuất TDD, các thử nghiệm được viết trước khi mã (hoặc hộp) tồn tại bằng mọi cách :)

Thử nghiệm Hộp Trắng (theo như tôi hiểu) hữu ích hơn trong tư duy gỡ lỗi.

— Matthieu M
nguồn

-1, TDD là thử nghiệm hộp trắng. Trong TDD, điều cần thiết là phải biết những gì mã liên quan đến thử nghiệm làm (và những gì nó không) để viết thử nghiệm tiếp theo. Kiểm thử hộp đen có nghĩa là ai đó không có ý tưởng về mã (người kiểm tra, người thậm chí không cần biết cách viết mã), thiết kế các thử nghiệm.

— Doc Brown

1

Sau đó, chúng tôi không thực hành TDD theo cùng một cách. TDD đối với tôi là về việc thực thi các thông số kỹ thuật của một lớp / hàm: các bài kiểm tra được viết để kiểm tra xem lớp / hàm đó có hoạt động như được chỉ định hay không, nhưng có thể quan tâm ít hơn cách mã hoạt động đằng sau cảnh miễn là các thông số đó được giữ nguyên ... điều cần thiết là các bài kiểm tra được viết trước chức năng.

— Matthieu M.

1

Kiểm thử hộp đen, bởi vì bạn đang viết kiểm tra trước khi mã tồn tại. Người thử nghiệm cần phải phát triển các thử nghiệm tự động tốn thời gian song song với mã viết của nhà phát triển để có hiệu quả trong một nhóm nhỏ.

Nếu mã đã được viết, tôi khuyên bạn nên dành thời gian phác thảo phạm vi kiểm tra theo quan điểm của hộp đen để đảm bảo bạn có thời gian động não trước khi bạn làm lộn xộn bộ não của mình với mã thực tế. Tuy nhiên, sau đó bạn có thể chuyển sang hộp trắng và xem mã trước khi đi quá xa cùng với thử nghiệm thực tế để cảm nhận về các khu vực rủi ro và ưu tiên các thử nghiệm mà bạn đã động não trước đó (và tăng cường chúng bằng các thử nghiệm mới nghĩ ra nhìn vào các phần của mã có vẻ phức tạp hoặc nghi vấn).

— Ethel Evans
nguồn

0

Cũng không. Tôi cố gắng viết các bài kiểm tra tốt bằng BICEP phải của mình , ghi nhớ các điều kiện biên ĐÚNG cho dù chúng có xuất hiện theo thứ tự nào. Cả hai đều là từ viết tắt được đề xuất trong bài kiểm tra đơn vị thực dụng .

Mục tiêu của tôi là tập trung vào viết các bài kiểm tra tốt, và không phải viết màu nào trước.

— Steven Evers
nguồn

'Trắng' và 'đen' không phải là thuật ngữ thử nghiệm đơn vị, vì vậy tất nhiên bạn không lo lắng về điều đó. Kiểm tra đơn vị là hộp trắng thực tế.

— Ethel Evans

@Ethel Evans: Theo định nghĩa, chúng không phải là hộp trắng. Phần lớn các bài kiểm tra đơn vị là các bài kiểm tra hộp trắng, nhưng đó không phải là một yêu cầu. Bất kỳ thử nghiệm nào ánh xạ miền của đầu vào vào phạm vi đầu ra của hàm là các thử nghiệm đơn vị, nhưng không cần biết chi tiết về việc thực hiện.

— Steven Evers

0

Đầu tiên làm nó kiểm tra hộp trắng .

Thứ hai đi thử nghiệm hộp đen.

> Kiểm tra hộp đen

I. Người kiểm tra cần kiểm tra chức năng của ứng dụng, như hộp Văn bản, nút Radio, hộp danh sách, nút Lệnh, ... vv. ,,

II. Người kiểm tra nên kiểm tra không hoạt động của ứng dụng, như logo, hình ảnh, chính tả, v.v.

III. Người kiểm tra nên kiểm tra toàn bộ dòng chảy của ứng dụng.

Lưu ý: Để kiểm tra điều kiện tích cực và tiêu cực.

Kiểm tra hộp đen hoặc hộp trắng - bạn làm gì đầu tiên?

Đen