Tìm Hiểu Các Kỹ Thuật Kiểm Thử Phần Mềm và Một Số Ứng Dụng Trong Thực Tế

Báo cáo bài tập lớn Kỹ thuật phần mềm

1

TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘIVIỆN CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG

----------------------------------------------

BÀI TẬP LỚN MÔN KỸ THUẬT PHẦN MỀM

ĐỀ TÀI : Tìm Hiểu Các Kỹ Thuật Kiểm Thử Phần Mềm và Một Số Ứng Dụng Trong Thực Tế (BTL05)

Giảng viên hướng dẫn: TS. Vũ Thị Hương Giang

Nhóm sinh viên thực hiện:

Trần Anh Thơ – CNPMK53 – 20082569Nguyễn Ngọc Toàn– CNPMK53 – 20082704Nguyễn Thế Anh – CNPMK53 – 20080070Vũ Hồng Quân – CNPMK53 – 20082128

Hà Nội 10/2011


----------------------------------------------






Hà Nội 10/2011


----------------------------------------------






Hà Nội 10/2011


----------------------------------------------






Hà Nội 10/2011


----------------------------------------------






Hà Nội 10/2011


----------------------------------------------






Hà Nội 10/2011


----------------------------------------------






Hà Nội 10/2011


----------------------------------------------






Hà Nội 10/2011


----------------------------------------------






Hà Nội 10/2011


----------------------------------------------






Hà Nội 10/2011


----------------------------------------------






Hà Nội 10/2011


----------------------------------------------






Hà Nội 10/2011


----------------------------------------------






Hà Nội 10/2011


----------------------------------------------






Hà Nội 10/2011


----------------------------------------------






Hà Nội 10/2011


----------------------------------------------






Hà Nội 10/2011


----------------------------------------------






Hà Nội 10/2011


----------------------------------------------






Hà Nội 10/2011


----------------------------------------------






Hà Nội 10/2011


----------------------------------------------






Hà Nội 10/2011


----------------------------------------------






Hà Nội 10/2011


----------------------------------------------






Hà Nội 10/2011


----------------------------------------------






Hà Nội 10/2011


----------------------------------------------






Hà Nội 10/2011


----------------------------------------------






Hà Nội 10/2011


----------------------------------------------






Hà Nội 10/2011


----------------------------------------------






Hà Nội 10/2011


----------------------------------------------






Hà Nội 10/2011


----------------------------------------------






Hà Nội 10/2011


----------------------------------------------






Hà Nội 10/2011


----------------------------------------------






Hà Nội 10/2011


----------------------------------------------






Hà Nội 10/2011


----------------------------------------------






Hà Nội 10/2011


----------------------------------------------






Hà Nội 10/2011


MỤC LỤC

>>>LỜI NÓI ĐẦU.....................................................................................................................51. Tổng quan về kiểm thử....................................................................................................6

1.1 Các khái niệm cơ bản.................................................................................................61.1.1 Định nghĩa..........................................................................................................61.1.2. Một số thuật ngữ và khái niệm thường gặp trong kiểm thử..............................6

1.2. Một số đặc điểm của kiểm thử..................................................................................71.2.1. Các khó khăn khi kiểm thử................................................................................71.2.2. Một số lưu ý khi kiểm thử.................................................................................7

1.3. Phân loại kiểm thử....................................................................................................71.4. Mô hình chữ V trong kiểm thử.................................................................................81.5. Vòng đời của kiểm thử.............................................................................................91.6. Các tiêu chí đánh giá kiểm thử...............................................................................10

2. Sơ lược các kỹ thuật kiểm thử phần mềm.....................................................................122.1. Kiểm thử tầm hẹp...................................................................................................12

2.1.1. Kiểm thử hộp đen............................................................................................122.1.2. Kiểm thử hộp trắng..........................................................................................172.1.3. Kiểm thử hộp xám...........................................................................................23

2.2. Kiểm thử tầm rộng..................................................................................................242.2.1 Kiểm thử đơn vị (Unit Testing)........................................................................242.2.2 Kiểm thử tích hợp (Integration Test)................................................................252.2.3. Kiểm thử hệ thống (System Testing)...............................................................272.2.4. Kiểm thử chấp nhận (Acceptance Testing)......................................................28

3. Các chiến lược kiểm thử phần mềm..............................................................................303.1 Khái quát..................................................................................................................303.2 Chiến lược kiểm thử................................................................................................30

4. Các công cụ kiểm thử phần mềm...................................................................................334.1.Quick test pro...........................................................................................................33

4.1.1 Giới thiệu..........................................................................................................334.1.2 Loại phần mềm hỗ trợ.......................................................................................344.1.3 Đặc điểm...........................................................................................................344.1.4 Các thành phần quan trọng trong QTP.............................................................35

2


4.1.5 Ngôn ngữ viết script.........................................................................................364.2 JUnit.........................................................................................................................36

4.2.1 Giới thiệu..........................................................................................................364.2.2 Các thành phần quan trọng của JUnit...............................................................374.2.3 Cách tổ chức chương trình chạy với JUnit.......................................................38

4.3 Load Runner............................................................................................................394.3.1 Giới thiệu..........................................................................................................394.3.2 Đặc điểm...........................................................................................................404.3.3 Môi trường hỗ trợ.............................................................................................404.3.4 Các bước thực hiện...........................................................................................41

4.4 NUnitTest................................................................................................................424.4.1 Khái quát...........................................................................................................42

