Màu xám là gì Box Kiểm tra? Kỹ thuật, Ví dụ

Màu xám là gì Box Kiểm tra?

Xám Box Kiểm tra (cũng được viết là Gray) Box Kiểm thử (Testing) là một kỹ thuật kiểm thử phần mềm, kiểm tra một sản phẩm hoặc ứng dụng phần mềm với kiến ​​thức hạn chế về cấu trúc bên trong của ứng dụng. Mục đích của Grey là... Box Kiểm thử là quá trình tìm kiếm và xác định các lỗi do cấu trúc mã không phù hợp hoặc sử dụng ứng dụng không đúng cách gây ra.

Trong quy trình này, các lỗi cụ thể theo ngữ cảnh liên quan đến hệ thống web thường được xác định. Kỹ thuật này giúp tăng cường... Kiểm tra vùng phủ sóng bằng cách tập trung vào tất cả các lớp của một hệ thống phức tạp thay vì chỉ một lớp duy nhất.

Xám Box Kiểm thử là một phương pháp kiểm thử phần mềm kết hợp trắng Box Kiểm tra và Da Đen Box Kiểm traSự khác biệt giữa ba loại này nằm ở việc người kiểm thử có thể nhìn thấy bao nhiêu phần cấu trúc bên trong:

• màu trắng Box Việc kiểm tra cấu trúc nội bộ (mã nguồn) đã được biết đến.
• Màu đen Box Việc kiểm tra cấu trúc nội bộ (mã nguồn) hiện chưa rõ.
• màu xám Box Việc kiểm tra cấu trúc nội bộ (mã nguồn) đã được biết một phần.

Sơ đồ bên dưới thể hiện ba phương pháp này trên cùng một thang đo mức độ dễ thấy.

In kỹ thuật phần mềm, Xám Box Kiểm thử cho phép kiểm tra cả hai phía của ứng dụng, lớp trình bày cũng như mã lập trình phía sau. Nó đặc biệt hữu ích trong việc Thử nghiệm hội nhập và thâm nhập thử nghiệm.

Ví dụ về màu xám Box Thử nghiệm: Khi kiểm thử một tính năng của trang web, chẳng hạn như liên kết hoặc liên kết mồ côi, nếu người kiểm thử gặp sự cố với các liên kết này, họ có thể thực hiện thay đổi ngay lập tức trong mã HTML và kiểm tra trong thời gian thực.

Tại sao lại là màu xám? Box Kiểm tra

Xám Box Việc kiểm tra được thực hiện vì những lý do sau:

• Nó cung cấp những lợi ích kết hợp của cả kiểm thử hộp đen và kiểm thử hộp trắng.
• Nó kết hợp ý kiến ​​đóng góp của cả nhà phát triển và người kiểm thử, từ đó nâng cao chất lượng tổng thể của sản phẩm.
• Nó giúp giảm bớt chi phí phát sinh trong quá trình kiểm thử dài dòng đối với các kiểu dữ liệu chức năng và phi chức năng.
• Điều này giúp lập trình viên có đủ thời gian rảnh để sửa lỗi.
• Việc kiểm thử được thực hiện từ góc nhìn của người dùng chứ không phải góc nhìn của nhà thiết kế.
• Một lỗi có thể được giải thích thay vì chỉ được báo cáo, bởi vì người kiểm thử có thể thấy được lớp nơi xảy ra lỗi.

Xám Box Thử nghiệm so với màu đen Box so với Trắng Box Kiểm tra

Ba phương pháp này không hẳn là những lựa chọn cạnh tranh mà đúng hơn là ba cấp độ truy cập khác nhau, và mỗi phương pháp giải quyết một loại câu hỏi khác nhau. Đặt chúng cạnh nhau sẽ giúp việc lựa chọn trở nên rõ ràng hơn.

Hầu hết các đội đều sử dụng cả ba loại này. vòng đời kiểm thử phần mềmVà lớp "hộp xám" là nơi thường phát hiện ra các lỗi nằm giữa giao diện người dùng và kho dữ liệu.

Xám Box Chiến lược thử nghiệm

Để thực hiện Grey Box Trong quá trình kiểm thử, người kiểm thử không nhất thiết phải có quyền truy cập vào mã nguồn. Bài kiểm thử được thiết kế dựa trên kiến ​​thức về thuật toán, kiến ​​trúc, trạng thái nội bộ hoặc các mô tả cấp cao khác về hành vi của chương trình.

Để thực hiện Grey Box Thử nghiệm:

