Chương 1: CƠ SỞ LÝ THUYẾT VỀ KIỂM THỬ PHẦN MỀM 1. Tổng quan về kiểm thử phần mềm 1.1 Kiểm thử phần mềm là gì? - Kiểm thử phần mềm là một cuộc kiểm tra nhằm cung cấp cho các bên liên quan (khách hàng, nhóm phát triển) thông tin về chất lượng sản phẩm dịch đang kiểm thử. - Mục đích của kiểm thử phần mềm là chỉ ra rằng phần mềm thực hiện đúng các chức năng mong muốn. - Kiểm thử phần mềm là quy trình thiết lập sự tin tưởng về việc phần mềm hay hệ thống thực hiện được điều mà nó hỗ trợ.
- Kiểm thử phần mềm là quy trình thi hành phần mềm với ý định tìm kiếm các lỗi của nó. - Kiểm thử phần mềm được xem là quy trình cố gắng tìm kiếm các lỗi của phần mềm. Tại sao kiểm thử phần mềm là cần thiết? - Kiểm thử phần mềm là thực sự cần thiết vì nó chỉ ra những khiếm khuyết và sai sót đã được thực hiện trong giai đoạn phát triển. - Nó quan trọng vì nó đảm bảo độ tin cậy của khách hàng và sự hài lòng của họ trong ứng dụng.
- Nó là rất quan trọng vì nó đảm bảo chất lượng của sản phẩm. - Kiểm thử là cần thiết cho một hoạt động hiệu quả của ứng dụng phần mềm hoặc sản phẩm. - Điều quan trọng là để đảm bảo rằng các ứng dụng không có bất kỳ kết quả nào không như mong đợi, bởi vì chi phí sẽ tăng cao nếu phát hiện lỗi trong các giai đoạn sau phát triển phần mềm. - Đó là yêu cầu thiết yếu giúp sản phẩm tồn tại trong kinh doanh.
Các mục tiêu chính của kiểm thử phần mềm - Phát hiện càng nhiều lỗi càng tốt trong thời gian kiểm thử xác định trước. - Chứng minh rằng sản phẩm phần mềm phù hợp với các đặc tả yêu cầu của nó. - Tạo các test case chất lượng cao, thực hiện kiểm thử hiệu quả và tạo ra các báo cáo vấn đề đúng và hữu dụng. Định nghĩa Lỗi: Là những gì hoạt động không đúng như mong đợi từ khách hàng hoặc nhà sản xuất.
Tại sao lại xảy ra lỗi? - Các lỗi có thể bị phát sinh do nhiều lý do, nhưng trong quá trình phân tích các dự án mẫu thì lý do chính có thể được tìm thấy trong quá trình truy vết theo bản đặc tả. - Những lý do liên quan đến bản đặc tả là nguyên nhân chính làm xuất hiện lỗi tài liệu đặc tả. - Một số bản đặc tả không viết cụ thể, không đủ kỹ lưỡng, hoặc nó liên tục thay đổi, nhưng lại không có sự phối hợp, trao đổi thông tin kịp thời với các đội phát triển dự án. - Lý do quan trọng tiếp theo mà dễ phát sinh lỗi là quá trình thiết kế.
Các lỗi xuất hiện ở đây với những lý do tương tự như khi chúng xuất hiện trong bản đặc tả. Nó bị dồn lại, thay đổi, hoặc giao tiếp không tốt. - Cuối cùng là viết mã - Những lỗi về viết mã có thể được xem là quen thuộc nhất, lỗi về viết mã thường xảy ra do giao tiếp không tốt giữa người lập trình và người phân tích dự án, áp lực của lịch trình hay phần mềm phức tạp và nguyên nhân thường gặp nhất phát sinh ra lỗi ở người lập trình là sao chép mà quên chỉnh sửa. Chi phí cho việc sửa lỗi ? Hình 1.
Chi phí cho việc sửa lỗi - Chi phí cho việc sửa lỗi có thể tăng đột ngột trên toàn bộ dự án - Chi phí được tính theo hàm loga, mỗi lần chúng tăng lên gấp 10 lần. Lỗi được tìm thấy và sửa lại trong thời gian gần nhất khi bản đặc tả bắt đầu được viết thì chi phí có thể không là gì cả, hoặc chỉ là 1$ cho ví dụ của Hình 1. Cũng với lỗi tương tự, nếu nó không được tìm thấy cho đến khi phần mềm được được lập trình và kiểm thử thì chi phí có thể lên tới 10$ đến 100$. Nếu để một khách hàng tìm ra nó, thì chi phí có thể lên tới hàng nghìn thậm chí hàng triệu dollar.
Từ ví dụ trên, ta có thể kết luận, việc tìm ra lỗi là càng sớm càng tốt, để giảm chi phí cho việc sửa lỗi. Nguyên tắc kiểm tra lỗi chung - Kiểm thử chứng minh sự hiện diện của lỗi: Kiểm thử chỉ chứng minh được rằng phần mềm đang có lỗi, kiểm thử không thể chứng minh được sản phẩm không còn lỗi. Nghĩa là sản phẩm luôn luôn có lỗi dù có kiểm thử bao nhiêu đi nữa. Do đó, điều quan trọng là chúng ta phải thiết kế các trường hợp kiểm thử (test case) sao cho có thể tìm được càng nhiều lỗi càng tốt.
- Kiểm thử toàn bộ là không khả thi: Kiểm tra tất cả các trường hợp là không khả thi, do các yếu tố về thời gian và chi phí, vì vậy việc phân tích rủi ro và đưa ra các mức độ ưu tiên để kiểm tra các trường hợp cần thiết 5 nhất, rồi sau đó tùy thuộc vào tiến trình của dự án mà kiểm tra các trường hợp còn lại theo mức độ ưu tiên thấp hơn. - Kiểm thử càng sớm càng tốt: Hoạt động kiểm thử được triển khai càng sớm càng tốt, kiểm tra ngay từ giai đoạn đầu lấy yêu cầu khách hàng hay thiết kế tài liệu sản phẩm. Thông thường, thời gian cho kiểm thử thường bị co lại khi sản phẩm gần ra thị trường. Do đó, việc kiểm thử sớm trong giai đoạn đầu sẽ giúp chúng ta có thời gian để tiến hành kiểm thử trong từng giai đoạn một cách đầy đủ.
Việc phát hiện lỗi càng trễ bao nhiêu thì chi phí để sửa lỗi càng cao bấy nhiêu, tương tự việc thay đổi yêu cầu không đúng ngay từ đầu thường tốn ít chi phí thay đồi tính năng trong hệ thống. - Lỗi phân bố tập trung: Trong quá trình kiểm thử, chúng ta có thể dễ dàng quan sát thấy, 80% số lỗi được tìm thấy trong 20% tính năng của hệ thống. Điều này cho thấy, lỗi thường tập trung ở một vài tính năng chính của chương trình. - Nghịch lý thuốc trừ sâu: Trong cuộc sống nếu ta cứ phun một loại thuốc trừ sâu với liều lượng như nhau thì một số loại sau nhờn thuốc sẽ không được diệt sạch.
Cũng như trong kiểm thử phần mềm, nếu bạn cứ thực thi lặp đi lặp lại một bộ test case thì có khả năng rất thấp bạn sẽ tìm được lỗi từ những trường hợp kiểm thử này. Nguyên nhân là do khi hệ thống ngày càng hoàn thiện, những lỗi được tìm thấy lúc trước đã được sửa trong khi những trường hợp kiểm thử đã cũ. Do đó, khi một lỗi được sửa hay một tính năng mới được thêm vào, chúng ta nên tiến hành làm regression (kiểm thử hồi qui) nhằm mục đích đảm bảo những thay đổi này không ảnh hưởng đến những vùng khác của sản phẩm. Tuy nhiên, các trường hợp kiểm thử trong regression test cũng cần phải được cập nhật để phản ánh sự thay đổi tương ứng của hệ thống.
6 - Kiểm thử phụ thuộc vào ngữ cảnh: Tùy vào loại cũng như bản chất của ứng dụng mà chúng ta sẽ áp dụng những phương thức, kỹ thuật, cũng như loại kiểm thử khác nhau. Chẳng hạn như phần mềm trong các thiết bị y khoa cần sẽ được kiểm thử kỹ lưỡng hơn một trò chơi điện tử. Quan trọng hơn, việc kiểm thử trên loại thiết bị này đòi hỏi phải dựa trên đánh giá rủi ro, đáp ứng những quy định nghiêm ngặt trong y khoa cũng như một bộ kiểm thử đặc thù. Tương tự, một website “lớn” cần phải được kiểm thử một cách đầy đủ từ hiệu năng đến tính năng nhằm đảm bảo server không bị ảnh hưởng khi có nhiều người truy cập vào hệ thống.
- Quan niệm sai lầm về việc hết lỗi: Việc không tìm thấy lỗi trên sản phẩm không đồng nghĩa với việc sản phẩm đã sẵn sàng để tung ra thị trường. Việc không tìm thấy lỗi cũng có thể là do bộ test case được tạo ra chỉ nhằm kiểm tra những tính năng được làm đúng theo yêu cầu thay vì nhằm tìm kiếm lỗi mới. Kiểm thử với mô hình trong phát triển phần mềm 1.Mô hình thác nước Hình 1. Mô hình thác nước - Trong mô hình thác nước, năm pha trên phải được thực hiện một cách tuần tự; kết thúc pha trước, rồi mới được thực hiện pha tiếp theo.
7 + Phân tích yêu cầu và tài liệu đặc tả (Requirements and Specifications): là giai đoạn xác định những “đòi hỏi” (“What”) liên quan đến chức năng và phi chức năng mà hệ thống phần mềm cần có. Giai đoạn này cần sự tham gia tích cực của khách hàng và kết thúc bằng một tài liệu được gọi là “Bản đặc tả yêu cầu phần mềm” hay SRS (software requirement specification), trong đó bao gồm tập hợp các yêu cầu đã được duyệt (reviewed) và nghiệm thu (approved) bởi những người có trách nhiệm đối với dự án (từ phía khách hàng). SRS chính là nền tảng cho các hoạt động tiếp theo cho đến cuối dự án. + Phân tích và thiết kế hệ thống (System Analysis and Design): là giai đoạn định ra “làm thế nào” (“How”) để hệ thống phần mềm đáp ứng những “đòi hỏi” (“What”) mà khách hàng yêu cầu trong SRS.
Đây là chính là cầu nối giữa “đòi hỏi” (“What”) và mã (Code) được hiện thực để đáp ứng yêu cầu đó. + Mã hóa (Coding): là giai đoạn hiện thực “làm thế nào” (“How”) được chỉ ra trong giai đoạn “Phân tích hệ thống và thiết kế” mã hóa thành câu lệnh. Một khâu kiểm thử cuối cùng thường được thực hiện là nghiệm thu (acceptance test), với sự tham gia của khách hàng trong vai trò chính để xác định hệ thống phần mềm có đáp ứng yêu cầu của họ hay không. + Bảo trì (Maintenance): đây là giai đoạn cài đặt, cấu hình và hướng dẫn khách hàng.
Giai đoạn này sửa chữa những lỗi của phần mềm (nếu có) và phát triển những thay đổi mới được khách hàng yêu cầu (như sửa đổi, thêm hay bớt chức năng/đặc điểm của hệ thống). 8 - Nhược điểm chính của mô hình thác nước là rất khó khăn trong việc thay đổi các pha đã được thực hiện, phát hiện lỗi trễ dẫn đến chi phí sửa lỗi cao. - Mô hình này chỉ thích hợp khi các yêu cầu đã được tìm hiểu rõ ràng và những thay đổi sẽ được giới hạn một cách rõ ràng trong suốt quá trình thiết kế. Mô hình V-Shape Hình 1.
Mô hình chữ V Bước 1: Phân tích yêu cầu Đóng vai trò xác định yêu cầu bài toán, tính chất của công việc, khi step này được hoàn thành, thì được đưa vào một bước test gọi là Kiểm thử chấp nhận.