Rate this post

Phương pháp kiểm thử hộp của kiểm thử phần mềm bao gồm kiểm thử hộp đen và kiểm thử White box. Ở đây chúng ta đang thảo luận về thử nghiệm White box hay còn gọi là hộp thủy tinh là thử nghiệm, thử nghiệm cấu trúc, thử nghiệm hộp trong, thử nghiệm hộp mở và thử nghiệm hộp trong suốt. Nó Testing code nội bộ và cơ sở hạ tầng của một phần mềm tập trung vào việc Testing các đầu vào được xác định trước so với đầu ra dự kiến và mong muốn. Nó dựa trên hoạt động bên trong của một ứng dụng và xoay quanh việc Testing cấu trúc bên trong. Trong loại kiểm thử này, các kỹ năng lập trình được yêu cầu để thiết kế các trường hợp kiểm thử. Mục tiêu chính của kiểm thử White box là tập trung vào luồng đầu vào và đầu ra thông qua phần mềm và tăng cường bảo mật của phần mềm.

Các bài viết liên quan:

Thuật ngữ ‘White box’ được sử dụng vì quan điểm bên trong của hệ thống. Hộp trong hoặc White box hoặc tên hộp trong suốt biểu thị khả năng nhìn xuyên qua lớp vỏ bên ngoài của phần mềm vào hoạt động bên trong của nó.

Các nhà phát triển thực hiện thử nghiệm White box. Trong điều này, nhà phát triển sẽ Testing mọi dòng mã của chương trình. Các nhà phát triển thực hiện kiểm thử White box và sau đó gửi ứng dụng hoặc phần mềm đến nhóm kiểm thử, nơi họ sẽ thực hiện Testing hộp đen và xác minh ứng dụng cùng với các yêu cầu và xác định lỗi và gửi cho nhà phát triển.

Nhà phát triển sửa lỗi và thực hiện một vòng Testing White box và gửi nó cho nhóm Testing. Ở đây, việc sửa lỗi có nghĩa là lỗi đã bị xóa và tính năng cụ thể đang hoạt động tốt trên ứng dụng.

Ở đây, các kỹ sư Testing sẽ không bao gồm việc sửa chữa các khiếm khuyết vì những lý do sau:

Việc sửa lỗi có thể làm gián đoạn các tính năng khác. Do đó, kỹ sư Testing phải luôn tìm ra lỗi và các nhà phát triển vẫn nên tiến hành sửa lỗi.
Nếu các kỹ sư Testing dành phần lớn thời gian để sửa các lỗi, thì họ có thể không tìm thấy các lỗi khác trong ứng dụng.

Thử nghiệm White box bao gồm các thử nghiệm khác nhau, như sau:

Path testing
Loop testing
Condition testing
Testing based memory
Test performance

Tóm tắt nội dung

Path testing

Trong Testing đường dẫn, chúng tôi sẽ viết các đồ thị luồng và Testing tất cả các đường dẫn độc lập. Ở đây việc viết biểu đồ luồng ngụ ý rằng đồ thị luồng đang đại diện cho luồng của chương trình và cũng cho thấy cách mọi chương trình được thêm vào với nhau như chúng ta có thể thấy trong hình ảnh dưới đây:

Và Testing tất cả các đường dẫn độc lập ngụ ý rằng giả sử một đường dẫn từ hàm main () đến hàm G, trước tiên hãy đặt các tham số và Testing xem chương trình có đúng trong đường dẫn cụ thể đó hay không, đồng thời Testing tất cả các đường dẫn khác và sửa lỗi.

Xem thêm Black box testing- kiểm thử hộp đen

Loop testing

Trong Testing vòng lặp, chúng tôi sẽ Testing các vòng lặp như while, for, và do-while, v.v. và cũng Testing điều kiện kết thúc nếu hoạt động chính xác và kích thước của các điều kiện có đủ hay không.

Ví dụ: chúng tôi có một chương trình mà các nhà phát triển đã đưa ra khoảng 50.000 vòng lặp.

{

while(50,000)

……

}

Chúng tôi không thể Testing chương trình này theo cách thủ công cho tất cả chu kỳ 50.000 vòng. Vì vậy, chúng tôi viết một chương trình nhỏ giúp cho tất cả 50.000 chu kỳ, như chúng ta có thể thấy trong chương trình bên dưới, bài Testing P đó được viết bằng ngôn ngữ tương tự như chương trình mã nguồn và đây được gọi là bài Testing Đơn vị. Và nó chỉ được viết bởi các nhà phát triển.

