Kiểm thử phần mềm không phá hủy (NDT): Khái niệm, Chiến lược kiểm thử

Kiểm thử phần mềm không phá hủy là gì?

Kiểm tra không phá hủy là một loại thử nghiệm phần mềm liên quan đến việc thử nghiệm và tương tác với ứng dụng phần mềm một cách chính xác. Nói cách khác, Kiểm thử phần mềm không phá hủy (NDT) cũng có thể được gọi là Kiểm thử tích cực hoặc Kiểm thử đường dẫn hạnh phúc. Nó đưa ra kết quả như mong đợi và chứng minh rằng ứng dụng phần mềm đang hoạt động như mong đợi.

Tên gọi này được mượn từ kỹ thuật, nơi phương pháp kiểm tra không phá hủy (non-destructive testing) kiểm tra một linh kiện vật lý mà không làm hỏng nó. Trong phần mềm, ý tưởng cũng tương tự: ứng dụng được vận hành theo cách nó được thiết kế để sử dụng, và nó vượt qua bài kiểm tra mà không bị hư hại.

Ví dụ: Nhập dữ liệu chính xác vào mô-đun đăng nhập và kiểm tra xem hệ thống có chấp nhận thông tin đăng nhập và chuyển đến trang tiếp theo hay không.

Ảnh chụp màn hình bên dưới hiển thị biểu mẫu đăng nhập, với một giá trị hợp lệ được nhập vào trường tên người dùng trước khi bài kiểm tra được thực thi.

Để thực hiện kiểm thử không phá hủy trên ví dụ trên, hãy nhập tên người dùng và mật khẩu hợp lệ vào biểu mẫu đăng nhập. Vì thông tin nhập vào phù hợp với yêu cầu cho phép, kết quả mong muốn là tích cực và người kiểm thử chỉ cần xác nhận rằng ứng dụng chuyển sang trang tiếp theo.

Tại sao phải kiểm thử phần mềm không phá hủy (NDT)?

Kiểm thử không phá hủy trả lời câu hỏi đầu tiên mà mọi bên liên quan đặt ra về một bản dựng: tính năng đó có thực sự hoạt động như mong đợi hay không? Đây là những lý do mà các nhóm thực hiện kiểm thử này.

• Lợi ích chính của phương pháp NDT là nó giúp cải thiện chất lượng phần mềm, vì các lỗi được phát hiện trong quy trình chính sẽ được khắc phục sớm.
• Để chứng minh rằng các chức năng phần mềm đang hoạt động theo đúng đặc tả.
• Để xác minh rằng các yêu cầu về hiệu suất đã được đáp ứng.
• Để xác minh rằng các yêu cầu của người dùng cuối được đáp ứng.
• Để kiểm tra xem một đoạn mã hoặc chức năng nhỏ có hoạt động như mong đợi hay không và không gây lỗi cho các chức năng liên quan.
• Để đưa ra bằng chứng có thể được trình bày tại một kiểm tra sự chấp nhận của người dùng Phê duyệt cuối cùng, trong đó khách hàng muốn thấy hành vi dự định chứ không phải các chế độ lỗi.

Khi nào thử nghiệm không phá hủy (NDT) được thực hiện?

Thời điểm thực hiện quan trọng hơn ở đây so với hầu hết các kỹ thuật khác, bởi vì quy trình tối ưu sẽ điều chỉnh mọi thứ tiếp theo.

• Đây là hình thức kiểm thử đầu tiên mà người kiểm thử sẽ thực hiện trên một ứng dụng, tức là ở giai đoạn ban đầu. SDLC.
• Kiểm tra không phá hủy thường được thực hiện khi không có đủ thời gian cho một chu kỳ kiểm tra đầy đủ, vì nó vẫn chứng minh được các tiêu chí chấp nhận đã được đáp ứng.
• Nó hoạt động trước các tình huống tiêu cực và gây hại. Nếu luồng chính bị gián đoạn, các bài kiểm tra xử lý lỗi sẽ báo cáo nhiễu thay vì các lỗi thực sự.
• Quá trình này được lặp lại sau mỗi lần sửa lỗi, đó là lý do nó trùng lặp với... kiểm tra hồi quy.