• Nó áp dụng các kỹ thuật đơn giản của kiểm thử hộp đen.
• Nó dựa trên việc tạo ra các trường hợp kiểm thử theo yêu cầu, do đó nó thiết lập trước tất cả các điều kiện trước khi chương trình được kiểm thử bằng phương pháp khẳng định.

Các kỹ thuật được sử dụng cho Gray Box Thử nghiệm là:

• Kiểm tra ma trận: Kỹ thuật này bao gồm việc xác định tất cả các biến tồn tại trong chương trình, cùng với rủi ro mà mỗi biến mang lại, để các biến không được sử dụng và có rủi ro cao được nhận diện.
• Kiểm tra hồi quy: Kiểm tra xem liệu sự thay đổi trong phiên bản trước có gây ra sự suy giảm hiệu suất ở các khía cạnh khác của chương trình trong phiên bản mới hay không. Việc này được thực hiện bằng các chiến lược như kiểm tra lại toàn bộ, kiểm tra lại các trường hợp sử dụng rủi ro và kiểm tra lại trong phạm vi tường lửa.
• Kiểm tra mảng trực giao hoặc OAT: Cung cấp độ phủ mã tối đa với số lượng trường hợp kiểm thử tối thiểu.
• Kiểm tra mẫu: được thực hiện trên dữ liệu lịch sử về các lỗi hệ thống trước đó. Không giống như kiểm thử hộp đen, Grey Box Kiểm thử giúp phân tích mã nguồn và xác định nguyên nhân gây ra lỗi.

Xám Box phương pháp này thường sử dụng tự động hóa công cụ kiểm thử phần mềm Để tiến hành kiểm thử. Các đoạn mã giả và trình điều khiển mô-đun được tạo ra để người kiểm thử không phải tự tạo mã thủ công.

Các bước thực hiện Gray Box Thử nghiệm là:

• Bước 1: Xác định các yếu tố đầu vào.
• Bước 2: Xác định các kết quả đầu ra.
• Bước 3: Xác định các tuyến đường chính.
• Bước 4: Xác định các chức năng phụ.
• Bước 5: Phát triển các đầu vào cho các hàm con.
• Bước 6: Phát triển các kết quả đầu ra cho các chức năng con.
• Bước 7: Thực thi trường hợp kiểm thử cho các hàm con.
• Bước 8: Kiểm tra kết quả chính xác của các hàm con.
• Bước 9: Lặp lại các bước 4 đến 8 cho các chức năng phụ khác.
• Bước 10: Lặp lại bước 7 và 8 cho các chức năng phụ khác.

Các trường hợp thử nghiệm cho Grey Box Việc kiểm thử có thể bao gồm các vấn đề về giao diện người dùng đồ họa (GUI), bảo mật, cơ sở dữ liệu, trình duyệt và hệ điều hành, cùng nhiều vấn đề khác. Mỗi trường hợp được tạo ra vẫn cần các bước kiểm tra thông thường. trường hợp thử nghiệm các thuộc tính, vì một trường hợp không thể tái tạo từ chính mô tả của nó thì ít hữu ích trong quá trình hồi quy.

Nơi Xám Box Việc thử nghiệm được sử dụng

Kỹ thuật này tỏ ra hữu ích trong mọi trường hợp mà khuyết điểm chỉ có thể được chẩn đoán bằng cách kiểm tra đồng thời hai lớp. Các tình huống sau đây là những trường hợp mà kỹ thuật này thường được áp dụng nhất:

• Quy trình làm việc dựa trên cơ sở dữ liệu: Một thao tác được thực hiện thông qua giao diện người dùng, và các hàng kết quả sau đó được truy vấn trực tiếp để xác nhận rằng các giá trị, kiểu dữ liệu và mối quan hệ đã được lưu trữ như dự định.
• Dịch vụ web và API: Một yêu cầu được gửi đi và trạng thái phản hồi, tiêu đề và dữ liệu được kiểm tra so với cấu hình đã công bố.tract, đó là hình thức thông dụng hàng ngày của Thử nghiệm API.
• Điểm tích hợp: Các thông điệp vượt qua ranh giới giữa hai mô-đun được kiểm tra trong khi cả hai mô-đun được coi là các hệ thống đang chạy chứ không phải là các tệp nguồn.
• Đánh giá an ninh: Một chuyên gia kiểm thử xâm nhập, khi được cung cấp tài khoản người dùng thông thường và tổng quan về kiến ​​trúc hệ thống, sẽ tái tạo lại vị trí của một người nội bộ, đây chính là mô hình kiểm thử hộp xám tiêu chuẩn.
• Ứng dụng web và giao diện người dùng đồ họa (GUI): Các liên kết hỏng, các trang mồ côi, việc xử lý phiên và xác thực phía máy khách đều được kiểm tra với khả năng hiển thị một phần mã HTML và luồng yêu cầu.

