Nghiên cứu một số kỹ thuật và công cụ kiểm thử ứng dụng trong kiểm thử tự động ứng dụng web (Luận văn thạc sĩ)

Nghiên cứu một số kỹ thuật và công cụ kiểm thử ứng dụng trong kiểm thử tự động ứng dụng web (Luận văn thạc sĩ)Nghiên cứu một số kỹ thuật và công cụ kiểm thử ứng dụng trong kiểm thử tự động ứng dụng web (Luận văn thạc sĩ)Nghiên cứu một số kỹ thuật và công cụ kiểm thử ứng dụng trong kiểm thử tự động ứng dụng web (Luận văn thạc sĩ)Nghiên cứu một số kỹ thuật và công cụ kiểm thử ứng dụng trong kiểm thử tự động ứng dụng web (Luận văn thạc sĩ)Nghiên cứu một số kỹ thuật và công cụ kiểm thử ứng dụng trong kiểm thử tự động ứng dụng web (Luận văn thạc sĩ)Nghiên cứu một số kỹ thuật và công cụ kiểm thử ứng dụng trong kiểm thử tự động ứng dụng web (Luận văn thạc sĩ)Nghiên cứu một số kỹ thuật và công cụ kiểm thử ứng dụng trong kiểm thử tự động ứng dụng web (Luận văn thạc sĩ)Nghiên cứu một số kỹ thuật và công cụ kiểm thử ứng dụng trong kiểm thử tự động ứng dụng web (Luận văn thạc sĩ)Nghiên cứu một số kỹ thuật và công cụ kiểm thử ứng dụng trong kiểm thử tự động ứng dụng web (Luận văn thạc sĩ)

I

ĐẠI HỌC THÁI NGUYÊN

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG

NGUYỄN THỊ KIM TUYẾN

NGHIÊN CỨU MỘT SỐ KỸ THUẬT VÀ CÔNG CỤ KIỂM THỬ ỨNG DỤNG TRONG KIỂM THỬ TỰ ĐỘNG ỨNG DỤNG WEB

Chuyên ngành: Khoa học máy tính

Mã số: 848 01 01 LUẬN VĂN THẠC SĨ KHOA HỌC MÁY TÍNH

Người hướng dẫn khoa học: TS Nguyễn Văn Núi

THÁI NGUYÊN, 2018

II

LỜI CAM ĐOAN

Tôi 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 Trong toàn bộ nội dung của luận văn, những điều được trình bày hoặc là của cá nhân hoặc là được tổng hợp từ 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ôi 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

Tác giả luận văn

Nguyễn Thị Kim Tuyến

III

LỜI CẢM ƠN

Luận văn Thạc sĩ này được thực hiện tại Đại học Công Nghệ Thông Tin & Truyền Thông dưới sự hướng dẫn của TS Nguyễn Văn Núi Xin được gửi lời cảm ơn sâu sắc đến thầy về định hướng khoa học, liên tục quan tâm, tạo điều kiện thuận lợi trong suốt quá trình nghiên cứu hoàn thành luận văn này Tôi xin được gửi lời cảm ơn đến các các thầy giáo, cô giáo đã giảng dạy

và cung cấp cho tôi những kiến thức rất bổ ích trong thời gian học, giúp tôi có nền tảng tri thức để phục vụ nghiên cứu khoa học sau này

Tôi cũng xin bày tỏ lòng cảm ơn đến gia đình và bạn bè, những người luôn quan tâm, động viên và khuyến khích tôi đã giúp tôi có thêm nghị lực, cố gắng để hoàn thành luận văn này

Cuối cùng, xin gửi lời cảm ơn chân thành nhất đến các bạn cùng học K15A, các bạn đồng nghiệp đã giúp đỡ tôi trong suốt 2 năm học tập

Tác giả luận văn

Nguyễn Thị Kim Tuyến

IV

DANH MỤC HÌNH ẢNH

Hình 1 1 Minh họa sử dụng quy trình kiểm chứng và thẩm định trong quá

trình phát triển phần mềm 4

Hình 1 2 Các nguyên nhân gây ra lỗi phần mềm 6

Hình 1 3 Quy trình kiểm thử phần mềm 8

Hình 4 1 Cấu trúc của Selenium i

Hình 4 2 Thao tác mở Selenium IDE trên thanh công cụ iv

Hình 4 3 Giao diện chính của Selenium IDE iv

Hình 4 4 Download và cài đặt JDK xiii

Hình 4 5 Download Eclipse IDE xiv

Hình 4 6 Download Selenium Java Client Driver xiv

Hình 4 7 Tạo một project mới xv

Hình 4 8 Đặt tên và chọn tạo phương thức xv

Hình 4 9 Tên Class trong Eclipse xvi

Hình 4 10 Thêm Selenium Java Client Driver (.jar) vào trong project xvi

Hình 4 11 Đăng nhập thành công trên Firefox 38

Hình 4 14 Giao diện báo cáo kết quả kiểm thử thất bại 38

Hình 4 15 Bảng tóm tắt các trường hợp testcase đã chạy 39

V

MỤC LỤC LỜI CAM ĐOAN I LỜI CẢM ƠN III DANH MỤC HÌNH ẢNH IV MỤC LỤC V CHƯƠNG 1: TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM VÀ VẤN ĐỀ ĐẢM

BẢO CHẤT LƯỢNG PHẦN MỀM 3

1 Sản phẩm phần mềm và kiểm thử phần mềm 3

1.1 Sản phẩm phần mềm là gì? 3

1.2 Khái niệm kiểm thử phần mềm 3

2 Vấn đề về đảm bảo chất lượng phần mềm 5

2.1 Lỗi phần mềm là gì? 5

2.2 Tại sao lỗi phần mềm xuất hiện 6

2.3 Chi phí cho việc sửa lỗi 7

3 Quy trình kiểm thử phần mềm 7

CHƯƠNG 2: MỘT SỐ KỸ THUẬT VÀ CÔNG CỤ KIỂM THỬ PHẦN MỀM 10

2.1 Nguyên tắc kiểm thử 10

2.1.1 Mục tiêu kiểm thử 10

2.1.2 Luồng thông tin kiểm thử 10

2.2 Một số kỹ thuật kiểm thử phần mềm 11

2.2.1 Kỹ thuật kiểm thử hộp trắng (White - Box Testing) 11

2.2.2 Kỹ thuật kiểm thử đường dẫn cơ bản (Basic Path Testing) 12

2.3 Kỹ thuật kiểm thử hộp đen (Black – Box Tesing) 15

2.3.1 Phân hoạch tương đương 16

