ĐẠ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

2

ĐẠ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

3

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

4

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

5

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

6

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

7

Danh mục các ký hiệu và chữ viết tắt

STT Từ viết tắt Nghĩa đầy đủ Ghi chú

1 SRS Software Specification

2 ID Identification

3 POI Poor Obfuscation Implementation

4 HSSF Horrible SpreadSheet Format

5 XSSF XML SpreadSheet Format

6 HPSF Horrible Property Set Format

7 HWPF Horrible Word Processor Format

8 HSLF Horrible Slide Layout Format

9 HDGF Horrible DiaGram Format

10 HPBF Horrible PuBlisher Format

11 HSMF Horrible Stupid Mail Format

12 DDF Dreadful Drawing Format

13 XML eXtensible Markup Language

8

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

9

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

10

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.

11

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.

12

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.

13

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

14

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.

15

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)

16

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 đó).

17

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.

18

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

19

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.

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

Remarks

Req_3 [FN_121] Update

Applicant

Government

Agency

successfully.

- Not

change the

email.

Step 1: Click <Profile>

button at the top right of the

INBOX page.

Step 2: Update valid data

then click <Next> button.

Step 3: Input valid captcha

then click <Submit> button.

Step 4: Click <OK> 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

Thông thƣờng, các Test Case có thể đƣợc phân chia thành 2 loại chính: Test Case

chính thức và Test Case không chính thức.

Test Case chính thức:

Test Case loại này dùng để đảm bảo rằng đã chạy hết tất cả các trƣờng hợp cho

một yêu cầu chức năng. Với loại test case này, cần có đủ cả 2 trƣờng hợp: Trƣờng

hợp thành công và trƣờng hợp thất bại.

Loại Test Case này thƣờng dùng trong trƣờng hợp đầu vào và đầu ra của chức

năng đều đã đƣợc xác định một cách rõ ràng và đầy đủ.

Loại Test Case này phù hơp cho các loại dự án phần mềm đƣợc thực thi theo mô

hình Waterfall.

Test Case không chính thức:

Test Case loại này thƣờng đƣợc sử dụng dựa trên các điều kiện có thể chấp nhận

đƣợc của một yêu cầu chức năng. Ở một số trƣờng hợp, loại Test Case này không

cần đƣợc viết ra một cách cụ thể mà các hoạt động kiểm thử vẫn đƣợc tiến hành

vào báo cáo dựa trên các điều kiện cụ thể.

Loại Test Case này thƣờng đƣợc dùng trong các trƣờng hợp đầu vào và đầu ra của

chức năng chƣa đƣợc xác định một cách cụ thể, hoặc trong các trƣờng hợp vô cùng

phức tạp, không thể xác định rõ đƣợc đầu ra của chức năng.

Loại Test Case này thƣờng đƣợc sử dụng cho các loại dự án phần mềm thực thi

theo mô hình Agile/Scrum.

Trong luận văn này, chúng tôi chỉ đề cập tới loại Test Case chính thức, với dữ liệu

đầu vào và đầu đƣợc sử dụng từ các Use Case đƣợc đề cập trong tài liệu SRS.

22

2.3.2 Vị trí của Test Case trong quá trình xây dựng phần mềm

Test Case đƣợc xây dựng ở giai đoạn gần cuối của quy trình sản xuất phần mềm,

khi các khâu xây dựng tài liệu SRS, thiết kế và lập trình gần nhƣ đã hoàn thiện, các Teste

sẽ bắt đầu bắt tay vào xây dựng bộ Test Case dựa trên các yêu cầu nghiệp vụ đƣợc mô tả

trong tài liệu SRS. Sau đó, các Test Case này sẽ đƣợc đƣa vào thực thi trong quá trình

kiểm thử phần mềm trƣớc khi chƣơng trình phần mềm đƣợc đƣa vào hoạt động trong thực

tế.

Figure 3: Vị trí của Test Case trong quá 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 có thể bao gồm một bƣớc thực hiện hoặc một bộ các bƣớc thực hiện

tuần tự, dùng để kiểm thử tính đúng đắn của hành động/chức năng của một chƣơng trình

