日本語
English7 Nguyên Tắc Trong Kiểm Thử Phần Mềm
Hoạt động Kiểm thử phần mềm được ra đời cùng với sự ra đời của phần mềm. Từ đó đến nay, đã có nhiều nguyên tắc được đúc kết để giúp cho việc Kiểm thử đạt hiệu quả. Tuy nhiên, trong số các nguyên tắc đó có 7 Nguyên Tắc cốt lõi cần ghi nhớ khi bắt đầu thực hiện Kiểm thử phần mềm như sau:
1/ Kiểm thử có thể chứng minh sản phẩm có lỗi, không thể chứng minh sản phẩm không có lỗi
Khi kiểm thử phần mềm, trường hợp phát hiện ra lỗi thì chúng ta có thể khẳng định rằng sản phẩm đó có lỗi. Tuy nhiên, trường hợp cho dù có thực hiện kiểm thử kỹ đến thế nào cũng không tìm ra được lỗi thì ta cũng không thể khẳng định rằng sản phẩm đó không còn lỗi. Bởi vì, có khả năng các trường hợp kiểm thử (test case) của ta chưa bao gồm các trường hợp xảy ra lỗi.
Ví dụ: Khi kiểm thử tính năng lưu DB, yêu cầu khi nhấn nút lưu sẽ chỉ cập nhật giá trị của các record được chỉ định, các record khác giữ nguyên. Khi kiểm thử, bạn chỉ kiểm thử các record được chỉ định xem có lưu đúng hay chưa mà không kiểm tra các record còn lại. Kết quả là các record còn lại cũng bị cập nhật theo nhưng bạn đã không nhận ra.
Vì vậy, điều quan trọng là cần thiết kế các trường hợp kiểm thử sao cho có thể bao phủ được các trường hợp, tìm ra được càng nhiều lỗi càng tốt.
2/ Kiểm thử toàn bộ các trường hợp là không thể
Kiểm thử toàn bộ các trường hợp có nghĩa là kiểm thử toàn bộ dữ liệu nhập vào phần mềm và tất cả các trường hợp của điều kiện kiểm thử.
Ví dụ cụ thể như sau: Yêu cầu khi nhập nhiều hơn 8 ký tự sẽ trả về message lỗi. Khi test, ta sẽ kiểm thử các trường hợp nhập ít hơn hoặc bằng 8 ký tự (gọi là case bình thường) và các trường hợp nhập nhiều hơn 8 ký tự (gọi là case bất thường). Các case bình thường ta sẽ nhập lần lượt 0, 1, 2, 3, 4, 5, 6, 7, 8 ký tự. Còn các case nhập nhiều hơn 8 ký tự, nếu kiểm thử toàn bộ thì ta sẽ không bao giờ có thể có đủ thời gian để test xong được vì nhiều hơn 8 ký tự là test đến vô tận. Vậy, phải kiểm thử trường hợp này như thế nào để có thể tiết kiệm thời gian mà vẫn đảm bảo chức năng hoạt động đúng? Trong kiểm thử phần mềm có rất nhiều kỹ thuật kiểm thử và trong trường hợp này, ta có thể áp dụng Kỹ thuật phân vùng tương đương. Ở trên, ta đã phân tích ra được 2 vùng giá trị, một vùng giá trị nếu nhập vào sẽ trả lỗi (nhập nhiều hơn 8 ký tự) và một vùng giá trị nếu nhập vào sẽ hoạt động đúng (nhập ít hơn hoặc bằng 8 ký tự). Ta chỉ cần chọn 1 giá trị đại diện nằm trong 2 vùng đó và test là được. Nhập 6 ký tự và không bị trả lỗi, tức đã hoạt động đúng. Nhập 10 ký tự và hệ thống trả lỗi, tức đã hoạt động đúng.Ngược lại, nếu ta nhập 6 ký tự và bị trả lỗi, hoặc nhập 10 ký tự nhưng hệ thống không trả lỗi thì tức là hệ thống đang hoạt động không đúng. Kỹ thuật kiểm thử này gọi là Kỹ thuật phân vùng tương đương.
Vì vậy, khi kiểm thử thực tế cần xem xét các yếu tố như tính chất và mục đích của phần mềm, cũng như cách nó được sử dụng để xác định những trọng điểm cần tập trung và thứ tự ưu tiên khi kiểm thử.
3/ Kiểm thử sớm giúp tiết kiệm thời gian và chi phí
Việc phát hiện lỗi và sửa lỗi sớm sẽ giúp tiết kiệm thời gian và chi phí sửa lỗi. Nếu lỗi được phát càng muộn thì càng tốn nhiều thời gian và chi phí sửa lỗi. Hãy thử suy nghĩ đến việc lắp bóng đèn cho một tòa nhà văn phòng. Nếu phát hiện ra màu của bóng đèn không phù hợp ở giai đoạn thiết kế, thì chỉ cần thay đổi thiết kế là được. Nếu phát hiện lỗi đó ở giai đoạn đã chuẩn bị xong bóng đèn, thì cần đổi lại bóng đèn và chi phí đổi trả. Tuy nhiên, nếu phát hiện ở giai đoạn sau khi đã lắp xong toàn bộ bóng đèn, thì sẽ rất tốn thời gian và chi phí: chi phí tháo dỡ, mua lại bóng đèn mới và lắp lại. Kiểm thử phần mềm cũng tương tự như vậy, phát hiện lỗi càng sớm, càng tiết kiệm được thời gian và chi phí sửa chữa.
Vì vậy, việc thực hiện kiểm thử nên được thực hiện càng sớm càng tốt, từ những bước đầu tiên trong quy trình phát triển.
4/ Lỗi phân bố không đồng đều
Phần mềm được tạo nên từ nhiều thành phần, chức năng ghép lại với nhau (UI, database, chức năng tính toán, lưu data,…). Việc phát triển những thành phần, chức năng đó cũng có những độ khó khác nhau. Ở một số dự án có quy mô lớn thì có khả năng có nhiều team sẽ đảm nhiệm một số chức năng và thành phần nhất định, sau đó ghép lại với nhau. Chính vì vậy, lỗi ở phần mềm thường không phân bố đồng đều mà tập trung ở một số chức năng hoặc thành phần nhất định. Theo nguyên lý Pareto, 80% kết quả là do 20% nguyên nhân gây nên.
Do đó, chúng ta có thể phân tích kết quả kiểm thử trong quá khứ và kết quả kiểm thử gần đây để dự đoán những chỗ có khả năng xảy ra lỗi cao. Sau đó, tập trung kiểm thử những chỗ đó sẽ giúp cho việc kiểm thử đạt hiệu quả tốt.
5/ Chú ý Nghịch lý Thuốc trừ sâu
Nghịch lý Thuốc trừ sâu là khi ta sử dụng một loại thuốc trừ sâu liên tục, lâu dần các loại sâu bọ sẽ hình thành khả năng kháng thuốc và thuốc trừ sâu sẽ không còn tác dụng với chúng nữa. Trong Kiểm thử phần mềm, nếu ta dùng đi dùng lại một bộ test case để kiểm thử phần mềm, lâu dần sẽ không phát hiện ra được lỗi khi kiểm thử bằng bộ test case đó nữa. Vì những lỗi được phát hiện ra từ các trường hợp test đó đã được sửa.
Vì vậy, cần liên tục làm mới trường hợp test để kiểm tra ra được các lỗi mới. Mỗi lần phát hiện lỗi từ việc thay đổi trường hợp test như vậy, chắc chắn sẽ giúp nâng cao chất lượng của phần mềm.
Tuy nhiên, trong phương pháp Kiểm thử Hồi quy, việc sử dụng lại bộ trường hợp kiểm thử cũ sẽ có tác dụng. Kiểm thử Hồi quy tức là thực hiện kiểm thử các chức năng liên quan, hoặc toàn bộ phần mềm khi có thay đổi ở một số chức năng nhất định. Khi thực hiện Kiểm thử Hồi quy cho các chức năng không có thay đổi, ta có thể sử dụng lại bộ trường hợp kiểm thử cũ để kiểm tra lại. Lỗi được phát hiện trong trường hợp này gọi là lỗi regression. Ở các công ty Nhật Bản và Việt Nam, lỗi này được gọi là lỗi degrade.
6/ Kiểm thử theo ngữ cảnh
Mỗi phần mềm có những mục đích sử dụng, cấu trúc hệ thống và điều kiện sử dụng khác nhau, cần áp dụng những phương pháp kiểm thử khác nhau. Ví dụ kiểm thử phần mềm kế toán sẽ khác với kiểm thử phần mềm đọc tin tức. Khi kiểm thử phần mềm kế toán, cần chú trọng test các logic tính toán, đảm bảo việc tính toán không xảy ra sai sót. Còn đối với phần mềm đọc tin tức, ta sẽ chú trọng vào test phần hiển thị xem nội dung tin tức có được hiển thị đúng, dễ xem, dễ đọc hay chưa.
Nói chung, cần xem xét mục đích sử dụng, cấu trúc hệ thống và điều kiện sử dụng của sản phẩm để chọn phương pháp kiểm thử và tạo các trường hợp kiểm thử phù hợp.
7/ Bẫy “không lỗi”
Không phải sửa hết tất cả các lỗi được báo cáo là phần mềm sẽ hoạt động hoàn hảo. Đây chính là bẫy “không lỗi”. Khi nhận báo cáo lỗi, cần xem xét nếu sửa lỗi đó có ảnh hưởng như thế nào đến tính năng và hệ thống của phần mềm rồi mới quyết định sửa hay không. Vì thế nên, trong cộng đồng thường có câu đùa rằng: “Đó không phải bug, đó là tính năng.”
Việc ghi nhớ và áp dụng những nguyên tắc phía trên sẽ giúp cho hoạt động kiểm thử của bạn hiệu quả hơn. Tuy nhiên, điều quan trọng vẫn là khả năng tưởng tượng và lý giải những trường hợp sẽ xảy ra khi thực hiện kiểm thử thực tế.
※Câu hỏi luyện tập: