Tải bản đầy đủ (.pdf) (74 trang)

Luận văn thạc sĩ VNU UET nghiên cứu kiểm thử các ứng dụng web và xây dựng công cụ hỗ trợ luận văn ths công nghệ thông tin 61 48 10

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (923.54 KB, 74 trang )

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƢỜNG ĐẠI HỌC CÔNG NGHỆ

TẠ VŨ NHÂN

NGHIÊN CỨU KIỂM THỬ CÁC ỨNG DỤNG WEB VÀ XÂY
DỰNG CƠNG CỤ HỖ TRỢ

Ngành: Cơng Nghệ Thơng Tin
Chun ngành: Công Nghệ Phần Mềm
Mã số: 60 48 10

LUẬN VĂN THẠC SĨ

NGƯỜI HƯỚNG DẪN KHOA HỌC
TS.Trƣơng Ninh Thuận

Hà Nội - 2010

LUAN VAN CHAT LUONG download : add


LỜI CAM ĐOAN
Tơi xin cam đoan đây là cơng trình nghiên cứu của riêng tôi. Các kết quả nêu
trong bản luận văn này là trung thực và chưa từng được ai cơng bố trong bất cứ
cơng trình nào khác.

Hải Phịng, tháng 01 năm 2010
Tạ Vũ Nhân

LUAN VAN CHAT LUONG download : add




LỜI CẢM ƠN
Trước hết tôi xin gửi lời cảm ơn đặc biệt nhất tới TS. Trương Ninh Thuận, Bộ
môn Công nghệ phần mềm, Khoa Công nghệ thông tin, Trường Đại học Công
nghệ, Đại học Quốc Gia Hà Nội, người đã trực tiếp giảng dạy, định hướng đề tài
và đã tận tình hướng dẫn chỉ bảo tơi trong suốt q trình thực hiện luận văn cao
học này.
Tôi xin được gửi lời cảm ơn sâu sắc tới các thầy cô giáo trong Khoa Công nghệ
thông tin, Trường Đại học Công nghệ, Đại học Quốc Gia Hà Nội đã tận tình
giảng dạy và truyền đạt những kiến thức, những kinh nghiệm quý báu trong suốt
2 năm học Cao học.
Cuối cùng tôi xin dành một tình cảm biết ơn tới Bố, Mẹ và gia đình, những
người đã ln ln ở bên cạnh tơi, động viên, chia sẻ cùng tôi trong suốt thời
gian học cao học cũng như quá trình thực hiện luận văn cao học.

LUAN VAN CHAT LUONG download : add


DANH MỤC CÁC TỪ VIẾT TẮT
Từ viết tắt

Tiếng Anh

EP

Equivalence Partitioning

EV


EventValidation

VS

ViewState

BVA

Boundary Value Analysis

WS

Web Services

WSDL

Web Services Description Language

XML

eXtensible Markup Language

SOAP

Simple Object Access Protocol

WBT

White Box Testing


BBT

Black Box Testing

HTTP

Hyper Text Transfer Protocol

DFT

Data Flow Testing

SUT

System Under Test

LUAN VAN CHAT LUONG download : add


DANH MỤC CÁC HÌNH VÀ BẢNG
Hình 1: Web Service cho phép truy cập tới các code ứng dụng sử dụng chuẩn
cơng nghệ Internet ............................................................................................... 10
Hình 2: Web Service cung cấp một tầng trừu tượng giữa ứng dụng client và ứng
dụng cần gọi tới. .................................................................................................. 11
Hình 3: Mơ tả cơ chế hoạt động của Web Service. ............................................ 12
Hình 4: Web Service technology stack .............................................................. 13
Hình 5: TCP/IP network model.......................................................................... 13
Hình 7: Minh họa thiết kế tổng thể ứng dụng ..................................................... 48
Hình 8: Gọi dịch vụ SearchFlightService ........................................................... 49
Hình 9: Gọi dịch vụ SearchHotelService ............................................................ 50

Hình 10 : Ứng dụng sử dụng dữ liệu từ 2 webservice ........................................ 50
Hình 11: Cơng cụ kiểm thử webservice .............................................................. 51
Hình 12: Kiểm thử tự động với webservice1 SearchHotel ................................. 54
Hình 14 : Kiểm thử tự động tích hợp cả 2 webservices ...................................... 58

LUAN VAN CHAT LUONG download : add


MỤC LỤC
MỞ ĐẦU ............................................................................................................... 1
Chương 1 - CÁC KỸ THUẬT KIỂM THỬ PHẦN MỀM ................................... 4
1.1. Kiểm thử hộp trắng (WBT) ....................................................................... 4
1.2. Kiểm thử hộp đen (BBT) .......................................................................... 6
1.2.1. Kỹ thuật kiểm thử nền tảng đồ thị ...................................................... 6
1.2.2. Kỹ thuật phỏng đoán lỗi ..................................................................... 6
1.2.3. Kỹ thuật phân tích giá trị đường biên ................................................ 6
1.2.4. Kỹ thuật phân vùng tương đương (EP) .............................................. 6
1.2.5. Kỹ thuật kiểm thử so sánh .................................................................. 7
1.2.6. Kỹ thuật kiểm thử chuỗi trực giao ..................................................... 7
1.3. Lựa chọn kiểu kiểm thử cho hệ thống phần mềm ..................................... 8
Chương 2 - WEB SERVICE VÀ CÁC ỨNG DỤNG WEB ............................. 10
2.1. Giới thiệu về web service ........................................................................ 10
2.2. Kiến trúc web service .............................................................................. 12
2.2.1. Mô tả cơ chế hoạt động của web service ......................................... 12
2.2.2. Kiến trúc phân tầng của web service ............................................... 13
2.3. Các ứng dụng web ................................................................................. 15
Chương 3 - KIỂM THỬ CÁC ỨNG DỤNG WEB ............................................ 16
3.1. Một số vấn đề về kiểm thử các trang web .............................................. 16
3.1.1. Giới thiệu .......................................................................................... 16
3.1.2. Gửi một HTTP GET Request và nhận HTTP Response.................. 17

3.1.3. Gửi một HTTP-Request và nhận HTTP-Response có quyền xác thực
..................................................................................................................... 17
3.1.4. Gửi một HTTP GET Request phức tạp và nhận HTTP Response... 18
3.1.5. Nhận một HTTP Response theo từng dòng một .............................. 19
3.1.6. Gửi một HTTP POST Request tới một trang Web ASP .................. 20
3.1.7. Gửi một HTTP POST Request tới một ứng dụng Web ASP.NET .. 21
3.1.8. Xử l‎‎ý đầu vào có chứa các ký tự đặc biệt ........................................ 22

LUAN VAN CHAT LUONG download : add


3.1.9. Lập chương trình lấy các giá trị VS và giá trị EV ........................... 24
3.1.10. Xử lý với các điểu khiển Checkbox và RadioButtonList .............. 27
3.2. Kiểm thử web services ............................................................................ 28
3.2.1. Giới thiệu .......................................................................................... 28
3.2.2. Kiểm thử một phương thức Web dùng Proxy .................................. 33
3.2.3. Kiểm thử một phương thức Web dùng Sockets ............................... 35
3.2.4. Kiểm thử một phương thức Web dùng HTTP ................................. 40
3.2.5. Kiểm thử một phương thức Web dùng TCP .................................... 41
3.2.6. Sử dụng bộ nhớ trong để lưu trữ tình huống kiểm thử .................... 43
Chương 4 - XÂY DỰNG CÔNG CỤ HỖ TRỢ KIỂM THỬ ............................ 46
4.1. Các yêu cầu cho việc kiểm thử các ứng dụng sử dụng dịch vụ web ...... 46
4.2. Xây dựng chương trình kiểm thử ứng dụng web sử dụng dịch vụ web.. 47
4.2.1. Phạm vi ứng dụng ............................................................................ 47
4.2.2. Thiết kế ứng dụng ............................................................................ 48
4.2.3. Cài đặt và triển khai ứng dụng ......................................................... 49
TÀI LIỆU THAM KHẢO ................................................................................... 61

LUAN VAN CHAT LUONG download : add



1

MỞ ĐẦU
Vào khoảng đầu những năm 60 nhu cầu sử dụng các hệ thống phần mềm, giải
phóng sức lao động trí tuệ trong các hoạt động kinh doanh, quản lý, giải trí và một số
lĩnh vực khoa học xã hội tăng cao. Tuy nhiên các yêu cầu về nghiệp vụ phức tạp trong
các hệ thống này dẫn đến các hệ thống phần mềm tương ứng cũng ngày càng trở nên
phức tạp, cồng kềnh và khó kiểm sốt. Rất nhiều u cầu nghiệp vụ đòi hỏi xử lý các
vấn đề liên quan đến dữ liệu phân tán, xử lý các thông tin khác nhau do nhiều tổ chức
nắm giữ. Đã có nhiều kiến trúc phần mềm được đưa ra nhưng chưa đủ mạnh để đáp
ứng được nhu cầu thực tế dẫn đến sự khủng hoảng phần mềm.
Trong thời kỳ này, một số dự án phần mềm điển hình đã thất bại như: Hệ thống
điều khiển hàng không; Các hệ thống phần mềm phục vụ cho ngành viễn thông, y
tế,.... Theo sự phân tích thực tế, các hệ thống phần mềm rơi vào tình trạng này bởi các
nguyên nhân khác nhau như[19]:
 Khả năng xây dựng phần mềm cho phần cứng không theo kịp sự phát
triển của phần cứng.
 Khả năng xây dựng phần mềm chưa đáp ứng được nhu cầu thực tế.
 Sự cạnh tranh giữa các hệ thống phần mềm về chất lượng và độ tin cậy
ngày càng cao.
 Nguồn nhân lực khơng đủ so với nhu cầu thực tế.
Ngồi những ngun nhân cơ bản trên, cịn có những ngun nhân xuất phát từ
điểm yếu của hệ thống phầm mềm như:
 Khơng có đơn vị dữ liệu chuẩn để đánh giá hệ thống.
 Khơng xác định chính xác được chi phí xây dựng hệ thống.
 Các cơng cụ hỗ trợ lập kế hoạch và đánh giá tự động không phù hợp.
 Kế hoạch phát triển hệ thống không hợp lý tạo sức ép lớn cho người thực
hiện
 Quá trình quản lý tiến trình thực hiện và sự cố phát sinh không phù hợp.


LUAN VAN CHAT LUONG download : add


2
 Thiếu khả năng kiểm duyệt thiết kế và quản lý mã lệnh của hệ thống
phần mềm.
Để khắc phục và hạn chế được những điểm yếu này đòi hỏi dự án phần mềm phải
có những quy trình nhất định, giúp chúng ta kiểm sốt được tiến trình thực hiện dự án
cũng như hiệu quả công việc, kết quả và hướng phát triển của dự án. Sau khi hoàn
thành hệ thống phần mềm của dự án và trước khi đưa vào ứng dụng trong thực tế, hệ
thống này cần phải được kiểm tra, đánh giá tính chính xác và khả năng đáp ứng yêu
cầu thực tế - thuật ngữ “Kiểm thử phần mềm” bắt nguồn từ đây[9,18].
Kiểm thử phần mềm là một phương pháp kiểm sốt q trình thử nghiệm, thực
hiện các chức năng trong hệ thống phần mềm theo một tập hợp các điều kiện đặt ra với
mục đích tìm ra lỗi của hệ thống. Kết quả của kiểm thử phần mềm là tư liệu chứng
minh hệ thống có thể đáp ứng được các yêu cầu đặt ra và ứng dụng được trong thực tế
hay khơng?
Kiểm thử phần mềm có thể nói là một phần khơng thể thiếu trong việc xây dựng
và phát triển phần mềm. Nó cho chúng ta biết một phần mềm khi xây dựng và sử dụng
có đúng với các yêu cầu mà chúng ta đặt ra hay không.
Ở nước ta hiện nay ngành Công nghệ phần mềm đang phát triển mạnh mẽ, việc
kiểm thử phần mềm chưa thực sự được quan tâm nhiều hoặc quan tâm nhưng không
đúng cách. Việc áp dụng các công cụ tự động cho việc kiểm thử hầu như khơng có.
Trong khi đó theo thống kê chúng ta có thể tốn 40% đến 60% thời gian dành cho việc
kiểm thử.
Phần lớn các cơng ty thường khơng có các tester thực sự, một số cơng ty có
những người chun về kiểm thử nhưng thường làm thủ cơng. Vì vậy việc xây dựng
các cơng cụ hỗ trợ kiểm thử cho chúng ta các lợi ích sau.
 Mất ít thời gian hơn.

 Chính xác hơn.
 Hiệu quả hơn.
 Tránh được các lỗi do con người gây ra do kiểm thử thủ công
