1. Khái niệm kiểm thử: Định nghĩa kiểm thử và những vấn đề, những điểm lưu ý khi thực hiện kiểm thử

Kiểm thử phần mềm là quá trình khảo sát một hệ thống hay thành phần dưới những điều kiện xác định, quan sát và ghi lại các kết quả, và đánh giá một khía cạnh nào đó của hệ thống hay thành phần đó.

Bản chất của kiểm thử là để tìm ra lỗi của phần mềm.

Những điểm cần lưu ý khi thực hiện kiểm thử phần mềm:

• Chất lượng phần mềm do khâu thiết kế quyết định là chủ yếu, chứ không phải khâu kiểm thử.

• Tính dễ kiểm thử phụ thuộc vào cấu trúc chương trình.

• Nên được thực hiện bởi những đối tượng không tham gia vào quá trình phát triển phần mềm.

• Dữ liệu thử cho kết quả bình thường thì không có ý nghĩa nhiều, cần có những dữ liệu kiểm thử mà phát hiện ra lỗi.

• Khi thiết kế trường hợp thử, không chỉ dữ liệu kiểm thử nhập vào, mà phải thiết kế trước cả dữ liệu kết quả sẽ có.

• Khi phát sinh thêm trường hợp thử thì nên thử lại những trường hợp thử trước đó để tránh ảnh hưởng lan truyền sóng.

• Việc kiểm thử nên được hoạch định trước một thời gian dài.

• Nên tiến hành từ nhỏ đến lớn: bắt đầu từ những module riêng biệt rồi sau đó tích hợp các module lại.

• Nên đưa cho người sử dụng mức trình độ chấp nhận được dùng thử để đưa ra đánh giá khách quan cho phần mềm hiện tại.

• Không hệ thống rơi vào những người có trình độ nghiệp vụ cao và có chủ ý phá hoại.

2. Phương pháp thử: kiểm thử trên bàn (kiểm thử tĩnh) và kiểm thử trên máy (kiểm thử động)

• Kiểm thử trên bàn:

 Duyệt lại các yêu cầu và các đặc tả bằng tay, thông qua việc sử dụng giấy, bút để kiểm tra logic, lần từng chi tiết mà không cần chạy chương trình.

 Thường được sử dụng bởi chuyên viên thiết kế người mà viết mã lệnh một mình.

• Kiểm thử trên máy:

 Chạy trực tiếp chương trình để kiểm tra các trạng thái tác động của chương trình

 Trình tự kiểm thử trên máy:

(1) Thiết kế trường hợp thử theo thử trên bàn

(2) Trường hợp thử phải có cả kết quả kỳ vọng sẽ thu được

(3) Dịch chương trình nguồn và tạo môđun tải để thực hiện

(4) Khi trường hợp thử có xử lý tệp vào-ra, phải làm trước trên bàn việc xác định miền của các tệp

(5) Nhập dữ liệu đã thiết kế cho trường hợp kiểm thử

(6) Điều chỉnh môi trường thực hiện môđun tải (tạo thủ tục đưa các tệp truy cập tệp vào chương trình)

(7) Thực hiện môđun tải và ghi nhận kết quả

(8) Xác nhận kết quả với kết quả kỳ vọng

(9) Lặp lại thao tác (5)-(8)

3. Phương pháp thiết kế trường hợp kiểm thử: Kiểm thử hộp đen (What); Kiểm thử hộp trắng (How); Trình tự thiết kế

a. Kiểm thử hộp đen

• Kiểm thử hướng dữ liệu (hướng chức năng)

• Không quan tâm đến cấu trúc bên trong chương trình mà chỉ chú tâm đến các sai sót về chức năng

• Ưu điểm: khách quan

Nhược điểm: ít thông tin

• Một số phương pháp kiểm thử hộp đen:

 Phân đoạn tương đương: Chia dữ kiệu vào thành các đoạn, mỗi đoạn đại diện cho một số dữ liệu, việc kiểm thử chỉ thực hiện trên đại diện đó

 Phân tích giá trị biên: trường hợp riêng của phân đoạn (ví dụ nếu miền dữ liệu là tháng thì giá trị 0 hay >12 là không hợp lệ)

 Đoán lỗi: dựa vào trực giác hay kinh nghiệm, thường ko tìm ra hết lỗi (ví dụ kiểm tra lỗi chia cho 0)

b. Kiểm thử hộp trắng

• Dựa trên những đặc tả bên trong của chương trình

• Đảm bảo:

 Kiểm tra tất cả các lộ trình độc lập bên trong 1 mô đun ít nhất 1 lần

 Kiểm tra tất cả các nhánh đúng/sai của lựa chọn

 Kiểm tra việc thực hiện của vòng lặp tại các biên và bên trong vòng lặp

 Kiểm tra các cấu trúc dữ liệu để đảm bảo tính hợp thức.

• Nhược điểm: khó thực hiện, tốn kém

4. Phương pháp thử các môđun: Thử dưới lên, Thử trên xuống, Các cách thử khác

a. Kiểm thử từ dưới lên (bottom up)

Các module cấp thấp được kiểm thử trước.