Nhìn chung, chi phí do lỗi hệ thống gây ra được giảm thiểu vì các vấn đề được phát hiện và giải thích trước khi chúng lan rộng hơn nữa trong quy trình. Thử nghiệm hệ thống hoặc sản xuất.

Xám Box Công cụ kiểm tra

Không có công cụ nào thực hiện Grey Box Việc kiểm thử riêng lẻ thì không cần thiết. Điều mà hạng mục này cần là sự kết hợp giữa trình điều khiển giao diện, công cụ kiểm tra lớp bên dưới và cách thức để lập trình kết hợp cả hai.

• API và máy khách dịch vụ web như là Postman và SoapUIĐược sử dụng để đưa ra yêu cầu và xác nhận mã trạng thái cũng như nội dung phản hồi.
• Các công cụ truy vấn cơ sở dữ liệu và công cụ truy vấn SQLĐược sử dụng để xác minh trạng thái được lưu trữ sau một thao tác trên giao diện.
• Công cụ dành cho nhà phát triển trình duyệt và máy chủ proxy HTTP như là Burp SuiteĐược sử dụng để kiểm tra và sửa đổi các yêu cầu trong các phiên bảo mật.
• khung tự động hóa giao diện người dùng như là Selenium, được sử dụng để điều khiển lớp trình bày bên trong một kiểm tra tự động hóa trên.
• Công cụ ghi nhật ký và giám sát, được sử dụng để đối chiếu lỗi quan sát được với những gì ứng dụng đã ghi lại nội bộ tại thời điểm đó.

Việc lựa chọn không quan trọng bằng cách đấu dây: trừ khi trình điều khiển giao diện và bước kiểm tra chạy trong cùng một luồng kịch bản, kết quả sẽ là hai lần kiểm tra thủ công riêng biệt thay vì một bài kiểm tra hộp xám duy nhất.

Xám Box Thử thách thử thách

Khả năng hiển thị một phần gây ra những vấn đề mà cả hai phương pháp thuần túy đều không gặp phải, và sau đây là những vấn đề mà các nhóm thường gặp nhất:

• Khi một thành phần đang được kiểm thử gặp lỗi, nó có thể dừng hoạt động đang diễn ra và bỏ dở phần còn lại của trình tự kiểm thử.
• Một bài kiểm tra có thể được thực thi đầy đủ trong khi nội dung của kết quả không chính xác, vì vậy bước xác minh phải kiểm tra giá trị chứ không phải là việc hoàn thành bài kiểm tra.
• Việc đạt được độ bao phủ toàn bộ đường dẫn mã là không khả thi, bởi vì người kiểm thử không bao giờ nhìn thấy mọi nhánh mà phương pháp kiểm thử hộp trắng có thể tiếp cận.
• Tài liệu thiết kế mà các bài kiểm tra dựa vào có thể đã lỗi thời, và một lược đồ hoặc đặc tả giao diện lỗi thời sẽ âm thầm làm mất hiệu lực thiết kế bài kiểm tra.
• Người kiểm thử phần mềm cần cả sự hiểu biết về lĩnh vực chuyên môn và kiến ​​thức chuyên sâu về kỹ thuật, đây là một nhóm kỹ năng khá hẹp khi tuyển dụng.
• Phân bố rộng rãi và hấp thụ mạnh.tracCác kiến ​​trúc phức tạp khiến việc xác định nguyên nhân gây ra lỗi ở một thành phần nội bộ cụ thể trở nên khó khăn.

Những hạn chế này cho thấy cần phải điều trị cho bệnh Grey. Box Kiểm thử chỉ là một trong nhiều lớp kiểm thử chứ không phải là sự thay thế cho các lớp khác, đó là điểm được nhấn mạnh trong toàn bộ phạm vi rộng hơn. các kỹ thuật kiểm thử phần mềm và các loại kiểm thử phần mềmNó nằm một cách tự nhiên bên cạnh... thử nghiệm chức năng và các phương pháp tiếp cận dựa trên đặc tả kỹ thuật như thử nghiệm dựa trên mô hình.

Câu Hỏi Thường Gặp