Với thực tế và các lợi ích trên tơi nhận thấy việc nghiên cứu và xây dựng đề tài
này là cần thiết, phù hợp với tình hình hiện tại.

LUAN VAN CHAT LUONG download : add


3
Cấu trúc của luận văn bao gồm:
Chƣơng 1 Đưa ra một số kỹ thuật kiểm thử phần mềm, tìm hiểu một số ưu nhược
điểm của mỗi kỹ thuật kiểm thử. Lựa chọn các kỹ thuật kiểm thử phần mềm.
Chƣơng 2 Đưa ra cái nhìn tổng qt về cơng nghệ Web Service, tìm hiểu về các
thành phần chuẩn được sử dụng trong công nghệ Web Service, kiến trúc Web Service
và quy trình hoạt động của một Web Service. Tìm hiểu về ứng dụng web và xu hướng
phát triển các ứng dụng.
Chƣơng 3 Đưa ra một số vấn đề và cách giải quyết các vấn đề trong việc viết
một công cụ hỗ trợ kiểm thử trong .Net của các ứng dụng web. Nghiên cứu các
phương pháp kiểm thử web services.
Chƣơng 4 Giới thiệu một bài toán Travel-Agent, mục tiêu, yêu cầu của bài tốn.
Xây dựng cơng cụ hỗ trợ kiểm thử cho bài toán.

LUAN VAN CHAT LUONG download : add


4

Chƣơng 1 - CÁC KỸ THUẬT KIỂM THỬ PHẦN MỀM
Hai kỹ thuật thường hay sử dụng để kiểm thử phần mềm:



Kiểm thử hộp trắng (WBT – White Box Testing).



Kiểm thử hộp đen (BBT – Black Box Testing).

1.1. Kiểm thử hộp trắng (WBT)
WBT liên quan đến việc xem xét cấu trúc của mã lệnh. Khi biết được cấu trúc
của sản phẩm, kiểm thử có thể kiểm sốt được một cách chắc chắn bản chất thao tác
thực hiện có theo đặc tả kỹ thuật khơng? Và các thành phần có được thực hiện hợp lý
khơng?
WBT có khuynh hướng bao trùm các sự kiện của các chi tiết kỹ thuật trong mã
lệnh, bao gồm các kỹ thuật sau[20]:
 Phân đoạn sự kiện: mỗi phân đoạn của cấu trúc điều khiển mã lệnh được thi
hành theo sự phân đoạn nhỏ nhất
 Phân nhánh sự kiện hoặc kiểm thử nút: mỗi nhánh trong mã lệnh được thực
hiện theo mỗi hướng có thể thực hiện được theo mức nhỏ nhất.
 Sự kiện điều kiện ghép: Khi có nhiều điều kiện, chúng ta khơng cần kiểm
thử từng hướng (từng điều kiện) nhưng phải kết hợp các hướng có thể thực hiện
được của điều kiện, cách thường dùng là bảng chân lý (chân trị).
 Kiểm thử đường đi cơ bản: Mỗi đường đi độc lập từ đầu đến cuối trong mã
lệnh trong trình tự đã được xác định trước.
 Kiểm thử theo luồng dữ liệu (DFT - Data Flow Testing): phương pháp này
thực hiện kiểm tra các biến đặc trưng trong mỗi tính tốn có thể được thực thi,
như vậy hạn chế thiết lập các đường trung gian từ đầu đến cuối mã lệnh, … đây
là cơ sở trên mỗi mảnh của mã lệnh để chọn và kiểm tra.
 Kiểm thử đường đi: kiểm thử đường đi là kiểm thử kiểm thử tất cả các
đường đi có thể thực hiện được từ đầu đến cuối mã lệnh được định nghĩa và

chuyển đổi. Kiểm thử này rất phức tạp và tốn thời gian.

LUAN VAN CHAT LUONG download : add


5
 Kiểm thử vòng lặp: bổ sung đơn vị đo lường lớn nhất, đó là chiến lược kiểm
thử căn bản trong kiểm thử vòng lặp. Chiến lược này hướng tới việc kiểm thử
các vòng lặp đơn, các vòng lặp ràng buộc nhau, và các vòng lặp lồng nhau.
Chúng ta làm gì với WBT
WBT sử dụng cấu trúc điều khiển của thiết kế các thủ tục để đưa ra các tình
huống kiểm thử. Người kiểm thử có thể sử dụng phương thức WBT để đưa ra các tình
huống kiểm thử mà:
 Đảm bảo tất cả các đường đi độc lập trong module được thực thi ít nhất
một lần.
 Sử dụng tất cả các quyết định logic trong các giá trị của nó (đúng hoặc sai).
 Thực thi được tất cả các vòng lặp.
 Sử dụng các cấu trúc dữ liệu của nó để đảm bảo giá trị của chúng.
WBT cịn được gọi là kiểm thử hộp kính hoặc kiểm thử cấu trúc.
Tại sao dùng WBT?
Chúng ta dùng WBT vì BBT khơng chắc đã phát hiện được nhiều lỗ hổng của các
nhược điểm trong lập trình như:

Các lỗi logic và các giả định không đúng bị đảo ngược. Lỗi này xuất hiện
khi thiết kế và thực thi các hàm chức năng, các điều kiện hoặc các điều khiển.

Luồng logic của chương trình có những khác thường, nghĩa là giả định của
chúng ta về luồng của điều khiển và dữ liệu có thể tạo ra các lỗi thiết kế mà nó
chỉ có thể phát hiện được khi dùng kiểm thừ đường đi.