5. Demo JUnit(Java) – NUnit(C#).....................................................................................445.1 JUnit (trong Java)....................................................................................................445.2 NUnit (trong C#)......................................................................................................46

6. Tài Liệu Tham Khảo......................................................................................................49

3


Bảng Phân Công Công Việc Trong Nhóm

Họ và Tên Công việc thực hiện Mức độ hoàn thành

Trần Anh Thơ Tổng quan về kiểm thử,Các kỹ thuật kiểm thử phần mềm

100%

Nguyễn Ngọc Toàn Các kỹ thuật kiểm thử phần mềm 100%

Nguyễn Thế AnhCác chiến lược kiểm thử phần mềmDemo Unit Testing trong Java(JUnitTest) và C#(NUnitTest) 100%

Vũ Hồng Quân Các công cụ kiểm thử phần mềm 100%

Tài liệu doc này sẽ đi kèm với 2 Project Test (một của Java và một của C#)

4


L I NÓI Đ UỜ ẦTrong ngành kỹ nghệ phần mềm, năm 1979, có một quy tắc nổi tiếng là: “Trong một dự án lập trình điển hình, thì xấp xỉ 50% thời gian và hơn 50% tổng chi phí được sử dụng trong kiểm thử các chương trình hay hệ thống đã được phát triển”. Và cho đến nay, sau gần một phần 3 thế kỷ, quy tắc đó vẫn còn đúng. Đã có rất nhiều ngôn ngữ, hệ thống phát triển mới với các công cụ tích hợp cho các lập trình viên sử dụng phát triển ngày càng linh động. Nhưng kiểm thử vẫn đóng vai trò hết sức quan trọng trong bất kỳ dự án phát triển phần mềm nào.Rất nhiều các giáo sư, giảng viên đã từng than phiền rằng: “ Sinh viên của chúng ta tốt nghiệp và đi làm mà không có được những kiến thực thực tế cần thiết về cách để kiểm thử một chương trình. Hơn nữa, chúng ta hiếm khi có được những lời khuyên bổ ích để cung cấp trong các khóa học mở đầu về cách một sinh viên nên làm về kiểm thử và gỡ lỗi các bài tập của họ”. Các tác giả của cuốn sách nổi tiếng “The Art of Software Testing” – Nghệ thuật kiểm thử phần mềm, Glenford J. Myers, Tom Badgett, Todd M. Thomas, Corey Sandler đã khẳng định trong cuốn sách của mình rằng: “ Hầu hết các thành phần quan trọng trong các thủ thuật của một nhà kiểm thử chương trình là kiến thức về cách để viết các ca kiểm thử có hiệu quả”. Việc xây dựng các test – case là một nhiệm vụ rất khó khăn. Để có thể xây dựng được tập các test – case hữu ích cho kiểm thử, chúng ta cần rất nhiều kiến thức và kinh nghiệm. Đó là những lý do thúc đẩy nhóm em thực hiện đề tài này. Mục đích của đề tài là tìm hiểu những kiến thức tổng quan nhất về kiểm thử, và cách thiết kế test – case trong kiểm thử phần mềm. Việc thực hiện đề tài sẽ giúp em tìm hiểu sâu hơn và lĩnh vực rất hấp dẫn này, vận dụng được các kiến thức đã học để có thể thiết kế được các test – case một cách có hiệu quả và áp dụng vào những bài toán thực tế.Bản báo cáo được hoàn thành dưới sự hướng dẫn tận tình của cô giáo, TS Vũ Thị Hương Giang, sự giúp đỡ nhiệt tình của các thầy cô trong bộ môn Công nghệ phần mềm, và tất cả các bạn. Chúng em hi vọng sẽ nhận được sự đóng góp ý kiến của các thầy cô và các bạn để bản báo cáo được hoàn thiện hơn. Những đóng góp đó sẽ là kinh nghiệm quý báu cho nhóm. Và từ đó, chúng em có thể tiếp tục phát triển đề tài này cho công việc trong tương lai. Chúng em xin chân thành cám ơn.

Nhóm Sinh Viên Bài tập lớn

5


1. T ng quan v ki m thổ ề ể ử1.1 Các khái ni m c b nệ ơ ả1.1.1 Đ nh nghĩaịCó thể có nhiều cách định nghĩa kiểm thử và sau đây là một số cách định nghĩa chính:

Kiểm thử là quá trình vận hành hệ thống hoặc thành phần dưới những điều kiện xác định, quan sát hoặc ghi nhận kết quả và đưa ra đánh giá về hệ thống hoặc thành phần đó (IEEE)

Kiểm thử là quá trình thực thi một chương trình với mục đích tìm ra lỗi (Mayer – The art of software testing)

Kiểm thử phần mềm là hoạt động khảo sát thực tiễn sản phẩm hay dịch vụ phần mềm trong đúng môi trường chúng dự định sẽ được triển khai nhằm cung cấp cho những người có lợi ích liên quan những thông tin về chất lượng của sản phẩm hay dịch vụ phần mềm ấy. Mục đích của kiểm thử phần mềm là tìm ra các lỗi hay khiếm khuyết phần mềm nhằm đảm bảo hiệu quả hoạt động tối ưu của phần mềm trong nhiều ngành khác nhau. (Wikipedia)

1.1.2. M t s thu t ng và khái ni m th ng g p trong ki m thộ ố ậ ữ ệ ườ ặ ể ử Lỗi (Error): Là một lỗi lầm trong phần mềm do con người gây ra. Sai sót (Fault): Sai sót gây ra lỗi. Sai sót có thể được phân loại như

sau: Sai sót do đưa ra dư thừa – Đưa ra một vài thứ không chính xác

vào mô tả yêu cầu phần mềm Sai sót do bỏ sót – Bỏ sót một số phần đáng ra phải có trong

phần mô tả yêu cầu phần mềm Hỏng hóc (Failure): Hỏng hóc xảy ra khi sai sót được thực thi. Trạng

thái hỏng hóc sẽ xảy ra tại các nơi bị sai trong chương trình. Kết quả không mong đợi (Incident): Là những kết quả do sai sót đem

đến. Hậu quả là các triệu chứng liên kết với một hỏng hóc và báo cho người dùng biết sự xuất hiện của hỏng hóc

Trường hợp kiểm thử (Test case): Là một bộ bao gồm một tập các dữ liệu đầu vào, các điều kiện thực thi và các kết quả mong đợi với tập các đầu vào đó.

Kịch bản kiểm thử (Test Scenario): Các bước thực hiện khi kiểm thử Kiểm thử viên (Tester): Người thực hiện kiểm thử phần mềm

6


1.2. M t s đ c đi m c a ki m thộ ố ặ ể ủ ể ử1.2.1. Các khó khăn khi ki m thể ử

Nâng cao chất lượng của phần mềm nhưng không vượt quá chất lượng khi thiết kế. Chỉ phát hiện ra các lỗi tiềm tàng và sửa chúng

Phát hiện lỗi bị hạn chế do thực hiện thủ công là chính Do kiểm thử chỉ chạy thử chương trình trên một tập các dữ liệu đầu

vào hữu hạn nên không thể khẳng định là chương trình không có lỗi Thường mắc phải một số đặc trưng chủ quan như:

Bộ dữ liệu kiểm thử không thay đổi trong quá trình xây dựng phần mềm

Chỉ kiểm tra trong các trường hợp hợp lệ mà không quan tâm đến các cận hay các ngoại lệ

Cài đặt chức năng nào thì chỉ kiểm tra chức năng đó

1.2.2. M t s l u ý khi ki m thộ ố ư ể ử Chất lượng phần mềm do khâu thiết kế quyết định là chủ yếu chứ

không phải do khâu kiểm thử Tính dễ kiểm thử phụ thuộc vào cấu trúc chương trình Người kiểm thử và người phát triển nên khác nhau Dữ liệu thử cho kết quả bình thường thì không có ý nghĩa nhiều, cần

có những dữ liệu kiểm thử để phát hiện ra lỗ Khi thiết kế trường hợp thử không chỉ thiết kế dữ liệu kiểm thử đầu

vào mà còn phải thiết kế trước cả dữ liệu kết quả sẽ có Khi phát sinh thêm trường hợp thử thì nên thử lại những trường hợp

trước đó để tránh ảnh hưởng lan truyền sóng

1.3. Phân lo i ki m thạ ể ửCó hai mức phân loại kiểm thử:

Phân biệt theo mức độ chi tiết của các bộ phận hợp thành phần mềm Kiểm thử đơn vị (Unit Testing) Kiểm thử thành phần (Module Testing) Kiểm thử tích hợp (Integration Testing) Kiểm thử hệ thống (System Testing) Kiểm thử chấp nhận (Acceptance Testing)

Phân loại dựa trên phương pháp kiểm thử (Thường dùng ở kiểm thử đơn vị)

Kiểm thử hộp đen (Black box tesing): Dùng để kiểm tra chức năng

7


Kiểm thử hộp trắng (White box testing): Dùng để kiểm tra cấu trúc

Kiểm thử hộp xám (Gray box testing)Cụ thể các hình thức kiểm thử này sẽ được đề cập một cách chi tiết trong phần dưới

1.4. Mô hình ch V trong ki m thữ ể ửMô hình chữ V giải thích sự tương quan giữa các công đoạn xây dựng

phần mềm và các loại kiểm thử

Hình 1 - Mô hình chữ VTa thấy nhánh bên trái của chữ V là từng giai đoạn trong quy trình phát triển phần mềm còn ở nhánh bên phải là từng loại kiểm thử tương ứng với mỗi giai đoạn phát triển đó. Các mức kiểm thử có thể được lập kế hoạch và thiết kế song song với các bước tương ứng trong quy trình phát triển phần mềm. Sau đó chúng ta sẽ thực hiện kiểm thử từ đáy chữ V lên các bước bên trên. Kê hoạch kiểm thử của hệ thống phải được lập trước khi các pha kiểm thử bắt đầu và phải thỏa mãn một số điều kiện sau:

Kiểm thử hệ thống phải khớp với các yêu cầu kiểm thử phần mềm Các trường hợp kiểm thử cần phải được hoàn thành khi mà các thiết

kế chi tiết đã xong Kiểm thử bắt đầu từ ngay sau khi lập trình

Ở mỗi công đoạn xây dựng phần mềm sẽ tương ứng với một loại kiểm thử và cần có một hồ sơ kiểm thử tương ứng được thành lập để phục vụ cho việc kiểm thử. Ví dụ:

8


Công đoạn: Yêu cầu phần mềm, Loại kiểm thử: Kiểm thử chấp nhận, Hồ sơ: Hồ sơ kiểm thử chấp nhận (Acceptance test spec)

Công đoạn: Mô tả chi tiết phần mềm, Loại kiểm thử: Kiểm thử hệ thống, Hồ sơ: Hồ sơ kiểm thử hệ thống (System test spec)

Công đoạn: Hồ sơ kiến trúc (Architecture spec), Loại kiểm thử: Kiểm thử tích hợp, Hồ sơ: Hồ sơ kiểm thử tích hợp (Integration test spec)

Công đoạn: Thiết kế chi tiết, Loại kiểm thử: Kiểm thử khối (Module test), Hồ sơ: Hồ sơ kiểm thử khối (Module test spec)

Công đoạn: Cài đặt, Loại kiểm thử: Kiểm thử đơn vị, Hồ sơ: Hồ sơ kiểm thử đơn vị (Unit test spec)

1.5. Vòng đ i c a ki m thờ ủ ể ửCơ bản kiểm thử tuân theo vòng đời tương ứng với mọi pha của vòng

đời phát triển phần mềm. Trong pha lập kế hoạch dự án người quản lý dự án phải quyết định

những cái gì được kiểm thử dựa trên bản đặc tả yêu cầu phần mềm. Đây là lúc người lãnh đạo kiểm thử và người quản lí dự án làm việc cùng nhau để tạo ra bản kế hoạch kiểm thử phần mềm Software Test Plan (STP) mô tả cho phạm vi, khuôn khổ kiểm thử, phương pháp kiểm thử, lịch biểu kiểm thử, chức năng được kiểm thử hay không kiểm thử, kiểu kiểm thử nào cần được thực hiện ở các pha khác nhau của vòng đời, môi trường cho kiểm thử, và phân công cho từng người kiểm thử.

Trong pha phân tích yêu cầu, thành viên tổ kiểm thử phải kiểm thử bản đặc tả yêu cầu kiểm thử và bản kế hoạch kiểm thử phần mềm để chắc chắn rằng họ hiểu các yêu cầu và điều gì cần được kiểm thử. Họ sẽ thêm nhiều chi tiết vào bản kế hoạch kiểm thử phần mềm để chắc chắn rằng họ đã bao quát mọi chức năng phải được kiểm thử. Sau khi được hoàn thành, bản kế hoạch kiểm thử được sửa đổi sẽ được gửi cho tổ phát triển kiểm điểm để đảm bảo tính đúng đắn, tính đầy đủ của bản kế hoạch này. Cả hai tổ sẽ thảo luận thông tin liên quan tới lịch biểu dự án và phối hợp các hoạt động phát triển với hoạt động kiểm thử. Điều này là quan trọng vì cả người phát triển và người kiểm thử phải làm việc cùng nhau trên các trường hợp kiểm thử, dữ liệu kiểm thử, kịch đoạn kiểm thử cũng như kiểm thử phụ để đảm bảo rằng sản phẩm cuối cùng sẽ đáp ứng yêu cầu của khách hàng. Bản kế hoạch kiểm thử phần mềm được sửa đổi cũng sẽ được gửi tới khách hàng để kiểm điểm và chấp thuận. Một khi được chấp thuận, nó có nghĩa là

9


nếu mọi kiểm thử đều qua được, sản phẩm phần mềm đáp ứng yêu cầu của khách hàng.

Trong pha thiết kế phần mềm, khi người phát triển đưa nhiều chi tiết vào trong thiết kế, người kiểm thử phải làm việc cùng người phát triển để bổ sung thêm chi tiết cho bản kế hoạch kiểm thử và trường hợp kiểm thử. Họ phải xác định kiểm thử nào có thể được tự động hoá và kiểm thử nào phải được thực hiện thủ công. Đây cũng là lúc để nhận diện mọi vấn đề rủi ro và lập kế hoạch giảm nhẹ chúng. Tổ kiểm thử phải xác định dữ liệu kiểm thử cho từng trường hợp kiểm thử, dựng kịch bản kiểm thử cho mọi kiểm thử tự động và sửa lại lịch biểu kiểm thử, nếu cần.

Trong pha cài đặt, khi người phát triển làm việc trên mã của họ và chuẩn bị kiểm thử của họ (kiểm thử đơn vị và kiểm thử chức năng), người kiểm thử cũng phải hoàn thành mọi trường hợp kiểm thử của họ, các kịch bản kiểm thử, bộ dẫn lái kiểm thử và các kiểm thử phụ khác được yêu cầu trong bản đặc tả yêu cầu phần mềm

Trong pha kiểm thử, sau khi người phát triển hoàn thành kiểm thử đơn vị và kiểm thử chức năng của họ, tổ kiểm thử phải thực hiện mọi kiểm thử còn lại. Mọi kết quả đều phải được làm tài liệu như số lỗi, số các kiểm thử qua được hay không qua được, tình trạng của lỗi, nếu cần người kiểm thử cũng phải sửa đổi lại các trường hợp kiểm thử hay thêm các trường hợp kiểm thử mới. (Nếu có thay đổi yêu cầu hay thay đổi mã) và kiểm thử lại các trường hợp kiểm thử và thực hiện kiểm thử rà lại. Tổ kiểm thử cũng phải chuẩn bị cho kiểm thử chấp phận được tiến hành trong môi trường của khách hang.

Sau khi dự án được hoàn thành, tổ kiểm thử phải đánh giá mọi hoạt động kiểm thử, qui trình và kế hoạch kiểm thử cho cải tiến tương lai. Trong pha này, tổ kiểm thử sẽ phân tích qui trình kiểm thử của mình và làm tài liệu về những ưu điểm và những hạn chế. Họ phải chắc chắn rằng nếu họ phạm bất kì sai lầm nào, nó sẽ không lặp lại trong dự án tương lai.

1.6. Các tiêu chí đánh giá ki m thể ửTiêu chí đánh giá kiểm thử bao gồm độ bao phủ và chất lượng của kiểm thử:

10


Sự bao phủ của kiểm thử là một tiêu chí quan trọng trong tiến trình kiểm thử, nó phải bao phủ toàn bộ các yêu cầu cần kiểm thử và các trường hợp kiểm thử hay toàn bộ đoạn chương trình

Chất lượng của kiểm thử là một tiêu chí quan trọng để đánh giá độ tin cậy, tính hiệu năng, sự ổn định của chương trình. Chất lượng của kiểm thử phụ thuộc vào việc đánh giá, phân tích để phát hiện ra lỗi của chương trình trong suốt tiến trình kiểm thử

11


2. S l c các kỹ thu t ki m th ph n m mơ ượ ậ ể ử ầ ề2.1. Ki m th t m h pể ử ầ ẹCác loại kiểm thử này được thực hiện để kiểm thử đến các đơn vị (unit) hoặc các khối chức năng (module).

2.1.1. Ki m th h p đenể ử ộ2.1.1.1 Định nghĩa

Kiểm thử hộp đen còn gọi là kiểm thử chức năng. Việc kiểm thử này được thực hiện mà không cần quan tâm đến thiết kế và mã viết của chương trình. Kiểm thử theo cách này chỉ quan tâm đến chức năng đã đề ra của chương trình. Vì vậy kiểm thử loại này chỉ dựa vào bản mô tả chức năng của chương trình, xem chương trình có thực sự cung cấp đúng chức năng đã mô tả trong bản chức năng đó hay không.Kiểm nghiệm hộp đen dựa vào các định nghĩa về chức năng của chương trình. Các trường hợp kiểm thử được tạo ra dựa vào bản mô tả chức năng chứ không phải dựa vào cấu trúc của chương trình.

2.1.1.2 Một số phương pháp kiểm thử hộp đen Phân lớp tương đương – Equivalence partitioning. Phân tích giá trị biên – Boundary value analysis. Kiểm thử mọi cặp – All-pairs testing. Kiểm thử fuzz – Fuzz testing. Kiểm thử dựa trên mô hình – Model-based testing. Ma trận dấu vết – Traceability matrix. Kiểm thử thăm dò – Exploratory testing. Kiểm thử dựa trên đặc tả – Specification-base testing.

2.1.1.3 Ưu và nhược điểmKiểm thử hộp đen không có mối liên quan nào tới mã lệnh, và kiểm

thử viên chỉ rất đơn giản tâm niệm là: một mã lệnh phải có lỗi. Sử dụng nguyên tắc “ Hãy đòi hỏi và bạn sẽ được nhận”, những kiểm thử viên hộp đen tìm ra lỗi mà những lập trình viên đã không tìm ra. Nhưng, mặt khác,

12


người ta cũng nói kiểm thử hộp đen “giống như là đi trong bóng tối mà không có đèn vậy”, bởi vì kiểm thử viên không biết các phần mềm được kiểm tra thực sự được xây dựng như thế nào. Đó là lý do mà có nhiều trường hợp mà một kiểm thử viên hộp đen viết rất nhiều ca kiểm thử để kiểm tra một thứ gì đó mà đáng lẽ có thể chỉ cần kiểm tra bằng 1 ca kiểm thử duy nhất, và/hoặc một số phần của chương trình không được kiểm tra chút nào.Do vậy, kiểm thử hộp đen có ưu điểm của “một sự đánh giá khách quan”, mặt khác nó lại có nhược điểm của “thăm dò mù”.

2.1.1.4 Khái quát một số phương pháp kiểm thử hộp đena) Phân đoạn tương đương

Phân đoạn tương đương là phương pháp chia dữ liệu vào thành các đoạn, mỗi đoạn đại diện cho một số dữ liệu. Và việc kiểm thử chỉ thực hiện trên đại diện đó. Mục đích của phương pháp này là giảm số lượng test bằng cách chọn các tập dữ liệu đại diện.Phương pháp dựa trên một số ý tưởng sau:

Chương trình chạy để gom những tín hiệu đầu vào tương tự nhau vào trong cùng một đoạn

Test mỗi giá trị đại diện của từng đoạn Nếu các giá trị đại diện bị lỗi thì các thành viên trong đoạn đó

cũng sẽ bị lỗi như thếTrong thực tế, có một số cách để nhận diện các đoạn tương đương như:

Dựa vào các điều kiện vào ra trong đặc tính kỹ thuật, mô tả kỹ thuật

Phân chia thành hai đoạn đầu vào tương đương là Valid và Invalid tương ứng với dữ liệu đầu vào hợp lệ và không hợp lệ

Dựa vào các ý kiến của chuyên gia để phân đoạn tương đương cho hợp lý

Ví dụ: Kiểm thử một hàm tính giá trị tuyệt đối của một số nguyên x theo phương pháp phân đoạn tương đương.Ta có thể chia thành các đoạn tương đương theo bảng sau:Điều kiện Các đoạn tương

đương ValidCác đoạn tương đương Invalid

Số lượng số nhập vào 1 0 hoặc > 1Kiểu dữ liệu nhập vào Nguyên Không nguyên

Giá trị <0, >= 0Do đó ta có thể đề xuất test case theo phương pháp phân đoạn tương đương như sau:

13


x = -200 với đoạn x < 0 nguyên có 1 chữ số; x = 100 với đoạn x >= 0 nguyên có 1 chữ số

x = 23 435 với đoạn số lượng số nhập vào > 1; x = "abcdef" với đoạn giá trị nhập vào không phải là số nguyên.

b) Phương pháp phân tích giá trị biên Phương pháp phân tích giá trị biên là một trường hợp riêng của phương pháp phân đoạn tương đương. Với ý tưởng như sau:

