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 luận văn sản phẩm riêng cá nhân Tác giả 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 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 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 tê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 tế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ả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 .8 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 q 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 (Activites 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 tn Use Case Test Case 28 3.3.2 Xây dựng Điều kiện cần (Pre-conditon) 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 tn 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 Specificaton Identficaton Poor Obfuscaton Implementaton 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 tn 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 Figure 10: Xây dựng nội dung cho “Kết mong đợi” trường hợp Validaton fail 3 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 ln trọng đến q trình đầu vào đầu sản phẩm, hai trình tác động cách trực tếp đến mục tê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, gọi SRS (Software Requirement Specificaton) Với liệu chuẩn này, bên liên quan sử dụng tài liệu chung chuẩn nhất, cập nhật sử dụng xuyên suốt toàn dự án phần mềm Về 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 xây dựng theo yêu cầu mục tê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ử, gọi tester, với khóa đào tạo chuyên nghiệp để tế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 têu yêu cầu ban đầu, tránh lỗi coding, mang lại cho người sử dụng sản phẩm tương đối hồn hảo Trong q trình kiểm thử đầu sản phẩm, tất test case 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 tn từ SRS thành dạng test case, để hỗ trợ cho q 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 tn phần “Objectve” từ bảng phần “General Informaton” hình đâ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) thực hình đâ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) thực hình đâ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: Validaton Passed o Trong trường hợp Validton passed, hệ thống tếp tục đọc thông tn Business rule để lấy thơng tin sau:  Nếu Use Case dùng để cập nhật (update)/tạo (create) đối tượng mới, hệ thống tếp tục đọc thông tn của Updatng 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: Validaton Fail o Trong trường hợp Validton fail, hệ thống tếp tục đọc thông tn Validaton Rules phần Business Rules để lấy thơng tn cho Test Case o Mỗi điểm trình bày Validaton Rules trình bày thành Test Case o Nếu điểm Validaton 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 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ụ trình bày 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, trình bày dạng bullet 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 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, 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 Word, Excel, Power point, Visio, POI viết tắt "Poor Obfuscaton Implementaton" Các định dạng file Microsoft 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ó tếp đầu ngữ HSSF, XSSF, HPSF, Nhìn vào tiếp đầu ngữ class, bạn biết 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 Ofice XML (XLSX) HPSF (Horrible Property Set Format) Đọc thơng tn tóm tắt tài liệu từ file Microsoft Ofice 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 (implementaton) 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 Ofice Drawing Mô tả Apache POI áp dụng rộng rãi công việc thực tế sau: 36 4.1.2 Sử dụng Apache POI đọc file SRS Đọc từ file doc liệu XWPFParagaraph Nếu file đọ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 Preconditon, actor, objective tương ứng với usecase Ta có đầu vào USE CASE Đọc tế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 tn 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 hỗ trợ thao tác với API (ví dụ macro đồ thị) Cách giải đề nghị cho tính khơng hỗ trợ để tạo đối tượng tay mẫu Excel điền mẫu với liệu sau  Các tế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 ngôn ngữ biểu thức  Tạo nhiều sheet output  Dùng trực tế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 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 Registraton 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ụ sau: SRS.docx Khi sử dụng chương trình, tạo Test Case với test cases file 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ơ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 sau:  Các đặc tả yêu cầu nghiệp vụ trình bày rõ ràng theo khung Use Case đề cập phần Giới thiệu Use Case  Các đặc tả yêu cầu nghiệp vụ Use Case chia thành Business Rules sau: o Displaying/Showing rules o Validaton rules o Updatng rules o Saving rules o Deletng 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 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 Badget 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 | Internatonal Insttute 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 Purtlo, 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 ... phần mềm Trên giới có chuẩn chung cho tài liệu SRS SRS từ viết tắt Software Requirement Specificaton (Tài liệu đặc tả yêu cầu phần mềm) “Một tài liệu đặc tả yêu cầu phần mềm (SRS) mô tả hệ thống... 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 ký kết khách hàng, coi tài liệu cam kết bên đồng ý xây dựng phần mềm với chức tài liệu đặc tả  Software...ĐẠ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