Test P

{

……

…… }

Như chúng ta có thể thấy trong hình dưới đây, chúng ta có các yêu cầu khác nhau như 1, 2, 3, 4. Và sau đó, nhà phát triển viết các chương trình như chương trình 1,2,3,4 cho các điều kiện song song. Ở đây ứng dụng chứa dòng mã 100s.

Nhà phát triển sẽ thực hiện Testing White box và họ sẽ Testing tất cả năm chương trình từng dòng mã để tìm ra lỗi. Nếu họ tìm thấy bất kỳ lỗi nào trong bất kỳ chương trình nào, họ sẽ sửa nó. Và họ lại phải Testing hệ thống thì quá trình này tốn rất nhiều thời gian và công sức và làm chậm thời gian phát hành sản phẩm.

Bây giờ, giả sử chúng ta có một trường hợp khác, trong đó khách hàng muốn sửa đổi các yêu cầu, sau đó nhà phát triển sẽ thực hiện các thay đổi được yêu cầu và Testing lại cả bốn chương trình, việc này mất rất nhiều thời gian và nỗ lực.

Những vấn đề này có thể được giải quyết theo những cách sau:

Trong phần này, chúng tôi sẽ viết thử nghiệm cho một chương trình tương tự trong đó nhà phát triển viết mã thử nghiệm này bằng ngôn ngữ liên quan làm mã nguồn. Sau đó, chúng thực thi các mã Testing này, còn được gọi là các chương trình Testing đơn vị. Các chương trình thử nghiệm này liên kết với chương trình chính và được thực hiện như các chương trình.

Do đó, nếu có bất kỳ yêu cầu sửa đổi hoặc lỗi nào trong mã, thì nhà phát triển thực hiện điều chỉnh cả trong chương trình chính và chương trình thử nghiệm, sau đó thực hiện chương trình thử nghiệm.

Xem thêm Functional Testing

Condition testing

Trong phần này, chúng tôi sẽ Testing tất cả các điều kiện logic cho cả giá trị đúng và sai; nghĩa là, chúng tôi sẽ xác minh cho cả điều kiện if và else.

Ví dụ:

if(condition) – true

{

…..

……

}

else – false

{

…..

……

}

Chương trình trên sẽ hoạt động tốt cho cả hai điều kiện, có nghĩa là

nếu điều kiện là chính xác, và nếu điều kiện khác sẽ là sai và ngược lại.

Testing based memory

Kích thước của mã đang tăng lên vì những lý do sau:

Việc sử dụng lại mã không có ở đó: chúng ta hãy lấy một ví dụ, trong đó chúng ta có bốn chương trình của cùng một ứng dụng và mười dòng đầu tiên của chương trình cũng tương tự. Chúng ta có thể viết mười dòng này dưới dạng một hàm rời rạc và nó cũng phải có thể truy cập được bởi bốn chương trình trên. Ngoài ra, nếu có bất kỳ lỗi nào ở đó, chúng tôi có thể sửa đổi dòng mã trong hàm thay vì toàn bộ mã.
Các nhà phát triển sử dụng logic có thể được sửa đổi. Nếu một lập trình viên viết mã và kích thước tệp lên đến 250kb, thì lập trình viên khác có thể viết mã tương tự bằng cách sử dụng logic khác và kích thước tệp lên đến 100kb.
Nhà phát triển khai báo rất nhiều hàm và biến có thể không bao giờ được sử dụng trong bất kỳ phần nào của mã. Do đó, kích thước của chương trình sẽ tăng lên.

Ví dụ,

Int a=15;

Int b=20;

String S= “Welcome”;

….

…..

….

…..

Int p=b;

Create user()

{

……

….. 200’s line of code

}

Trong đoạn mã trên, chúng ta có thể thấy rằng số nguyên a chưa bao giờ được gọi ở bất kỳ đâu trong chương trình, và hàm Tạo người dùng cũng chưa bao giờ được gọi ở bất kỳ đâu trong đoạn mã. Do đó, nó dẫn chúng ta đến việc tiêu thụ trí nhớ.

Chúng tôi không thể nhớ loại lỗi này theo cách thủ công bằng cách xác minh mã vì mã lớn. Vì vậy, chúng tôi có một công cụ tích hợp, giúp chúng tôi Testing các biến và hàm không cần thiết. Và, ở đây chúng ta có một công cụ có tên là Rational pure.

