Kiểm thử phần mềmPhần Mềm

7 Nguyên tắc Kiểm thử Phần mềm: Tìm hiểu với các Ví dụ

7 nguyên tắc kiểm thử phần mềm

  • Kiểm tra cho thấy sự hiện diện của các thiếu sót
  • Không thể kiểm tra hết mức
  • Thử nghiệm sớm
  • Phân cụm khiếm khuyết
  • Nghịch lý thuốc trừ sâu
  • Thử nghiệm phụ thuộc vào ngữ cảnh
  • Không có lỗi ngụy biện

Lý lịch

Điều quan trọng là bạn phải đạt được kết quả kiểm tra tối ưu trong khi tiến hành kiểm thử phần mềm mà không đi chệch mục tiêu. Nhưng làm thế nào bạn xác định rằng bạn đang theo đúng chiến lược để kiểm tra? Để làm được điều đó, bạn cần phải tuân theo một số nguyên tắc kiểm tra cơ bản. Dưới đây là bảy nguyên tắc kiểm thử phổ biến được thực hành rộng rãi trong ngành công nghiệp phần mềm.

Để hiểu điều này, hãy xem xét một tình huống mà bạn đang di chuyển một tệp từ thư mục A sang thư mục B.

Hãy nghĩ về tất cả các cách có thể để bạn có thể kiểm tra điều này.

Ngoài các tình huống thông thường, bạn cũng có thể kiểm tra các điều kiện sau

  • Cố gắng di chuyển tệp khi nó đang mở
  • Bạn không có quyền bảo mật để dán tệp vào Thư mục B
  • Thư mục B nằm trên ổ đĩa dùng chung và dung lượng lưu trữ đã đầy.
  • Thư mục B đã có một tệp trùng tên, thực tế là danh sách dài vô tận
  • Hoặc giả sử bạn có 15 trường đầu vào để kiểm tra, mỗi trường có 5 giá trị có thể có, số lượng kết hợp cần kiểm tra sẽ là 5 ^ 15

Nếu bạn đã kiểm tra toàn bộ các kết hợp có thể có của dự án THỜI GIAN THI CÔNG & CHI PHÍ sẽ tăng theo cấp số nhân. Chúng tôi cần các nguyên tắc và chiến lược nhất định để tối ưu hóa nỗ lực kiểm tra

Dưới đây là 7 nguyên tắc:

1) Không thể kiểm tra hết mức

Đúng! Không thể kiểm tra hết. Thay vào đó, chúng tôi cần lượng thử nghiệm tối ưu dựa trên đánh giá rủi ro của ứng dụng.

Và câu hỏi triệu đô là, làm thế nào để bạn xác định được rủi ro này?

Để trả lời điều này, chúng ta hãy làm một bài tập

Theo bạn, thao tác nào dễ khiến Hệ điều hành của bạn bị lỗi nhất?

Tôi chắc chắn rằng hầu hết các bạn sẽ đoán được, Mở 10 ứng dụng khác nhau cùng một lúc.

Vì vậy, nếu bạn đang thử nghiệm Hệ điều hành này, bạn sẽ nhận ra rằng các khiếm khuyết có thể được tìm thấy trong hoạt động đa tác vụ và cần được kiểm tra kỹ lưỡng, điều này sẽ đưa chúng ta đến nguyên tắc tiếp theo của chúng tôi Phân cụm khiếm khuyết

2) Phân cụm khiếm khuyết

Phân cụm khiếm khuyết cho biết rằng một số lượng nhỏ các mô-đun chứa hầu hết các lỗi được phát hiện. Đây là ứng dụng của Nguyên tắc Pareto vào kiểm thử phần mềm: khoảng 80% các vấn đề được tìm thấy trong 20% ​​các mô-đun.

Bằng kinh nghiệm, bạn có thể xác định các mô-đun rủi ro đó. Nhưng cách tiếp cận này có những vấn đề riêng

Nếu các bài kiểm tra giống nhau được lặp đi lặp lại nhiều lần, cuối cùng các trường hợp kiểm thử giống nhau sẽ không còn tìm thấy lỗi mới nữa.

3) Nghịch lý thuốc trừ sâu

Việc sử dụng lặp đi lặp lại cùng một hỗn hợp thuốc trừ sâu để diệt trừ côn trùng trong quá trình canh tác theo thời gian sẽ dẫn đến việc côn trùng phát triển khả năng kháng thuốc. Do đó, thuốc trừ sâu trên côn trùng không hiệu quả. Điều tương tự cũng áp dụng cho kiểm thử phần mềm. Nếu cùng một tập hợp các thử nghiệm lặp đi lặp lại được tiến hành, thì phương pháp này sẽ vô ích cho việc phát hiện ra các thiếu sót mới.

Để khắc phục điều này, các trường hợp thử nghiệm cần được thường xuyên xem xét & sửa đổi, bổ sung các trường hợp thử nghiệm mới & khác nhau để giúp tìm ra nhiều khiếm khuyết hơn.

Người kiểm tra không thể chỉ phụ thuộc vào các kỹ thuật kiểm tra hiện có. Anh ta phải liên tục tìm kiếm để cải tiến các phương pháp hiện có nhằm làm cho việc kiểm tra hiệu quả hơn. Nhưng ngay cả sau tất cả mồ hôi và công việc khó khăn trong quá trình thử nghiệm, bạn không bao giờ có thể khẳng định sản phẩm của mình là không có lỗi. Để lái xe về nhà vào thời điểm này, hãy cùng xem đoạn video ra mắt công khai Windows 98