Kiểm tra điều kiện biên của đoạn thì có tác dụng hơn là kiểm tra các giá trị tùy ý của các lớp như trên

Chọn các giá trị biên đầu vào để kiểm tra các đoạn thay vì kiểm tra những giá trị tùy ý

Chiến lược của phương pháp Chọn một giá trị tùy ý cho mỗi đoạn Chọn các giá trị chính xác ở biên trên và biên dưới của

mỗi đoạn Chọn các giá trị ở ngay bên dưới và bên trên của mỗi

biên nếu có thểVí dụ: Kiểm thử một hàm tính giá trị tuyệt đối của một số nguyênBảng phân đoạn tương đương như sauĐiều kiện Các đoạn tương

đương ValidCác đoạn tương đương Invalid

Số lượng số nhập vào 1 0 hoặc > 1Kiểu dữ liệu nhập vào Nguyên Không nguyên

Giá trị <0, >= 0

Các test case như sau: Trên đoạn x < 0 ta chọn giá trị tùy ý là x = -123 Trên đoạn x >= 0 ta chọn giá trị tùy ý là x = 234 Các đoạn x < 0 và x >= 0 có giá trị biên là x = 0 Các đoạn x < 0 và x >= 0 có các giá trị trên và dưới biên là x = -

1 và x = +1 Đoạn Invalid có số lượng số nhập vào > 1 ta chọn x = 124 345 Đoạn giá trị nhập vào không nguyên ta chọn x = "abcdef"

c) Phương pháp đồ thị nguyên nhân - kết quả (Cause - Effect Graphing) Phương pháp đồ thị nguyên nhân - kết quả sử dụng một đồ thị có hướng mà ánh xạ một bộ nguyên nhân sang một bộ kết quả. Bộ các nguyên nhân có thể được xem như đầu vào còn bộ các kết quả có thể được xem như đầu ra. Thông thường, đồ thị mô tả những nút nguyên nhân ở bên trái còn những nút kết quả ở bên phải. Có thể có những nút

14


trung gian đứng ở giữ để kết hợp các nút sử dụng các phép toán logic AND và OR.Thay vì các tester phải cố gắng xác định các testcase một cách thủ công thì họ có thể sử dụng kỹ thuật trên để xác định các trường hợp kiểm thử có thể bao phủ 100% các chức năng. Điểm bắt đầu để xây dựng đồ thị nguyên nhân – kết quả là tài liệu đặc tả yêu cầu cái mà mô tả hệ thống dự định sẽ làm gì. Từng đầu vào và đầu ra trong đồ thị nguyên nhân kết quả tương ứng với một biểu thức điều kiện cái mà có thể nhận một trong hai giá trị true hoặc false.Một vài ví dụ sau đây sẽ mô tả chi tiết hơn phương pháp đồ thị nguyên nhân - kết quả:Ví dụ: Xây dựng đồ thị nguyên nhân kết quả của câu lệnh sau: if A OR B then C;Có thể xảy ra các trường hợp sau:

Nếu A đúng và B đúng thì C là đúng Nếu A đúng và B sai thì C là đúng Nếu A sai và B đúng thì C đúng Nếu A sai và B sai thì C sai

Đồ thị nguyên nhân - kết quả sẽ được mô tả như hình dưới:

Đồ thị nguyên nhân - kết quả

Trong hình trên thì A, B, C được gọi là các nút, trong đó thì nút A, B là các nút nguyên nhân còn nút C là nút kết quả. Từng nút có thể nhận một trong hai giá trị true hoặc false. Các cung nối giữa các đỉnh có thể gọi là các vector.

Một số loại quan hệ giữa các nút như sau:

15


Một số loại quan hệ giữa các nút trong đồ thị nguyên nhân – kết quả

Đồ thị nguyên nhân – kết quả sau khi được thiết lập xong sẽ được chuyển sang bảng quyết định (Decision Table). Bảng quyết định để mô tả quan hệ logic giữa nguyên nhân và kết quả. Từng cột trong bảng quyết định là một trường hợp kiểm thử (test case). Từng testcase tương ứng với một đầu vào cụ thể và đầu vào đó là một tập hợp các giá trị của của các nút nguyên nhân có thể nhận giá trị true hoặc false.Ứng với ví dụ trên thì ta có thể xây dựng được bảng quyết định như sau:

Testcase 1 Testcase 2 Testcase 3Cause A True False False

B False True FalseEffect C True True False

Trên lý thuyết, ta thấy khi đầu vào của bài toán có 2 nút cause như trong ví dụ trên, mà mỗi nút có thể nhận một trong hai giá trị là true hoặc false thì sẽ có tất cả là 22 = 4 trường hợp kiểm thử. Nhưng trong bảng trên ta chỉ xét 3 trường hợp kiểm thử vì trường hợp cuối cùng (A = true và B = true C = true) là dư thừa (Do ở 3 trường hợp xét trước đó thì A, B, C đã nhận cả true và false) nên ta không cần thiết phải đưa vào.Do đó, dựa vào bảng quyết định trên thì ta có thể tìm được các testcase bao phủ được hết các chức năng của chương trình.

16


Ví dụ: Tính result = 1 + 2 + … + |value| nếu result <= maxint và sinh ra lỗi nếu ngược lại

Đồ thị nguyên nhân kết quả như sau:

Đồ thị nguyên nhân - kết quả

Bảng quyết định

2.1.2. Ki m th h p tr ngể ử ộ ắ2.1.2.1 Định nghĩa

Kiểm thử hộp trắng còn gọi là kiểm thử cấu trúc. Kiểm thử theo cách này là loại kiểm thử sử dụng các thông tin về cấu trúc bên trong của ứng dụng. Cho phép tester truy cập vào các cấu trúc dữ liệu và các đoạn mã bên trong của chương trình. Việc kiểm thử này dựa trên quá trình thực hiện và xây dựng phần mềm.

17


2.1.2.2 Tiêu chuẩn của kiểm thử hộp trắng Bao phủ dòng lệnh: Mỗi dòng lệnh ít nhất phải được thực thi một lần Bao phủ nhánh: Mỗi nhánh trong sơ đồ điều khiển phải được đi qua ít

nhất một lần Bao phủ đường: Tất cả các đường từ điểm khởi tạo đến điểm cuối

cùng trong sơ đồ dòng điều khiển phải được đi qua Kiểm thử giao diện lập trình ứng dụng - API testing (application

programming interface): là phương pháp kiểm thử của ứng dụng sử dụng các API công khai và riêng tư.

Các phương pháp gán lỗi – Fault injection. Các phương pháp kiểm thử hoán chuyển – Mutation testing methods. Kiểm thử tĩnh – Static testing: kiểm thử hộp trắng bao gồm mọi kiểm