Giả sử chúng ta có ba chương trình như Chương trình P, Q và R, cung cấp đầu vào cho S. Và S đi vào chương trình và xác minh các biến không sử dụng và sau đó đưa ra kết quả. Sau đó, các nhà phát triển sẽ nhấp vào một số kết quả và gọi hoặc loại bỏ hàm và các biến không cần thiết.

Công cụ này chỉ được sử dụng cho ngôn ngữ lập trình C và ngôn ngữ lập trình C ++; đối với ngôn ngữ khác, chúng tôi có các công cụ liên quan khác có sẵn trên thị trường.

Nhà phát triển không sử dụng các chức năng cài sẵn có sẵn; thay vào đó họ viết các tính năng đầy đủ bằng cách sử dụng logic của họ. Do đó, nó dẫn đến việc chúng ta lãng phí thời gian và cũng làm trì hoãn việc phát hành sản phẩm.

Test performance

Ứng dụng có thể chậm vì những lý do sau:

Khi logic được sử dụng.
Đối với các trường hợp có điều kiện, chúng tôi sẽ sử dụng hoặc & và đầy đủ.
Trường hợp chuyển mạch, có nghĩa là chúng ta không thể sử dụng if lồng nhau, thay vì sử dụng trường hợp chuyển mạch.

Như chúng ta biết rằng nhà phát triển đang thực hiện thử nghiệm White box, họ hiểu rằng mã đang chạy chậm hoặc hiệu suất của chương trình cũng đang có chủ ý. Và nhà phát triển không thể truy cập chương trình theo cách thủ công và xác minh dòng mã nào đang làm chậm chương trình.

Để phục hồi với tình trạng này, chúng tôi có một công cụ có tên là Rational Quantify, công cụ này sẽ tự động giải quyết các loại vấn đề này. Khi toàn bộ mã đã sẵn sàng, công cụ định lượng hợp lý sẽ đi qua mã và thực thi nó. Và chúng ta có thể xem kết quả trong bảng kết quả dưới dạng các đường kẻ dày và mảnh.

Ở đây, dòng dày chỉ định phần mã nào tốn nhiều thời gian. Khi chúng ta nhấp đúp vào dòng dày, công cụ sẽ tự động đưa chúng ta đến dòng hoặc đoạn mã đó, cũng được hiển thị bằng màu khác. Chúng tôi có thể thay đổi mã đó và một lần nữa và sử dụng công cụ này. Khi thứ tự của các dòng đều mỏng, chúng ta biết rằng sự trình bày của chương trình đã nâng cao. Và các nhà phát triển sẽ thực hiện Testing White box tự động vì nó tiết kiệm thời gian hơn là thực hiện thủ công.

Các trường hợp kiểm thử để kiểm thử White box có nguồn gốc từ giai đoạn thiết kế của vòng đời phát triển phần mềm. Kiểm thử dòng dữ liệu, Testing dòng điều khiển, Testing đường dẫn, Testing nhánh, phạm vi tuyên bố và quyết định tất cả các kỹ thuật này được kiểm thử White box sử dụng như một hướng dẫn để tạo ra một phần mềm không có lỗi.

Kiểm thử White box tuân theo một số bước làm việc để giúp Testing có thể quản lý được và dễ hiểu nhiệm vụ tiếp theo cần làm. Có một số bước cơ bản để thực hiện Testing White box.

Các bước chung của Testing White box

Thiết kế tất cả các kịch bản kiểm thử, các trường hợp kiểm thử và sắp xếp thứ tự ưu tiên theo số lượng ưu tiên cao.
Bước này liên quan đến việc nghiên cứu mã trong thời gian chạy để Testing việc sử dụng tài nguyên, các vùng không được truy cập của mã, thời gian thực hiện bằng các phương pháp và hoạt động khác nhau, v.v.
Trong bước này, việc Testing các chương trình con bên trong diễn ra. Các chương trình con bên trong như phương thức không công khai, các giao diện có khả năng xử lý tất cả các loại dữ liệu một cách thích hợp hay không.
Bước này tập trung vào việc thử nghiệm các câu lệnh điều khiển như vòng lặp và câu lệnh điều kiện để Testing tính hiệu quả và độ chính xác cho các đầu vào dữ liệu khác nhau.
Trong bước cuối cùng, Testing White box bao gồm Testing bảo mật để Testing tất cả các lỗ hổng bảo mật có thể có bằng cách xem cách mã xử lý bảo mật.

