Bài giảng Kiểm thử phần mềm (Dùng cho sinh viên các lớp đại học Công nghệ thông tin)

Nội dung text: Bài giảng Kiểm thử phần mềm (Dùng cho sinh viên các lớp đại học Công nghệ thông tin)

1. TRƯỜNG ĐẠI HỌC PHẠM VĂN ĐỒNG KHOA CÔNG NGHỆ THÔNG TIN VÕ ĐỨC LÂN BÀI GIẢNG KIỂM THỬ PHẦN MỀM (Dùng cho sinh viên các lớp đại học Công nghệ thông tin) Quảng Ngãi, 07 - 2020
2. TRƯỜNG ĐẠI HỌC PHẠM VĂN ĐỒNG KHOA CÔNG NGHỆ THÔNG TIN VÕ ĐỨC LÂN BÀI GIẢNG KIỂM THỬ PHẦN MỀM (Dùng cho sinh viên các lớp đại học Công nghệ thông tin) Lưu hành nội bộ
3. MỤC LỤC LỜI NÓI ĐẦU 1 CHƯƠNG 1 GIỚI THIỆU VỀ KIỂM THỬ 2 1.1 Khái niệm lỗi 4 1.2 Khái niệm kiểm thử 6 1.3. Các bước kiểm thử 11 1.4. Kiểm chứng và hợp thức hóa 13 1.5. Khái niệm hoạt động kiểm thử 13 1.6. Các nguyên tắc kiểm thử 15 1.7. Các khó khăn của kiểm thử 19 1.7.1 Khó khăn liên quan đến quy trình phát triển phần mềm 19 1.7.2 Khó khăn về mặt con người 19 1.7.3 Khó khăn về mặt kĩ thuật 20 1.8 Kết luận 20 Câu hỏi và bài tập 21 CHƯƠNG 2 KIẾM THỬ TRONG QUY TRÌNH PHÁT TRIỂN PHẦN MỀM 22 2.1. Các kĩ thuật kiểm thử 22 2. 1. 1. Phân nhỏm các kĩ thuật kiểm thử 22 2.1.2 Sự hiệu quả của các kĩ thuật kiểm thử 25 2.1.3. Mục tiêu cùa các nhóm kĩ thuật kiểm thử 26 2.2. Các quy trình phát triển phần mềm 28 2.2.1 Quy trình thác nước 28 2.2.2.Quy trình V 29 2.2.3. Quy trình xoắn 30 2.2.4.Quy trình hợp nhất 30
4. 2.2.5. Nhận xét 31 2.3 Các hoạt động kiểm thử trong quy trình phát triển phần mềm 32 2.3.1. kiểm thử đơn vị 33 2.3.2. Kiểm thử tích hợp 35 2.3.3. Kiểm thử hệ thống 38 2.3.4. Kiểm thử hồi quy 40 2.3.5. Kiểm thử chấp nhận 40 2.4. Kết luân 42 Câu hỏi và bài tập 42 CHƯƠNG 3 KIỂM THỬ CHỨC NĂNG - KIỂM THỬ CẤU TRÚC 43 3.1. Kiểm thử giá trị biên 44 3.2. Kiểm thử giá trị đặc biệt 50 3.3. Kiểm thử lớp tương đương 50 3.4. Kiểm thử dựa trên bảng quyết định 57 3.5. Kiểm thử dựa trên đồ thị luồng điều khiển 65 3.5.1. Khái niệm đồ thì 66 3.5.2. Tiêu chí bao phủ định 70 3.5.3. Tiêu chí bao phủ cung 72 3.5.4. Tiêu chí bao phủ lộ trình 75 3.5.5. Tiêu chí bao phủ lộ trình độc lập 76 3.6. Kiềm thử dựa trên đồ thị luồng dữ liệu 82 3.6.1. Đồ thị luồng dữ liệu 82 3.6.2. Tiêu chí bao phủ định nghĩa 84 3.6.3. Tiêu chí bao phủ sử dụng 86 3.6.4. Tiêu chí bao phủ lộ trình định nghĩa sử dụng 86 3.7. Kiểm thử đột biến 89
5. 3.7.1. Khái niệm kiểm thử đột biến 89 3.7.2. Một số khái niệm cơ bản 90 3.7.3. Quy trình kiểm thử đột biến 93 3.7.4. Hạn chế của kiểm thử đột biến 94 3.7.5. Ứng dụng của kiểm thử đột biến 95 3.8. Kết luận 96 Câu hỏi và bài tập 96 CHƯƠNG 4 THIẾT KẾ CÁC TRƯỜNG HỢP KIỂM THỬ 98 4.1. Lập kế hoạch kiểm thử 98 4.2. Đặc tả thiết kế kiểm thử, ca kiểm thử và thủ tục kiểm thử 100 4.2.1 Đặc tả thiết kế kiểm thử 100 4.2.2 Đặc tả ca kiểm thử 101 4.2.3. Đặc tả thủ tục kiểm thử 102 4.3. Lập báo cáo kiểm thử 103 4.3.1. Nhật kí kiểm thử 103 4.3.2. Báo cáo lỗi 104 4.3.3. Báo cáo kiểm thử 105 4.4. Kết luận 105 Câu hỏi và bài tập 107 CHƯƠNG 5 KIỂM THỬ TỰ ĐỘNG VÀ CÔNG CỤ KIỂM THỬ 108 5.1. Kiểm thử tự động 108 5.2. Đặc điểm cơ bản của kiểm thử tự động 110 5.2.1. Ưu điểm của kiểm thử tự động 111 5.2.2. Vấn để của kiểm thử tự động 111 5.2.3. Kiễm thử thủ công và kiểm thử tự động 113 5.3. Quy trình kiểm thử tự động 114
6. 5.4. Công cụ kiểm thử tự động 114 Câu hỏi và bài tập 119 TÀI LIỆU THAM KHẢO 120
7. LỜI NÓI ĐẦU Chúng ta đã và đang chứng kiến sự tăng trưởng đáng kinh ngạc của ngành công nghiệp phần mềm trong vài thập kỷ qua. Nếu như trước đây phần mềm máy tính chỉ được sử dụng để tính toán khoa học kỹ thuật và xử lý dữ liệu thì ngày nay nó đã được ứng dụng vào mọi mặt của của đời sống hàng ngày của con người, từ các ứng dụng nhỏ để điều khiển các thiết bị dùng trong gia đình như các thiết bị nghe nhìn, điện thoại, máy giặt, lò vi sóng, nồi cơm điện, đến các ứng dụng lớn hơn như trợ giúp điều khiển các phương tiện và hệ thống giao thông, trả tiền cho các hoá đơn, quản lý và thanh toán về tài chính, vân vân. Vì thế con người ngày càng phụ thuộc chặt chẽ vào các sản phẩm phần mềm và do vậy đòi hỏi về chất lượng của các sản phẩm phần mềm ngày càng cao, tức là các phần mềm phải được sản xuất với giá thành hạ, dễ dùng, an toàn và tin cậy được. Kiểm thử có phương pháp là một hoạt động không thể thiếu trong quy trình sản xuất phần mềm để đảm bảo các yếu tố chất lượng nêu trên của các sản phẩm phần mềm. Bài giảng được thiết kế dành cho sinh viên đại học ngành Công nghệ thông tin. Nội dung được xây dựng đúng chương trình chi tiết của học phần môn Kiểm thử phần mềm đã được ban hành. Hy vọng bài giảng sẽ là tài liệu bổ ích dành cho sinh viên ngành Công nghệ thông tin cảu Trường Đại học Phạm Văn Đồng. Tuy nhiên do hạn chế về thời gian nên bà giảng còn nhiều thiếu sót. Mong nhận được nhiều ý kiến đóng góp từ các bạn đọc, đồng nghiệp và Sinh viên. Tác giả Võ Đức Lân Trang 1
8. CHƯƠNG 1 GIỚI THIỆU VỀ KIỂM THỬ Vào những thập niên 1960 hay 1970, rất ít người sử dụng máy tính, thì ngày nay những người làm việc trong văn phòng hầu như không thể làm việc thiếu máy tính. Tất nhiên, ngày nay máy tính đã phát triển với tốc độ cao hơn hàng nghìn lần. Phần mềm được sử dụng sẽ tác động đến công việc của rất nhiều người phần mềm giúp cho con người thực hiện công việc hiệu qủa hơn. Như thế, việc phát triển phần mềm chất lượng càng trở nên quan trọng hơn. Quy trình phát triến phần mềm bao gồm nhiều giai đoạn và nhiều hoạt động nhằm tạo ra sản phẩm phần mềm. Trong đó, kiểm thử là một trong những hoạt động đóng vai trò quan trọng nhằm phát hiện lỗi của phần mềm. Kiếm thử phần mềm ngày càng trở nên khó khăn hơn. bởi vi các ngôn ngừ lập trình, các hệ điêu hành, các phương pháp phát triển phần mềm cũng như các thiết bị phần cứng ngày càng phong phú và đa dạng. Một cách lí tưởng, chúng ta muốn kiểm thử tất cả các trường hợp thực thi có thế của một chương trình. Tuy nhiên, điều này là không thể thực hiện dược. Bởi vì, thậm chí đối với một chương trình rất đơn giản thi nó cũng có số lượng dữ liệu vào rất lớn (hàng ngàn, hàng triệu ). Mặc dù theo các kết quả thống kê, chi phí kiếm thử rất lớn, chiếm khoảng hơn 50% tổng chi phí cho một dự án phát triền phần mềm, tuy nhiên lỗi phần mềm vẫn luôn tồn tại và gây ra những thiệt hại rất lớn. Chúng ta sẽ xem xét một vài lỗi phần mềm nghiêm trọng dưới đây. Năm 1994, Công ty Disney tung ra thị trường phần mềm trò chơi Vua Sư tử (Lion King) dành cho trẻ con. Lúc bấy giờ, có rất nhiều công ti chuyên sản xuất về phần mềm trò chơi, còn đối với Disney đây là lần đầu tiên đặt chân vào thị trường này. Vì thế, chiến dịch quảng cáo phần mềm trò chơi này rất rầm rộ. Phần mềm đã được bán rất chạy. là món quà quý giá cho trẻ con nhân dịp giáng sinh. Tuy nhiên, điều không ngờ đã xảy ra. Ngày 26 tháng 12, một ngày sau lề giáng sinh, điện thoại nhóm hỗ trợ khách hàng của Disney đã đố chuông liên tục. Cha mẹ của những đứa trẻ đã phàn nàn phần mềm trò chơi không thể hoạt động được. Sau đó, rất nhiều bài báo cũng như tin tức truyền hình đưa tin về vấn đề này. Cuối cùng, Disney phát hiện ra rằng phần mềm chỉ hoại động được trên một số máy tính mà đội ngũ lập trình đã sử dụng và không hoạt động được trên rất nhiều các máy tính mà đa số khách hàng đang sử dụng. Trang 2
9. Ngày 21 tháng 3 năm 1986, ở bệnh viện ung thư Tyler tại Texas, bệnh nhân Voyne Ray Cox được thực hiện chiếu tia bức xạ sau một ca phẫu thuật. Khi kĩ thuật viên thực hiện khởi động máy gia tốc hạt, là máy được điều khiển hoàn toàn bằng một phần mềm máy tính, bệnh nhân cảm giác khác với những lần trước, có một sự phóng ra điện rất mạnh làm anh ta đau đớn. Bệnh nhân đề nghị bác sĩ kiểm tra xem việc chiếu tia bức xạ có bình thường không. Bác sĩ xem màn hình máy tính và thấy ghi nhận rằng việc chiếu tia bức xạ chưa được thực hiện và một thông điệp lỗi được hiển thị. Sau đó một vài ngày bệnh nhân có các triệu chứng biếu hiện như bị chiếu các tia bức xạ cường độ quá cao, bệnh nhân đã chết sau tai nạn đó vài tháng. Một tai nạn thứ hai đã xảy ra sau đó một thời gian trên một bệnh nhân khác khi được chiếu tia bức xạ với cùng một kết quả thông điệp lỗi. Bệnh nhân này cũng đã chết sau đó một tháng. Sau đó, người ta đã thực hiện kiếm tra phần mềm điều khiển máy gia tốc. Kết quả được ghi nhận là, khi thay đổi một vài tham số của phần mềm thì nhận được cùng một thông điệp báo lỗi, và khi đó máy sẽ phát ra tia bức xạ có cường độ mạnh gấp 100 lần tia bức xạ bình thường. Một thời gian sau, nhà sản xuất chiếc máy đã có báo cáo rằng phần mềm được xây dựng bởi các lập trình viên của họ, sinh ra lỗi khi có sự thay đối các tham số. Sau các tai nạn này, trong hồ sơ lưu trữ bệnh án có rất nhiều trường hợp chiếu tia bức xạ có vấn đề và không thể giải thích được đã được phơi bày. Trong cuộc chiến vùng Vịnh năm 1991, hệ thống phòng chống tên lửa Patriot của Mỹ đã được sử dụng để chống lại tên lửa Scud của 1-rẳc. Mặc dù có nhiều thành công của hệ thống, tuy nhiên cũng có không ít thất bại, kể cả tai nạn đã giết chết 28 lính Mỹ ở Ả-rập Xê-Út. Sau khi kiểm tra lại, người ta phát hiện ra rằng có một lỗi phần mềm trong hệ thống. Đó là một lỗi nhỏ về thời gian : khi thời gian tích luỹ của hệ thống vượt quá 14 giờ thì hệ thống dò tìm dấu vết không còn hoạt động chính xác. Trong trường hợp tai nạn ờ Ả-rập Xê-út, hệ thống đã hoạt động hơn 100 giờ. Trên đây chỉ là một số ít trường hợp nghiêm trọng do các lỗi phần mềm gây ra. Chắc hẳn, mỗi một chúng ta đều đã là “nạn nhân” của một phần mềm hoạt động tốt ở một thời điểm nào đó, nhưng hoàn toàn không hoạt động ở một thời điểm khác. Nếu đó chỉ là phần mềm trò chơi hay phần mềm văn phòng thì vấn dề sẽ được giải quyết rất đơn giản bằng cách tắt máy tính và sau đó khởi động lại. Tuy nhiên, nếu những lỗi phần mềm xuất hiện trong những tình huống có thể gây thiệt hại lớn về kinh tế hay tính mạng con người (chăng hạn, các trường hợp vừa nêu ở trên), thì hậu quả của nó thật khủng khiếp. Như thế, kiểm thử phần mềm không còn chỉ là công việc các chuyên gia khoa học máy tính, bởi vì phần mềm ngày càng được sử dụng rất rộng rãi trong dời sổng hằng ngày. Kiểm thử phần mềm trở thành một lĩnh vực khoa học mới mẻ và đóng vai trò rất quan trọng trong khoa học máy tính. Trang 3
10. 1.1 Khái niệm lỗi Trước khi đề cập đến kiếm thử phần mềm, trước hết chúng ta sẽ tìm hiếu một số khái niệm liên quan đến lỗi. Trong các ví dụ ở trên, chúng ta đã thấy các phần mềm hoạt động không như mong muốn. Như thế, thông thường chúng ta sẽ nội ràng phần mêm có lỗi. Tuy nhiên, cũng có thế dùng nhiều thuật ngữ khác để mô tả như : thất bại, sai sót, có vấn đề, bất thường, không hợp lí, không tương thích Cần phải định nghĩa rõ ràng hơn khái niệm lỗi phần mềm. Định nghĩa lỗi phần mềm dưới đây dựa trên khái niệm đặc tả : một đặc tả (specification) là một sự thống nhất giữa những người phát triển phần mềm hoặc giữa người phát triển phần mềm và người sử dụng phần mềm. Lỗi phần mềm xuất hiện khi một hay nhiều điều kiện sau là đúng [2](,): 1. Phần mềm không thực hiện đúng những gì mà đặc tả định nghĩa. 2. Phần mềm thực hiện những gì mà đặc tả khuyến cáo không nên thực hiện. 3. Phần mềm thực hiện những gì mà đặc tả không đề cập đến 4. Phần mềm không thực hiện những gì mà đặc tả không đề cập đến nhưng lẽ ra nên thực hiện. 5. Phần mềm là khó hiểu hay khó sử dụng Ví dụ về kiếm thử chương trình tính toán trên phân số sau sẽ minh hoạ khái niệm lỗi trên. Chương trình cho phép thực hiện các phép toán trên phân số: rút gọn, cộng, trừ, nhân và chia. Đặc tá định nghĩa chương trinh phải thực hiện đúng các phép toán: rút gọn một phân số, cộng, trừ. nhân và chia hai phân số. Nếu thực hiện phép toán cộng hai phân số mà chương trình không hiển thị gì cả hoặc hiển thị kết qủa sai, dó là lỗi ứng với điều kiện 1. Đặc tả định nghĩa chương trình không nên chạy ở chế độ thường trú như một tiến trình. Tuy nhiên, nếu khi kích hoạt chương trình lại luôn được thường trú, làm tốn kém bộ nhớ. Đó là lỗi ứng với điều kiện 2. Khi kiểm thừ chúng ta nhận thấy, ngoài các phép toán rút gọn một phân số. cộng. trừ. nhân và chia hai phân số, còn có các phép toán cộng, trừ, nhân và chia của n (n > 2) phân số. vấn đề này không được đề cập trong đặc tả, đó là lỗi ứng với điều kiện 3. Sau khi thực hiện các phép toán nhân hai phân số 3/10 * 100/9, kết quả là Trang 4
11. 300/90. Tuy nhiên, kết quả chúng la mong đợi là 10/3. Mặc dù vấn đề này không được định nghĩa chính xác trong đặc tả, nhưng đó là vấn đề mà chương trình nên thực hiện. Lỗi này tương ứng với điều kiện 4. Lỗi ứng với điều kiện 5 khi người sử dụng chạy thử chương trình và nhận thấy chương trình không tốt, cho dù đó là lí do gì. Chẳng hạn, người sừ dụng cho rằng cách hiển thị phân số với màu sắc khó nhìn hay các nút bấm là quá nhỏ. khó sử dụng. Tất nhiên, mỗi người sử dụng có cách nhìn khác nhau về chương trình, vì thế rất khó dể đáp ứng tất cả các yêu cầu khác nhau của người sử dụng. Tuy nhiên, khi kiếm thử phải luôn nghĩ đến các lỗi ứng với điều kiện 5 để có những chọn lựa hợp lí nhất. Ngoài ra, trong lĩnh vực nghiên cứu về tính khả tin cậy (dependability) [1] của hệ thống, ba khái niệm - sai sót, lỗi và thất bại - được sử dụng nhằm thể hiện rõ mức độ ảnh hưởng của lỗi đối với phần mềm. Một sai sót (fault) là một sự nhầm lẫn hay một sự hiểu sai trong quá trình phát triển phần mềm của người phát triển. Người phát triển ở đây bao gồm: người phân tích, người thiết kế, lập trình viên, kiểm thử viên hay nói cách ngắn gọn là tất cả những người tham gia vào quá trình phát triển phần mềm. Như thế, sai sót xuất hiện trong quá trình phát triển phần mềm. Ví dụ, người thiết kế hiểu nhầm một khái niệm hay vấn đề nhỏ nào đó hoặc lập trình viên gõ nhầm một câu lệnh, một toán tử Một lỗi (error) xuất hiện trong phần mềm như là kết quả của một sai sót. Lồi làm cho phần mềm có những hoạt động không đúng so với yêu cầu đặt ra. Như thế, chúng ta dễ nhận thấy rằng sai sót là nguyên nhân gây nên lỗi hay khi sai sót được kích hoạt thì tạo nên lỗi. Một cách cụ thể, sai sót xuất hiện trong quá trinh phân tích, thiết kế, lập trình thì lồi xuất hiện khi thực thi chương trinh. Ví dụ, khi thực thi một chương trình thì xuất hiện câu thông báo lỗi. Một thất bại (failure) là kết quá của một lỗi xuất hiện làm cho chương trình không hoạt động được hay hoạt động nhưng cho kết quả không như mong đợi. Như thế, lỗi là nguyên nhân gây nên sự thất bại. Một khi thất bại xáy ra thì chương trình không thề tiếp tục hoạt động được nữa. Quan hệ giữa các khái niệm trên được minh hoạ trong Hình 1.1 Xảy ra Xảy ra Sai sót Lỗi Thất bại Hình 1.1 Quan hệ giữa sai sót, lỗi và thất bại Các khái niệm này được phân biệt chủ yếu là trong lĩnh vực nghiên cứu về độ tin Trang 5
12. cậy của phần mềm. Lĩnh vực này tập trung nghiên cứu trên các phần mềm quan trọng (critical software), nghĩa là nếu có lỗi xảy ra thì hậu quá rất lớn. thậm chí là nguy hiểm. Chẳng hạn, các phần mềm điều khiển tàu điện ngầm, điều khiển tên lửa Mục đích của chúng ta quan tâm đặc biệt tới các lỗi phạm phải nhằm hạn chế tối thiểu các thất bại có thể xuất hiện. Nhằm tránh sự chặt chẽ nghiêm ngặt có thể làm ảnh hưởng tính sư phạm của tài liệu, chúng tôi sử dụng một cách không phân biệt các khái niệm lỗi và sai sót trong tài liệu này. Tập hợp các lỗi có thế ảnh hưởng đến phần mềm là không xác định và như thế khó có thế có sự phân loại chúng một cách chính xác. Tuy nhiên, chúng ta có thể phân loại trong tài liệu này sáu lớp lỗi cơ bản trong quá trình lập trình mà người phát triển có thể phạm phải : -Lỗi tính toán : lỗi ở các biểu thức tính toán. Ví dụ, tồn tại câu lệnh X - X + 10 thay vì X = X + 100. -Lỗi lô-gic : biểu diễn sai một điều kiện. Ví dụ, biểu thức điều kiện a > b được sử dụng thay vì viết a < b. -Lỗi vào/ra : gồm tất cả các lỗi liên quan xử lí dữ liệu vào/ra, như định dạng sai, chuyển đổi sai kiểu các dữ liệu vào/ra. -Lỗi xứ lí dữ liệu : truy cập hay thao tác sai trên dữ liệu, như sử dụng sai một con trỏ, sử dụng vượt quá chì số mảng -Lồi giao tiếp : lỗi về giao tiếp giữa các thành phần bên trong của phần mềm, chẳng hạn như truyền tham số không đúng, gọi hàm không đúng -Lỗi định nghĩa dữ liệu : định nghĩa sai dữ liệu. Ví dụ, một dữ liệu được định nghĩa kiểu số thực mà đúng ra nó nên được định nghĩa kiếu số nguyên. 1.2 Khái niệm kiểm thử Trong thực tế, khái niệm kiểm thử lại thường được hiểu một cách không chính xác bởi các phát biểu như : “kiểm thử là quy trình nhằm chỉ ra rằng không tồn tại lỗi trong phần mềm” hay “kiểm thử nhằm mục đích chỉ ra rằng phần mềm thực hiện đúng các chức năng mong đợi một cách đúng đắn”. Nếu “kiểm thừ là quy trình nhằm chỉ ra ràng không tồn tại lỗi trong phần mềm” thì mục đích này không thể thực hiện được với mọi phần mềm. Bởi vì trên thực tế, không thể khẳng định được một phần mềm là không chứa lỗi, cho dù đó chỉ là chương trình đơn giản. Nếu “kiểm thử nhằm mục đích chỉ ra rằng phần mềm thực hiện đúng các chức Trang 6
13. năng mong đợi một cách đúng đắn”, thì vẫn có thể phần mềm còn chứa lỗi. Chẳng hạn, lỗi vẫn có thể tồn tại nếu phần mềm thực hiện các chức năng không được đặc tả. Kiểm thử được định nghĩa bởi nhiều cách khác nhau, như : -Kiểm thử là quy trình vận hành hệ thống hoặc thành phần dưới những điều kiện xác định, quan sát hoặc ghi nhận kết quả và đưa ra đánh giá về hệ thống hoặc thành phần đó [6]. -Kiểm thử dược mô tả là các thủ tục được thực hiện nhằm đánh giá một vài mặt của phần mềm [4]. -Kiểm thử được mô tả như là quy trình được sử dụng để phát hiện lỗi phần mềm, để xác định rằng phần mềm đạt được chất lượng đặt ra [4], -Kiểm thử là quy trình thực thi chương trình với mục đích tìm thấy lỗi [2]. Tuy có các định nghĩa khác nhau về kiểm thử, nhưng chúng cùng bao trùm hai nội dung cơ bản là phát hiện lỗi và đánh giá chất lượng của phần mềm. Trong các định nghĩa trên, thì định nghĩa của Myers “kiểm thử là quy trình thực thi chương trình với mục đích tìm thấy lỗi” [1] là đơn giản và có tính thực tế cao hơn. Tuy nhiên, trong một số trường hợp, định nghĩa này lại không thích hợp, bởi vì các kỉ thuật kiểm thử tĩnh có khả năng phát hiện lỗi cao, nhưng không yêu cầu phải thực thi chương trình, như kĩ thuật thẩm định, kĩ thuật thanh tra, phân tích tĩnh Quan niệm thông thường cùa lập trình viên là : kiểm thử phát hiện lỗi là không thành công và ngược lại là thành công. Tuy nhiên, theo định nghĩa của Myers, kiểm thử mà không phát hiện được lỗi được coi là không thành công, ngược lại nếu kiếm thử phát hiện được lỗi được coi là thành công. 'Thực vậy, mục đích của kiểm thử là phát hiện lỗi, nếu kiểm thử mà không phát hiện lỗi thi mục đích chưa đạt được. Bởi vi, trong thực tế phần mềm hầu như không bao giờ không chứa lỗi. Như thế. quan niệm phát hiện được lỗi là thành công hay thất bại tùy thuộc vào quan điểm của lập trình viên hay kiểm thử viên. Chúng ta xem xét trường hợp tương tự: một người đến bệnh viện vì cảm giác mình bị mắc bệnh. Sau khi bác sĩ khám và thực hiện các xét nghiệm mà không phát hiện được bệnh, thì có thể nói là việc khám và xét nghiệm thất bại, bời vì bệnh không được phát hiện trong khi chi phí phải trả mà người bệnh vẫn còn ốm. Trong trường hợp này, người bệnh thậm chí có thể nghi ngờ khá năng của bác sĩ. Ngược lại, nếu bệnh được phát hiện, thì việc khám và xét nghiệm được coi là thành công, sau đó bác sĩ sẽ tiến hành phương án chữa trị. Một cách tương tự, trong kiếm thử chúng ta cũng có thể xem phần mềm cần kiểm thử, khi bắt đầu kiểm thử, như là một người bệnh. Trang 7
14. Ngoài ra, cũng cần phải phân biệt sự khác nhau giữa hai hoạt động kiểm thử và gỡ rối (debugging). Kiểm thử nhằm mục đích phát hiện lỗi, trong khi gỡ rối được thực hiện một khi kiểm thử đã phát hiện được lỗi. Gỡ rối gồm hai bước : -Xác định bàn chất lỗi và định vị lỗi trong chương trình ; -Tiến hành sửa lỗi. Tóm lại, kiểm thử nhằm thực hiện mục đích phát hiện ra lỗi trong phần mềm (với giả thiết sự tồn tại lỗi trong phần mềm). Kiểm thử phát hiện được lỗi sẽ góp phần nâng cao chất lượng của phần mềm. Các khái niệm cơ bản: Trong mục này, chúng tôi sẽ trình bày một số các khái niệm cơ bản liên quan đến kiểm thử. Như đã định nghĩa ở trên, hoạt động kiểm thử nhằm mục đích phát hiện lỗi. Hoạt động kiểm thử' có thế hoặc tìm các lỗi bằng các phương pháp phân tích tĩnh (không thực thi phần mềm) hoặc phát hiện lỗi bằng cách xác định dữ liệu vào cần cung cấp cho phần mềm khi thực thi. Các dữ liệu vào này được gọi là các dữ liệu thử (DT - test data). Chúng ta thường kí hiệu một DT bởi tập hợp. Chẳng hạn, chúng ta kiểm thử một chương trình tính tổng nhận các biến a, b và c kiểu số nguyên như là dữ liệu vào, khi đó chúng ta kí hiệu : DT1 - {a = 3, h = 10, c - 1} có nghĩa là chúng ta khởi gán các giá trị 3, 10 và 1 cho các biến tương ứng a,b và c để tạo ra dữ liệu thử đầu tiên. Tập hợp các DT được tạo ra để kiểm thử được gọi tập dữ liệu thử (set of test data). Để có thể đưa tập dữ liệu vào một chương trình, một vài hoạt động hay thao tác cần phải được thực hiện. Chẳng hạn, để kiểm thử một lựa chọn trên giao diện có đưa đến việc thực thi một chức năng yêu cầu hay không, cần phải thực thi phần mềm, khởi gán một vài tệp tin và thực hiện lựa chọn các mục cần thiết để kích hoạt lựa chọn cần kiểm thử. Dãy các thao tác này được gọi là kịch bản kiểm thử (test scenario) Khi một kịch bản kiểm thử được thực hiện, phần mềm sẽ cho một kết quả xác định. Chúng ta giả sử rằng, sự thiếu vắng kết quả bởi một yếu tố không xác định nào đó (như sự dừng bất thường của chương trình khi thực thi, vòng lặp vĩnh cửu ) cũng đều được coi là một kết quà. Kết qủa này sẽ được so sánh với kết qủa mong đợi (được đặc tả) để kết luận việc kiểm thử. Việc đánh giá kết qủa kiểm thử không nên được xem nhẹ. Trong thực tế, đôi khi việc đánh giá kết quả kiểm thử còn khó khăn hơn cả việc tạo ra dữ liệu thử. Việc đánh giá kết quả kiểm thử có thể được thực hiện môt cách tự động bởi công cụ hoặc một cách thủ công bởi con người, chúng ta gọi đó là một Trang 8
15. phán xét kiểm thử (test oracle). Chẳng hạn, để xác định xem chương trình tính nghiệm một phương trình bậc nhất có cho đúng nghiệm hay không, chúng ta thay thế nghiệm (kết quả) vào phương trình đế kiểm tra. Như thế, phán xét kiểm thử là một tài liệu hay chương trình cho phép kiểm thử viên xác định một phép kiểm thử là thành công hay thất bại. Nếu phán xét kiểm thử là một tài liệu, chẳng hạn đặc tả hay thiết kế. thì việc xác định kết quả của kiểm thử phải thực hiện một cách thủ công, nhờ vào sự quan sát của con người. Trong thực tế thì phán xét kiểm thử thường chỉ là một tài liệu. Trường hợp phán xét kiếm thử là một chương trình, thì kết quả kiểm thử có thể được thực hiện một cách tự động hoàn toàn, tức là không cần sự can thiệp của con người. Tuy nhiên, trong thực tế để xây dựng một chương trình phán xét kiểm thử tin cậy là không đơn giản, thậm chí có thể còn phức tạp hơn việc xây dựng chính chương trình cần kiểm thử. Xây dựng và sử dụng phán xét kiểm thử là một trong những yếu tố khó khăn trong quy trình kiểm thử. Thật vậy, một tài liệu phán xét kiểm thử thì xây dựng dễ dàng bằng cách dựa vào đặc tả và thiết kế, tuy nhiên hiệu quả lại thấp và cản trở sự tự động hoá quy trình kiểm thử vì nó đòi hỏi phải có sự can thiệp thủ công của con người. Trong khi chương trình phán xét kiểm thử thì có độ chính xác cao hơn, cho phép tự động hoá quy trình kiểm thử, tuy nhiên xây dựng chương trình phán xét kiểm thử là rất khó khăn và chi phí cao. Trong tài liệu này chúng ta sẽ không đề cập chi tiết đến việc xây dựng và sử dụng phán xét kiểm thử. Trong kiểm thử. chúng ta không thể không đề cập đến vai trò con người, trước đây công việc kiểm thử thường được thực hiện bởi chính các lập trình viên. Tuy nhiên, gần đây với sự phát triển của công nghiệp phần mềm, kiểm thử là một lĩnh vực được chuyên môn hoá. Khi đó. người thực hiện kiểm thử được gọi là kiểm thử viên (tester) hay kĩ sư kiểm thử (test engineer). Việc kiếm thử phải được thực hiện bởi các kiểm thử viên độc lập là rất quan trọng (tuy nhiên, điều này không phải luôn được tuân thủ vì các lí do kinh tế). Lập trình viên là người làm ra sản phẩm, nếu chính họ cũng là kiểm thử viên thì chắc chắn việc phát hiện lỗi không đơn giản bởi các yếu tố tâm lí : -Lập trình viên tạo ra sản phẩm với số lỗi ít nhất có thể, trong khi kiểm thử viên cố gắng phát hiện số lỗi nhiều nhất có thể ; -Lập trình viên không bao giờ muốn phá huỷ sản phấm đã làm ra, mà luôn mong muốn kết thúc công việc này để thực hiện các công việc khác ; -Lập trình viên thường kiểm thử chương trình bằng cách cung cấp các dữ liệu thử Trang 9
16. mà cho kết quả như mong đợi. Chẳng hạn, nếu một người viết một bài văn, sau đó chính người đó đọc và tìm lỗi thì sẽ không tốt bàng một người khác làm việc đó. Thông thường, để thực hiện kiểm thử một phần mềm, kiểm thử viên lựa chọn một tập dữ liệu thử, sau đó cho thực thi phần mềm dưới những điều kiện nào đó (nghĩa là thực hiện các bước của kịch bản kiểm thử) và cuối cùng quan sát, so sánh kết quả thu được so với kết quả mong đợi (kết quả được đặc tả). Các thông tin gồm dữ liệu thử, điều kiện thực thi/các bước thực thi và kết quả mong đợi được gọi là một ca kiểm thử (test case). Hình 1.2 sẽ minh hoạ một số các khái niệm vừa trình bày ở trên. Kết quả mong đợi =6 Đặc tả Đúng Chương trình được kiểm thử Tập dữ liệu thử DT Chương trình tính tổng DT1={a=1,b=2,c a+b+c =3} Kết quả DT2={ Kết quả =6 =6 Kiểm thử viên Phán xét kiểm thử Kiểm tra Đúng Kết quả= a+b+c? Hình 1.2 Minh họa một số khái niệm về kiểm thử Để một quy trình kiểm thử - bao gồm chọn dữ liệu thử, kịch bản kiểm thử và đánh giá kết quả - mang lại độ tin cậy cao, cần phải xây dựng các dữ liệu thử làm sao đại diện cho được tất cả các dữ liệu vào có thể của phần mềm. Hiển nhiên rằng khi kiểm thử phần mềm, nếu chúng ta có thể tạo ra tất cả các dữ liệu vào có thể - được gọi là kiểm thử-Vét—can (exhaustive/complete testing) - thì khi đó bộ dữ liệu thử đại diện một cách hoàn toàn các dữ liệu vào, độ tin cậy của chúng ta đối với phần mềm đã được kiểm thử sẽ là tuyệt đối. Tuy nhiên, cần phải hiểu ràng tạo ra tất cả các dữ liệu vào có thể, thậm chí đối với một chương trình rất đơn giản, là một việc không khả thi. Chúng ta có thế tưởng tượng độ lớn của tập dữ liệu để kiểm thử vét cạn chương trình tính tổng của ba số nguyên. Vì thế, tập dữ liệu thử thông thường chi là một tập con của tất cả các dữ liệu vào. Tính đại diện của tập dữ liệu thử đối với tất cả các dữ liệu vào có thế, có nghĩa là tập dữ liệu phải được chọn lựa sao cho phát hiện được số lỗi nhiều nhất có thể. Trong trường hợp lí tưởng, bộ dữ liệu thử nhỏ hơn rất nhiều so với Trang 10
17. tập tất cả các dữ liệu vào có thế nhưng phát hiện tất cả các lỗi mà tập tất cả các dữ liệu vào có thế cũng phát hiện được. Vấn đề đặt ra là làm thế nào để tạo ra tập dử liệu thử có tính đại diện cao ? Thực tế, thì tính đại diện của tập dữ liệu thử sẽ dẫn đến vấn đề tính đại diện của các lỗi trong phần mềm. Lưu ý rằng, khi nói đến kiểm thử, chúng ta chỉ quan tâm đến các lỗi mắc phải bởi người phát triển (phân tích viên, thiết kế viên, lập trình viên), như lỗi nhầm lẫn, sai sót chứ không phái là các lỗi cấu thả hởi những người phát triển kém cõi. Từ đó, chúng ta sẽ thấy rằng các kĩ thuật kiểm thử, mà chúng ta sẽ tìm hiểu, tạo nên những nhóm theo tiêu chuẩn lựa chọn dữ liệu thử và theo đối tượng được kiểm thử (đặc tà, mã nguồn hay mã thực thi) nhằm đảm bảo một số các loại lỗi được phát hiện. Chúng ta sẽ xem xét qua các tính chất cơ bản của các nhóm kĩ thuật kiểm thử. Các kĩ thuật kiểm thử tạo ra các tập dữ liệu thử chi dựa trên kết quả của việc thực thi phần mềm, mà không quan tâm đến cấu trúc bên trong của phần mềm được gọi các kĩ thuật kiểm thử chức năng (functional testing). Một thuật ngữ khác được sử dụng một cách tương đương là kĩ thuật kiểm thử hộp đen (black-box testing), bởi vì chúng ta xem phần mềm như một hộp đen mà không thể nhìn thấy vào bên trong nó được (nghĩa là mã nguồn). Ngược lại, các kĩ thuật kiểm thử tạo ra các tập dữ liệu thử bằng cách phân tích cấu trúc phần mềm được gọi là các kĩ thuật kiểm thử cấu trúc (structural testing), hay còn được gọi là kĩ thuật kiểm thử hộp trắng (white- box testing). Phần mềm được xem như một hộp trắng, có thể nhìn xuyên suốt được (thấy cấu trúc bên trong, tức là mã nguồn hay mô hình thiết kế). Các kĩ thuật kiểm thử còn được phân loại dựa theo mã nguồn có được thực thi khi kiểm thử hay không. Các kĩ thuật kiểm thử yêu cầu thực thi mã nguồn của phần mềm được gọi là các kĩ thuật kiểm thử động (dynamic testing). Ngược lại. các kĩ thuật kiềm thử chỉ phân tích các dạng lĩnh của phần mềm (đặc tả, mã nguồn) được gọi các kĩ thuật kiểm thử tĩnh (static testing). Ngoài ra. các kì thuật kiểm thử trộn lẫn các kỉ thuật kiểm thử chức năng và kiểm thử cấu trúc được gọi là các kĩ thuật kiểm thử hộp xám (grey- box testing). Các kĩ thuật kiểm thử hộp xám thường sử dụng các kĩ thuật kiểm thử chức năng trong các bước đầu. sau đó các phần còn lại của mã nguồn được kiểm thử bởi các kĩ thuật cấu trúc. 1.3. Các bước kiểm thử Để kiểm thử một chương trình, kiểm thử viên phải thực hiện các bước cơ bản Trang 11
18. khác nhau. Các bước này được giải thích chi tiết ở dưới đây. -Lập kế hoạch kiểm thử : Kế hoạch kiểm thử cho phép xác định mục tiêu kiểm thử, đối tượng kiểm thử. kĩ thuật kiểm thử. nguồn tài nguyên, lịch kiểm thử Một kế hoạch kiểm thử tốt sẽ giảm được chi phí, cải thiện được quan hệ với lập trình viên và nâng cao được chất lượng của kiểm thử. -Thiết kế ca kiểm thử: Như đã trình bày ở trên, một ca kiểm thử bao gồm dữ liêu thử, điều kiện thực thi và kết quả mong đợi. +Thiết kế dữ liệu thử : Tùy theo mục tiêu kiểm thử, kĩ thuật kiểm thử và đối tượng kiểm thử mà các dữ liệu thử sẽ được thiết kế dựa trên đặc tả yêu cầu, thiết kế chương trình hay mã nguồn. Thiết kế dữ liệu thử được xem là hoạt động quan trọng nhất, bởi vi các dữ liệu thử phải có khả năng phát hiện lỗi cao. +Xát định điều kiện thực thi : Việc xác đinh điều kiện kiểm thử hay các bước thực thi có thế đơn giản hay phức tạp, tùy theo đối tượng cần được kiểm thử. + Xác định kết quả mong đợi : Cần xác định kết quả chúng ta mong đợi khi thực thi phần mềm với dữ liệu thử được thiết kế. -Thực thi chương trình : Kiểm thử viên có thể cần phải chuẩn bị môi trường để thực thi chương trình cần được kiểm thử. Sau đó, kiểm thử viên thực thi chương trình với các dữ liệu được thiết kế và ghi nhận kết quả thu được. -Phân tích kết quả kiểm thử và lập báo cáo : Hoạt động cuối cùng là phân tích kết quả của việc thực hiện ca kiểm thử. Công việc chính là so sánh kết quà thực thi chương trinh với kết quả mong đợi. Độ phức tạp của việc so sánh phụ thuộc vào độ phức tạp của dữ liệu cần được quan sát và phân tích. Sau bước này, phán xét kiểm thử được gán cho chương trình khi thực hiện ca kiểm thử. Có ba phán xét chính được gán gồm: thành công, thất bại và chưa kết luận. + Nếu chương trình tạo ra kết quả khác với kết quả mong đợi thì phán xét thất bại được gán. + Trong một số trường hợp không thể xác định chương trình thành công hay thất bại khi thực hiện ca kiểm thử, nghĩa là cần phải thực hiện thêm các kiểm thử khác để làm rõ chương trình thành công hay thất bại. Khi đó, phán xét chưa kết luận được gán. Ở bước này, kiểm thử viên cần phải lập báo cáo lỗi cũng như báo cáo kiểm thử. Báo cáo lỗi (bug report) phải được lập ngay sau khi phân tích mỗi lỗi. Báo cáo lỗi nên chứa các thông tin về người xác định lỗi. thời gian xác định lỗi, sản phẩm (gồm cả phiên bản) bị lỗi, mô tả lỗi. cách tái tạo lỗi, độ nghiêm trọng của lỗi. trạng thái lỗi Trang 12
19. cũng như các thông tin khác hổ trợ việc sửa lỗi. Báo cáo kiểm thử (test report) tổng hợp kết quả kiểm thử, nêu rõ những gì đã được kiểm thử, những gì chưa được kiểm thử, danh sách các lỗi được tìm thấy, lịch và thời gian kiểm thử thực tế. 1.4. Kiểm chứng và hợp thức hóa Nếu chúng ta muốn bảo đảm rằng một phần mềm được phát triển một cách đúng đắn và các thành phần cấu tạo nên phần mềm cũng được phát triển một cách đúng đắn, chúng ta gợi là kiểm chứng (verification). Tuy nhiên, một phần mềm không chỉ đơn thuần là đáp ứng yêu cầu của nhà sản xuất, mà nó chỉ trở nên hữu ích nếu đáp ứng được nhu cầu của người sử dụng cuối cùng. Việc báo đảm một phần mềm đáp ứng nhu cầu của người sử dụng được gọi là hợp thức hoá (validation). Hợp thức hoá một phần mềm phản ánh góc nhìn của người sử dụng, trong khi kiểm chứng phản ánh góc nhìn của nhà sản xuất. Trong thực tế, một phần mềm đáp ứng được nhu cầu người sử dụng không có nghĩa là nộ được sản xuất một cách đúng đắn. Ngược lại, phát triển ra một phần mềm tuân thủ tất cả các quy trình sản xuất cũng không bảo đảm rằng phần mềm đó sẽ đáp ứng được nhu cầu của người sử dụng. Vì vậy, kiểm chứng và hợp thức hoá, được kí hiệu là v&v (Verification & Validation), cùng hồ trợ cho nhau nhằm tạo ra sản phấm phần mềm có chất lượng tốt. Chúng ta có thể phân biệt hai khái niệm này như sau : kiểm chứng nhằm trả lời câu hỏi ''Chúng ta đã xây dựng tốt một phần mềm chưa trong khi hợp thức hoá nhằm trả lời câu hỏi ''Chúng ta đã xây dựng một phần mềm tốt chưa Hiển nhiên rằng mỗi chiến lược kiểm thử có thể sử dụng các kĩ thuật kiểm thử khác nhau. Để hợp thức hoá, các kĩ thuật kiểm thử chức năng thường được sử dụng, bởi vì các chức năng là mối quan tâm hàng đầu đối với người sử dụng. Dể kiểm chứng, các kĩ thuật kiểm thử chức năng cũng như kiểm thử cấu trúc đều có thể được sử dụng. 1.5. Khái niệm hoạt động kiểm thử Một hoạt động kiểm thử (test activity) hay mức kiểm thử (test level) là một kế hoạch nhằm định nghĩa mục tiêu của các giai đoạn kiểm thử cũng như các kĩ thuật kiểm thử được sử dụng. Hoạt động kiểm thử thường được quyết định dựa vào : -Tiêu chuẩn vầ độ tin cậy của phần mềm; -Chi phí cho việc phát triển phần mềm Trong bất kì quy trình phát triển phần mềm nào, chúng ta đều có thể nhận thấy các đơn vị độc lập nhỏ được viết bởi các lập trình viên, sau đó chúng được phát triển Trang 13
20. và tích hợp dần dần cho đến khi đạt được sản phẩm cuối cùng theo yêu cầu của khách hàng. Một chiến lược kiểm thử sẽ phụ thuộc kích thước của đối tượng được kiểm thử cũng như quan điểm của chúng ta về đối tượng được kiểm thử. Nếu chúng ta muốn kiểm thử một cách độc lập các thành phần (đơn vị) cấu tạo nên phần mềm, chúng ta gọi là kiểm thử đơn vị (unit testing). Kiểm thử đơn vị chỉ quan tâm từng đơn vị phần mềm, như hàm, thủ tục hay lớp. Kiểm thử đơn vị được thực hiện bởi các lập trình viên. Các kĩ thuật kiểm thử chức năng và kiểm thử cấu trúc đều có thể được sử dụng cho kiểm thử đơn vị. Nếu chúng ta muốn kiểm thử sự kết hợp các thành phần cấu tạo nên phần mềm, chúng ta gọi là kiểm thử tích hợp (integration tesing). Kiểm thử tích hợp hướng đến phát hiện lỗi giao tiếp giữa các thành phần. Kiểm thử tích hợp thường được thực hiện bởi các lập trình viên và/hoặc các kiểm thử viên. Thông thường, chỉ các kĩ thuật kiểm thử chức năng được sử dụng cho kiểm thử tích hợp. Trong các trường hợp cần thiết, các kĩ thuật kiểm thử cấu trúc cũng có thể được sử dụng, tuy nhiên chi phí kiểm thử sẽ cao. Một khi đã kết thúc kiểm thử tích hợp, chúng ta kiểm thử toàn bộ phần : mềm, chúng ta gọi là kiểm thử hệ thống (System testing). Kiểm thử hệ thống thường là giai đoạn cuối trong các quy trình phát triển, nhằm đảm bảo hầu hết các lỗi đã được phát hiện và sửa chữa, phần mềm đáp ứng được yêu cầu đặt ra, có thể chuyền giao để sử dụng. Kiểm thử hệ thống có thể bao gồm nhiều loại kiểm thử khác nhau, như kiểm thử chức năng, kiểm thử bảo mật, kiểm thử cấu hình, kiểm thử khả năng chịu tải, kiểm thử hiệu năng, kiểm thử độ tin cậy, kiểm thử tài liệu Kiểm thử hệ thống được thực hiện bởi các kiểm thử viên. Sau khi hoàn tất kiểm thử hệ thống, phần mềm được chuyển giao cho người sử dụng. Người sử dụng sẽ thực hiện các kiểm thử phần mềm, được gọi là kiểm thử chấp nhận (acceptance testing). Mục tiêu của kiểm thử chấp nhận là đánh giá chất lượng của phần mềm, thay vì tìm lỗi (là mục tiêu của kiểm thử đơn vị, kiểm thử tích hợp và kiểm thử hệ thống). Khi kiểm thử chấp nhận, người sử dụng có thể định nghĩa các tiêu chí chấp nhận dựa trên mong đợi của họ về phần mềm Như thế, một phần mềm thường trải qua bốn giai đoạn kiểm thử trước khi được triển khai để sử dụng. Ba giai đoạn kiểm thử đơn vị, kiểm thử tích hợp và kiểm thử hệ thống được thực hiện bởi người phát triển phần mềm, trong khi kiểm thử chấp nhận được thực hiện bởi khách hàng. Ngoài ra, một khi kiểm thử phát hiện lỗi, việc sửa lỗi sau đó thường dẫn đến sự xuất hiện của các lỗi khác. Vì vậy, cần phải thực hiện các kiểm thử khác đế bảo đảm rằng các lỗi mới không xuất hiện, chúng ta gọi đó là kiểm thử hồi quy (regression Trang 14
21. testing). Kiểm thử hồi quy có thể được thực hiện trong suốt quy trình phát triển. Kiểm thử hồi quy được thực hiện khi một thành phần của hệ thống bị thay đổi. Mục tiêu chính của kiểm thử hồi quy nhằm đảm bảo sự thay đổi không tạo ra các lỗi mới trong các thành phần không bị chỉnh sửa. Kiểm thử hồi quy không được xem là một hoạt động kiểm thử khác. Đúng hơn, kiểm thử hồi quy là một giai đoạn con của kiểm thử đơn vị, kiểm thử tích hợp và kiểm thử hệ thống, như được minh hoạ trong Kiểm thử hồi quy Kiểm thử Kiểm thử Kiểm thử hệ Kiểm thử đơn vị tích hợp thống chấp nhận Hình 1.3. Kiểm thử hồi quy ở các hoạt động kiểm thử khác nhau 1.6. Các nguyên tắc kiểm thử Các nguyên tắc luôn đóng vai trò quan trọng trong lĩnh vực công nghệ phần mềm. Các nguyên tắc trong công nghệ phần mềm là các luật hay quy tắc hướng dẫn làm thế nào để xây dựng (thiết kế, phát triển, kiểm thử và bảo trì) phần mềm. Kiểm thử là một trong những lĩnh vực của công nghệ phần mềm, kiểm thử cũng có các nguyên tắc riêng dành cho các kiểm thử viên. Các nguyên tắc này giúp cho kiểm thử viên xác định cách kiểm thử một phần mềm cũng như thực hiện công việc kiểm thử một cách chuyên nghiệp. Chúng ta sẽ xem xét một sổ nguyên tắc cơ bản [4] liên quan đến kiểm thử động, nghĩa là kiểm thử yêu cầu thực thi phần mềm. Nguyên tắc 1 : Kiểm thử là quy trình thực thi phần mềm và sử dụng các ca kiểm thử để phát hiện lỗi. Mặc dù công nghệ phần mềm đã có rất nhiều cài tiến trong các phương pháp phát triển để hạn chế và loại bỏ lỗi. Tuy nhiên, lỗi vẫn luôn xuất hiện và có các ảnh hưởng xấu đến chất lượng phần mềm. Kiểm thử viên cần phải xác định các lỗi này trước khi phần mềm được sử dụng. Định nghĩa kiểm thử phần mềm được hiểu như là một nguyên tắc mà kiểm thử viên phải luôn luôn tuân theo. Không nên lên một kế hoạch kiểm thử nhằm chứng minh rằng lỗi không tồn tại. Nguyên tắc 2 : Với mục đích của kiểm thử nhằm phát hiện lỗi. một ca kiểm thử tốt là ca kiểm thử có khả năng cao phát hiện những lỗi chưa được tìm thấy. Nguyên tắc này cung cấp cách để đánh giá sự hiệu quả một ca kiểm thử. Khi thiết kế, kiểm thử viên phải xác định mục tiêu rõ ràng của mỗi ca kiểm thử, tức là Trang 15
22. nhằm phát hiện các loại lỗi gì. Sau đó, kiểm thử viên thực hiện chọn lựa bộ dữ liệu thử, kịch bản kiểm thử và thực thi phần mềm để kiểm thử. Kết quả kiểm thử sẽ giúp cho kiểm thử viên khẳng định mục tiêu của ca kiểm thử. Nguyên tắc 3: Một ca kiểm thử phải định nghĩa kết quả mong đợi Đối với kiểm thử viên, điều hiển nhiên là một ca kiểm thử phải chứa dữ liệu thử. Tuy nhiên, một ca kiểm thử sẽ không có giá trị nếu chúng ta bỏ quên kết quả mong đợi tương ứng với dữ liệu thử. Trong trường hợp này vấn đề sẽ trở nên tồi tệ hơn, khi mà một kết quả sai được cho là kết quả đúng bởi vì tâm lí của người phát triển mong muốn nhận được kết quả tốt. Định nghĩa kết quả mong đợi sẽ cho phép kiểm thử viên xác định có hay không có lỗi và việc kiểm thử thành công hay thất bại. Việc đặc tả các dữ liệu thử và kết qủa tương ứng là phải được thực hiện trong quá trình thiết kế các ca kiểm thử. Nguyên tắc 4 : Kiểm thử nên được thực hiện bởi một nhóm độc lập với nhóm phát triển. Trước hết về mặt tâm lí, rất khó để các lập trình viên chấp nhận rằng phần mềm do mình làm ra bị lỗi. 'Thật vậy, một khi các lập trình viên xây dựng nên phần mềm, thật là khó để họ chuyển từ góc nhìn xây dựng sang góc nhìn phá huỷ trong khi kiểm thử. Nếu các lập trình viên thực hiện kiểm thử phần mềm do chính họ làm ra thì sẽ không mang lại hiệu quả vì họ không mong muốn phát hiện lỗi của chính họ. Hơn nữa, một lập trình viên có thể luôn tránh tìm ra lỗi, bởi vì họ ngại sự đánh giá thấp từ đồng nghiệp hay cấp trên. Ngoài lí do về mặt tâm lí, một vấn đề khác rất thực tế là : chương trình có thể chứa lỗi do sự hiểu không chính xác về đặc tả hay mô tả bài toán của lập trình viên. Trong trường hợp này. dường như rằng lập trình viên sẽ mang luôn cả sự hiểu không chính xác đó vào trong kiểm thử chương trình. Như vậy, lỗi sẽ rất khó được phát hiện. Tuy nhiên, nguyên tắc nàv không có nghĩa là những lập trình viên không thể kiểm thử chưong trình của chính họ, mà đúng hơn là kiểm thử sẽ hiệu qủa hơn khi được thực hiện bởi những người khác. Nguyên tắc 5: Kết quả kiểm thử nên được phân tích một cách cẩn thận Đây là nguyên tắc rất cơ bản, nhưng thường không được đánh giá đúng dẫn đến không phát hiện được lỗi hoặc làm xuất hiện các lỗi khác. Chẳng hạn : -Một lỗi bị bỏ qua hoặc coi nhẹ, khi đó việc kiểm thử sẽ được coi là không phát hiện được lỗi. tuy nhiên thực tế thì lỗi tồn tại. Kiểm thử sẽ được tiếp tục dựa trên kết quả không chính xác trước đó. có thể trong các bước kiểm thử sau lỗi sẽ được phát hiện. Trong trường hợp đó việc định vị lỗi và sửa lỗi sẽ trở nên khó khăn hơn. Trang 16
23. - Một lỗi có thể bị nghi ngờ là tồn tại, tuy nhiên thực tế thì lỗi không tồn tại. Trong trường hợp đó. chúng ta sẽ có thể mất nhiều thời gian và công sức để tìm và xác định lỗi. Trong khi đó, một sự phân tích tỉ mỉ kết quả kiểm thử sẽ chỉ ra rằng lỗi không tồn tại. Nguyên tắc 6 : Các ca kiểm thử nên được thiết kế cho cả những dữ liệu vào hợp lệ và không hợp lệ. Kiểm thử một phần mềm thường chỉ chú ý đến các tập dữ liệu vào hợp lệ, tức là các tập dữ liệu vào đúng như đặc tả. Trong thực tế, dữ liệu vào có thể không hợp lệ bởi nhiều lí do khác nhau. Chẳng hạn, người sử dụng hiểu không chính xác hoặc thiếu thông tin về dữ liệu vào. Thậm chí khi có được thông tin đầy đù, người sử dụng cũng gõ sai dữ liệu vào. Các thiết bị cung cấp dữ liệu vào sai do các tác động hay điều kiện bất thường. Sử dụng các ca kiểm thử với các dữ liệu không hợp lệ sẽ kích hoạt phần mềm một cách không mong đợi và như thế có thể sẽ xác định được các hành vi bất thường của phần mềm. Hơn nữa, các dữ liệu không hợp lệ còn cho phép đánh giá được khả năng bền vững của phần mềm, nghĩa là hoạt động của phần mềm khi có sự kiện không mong đợi xuất hiện. Ngoài ra, các ca kiểm thử với các dữ liệu vào không hợp lệ thường có khả năng phát hiện lỗi tốt hơn các ca kiểm thử với các dữ liệu vào hợp lệ. Nguyên tắc 7: Các ca kiểm thử phải được tái sử dụng. Các ca kiểm thử nên được lưu giữ sau mỗi kiểm thử. Vì sau khi kiểm thử, phần mềm chứa lỗi, cần thực hiện sửa lỗi. Phần mềm sau đó sẽ được kiểm thử lại hay kiểm thử hồi quy. Nếu không lưu giữ lại các ca kiểm thử thì cần phải xây dựng lại. Việc xây dựng lại các ca kiểm thử luôn yêu cầu nhiều thời gian, nên đôi khi kiểm thử lại bị bỏ quên. Vì thế, kiểm thử lại thường ít khi được thực hiện nghiêm túc như kiểm thử lần đầu. Nguyên tắc 8 : Xác suất tồn tại của các lỗi khác nữa trong một đơn vị phần mềm tỉ lệ với số các lỗi đã được phát hiện trong đơn vị phần mềm đó. Khái niệm đơn vị phần mềm ở đây được hiểu là một thành phần cấu tạo nên phần mềm, có thể là một hàm, thủ tục, phương thức, lớp hay thậm chí lá một phần mềm. Nguyên tắc này nói rằng nếu một đơn vị phần mềm với một số lượng lớn các lỗi đã được phát hiện, thì khi tiếp tục thực hiện kiểm thử khả năng xác định được nhiều lỗi hơn nữa là rất cao. Chẳng hạn, giả sử có hai đơn vị phần mềm A và B, khi kiểm thử phát hiện đơn vị A chứa 20 lỗi trong khi B chỉ chứa 4 lỗi, như thế khả năng tồn tại Trang 17
24. lỗi khác nữa trong A cao hơn trong B. Nguyên tắc này được dựa trên việc quan sát từ thực tế khi kiểm thử phân mềm. Các lỗi thường xuất hiện trong các đơn vị phần mềm có độ phức cao và được thiết kế không tốt. Khi đó, cần phải tiếp tục thực hiện kiểm thử nhiều hơn nữa đối với các đơn vị phần mềm có xu hướng lỗi này. Nguyên tắc 9: Kiểm thử nên được lập kế hoạch. Kế hoạch kiểm thử nên được mô tả chi tiết từ mỗi giai đoạn kiểm thử. Kế hoạch kiểm thử với các mục tiêu xác định nhằm đảm bảo phân phối hợp lí về mặt thời gian cũng như tài nguyên kiểm thử và bảo đảm kiểm thử được giám sát và quản lí. Kế hoạch kiểm thử cần phải được xây dựng kết hợp với kế hoạch dự án. Thật vậy, kiểm thử viên không thể thực thi các ca kiểm thử cho một đơn vị phần mềm khi mà nó chưa được hoàn thành bởi lập trình viên. Nguyên tắc 10 : Các hoạt động kiểm thử nên phải được tích hợp vào quy trình phát triển phần mềm. Hoạt động kiểm thử không chỉ được thực hiện sau khi đã có mã nguồn mà cần phải được thực hiện sớm hơn trong các giai đoạn phát triển, như giai đoạn phân tích, đặc tả và thiết kế. Các hoạt động kiểm thử được thực hiện xuyên suốt trong quá trinh phát triển cho đến khi sản phẩm được chuyển giao cho người sử dụng. Bởi vì, việc phát hiện lỗi càng sớm trong các giai đoạn phát triển thì việc sửa lỗi sẽ càng đơn giản và ít chi phí. Nguyên tắc 11: Kiểm thử là một công việc đầy sáng tạo và thách thức. Đối với các phần mềm phức tạp, yêu cầu sáng tạo trong kiểm thử thậm chỉ còn vượt cả yêu cầu sáng tạo trong thiết kế. Để hoàn thành tốt công việc kiểm thử, các kiểm thử viên cần phải : - Có kiến thức rộng về lĩnh vực công nghệ phần mềm, đặc biệt là về đặc tả, thiết kế và phát triển phần mềm -Hiểu biết các loại lỗi, và các loại lỗi thường xuất hiện ở những cấu trúc lệnh nào hay ở các đơn vị phần mềm nào; -Biết lập luận đưa ra những giả thiết liên quan đến sự hiện diện lỗi trong chương trình ; -Nắm bắt được môi trường ứng dụng của phần mềm cần kiểm thử ; -Lên kế hoạch phân phối tài nguyên kiểm thử hợp lí; Trang 18
25. -Nắm bắt và áp dụng các công cụ kiểm thử ; -Iàm việc và hợp tác không chỉ các thành viên nhóm kiểm thử mà còn với các thành viên của nhóm phát triển, cũng như với khách hàng và người sử dụng. 1.7. Các khó khăn của kiểm thử Theo các nghiên cứu thống kê đã khẳng định, giai đoạn kiểm thử là giai đoạn đòi hỏi nhiều chi phí nguồn tài nguyên (theo [3], khoảng 40% tổng chi phí của một dự án phần mềm). Chúng ta có thể kết luận rằng giảm chi phí các hoạt động kiểm thử sẽ giảm được tổng chi phí của dự án phần mềm. Trong một số dự án phần mềm, vì lí do kinh tế các hoạt động kiểm thử được giảm bớt. Hậu qủa nhận được, về mặt kinh tế, chi phí cho giai đoạn bảo trì sẽ tăng lên rất lớn. Vì vậy, giải pháp là không nên giảm các hoạt động kiểm thử mà quan trọng là kiểm thử một cách tốt hơn, nghĩa là cần phải chọn chiến lược và kĩ thuật kiểm thử phù hợp để phát hiện ra số lượng lỗi thực tế lớn nhất có thể. Lỗi thực tế từ đây được hiểu là các lỗi thường sinh ra trong quá trình phát triển. Bởi vì một kĩ thuật kiểm thử không thực sự có ích khi nó chi phát hiện ra những lỗi ít khi gặp phải hoặc rất ít nghiêm trọng. Để kiểm thử tốt hơn, cần phải quan tâm đến các yếu tố làm cho việc kiểm thử khó khăn. Các yếu tố này có thể được chia làm các nhóm sau [3] : -Khó khăn liên quan đến quy trình phát triển phần mềm, -Khó khăn về mặt con người, -Khó khăn về mặt kĩ thuật. 1.7.1 Khó khăn liên quan đến quy trình phát triển phần mềm Quy trình phát triển phần mềm là một tập hợp các hoạt động từ giai đoạn tìm hiểu, khảo sát, phân tích, thiết kế và cài đặt cho đến giai đoạn sử dụng và bão trì. Mỗi giai đoạn này thực ra là một sự chuyển đổi một tập hợp thông tin này sang một tập hợp thông tin khác, trong đó, tập hợp thông tin đầu tiên là mô hình thế giới thực cần tin học hoá và tập hợp thông tin cuối cùng chính là phần mềm thực thi được. Quá trình chuyển đổi này sẽ dẫn đến sự mất mát thông tin khó tránh khỏi, nghĩa là các lỗi sẽ xuất hiện. Khó khăn đầu tiên của kiểm thử liên quan đến tính chất trừu tượng của đối tượng trong quá trình chuyển đổi. Hơn nữa, các giai đoạn chuyển đổi có thể tạo nên một thất bại tới giai đoạn cuối cùng mà khi phát hiện lập trình viên khó có thể biết được nguyên nhân do giai đoạn nào trước đó. 1.7.2 Khó khăn về mặt con người Trước hết. kiếm thử là một hoạt động mà mục đích của nó đôi khi được nhìn Trang 19
26. nhận chưa rõ ràng bởi các chuyên gia tin học. Một phần của vấn đề là do đào tạo, tuy nhiên một phần cũng là do thiếu sư quan tâm đầy đủ về kiểm thử trong lĩnh vực công nghệ phần mềm. Thông thường, các chuyên gia tin học chỉ chú trọng đến thiết kế, lập trình hoặc các công nghệ mà ít chú trọng đến kiểm thử. Kiểm thử thường chỉ được coi là giai đoạn đơn giản cuối cùng được dùng để hợp thức hoá sản phẩm. Hơn nữa, kiểm thử cũng ít được chú trọng đối với các nhà nghiên cứu. Vì thế, nhiều lỗi nghiêm trọng mắc phải ngay từ các giai đoạn đầu của quy trình phát triển (đặc tả và thiết kế). Trong khi đó, nhiều thống kê cho thấy: các lỗi mắc phải càng sớm trong quy trình phát triển, thì các lỗi đó càng khó phát hiện và khó khắc phục. Vì vậy, việc nghiên cứu các phương pháp và công cụ phát triển thích ứng sẽ góp phần rất lớn vào việc giảm bớt các lỗi ngay từ các giai đoạn đầu của quy trình phát triển. 1.7.3 Khó khăn về mặt kĩ thuật Khó khăn về mặt kĩ thuật là một tính chất đặc trưng của hoạt động kiểm thử. Thật vậy, từ năm 1931, nhà toán học Kurt Gôdel đã chứng minh được rằng tồn tại những phát biểu mà không thể chứng minh được là đúng hay sai, được gọi là các vấn đề không giải quyết được (non-decidability). Lấy một ví dụ cổ điển [1], phát biểu này là đúng hay sai : "Câu này là sai". Nêu câu này là đúng thì điều được phát biểu là đúng, nghĩa là câu này là sai. Liên quan đến hoạt động kiểm thử, có thể gói gọn bằng phát biểu rằng : Không tồn tại thuật toán tổng quát có thể chứng minh sự đúng đắn hoàn toàn của bất kì một chương trình nào. Như thế. Kiểm thử không những bị giới hạn chỉ bởi các yếu tố định lượng (không thể kiểm thử vét cạn tất cả các dữ liệu vào. độ phức tạp của mã nguồn, khó khăn xây dựng phán xét tự động ) mà còn bị giới hạn bởi yếu tố định tính về các tính chất giải quyết được của một hệ thống bất kì. 1.8 Kết luận Chương này đã trình bày tổng quan về kiểm thử phần mềm. Trước hết, một số ví dụ cụ thể mà phần mềm đã gây ra những thiệt hại lớn khi mà kiểm thử đã chưa được thực hiện tốt, nhằm cho thấy rõ rằng hoạt động kiểm thử đóng vai trò rất quan trọng trong phát triển phần mềm. Từ đó, khái niệm lỗi đã được giới thiệu. Nhiều định nghĩa khác nhau của kiểm thử đã được đề cập, tuy nhiên các định nghĩa này đều hướng đến kiểm thử nhằm mục đích phát hiện lỗi và nâng cao chất lượng phần mềm. Nhiều khái niệm liên quan đến lĩnh vực kiểm thử đã được trình bày như: dữ liệu vào, dữ liệu thử, kịch bản kiểm thử, ca kiểm thử hay phán xét kiểm thử. Các kĩ thuật Trang 20
27. kiểm thử cũng đã được chia thành các nhóm tuỳ theo cách mà dữ liệu thử được thiết kế. Sau đó, các hoạt động kiểm thử đã được phân biệt tuỳ thuộc vào đối tượng được kiểm thử hay giai đoạn phát triển phần mềm. Định hướng của kiểm thử viên trong suốt quá trình kiểm thử được nhấn mạnh thông qua các nguyên tắc kiểm thử. Cuối cùng, nhiều yếu tố khác nhau cho thấy rằng kiểm thử là hoạt động rất phức tạp đòi hỏi sự chú trọng hơn nữa của những chuyên gia tin học. Trong các chương tiếp theo, chúng ta sẽ tiếp tục đề cập một cách chi tiết các vấn đề đã được giới thiệu trong chương này. Câu hỏi và bài tập 1.Hãy phân biệt các khái niệm sai sót, lỗi và thất bại. Cho ví dụ minh hoạ. 2.Kiểm thử nhằm mục đích gì ? 3.Tại sao không thể kiểm thử vét cạn ? 4.Ca kiểm thử là gì ? 5.Phán xét kiểm thử là gì? 6. Tại sao phát hiện lỗi càng sớm trong quy trình phát triện phần mềm càng tốt ? 7.Phân biệt kiểm thử động và kiểm thử tỉnh? 8. Phân biệt kiểm thử chức năng và kiểm thử cấu trúc? 9. Trong quy trình kiểm thử, bước nào thưòng quan trọng nhất ? Tại sao ? 10. Phân biệt thuật ngữ kiểm chứng và hợp thức hoá? 11. Tại sao kiểm thử nên được thực hiện bởi nhóm độc lập với nhóm phát triển ? 12. Tại sao các ca kiểm thử nên được thiết kế cho cả những dữ liệu hợp lệ và dữ liệu không hợp lệ ? Trang 21
28. CHƯƠNG 2 KIẾM THỬ TRONG QUY TRÌNH PHÁT TRIỂN PHẦN MỀM Sau khi giới thiệu tổng quan về kiểm thử phần mềm, chương này sẽ trình bày chi tiết hơn về vai trò kiểm thử trong quy trinh phát triển phần mềm. Trước hết, toàn cảnh các kĩ thuật kiếm thử sẽ được đề cập. Sau đó. một số quy trình phát triền phần mềm phổ biến trong công nghệ phần mềm sẽ được nhắc lại. Cuối cùng, các hoạt động kiểm thử trong các quy trình phần mềm cũng như các kĩ thuật kiểm thử liên quan sẽ được thảo luận. 2.1. Các kĩ thuật kiểm thử Hiện nay, có rất nhiều kĩ thuật kiểm thử có thể được ứng dụng trong các dự án phát triển phần mềm. Chương này sẽ không giới thiệu một cách chi tiết các kĩ thuật này mà chi nêu rõ việc sử dụng các kĩ thuật trong các dự án phát triển phần mềm. Để chỉ rõ các kĩ thuật kiểm thừ phần mềm đóng góp vào việc nâng cao chất lượng của phần mềm, trước hết chúng tôi sẽ trình bày phân nhóm các kĩ thuật kiểm thử, sau đó chúng tôi sẽ nhấn mạnh vào mục tiêu của mỗi nhón kĩ thuật này. 2. 1. 1. Phân nhỏm các kĩ thuật kiểm thử Để áp dụng các kĩ thuật kiểm thử, chúng ta cần it nhất một trong các đối tượng sau : - Đặt tả của phần mềm. - Mã nguồn của phần mềm. - Mã phần mềm thực thi được(mã nhị phân). Có rất nhiều quan điểm phân nhóm các kĩ thuật kiểm thử, trước hết chúng ta nêu cách phân loại theo tài liệu |39|, dựa trên sự kết hợp của ba đối tượng trên để áp dụng một kĩ thuật kiểm thử. Đánh số các khả năng kết hợp ba đối tượng trên tạo nên bảy lớp từ 1 đến 7. Trong Báng 2.1. dấu X trong một ô nghĩa là lớp kĩ thuật cần đối tượng tương ứng để kiểm thử. Chẳng hạn, một kĩ thuật thuộc lớp 3, nghĩa là kĩ thuật này cần mã nguồn và mã thực thi để áp dụng. Lớp 1 : Các kĩ thuật kiểm thử trong lớp này chi dựa trên mã thực thi vì thế là các kĩ thuật đơm giản nhất. Thông thường là các kiểm thử được thực hiện bởi người sử dụng hoặc các kĩ thuật kiểm thử ngẫu nhiên (tức là tập dữ liệu thử được tạo ra một cách ngẫu nhiên chứ không theo một tiêu chi nao) Trang 22
29. Bảng 2. 1. Phân loại các kĩ thuật kiểm thử Lớp Đặc tả Mã nguồn Mã thực thi 1 X 2 X 3 X X 4 X 5 X X 6 X X 7 X X X Lớp 2 : Các kĩ thuật kiểm thử này dựa trên mã nguồn để xác định các lỗi, thông thường là các lỗi chung, tức là độc lập với phẩn mềm cụ thể. Lớp này bao gồm các kĩ thuật phân tích tĩnh (không thực thi chương trình), thẩm định mã nguồn, phân tích độ phức tạp, kiểm tra cú pháp . Lớp 3 : Gồm các kĩ thuật kiểm thử động (thực thi chương trình) như phân tích luồng dữ liệu hay luồng điều khiển Lớp 4 : Gồm các kĩ thuật phân tích và kiểm tra đặc tả. Lớp 5 : Gồn tập hợp rất nhiều các kĩ thuật kiểm thử chức năng phổ biến như kiểm thử giá trị biên, kiểm thử lớp tương đương, kiểm thử dựa trên bảng quyết định Lớp 6 : Gồm một số kĩ thuật thực thi kí hiệu và các kĩ thuật chứng minh sự đúng đắn của chương trinh. Lớp 7 : Gồm phần lớn các kĩ thuật kiểm thử cấu trúc, như phủ tất cả các cung, phủ tất cả các lộ trình Ngoài ra, một cách phân nhóm khác về các kĩ thuật kiểm thử củng rất phổ biến trong các tài liệu về kiểm thử. Các kĩ thuật kiểm thử chức năng hay ki thuật kiểm thử hộp đen là các kĩ thuật không dựa trên mã nguồn mà chi dựa trên đặc tả. Các kĩ thuật kiểm thử cấu trúc hay kĩ thuật kiểm thử hộp trắng là các kĩ thuật dựa trên mă nguồn để tạo ra dữ liệu thử. Các kĩ thuật kiểm thử cũng có thể dược phân nhóm theo tiêu chí: thực thi hay không thực thi chương trình. Các kĩ thuật động yêu cầu thực thi mã chương trình, trong khi các kĩ thuật tĩnh chi dựa trên mà nguồn hay đặc tả mà không yêu cầu thực thi chương trinh. Trong phần lớn các tài liệu về kiểm thử, các kĩ thuật kiểm thử được phân nhóm Trang 23
30. theo các nhóm kĩ thuật chức năng/kĩ thuật cấu trúc hay kĩ thuật động/kĩ thuật tĩnh. Một số quan điểm còn cho rằng chỉ những kĩ thuật động mới là các kĩ thuật kiểm thử, nghĩa là hoạt động kiểm thử cần phải thực thi chương trình. Trong tài liệu này, chúng tôi sẽ tập trung vào ba nhóm : - Nhỏm các kĩ thuật tĩnh gồm tất cả các kĩ thuật kiểm thử không yêu cầu thực thi phần mềm ; - Nhóm các kĩ thuật kiểm thử chức năng gồm các kĩ thuật dựa trên đặc tả phân mềm ; - Nhóm các kĩ thuật kiểm thử cấu trúc gồm các kĩ thuật dựa trên mã nguồn phân mềm. Như thế, khi nói đến các kĩ thuật kiểm thử chức năng hay kiểm thử cấu trúc chúng ta hiểu là các kĩ thuật động. Mỗi kĩ thuật kiểm thử có những ưu và nhược điểm riêng của nó. Cũng như thế, mỗi nhóm các kĩ thuật kiểm thử củng có những ưu và nhược điểm. Các kĩ thuật kiểm thử chức năng cho phép xác định được các chức năng của phần mêm có được đáp ứng hay không. Tuy nhiên, do các kĩ thuật kiểm thử chức năng không dựa trên mã nguồn, nên nếu có lỗi xảy ra. rất khó xác định được yếu tố gây nên lỗi. Ngược lại, các kĩ thuật kiểm thử cấu trúc có thể khảo sát được dễ dàng hơn so với các kĩ thuật kiểm thử chức năng về các yếu tấ gây nên lỗi, nhưng chúng không thể xác định được các chức năng của phần mềm có được thực hiện đúng đắn hay không. Chúng ta cũng có thề phân biệt hai khái niệm “lỗi phạm phải” và "lỗi bỏ quên". Các kĩ thuật kiểm thử cấu trúc dễ dàng phát hiện các lỗi phạm phải. Tuy nhiên, các kĩ thuật kiểm thử chức năng dễ dàng phát hiện các lỗi bỏ quen. Thật vậy, một bộ kiểm tra chính tả dễ dàng phát hiện các lỗi chính tả chúng ta phạm phải khi đọc văn bản, nhưng nó không thể cho chúng ta biết có những câu hay từ nào chúng ta đã bỏ quên. Ngược lại, nếu chúng ta đọc văn bản cho một người nghe, người đó có thể phát hiện các câu hay từ chủng ta bỏ quên, nhưng không thê phát hiện được các lỗi từ vựng. Nói một cách khác, các kĩ thuật kiểm thử cấu trúc dể dàng phát hiện các lỗi người phát triền phạm phải trong quá trình lập trình. Ngược lại, các kĩ thuật kiểm thử chức năng dễ dàng phát hiện cảc lỗi người phát triển phạm phái trong quá trinh thiết kế. Hay đơn giản hơn, các kĩ thuật kiểm thử cấu trúc nhằm phát hiện lớp các lỗi do lập trinh viên gây ra, trong khi các kĩ thuật kiểm thử chức năng nhằm phát hiện các lỗi cúa người đặc tả và thiết kế. Trang 24
31. Một cách tương tự, chúng ta phân biệt sự khác nhau giữa các kĩ thuật kiểm thử động và các kĩ thuật kiểm thử tĩnh. Các kĩ thuật kiểm thử tĩnh cho phép xác định được các lỗi chung dễ dàng như các quy ước thiết kế, quy ước lập trinh Các lỗi này độc lập với phần mềm cụ thể cần được kiểm thử. Tuy nhiên, chúng không thể xác định được chính xác hành vi của phần mềm khi thực thi, đay củng chính là ưu thế của các kĩ thuật kiểm thử động. Tóm lại. chúng ta có thể kết luận rằng các kĩ thuật kiểm thử bổ sung lẫn nhau nhằm nâng cao chất lượng phần mềm. Tùy các tình huống và yêu cầu cụ thể, chúng sé được kết hợp sử dụng nhằm mang lại hiệu quả cao nhất. 2.1.2 Sự hiệu quả của các kĩ thuật kiểm thử Sự hiệu quả của một số kĩ thuật kiểm thử cần phải được xem xét thận trọng,bởi vì có nhiều yếu tố có thể ảnh hưởng đến. Một số yếu tố có thể gồm: - Loại ứng dụng; - Kinh nghiệm của kiểm thử viên; Độ khó áp dụng của kĩ thuật và hiệu suất của nó (thời gian học/đào tạo, giá công cụ ); - Môi trường phần cứng ; - Loại lỗi được phát hiện, tần suất và độ nghiêm trọng của lỗi; - Phương pháp phát triển đang sử dụng và giai đoạn áp dụng; - Tài liệu hỗ trợ; - Độ chính xác khi định vị lỗi; Trong số các yếu tố này, yếu tố độ chính xác khi định vị lỗi là rất quan trọng. Bởi vì, chúng ta không chỉ quan tâm đến phát hiện lỗi mà còn định vị lỗi. Phân lớn các kĩ thuật kiểm thử cấu trúc có khả năng xác định chinh xác vị trí gần lỗi trong mã nguồn, như thế thời gian để gở rối giảm đáng kể. Ngược lại, phần lớn các kĩ thuật kiểm thử chức năng tìm thấy lỗi, nhưng cần nhiều thời gian để gở rối nhằm định vị lỗi. Đôi khi thời gian này rất dài, vì thế làm giảm hiệu quả của kĩ thuật kiểm thử chức năng. Để xác định hiệu quả thực tế của một kĩ thuật kiểm thử cần phài nắm tất cả các yếu tố này và các thành phần của chúng. Thậm chi, một khi đã nắm được tất cả các yếu tố này, cẩn phải không quên rằng các lỗi phạm phải bởi các lập trinh viên thay đổi theo thời gian : bản chất và tần suất của lỗi thay đổi theo sự phát triển của công nghệ phần mềm. Trang 25
32. Trong thực tế. chúng ta biết rằng các công nghệ mới trong công nghệ phần mềm (đặc tả hình thức, hỗ trợ thiết kế, sinh mã nguôn tự dộng, kiểm tra kiểu ) làm giảm đáng kể các lỗi mà phát triền viên có thể phạm phai. Chăng hạn, một lập trình biên dịch cảnh báo cho một lập trình viên biết một biến không được khởi gán. Vi thế, lập trinh viên sẽ có xu hướng sửa lỗi này thường xuyên. Lập trình viên sẽ tự cho rằng “nếu một biên không được khởi gán, thì chi cần đơm giản là khởi gán bàng 0” Cách sửa lõi nay có thể là nguồn gốc dẩn đến các lỗi khác. Như thế, có thể việc tích hợp các kĩ thuật mới thay đổi loại lỗi phạm phải. Các lỗi này trở nên khó để phát hiện hơn và yêu cầu các kĩ thuật kiểm thử phức tạp hơn. Nghịch lí này không nói lên rằng việc tích hợp các công cụ hay kĩ thuật mới là không tốt, tuy nhiên chúng tôi muốn nhấn mạnh rằng chính sách công cụ hóa hoàn toàn không phải luôn là sự thành công về mặt kiểm thử. Một sự đánh giá hiệu quả phát hiện lỗi của các kĩ thuật kiểm thử đề xuất trong [7] dựa trên sự phân loại các loại lỗi (Bẩng 2.2). Bảng 2.2 chi ra rằng khả năng phát hiện các loại lổi của các kĩ thuật kiểm thử. Chẳng hạn, các kĩ thuật kiểm thử cấu trúc có khả năng “tấn công” cao các loại lỗi tính toán và lô-gíc (như các biểu thức số học và các biểu thức điều kiện). Bảng 2.2 không hoàn toàn cho biết lợi ich của mỗi kĩ thuật, chẳng hạn thẩm định mã nguồn rất hiệu quả phát hiện các loại lỗi. nhưng lại chi phi rất cao. Chúng ta có thể đánh giá hiệu qua của các kĩ thuật bằng cách so sánh các lỗi được phát hiên và các lỗi còn lại chưa được phát hiện (với giả thiết chúng ta đánh giá được số lượng lỗi còn lại). Tỉ lệ phát hiện = Số lỗi được phát hiện Tổng số lỗi Tổng số lỗi là số lỗi được phát hiện sau giai đoạn kiểm thử bănfg cách sư dụng các kỉ thuật khác, chứ không phái là số lỗi thực tế. Theo kết quả của một số thống kê thực hiện với các kĩ thuật kiểm thử, chúng ta có được sự đánh giá tương đối về tỉ lệ phát hiện lỗi trong Bảng 2.3. Tất nhiên, kết quả này chỉ là các dấu hiệu về hiệu quả của các kĩ thuật kiểm thử và có thể sử dụng để tham khảo. Bởi vì một kĩ thuật hiệu quả không đơn thuân chi là phát hiện các lỗi nói chung mà phải phát hiện các lỗi thường xuyên xuất hiện và các lỗi nghiêm trọng. 2.1.3. Mục tiêu cùa các nhóm kĩ thuật kiểm thử Các kĩ thuật kiêm thử tĩnh không thực thi mã chương trinh có thể được chia Trang 26
33. làm bốn nhóm khác nhau. Nhóm kĩ thuật kiểm thử tĩnh thú nhất gồm các kĩ thuật thẩm định mà nguồn hay thẩm định đặc tã với mục tiêu kiểm tra sự tuân thủ các nguyên tắc lập trinh hay nguyên tắc đặc tã được đặt ra. Hơn nữa, thẩm định mã nguồn hay đặt tả còn giúp phát hiện ra những điểm khó hiểu và dấu hiệu lỗi. Chất lượng của các kĩ thuật này phụ thuộc nhiều vào năng lực của thẩm định viên. Bảng 2.2. Hiệu qua phát hiện lỗi cùa các kĩ thuật kiểm thử Kĩ thuật Thẩm định Phân tích Chứng minh Kiểm thử Kiểm thử Loại lỗi mã nguồn tĩnh sự đúng đắn cấu trúc chức năng Tính trung bình trung bình lớn lớn trung bình toán Lô-gic trung bình trung bình lớn lớn trung bình Xử lí dữ lớn lớn trung bình hạn chế lớn liệu Giao lớn lớn hạn chế lớn trung bình tiếp Định nghĩa dữ trung bình trung bình trung bình hạn chế trung bình liệu Bảng 2.3. Tỉ lệ phát hiện các loại lỗi Kĩ thuật Tỉ lệ phát hiện Thẩm định mã nguồn 0,35-0,90 Phân tích tĩnh 0,20 - 0.40 Chứng minh sự đúng đắn 0,50- 1,00 Kiểm thử cấu trúc 0,20 - 0.70 Kiểm thử chức năng 0.20 - 0.70 Trang 27
34. Nhóm kĩ thuật kiểm thử tĩnh thứ hai gồm các kĩ thuật đánh giá độ lón một sổ lính chát cùa mã nguồn, như số dòng lệnh, số dữ liệu vào/ra, độ phức tạp Mục tiêu cùa các kĩ thuật này nhằm so sánh độ lớn một số tính chất của mã nguồn với các ngưỡng đặt ra trước. Các kĩ thuật được sử dụng phổ biển là các kĩ thuật đánh giá độ phức lạp của McCabe hay của Halstead. - Nhóm kĩ thuật kiểm thử tĩnh thứ ba gồm các kĩ thuật chứng minh sự đúng đắn của chưcmg trình. Mục tiêu của các kĩ thuật này không phải là xác minh mà là chứng tó rằng chương.trình hay thuật toán đúng đắn. Khái niệm đúng đắn phụ thuộc vào đặc tả chương trình. Chứng minh sự đúng đắn là những kĩ thuật phức tạp, thường chỉ được thực hiện đối với các phần mềm đòi hói độ tin cậy cao. - Nhóm kĩ thuật kiểm thử tĩnh thứ tư gồm các kĩ thuật phân tích luồng dữ liệu hay luồng điều khiển của một chương trình nhằm kiểm tra các tính chất có được tuân thủ hay không. Chẳng hạn, các tính chất có thể kiểm tra bởi các kĩ thuật này, như : biến được khai báo nhựng không sử dụng, biến được gán liên tục hai lần mà không sử dụng giữa hai lần gán đó - Nhóm các kĩ thuật kiểm thử chức năng là những kĩ thuật được sử dụng phố biến nhất để kiêm thử phần mềm, bởi vi chúng cho phép trá lời trực tiếp quan tâm cùa kiểm thử viên là “kiểm tra xem phần mềm có thực hiện đúng chức năng cùa nó hay không'’. Mục tiêu của các kĩ thuật kiểm thử này là kiếm thừ tất cả các điều kiện hoạt động cùa phần mềm hay đơn vị phần mềm như nó được đặc tà. - Mục tiêu của các kĩ thuật kiểm thử cấu trúc là bao phủ cấu trúc mã nguồn. Sự bao phủ có thể dựa trên nhiều tiêu chí khác nhau, nhử bao phủ các lệnh, bao phù các rẽ nhánh, bao phủ các điều kiện, bao phủ các lộ trình - Chúng ta có thể nhận thấy rằng mục tiêu của các nhóm kĩ thuật kiểm thử là khác nhau. Việc sử dụng kĩ thuật nào là phụ thuộc vào yêu cầu về kiểm thử đối với phần mềm hay độ tin cậy của phần mềm. Các kĩ thuật kiểm thử này bổ sung lẫn nhau dế phát hiện ra các loại lỗi khác nhau nhàm tạo ra phần mềm có chất lượng tốt nhất có thể. 2.2. Các quy trình phát triển phần mềm Trước khi đề cập chi tiết đến các hoạt động kiểm thử trong quy trình phát triển phần mềm, chúng tôi sẽ nhắc lại một số các quy trình phát triển phần mềm cơ bản cũng như các giai đoạn kiêm thử liên quan. 2.2.1 Quy trình thác nước Quy trình phát triển phần mềm cổ điển nhất được gọi là quỵ trình thác nước Trang 28
35. (waterfall process). Quy trình này gồm dãy nối tiếp các giai đoạn phát triển phần mềm từ. giai đoạn phân tích tính khả thi đến giai đoạn bảo trì. Hình 2.1. Quy trình thác nước Trong quy trình này. hai giai đoạn liền kề nhau có thề trao đổi với nhau. Kết quả (đầu ra) cùa một giai đoạn trước là đầu vào của giai đoạn sau. Khi mới ra đời. quy trình thác nước không cho phép quay lui. Sau này, để mềm dẻo hơn. quy trình cho phép giai đoạn sau có thể quay lại giai đoạn trước. Chúng ta nhận thấv rằng mỗi giai đoạn đều có các hoạt động kiêm thử cần thiết để hợp thức hoá kết quả của giai đoạn đó, trước khi chuyên sang giai đoạn tiếp theo. 2.2.2.Quy trình V Mục đích của quv trình V (V process) là làm rõ các hoạt động kiểm thứ phần mềm ớ mỗi giai đoạn phát triển. Ý tưởng cũa quy trình là kết hợp quy trình thác nước với các hoạt động kiểm thừ và bẻ gãy đường biều điền các giai đoạn phát triển đế nhấn mạnh sự tương úng giữa mỗi giai đoạn xây đựng sản phẩm và sự kiểm thử hay họp thức hoá nó. Quy trình V được minh hoạ trong Hình 2.2 Trang 29
36. Hình 2.2. Quy trình V Trong quy trình V, nhánh đi xuống của hỉnh V” biếu điễn các hoạt động phát triển, trong khi nhánh đi lên biểu điễn các hoạt động kiểm thư được thực hiện đựa trên các kêt quả của các giai đoạn phát triển ở củng một mức trên đường đi xuống. Các mũi tên ngang nét đứt chỉ ra rằng các hoạt động kiêm thử được chuân bị ngay khi giai đoạn xây đựng tương ứng kết thúc. Điều này cho phép kiểm thử viên chuẩn bị phương án kiểm thừ, xây dựng các ca kiểm thử và dữ liệu thử đồng thời với các giai đoạn phát triển. 2.2.3. Quy trình xoắn Quy Irình xoán ồc (spiral proccss) cho phép phái triển phân mềm bởi nhiều chu kì. mồi chu kì lương ứng với một sản phẩm cúa một giai đoạn phát triển phần mềm. Mỗi chu kì đều trải qua bốn bước sau : 1. Xác đinh các mục liêu, các giái pháp và các ràng buộc. 2. Đánh giả các giải pháp, xác định và tìm cách giải quyết các rủi ro. 3. Phát triển và kiếm thử sản phẩm của chu kì này. 4. Lập kế hoạch cho chu kì tiếp theo. Quy trinh xoắn ốc được minh hoạ trong Hình 2.3. Quy trình xoắn ôc nhấn mạnh vào việc xác định và giải quyết các rủi ro tiềm ẩn trong quy trình phát triển. Cho đến chu kì cuối cùng của quy trình, sàn phẩm được hoàn thảnh và các rủi ro sẽ bị loại bỏ. 2.2.4.Quy trình hợp nhất Quy trình hợp nhất (unified process) được phát triển trên sự mở rộng cúa quy trình xoắn ốc nhưng chặt chẽ và hình thức hơn. Quy trình này đặc biệt được sử dụng trong phát triển các hệ thống hướng đối tượng. Quy trình hợp nhất có hai góc nhìn Trang 30
37. khác nhau : góc nhìn quản lí và góc nhìn kĩ thuật. Góc nhìn quản lí quan tâm đến lĩnh vực kinh tế, chiến thuật và con người phát triển đự án. Đưới góc nhìn quản lí. quy trình gồm bốn giai đoạn: - Khởi đầu (inception) : đánh giá tính khả thi của dự án. - Phác thảo(elabpration): phân tích và thiết kế kiến trúc hệ thống. - Xây dựng(construction): thiết kế chi tiết, mã hóa và kiểm thử sản phẩm. - Chuyển giao(transition): chuyển giao sản phẩm cho người sử dụng. Góc nhìn kĩ thuật quan tâm đến công nghệ, kiểm tra chất lượng và phương pháp phát triển. Đưới góc nhìn kĩ thuật, quy trình được chia thành nhiều bước lặp. Mỗi bước lặp tạo ra một nguyên mẫu thực thi được, hệ thống lớn đần theo số bước lặp cho đến khi hoàn thành. Mồi bước lặp gồm các giai đoạn con : đặc tả, phân tích, thiết kế, mã hoá, kiểm thử và cài đặt. Quy trình hợp nhất được minh hoạ trong Hình 2.3. Hình 2.3. Quy trình xoắn ốc 2.2.5. Nhận xét Hiện nay, tồn tại nhiều quy trình phát triển phần mềm khác nhau, mỗi quy trình Trang 31
38. có những điểm mạnh và hạn chế riêng của nó. Vì vậy, tùy theo tính chất và ràng buộc của mỗi dự án mà lựa chọn một hay nhiều quy trình phù hợp để phát triển. Cho dù các quy trình phát triển khác nhau, tuy nhiên các hoạt động kiểm thử điều được tích hợp trong mỗi quy trình phát triển. Mục tiếp theo sẽ trình bày về các hoạt động kiểm thử cơ bản trong quy trình phát triển phần mềm. Góc nhìn quản Góc nhìn kĩ thuật Kết quả lí Bước lặp chuẩn bị Nguyên mẫu thử Khởi đầu Bước lặp thiết kế Nguyên mẫu thiết kế Phác thảo Bước lặp thiết kế Nguyên mẫu thiết kế Bước lặp xây dựng Nguyên mẫu xây dựng Bước lặp xây dựng Nguyên mẫu xây dựng Xây dựng Bước lặp xây dựng Phiên bản bêta Bước lặp chuyển giao Phiên bản bêta Chuyển giao Bước lặp chuyển giao Phiên bản chính thức Hình 2.4. Quy trình hợp nhất 2.3 Các hoạt động kiểm thử trong quy trình phát triển phần mềm Để kiểm thử một sản phẩm phần mềm, chúng ta không chỉ kiểm thử một lần, khi mà nó đã được hoàn thành. Các thành phần của phần mềm điều phải được kiểm thử trước, sau đó trong suốt quá trình tích hợp các thành phần cũng phải được kiểm thử cho đến khi đạt được sản phẩm cuối cùng. Như chúng ta đã biết, có nhiều quy trình phát triển phần mềm được sử dụng. Chúng khác nhau về bản chất , cách tiến hành , số giai đoạn phát triển , tuy nhiên chúng ta có thể thấy chúng có những điểm sau khi hoạt động kiểm thử. Sau giai đoạn phân tích, các dơn vị hay mô-đun nhỏ được phát triển và kiểm thử riêng rẽ. Đó là kiểm thử đơn vị. Các mô-đun này sẽ được tích hợp dần dần trong quá trình phát triển, và chúng lại là các đối tượng cần kiểm thử; đó là kiểm thử tích hợp. Một khi tất cả các mô-đun đã được tích hợp, phần mềm được kiểm thử để hợp thức hóa yêu cầu của người sử dụng; đó là kiểm thử hệ thống. Sau khi đưa vào sử dụng , phần mềm có thể cần phải sửa đổi, khi đó cần phải thực hiện các kiểm thử liên quan đến các đoạn mã mới. Các kiểm thử này nhằm đảm bảo các sửa đổi không ảnh Trang 32
39. hưởng đến các phần còn lại của phần mềm; chúng ta gọi là kiểm thử hồi quy. Trước khi phần mềm được đưa vào sử dụng, phần mềm cần phải được kiểm thử bởi người sử dụng nhằm đánh giá phần mềm so với mong đợi và mục tiêu của người sử dụng. Đó là kiểm thử chấp nhận. 2.3.1. kiểm thử đơn vị • Đơ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. Trang 33
40. 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ử. Trình điều Đơn vị cần kiểm thử Nút trám 1 Nút trám 2 Hình 2.5. Minh họa khái niệm trình điều khiển và nút trám Trang 34
41. Đố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. Kiểm thử tích hợp nên chỉ thực hiện với các đơn vị đã được thẩm định và đã Trang 35
42. đượ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 M0 M1 M2 M3 M4 M5 M6 M7 M8 M9 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 Trang 36
43. 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. M0 M1 M2’ M3’ M4’ M5’ M6’ 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 Trang 37
44. 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 Trang 38
45. 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 liệu hướng dẫn sử dụng hay kịch bản sử dụng Bởi vì kiểm thử hệ thống thường yêu cầu rất lớn về nguồn lực, kiểm thử hệ thống thường được thực hiện bởi nhóm các kiểm thử viên ddoowcj lập. Các kiểm thử viên phải tìm các điểm yếu của phần mềm và như thế, tốt nhất các lập trình viên không tham quan vào việc kiểm thử hệ thống. Kiểm thử hệ thống không chỉ nhằm đánh giá chức năng của hệ thống mà còn đánh giá các tính chất về chất lwuowngj khác , như khả năng sử dụng khả năng tin cậy, hiệu năng hay tính bảo mật Tuy nhiên mỗi loại phần mềm và yêu cầu của phần mềm , các loại kiểm thử hệ thống khác nhau được áp dụng: - Kiểm thử giao diện : các giao diện có phù hợp với các giao diện đã được đặc tả , như màn hình , tệp tin, thông báo ; - Kiểm thử hiệu năng : thời gian tính toán , thời gian trả lời , sử dụng bộ nhớ ; - Kiểm thử độ tin cậy : tần suất lỗi xuất hiện, độ nghiêm trọng của lỗi ; - Kiểm thử cấu hình : cấu hình phần mềm , cấu hình phần cứng, cấu hình giữa phần cứng và phần mềm; - Kiểm thử khả năng chịu tải : khi dung lượng dữ liệu lớn, các xử lí lặp đi lặp lại nhiều, số người sử dụng đồng thời rất lớn ; - Kiểm thử bảo mật : quyeend truy xuất , bảo mật dữ liệu, mã hóa ; - Kiểm thử tính tương thích : chia sẽ chung bộ nhớ , chia sẽ chung dữ liệu, tương thích với các phần mềm khác ; - Kiểm thử khả năng sử dụng : tính dễ sử dụng, yếu tố con người , tài liệu hướng dẫn ; - Kiểm thử cài đặt : sự cài đặt phần mềm , xóa cài đặt , cài đặt lại; - Kiểm thử tài liệu : tài liệu hướng dẫn sử dụng, tài liệu đào tạo, trợ giúp trực tuyến Kiểm thử hệ thống nên được thực hiện trong môi trường như môi trường mà phần mềm sẽ hoạt động, vì đây là giai đoạn kiểm thử trước khi chuyển giao phần mềm cho người sử dụng để thực hiện kiểm thử chấp nhận. Tuy nhiên, điều này không phải Trang 39
46. lúc nào cũng thực hiện được, bởi vì chúng ta không thể có được môi trường sử dụng thực đối với một số phần mềm, như phần mềm điều khiển hay phần mềm giao dịch tài chính Trong trường hợp đó, thông thường chúng ta cần phải mô phỏng môi trường thực hiện để thực hiện kiểm thử. 2.3.4. Kiểm thử hồi quy Quy trình phát triển phần mềm, mà trong đó bao gồm kiểm thử, không dừng lại một khi phần mềm được chuyển giao cho người sử dụng. Bởi vì phần mềm là một trong những loại sản phẩm thay đổi rất nhanh. Người sử dụng luôn có yêu cầu cải tiến phần mềm và bổ sung các chức năng mới. Ngoài ra, các thống kê cho thấy đối với các dự án lớn , hơn 50% các lỗi hoặc sự không tương thích của phần mềm được tìm thấy khi được đưa vào sử dụng . Như thế, sự chỉnh sửa phần mềm sau khi đưa vào sử dụng là cần thiết. Mà chúng ta đã biết, bất kì sự sửa đổi nào cùng có thể dẫn đến các lỗi mới. Nghĩa là phần mềm nhất thiết phải được kiểm thử lại sau khi sửa đổi, giai đoạn kiểm thử này gọi là kiểm thử hồi quy (regression testing). Kiểm thử hồi quy thường tái sử dụng các bộ dữ liệu thử đã sử dụng trong các giai đoạn trước nhằm đảm bảo rằng không có các lỗi mới được đưa vào. Vấn đề đặt ra ở đây là : Các bộ dữ liệu thử nào được tái sinh sử dụng ? Để trả lời câu hỏi này, chúng ta cần phải thực hiện phân tích sự ảnh hưởng của sự sửa đổi. Thông thường, chúng ta cần xác định một cách không hình thức các thành phần bị ảnh hưởng bởi sự sửa đổi bằng cách dựa vào kiến trúc của phần mềm . Đối với các phần mềm đòi hỏi độ tin cậy cao, chúng ta có thể sử dụng các công cụ phân tích luồng dữ liệu hay đồ thị gọi (call graph) để xác đínhự ảnh hưởng. Sau khi đã phân tích sự ảnh , chúng ta có thể : - Thực hiện lại một số kiểm thử đơn vị các thành phần bị sửa đổi: - Thực hiện lại một số kiểm thử tích hợp có kích hoạt các thành phần bị sửa đổi ; - Thực hiện lại một số kiểm thử hệ thống có kích hoạt các chức năng bị sửa đổi; Như vậy, kiểm thử hồi quy không phải là một hoạt động kiểm thử , mà kiểm thử hồi quy có thể áp dụng ở kiểm thử đơn vị, kiểm thử tích hợp và kiểm thử hệ thống. Ngoài ra, chúng ta phải lưu ý rằng , để dễ dàng kiểm thử hồi quy , chúng ta nên lưu trữ lại môi trường kiểm thử , các nút trám , các trình điều khiển và các bộ dữ liệu thử để tái sử dụng. 2.3.5. Kiểm thử chấp nhận Trong các hoạt động kiểm thử đã được trình bày, người sử dụng chỉ đóng vai trò hỗ trợ . Họ chỉ tham gia vào các hoạt động phân tích yêu cầu, thẩm định và lập kế hoạch. Sau khi phần mềm đã trải qua các kiểm thử hệ thống và việc sửa lỗi đã hoàn tất Trang 40
47. , người sử dụng có thể đóng vai trò tích cực hơn trong quy trình kiểm thử. Lập trình viên và kiểm thử viên phải luôn luôn chú ý rằng phần mềm được phát triển nhằm đáp ứng các yêu cầu của người sử dụng , nó chỉ được chấp nhận bởi người sử dụng nếu nó giúp người sử dụng đạt được các mục tiêu của họ. Kiểm thử chấp nhận không nhằm mục đích phát hiện lỗi mà nhằm mục đích cho người sử dụng đánh giá phần mềm so với mong đợi và mục tiêu của họ. Khi phần mềm được phát triển cho một khách hàng cụ thể, kiểm thử chấp nhận cần phải được phát hiện sau khi kiểm thử hệ thống. Kiểm thử chấp nhận phải được lập kế hoạch với các nguồn đầu vào từ khách hàng hay người sử dụng. Các ca kiểm thử chấp nhận được thiết kế dựa trên tài liệu yêu cầu và tài liệu hướng dẫn sử dụng. Các ca kiểm thử hệ thống có thể được tái sử dụng. Phần mềm phải được thực thi trong môi trường thực . Các dữ liệu đầu vào điển hình hợp lệ và không hợp lệ nên được sử dụng và tất cả các hàm quan trọng nên được thực thi . Kiểm thử chấp nhận là một mốc quan trọng đối với người phát triển . Tại thời điểm này, khách hàng sẽ quyết định phần mềm có đạt yêu cầu không. Khách hàng sẽ nghiệm thu và thực hiện các khoản thanh toán cuối cùng cho tổ chức phát triển phần mềm nếu kiểm thử chấp nhận thành công. Kiểm thử chấp nhận phải được chuẩn bị cẩn thận bởi các lập trình viên và kiểm thử viên. Khách hàng sẽ được đón tiếp trong tổ chức phát triển phần mềm . Họ sẽ được cung cấp tài liệu để hổ trợ họ tham gia vào quá trình kiểm thử chấp nhận và đánh giá sản phẩm . Sau khi kiểm thử chấp nhận , khách hàng sẽ chỉ ra các yêu cầu nào thỏa mãn và yêu cầu nào chưa thỏa mãn . Một số yêu cầu có thể bị loại bỏ , chỉnh sửa hay thêm mới do nhu cầu thay đổi. Nếu khách hàng hài lòng về phần mềm , họ sẽ chấp thuận sản phẩm và bước tiếp theo là cài đặt phần mềm tại môi trường của khách hàng . Nếu các điều kiện môi trường phía khách hàng khác với môi trường phát triển, các lập trình viên phải thiết lập phần mềm sao cho có thể tương tác trong môi trường của khách hàng . Có thể kiểm thử lại nhằm đảm bảo phần mềm hoạt động như mong muốn trong môi trường của khách hàng. Nếu phần mềm được phát triển cho thị trường rộng lớn , chứ không phải cho khách hàng cụ thể, thì kiểm thử phần mềm cho mỗi khách hàng là không thực tế . Trong trường hợp này, kiểm thử chấp nhận thường được chia làm hai giai đoạn : kiểm thử anpha và kiểm thử bêta. Kiểm thử anpha được thực hiện trong môi trường phát triển . Một nhóm những người sử dụng tiềm năng và thành viên nhóm phát triển được mời sử dụng phần mềm . Các lập trình viên sẽ quan sát và ghi nhận các vấn đề xảy ra. Kiểm thử bêta gửi phần mềm đến những người sử dụng, họ cài đặt và sử dụng phần Trang 41
48. mềm trong môi trường làm việc thực tế . Người sử dụng sẽ gửi các vấn đề cho tổ chức phát triển và nhóm phát triển chịu trách nhiệm chỉnh sửa các lỗi . 2.4. Kết luân Tronh chương này, chúng ta trước hết đã trình bày cái nhìn tổng quan về các kĩ thuật kiểm thử cũng như các cách phân loại các kĩ thuật kiểm thử . Sau đó, chúng ta nhwcas lại các quy trình phát triển phần mềm cơ bản , đặc biệt trong mỗi quy trình chúng ta đều làm rõ sự hiện diện các hoạt động kiểm thử. Cuối cùng, cho dù các kĩ thuật kiểm thử được sử dụng trong các quy trình phát triển phần mềm khác nhau, tuy nhiên chúng ta đều được sử dụng trong các hoạt động kiểm thử gồm : kiểm thử đơn vị , kiểm thử tích hợp , kiểm thử hệ thống, kiểm thử hồi quy và kiểm thử chấp nhận Câu hỏi và bài tập 1. Nêu các cách phân loại kiểm thử phần mềm phổ biến 2. Phân biệt lớp lỗi được phát hiện bởi các kĩ thuật kiểm thử chức năng và các kĩ thuật kiểm thử cấu trúc 3. Giải thích hoạt động kiểm thử trong quy trình V 4. Sự khác biệt cơ bản giữa hoạt động kiểm thử chấp nhận và các hoạt động kiểm thử khác (đơn vị, tích hợp và hệ thống) là gì? 5. Phân biệt kiểm thử đơn vị, kiểm thử tích hợp và kiểm thử hệ thống 6. Nêu mục đích của kiểm thử hồi quy 7. Tại sao kiểm thử cấu trúc chủ yếu áp dụng cho kiểm thử đong vị? 8. Nêu khái niệm trình điều khiển và nút trám 9. Kiểm thử tích hợp nhằm phát hiện loại lỗi nào? 10. Thảo luận các ưu điểm và nhược điểm của chiến lược từ trên xuống chiến lược từ dưới lên của kiểm thử tích hợp 11. Phân biệt kiểm thử anpha và kiểm thử bêta 12. Cho cây cấu trúc quan hệ các mô-đun trong Hình 2.8 hãy chỉ ra thứ tự tích hợp các mô-đun theo chiến lược từ trên xuống và chiến lược từ dưới lên M0 M1 M2 M3 M4 M5 M6 M7 M8 M9 M1 M1 M1 M1 M14 Trang 42
49. CHƯƠNG 3 KIỂM THỬ CHỨC NĂNG - KIỂM THỬ CẤU TRÚC Kiểm thử chức năng xem phần mềm như một chức năng ánh xạ các giá trị đầu vào đến các giá trị đầu ra. Trong ngữ cảnh như thế, phần mềm được xem như là “hộp đen” (Hình 3.1). Vì vậy, kiểm thử chức năng còn được gọi là kiểm thư hộp đen. Nội dung của hộp đen không được biết, tuy nhiên chức năng của hộp đen được mô tả rõ ràng qua các đầu vào và đầu ra. Đầu vào Đầu ra Hình 3.1. Phần mềm được xem là hộp đen Kiểm thử chức năng chỉ dựa vào đặc tả phần mềm để tạo ra các kiểm thử. Vì vậy, kiểm thử chức năng có hai ưu điểm nổi bật: - Các ca kiểm thử độc lập với việc phần mềm được cài đặt như thế nào, nghĩa là cấu trúc bên trong của phần mềm. Như thế khi cài đặt phần mềm thay đổi, các ca kiểm thử vẫn được sử dụng. - Các ca kiểm thử có thể được thiết kế trước khi cài đặt phần mềm. Ca kiểm thử được tạo ra ngay khi có đặc tả yêu cầu. Ngoài ra, kiểm thử chức năng có các đặc điểm khác: - Hiệu quả trong việc tìm lỗi, đặt biệt phù hợp tìm các lỗi về thiết kế, nghĩa là lỗi do những người thiết kế, người đặc tả tạo ra. - Chi phí thấp so với kĩ thuật kiểm thử cấu trúc trong việc thiết kế các ca kiểm thử. - Dễ dàng áp dụng và áp dụng phổ biến, khi chỉ dựa trên đặc tả yêu cầu cà có thể được áp dụng cho tất cả các hoạt động kiểm thử (đơn vị tích hợp và hệ thống). Trong chương này, chúng ta sẽ tìm hiểu các kĩ thuật kiểm thử chức năng cơ bản, gồm kiểm thử giá trị biên, kiểm thử giá trị đặc biệt, kiểm thử lớp tương đương và kiểm thử dựa trên bảng quyết định. Kiểm thử cấu trúc (structural testing) là kỹ thuật cơ bản về xây dựng các ca kiểm thử. Khác với kiểm thử chức năng, kiểm thử cấu trúc dựa trên cấu trúc bên trong của chương trình để tạo ra kiểm thử. Chương trình được xem là trong suốt đối với Trang 43
50. kiểm thử viên, vì vậy, kiểm thử cấu trúc còn được gọi là kiểm thử hộp trắng hoặc kiểm thử hộp gương. Kiểm thử chức năng (hay kiểm thử hộp đen) tạo ra ca kiểm thử dựa trên đặc tả, như thế không thể đảm bảo được mọi phần trong chương trình được thực thi bởi các ca kiểm thử. Giả sử nếu có một phần nào đó không được thực thi bởi các ca kiểm thử nào, các lỗi (nếu có) trong phần đó sẽ không bị phát hiện. Trong khi kiểm thử cấu trúc có thể đảm bảo các thành phần (câu lệnh, rẽ nhánh, lộ trình ) trong chương trình được thực thi. Tuy nhiên, kiểm thử cấu trúc cũng không đảm bảo được rằng thực thi các thành phần trong chương trình sẽ phát hiện được tất cả các lỗi. Bởi vì thực thi một câu lệnh lỗi có thể không làm lỗi xuất hiện, do có thể lỗi không xuất hiện khi thực thi câu lệnh với một số dữ liệu vào nào đó hoặc câu lệnh lỗi đó khi thực thi không dẫn đến sự thất bại của chương trình. Kiểm thử cấu trúc nhằm mục tiêu bao phủ (coverage), nghĩa là thực thi, các thành phần trong chương trình, như bao phủ lệnh, bao phủ rẽ nhánh, bao phủ lộ trình Các tiêu chí bao phủ này nhằm nâng cao độ tin cậy của chương trình cần được kiểm thử. Kiểm thử cấu trúc có đặc điểm: - Hiệu quả trong việc phát hiện các lỗi về cài đặt, nghĩa là các lỗi của lập trình viên. - Chỉ được thực hiện khi biết cấu trúc bên trong của chương trình, nghĩa là thiết kế hay mã nguồn. - Có chi phí cao (do dựa trên cấu trúc chi tiết của chương trình), vì vậy chủ yếu chỉ áp dụng cho kiểm thử đơn vị và ngoài ra có thể áp dụng cho kiểm thử tích hợp. Phần lớn các kỹ thuật kiểm thử cấu trúc là các kỹ thuật kiểm thử dựa trên đồ thị, nghĩa là biểu diễn cấu trúc chương trình bởi đồ thị, sau đó tạo ra dữ liệu thử nhằm bao phủ các thành phần của đồ thị. Do đó, trong chương này, trước hết chúng tôi nhắc lại một số khái niệm cơ bản về đồ thị ứng dụng trong kiểm thử cấu trúc, sau đó chúng tôi trình bày một số kỹ thuật kiểm thử cấu trúc cơ bản dựa trên đồ thị và kỹ thuật kiểm thử đột biến. 3.1. Kiểm thử giá trị biên Kiểm thử giá trị biên là một trong những kĩ thuật kiểm thử chức năng được áp dụng rộng rãi và hiệu quả. Kĩ thuật này tạo ra các ca kiểm thử bởi việc phân tích miễn dữ liệu vào. Kinh nghiệm của những người phát triển phần mềm cho thấy rằng các lỗi Trang 44
51. thường do chương trình không được đặc tả các hành vi đối với các giá trị biên (giá trị rất lớn, giá trị không hay âm đối với chỉ số, chuỗi kí tự rỗng, hay các dữ liệu không hợp lệ). Các giá trị biên được xác định dựa vào miền giá trị của các biến đầu vào. Kĩ thuật kiểm thử giá trị biên xác định các giá trị để kiểm thử cho một biến đầu vào x gồm (Hình 3.2): - giá trị nhỏ hơn giá trị nhỏ nhất (min-), - giá trị nhỏ nhất (min), - giá trị lớn hơn giá trị nhỏ nhất (min+), - giá trị bình thường (nom), - giá trị nhỏ hơn giá trị lớn nhất (max-), - giá trị lớn nhất (max), - giá trị lớn hơn giá trị lớn nhất (max+). x min- min min+ nom max- max max+ Hình 3.2. Minh họa các giá trị dữ liệu thử x b a c d y Hình 3.3. Miền vào của chương trình có hai biến vào Với giả thuyết lỗi đơn, kiểm thử giá trị biên cho chương trình f với hai biến đầu vào gồm các dữ liệu thử sau: { , , , , , , , , , , , , } Các dữ liệu thử này được minh họa trong Hình 3.4. Trang 45
52. x b a y c d Hình 3.4. Dữ liệu thử (với giả thuyết lỗi đơn) cho chương trình có hai biến vào Số dữ liệu thử có thể được xác định qua số biến vào: nếu chương trình có n biến vào, chỉ một biến nhận các giá trị min-, min, min+, max-, max, max+, các biến còn lại nhận giá trị nom, và một trường hợp tất cả các biến đều nhận giá trị nom. Như vậy đối với chương trình có n biến vào, kiểm thử giá trị biên (với giả thuyết lỗi đơn) có 6n+1 dữ liệu thử. Nếu bỏ qua giả thuyết lỗi đơn, chúng ta quan tâm đến điều gì xảy ra khi nhiều hơn một biến đầu vào đạt đến giá trị biên. Trong trường hợp này, chúng ta gọi kiểm thử gái biên trong trường hợp xấu nhất. Đối với mỗi biến đầu vào, chúng ta bắt đầu với tập hợp bảy giá trị min-, min, min+,nom, max-, max, max+. Chúng ta sử dụng tích Đề-các của các tập hợp này đẻ tạo ra các dữ liệu thử. Các dữ liệu thử đối với chương trình có hai biến đầu vào được minh họa trong Hình 3.5. Chúng ta có thể nhận thấy rằng các dữ liệu thử có tính đến giả thuyết lỗi đơn chỉ là tập con của các dữ liệu thử bỏ qua giả thuyết lỗi đơn. Điều đó cũng cho thấy rằng kiểm thử trong trường hợp xấu nhất yêu cầu chi phí cao hơn: kiểm thử trong trường hợp xấu nhất cho một chương trình có n biến đầu và tạo ra 7푛 dữ liệu thử, so với 6n + 1 dữ liệu thử khi tính đến giả thuyết lỗi đơn. Kiểm thử giá trị biên là kĩ thuật đơn giản, dễ áp dụng và hiệu quả trong việc phát hiện lỗi. Tuy nhiên, kiểm thử giá trị biên không hiệu quả đối với các biến kiểu logic, bỏi vì biến chỉ nhận hai giá trị đúng hoặc sai. x b a y c d Hình 3.5. Dữ liệu thử (bỏ qua giả thuyết lỗi đơn) cho chương trình có hai biến vào Trang 46