Tóm tắt 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

Trong khuân khổ luận văn này, tác giả mong muốn đề cập đến những khái niệm căn bản liên quan đến SRS và Test Case, các lý thuyết chung, và đưa ra những kết quả nghiên cứu bước đầu. Tác giả cũng mong muốn có thể giải quyết được vấn đề sinh Test Case từ các yêu cầu phần mềm, từ đó phát triển được bộ công cụ sinh Test Case tự động, đưa ra những giải pháp công nghệ để có thể giải quyết bài toán đặt ra.

ĐẠ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 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 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 12 2.1.3 Cấu trúc tổng quan SRS 12 2.2 Giới thiệu Use Case 13 2.2.1 Khái niệm Use Case 13 2.2.2 Vai trò Use Case SRS 13 2.2.3 Cấu trúc tổng quan Use Case 13 2.3 Giới thiệu tổng quan Test Case 13 2.3.1 Khái niệm Test Case 13 2.3.2 Vị trí Test Case trình xây dựng phần mềm 14 2.3.3 Cấu trúc tổng quan Test Case 15 CHƢƠNG GIẢI PHÁP XÂY DỰNG TEST CASE DỰA TRÊN SRS 16 3.1 Dữ liệu đầu vào 16 3.1.1 Thuộc tính Use Case 16 3.1.2 Luồng hoạt động (Activity Flow) 16 3.1.3 Các quy tắc nghiệp vụ (Business Rules) 16 3.2 Dữ liệu đầu 17 3.3 Phƣơng pháp thực 17 CHƢƠNG CÔNG NGHỆ SỬ DỤNG 18 4.1 POI Apache 18 4.1.1 Tính Apache POI 18 4.1.2 Sử dụng Apache POI đọc file SRS 19 4.2 JXLS 21 4.2.1 Giới thiệu 21 4.2.2 Tính năng, đặc điểm 21 4.2.3 Sử dụng JXLS để tạo file excel 21 KẾT LUẬN VÀ HƢỚNG PHÁT TRIỂN 23 TÀI LIỆU THAM KHẢO 24 PHỤ LỤC 25 DANH MỤC CÁC KÝ HIỆU VÀ CHỮ VIẾT TẮT STT Từ viết tắt SRS ID POI HSSF XSSF HPSF 10 11 12 13 HSLF HDGF HPBF HSMF DDF XML HWPF Nghĩa đầy đủ Ghi 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 DANH MỤC BẢNG Table 1: Cấu trúc Test Case thông thƣờng 14 Table 2: Thuộc tính Use Case 16 DANH MỤC HÌNH VẼ Figure 1: Vị trí Test Case trình xây dựng phần mềm 15 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 hồn hảo Trong q 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 CHƢƠNG GIỚI THIỆU CHUNG 1.1 Nội dung luận văn Luận văn chƣơng trình phần mềm với mục 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 này, tác giả mong muốn đề cập đến khái niệm liên quan đến SRS Test Case, lý thuyết chung, đƣa kết nghiên cứu bƣớc đầu Tác giả mong muốn giải đƣợc vấn đề sinh Test Case từ yêu cầu phần mềm, từ phát triển đƣợc cơng cụ sinh Test Case tự động, đƣa giải pháp cơng nghệ để giải tốn đặt 1.2 Cấu trúc luận văn Cấu trúc luận văn đƣợc chia thành phần chính: Chƣơng 1: Giới thiệu tổng quan tốn nội dung luận văn Chƣơng 2: Đƣa khái niệm tổng quan đối tƣợng liên quan Chƣơng 3: Trình bày giải pháp sinh Test Case tự động Chƣơng 4: Giới thiệu công nghệ sử dụng Chƣơng 5: Kết luận định hƣớng phát triển Với nội dung đề cập trên, tác giả mong muốn cung cấp đầy đủ thơng tin để luận văn trở thành luận văn nghiên cứu với vấn đề đƣợc giải cách triệt để có định hƣớng phát triển lâu dài CHƢƠNG CÁC KHÁI NIỆM TỔNG QUAN 2.1 Giới thiệu tổng quan SRS 2.1.1 Khái niệm SRS Hiện nay, công ty phần mềm có xu hƣớng xây dựng tài liệu yêu cầu phần mềm chuẩn cho dự án phần mềm, để đảm bảo tất bên liên quan có hiểu biết đắn giống mục tiêu đầu sản phẩm 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 Specification (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 phần mềm đƣợc phát triển Nó đƣa yêu cầu chức phi chức năng, bao gồm tập hợp trƣờng hợp sử dụng để mô tả tƣơng tác ngƣời dùng mà sản phẩm phần mềm phải cung cấp” [1] SRS thiết lập sở cho thỏa thuận khách hàng nhà thầu nhà cung cấp bên liên quan (trong số dự án định hƣớng thị trƣờng, bên liên quan đơn vị tiếp thị phát triển) mong muốn mục tiêu họ làm sản phẩm phần mềm kèm theo điều mà họ khơng mong muốn có sản phẩm Tài liệu cung cấp sở thực tế cho việc ƣớc tính thời gian thực nhƣ chi phí, rủi ro lịch trình chi tiết cho việc xây dựng sản phẩm 2.1.2 Vị trí SRS q trình xây dựng phần mềm SRS đƣợc tạo giai đoạn đầu dự án, bên liên quan hình thành ý tƣởng xây dựng yêu cầu cho sản phẩm phần mềm Bên phát triển phần mềm cần tổ chức họp với bên liên quan để thu thập yêu cầu, từ xây dựng nên tài liệu đặc tả yêu cầu phần mềm, SRS Các SRS đƣợc coi nhƣ tài liệu chuẩn đƣợc sử dụng xuyên suốt suốt trình xây dựng phần mềm Bên sản xuất phần mềm coi nhƣ tài liệu chuẩn đƣợc thống bên liên quan, sử dụng cho toàn trình coding testing, nhƣ xây dựng tài liệu đầu cho sản phẩm nhƣ: Tài liệu hƣớng dẫn sử dụng, Bộ test case cho Unit test System test, v.v 2.1.3 Cấu trúc tổng quan SRS Một tài liệu SRS cần bao gồm đƣợc toàn nội dung đặc tả yêu cầu mà sản phẩm phần mềm cần có Một SRS thơng thƣờng cần có phần nhƣ sau:  Giới thiệu chung     Yêu cầu tổng quan Yêu cầu chức chi tiết Yêu cầu phi chức Phụ lục 2.2 Giới thiệu Use Case 2.2.1 Khái niệm Use Case Một Use Case tất cách thức sử dụng chức hệ thống để đạt đƣợc mục đích ngƣời dùng cụ thể Tập hợp tất Use Case cho cách thức hiệu để sử dụng hệ thống phần mềm Một Use Case là:  Một tập hợp tuần từ hành động mà hệ thống phần mềm thực thi để đƣợc kết mong muốn cho ngƣời dùng cụ thể  Xác định hành vị hệ thống để kết hợp với ngƣời dùng nhằm mục đích tạo giá trị cho ngƣời trình sử dụng hệ thống  Là đơn vị nhỏ hoạt động cung cấp kết có ý nghĩa cho ngƣời dùng  Là nơi để chứa đựng yêu cầu có liên quan đến 2.2.2 Vai trò Use Case SRS Trong SRS, Use Case đƣợc trình bày chi tiết phần “Yêu cầu chức chi tiết” 2.2.3 Cấu trúc tổng quan Use Case Một Use Case dùng để đặc tả chi tiết chức năng, đƣợc chia thành phần chi tiết nhƣ sau: Thông tin tổng quan (General Information), Luồng hoạt động (Activities Flow), Các quy tắc nghiệp vụ (Business Rules) Giả lập hình (Mockup Screen) 2.3 Giới thiệu tổng quan Test Case 2.3.1 Khái niệm Test Case Test Case, tập hợp điều kiện đƣợc coi nhƣ thử nghiệm để xác định liệu ứng dụng, hệ thống phần mềm tính có làm việc nhƣ thiết lập ban đầu hay không Các chế để xác định liệu chƣơng trình phần mềm hệ thống đƣợc thông qua thử nghiệm không đƣợc biết đến nhƣ quy trình kiểm thử Có thể cần nhiều trƣờng hợp thử nghiệm để xác định chƣơng trình phần mềm hệ thống đƣợc coi xem xét kỹ lƣỡng đầy đủ trƣớc phát hành bàn giao sản phẩm Hiện này, Việt Nam, công ty sản xuất phần mềm, Test Case hầu hết đƣợc xây dựng lƣu trữ file excel để thuận tiện cho việc quản lý chỉnh sửa nhƣ bàn giao bên liên quan Nội dung Test Case nhƣ sau: Req Id Test case Id Test case Title Test procedure Expected result Priority Test Round Result Test Round Result Req_3 [FN_121] Update Applicant Government Agency successfully - Not change the email Step 1: Click button at the top right of the INBOX page Step 2: Update valid data then click button Step 3: Input valid captcha then click button Step 4: Click button Profile screen is opened Submit registration form is displayed with captcha generated by the system Updated Confirmed page is displayed Update profile successfully and return Home page of Inbox High Fail Pass Remarks Table 1: Cấu trúc Test Case thông thường 2.3.2 Vị trí Test Case q trình xây dựng phần mềm Test Case đƣợc xây dựng giai đoạn gần cuối quy trình sản xuất phần mềm, khâu xây dựng tài liệu SRS, thiết kế lập trình gần nhƣ hồn thiện, Teste bắt đầu bắt tay vào xây dựng Test Case dựa yêu cầu nghiệp vụ đƣợc mô tả tài liệu SRS Sau đó, Test Case đƣợc đƣa vào thực thi trình kiểm thử phần mềm trƣớc chƣơng trình phần mềm đƣợc đƣa vào hoạt động thực tế Figure 1: Vị trí Test Case q trình xây dựng phần mềm 2.3.3 Cấu trúc tổng quan Test Case Một Test Case bao gồm bƣớc thực bƣớc thực tuần tự, dùng để kiểm thử tính đắn hành động/chức chƣơng trình phần mềm Các kết mong muốn đầu mong muốn hành động/chức phải đƣợc đề cập Test Case CHƢƠNG GIẢI PHÁP XÂY DỰNG TEST CASE DỰA TRÊN SRS 3.1 Dữ liệu đầu vào Việc xây dựng Test Case cho nhiều chức cho chƣơng trình phần mềm dựa thông tin đƣợc bao gồm tài liệu SRS, thơng tin dùng cho Test Case đƣợc lấy từ thông tin Use Case Các thông tin Use Case đƣợc sử dụng để xây dựng Test Case nhƣ sau: 3.1.1 Thuộc tính Use Case Thuộc tính Use Case SRS bao gồm thơng tin nhƣ sau: Objective: Mục đích Use Case Actor: Ngƣời thực Use Case Trigger: Hoạt động bắt đầu để thực Use Case Pre-condition: Điều kiện cần thiết để Use Case đƣợc thực Post-condition: Kết mong đợi sau Use Case đƣợc thực thành công Table 2: Thuộc tính Use Case 3.1.2 Luồng hoạt động (Activity Flow) Các thông tin Activity Flow đƣợc sử dụng để tạo nội dung “Các bƣớc thực thứ tự hành động” (Test Procedure) Test Case Trong Activity Flow Use Case SRS, tập trung vào bƣớc đƣợc thực bên phía ngƣời dùng (Actor), thay bƣớc thực bên phía hệ thống (system) Các thơng tin thực bên phía hệ thống đƣợc sử dụng để làm nội dung cho phần “Kết mong đợi” Test Case Các thông tin luồng hoạt động Use Case đƣợc sử dụng để xây dựng Các bƣớc thực (Test Procedure) Kết mong đợi (Expected Result) 3.1.3 Các quy tắc nghiệp vụ (Business Rules) Các quy tắc nghiệp vụ (Business Rules) thành phần Use Case Phần quy định điều kiện hiển thị, hoạt động nhƣ cách thức hoạt động Use Case Thơng thƣờng, Use Case bao gồm loại quy tắc nghiệp vụ nhƣ sau: Trong luận văn này, tác giả đề cập tới cách sử dụng loại quy tắc nghiệp vụ để xây dựng đƣợc Test Case Test Case cho chƣơng trình phần mềm 16 3.2 Dữ liệu đầu Từ thông tin Use Case đƣợc mô tả SRS, tác giả luận văn mong muốn xây dựng Test Case sử dụng thơng tin với thơng tin chi tiết nhƣ sau: Template TC.xlsx 3.3 Phƣơng pháp thực Trong Test Case, chúng tơi mong muốn xây dựng Test Case cho Use Case riêng biệt, gộp Test Case Use Case thành nhóm Nhƣ vậy, từ Use Case, xây dựng nên Test Case cho Use Case cụ thể theo quy luật 17 CHƢƠNG CÔNG NGHỆ SỬ DỤNG Nhƣ trình bày trên, luận văn này, tơi sử dụng mã nguồn mở POI việc đọc ghi liệu cho Microsoft Word Microsoft Excel ngơn ngữ lập trình Java 4.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 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 Mô tả 18 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 Apache POI đƣợc áp dụng rộng rãi công việc thực tế nhƣ sau: 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 Nếu table USE CASE tiến hành đọc Precondition, actor, objective tƣơng ứng với usecase 19 Ta có đầu vào USE CASE Đọc tiếp bảng RULES sau bảng USE CASE Ta có đầu vào RULES 20 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 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 Ta có định dạng file Excel để sử dụng làm template output: Sử dụng comment excel để định nghĩa liệu truyền vào: 21  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 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 22 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 toá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 23 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 24 PHỤ LỤC Phụ lục 4: THÔNG TIN LUẬN VĂN THẠC SĨ ÐẠI HỌC QUỐC GIA HÀ NỘI TRUỜNG ÐẠI HỌC CÔNG NGHỆ CỘNG HÒA XÃ HỘI CHỦ NGHIA VIỆT NAM Ðộc lập - Tự - Hạnh phúc THÔNG TIN VỀ LUẬN VĂN THẠC SĨ Họ tên học viên: Bùi Thị Thúy Giới tính: Nữ Ngày sinh:13/02/1991 Nơi sinh: Việt Thuận, Vũ Thƣ, Thái Bình Quyết định công nhận học viên số: , ngày… tháng.… nam Các thay đổi q trình tạo: Khơng Tên đề tài luận van: Chuyên ngành: Hệ thống thông tin Mã số: 10 Cán huớng dẫn khoa học: ThS Trƣơng Ninh Thuận 11 Tóm tắt kết luận van: nêu tóm tắt kết luận van, nhấn mạnh kết có) 12 Khả ứng dụng thực tiễn: (nếu có) 13 Những huớng nghiên cứu tiếp theo: (nếu có) 14 Các cơng trình dã cơng bố có liên quan đến luận van: liệt kê cơng trình theo thứ tự thời gian có) Ngày tháng năm 20 Xác nhận cán huớng dẫn (Kí ghi rõ họ tên) Ngày tháng năm 20 Học viên (Kí ghi rõ họ tên) 25 ... 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 toán với điều kiện nhƣ sau:  Các đặc tả yêu cầu nghiệp vụ. .. 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