Đề tài Tìm hiểu các kỹ thuật kiểm thử phần mềm

Tr­êng ®¹i häc hïng v­¬ng Khoa to¸n - c«ng nghÖ --------------d ß c------------ ĐỀ TÀI TÌM HIỂU CÁC KỸ THUẬT KIỂM THỬ PHẦN MỀM Giáo viên hướng dẫn: Lương Mạnh Bá Sinh Viên Thực Hiện: 1. Nguyễn Ngọc Hải (Trưởng Nhóm) 2. Nguyễn Xuân Chiến 3. Hạ Ngọc Xuân Sinh Viên Lớp K6 Tin Phú Thọ 2011 Mục lục Phần I: Giới Thiệu Về Kiểm Thử Phần Mềm 1.1Khái niệm kiểm thử phần mềm Kiểm thử phần mềm là một quá trình liên tục, xuyên suốt mọi giai đoạn phát triển phần mềm để đảm bảo rằng phần mềm thoả mãn các yêu cầu thiết kế và các yêu cầu đó đáp ứng các nhu cầu của người dùng. Các kỹ thuật kiểm thử phần mềm đã, đang được nghiên cứu, và việc kiểm thử phần mềm đã trở thành qui trình bắt buộc trong các dự án phát triển phần mềm trên thế giới. Kiểm thử phần mềm là khâu mấu chốt để đảm bảo chất lượng phần mềm, là đánh giá cuối cùng về đặc tả thiết kế và mã hóa. Kiểm thử phần mềm là quá trình chạy thử một ứng dụng để phát hiện lỗi và xem nó có thỏa mãn các yêu cầu đã đặt ra trong quá trình phát triển phần mềm, những người phát triển phần mềm và các kỹ sư kiểm thử cùng làm việc để phát hiện lỗi và đảm bảo chất lượng sản phẩm. Một sản phẩm phần mềm được phân phối phải có đầy đủ các chức năng yêu cầu và tương thích với phần cứng của khách hàng. Chi phí của kiểm thử chiếm 40% tổng công sức phát triển >=30% tổng thời gian phát triển Kiểm thử tốt sẽ: Giảm chi phí phát triển Tăng độ tin cậy của sản phẩm phần mềm Thiết kế trường hợp kiểm thử Chuẩn bị dữ liệu kiểm thử Chạy trương trình với dữ kiệu kiểm thử Trường hợp kiểm thử dữ liệu kiểm thử Kết quả kiểm thử Báo cáo kiểm thử So sánh kết quả với các trường hợp kiểm thử Sơ đồ kiểm thử 1.2 Mục tiêu của kiểm thử Các nguyên tắc được xem như mục tiêu kiểm thử là: Kiểm thử là một quá trình thực thi chương trình với mục đích tìm lỗi. Một trường hợp kiểm thử tốt là trường hợp kiểm thử mà có khả năng cao việc tìm thấy các lỗi chưa từng được phát hiện. Một kiểm thử thành công là kiểm thử mà phát hiện lỗi chưa từng được phát hiện. 1.3 Những khó khăn của kiểm thử Nâng cao chất lượng phần mềm nhưng không vượt quá chất lượng thiết kế. chỉ phát hiện các lỗi tiềm tàng và sửa chúng Phát hiện lỗi bị hạn chế do thủ công là chính Dễ bị ảnh hưởng tâm lý khi kiểm thủ. Khó đảm bảo tính đầy đủ của kiểm thử 1.4 Các phương pháp kiểm thử Người ta phân biệt 2 phương pháp kiểm thử: Kiểm thử trên bàn hay kiểm thử tĩnh và Kiểm thử trên máy hay kiểm thử động. Kiểm thử tĩnh thường được tiến hành trước nhằm tạo ra kịch bản cho kiểm thử động. 1.5 Các kỹ thuật thiết kế trường hợp kiểm thử Kiểm thử hộp đen – Black box testing Kiểm thử hộp trắng – White box testing Kiểm thử hộp xám – Gray box testing 1.6 Phương pháp thử các mô đun Để kiểm thử một phần mềm, người ta tiến hành kiểm thử theo trình tự sau: Kiểm thử môđun Kiểm thử tích hợp Kiểm thử hệ thống Kiểm thử chấp nhận (b Testing) PHẦN II GIỚI THIỆU CHI TIẾT VỀ KIỂM THỬ Có thể sử dụng một số kỹ thuật trong quá trình kiểm thử nhằm tăng hiệu quả của họat động này. Mc Gregor mô tả các kỹ thuật kiểm thử như những công cụ được thiết kế để đảm bảo rằng tất cả các khía cạnh của sản phẩm đều được khảo sát. Mặt khác, các kỹ thuật kiểm thử là những công cụ để dễ dàng đạt được hiệu quả kiểm thử. 2.1 Nguyên tắc cơ bản kiểm thử phần mềm. Trong lúc kiểm thử, công nghệ phần mềm phát sinh một chuỗi các trường hợp kiểm thử được sử dụng để “tách từng phần” phần mềm. Kiểm thử là một bước trong qui trình phần mềm mà có thể được xem xét bởi đội ngũ phát triển bằng cách phá vỡ thay vì xây dựng. Các kỹ sư phần mềm chính là những người xây dựng và việc kiểm thử yêu cầu họ vượt qua các khái niệm cho trước về độ chính xác và giải quyết mâu thuẫn khi các lỗi được xác định. 2.2 Các phương pháp kiểm thử Có 2 phương pháp kiểm thử chính là: Kiểm thử tĩnh và Kiểm thử động. 2.2.1 Thử tĩnhKhái niệmPhương pháp thử phần mềm thông qua việc sử dụng giấy, bút trên bàn để kiểm tra logic, lần từng chi tiết ngay sau khi lập trình xongChủ yếu kiểm tra mã, các tài liệu đặc tảCác phương pháp thử tĩnhThanh traDuyệt* Thanh traKhái niệmPhương pháp kiểm tra ngang hàng sản phẩm phần mềm thực hiện bởi những người nghiên cứu riêng lẻ để tìm ra những lỗi có thể bằng một tiến trình chuẩn cho trướcMột cuộc thanh tra bao gồm:Đặc tả phần mềmKế hoạch thanh traSản phẩm phần mềmĐiều phối viênThanh tra viênTác giả phần mềmTiến trình thanh tra:1. Lên kế hoạch2. Gặp gỡ trước3. Chuẩn bị4. Gặp gỡ thanh tra5. Gia công lại6. Bám sátChú ý: các khâu 3,4,5 có thể thực hiện lặp lại* DuyệtKhái niệm:Là một phương pháp kiểm tra ngang hàng với một người thiết kế hướng nhóm phát triển đến các hoạt động chú ý của quá trình sản xuất phần mềm, tham gia đặt câu hỏi và chú thích cho các lỗi có thể có.Khác biệt với thanh tra:Cấu trúc mởKhả năng gợi ý định hướng thay đổi phần mềmTiến trình duyệt:1. Đánh giá đầu vào2. Chuẩn bị quản lí3. Lập kế hoạch4. Gặp gỡ trước5. Chuẩn bị riêng6. Duyệt7. Gia công/ bám sát8. Kết thúc, đánh giá 2.2.2 Kiểm thử động – Dynamic testing Dùng máy chạy chương trình để điều tra trạng thái từng động tác của chương trình. 9 bước của trình tự kiểm thử bằng máy: (1) Thiết kế trường hợp thử theo thử trên bàn (2) Trường hợp thử phải có cả kết quả kỳ vọng sẽ thu được (3) Dịch chương trình nguồn và tạo môđun tải để thực hiện (4) Khi trường hợp thử có xử lý tệp vào-ra, phải làm trước trên bàn việc xác định miền của các tệp (5) Nhập dữ liệu đã thiết kế cho trường hợp kiểm thử (6) Điều chỉnh môi trường thực hiện môđun tải (tạo thủ tục đưa các tệp truy cập tệp vào chương trình) (7) Thực hiện môđun tải và ghi nhận kết quả (8) Xác nhận kết quả với kết quả kỳ vọng (9) Lặp lại thao tác (5)-(8) 2.3 Các kỹ thuật thiết kế trường hợp kiểm thử 2.3.1 Kiểm thử hộp đen – Black box testing Kiểm thử hộp đen (Black Box testing) là kỹ thuật thiết kế trường hợp thử dựa trên đặc tả bề ngoài của chương trình. Người kiểm thử chỉ quan tâm đến nhiệm vụ mà mô đun phải đảm nhận, đầu vào cho mô đun và kết quả xử lý - đầu ra. Kiểm thử hộp đen lại chia nhỏ ra nhiều kỹ thuật: - Phân đoạn tương đương - Phân tích giá trị biên - Đoán lỗi và một số kỹ thuật khác Hình 1: Black Box testing *Phân Đoạn Tương Đương Đây là kỹ thuật chia vùng thông tin nhập vào của chương trình thành các lớp thông tin/dữ liệu. Lớp tương đương biểu diễn thành một tập các giá trị hợp lệ và không hợp lệ. Nhưng lớp dữ liệu tương đương này có thể được xác định theo những cách sau: 1. Nếu điều kiện đầu vào xác định một khoảng giá trị [a,b], thì phân hoạch thành một lớp tương đương hợp lệ và một lớp tương đương không hợp lệ. Chẳng hạn, nếu đầu vào x nằm trong khoảng [0,100], lớp hợp lệ là 0 100. 2. Nếu điều kiện đầu vào yêu cầu một giá trị xác định, phân hoạch thành một lớp tương đương hợp lệ và hai lớp tương đương không hợp lệ. Chẳng hạn, nếu đầu vào x=5, thì lớp hợp lệ là x= 5, các lớp không hợp lệ là x 5. 3. Nếu điều kiện đầu vào xác định một phần tử của tập hợp, thì phân hoạch thành một lớp tương đương hợp lệ và một lớp tương đương không hợp lệ. 4. Nếu điều kiện đầu vào là Boolean, thì phân hoạch thành một lớp tương đương hợp lệ và một lớp tương đương không hợp lệ tương ứng với hai trạng thái true và false. Một mẫu cho việc liệt kê các lớp tương đương Điều kiện bên ngoài Các lớp tương đương hợp lệ Các lớp tương đương không hợp lệ Ngoài ra, một nguyên tắc thứ năm được bổ sung là sử dụng khả năng phán đoán, kinh nghiệm và trực giác của người kiểm thử. Các trường hợp kiểm thử Bước thứ hai trong phương pháp phân đoạn tương đương là thiết kế các trường hợp kiểm thử dựa trên sự ước lượng của các lớp tương đương cho miền đầu vào. Tiến trình này được thực hiện như sau: 1. Gán một giá trị duy nhất cho mỗi lớp tương đương. 2. Đến khi tất cả các lớp tương đương hợp lệ được phủ bởi các trường hợp kiểm thử thì viết một trường hợp kiểm thử mới phủ nhiều nhất có thể các lớp tương đương hợp lệ chưa được phủ. 3. Đến khi tất cả các lớp tương đương không hợp lệ được phủ bởi các trường hợp kiểm thử thì hãy viết các trường hợp kiểm thử mới sao cho mỗi trường hợp kiểm thử mới chỉ phủ duy nhất một lớp tương đương không hợp lệ chưa được phủ. *Phân tích giá trị biên – Boundary Value Analysis Kinh nghiệm cho thấy các ca kiểm thử mà khảo sát tỷ mỷ các điều kiện biên có tỷ lệ phần trăm cao hơn các ca kiểm thử khác. Các điều kiện biên là những điều kiện mà các tình huống ngay tại, trên và dưới các cạnh của các lớp tương đương đầu vào và các lớp tương đương đầu ra. Phân tích các giá trị biên là phương pháp thiết kế ca kiểm thử bổ sung thêm cho phân lớp tương đương, nhưng khác với phân lớp tương đương ở 2 khía cạnh: Phân tích giá trị biên không lựa chọn phần tử bất kỳ nào trong 1 lớp tương đương là điển hình, mà nó yêu cầu là 1 hay nhiều phần tử được lựa chọn như vậy mà mỗi cạnh của lớp tương đương đó chính là đối tượng kiểm tra. Ngoài việc chỉ tập trung chú ý vào các trạng thái đầu vào (không gian đầu vào), các ca kiểm thử cũng nhận được bằng việc xem xét không gian kết quả (các lớp tương đương đầu ra). Phân tích giá trị biên yêu cầu óc sáng tạo và lượng chuyên môn hóa nhất định và nó là một quá trình mang tính kinh nghiệm rất cao. Tuy nhiên, có một số quy tắc chung như sau: Nếu 1 trạng thái đầu vào định rõ giới hạn của các giá trị, hãy viết các ca kiểm thử cho các giá trị cuối của giới hạn, và các ca kiểm thử đầu vào không hợp lệ cho các trường hợp vừa ra ngoài phạm vi. Nếu 1 trạng thái đầu vào định rõ số lượng giá trị, hãy viết các ca kiểm thử cho con số lớn nhất và nhỏ nhất của các giá trị và một giá trị trên, một giá trị dưới những giá trị này. Sử dụng quy tắc 1 cho mỗi trạng thái đầu vào. Ví dụ, nếu 1 chương trình tính toán sự khấu trừ FICA hàng tháng và nếu mức tối thiểu là 0.00$, và tối đa là 1,165.25$, hãy viết các ca kiểm thử mà khấu trừ 0.00$ và 1,165.25, khấu trừ âm và khấu trừ lớn hơn 1,165.25$. Chú ý là việc xem xét giới hạn của không gian kết quả là quan trọng vì không phải lúc nào các biên của miền đầu vào cũng mô tả cùng một tập sự kiện như biên của giới hạn đầu ra (ví dụ, xét chương trình con tính SIN). Ngoài ra, không phải lúc nào cũng có thể tạo ra 1 kết quả bên ngoài giới hạn đầu ra, nhưng tuy nhiên rất đáng để xem xét tiềm ẩn đó. Sử dụng nguyên tắc 2 cho mỗi trạng thái đầu ra. Nếu đầu vào hay đầu ra của 1 chương trình là tập được sắp thứ tự ( ví dụ,1 file tuần tự hay 1 danh sách định tuyến hay 1 bảng) tập trung chú ý vào các phần tử đầu tiên và cuối cùng của tập hợp. Sử dụng sự khéo léo của bạn để tìm các điều kiện biên. * Kỹ Thuật Cause-Effect Graphing Ta thấy rằng 2 kỹ thuật trên dữ liệu đầu vào đã được phân loại để phân tích. Tuy nhiên kỹ thuật sắp trình bày dưới đây cho phép xác định ra các trường hợp kiểm thử hiểu quả nhất ngay cả trong lúc dữ liệu đầu vào là khó phân loài thành các lớp như trong 2 kỹ thuật trên. Kỹ thuật này gồm có 4 bước như sau : Đặc tả được chia thành các phần có thể thực hiện được. Điều này là cần thiết bởi vì đồ thị nguyên nhân – kết quả trở nên khó sử dụng khi được sử dụng trên những đặc tả lớn. Nguyên nhân và kết quả trong các đặc tả được nhận biết. Một nguyên nhân là một trạng thái đầu vào nhất định hay một lớp tương đương của các trạng thái đầu vào. Một kết quả là một trạng thái đầu ra hay 1 sự biến đổi hệ thống (kết quả còn lại mà 1 đầu vào có trạng thái của 1 chương trình hay hệ thống). Bạn nhận biết nguyên nhân và kết quả bằng việc đọc từng từ của đặc tả và gạch chân các từ hoặc cụm từ mô tả nguyên nhân và kết quả. Khi được nhận biết, mỗi nguyên nhân và kết quả được gán cho 1 số duy nhất. Xây dựng đồ thị nguyên nhân – kết quả bằng cách phát triển và biến đổi nội dung ngữ nghĩa của đặc tả thành đồ thị Boolean nối giữa nguyên nhân và kết quả. Đồ thị được được diễn giải với các ràng buộc mô tả những sự kết hợp của nguyên nhân và/hoặc kết quả là không thể vì các ràng buộc ngữ nghĩa và môi trường. Bằng việc dò theo các điều kiện trạng thái trong đồ thị một cách cẩn thận, bạn chuyển đổi đồ thị thành một bảng quyết định mục vào giới hạn. Mỗi cột trong bảng mô tả một ca kiểm thử. Các cột trong bảng quyết định được chuyển thành các ca kiểm thử. Ký hiệu cơ bản cho đồ thị được chỉ ra trong hình 1. Tưởng tượng mỗi nút có giá trị là 0 hoặc 1; 0 mô tả trạng thái vắng mặt và 1 mô tả trạng thái có mặt. Hàm đồng nhất nói là nếu a là 1 thì b là 1; ngược lại, b là 0. Hàm not là nói nếu a là 1 thì b là 0; ngược lại thì b là 1. Hàm or khẳng định rằng nếu a hoặc b hoặc c là 1, thì d là 1; ngược lại d là 0. Hàm and khẳng định nếu cả a và b là 1 thì c là 1; ngược lại c là 0. Hai hàm or và and được phép có số lượng đầu vào bất kỳ. Hình 1 Các ký hiệu đồ thị nguyên nhân – kết quả cơ bản Trong hầu hết các chương trình, sự kết hợp nào đó của một số nguyên nhân là không thể bởi vì lý do ngữ nghĩa và môi trường (ví dụ, một ký tự không thể đồng thời vừa là “A” vừa là “B”). khi đó, ta sử dụng ký hiệu trong Hình 2 Ràng buộc E (Exclude – loại trừ) khẳng định rằng tối đa, chỉ có hoặc a hoặc b có thể là 1 (a và b không thể đồng thời là 1). Ràng buộc I (Include – bao hàm) khẳng định ít nhất một trong a, b hoặc c phải luôn luôn là 1 (a, b hoặc c không thể đồng thời là 0). Ràng buộc O (Only – chỉ một) khẳng định một và chỉ một hoặc a hoặc b phải là 1. Ràng buộc R (Request – yêu cầu) khẳng định rằng khi a là 1, thì b phải là 1 (ví dụ, không thể có trường hợp a là 1, còn b là 0). Ràng buộc M (Mask – mặt nạ) khẳng định là nếu kết quả a là 1, kết quả b sẽ bắt buộc phải là 0. Hình 2 Các ký hiệu ràng buộc Bước tiếp theo là tạo bảng quyết định mục vào giới hạn – limited-entry decision table. Tương tự với các bảng quyết định, thì nguyên nhân chính là các điều kiện và kết quả chính là các hành động. Quy trình được sử dụng là như sau: Chọn một kết quả để là trạng thái có mặt (1). Lần ngược trở lại đồ thị, tìm tất cả những sự kết hợp của các nguyên nhân (đối tượng cho các rằng buộc) mà sẽ thiết lập kết quả này thành 1. Tạo một cột trong bảng quyết định cho mỗi sự kết hợp nguyên nhân. Với mỗi sự kết hợp, hãy quy định trạng thái của tất cả các kết quả khác và đặt chúng vào mỗi cột. Trong khi biểu diễn bước 2, cần quan tâm các vấn đề sau: Khi lần ngược trở lại qua một nút or mà đầu ra của nó là 1, không bao giờ thiết lập nhiều hơn 1 đầu vào cho nút or là 1 một cách đồng thời. Điều này được gọi là path sensitizing – làm nhạy đường đi. Mục tiêu của nó là để ngăn chặn dò lỗi thất bại vì một nguyên nhân che đi một nguyên nhân khác. Khi lần ngược trở lại qua một nút and mà đầu ra của nó là 0, dĩ nhiên, phải liệt kê tất cả các sự kết hợp đầu vào dẫn tới đầu ra 0. Tuy nhiên, nếu bạn đang khảo sát trạng thái mà 1 đầu ra là 0 và một hay nhiều đầu ra khác là 1, thì không nhất thiết phải liệt kê tất cả các điều kiện mà dưới điều kiện đó các đầu vào khác có thể là 1. Khi lần ngược trở lại qua một nút and mà đầu ra của nó là là 0, chỉ cần liệt kê 1 điều kiện trong đó tất cả đầu vào bằng 0. (Nếu nút and ở chính giữa của đồ thị như vậy thì tất cả các đầu vào của nó xuất phát từ các nút trung gian khác, có thể có quá nhiều trạng thái mà trong trạng thái đó tất cả các đầu vào của nó bằng 0.) Hình 3 Những xem xét được sử dụng khi dò theo đồ thị Nếu x=1, không quan tâm về trường hợp a=b=1 (sự xem xét thứ 1) Nếu x=0, liệt kê tất cả các trường hợp trong đó a=b=0. Nếu x =1, liệt kê tất cả các trường hợp trong đó a=b=c=1. Nếu x=0, bao gồm chỉ 1 trường hợp mà a=b=c=0 (sự xem xét 3). Đối với các trạng thái mà abc là 001, 010, 100, 011, 101 và 110 , bao gồm chỉ 1 trường hợp mỗi trạng thái (sự xem xét 2). Những sự xem xét này có thể xuất hiện thất thường, nhưng chúng có một mục đích rất quan trọng: để giảm bớt các kết quả được kết hợp của đồ thị. Chúng liệt kê các trường hợp mà hướng về các ca kiểm thử ít có lợi. Nếu các ca kiểm thử ít có lợi không được liệt kê, một đồ thị nguyên nhân – kết quả lớn sẽ tạo ra một số lượng ca kiểm thử cực kỳ lớn. Nếu số lượng các ca kiểm thử trên thực tế là quá lớn, bạn sẽ chọn ra 1 tập con nào đó, nhưng không đảm bảo là các ca kiểm thử ít có lợi sẽ là những ca kiểm thử được liệt kê. Do đó, tốt hơn hết là liệt kê chúng trong suốt quá trình phân tích của đồ thị. * Đoán lỗi Một kỹ thuật thiết kế trường hợp kiểm thử khác là error guessing – đoán lỗi. Tester được đưa cho 1 chương trình đặc biệt, họ phỏng đoán, cả bằng trực giác và kinh nghiệm, các loại lỗi có thể và sau đó viết các ca kiểm thử để đưa ra các lỗi đó. Thật khó để đưa ra một quy trình cho kỹ thuật đoán lỗi vì nó là một quy trình có tính trực giác cao và không thể dự đoán trước. Ý tưởng cơ bản là liệt kê một danh sách các lỗi có thể hay các trường hợp dễ xảy ra lỗi và sau đó viết các ca kiểm thử dựa trên danh sách đó. Một ý tưởng khác để xác định các ca kiểm thử có liên đới với các giả định mà lập trình viên có thể đã thực hiện khi đọc đặc tả (tức là, những thứ bị bỏ sót khỏi đặc tả, hoặc là do tình cờ, hoặc là vì người viết có cảm giác những đặc tả đó là rõ ràng). Nói cách khác, bạn liệt kê những trường hợp đặc biệt đó mà có thể đã bị bỏ sót khi chương trình được thiết kế. 2.3.2 Kiểm thử hộp trắng – White box testing Kiểm thử hộp trắng là kiểm tra cấu trúc và logic phần mềm theo mục tiêu(Trong trường hợp này yêu cầu người kiểm thử phải biết ngôn ngữ lập trình) Kiểm tra trạng thái của chương trình tại nhiều điểm của chương trình * Kiểm thử đường diễn tiến của chương trình Khái niêm: Là việc thiết kế các trường hợp kiểm thử trên từng câu lệnh trong chương trình được sẽ được thực hiện ít nhất 1 lần không quan tâm đến ảnh hưởng lên các đường quyết định. Mỗi nút của đồ thị được biểu diễn một lệnh hay một dãy lệnh liên tiếp của chương trình. Các bước tiến hành: Dùng tài liệu thiết kế hay mã nguồn để vẽ thuật toán của chương trình hay hàm Xác định đồ thị V(G) Từ đồ thị xác định tập đường độc lập tuyến tính lẫn nhau Xây dựng trường hợp kiểm thử dựa trên tập đường xác định ở trên *Kiểm Định Cấu Trúc Điều Kiển a. Kiểm thử các biểu thức điều kiện Kiểm thử biểu thức điều kiện là phương pháp kiểm thử trên những điều kiện logic của hàm hay module. Một điều kiện đơn giản là một biến boolean hoặc là một biểu thức quan hệ: X hay Not X một điều kiện logic đơn giản. Biểu thức quan hệ thường có dạng : E1 E2 E1, E2 là các biểu thức số học và phép toán quan hệ là một trong các phép toán sau : hay >=. Một điều kiện kết hợp của 2 hay nhiều điều kiện đơn giản, các phép toán boolean : OR ( | |, AND (&) and NOT (!) Các loại lỗi của điều kiện bao gồm Lỗi trong các thao tác luận lý ( lỗi tồn tại một biểu thức không đúng, thiếu hoặc thừa các thao tác luận lý Lỗi do giá trị của biến luận lý Lỗi do dấu ngoặc Lỗi do phép toán quan hệ Lỗi trong biểu thức toán học Mục đích của kiểm thử cấu trúc điều kiển là phát hiện không chỉ lỗi trong điều kiện mà còn những lỗi khác trong chương trình. Nếu một tập kiểm thử cho một chương trình P là hiệu quả cho việc phát hiện lỗi trong điều kiện của P,thì bộ kiểm thử đò cũng có thể phát hiện các lỗi khác trong P. E1 E2 Ba trường hợp kiểm thử được yêu cầu để kiểm tra là giá trị E1 lớn hơn, nhỏ hơn và bằng giá trị của E2. Nếu là không đúng và E1, E2 là đúng thì 3 loại kiểm thử trên có đảm bảo có thể xác định được lỗi trong phép toán quan hệ. Để phát hiện lỗi trong E1và E2 thì các trường hợp kiểm thử E1 lớn hơn, nhỏ hơn E2 có thể phát hiện ra được lỗi. Một biểu thức có n biến, thì có 2n khả năng kiểm thử xãy ra khi (n>0) b. Kiểm Thử luồng Dữ liệu (DFT) Phương pháp kiểm thử luồng dữ liệu chọn lựa một số đường diễn tiến của chương trình dựa vào việc cấp phát, định nghĩa, và sư dụng những biến trong chương trình. Để hình dung ra cách tiếp cận này ta giả sử rằng mỗi câu lệnh của chương trình được gán một số duy nhất và rằng mỗi hàm khong được thay đổi thông số của nó và biến toàn cục. DEF(S) = { X | lệnh S chứa định nghĩa X } USE(S) = { X | lệnh S chứa một lệnh/biểu thức sủ dụng X } Nếu S là câu lệnh if hay loop, thì tập DEF của S là rỗng và USE là tập dựa trên điều kiện của câu lệnh S. Định nghĩa 1 biến X tại câu lênh S được cho là vẫn còn sống tại câu lênh S’ nếu như tồn tại một đường từ câu lệnh S đến câu lệnh S’ không chứa bất kỳ định nghĩa nào của X. Định nghĩa 2 Một chuỗi dùng của biến X ( gọi là DU của X) ký hiệu [X, S, S’] là định nghĩa của X trong câu lệnh S vẫn sống trong câu lênh S’. Phương pháp kiểm thử luồng dữ liệu yêu cầu rằng tất cả các chuỗi DU đều được kiểm thử ít nhất một lần. Có thể thấy rằng bộ kiểm thử cho luồng dữ liệu có thể không bao trùm tất cả các nhánh của chương trình. Tuy nhiên nêu môt nhánh đảm bảo được sẽ được phát hiện bỏi phương pháp kiểm thử này. Trong một số hiếm trường hợp như là cấu trúc lệnh if-then trong phần then không có định nghĩa thêm một biến nào và phần else không tồn tại. Trong tình huông này thì nhánh else của câu lênh ì trên không cần thiết phải bảo hộ bởi phương pháp này. DFT rất hũư ích cho các loài kiểm thử một chương trình có nhiều lệnh if và lệnh lặp lồng nhau nhiều cấp. Ví Dụ Hình 1 Một Thủ Tục Với Lệnh Điều Kiện Và Lệnh Lặp Phức Tạpproc x B1; do while C1 if C2 then if C4 then B4; else B5 endif; else if C3 then B2 else B3 endif; endif enddo B6 End proc Để xây dựng các trường hợp kiểmthử DFT cho thủ tục trên, chúng ta cần phải biết định nghĩa và sử dụng biến ở mỗi điều kiện hoặc một khối trong thủ tục này. Giả sử biến X được định nghĩa trong câu lệnh cuối của khối lệnh B2, B3, B4 và B5. và biến X được sử dụng ở đầu của các khối B2, B3, B4, B5 và B6. Kiểm thử DU yêu cầu đường thực thi ngắn nhất từ Bi, 0< i <= 5 đến Bj 1<j<=6.( thật sự thì trong trường hợp này các trường hợp kiểm thử cũng có khả năng phát hiện bất kỳ việc dùng biến X trong các điều kiện C1, C2, C3 và C4) mặc dù có đến 25 chuổi DU nhưng chỉ cần 5 là đủ để bao hàm các trường hợp khác. *. Kiểm Thử Vòng Lặp Vòng lặp là một trong những nền tảng cho rất nhiều các thuật toán được cài đặc trong các phần mềm. tuy nhiên cho đến lúc này chúng ta vẫn còn ít chú ý đến việc xây dựng các trương hợp để kiểm thử. Kiểm thử vòng lặp tập trung vào tính chất của cấu trúc vòng lặp. Có 4 cầu trúc vòng lặp như sau: vòng lặp đơn giản, vòng lặp móc nối, vòng lặp tạo thành tổ, và vòng lặp không cầu trúc Hình 2 Các Cấu Trúc Lặp vòng lặp đơn giản vòng lặp tạo thành tổ vòng lặp móc nối vòng lặp không cầu trúc Vòng Lặp Đơn Tập hợp tiếp theo là các trường hợp kiểm thử cho vòng lặp đơn, với n là maximum số lần lặp. Bỏ tính toàn vẹn của vòng lặp Chỉ cần một lần duyệt xuyên qua cả vòng lặp Hai lần duyệt xuyên qua cả vòng lặp m lần duyệt xuyên qua cả vòng lặp n-1, n, n+1 lần duyệt xuyên qua cả vòng lặp Vòng Lặp Tạo Tổ Nếu như chúng ta mở rộng phương pháp kiểm thử cho vòng lặp đơn thì số lượng trường hợp kiểm thử sẽ tăng rất nhiều. Sau đây là một cách là giảm sồ lượng trường hợp kiểm thử : Bắt đầu tại vòng lặp con trong cùng. Thiết lập tất cả các vòng lặp khác là giá trị minimum. Kiểm soát vòng lặp ở trong cùng trong khi giữ các vòng lặp bên ngoài lặp lại với giá trị là minimum thông số ảnh hưởng nhau ( thông số đó có thể là biến lặp). Thêm môt số trường hợp ngoài phạm vi của biến lặp và một số giá trị đặc biệt. Thực hiên như bước trên và tiến ra ngoài dần Thực hiện tiếp cho đến khi tất cả các vòng lặp được kiểm thử hết. Vòng Lặp Móc Nối Đồi vói kiểu này có thể kiểm thử bằng cách như với vòng lặp đơn ở trên nếu các biền lặp độc lập với nhau. Tuy nhiên nếu 2 vòng lặp là móc nối và biến lặp của vòng lặp thứ nhất được sử dụng như là biến khởi tạo cho vòng lặp 2 thì 2 vòng lặp này không còn độc lặp nữa, Phương pháp dùng cho vòng lặp tạo tổ sẽ được sử dụng ở đây. Vòng Lặp Không Có Cấu Trúc Khi nào gặp các cầu trúc lặp như vầy thì nên thiết kế lại. Việc kiểm thử rất phức tạp. * Độ phức tạp lặp (Cyclomatic Complexity) Độ phức tạp lặp là 1 số đo phần mềm, cung cấp 1 đơn vị đo định lượng về độ phức tạp lô gic của CT. Trong ngữ cảnh áp dụng kiểm thử theo lộ trình, giá trị này sẽ cung cấp số lượng các lộ trình (path) độc lập trong 1 chương trình và đó được coi như là cận trên của số lượng test phải tiến hành để đảm bảo mọi lệnh đều được thực hiện ít nhất 1 lần. - Lộ trình độc lập? là 1 phần của chương trình bao gồm ít nhất một tập lệnh hay 1 điều khiển mới. Đồ thị chương trình trên có 4 lộ trình độc lập: 1-11; 1-2-3-4-5-10-1-11; 1-2-3-6-8-9-10-1-11; 1-2-3-6-7-9-10-1-11 Có 3 cách tính độ phức tạp lặp ký hiệu V(G): V(G) = E – N +2, với E là số cung, N là số nút của G V(G) = số vùng (region) V(G) = P +1, với P là số lượng nút Predicat (nút giả định, không có thật 2.3.3 Kiểm thử hộp xám – Gray box testing Kiểm thử hộp xám đòi hỏi phải có sự truy cập tới cấu trúc dữ liệu và giải thuật bên trong cho những mục đích thiết kế các ca kiểm thử, nhưng là kiểm thử ở mức người sử dụng hay mức hộp đen. Việc thao tác tới dữ liệu đầu vào và định dạng dữ liệu đầu ra là không rõ ràng, giống như một chiếc “hộp xám”, bởi vì đầu vào và đầu ra rõ ràng là ở bên ngoài “hộp đen” mà chúng ta vẫn gọi về hệ thống được kiểm tra. Sự khác biệt này đặc biệt quan trọng khi quản lý kiểm thử tích hợp – Intergartion testing giữa 2 modun mã lệnh được viết bởi hai chuyên viên thiết kế khác nhau, trong đó chỉ giao diện là được đưa ra để kiểm thử. Kiểm thử hộp xám có thể cũng bao gồm cả thiết kế đối chiếu để quyết định, ví dụ, giá trị biên hay thông báo lỗi. 2.4 Phương pháp thử các mô đun 2.4.1 Kiểm thử mô đun Được tiến hành một cách độc lập từng mô đun theo các kỹ thuật trên. Khi các mô đun được kiểm thử xong, kiểm thử tích hợp được tiến hành. 2.4.2 Kiểm thử tích hợp – Intergration Test Kiểm thử tích hợp với mục đích là kiểm tra giao diện và sự liên tác giữa các mô đun. Do vậy, các mô đun đã được kiểm thử xong coi như không có lỗi ở mức mô đun. Việc truy nhập ở đây là ở mức mô đun và nhằm phát hiện lỗi giao diện khi các mô đun truy nhập (gọi) tới nhau. * Kiểm tra top-down Phương pháp kiểm tra top-down cần một mã ngoài, được hiểu như là một bộ khung để gắn các chức năng gốc, các modul, và các phần khác của ứng dụng. Bộ khung này thường bắt đầu với ngôn ngữ điều khiển công việc và logic chính của ứng dụng. Logic chính được kiểm tra và lập khung theo các hệ thống phân rã. Đầu tiên chỉ có các thủ tục thiết yếu và các logic điều khiển được kiểm tra. Khi các module thiết yếu nhất đã được kiểm tra và chạy tốt thì mã của các modul ít quan trọng hơn sẽ được gắn vào khung và tiếp tục kiểm tra. Về lý thuyết thì, top-down sẽ tìm thấy các lỗi thiết kế sớm hơn trong kiểm tra thao tác (testing process) hơn các khuynh hướng khác. Phương pháp này ít hiệu quả trong việc cải thiện chất lượng của các phần mềm chuyển giao vì bản chất tương tác của kiểm tra. Kiểm tra top-down dễ dàng hỗ trợ giao diện người dùng và thiết kế màn hình. Trong các ứng dụng tương tác, thường là bộ điều khiển màn hình được kiểm tra đầu tiên. Người dùng có thể kiểm tra sự điều khiển thông qua màn hình với các phát triển tạo mẫu. Ưu điểm và nhược điểm: Ưu điểm của kiểm thử trên xuốngPhát hiện sớm các lỗi thiết kếCó phiên bản hoạt động sớmNhược điểm của kiểm thử trên xuốngKhó có thể mô phỏng được các chức năng của mô đun cấp thấp phức tạp Không kiểm thử đầy đủ các chức năng Trên thực tế người ta thường tìm cách phối hợp hai chiến lược này, gọi là sandwich testing * Kiểm tra bottom-up Nguyên tắc của bottom-up là kiểm tra mọi thay đổi tại module có thể ảnh hưởng tới chức năng của nó. Trong kiểm tra bottom-up, toàn bộ khối là đơn vị để đánh giá. Tất cả các module được mã hoá và kiểm tra riêng rẽ. Mức 4 Mức 3 Mức 2 Mức 1 Các trường hợp kiểm tra: các trường hợp kiểm tra là dữ liệu vào được tạo để thể hiện từng khối và toàn bộ hệ thống thoả mãn tất cả các yêu cầu thiết kế. Mỗi trường hợp kiểm tra nên được phát triển để kiểm tra nghiệm các đòi hỏi thiết kế đặc trưng, thiết kế chức năng, hoặc mã đã được thoả mãn. Hơn nữa các trường hợp kiểm tra cần dự đoán các output. Mỗi đơn nguyên của ứng dụng (Ví dụ: module, subroutine, program, utility,...) phải được kiểm tra với ít nhất hai trường hợp kiểm tra: một trường hợp chạy tốt và một trường hợp không chạy. Trong trường hợp chạy sai hệ phải đưa được thông báo, quay lại (rollback) được trạng thái ban đầu của giao dịch. Để chắc chắn rằng các trường hợp được toàn diện nhất, người ta thường dùng ma trận. Chúng được dùng cho: Kiểm tra đơn khối để định nhánh logic, điều kiện logic, các phần dữ liệu hoặc biên dữ liệu để kiểm tra trên cơ sở đặc tả chương trình. Kiểm tra tổ hợp để định ra yêu cầu về dữ liệu và quan hệ trong số các tương tác. Kiểm tra hệ thống để xác định yêu cầu về người dùng và hệ thống từ các yêu cầu chức năng và các yêu cầu chấp nhận. Phối hợp các kiểm tra trong một chiến lược: mục đích của các nhà kiểm tra là tìm ra sự cân bằng của các chiến lược cho phép họ chứng minh được ứng dụng chạy tốt mà tối thiểu hoá chi phí máy tính và nhân lực. Sử dụng duy nhất một chiến lược là rất nguy hiểm. Không có cái nào là duy nhất đúng. Nếu chỉ có white-box thì tài nguyên nhân lực và máy là rất tốn kém, nếu chỉ có black-box các vấn đề logic đặc trưng có thể chưa được khám phá. Ưu điểm và nhược điểm Kiểm thử dưới lên có một số ưu điểm:Tránh phải tạo các stub phức tạp hay tạo các kết quả nhân tạoThuận tiện cho phát triển các mô đun thứ cấp dùng lại đượcNhược điểm của phương pháp bottom-up: Phát hiện chậm các lỗi thiết kếChậm có phiên bản thực hiện được của hệ thống * Kiểm thử hệ thống – System Test Mục đích System Test là kiểm thử thiết kế và toàn bộ hệ thống (sau khi tích hợp) có thỏa mãn yêu cầu đặt ra hay không. System Test bắt đầu khi tất cả các bộ phận của phần mềm đã được tích hợp thành công. Thông thường loại kiểm thử này tốn rất nhiều công sức và thời gian. Trong nhiều trường hợp, việc kiểm thử đòi hỏi một số thiết bị phụ trợ, phần mềm hoặc phần cứng đặc thù, đặc biệt là các ứng dụng thời gian thực, hệ thống phân bố, hoặc hệ thống nhúng. Ở mức độ hệ thống, người kiểm thử cũng tìm kiếm các lỗi, nhưng trọng tâm là đánh giá về hoạt động, thao tác, sự tin cậy và các yêu cầu khác liên quan đến chất lượng của toàn hệ thống. Điểm khác nhau then chốt giữa Integration Test và System Test là System Test chú trọng các hành vi và lỗi trên toàn hệ thống, còn Integration Test chú trọng sự giao tiếp giữa các đơn thể hoặc đối tượng khi chúng làm việc cùng nhau. Thông thường ta phải thực hiện Unit Test và Integration Test để bảo đảm mọi Unit và sự tương tác giữa chúng hoạt động chính xác trước khi thực hiện System Test. Sau khi hoàn thành Integration Test, một hệ thống phần mềm đã được hình thành cùng với các thành phần đã được kiểm tra đầy đủ. Tại thời điểm này, lập trình viên hoặc kiểm thử viên bắt đầu kiểm thử phần mềm như một hệ thống hoàn chỉnh. Việc lập kế hoạch cho System Test nên bắt đầu từ giai đoạn hình thành và phân tích các yêu cầu. System Test kiểm thử cả các hành vi chức năng của phần mềm lẫn các yêu cầu về chất lượng như độ tin cậy, tính tiện lợi khi sử dụng, hiệu năng và bảo mật. Mức kiểm thử này đặc biệt thích hợp cho việc phát hiện lỗi giao tiếp với phần mềm hoặc phần cứng bên ngoài, chẳng hạn các lỗi "tắc nghẽn" (deadlock) hoặc chiếm dụng bộ nhớ. Sau giai đoạn System Test, phần mềm thường đã sẵn sàng cho khách hàng hoặc người dùng cuối cùng kiểm thử chấp nhận sản phẩm (Acceptance Test) hoặc dùng thử (Alpha/Beta Test). Đòi hỏi nhiều công sức, thời gian và tính chính xác, khách quan, System Test thường được thực hiện bởi một nhóm kiểm thử viên hoàn toàn độc lập với nhóm phát triển dự án. Bản thân System Test lại gồm nhiều loại kiểm thử khác nhau, phổ biến nhất gồm: Kiểm thử chức năng (Functional Test): Bảo đảm các hành vi của hệ thống thỏa mãn đúng yêu cầu thiết kế. Kiểm thử hiệu năng (Performance Test): Bảo đảm tối ưu việc phân bổ tài nguyên hệ thống (ví dụ bộ nhớ) nhằm đạt các chỉ tiêu như thời gian xử lý hay đáp ứng câu truy vấn... Kiểm thử khả năng chịu tải (Stress Test hay Load Test): Bảo đảm hệ thống vận hành đúng dưới áp lực cao (ví dụ nhiều người truy xuất cùng lúc). Stress Test tập trung vào các trạng thái tới hạn, các "điểm chết", các tình huống bất thường như đang giao dịch thì ngắt kết nối (xuất hiện nhiều trong kiểm tra thiết bị như POS, ATM...)... Kiểm thử cấu hình (Configuration Test). Kiểm thử bảo mật (Security Test): Bảo đảm tính toàn vẹn, bảo mật của dữ liệu và của hệ thống. Kiểm thử khả năng phục hồi (Recovery Test): Bảo đảm hệ thống có khả năng khôi phục trạng thái ổn định trước đó trong tình huống mất tài nguyên hoặc dữ liệu; đặc biệt quan trọng đối với các hệ thống giao dịch như ngân hàng trực tuyến... Nhìn từ quan điểm người dùng, các cấp độ kiểm thử trên rất quan trọng: Chúng bảo đảm hệ thống đủ khả năng làm việc trong môi trường thực. Lưu ý là không nhất thiết phải thực hiện tất cả các loại kiểm thử nêu trên. Tùy yêu cầu và đặc trưng của từng hệ thống, tuỳ khả năng và thời gian cho phép của dự án, khi lập kế hoạch, người Quản lý dự án sẽ quyết định áp dụng những loại kiểm thử nào. * Kiểm thử chấp nhận sản phẩm – Acceptance Test Thông thường, sau giai đoạn System Test là Acceptance Test, được khách hàng thực hiện (hoặc ủy quyền cho một nhóm thứ ba thực hiện). Mục đích của Acceptance Test là để chứng minh phần mềm thỏa mãn tất cả yêu cầu của khách hàng và khách hàng chấp nhận sản phẩm (và trả tiền thanh toán hợp đồng). Acceptance Test có ý nghĩa hết sức quan trọng, mặc dù trong hầu hết mọi trường hợp, các phép kiểm thử của System Test và Acceptance Test gần như tương tự, nhưng bản chất và cách thức thực hiện lại rất khác biệt. Đối với những sản phẩm dành bán rộng rãi trên thị trường cho nhiều người sử dụng, thông thường sẽ thông qua hai loại kiểm thử gọi là kiểm thử Alpha – Alpha Test và kiểm thử Beta – Beta Test. Với Alpha Test, người dùng kiểm thử phần mềm ngay tại nơi phát triển phần mềm, lập trình viên sẽ ghi nhận các lỗi hoặc phản hồi, và lên kế hoạch sửa chữa. Với Beta Test, phần mềm sẽ được gửi tới cho người dùng để kiểm thử ngay trong môi trường thực, lỗi hoặc phản hồi cũng sẽ gửi ngược lại cho lập trình viên để sửa chữa. Thực tế cho thấy, nếu khách hàng không quan tâm và không tham gia vào quá trình phát triển phần mềm thì kết quả Acceptance Test sẽ sai lệch rất lớn, mặc dù phần mềm đã trải qua tất cả các kiểm thử trước đó. Sự sai lệch này liên quan đến việc hiểu sai yêu cầu cũng như sự mong chờ của khách hàng. Ví dụ đôi khi một phần mềm xuất sắc vượt qua các phép kiểm thử về chức năng thực hiện bởi nhóm thực hiện dự án, nhưng khách hàng khi kiểm thử sau cùng vẫn thất vọng vì bố cục màn hình nghèo nàn, thao tác không tự nhiên, không theo tập quán sử dụng của khách hàng v.v... Gắn liền với giai đoạn Acceptance Test thường là một nhóm những dịch vụ và tài liệu đi kèm, phổ biến như hướng dẫn cài đặt, sử dụng v.v... Tất cả tài liệu đi kèm phải được cập nhật và kiểm thử chặt chẽ. *Kiểm thử big bang Kiểm thử big bang (big bang testing) là một chiến lược kiểm thử hệ thống tiến hành một lần duy nhất khi đã phát triển toàn bộ các mô đun và tích hợp thành một phần mềm hoàn chỉnhPhương pháp này vẫn thường được tiến hành khi phát triển các phần mềm có kích thước nhỏ *Kiểm thử sandwich Kết hợp 2 kỹ thuật kiểm thử: Trên -Xuống cho các mức trên của chương trình; Dưới – Lên cho các mức phụ thuộc. Hạn chế: Khó cô lập lỗi. 2.5 Một số kiểm thử khác Kiểm thử tính đúng – Correctness testing: Tính đúng đắn là yêu cầu tối thiểu của phần mềm, là mục đích chủ yếu của kiểm thử. Kiểm thử tính đúng sẽ cần một kiểu người đáng tin nào đó, để chỉ ra cách hoạt động đúng đắn từ cách hoạt động sai lầm. Kiểm thử viên có thể biết hoặc không biết các chi tiết bên trong của các modun phần mềm được kiểm thử, ví dụ luồng điều khiển, luông dữ liệu, v.v …. Do đó, hoặc là quan điểm hộp trắng, hoặc là quan điểm hộp đen có thể được thực hiện trong kiểm thử phần mềm. PHẦN III MỘT SỐ ỨNG DỤNG CỦA KỸ THUẬT KIỂM THỬ Áp dụng kỹ thuật kiểm thử hộp đen: Chương trình đọc vào 3 giá trị nguyên từ hộp thoại vào. Ba giá trị này tương ứng với chiều dài 3 cạnh của 1 tam giác. Chương trình hiển thị 1 thông điệp cho biết tam giác đó là tam giác thường, cân, hay đều. Ba giá trị nhập vào thỏa mãn là 3 cạnh của một tam giác khi và chỉ khi cả 3 số đều là số nguyên dương, và tổng của 2 số bất kỳ trong 3 số phải lớn hơn số thứ 3. Khi đó, một tam giác đều là tam giác có 3 cạnh bằng nhau, tam giác cân là tam giác có 2 trong 3 cạnh bằng nhau, và tam giác thường thì có 3 cạnh khác nhau Vẽ đồ thị nguyên nhân – kết quả Do đặc tả có sự kết hợp đầu vào nên trước tiên, áp dụng phương pháp vẽ đồ thị nguyên nhân – kết quả. Nguyên nhân là: Cả 3 giá trị nhập vào đều là số nguyên dương. Tổng 2 số bất kỳ trong 3 số lớn hơn số còn lại. Hai trong 3 số có giá trị bằng nhau. Ba số có giá trị bằng nhau. Kết quả là: R1. Thông báo ba giá trị nhập vào lập thành tam giác thường. R2. Thông báo ba giá trị nhập vào lập thành tam giác cân. R3. Thông báo ba giá trị nhập vào lập thành tam giác đều. R4. Thông báo ba giá trị nhập vào không lập thành một tam giác. R5. Thông báo lỗi nhập dữ liệu. Đồ thị nguyên nhân – kết quả: Bước tiếp theo là tạo bảng quyết định mục vào giới hạn. Chọn kết quả R1 là đầu tiên. R1 có mặt nếu nút các nút 12 và 3 = 1,0. Nút 12 = 1 khi 1 và 2 = 1,1. Áp dụng lần lượt cho sự có mặt của từng kết quả đầu vào, ta được bảng quyết định như sau: Bảng quyết định 1 2 3 4 5 1 1 1 1 1 0 2 1 1 0 3 0 1 4 1 R1 1 0 0 0 0 R2 0 1 0 0 0 R3 0 0 1 0 0 R4 0 0 0 1 0 R5 0 0 0 0 1 Bước cuối cùng là chuyển đổi bảng quyết định thành các ca kiểm thử. Các ca kiểm thử thu được như sau: STT Các điều kiện Ca kiểm thử Hành động 1 Cả 3 giá trị nhập vào đều là số nguyên dương, và tổng của 2 số bất kỳ trong 3 số luôn lớn hơn số thứ 3, và không có cặp 2 số bất kỳ nào trong 3 số đó là = nhau. 2,3,4 2,4,3 3,2,4 3,4,2 4,2,3 4,3,2 R1 2 Cả 3 giá trị nhập vào đều là số nguyên dương, và tổng cảu 2 số bất kỳ trong 3 số luôn lớn hơn số thứ 3, và tồn tại một cặp 2 số trong 3 số đó là = nhau. 3,3,4 3,4,3 4,3,3 R2 3 Cả 3 giá trị nhập vào đều là số nguyên dương, và cả 3 số có giá trị bằng nhau. 3,3,3 R3 4 Cả 3 giá trị nhập vào đều là số nguyên dương, và tồn tại 2 số trong 3 số có tổng nhỏ hơn hoặc bằng số còn lại. 1,2,4 Và 5 hoán vị của nó R4 5 Tồn tại một giá trị nhập vào không phải là số nguyên dương. A,2,2 -1,1,1 1.1,1,1 Và 2 hoán vị của mỗi trường hợp R5 Phân lớp tương đương Xác định các lớp tương đương Các giá trị nhập vào là số Cả 3 giá trị đều là số (1) Tồn tại 1 giá trị không phải là số (2) Các giá trị là nguyên Cả 3 giá trị đều nguyên (3) Tồn tại 1 giá trị không nguyên (4) Các giá trị là dương Cả 3 giá trị đều dương (5) Tồn tại 1 giá trị <=0 (6) Hằng số -32768 : 32767 (7) 32767 (9) Tổng 2 số bất kỳ so với số thứ 3 Lớn hơn (10) Nhỏ hơn hoặc bằng (11) Xác định các ca kiểm thử Các ca kiểm thử bao phủ các lớp tương đương hợp lệ: Ca kiểm thử 2,3,4 và 5 hoán vị bao phủ các lớp (1), (3), (5), (7), (10). Các ca kiểm thử tương ứng với từng ca kiểm thử không hợp lệ: (2) A, 1, 1 và 2 hoán vị. (4) 1.1, 1, 1 và 2 hoán vị. (6) -1, 1, 1 và 2 hoán vị. (8) -32769, 1, 1 và 2 hoán vị. (9) 32768, 1, 1 và 2 hoán vị. (11) 1, 2, 4 và 5 hoán vị. Phân tích giá trị biên Xét các trạng thái đầu vào Xét các trạng thái đầu vào thu được các ca kiểm thử như sau: 1, 1, 1 A, 1, 1 và 2 hoán vị. 1.1, 1, 1 và 2 hoán vị. 0, 1, 1 và 2 hoán vị. -1, 1, 1 và 2 hoán vị. -32768, 1, 1 và 2 hoán vị. -32769, 1, 1 và 2 hoán vị. 32767, 1, 1 và 2 hoán vị. 32768, 1, 1 và 2 hoán vị. 1, 2, 3 và 5 hoán vị. 1, 2, 4 và 5 hoán vị. Áp dụng kỹ thuật kiểm thử hộp trắng vào kiểm thử một chương trình . Static void Main(){ short x,y,try{ Console.WriteLine(“nhap canh x= “);x = short.Parse(Console.ReadLine());Console.WriteLine(“nhap canh y= “);y = short.Parse(Console.ReadLine());Console.WriteLine(“nhap canh z= “);z = short.Parse(Console.ReadLine()); if (x=Int16.MinValue ||y>= Int16.MinValue || z>= Int16.MinValue) ketqua(x,y,z) } Catch { Console.WriteLine(“Sai lỗi định dạng”); } 1 7 6 5 4 3 2 Static void ketqua(short x, short y, short z){ If (x+y<=z || x+z<=y || y+z<=x || x<=0 || y<=0 || z<=0) 8 Console.WriteLine(“Đây không phải là 3 cạnh của tam giác”); 10 14 13 12 11 9 Else{If (x==y && y==z)Console .WriteLine(“Đây là tam giác đều”);Else{ 17 16 15 If (x==y || x==z || y==z)Console .WriteLine(“Đây là tam giác cân”);ElseConsole .WriteLine(“Đây là tam giác thường”); }}} Kiểm thử hộp trắng theo đường diễn tiến của chương trình thì cần thực hiện các bước sau:Bước 1: xác định các nút- Các nút là gì: là các câu lệnh, các câu lệnh tuần tự, điểm kết thúc của một vòng lặp, điểm kết thúc của một hàm/Bước 2: vẽ đồ thị thể hiện đường diễn tiến của chương trình - Các nút đã xác định ở bước 1- Các cạnh nối hai nút biểu diễn dòng điều khiển 8 5 6 14 1 2 3 4 5 6 10 9 8 7 11 12 13 15 16 17 1 2 3 4 7 9 11 10 x=y y=z x=y x=z y=z Tam giác đều TG thường Tam giác cân Không là tam giác T T F F F F F T T T Bước 3: Cách 1: E= 27, N=17àV(G)= 27-17+2=12 Cách 2: P=11à V(G)=11+1=12 Số đường kiểm thử là: 1 1.2.8.17 2 1.2.3.8.17 3 1.2.3.4.8.17 4 1.2.3.4.5.8.17 5 1.2.3.4.5.6.8.17 6 1.2.3.4.5.6.7.8.17 7 1.2.3.4.5.6.7.9.10.11.17 8 1.2.3.4.5.6.7.9.10.12.15.17 9 1.2.3.4.5.6.7.9.12.15.17 10 1.2.3.4.5.6.7.9.12.13.15.17 11 1.2.3.4.5.6.7.9.12.13.14.15.17 12 1.2.3.4.5.6.7.9.12.13.14.16.17 Bước 4: xác định các testcase cho mỗi trường hợp Đường kiểm thử Đầu vào Kết quả mong đợi 1 x=1, y=1,z=3 Không phải tam giác 2 x=1, y=4, x=2 Không phải tam giác 3 x=5, y=1, z=3 Không phải là tam giác 4 x=-1 Không là tam giác 5 y=-1 Không là tam giác 6 z=-1 Không là tam giác 7 x=4, y=4, z=4 Tam giác đều 8 x=3, y=3, z=4 Cân x, y 9 x= 3, y=4, z=4 Cân y, z 10 x= 3, y=4, z=3 Cân x, z 11 x= 3, y=4, z=4 Cân y, z 12 X=3, y = 4, z=5 Tam giác thường PHẦN VI TỔNG KẾT Kiểm thử phần mềm, một hướng đi không còn mới mẻ trên thế giới, nhưng lại là một hướng đi rất mới ở Việt Nam. Nó hứa hẹn một tương lai mới cho các học sinh, sinh viên ngành CNTT. Tiềm năng của nghề: 1 dự án nói chung cứ 3 lập trình viên thì phải có 1 kiểm thử viên phần mềm. ở Việt Nam tuy là nguồn nhân lực rất trẻ đang theo nghành công nghệ thông tin nhưng đa số lại theo con đường lập trình -> nếu bạn theo nghề kiểm thử thì cơ hội nghề nghiệp rất cao. 10 lý do để nghề kiểm thử trở thành một nghề thời thượng: Kiểm thử PM là một nghề có phúc lợi tốt, với cơ hội thăng tiến nghề nghiệp nhanh chóng và đa dạng. Kiểm thử PM là một nghề xứng đáng và thử thách. Kiểm thử PM luôn là một nghề cần thiết. Nhiều người có thể làm, nhưng rất ít người có thể làm tốt. Kiểm thử PM đòi hỏi cao về tư duy, phân tích và sáng tạo. Tiếp cận những điều tốt nhất và mới nhất. Bạn làm hài lòng nhiều người. Đem đến sự tự tin (bạn và khách hàng). Giữ uy tín và tiết kiệm cho công ty của mình. Không có kiểm thử PM không có TÀI LIỆU THAM KHẢO Lương Mạnh Bá Giáo trình nhập môn công nghệ phần mềm, Đại Học Bách Khoa Hà Nội. Nguyễn Xuân Huy (1994), Công nghệ phần mềm, Đại học Tổng hợp Tp. Hồ Chí Minh.