Lỗi sinh các giá trị ngẫu nhiên.

Kỹ năng yêu cầu
Về lý thuyết thì chúng ta cần làm trong WBT là định nghĩa tất cả các đường
logic, mở rộng các tình huống kiểm thử để thực thi và đánh giá kết quả trả về… nói
chung là các tình huống kiểm thử thực thi được tất cả các vấn đề trong chương trình.

LUAN VAN CHAT LUONG download : add


6
Để thực hiện được điều này chúng ta phải nắm được chương trình, đặc tả kỹ thuật
và mã lệnh được kiểm thử.
Công cụ sử dụng cho WBT
Một vài công cụ kiểm thử tự động cung cấp WBT như:


Cơng cụ dị tìm lỗ hổng bộ nhớ và lỗi run-time.


Cơng cụ ghi lại chính xác thời gian sử dụng ứng dụng trong khối nhất định
của mã lệnh cho mục đích tìm kiếm những đoạn mã không hiệu quả.


Công cụ xác định các vùng của ứng dụng được hoặc không được thực thi.

1.2. Kiểm thử hộp đen (BBT)
Với kiểm thử hộp đen, người kiểm thử không cần biết đến cấu trúc hoặc cơ chế
làm việc bên trong hộp đen mà cái cần quan tâm là chức năng của nó[16,20].


1.2.1. Kỹ thuật kiểm thử nền tảng đồ thị
Kiểm thử phần mềm bắt đầu bằng việc tạo ra đồ thị của các đối tượng quan trọng
và các mối liên quan tới nó, sau đó đưa ra một chuỗi các kiểm thử mà nó bao hàm
được đồ thị để thực thi được các đối tượng và các quan hệ của đối tượng để phát hiện
lỗi.

1.2.2. Kỹ thuật phỏng đốn lỗi
Phỏng đốn lỗi được hình thành qua kinh nghiệm kỹ thuật và dự án. Khơng có
cơng cụ và công nghệ giành cho kỹ thuật này, nhưng chúng ta có thể dựng các tình
huống kiểm thử dựa vào trạng thái làm việc của hàm chức năng.

1.2.3. Kỹ thuật phân tích giá trị đƣờng biên
Phân tích giá trị đường biên (BVA - Boundary Value Analysis) là kỹ thuật lựa
chọn dữ liệu kiểm thử (kỹ thuật kiểm thử chức năng) với các giá trị đường biên. Giá trị
đường biên bao gồm: cực đại, cực tiểu. giá trị sát trong/ sát ngoài đường biên, các giá
trị đặc biệt và các giá trị lỗi. Kỹ thuật này thực hiện với kỳ vọng: nếu hệ thống thực
hiện đúng với các giá trị đặc biệt này thì sẽ chạy đúng với tất cả các giá trị trong phạm
vi của nó[17].

1.2.4. Kỹ thuật phân vùng tƣơng đƣơng (EP)

LUAN VAN CHAT LUONG download : add


7
Kỹ thuật phân vùng tương đương là kỹ thuật kiểm thử hộp đen thực hiện phân
chia vùng dữ liệu đầu vào của chương trình trong lớp dữ liệu theo các tình huống kiểm
thử có thể phân chia được.
Kỹ thuật EP được định nghĩa theo các nguyên tắc sau:

1- Nếu điều kiện vào định rõ phạm vi thì một lớp hợp lệ và hai lớp không hợp
lệ được xác định.
2- Nếu điều kiện vào yêu cầu giá trị đặc biệt, thì một lớp tương đối hợp lệ và
hai lớp tương đối không hợp lệ được xác định.
3- Nếu điều kiện định rõ thành phần thiết lập, thì một lớp tương đối hợp lệ và
một lớp tương đối không hợp lệ được xác định.
4- Nếu điều kiện vào là giá trị logic, thì một lớp hợp lệ và một lớp khơng hợp
lệ được xác định.

1.2.5. Kỹ thuật kiểm thử so sánh
Có những tình huống giành cho những phiên bản độc lập của phần mềm ứng
dụng, những phiên bản độc lập này là cơ sở của kỹ thuật kiểm thử hộp đen được gọi là
kiểm thử so sánh hoặc kiểm thử back – to – back

1.2.6. Kỹ thuật kiểm thử chuỗi trực giao
Chiến lược kiểm thử chuỗi trực giao là phương thức thống kê, có hệ thống của
kiểm thử tương tác bắt nguồn từ tập hợp nhỏ thích hợp của các tình huống kiểm
thử[16,17].
Ƣu điểm:
 Người kiểm thử không cần biết về mặt kỹ thuật.
 Kỹ thuật kiểm thử này thích hợp nhất cho việc tìm lỗi như một người dùng
thực thụ.
 Kỹ thuật kiểm thử này hỗ trợ nhận dạng sự gần đúng và trái ngược trong
hàm chức năng.
 Các tình huống kiểm thử được phác họa ngay sau khi hoàn thành hàm chức
năng.

LUAN VAN CHAT LUONG download : add



8
Nhƣợc điểm:
 Khả năng kiểm thử phụ thuộc vào người lập trình.
 Dữ liệu đầu vào cho kiểm thử cần một lượng mẫu lớn.
 Rất khó để nhận dạng được tất cả dạng dữ liệu đầu vào cho giới hạn kiểm
thử.
 Khơng xác định được đồ thị cho q trình kiểm thử.

1.3. Lựa chọn kiểu kiểm thử cho hệ thống phần mềm
WTB sử dụng kiểm thử cho một sản phẩm phần mềm nên nó khơng đảm bảo
được khả năng thực hiện các chi tiết kỹ thuật (đặc điểm kỹ thuật của phần mềm) một
cách trọn vẹn. BBT được sử dụng kiểm thử cho chi tiết kỹ thuật, nhưng nó khơng đảm
bảo khả năng thực hiện được hết tất cả các chi tiết kỹ thuật. Như vậy chúng ta có thể
thấy:
 BBT là kiểm thử dựa vào đặc tả kỹ thuật, khi tìm thấy lỗi sẽ xác định được
