• Đơn vị phần mềm
Phần lớn các phương pháp thiết kế phần mềm đều dẫn đến chia phần mềm thành những mô-đun hay chương trình nhỏ có các dữ liệu vào và kết quả riêng. Chúng ta gọi các mô-đun hay chương trình đó là các đơn vị (unit) phần mềm. Trên các đơn vị này chúng ta sẽ tiến hành kiểm thử đơn vị.
Như thế, một đơn vị phần mềm là thành phần nhỏ nhất được kiểm thử. Trong lập trình hướng thủ tục, một đơn vị phần mềm có thể là một hàm hay một thủ tục, một đoạn mã nguồn biên dịch độc lập được. Trong lập trình hướng đối tượng , một phương thức hay một lớp đều có thể xem là một đơn vị. Đơn vị phần mềm được kiểm thử có kích thước khá nhỏ và đơn giản, nên đễ dàng thiết kế dữ liệu thử, thực thi kiểm thử và phân tích kết quả kiểm thử. Nếu lỗi được phát hiện, cũng dễ dàng định vị và sửa lỗi.
•Lập kế hoạch kiểm thửđơn vị
Kế hoạch kiểm thử đơn vị nên phải được chuẩn bị. Nó được chuẩn bị như là một thành phần của kế hoạch kiểm thử tổng thể hoặc một kế hoạch riêng. Kế hoạch kiểm thửđơn vị nên được chuẩn bị cùng với kế hoạch kiểm thử tổng thể và kế hoạch thực hiện dự án. Các hoạt động lập kế hoạch kiểm thửđơn vị được thực hiện trong ba bước chính (theo chuẩn IEEE [7]) dưới đây.
Bước 1: Mô tả các rủi ro và phương pháp kiểm thử đơn vị
Người lập kế hoạch cần xác định các rủi ro của kiểm thử đơn vị , các kĩ thuật được sử dụng để thiết kế dữ liệu cho kiểm thử đơn vị, các kĩ thuật được sử dụng để ghi nhận và phân tích kết quả kiểm thử, cũng như các công cụ và phương tiện hỗ trợ để kiểm thửđơn vị. Cũng trong bước này, cần xác định tiêu chí bắt đầu kiểm thửđơn vị, như đơn vị biên dịch được, công cụ sẵn sàng , các ca kiểm thử đã được thiết kế, và tiêu chí kết thúc kiểm thử đợn vị, chẳng hạn tiêu chí bao phủ (câu lệnh , rẽ nhánh...) , tỉ lệ ca kiểm thử hoàn thành. Cuối cùng , người lập kế hoạch cần định giá nguồn tài nguyên cần thiết cho kiểm thử đơn vị, gồm phần cứng, phần mềm, con người và xây dựng lịch kiểm thử đơn vị, kiểm thử đơn vị thường được thực hiện bởi các lập trình viên.
Bước 2: Xác định các đặc tính của mỗi đơn vị cần được kiểm thử
Bước này cần thông tin từ đặc tả và thiết chi tiết của các đơn vị phần mềm. Người lập kế hoạch xác định rõ các đặc tính nào của mỗi đơn vị sẽ được kiểm thử, chẳng hạn: chức năng, yêu cầu về hiệu năng, cấu trúc điều khiển, luồng dữ liệu...
Bước 3: Hoàn thiện kế hoạch kiểm thử đơn vị
Ở bước này, người lập kế hoạch bổ sung các chi tiết cho kế hoạch đã xây dựng trong hai bước trước. Các chi tiết về phương pháp kiểm thử, nguồn tài nguyên kiểm thử , công cụ kiểm thử và lịch kiểm thử cần được làm rõ
Thiết kế ca kiểm thử
Thiết kế ca kiểm thử ở mức đơn vị có thể dựa trên các kĩ thuật kiểm thử chức năng và kiểm thử cấu trúc. Hai loại kĩ thuật này đều hữu hiệu cho việc kiểm thử các hàm và thủ tục hay các phương thức trong các lớp.
Trong phần lớn các trường hợp, các kĩ thuật kiểm thử chức năng thường được sử dụng trong giai đoạn kiểm thử đơn vị. Các ca kiểm thử được thiết kế dựa trên phân tích tài liệu đặc tả và tài liệu thiết kế các đơn vị. Tuy nhiên , ddooid với các phần mềm đòi hỏi sự chặt chẽcao, các kĩ thuật kiểm thửtĩnh và kiểm thử cấu trúc được sử dụng. Ngoài ra, đối với các dơn vị thực hiện các chức năng đặc biệt , có thể phải thiết kế các ca kiểm thử quá tải , kiểm thử hiệu năng hay kiểm thử bảo mật
• Chuẩn bị mã nguồn hỗ trợ kiểm thửđơn vị
Ngoài việc thiết kế ca kiểm thử, các mã nguồn hỗ trợ cần được phát triển để thực thi mỗi đơn vị. Mã nguồn hỗ trợ gồm:
- Trình điều khiển (driver) : gọi đợn vị cần được kiểm thử
- Nút trám (stub) : thay thế cho các đơn vị được gọi bởi đơn vị cần kiểm thử.
Hình 2.5. Minh họa khái niệm trình điều khiển và nút trám
Trình điều
Đơn vị cần kiểm thử
Đối với lập trình hướng thủ tục , các trình điều khiển và nút trám là các hàm hay thủ tục. Trong khi đối với lập trình hướng đối tượng , phát triển các trình điều khiển và nút trám thường là thiết kếvà cài đặt các lớp đặc biệt nhằm thực hiện công việc kiểm thử
• Thực hiện kiểm thử, ghi nhận và phân tích kết quả
Một khi đơn vị đã sẵn sàng để kiểm thử, ca kiểm thử đã được thiết kế , các công cụ và mã nguồn hỗ trợđã sẵn sàng, kiểm thửđơn vị thực thi và ghi nhận kết quả kiểm thử. Kiểm thử viên cần phân tích kết quả kiểm thửvà đánh giá tiêu chí kết thúc kiểm thử đơn vị. Từ kết quả kiểm thử, cần xác định kiểm thử thành công hay thất bại. Nếu kiểm thử đơn vị thất bại , có thể nhiều nguyên nhân khác nhau cần điều tra :
- Lỗi trong đặc tả ca kiểm thử, chảng hạn dữ liệu vào hay kết quả mong đợi không được đặc tả đúng;
- Lỗi trong quá trình thực thi kiểm thử;
- Lỗi trong môi trường kiểm thử, chẳng hạn các tham số không được cấu hình đúng đắn ;
- Lỗi trong thiết kế đơn vị;
- Lỗi trong mã nguồn của đơn vị;
Một cách lí tưởng, khi kiểm thử đơn vị kết thúc, tất cả các ca kiểm thử thành công và đơn vị sẵn sàng cho kiểm thử tích hợp. Khi kiểm thửđơn vị kết thúc, một báo cáo tổng kết kiểm thửđơn vị cần được chuẩn bị và cung cấp cho nhóm kiểm thử tích hợp và kiểm thử hệ thống. Các ca kiểm thử , thủ tục kiểm thử cũng như mac nguồn hỗ trọ nên được lưu trữ cho việc tái sử dụng trong tương lai.
2.3.2. Kiểm thử tích hợp
Mục tiêu của kiểm thử tích hợp nhằm phát hiện các lỗi tương tác giữa các đơn vị , tích hợp các đơn vị thành các hệ thống con vân hành tốt và cuối cùng hệ thống hoàn chỉnh sãn sàng cho kiểm thử hệ thống.
Kiểm thử đơn vị đã tập trung vào việc phát hiện các lỗi liên quan đến chức năng và cấu trúc của đơn vị. Trong kiểm thử đơn vị, đã có kiểm thử đơn giản sự tương tác giữa đơn vị với trình điều khiển và các nút trám . Tuy nhiên , mỗi đơn vị chưa được kiểm thử sự tích hợp hoàn toàn với tất cảcác đơn vị mà nó gọi và với các đơn vị gọi nó.
Trong quá trình tích hợp , có thể có khả năng không chỉ tích hợp các đơn vị được phát triển trong dự án phần mềm, mà còn tích hợp các đơn vị hoặc thành phần được cung cấp sãn bởi các thư viện hay thậm chí là thành phần được cung cấp bởi hệ điều hành.
được kiểm thử đơn vị thành công. Kiểm thử tích hợp thường được thực hiện như một quy trình lặp. Mỗi bước lặp , một đơn vị (hoặc một sốít đơn vị) được tích hợp vào tập hợp các đơn vịđã được tích hợp và kiểm thửthành công trước đó. Sựtương tác và chức năng của đơn vị mới được tích hợp và tập các đơn vị đã được tích hợp trước đó sẽ được kiểm thử. Việc tích hợp mỗi lần một đơn vị rất hữu ích đối với kiểm thử viên. Trước hết, số tập trung vào các tương tác đó . Nếu có lỗi xuất hiện , thì thường chỉ là lỗi của các tương tác mới đó. Ngoài ra , chúng ta tránh được việc tích hợp cùng một lúc nhiều đơn vị làm nảy sinh sốlượng lỗi lớn. Hơn nữa , chiến lược này cũng giúp cho lập trình viên chỉ tập trung vào việc định vị và sửa lỗi trong tập hợp nhỏcác đơn vị. Trong mục tiếp theo , chúng sẽ trình bày chi tiết hơn về chiến lược này.
• Chiến lược kiểm thử tích hợp
Giai đoạn kiểm thử tích hợp cần phải quan tâm tới thứ tự tích hợp các đơn vị hay mô-đun. Thứ tự yichs hợp các đơn vị hay mô-đun hụ thuộc vào kiến trúc phần mềm, các mô-đun sẵn có cũng như môi trường kiểm thử(các nút trám, trình điều khiển hay các phần cứng/phần mềm liên quan). Trước khi tiến hành kiểm thử tích hợp, cần phải lên kế hoạch thứ tự tích hợp các mô-đun , được gọi là chiến lược kiểm thử tích hợp
Để lập kế hoạch thứ tự tích hợp các mô-đun trong một phần mềm, cây trúc quan hệ giữa các mô-đun thường được sử dụng để biểu diễn quan hệ sử dụng hay gọi nhau một cách có thứ bậc giữa các mô-đun. Hình 2.6 minh họa một ví dụ cây cấu trúc quan hệ giữa các mô-đun
Hình 2.6. Ví dụ cây cấu trúc quan hệ giữa các mô-đun
Hai chiến lược kiểm thử tích hợp cơ bản thường được áp dụng gồm: tích hợp từ trên xuống (top-down) và tích hợp từdưới lên (bottom-up).
Chiến lược tích hợp từ trên xuống thực hiện kiểm thử các mô-đun chính trước , sau đó tích hợp thêm vào các mô-đun được gọi trực tiếp bởi các mô-đun vừa được kiểm thử. Nghĩa là, việc kiểm thử được bắt đầu ở mô-đun trên đỉnh của cây cấu trúc quan hệ giữa các mô-đun. Mô-đun để kiểm thử tiếp theo được lựa chọn theo nguyên
M0 M1 M4 M5 M6 M2 M3 M9 M8 M7
tắc : có ít nhất một trong những mô-đun gọi nó đã được kiểm thử trước đó. Đối với chiến lược này, khi kiểm thử một mô-đun phải xây dựng các nút trám để thay thế cho các mô-đun đó. Sau đó, thay thế dần ở mỗi bước tích hợp tiếp theo mỗi nút trám bởi một mô-đun thực. Chẳng hạn, trong ví dụ trong Hình 2.6, mô-đun M0 được kiểm thử trước và cần phải phát triển các nút trám tháy thế cho các mô-đun M1, M2 và M3, giả sử các nút trám tương ứng là M1 ‘, M2’, và M3’,.
Nếu các ca kiểm thử thành công, thì chúng ta thay thế một nút trám trong số các nút trám M1’, M2’, và M3’, bởi mô-đun thực tương ứng , giả sử đó là mô-đun M1. Khi đó, chúng ta phải xây dựng thêm các nút trám M4’, M5’ và M6’. Hình 2.7
minh họa tập các mô-đun và nút trám được kiểm thử ở bước tích hợp này.
Hình 2.7. Minh họa bước tích hợp từ trên xuống
Tích hợp từ trên xuống đảm bảo rằng các mô-đun ở mức cao trong cây cấu trúc quan hệ giữa các mô-đun được kiểm thử sớm. Nếu các mô-đun này phức tạp, chúng cần phải được thiết kế lại, như thế còn có nhiều thời gian để làm việc đó. Hơn nữa , chiến lược kiểm thử từ trên xuống cho phép xác định sớm các lỗi về kiến trúc và các bộ dữ liệu thử có thể được tái sử dụng cho các bước tiếp theo, tuy nhiên chiến lược này đòi hỏi phải xây dựng nhiều nút trám
Chiến lược tích hợp từ dưới lên bắt đầu bởi kiểm thử các mô-đun ở mức thấp nhất , tức là các mô-đun ở dưới cùng (các nút lá) trong cây cấu trúc quan hệ giữa các mô-đun . Các mô-đun này không gọi các mô-đun khác. Trong cây cấu trúc quan hệ giữa các mô-đun trong Hình 2.6 , các mô-đun này gồm M4, M5, M6, M7, M8 và M9. Để kiểm thử các mô-đun này, cần xây dựng các trình điều khiển . Bước tiếp theo tích hợp các mô-đun ở mức cao hơn trong cây cấu trúc quan hệ giữa các mô đun mà các mô-đun phụ thuộc ở mức thấp hơn của chúng đã được kiểm thử. Chảng hạn, các mô- đun M4, M5 và M6 đã được kiểm thử, khi chúng ta tích hợp mô-đun M1 với các mô- đun M4, M5 và M6 . Mô-đun M1 thay thế trình điều khiển của các mô-đun này.
Đối với chiến lược tích hợp từ dưới lên , sau khi một mô-đun được kiểm thử, trình điều khiển của nó được thay thế bởi mô-đun thực (được tích hợp vào) . Mô-đun được tích hợp tiếp theo này có thể lại cần một trình điều khiển , việc này được tiếp tục
M0
M1
M4’ M5’ M6’
cho đến khi chúng ta đạt đến mô-đun ở mức cao nhất của cây cấu trúc quan hệ các mô-đun.
Chúng ta có thể nhận thấy rằng chiến lược tích hợp từ trên xuống yêu cầu phát triển các nút trám phức tạp, trong khi chiến lược tích hợp từ dưới lên lại yêu cầu phát triển các trình điều khiển . Trong nhiều trường hợp, sự kết hợp hai chiến lược này được sử dụng : chiến lược tích hợp xen kẽ (sandwich) . Đối với chiến lược này, các mô-đun ở mức cao được tích hợp theo chiến lược từ trên xuống, các mô-đun ở mức thấp được tích hợp theo chiến lược từdưới lên.
Cho dù chiến lược nào được sử dụng thì chiến lược kiểm thử tích hợp cũng nên phải thỏa mãn các tiêu chí bao phủ , Chẳng hạn, tất cả các mô-đun trong cây cấu trúc quan hệ các mô-đun phải được thự thi ít nhất một lần (phủ tất cả các cạnh) ; tất cả các chuỗi lời gọi là hàm từ trên xuống phải được thực thi ít nhất một lần (phủ tất cả các lộ trình)
•Thiết kế các ca kiểm thử tích hợp
Các kĩ thuật kiểm thử chức năng hoặc kĩ thuật kiểm thử cấu trúc có thể được sử dụng để thiết kế các ca kiểm thử. Cả hai loại kĩ thuật được khuyến nghị sử dụng . Bởi vì lỗi thường xuất hiện khi tương tác giữa các mô-đun, kiểm thử viên cần tập trung các cặp tham số vào/ra và các quan hệ gọi hàm. Cần phải đảm bảo kiểu tham sốđúng và thứ tự tham số dúng.
Các ca kiểm thửđược thiết kế nhằm đảm bảo rằng tất cả các mô-đun trong cây cấu trúc quan hệ giữa các mô-đun được gọi ít nhất một lần , và đảm bảo rằng tất cả các mô-đun được gọi phải được gọi bởi các mô-đun gọi chúng
Một số các ca kiểm thử chức năng được thiết kế cho kiểm thử đơn vị có thể được tái sử dụng cho kiểm thử tích hợp . Các nguồn để thiết kế ca kiểm thử chức năng gồm tài liệu đặc tả yêu cầu và tài liệu thiết kế.
•Lập kế hoạch kiểm thử tích hợp
Lập kế hoạch kiểm thử tích hợp có thể bắt đầu khi thiết kế kiến trúc của hệ thống hoàn tất. Trong kế hoạch kiểm thử, chiến lược kiểm thử tích hợp cần phải được định nghĩa. Thứ tự kiểm thử các mô-đun phải được định nghĩa . Điều này phụ thuộc vào chiến lược được lựa chọn. Mục tiêu là nhằm tích hợp các mô-đun thành một hệ thống con và đảm bảo hệ thống con hoạt động đúng đắn . Trong kế hoạch kiểm thử , cần xác định rõ nguồn tài nguyên cần thiết và lịch tích hợp.
2.3.3. Kiểm thử hệ thống
Kiểm thử hệ thống có thể bắt đầu ngay sau khi kiểm thử tích hợp kết thúc. Mục tiêu của kiểm thử hệ thống là cần chỉ ra rằng phần mềm thực hiện đúng những gì mà người sử dụng mong đợi. Vì thế , ở giai đoạn này, kiểm thửđược thực hiện dưới góc
nhìn của người sử dụng, chứ không phải dưới góc nhìn của người phát triển như các giai đoạn kiểm thửđơn vị hay kiểm thử tích hợp.
Lập kế hoạch kiểm thử hệ thống nên được thực hiện ở giai đoạn phân tích và đặc tả yêu cầu. Kế hoạch kiểm thử cần phải chứa các thành phần , như phương pháp kiểm thử , chi phí, nguồn tài nguyên, lịch kiểm thử và các ca kiểm thử.
Bởi vì kiểm thử hệ thống được thực hiện dưới góc nhìn của người sử dụng, nên giai đoạn này chỉ sử dụng các kĩ thuật kiểm thử chức năng , tức là các kĩ thuật kiểm thử hộp đen. Các ca kiểm thử được thiết kế dựa trên các tài liệu đặc tả yêu cầu , tài