Nghiên cứu công cụ kiểm thử open source jfunc

Kiểm thử phần mềm là sự kiểm tra thông qua việc thực hiện chương trình, được tiến hành sau khi đã phát triển chương trình (mã nguồn), để phát hiện khuyết tật (lỗi) của hệ thống (đặc biệt là lỗi lập trình). Từ đó để có biện pháp sửa lỗi nhằm làm cho hệ thống ngày càng hoàn thiện. Đảm bảo chất lựợng phần mềm. Kiểm thử phần mềm đứng ở vị trí hết sức nhạy cảm, nó là bước đệm giữa giai đoạn xây dựng phần mềm và sử dụng phần mềm, trước khi giao sản phẩm hoàn chỉnh cho khách hàng

Nghiên cứu công cụ kiểm thử open source Jfunc TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI KHOA CÔNG NGHỆ THÔNG TIN BÁO CÁO THỰC TẬP TỐT NGHIỆP Đề tài : Nghiên cứu công cụ kiểm thử open source Jfunc trang1 Nghiên cứu công cụ kiểm thử open source Jfunc MỤC LỤC I TÓM LƯỢC BÁO CÁO II GIỚI THIỆU III PHẠM VI CỦA DỰ ÁN IV ĐẶC TẢ YÊU CẦU VÀ THIẾT KẾ V KIỂM THỬ V.a LẬP KẾ HOẠCH KIỂM THỬ V.b TIẾN TRÌNH KIỂM THỬ VI KẾT LUẬN VII LỜI CẢM ƠN I TÓM LƯỢC BÁO CÁO I.1 Đề tài: trang2 Nghiên cứu công cụ kiểm thử open source Jfunc - Nghiên cứu Test function - Sử dụng công cụ JFunc để nghiên cứu , tìm ưu điểm, nhược điểm và hướng cải tiến I.2 Công cụ: T ool name: Jfunc1.1 Địa chỉ download: http://sourceforge.net/projects/jfunc/ I.3 Nguồn tham khảo Nguồn tham khảo : www.DBunit.org trang web này nói về phần mềm test opensource DBunit ngoài ra nó còn giới thiệu về các phần mềm mã nguồn mở khác từ đây ta liên kết đến trang www.sourceforge.net là nơi lưu trữ phần mềm kiểm thử Jfunc SourceForge.net là một mã nguồn kho, là một địa điểm tập trung cho phát triển phần mềm để kiểm soát và quản lý các phần mềm mã nguồn mở phát triển SourceForge.net được điều hành bởi SourceForge, Inc Tính đến tháng tám SourceForge.net có hơn 180.000 dự án và hơn 1,9 triệu người dùng đăng ký SourceForge.net đã được cung cấp miễn phí truy cập để lưu trữ và các công cụ cho các nhà phát triển phần mềm tự do / phần mềm mã nguồn mở trong nhiều năm, và đã trở nên nổi tiếng như vậy trong phát triển cộng đồng cho các dịch vụ này SourceForge.net cạnh tranh với các nhà cung cấp dịch vụ như RubyForge, Tigris.org, BountySource, BerliOS, JavaForge và GNU Savannah Tên miền sourceforge.net thu hút được ít nhất là 28 triệu khách hàng năm 2008 do Compete.com khảo sát SourceForge.net cung cấp không gian lưu trữ cho một dự án để như là một wiki, MySQL cơ sở dữ liệu, quản lý phiên bản mã nguồn với CVS hay Subversion, và thậm chí cả trang web của mình tại các vị trí tên miền phụ Tải Jfunc tại địa chỉ: http://sourceforge.net/projects/jfunc/ : trang3 Nghiên cứu công cụ kiểm thử open source Jfunc II GIỚI THIỆU II.1 Kiểm thử phần mềm là gì Kiểm thử phần mềm là sự kiểm tra thông qua việc thực hiện chương trình, được tiến hành sau khi đã phát triển chương trình (mã nguồn), để phát hiện khuyết tật (lỗi) của hệ thống (đặc biệt là lỗi lập trình) Từ đó để có biện pháp sửa lỗi nhằm làm cho hệ thống ngày càng hoàn thiện Đảm bảo chất lựợng phần mềm Kiểm thử phần mềm đứng ở vị trí hết sức nhạy cảm, nó là bước đệm giữa giai đoạn xây dựng phần mềm và sử dụng phần mềm, trước khi giao sản phẩm hoàn chỉnh cho khách hàng II.2 Các mức độ kiểm thử phần mềm trang4 Nghiên cứu công cụ kiểm thử open source Jfunc Hình1: trình bày các mức độ kiểm thử phần mềm Thực tế, kiểm thử phần mềm không đơn giản như nhiều người thường nghĩ, công việc này có nhiều mức độ khác nhau và có mối tương quan với các chặng phát triển trong dự án phát triển phần mềm Hình 1 cho thấy 4 mức độ cơ bản của kiểm thử phần mềm và hình 2 cho thấy mối tương quan với các chặng phát triển trong mô hình V-model Phần sau sẽ làm rõ chi tiết về các mức độ kiểm thử phần mềm 1 Unit Test – Kiểm tra mức đơn vị Để có thể hiểu rõ về Unit Test, khái niệm trước tiên ta cần làm rõ: thế nào là một đơn vị phần mềm (Unit)? Một đơn vị là một thành phần phần mềm nhỏ nhất mà ta có thể kiểm tra được Theo định nghĩa này, các hàm (Function), thủ tục (Procedure), lớp (Class), hoặc các phương thức (Method) đều có thể được xem là đơn vị Vì đưon vị được chọn để kiểm tra thường có kích thước nhỏ và chức năng hoạt động đơn giản, chúng ta không khó khăn gì trong việc tổ chức, kiểm tra, ghi nhận và phân tích kết quả kiểm tra Nếu phát hiện lỗi, việc xác định nguyên nhân và khắc phục cũng tương đối dễ dàng vì chỉ khoanh vùng trong một đơn thể đang kiểm tra Một nguyên lý đúc kết từ thực tiễn: thời gian tốn cho kiểm thử đơn trang5 Nghiên cứu công cụ kiểm thử open source Jfunc vị(Unit Test) sẽ được đền bù bằng việc tiết kiệm rất nhiều thời gian và chi phí cho việc kiểm tra và sửa lỗi ở các mức kiểm tra sau đó 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 Thông thường, Unit Test đòi hỏi kiểm tra viên có kiến thức về thiết kế và code của chương trình Mục đích của Unit Test là bảo đảm thông tin được xử 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 đơn vị Điều này thường đòi hỏi tất cả các nhánh bên trong đưon vị đề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 đơn vị, ví dụ: chuỗi các lệnh sau điều kiện If và nằm giữa then else là một nhánh Thực tế việc chọn lựa các nhánh để đơn giản hóa việc kiểm tra và quét hết đơn vị đòi hỏi phải có kỹ thuật, đôi khi phải dùng thuật toán để chọn lựa Cũng như các mức kiểm tra khác, Unit Test cũng đòi hỏi phải chuẩn bị trước các tình huống (test case) hoặc kịch bản (script), trong đó chỉ định rõ dữ liệu vào, các bước thực hiện và dữ liệu mong chờ sẽ xuất ra Các test case và script này nên được giữ lại để tái sử dụng 2 Integration Test – Kiểm thử tích hợp kiểm thử tích hợp: kết hợp các thành phần của một ứng dụng và kiểm tra như một ứng dụng đã hoàn thành Trong khi Unit Test kiểm tra các thành phần và đơn vị 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 Integration Test có 2 mục tiêu chính: • 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 tra ở mức hệ thống (System Test) Trong Unit Test, lập trình viên cố gắng phát hiện lỗi liên quan đến chức năng và trang6 Nghiên cứu công cụ kiểm thử open source Jfunc cấu trúc nội tại của Unit Có một số phép kiểm tra đơn giản trên giao tiếp giữa Unit với các thành phần liên quan khác, tuy nhiên mọi giao tiếp liên quan đến Unit thật sự được kiểm tra đầy đủ khi các Unit tích hợp với nhau trong khi thực hiện Integration Test Trừ một số ít ngoại lệ, Integration Test chỉ nên thực hiện trên những đơn vị đã được kiểm tra cẩn thận trước đó bằng Unit Test, và tất cả các lỗi mức đơn vị đã được sửa chữa Một số người hiểu sai rằng đơn vị một khi đã qua giai đoạn Unit Test với các giao tiếp giả lập thì không cần phải thực hiện Integration Test nữa Thực tế việc tích hợp giữa các Unit dẫn đến những tình huống hoàn toàn khác Một chiến lược cần quan tâm trong Integration Test là nên tích hợp dần từng Unit Một Unit tại một thời điểm được tích hợp vào một nhóm các Unit khác đã tích hợp trước đó và đã hoàn tất (passed) các đợt Integration Test trước đó Lúc này, ta chỉ cần kiểm tra giao tiếp của đơn vị mới thêm vào với hệ thống các Unit đã tích hợp trước đó, điều này làm cho số lượng kiểm tra sẽ giảm đi rất nhiều, sai sót sẽ giảm đáng kể Có 4 loại kiểm tra trong Integration Test: • Kiểm tra cấu trúc (structure): Tương tự White Box Test (kiểm tra nhằm bảo đảm các thành phần bên trong của một chương trình chạy đúng), chú trọng đến hoạt động của các thành phần cấu trúc nội tại của chương trình chẳng hạn các lệnh và nhánh bên trong • Kiểm thử chức năng (functional): Tương tự Black Box Test (kiểm tra chỉ chú trọng đến chức năng của chương trình, không quan tâm đến cấu trúc bên trong), chỉ khảo sát chức năng của chương trình theo yêu cầu kỹ thuật • Kiểm thử hiệu năng (performance): Kiểm tra việc vận hành của hệ thống • Kiểm thử khả năng chịu tải (stress): Kiểm tra các giới hạn của hệ thống 3 System Test - Kiểm tra mức hệ thống trang7 Nghiên cứu công cụ kiểm thử open source Jfunc Mục đích System Test là kiểm tra 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 tra 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 tra đò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 tra 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 tra viên (tester) bắt đầu kiểm tra 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 tra 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 tra 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 tra để chấp nhận (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 tra viên hoàn toàn độc lập với nhóm phát triển dự án trang8 Nghiên cứu công cụ kiểm thử open source Jfunc Bản thân System Test lại gồm nhiều loại kiểm tra khác nhau (xem hình 3), 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ử khả năng vận hành (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 • Kiểm thử cấu hình (Configuration Test) • Kiểm thử khả năng 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 kiểm thử trên rất quan trọng: bảo đảm hệ thống đủ khả năng làm việc trong môi trường thực Lưu ý 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 Kiểm thẻ Yêu cầu chấp nhận 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, trưởng dự án sẽ quyết định áp dụng những loại kiểm thử nào Đặc tả Thiết kế chi tiết Thực thi code Kiểm thử hệ thống Kiểm thử tích hợp Kiểm thử đơn vị trang9 Nghiên cứu công cụ kiểm thử open source Jfunc Hình 2: Mối tương quan giữa phát triển và kiểm thử phần mềm 4 Acceptance Test - Kiểm tra chấp nhận sản phẩm 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 tra của System Test và Accepatnce 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 tra gọi là Alpha Test và Beta Test Với Alpha Test, người sử dụng kiểm tra 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 sử dụng để kiểm tra 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 tra 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 tra về chức năng thực hiện bởi nhóm trang10 Nghiên cứu công cụ kiểm thử open source Jfunc (6) Khi phát sinh thêm trường hợp thử thì nên thử lại những trường hợp thử trước đó để tránh ảnh hưởng lan truyền sóng II.5 Kiểm thử chức năng II.5.1 Thế nào là kiểm thử chức năng Kiểm thử chức năng (functional testing) còn gọi là kiểm thử hộp đen (black box testing).Kiểm thử này chỉ quan tâm dữ liệu đầu vào và đầu ra là sự kiểm thử sử dụng các kiểm thử được thiết kế dựa trên đặc tả yêu cầu, tài liệu người dùng nhằm mục đích phát hiện ra các khiếm khuyết Kiểm thử chức năng nhìn nhận mô đun được kiểm thử như là một hộp đen, và chỉ quan tâm đến chức năng (hành vi) của mô đun, tức là kiểm tra xem có hoạt động đúng với đặc tả hay không kiểm thử chức năng liên quan đến toàn bộ hệ thống II.5.2 Phương pháp kiểm thử chức năng • Xuất phát là việc kiểm thử đầu vào là dựa trên đặc tả chức năng • Những đầu mối được chứa từ những đặc tả • Những đầu mối sẽ hướng tới kiểm thử những yêu cầu • Kiểm thử những yêu cầu sẽ dẫn đến kiểm thử những đặc tả • Kiểm thử những đặc tả được sử dụng cho việc thực hiện thật sự những chương trình kiểm thử sau Đặc tả Hành vi mong muốn Test theo yêu cầu Chương trình đúng Test theo đặc tả Đầu ra Kiểm soát Test Đến khi đạt yêu cầu Chương trình Hành vi thực Hoặc Chương trình bị lỗi : Thực hiện đánh dấu và tiến hành với kiểm thử hoặc thiết lập trang13 chạy chế độ debug Nghiên cứu công cụ kiểm thử open source Jfunc Thông thường, không thể kiểm thử với mọi dữ liệu, chiến lược chung khi thiết kế dữ liệu kiểm thử là phân hoạch (dữ liệu) tương đương Phân hoạch tương đương chia miền dữ liệu vào ra thành các vùng, mà mỗi vùng chứa các dữ liệu có cùng hành vi Do đó, đối với mỗi vùng dữ liệu chỉ cần xây dựng một cách kiểm thử Miền dữ liệu vào được chia Miền dữ liệu vào thành những miền dữ liệu con 2 1 3 4 Kiểm thử quá nhiều dữ liệu đầu vào Có bốn kiểm thử dữ liệu vào, chọn một trong mỗi miền dữ liệu con Thế nào là phân vùng dữ liệu ?: • Dữ liệu đầu vào là một chương trình cung cấp những thông tin cho phân vùng Ví dụ : Giả sử chương trình p có một biến số nguyên X khi nhập giá trị X Nếu X=0 thì chương trình thực hiện công việc T2 trang14 Nghiên cứu công cụ kiểm thử open source Jfunc o Miền dữ liệu vào được giới hạn là miền lớn bởi vì giá trị X có thể là một số lớn o Tuy nhiên, ta mong chương trình P thực hiện cùng cách cho tất cả giá trị X=0 o Vì thế phân vùng chứa miền dữ liệu vào của chương trình P chứa hai miền con Một trường hợp kiểm thử X=-3 Lớp tương đương Lớp tương đương X=0 Trường hợp kiểm thử khác X=-15 Tất cả những trường hợp kiểm thử trong miền dữ liệu vào X=0 • Trong ví dụ trước, hai lớp tương đương không chồng lên nhau Nói cách khác hai miền này tách rời nhau • Khi hai miền dữ liệu được tách rời, điều đó là đầy đủ để lựa chọn một kiểm thử đầu vào từ mỗi lớp tương đương để kiểm thử chương trình • Một lớp tương đương được gọi là “phủ “ khi có ít nhất một kiểm thử được chọn từ nó • Mục đích của chúng ta trong phân vùng kiểm thử là “phủ” tất cả những lớp tương đương trang15 Nghiên cứu công cụ kiểm thử open source Jfunc II.4.3 a) Ưu điểm nhược điểm của kiểm thử chức năng Ưu điểm: Kiểm thử chức năng có thể giúp chúng ta - phát hiện sự thiếu sót chức năng - phát hiện khiếm khuyết - sai sót về giao diện giữa các mô đun - sự không hiệu quả của chương trình - các lỗi khởi tạo, lỗi kết thúc b) Nhược điểm: Kiểm thử chức năng chỉ dựa trên đặc tả nên không thể kiểm thử được các trường hợp không được khai báo trong đặc tả, không đảm bảo thử hết được các khối mã nguồn của mô đun Kiểm thử chức năng cũng không phát hiện được các đoạn mã yếu (có khả năng sinh lỗi với một trạng thái đặc biệt nào đó của hệ thống), và trong nhiều trường hợp việc đảm bảo xây dựng đầy đủ các cách kiểm thử là khó khăn Ví dụ, hàm tính trị tuyệt đối sau có thể thoát được kiểm thử chức năng tuy có lỗi int abs(int n) { if (n>0) return n; else (n