thử tĩnh.Phương pháp kiểm thử hộp trắng cũng có thể được sử dụng để đánh giá sự hoàn thành của một bộ kiểm thử mà được tạo cùng với các phương pháp kiểm thử hộp đen. Điều này cho phép các nhóm phần mềm khảo sát các phần của 1 hệ thống ít khi được kiểm tra và đảm bảo rằng những điểm chức năng quan trọng nhất đã được kiểm tra.

2.1.2.3 một số phương pháp, kỹ thuật trong kiểm thử hộp trắnga) Mô tả một số cấu trúc theo lược đồ

Trong các phương pháp kiểm tra tính đúng đắn của chương trình lược đồ được dùng để:

Trừu tượng hóa cú pháp của mã lệnh Làm khuôn mẫu cơ bản cho các nguyên tắc kiểm tra theo

trường hợp Kiểm tra tính đúng đắn trên toàn bộ lược đồ

Dưới đây là một số lược đồ của các loại câu lệnh thường gặp:

18


Một số lược đồ của các câu lệnhb) Kiểm tra theo câu lệnh (Statement Testing)

Phương pháp này thiết kế quá trình kiểm tra sao cho mỗi câu lệnh của chương trình được thực hiện ít nhất một lần. Phương pháp kiểm tra này xuất phát từ ý tưởng. Nếu một câu lệnh không được thực hiện thì ta không thể biết có lỗi xảy ra trong câu lệnh đó hay không. Do đó ý tưởng của phương pháp này là đưa ra test case sao cho test case đó sẽ quét hết tất cả các câu lệnh trong đoạn chương trình ta muốn kiểm thử.Ví dụ: Cho đoạn chương trình sau:

Đoạn chương trình trên mô tả bài toán tính

19


result = 1 + 2 + … + |value| nếu result <= maxint và In ra 'Too Large' nếu ngược lạiDựa vào đoạn mã trên ta có thể xây dựng được đồ thị sau:

Với bộ giá trị Input (maxint = 10, value = -1) và (maxint = 0, value = -1) sẽ kiểm tra được toàn bộ các lệnh trong đoạn chương trình trên.

c) Kiểm tra theo đường dẫn (Path Testing)Đây là phương pháp kiểm tra bao trùm mọi đường dẫn của chương trình và cần kết hợp với lược đồ tiến trìnhVí dụ: Với đoạn mã

if (A > B && C > D) {S1;

}else{

S2;}

S3;Ta sẽ có lược đồ tiến trình như sau:

20


Lược đồ mô tả cấu trúc path của chương trìnhNhận xét: Phương pháp kiểm tra theo biểu thức phụ thuộc nhiều vào các biểu thức điều kiện. Tuy nhiên, có những trường hợp số lượng đường dẫn quá lớn (thường trong các trường hợp có vòng lặp). Vì vậy phương pháp này thường không phải là lựa chọn thực tế để kiểm tra tính đúng đắn của chương trình.

d) Kiểm tra theo điều kiện (Condition Testing)Đây là phương pháp kiểm tra các biểu thức điều kiện trên hai giá trị true hoặc false.Phương pháp trên sẽ được minh họa qua ví dụ sau:Ví dụ 1:

if (x > 0 && y > 0){x = 100;

}else{

x = 5000; }Trong trương hợp trên ta thấy các bộ kiểm tra {(x > 0, y > 0), (x <= 0, y > 0)} sẽ kiểm tra toàn bộ các điều kiện.Ví dụ 2:

if (x != 0){y = 100;

}if (z < 1){

z /= x;}else{

z = 0;}

21


Với bộ kiểm tra {(x = 0, z = 1), (x = 1, z = 0)} sẽ kiểm tra bao trùm được các điều kiện.Tuy nhiên không kiểm tra được trường hợp lỗi chia cho 0 (trong trường hợp x = 0).Do đó ta rút ra nhận xét là khi kiểm tra bằng phương pháp kiểm thử theo điều kiện cần xem xét kết hợp các điều kiện với nhau.

e) Kiểm tra theo vòng lặp (Loop Testing)Đây là phương pháp kiểm thử tập trung vào tính hợp lệ của các cấu trúc vòng lặp

Với từng loại vòng lặp ta có cách thức kiểm tra như sau: Các bước cần kiểm tra cho vòng lặp đơn

o Bỏ qua vòng lặpo Lặp một lầno Lặp hai lầno Lặp m lần (m < n)o Lặp (n - 1), n, (n + 1) lầnTrong đó n là số lần lặp tối đa của vòng lặp

Các bước cần kiểm tra cho vòng lặp dạng lồng nhauo Khởi đầu với vòng lặp nằm bên trong nhất. Thiết lập các

tham số lặp cho các vòng lặp bên ngoài về giá trị nhỏ nhất

o Kiểm tra với tham số min+1, 1 giá trị tiêu biểu, max-1 và max cho vòng lặp bên trong nhất trong khi các tham số lặp của các vòng lặp bên ngoài là nhỏ nhất

22


o Tiếp tục tương tự với các vòng lặp liền ngoài tiếp theo cho đến khi tất cả vòng lặp bên ngoài được kiểm tra

Các bước cần kiểm tra cho vòng lặp nối tiếpo Nếu các vòng lặp là độc lập với nhau thì kiểm tra như

trường các vòng lặp dạng đơn, nếu không thì kiểm tra như trường hợp các vòng lặp lồng nhau

Ví dụ:#define MAX 10#define MIN 1void main(){

int input, numberOfInterations = 0;scanf("%d", &input);for (int i = input; i >= MIN && i <= MAX; i+

+){numberOfInterations++;

}printf("%d", numberOfInterations);

}Nhận thấy đây là trường hợp vòng lặp đơn nên ta sẽ thiết lập được test case như trong bảng sau:

Đầu vào Đầu ra11 0 (Bỏ qua vòng lặp)10 1 (Chạy 1 lần lặp)9 2 (Chạy 2 lần lặp)5 6 (Chạy m lần lặp với m < n)2 9 (Chạy n - 1 lần lặp)1 10 (Chạy n lần lặp)0 0 (Bỏ qua vòng lặp)

2.1.3. Ki m th h p xámể ử ộKiểm thử hộp xám đòi hỏi phải có sự truy cập tới cấu trúc dữ liệu và

giải thuật bên trong cho những mục đích thiết kế các ca kiểm thử, nhưng là kiểm thử ở mức người sử dụng hay mức hộp đen. Việc thao tác tới dữ liệu đầu vào và định dạng dữ liệu đầu ra là không rõ ràng, giống như một chiếc hộp xám, bởi vì đầu vào và đầu ra rõ ràng là ở bên ngoài hộp đen mà chúng ta vẫn gọi về hệ thống được kiểm tra. Sự khác biệt này đặc biệt quan trọng khi quản lý kiểm thử tích hợp – Integration testing giữa 2 modun mã lệnh được viết bởi hai chuyên viên thiết kế khác nhau, trong đó chỉ giao diện là

23


được đưa ra để kiểm thử. Kiểm thử hộp xám có thể cũng bao gồm cả thiết kế đối chiếu để quyết định, ví dụ, giá trị biên hay thông báo lỗi.

2.2. Ki m th t m r ngể ử ầ ộHình dưới mô tả các bước kiểm thử có trong quy trình phát triển phần mềm

Hình 2 - Các loại kiểm thử

Dưới đây ta sẽ trình bày một cách chi tiết từng kỹ thuật kiểm thử trên

2.2.1 Ki m th đ n v (Unit Testing)ể ử ơ ịTrước hết ta sẽ định nghĩa khái niệm đơn vị. Một đơn vị là một thành

phần phần mềm nhỏ nhất mà ta có thể kiểm tra được. Ví dụ, các hàm (Function), thủ tục (Procedure), lớp (Class) hay phương thức (Method) đều có thể được xem là Unit.Do đó kiểm thử đơn vị là kiêm tra sự thực thi của các đơn vị chương trình riêng rẽ. Do các Unit được kiểm tra thường có kích thước nhỏ và chức năng hoạt động tương đối đơn giản nên chúng ta sẽ không gặp mấy khó khăn trong việc tổ chức kiểm tra ghi nhận và phân tích kết quả kiểm tra. Nếu phát hiện lỗi, việc xác định nguyên nhân và khắc phục cũng tương đối dễ dàng vì chỉ khoanh vùng trong một đơn thể Unit đang kiểm tra. Trong thực tiễn thường thì thời gian chi phí cho Unit Test sẽ được đền bù bằng việc tiết kiệm rất nhiều thời gian và chi phí cho việc kiểm tra và sửa lỗi ở các mức kiểm tra sau đó. Do đó nếu trong bước này chúng ta làm cẩn thận thì các bước test sau sẽ ít gặp lỗi hơn nhiều.

24


Giá thành sẽ càng bị đội lên nếu không phát hiện thấy lỗi ở ngay bước Unit Testing

Unit Test thường do lập trình viên thực hiện. Công đoạn này cần được thực hiện càng sớm càng tốt trong giai đoạn viết code và xuyên suốt chu kỳ phát triển phần mềm. Thông thường, Unit Test đòi hỏi kiểm tra viên có kiến thức về thiết kế và code của chương trình. Mục đích của Unit Test là bảo đảm thông tin được xử lý và xuất ra khỏi Unit là chính xác trong mối tương quan giữa dữ liệu nhập và chức năng của unit. Cũng như các mức kiểm tra khác, Unit Test cũng đòi hỏi phải chuẩn bị trước các tình huống (test case) hoặc kịch bản (script), trong đó chỉ định rõ dữ liệu vào, các bước thực hiện và dữ liệu mong chờ sẽ xuất ra. Các test case và script này nên được giữ lại để tái sử dụng

2.2.2 Ki m th tích h p (Integration Test)ể ử ợIntegration test kết hợp các thành phần của một ứng dụng và kiểm tra

như một ứng dụng đã hoàn thành. Trong khi Unit Test kiểm tra các thành phần và Unit riêng lẻ thì Intgration Test kết hợp chúng lại với nhau và kiểm tra sự giao tiếp và truyền thông điệp giữa chúng.

25


Các mục tiêu chính của Integration Test bao gồm: Phát hiện lỗi giao tiếp xảy ra giữa các Unit. Tích hợp các Unit đơn lẻ thành các hệ thống nhỏ (subsystem) và cuối

cùng là nguyên hệ thống hoàn chỉnh (system) chuẩn bị cho kiểm tra ở mức hệ thống (System Test).

Trong Unit Test, lập trình viên cố gắng phát hiện lỗi liên quan đến chức năng và cấu trúc nội tại của Unit. Có một số phép kiểm tra đơn giản trên giao tiếp giữa Unit với các thành phần liên quan khác, tuy nhiên mọi giao tiếp liên quan đến Unit thật sự được kiểm tra đầy đủ khi các Unit tích hợp với nhau trong khi thực hiện Integration Test. Trừ một số ít ngoại lệ, Integration Test chỉ nên thực hiện trên những Unit đã được kiểm tra cẩn thận trước đó bằng Unit Test, và tất cả các lỗi mức Unit đã được sửa chữa. Một số người hiểu sai rằng Unit một khi đã qua giai đoạn Unit Test với các giao tiếp giả lập thì không cần phải thực hiện Integration Test nữa. Thực tế việc tích hợp giữa các Unit dẫn đến những tình huống hoàn toàn khác.Một chiến lược cần quan tâm trong Integration Test là nên tích hợp dần từng Unit. Một Unit tại một thời điểm được tích hợp vào một nhóm các Unit khác mà nhóm các Unit đó đã được tích hợp trước đó và đã hoàn tất các đợt Integration Test trước đó. Lúc này, ta chỉ cần kiểm tra giao tiếp của Unit mới thêm vào với hệ thống các Unit đã tích hợp trước đó, điều này làm cho số lượng kiểm tra sẽ giảm đi rất nhiều và sai sót sẽ giảm đáng kể.Có 4 loại kiểm tra trong Integration Test:

Kiểm tra cấu trúc (structure): Tương tự White Box Test tức là kiểm tra nhằm bảo đảm các thành phần bên trong của một chương trình chạy đúng, chú trọng đến hoạt động của các thành phần cấu trúc nội tại của chương trình chẳng hạn các lệnh và nhánh bên trong.

Kiểm tra chức năng (functional): Tương tự Black Box Test tức là kiểm tra chỉ chú trọng đến chức năng của chương trình, không quan tâm đến cấu trúc bên trong, chỉ khảo sát chức năng của chương trình theo yêu cầu kỹ thuật.

26


Kiểm tra hiệu năng (performance): Kiểm tra việc vận hành của hệ thống.

Kiểm tra khả năng chịu tải (stress): Kiểm tra các giới hạn của hệ thống.

2.2.3. Ki m th h th ng (System Testing)ể ử ệ ốSystem test bao gồm một loạt những kiểm nghiệm nhằm xác minh

toàn bộ các thành phần của hệ thống được tích hợp một cách đúng đắn. Mục đích của kiểm thử hệ thống là đảm bảo toàn bộ hệ thống hoạt động như khách hàng mong muốn.System Test bắt đầu khi tất cả các bộ phận của phần mềm đã được tích hợp thành công. Thông thường loại kiểm tra này tốn rất nhiều công sức và thời gian. Trong nhiều trường hợp, việc kiểm tra đòi hỏi yên cầu phải có môi trường kiểm thử thích hợp. Ví dụ như một số thiết bị phụ trợ, phần mềm hoặc phần cứng đặc thù, đặc biệt là các ứng dụng thời gian thực, hệ thống phân bố, hoặc hệ thống nhúng. Ở mức độ của kiểm thử hệ thống thì tester cũng tìm kiếm các lỗi, nhưng trọng tâm của loại kiểm thử này là đánh giá về chức năng, hoạt động, thao tác, sự tin cậy và các yêu cầu khác liên quan đến chất lượng của toàn hệ thống.Điểm khác nhau then chốt giữa Integration Test và System Test là System Test chú trọng các hành vi và lỗi trên toàn hệ thống, còn Integration Test chú trọng sự giao tiếp giữa các thực thể hoặc đối tượng khi chúng làm việc cùng nhau. Trong quy trình kiểm thử thì thông thường ta phải thực hiện Unit Test và Integration Test để đảm bảo mọi đơn vị và giao tiếp, tương tác giữa chúng hoạt động chính xác trước khi thực hiện System Test.Sau khi hoàn thành Integration Test, một hệ thống phần mềm đã được hình thành cùng với các thành phần đã được kiểm tra đầy đủ. Tại thời điểm này, lập trình viên hoặc tester sẽ bắt đầu kiểm tra phần mềm như một hệ thống hoàn chỉnh. Và việc lập kế hoạch cho System Test nên bắt đầu từ giai đoạn hình thành và phân tích các yêu cầu của phần mềm.System Test kiểm tra cả các hành vi chức năng của phần mềm lẫn các yêu cầu phi chức năng như độ tin cậy, tính tiện lợi khi sử dụng, hiệu năng và bảo mật… Mức kiểm tra này đặc biệt thích hợp cho việc phát hiện lỗi giao tiếp với các phần mềm hoặc phần cứng bên ngoài, chẳng hạn các lỗi bế tăc (deadlock) hoặc chiếm dụng bộ nhớ. Sau giai đoạn System Test, phần mềm thường đã sẵn sàng cho khách hàng hoặc người dùng cuối cùng kiểm tra để chấp nhận (Acceptance Test) hoặc dùng thử (Alpha/Beta Test).Đòi hỏi nhiều công sức, thời gian và tính chính xác, khách quan, System Test thường được thực hiện bởi một nhóm kiểm tra viên hoàn toàn độc lập với nhóm phát triển dự án

27


System test bao gồm một số loại kiểm tra sau: Kiểm tra chức năng (Functional Testing): Kiểm tra hệ thống sau khi

tích hợp có hoạt động đúng chức năng với yêu cầu đặt ra trong bản mô tả yêu cầu hay không.VD: Với hệ thống xử lý văn bản thì kiểm tra các chức năng như: tạo tài liệu, sửa tài liệu, xóa tài liệu… có hoạt động đúng theo yêu cầu hay không.

Kiểm tra hiệu năng (Performance Testing): Đảm bảo tối ưu việc phân bổ tài nguyên hệ thống nhằm đạt các chỉ tiêu như thời gian xử lý hay đáp ứng câu truy vấn.

Kiểm tra mức độ đáp ứng (Stress Testing): Thực thi hệ thống với giả thiết là các tài nguyên hệ thống yêu cầu không đáp ứng được về chất lượng, ổn định, số lượng. Loại kiểm tra này tập trung vào các điểm tới hạn, điểm chết, các tình huống bất thường của hệ thống.

Kiểm tra cấu hình (Configuration Network): Phân tích hệ thống với các thiết lập cấu hình khác nhau

Kiểm nghiệm ổn định (Robustness Testing): Kiểm nghiệm dưới các điều kiện không mong đợi. Ví dụ như người dùng gõ lệnh sai hay nguồn điện bị ngắt.

Kiểm tra khả năng phục hồi (Recorvery Testing): Đảm bảo hệ thống có khả năng khôi phục trạng thái ổn định trước đó trong tình huống mất tài nguyên hoặc dữ liệu. Điều này đặc biệt quan trọng với các hệ thống giao dịch như ngân hàng trực tuyến.

Kiểm tra khả năng bảo mật (Security Testing): Đảm bảo tính toàn vẹn, bảo mật của dữ liệu và của hệ thống.

Kiểm tra quá tải (Overload Testing): Đánh giá hệ thống khi nó vượt qua giới hạn cho phép.

Kiểm tra chất lượng (Quality Testing): Đánh giá sự tin tưởng, vấn đề duy tu, tính sẳn sàng của hệ thống. Bao gồm cả việc tính toán thời gian trung bình hệ thống sẽ bị hỏng và thời gian trung bình để khắc phục.

Kiểm tra cài đặt (Installation Testing): Người dùng sử dụng các chức năng của hệ thống và ghi lại các lỗi tại vị trí sử dụng thật sự. VD: Một hệ thống điều khiển một lò nấu thép phải đảm bảo không chịu sự ảnh hưởng của nhiệt độ.

2.2.4. Ki m th ch p nh n (Acceptance Testing)ể ử ấ ậSau giai đoạn System Test là Acceptance Test, đây là giai đoạn kiểm

tra được khách hàng thực hiện. Mục đích của Acceptance Test là để chứng

28


minh phần mềm thỏa mãn tất cả yêu cầu của khách hàng và khách hàng chấp nhận sản phẩm và trả tiền thanh toán hợp đồng.Acceptance Test có ý nghĩa hết sức quan trọng, mặc dù trong hầu hết mọi trường hợp, các phép kiểm tra của System Test và Accepatnce Test gần như tương tự, nhưng bản chất và cách thức thực hiện lại rất khác biệt.Đối với những sản phẩm dành bán rộng rãi trên thị trường cho nhiều người sử dụng, thông thường sẽ thông qua hai loại kiểm tra gọi là Alpha Test và Beta Test. Với Alpha Test, người sử dụng kiểm tra phần mềm ngay tại nơi phát triển phần mềm, lập trình viên sẽ ghi nhận các lỗi hoặc phản hồi, và lên kế hoạch sửa chữa. Với Beta Test, phần mềm sẽ được gửi tới cho người sử dụng để kiểm tra ngay trong môi trường thực, lỗi hoặc phản hồi cũng sẽ gửi ngược lại cho lập trình viên để sửa chữa.Trên thực tế, nếu khách hàng không quan tâm và không tham gia vào quá trình phát triển phần mềm thì thường kết quả Acceptance Test sẽ sai lệch rất lớn, mặc dù PM đã trải qua tất cả các kiểm tra trước đó. Sự sai lệch này liên quan đến việc hiểu sai yêu cầu cũng như sự mong chờ của khách hàng. Ví dụ đôi khi một PM xuất sắc vượt qua các phép kiểm tra về chức năng thực hiện bởi nhóm thực hiện dự án, nhưng khách hàng khi kiểm tra sau cùng vẫn thất vọng vì bố cục màn hình nghèo nàn, thao tác không tự nhiên, không theo tập quán sử dụng của khách hàng…

29


3. Các chi n l c ki m th ph n m mế ượ ể ử ầ ề3.1 Khái quátMột chiến lược kiểm thử là một bản phác họa mô tả phần kiểm thử của một qui trình phát triển phần mềm. Nó được tạo ra để thông báo đến các quản lý dự án, tester và DEV về một số vấn đề chính của quá trình kiểm thử. Bao gồm mục tiêu kiểm thử, các phương pháp dùng để kiểm thử các chức năng mới, tổng thời gian và nguồn nhân lực được yêu cầu cho dự án và môi trường kiểm thử.Các chiến lược kiểm thử mô tả làm thế nào để các rủi ro sản phẩm của các bên liên quan được giảm bớt ở các mức kiểm thử, loại kiểm thử nào sẽ được thực hiện, và sẽ áp dụng điều kiện bắt đầu và kết thúc kiểm thử nào. Chúng được tạo ra dựa trên các tài liệu thiết kế phát triển phần mềm. Các tài liệu thiết kế hệ thống được sử dụng chủ yếu và đôi khi cũng tham khảo tài liệu thiết kế khái niệm. Các tài liệu thiết kế mô tả chức năng của phần mềm sẽ được kích hoạt trong đợt phát hành sắp tới. Ở mọi giai đoạn (chặng) thiết kế phát triển, một chiến lược kiểm thử tương ứng sẽ được tạo để kiểm thử các tập đặc điểm mới (vì ở mỗi chặng phát triển phần mềm thì có các đặc điểm riêng cần kiểm thử).

Định nghĩa khác: Phương pháp tiếp cận kiểm thử và Cấu trúc kiểm thử là các thuật ngữ khác thường được sử dụng để mô tả cái gọi là chiến lược kiểm thử.Ví dụ một chiến lược kiểm thử được trình bày một cách đơn giản: "Chúng ta sẽ sử dụng black box testing, cause-effect graphing, boundary testing, và white box testing để kiểm thử sản phẩm này dựa vào bản mô tả định nghĩa của nó."

