Luận văn thạc sĩ tự động sinh bộ kiểm thử dựa trên tài liệu đặc tả yêu cầu nghiệp vụ SRS

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƢỜNG ĐẠI HỌC CÔNG NGHỆ TỰ ĐỘNG SINH BỘ KIỂM THỬ DỰA TRÊN TÀI LIỆU ĐẶC TẢ YÊU CẦU NGHIỆP VỤ SRS Tác giả: Bùi Thị Thúy LUẬN VĂN THẠC SĨ Chuyên ngành: HỆ THỐNG THÔNG TIN Hà Nội, 10/2016 ĐẠI HỌC QUỐC GIA HÀ NỘI TRƢỜNG ĐẠI HỌC CÔNG NGHỆ TỰ ĐỘNG SINH BỘ KIỂM THỬ DỰA TRÊN TÀI LIỆU ĐẶC TẢ YÊU CẦU NGHIỆP VỤ SRS Tác giả: Bùi Thị Thúy Giảng viên hƣớng dẫn: PGS.TS Trƣơng Ninh Thuận Hà Nội, 10/2016 LỜI CAM ĐOAN Tác giả xin cam đoan kết đạt đƣợc luận văn sản phẩm riêng cá nhân Tác giả đƣợc hƣớng dẫn khoa học PGS TS Trƣơng Ninh Thuận, không chép lại ngƣời khác Trong toàn nội dung luận văn, điều trình bày cá nhân đƣợc tổng hợp nhiều nguồn tài liệu Tất tài liệu tham khảo có xuất xứ rõ ràng đƣợc trích dẫn hợp pháp Tác giả xin hồn tồn chịu trách nhiệm chịu hình thức kỷ luật theo quy định cho lời cam đoan Hà Nội, ngày tháng năm 2016 HỌC VIÊN Bùi Thị Thúy LỜI CẢM ƠN Lời đầu tiên, em xin gửi lời cảm ơn chân thành sâu sắc tới PGS.TS Trƣơng Ninh Thuận, ngƣời thầy trực tiếp hƣớng dẫn tận tình đóng góp ý kiến quý báu cho em suốt trình thực luận văn tốt nghiệp Em xin gửi lời cảm ơn đến thầy cô giáo trƣờng Đại học Công nghệ - Đại học Công nghệ - Đại học Quốc gia Hà Nội, tận tâm truyền đạt kiến thức quý báu làm tảng cho em công việc sống Qua đây, em xin gửi lời cảm ơn đến đồng nghiệp công ty TNHH FPT Software giúp đỡ em trình làm thực nghiệm cho luận văn Cuối cùng, em xin đƣợc cảm ơn cha mẹ, ngƣời thân, bạn bè đồng nghiệp em tại, ngƣời ln bên em, khuyến khích động viên em sống học tập HỌC VIÊN Bùi Thị Thúy MỤC LỤC Danh mục ký hiệu chữ viết tắt Danh mục bảng Danh mục hình vẽ MỞ ĐẦU 10 CHƢƠNG 1: GIỚI THIỆU CHUNG 11 1.1 Nội dung luận văn 11 1.2 Cấu trúc luận văn 11 CHƢƠNG CÁC KHÁI NIỆM TỔNG QUAN 12 2.1 Giới thiệu tổng quan SRS 12 2.1.1 Khái niệm SRS 12 2.1.2 Vị trí SRS trình xây dựng phần mềm 13 2.1.3 Cấu trúc tổng quan SRS 14 2.2 Giới thiệu Use Case 14 2.2.1 Khái niệm Use Case 14 2.2.2 Vai trò Use Case SRS 15 2.2.3 Cấu trúc tổng quan Use Case 15 2.3 Giới thiệu tổng quan Test Case 18 2.3.1 Khái niệm Test Case 18 2.3.2 Vị trí Test Case trình xây dựng phần mềm 22 2.3.3 Cấu trúc tổng quan Test Case 22 CHƢƠNG GIẢI PHÁP XÂY DỰNG TEST CASE DỰA TRÊN SRS 24 3.1 Dữ liệu đầu vào 24 3.1.1 Thuộc tính Use Case 24 3.1.2 Luồng hoạt động (Activities Flow) 24 3.1.3 Các quy tắc nghiệp vụ (Business Rules) 25 3.2 Dữ liệu đầu 28 3.3 Phƣơng pháp thực 28 3.3.1 Xây dựng thông tin Use Case Test Case 28 3.3.2 Xây dựng Điều kiện cần (Pre-condition) cho Test Case 28 3.3.3 Xây dựng Actor cho Test Case: 29 3.3.4 Xây dựng thông tin cho Use Case ID, Test Case ID 29 3.3.5 Xây dựng Tên Test Case (Test Case Title) 30 3.3.6 Xây dựng Các bƣớc thực (Test Procedure) 30 3.3.7 Xây dựng kết mong đợi (Expected Result) 31 3.3.8 Xây dựng Test Case dựa bullet numbering 33 CHƢƠNG CÔNG NGHỆ SỬ DỤNG 35 1.1 POI Apache 35 4.1.1 Tính Apache POI 35 4.1.2 Sử dụng Apache POI đọc file SRS 37 4.2 JXLS 39 4.2.1 Giới thiệu 39 4.2.2 Tính năng, đặc điểm 40 4.2.3 Sử dụng JXLS để tạo file excel 40 KẾT LUẬN VÀ HƢỚNG PHÁT TRIỂN 43 TÀI LIỆU THAM KHẢO 44 Danh mục ký hiệu chữ viết tắt STT 10 11 12 13 Từ viết tắt SRS ID POI HSSF XSSF HPSF HWPF HSLF HDGF HPBF HSMF DDF XML Nghĩa đầy đủ Software Specification Identification Poor Obfuscation Implementation Horrible SpreadSheet Format XML SpreadSheet Format Horrible Property Set Format Horrible Word Processor Format Horrible Slide Layout Format Horrible DiaGram Format Horrible PuBlisher Format Horrible Stupid Mail Format Dreadful Drawing Format eXtensible Markup Language Ghi Danh mục bảng Table 1Cấu trúc Test Case thông thƣờng 20 Table 2: Thuộc tính Use Case 24 Table 3: Bảng mô tả luồng hoạt động Use Case 25 Danh mục hình vẽ Figure 1: Vị trí SRS quy trình sản xuất phần mềm 13 Figure 2: Use Case Diagram cho hệ thống điện thoại đơn giản 15 Figure 3: Vị trí Test Case q trình xây dựng phần mềm 22 Figure 4: Xây dựng thông tin Use Case Test Case 28 Figure 5: Xây dựng Điều kiện cần (Pre-condition) cho Test Case 29 Figure 6: Xây dựng Actor cho Test Case 29 Figure 7: Xây dựng nội dung cho “Tên Test Case” Test Case 30 Figure 8: Xây dựng nội dung cho “Các bƣớc thực hiện” Test Case 31 Figure 9: Xây dựng nội dung cho “Kết mong đợi” trƣờng hợp Validation passed 32 Figure 10: Xây dựng nội dung cho “Kết mong đợi” trƣờng hợp Validation fail 33 Figure 11: Business rules với điều kiện rẽ nhánh cha-con 34 Figure 12: Xây dựng Test Case dựa điều kiện rẽ nhánh cha-con 34 MỞ ĐẦU Ngày này, quy trình sản xuất phần mềm, ngồi khâu hình thành xây dựng sản phẩm, cơng ty chuyên sản xuất phần mềm trọng đến trình đầu vào đầu sản phẩm, hai q trình tác động cách trực tiếp đến mục tiêu chất lƣợng sản phẩm phần mềm Về trình đầu vào sản phẩm, số công ty phần mềm lớn xây dựng quy trình thu thập yêu cầu phần mềm xây dựng tài liệu chuẩn để làm đầu vào cho trình coding xây dựng sản phẩm Đầu trình tài liệu yêu cầu phần mềm, đƣợc gọi SRS (Software Requirement Specification) Với liệu chuẩn này, bên liên quan sử dụng nhƣ tài liệu chung chuẩn nhất, đƣợc cập nhật nhƣ sử dụng xuyên suốt tồn dự án phần mềm Về q trình đầu sản phẩm, hầu hết công ty xây dựng đội ngũ kiểm thử chất lƣợng sản phẩm, tồn quy trình hoạt động sản phẩm để đảm bảo sản phẩm phần mềm đƣợc xây dựng theo nhƣ yêu cầu mục tiêu đề ban đầu Hiện nay, công ty phần mềm lớn nhỏ, họ xây dựng đội ngũ kiểm thử, đƣợc gọi tester, với khóa đào tạo chuyên nghiệp để tiến hành chạy test case sau sản phẩm hoàn thành, đảm bảo sau sản phẩm đƣa vào sử dụng với mục tiêu yêu cầu ban đầu, tránh đƣợc lỗi coding, mang lại cho ngƣời sử dụng sản phẩm tƣơng đối hoàn hảo Trong trình kiểm thử đầu sản phẩm, tất test case đƣợc tester viết tay, sau sử dụng test case cho việc kiểm thử Công việc công việc tƣơng đối tốn thời gian, sản phẩm phần mềm thƣờng có số lƣợng test case lớn, có sản phẩm phần mềm với quy mơ lớn lên đến hàng chục nghìn test case, điều vơ hình chung thƣờng mang lại áp lực vơ hình cho ngƣời làm công việc kiểm thử phần mềm Từ mong muốn nhu cầu thiết thực trên, mong muốn nghiên cứu xây dựng sản phẩm tự động chuyển hóa thơng tin từ SRS thành dạng test case, để hỗ trợ cho trình xây dựng test case chuẩn từ yêu cầu phần mềm, phục vụ cho trình kiểm thử phần mềm, giúp tiết kiệm thời gian cho tester việc viết test case 10 Ví dụ: [TC_121] 3.3.5 Xây dựng Tên Test Case (Test Case Title) Việc chuyển đổi nội dung Use Case sang “Tên Test Case” (Test Case Title) sử dụng thông tin phần “Objective” từ bảng phần “General Information” nhƣ hình dƣới đây: Figure 7: Xây dựng nội dung cho “Tên Test Case” Test Case 3.3.6 Xây dựng Các bước thực (Test Procedure) Việc chuyển đổi nội dung Use Case sang “Các bƣớc thực hiện” (Test Procedure) đƣợc thực nhƣ hình dƣới đây: 30 Figure 8: Xây dựng nội dung cho “Các bước thực hiện” Test Case 3.3.7 Xây dựng kết mong đợi (Expected Result) Việc chuyển đổi nội dung Use Case sang “Kết mong đợi” (Expected Result) đƣợc thực nhƣ hình dƣới đây:  Với bƣớc rẽ nhánh để kiểm tra điều kiện, cần chia thành Test Case với loại “Kết mong đợi” (Expected Result):  Expected Result 1: Validation Passed o Trong trƣờng hợp Validtion passed, hệ thống tiếp tục đọc thông tin Business rule để lấy đƣợc thơng tin nhƣ sau:  Nếu Use Case dùng để cập nhật (update)/tạo (create) đối tƣợng mới, hệ thống tiếp tục đọc thông tin của Updating Rules/Saving Rules phần Business Rules điền thông tin tƣơng ứng Business Rules vào Test Case 31 Figure 9: Xây dựng nội dung cho “Kết mong đợi” trường hợp Validation passed  Expected Result 2: Validation Fail o Trong trƣờng hợp Validtion fail, hệ thống tiếp tục đọc thông tin Validation Rules phần Business Rules để lấy đƣợc thông tin cho Test Case o Mỗi điểm đƣợc trình bày Validation Rules đƣợc trình bày thành Test Case o Nếu điểm Validation Rules có nhiều cấp độ, hệ thống chia Test Case theo cấp độ nhỏ nhất, gộp cập độ với cấp độ cha nhƣ sau: 32 Figure 10: Xây dựng nội dung cho “Kết mong đợi” trường hợp Validation fail 3.3.8 Xây dựng Test Case dựa bullet numbering Đối với yêu cầu nghiệp vụ đƣợc trình bày dƣới dạng bullet numbering định dạng văn word, hệ thống phân chia theo bullet numbering điều kiện rẽ nhánh bé (chứa cụm từ “If” “Else” “Otherwise” Hệ thống kết hợp bullet cha bullet thành Test Case Ví dụ: Chúng ta có điều kiện rẽ nhánh, đƣợc trình bày dƣới dạng bullet nhƣ sau: 33 Figure 11: Business rules với điều kiện rẽ nhánh cha-con Hệ thống phân tích điều kiện rẽ nhánh, tìm đến điều kiện có cấp độ bé nhất, sau kết hợp với điều kiện cha để tạo thành Test Case riêng biệt nhƣ sau: Figure 12: Xây dựng Test Case dựa điều kiện rẽ nhánh cha-con 34 CHƢƠNG CƠNG NGHỆ SỬ DỤNG Nhƣ trình bày trên, luận văn này, sử dụng thử nghiệm mã nguồn mở POI việc đọc ghi liệu cho Microsoft Word Microsoft Excel ngơn ngữ lập trình Java 1.1 POI Apache Apache POI thƣ viện mã nguồn mở Java, đƣợc cung cấp Apache, thƣ viện đầy sức mạnh giúp bạn làm việc với tài liệu Microsoft nhƣ Word, Excel, Power point, Visio, POI viết tắt "Poor Obfuscation Implementation" Các định dạng file Microsoft đƣợc giấu kín Những kỹ sƣ Apache phải cố gắng để tìm hiểu nó, họ thấy Microsoft tạo định dạng phức tạp cách khơng cần thiết 4.1.1 Tính Apache POI Apache POI hỗ trợ bạn làm việc với định dạng Microsoft, class thƣờng có tiếp đầu ngữ HSSF, XSSF, HPSF, Nhìn vào tiếp đầu ngữ class, bạn biết đƣợc class hỗ trợ loại định dạng Ví dụ để làm việc với định dạng Excel (XLS) bạn cần class:  HSSFWorkbook  HSSFSheet  HSSFCellStyle 35  HSSFDataFormat  HSSFFont  STT Tiếp đầu ngữ HSSF (Horrible SpreadSheet Format) Đọc ghi file định dạng Microsoft Excel (XLS) XSSF (XML SpreadSheet Format) Đọc ghi định dạng file Open Office XML (XLSX) HPSF (Horrible Property Set Format) Đọc thông tin tóm tắt tài liệu từ file Microsoft Office HWPF (Horrible Word Processor Format) Mục đích đọc ghi file định dạng Microsoft Word 97 (DOC) HSLF (Horrible Slide Layout Format) Một thực Java cho file Microsoft PowerPoint HDGF (Horrible DiaGram Format) Các thực (implementation) Java khởi đầu cho file nhị phân Microsoft Visio HPBF (Horrible PuBlisher Format) Một thực Java cho file Microsoft Publisher HSMF (Horrible Stupid Mail Format) Một thực Java cho file Microsoft Outlook MSG DDF (Dreadful Drawing Format) Một package cho giải mã định dạng Microsoft Office Drawing Mô tả Apache POI đƣợc áp dụng rộng rãi công việc thực tế nhƣ sau: 36 4.1.2 Sử dụng Apache POI đọc file SRS Đọc từ file doc liệu XWPFParagaraph Nếu file đọc đƣợc heading kiểm tra xem có phải heading có value “USE CASE” khơng Nếu header USE CASES tiến hành đọc danh sách table USE CASE 37 Nếu table USE CASE tiến hành đọc Precondition, actor, objective tƣơng ứng với usecase Ta có đầu vào USE CASE Đọc tiếp bảng RULES sau bảng USE CASE Ta có đầu vào RULES 38 4.2 JXLS 4.2.1 Giới thiệu  Jxls thƣ viện Java hỗ trợ cho việc xuất file excel Jxls sử dụng đánh dấu đặc biệt Excel mẫu để xác định định dạng đầu bố trí liệu  Java có nhiều mã nguồn mở thƣ viện thƣơng mại để tạo tập tin Excel (của mã nguồn mở đáng nói Apache POI Java Excel API  Những thƣ viện khác phải sử dụng nhiều câu lệnh Java để tạo file Excel đơn giản  Thông thƣờng, bạn phải tự thiết lập cho định dạng liệu cho bảng tính Tùy thuộc vào phức tạp cách bố trí báo cáo liệu định 39 dạng mã Java trở nên phức tạp khó khăn để gỡ lỗi trì Ngồi khơng phải tất tính Excel đƣợc hỗ trợ đƣợc thao tác với API (ví dụ macro đồ thị) Cách giải đề nghị cho tính khơng đƣợc hỗ trợ để tạo đối tƣợng tay mẫu Excel điền mẫu với liệu sau  Các tiếp cận JXLS với Excel mức độ cao Tất bạn cần làm làm việc với Jxls để xác định tất định dạng báo cáo bạn cách bố trí liệu mẫu Excel chạy động Jxls cung cấp với liệu để điền vào mẫu Mã bạn cần phải viết hầu hết trƣờng hợp lời gọi đơn giản động Jxls với cấu hình thích hợp 4.2.2 Tính năng, đặc điểm Các tính đặc điểm bật JXLS:  Định dạng Excel đầu XML nhị phân (phụ thuộc vào mức độ phát triển)  Tạo thành tập hợp dòng cột  Xây dựng đầu có điều kiện  Đánh dấu đƣợc ngơn ngữ biểu thức  Tạo nhiều sheet output  Dùng trực tiếp công thức Excel  Sử dụng công thức kèm tham số  Hỗ trợ việc Merge Cell  Sử cụng comments markup Excel để định nghĩa công thức  Tùy chỉnh công thức 4.2.3 Sử dụng JXLS để tạo file excel Test Case Ta có định dạng file Excel để sử dụng làm template output: 40 Sử dụng comment excel để định nghĩa liệu truyền vào:  Items: danh sách liệu đƣợc in output  lastCell: cell cuối template output liệu Thực đọc file template (output) ghi file Result.xlsx Ta có output đầu tƣơng ứng: 41 Hiện tại, sử dụng tài liệu SRS Applicant Registration Module (Đăng ký ngƣời dùng) dự án phần mềm công ty FPT Software làm với khách hàng Singapore để làm ví dụ minh họa cho việc sinh test cases  File đầu vào chƣơng trình tài liệu đặc tả yêu cầu nghiệp vụ nhƣ sau: SRS.docx  Khi sử dụng chƣơng trình, tạo đƣợc Test Case với test cases nhƣ file dƣới result.xlsx 42 KẾT LUẬN VÀ HƢỚNG PHÁT TRIỂN Trong luận văn này, tác giả hồn thành đƣợc cơng việc cụ thể sau:  Hoàn thiện việc nghiên khái niệm chức liên quan SRS Test Case  Xây dựng công thức sinh Test Case từ yêu cầu nghiệp vụ  Xây dựng chƣơng trình sinh tự động Test Case từ tài liệu đặc tả yêu cầu nghiệp vụ SRS Hiện nay, chƣơng trình giải tốn với điều kiện nhƣ sau:  Các đặc tả yêu cầu nghiệp vụ đƣợc trình bày rõ ràng theo khung Use Case nhƣ đề cập phần Giới thiệu Use Case  Các đặc tả yêu cầu nghiệp vụ Use Case đƣợc chia thành Business Rules nhƣ sau: o Displaying/Showing rules o Validation rules o Updating rules o Saving rules o Deleting rules Định hƣớng tƣơng lai tác giả mong muốn phát triển đề tài để tự động sinh Test Case cho chức hệ thống phức tạp nhƣ Batch Job Timer Job hệ thống, chức chạy không cần tác động user, chức trả kết trừu tƣợng 43 TÀI LIỆU THAM KHẢO Glenford J Myers, Tom Badgett and Corey Sandler (2015), The Art of Software Testing, Third Edition Practice Book for the Paper-based GRE ® revised General Test (PDF), Second Edition Glenn Fulcher and Fred Davidson (2006), Language Testing and Assessment: An Advanced Resource Book Rekard Edgren (2012), The Little Black Book on Test Design Cem Kaner and Jack Falk, Testing Computer Software IIBA | International Institute of Business Analysis (2015), A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide), Third Edition IEEE Computer Society (1998), IEEE Recommended Practice for Software Requirements Specifications John D Gannon, James M Purtilo, Marvin V Zelkowitz (2001), MarylandSOFTWARE SPECIFICATION: A Comparison of Formal Methods, Department of Computer Science University of Maryland College Park Ivar Jacobson, Ian Spence, Kurt Bittner (2011), USE-CASE 2.0 - The Guide to Succeeding with Use Cases 10 Donald Bell and IBM Glabal Service (2003), UML basics: An introduction to the Unified Modeling Language 11 Addison-Wesley (2001), Writing effective Use Cases 44 ... tiêu sinh tự động Test Case dựa liệu đầu vào tài liệu đặc tả yêu cầu nghiệp vụ SRS Bộ Test Case đƣợc sử dụng đầu vào cho trình kiểm thử phần mềm quy trình sản xuất phần mềm Trong khuân khổ luận văn. ..ĐẠI HỌC QUỐC GIA HÀ NỘI TRƢỜNG ĐẠI HỌC CÔNG NGHỆ TỰ ĐỘNG SINH BỘ KIỂM THỬ DỰA TRÊN TÀI LIỆU ĐẶC TẢ YÊU CẦU NGHIỆP VỤ SRS Tác giả: Bùi Thị Thúy Giảng viên hƣớng dẫn: PGS.TS Trƣơng... yêu cầu nghiệp vụ khách hàng, từ xay a dựng lên tài liệu đặc tả yêu cầu nghiệp vụ (SRS) Tài liệu sau đƣợc ký kết khách hàng, coi nhƣ tài liệu cam kết bên đồng ý xây dựng phần mềm với chức nhƣ tài