Hoạt động kiểm thử luôn là hoạt động quan trọng trong quy trình phát triển phần mềm. Nó góp phần rất lớn trong việc đánh giá chất lượng của một phần mềm và là giai đoạn bắt buộc trong các dự án phát triển phần mềm trên thế giới cũng như ở Việt Nam. Kỹ thuật kiểm thử góp phần không nhỏ vào việc kiểm soát chất lượng của phần mềm.
Theo Glen Myers[8], kiểm thử phần mềm là một quá trình vận hành chương trình để tìm ra lỗi. Một ca kiểm thử tốt là ca kiểm thử có xác xuất cao tìm ra một lỗi chưa được phát hiện. Một ca kiểm thử thắng lợi là ca kiểm thử làm lộ ra ít nhất một lỗi còn chưa được phát hiện. Với cách nhìn này, mục tiêu của chúng ta là thiết kế các ca kiểm thử để có thể phát hiện một cách có hệ thống các loại lỗi khác nhau với chi phí thời gian và chi phí công sức ít nhất có thể.
Với mục đích phát hiện lỗi, kiểm thử phần mềm thường phải trải qua các bước: tạo dữ liệu thử, thực thi phần mềm theo dữ liệu thử và quan sát kết quả nhận được.
Các phép kiểm thử tại các mức khác nhau thì được tiến hành bởi các cá nhân khác nhau và có ý nghĩa khác nhau trong quá trình phát triển. Tiếp theo tôi đưa ra một số mức kiểm thử.
2.4.1. Kiểm thử đơn vị
Kiểm thử đơn vị là phương pháp kiểm tra phần mềm xem liệu các modul hay các chương trình riêng lẻ có phù hợp cho việc sử dụng hay không. Một đơn vị là thành phần nhỏ nhất có thể kiểm thử được của một ứng dụng. Thành phần hay đơn vị nhỏ nhất của phần mềm có thể là phương thức, thủ tục, hàm, lớp ...
Đây là pha kiểm thử sớm nhất được thực hiện phối hợp giữa kiểm thử cấu trúc và kiểm thử chức năng để có thể phát hiện các khiếm khuyết, sai sót trong câu lệnh, thực hiện tính logic và những yêu cầu đã được đặc tả. Thông thường kiểm thử loại này được thực hiện bởi chính người lập trình, họ sẽ thực hiện cho chạy từng đoạn mã trong chương trình mình viết xem có chạy đúng cấu trúc chương trình đã được xây dựng, các chức năng có đúng như đã được đặc tả và thỏa mãn chuẩn chất lượng đề ra không. Các sai sót, khiếm khuyết được phát hiện trong chương trình thì sớm được xem xét và đi đến khắc phục, đồng thời tìm cách tránh phát sinh khiếm khuyết mới. Vì mức kiểm thử này, người kiểm thử tác động trực tiếp vào mã lệnh chính là thực hiện kiểm thử trong của sản phẩm nên thực hiện kiểm thử bằng phương pháp kiểm thử hộp trắng.
Khi kiểm soát được các sai sót hay khiếm khuyết của các đơn vị trong giai đoạn tham gia kiểm thử đơn vị chính là đã kiểm soát được chất lượng trong của phần mềm nhằm đảm bảo chất lượng đã đề ra.
2.4.2. Kiểm thử tích hợp
Kiểm thử tích hợp là thực hiện tích hợp các đơn vị thành phần thành các mô đun chức năng, các hệ con và cuối cùng hệ thống hoàn chỉnh. Thực hiện tích hợp chương trình đến đâu thì thực hiện kiểm thử đến đó. Thông thường hay sử dụng mức kiểm thử này để kiểm thử chức năng như: kiểm tra giao diện, hiệu ứng của một mô đun gây lỗi cho mô đun khác, kiểm tra tính đúng đắn so với đặc tả và kiểm tra tính hiệu quả của phần mềm. Các đơn vị được thêm vào theo một trong hai chiến lược: top down hoặc bottom – up. Ở mức kiểm thử này thì thành viên tham gia kiểm thử thường do nhóm kiểm thử độc lập thực hiện. Tại mức này, kiểm thử viên sẽ tiến hành kiểm thử sự tương tác giữa các mô đun thành phần xem có phù hợp với thiết kế không. Phương pháp sử dụng kiểm thử chính là hộp đen vì người kiểm thử có thể không cần quan tâm đến mã chương trình như thế nào và có thể sử dụng bổ sung phương pháp hộp trắng khi cần kiểm thử lại các mô đun. Khi áp dụng mức kiểm thử tích hợp thì ta đã kiểm soát được chất lượng ngoài của sản phẩm. Kết quả của quá
trình kiểm thử phải được lập tài liệu để lưu lại lỗi và các bước gây lỗi. Tài liệu này là cơ sở để thực hiện sửa chữa lỗi đồng thời là tài liệu giúp các thành viên rút kinh nghiệm trong lập trình để tránh lặp lại một số lỗi.
2.4.3. Kiểm thử chấp nhận
Kiểm thử chấp nhận có sự tham gia của khách hàng/người sử dụng (hoặc ủy quyền cho một nhóm thứ ba thực hiện). Mục đích là thẩm định phần mềm có khiếm khuyết, sai sót so với yêu cầu của người dùng không? Từ đó có đi đến chấp nhận và đi đến bàn giao sản phẩm hay không? Mức kiểm thử này có sử dụng các dữ liệu thực do người dùng cung cấp. Với những sản phẩm sử dụng trên phạm vi rộng thì thực hiện kiểm thử trải qua hai bước: kiểm thử trong sự quản lý của nhà phát triển (alpha testing) và kiểm thử không có sự quản lý của nhà phát triển (beta testing) lỗi được gửi lại cho nhà phát triển sửa chữa. Thông thường một phần mềm khi sử dụng rộng rãi thì mới có thể phát hiện được những lỗ hổng, những khiếm khuyết và những sai sót mà kiểm thử thông thường chưa phát hiện được. Thông qua kiểm thử chấp nhận, người dùng có thể bổ sung thêm các yêu cầu cho phù hợp với công việc của họ. Do vậy mà phần mềm luôn được mở rộng và nâng cấp để đáp ứng nhu cầu khách hàng, có đáp ứng được nhu cầu đó thì phần mềm mới có thời gian sống lâu hơn.
2.4.4. Kiểm thử hồi quy
Kiểm thử hồi quy không như các mức kiểm thử nói trên, nó đơn thuần chỉ là kiểm thử lại phần mềm sau khi có sự sửa chữa, thay đổi xảy ra để đảm bảo rằng phần mềm mới thực hiện tốt các chức năng như phiên bản cũ và sự thay đổi không gây ra lỗi mới trên các chức năng vốn đã làm việc tốt. Kiểm thử hồi quy là mức kiểm thử tốn nhiều thời gian và chi phí nhất nhưng không được phép bỏ qua mức kiểm thử này. Nếu bỏ qua mức kiểm thử này, phần mềm có thể phát sinh các lỗi nguy hiểm không lường trước được.
Tóm lại trong phát triển các dự án phần mềm nói chung, hoạt động đảm bảo chất lượng phần mềm, hoạt động kiểm soát chất lượng và hoạt động cải tiến chất lượng luôn đóng vai trò quyết định cho sự thành công của dự án. Việc thực hiện kiểm soát chất lượng trong suốt vòng đời phát triển còn hỗ trợ phát hiện những khiếm khuyết sớm nhất có thể, nhờ đó giảm được nhiều chi phí sửa đổi, bảo trì. Góp phần nâng cao giá trị, nâng cao chất lượng cho phần mềm khi đưa vào sử dụng.
2.4.5. Danh sách lỗi và chức năng bổ sung
Với đặc điểm của phần mềm: quy mô lớn, thực hiện triển khai và phát triển đồng thời là điểm khó khăn đối với quá trình phát triển phần mềm. Điểm khó khăn được thể hiện ở đây là do thực hiện triển khai đồng thời vẫn thực hiện phát triển nên các
yêu cầu có thể được bổ sung để đáp ứng khách hàng. Vì vậy, để kiểm soát quá trình phát triển của phần mềm thì danh sách các khiếm khuyết, các lỗi được phát hiện trong quá trình đánh giá, kiểm thử và yêu cầu bổ sung được liệt kê dưới dạng danh sách như sau: Ngày phát hiện vấn đề (ghi cụ thể hiện tượng) Mô tả lỗi Loại (câu hỏi/yêu cầu) Tầm quan trọng Ngày ghi nhận Người phát hiện Thời hạn dự định xử lý Người phụ trách Ngày dự định kết thúc Ngày dự định phúc đáp việc xử lý Ngày thực sự hoàn tất Tình trạng
Bảng 2. 1: các hạng mục khi liệt kê lỗi
Ý nghĩa các mục trong bảng danh sách liệt kê.
- Ngày phát hiện vấn đề (ghi cụ thể hiện tượng):
o Khi thực hiện đánh giá, thực hiện kiểm thử mà phát hiện khiếm khuyết hay sai sót thì được ghi lại theo thứ tự các bước thực hiện. Phần này thông thường là do nhà phát triển thực hiện, đôi khi do người sử dụng phát hiện lỗi khi áp dụng dữ liệu thực tế mà người phát triển không lường trước được.
o Phần mềm khi triển khai tới người sử dụng, có bổ sung yêu cầu mới hoặc yêu cầu sửa đổi sao cho sát với nhu cầu sử dụng: có thể bổ sung về giao diện (cho dễ sử dụng, thân thiện với người sử dụng…), hoặc thêm chức năng…
- Mô tả lỗi: chỉ rõ lỗi thể hiện như thế nào
- Loại (câu hỏi, yêu cầu)
o Yêu cầu thêm vào
o Lỗi không đáp ứng yêu cầu
o Lỗi logic…
o Mức trung bình có thể phần mềm vẫn chạy được mà không bị ảnh hưởng nhiều. Như vậy có thể chưa cần thiết phải sửa ngay lập tức.
o Mức cao: ở mức này thì phải thực hiện sửa chữa sớm, tránh gây ảnh hưởng tới các phần khác hoặc phát sinh lỗi mới.
- Ngày ghi nhận: ghi lại thời điểm phát hiện lỗi hoặc thời điểm tiếp nhận yêu
cầu từ phía khách hàng.
- Người phát hiện: ghi tên người phát hiện ra lỗi.
- Người phụ trách: khi nhìn vào miêu tả lỗi, xác định được lỗi đó thuộc về thành viên/đơn vị nào phụ trách phần nội dung gây lỗi. Khi nhìn vào bảng này thì thành viên/đơn vị phụ trách thấy được trách nhiệm của mình và tìn phương hướng sửa chữa khiếm khuyết, sai sót hoặc tìm cách bổ sung yêu cầu vào phần mềm.
- Ngày dự kiến kết thúc: dự kiến ngày hoàn thành các sửa chữa, bổ sung theo
như được xác định.
- Ngày dự định phúc đáp việc xử lý: dự kiến ngày trao đổi với khách hàng để
giải quyết những yêu cầu
- Ngày thực sự hoàn thành: ngày thực sự sửa chữa xong những khiếm khuyết
hay đã hoàn thành việc bổ sung yêu cầu.
- Tình trạng (hiện thời): thể hiện tình trạng của phần mềm tại thời điểm hiện thời (đã chạy tốt hay vẫn đang sửa chữa).
Nhưng để có thể đưa ra được một bảng theo như miêu tả ở trên thì đòi hỏi người quản lý phải giầu kinh nghiệm trong phát triển phần mềm mới có thể đưa ra được các thông tin chi tiết như vậy. Với các thông tin được nêu ra trong bảng danh sách lỗi đó thì các thành viên trong nhóm phát triển biết được mô đun nào đã được kiểm tra, và việc kiểm tra, kiểm thử có đúng đắn không, biết được kế hoạch sửa chữa khiếm khuyết, sai sót, bổ sung yêu câu. Từ đó biết được mô đun chương trình nào có thể thực hiện triển khai được. Vì thế việc kiểm tra, kiểm thử không bị lăp lại giúp cho công việc của các thành viên trong nhóm phát triển sẽ dễ dàng, kịp thời và đáp ứng được việc kiểm soát chất lượng của phần mềm giúp phần mềm sản xuất có chất lượng cao