2.3.2 Phân tích giá trị biên (BVA - Boundary Value Analysis) 17

2.3.3 Kỹ thuật đồ thị nhân-quả (Cause-Effect Graph) 18

2.3.4 Kiểm thử so sánh 18

2.4 Kiểm thử tự động 19

VI

2.4.1 Kiểm thử hàm 21

2.4.2 Kiểm thử dòng điều khiển 22

CHƯƠNG 3: MỘT SỐ CÔNG CỤ KIỂM THỬ PHẦN MỀM 25

3.1 Công cụ kiểm thử Jmeter 25

3.1.1 Giới thiệu chung về Jmeter 25

3.1.2 Đặc trưng của Jmeter 25

3.1.3 Các thành phần chính của Jmeter 25

3.2 Công cụ kiểm thử QuickTest Pro 26

3.2.1 Giới thiệu chung về QuickTest Pro 26

3.2.2 Đặc trưng của QuickTest Pro 26

3.2.3 Các thành phần chính của QuickTest Pro 27

3.3 Công cụ kiểm thử Katalon Studio 28

3.3.1 Giới thiệu chung về Katalon Studio 28

3.3.2 Đặc trưng của Katalon Studio 28

3.3.3 Các thành phần chính của Katalon Studio 29

3.4 Công cụ kiểm thử Selenium Webdriver 30

CHƯƠNG 4: ỨNG DỤNG CÔNG CỤ HỖ TRỢ KIỂM THỬ SELENIUM WEBDRIVER TRONG KIỂM THỬ ỨNG DỤNG WEB 33

4.1 Lý do chọn bài toán ứng dụng 33

4.2 Kiểm thử tự động ứng dụng Gmail 35

4.2.1 Giới thiệu bài toán 35

4.2.2 Chuẩn bị testcase cho bài toán 36

4.2.3 Xây dựng kịch bản kiểm thử tự động 37

KẾT LUẬN 40

PHỤ LỤC i

Phụ lục 1 - Giới thiệu về Selenium i

Phụ lục 2 - Selenium IDE iii

VII

1 Giới thiệu về Selenium IDE iii

2 Hướng dẫn cài đặt Selenium IDE iii

3 Các câu lệnh chính của Selenium IDE v

4 Locator (Xác định đối tượng UI) vii

Phụ lục 3 - Selenium WebDriver x

1 Giới thiệu Selenium WebDriver x

2 Cài đặt Selenium WebDriver xiii

3 Các câu lệnh sử dụng trong Selenium WebDriver xx

TÀI LIỆU THAM KHẢO i

1

MỞ ĐẦU

Chúng ta đã và đang chứng kiến sự tăng trưởng đáng kinh ngạc của ngành công nghiệp phần mềm trong vài thập kỷ qua Nếu như trước đây phần mềm máy tính chỉ được sử dụng để tính toán khoa học kỹ thuật và xử lí

dữ liệu thì ngày nay nó đã được ứng dụng vào mọi mặt đời sống hàng ngày của con người, từ các ứng dụng nhỏ để điều khiển các thiết bị dùng trong gia đình như các thiết bị nghe nhìn, điện thoại, máy giặt, lò vi sóng, nồi cơm điện, đến các ứng dụng lớn hơn như trợ giúp điều khiển các phương tiện và

hệ thống giao thông, trả tiền cho các hoá đơn, quản lí và thanh toán về tài chính, Vì thế con người ngày càng phụ thuộc chặt chẽ vào các sản phẩm phần mềm Do vậy đòi hỏi về chất lượng của các sản phẩm phần mềm ngày càng cao, tức là các phần mềm phải được sản xuất với giá thành hạ, dễ dùng,

an toàn và tin cậy được Kiểm thử có phương pháp là một hoạt động không thể thiếu trong quy trình sản xuất phần mềm để đảm bảo các yếu tố chất lượng nêu trên của các sản phẩm phần mềm

Bên cạnh đó, các ứng dụng Web đã được phát triển và trở thành nền tảng kết nối thông tin thiết yếu trong doanh nghiệp, đóng vai trò quyết định trong thương mại điện tử, trao đổi thông tin Để đạt được điều này, các ứng dụng Web cần phải có hiệu năng cao, đáng tin cậy,… Việc đưa ra một ứng dụng Web tốt cho người dùng đã và sẽ sử dụng ứng dụng đã trở thành một thách thức chính trong vấn đề đảm bảo chất lượng

Selenium WebDriver là một công cụ kiểm thử ứng dụng Web tiêu biểu Đây là một công cụ mã nguồn mở, mạnh mẽ hỗ trợ trên nền Web, nhiều platform và các trình duyệt phổ biến Selenium WebDriver có lẽ một trong những công cụ tốt nhất trên thị trường cho các ứng dụng Web Những lợi ích của các công cụ kiểm thử tự động mang lại là rất lớn nên hy vọng

luận văn “Nghiên cứu một số kỹ thuật và công cụ kiểm thử ứng dụng trong

2

kiểm thử tự động ứng dụng Web” sẽ mang lại cho người đọc một tài liệu hỗ

trợ hữu ích trước khi quyết định sử dụng kiểm thử tự động cho ứng dụng Web của mình

Nội dung luận văn gồm 4 chương:

Chương 1: Tổng quan về kiểm thử phần mềm và vấn đề đảm bảo chất lượng phần mềm

Chương 2: Một số công cụ kiểm thử phần mềm

Chương 3: Một số cộng cụ kiểm thử phần mềm

Chương 4: Ứng dụng công cụ hỗ trợ kiểm thử Selenium Webdriver trong kiểm thử ứng dụng Web

Việc tạo ra một sản phẩm phần mềm phải trải qua nhiều giai đoạn, người

ta gọi là qui trình phát triển phần mềm, bắt đầu từ khi bắt đầu có ý tưởng cho đến khi đưa ra sản phẩm phần mềm thực thi Khối lượng công việc trong từng giai đoạn của quá trình sản xuất phần mềm cũng thay đổi theo thời gian

1.2 Khái niệm kiểm thử phần mềm

Kiểm thử phần mềm là công việc được thực hiện nhằm tìm ra lỗi, thiếu sót của phần mềm hoặc chứng minh phần mềm hoạt động đúng đắn Kiểm thử phần mềm có vai trò rất quan trọng trong việc cải thiện chất lượng phần mềm và làm giảm chi phí kiểm thử cũng như khắc phục lỗi