phần mềm. Các kết quả mong muốn hoặc đầu ra mong muốn của hành động/chức năng

luôn phải đƣợc đề cập trong một Test Case.

Ngoài ra, một Test Case có thể bao hàm những thông tin sau:

Thông tin Mô tả

Test Case ID Là một giá trị duy nhất dùng để xác định tính duy nhất của một

Test Case trong một bộ Test Case.

Nội dung Test Case Là Nội dung mô tả của một Test Case. Phần nội dung này sẽ

mô tả mục đích chung của Test Case trong việc kiểm thử chức

23

năng của chƣơng trình phần mềm.

Các bƣớc thực hiện

hoặc thứ tự của hành

động.

Thông thƣờng, phần nội dung này sẽ mô tả các bƣớc thực hiện

tuần tự để có thể chạy đƣợc một chức năng của chƣơng trình

phần mềm.

Kết quả mong đợi Phần này sẽ hiển thị các nội dung của các kết quả mong đợi sau

khi Test Case đƣợc thực thi thành công. Kết quả mong đợi này

sẽ dùng để đánh giá một Test Case là “pass” hay “fail”.

Các yêu cầu liên

quan

Phần này dùng để mô tả các nội dung có thể liên quan hoặc ảnh

hƣởng trực tiếp đến điều kiện chạy hoặc kết quả đầu ra của

Test Case.

Danh mục Phần này thƣờng dùng để gộp các Test Case có cùng một mục

đích hoặc dùng chung cho một chức năng.

Tác giả Hiển thị tên của ngƣời tạo ra Test Case.

Ngƣời thực thi Hiển thị tên của ngƣời thực thi Test Case.

Trạng thái Hiển thị trạng thái của Test Case sau khi ngƣời thực thi Test

Case đã chạy qua các bƣớc của Test Case và lấy đƣợc kết quả

đầu ra của Test Case. Nội dung của phần này thông thƣờng sẽ

đƣợc hiển thị nhƣ sau:

Pass: Đầu ra của Test Case tƣơng ứng hoặc trùng khớp với

kết quả mong đợi ban đầu.

Fail: Đầu ra của Test Case không tƣơng ứng hoặc không

trùng khớp với kết quả mong đợi ban đầu.

Mức độ phức tạp Hiển thị mức độ phức tạp của Test Case. Thông thƣờng, sẽ có

3 mức dùng để đánh giá về độ phức tạp của Test Case:

Low: Test Case có mức độ này thƣờng không có ảnh hƣởng

nghiêm trọng đến hệ thống.

Medium: Test Case ở mức độ này thƣờng sẽ liên quan đến

các yêu cầu nghiệp vụ của hệ thống phần mềm, nếu thực

hiện không thành công có thể sẽ dẫn đến những sai số về

yêu cầu chức năng của hệ thống.

High: Test Case ở mức độ này cần đƣợc chú trọng, vì nếu

loại Test Case này thực hiện không thành công có thể gây

ảnh hƣởng nghiêm trọng đến hệ thống, có thể gây chết hệ

thống hoặc dẫn đến những sai lầm nghiêm trọng về yêu cầu

nghiệp vụ.

Ghi chú Hiển thị các ghi chú của ngƣời tạo Test Case hoặc ngƣời thực

24

thi Test Case.

CHƢƠNG 3. 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 bộ Test Case cho một hoặc nhiều chức năng cho một chƣơng trình

phần mềm sẽ dựa trên các thông tin đƣợc bao gồm trong tài liệu SRS, trong đó các thông

tin dùng cho mỗi Test Case sẽ đƣợc lấy ra từ các thông tin của Use Case.

Các thông tin của Use Case sẽ đƣợc sử dụng để xây dựng Test Case nhƣ sau:

3.1.1 Thuộc tính của Use Case

Thuộc tính của một Use Case trong SRS sẽ bao gồm các thông tin nhƣ sau:

Objective: Mục đích hoặc chứ năng chính của Use Case.

Actor: Ngƣời thực hiện Use Case.

Trigger: Hoạt động bắt đầu để thực hiện Use Case.