cụ thể chi tiết kỹ thuật chưa hoàn chỉnh.
 WTB là kiểm thử dựa theo quy trình thực hiện, khi tìm thấy lỗi sẽ xác định
được phần lỗi của quy trình.
Vậy nên để hoàn thành kiểm thử cho sản phầm phần mềm cần phải áp dụng cả
hai loại kiểu thử này.
WBT phức tạp hơn BBT vì nó cần đến mã lệnh nguồn của phần mềm trước khi
dựng kế hoạch kiểm thử và nếu như phần mềm xây dựng khơng chính xác theo u
cầu kỹ thuật thì rất khó xác định dữ liệu đầu vào phù hợp. Vì vậy khi dựng kế hoạch
kiểm thử nên bắt đầu từ BBT để xác định được những chi tiết kỹ thuật được dùng,
WBT đưa vào thiết kế mức thấp (LLD – Low Level Design) là hoàn thành. LLD sẽ ghi
địa chỉ cho tất cả các thuật toán và kiểu mã. Sau đó kiểm tra lại dựa theo BBT và đưa
thêm các tình huống kiểm thử theo yêu cầu.
Vai trò của giai đoạn giải quyết lỗi kiểm thử rất quan trọng vì lỗi của tình huống
kiểm thử có thể có kết quả thay đổi theo từng tình huống khác nhau, trường hợp này
yêu cầu phải thực hiện lại BBT và xác định lại đường đi của WBT. Sự lựa chọn ít

phức tạp hơn là coi q trình kiểm thử có kết quả đúng, sau đó dùng kết quả này thực
hiện lại bước liền trước đó, có thể sẽ tìm thấy lỗi.

LUAN VAN CHAT LUONG download : add


9

LUAN VAN CHAT LUONG download : add


10

Chƣơng 2 - WEB SERVICE VÀ CÁC ỨNG DỤNG WEB
2.1. Giới thiệu về web service
Web Service là gì: Web Service là một giao diện truy cập mạng đến các ứng
dụng chức năng, được xây dựng từ việc sử dụng các cơng nghệ chuẩn Internet[1,3].
Được minh hoạ trong hình dưới đây.

Hình 1: Web Service cho phép truy cập tới các code ứng dụng sử dụng chuẩn công
nghệ Internet
Thuật ngữ Web Service diễn tả một cách thức tích hợp các ứng dụng trên nền
web lại với nhau bằng cách sử dụng các công nghệ XML, SOAP, WSDL, và UDDI
trên nền tảng các giao thức Internet với mục tiêu tích hợp ứng dụng và truyền thông
điệp. XML được sử dụng để đánh dấu dữ liệu, SOAP được dùng để truyền dữ liệu,
WSDL được sử dụng để mơ tả các dịch vụ có sẵn và UDDI được sử dụng để liệt kê
những dịch vụ nào hiện tại đang có sẵn để có thể sử dụng. Web Service cho phép các
tổ chức có thể trao đổi dữ liệu với nhau mà khơng cần phải có kiến thức hiểu biết về hệ
thống thông tin đứng sau Firewall kia [1].
Khơng giống như mơ hình Client/Server truyền thống, chắng hạn như hệ thống

Webserver/webpage, Web Service không cung cấp cho người dùng một giao diện đồ
họa nào, Web Service đơn thuần chỉ là việc chia sẻ các dữ liệu logic và xử lý các dữ
liệu đó thơng qua một giao diện chương trình ứng dụng được cài đặt xuyên suốt trên
mạng máy tính. Tuy nhiên nguời phát triển Web Service hồn tồn có thể đưa Web
Service vào một giao diện đồ họa người dùng (chẳng hạn như là một trang web hoặc
một chương trình thực thi nào đó) để có thể cung cấp thêm các chức năng đặc biệt cho
người dùng.
Web Service cho phép các ứng dụng khác nhau từ các nguồn khác nhau có thể
giao tiếp với các ứng dụng khác mà khơng địi hỏi nhiều thời gian viết mã lệnh, do tất
cả các quá trình giao tiếp đều tuân theo định dạng XML, cho nên Web Service khơng
bị phụ thuộc vào bất kì hệ điều hành hay ngơn ngữ lập trình nào. Ví dụ, chương trình

LUAN VAN CHAT LUONG download : add


11
viết bằng ngơn ngữ Java cũng có thể trao đổi dữ liệu với các chương trình viết bằng
Perl, các ứng dụng chạy trên nền Windows cũng có thể trao đổi dữ liệu với các ứng
dụng chạy trên nền Linux. Công nghệ Web Service khơng u cầu phải sử dụng trình
duyệt và ngơn ngữ HTML, đơi khi Web Service cịn được gọi là Application Services.
Xét theo một khía cạnh khác, nếu các ứng dụng có thể truy cập thơng qua mạng
máy tính bằng việc sử dụng các giao thức như HTTP, XML, SMTP hoặc Jabber thì đó
chính là Web Service.
Như Hình 1 và Hình 2 đã minh họa, Web Service là một Application Interface
được đặt giữa Application Code và người sử dụng các code đó. Nó có thể được ví như
một tầng trừu tượng, phân tách giữa platform và ngôn ngữ lập trình, nó mơ tả cách
thức mà các application code được triệu gọi như thế nào. Điều này có nghĩa nếu bất kì
một ngơn ngữ lập trình nào hỗ trợ Web Service đều có thể truy cập các ứng dụng chức
năng của nhau.


Hình 2: Web Service cung cấp một tầng trừu tượng giữa ứng dụng client và ứng dụng
cần gọi tới.
Ngày này, Web Service có thể được triển khai trên Internet dưới dạng một
Website HTML, chính vì thế, các Application Service cần phải có một cơ thế cho việc
cơng bố, quản lý, tìm kiếm và phục hồi nội dung được người sử dụng truy cập thông
qua giao thức chuẩn HTTP và định dạng dữ liệu HTML. Các ứng dụng Client ( như
Web Browser) cần phải hiểu các chuẩn mà Web Service hỗ trợ để có thể tương tác với
các service nhằm thực thi một nhiệm vụ như việc đặt mua sách, gửi thiệp mừng hoặc
là đọc bản tin vv...
Web Service cung cấp tính trừu tượng cho các giao diện chuẩn, cho nên sẽ khơng
nảy sinh ra bất kì vấn đề gì trong quá trình tương tác khi các service được viết trên
java và trình duyệt được viết bằng C++, hoặc các service được triển khai trên Unix
trong khi các trình duyệt lại được triển khai trên Windows. Web Service cho phép giao
tiếp giữa các platform khác nhau có thể hoạt động cùng nhau theo nguyên tắc tạo ra
một platform trung gian có liên quan.

