Tài liệu Luận văn cntt 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 2 LỜI CAM ĐOAN Tác giả xin cam đoan kết quả đạt đƣợc trong luận văn là sản phẩm của riêng cá nhân Tác giả và đƣợc sự hƣớng dẫn khoa học của PGS. TS. Trƣơng Ninh Thuận, không sao chép lại của ngƣời khác. Trong toàn bộ nội dung của luận văn, những điều trình bày của cá nhân hoặc đƣợc tổng hợp của nhiều nguồn tài liệu. Tất cả các tài liệu tham khảo đều có xuất xứ rõ ràng và đƣợc trích dẫn hợp pháp. Tác giả xin hoàn toàn chịu trách nhiệm và chịu mọi hình thức kỷ luật theo quy định cho lời cam đoan của mình. Hà Nội, ngày tháng năm 2016 HỌC VIÊN Bùi Thị Thúy 3 LỜI CẢM ƠN Lời đầu tiên, em xin gửi lời cảm ơn chân thành và sâu sắc nhất 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 và đóng góp những ý kiến quý báu cho em trong suốt quá trình thực hiện luận văn tốt nghiệp này. Em xin gửi lời cảm ơn đến các 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 những kiến thức quý báu làm nền tảng cho em trong công việc và cuộc sống. Qua đây, em cũng xin gửi lời cảm ơn đến các đồng nghiệp tại công ty TNHH FPT Software đã giúp đỡ em trong quá 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è và đồng nghiệp của em tại, những ngƣời đã luôn bên em, khuyến khích và động viên em trong cuộc sống và học tập. HỌC VIÊN Bùi Thị Thúy 4 MỤC LỤC Danh mục các ký hiệu và chữ viết tắt ................................................................................... 7 Danh mục bảng ..................................................................................................................... 8 Danh mục hình vẽ ................................................................................................................. 9 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 2. CÁC KHÁI NIỆM TỔNG QUAN ............................................................... 12 2.1 Giới thiệu tổng quan về SRS................................................................................. 12 2.1.1 Khái niệm SRS ............................................................................................... 12 2.1.2 Vị trí của SRS trong quá trình xây dựng phần mềm ...................................... 13 2.1.3 Cấu trúc tổng quan của SRS........................................................................... 14 2.2 Giới thiệu về Use Case.......................................................................................... 14 2.2.1 Khái niệm Use Case ....................................................................................... 14 2.2.2 Vai trò của Use Case trong SRS .................................................................... 15 2.2.3 Cấu trúc tổng quan của Use Case ................................................................... 15 2.3 Giới thiệu tổng quan về Test Case ........................................................................ 18 2.3.1 Khái niệm Test Case ...................................................................................... 18 2.3.2 Vị trí của Test Case trong quá 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 3. 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 của 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 ra ........................................................................................................ 28 3.3 Phƣơng pháp thực hiện ......................................................................................... 28 5 3.3.1 Xây dựng thông tin Use Case trong 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 hiện (Test Procedure) ............................................ 30 3.3.7 Xây dựng kết quả mong đợi (Expected Result) ............................................. 31 3.3.8 Xây dựng Test Case dựa trên bullet và numbering ........................................ 33 CHƢƠNG 4. CÔNG NGHỆ SỬ DỤNG ........................................................................... 35 1.1 POI Apache ........................................................................................................... 35 4.1.1 Tính năng của Apache POI ............................................................................ 35 4.1.2 Sử dụng Apache POI trong đọ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 6 Danh mục các ký hiệu và chữ viết tắt STT 1 2 3 4 5 6 7 8 9 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 chú 7 Danh mục bảng Table 1Cấu trúc của một Test Case thông thƣờng ............................................................. 20 Table 2: Thuộc tính của Use Case ...................................................................................... 24 Table 3: Bảng mô tả luồng hoạt động của Use Case .......................................................... 25 8 Danh mục hình vẽ Figure 1: Vị trí của SRS trong quy trình sản xuất phần mềm ............................................ 13 Figure 2: Use Case Diagram cho một hệ thống điện thoại đơn giản .................................. 15 Figure 3: Vị trí của Test Case trong quá trình xây dựng phần mềm .................................. 22 Figure 4: Xây dựng thông tin Use Case trong 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” trong Test Case ................................. 30 Figure 8: Xây dựng nội dung cho “Các bƣớc thực hiện” trong Test Case ......................... 31 Figure 9: Xây dựng nội dung cho “Kết quả mong đợi” trong trƣờng hợp Validation passed.................................................................................................................................. 32 Figure 10: Xây dựng nội dung cho “Kết quả mong đợi” trong 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 trên điều kiện rẽ nhánh cha-con ............................... 34 9 MỞ ĐẦU Ngày này, trong các quy trình sản xuất phần mềm, ngoài khâu hình thành và xây dựng sản phẩm, các công ty chuyên về sản xuất phần mềm luôn chú trọng đến quá trình đầu vào và đầu ra của sản phẩm, bởi hai quá trình này có thể tác động một cách trực tiếp đến mục tiêu và chất lƣợng của một sản phẩm phần mềm. Về quá trình đầu vào của sản phẩm, một số công ty phần mềm lớn hiện nay đã xây dựng một quy trình thu thập yêu cầu phần mềm và xây dựng một bộ tài liệu chuẩn để làm đầu vào cho quá trình coding và xây dựng sản phẩm. Đầu ra của quá trình này là một bộ tài liệu về yêu cầu phần mềm, đƣợc gọi là SRS (Software Requirement Specification). Với bộ liệu chuẩn này, các bên liên quan đều có thể sử dụng nhƣ một bộ tài liệu chung và chuẩn nhất, đƣợc cập nhật cũng nhƣ sử dụng xuyên suốt trong toàn bộ dự án phần mềm. Về quá trình đầu ra của sản phẩm, hầu hết các công ty đều đã xây dựng một đội ngũ kiểm thử về chất lƣợng của sản phẩm, và toàn bộ quy trình hoạt động của sản phẩm để đảm bảo rằng sản phẩm phần mềm này đang đƣợc xây dựng theo đúng nhƣ yêu cầu và mục tiêu đề ra ban đầu. Hiện nay, tại các công ty phần mềm lớn và nhỏ, họ đều xây dựng một đội ngũ kiểm thử, đƣợc gọi là tester, với những khóa đào tạo chuyên nghiệp để có thể tiến hành chạy những test case sau khi sản phẩm đã hoàn thành, đảm bảo rằng sau khi sản phẩm đƣa vào sử dụng sẽ đúng với mục tiêu và yêu cầu ban đầu, và tránh đƣợc những lỗi về coding, mang lại cho ngƣời sử dụng một sản phẩm tƣơng đối hoàn hảo. Trong quá trình kiểm thử đầu ra của sản phẩm, hiện nay tất cả các test case đều đƣợc tester viết bằng tay, sau đó sử dụng các test case đó cho việc kiểm thử. Công việc này là một công việc tƣơng đối tốn thời gian, vì mỗi sản phẩm phần mềm thƣờng có số lƣợng test case lớn, có những sản phẩm phần mềm với quy mô lớn có thể lên đến hàng chục nghìn test case, điều này vô hình chung thƣờng mang lại những áp lực vô hình cho những ngƣời làm công việc kiểm thử phần mềm. Từ những mong muốn và nhu cầu thiết thực trên, chúng tôi mong muốn nghiên cứu và xây dựng một sản phẩm có thể tự động chuyển hóa các thông tin từ SRS thành dạng test case, để có thể hỗ trợ cho quá trình xây dựng một bộ test case chuẩn từ các yêu cầu phần mềm, phục vụ cho quá trình kiểm thử phần mềm, và giúp tiết kiệm thời gian cho tester trong việc viết test case. 10 CHƢƠNG 1: GIỚI THIỆU CHUNG 1.1 Nội dung luận văn Luận văn là một chƣơng trình phần mềm với mục tiêu có thể sinh tự động ra một bộ Test Case dựa trên dữ liệu đầu vào là một tài liệu đặc tả yêu cầu nghiệp vụ SRS. Bộ Test Case này sẽ đƣợc sử dụng là đầu vào cho quá trình kiểm thử phần mềm trong 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 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. 1.2 Cấu trúc luận văn Cấu trúc của luận văn đƣợc chia thành 5 phần chính: Chƣơng 1: Giới thiệu tổng quan về bài toán và nội dung chính của luận văn. Chƣơng 2: Đƣa ra các khái niệm tổng quan về các đố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 về các công nghệ sử dụng. Chƣơng 5: Kết luận và định hƣớng phát triển. Với 5 nội dung đề cập trên, tác giả mong muốn cung cấp đầy đủ thông tin để luận văn có thể trở thành một luận văn nghiên cứu với những vấn đề đƣợc giải quyết một cách triệt để và có định hƣớng phát triển lâu dài. 11 CHƢƠNG 2. CÁC KHÁI NIỆM TỔNG QUAN 2.1 Giới thiệu tổng quan về SRS 2.1.1 Khái niệm SRS Hiện nay, các công ty về phần mềm đều có xu hƣớng xây dựng một bộ tài liệu yêu cầu phần mềm chuẩn cho mỗi một dự án phần mềm, để đảm bảo rằng tất các bên liên quan đều có những hiểu biết đúng đắn giống nhau về mục tiêu và đầu ra của sản phẩm phần mềm đó. Trên thế giới hiện nay cũng đã có những chuẩn chung cho bộ tài liệu SRS này. SRS là từ viết tắt của 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) là một mô tả của một hệ thống phần mềm đƣợc phát triển. Nó đƣa ra các yêu cầu chức năng và phi chức năng, và có thể bao gồm một tập hợp các trƣờng hợp sử dụng để mô tả tƣơng tác ngƣời dùng mà một sản phẩm phần mềm phải cung cấp” [1]. SRS thiết lập cơ sở cho một thỏa thuận giữa khách hàng và các nhà thầu hoặc nhà cung cấp và các bên liên quan (trong một số dự án định hƣớng thị trƣờng, các bên liên quan có thể là các đơn vị tiếp thị và phát triển) về những mong muốn và mục tiêu của họ khi làm ra sản phẩm phần mềm và kèm theo cả những điều mà họ không mong muốn có trong sản phẩm đó. Tài liệu này cũng cung cấp một cơ sở thực tế cho việc ƣớc tính về thời gian thực hiện cũng nhƣ chi phí, các rủi ro và lịch trình chi tiết cho việc xây dựng sản phẩm. 12 2.1.2 Vị trí của SRS trong quá trình xây dựng phần mềm SRS sẽ đƣợc tạo ra ở giai đoạn đầu của một dự án, khi các bên liên quan hình thành ý tƣởng và xây dựng yêu cầu cho một sản phẩm phần mềm. Bên phát triển phần mềm cần tổ chức các cuộc họp với các bên liên quan để thu thập yêu cầu, từ đó xây dựng nên các tài liệu đặc tả yêu cầu phần mềm, chính là các SRS. Các SRS này có thể đƣợc coi nhƣ một tài liệu chuẩn và đƣợc sử dụng xuyên suốt trong suốt quá trình xây dựng phần mềm. Bên sản xuất phần mềm có thể coi nhƣ là một bản tài liệu chuẩn đã đƣợc thống nhất giữa các bên liên quan, sử dụng cho toàn bộ quá trình coding và testing, cũng nhƣ xây dựng các tài liệu đầu ra cho sản phẩm nhƣ: Tài liệu hƣớng dẫn sử dụng, Bộ test case cho Unit test và System test, v.v. Figure 1: Vị trí của SRS trong quy trình sản xuất phần mềm Các công đoạn của quy trình sản xuất phần mềm có thể đƣợc giải thích cụ thể nhƣ sau:  SRS: đây là giai đoạn mà đội phát triển dự án cần gặp gỡ và họp với khách hàng để có thể làm rõ các yêu cầu nghiệp vụ của khách hàng, từ đó xay a dựng lên một tài liệu đặc tả yêu cầu nghiệp vụ (SRS). Tài liệu này sau đó sẽ đƣợc ký kết bởi khách hàng, coi nhƣ là tài liệu cam kết 2 bên đã đồng ý sẽ xây dựng một phần mềm với chức năng đúng nhƣ tài liệu đã đặc tả.  Software Design & Technical Design: Sau khi đã tạo đƣợc tài liệu đặc tả yêu cầu nghiệp vụ (SRS) và đã đƣợc ký kết bởi khách hàng, đội phát triển phần 13 mềm sẽ tiến hành các bƣớc thiết kế chƣơng trình phần mềm nhƣ thiết kế cấu trúc phần mềm, cơ sở dữ liệu, v.v.  Implement and Unit Testing: Sau khi đã có thiết kế hệ thống hoàn chỉnh, đội phát triển sẽ tiến hành giai đoạn coding và kiểm thử phần mềm.  Integration & System Testing: Sau khi hệ thống phần mềm đã hình thành, đội phát triển cần tích hợp hệ thống với các hệ thống liên quan (nếu có) và tiến hành kiểm thử sự tƣơng tác giữa 2 (hoặc nhiều) hệ thống.  Operationg & Maintenance: Sau khi đã hoàn thành các công việc kiểm thử, hệ thống sẽ đƣợc đƣa vào sử dụng trong thực tế, và tiến hành các khâu bảo trì sản phẩm nếu cần thiết. 2.1.3 Cấu trúc tổng quan của SRS Một tài liệu SRS cần bao gồm đƣợc toàn bộ nội dung đặc tả yêu cầu mà một sản phẩm phần mềm cần có. Một SRS thông thƣờng cần có các phần nhƣ sau:  Giới thiệu chung: Phần này sẽ bao gồm các nội dung giới thiệu về Mục đích, Tổng quan, Phạm vi độc giả, Các từ viết tắt và một số mục đặc thù áp dụng cho từng loại SRS riêng.  Yêu cầu tổng quan: Phần này sẽ bao gồm các nội dung chung và các chức năng tổng thể của hệ thống. Phần này sẽ dùng cho các bên liên quan để có thể hiểu về mục tiêu và định hƣớng chức năng chính của sản phẩm phần mềm.  Yêu cầu chức năng chi tiết: Cấu trúc của phần này sẽ đƣợc chia nhỏ đến mức Use Case, mỗi Use Case sẽ mô tả chi tiết một chức năng của hệ thống. Phần này sẽ đƣợc sử dụng chủ yếu trong quá trình coding và testing.  Yêu cầu phi chức năng: Phần này sẽ mô tả về các yêu cầu chung không phải là các chức năng chính của sản phẩm phần mềm, ví dụ: yêu cầu hardware, các phiên bản phần mềm hỗ trợ, quy định chung về hiển thị nhƣ font chữ, cỡ chữ, v.v. Phần này sẽ dùng cho tất cả các bên liên quan sử dụng nhƣ một sự thống nhất về đầu ra và quá trình chạy phần mềm, cũng nhƣ để ƣớc tính chi phí.  Phụ lục: Phần này sẽ chứa các thông tin liên quan cũng nhƣ đặc thù cho mỗi sản phẩm phần mềm, ví dụ: nội dung của các thông báo hiển thị khi ngƣời dùng phần mềm, nội dung các email gửi đến cho ngƣời dùng, hoặc các thông tin đặc thù khác. 2.2 Giới thiệu về Use Case 2.2.1 Khái niệm Use Case Một Use Case là tất cả những cách thức sử dụng một chức năng hệ thống để đạt đƣợc một mục đích nào đó của một ngƣời dùng cụ thể. Tập hợp tất cả các Use Case sẽ cho chúng ta một bộ các cách thức hiệu quả để sử dụng hệ thống phần mềm. 14 Một Use Case là:  Một tập hợp tuần từ các hành động mà hệ thống phần mềm thực thi để ra đƣợc một kết quả mong muốn cho một ngƣời dùng cụ thể.  Xác định một hành vị của hệ thống để kết hợp với một ngƣời dùng nhằm mục đích tạo ra một giá trị cho ngƣời đó trong quá trình sử dụng hệ thống.  Là đơn vị nhỏ nhất của các hoạt động cung cấp một kết quả có ý nghĩa cho ngƣời dùng.  Là một nơi để chứa đựng một bộ các yêu cầu có liên quan đến nhau. Các Use Case trong một hệ thống thƣờng sẽ đƣợc mô hình hóa thành diagram nhƣ sau: Figure 2: Use Case Diagram cho một hệ thống điện thoại đơn giản 2.2.2 Vai trò của Use Case trong SRS Trong SRS, một Use Case đƣợc trình bày chi tiết trong phần “Yêu cầu chức năng chi tiết”. 2.2.3 Cấu trúc tổng quan của Use Case Một Use Case sẽ dùng để đặc tả chi tiết một chức năng, và đƣợc chia thành các 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) và Giả lập màn hình (Mockup Screen). 1. Thông tin tổng quan (General Information) 15 Thông tin tổng quan của một Use Case bao gồm một số thông tin thuộc tính của Use Case đó, nhƣ: Mục tiêu (Objective), Ngƣời thực hiện (Actor), Điều kiện tiên quyết (Pre-condition) và Điều kiện hoàn thành (Post Condition).  Mục tiêu (Objective): Diễn tả mục tiêu của Use Case trong hệ thống, giúp cho các bên liên quan biết đƣợc chức năng chính của Use Case này trong hệ thống.  Đối tƣợng thực hiện (Actor): Xác định đối tƣợng sẽ thực hiện chức năng này. Đối tƣợng thực hiện có thể là một user role (vai trò ngƣời dùng) hoặc một user role group (nhóm vai trò ngƣời dùng), một hệ thống bên ngoài, hoặc chính hệ thống (dùng cho các timer job (chức năng chạy tự động theo thời gian nhƣ gửi email, dọn rác hàng ngày, v.v.)).  Điều kiện tiên quyết (Pre-condition): o Xác định một điều kiện để chức năng này có thể đƣợc thực hiện (ví dụ: ngƣời dùng cần đăng nhập vào hệ thống, hoặc trạng thái của một yêu cầu đã đƣợc phê duyệt bởi ngƣời quản lý, v.v.). o Một Use Case có thể có điều kiện tiên quyết hoặc không có điều kiện tiên quyết, điều này phụ thuộc vào yêu cầu nghiệp vụ.  Điều kiện hoàn thành (Post-condition): Xác định các điều kiện khi Use Case đƣợc thực hiện thành công. Thông thƣờng, điều kiện hoàn thành sẽ diễn tả mục tiêu (objective) đƣợc thực hiện thành công. 2. Luồng hoạt động (Activities Diagram) Luồng hoạt động của một Use Case là một bộ các hoạt động tuần tự của hệ thống (System) và đối tƣợng tƣơng tác với hệ thống (một ngƣời dùng (user) hoặc một hệ thống bên ngoài (external system) hoặc chính hệ thống đó). 16 Trong Luồng hoạt động, các hành động đƣợc đánh số thứ tự theo tuần tự, và chia đều cho 2 bên: Đối tƣợng thực hiện (Actor) và hệ thống (system). Luồng hoạt động sẽ đƣợc sử dụng trong quá trình xây dựng Các bƣớc thực hiện và Kết quả mong đợi (Expected Result) cho Test Case. Phần này sẽ đƣợc đề cập trong CHƢƠNG 3. GIẢI PHÁP XÂY DỰNG TEST CASE DỰA TRÊN SRS trong tài liệu này. 3. Giả lập màn hình Phần giải lập màn hình sẽ trình bày hình ảnh về cách bố trí màn hình ở dạng sơ khai nhất. Giải lập màn hình sẽ giúp các bên liên quan về bố cục cũng nhƣ cách trình bày của các đối tƣợng trên màn hình để ngƣời dùng có thể sử dụng chức năng đó. Phần giả lập màn hình bao gồm 2 phần chính:  Hình ảnh màn hình: Hiển thị ảnh của màn hình là một khung với các đối tƣợng đƣợc bố trí trên khung và vị trí của từng đối tƣợng. 17  Mô tả màn hình: Hiển thị mô tả và chức năng của từng đối tƣợng trên màn hình đi kèm chi tiết về đối tƣợng đó. 2.3 Giới thiệu tổng quan về Test Case 2.3.1 Khái niệm Test Case 18 Test Case là một tập hợp các điều kiện đƣợc coi nhƣ một thử nghiệm để xác định liệu một ứng dụng, một hệ thống phần mềm hoặc một trong các tính năng của nó có làm việc nhƣ những thiết lập ban đầu hay không. Các cơ chế để xác định liệu một chƣơng trình phần mềm hoặc hệ thống đã đƣợc thông qua một thử nghiệm nay không đƣợc biết đến nhƣ một quy trình kiểm thử. Có thể cần nhiều trƣờng hợp thử nghiệm để có thể xác định rằng một chƣơng trình phần mềm hoặc hệ thống đƣợc coi là xem xét kỹ lƣỡng đầy đủ trƣớc khi phát hành hoặc bàn giao sản phẩm. 19 Hiện này, tại Việt Nam, ở các công ty sản xuất phần mềm, Test Case hầu hết đều đƣợc xây dựng và lƣu trữ bằng file excel để thuận tiện cho việc quản lý và chỉnh sửa cũng nhƣ bàn giao giữa các bên liên quan. Nội dung của một Test Case có thể nhƣ sau: Req. Id Test case Id Test case Title Test procedure Expected result Priority Test Round 1 Result Test Round 2 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. 1. Profile screen is opened. 2. Submit registration form is displayed with captcha generated by the system. 3. Updated Confirmed page is displayed. 4. Update profile successfully and return Home page of Inbox. High Fail Pass Table 1Cấu trúc của một Test Case thông thường Remarks