Pre-condition: Điều kiện cần thiết để Use Case có thể đƣợc thực hiện.

Post-condition: Kết quả mong đợi sau khi Use Case đƣợc thực hiện thành công

Table 2: Thuộc tính của Use Case

3.1.2 Luồng hoạt động (Activities Flow)

Các thông tin trong Activity Flow sẽ đƣợc sử dụng để tạo ra nội dung “Các bƣớc

thực hiện hoặc thứ tự của hành động” (Test Procedure) trong Test Case.

Trong Activity Flow của Use Case trong SRS, chúng ta sẽ chỉ tập trung vào các

bƣớc đƣợc thực hiện ở bên phía ngƣời dùng (Actor), thay vì các bƣớc thực hiện bên phía

25

hệ thống (system). Các thông tin thực hiện bên phía hệ thống sẽ có thể đƣợc sử dụng để

làm nội dung cho phần “Kết quả mong đợi” trong Test Case.

Step Actor Step System

Main Flow: View list of Kneading Command – Create Tabletising Command

1 User clicks “Go” button on “Create

Tabletising Command” page.

2 The system will display the form for user to

key in data on the bottom of page.

3 Keys in data and clicks on “Save”

button to add new item

4 Validate data.

If pass, go to step 5.

If fail, go to step 3.

5 Save data into database.

Table 3: Bảng mô tả luồng hoạt động của Use Case

Các thông tin trong luồng hoạt động của Use Case có thể đƣợc sử dụng để xây

dựng Các bƣớc thực hiện (Test Procedure) và Kết quả 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) là thành phần chính của một Use Case.

Phần này sẽ quy định các điều kiện hiển thị, hoạt động cũng nhƣ cách thức hoạt động của

một Use Case.

26

Thông thƣờng, một Use Case có thể bao gồm các loại quy tắc nghiệp vụ chính nhƣ

sau:

STT Tên quy tắc nghiệp vụ Mô tả

1 Quy tắc hiển thị

(Displaying Rules)

Quy tắc này mô tả cách mà một màn hình

hoặc một form đƣợc hiển thị khi ngƣời dùng

thực hiện Use Case.

Các thông tin sẽ đƣợc hiển thị có thể bao

gồm:

Vị trí hiển thị (đầu trang, cuối trang, giữa

trang, góc trái, góc phải, v.v.)

Cách thức hiển thị (trong cùng trang,

hiển thị dạng pop-up, mở sang một tab

mới của trình duyệt web, v.v.)

Màu sắc hiển thị (nếu có)

2 Quy tắc kiểm tra giá trị lỗi

(Validation Rules)

Quy tắc này mô tả cách thức hệ thống kiểm

tra dữ liệu do ngƣời dùng nhập vào để đảm

bảo rằng các dữ liệu đó là hợp lệ hoặc là các

dữ liệu phù hợp với yêu cầu nghiệp vụ của

hệ thống.

Các loại quy tắc phổ biến để kiểm tra dữ

liệu:

Kiểm tra các trƣờng bắt buộc trên form.

Kiểm tra kiểu dữ liệu của các field số,

ngày tháng, v.v.

Kiểm tra độ dài của chuỗi không đƣợc

vƣợt quá giới hạn cho phép.

Kiểm tra giá trị của dữ liệu nhập vào có

vi phạm điều kiện của yêu cầu nghiệp vụ

hay không.

Cách thức hiển thị thông báo lỗi (nếu có):

Hiển thị tin nhắn lỗi trực tiếp trên form.

Hiển thị tin nhắn lỗi dạng hộp thoại.

3 Quy tắc tính toán

(Calculation Rules)

Quy tắc này mô tả cách thức hệ thống thực

hiện việc tính toán cho một trƣờng trên form

dựa vào các dữ liệu ngƣời dùng nhập vào

27

hoặc các dữ liệu lấy từ cơ sở dữ liệu hoặc từ

một nguồn khác.

Các thông tin bao gồm trong quy tắc này:

Trƣờng đƣợc tính toán.

Dữ liệu sử dụng để tính toán.

Công thức tính toán.

Các thức hiển thị kết quả.

4 Quy tắc lƣu dữ liệu (Saving

data Rules)

