Bài viết này giới thiệu bảy nguyên tắc kiểm tra cơ bản của Kiểm thử phần mềm mà mọi người kiểm thử phần mềm chuyên nghiệp và chuyên gia QA nên biết ngoài người quản lý dự án. Show
Bối cảnh của các nguyên tắc kiểm thử phần mềmĐiều quan trọng là chúng tôi phải đạt được kết quả kiểm tra tối ưu với kiểm thử phần mềm mà không đi chệch khỏi mục tiêu kiểm thử. Nhưng làm thế nào để chúng ta xác định liệu chúng ta có đúng hay không? chiến lược kiểm tra theo dõi? Đối với điều này, chúng tôi phải tuân theo một số nguyên tắc kiểm tra cơ bản. Để hiểu điều này, hãy nghĩ đến một kịch bản thử nghiệm trong đó chúng ta phải di chuyển một tệp từ thư mục A sang thư mục B. Hãy nghĩ về tất cả những điều có thể mà chúng ta sẽ phải thử nghiệm cho điều đó. Ngoài việc chạy tốt kịch bản thử nghiệm chúng tôi cũng có thể kiểm tra các điều kiện sau:
Có một danh sách vô tận về các loại thử nghiệm này để đưa ra, chỉ dành cho trường hợp đơn giản này. Hoặc nghĩ về một màn hình có 15 trường đầu vào, mỗi trường có 5 giá trị có thể, số tổ hợp cần kiểm tra là 5 đến 15 công suất. Kiểm tra thử nghiệm kiểm tra ... Nếu chúng tôi phải kiểm tra tất cả các kết hợp có thể có của một ứng dụng SaaS, thời gian và chi phí sẽ tăng theo cấp số nhân. Đó là lý do tại sao chúng ta cần những nguyên tắc và chiến lược nhất định để tối ưu hóa số lượng bài kiểm tra. KHAI THÁC. Kiểm tra, thử nghiệm, kiểm tra, thử nghiệm toàn diện là không thểDo đó, không thể thử nghiệm hết mức, đặc biệt là đối với SaaS. Thay vào đó, chúng tôi tìm kiếm số lượng thử nghiệm tối ưu cần thiết dựa trên phân tích rủi ro của ứng dụng. Thử nghiệm nào có khả năng bị lỗi phần mềm hệ thống? Hầu hết mọi người sẽ đặt cược vào khả năng 10 người dùng khác nhau sẽ mở các ứng dụng cùng một lúc. Vì vậy, nếu chúng ta phải kiểm tra một ứng dụng SaaS, hầu hết các lỗi đều có khả năng nằm trong các hoạt động đa nhiệm và vì vậy chúng ta phải kiểm tra điều này một cách kỹ lưỡng. KHAI THÁC. Khiếm khuyết cụmDefect Clustering giả định rằng một số lượng nhỏ các mô-đun chứa nhiều khiếm khuyết nhất. Đây là ứng dụng của nguyên tắc Pareto để kiểm thử phần mềm: khoảng 80% sự cố xảy ra trong 20% số mô-đun. Chỉ thông qua kinh nghiệm, chúng tôi mới có thể xác định các mô-đun rủi ro như vậy. Thường có các mô-đun trong đó các tệp chính được duy trì hoặc các đột biến đơn lẻ được nhập vào. Chúng tôi không gặp rủi ro lớn với điều đó. Tuy nhiên, luôn có 1 hoặc 2 mô-đun nơi công việc thực sự diễn ra. Tất cả dữ liệu được kết hợp với nhau ở đó và được xử lý thành thông tin mới. Hoặc có liên kết với các hệ thống khác. Ví dụ: hãy xem xét mô-đun lập hóa đơn có liên kết đến hệ thống kế toán. Các loại mô-đun này có nguy cơ lỗi lớn nhất. KHAI THÁC. Nghịch lý thuốc trừ sâuNếu chúng tôi lặp đi lặp lại các thử nghiệm giống nhau, chúng tôi sẽ không nhận được bất kỳ thử nghiệm mới nào có cùng các trường hợp thử nghiệm lỗi tìm thêm. Việc sử dụng thường xuyên cùng một loại chất độc nông nghiệp để tiêu diệt côn trùng trong nông nghiệp, theo thời gian, sẽ khiến côn trùng phát triển khả năng kháng thuốc trừ sâu. Kết quả là, nó không còn hiệu quả đối với những loài côn trùng đó. Đối với kiểm thử phần mềm cũng vậy. Nếu chúng ta chạy lặp đi lặp lại cùng một loạt các bài kiểm tra, phương pháp kiểm tra phần mềm 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, chúng ta phải thường xuyên xem xét lại các test case. Mới và khác thêm các trường hợp thử nghiệm vào bộ thử nghiệm giúp tìm ra nhiều khiếm khuyết hơn. Người kiểm tra không nên dựa vào các kỹ thuật kiểm tra hiện có. Họ phải liên tục xem liệu họ có thể cải tiến các phương pháp hiện có để làm cho việc thử nghiệm hiệu quả hơn hay không. Nhưng ngay cả sau những nỗ lực thử nghiệm khó khăn nhất, chúng tôi không bao giờ có thể khẳng định rằng ứng dụng này là hoàn hảo. Bạn có nghĩ rằng một công ty như Microsoft sẽ không kiểm tra kỹ lưỡng hệ điều hành của họ chỉ để làm hỏng hệ điều hành của họ trong buổi ra mắt công khai không? Điều này thực sự đã xảy ra với Windows 98! KHAI THÁC. Kiểm tra chứng minh rằng có lỗi trong phần mềmKiểm thử nói lên điều gì đó về sự hiện diện của các lỗi trong phần mềm, không phải về sự vắng mặt của chúng. Với điều này, chúng tôi giảm nguy cơ xuất hiện các lỗi chưa được khắc phục trong phần mềm bằng Kiểm thử phần mềm. Nhưng ngay cả khi không có khuyết tật nào được tìm thấy, đó không phải là bằng chứng về tính đúng đắn. Có một số kỹ thuật kiểm thử mà các lập trình viên cố tình tạo ra một số lỗi trong phần mềm. Ví dụ 5. Nếu người kiểm tra tìm thấy 4, chúng tôi có thể nói rằng phần mềm là 80% OK. KHAI THÁC. Không có lỗiCó khả năng phần mềm không có lỗi 99% nhưng không sử dụng được cho tổ chức. Điều này có thể xảy ra, ví dụ: nếu chúng tôi kiểm tra ứng dụng kỹ lưỡng nhưng sai yêu cầu. Vì vậy, kiểm thử phần mềm không chỉ là tìm ra lỗi mà còn là xác định xem phần mềm có đáp ứng đúng nhu cầu kinh doanh hay không. Việc tìm kiếm và sửa chữa các khiếm khuyết sẽ không hữu ích nếu hệ thống đã xây dựng không sử dụng được và không đáp ứng được nhu cầu và yêu cầu của người dùng. Tất nhiên, đây là cơn ác mộng tồi tệ nhất của mọi nhà quản lý dự án. KHAI THÁC. Kiểm tra sớm trong quy trình phần mềmThử nghiệm sớm - Kế hoạch dự án cần cung cấp cho việc thử nghiệm được bắt đầu sớm nhất có thể trong quá trình phát triển Phần mềm. Nếu điều đó thành công, chúng tôi có thể xác định sớm bất kỳ thiếu sót nào trong các yêu cầu hoặc thiết kế. Nó rẻ hơn nhiều để giải quyết một khiếm khuyết trong các giai đoạn thử nghiệm ban đầu. Nhưng chúng ta nên bắt đầu thử nghiệm sớm như thế nào? Người lãnh đạo dự án muốn chúng tôi tìm ra tất cả các lỗi ngay khi chúng tôi viết ra các yêu cầu. Vì vậy, chúng tôi phải kiểm tra báo cáo yêu cầu và các thiết kế sau đó. Lập kế hoạch đánh giá trong thời gian thích hợp. KHAI THÁC. Kiểm tra là phụ thuộc vào ngữ cảnhKiểm tra phụ thuộc vào ngữ cảnh, về cơ bản có nghĩa là cách chúng tôi kiểm tra một webshop khác với kiểm tra một ứng dụng Windows. Tất cả các phần mềm được phát triển đều khác nhau. Một cách tiếp cận, phương pháp luận và kỹ thuật khác có thể đã được sử dụng để tạo ra phần mềm. Loại thử nghiệm chúng ta cần thực hiện tùy thuộc vào loại ứng dụng. Ví dụ: thử nghiệm thanh toán bằng mã PIN tại quầy thu ngân trong cửa hàng khác với thử nghiệm Ứng dụng SaaS COTS. Tóm tắt bảy nguyên tắc kiểm tra
 Thảo luận với chúng tôi LinkedIn. Tóm tắt điều khoản Nguyên tắc kiểm tra phần mềm 7 Mô tả Điều quan trọng là bạn đạt được kết quả kiểm tra tối ưu với kiểm tra phần mềm mà không đi lệch khỏi mục tiêu kiểm tra. Nhưng làm thế nào để bạn xác định xem bạn đang theo chiến lược kiểm tra chính xác? Đối với điều này, bạn phải tuân theo một số nguyên tắc cơ bản. |