Lý do thử nghiệm White box

Nó xác định các lỗ hổng bảo mật nội bộ.
Để Testing cách nhập bên trong mã.
Testing chức năng của các vòng lặp có điều kiện.
Để Testing hàm, đối tượng và câu lệnh ở cấp độ riêng lẻ.

Ưu điểm của thử nghiệm White box

Testing White box tối ưu hóa mã để các lỗi ẩn có thể được xác định.
Các trường hợp kiểm thử của kiểm thử White box có thể được tự động hóa dễ dàng.
Thử nghiệm này kỹ lưỡng hơn các phương pháp thử nghiệm khác vì nó bao gồm tất cả các đường dẫn mã.
Nó có thể được bắt đầu trong giai đoạn SDLC ngay cả khi không có GUI.

Nhược điểm của kiểm thử White box

Kiểm thử White box tốn quá nhiều thời gian khi nói đến các ứng dụng lập trình quy mô lớn.
Thử nghiệm White box rất tốn kém và phức tạp.
Nó có thể dẫn đến lỗi sản xuất vì nó không được các nhà phát triển chi tiết.
Kiểm thử White box cần những lập trình viên chuyên nghiệp có kiến thức và hiểu biết chi tiết về ngôn ngữ lập trình và cách thực hiện.

Các kỹ thuật được sử dụng trong thử nghiệm White box

Data Flow Testing: Kiểm tra luồng dữ liệu là một nhóm các chiến lược kiểm tra nhằm kiểm tra luồng điều khiển của các chương trình nhằm khám phá chuỗi các biến theo chuỗi sự kiện.
Control Flow Testing: Kiểm tra luồng kiểm soát xác định thứ tự thực hiện của các câu lệnh hoặc hướng dẫn của chương trình thông qua một cấu trúc điều khiển. Cấu trúc điều khiển của một chương trình được sử dụng để phát triển một trường hợp kiểm thử cho chương trình. Trong kỹ thuật này, một phần cụ thể của một chương trình lớn được người thử nghiệm chọn để thiết lập đường dẫn thử nghiệm. Các ca kiểm thử được biểu diễn bằng đồ thị điều khiển của chương trình.
Branch Testing: Kỹ thuật bao phủ nhánh được sử dụng để bao phủ tất cả các nhánh của đồ thị luồng điều khiển. Nó bao gồm tất cả các kết quả có thể xảy ra (đúng và sai) của mỗi điều kiện của điểm quyết định ít nhất một lần.
Statement Testing: Kỹ thuật bao phủ Statement được sử dụng để thiết kế các trường hợp kiểm thử hộp trắng. Kỹ thuật này liên quan đến việc thực thi tất cả các câu lệnh của mã nguồn ít nhất một lần. Nó được sử dụng để tính tổng số câu lệnh được thực thi trong mã nguồn, trên tổng số câu lệnh có trong mã nguồn.
Decision Testing: Kỹ thuật này báo cáo kết quả đúng và sai của biểu thức Boolean. Bất cứ khi nào có khả năng xảy ra hai hoặc nhiều kết quả từ các câu lệnh như câu lệnh do while, câu lệnh if và câu lệnh trường hợp (câu lệnh luồng điều khiển), nó được coi là điểm quyết định vì có hai kết quả đúng hoặc sai.

Sự khác biệt giữa White box testing và Black box testing

Sau đây là những khác biệt đáng kể giữa White box testing và Black box testing:

White box testing	Black box testing
Các nhà phát triển có thể thực hiện White box testing.	Các kỹ sư kiểm tra thực hiện kiểm tra hộp đen.
Để thực hiện WBT, chúng ta nên hiểu về các ngôn ngữ lập trình.	Để thực hiện BBT, không cần phải có hiểu biết về các ngôn ngữ lập trình.
Trong phần này, chúng ta sẽ xem xét mã nguồn và kiểm tra tính logic của mã.	Trong phần này, chúng tôi sẽ xác minh chức năng của ứng dụng dựa trên đặc điểm kỹ thuật yêu cầu.
Trong điều này, nhà phát triển nên biết về thiết kế bên trong của mã.	Trong điều này, không cần biết về thiết kế bên trong của mã.

Software testing

Testing White box- kiểm thử phần mềm hộp trắng