7 NGUYÊN TẮC KIỂM THỬ PHẦN MỀM CƠ BẢN | CO-WELL Asia

Kiểm thử phần mềm là quá trình vận hành một chương trình nhằm tìm ra lỗi của nó. Để phần mềm hoạt động trơn tru, nó cần phải sạch lỗi. Và nếu kiểm thử phần mềm được thực hiện thành công, việc này sẽ khiến các lỗi không còn xuất hiện. Tuy nhiên, để tiết kiệm thời gian và công sức truy tìm các lỗi, có 7 nguyên tắc kiểm thử quan trọng mà bạn cần tuân theo.

Dưới đây là 7 nguyên tắc Kiểm thử phần mềm đó :

• Kiểm thử chứng minh sự hiện diện của lỗi
• Kiểm thử toàn bộ là không khả thi
• Kiểm thử càng sớm càng tốt
• Lỗi thường phân bổ tập trung
• Nghịch lý thuốc trừ sâu
• Kiểm thử phụ thuộc vào ngữ cảnh
• Quan niệm sai lầm về việc “hết lỗi”

Hãy cùng CO-WELL Asia khám phá kỹ hơn 7 nguyên tắc kiểm thử này nhé :

1. Kiểm thử phần mềm chứng minh sự hiện diện của lỗi

Bằng việc kiểm thử, tất cả chúng ta hoàn toàn có thể làm giảm lượng bugs khi vận dụng nhiều chiêu thức kiểm thử lên phần mềm. Tuy nhiên khi được đưa lên môi trường tự nhiên thật, người dùng cuối trọn vẹn hoàn toàn có thể thấy nhiều lỗi khác không tìm thấy trong quy trình kiểm thử. Kiểm thử chứng tỏ được loại sản phẩm có lỗi nhưng không hề chứng tỏ rằng loại sản phẩm không còn lỗi. Điều này có nghĩa là, sẽ luôn có lỗi không được phát hiện trong phần mềm, ngay cả khi không tìm thấy lỗi, cũng không đồng nghĩa tương quan rằng phần mềm đúng trọn vẹn .

2. Kiểm thử toàn bộ là không khả thi

Đúng vậy, rất khó để kiểm tra hàng loạt những module cũng như những tính năng, phối hợp với nguồn vào và đầu ra trong suốt quy trình kiểm tra. Các mẫu sản phẩm phần mềm lúc bấy giờ cực kỳ phong phú và phức tạp, được tăng trưởng trên nhiều nền tảng, thêm vào đó, ngày càng có nhiều công nghệ tiên tiến mới, năng lực liên kết tài liệu lớn … khiến việc kiểm thử hàng loạt gần như là không hề. Thay vì nỗ lực kiểm thử hàng loạt, hãy xác lập mức độ quan trọng và độ ưu tiên của những module để kiểm thử những phần thiết yếu hoặc gặp nhiều rủi ro tiềm ẩn hơn .

3. Kiểm thử càng sớm càng tốt

Nguyên tắc kiểm thử sớm có nghĩa là việc kiểm thử cần được triển khai càng sớm càng tốt trong vòng đời tăng trưởng phần mềm. Vậy ở bước nào thì được coi là sớm ? Nguyên tắc này cho thấy ta cần phát hiện bug ngay từ những bước tiên phong như nghiên cứu và điều tra nhu yếu ( requirement ) hay design. Phát hiện lỗi càng muộn, ngân sách bỏ ra để giải quyết và xử lý càng cao. Vì vậy, việcthay đổi nhu yếu không đúng từ sớm sẽ khiến tốn ít ngân sách để đổi khác tính năng hơn .

4. Lỗi thường được phân bố tập trung