Bạn nghĩ rằng một công ty như MICROSOFT sẽ không kiểm tra hệ điều hành của họ một cách kỹ lưỡng và sẽ mạo hiểm danh tiếng của họ chỉ để thấy hệ điều hành của họ gặp sự cố trong thời gian ra mắt công chúng!

4) Thử nghiệm cho thấy sự hiện diện của thiếu sót

Do đó, nguyên tắc kiểm tra nói rằng – Kiểm tra nói về sự hiện diện của các thiếu sót và không nói về sự vắng mặt của các thiếu sót. tức là Kiểm thử phần mềm làm giảm xác suất của các lỗi chưa được phát hiện còn lại trong phần mềm nhưng ngay cả khi không tìm thấy thiếu sót nào thì nó cũng không phải là bằng chứng về tính đúng đắn.

Nhưng điều gì sẽ xảy ra nếu bạn làm việc chăm chỉ hơn, thực hiện tất cả các biện pháp phòng ngừa và làm cho sản phẩm phần mềm của bạn 99% không có lỗi. Và phần mềm không đáp ứng được nhu cầu & yêu cầu của khách hàng.

Điều này dẫn chúng ta đến nguyên tắc tiếp theo của chúng ta, trong đó nói rằng- Không có lỗi

5) Sự sai lầm về việc không có lỗi

Có thể phần mềm không có lỗi 99% vẫn không sử dụng được. Điều này có thể xảy ra nếu hệ thống được kiểm tra kỹ lưỡng về yêu cầu sai. Kiểm thử phần mềm không chỉ là tìm ra các khiếm khuyết mà còn để kiểm tra xem phần mềm có đáp ứng được các nhu cầu của doanh nghiệp hay không. Sự sai lầm về việc không có lỗi là Việc tìm kiếm và sửa chữa các khiếm khuyết sẽ không giúp ích gì nếu việc xây dựng hệ thống không sử dụng được và không đáp ứng nhu cầu & yêu cầu của người dùng.

Để giải quyết vấn đề này, nguyên tắc kiểm tra tiếp theo nói rằng Kiểm tra sớm

6) Thử nghiệm sớm

Thử nghiệm sớm – Thử nghiệm nên bắt đầu càng sớm càng tốt trong Vòng đời phát triển phần mềm. Vì vậy, bất kỳ khiếm khuyết nào trong các yêu cầu hoặc giai đoạn thiết kế đều được ghi lại trong giai đoạn đầu. Sẽ rẻ hơn nhiều nếu sửa chữa một Lỗi trong giai đoạn đầu của quá trình thử nghiệm. Nhưng người ta nên bắt đầu thử nghiệm sớm như thế nào? Bạn nên bắt đầu tìm lỗi ngay khi các yêu cầu được xác định. Tìm hiểu thêm về nguyên tắc này trong một hướng dẫn đào tạo sau.

7) Thử nghiệm phụ thuộc vào ngữ cảnh

Kiểm tra phụ thuộc vào ngữ cảnh, về cơ bản có nghĩa là cách bạn kiểm tra một trang web thương mại điện tử sẽ khác với cách bạn kiểm tra một ứng dụng thương mại ngoài giá trị. Tất cả các phần mềm được phát triển không giống nhau. Bạn có thể sử dụng một cách tiếp cận, phương pháp luận, kỹ thuật và loại thử nghiệm khác tùy thuộc vào loại ứng dụng. Ví dụ: thử nghiệm, bất kỳ hệ thống POS nào tại một cửa hàng bán lẻ sẽ khác với thử nghiệm một máy ATM.

Lầm tưởng: “Các nguyên tắc chỉ mang tính chất tham khảo. Tôi sẽ không sử dụng chúng trong thực tế.”

Điều này là rất sai sự thật. Các Nguyên tắc Kiểm tra sẽ giúp bạn tạo Chiến lược Kiểm thử hiệu quả và soạn thảo các trường hợp kiểm thử bắt lỗi.

Nhưng việc học các nguyên tắc sát hạch cũng giống như học lái xe lần đầu.

Ban đầu, khi bạn học lái xe, bạn chú ý đến từng thứ như chuyển số, tốc độ, xử lý ly hợp, … Nhưng với kinh nghiệm, bạn chỉ tập trung vào việc lái xe, phần còn lại sẽ đến một cách tự nhiên. Như vậy bạn thậm chí còn tổ chức các cuộc trò chuyện với những hành khách khác trên xe.

Điều này cũng đúng đối với các nguyên tắc kiểm tra. Những người kiểm tra có kinh nghiệm đã nội dung những nguyên tắc này đến mức họ áp dụng chúng ngay cả khi không cần suy nghĩ. Do đó, lầm tưởng rằng các nguyên tắc không được sử dụng trong thực tế đơn giản là không đúng.

Blog Tiền Điện Tử

Blog tiền điện tử công thông tin tổng hợp uy tín nhất tất cả các mảng xã hội, giáo dục , công nghệ số. Với khả năng số hóa mạnh mẽ hy vọng sẽ mang lại cho quý bạn đọc những thông tin chính xác nhất 24/24
Back to top button