Bài giảng Công nghệ phần mềm - Chương 6: Kiểm thử phần mềm

PHẦN 4: KIỂM THỬ CHƯƠNG 6: KIỂM THỬ PHẦN MỀM Mục tiêu Nội dung Mục tiêu T h ự c h i ệ n c h ư ơ n g t r ì n h đ ể t ì m l ỗ i Khám phá các lỗi tiềm ẩn Tạo các kiểm thử với khả năng cao tìm kiếm ra các lỗi tiềm ẩn Nâng cao độ tin cậy của phần mềm Phần mềm, Mô hình phần mềm, danh sách các yêu cầu Kết quả tiếp nhận Phần mềm đã được khẳng định về chất lượng. Kết quả chuyển giao NỘI DUNG: 1. Giới thiệu 2. Các kỹ thuật kiểm thử 3. Các chiến lược kiểm thử 4. Gỡ lỗi 1 . G i ớ i t h i ệ u 4. Gỡ lỗi 2 . C á c k ỹ t h u ậ t k i ể m t h ử 3. Các chiến lược kiểm thử Nội dung 1. Giới thiệu 1.1 Mở đầu 1.2 Nguyên tắc 1.3 Khái niệm các kiểm thử (test cases) 1.1 Mở đầu ƒ Lỗi có thể xảy ra trong tất cả các giai đoạn: Xác định, phát triển, khai thác. Ngăn chặn sai sót từ đầu là việc làm đáng quan tâm. 9 Không để lỗi sai lọt vào chương trình (đơn thể, chương trình con) 9 Không để lỗi sai lọt vào hệ thống chương trình. 9 Không để lỗi sai lọt vào giai đoạn khai thác ƒ Kiểm thử là quá trình tìm lỗi; là đánh giá cuối cùng về giai đoạn phát triển PM trước khi khai thác. ƒ Kiểm thử là một họat động rất khó được chấp nhận, đặc biệt là không phải là thành phần trong nhóm xây dựng phần mềm ƒ Kiểm thử nên hướng về yêu cầu khách hàng. ƒ Nên lập kế hoạch trước một thời gian dài. ƒ Áp dụng nguyên lý Pareto: 80% lỗi có nguyên nhân từ 20% lỗi của các modun nhỏ hơn. ƒ Quá trình kiểm thử tiến hành từ các thành phần nhỏ đến các thành phần lớn hơn. ƒ Kiểm thử theo kiểu vét cạn là không khả thi. ƒ Nên có thành phần thứ 3 độc lập với người dùng và bộ phận phát triển PM 1.2 Nguyên tắc: 1.3 Khái niệm các kiểm thử (test cases): ƒ Dữ liệu Input. ƒ Thao tác kiểm thử ƒ Dữ liệu output của chương trình ƒ Các kiểm thử cho White-Box: Dựa vào cấu trúc điều khiển của CT. ƒ Các kiểm thử cho Black-Box: Dựa vào yêu cầu chức năng phần mềm. 2. Các kỹ thuật kiểm thử 2.1 Kiểm thử hộp trắng 2.2 Kiểm thử hộp đen 2.1 Kiểm thử hộp trắng (White -box testing) Mục tiêu: Sử dụng các cấu trúc điều khiển để tạo ra các kiểm thử với mục tiêu : ‘ Bảo đảm mọi đường thực hiện độc lập trong một modun được thực hiện ít nhất 1 lần. ‘ Tất cả các điều kiện logic đều được thực hiện. ‘ Tất cả vòng lặp đều được thực hiện tại biên. ‘ Kiểm tra tất cả cấu trúc dữ liệu nhằm đảm bảo tính hợp lệ. Kiểm thử Hộp trắng 2 . 1 . 1 K i ể m t h ử đ ư ờ n g c ơ b ả n ( B a s i s P a t h T e s t i n g ) 2.1.4 Kiểm thử điều kiện (Condition Testing) 2 . 1 . 2 K i ể m t h ử l u ồ n g d ữ l i ệ u ( D a t a F l o w T e s t i n g ) 2.1.3 Kiểm thử vòng lặp (Loop Testing) 2.1.1 Kiểm thử đường độc lập cơ bản a. Đồ thị dòng chảy b. Các đường độc lập cơ bản c. Các cách tính khác của độ phức tạp chu trình d. Các bước thực hiện để tạo kiểm thử a. Đồ thị dòng chảy ‘ Đồ thị dòng chảy xây dựng từ lưu đồ thuật giải hay mã CT ‘ Mỗi nút hình tròn biểu diễn một hay nhiều câu lệnh. (Mỗi điều kiện là phân nhánh hoặc hợp nhánh phải đưa thành node) ‘ Cạnh có hướng mô tả đường thực hiện. Tuần tự Rẽ nhánh Lựa chọn while do ...while Ví dụ: 5 1 2 3 46 7 8 9 10 11 1 2 3 4 5 6 7 8 9 10 11 Lưu đồ Đồ thị dòng chảy Ví dụ: 1 2 34 6 5 7 8 9 while (x == 0) { if (y ==0) z = 0; else if (k == 0) z = 1; else x = 1; } Đồ thị dòng chảy (DT1) Ghi chú: ‘ Phải phân rã tất cả các điều kiện phức thành các điều kiện đơn. ‘ Mỗi node mô tả một điều kiện đơn gọi là node vị ngữ (Predicate) ab x y Sơ đồ dòng chảy if (a&&b) y; else x; a b y x 1 1 0 0 Phân tích if (a) { if(b) y; else x; } else x; Lưu đồ !(a&&b) ≡ !a || !b while (a || b) x; Phân rã Lưu đồ Sơ đồ dòng chảy b. Các đường độc lập cơ bản ‘Đường độc lập cơ bản là các đường từ node bắt đầu đến node kết thúc sao cho đường đang xét ít nhất đi qua 1 cạnh chưa được duyệt qua bởi các đường liệt kê trước đó. ‘Độ phức tạp chu trình được định nghĩa là tổng số các đường độc lập cơ bản. ‘Gọi V(G) là độ phức tạp chu trình, V(G) có thể tính được bằng công thức sau đây: V(G) = P +1; với P là số node vị ngữ Ví dụ: xem đồ thị dòng chảy: Liệt kê: ‘ Đường 1: 1->9 ‘ Đường 2: 1->2->3->8->1... ‘ Đường 3: 1->2->4->5->7->8->1... ‘ Đường 4: 1->2->4->6->7->8->1... Tổng số đường: V(G) = P+1 = 3 + 1 = 4 Các node phân nhánh: 2, 4, 1 1 2 34 6 5 7 8 9 c. Các cách tính khác của độ phức tạp chu trình ‘ Các cạnh của đồ thị dòng chảy sẽ tạo ra biên của nhiều vùng (Region) của đồ thị.Vùng ở ngoài đồ thị cũng được xem là một vùng. 1 2 3 4 5 6 7 8 9 10 11 ‘ Độ phức tạp chu trình còn có thể tính theo các cách khác sau đây: ™ V(G)= E – N + 2; ( trong đó: E số cạnh, N số node ) ™ V(G) = Số vùng trong lưu đồ. Node Cạnh Vùng Ví dụ: xem đồ thị dòng chảy: Tổng số đường: Cách 1: V(G) = P+1 = 3 + 1 = 4 Các node phân nhánh: 6, 3, 1 Cách 2: V(G)= E – N + 2 = 13 – 11+2 = 4 Cách 3: V(G) = Số vùng trong lưu đồ = 4 1 2 3 4 5 6 7 8 9 10 11 v 1 v 2 εΛ V4 d. Các bước thực hiện để tạo kiểm thử ‘ Thiết lập một kiểm thử cho mỗi đường độc lập cơ bản. ‘ Dựa vào thuật giải để tìm ra một dữ liệu input, sau đó tính dữ liệu output xem có đáp ứng mong đợi của thuật giải Ví dụ: Xét đồ thị dòng chảy sau 1 3 2 4 5 6 7 8 9 11 10 12 c>0 a<b+c a=c a=b b=c a2 = b2 + c2 Các node phân nhánh: 1, 2, 4, 6, 8, 9. - Tổng số đường: V(G) = P + 1 = 6 + 1= 7 - Liệt kê các đường độc lập cơ bản: ‘ Đường 1: 1->3->12 ‘ Đường 2: 1->2->3->12 ‘ Đường 3: 1->2->4->5->12 ‘ Đường 4: 1->2->4->6->7->12 ‘ Đường 5: 1->2->4->6->8->7->12 ‘ Đường 6: 1->2->4->6->8->9->10->12 ‘ Đường 7: 1->2->4->6->8->9->11->12 Thiết lập các kiểm thử ‘ Kiểm thử cho đường 1: 1->3->12 – Input: a = 4, b = 2, c= 0 – Output: Lỗi ‘ Kiểm thử cho đường 2: 1->2->3->12 – Input: a = 17, b = 5, c= 4 – Output: Lỗi ‘ Kiểm thử cho đường 3: 1->2->4->5->12 – Input: a = 6, b = 6, c= 6 ‘Output: Đều (Tg) ‘ . . . 2.1.2 Kiểm thử điều kiện ƒ Phương pháp tạo các kiểm thử dựa vào các điều kiện logic của chương trình. ƒ Một điều kiện đơn giản là một điều kiện Boolean (true/falsse) hay điều kiện quan hệ (, =). ƒ Một điều kiện phức tạp bao gồm các điều kiện đơn giản nối kết bằng các toán tử quan hệ (&&, ||, !,. . .) Các chiến lược kiểm thử điều kiện bao gồm: ƒ Kiểm nhánh: Phân rã các điều kiện tổng hợp thành các điều kiện đơn giản và thực hiện kiểm thử trên các nhánh đơn giản này ít nhất 1 lần. ƒ Kiểm lĩnh vực: Các kiểm thử dựa vào điều kiện quan hệ và tóan tử quan hệ. ƒ Kiểm nhánh và quan hệ: Thực hiện trên các điều kiện tổng hợp. Tất cả các tổ hợp có thể có từ các điều kiện đơn giản đều được kiểm thử 2.1.3 Kiểm thử luồng dữ liệu Phương pháp tạo các kiểm thử dựa vào vị trí khai báo và qua trình sử dụng biến trong chương trình, gọi là chuỗi khai báo sử dụng của biến. Mỗi chuỗi cần được duyệt qua và kiểm thử ít nhất 1 lần. Phương pháp này không đảm bảo mọi nhánh thực hiện chương trình nhưng thích hợp để kiểm tra độ chính xác của dữ liệu khi thực hiện. 2.1.4 Kiểm thử vòng lặp Xét các loại vòng lặp: ƒ Đơn giản ƒ lồng nhau a. Vòng lặp đơn giản: với n là số lần lặp tối đa. Thực hiện các bước: ƒ Bỏ qua không thực hiện ƒ Thực hiện vòng lặp 1 lần ƒ Thực hiện vòng lặp 2 lần ƒ Thực hiện vòng lặp m lần (m < n) ƒ Thực hiện vòng lặp tại biên lặp trên, qua n-1, n, n+1 lần thực hiện. b. Vòng lặp lồng nhau: Độ phức tạp của các vòng lặp lông nhau có thể rất lớn, có thể không kiểm thử hiệu quả được. Hướng giải quyết sẽ là: ƒ Bắt đầu từ vòng lặp bên trong nhất, tất cả các vòng lặp ngoài đặt biến điều khiển ở mức thấp nhất. ƒ Thực hiện kiểm thử vòng lặp đơn giản cho vòng lặp trong nhất này. ƒ Thực hiện tiếp tục dần ra ngoài cho đến hết vòng lặp. 2.2 Kiểm thử hộp đen (black- box testing) Kiểm thử hộp đen tập trung vào các chức năng hệ thống (không quan tâm đến cáu trúc bên trong), tạo ra các kiểm thử với mục tiêu : ‘ Kiểm định độ hợp lý của các chức năng. ‘ Phân lớp đầu vào để kiểm thử ‘ Phân biên cho dữ liệu được truy xuất để kiểm thử ‘ Kiểm định lưu lượng và mật độ dữ liệu hệ thống. Các lỗi thường được phát hiện: ‘ Chức năng sai hay thiếu. ‘ Lỗi giao diện ‘ Lỗi trong cấu trúc dữ liệuhay truy xuất dữ liệu ngoài ‘ Lỗi khởi tạo ‘ . . . Kiểm thử Hộp đen . . . 2 . 2 . 1 P h â n c h i a t ư ơ n g đ ư ơ n g ( E q u i v a l e n c e P a r t i t i o n i n g ) 2.2.2 Phân tích giá trị biên (Boundary Value Analyis) 2.2.1. Phân chia tương đương ƒ Phân các điều kiện đầu vào thành các lớp tương đương. ƒ Chỉ cần kiểm thử trên mỗi lớp tương đương 2.2.2. Phân tích giá trị biên ƒ Các lỗi xảy ra thường nằm tại các biên của các khoảng dữ liệu đầu vào. ƒ Dữ liệu đầu vào là khoảng số thì kiểm thử thực hiện tại các giá trị gần biên dưới, biên trên 3. Các chiến lược kiểm thử ‘ Mở đầu ‘ Kiểm thử đơn vị ‘ Kiểm thử tích hợp ‘ Kiểm thử chức năng ‘ Kiểm thử hệ thống 3.1 Mở đầu ƒ Quá trình phát triển PM đi từ trên xuống, trong khi đó chiến lược kiểm thử PM đi từ dưới lên. Bắt đầu từ các modun tạo mã đến quá trình tích hợp theo thiết kế, xác minh và khẳng định tính hợp lệ của PM với các yêu cầu đặt ra. ƒ Xác minh (Verification) là quá trình khẳng định chương trình xây dựng đúng theo thiết kế. ƒ Hợp lệ (Validation) là quá trình khẳng định PM xây dựng thỏa mãn mọi yêu cầu đặt ra. Phân tích toàn bộ hệ thống Kiểm thử toàn bộ hệ thống Phân tích Yêu cầu Kiểm thử hợp lệ Thiết kế phần mềm Kiểm thử tích hợp Mã hóa Kiểm thử đơn vị Quan hệ giữa các giai đọan phát triển và kiểm thử PM Các mức kiểm thử K i ể m t h ử đ ơ n v ị Kiểm thử hệ thống K i ể m t h ử t í c h h ợ p Kiểm thử hợp lệ T ừ t r ê n x u ố n g Từ dưới lên 3.2 Kiểm thử đơn vị: ( Unit testing) ƒ Tiến hành cho mỗi đơn vị nhỏ nhất của PM, đó là các modun mã nguồn đã được dịch thành công ƒ Thường dùng phương pháp White-Box ƒ Có thể tiến hành cùng lúc nhiều modun. ƒ Kiểm thử theo trình tự: giao diện, cấu trúc dữ liệu địa phương, điều kiện biên, đường thực hiện, ... Modun -------------- -------------- -------------- -------------- -------------- -------------- -Giao diện -cấu trúc dữ liệu địa phương Điều kiện biên -Đường thực hiện, -... Các kiểm thử ƒ Mỗi modun mã nguồn không phải là chương trình hoàn chỉnh và đôi khi phải gọi các modun chưa được kiểm nghiệm khác. Do đó phải xây dựng các driver hoặc stub. ƒ Driver (chương trình điều khiển) là chương trình chính có nhiệm vụ nhận dữ liệu kiểm thử, chuyến dữ liệu đó xuống cho modun để kiểm tra và in ra kết quả kiểm tra tương ứng. ƒ Stub thay thế các modun được gọi là modun đang kiểm tra 3.3 Kiểm thử tích hợp (Integration testing) ƒ Kiểm thử trong quá trình tích hợp là cần thiết vì: 9Dữ liệu có thể mất qua giao diện. 9Modun này có thể làm sai lạc các modun khác 9 . . . ƒ Kiểm thử tích hợp là kỹ thuật thực hiện một cách có hệ thống lắp ghép cấu trúc chương trình, đồng thời thực hiện các kiểm thử phát hiện lỗi giao diện. ƒ Có 2 hướng tích hợp chính: 9Từ trên xuống 9Từ dưới lên. 3.3.1 Tích hợp từ trên xuống (Top-Down Integration) ƒ Là một cách làm tăng tiến để xây dựng kiến trúc chương trình. ƒ Các modun được tích hợp xuống theo cấu trúc điều khiển. ƒ Có thể đi theo chiều sâu (defth first) hay chiều rộng (breadth first). ƒ Đi theo chiều sâu: nhánh 9 Tại mỗi nhánh, các modun con lần lượt ghép nối, những nhánh chưa được ghép nối hay modun thấp hơn sẽ được thay bằng các modun giả lập. Sau khi thực hiện xong tại 1 nhánh, các modun giả lập dần được thay đổi ở mức thấp và ở các nhánh khác ƒ Đi theo chiều rộng: 9 Tích hợp theo từng mức. Tất các các modun tại một mức sẽ dần được tích hợp. Các modun ơ mức thấp thay bằng modun giả lập. Quá trình tích hợp bao gồm các bước: 1. Modun chính được dùng làm điều khiển kiểm thử, các modun giả lập nối trực tiếp vào modun này 2. Tùy vào cách tích hợp, từng modun giả lập sẽ được thay bằng modun thật. 3. Kiểm thử được thực hiện với từng modun thay thế 4. Khi kết thúc một kiểm thử, một modun khác lại được thay thế bằng modun thật. 5. Kiểm thử lại có thể được thực hiện nhằm bảo đảm quá trình tích hợp modun mới không làm ảnh hưởng kết quả kiểm thử cũ. Tích hợp từ trên xuống (theo chiều sâu) M1 M2 M3 M4 M5 M6 M7 M8 M9 3.3.2 Tích hợp từ dưới lên (Bottom-Up Integration) Bắt đầu từ các modun ở mức thấp nhất, sau đó các modun được tích hợp dần lên. Quá trình tích hợp gồm các bước: ƒ Các modun thấp được tích hợp thành các cụm (cluster) thực hiện một phần chức năng cụ thể của PM. ƒ Một driver được viết để kết hợp các kiểm thử đầu vào và đầu ra ƒ Toàn bộ cụm được kiểm tra ƒ Các driver bị loại bỏ, các cụm được kết hợp tiếp lên để hình thành cấu trúc chương trình. Quá trình kiểm thử này dễ dàng thực hiện hơn, nhưng lại tốn nhiều sức để viết các driver Tích hợp từ dưới lên M0 Ma Mb D1 D2 D3 C l u s t e r 1 Cluster 2 3.3.3 Kiểm thử lại (Regression Testing) ƒ Khi một modun mới được thêm vào, phần mềm sẽ thay đổi.Những luồng dữ liệu mới, những điều khiển mới. . .được thêm vào có thể thay đổi những gì thực hiện trước đó. ƒ Kiểm thử lại là hoạt động nhằm đảm bảo những thay đổi do trong quá trình tích hợp . ƒ Kiểm thử lại chỉ lấy một phần của bộ kiểm thử trước đó để thực hiện, chẳng hạn một số mẫu chức năng hệ thống, các kiểm thử trên các chức năng có thể bị thay đổi,... 3.3 Kiểm thử hợp lệ (chức năng) ƒ Kiểm thử các chức năng phần mềm có phù hợp với các yêu cầu chức năng trong hồ sơ phân tích yêu cầu. ƒ Áp dụng phương pháp Black-Box. ƒ Kiểm thử hợp lệ bao gồm: 9Xem xét lại cấu hình phần mềm 9Kiểm thử Alpha 9Kiểm thử Beta 1. Xem xét cấu hình phần mềm ‘ Nhằm đảm bảo các chức năng phần mềm được phát triển một cách đúng đắn và phù hợp với các đặc tả phân tích, thiết kế phần mềm Kiểm thử hợp lệ Phê chuẩn quản lý Xét duyệt cấu hình Phần mềm tích hợp Các yêu cầu Tư liệu người sử dụng Tư liệu người sử dụng Tư liệu thiết kê Các tư liệu kiểm thử Phần mềm hợp lệ C ấ u h ì n h p h ù h ợ p Phát hành Phần mềm 2. Kiểm thử Alpha ‘ Kiểm thử Alpha được khách hàng tiến hành tại cơ quan của nhà phát triển phần mềm. Phần mềm được khách hàng sử dụng qua sự sắp đặt tự nhiên của nhà phát triển, lỗi phần mềm và các vấn đề sử dụng sẽ được ghi lại. ‘ Kiểm thử Alpha được tiến hành trong một môi trường có kiểm soát 3. Kiểm thử Beta ‘ Tiến hành ngoài nơi sản xuất phần mềm. Khách hàng sẽ thực hiện tại một hay nhiều cơ quan của khách hàng và nhà phát triển không có mặt. ‘ Do đó, kiểm thử beta là việc thực hiện phần mềm trong môi trường mà nhà phát triển không kiểm sóat được. ‘ Khách hàng sẽ ghi lại tất cả các lỗi của phần mềm, các vấn đề sử dụng và chuyển lại cho nhà phát triển giải quyết. 3.4 Kiểm thử hệ thống (System testing) ƒ Phần mềm là một yếu tố của một hệ thống dựa trên máy tính, chảng hạn phần cứng, cơ sở dữ liệu, tài liệu, . . .Cuối cùng phần mềm sẽ được tổ hợp với các yếu tố hệ thống khác để tạo hệ thống dựa trên máy tính, nên sẽ phải tiến hành các kiểm thử trên hệ thống. ƒ Ta thường dùng các kiểu kiểm thử hệ thống sau: 9 Kiểm tra tính phục hồi dữ liệu (Recovery Testing). 9 Kiểm tra tính bảo mật (Security Testing). 9 Kiểm tra hiệu suất (Performance Testing). 4. Gỡ lỗi ‘ Gỡ lỗi không phải là kiểm thử, nhưng bao giờ cũng xuất hiện như là một hệ quả của kiểm thử. ‘ Tiến trình gỡ lỗi bắt đầu với thực hiện một trường hợp kiểm thử, thực hiện các kỹ thuật kiểm thử, các chiên lược kiểm thử, cho ra kết quả kiểm thử. ‘ Tiến trình gỡ lỗi bao giờ cũng có một trong 2 kết quả logic: ‘ Nguyên nhân tìm ra: Sửa chữa và loại bỏ lỗi. ‘ Nguyên nhân không tìm ra: Người thực hiện đặt giả thiết các nguyên nhân, thiết kế trường hợp kiểm thử, tiến hành thực hiện kiểm thử, tiến hành lặp lại các bước gỡ lỗi, . . . Gỡ lỗiXác định nguyên nhân Sửa chữa Nguyên nhân hoài nghi Trường hợp kiểm thử Kiểm thử phụ Kết quả Thực hiện trường hợp kiểm thử Bài tập Đề 1: Cho đoan trình: if(a||b) x; else y; - Tạo sơ đồ dòng chảy. - Thiết lập các kiểm thủ cho các đươnf độc lập cơ bản Đề 2: Cho đoạn trình: while (a&&b) x; - Tạo sơ đồ dòng chảy tương ứng - Thiết lập các kiểm thử cho các đường độc lập cơ bản