Chiến lược thử nghiệm để thử nghiệm không phá hủy

Chiến lược kiểm tra không phá hủy được xây dựng một cách đơn giản, và điểm mấu chốt nằm ở việc giữ thái độ tích cực hơn là ở công cụ.

• Cách tiếp cận đối với kiểm tra không phá hủy nên mang tính tích cực.
• Mục đích của kỹ thuật NDT là chứng minh rằng một ứng dụng sẽ hoạt động khi được cung cấp dữ liệu đầu vào hợp lệ.
• Không cần bất kỳ yêu cầu hay môi trường đặc biệt nào để thực hiện kiểm tra không phá hủy.
• Phương pháp tốt nhất để kiểm tra không phá hủy là kiểm tra xem hệ thống có hoạt động đúng như mong đợi hay không.

Sơ đồ dưới đây tóm tắt cách thức chiến lược đó thường được tổ chức trong suốt một chu kỳ thử nghiệm.

Cách viết các trường hợp kiểm thử không phá hủy (tích cực)

Một trường hợp kiểm thử không phá hủy chỉ hữu ích khi dữ liệu đầu vào của nó được chứng minh là hợp lệ và kết quả mong đợi xuất phát từ yêu cầu chứ không phải từ giả định của người kiểm thử. Các bước sau đây tạo ra loại trường hợp kiểm thử đó. trường hợp thử nghiệm.

Bước 1) Chọn một tiêu chí chấp nhận. Đọc kỹ yêu cầu và diễn đạt lại thành một câu duy nhất có thể kiểm chứng được, ví dụ: “Trường tên người dùng chấp nhận từ sáu đến hai mươi ký tự chữ và số”.

Bước 2) Chọn dữ liệu đầu vào hợp lệ. Chọn các giá trị nằm trong phạm vi cho phép. Phân vùng tương đương Điều này rất hữu ích — thông thường chỉ cần một giá trị đại diện cho mỗi phân vùng hợp lệ là đủ.

Bước 3) Viết kết quả mong muốn trước khi thực thi. Kết quả mong đợi phải được viết dựa trên đặc tả kỹ thuật. Việc viết kết quả sau khi chạy sẽ biến bài kiểm tra thành bản mô tả về những gì mà quá trình biên dịch đã thực hiện.

Bước 4) Giữ nguyên các bước theo thứ tự người dùng. Trình tự các bước phải khớp với cách người dùng thực sự hoàn thành nhiệm vụ, bởi vì mục đích của kỹ thuật này là để xác nhận hành trình dự định.

Bước 5) Ghi lại mã định danh yêu cầu. TracViệc đưa vụ việc trở lại tiêu chí ban đầu là điều cho phép nhóm chứng minh phạm vi bao phủ trong quá trình xem xét.

Một ví dụ minh họa cho mô-đun đăng nhập trông như thế này.

Lưu ý rằng không có gì trong trường hợp này cố gắng ngắt trường. Trường hợp nhập năm ký tự để xem thông báo lỗi là một trường hợp như vậy. kiểm tra âm tínhKhông phải là một phương pháp không gây hại.

Ví dụ về thử nghiệm không phá hủy

Ví dụ dưới đây minh họa cách thức hoạt động của kiểm thử không phá hủy trên một ứng dụng đa mô-đun sau khi lỗi đã được khắc phục.