3.2 Chi n l c ki m thế ượ ể ửTiến trình kỹ nghệ phần mềm có thể được xét theo vòng xoắn ốc. Ban đầu, kỹ nghệ phần mềm xác định vai trò của phần mềm và đưa tới việc phân tích yêu cầu phần mềm, chỗ thiết lập nên lĩnh vực thông tin, chức năng, hành vi, hiệu năng, ràng buộc và tiêu chuẩn hợp lệ cho phần mềm. Đi vào trong vòng xoắn ốc, chúng ta tới thiết kế và cuối cùng tới mã hoá. Để xây dựng phần mềm máy tính, chúng ta đi dọc theo đường xoắn ốc, mỗi lần mức độ trừu tượng lại giảm dần. Một chiến lược cho kiểm thử phần mềm cũng có thể xem xét bằng cách đi theo đường xoắn ốc ra ngoài. Việc kiểm thử đơn vị bắt đầu tại tâm xoáy của xoắn ốc và tập chung vào các đơn vị của phần mềm khi được cài đặt trong

30


chương trình gốc. Việc kiểm thử tiến triển bằng cách đi ra theo đường xoắn ốc tới kiểm thử tích hợp, nơi tập trung vào thiết kế và việc xây dựng kiến trúc phần mềm. Đi thêm một vòng xoáy nữa trên đường xoắn ốc chúng ta gặp kiểm thử hợp lệ, nơi các yêu cầu, được thiết lập như một phần của việc phân tích yêu cầu phần mềm, được hợp lệ hoá theo phần mềm đã được xây dựng. Cuối cùng chúng ta tới kiểm thử hệ thống, nơi phần mềm và các phần tử hệ thống khác được kiểm thử như một toàn bộ. Để kiểm thử phần mềm máy tính, chúng ta theo đường xoáy mở rộng dần phạm vi kiểm thử một lần.

Hình 3 – Các bước kiểm thửXem xét tiến trình này theo quan điểm thủ tục vì việc kiểm thử bên trong hoàn cảnh kỹ nghệ phần mềm thực tại là một chuỗi gồm ba bước được thực hiện tuần tự nhau. Các bước này được minh họa trong Hình 3. Ban đầu, việc kiểm thử tập trung vào từng mô đun riêng biệt, đảm bảo rằng nó vận hành đúng đắn như một đơn vị. Do đó mới có tên kiểm thử đơn vị. Kiểm thử đơn vị dùng rất nhiều các kỹ thuật kiểm thử hộp trắng, thử các đường đặc biệt trong cấu trúc điều khiển của một mô đun để đảm bảo bao quát đầy đủ và phát hiện ra lỗi tối đa. Tiếp đó các mô đun phải được lắp ghép hay tích hợp lại để tạo nên bộ trình phần mềm hoàn chỉnh. Việc kiểm thử tích hợp đề cập tới các vấn đề có liên quan tới các vấn đề kiểm chứng và xây dựng chương trình. Các kỹ thuật thiết kế kiểm thử hộp đen chiếm đại đa số trong việc tích hợp, mặc dầu một số giới hạn các kiểm thử hộp trắng cũng có thể dược dùng để đảm bảo bao quát đa số các đường điều khiển.

31


Sau khi phần mềm đã được tích hợp (được xây dựng), một tập các phép kiểm thử cao cấp sẽ được tiến hành. Các tiêu chuẩn hợp lệ (được thiết lập trong phân tích yêu cầu) cũng phải được kiểm thử. Việc kiểm thử hợp lệ đưa ra sự đảm bảo cuối cùng rằng phần mềm đáp ứng cho tất cả các yêu cầu chức năng, hành vi và sự hoàn thiện. Các kỹ thuật kiểm thử hộp đen được dùng chủ yếu trong việc hợp lệ hoá này. Bước kiểm thử cấp cao cuối cùng rơi ra ngoài phạm vi của kỹ nghệ phần mềm và rơi vào hoàn cảnh rộng hơn của kỹ nghệ hệ thống máy tính. Phần mềm, một khi được hợp lệ hoá, phải được tổ hợp với các phần tử hệ thống khác (như phần cứng, con người, cơ sở dữ liệu). Kiểm thử hệ thống kiểm chứng lại rằng tất cả các yếu tố có khớp đúng với nhau không và rằng chức năng/ độ hoàn thiện hệ thống toàn bộ đã đạt được.

32


4. Các công c ki m th ph n m mụ ể ử ầ ề4.1.Quick test pro

4.1.1 Gi i thi uớ ệPhần mềm QuickTest Pro là phần mềm kiểm soát việc test tự động những chức năng của một sản phẩm phần mềm khác, là một bộ phận (module) của hệ thống Mercury Quality Center bao gồm nhiều module phần mềm phối hợp với nhau để quản lý toàn bộ quy trình đảm bảo chất lượng sản phẩm phần mềm. Trước đây, phần mềm này do hãng Mercury (www.mercury.com) phát hành. Sau này, tập đoàn HP đã mua lại toàn bộ hãng Mercury, nên tên gọi của nó đầy đủ là: HP Mercury QuickTest Pro.Nếu ta có một sản phẩm phần mềm Quản lý Nhân sự. Ví dụ, khi mở phần mềm Quản lý Nhân sự lên, thì người dùng sẽ gặp form Đăng nhập (login) để nhập vào "Tên tài khoản" và "Mật khẩu", rồi nhấn nút "OK" hoặc "Cancel" để vào.Ta lập trình ra lệnh cho QuickTest Pro tự động điền thông tin vào 2 ô "Tên tài khoản" và "Mật khẩu", và rồi cũng tự động "nhấn" nút "OK" hoặc "Cancel" dùm bạn luôn. Công việc này gọi là viết script cho QuickTest Pro. Viết script để thực hiện nhiều trường hợp nhập dữ liệu khác nhau, nhiều thao tác khác nhau, để thử xem chức năng của form "Đăng nhập" có hoạt động đúng hay không. QuickTest Pro sau khi chạy script xong, sẽ thực hiện ghi nhận kết quả việc test tự động, và có thể xuất report. Nếu có đủ một hệ thống Mercury Quality Center thì ít ra phải có thêm phần mềm Mercury Test Director đóng vai trò là phần mềm chủ (serving software) đảm nhận việc tổng hợp các kết quả test, các báo cáo, các phát sinh... của QuickTest Pro, từ đó phục vụ cho công việc quản trị chất lượng sản phẩm phần mềm của bạn (Software Quality Assurance).Đây là chương trình dùng để kiểm tra chức năng (functional test) và cho phép thực hiện kiểm tra hồi qui (regression test) một cách tự động. Đây cũng là công cụ áp dụng phương pháp Keyword-Driven, một kỹ thuật scripting hiện đại, cho phép kĩ thuật viên bổ sung test case bằng cách tạo file mô tả cho nó mà không cần phải chỉnh sửa hay bổ sung bất cứ script nào cả. Nó cũng phù hợp trong tình huống chuyển giao công việc mà người mới tiếp nhận chưa có thời gian hoặc không hiểu script vẫn có thể thực hiện kiểm tra phần mềm theo đúng yêu cầu.

33


4.1.2 Lo i ph n m m h trạ ầ ề ỗ ợQTP giúp chúng ta kiểm tra phần mềm theo hướng chức năng trên rất nhiều loại chương trình phần mềm khác nhau. Tuy nhiên Mercury chỉ hỗ trợ sẵn một số loại chương trình thông dụng như:

Ứng dụng Windows chuẩn/Win32. Ứng dụng web theo chuẩn HTML, XML chạy trong trình duyệt

Internet Explorer, Netscape hoặc AOL. Visual Basic. ActiveX. QTP hỗ trợ Unicode (UTF-8, UTF-16). Một số loại chương trình khác đòi hỏi chúng ta phải cài đặt thêm

thành phần bổ sung của QTP thì mới thực hiện kiểm tra được. Các loại chương trình đó là

- .NET Framework 1.0, 1.1, 2.0- Các đối tượng chuẩn của .NET và các đối tượng

khác thừa kế từ các đối tượng chuẩn.- Java Sun JDK 1.1 – 1.6- IBM JDK 1.2 – 1.4- Oracle Applications 11.5.7, 11.5.8, 11.5.9- PeopleSoft Enterprise 8.0 – 8.8- SAP GUI HMTL 4.6D, 6.10, 6.20- SAP Workplace 2.11- SAP Enterprise Portal 5.0- Siebel 7.0, 7.5, 7.7- Terminal Emulators- Attachmate EXTRA! 6.7, 7.1- IBM Personal Communications

4.1.3 Đ c đi mặ ể Dễ sử dụng, bảo trì, tạo test script nhanh. Cung cấp dữ liệu kiểm tra rõ

ràng và 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í dụ khi

ứng dụng thay đổi nút tên “Login” thành “Đăng nhập”, thì chỉ cần cập nhật lại Object Repository (OR –được giải thích ở phần sau) để QTP nhận ra sự thay đổi đó mà không cần thay đổi bất cứ test script nào.

Hỗ trợ làm việc theo nhóm thông qua sự chia sẻ thư viện, thống nhất quản lý Object Repository.

Thực tế cho thấy, QTP thực hiện kiểm tra tự động trên nhiều trình duyệt cùng lúc tốt hơn những công cụ kiểm tra khác.

34


Với chức năng Recovery Scenarios, QTP cho phép xử 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.

QTP 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).

Quản trị Object Repository Phối hợp giữa các KTV qua việc đồng bộ hóa dữ liệu, khả năng trộn,

nhập/xuất ra file XML Kiểm tra tài nguyên: Kiểm tra tài nguyên cần thiết trước khi thực thi

lệnh kiểm tra tự động. Hỗ trợ XML cho báo cáo: Lưu trữ kết quả kiểm tra dưới dạng XML,

HTML, từđó cho phép tùy biến báo cáo. Quản trị từ khóa trong quá trình sử dụng Hỗ trợ đa giao tiếp: Cho phép người dùng mở và soạn thảo đồng thời

nhiều hàm thư viện và Object Repository. Giao diện sử dụng đẹp, dễ bắt nhập Hỗ trợ quản lý script: Debug toolbar, hỗ trợ kiểm tra lỗi trong test

script (debug) Testing: Hỗ trợ quá trình tạo test script hoặc thực hiện kiểm tra tự

động

4.1.4 Các thành ph n quan tr ng trong QTPầ ọ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 tra tự động 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 dữ liệu phục vụ cho kiểm tra tự động. 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 cho riêng 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 QTP 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 Action.

d) Checkpoint

35


Là nơi kiểm tra trong test script, khi chạy nó sẽ thực hiện so sánh kết quả thực tế khi kiểm tra phần mềm với kết quả mong đợi. Sau khi tiến hành so sánh QTP sẽ tự động ghi lại kết quả vào Test Results (nơi lưu kết quả khi chạy test script).

4.1.5 Ngôn ng vi t scriptữ ế QTP sử dụng ngôn ngữ VBScript để viết test script. Đây là ngôn ngữ dễ học; rất giống ngôn ngữ VBA. Chế độ Expert View của QTP là chế độ soạn thảo dành cho VBScript. Ngoài việc dùng VBScript để tương tác với phần mềm được kiểm tra, QTP còn có khả năng cấu hình hệ thống bằng ngôn ngữ Windows Script.Chi tiết về ngôn ngữ VBScript, người đọc có thể dễ dàng tìm trong các sách hiện có trên thị trường, thậm chí ngay chính trong phần help của QTP.

4.2 JUnit