Quy tắc này mô tả cách thức hệ thống phần

mềm thực hiện việc lƣu các dữ liệu mà

ngƣời dùng nhập vào xuống cơ sở dữ liệu,

hoặc hệ thống tự động lấy dữ liệu từ một

nguồn khác và lƣu xuống cơ sở dữ liệu.

Các thông tin bao gồm:

Loại dữ liệu đƣợc lƣu xuống.

Cách thức xử lý khi dữ liệu đƣợc lƣu

xuống cơ sở dữ liệu thành công: hiển thị

thông báo, chuyển trang, v.v.

5 Quy tắc cập nhật dữ liệu

(Updating Rules)

Quy tắc này mô tả cách thức hệ thống phần

mềm thực hiện việc cập nhật các dữ liệu có

sẵn trong cơ sở dữ liệu bằng các dữ liệu mà

ngƣời dùng nhập vào, hoặc hệ thống tự động

lấy dữ liệu từ một nguồn khác.

Các thông tin bao gồm:

Loại dữ liệu đƣợc cập nhật.

Cách thức xử lý khi dữ liệu đƣợc cập

nhật vào cơ sở dữ liệu thành công: hiển

thị thông báo, chuyển trang, v.v.

6 Quy tắc xóa dữ liệu

(Deleting Rules)

Quy tắc này mô tả cách thức mà chƣơng

trình phần mềm thực hiện việc xóa các dữ

liệu có sẵn trong cơ sở dữ liệu.

Các thông tin bao gồm:

Loại dữ liệu sẽ bị xóa.

Cách thức xử lý khi dữ liệu đƣợc xóa

thành công: hiển thị thông báo, chuyển

trang, v.v.

28

Trong luận văn này, tác giả sẽ đề cập tới cách sử dụng từng loại quy tắc nghiệp vụ

để xây dựng đƣợc các Test Case trong bộ Test Case cho một chƣơng trình phần mềm.

3.2 Dữ liệu đầu ra

Từ thông tin của Use Case đƣợc mô tả trong SRS, tác giả của luận văn mong muốn

có thể xây dựng một bộ Test Case sử dụng các thông tin đó với các thông tin chi tiết nhƣ

sau:

Template TC.xlsx

3.3 Phƣơng pháp thực hiện

Trong một bộ Test Case, chúng tôi mong muốn có thể xây dựng các Test Case cho

từng Use Case riêng biệt, và sẽ gộp các Test Case trong cùng một Use Case thành một

nhóm. Nhƣ vậy, từ một Use Case, chúng ta có thể xây dựng nên một bộ Test Case cho

một Use Case cụ thể theo các quy luật nhƣ đƣợc trình bày dƣới đây.

3.3.1 Xây dựng thông tin Use Case trong Test Case

Việc xây dựng thông tin của Use Case trong Test Case có thể đƣợc thực hiện bằng

cách đọc nội dung của Use Case đƣợc đề cập trong SRS nhƣ sau:

Figure 4: Xây dựng thông tin Use Case trong Test Case.

3.3.2 Xây dựng Điều kiện cần (Pre-condition) cho Test Case

Việc xây dựng Điều kiện cần cho Test Case có thể sử dụng thông tin từ phần “Pre-

condition” trong bảng thuộc tính của Use Case nhƣ sau:

29

Figure 5: Xây dựng Điều kiện cần (Pre-condition) cho Test Case.

3.3.3 Xây dựng Actor cho Test Case:

Việc xây dựng Điều kiện cần cho Test Case có thể sử dụng thông tin từ phần

“Actor” trong bảng thuộc tính của Use Case nhƣ sau:

Figure 6: Xây dựng Actor cho Test Case

3.3.4 Xây dựng thông tin cho Use Case ID, Test Case ID

Thông tin của Use Case ID sẽ đƣợc xây dựng bằng cách sử dụng tiếp đầu ngữ

“UC”, đi kèm với một số thứ tự của Use Case đó trong tài liệu SRS. Định dạng của Use

Case ID đƣợc định nghĩa nhƣ sau:

UC_{Số thứ tự của Use Case trong SRS}