Nguyên lý về phân bổ lỗi chỉ ra rằng, chỉ 1 số ít ít module chứa hầu hết số lỗi phát hiện được. Những module này thường là những thành phần, tính năng chính của mạng lưới hệ thống. Điều này cũng đúng theo nguyên tắc Pareto : 80 – 20 : 80 % số lỗi tìm thấy ở chỉ 20 % module. Bằng kinh nghiệm tay nghề, những QA / Tester hoàn toàn có thể xác lập được những module có tính rủi ro đáng tiếc và nhiều lỗi như vậy, giúp tập trung chuyên sâu tìm kiếm lỗi nhanh và hiệu suất cao hơn. Tuy nhiên, cách tiếp cận này cũng chứa đựng yếu tố : nếu triển khai kiểm thử tương tự như lặp đi lặp lại, dễ thấy rằng những test case cũ sẽ khó tìm thêm được bug mới .

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

Trong trồng trọt, nếu người nông dân sử dụng lặp lại một liều trừ sâu, những loại sâu bệnh sẽ từ từ thích nghi và trở nên “ nhờn ” với loại thuốc trừ sâu đó. Tương tự với kiểm thử phần mềm, khi lặp đi lặp lại một test case, thì Xác Suất tìm được lỗi là rất thấp. Nguyên nhân là mạng lưới hệ thống hoàn thành xong hơn, lỗi tìm thấy đã được sửa theo test case cũ. Để giải quyết và xử lý hiệu ứng “ thuốc trừ sâu ” này, test case cần được tiếp tục xem lại và chỉnh sửa, thêm nhiều test case mới để tìm lỗi mới ( regression test ) .

Thêm vào đó, QA/ Tester cũng không nên phụ thuộc quá nhiều vào các kỹ thuật test sẵn có. Bạn cần liên tục cải tiến các phương pháp có sẵn để làm việc kiểm thử hiệu quả hơn.

6. Kiểm thử phụ thuộc vào ngữ cảnh

Kiểm thử nhờ vào vào ngữ cảnh, nói một cách đơn thuần, là việc kiểm thử một trang thương mại điện tử sẽ phải khác cách test một ứng dụng đọc tin tức. Tất cả những phần mềm đều được tăng trưởng theo cách khác nhau. Và việc vận dụng chung một “ cách giải ” là sai lầm đáng tiếc. Bạn cần sử dụng cách tiếp cận khác nhau, phương pháp, kỹ thuật test khác nhau, loại test nhờ vào vào loại phần mềm / ứng dụng / website .

7. Quan niệm sai lầm về việc “hết lỗi”

Một phần mềm sạch bug 99 % vẫn hoàn toàn có thể không sử dụng được. Đây là trường hợp phần mềm được kiểm thử bằng một requirement sai. Kiểm thử không chỉ để tìm ra lỗi, mà còn để kiểm tra xem phần mềm có cung ứng được đúng nhu yếu hay không. Chính thế cho nên, việc Không còn lỗi hay Hết lỗi là ý niệm sai lầm đáng tiếc .Quan điểm : “ Nguyên tắc kiểm thử chỉ là để tìm hiểu thêm, không có tính ứng dụng thực tiễn ” ?Đây là quan điểm cực kỳ sai lầm đáng tiếc. Các nguyên tắc kiểm thử giúp tạo ra một kế hoạch kiểm thử rõ ràng và tạo ra những trường hợp kiểm thử sát sao, dễ bắt được bug. Những tester dày dạn kinh nghiệm tay nghề vận dụng những nguyên tắc kiểm thử thuần thục đến độ họ không nghĩ rằng họ đang vận dụng chúng. Vì vậy, việc nguyên tắc kiểm thử không có tính ứng dụng trong thực tiễn là sai lầm đáng tiếc .

Kết luận

Kiểm thử không phải là một hoạt động riêng lẻ mà là một chuỗi các hoạt động phức tạp có quan hệ với nhau, bổ sung cho nhau. Để đơn giản hóa công việc đó đồng thời nhìn nhận việc kiểm thử bao quát hơn, đánh giá hiệu quả của quá trình kiểm thử, việc ứng dụng 7 nguyên tắc kiểm thử kể trên sẽ cực kỳ có ích.

 Đọc thêm các bài viết thú vị từ CO-WELL Asia tại đây.

Cập nhật những thông tin hữu dụng về Kiểm thử phần mềm tại đây .

Source: https://vh2.com.vn
Category : Phần Mềm