• Một ứng dụng có năm mô-đun: trang đăng nhập, trang chủ, trang chi tiết người dùng, tạo người dùng mới và tạo tác vụ.
• Giả sử có một lỗi trên trang đăng nhập: trường tên người dùng chấp nhận ít hơn sáu ký tự chữ và số. Điều này trái với yêu cầu đã đặt ra, quy định rằng tên người dùng không được chấp nhận ít hơn sáu ký tự, vì vậy hành vi này là một lỗi.
• Lỗi này được báo cáo cho nhóm phát triển thông qua quy trình thông thường. quy trình quản lý khuyết tậtLỗi đã được khắc phục và bản dựng được gửi lại cho nhóm thử nghiệm.
• Nhóm kiểm thử không chỉ kiểm tra trang đăng nhập nơi lỗi đã được khắc phục mà còn kiểm tra các mô-đun khác. Trong quá trình kiểm thử tất cả các mô-đun với dữ liệu hợp lệ, nhóm thực hiện kiểm thử không phá hủy, chỉ đơn giản để xác nhận rằng toàn bộ ứng dụng vẫn hoạt động bình thường.

Kiểm tra không phá hủy so với kiểm tra phá hủy

Hai kỹ thuật này thường được dạy cùng nhau vì chúng giải đáp những câu hỏi trái ngược nhau về cùng một cấu trúc. Thử nghiệm phá hủy Phương pháp này tìm kiếm điểm mà phần mềm gặp sự cố, trong khi kiểm tra không phá hủy xác nhận rằng hành vi dự định vẫn được duy trì.

Hai phương pháp này bổ sung cho nhau chứ không phải là lựa chọn thay thế. Chỉ thực hiện kiểm thử không phá hủy sẽ không thể xác minh được việc xử lý lỗi, còn chỉ thực hiện kiểm thử phá hủy sẽ không bao giờ chứng minh được sản phẩm hoạt động đúng chức năng của nó.

Ưu điểm và hạn chế của kiểm thử phần mềm không phá hủy

Việc biết kỹ thuật đó không còn hữu ích ở điểm nào cũng quan trọng như việc biết nó bao gồm những gì.

Ưu điểm

• Thiết kế và triển khai nhanh chóng vì dữ liệu thử nghiệm được lấy trực tiếp từ bản đặc tả kỹ thuật.
• Không yêu cầu môi trường đặc biệt, việc chèn lỗi hoặc tập dữ liệu bị hỏng.
• Cung cấp bằng chứng khớp chính xác với các yêu cầu, phù hợp với các cuộc kiểm toán và phê duyệt.
• Có tác dụng tương đương Kiểm tra bằng tay và theo kịch bản kiểm tra tự động hóaNhờ đó, các trường hợp tương tự có thể được sử dụng lại trong bộ kiểm thử hồi quy.
• Cung cấp tín hiệu sớm và trung thực về tình trạng của công trình ở mọi cấp độ, từ cấp đơn vị trở lên. Thử nghiệm hội nhập đến Thử nghiệm hệ thống.

Hạn chế

• Việc chạy thành công toàn bộ chương trình không nói lên điều gì về cách ứng dụng xử lý dữ liệu đầu vào không hợp lệ, do đó các lỗi nghiêm trọng trong việc xử lý lỗi vẫn có thể tồn tại.
• Phạm vi bao phủ bị giới hạn bởi chất lượng của các yêu cầu. Bất cứ điều gì không được chỉ định sẽ không bao giờ được kiểm thử.
• Việc chỉ lựa chọn phương án tối ưu trước khi phát hành sản phẩm có thể tạo ra sự tự tin sai lầm.
• Nó không đo lường độ bền, khả năng phục hồi hoặc hiệu suất khi chịu áp lực, những yếu tố này cần các kỹ thuật riêng biệt từ tập hợp các phương pháp đo lường rộng hơn. các loại kiểm thử phần mềm.

Hãy coi kiểm tra không phá hủy là nền tảng mà mọi kỹ thuật khác đều dựa trên đó, và lên kế hoạch thực hiện nó trong quy trình tổng thể. vòng đời kiểm thử phần mềm thay vì coi đó là một hoạt động chỉ diễn ra một lần.

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