4.2.1 Gi i thi uớ ệJUnit là một framework đơn giản dùng cho việc tạo các unit testing tự động, và chạy các test có thể lặp đi lặp lại. Nó chỉ là một phần của họ kiến trúc xUnit cho việc tạo các unit testing. JUnit là một chuẩn trên thực tế cho unit testing trong Java. JUnit về nguồn gốc được viết bởi 2 tác giả Erich Gamma và Kent BeckJUnit có những đặc điểm đáng lưu tâm như sau:

Xác nhận (assert) việc kiểm tra kết quả được mong đợi Các Test Suite cho phép chúng ta dễ dàng tổ chức và chạy các test Hỗ trợ giao diện đồ họa và giao diện dòng lệnh Các test case của JUnit là các lớp của Java, các lớp này bao gồm một

hay nhiều các phương thức unit testing, và những test này lại được nhóm thành các Test Suite.

Mỗi phương thức test trong JUnit phải được thực thi nhanh chóng. Tốc độ là điều tối quan trọng vì càng nhiều test được viết và tích hợp vào bên trong quá trình xây dựng phần mềm, cần phải tốn nhiều thời gian hơn cho việc chạy toàn bộ Test Suite. Các lập trình viên không muốn bị ngắt quãng trong một khoãng thời gian dài trong khi các test chạy, vì thế các test mà chạy càng lâu thì sẽ có nhiều khả năng là các lập trình viên sẽ bỏ qua bước cũng không kém phần quan trọng này.

Các test trong JUnit có thể là các test được chấp nhận hay thất bại, các test này được thiết kế để khi chạy mà không cần có sự can thiệp của con người. Từ những thiết kế như thế, bạn có thể thêm các bộ test vào

36


quá trình tích hợp và xây dựng phần mềm một cách liên tục và để cho các test chạy một cách tự động

4.2.2 Các thành ph n quan tr ng c a JUnitầ ọ ủ* Phương thức assertXXX()

i. assertEquals(): So sánh 2 giá trị để kiểm tra bằng nhau. Test sẽ được chấp nhận nếu các giá trị bằng nhau

ii. assertFalse(): Đánh giá biểu thức luận lý. Test sẽ được chấp nhận nếu biểu thức sai

iii. assertNotNull(): So sánh tham chiếu của một đối tượng với null. Test sẽ được chấp nhận nếu tham chiếu đối tượng khác null

iv. assertNotSame(): So sánh địa chỉ vùng nhớ của 2 tham chiếu đối tượng bằng cách sử dụng toán tử “==”. Test sẽ được chấp nhận nếu cả 2 đều tham chiếu đến các đối tượng khác nhau

v. assertNull(): So sánh tham chiếu của một đối tượng với giá trị null. Test sẽ được chấp nhận nếu tham chiếu là null

vi. assertSame(): So sánh địa chỉ vùng nhớ của 2 tham chiếu đối tượng bằng cách sử dụng toán tử “ ==”. Test sẽ được chấp nhận nếu cả 2 đều tham chiếu đến cùng một đối tượng

vii. assertTrue(): Đánh giá một biểu thức luận lý. Test sẽ được chấp nhận nếu biểu thức đúng

viii. fail(): Phương thức này làm cho test hiện hành thất bại, phương thức này thường được sử dụng khi xử lý các biệt lệ

Tất cả các phương thức của bảng trên đều nhận vào một String không bắt buộc làm tham số đầu tiên. Khi được xác định, tham số này cung cấp một thông điệp mô tả test thất bại.

* Phương thức set up và tear downi. Hai phương thức setUp() và tearDown() là một phần của lớp

junit.framework.TestCase Bằng cách sử dụng các phương thức setUp và tearDown. Khi sử dụng 2 phương thức setUp() và tearDown() sẽ giúp chúng ta tránh được việc trùng mã khi nhiều test cùng chia sẻ nhau ở phần khởi tạo và dọn dẹp các biến.

ii. JUnit tuân thủ theo một dãy có thứ tự các sự kiện khi chạy các test. Đầu tiên, nó tạo ra một thể hiện mới của test case ứng với mỗi phương thức test. Từ đó, nếu bạn có 5 phương thức test thì JUnit sẽ tạo ra 5 thể hiện của test case. Vì lý do đó, các biến thể hiện không thể được sử dụng để chia sẻ trạng thái giữa các phương thức test. Sau khi tạo xong tất cả các đối tượng test case, JUnit tuân theo các bước sau cho mỗi phương thức test:

37


iii. Gọi phương thức setUp() của test case / Gọi phương thức test / Gọi phương thức tearDown() của test case

iv. Quá trình này được lặp lại đối với mỗi phương thức test trong test case.

v. Thông thường bạn có thể bỏ qua phương thức tearDown() vì mỗi unit test riêng không phải là những tiến trình chạy tốn nhiều thời gian, và các đối tượng được thu dọn khi JVM thoát. tearDown() có thể được sử dụng khi test của bạn thực hiện những thao tác như mở kết nối đến cơ sở dữ liệu hay sử dụng các loại tài nguyên khác của hệ thống và bạn cần phải dọn dẹp ngay lập tức. Nếu bạn chạy một bộ bao gồm một số lượng lớn các unit test, thì khi bạn trỏ tham chiếu của các đối tượng đến null bên trong thân phương thức tearDown() sẽ giúp cho bộ dọn rác lấy lại bộ nhớ khi các test khác chạy

vi. Đôi khi bạn muốn chạy vài đoạn mã khởi tạo chỉ một lần, sau đó chạy các phương thức test, và bạn chỉ muốn chạy các đoạn mã dọn dẹp chỉ sau khi tất cả test kết thúc. Ở phần trên, JUnit gọi phương thức setUp() trước mỗi test và gọi tearDown() sau khi mỗi test kết thúc, vì thế để làm được điều như trên, chúng ta sẽ sử dụng lớp junit.extension.TestSetup để đạt được yêu cầu trên.

* Chạy các test lặp đi lặp lạii. Trong một vài trường hợp, chúng ta muốn chạy một test nào đó lặp đi

lặp lại nhiều lần để đo hiệu suất hay phân tích các vấn đề trục trặc. JUnit cung cấp cho chúng ta lớp junit.extension.RepeatedTest để làm được điều này. Lớp RepeatedTest giúp chúng ta thực hiện điều này một cách dễ dàng

ii. public static Test suite() {//Chạy toàn bộ test suite 10 lần

return new RepeatedTest(new TestSuite(TestGame.class), 10);}

iii. Tham số đầu tiên của RepeatedTest là một Test cần chạy, tham số thứ 2 là số lần lặp lại. Vì TestSuite cài đặt interface Test nên chúng ta có thể lặp lại toàn bộ test như trên

4.2.3 Cách t ch c ch ng trình ch y v i JUnitổ ứ ươ ạ ớ* Tổ chức các test vào các test suite

i. Thông thường JUnit tự động tạo ra các Test Suite ứng với mỗi Test Case. Tuy nhiên bạn muốn tự tạo các Test Suite của riêng mình bằng

38


cách tổ chức các Test vào Test Suite. JUnit cung cấp lớp junit.framework.TestSuite hỗ trợ việc tạo các Test Suite

ii. Khi sử dụng giao diện text hay graphic, JUnit sẽ tìm phương thức sau trong test case của bạn

iii. public static Test suite() { … }iv. Nếu không thấy phương thức trên, JUnit sẽ sử dụng kỹ thuật

reflection để tự động xác định tất cả các phương thức testXXX() trong test case của bạn, rồi thêm chúng vào một test suite. Sau đó nó sẽ chạy tất cả các test trong suite này

* Test các exceptioni. Chúng ta sử dụng cặp từ khóa try/catch để bắt các exception như

mong đợi, chúng ta sẽ gọi phương thức fail() khi exception chúng ta mong đợi không xảy ra.

ii. Trong ví dụ sau, constructor của lớp Person nên tung ra IllegalArgumentException khi cả 2 tham số của nó đều mang giá trị null. Test sẽ thất bại nếu nó không tung ra exception.public void testPassNullsToConstructor() {

try {Person p = new Person(null, null);fail("Expected IllegalArgumentException because both args are null");

} catch (IllegalArgumentException expected)

{//Bỏ qua phần này không xử lý vì có

nghĩa là test được chấp nhận }

}iii. Nói chung bạn chỉ nên sử dụng kỹ thuật này khi bạn mong đợi một

exception xảy ra. Đối với các điều kiện lỗi khác bạn nên để exception chuyển sang cho JUnit. Khi đó JUnit sẽ bắt lấy và tường trình 1 lỗi test.

4.3 Load Runner

4.3.1 Gi i thi uớ ệVề Performance Test (PT): PT là một dạng kiểm thử tự động, để tìm ra điểm “thắt cổ chai” của phần mềm cần kiểm tra, qua đó giúp cho người làm phần mềm có thay đổi thích hợp để tăng khả năng thực thi của phần mềm (PM).

39


Bên cạnh đó cũng giúp người kiểm tra biết được những thông số ngưỡng của phần mềm, đề ra tiêu chuẩn cho những lần kiểm tra sau. Khi thực hiện PT, người kiểm tra phải đề ra kết quả mong đợi một cách rõ ràng. Ví dụ: đối với ứng dụng web, chúng ta cần biết thông số quan trọng là: số kết nối (session) đồng thời mà server có thể phục vụ, thời gian (bao nhiêu phút/giây) mà trình duyệt nhận được kết quả từ server....Khi thực hiện PT người ta thường chọn thời điểm mà chương trình tương đối ổn định. Thông thường chức năng nằm trong tình huống cần kiểm tra hiệu năng đã được kiểm tra là chạy đúng. Điều này sẽ giúp cho việc phân tích đánh giá kết quả của PT dễ dàng và đúng đắn.Mercury LoadRunner là công cụ kiểm tra tự động thực hiện việc kiểm tra hiệu năng của phần mềm. Nó cho phép chúng ta tìm ra những lỗi về khả năng thực thi bằng việc phát hiện nguyên nhân, chỗ làm cho phần mềm chạy chậm hoặc không đúng yêu cầu. Đây là công cụ mạnh với giải pháp kiểm tra tải, phát hiện và đưa ra giải pháp cải tiến.Ứng dụng LoadRunner sẽ giúp giảm thời gian viết test script đến 80%, đó là nhờ nó cung cấp chức năng tự động phát sinh script mô tả lại các tình huống muốn kiểm tra.

4.3.2 Đ c đi mặ ểTheo một số quan niệm thì một công cụ PT phải có khả năng thực hiện kiểm tra chức năng. Điều này mang nghĩa tương đối vì thực tế công cụ PT không thể thay thế công cụ kiểm tra chức năng và ngược lại. Ví dụ: trong môi trường web, công cụ kiểm tra chức năng kiểm tra hoạt động của phần mềm ở cả phía client và server. Còn công cụ PT chỉ kiểm tra ở phía server mà thôi.LoadRunner có khả năng tạo ra hàng ngàn người dùng ảo thực hiện các giao dịch cùng một lúc. Sau đó LoadRunner giám sát các thông số xử lý của phần được kiểm tra. Kết quả thống kê sẽ được lưu lại và cho phép kĩ thuật viên thực hiện phân tích.