Kiểm thử phần mềm sử dụng quy trình kiểm chứng và thẩm định chất lượng phần mềm trong quá trình thực hiện việc kiểm thử Quy trình kiểm chứng sẽ đảm bảo rằng phần mềm khi được phát triển sẽ đúng với đặc tả của nó và quy trình thẩm định thì sẽ đảm bảo rằng phần mềm thỏa mãn được yêu cầu của người dùng cuối Quy trình kiểm chứng sẽ được thực hiện trước quy trình thẩm định do sản phẩm phần mềm cần đúng với đặc tả trước Nếu thực hiện quy trình thẩm định trước quy trình đặc tả, nếu xảy ra lỗi, rất khó có thể xác định lỗi này là do đặc tả sai hay do lập trình sai so với đặc tả Tuy nhiên, thẩm định nếu được thực hiện quá muộn thì khi phát hiện

ra lỗi hoặc thiếu sót sẽ kéo theo chi phí khắc phục lỗi tăng đồng thời khiến

4

thời gian hoàn thiện phần mềm kéo dài Vì vậy, quy trình thẩm định nên được thực hiện sớm để góp phần làm giảm chi phí cũng như thời gian phát triển sản phẩm phần mềm Trong phương pháp phát triển phần mềm Agile, khách hàng sẽ đóng vai trò là một thành viên của nhóm phát triển và thực hiện việc thẩm định sản phẩm phần mềm liên tục sau mỗi vòng lặp phát triển trong suốt quá trình thực hiện dự án phần mềm Chính điều này giúp cho việc phát triển phần mềm theo phương pháp Agile trở nên rất nhanh chóng và giảm được nhiều chi phí cho việc sửa lỗi do lỗi được phát hiện từ rất sớm

Hình 1 1 Minh họa sử dụng quy trình kiểm chứng và thẩm định trong quá

trình phát triển phần mềm

Trong kiểm thử phần mềm, các khái niệm như lỗi, sai, khuyết thiếu, thất bại đều có nghĩa khá gần nhau nhưng trên thực tế cần phân biệt rõ 4 khái niệm này

 Lỗi: do lập trình viên phạm phải trong quá trình lập trình Khi lỗi được thực thi sẽ dẫn tới thất bại

 Sai: bắt nguồn từ lỗi, do quá trình thực hiện không tuân theo quy trình dẫn đến phần mềm thực hiện một cách không xác định

 Thất bại: xảy ra khi chức năng của phần mềm không thực hiện đúng như mong đợi

 Khuyết thiếu: là sự thiếu sót các trường hợp có thể xảy ra khi phần mềm hoạt động, có thể do đặc tả thiếu hoặc thiếu sót khi lập trình

 Kiểm thử động là kỹ thuật chỉ được thực hiện khi mã nguồn chương trình phần mềm được biên dịch và chạy Mục đích chính của kỹ thuật kiểm thử động là thẩm định xem chương trình phần mềm có hoạt động đúng và đầy đủ các chức năng như những mong muốn của người sử dụng hay không, do đó trong quy trình kiểm chứng và thẩm định chất lượng phần mềm thì kiểm thử động được sử dụng trong

quy trình thẩm định

2 Vấn đề về đảm bảo chất lượng phần mềm

2.1 Lỗi phần mềm là gì?

Có rất nhiều định nghĩa khác nhau về lỗi phần mềm, nhưng tựu chung

có thể phát biểu một cách tổng quát: “Lỗi phần mềm là sự không khớp giữa chương trình và đặc tả của nó”

Dựa vào định nghĩa, chúng ta có thể thấy lỗi phần mềm xuất hiện theo

ba dạng sau:

• Sai: Sản phẩm được xây dựng khác với đặc tả

• Thiếu: Một yêu cầu đã được đặc tả nhưng lại không có trong sản phẩm được xây dựng

• Thừa: Một yêu cầu được đưa vào sản phẩm mà không có trong đặc

6

tả Cũng có trường hợp yêu cầu này có thể là một thuộc tính sẽ được người dùng chấp nhận nhưng khác với đặc tả nên vẫn coi là có lỗi

2.2 Tại sao lỗi phần mềm xuất hiện

Khác với sự cảm nhận thông thường, lỗi xuất hiện nhiều nhất không phải do lập trình Nhiều nghiên cứu đã được thực hiện trong các dự án từ rất nhỏ đến các dự án rất lớn và kết quả luôn giống nhau Số lỗi do đặc tả gây ra

là nhiều nhất, chiếm khoảng 80% Có một số nguyên nhân làm cho đặc tả tạo

ra nhiều lỗi nhất Trong nhiều trường hợp, đặc tả không được viết ra Các nguyên nhân khác có thể do đặc tả không đủ cẩn thận, nó hay thay đổi, hoặc

do chưa phối hợp tốt trong toàn nhóm phát triển Sự thay đổi yêu cầu của khách hàng cũng là nguyên nhân dễ gây ra lỗi phần mềm Khách hàng thay đổi yêu cầu không cần quan tâm đến những tác động sau khi thay đổi yêu cầu như phải thiết kế lại, lập lại kế hoạch, làm lại những việc đã hoàn thành Nếu

có nhiều sự thay đổi, rất khó nhận biết hết được phần nào của dự án phụ thuộc

và phần nào không phụ thuộc vào sự thay đổi Nếu không giữ được vết thay đổi rất dễ phát sinh ra lỗi

Hình 1 2 Các nguyên nhân gây ra lỗi phần mềm

7

Nguồn gây ra lỗi lớn thứ hai là thiết kế Đó là nền tảng mà lập trình

viên dựa vào để nỗ lực thực hiện kế hoạch cho phần mềm

Lỗi do lập trình gây ra cũng khá dễ hiểu Ai cũng có thể mắc lỗi khi lập trình Thời kì đầu, phát triển phần mềm có nghĩa là lập trình, công việc lập trình thì nặng nhọc, do đó lỗi do lập trình gây ra là chủ yếu Ngày nay, công việc lập trình chỉ là một phần việc của quá trình phát triển phần mềm, cộng với sự hỗ trợ của nhiều công cụ lập trình cao cấp, việc lập trình trở nên nhẹ nhàng hơn, mặc dù độ phức tạp phần mềm lớn hơn rất nhiều Do đó, lỗi do lập trình gây ra cũng ít hơn Tuy nhiên, nguyên nhân để lập trình tạo ra lỗi lại nhiều hơn Đó là do độ phức tạp của phần mềm, do tài liệu nghèo nàn, do sức

ép thời gian hoặc chỉ đơn giản là những lỗi “không nói lên được” Một điều cũng hiển nhiên là nhiều lỗi xuất hiện trên bề mặt lập trình nhưng thực ra lại

