Chương 2 : Một số khái niệm cơ bản
2.5 Lý thuyết kiểm thử
2.5.2 Nguyên nhân gây lỗi phần mềm
2.5.2.1 Chúng ta có gây ra các sai lầm khi phát triển phần mềm?
Ta biết rằng bất kỳ ai bao gồm cả lập trình viên và nhân viên kiểm thử, có thể gây ra các sai sót. Các sai sót này sẽ làm sản sinh ra lỗi trong mã chương trình, trong hệ thống hoặc trong một tài liệu nào đó. Nếu lỗi phát sinh từ trong code dẫn đến việc hệ thống có thể có khả năng bị thất bại. Bởi thế các sai sót chúng ta gây ra là một phần để lại kết quả trong các sản phẩm mà ta chịu trách nhiệm.
Các sai sót của chúng ta có thể là nghiêm trọng bởi vì các hệ thống phần mềm và các dự án là phức tạp. Nhiều sản phẩm chuyển tiếp và sản phẩm cuối cùng được dựng lên trong một dự án, con người ta chắc hẳn sẽ gây ra các sai lầm, thiếu sót trong toàn bộ các hoạt động xây dựng. Một số sai sót trong số đó có thể được loại bỏ trong quá trình xây dựng, nhưng người ta khó tìm ra lỗi của họ trong khi xây dựng sản phẩm. Lỗi trong phần mềm, các hệ thống hoặc các tài liệu có thể là nguyên nhân gây ra các hỏng hóc. Tuy vậy, không phải tất cả lỗi đều gây ra các hỏng hóc.
Khả năng của con người là khá phức tạp, khi ta thiếu kinh nghiệm, không nhận được các thông tin đúng, thiếu hiểu biết, hoặc nếu khi không cẩn thận, mệt mỏi, hoặc cảm thấy không hài lòng. Tất cả các nhân tố này ảnh hưởng đến khả năng của chúng ta để đưa ra các quyết định nhạy cảm – não của chúng ta cũng không có thông tin hoặc việc xử lý nó không đủ nhanh.
Hơn nữa, chúng ta lại gặp thêm các lỗi liên quan đến sự phức tạp kỹ thuật, các vấn đề nghiệp vụ, sự phức tạp của các quy trình nghiệp vụ, code hoặc hạ tầng, sự thay đổi kỹ thuật hoặc rất nhiều các tương tác hệ thống.
Không chỉ các lỗi gây nên sự hỏng hóc. Các hỏng hóc có thể cũng có nguyên nhân bởi các điều kiện môi trường: ví dụ như một vụ nổ bức xạ, từ trường mạnh, các lĩnh vực liên quan đến điệu tử, hoặc sự ô nhiễm có thể là nguyên nhân gây các lỗi trong phần cứng hoặc phần vi xử lý. Các lỗi này có thể ngăn cản, hoặc thay đổi sự thực hiện của phần mềm. Các sai sót có thể cũng xuất hiện do sai lầm của người tương tác hệ thống phần mềm, có thể là giá trị đầu vào sai hoặc do kết quả đầu ra bị sai.
Khi ta nghĩ đến những gì có thể làm sai hướng ta phải nghĩ đến lỗi và những hỏng hóc phát sinh từ:
Lỗi trong đặc tả, thiết kế và cài đặt phần mềm hệ thống
Lỗi trong khi sử dụng hệ thống
Các điều kiện môi trường
Hậu quả của các sai sót sớm, thiệt hại do cố ý, lỗi và các hỏng hóc;
2.5.2.2 Khi nào thì xảy ra lỗi?
Hình dưới ta có thể thấy được số các lỗi có thể phát sinh theo 4 dạng khai thác yêu cầu trong một sản phẩm.
Hình 3. Các tình huống phát sinh lỗi trong quá trình phát triển phần mềm
Đặc tả yêu cầu đúng
Thiết kế đáp ứng được yêu cầu
Xây dựng đúng theo thiết kế
Sản phẩm đúng theo mong đợi
Các yêu cầu chức năng và phi chức năng bàn giao đúng
theo mong đợi. Yêu cầu 1 Đặc tả yêu cầu đúng Thiết kế đáp ứng được yêu cầu Các lỗi chương trình cần được sửa Yêu cầu 2 Lỗi trong bước xây dựng Sản phẩm có chứa lỗi Đặc tả yêu cầu đúng Lỗi trong thiết kế Xây dựng đúng thiết kế Sản phẩm có khiếm khuyết thiết kế
Thiết kế lại để sửa lỗi
Lỗi bước đặc tả yêu cầu
Thiết kế đúng theo xây dựng yêu cầu
Chương trình xây dựng đúng theo thiết kế
Sản phẩm bàn giao bị sai.
Lỗi có thể tiềm ẩn trong nhóm phát triển bao gồm cả kiểm thử viên Yêu cầu 3 Yêu cầu 4
Yêu cầu số 1 được thực hiện đúng – chúng ta hiểu yêu cầu khách hàng, thiết kế đúng đáp ứng đầy đủ yêu cầu, xây dựng đúng theo thiết kế, và bởi vậy phát triển các yêu cầu đó theo đúng thuộc tính; chức năng. Sản phẩm làm ra sẽ đáp ứng được những giả định và các thuộc tính phi chức năng, bởi vậy yêu cầu thực hiện được đáp ứng, sản phẩm làm ra là thân thiện, dễ hiểu cho người dùng.
Với yêu cầu số 2 được phát triển bình thường cho tận đến giai đoạn code, khi ta gây ra một số sai sót, và các lỗi xuất hiện. Các sai sót này để lại dấu vết và
được sửa khi tiến hành kiểm thử, bởi thế chúng ta có thể thấy sản phẩm trước khi tiến hành kiểm thử sẽ không đáp ứng đặc tả thiết kế.
Các lỗi nói đến trong yêu cầu số 3 là khó liên hệ hơn; chúng ta xây dựng theo đúng những gì mà chúng ta đã nói, nhưng thật không may mắn người thiết kế gây ra một số sai sót, bởi vậy lỗi đó tiếp tục tồn tại tại khâu trong phát triển. Nếu chúng ta không kiểm tra lại các yêu cầu định nghĩa, ta sẽ không thể tìm ra những lỗi này trong quá trình kiểm thử. Khi ta phát hiện ra lỗi thì chúng sẽ trở nên khó sửa, bởi vì khi đó thiết kế sẽ phải thay đổi.
Các lỗi trong yêu cầu số 4 được đưa ra khi định nghĩa các yêu cầu; sản phẩm được thiết kế và xây dựng đáp ứng các yêu cầu định nghĩa. Nếu khi kiểm tra ta thấy sản phẩm đã đáp ứng yêu cầu và thiết kế hay chưa, quá trình kiểm thử là thành công. Nhưng mặt khác, sản phẩm đó có thể bị loại bởi khách hàng hoặc người dùng cuối. Các lỗi này được liệt kê khi khách hàng thực hiện kiểm thử nghiệm thu hoặc đưa vào sử dụng. Như vậy chi phí phát hiện lỗi ở bước này là rất cao. Thực tế, các lỗi xuất phát từ bước tìm hiểu yêu cầu và thiết kế là không hiếm; qua việc đánh giá hàng ngàn dự án, người ta đã chỉ ra rằng các lỗi trong
các yêu cầu và thiết kế chiếm một nửa trong tổng số các lỗi dự án.
2.5.2.3 Chi phí sửa lỗi là gì?
Tại thời điểm xem xét các ảnh hưởng của việc phát sinh các hỏng hóc từ lỗi, ta cần phải xem xét các ảnh hưởng khi tìm ra các lỗi này. Chi phí cho việc tìm và sửa lỗi được tính đến dựa trên vòng đời của nó. Chẳng hạn, nếu bạn vá được một lỗ hổng trên ống tay của bạn bây giờ khi nó còn nhỏ, điều đó rất dễ làm, nhưng nếu bạn để lại đó, nó sẽ hỏng tệ hơn và cần nhiều mũi vá hơn mới sửa được.
Nếu ta liên hệ lại theo một chuỗi các cái đã đề cập từ trước đến hình dưới đây, ta thấy rằng, nếu một sai sót gây ra và kết quả là lỗi được tìm thấy tại giai đoạn đó thì liên quan đến việc chi phí tìm và sửa lỗi là rẻ. Ta thấy sự tăng chi phí sửa khi thời gian các lỗi để càng lâu mới phát hiện được, bạn sẽ thấy được các bằng chứng hiệu quả kinh tế của việc kiểm thử và các hoạt động đảm bảo chất lượng khác. Đặc tả có thể được sửa hoặc đề cập ngược trở lại. Giống như nếu một sai sót gây ra và kết quả là nó được tìm thấy ngay trong giai đoạn thiết kế, thì thiết kế có thể được sửa, và như thế chi phí để sửa chữa sai lầm là ít hơn nếu nó được phát hiện ở các giai đoạn sau.
Hình 4. Chi phí sửa lỗi qua các giai đoạn phát triển [2]
Chi phí tìm và sửa lỗi tăng theo thời gian
Chi phí
Thời gian
Yêu cầu Thiết kế Xây dựng Kiểm thử Bảo trì
Tuy nhiên một lỗi xuất hiện trong đặc tả yêu cầu mà không được phát hiện cho tới tận khi tiến hành kiểm thử chấp nhận hoặc thậm chí cho tới khi cài đặt hệ thống, thì chi phí sửa nó sẽ đắt hơn rất nhiều. Điều này là bởi vì để sửa được lỗi đó, ta sẽ phải thực hiện lại các công việc đặc tả, thiết kế; và một lỗi trong các yêu cầu có thể bị nhân lên ở nhiều nơi trong thiết kế và trong code; và tất cả các công việc kiểm thử được tiến hành theo từng điểm sẽ cần được lặp lại để phần mềm đạt đến mức ổn định chấp nhận được.
Thường các lỗi được phát hiện ra ở giai đoạn rất muộn, phụ thuộc vào độ nghiêm trọng của chúng, bởi thế chi phí sửa nó là quá cao. Cũng vậy, nếu phần mềm đó được chuyển giao và đáp ứng được đặc tả, đôi khi nó sẽ không được chấp nhận nếu đặc tả là sai. Nhóm dự án có thể đã chuyển giao đúng những gì họ được yêu cầu, nhưng lại không phải những gì người dùng mong muốn. Trong một số trường hợp, những lỗi đó là quá nghiêm trọng, vì thế hệ thống phải được cài đặt lại từ đầu.