4.3.3 Môi tr ng h trườ ỗ ợLoadRunner có khả năng thực hiện PT trên nhiều môi trường khác nhau, cụ thể những giao thức và công nghệ phổ biến như ERP/CRM, Web, J2EE/.NET, XML, .NET, Wireless, Streaming Media. LoadRunner hỗ trợ hơn 60 giao thức và được xem là công cụ có khả năng hỗ trợ tối đa những công nghệ mới hiện nay.Bên cạnh đó còn có những môi trường yêu cầu phải mua và cài đặt thêm thành phần hỗ trợ như: VMWare, Web Forms, Java (SWT, AWT), ActiveX, Delphi 8 .NET WinForms, WPF from .NET 3.0, JBDC, SIP...

40


4.3.4 Các b c th c hi nướ ự ệSau khi cài đặt, LoadRunner sẽ cung cấp sẵn một số ứng dụng cho chúng ta thử nghiệm. Trong bài viết này chúng ta thực hiện kiểm tra ứng dụng Mercury Web Tours.Mở web server tại $Mercury LoadRunner >Samples>Web>Start Web ServerMở LoadRunner $menu Start>Programs>Mercury LoadRunner>LoadRunner. Chọn Create/Edit Scripts để mở Virtual User Generator tạo script cho người dùng ảo.Chọn giao thức để kiểm tra ứng dụng web: chọn New Vuser script, sau đó chọn Web (HTTP/HTML)LoadRunner tổ chức các bước thực hiện một cách rõ ràng bên trái màn hình, rất dễ sử dụng. Sau đây là công việc phải làm trong các bước đó.

i. Recording (Ghi nhận): Cho phép tự động phát sinh script ghi lại thao tác người dùng lên ứng dụng cần kiểm tra. Cách tổ chức script của LoadRunner được chia ra thành 3 thành phần chính.

- vuser_init: mỗi người dùng ảo sẽ thực hiện một lần trước khi chạy PT.

- Run: bao gồm một hoặc nhiều hàm (action), và cho phép người dùng ảo chạy lặp lại nhiều lần. Dựa trên action chúng ta có thể tổ chức các nhóm chứa các action khác nhau và theo thứ tự tùy ý.- vuser_end: mỗi người dùng ảo thực hiện một lần cuối cùng

khi chạy PT. ii. Replay (Phát lại):

Đây là bước cho phép chạy thử để kiểm tra script đã chạy đúng yêu cầu của một người dùng ảo hay chưa, qua đó có sự chỉnh sửa nếu cần. Bên cạnh đó LoadRunner còn cho phép tổ chức thứ tự, số lần lặp lại các action hiện đang có bằng cách chọn Open Run-Time Settings, và thiết lập thời gian tương tác giữa người dùng ảo và web server...

iii. Enhancements (Nâng cao):Tạo transaction: transaction là một số hành động do chúng ta chọn từ quá trình tự động phát sinh script. Mục tiêu là giám sát thông số hoạt động của một số hành động trong transaction đó. Thông số giám sát sẽ được thể hiện sau khi chúng ta thực hiện kiểm tra PT.- Tham biến hóa: thay thế các giá trị cố định trong script bằng các biến.

41


- Kiểm tra nội dung: cho phép thêm các điểm kiểm tra nội dung, trong LoadRunner gọi là content check, có thể hiểu giống như một thuật ngữ khác đã được đề cập trong bài viết trước là checkpoint. iv. Prepare For Load (Chuẩn bị thực thi):- Thiết lập sự lặp lại của các action, ở giai đoạn Replay chúng ta cũng có thể làm điều này.- Thiết kế tình huống: thiết lập số người dùng ảo tối đa thực hiện cùng một lúc, thời gian chạy bao lâu, số lượng người dùng ảo tăng như thế nào (Ramp Up) hoặc giảm như thế nào (Ramp Down).

Ví dụ: Giả lập tổng số người dùng tối đa là 100, bắt đầu là 10 người và cứ 10 phút thì tăng 1 người. Chạy trong thời gian 5 tiếng, sau đó cứ 10 phút thì giảm 1 người dùng.

- Thực hiện tình huống: thực thi các tình huống kiểm tra, phân tích kết quả dựa trên các thông số của môi trường kiểm tra, ví dụ: số yêu cầu gửi tới web server xử lý trong 1 giây, số hồi đáp từ server trong 1 giây, số trang mà người dùng có thể mở trong 1 giây, ...

v. Finish (Kết thúc):

- Upload script lên Performance Center server, đây là một phần trong việc thực hiện giải pháp chia sẻ tài nguyên PT qua Internet.

- Quản lý script thông qua việc kết hợp với giải pháp mà Mercury cung cấp là Quality Center.

4.4 NUnitTest

4.4.1 Khái quátNUnit (hhtp://www.nunit.org) là khung kiểm tra đơn vị chương trình (như lớp, hàm hay module) có mã nguồn mở. Được phát triển theo mô hình JUnit (công cụ kiểm tra nổi tiếng dùng cho Java), nhưng NUnit được viết bằng C# và khai thác được ưu điểm của các ngôn ngữ .NET.NUnit cho phép bạn viết hàm kiểm tra lỗi (unit test) theo ngôn ngữ lựa chọn để kiểm tra một chức năng cụ thể của chương trình. Unit test là cách thức tốt để kiểm tra hoạt động của đoạn code viết mới, và cũng là một phương thức kiểm tra hồi quy ứng dụng. Các unit test có thể lưu lại và chạy lại mỗi khi bạn sửa đổi code, điều này giúp phát hiện lỗi dễ dàng hơn và đảm bảo phát triển ứng dụng tốt hơn.

42


NUnit cung cấp khung để viết các unit test, và còn có giao diện đồ họa để chạy các unit test và xem kết quả. Ví dụ, chúng ta sẽ kiểm tra hoạt động của lớp Hashtable trong .NET với việc thêm vào và lấy ra 2 đối tượng. Bước đầu tiên là tham chiếu đến NUnit.Framework để có thể dùng các thuộc tính và hàm của NUnit; kế tiếp, tạo một lớp và đánh dấu nó với thuộc tính [TestFixture] để NUnit biết lớp này có hàm kiểm tra.

43


5. Demo JUnit(Java) – NUnit(C#)

5.1 JUnit (trong Java)Ta tạo một project mới cùng class Calculator và đặt nó trong package bachkhoa đặt trong package Source Package, nó có 2 phương thức là chia() và giaiThua() như saupackage bachkhoa;public class Calculator { public int chia(int a, int b){ try{ return a/b; } catch(ArithmeticException ae){ throw ae; } }

public int giaiThua(int n){ int re = 1; for (int i=1;i<=n;i++){ re = re*i; } return re; }}Để test unit này (test phương thức chia() và giaiThua()), ta tạo ra một lớp CalculatorTest trong package bachkhoa trong package Test Packages như sauTrước hết là phương thức chia()/** * Test of chia method, of class Calculator. */@Testpublic void testDevide() { System.out.println("devide"); try { int a = 6; int b = 0; Calculator instance = new Calculator();

44


int expResult = 2; int result = instance.chia(a, b); assertEquals(expResult, result); // TODO review the generated test code and remove the default call to fail. //fail("The test case is a prototype."); } catch (ArithmeticException ae) { assertTrue(true); }}

đây, ta truy n vào hàm chia hai đ i s a = 6 và b = 0 và mong mu n Ở ề ố ố ốhàm sẽ ph i tr ra Exception ả ả ArithmeticException do ta đ t ặassertTrue(true); trong hàm Test. Kết quả là PASS do hàm chia() đã throw Exception này ra đúng như mong đợi.

Và tiếp theo là test phương thức giaiThua()/** * Test of giaithua method, of class Calculator. */@Testpublic void testGiaithua() { System.out.println("giaithua"); int n = 3; Calculator instance = new Calculator(); int expResult = 6; int result = instance.giaiThua(n); assertEquals(expResult, result); // TODO review the generated test code and remove the default call to fail. //fail("The test case is a prototype.");}

đây, ta truy n vào hàm tính giai th a c a m t s v i đ i s n = 3 và Ở ề ừ ủ ộ ố ớ ố ốmong mu n hàm sẽ ph i tr ra k t qu 6 do ta đ t ố ả ả ế ả ặ int expResult = 6; trong hàm Test. Kết quả là PASS do hàm giaiThua() đã trả đúng kết quả như mong đợi.Kết quả được hiển thị như sau

45


Kết quả pass 100% test

5.2 NUnit (trong C#)Ta tạo một project mới cùng class Program và đặt nó trong namespace TestDemo, nó có một phương thức là chia() như saunamespace TestDemo{ class Program { public static void Main() { } private int chia(int a, int b) { return a / b; } }}

Ta sẽ tạo một Unit Test để kiểm thử hàm chia() trong lớp Program nói trênTa sẽ tạo hai test case :

1. Một test case bình thường truyền vào tham số a = 6 ; b = 2 và mong muốn nhận được kết quả trả về là 3

2. Một test case truyền vào a = 4 và b = 0 và mong muốn phải trả ra kết quả là -1; chứ nếu bung ra Exception (cụ thể ở đây là DivideByZeroException – do chia cho 0 – chương trình bị crash) chứng tỏ là lập trình viên chưa xử lý trường hợp này

/// <summary>///A test for chia

46


///</summary>[TestMethod()][DeploymentItem("TestDemo.exe")]public void chiaTest(){ Program_Accessor target = new Program_Accessor();// TODO: Initialize to an appropriate value int a = 6; // TODO: Initialize to an appropriate value int b = 2; // TODO: Initialize to an appropriate value int expected = 3; // TODO: Initialize to an appropriate value int actual; actual = target.chia(a, b); Assert.AreEqual(expected, actual);}

/// <summary>///A test for chia///</summary>[TestMethod()][DeploymentItem("TestDemo.exe")]public void chiaTest1(){ try { Program_Accessor target = new Program_Accessor();// TODO: Initialize to an appropriate value int a = 6; // TODO: Initialize to an appropriate value int b = 0; // TODO: Initialize to an appropriate value int actual; actual = target.chia(a, b); if (actual == -1) { Assert.IsFalse(false); } } catch (DivideByZeroException ex) { Assert.IsFalse(true); }}

Và nhận được kết quả

47


Chi tiết của Test Case 1:

Chi tiết của Test Case 2:

Ta có thể thấy Test 1 lấy 6 / 2 = 3 là chính xác nhưng Test 2 đã fail do bị bung ra DivideByZeroException.

48


6. Tài Li u Tham Kh oệ ả Slide bài gi ng c a cô Vũ Th H ng Giangả ủ ị ươ The Art Of Software Testing – Second Edition - Glenford J. Myers McGraw Hill - Software Engineering - A Practitioner's Approach -

Pressman (5th Ed)(2001) Sybex - Effective Software Test Automation Happy About® Global Software Test Automation - Hung Q. Nguyen,

Michael Hackett, Brent K. Whitlock http://en.wikipedia.org/wiki/Unit_testing http://en.wikipedia.org/wiki/Software_testing http://msdn.microsoft.com/en-us/library/ms243147(v=vs.80).aspx http://students.depaul.edu/~slouie/QTUsers Guide .pdf

49

http://students.depaul.edu/~slouie/QTUsersGuide.pdf

http://msdn.microsoft.com/en-us/library/ms243147(v=vs.80).aspx

http://en.wikipedia.org/wiki/Software_testing

http://en.wikipedia.org/wiki/Unit_testing

Education

Tìm Hiểu Các Kỹ Thuật Kiểm Thử Phần Mềm và Một Số Ứng Dụng Trong Thực Tế