do lỗi của đặc tả hoặc thiết kế

Một nguyên nhân khác tạo ra lỗi là do bản thân các công cụ phát triển phần mềm cũng có lỗi như công cụ trực quan, thư viện lớp, bộ biên dịch,…

2.3 Chi phí cho việc sửa lỗi

Bảo trì là phần chi phí chính của phần mềm và kiểm thử là hoạt động chi phí đắt thứ hai, ước tính khoảng 40% (15/33) chi phí trong quá trình phát triển ban đầu của sản phẩm phần mềm Kiểm thử cũng là phần chi phí chính của giai đoạn bảo trì do phải tiến hành kiểm thử lại những thay đổi trong quá trình sửa lỗi và đáp ứng yêu cầu người dùng

Kiểm thử và sửa lỗi có thể được thực hiện tại bất kỳ giai đoạn nào của vòng đời phần mềm Tuy nhiên chi phí cho việc tìm và sửa lỗi tăng một cách đáng kể trong quá trình phát triển

3 Quy trình kiểm thử phần mềm

Software Testing Life Cycle đề cập đến một quy trình Test (Testing process) trong đó các bước cụ thể được thực hiện theo một trình tự nhất định

8

để đảm bảo mục tiêu chất lượng được đáp ứng Trong quy trình kiểm thử phần mềm mỗi hoạt động được thực hiện một cách có kế hoạch và hệ thống Mỗi một giai đoạn có các mục tiêu khác nhau

Hình 1 3 Quy trình kiểm thử phần mềm

Requirement Analysis (giai đoạn tìm hiểu và phân tích yêu cầu): Đây

là giai đoạn tiếp cận dự án được thực hiện bởi toàn bộ team (project manager, developer, tester, QA…) cùng tham gia để phân tích các nghiệp vụ trong SRS thành các đơn vị chức năng của chương trình cần xây dựng

Test Planning (giai đoạn lập kế hoạch): Đây là giai đoạn được thực hiện

bởi Test Manager/ Test Leader, dựa vào các đặc tả SRS đã phân tích, phối hợp cùng project manager lập lên kế hoạch test cho dự án (Thời gian thực hiện, nhân

lực, các phương pháp/kỹ thuật sẽ áp dụng, môi trường kiểm thử…)

Testcase Development (giai đoạn lập các trường hợp kiểm thử): Sau

khi có test plan, đội ngũ tester bắt đầu vào giai đoạn thiết kế các trường hợp kiểm thử cho các chức năng trong dự án, sau khi testcase được thiết kế xong

sẽ được test leader, test manager phê duyệt để đưa vào giai đoạn thực hiện test sau này

9

Environment Setup (giai đoạn thiết lập môi trường kiểm thử): Sau khi

hoàn thành xong giai đoạn thiết kế các trường hợp kiểm thử, đội test sẽ tiếp tục chuẩn bị các môi trường kiểm thử (hệ điều hành, browser, thiết bị…) để sẵn sàng đưa sản phẩm vào thực hiện test sau khi hoàn thành xong

Test Execution (giai đoạn thực hiện test): Sau khi dự án hoàn thành

được 70% thì đội test bắt đầu đưa sản phẩm vào thực hiện test vòng 1(test sơ

bộ, vừa test vừa thực hiện nghiệp vụ) Vòng 2 sẽ bắt đầu ngay sau khi sản phẩm hoàn thành 100% (Test hết tất cả các testcase đã thiết kế và tiến hành log bug vào hệ thống) Vòng 03 sẽ bắt đầu khi những bug mà tester tìm ra ở vòng test thứ 2 được xử lý hết và đội lập trình triển khai phiên bản mới

Chú ý: Số vòng test có thể nhiều hơn hoặc ít hơn tùy thuộc vào quy mô

cũng như yêu cầu của dự án

Test Cycle Closure (giai đoạn kết thúc): Sau khi dự án thỏa mãn các

tiêu chí về chất lượng, test leader/test manager tiến hành xác minh, tổng kết quá trình test để sẵn sàng ra mắt cho khách hàng Đội test sẽ tiến hành lập báo cáo kiểm thử cho quản lý trực tiếp phục vụ cho việc làm tài liệu dự án gửi cho khách hàng Tiếp theo đó, đội test có thể sẽ tiếp tục làm hướng dẫn sử dụng hoặc tài liệu triển khai phần mềm

10

CHƯƠNG 2: MỘT SỐ KỸ THUẬT VÀ CÔNG CỤ KIỂM THỬ PHẦN MỀM

Có thể chia các kỹ thuật kiểm thử phần mềm thành hai loại: các kỹ thuật kiểm thử hộp đen (black-box testing) và kỹ thuật kiểm thử hộp trắng (white-box testing) Kiểm thử sử dụng kỹ thuật hộp đen thường được gọi đơn giản là các kiểm thử black-box Các kiểm thử black-box tìm các lỗi như thiếu các chức năng, khả năng sử dụng và các yêu cầu phi chức năng

Các kỹ thuật kiểm thử white-box yêu cầu hiểu biết về cấu trúc chương trình bên trong và các kiểm thử nhận được từ đặc tả thiết kế bên trong

2.1.1 Mục tiêu kiểm thử

Các nguyên tắc được xem như mục tiêu kiểm thử là:

- Kiểm thử là một quá trình thực thi chương trình với mục đích tìm lỗi

- Một trường hợp kiểm thử tốt là trường hợp kiểm thử mà có khả năng cao việc tìm thấy các lỗi chưa từng được phát hiện

- Một kiểm thử thành công là kiểm thử mà phát hiện lỗi chưa từng được phát hiện

2.1.2 Luồng thông tin kiểm thử

- Cấu hình phần mềm: gồm các đặc tả yêu cầu, đặc tả thiết kế, và mã nguồn

- Cấu hình kiểm thử: gồm có kế hoạch kiểm thử, các thủ tục, trường hợp kiểm thử, và các công cụ kiểm thử

11

2.2 Một số kỹ thuật kiểm thử phần mềm

2.2.1 Kỹ thuật kiểm thử hộp trắng (White - Box Testing)

Kiểm thử hộp trắng hay còn gọi là kiểm thử hướng logic, cho phép kiểm tra cấu trúc bên trong của phần mềm với mục đích đảm bảo rằng tất cả các câu lệnh và điều kiện sẽ được thực hiện ít nhất một lần