Ví dụ: UC_1

Thông tin của Test Case ID đƣợc xây đựng bằng các sử dụng tiếp đầu ngữ “TC”, đi

kèm với một số tự tăng chính là số thứ tự của Test Case trong bộ Test Case. Định dạng

của Test Case ID sẽ đƣợc định nghĩa nhƣ sau:

[TC_{Số thứ tự tự tăng của Test Case}]

30

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 của Use Case sang “Tên Test Case” (Test Case Title) có

thể sử dụng thông tin của phần “Objective” từ bảng trong phần “General Information”

nhƣ hình dƣới đây:

Figure 7: Xây dựng nội dung cho “Tên Test Case” trong Test Case

3.3.6 Xây dựng Các bước thực hiện (Test Procedure)

Việc chuyển đổi nội dung của Use Case sang “Các bƣớc thực hiện” (Test

Procedure) có thể đƣợc thực hiện nhƣ hình dƣới đây:

31

Figure 8: Xây dựng nội dung cho “Các bước thực hiện” trong Test Case

3.3.7 Xây dựng kết quả mong đợi (Expected Result)

Việc chuyển đổi nội dung của Use Case sang “Kết quả mong đợi” (Expected

Result) có thể đƣợc thực hiện nhƣ hình dƣới đây:

Với các bƣớc rẽ nhánh để kiểm tra điều kiện, cần chia thành 2 Test Case với 2

loại “Kết quả mong đợi” (Expected Result):

Expected Result 1: Validation Passed.

o Trong trƣờng hợp Validtion passed, hệ thống sẽ tiếp tục đọc thông tin

trong Business rule để có thể lấy đƣợc thông tin nhƣ sau:

Nếu Use Case dùng để cập nhật (update)/tạo mới (create) một đối

tƣợng mới, hệ thống sẽ tiếp tục đọc thông tin của của Updating

Rules/Saving Rules trong phần Business Rules và điền thông tin

tƣơng ứng của Business Rules này vào Test Case.

32

Figure 9: Xây dựng nội dung cho “Kết quả mong đợi” trong trường hợp Validation passed.

Expected Result 2: Validation Fail.

o Trong trƣờng hợp Validtion fail, hệ thống sẽ tiếp tục đọc thông tin của

Validation Rules trong phần Business Rules để có thể lấy đƣợc thông tin

cho Test Case.

o Mỗi điểm đƣợc trình bày trong Validation Rules sẽ đƣợc trình bày thành

một Test Case.

o Nếu một điểm trong Validation Rules có nhiều cấp độ, thì hệ thống sẽ

chia Test Case theo cấp độ nhỏ nhất, gộp các cập độ đó với cấp độ cha

nhƣ sau:

33

Figure 10: Xây dựng nội dung cho “Kết quả mong đợi” trong trường hợp Validation fail.

3.3.8 Xây dựng Test Case dựa trên bullet và numbering

Đối với các yêu cầu nghiệp vụ đƣợc trình bày dƣới dạng bullet hoặc numbering

định dạng trong văn bản word, hệ thống sẽ phân chia theo bullet và numbering của điều