LUAN VAN CHAT LUONG download : add


12
Tính tương thích (Inteoperability) là một lợi thế vơ cùng mạnh mẽ của Web
Service, thông thường, các công nghệ Java và cơng nghệ của Microsoft rất khó có thể
tích hợp được với nhau, nhưng với Web Service thì các Application và Client sử dụng
2 cơng nghệ trên hồn tồn có khả năng tương tác với nhau thông qua Web Service[2].
Rất nhiều nhà cung cấp ứng dụng như IBM và Microsoft đều đã hỗ trợ Web
Service trong các sản phẩm của họ. IBM hỗ trợ Web Service thơng qua gói
WebSphere, Tivoli, Lotus và DB2 và Microsoft với.NET cũng đã hỗ trợ Web Service.

2.2. Kiến trúc web service
2.2.1. Mô tả cơ chế hoạt động của web service


Hình 3: Mơ tả cơ chế hoạt động của Web Service.
Cơ chế hoạt động của Web Service yêu cầu phải có 3 thao tác đó là: Find, Public,
Bind [1].
Trong kiến trúc Web Service, Service Provider công bố các mô tả về các service
thông qua Service Registry. Service Consumer tìm kiếm trong các Service Registry để
tìm ra các service mà họ cần sử dụng. Service Consumer có thể là một người hoặc
cũng có thể là một chương trình.
Kĩ thuật mơ tả dịch vụ là một trong những thành phần chủ chốt của kiến trúc Web
Service. Các thông tin mô tả đầy đủ nhất về kiến trúc Web Service được thể hiện trong
hai tài liệu riêng biệt, đó là NASSL – Network Accessible Service Specification
Language và WDS – Web-Defined Service. NASSL là một tài liệu dưới dạng chuẩn
của XML cho các service chạy trên nền Network, nó được sử dụng để chỉ ra các thông
tin hoạt động của Web Service, chẳng hạn như danh sách các service, các mô tả về
service, ngày hết hạn của service và các thông tin liên quan đến các Service Provider,

LUAN VAN CHAT LUONG download : add


13
như tên, địa chỉ[5]. Tài liệu WDS là một tài liệu mang tính đáp ứng đầy đủ cho tài liệu
NASSL. Khi ta kết hợp hai tài liệu này với nhau ta sẽ có được sự mơ tả một cách đầy
đủ về các dịch vụ để cho phía yêu cầu dịch vụ có thể dễ dàng tìm kiếm và gọi các dịch
vụ đó.

2.2.2. Kiến trúc phân tầng của web service

Hình 4: Web Service technology stack
Mơ hình kiến trúc phân tầng của Web Service tương tự với mơ hình TCP/IP được
sử dụng để mơ tả kiến trúc Internet.


Hình 5: TCP/IP network model
Các tầng truyền thống như Packaging, Description, và Discovery trong mô hình
Web Service Stack là những tầng cung cấp khả năng tích hợp và cần thiết cho mơ hình
ngơn ngữ lập trình trung lập.

Tầng Discovery: Tầng Discovery cung cấp cơ chế cho người dùng khả
năng lấy các thông tin mô tả về các Service Provider. Công nghệ được sử dụng
tại tầng này đó chính là UDDI – Universal Description, Discovery and
Integration.

Tầng Desciption: Khi Web Service được thực thi, nó cần phải đưa ra các
quyết định về các giao thức trên các tầng Network, Transport, Packaging mà nó
sẽ hỗ trợ trong quá trình thực thi. Các mơ tả về dịch vụ sẽ đưa ra phương pháp để
làm thế nào mà các Service Consumer có thể liên kết và sử dụng các service đó.
Tại tầng Description, cơng nghệ được sử dụng ở đây chính là WSDL (Web
Service Desciption Language) – Ngơn ngữ mơ tả Web Service. Ngồi ra, ít phổ
biến hơn, chúng ta cịn có 2 ngơn ngữ khác được định nghĩa bởi tổ chức W3C đó

LUAN VAN CHAT LUONG download : add


14
là ngôn ngữ môt tả tài nguyên - W3C‟s Resource Desciption Framework (RDF)
và ngôn ngữ đánh dấu sự kiện DARPA. Cả hai ngơn ngữ này đều có khả năng
cung cấp việc mô tả Web Service mạnh hơn ngôn ngữ WSDL tuy nhiên do tính
phức tạp của chúng nên khơng được phát triển rộng rãi. Chúng tôi sẽ đề cập đến
ngôn ngữ WSDL một cách cụ thể hơn trong phần “Các cơng nghệ của Web
Service ” tại chương 2 của khóa luận này.


Tầng Packaging: Việc thực hiện vận chuyển các dữ liệu Web Service được
thực hiện bởi tầng Transport, tuy nhiên trước khi được vận chuyển, các dữ liệu
cần phải được đóng gói lại theo các định dạng đã định trước để các thành phần
tham gia vào mơ hình Web Service có thể hiểu được, việc đóng gói dữ liệu được
thi bởi tầng Packaging. Việc đóng gói dữ liệu bao gồm các cơng việc định dạng
dữ liệu, mã hóa các giá trị đi kèm dữ liệu đó và các cơng việc khác.
Các dữ liệu có thể được đóng gói dưới dạng các tài liệu HTML, tuy nhiên với các
tài liệu HTML thường khơng thuận tiện cho u cầu này bởi vì HTML chỉ có ưu
điểm trong việc thể hiện dữ liệu hơn là trình bày ý nghĩa dữ liệu đó. XML là một
định dạng cơ bản nhất cho việc trình bày dữ liệu, bởi vì XML có thể được sử
dụng để trình bày ý nghĩa dữ liệu được vận chuyển, và hơn thế nữa, hiện tại đa số
các ứng dụng chạy trên nền Web-Base đều hỗ trợ các bộ phân tích cú pháp XML.
SOAP là công nghệ chủ yếu được sử dụng tại tầng này, nó là một giao thức đóng
gói dữ liệu phổ biến dựa trên nền tảng XML.

Tầng Transport: Tầng Transport có vai trị đảm nhiệm việc vận chuyển các
Web Service Message, tại đây bao gồm một vài dạng công nghệ khác nhau cho
phép các giao tiếp trực tiếp giữa các Application - to - Application dựa trên tầng
Network. Mỗi công nghệ bao gồm các giao thức như tcp, http, smtp và
jabber..v.v.
Việc lựa chọn giao thức vận chuyển được dựa trên mỗi nhu cầu giao tiếp của các
Web Service. ví dụ: với giao thức HTTP là một giao thức vận chuyển khá phổ
biến được sử dụng cho các ứng dụng Web-Base, nhưng nó khơng cung cấp cơ
chế giao tiếp bất đối xứng. Jabber, xét trên phương diện khác, nó khơng phải là
một chuẩn nhưng có khả năng cung cấp tốt các kênh giao tiếp bất đối xứng.

Tầng Network: Tầng Network trong cơng nghệ Web Service chính xác
giống tầng Network trong mơ hình giao thức TCP/IP. Nó cung cấp khả năng giao
tiếp cơ bản, định địa chỉ và định tuyến.


LUAN VAN CHAT LUONG download : add


15

2.3. Các ứng dụng web
Trong kỹ thuật phần mềm, một Ứng dụng web hay webapp là một trình ứng dụng
mà có thể tiếp cận qua web thơng qua mạng như Internet hay intranet.
Ứng dụng web phổ biến nhờ vào sự có mặt vào bất cứ nơi đâu của một chương
trình. Khả năng cập nhật và bảo trì ứng dụng Web mà không phải phân phối và cài đặt
phần mềm trên hàng ngàn máy tính là lý do chính cho sự phổ biến của nó. Ứng dụng
web được dùng để hiện thực Webmail, bán hàng trực tuyến, đấu giá trực tuyến, wiki,
diễn đàn thảo luận, Weblog, MMORPG, Hệ quản trị quan hệ khách hàng và nhiều
chức năng khác.
Sẽ đến ngày các chương trình chạy trên desktop được thay thế bằng những dịch
vụ online đơn giản và miễn phí, cho phép người dùng thực hiện mọi thao tác từ lập
bảng tính, soạn văn bản, lên lịch làm việc, quản lý thông tin...
Tổ hợp công nghệ AJAX giúp các website tương tác với tốc độ sánh ngang mơi
trường desktop. Dữ liệu khơng cịn bị bó hẹp trong một hệ thống điện tốn mà được
truy cập tại bất cứ đâu. Tuy nhiên, giới chuyên môn đánh giá AJAX mới chỉ ở giai
đoạn beta, tức còn phải chỉnh sửa và nâng cấp nhiều trước khi có thể "sốn ngơi"
chương trình desktop.
Chúng ta có thể thấy được xu hướng các ứng dụng thường được phát triển và
được người dùng cũng như những người phát triển chính là Web. Đã có rất nhiều các
ứng dụng Web rất phổ biến và thành công.
Trong lĩnh vực nhật ký làm việc, Google Calendar được đánh giá là một phần
mềm sử dụng rất tiện dụng. Cũng như nhiều chương trình hoạt động trên công nghệ
AJAX khác, công cụ này cho phép người dùng tạo các mục sự kiện nhanh chóng và
thân thiện giống như các ứng dụng trên Desktop. Ví dụ, chúng ta có thể gõ bất cứ nội
dung gì vào ô như "9 giờ sáng ngày 20/02/2010 tiếp khách hàng".

Một chương trình cạnh tranh khác là 30Boxes. Về cơ bản, 30Boxes hoạt động
như một cuốn lịch online, dự báo thời tiết, nhập RSS feed, tạo danh mục cần làm, nhận
thông báo từ LiveJournal, MySpace và Flickr. Hơn nữa, mọi người có thể cài thêm
một vài ứng dụng nhỏ như thanh tìm kiếm Google, Yahoo Mail và cả Google
Calendar. 30Boxes cũng đang phát triển một phiên bản riêng dành cho điện thoại di
động.

LUAN VAN CHAT LUONG download : add


16

Chƣơng 3 - KIỂM THỬ CÁC ỨNG DỤNG WEB
Trong chương này chúng tơi trình bày các phương pháp đã được sử dụng để kiểm
thử các ứng dụng web sử dụng công nghệ .NET. Sau khi giới thiệu một số kỹ thuật
kiểm thử cho các ứng dụng web đơn giản, chúng tôi đi sâu nghiên cứu phương pháp
kiểm thử các dịch vụ (web services).

3.1. Một số vấn đề về kiểm thử các trang web
3.1.1. Giới thiệu
Kiểm thử các ứng dụng web về cơ bản là kiểm thử các Http-request và Httpresponse. Để chạy một ứng dụng web, chúng ta cần gửi một Http-request tới Web
Server. Web Server sẽ tiếp nhận Http-request xử lý và trả lại Http-response. Chúng ta
có thể bắt Http–response và lấy được giá trị theo yêu cầu. Thao tác request-response
thường thực thi cùng nhau, có nghĩa là trong một tình huống kiểm thử Lightweight
Test Automation bạn khơng thể gửi một request mà không nhận response hoặc bạn
nhận được response mà chưa gửi một request nào. Trong phần này tôi sẽ giới thiệu các
kỹ thuật để thực hiện gửi tự động một Http-request và nhận về Http-response và cách
bắt Http-response để lấy giá trị xử lý..
Môi trường .Net Framework cung cấp cho chúng ta 5 phương pháp, trong đó có 3
phương pháp cơ bản và 2 phương pháp cấp thấp để có thể gửi một Http-request và lấy

lại Http-response tương ứng, các phương pháp này lần lượt là [6]:
 WebClient: Sử dụng rất đơn giản nhưng không cho phép gửi thông tin xác
thực.
 WebRequest - WebResponse: Sử dụng một cách linh hoạt, mềm dẻo, đặc
biệt là cho phép gửi thông tin xác thực.
 HttpWebRequest – HttpWebResponse: Cho phép kiểm sốt đầy đủ thơng
tin với nhiều thuộc tính khá phức tạp.
 TcpClient: Là lớp ở cấp thấp có sẵn, nhưng ít dùng trong kiểm thử tự động
(LightWeight Test Automation).
 Socket: Là lớp ở cấp độ rất thấp, rất hiếm khi sử dụng trong Lightweight Test
Automation.

LUAN VAN CHAT LUONG download : add


17
3.1.2. Gửi một HTTP GET Request và nhận HTTP Response
Để gửi một Http-request và nhận lại Http-response, đơn giản nhất là chúng ta
dùng phương thức DownLoadData() trong lớp WebClient mà ta đã giới thiệu ở trên.
Chúng ta thực hiện như sau:
 Tạo đầu vào là đường dẫn Url:
string uri=”http://server/path/webform.aspx”;
 Khởi tạo một đối tượng thuộc WebClient.
WebClient wc = new WebClient();
Console.WriteLine("Gửi một Http-request tới " + uri);
 Dùng phương thức DownLoadData để lấy phản hồi.
byte[] bResponse = wc.DownloadData(uri);
string strResponse = Encoding.ASCII.GetString(bResponse);
Console.WriteLine("Http-response là: ");
Console.WriteLine(strResponse);

Lớp WebClient hữu dụng nhất khi chúng ta kiểm thử với một trang HTML tĩnh
hơn là các ứng dụng Web ASP.NET. Đoạn mã này có thể dùng để kiểm tra các phản
hồi của một ứng dụng ASP.NET nhưng để mở rộng đoạn mã này cho một kiểm thử tự
động chúng ta cần phải kiểm tra các Http-response và so sánh với một giá trị theo
mong đợi nào đó.

3.1.3. Gửi một HTTP-Request và nhận HTTP-Response có quyền xác thực
Muốn gửi một Http-request có quyền xác thực và nhận Http-response, chúng ta
không sử dụng lớp WebClient được mà cần phải tạo một đối tượng WebRequest và
một đối tượng NetworkCredential. Sau đó gán đối tượng NetworkCredential cho các
thuộc tính xác thực của đối tượng WebRequest và nhận Http-response dùng phương
thức WebRequest.GetResponse().
Nếu ứng dụng cần gửi một yêu cầu có sự xác thực quyền trên mạng (UserID,
Domain, Password), chúng ta có thể dùng 2 lớp là WebRequest và WebResponse. Các
lớp này nằm trong namespase System.Web, nó khơng có khả năng truy cập mặc định
bởi ứng dụng console vì vậy chúng ta phải bổ sung file System.Web.dll vào thư viện
của ứng dụng.
Sau khi tạo tạo đối tượng NetworkCredential chúng ta có thể gắn kèm vào đối
tượng WebRequest. Lấy đối tượng WebResponse trả về bằng cách gọi phương thức
WebRequest.GetResponse(). Giống như bất kỳ một Stream phản hồi nào, các stream

LUAN VAN CHAT LUONG download : add


18
có thể phản hồi liên quan tới đối tượng StreamReader vì vậy chúng ta có thể nhận tồn
bộ Http-response như một chuỗi bằng cách dùng phương thức ReadToEnd().
Lớp WebRequest và WebResponse là 2 lớp trừu tượng. Trong điều kiện thực tế,
chúng ta sử dụng WebRequest - WebResponse tương đối đơn giản khi Http-request
yêu cầu có quyền xác thực.

Nếu ứng dụng khơng u cầu quyền xác thực thì lớp WebClient thường là lựa
chọn tốt hơn. Nếu phải gửi một HTTP POST Request thì sử dụng 2 lớp
HttpWebRequest và HttpWebResponse là lựa chọn tốt hơn. Lớp WebRequest và
WebResponse hỗ trợ gọi không đồng bộ, nhưng điều này hiếm khi cần thiết trong
LightWeight Test Automation.

3.1.4. Gửi một HTTP GET Request phức tạp và nhận HTTP Response
Khi muốn gửi một HTTP GET Request và có các thuộc tính điều khiển đầy đủ,
chúng ta phải tạo một đối tượng thuộc lớp HttpWebRequest và nhận về Http-response
bằng cách sử dụng phương thức GetResponse().
Các lớp HttpWebRequest và HttpWebResponse là cách tốt nhất để chúng ta gửi
và nhận dữ liệu HTTP trong các kịch bản LightWeight Test Automation. Nó hỗ trợ rất
nhiều các thuộc tính hữu dụng, 2 lớp này nằm trong namespace System.Net, chúng có
khả năng truy cập mặc định trong ứng dụng Console[6].
Một đối tượng HttpWebResponse được trả lại bởi gọi phương thức
HttpWebResponse.GetResponse(). Chúng ta có thể kết hợp các stream phản hồi với
đối tượng StreamReader và nhận toàn bộ các Http-response bằng cách dùng phương
thức ReadToEnd(). Ngồi ra chúng ta cũng có thể nhận các Http-response theo từng
stream một bằng cách dùng phương thức StreamReader.ReadLine().
Các kỹ thuật này cho phép chúng ta giới hạn các yêu cầu phản hồi và thiết lập
thời gian dừng (Timeout). Dưới đây là một số các thuộc tính hữu dụng của lớp
HttpWebRequest trong LightWeight Test Automation.
 AllowAutoRedirect: Trả về hoặc thiết lập giá trị chỉ ra rằng có hay khơng
u cầu theo sự phản hồi chuyển hướng.
 CookieContainer: Trả về hoặc thiết lập các cookie kêt hợp với yêu cầu.
 Credentials: Cung cấp các thông tin quyền xác thực cùng với yêu cầu.

LUAN VAN CHAT LUONG download : add



×