Hộp trắng đúng nghĩa phải gọi là hộp trong suốt Chính vì vậy, kỹ thuật này còn có một số tên khác là kiểm thử hộp thuỷ tinh (Glass-Box Testing), hay kiểm thử hộp trong suốt (Clear-Box Testing) Người kiểm thử truy nhập vào mã nguồn chương trình và có thể kiểm tra nó, lấy đó làm cơ sở để hỗ trợ việc kiểm thử

Tương tự như vấn đề kiểm thử đầu vào trong kỹ thuật kiểm thử hộp đen, đó là vấn đề kiểm thử các đường dẫn lệnh trong kỹ thuật hộp trắng Nếu phải thực hiện tất cả các đường dẫn của lưu trình điều khiển trong chương trình thông qua việc chạy tất cả các trường hợp kiểm thử thì có thể nói rằng chương trình đã được kiểm thử triệt để Tuy nhiên điều đó không thể thực hiện được vì số đường dẫn logic khác nhau trong một chương trình là cực kỳ lớn Ví dụ trong hình 2.2, sơ đồ khối của một chu trình điều khiển Sơ đồ biểu diễn một vòng lặp từ 1 đến 20 lần Trong thân của vòng lặp có một tập các lệnh điều kiện rẽ nhánh lồng nhau Số đường dẫn trong vòng lặp là 5 Như vậy, tổng số đường dẫn có thể là (5 + 52 + 53 + … + 520) khoảng xấp xỉ 1014

Ngoài những điều bất khả thi như trên, chương trình cũng có thể còn nhiều lỗi do các nguyên nhân khác Đây chính là nhược điểm của kỹ thuật kiểm thử hộp trắng

- Việc kiểm thử bằng kỹ thuật hộp trắng không thể đảm bảo rằng chương trình đã tuân theo đặc tả

- Một chương trình sai do thiếu đường dẫn Việc kiểm thử hộp trắng không thể biết được sự thiếu sót này

Nguyên tắc của kỹ thuật kiểm thử hộp trắng là:

- Thực hiện mọi đường dẫn độc lập ít nhất một lần

- Thực hiện mọi điều kiện logic (if-then-else) trên các giá trị true và false của chúng

- Thực hiện mọi vòng lặp (các vòng lặp for, while-do) tại các biên và trong phạm vi hoạt động của chúng

- Thực hiện mọi cấu trúc dữ liệu bên trong để đảm bảo tính hợp lệ của chúng

2.2.2 Kỹ thuật kiểm thử đường dẫn cơ bản (Basic Path Testing)

Kiểm thử đường dẫn cơ sở là một kỹ thuật kiểm thử hộp trắng do Tom McCabe đề xuất Phương pháp đường dẫn cơ sở cho phép người thiết kế trường hợp kiểm thử thực hiện phép đo độ phức tạp logic của thiết kế thủ tục

và sử dụng phép đo này như một chỉ dẫn cho việc thiết kế một tập cơ sở các đường dẫn thực hiện Những trường hợp kiểm thử được suy diễn để thực hiện tập cơ sở Các trường hợp kiểm thử đó được đảm bảo để thực hiện mỗi lệnh trong chương trình ít nhất một lần trong quá trình kiểm thử

2.2.2.1 Đồ thị lưu trình (Flow Graph)

Trong thực tế, phương pháp đường dẫn cơ sở có thể được dùng không cần sử dụng đồ thị lưu trình Tuy nhiên, đồ thị lưu trình là một công cụ hữu ích để hiểu lưu trình điều khiển và minh hoạ phương pháp tiếp cận Phần này

sẽ trình bày một số ký hiệu đơn giản của lưu trình điều khiển, được gọi là đồ thị lưu trình Đồ thị lưu trình vẽ lưu trình điều khiển logic sử dụng một số ký

13

hiệu được minh hoạ như hình 2.1 Mỗi cấu trúc điều khiển có một ký hiệu đồ thị lưu trình tương ứng

Đồ thị lưu trình gồm có:

- Mỗi hình tròn gọi là đỉnh, biểu diễn một hoặc nhiều lệnh thủ tục

- Con trỏ được gọi là cung hoặc liên kết biểu diễn lưu trình điều

khiển Một cung cần phải kết thúc tại một đỉnh

- Mỗi đỉnh có chứa điều kiện gọi là đỉnh điều kiện

- Phần được bao bởi các cung và các đỉnh gọi là vùng

Tuần tự Rẽ nhánh Lựa chọn Lặp While

Hình 2 1 Ký hiệu đồ thị lưu trình 

 Biểu diễn các điều kiện phức trong đồ thị lưu trình

Khi gặp các điều kiện phức xuất hiện trong câu lệnh điều kiện được biểu diễn gồm một hoặc nhiều phép toán logic (AND, OR, NOT), cần phải được chia thành các điều kiện đơn trong thực hiện kiểm thử đường dẫn cơ sở Mỗi đỉnh chứa điều kiện được gọi là đỉnh điều kiện và được đặc trưng bởi hai hoặc nhiều cạnh bắt nguồn từ nó

Ví dụ: IF (a OR b) then {Procedure x } else {Procedure y}

IF (c AND d) then {Procedure x} else {Procedure y}

ra ít nhất một tập lệnh xử lý hoặc điều kiện mới

Một số nghiên cứu công nghiệp đã chỉ rằng độ phức tạp Cyclomat càng cao, xác suất hoặc lỗi càng cao

V(G)

Các module trong vùng này dễ xảy ra nhiều lỗi

Việc tính toán độ phức tạp cyclomat sẽ cho chúng ta biết có bao nhiêu đường dẫn cần tìm Cho đồ thị lưu trình G, độ phức tạp Cyclomat V(G) được tính theo một trong 3 công thức sau (dựa trên Lý thuyết đồ thị):

15

1 V(G) = R, trong đó R là số vùng của đồ thị lưu trình

2 V(G) = P + 1, trong đó P là số đỉnh điều kiện có trong đồ thị lưu trình G

3 V(G) = E – N + 2, trong đó E là số cạnh của đồ thị lưu trình, N

là số đỉnh của đồ thị lưu trình G

2.3 Kỹ thuật kiểm thử hộp đen (Black – Box Tesing)

Kỹ thuật kiểm thử hộp đen còn được gọi là kiểm thử hướng dữ liệu (data-driven) hay là kiểm thử hướng vào/ra (input/output driven) Trong kỹ thuật này, người kiểm thử xem phần mềm như là một hộp đen Người kiểm thử hoàn toàn không quan tâm cấu trúc và hành vi bên trong của phần mềm Người kiểm thử chỉ cần quan tâm đến việc tìm các hiện tượng mà phần mềm không hành xử theo đúng đặc tả của nó

