7 nguyên tắc kiểm thử phần mềm. Nắm vững nguyên lý bạn sẽ thật sự thành công

7 nguyên tắc kiểm thử phần mềm – trong bài viết này BlogCNTT sẽ giới thiệu 7 nguyên tắc cơ bản mà bất kỳ chuyên gia QA nào đều phải biết.

Điều quan trọng là làm thế nào để kiếm thử đúng tiến trình mà phải đúng mục đích. Câu hỏi đặt ra ở đây là làm sao bạn biết bạn đang đi theo một chiến lược đúng hướng. Muốn như vậy bạn cần tuân theo những nguyên tắc cơ bản được phổ biến rộng rãi trong ngành công nghệ phần mềm.

Để hiểu điều này, hãy xem xét một kịch bản trong đó bạn đang di chuyển một tệp từ thư mục A sang Thư mục B.

Dưới đây là một vài trường hợp ngoại lệ khi bạn thực hiện kịch bản.

  • Đang 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 chung và dung lượng lưu trữ đã đầy.
  • Thư mục B đã có một tệp có cùng tên, trên thực tế, danh sách này là 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ể, số lượng kết hợp sẽ được kiểm tra sẽ là 5 ^ 15

Nếu bạn muốn kiểm tra toàn bộ dự án kết hợp có thể THỜI GIAN THỰC HIỆN & CHI PHÍ sẽ tăng theo cấp số nhân. Thì lúc này là lúc bạn cần 7 nguyên tắc dưới đây.

Không thể kiểm tra toàn diện

Vâng! Kiểm tra toàn diện là không thể. Thay vào đó, hãy tìm ra kịch bản thử nghiệm tối ưu để đánh giá rủi do của phần mềm.

Một kịch bản kiểm thử một ứng dụng trên điện thoại di động. Bạn sẽ cần:

  • Các thiết bị từ Apple bao gồm các thế hệ IPhone.
  • Các thiết bị có trang bị Androi: bạn có sẵn sàng mua để test ứng dụng trên hàng tá những chiếc điện thoại.

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

Sự tập trung của lỗi

Theo các chuyên gia đã chỉ ra rằng các lỗi đều tập trung ở một vài những mo-dun nhất định nào đó. Nó không nằm dàn trải trên tất cả mo-dun của sản phầm.

Khi bạn tìm được một bug tại một mo-dun nào đó thì bạn đừng dùng lại, hãy dùng hết sức bình sinh của mình. Có thể bạn sẽ gặp cả tá lỗi xuất hiện. Đây là ứng dụng của Nguyên tắc Pareto để kiểm tra phần mềm: khoảng 80% các vấn đề được tìm thấy trong 20% ​​các mô-đun.

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

Việc sử dụng lặp đi lặp lại cùng một loại thuốc trừ sâu để diệt côn trùng trong quá trình nuôi sẽ theo thời gian dẫn đến việc côn trùng phát triển tính kháng thuốc trừ sâu. 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 bộ các thử nghiệm lặp đi lặp lại được thực hiện, phương pháp sẽ vô dụng để phát hiện ra các khiếm khuyết mới.

Để khắc phục điều này, các trường hợp thử nghiệm cần phải được xem xét & sửa đổi thường xuyên, thêm 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.

Kiểm thử đưa ra lỗi

Do đó, nguyên tắc test cho rằng – Kiểm tra nói về sự xuất hiện của bug và không nói về sự hiện diện của các bug. Tức là kiểm thử phần mềm làm giảm xác suất lỗi chưa được phát hiện trong phần mềm nhưng ngay cả khi không tìm thấy lỗi. Đó không phải là bằng chứng về tính chính xác.

Nhưng nếu, bạn làm việc chăm chỉ hơn, thực hiện mọi biện pháp phòng ngừa và làm cho sản phẩm phần mềm của bạn không có lỗi 99%. Những cuối cùng sản phẩm đó không ai sử dụng cả. Bạn muốn thích phần mềm được fix 99% lỗi nhưng không ai dùng hay muốn phần mềm có 50% lỗi lại nhiều người dùng?

Hãy tin một ngày bạn không thể tìm ra lỗi thì lỗi có thể xuất hiện khi có các tác động bên ngoài: nâng cấp hệ thống, nâng cấp phần mềm,…

 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. Đây có thể là trường hợp nếu hệ thống được kiểm tra kỹ lưỡng cho các yêu cầu sai. Kiểm thử phần mềm không chỉ đơn thuần là tìm lỗi, mà còn để kiểm tra xem phần mềm có đáp ứng nhu cầu kinh doanh không. Sự vắng mặt của Lỗi là sai lầm, tức là Tìm và sửa lỗi 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.

Thử nghiệm sớm

Kiểm tra sớm – Kiểm tra nên bắt đầu sớm nhất có thể trong Vòng đời phát triển phần mềm. Vì vậy, bất kỳ khiếm khuyết trong các yêu cầu hoặc giai đoạn thiết kế được nắm bắt trong giai đoạn đầu. Chi phí rẻ hơn nhiều để sửa một khiếm khuyết trong giai đoạn đầu của thử nghiệm. Nhưng làm thế nào sớm nên bắt đầu thử nghiệm? Bạn nên bắt đầu tìm lỗi ngay khi yêu cầu được xác định. Việc kiểm thử sớm có thể thực hiện bởi lập trình viên hoặc bắt đầu 60% của dự án.

Kiểm thử phần mềm phụ thuộc ngữ cảnh

Kiểm tra phụ thuộc vào ngữ cảnh là gì?

Có nghĩa là cách bạn kiểm tra sàn TMDT sẽ khác với cách bạn kiểm tra ngoài ứng dụng. 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, kỹ thuật và loại thử nghiệm khác nhau. Ví dụ: Tính năng của facebook và zalo hoàn toàn khác nha.

Summary of the Seven Testing Principles

Nguyên tắc 1Testing shows presence of defects
Nguyên tắc 2Exhaustive testing is impossible
Nguyên tắc 3Early Testing
Nguyên tắc 4Defect Clustering
Nguyên tắc 5Pesticide Paradox
Nguyên tắc 6Testing is context dependent
Nguyên tắc 7Absence of errors – fallacy

Quan niệm: “Nguyên tắc chỉ mang tính 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. Nguyên tắc kiểm thử sẽ giúp bạn tạo Chiến lược kiểm thử phần mềm hiệu quả.

Nhưng học các nguyên tắc kiểm tra cũng giống như học lái xe lần đầu tiên.

Ban đầu, trong khi bạn học lái xe, bạn chú ý đến từng thứ và mọi thứ như sang số, tốc độ, xử lý ly hợp, v.v. Nhưng với kinh nghiệm, bạn chỉ tập trung vào việc lái phần còn lại 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 các hành khách khác trong xe.

Điều tương tự cũng đúng cho các nguyên tắc thử nghiệm. Những người testing có kinh nghiệm đã chắt lọc những nguyên tắc này lên 1 tầm cao. Do đó, quan niệm cho 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.

Categories

Related Posts

Trả lời

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *