Đề tài Tìm hiểu các kỹ thuật kiểm thử phần mềm ứng dụng trong lập trình Java

1 MỤC LỤC TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI VIỆN CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG BÀI TẬP LỚN Kỹ thuật phần mềm Đề tài: Tìm hiểu các kỹ thuật kiểm thử phần mềm ứng dụng trong lập trình Java. Nhóm sinh viên thực hiện: FSE20 Trần Văn Bích 20080215 Nguyễn Chí Công 20080316 Nguyễn Khắc Hưng 20080070 Bùi Huy Thắng 20082449 Giảng viên hướng dẫn: Vũ Thị Hương Giang Hà Nội, 2011 2 Mục Lục I. Giới thiệu đề tài .................................................................................................................................. 3 II. Kiểm thử phần mềm ........................................................................................................................ 4 1. Kiểm thử phần mềm là gì? .............................................................................................................. 4 2. Quá trình kiểm thử phần mềm ......................................................................................................... 4 3. Các cấp độ kiểm thử phần mềm ...................................................................................................... 5 4. Các nguyên tắc kiểm thử phần mềm ............................................................................................... 7 III. Giới thiệu về JUnit .......................................................................................................................... 9 1. Giới thiệu về JUnit Framework ....................................................................................................... 9 2. Các đặc điểm của JUnit ................................................................................................................... 9 3. Cấu trúc lớp của JUnit ..................................................................................................................... 9 4. Sử dụng JUnit ............................................................................................................................... 10 IV. Các kĩ thuật kiểm thử phần mềm ................................................................................................... 12 1. Kiểm thử hộp đen (Black Box Testing)......................................................................................... 12 i. Định nghĩa................................................................................................................................. 12 ii. Nguyên lý hoạt động ................................................................................................................. 12 iii. Trường hợp ứng dụng ........................................................................................................... 13 iv. Ưu điểm/ Nhược điểm ........................................................................................................... 23 v. Demo......................................................................................................................................... 23 2. Kiểm thử hộp trắng (White Box Testing). ..................................................................................... 25 i. Định nghĩa................................................................................................................................. 25 ii. Đặc điểm ................................................................................................................................... 26 iii. Các kĩ thuật kiểm thử ............................................................................................................ 27 iv. Ưu điểm / Nhược điểm .......................................................................................................... 32 v. Thiết kế trường hợp thử trên JUnit ............................................................................................ 33 3. Kiểm thử hộp xám (Gray Box Testing). ........................................................................................ 35 V. Tổng kết ............................................................................................................................................ 36 VI. Phụ lục .......................................................................................................................................... 37 TÀI LIỆU THAM KHẢO ........................................................................................................................ 38 3 I. Giới thiệu đề tài “Lỗi phần mềm là chuyện hiển nhiên của cuộc sống. Chúng ta dù cố gắng đến mức nào thì thực tế là ngay cả những lập trình viên xuất sắc nhất cũng không có thể lúc nào cũng viết được những đoạn mã không có lỗi. Tính trung bình, ngay cả một lập trình viên loại tốt thì cũng có từ 1 đến 3 lỗi trên 100 dòng lệnh. Người ta ước lượng rằng việc kiểm tra để tìm ra các lỗi này chiếm phân nửa khối lượng công việc phải làm để có được một phần mềm hoạt động được”. (Software Testing Techniques, Second Edition, by Boris Beizer, Van Nostrand Reinhold, 1990, ISBN 1850328803). Thật vậy, ngày nay càng ngày các chương trình (các phần mềm) càng trở lên phức tạp và đồ sộ. Việc tạo ra một sản phẩm có thể bán được trên thị trường đòi hỏi sự nổ lực của hàng chục, hàng trăm thậm chí hàng ngàn nhân viên. Số lượng dòng mã lên đến hàng triệu. Và để tạo ra một sản phẩm thì không phải chỉ do một tổ chức đứng ra làm từ đầu đến cuối, mà đòi hỏi sự liên kết, tích hợp của rất nhiều sản phẩm, thư viện lập trình, của nhiều tổ chức khác nhau Từ đó đòi hỏi việc kiểm nghiệm phần mềm càng ngày càng trở nên rất quan trọng và rất phức tạp. Song song với sự phát triển các công nghệ lập trình, các ngôn ngữ lập trình thì các công nghệ và kỹ thuật kiểm nghiệm phần mềm ngày càng phát triển và mang tính khoa học. Bài tiểu luận này với mục đích là tập hợp, nghiên cứu, phân tích các kỹ thuật, các công nghệ kiểm nghiệm phần mềm đang được sử dụng và phát triển hiện nay. 4 II. Kiểm thử phần mềm 1. Kiểm thử phần mềm là gì? Kiểm thử phần mềm có nhiều cách định nghĩa khác nhau. Tuy nhiên, 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. Định nghĩa sau đây của Myers là đơn giản và có tính thực tế: “Kiểm thử là tiến trình thực thi chương trình với mục đích tìm thấy lỗi”. 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. Hình 1: Kiểm thử phần mềm Mục đích của kiểm thử là phát hiện lỗi vì trong thực tế phần mềm hầu như không bao giờ không chứa lỗi. 2. Quá trình kiểm thử phần mềm Quát trình kiểm thử phần mềm nhằm đạt được 2 mục tiêu:  Chứng minh cho người phát triển và khách hàng thấy các yêu cầu của phần mềm. (Giải thích sự hoạt động chính xác – Paul Jorgensen)  Phát hiện ra các lỗi và khiếm khuyết trong phần mềm: phần mềm thực hiện không đúng, không như mong đợi hoặc không làm theo như đặc tả. 5 Hình 2: Vòng đời của kiểm nghiệm 3. Các cấp độ kiểm thử phần mềm 6 Hình 3: Sơ đồ các cấp độ kiểm thử a. Kiểm thử đơn vị - Unit test Một đơn vị là một thành phần phần mềm nhỏ nhất mà ta có thể kiểm thử được. Ví dụ, các hàm (Function), thủ tục (Procedure), lớp (Class) hay phương thức (Method) đều có thể được xem là Unit. Unit Test thường do lập trình viên thực hiện. Công đoạn này cần được thực hiện càng sớm càng tốt trong giai đoạn viết code và xuyên suốt chu kỳ phát triển phần mềm. Mục đích của Unit Test là bảo đảm thông tin được xử lý và xuất (khỏi Unit) là chính xác, trong mối tương quan với dữ liệu nhập và chức năng của Unit. Điều này thường đòi hỏi tất cả các nhánh bên trong Unit đều phải được kiểm tra để phát hiện nhánh phát sinh lỗi. Một nhánh thường là một chuỗi các lệnh được thực thi trong một Unit. b. Kiểm thử tích hợp - Intergration Test Intergration test kết hợp các thành phần của một ứng dụng và kiểm thử như một ứng dụng đã hoàn thành. Trong khi Unit Test kiểm tra các thành phần và Unit riêng lẻ thì Intgration Test kết hợp chúng lại với nhau và kiểm tra sự giao tiếp giữa chúng. Hai mục tiêu chính của Integration Test:  Phát hiện lỗi giao tiếp xảy ra giữa các Unit.  Tích hợp các Unit đơn lẻ thành các hệ thống nhỏ (Subsystem) và cuối cùng là nguyên hệ thống hoàn chỉnh (System) chuẩn bị cho kiểm thử ở mức hệ thống (System Test). c. 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à 7 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. 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). d. 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. 4. Các nguyên tắc kiểm thử phần mềm Để kiểm thử đạt hiệu quả thì khi tiến hành kiểm thử phần mềm cần phải tuân thủ một số quy tắc sau: Quy tắc 1: Một phần quan trọng của 1 ca kiểm thử là định nghĩa của đầu ra hay kết quả mong muốn. Quy tắc 2: Lập trình viên nên tránh tự kiểm tra chương trình của mình. Quy tắc 3: Nhóm lập trình không nên kiểm thử chương trình của chính họ. Quy tắc 4: Kiểm tra thấu đáo mọi kết quả của mỗi kiểm tra. Quy tắc 5: Các ca kiểm thử phải được viết cho các trạng thái đầu vào không hợp lệ và không mong muốn, cũng như cho các đầu vào hợp lệ và mong muốn. Quy tắc 6: Khảo sát 1 chương trình để xem liệu chương trình có thực hiện cái mà nó cần thực hiện chỉ là 1 phần, phần còn lại là xem liệu chương trình có thực hiện cái mà nó không cần phải thực hiện hay không. Quy tắc 7: Tránh các ca kiểm thử bâng quơ trừ khi chương trình thực sự là 1 chương trình bâng quơ. Quy tắc 8: Không dự kiến kết quả của kiểm thử theo giả thiết ngầm là không tìm thấy lỗi. 8 Quy tắc 9: Xác suất tồn tại lỗi trong 1 đoạn chương trình là tương ứng với số lỗi đã tìm thấy trong đoạn đó. Quy tắc 10: Kiểm thử là 1 nhiệm vụ cực kỳ sáng tạo và có tính thử thách trí tuệ. 9 III. Giới thiệu về JUnit 1. Giới thiệu về JUnit Framework JUnit là một framework đơn giản dùng cho việc tạo các unit testing tự động, và chạy các test có thể lặp đi lặp lại. Nó chỉ là một phần của họ kiến trúc xUnit cho việc tạo các unit testing. JUnit là một chuẩn trên thực tế cho unit testing trong Java. JUnit về nguồn gốc được viết bởi 2 tác giả Erich Gamma và Kent Beck. 2. Các đặc điểm của JUnit i. Xác nhận (assert) việc kiểm tra kết quả được mong đợi. ii. Các test suite cho phép ta dễ dàng tổ chức và chạy các test. iii. Hỗ trợ giao diện đồ họa và giao diện dòng lệnh. iv. Các test case của JUnit là các lớp của Java, nó bao gồm một hay nhiều phương thức unit testing, và các test này lại được nhóm thành test suite. v. Các test trong JUnit được thiết kế để khi chạy mà không cần có sự can thiệp của con người. 3. Cấu trúc lớp của JUnit Hình 4: Cấu trúc JUnit 10 Hình 5: Cấu trúc lớp  TestCase: - Cài đặt các trường hợp tests.  TestSuite: - Tập hợp các trường hợp thử liên quan.  TestResult: - Thu thập tất cả các sai sót, thất bại xảy ra trong thời gian test.  TestRunner: - Thực thi các Testsuite. 4. Sử dụng JUnit Hình 6: Xây dựng testcase 11  junit.framework.TestCase, lớp cha cho tất cả các test case, thừa kế từ lớp junit.framework.Assert. Lớp này định nghĩa khá nhiều các phương thức assertXXX(). Các phương thức test hoạt động bằng cách gọi những phương thức này.  Tạo phương thức test:  public void testXXX()  assertions per method  Phương thức setUp/tearDown nếu dữ liệu sử dụng được chia sẻ trong TestCase.  Các phương thức : Các phương thức assertXXX() được dùng để kiểm tra các điều kiện khác nhau có trong lớp junit.framework.Assert. • Boolean assertEquals(): So sánh hai giá trị để kiểm tra bằng nhau. Phép thử thất bại nếu hai giá trị không bằng nhau. • Boolean assertFalse(): Đánh giá biểu thức logic. Phép thử thất bại nếu biểu thức đúng. • Boolean assertNotNull(): So sánh tham chiếu của một đối tượng với Null. Phép thử thất bại nếu tham chiếu đối tượng Null. • Boolean assertNotSame(): So sánh địa chỉ vùng nhớ của hai tham chiếu hai đối tượng bằng cách sử dụng toán tử ==. Phép thử thất bại trả về nếu cả hai đều tham chiếu đến cùng một đối tượng. • Boolean assertNull(): So sánh tham chiếu của một đối tượng với giá trị Null. Phép thử thất bại nếu đối tượng không là Null. • Boolean assertSame(): So sánh địa chỉ vùng nhớ của hai tham chiếu đối tượng bằng cách sử dụng toán tử ==. Phép thử thất bại nếu cả hai không tham chiếu đến cùng một đối tượng. • Boolean assertTrue(): Đánh giá một biểu thức logic. Phép thử thất bại nếu biểu thức sai. • void fail(): Phương thức này làm cho test hiện tại thất bại, phương thức này thường được sử dụng khi xử lý các ngoại lệ. 12 IV. Các kĩ thuật kiểm thử phần mềm 1. Kiểm thử hộp đen (Black Box Testing). i. Định nghĩa  Định nghĩa: Kiểm thử hộp đen hay còn gọi là kiểm tra chức năng và thử nghiệm hành vi. Xem chương trình như là một “hộp đen” , hoàn toàn không quan tâm về cách cư xử và cấu trúc bên trong của chương trình. Thay vào đó, Tập trung vào tìm các trường hợp mà chương trình không thực hiện theo các đặc tả của nó.  Các phương pháp kiểm thử hộp đen: o Phân lớp tương đương – Equivalence partitioning. o Phân tích giá trị biên – Boundary value analysis. o Kiểm thử mọi cặp – All-pairs testing. o Kiểm thử fuzz – Fuzz testing. o Kiểm thử dựa trên mô hình – Model-based testing. o Ma trận dấu vết – Traceability matrix. o Kiểm thử thăm dò – Exploratory testing. o Kiểm thử dựa trên đặc tả – Specification-base testing  Đặc điểm: Kiểm thử dựa trên đặc tả tập trung vào kiểm tra tính thiết thực của phần mềmtheo những yêu cầu thích hợp. Do đó, kiểm thử viên nhập dữ liệu vào, và chỉ thấydữ liệu ra từ đối tượng kiểm thử. Mức kiểm thử này thường yêu cầu các ca kiểm thửtriệt để được cung cấp cho kiểm thử viên mà khi đó có thể xác minh là đối với dữliệu đầu vào đã cho, giá trị đầu ra (hay cách thức hoạt động) có giống với giá trịmong muốn đã được xác định trong ca kiểm thử đó hay không. Kiểm thử dựa trênđặc tả là cần thiết, nhưng không đủ để để ngăn chặn những rủi ro chắc chắn. ii. Nguyên lý hoạt động 13 Kiểm thử hộp đen không có mối l iên quan nào tới mã lệnh, và kiểm thử viênchỉ rất đơn giản tâm niệm là: một mã lệnh phải có lỗi. Sử dụng nguyên tắc “ Hãy đòi hỏi và bạn sẽ được nhận”, những kiểm thử viên hộp đen tìm ra lỗi mà những lậptrình viên đã không tìm ra. Nhưng, mặt khác, người ta cũng nói kiểm thử hộp đen“giống như là đi trong bóng tối mà không có đèn vậy”, bởi vì kiểm thử viên không biết các phần mềm được kiểm tra thực sự được xây dựng như thế nào. Đó là lý domà có nhiều trường hợp mà một kiểm thử viên hộp đen viết rất nhiều ca kiểm thử đểkiểm tra một thứ gì đó mà đáng lẽ có thể chỉ cần kiểm tra bằng 1 ca kiểm thử duynhất, và/hoặc một số phần của chương trình không được kiểm tra chút nào. - Các bước : o Ban đầu yêu cầu và thông số kỹ thuật của hệ thống được kiểm tra. o Tester chọn đầu vào hợp lệ (tích cực thử nghiệm kịch bản) để kiểm tra liệu SUT(Software Under Test) xử lý chúng một cách chính xác. Ngoài ra một số nguyên liệu đầu vào không hợp lệ (tiêu cực thử nghiệm kịch bản) được lựa chọn để xác minh rằng SUT có thể phát hiện ra chúng. o Tester xác định kết quả đầu ra dự kiến cho tất cả những yếu tố đầu vào. o Thử phần mềm xây dựng trường hợp thử nghiệm với các yếu tố đầu vào được lựa chọn. o Các trường hợp kiểm tra được thực hiện. o Phần mềm thử so sánh kết quả thực tế với kết quả mong đợi. o Khuyết tật nếu có được cố định và thử nghiệm lại. iii. Trường hợp ứng dụng  Phân lớp tương đương - Equivalence partitioning. - Ý tưởng : phân hoạch miền dữ liệu vào thành các dữ liệu có lien hệ với nhau - Mỗi lớp dùng để kiểm thử 1 chức năng , gọi là lớp tương đương. 14 - Các bước : 3 bước o Đối với dữ liệu đầu vào , xác định các lớp tương đương từ miền dữ liệu. o Chọn dữ liệu đại diện cho mỗi lớp tương đương o Kết hợp các dữ liệu thử bởi tích đề các để tạo ra bộ dữ liệu kiểm thử. - Nguyên tắc phân hoạch các lớp tương đương o Nếu dữ liệu vào phụ thuộc một khoảng , xây dựng  1 lớp các giá trị lớn hơn  1 lớp các giá trị nhỏ hơn  N các giá trị hợp lệ o Nếu dữ liệu là tập hợp các giá trị , Xây dựng  1 lớp tập rỗng  1 lớp quá nhiều các giá trị  N lớp hợp lệ o Nếu dữ liệu đầu vào là điều kiện ràng buộc , xây dựng  1 lớp các ràng buộc được thỏa mãn.  1 lớp với ràng buộc không được thỏa mãn. Ví dụ : Bài toán tam giác Nhọn Vuông Tù Thường 6,5,3 3,4,5 5,6,10 Cân 6,1,6 √ , 2, √ 7,4,4 Đều 4,4,4 Không thể Không thể Không là tam giác -1,2,8 15  Phân tích giá trị biên - Boundary value analysis.:  Cơ sở : lỗi thường xuất hiện gần các giá trị biên của miền dữ liệu.  Tập trung phân tích các giá trị biên của miền dữ liệu để xây dựng dữ liệu kiểm thử.  Nguyên tắc kiểm thử các dữ liệu bao gồm: o Giá trị nhỏ nhất. o Giá trị gần kề lớn hơn giá trị nhỏ nhất. o Giá trị bình thường. o Giá trị gần kề nhỏ hơn giá trị lớn nhất o Giá trị lớn nhất  Nguyên tắc chọn dữ liệu thử o Nếu dữ liệu vào thuộc một khoảng , chọn  2 Giá trị biên.  4 giá trị = Giá trị biên ± sai số nhỏ nhất o Nếu giá trị vào phụ thuộc danh sách các giá trị , chọn phần tử lớn thứ nhất , phần tử thứ hai , phần tử kế cuối , phần tử cuối. o Nếu dữ đầu vào là điều kiện ràng buộc số giá trị , chọn số giá trị tối thiểu và số giá trị tối đa và một số giá trị không hợp lệ. Ví dụ : Chương trình nhận vào ba số thực , kiểm tra xem có phải là độ dài ba cạnh tam giác hay không ? nếu là độ dài ba cạnh tam giác thì kiểm tra xem là tam giác thường , cân , vuông , nhọn , tù . Các giá trị cần kiểm tra: Dữ liệu thử 1, 1, 2 Không là tam giác 0, 0, 0 Chỉ là một điểm 4, 0, 3 Một cạnh bằng không 1, 2, 3.000001 Gần là 1 tam giác 0.001, 0.001, 0.001 Tam giác rất nhỏ 99999, 99999, 99999 Tam giác rất lớn 3.00001, 3, 3 Tam giác gần đều 16 2.99999, 3, 4 Tam giác gần cân 3, 4, 5.000001 Tam giác gần vuông 3, 4, 5, 6 Bốn giá trị 3 Chỉ 1 giá trị Dữ liệu rỗng -3, -4, -5 Giá trị âm  Bảng quyết định- Decision Table Bases testing. - Làm giảm số lượng tets casse không cần thiết so với 2 kỹ thuật trên vì nó loại trừ các phép kết hợp không cần thiết giữa các giá trị biến đầu vào. - Liệt kê nguyên nhân (cause) – kết quả (result) trong một ma trận. Mỗi cột ma trận đại diện cho 1 phép kết hợp giữa các cause trong trong việc tạo ra 1 result - Các bước để tạo bảng quyết định o Liệt kê các nguyên nhân trong bảng quyết định o Tính tổng số lượng kết hợp giữa các cause o Điền vào các cột với tất cả các kết hợp có thể có o Rút bớt số lượng các phép kết hợp dư thừa o Kiểm tra các phép kết hợp có bao phủ hết mọi trường hợp hay không o Bổ xung kết quả vào bảng quyết định Ví dụ : Bài toán kiểm tra loại chiều dài 3 cạnh a,b,c  B1: Liệt kê tất cả các nguyên nhân o Điền giá trị vào từng cause o Nhóm các cause có liên quan o Sắp xếp các Cause theo thứ tự 17  B2: Tính tổng số kết hợp giữa các cause o Tổng số phép kết hợp = (Số lượng value cause 1)**(Số lượng value của cause n). Ví dụ: Mỗi cause có 2 giá trị true , false -> Tổng số phép kết hợp là : .  B2: Điền giá trị các cột vào trong bảng o Thuật toán  Xác định số lần lặp lại (RF) trong từng giá trị của cause bằng cách lấy tổng số phép kết hợp còn lại chia cho số values mà cause có thể nhận  Điền dữ liệu cho dòng thứ i : Điền RF lần giá trị đầu tiên của cause i , tiếp theo RF lần theo giá trị tiếp theo của cause I cho đến khi dòng đầy  Chuyển sang dòng kế tiếp và quay lại bước 1 thực hiện Ví dụ :  Bước 4 : Giảm số phép kết hợp 18 o Duyệt qua tất cả các ô trong từng cột, ô nào mà kết quả của nó không ảnh hưởng đến result thì đặt giá trị trên ô này là “-” o Ghép các cột với lội dung giống nhau thành 1 cột  Bước 5 : Kiểm tra độ bao phủ của các phép kết hợp o Tính rule-count trên từng cột(số lượng phép kết hợp) mà cột này có thể thực hiện. o Với các dòng có giá trị là “-” thì lũy thừa 2 o Nếu tổng của các rule-count bằng với tổng số kết hợp giữa các cause trong bước 2 thì bẳng quyết định này đầy đủ  Bước 6 : Bổ xung kết quả vào trong bảng o Duyệt qua từng cột và check vào kết quả o Nhiều cột khác nhau có thể cho ra cùng 1 kết quả giống nhau 19  Đồ thị nguyên nhân kết quả. - Là kỹ thuật thiết kế test case dựa tên đồ thị - Tập trung vào việc xác định các mối kết hợp giữa các điều kiện và kết quả mà các mối kết hợp mang lại. - Các bước xây dựng đồ thị: o B1: Phân chia hệ thống thành vùng hoạt động o B2: Xác định nguyên nhân kết quả o B3: Chuyển nội dung ngữ nghĩa trong đặc tả thành đồ thị liên kết các cause và result o B4: Chuyển đổi đồ thị thành bảng quyết định o B5: Thiết lập danh sách test case từ bảng quyết định. Mỗi test case tương ứng với 1 cột trong bảng quyết định 20  B1: Phân chia hệ thống thành các vùng hoạt động o Phân rã các yêu cầu chức năng thành danh sách các functions hay sub_functions  B2:Xác định nguyên nhân kết quả o Dựa vào đặc tả , xác định các cause và chỉ định mỗi cause này định danh ID.  Mỗi 1 cause có thể xem như là 1 input conditions hoặc là đại diện của 1 lớp tương đương input conditions o Dựa vào đặc tả xác định kết quả hoặc thay đổi trạng thái của hệ thống và chỉ định mỗi kết quả 1 định danh ID  Kết quả có thể là ouput action , output option hay là đại diện của 1 lớp tương đương output conditions. Ví dụ : Xét đặc tả hệ thống tính phí bảo hiểm xe ô tô  Đối với nữ < 65 tuổi , phí bảo hiểm là : 500$  Đối với nam < 25 tuổi , phí bảo hiểm là : 3000$  Đối với nam từ 25 tuổi đến 64 tuổi , phí bảo hiểm là : 1000$  Nếu tuổi từ 65 trở lên, phí bảo hiểm là : 1500$ Có 2 yếu tố xác định phí bảo hiểm : giới tính và tuổi 21  B3: Chuyển nội dung ngữ nghĩa thành đồ thị liên kết -CEG #1: Đối với nam từ 25 đến 64 , phí bảo hiểm 1000$ -CEG #2 : Đối với nam <25 tuổi, phí bảo hiểm 3000$ -CEG #3 : Nếu tuổi từ 64 trở lên , phí bảo hiểm là : 1500$ -CEG #4 : Đối với nữ <65 tuổi , phí bảo hiểm là :500$ 22  B4: Chuyển đổi đồ thị thành bảng quyết định  B5: Thiết lập danh sách các test case từ bảng quyết định 23  Kiểm thử dựa trên yêu cầu - Specification-based testing. Phương pháp kiểm thử dựa vào chức năng - Specification-based testing: Việc kiểm thử được tiến hành dựa vào việc kiểm thử chức năng của phần mềm xem nó có phù hợp với yêu cầu của người dùng hay không. Vì vậy, các tester nhập data vào phần mềm và chỉ cần xem kết quả của phần mềm và các mục tiêu test. Mức test này thường yêu cầu các tester phải viết test case đầy đủ trước khi test, khi test, đơn giản chỉ cần thực hiện theo các bước mô tả trong test case thao tác và nhập data vào, sau đó xem kết quả trả về hoặc hành vi của phần mềm, rồi so sánh với kết quả mong đợi đã được viết trong test case, điền kết quả test vào test case là OK (OK = is – chương trình làm đúng theo mong đợi) hay NG (not good = is not – chương trình không làm đúng theo mong đợi). Specification-based testing là cần thiết, nhưng nó không đủ để bảo đảm chắc chắn các rủi ro xảy ra (nó chỉ là điều điện cần chứ không phải là điều kiện đủ). iv. Ưu điểm/ Nhược điểm  Ưu diểm:  Hiệu quả hơn trên các đơn vị code lớn hơn kiểm tra hộp thủy tinh (Glass box testing).  Tester và người lập trình độc lập với nhau.  Tester không cần kiến thức thực hiện, bao gồm cả ngôn ngữ lập trình cụ thể.  Tester thực hiện trên quan điểm của người sử dụng.  Giúp phát hiện bất kỳ sự mơ hồ hoặc không nhất quán trong các đặc tả chức năng.  Trường hợp kiểm tra có thể được thiết kế như là ngay sau khi các đặc tả kỹ thuật hoàn thành.  Nhược điểm:  Chỉ có một số nhỏ các yếu tố đầu vào có thể thực sự có thể được thử nghiệm, để kiểm tra tất cả các dòng đầu vào có thể sẽ mất gần như mãi mãi.  Mà không cần các chi tiết kỹ thuật rõ ràng và xúc tích, kiểm tra trường hợp rất khó để thiết kế.  Có thể được lặp đi lặp lại không cần thiết của đầu vào thử nghiệm nếu người thử không có thông tin về trường hợp thử nghiệm các lập trình viên đã thử nghiệm.  Có thể để lại nhiều phần chương trình chưa được kiểm tra.  Không thể được hướng dẫn đối với các phân đoạn cụ thể của mã mà có thể rất phức tạp.  Hầu hết các thử nghiệm nghiên cứu liên quan đã được hướng vào việc kiểm tra hộp trắng. v. Demo: Bài toán tính phí bảo hiểm 24  Xây dựng các testcase:  Đầu vào :Độ tuổi, giới tính.  Đầu ra: Đưa ra mức phí bảo hiểm phù hợp. 25 2. Kiểm thử hộp trắng (White Box Testing). i. Định nghĩa Là phương pháp kiểm nghiệm dựa vào cấu trúc/mã lệnh chương trình. Phương pháp white-box kiểm nghiệm một chương trình (một phần chương trình, hay một hệ thống, một phần của hệ thống) đáp ứng tốt tất cả các giá trị input bao gồm cả các giá trị không đúng hay không theo dự định của chương trình. Chiến lược này xuất phát từ dữ liệu kiểm thử bằng sự kiểm thử tính logic của chương trình. Kiểm thử viên sẽ truy cập vào cấu trúc dữ liệu và giải thuật bên trong chương trình (và cả mã lệnh thực hiện chúng). 26 Hình 7 : Kiểm thử hộp trắng ii. Đặc điểm  Kiểm thử hộp trắng dựa vào thuật giải cụ thể, vào cấu trúc dữ liệu bên trong của đơn vị phần mềm cần kiểm thử để xác định đơn vị phần mềm đó có thực hiện đúng không.  Do đó người kiểm thử hộp trắng phải có kỹ năng, kiến thức nhất định để có thể thông hiểu chi tiết về đoạn code cần kiểm thử.  Thường tốn rất nhiều thời gian và công sức nếu mức độ kiểm thử được nâng lên ở cấp kiểm thử tích hợp hay kiểm thử hệ thống.  Do đó kỹ thuật này chủ yếu được dùng để kiểm thử đơn vị. Trong lập trình hướng đối tượng, kiểm thử đơn vị là kiểm thử từng tác vụ của 1 class chức năng nào đó.  Có 2 hoạt động kiểm thử hộp trắng :  Kiểm thử luồng điều khiển.  Kiểm thử dòng dữ liệu. Phụ thuộc vào các cài đặt hiện tại của hệ thống và của phần mềm, nếu có sự thay đổi thì các bài test cũng thay đổi theo. 27 Được ứng dụng trong các kiểm tra ở cấp độ mô đun, tích hợp và hệ thống của quá trình test phần mềm. iii. Các kĩ thuật kiểm thử Phương pháp kiểm nghiệm white-box dựa trên:  Các câu lệnh (statement) : Thiết kế quá trình kiểm tra sao cho mỗi câu lệnh của chương trình được thực hiện ít nhất một lần. Phương pháp kiểm tra này xuất phát từ ý tưởng: - Từ phi một câu lệnh được thực hiện, nếu không ta không thể biết được có lỗi xảy ra trong câu lệnh đó hay không. - Nhưng việc kiểm tra với một giá trị đầu vào không đảm bảo là sẽ đúng cho mọi trường hợp. Xét ví dụ với đoạn mã lệnh JAVA sau: public void foo (int a, int b, int x){ if (a>1 && b==0) { x=x/a;} if (a==2||x>1){ x=x+1; } } 28 Hình 8:Sơ đồ luồng Có thể thực hiện mọi câu lệnh bằng việc viết 1 ca kiểm thử đơn đi qua đường ace. Tức là, bằng việc đặt A=2, B=0 và X=3 tại điểm a, mỗi câu lệnh sẽ được thực hiện 1 lần (thực tế, X có thể được gán bất kỳ giá trị nào).  Đường dẫn (path) Là phương pháp kiểm tra bao trùm mọi đường dẫn của chương trình và cần kết hợp với lược đồ tiến trình. Tư tưởng: Viết đủ các ca kiểm thử mà mỗi quyết định có kết luận đúng hay sai ít nhất 1 lần. Nói cách khác, mỗi hướng phân nhánh phải được xem xét kỹ lưỡng ít nhất 1 lần. 29 Hình 9: Các trường hợp kiểm thử đường dẫn Trong ví dụ trên: Kiêm thử đường dẫn có thể đạt được bởi ít nhất hai ca kiểm thử bao phủ các đường abe và abd hoặc acd và abe. Nếu chọn khả năng thứ hai thì hai đầu vào test case là: A=3, B=0, X=3 và A=2, B=1, X=1. Nhận xét: Phương pháp kiểm tra theo đường dẫn phụ thuộc nhiều vào các biểu thức điều kiện. Tuy nhiên, có những trường hợp số lượng đường dẫn quá lớn (trường hợp vòng lặp). Vì vậy thường không phải là lựa chọn thực tế để tiến hành việc kiểm tra tính đúng đắn của chương trình.  Mà cho dù có kiểm thử hết được toàn bộ các đường thi hành thì vẫn không thể phát hiện những đường thi hành cần có nhưng không (chưa) được hiện thực : if (a>0) doIsGreater(); if (a==0) dolsEqual(); // thiếu việc xử lý trường hợp a < 0 - if (a<0) dolsLess();  Một đường thi hành đã kiểm tra là đúng nhưng vẫn có thể bị lỗi khi dùng thật (trong 1 vài trường hợp đặc biệt) : int blech (int a, int b) { 30 return a/b; } khi kiểm tra, ta chọn b 0 thì chạy đúng, nhưng khi dùng thật trong trường hợp b = 0 thì hàm blech bị lỗi.  Các điều kiện (condition) Là phương pháp kiểm tra các biểu thức điều kiện trên 2 giá trị true và false.  Viết đủ các ca kiểm thử để đảm bảo rằng mỗi điều kiện trong một quyết định đảm nhận tất cả các kết quả có thể ít nhất một lần. Trong ví dụ trên: có 4 điều kiện: A>1, B=0, A=2, X>1. Do đó các ca kiểm thử đầy đủ là cần thiết để thúc đẩy những trạng thái mà A>1, A0 có mặt tại điểm a và A=2, A2, X>1, X<=1 có mặt tại điểm b. Số lượng đầy đủ các ca kiểm thử thỏa mãn tiêu chuẩn và những đường đi mà được đi qua bởi mỗi ca kiểm thử là: 1. A=2, B=0, X=4 ace 2. A=1, B=1, X=1 abd Ví dụ, 2 ca kiểm thử khác: 1. A=1, B=0, X=3 2. A=2, B=1, X=1 bao phủ tất cả các kết quả điều kiện, nhưng chúng chỉ bao phủ 2 trong 4 kết quả quyết định (cả 2 đều bao phủ đường đi abd và do đó, không sử dụng kết quả true của quyết định đầu tiên và kết quả false của quyết định thứ hai). Nhận xét: Khi kiểm tra bằng phương pháp kiểm tra theo điều kiện cần xem xét kết hợp các điều kiện với nhau.  Vòng lặp (loop) Là phương pháp tập trung vào tính hợp lệ của các cấu trúc vòng lặp. 31 Hình 10: Kiểm thử vòng lặp - Các bước cần kiểm tra cho vòng lặp đơn: + Bỏ qua vòng lặp. + Lặp một lần. + Lặp hai lần. + Lặp m lần (m<n). + Lặp (n-1), n, (n+1) lần. Trong đó n là số lần lặp tối đa của vòng lặp. - Các bước cần kiểm tra cho vòng lặp dạng lồng nhau: + Khởi đầu với vòng lặp nằm bên trong nhất. Thiết lập các tham số lặp cho các vòng lặp bên ngoài về giá trị nhỏ nhất. + Kiểm tra với tham số min+1, 1 giá trị tiêu biểu, max-1 và max cho vòng lặp bên trong nhất trong khi các tham số lặp của các vòng lặp bên ngoài là nhỏ nhất. + Tiếp tục tương tự với các vòng lặp liền ngoài tiếp theo cho đến khi tất cả vòng lặp bên ngoài được kiểm tra. - Các bước cần kiểm tra cho vòng lặp nối tiếp: + Nếu các vòng lặp là độc lập với nhau thì kiểm tra như trường các vòng lặp dạng 32 đơn, nếu không thì kiểm tra như trường hợp các vòng lặp lồng nhau. Ví dụ: // LOOP TESTING EXAMPLE PROGRAM import java.io.*; class LoopTestExampleApp { // ------------------ FIELDS ---------------------- public static BufferedReader keyboardInput = new BufferedReader(new InputStreamReader(System.in)); private static final int MINIMUM = 1; private static final int MAXIMUM = 10; // ------------------ METHODS --------------------- /* Main method */ public static void main(String[] args) throws IOException { System.out.println("Input an integer value:"); int input = new Integer(keyboardInput.readLine()).intValue(); int numberOfIterations=0; for(int index=input;index >= MINIMUM && index <= MAXIMUM;index++) { numberOfIterations++; } // Output and end System.out.println("Number of iterations = " + numberOfIterations); } } Giá trị đầu vào Kết quả (Số lần lặp) 11 0 (bỏ qua vòng lặp) 10 1 (chạy 1 lần lặp) 9 2 (chạy 2 lần lặp) 5 6 (trường hợp chạy m lần lặp khi m<n) 2 9 (chạy N-1 lần lặp) 1 10 (chạy N lần lặp) 0 0 (bỏ qua vòng lặp) iv. Ưu điểm / Nhược điểm  Ưu điểm  Kiểm tra được toàn bộ chương trình nguồn  Phát hiện lỗi tại chỗ  Tự động hóa kiểm thử 33  Chính xác: “Việc thực hiện một white box testing tốt có thể đưa đến một chương trình đúng tuyệt đối.”  Nhược điểm  Yêu cầu người kiểm thử phải am hiểu cấu trúc mã lệnh chương trình. Do đó đòi hỏi tài nguyên nhân lực và máy tốn kém.  Có khả năng tồn tại các tổ hợp lệnh khác nhau gây lỗi  Không kiểm thử hết đường đi với các vòng lặp lớn, phức tạp  Khó thực hiện và chi phí thực hiện cao v. Thiết kế trường hợp thử trên JUnit Bài toán tài khoản ngân hàng:  Xây dựng lớp BankAccount:  Phân tích bài toán: 34 35  Xây dựng các TestCase:  BankAccount(300,100,0)  testLimit:  testLimit : 150  testLowest:  testLowest : 400  testWithdraw:  testWithdraw : 50  testWithdraw0 : 0  testWithdrawSmaller0 : -10  testDeposit:  testDeposit : 100  testDeposit0 : 0  testDepositSmaller0 : -10 3. Kiểm thử hộp xám (Gray Box Testing). i. Định nghĩa Gray Box Testing là một phương pháp kiểm thử phần mềm được kết hợp giữa Phương pháp Kiểm thử Black Box (hộp đen) và White Box (hộp trắng). Trong Kiểm thử hộp đen, Tester kiểm thử các hạng mục mà không cần biết cấu trúc bên trong của nó, còn trong Kiểm thử Hộp trắng thì Tester biết được cấu trúc bên trong của chương trình. Trong Kiểm thử Hộp xám, cấu trúc bên trong sản phẩm chỉ được biết một phần, Tester có thể truy cập vào cấu trúc dữ liệu bên trong và thuật toán của chương trình với mục đích là để thiết kế test case, nhưng khi test thì test như là người dùng cuối hoặc là ở mức hộp đen. Được gọi là Gray Box Testing vì trong chương trình phần mềm, mắt của Tester giống như hộp xám/bán trong suốt - nhìn qua hộp này ta chỉ có thể thấy được một phần. ii. Ứng dụng Mặc dù phương pháp Gray Box Testing có thể ứng dụng vào nhiều mức test khác nhau nhưng chủ yếu nó hữu dụng trong mức Integration Testing - kiểm thử tích hợp. iii. Ưu điểm và Nhược điểm Ưu điểm và nhược điểm của Kiểm thử Hộp xám được quyết định dựa vào sự kết hợp các ưu điểm của Black Box Testing và White Box Testing. 36 V. Tổng kết Kiểm thử phần mềm là một phần nhỏ trong xây dựng, phát triển hệ thống thông tin nhưng lại là phần đặc biệt quan trọng nếu bạn muốn phát triển một ứng dụng phức tạp. “Đôi khi một hại bụi nhỏ cũng có thể làm hỏng cả bữa tiệc lớn” Thật tuyệt nếu bạn sử dụng một sản phẩm của công nghệ mà không phải thốt lên rằng “What is this? ”. Điều đó vẫn làm đau đầu các nhà phát triển trong đó có cả lập trình viên cũng như các tester. 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 khá 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. Qua tìm hiểu và xây dựng đề tài, chúng em đã có được những hiểu biết nhất định về một kỹ thuật không thể bỏ qua trong kỹ thuật phần mềm: Kỹ thuật kiểm thử. Những điểm đạt được:  Hiểu được tổng quan về kiểm thử phần mềm: Các khái niệm cơ bản, các phương pháp kiểm thử, các vấn đề liên quan,  Các chiến lược kiểm thử phần mềm:  Kiểm thử hộp đen  Kiểm thử hộp trắng  Kiểm thử hộp xám  Hiểu được cấu trúc JUnit Framework.  Sử dụng JUnit xây dựng kiểm thử trong lập trình java: áp dụng các phương pháp đã tìm hiểu xây dựng testcase cho bài toán cụ thể: Bài toán tài khoản ngân hàng Nhóm đã cố gắng xây dựng bài nghiên cứu hoàn chỉnh tuy nhiên không thể tránh khỏi những hạn chế thiếu sót, rất mong nhận được sự góp ý của cô để bài nghiên cứu của chúng em được hoàn thiện hơn. Thay mặt nhóm nghiên cứu, em xin chân thành cảm ơn! NT Nguyễn Chí Công 37 VI. Phụ lục Bảng phân công công việc nghiên cứu đề tài: Thành viên Nhiệm vụ Nguyễn Khắc Hưng Tìm hiểu chung về kiểm thử phần mềm, quá trình kiểm thử phần mềm Giới thiệu về chung về JUnit Framework: - Định nghĩa - Các đặc điểm Nguyễn Chí Công (20080316) Phân tích cấu trúc lớp trong JUnit Phân tích kĩ thuật kiểm thử hộp trắng - Bản chất - Các phương pháp Cài đặt WBT trong Java sử dụng JUnit Framework Tổng hợp và viết báo cáo Trần Văn Bích Phân tích kĩ thuật kiểm thử hộp đen: - Bản chất, đặc điểm - Các phương pháp - Phân tích ví dụ Bùi Huy Thắng Phân tích kĩ thuật kiểm thử hộp xám 38 TÀI LIỆU THAM KHẢO 1. The Art of Software Testing, Glenford J. Myers, Second Edition, John Wiley and Sons, Inc. 2. Software Engineering - A Practitioner’s Approach, Roger S.Pressman, Sixth Edition, Ph.D, McGraw-Hill, Inc. 3. A Practitioner's Guide to Software Test Design, Lee Copeland, First Edition, Artech House Publishers Boston, London. 4. Effective methods for Software Testing, William E. Perry, 3rd Edition, Wiley Publishing, Indian. 5. Software Testing, Ron Patton, Second Edition, Sam Publishing. 6. 7. 8. 9. Một số trang web về kiểm thử phần mềm khác.