Như vậy, cách tiếp cận kiểm thử hộp đen tập trung vào các yêu cầu chức năng của phần mềm Kiểm thử hộp đen cho phép các kỹ sư kiểm thử xây dựng các nhóm giá trị đầu vào mà sẽ thực thi đầy đủ tất cả các yêu cầu chức năng của chương trình Kiểm thử hộp đen không thay thế kỹ thuật hộp trắng, nhưng nó bổ sung khả năng phát hiện các lớp lỗi khác với các phương pháp hộp trắng

Kiểm thử hộp đen cố gắng tìm các loại lỗi sau:

- Các chức năng thiếu hoặc không đúng

- Các lỗi giao diện

- Các lỗi cấu trúc dữ liệu trong truy cập cơ sở dữ liệu bên ngoài

16

kiểm thử Vì kiểm thử hộp đen không để ý có chủ đích cấu trúc điều khiển, sự quan tâm tập trung trên miền thông tin Nếu người ta mong muốn sử dụng phương pháp này để tìm tất cả các lỗi trong chương trình thì điều kiện bắt buộc là phải kiểm thử tất cả các đầu vào, tức là mỗi một điều kiện đầu vào có thể có là một trường hợp kiểm thử Bởi vì nếu chỉ kiểm thử một số điều kiện đầu vào thì không đảm bảo được chương trình đã hết lỗi Tuy nhiên, điều này thực tế không thể thực hiện được

2.3.1 Phân hoạch tương đương

Như đã trình bày, việc kiểm thử tất cả các đầu vào của chương trình là không thể Vì thế, khi kiểm thử chương trình nên giới hạn một tập con tất cả các trường hợp đầu vào có thể có

Một tập con như vậy cần có hai tính chất:

- Mỗi trường hợp kiểm thử nên gồm nhiều điều kiện đầu vào khác nhau có thể để giảm thiểu tổng số các trường hợp cần thiết

- Nên cố gắng phân hoạch các miền đầu vào của một chương trình thành một số xác định các lớp tương đương, sao cho có thể giả định hợp lý rằng việc kiểm thử một giá trị đại diện của mỗi lớp là tương đương với việc kiểm thử một giá trị bất kỳ trong cùng lớp

Hai vấn đề xem xét ở trên tạo thành một phương pháp của kỹ thuật hộp đen và gọi là phân hoạch tương đương Vấn đề thứ hai được sử dụng để phát triển một tập các điều kiện cần quan tâm phải được kiểm thử Vấn đề thứ nhất được sử dụng để phát triển một tập cực tiểu các trường hợp kiểm thử phủ các điều kiện trên

Thiết kế trường hợp kiểm thử bằng phân hoạch tương đương được xử lý theo hai bước: phân hoạch các miền đầu vào/ra thành các lớp tương đương và thiết kế các trường hợp kiểm thử đại diện cho mỗi lớp

17

2.3.2 Phân tích giá trị biên (BVA - Boundary Value Analysis)

Khi thực hiện việc kiểm thử phần mềm theo dữ liệu, chúng ta kiểm tra xem đầu vào của người dùng, kết quả nhận được và kết quả tạm thời bên trong có được xử lý chính xác hay không

Các điều kiện biên là tình trạng trực tiếp ở phía trên và dưới của các lớp tương đương đầu vào và lớp tương đương đầu ra Việc phân tích các giá trị biên khác với phân hoạch tương đương theo hai điểm:

- Từ mỗi lớp tương đương, phân hoạch tương đương sẽ chọn phần tử bất kỳ làm phần tử đại diện, trong khi việc phân tích giá trị biên sử dụng một hoặc một số phần tử Như vậy, mỗi biên của lớp tương đương chính là đích kiểm thử

- Không chỉ chú ý tập trung vào những điều kiện đầu vào, các trường hợp kiểm thử cũng được suy ra từ việc xem xét các kết quả ra (tức các lớp tương đương đầu ra)

Rất khó có thể có thể liệt kê hết các hướng dẫn cụ thể cho các trường hợp Tuy nhiên, cũng có một số nguyên tắc phân tích giá trị biên như sau:

- Nếu điều kiện đầu vào xác định một khoảng giá trị giữa a và b, các trường hợp kiểm thử sẽ được thiết kế với giá trị a và b, và các giá trị sát trên và sát dưới a và b;

- Nếu một điều kiện đầu vào xác định một số các giá trị, các trường hợp kiểm thử sẽ được phát triển để thực hiện tại các giá trị cực đại, cực tiểu Các giá trị sát trên và dưới giá trị cực đại, cực tiểu cũng được kiểm thử;

- Nguyên tắc 1 và 2 được áp dụng cho các điều kiện đầu ra;

- Nếu cấu trúc dữ liệu chương trình bên trong được qui định các biên (chẳng hạn, mảng được định nghĩa giới hạn 100 mục), tập trung thiết

kế trường hợp kiểm thử để thực thi cấu trúc dữ liệu tại biên của nó

có thể vượt qua các kiểm thử khác từ lớp đó

2.3.3 Kỹ thuật đồ thị nhân-quả (Cause-Effect Graph)

Trong nhiều trường hợp, việc cố gắng chuyển một chính sách hoặc một thủ tục trong ngôn ngữ tự nhiên vào phần mềm dẫn đến sự thất bại và các vấn

đề khó hiểu Đồ thị nhân - quả là một phương pháp thiết kế trường hợp kiểm thử trên cơ sở đưa ra một sự mô tả súc tích các điều kiện logic và các hành vi kèm theo

Đồ thị nhân - quả sử dụng mô hình các quan hệ logic giữa nguyên nhân

và kết quả cho thành phần phần mềm Mỗi nguyên nhân được biểu diễn như một điều kiện (đúng hoặc sai) của một đầu vào, hoặc kết hợp các đầu vào Mỗi kết quả được biểu diễn như là một biểu thức Bool biểu diễn một kết quả tương ứng cho những thành phần vừa thực hiện

Đồ thị nhân - quả được tạo như sau:

- Tất cả các nguyên nhân (các đầu vào) và các kết quả (các đầu ra) được liệt kê dựa trên đặc tả và được định danh cho mỗi nhân - quả

- Các quan hệ giữa các nguyên nhân (các đầu vào) và các kết quả (các đầu ra) được biểu diễn trong đồ thị làm rõ ràng các quan hệ logic

- Từ đồ thị tạo ra bảng quyết định biểu diễn các quan hệ giữa nguyên

nhân và kết quả

2.3.4 Kiểm thử so sánh

Có một số trường hợp (như điện tử máy bay, điều khiển thiết bị năng lượng hạt nhân) trong đó độ tin cậy của phần mềm là tuyệt đối quan trọng, người ta thường gọi là phần mềm tuyệt đối đúng Trong các ứng dụng như

19

vậy phần cứng và phần mềm không cần thiết thường được sử dụng để tối thiểu khả năng lỗi Khi phần mềm không cần thiết được phát triển, các nhóm công nghệ phần mềm riêng biệt phát triển các phiên bản độc lập của ứng dụng

sử dụng cùng một đặc tả Trong các trường hợp như vậy, mỗi phiên bản có thể được kiểm thử với cùng dữ liệu kiểm thử để đảm bảo rằng tất cả cung cấp đầu ra y như nhau Sau đó tất cả các phiên bản được thực thi song song với so sánh thời gian thực các kết quả để đảm bảo tính chắc chắn Các phiên bản độc

lập là cơ sở của kỹ thuật kiểm thử hộp đen được gọi là kiểm thử so sánh hay kiểm thử back-to-back

Kiểm thử so sánh là không rõ ràng Nếu đặc tả mà tất cả các phiên bản được phát triển trên đó là có lỗi, thì tất cả các phiên bản sẽ có khả năng dẫn đến lỗi Hơn nữa, nếu mỗi phiên bản độc lập tạo ra giống nhau, nhưng không đúng, các kết qủa, kiểm thử điều kiện sẽ thất bại trong việc phát hiện lỗi

2.4 Kiểm thử tự động

Kiểm thử tự động: Kiểm thử phần mềm tự động là thực hiện kiểm thử phần mềm bằng một chương trình đặc biệt với rất ít hoặc không có sự tương tác của con người, giúp cho người thực hiện việc kiểm thử phần mềm (tester) không phải lặp đi lặp lại các bước nhàm chán.Công cụ kiểm thử tự động có thể lấy dữ liệu từ file bên ngoài (excel, csv…) nhập vào ứng dụng, so sánh kết quả mong đợi (từ file excel, csv…) với kết quả thực tế và xuất ra báo cáo kết

quả kiểm thử

Kiểm thử động là kỹ thuật chỉ được thực hiện khi mã nguồn chương trình phần mềm được biên dịch và chạy Mục đích chính của kỹ thuật kiểm thử động là thẩm định xem chương trình phần mềm có hoạt động đúng và đầy

đủ các chức năng như những mong muốn của người sử dụng hay không, do

đó trong quy trình kiểm chứng và thẩm định chất lượng phần mềm thì kiểm thử động được sử dụng trong quy trình thẩm định

20

Kiểm thử thủ công là Tester làm mọi công việc hoàn toàn bằng tay, từ viết TEST CASE đến thực hiện test, mọi thao tác như nhập điều kiện đầu vào, thực hiện một số sự kiện khác như click nút và quan sát kết quả thực tế, sau

đó so sánh kết quả thực tế với kết quả mong muốn trong test case, điền kết quả test Hiện nay, phần lớn các tổ chức, các công ty phần mềm, hoặc các nhóm làm phần mềm đều thực hiện kiểm thử thủ công là chủ yếu

So sánh kiểm thử thủ công và kiểm thử tự động:

- Thích hợp kiểm thử trong trường

hợp các test case chỉ phải thực hiện

một số ít lần

- Giảm được chi phí ngắn hạn

- Tốn thời gian Đối với mỗi lần release, người kiểm thử vẫn phải thực hiện lại một tập hợp các test case đã chạy dẫn đến

sự mệt mỏi và lãng phí effort

Tự động

- Thích hợp với trường hợp phải test

nhiều lần cho một case, có tính ổng

định và tin cậy cao hơn so với kiểm

thử thủ công

- Có thể thực hiện các thao tác lặp đi

lặp lại (nhập dữ liệu, click, check kết

quả ) giúp tester không phải làm

21

Kỹ thuật kiểm thử động chia làm 2 loại là kiểm thử chức năng và kiểm thử phi chức năng Kiểm thử chức năng được thực hiện bằng cách sử dụng trực tiếp chức năng cần được kiểm thử, sau đó đưa dữ liệu đầu vào và nhận được dữ liệu đầu ra Dữ liệu đầu ra này sẽ được so sánh với dữ liệu đầu ra được ước lượng trước đó dựa theo dữ liệu đầu vào và tài liệu đặc tả để tìm ra lỗi hoặc thiếu sót Kiểm thử phi chức năng bao gồm nhiều loại như kiểm thử hiệu năng hoạt động, độ tin cậy, khả năng bảo mật, khả năng tương thích, tính sẵn sàng,…

Ưu điểm của kỹ thuật kiểm thử động:

 Thời gian và chi phí thực hiện thấp

 Thực hiện được ở tất cả các mức

kiểm thử Nhược điểm của kỹ thuật:

 Đòi hỏi phải biên dịch và chạy chương trình trước khi kiểm thử

 Khi có lỗi xảy ra, rất khó để tìm ra nguyên nhân và vị trí mã nguồn gây ra lỗi

2.4.1 Kiểm thử hàm

Kiểm thử hàm hay còn gọi là kiểm thử chức năng là các hoạt động kiểm tra chương trình dựa trên tài liệu đặc tả chức năng Kiểm thử hàm dựa trên quan niệm rằng bất kỳ chương trình nào cũng được coi là một hàm ánh

xạ các giá trị từ miền dữ liệu đầu vào vào miền dữ liệu đầu ra của nó Với cách tiếp cận của kiểm thử hàm, để xác định các ca kiểm thử, thông tin duy nhất được dùng là đặc tả của phần mềm cần kiểm thử

Một hàm trong toán học được định nghĩa bởi cặp các tập (Xi, Yi) trong đó Xi là tập giá trị đầu vào và Yi là tập giá trị đầu ra Một chương trình P được xem là một hàm chuyển đổi tập giá trị đầu vào Xi thành tập giá trị đầu ra Yi, có thể viết là Yi = P(Xi) Xét một số ví dụ sau:

 Kiểm thử phân lớp tương đương

 Kiểm thử giá trị biên

 Bảng quyết định

 Kiểm thử ngẫu nhiên

 Đoán nhận lỗi

2.4.2 Kiểm thử dòng điều khiển

Hai dạng câu lệnh chính trong mã nguồn chương trình là câu lệnh gán

và câu lệnh điều kiện Có thể nhận ra câu lệnh gán bằng biểu tượng dấu “=”,

ví dụ như x = 2 * y, trong đó x và y là các biến Các câu lệnh điều kiện là các câu lệnh như if(), for(), while(), switch(), , ví dụ như if(x > 2) thì sẽ kiểm tra xem biến x có lớn hơn 2 hay không Trong chương trình, nếu như câu lệnh điều kiện bị thiếu hoặc viết sai có thể dẫn tới việc một đoạn mã nào đó không được thực hiện gây ra lỗi hoặc thất bại Ý tưởng của kiểm thử dòng điều khiển chính là việc xây dựng một đồ thị dòng điều khiển và thiết kế các

ca kiểm thử dựa trên các đường đi của đồ thị đó Đồ thị dòng điều khiển là

đồ thị có các đỉnh tương ứng với các câu lệnh hay nhóm các câu lệnh và các cạnh là các dòng điều khiển giữa các câu lệnh hay nhóm các câu lệnh

Để xây dựng đồ thị dòng điều khiển cần dựa trên các biểu tượng như hình 2.4 Hình chữ nhật đại diện cho câu lệnh gán hay nhóm câu lệnh gán,

23

hình thoi đại diện cho câu lệnh điều kiện, hình tròn không chứa câu lệnh mà chỉ đại diện cho điểm hợp nhất các câu lệnh (thường dùng cho vòng lặp)

Hình 2 4 Các biểu tượng xây dựng đồ thị dòng điều khiển

Để minh họa rõ hơn về xây dựng đồ thị dòng điều khiển, xin xét ví dụ hình 2.4 và đồ thị dòng điều khiển của nó ở bảng sau:

int i, n = 10, sum = 0;

for ( i= 1; i < n; i ++) {

sum + = i;

}

24

Hình 2 5 Đồ thị dòng điều khiển minh họa bảng trên

Bảng 1.1 Các điều kiện con kết hợp trong câu lệnh điều kiện

25

CHƯƠNG 3: MỘT SỐ CÔNG CỤ KIỂM THỬ PHẦN MỀM

3.1 Công cụ kiểm thử Jmeter

3.1.1 Giới thiệu chung về Jmeter

- Phần mềm kiểm thử tự động mã nguồn mở Jmeter;

- Jmeter được xây dựng và phát triển bởi Stefano Mazzocchi để kiểm thử hiệu năng FTP server, máy chủ CSDL, Java servlet và các đối tượng;

- Nổi trội hơn JMeter là công cụ LoadRuner nhưng bị hạn chế LoadRuner chỉ sử dụng được trên Windows, có phí và chỉ hỗ trợ giao thứ nền HTTP JMeter thì nổi trội hơn do hỗ trợ nhiều giao thức và sử dụng trên nhiều môi trường khác nhau: Web - HTTP, HTTPS sites 'web 1.0' web 2.0

3.1.2 Đặc trưng của Jmeter

- Nguồn mở, miễn phí

- Giao diện đơn giản, trực quan dễ sử dụng

- Có thể kiểm thử nhiều kiểu server: Web - HTTP, HTTPS, SOAP, Database - JDBC, LDAP, JMS, Mail - POP3,…

- Một công cụ độc lập có thể chạy trên nhiều nền tảng hệ điều hành khác nhau, trên Linux chỉ cần chạy bằng một shell scrip, trên Windows thì chỉ cần chạy một file bat

- Đa luồng, giúp xử lý tạo nhiều request cùng một khoảng thời gian, xử lý các dữ liệu thu được một cách hiệu quả

- Đặc tính mở rộng, có rất nhiều plugin được chia trẻ rộng rãi và miễn phí

3.1.3 Các thành phần chính của Jmeter

- Test Plan: Bao gồm các bước sẽ được JMeter thực thi

- Thread Group: Đại diện cho người dùng ảo (virtual user), có thể gồm các thành phần sau:

 Config Element: Sử dụng để thêm vào những thay đổi/ cấu hình cần thiết cho các sampler

 Timer: Điều chỉnh khoảng thời gian dừng giữa các lần gửi yêu cầu

 Pre/Post Processor: Cho phép thực hiện một số bước cần thiết ngay trước/ sau khi chạy một sampler nào đó

 Assertion: Các phương pháp xác nhận thông tin trả về từ đối tượng kiểm tra có đúng với mong đợi hay không

 Listener: Cho phép thu thập thông tin kết quả Có thể đưa ra các báo cáo kết quả kiểm tra dạng đồ thị, hoặc xuất ra tập tin

3.2 Công cụ kiểm thử QuickTest Pro

3.2.1 Giới thiệu chung về QuickTest Pro

Quick Test Professional là phần mềm kiểm soát việc kiểm thử tự động các chức năng của các sản phẩm phần mềm cần kiểm thử Sản phẩm này bao gồm một tập các mô-đun có thể tương tác với nhau nhằm quản lý toàn bộ quy trình kiểm thử phần mềm Quick Test Professional là một công cụ hỗ trợ kiểm thử hàm (kiểm thử chức năng) và cho phép tiến hành kiểm thử hồi quy một cách tự động

3.2.2 Đặc trưng của QuickTest Pro

- Dễ sử dụng, bảo trì, tạo Test Script nhanh Cung cấp dữ liệu kiểm tra rõ ràng dễ hiểu

- Kiểm tra phiên bản mới của ứng dụng với rất ít sự thay đổi

- Với chức năng Recovery Scenarios, QuickTest Pro cho phép sử lý những

sự kiển hoặc lỗi không thể đoán trước có thể làm script bị dừng trong khi đang chạy

- QuickTest Pro có khả năng hiểu test script của Mercury Winrunner (một công cụ kiểm tra khác của mercury)

3.2.3 Các thành phần chính của QuickTest Pro

a Action

Giống như thủ tục hay hàm trong các ngôn ngữ lập trình khác, Action ghi lại các bước thực hiện kiểm thử và nó có thể được sử dụng lại nhiều lần Trong một Test Script có thể có nhiều Action

b DataTable

Nơi lưu trữ dữ liệu phục vụ cho kiểm thử Một Test Script sẽ có một DataTable được dùng chung cho tất cả các Action Bên cạnh đó mỗi Action cũng có một DataTable riêng cho mình

c Object Repository (OR)

Cấu trúc theo dạng cây, mô tả các đối tượng trong phần mềm được kiểm tra Đây được xem là cầu nối để Test Script tương tác với phần mềm được kiểm tra

Khi ra lệnh cho QuickTest Pro ghi lại thao tác người dùng lên phần mềm thì trong OR sẽ tự động phát sinh thành phần đại diện cho những đối tượng trên phần mềm vừa được thao tác OR có thể tổ chức thành 2 loại, một loại dùng chung trong nhiều Test Script, loại khác dùng theo từng nhóm Action