kiện rẽ nhánh bé nhất (chứa cụm từ “If” hoặc “Else” hoặc “Otherwise”.

Hệ thống sẽ kết hợp các bullet cha và mỗi bullet con thành một Test Case.

Ví dụ:

Chúng ta có các điều kiện rẽ nhánh, và đƣợc trình bày dƣới dạng bullet nhƣ sau:

34

Figure 11: Business rules với điều kiện rẽ nhánh cha-con

Hệ thống khi phân tích các điều kiện rẽ nhánh, sẽ tìm đến điều kiện có cấp độ bé

nhất, sau đó kết hợp với các điều kiện cha để tạo thành các bộ Test Case riêng biệt nhƣ

sau:

Figure 12: Xây dựng Test Case dựa trên điều kiện rẽ nhánh cha-con

35

CHƢƠNG 4. CÔNG NGHỆ SỬ DỤNG

Nhƣ đã trình bày ở trên, trong luận văn này, chúng tôi sử dụng thử nghiệm một bộ mã

nguồn mở POI trong việc đọc và ghi dữ liệu cho Microsoft Word và Microsoft Excel và

ngôn ngữ lập trình Java.

1.1 POI Apache

Apache POI là một thƣ viện mã nguồn mở Java, đƣợc cung cấp bởi Apache, nó là

một thƣ viện đầy sức mạnh giúp bạn làm việc với các tài liệu của Microsoft nhƣ Word,

Excel, Power point, Visio,...

POI là viết tắt của "Poor Obfuscation Implementation". Các định dạng file của

Microsoft đƣợc giấu kín. Những kỹ sƣ của Apache phải cố gắng để tìm hiểu nó, và họ

thấy rằng Microsoft đã tạo ra các định dạng phức tạp một cách không cần thiết.

4.1.1 Tính năng của Apache POI

Apache POI hỗ trợ bạn làm việc với các định dạng của Microsoft, các class của nó

thƣờng có tiếp đầu ngữ HSSF, XSSF, HPSF, ... Nhìn vào tiếp đầu ngữ của một class, bạn

có thể biết đƣợc class đó hỗ trợ loại định dạng nào.

Ví dụ để làm việc với các định dạng Excel (XLS) bạn cần các class:

HSSFWorkbook

HSSFSheet

HSSFCellStyle

36

HSSFDataFormat

HSSFFont

...

STT Tiếp đầu ngữ Mô tả

1 HSSF (Horrible SpreadSheet

Format)

Đọc và ghi file định dạng Microsoft Excel

(XLS).

2 XSSF (XML SpreadSheet Format) Đọc và ghi định dạng file Open Office

XML (XLSX).

3 HPSF (Horrible Property Set

Format)

Đọc thông tin tóm tắt về tài liệu từ các file

Microsoft Office.

4 HWPF (Horrible Word Processor

Format)

Mục đích đọc và ghi các file định dạng

Microsoft Word 97 (DOC).

5 HSLF (Horrible Slide Layout

Format)

Một thực hiện thuần Java cho các file

Microsoft PowerPoint.

6 HDGF (Horrible DiaGram Format)

Các thực hiện (implementation) thuần

Java khởi đầu cho các file nhị phân

Microsoft Visio.

7 HPBF (Horrible PuBlisher Format) Một thực hiện thuần Java cho các file

Microsoft Publisher.

8 HSMF (Horrible Stupid Mail

Format)

Một thực hiện thuần Java cho các file

Microsoft Outlook MSG

9 DDF (Dreadful Drawing Format) Một package cho giải mã các định dạng

Microsoft Office Drawing.

Apache POI đƣợc áp dụng rộng rãi trong các công việc thực tế nhƣ sau:

37

4.1.2 Sử dụng Apache POI trong đọc file SRS

Đọc từ file doc ra dữ liệu XWPFParagaraph.

Nếu file đọc đƣợc là heading thì sẽ kiểm tra xem có phải heading có value là “USE

CASE” không.

Nếu header là USE CASES thì tiến hành đọc danh sách các table của USE CASE

38

Nếu table là USE CASE thì tiến hành đọc Precondition, actor, objective tƣơng ứng

với usecase đó.

Ta có đầu vào của 1 USE CASE

Đọc tiếp bảng RULES sau bảng USE CASE

Ta có đầu vào của 1 RULES

39

4.2 JXLS

4.2.1 Giới thiệu

Jxls là một thƣ viện Java hỗ trợ cho việc xuất file excel. Jxls sử dụng một

đánh dấu đặc biệt trong Excel mẫu để xác định định dạng đầu ra và bố trí dữ

liệu.

Java đã có rất nhiều mã nguồn mở và các thƣ viện thƣơng mại để tạo tập tin

Excel (của những mã nguồn mở đáng nói là Apache POI và Java Excel API.

Những thƣ viện khác sẽ phải sử dụng rất nhiều câu lệnh Java để tạo ra 1 file

Excel đơn giản.

Thông thƣờng, bạn phải tự thiết lập cho mỗi định dạng và dữ liệu cho các

bảng tính. Tùy thuộc vào sự phức tạp của cách bố trí báo cáo và dữ liệu định

40

dạng mã Java có thể trở nên khá phức tạp và khó khăn để gỡ lỗi và duy trì.

Ngoài ra không phải tất cả các tính năng Excel đƣợc hỗ trợ và có thể đƣợc

thao tác với API (ví dụ macro hoặc đồ thị). Cách giải quyết đề nghị cho các

tính năng không đƣợc hỗ trợ là để tạo ra các đối tƣợng bằng tay trong một

mẫu Excel và điền các mẫu với dữ liệu sau đó.

Các tiếp cận của JXLS với Excel ở một mức độ cao hơn. Tất cả bạn cần làm

khi làm việc với Jxls chỉ là để xác định tất cả các định dạng báo cáo của bạn

và cách bố trí dữ liệu trong một mẫu Excel và chạy động cơ Jxls cung cấp nó

với các dữ liệu để điền vào mẫu. Mã duy nhất bạn cần phải viết trong hầu hết

các trƣờng hợp là một lời gọi đơn giản của động cơ 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 năng và đặc điểm nổi bật của JXLS:

Định dạng Excel đầu ra là XML và nhị phân (phụ thuộc vào mức độ phát

triển)

Tạo thành 1 tập hợp các dòng và cột

Xây dựng đầu ra 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ác công thức của Excel

Sử dụng các công thức kèm tham số

Hỗ trợ việc Merge Cell

Sử cụng các comments trong markup của Excel để định nghĩa công thức

Tùy chỉnh các 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:

41

Sử dụng các comment trong excel để định nghĩa dữ liệu truyền vào:

Items: danh sách dữ liệu sẽ đƣợc in ra output.

lastCell: cell cuối cùng trong template output của 1 dữ liệu.

Thực hiện đọc file template (output) và ghi ra file Result.xlsx

Ta có output đầu ra tƣơng ứng:

42

Hiện tại, chúng tôi sử dụng bộ tài liệu SRS của Applicant Registration Module

(Đăng ký ngƣời dùng) của dự án phần mềm tại công ty FPT Software khi 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 của chƣơng trình là một 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 ra đƣợc bộ Test Case với các test cases

nhƣ trong file dƣới đây.

result.xlsx

43

KẾT LUẬN VÀ HƢỚNG PHÁT TRIỂN

Trong luận văn này, tác giả đã hoàn thành đƣợc những công việc cụ thể sau:

Hoàn thiện việc nghiên các khái niệm và chức năng liên quan của SRS và Test

Case.

Xây dựng các công thức sinh Test Case từ các yêu cầu nghiệp vụ.

Xây dựng chƣơng trình sinh tự động bộ Test Case từ một tài liệu đặc tả yêu cầu

nghiệp vụ SRS.

Hiện nay, chƣơng trình đã có thể giải quyết các bài toán với các đ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 của từng Use

Case nhƣ đã đề cập trong phần Giới thiệu về Use Case.

Các đặc tả yêu cầu nghiệp vụ của mỗi Use Case đƣợc chia thành các 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 có thể phát triển đề tài để có thể tự động

sinh bộ Test Case cho các chức năng hệ thống phức tạp hơn nhƣ các Batch Job hoặc các

Timer Job của hệ thống, các chức năng chạy không cần tác động của user, hoặc các chức

năng trả về những kết quả trừu tƣợng.

44

TÀI LIỆU THAM KHẢO

1. Glenford J. Myers, Tom Badgett and Corey Sandler (2015), The Art of Software

Testing, Third Edition.

2. Practice Book for the Paper-based GRE ® revised General Test (PDF), Second

Edition.

3. Glenn Fulcher and Fred Davidson (2006), Language Testing and Assessment: An

Advanced Resource Book.

4. Rekard Edgren (2012), The Little Black Book on Test Design.

5. Cem Kaner and Jack Falk, Testing Computer Software.

6. IIBA | International Institute of Business Analysis (2015), A Guide to the Business

Analysis Body of Knowledge® (BABOK® Guide), Third Edition.

7. IEEE Computer Society (1998), IEEE Recommended Practice for Software

Requirements Specifications.

8. 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.

9. 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.