Module mức trên được thay thế bằng module điều khiển (test driver), module này gọi module cần thử nghiệm, truyền dữ liệu và hiển thị kết quả.

Sau đó thay thế lần lượt các driver.

VD: xây dựng test driver để kiểm thử module getDay()

void getDayDriver()

{

date d;

while(1){

cout << "Enter date: ";

cin >> d;

cout << getDay(d) << endl;

}

}

Ưu điểm: tránh phải xây dựng các module tạm thời (stub), thuận tiện cho phát triển các module để dùng lại

Nhược điểm: chậm phát hiện các lỗi kiến trúc

b. Kiểm thử từ trên xuống (top down)

Các module mức trên được kiểm thử trước.

Các module thuộc cấp đc thay bằng các module tạm thời (stub function có cùng tên, cùng giao diện với module thật, trả lại kết quả với một hoặc một vài bộ dữ liệu chuẩn).

VD: kiểm thử module calendar() có gọi đến module getDay() chưa được phát triển:

Module getDay:

String getDay(Date d)

{

return "Monday";

}

Ưu điểm: phát hiện sớm các lỗi thiết kế

Nhược điểm: nhiều module cấp thấp khó mô phỏng

c. Các cách thử khác

Sandwich test: Kết hợp cả hai phương pháp top-down (cho các module phía trên) và bottom-up (cho các module phía dưới)

Kiểm thử hồi qui: Tiến hành lại các phép thử đã thành công mỗi khi tích hợp thêm module hoặc khi cập nhật mã nguồn chương trình.

5. Phương pháp kiểm thử tích hợp: các kỹ thuật cơ bản và nâng cao.

Kiểm thử tích hợp (Integration test) là phương pháp kiểm thử tích hợp các module lại với nhau và kiểm tra sự giao tiếp giữa chúng.

Mục tiêu:

o Phát hiện lỗi giao tiếp xảy ra giữa các Unit.

o Tích hợp các Unit đơn lẻ thành các hệ thống nhỏ (Subsystem) và cuối cùng là nguyên hệ thống hoàn chỉnh (System) chuẩn bị cho kiểm thử ở mức hệ thống (System Test).

6. Bảo trì phần mềm: khái niệm và trình tự nghiệp vụ bảo trì.

Bảo trì phần mềm là là quá trình sửa đổi một bộ phận hoặc toàn bộ sản phẩm phần mềm sau khi đã bàn giao nhằm sửa lỗi, cải thiện tính năng hoặc để phần mềm có thể đáp ứng các thay đổi của môi trường.

Trình tự bảo trì:

7. Quản lý cấu hình (SCM)

a. Định nghĩa:

Cấu hình phần mềm bao gồm các thành phần phần mềm xác định tính chất cơ bản của phần mềm như mã nguồn, tệp dữ liệu, đặc tả yêu cầu, tài liệu thiết kế,... Các thành phần này gọi là các Configuration Items (CI)

Quản lý cấu hình là lĩnh vực của quản trị dự án nhằm định nghĩa, xác định, quản lý, kiểm tra cấu hình trong suốt quá trình phát triển phần mềm.

Vai trò của quản lý cấu hình:

• Hỗ trợ người quản lý giám sát các thay đổi trong quá trình phát triển

• Cung cấp các chức năng và công cụ hỗ trợ người phát triển thực hiện các thay đổi

b. Các bước trong quản lý cấu hình

• Lập kế hoạch cấu hình

 Định nghĩa các thành phần của cấu hình (đặc tả yêu cầu, tài liệu thiết kế, mã nguồn, báo cáo kiểm thử,...)

 Định nghĩa các chính sách quản lý thay đổi và quản lý phiên bản

 Định nghĩa vai trò và trách nhiệm của các thành viên trong các hoạt động SCM

 Định nghĩa CSDL sử dụng để ghi thông tin về cấu hình

 Định nghĩa các công cụ sử dụng để hỗ trợ SCM

 Định danh các CI

• Quản lý phiên bản: một phiên bản là một thực thể mới của một CI sau khi đã qua một hoặc nhiều lần xem xét và thay đổi.

Đặt tên các phiên bản rõ ràng, không nhập nhằng (phương pháp thường đc sử dụng là đánh số)

• Quản lý thay đổi: ghi nhận tất cả các sự thay đổi của phần mềm và bảo đảm rằng chúng được thực hiện với chi phí thấp nhất.

• Xây dựng hệ thống: biên dịch và kết hợp tất cả các thành phần của một cấu hình thành một hệ thống thực thi được.

• Lưu trữ và sao chép dự phòng

8. Những vấn đề trong bảo trì hiện nay tại các công ty phần mềm và các cách tiếp cận để giải quyết.

Nhiều công ty tin học chưa có bộ phận bảo trì riêng biệt, người bảo trì cũng là người phát triển phần mềm. Đặc biệt hoạt động bảo trì được ước tính chiếm tới 70% chi phí sản xuất phần mềm thì lại thường bị xem nhẹ, chi phí dành cho bảo trì là rất thấp và hầu như không dùng công cụ trợ giúp cũng như không có một qui chuẩn rõ ràng trong việc kiểm thử và bảo trì.