1. Trang chủ
  2. » Luận Văn - Báo Cáo

Luận văn nghiên cứu kỹ thuật kiểm thử phần mềm và Ứng dụng trên môi trường dot net

82 1 0
Tài liệu được quét OCR, nội dung có thể không chính xác
Tài liệu đã được kiểm tra trùng lặp

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Tiêu đề Nghiên cứu kỹ thuật kiểm thử phần mềm và ứng dụng trên môi trường dot net
Tác giả Vũ Minh Hiếu
Người hướng dẫn PGS.TS. Đặng Văn Đức
Trường học Trường Đại Học Công Nghệ - Đại Học Quốc Gia Hà Nội
Chuyên ngành Công nghệ Thông tin
Thể loại Luận văn thạc sĩ
Năm xuất bản 2009
Thành phố Hà Nội
Định dạng
Số trang 82
Dung lượng 1,45 MB

Các công cụ chuyển đổi và chỉnh sửa cho tài liệu này

Nội dung

phân mềm với một số cấp độ tự động, qua đó những kiểm thử viên có thể giành thời gian để xem xét và giải quyết những vẫn đề thuộc phạm vì có nhiều rủi ro hơn, huy nhiên, tính bự động của

Trang 1

DAT HOC QUOC GIA HÀ NỘI TRƯỜNG DẠI HỌC CÔNG NGHỆ

VŨ MINH HIẾU

NGHIÊN CỨU KỸ THUẬT KIỂM THỦ PHẢN MÈM VÀ ỨNG ĐỤNG

TRÊN MÔI TRƯỜNG DOT NET

Ngành: Công nghệ Thông tin

Trang 2

Lài đầu tiên, tôi xin chân thành cam on PGS.TS Đăng Văn Đức, Viên công nghệ

thông tin, người đã định hưởng để tải nghiên cứu vá tận tình hướng dân cho tôi hoàn thành luận văn cao học này

Tôi xin gửi lời cảm ơn chân thành tới Phòng Đáo tạo sau đại học & NCKH, cáo

thầy cô giáo trong Khoa Công nghệ - Trường Đại Học Công Nghệ - Đại Học Quốc Gia

Hà Nội đã giảng dạy, truyền đạt và tạo diễu kiện học tập tốt nhất cho tôi suốt quả trình

học cao học cứng như thời gian thực hiện lưận văn cao học

Hà Nội, ngày 18 tháng 11 nữ 2009

Vũ Minh Liều

Trang 3

bờ

LỜI CAM ĐOAN

Tôi xin cam đoan kết quả đạt được trong luận văn là sản phẩm của riêng

cả nhân, không sao chép lại cúa người khác Trong toàn bộ nội dung của luận văn, những điều được trình bày hoặc là của cá nhân hoặc được tổng hợp từ nhiều nguồn tài liệu Tât cả các tải liệu tham khảo đều có xuât xứ rõ rằng và được trích dẫn hợp pháp

Tôi xin hoàn toàn chịu trách nhiệm và chủu mọi bình thức kỷ luật theo quy định

cho lời cam doan của mình

Hà Nội, ngày 18 tháng 11 năm 2008

Vũ Minh Liều

Trang 4

MỤC LỤC

BẰNG CÁC TỪ VIẾT TẮT, KÝ LIỆU à seeireieiirrree

THONG TIN HINH VE

THÔNG TIN BẰNG ¬— ¬— ¬—

M6 DAU

Đặt vấn đề c.ccoeoereee ¬— ¬— ¬—

Nội dung của đề tải

Cấu trúc luân văn ¬— ¬— ¬—

CHƯƠNG 1: KHAI QUAT VE KIEM THU’ PHAN MEM

1.1 Tổng quan e: sexy sexy sexy

1.2 Vai trò của kiểm thử phản mềm

1.3 Các công cụ kiểm thứ phổ biển hiện nay sexy sexy

1.4 Những Tợi ích cña kiểm thừ tư động,

4.1 Ap đụng cho mô hình phát

1.42 Đối với các kiếm thử viên

1.5 Phương pháp để kiểm thử tự động sexy sexy

1.6 Kiểm thử phần mềm và các ngôn ngữ lập trình

1.7 Kịch bản kiểm thủ ¬— ¬— ¬—

1.8 Kết chương

CHƯƠNG 2: PHƯƠNG PHAP VÀ CÁC THỦ LOẠI KIẾM TIIU PIIAN MEM

2.1 Tổng quan -: > sexy sexy sexy

2.2 Các phương pháp kiểm thứ sexy sexy sexy

3.21 Kidn thé inh — Static testing

222 Kiém thir déng — Dynamic testing

Trang 5

2.3 Các chiến lược kiểm thử ¬— ¬—

23.1 Kiếm thừhệp đen — Black box testing

2.3.2 Kiểmthửhỏptrắng White boxtesting

2.3.3 Kiểm thử hộp xám - Gray box testing

2.4 Các cấp độ kiểm thứ phần mễm sexy

2.41 Kiém thir mic don vi - Unit Test

2.4.2 Kiểm thứ tích hợp - Integration Test sexy

243 Kiém thir mic hé théng - System testing

2.4.4 Kiểm thứ chấp nhận sản phim - Acceptance Test

24.5 — Kiểm thữhỏi quy - Regression Tost

2.4.6 Kiểm thứ tỉnh đứng — Correctness testing:

2.5 Các phương pháp kiểm thử con người

2.5.1 Tổng duyệt Walktrough sexy

2.5.2 Thanh tama nguén — Code Inspection

2,6 Kat HOR cess sstessessstesenenee ¬— ¬—

CHƯƠNG 3: NGHTEN CUU XAY DUNG CONG CU KIRM THU PHAN MRM TỰ

ĐỘNG TRÊN MỖI TRƯỜNG NET "—

3.2.4 Không gian tên NƯTI CodeDom ¬—

3.3 Phân tích và thiết kế hệ thông

3.3.1 Mê hình nghiệp vụ và các yêu cầu của hệ thông

3.3.2 Phân tích cúc trường hợp sử dựng HHu re

Trang 6

= Tara chon hình thức kiếm thử đơn vị (Unit Test)

" Lựa chọn các đơn vị trong danh sách để kiểm thứ

"File chứa đữ hện kiểm thử

Trang 7

BANG CAC TU VIET TAT, KY HIEU

Assembly Trong môi trường “Net, Một gói kết

hợp Assembly là sự kết hợp cửa mộL

hoặc nhiều module, hoặc file (dll, exe,

“m]) cần để ứng đựng hoạt động CRU Coumen Languape Runtune | Ngôn ngữ thời gian thực

DLL Dynamic Link Library “hư viện liên kết động,

OpenVMS, Microsall Windows, Symbian, va hé diéu hành GS/2

TDE Tntergrated Development 'Môi butmg phal tién lich hop

GUI Graphical user interface Giao điện người dùng đỗ họa

Environment

thực thí, Mỗi moddle có thể là một thư

viện động ( dÍD hoặc là một Ble thực

Trang 8

Công cụ kiểm thử phân mềm do hãng

Mecury cung cân

Mây do Java

Trang 9

Hinh 1.2: Giao dién Quickest Professional 18

Hình 1.4: 6 bước của kiểm thử phản mềm tự đồng, 27 Hình 2.1: Mối tương quan giữa phát triển và kiểm thứ phần mém 3g Hình 3.1 Mö hình quả trình xử lý tách thông tin 49 Hình 3.3: Mỏ hinh xử lý sinh kịch bản kiểm thứ 4g

Hình 3.5 Trường hợp sử dụng của công cụ Unit Test 6

Trang 10

Bảng Trang

Bang 3.2: Mã nguồn để kiểm thử phương thúc objAdvancedCale.Square(} 55

Bang 3.3: Ma nguồn kiểm thứ phương thie objAdvancedCale.SimpleCale() 55

Bang 3.4: Ma nguén kiểm thử phương thức objAdvancedCale Sum() $6

Bang 3.5: Mã nguồn kiểm thử phương thức objAdvanoeđCale GetTypeQ s;

Bang 3.6: Mat sé lép (class) quan trọng trong không gian tên 38

System Reflection

Bang 3.7: Truy van thé loai System Reflection Assembly theo tén 60

Bang 3.8: Truy van théug lin thé loai theo thé hién ofia déi tuong 60 Bang 3.9: Xác định thông tín thể loại của một tiễn trình đang chạy @

Bang 3.11: Cac kiéu cung cap béi CodeDom để xây đựng không gian lên 64 Bảng 3.12: Cấu tric cia Test Script duge sinh bởi khéng giantén Codeom 65

Trang 11

nghệ thông tin được coi là một cuộc cách mạng cho sự phát triển của xã hội loài người

Kế từ năm 1981 khi chiếc máy vi tỉnh đầu tiên của HẦM được giới thiệu trên thị trường,

đánh dâu một mỗe quan trọng cho sự tiền bộ của khoa học kỹ thuật Cho tới thời điểm

tiện lại, trải qua một khoảng thời gian rất ngắn so với chiều dài lịch sử của xã hội loài người, tuy nhiên công nghệ thông tin đã phát triển rất nhanh (còn được diễn tả bằng

cum từ: “bừng nỗ”) Công nghệ thông tin đã được ứng đựng trong hâu hết các lĩnh vực

của xã hội, và thực tế đã chứng minh được lầm quan lrợng của tỏ

Trong lại thập kỹ qua phần mềm đã trở thành một thành phần của hầu hết các doanh nghiệp Hẳu như tắt cả các doanh nghiệp hoạt động trong mọi lĩnh vực tại Việt Nam cing như trên toan Thế GHói đều sử dụng phần mềm Phân mềm được áp dụng,

và viễn thông - nhằm tổ chức khai thác và sử đụng có hiệu quả các nguồn tải nguyên thông Gin rit phong phú và tiềm nẵng trong mọi lĩnh vực hoạt đông cũa con người và

xã hội”

Công nghệ thông tm là sự kết hợp của hạ ting phần cứng vả nên táng phần mém

Hạ tầng phần cứng sẽ ngày càng mạnh mẽ là tiển để cho phép phần mềm cũng ngày

Trang 12

cảng lớn và phức tạp hơn Chính vị lý do này mả Công nghệ phan mém (quy trình phát triển phần mềm) đã được chủ tâm bản thảo tử rất sớm nhằm tim ra những phương pháp

để phát triển phản mềm thuận tiện gó chất lượng cao đáp ứng tốt nhu cần ngày cảng đa dang và phức tạp

Hau hết các quy trình phát triển phần mềm đều trái qua các bước từ xác định yêu câu, phân tích, xây đụng, kiểm thủ, cho tới triển khai và bảo trì Trong đó kiểm thử phần mềm la một công việc khá phúc tạp, tồn nhiều công sức và cũng là điều kiện tiên quyết cho một sản phẩm phản mềm có chất lượng tết

Bat ky san phim phan mém nao cho đù đã áp đụng kỹ thuật kiểm thủ tiên tiễn nhật hiện nay đêu có phát sinh lỗi Một số lỗi đã được phát hiện va chỉnh sửa trong thời gian lập Irinh Một số khác dược tìm ra và chỉnh sửa trong các hhưất thức kiểm thử

(vd: kiểm thử module) Các doanh nghiệp phần mềm đều nhận ra một thực tế là có

nhiều lỗi phần mềm vẫn chưa được phát hiện và một số sẽ được sửa san đó thông qua những bản vá lỗi hoặc nâng cấp Kiểm thử là điều kiện tiên quyết cho một phần mém hoàn thiện, tuy nhiễn với kỹ thuật kiểm thứ hiện nay việc đắm bảo cho một phân mềm hoàn hão (không có lỗi) là một việc rất khó khăn, tốu thời gian, và lưỡng chừng như không thể Theo thống kê cũa Tassey năm 2002, thi lỗi trong những phân mềm dòng, gói gây thiệt hại cho nên linh tế Mỹ khoảng 59,5 t USD [9]

Kiểm thủ chiêm thoảng 25% tới 50% tổng chỉ phí phát triển một phân mềm Bộ

phân kiểm thử thường gồm các kỹ sư với vai trô là kiểm thờ viên, người sử đụng công

cụ, vả những người phát triển công cụ kiểm thứ Ngân sách và cơn người đều đồng vai

trò quan trong vi một sẵn phẩm trong quá trình xảy đựng phải được kiểm thử một cách

tốt nhất và hiệu quả nhất

Vào năm 2008, tổng đoanh thủ của phần mdm Việt Nam đạt trên S00 triệu USD

(tống doanh thu trên toản thể giới vào khoảng Sl9 tỷ USD - theo

tup:/Sollwaremag.com) Số lượng các kỹ sư và lập Irình viên tại Việt Nam năm 2008 vào khoảng 13.500 người Những con sd trên dựa trên tổng kết của Hiệp hội Doanh nghiệp phân mềm Việt Nam (vinasa: http://www.vinasa.org.vn) Gidm chi phi phat

Trang 13

phân mềm với một số cấp độ tự động, qua đó những kiểm thử viên có thể giành thời

gian để xem xét và giải quyết những vẫn đề thuộc phạm vì có nhiều rủi ro hơn, huy nhiên, tính bự động của các công cụ mới chỉ đứng ở các kỹ thuật đơn gián và những,

kich bản kiểm thử baa gồm chuỗi sự kiện nhẫn chuột hoặc bản phím Kiểm thử viên

mong đợi các công cụ kiểm Thứ hiệu quả và lính hoạt hơn với các tính năng tự động, cao đề có thể theo kịp sự phát triển rất nhanh trong céng nghệ phần mềm hiện nay

Mục tiêu của Luận văn là nghiên cửu kỹ thuật phát triển một công cụ kiếm thử tự

động, có thể kiểm thử một sân phẩm phân mềm phức tạp một cách hiệu quả với yêu

cau tac déng của con người lả it nhất

Nội dung của để tài

Xuất phát từ việc phân tích và mục tiểu nêu trên, nội dung của đẻ tài luận vẫn sẽ bao gồm những vẫn đẻ chỉnh sau:

-_ Nghiên cúu, tìm hiểu các vẫn đề tổng quan vẻ kiểm thủ phản mềm

~ Nghiên cứu kiến trúc và các thể loại kiểm thử phần mềm

- _ Nghiên cứu xây dựng công cụ kiểm thử phẩn mềm tự động trên môi trường Dot Net và thử nghiệm

Cấu trúc luận văn

Luận văn sẽ được chia thành 3 chương chính dựa vào nội đung néu trên:

-_ Chương I: Khải quát về kiểm thở phần mềm

~ Ghương 3: Phương pháp và các thể loại kiểm thừ phần mễnu

-_ Chương 3: Nghiên cửu xảy dựng công cụ kiểm thứ phần mềm tự động trên môi trường NET

Trang 14

CHƯƠNG 1: KHAI QUAT VE KIEM THU PHAN MEM

11 Tông quan

Kiểm thữ phản mềm là một trong những khâu quan trọng của quy trình phát triển phần mềm nhằm kiểm tra xem phần mém làm ra cỏ những lối gì cần khắc phục Kiểm

thử không thé chimg minh được phần mềm là hết lỗi mà nó chỉ giứp cho người viết mã

Trguỗn tầm ra và có biện pháp khắc phục càng nhiều lỗi cảng tốt

Bản chất của kiểm thứ phần miền là cóc cách thức làm việc voi may tink và chương trinh, tuy nhiền với những phẩn mêm lớn, việc kiểm thử cũng yêu cầu có sự phổi hợp của nhiễu nhóm chuyên mỗn phụ trách các thành phân riêng biệt, cho nên kiểm thử cũng cần các kĩ năng của con người

Đổ thực hiện tốt công việc kiểm thử, ngoài nắm vững các kĩ thuật kiểm thử điển hình, kiểm thứ viên cững cần xây dựng kế hoạch kiểm thử, chuẩn bị đữ liệa kiểm thú, tiến hành kiểm thử, viết báo cáo về kết quả kiểm thử, và cần biết quần lí loàn bộ công,

việc kiểm thử,

Kiểm thử cần được nhìn theo nhiền góc độ khác nhau liên quan tới phần nêm:

kiểm thử chức năng kiếm thử hiệu năng, cầu hình, an ninh và liên quan tới qui trình

kiểm thử: kiểm thứ đơn vị, kiểm thử tích hợp, kiểm thử hệ thông, kiểm thử chấp nhận,

đồng thởi phải thực hiện quán li toán bộ quả trình kiểm thứ: ghi lại hoàn cảnh lỗi, việc

sửa chữa, kiếm thử rà lai

1⁄2 Vai trò của kiếm thử phần mềm

Các lãi trong phản mêm không chỉ làm phiển phức và bực mình cho người đùng

mà chúng còn gây tên thái rất lớn cho nền kinh tế Đém cử hàng năm tiên kinh tế Mỹ thiệt hại khoảng 59,5 tỷ LISD do lỗi phản mắm gây ra (thông số được công bố bởi Viện Công nghệ và Tiêu chuẩn quốc gia (NIST) thuộc Bộ Thương mại Mỹ)

Theo Giám đốc Arden Bemenl của NTST, hiện nay mợi ngành ở Mỹ gần như đều phụ thuộc vào phẩn mềm dễ phát triển, từ khâu sản xuất đến khâu phân phỏi vả hỗ trợ khách hàng Hỏi thẻ, các lỗi kỹ thuật phần mềm là vô cùng nguy hiểm

Trang 15

Theo các số liệu của tạp chí SoftwareMag (softwaremag.com) nim 2007 tổng doanh thu của CNPM trên toàn Thế Giới là 451.8 tỷ USD va ting 14.7% so với năm

2006 Bên cạnh sự phát triển mạnh mẽ của nghành công nghiệp phần mỗi thì những,

lỗi — khiểm khuyết của phân mềm cững xảy ra ngày cảng thường xuyên, dẫn tới những

tổn thái đlo nỗ gây ra cũng ngày cảng răng nễ hơn Dưới đây là một vài ví dụ điển hình

vẻ sự tổn thất do

Một trong những lỗi phần mềm diễn hình về nức độ thiệt hại là vào tháng 4 năm

1999, một lỗi phản mềm đã gâ

thiệt hại 1.2 tỉ USD Đây có Ì

ty ra lỗi hệ thống phóng tên lửa Quân sự của Mỹ làm

là một lỗi phần mềm gây thiệt hại kinh tế lớn nhất ong, lịch sử công nghiệp phản mắm Chính điều nảy đã thủc đầy một cuộc tổng điều tra

trong ngành quân sự vả nên công nghiệp của Mỹ về vấn đẻ tích hợp phần mềm và quy

tới là trả nạn khi phỏng Vệ

việc là do trục trặc trong một bộ phận của phản mềm ở chức năng chuyến đổi chuẩn

độ do của Anh sang chuẩn độ do mới Năm 2002, người ta dã phát tién mét module

đành cho việc kiểm thử dựng eụ Quang học nhằm đâm bảo không có việc lẫn lộn giữa

các phép đo Nếu Vệ tính thăm dé thoi tiết của Sao Hỏa được trang bị muodnte nay thi

đã không xây ma tai nạn dáng tiếc trên dây,

Dam bao chất lượng phần mềm cần dược quan tâm một cách dùng mức, và doi hỏi những người liên quan có kiến thức và đánh giá đứng về vai trò của kiểm thử phần 1nêm, gồm: các quản trị viên cao cấp, quản lý dự án, nhân viên phát triển phần mỗm,

Trang 16

nhân viên kiểm thử phần mêm và người ding cuối Khi bắt dầu một dx an dựa theo các mô hình phát triển phản mễm, những người dùng cuối, lập trinh viên, kiểm thứ

vith

4 quan tri vién cao cap đều phải năm được yêu cầu phân mềm, các đặc tâ phân

mém vá các chiến lược kiểm thứ

'Trong hằu hết các mô hinh phát triển phẩn mềm thì kiểm thứ được lên kế hoạch

ngay từ thời điểm bắt đâu dụ án và được thực thi song song với vòng đời phát triển của

phan mềm Chúng ta sẽ không thể kiểm thử một sản phẩm nếu không có hiểu biết chú tiết về nỏ, Kiểm thử một sản phẩm đang trong giai đoạn được xây dựng sẽ luôn là một

trải nghiệm bố ích cho các kiểm thử viên Thời gian và nỗ lực của kiếm thử viên phụ

thuộc vào độ phức lạp của một sẵn phẩm cũng như kinh nghiệm của anh la trong lĩnh vực kiểm thủ phản mềm

Sẽ rất hữu ích nêu ta sử dụng các cổng cụ kiểm thử tự động, điều này sẽ hạn chế

bớt việc các kiểm thử viên phải giành quả nhiều thời giai cho công việc nghiên cửu một sản phẩm mới Qua đó họ cỏ thể giảnh thời gian nhiều hơn tập trung cho những, vấn đề, những yếu tế phức tạp và rủi ra cao trong khi vận hành phần mềm

Kiểm thử phản mềm là một tiên trình thử thách, trải nghiệm một ứng dung dé tim

lỗi và đảm bảo cho chất hượng của sản phẩm Các sản phẩm phần mềm đã được

chuyển giao sẽ phải bao hàm tất cả các chúc năng được yêu cầu và phải tương thích với hạ tầng phần cửng của khách hảng

Trong một thời gian dài, kiểm thử phần mẻm đã được thực biện một cách thủ công, có nghĩa là những kiếm thứ viên chạy ứng đựng dựa trên những tiên trình đã được định sẵn Kể từ thời điểm ban đâu của nên công nghuệp phân tuêm, các kiểm thử

viên đã tạo ra những tiền trình kiếm thử tự động khá hiệu quả Nhiéu công ty phản

mềm đanh tiếng đã tạo ra những công cụ kiêm thi: phan mém ma hién nay dang được chao bán rộng rãi trên thị trường Ngày nay, só nhiều công cụ kiểm thử trên thị trường,

đã được dùng dé tim ra lỗi để cỏ biện pháp chính sửa kịp thời trước khi chuyển giao Nhu đã để cập ở lrên, những uồng cụ này thực hi một số tác vụ môi cách lự đồng

Trang 17

16

(thực hiện một vài kể hoạch và sinh ra kịch bản kiểm thở), tuy nhiên nó vẫn tổn tại

một số khuyết điểm sau:

«- Các kịch bản kiểm thử, tự thân chứng cũng cẩn được kiểm thử

ø- Không thẻ thục hiện tất cả các liền trình kiểm thử một œ

ch độc lập

ø Ching thực thi các tiến trình có thẻ khẳng thống nhất hoàn toàn với thiết

kể phẩm mềm của tổ chức

®- Mội vải tiến trình được phân tách từ việc tự sinh kịch bản kiểm thử

Trong hảu hết các trưởng hợp, tạo lập hoặc ghi lại một kịch bản kiếm thử cho mỗi thành phân của một assembly là một công việc phức tạp mà các kiểm thử viên

phải thực hiện Tạo và lập tài liện cho đữ liệu kiếm thử với các công cụ hiện tại déu

hoàn toàn sử dụng sức người Do vậy, khả năng tự động của những công cụ kiểm thử

sẽ bị hạn chê

Nội dung của luận văn là nghiên cứu để phát triển một công cụ kiểm thử phần mém sao cho kiếm thử viên không cân viết các kịch bản kiếm thử bằng tay hoặc phải giủ lại các kịch bân kiểm thử một cách thủ công, Tiên trình kiểm thử phần mỗm sẽ

được thực thi với yêu cầu tương tác trục tiếp từ con người là ít nhật Công cụ được

thiết kế để giảm bớt và sát với yêu cầu của hầu hết các sân phẩm phân nếm Đồng thời dây cũng là cách thức dé tac ra cae module có thẻ sử dụng lại để kiểm thử nhiều mã nguồn khác nhau

1.3 Các công cụ kiểm thủ nhỗ biến hiện nay

Trén thi trường hiện nay có nhiều công cụ kiểm thủ phản mềm Với các nhà cung cap như: Rational Software ciia IBM, Mercury Interactives, Segue Software Hiện có nhiều nhả cung cấp khác vả củng có một số công cụ kiểm tht nguén mé nhy Ant,

JUnit, va JProbe Sau đây là một

công cụ kiểm thử phần mềm được sử dụng phổ

biến hiện nay:

* Visual Studio Team System Test Fdilion

Trang 18

Visual Studio Team System Test Edition bao gồm một bộ công cụ thử nghiệm đã

được tích hợp chặt chế với Visual Studio Nó không chỉ làm việc trong khuôn khổ của

nên tảng kiêm thử, mả cỏn tham gia vào một nên tảng lớn hơn tham gia vào các khâu

khác trong toản bộ vòng đời của phân mềm

Test Edition cho phép ta tạo, quản lý, chỉnh sửa và chay công việc kiểm thử, đồng thời cũng nhận được và lưu trữ kết quả kiểm thử Visual Studio tích hợp một vài loại thử nghiệm bao gồm: kiểm thử đơn vị (Unit Test), kiểm thử web (Web Test), kiểm

thử chịu tải (Load Test), và các kiểm thử thủ công

Thực hiện kiểm thử bằng cách sử dụng môi trường phát triên tích hợp của Visual Studio (DE Visual Studio) Ngoải ra, cỏ thể chạy các nhỏm thử nghiệm hoặc kiểm tra bất kỷ đơn vị thử nghiệm độc lập nảo khác bằng cách sử dụng dòng lệnh (command line)

Do các công cụ thử nghiệm được tích hợp với các thành phân khác của Visual

Studio Team System, nên kiểm thử viên có thê lưu trữ kết quả vảo cơ sở dữ liệu, tạo ra

các hình thức bảo cáo khác nhau, so sảnh các loại dữ liệu, và xem có bao nhiêu lỗi, là

những lỗi nào đã được tìm thấy bởi công cụ kiểm thử

Đây quả là một công cụ mạnh mẽ mà Microsoft trang bị cho bộ sản phẩm Visual

Studio của mình Với lợi thể là tích hợp chặt chế vào môi trường phát triển phần mềm,

công cụ sẽ giảm bớt được nhiêu công sức trong quá trình thực hiện các thao tác kiểm

Trang 19

18

thử, đồng thời việc quản lý nó cũng thông nhất trong suốt quá trình phát triển phản mềm Tuy nhiên để sở hữu được bộ công cụ nảy thì chủng ta cũng phải bỏ ra một khoản chỉ phí khả lớn, vào khoảng 5.200 USD Đồng thởi chúng ta cũng phải trang bị

nên tảng Visual Studio Team System 2008 Team Foundation Server (mức giả tham

Khao: 2.500 USD) dé cé the tich hop bộ công cụ này

Khu we Test (Fest pane) — „

‘Wag ig (Dota Table) y

to QuickTest Professional 8.2

na

Hinh 1.2: Giao dién QuickTest Professional QuickTest Professional (QTP) véi phién ban méi nhất 9.5 của hãng Mercury khá

tốt và mạnh, bao gồm nhiêu chức năng điện hình của một công cụ kiểm thử tự động,

QTP la céng cu ding dé kiem tra chite ning (functional test) va 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 tạo kịch bản kiểm thử (lập trình trong

kiểm thử tự động) hiện đại, cho phép kiểm thử 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ứ kịch bản nào 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 kịch bản vẫn có thẻ thực hiện được

QTP giúp chúng ta kiểm thử 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

Trang 20

chương trình thông dụng như: Ung dung Windows, Ung dung web theo ehuan HTML, XML; Ngôn ngữ lập trinh Cỡ, VI NUT

Một số loại chương trình khác yêu cầu 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, như NET Framework 1.1, 2.0, 3.5; Các đối lượng,

chuẩn của NHT và các đối tượng khác thừa kế tử các đối tượng, chuẩn; Java; Sun JIDK,

-_ TP có khả năng hiểu kịch bàn kiểm thử của Mercvy Winrunner (một công cụ kiểm tra khác của Mercury)

Nhược điễm:

- Chưa hỗ trợ tết trên nhiều nên tăng công nghệ khác nhau

- Gia thành khá cae: cho một máy 9.000 USD: cho nhiều máy đừng cùng lúc 12.000 USD

= JMeter

Trang 21

20

Hình 1.3: Logo JMeter

JMeter ctia Apache Jakarta la công cụ được phat triển bởi ngôn ngữ lava cho

phép kiểm tra máy chủ Web và thêm vào đó là khả năng kiểm tra các mg dụng với các

giao thức khách như TDBC, FTP, va LDAP Thue té, với công cụ mở rộng và cho phép người dùng tạo ra các tình huồng giả định thi người dùng có khả năng kiểm tra bắt kỳ giao thức nào thông qua Java Với chế độ mặc định nó có thẻ đưa ra nhimg file CSV

đề dễ dàng truyền các tham số vào cơ sở đữ liệu và đưa ra được rắt nhiều thông tin hơn

CSV Đây là công cụ được rất nhiều người mới vào nghẻ sử dụng trong vô số các công,

cụ khác đang cỏ trên mạng Internet

= JUnit, NUnit

JUnit la mét framework don gidn ding cho viée tao các Unit Testing tự động, và chạy các tác vụ kiểm thử có thể lặp đi lặp lại Nó là một phản của họ kiến trúc xUnit

cho viée tao cac unit testing, TUnit là một chuẩn trên thực tế cho umit testing trong

Java JUnit về nguồn góc được viết bởi 2 tác giả Erich Gamuna và Kent Beck Tương,

tự, NUnit là phiên bản dùng cho các sản phẩm phát triển trên nền tảng NET, nỏ có thể

tích hợp với Microsoft Visual Studio

Đây là một bộ công cụ giảnh cho Unit Test rất hiệu quả và hoản toàn miễn phí Tuy nhiên công cụ mới dừng ở việc kiểm thử thành phan, chưa mở rộng thêm các hình

thức kiểm thử khác

»_ Một số công cụ kiểm thử phổ biến khác

Công cụ kiểm thứ thành phan (component hod unit test):

- QACenter - Compuware

- PurifyPlus - BM Rational

- Tau Architect va Tau Developer - Telelogic

- C+ Test, Java Test, Insure++, va Test - Parasoft

Trang 22

Céng cu kiém thit chitc néing (function test):

- WinRunner - Mercury Interactive

- Quickest Professional - Mercury Interactive

- Astra QuickTest Mercury Interactive

- QACenter - Compuware

- SilkTest - Segue Sofhvare

- Rational Suite TestStudia - JBM Rational

- TauTester - Telelogic

= e-Tesl suile - Empiric

- Webking - Parasoft

- WetfT - RadView Software

Công cụ kiểm thủ: chịu tải (perƒforimance/laad-tesl:

- LoadKumner - Mercury Interactive

- Astra LoadTest - Mercury Interactive

= QACenter - Comproware

- WebLoad - RadView Software

- Rational Suite TestStudio - /BM Rational

- SilkPerformer - Segue

- e-Test suite - Limpirix

- webking - Parasoft

- Test Perspective - Keynote Systems

- LoadPro - Keynote Systems

Cũng cụ theo dõi thực thi (performance-monitoring):

- Vantage - Compuware

- Topaz - Mercury Interactive

- OneSight - Empire:

Trang 23

-_ FarSight- Empirkr

- Rational Suite TestStadio - /BA4 NafianaL

Céng cu quan ly kiém thie (test-management):

- QA Director - Compuware

~_ TesIDireclor - Mereury Interactive

- Rational Suile TestStudio - JBM Rational

- SilkPlan Pro - Segue

Vi tu cach la một người làm việc trực tiếp trong lĩnh vực sắn xuất phần mềm và

là người nghiên cứu Luận văn này, tôi đã đánh giá cao những khả năng tuyệt vời của các công cụ kiểm thi hiện cỏ, mặc đủ tỉnh lự dộng và hiệu quả của chúng chưa được như mong muôn Những hạn chế trong các công cụ được thương mại hóa gặp phái là

thường không theo kịp với các thay đối của công nghệ và khó thích ứng với quá trình

thiết kế mới trong các ngảnh công nghiệp phẩn ruẩm Trong hiện vẫn tảy, tôi sẽ nghiên cửu đẻ xuất nâng cấp các cơ sở hạ tầng kiểm thứ để tránh được những hạn chế

nay,

1.4 Những lợi ích của kiểm thử tụ động

Người ta mong đợi gi ở một công cụ tự động kiếm thử phần mém? Đó là tiết kiệm thời gian cũng như cỉn phí, các chuẩn số dược tuân theo một oách nghiêm ngặt,

và tắt nhiên chất lương phần mềm sẽ được nâng cao

Kiếm thủ phần mẻm vẫn luôn giữ một vai trỏ quan trọng trong ngành công nghiép phần mềm Thường bao hàm việc đào tạo các kiểm thử viên và yêu câu họ học những kỹ thuật kiểm thử trước khi một dự án được bắt dầu Củng với khả năng cing như kinh nghiệm của đội ngũ kiểm thử tăng nên thì tính tự động trong công việc cũng được nâng cao Khi kiếm thứ một sản phẩm hoàn toàn mới cfing chính là một quá trình trau déi kinh nghiệm cho mỗi kiểm thử viên Những hiểu biết sâu sắc về dự án sẽ giúp cho tính tự động trong công việc của họ tăng lên

Về mặt kỳ thuật, rất nhiên tác vụ kiếm thử có thé duoc thục hiện một cách tự

động Tuy nhiên, quản lý khã năng tự động hỏa của các lắc vụ kiểm thử cũng được coi iB tuy ay! y 5 t6 iB

Trang 24

như các vẫn dễ về mặt kỹ thuật và cân được nghiên cứu kỹ càng Quá trình phân tích cần xác định rõ các thông tim sau:

œ- Ngày may các dự án phần mềm thường rỗi phức tap và được giảnh để giải quyết các vấn để phức tạp Các công cụ kiêm thử phần mềm thương mại thường cân nhiều thời gian để tìm hiểu về một vấn để riêng biệt và đề theo kịp công nghệ ĐỂ đáp ứng dược khung lời gian bạn chế của một dự án,

các kiểm thử viên cũng cần tự phát triển một công cự kiểm thứ cho riêng,

mình để có thế bổ sung khiếm khuyết cho các công cụ kiểm thử thương mại trên thị trường

«- Đôi khi các kiểm thử viên cân xác định hoặc là kết hợp kiểm thử tự động, vào những dự án đang thực hiện hoặc sẽ kết hợp vào dự án hoán toàn mới

Buớc đâu tiên của các tiên trinh kiếm thử sẽ luôn liên quan tới kiểm thử

bằng lay Các kiểm thứ viên sử đựng chúng như là một cách để nghiên cứu

m trình phân mẻm Giống như các tiên trình phản mềm, các kiểm thử

vi

viên trở nên hiểu biết sâu sắc hơn về sản phẩm và các vẫn để tiểm tảng mà

họ có thể dự đoán trước Các công cụ kiểm thử tự động sau đỏ có thể được

bỗ sung vào để làm việc với từng vẫn đẻ cụ thể, œ_ Các tổ chức đã phát triển một mô hình phát triển phần mém mang tén “lap

trình cực đoan” (xtreme Programming - XP) cho những dự án có rủi ro

cao trong do yêu cầu phân mềm không thống nhật Họ không làm rõ được chỉ tiết các yêu cầu ngay từ đầu Thay vào đỏ mã nguồn của họ có thể

hoàn toàn được chỉnh sửa hoặc cập nhật thường xuyên Các kịch bản kiếm

thủ là một phần của nã nguồn điều khiến cùng với mã nguồn của chương, trình, Trên thục tế, kiểm thử tự dộng khỏ có thể áp dụng cho mô hình XP

đo những kịch bản kiếm thử có thế được chỉnh sa và trả về với mỗi quá trình phát triển tích hợp

ø Hiểm khi một tổ chúc có thế khỏng chú ý tỏi những cêng cụ kiểm thử tự

động, Đề quản lý chất lượng, việc phát triển một công cụ kiểm thứ tự động,

là một bước thúc đây cho việc phát triển đự án

Vòng đời của một mô hình phát triển phân mềm cũng tác động tới việc mở rộng

các tiến trình kiểm thử tự động;

Trang 25

œ_ Củng với tiến bộ của công nghệ, việc lập trinh cũng trở lên dễ dàng hơn

Vòng đời phát triển phần mềm cũng ngắn hơn đồng nghĩa với việc cho

phép it thời gian hơn dễ kiểm thử Một công cụ kiểm thứ tự dộng sẽ làm nhẹ bớt áp lực cho các kiểm thử viên để họ có nhiều thời gian hơn cho

việc nhận điện những vùng, rủi ro cao của đự án

1.4.1 Áp đụng cho mô hình phát triển phần mềm XP

Kent Beck tạo ra mô hỉnh XP trong cuôn sách của ông mang tén Extreme

Programming Explained: Embrace Change (Addison-Wesley 1999), Theo dinh nghia

XP là một kỹ thuật nhẹ nhàng tập trung cho việc lập trình những du án phần mềm có

được yêu cầu của một sản phẩm Cáo lập trinh viên không phải là thây bói và cũng.

Trang 26

không cần xác dinh tất cả các yêu câu trước khi thực hiển công việc lặp trình 3ẽ hiệu qua hơn nếu cưng cấp cho khách hàng những sản phẩm đơn giản ngay khi có thể Sau

đó khách hàng có thề

ủ dụng thử sản phẩm và thêm heặc thay đổi yêu câu của họ Sau củng lập trình viên sẽ nhận dược sản phẩm suỗi cùng thông qua việc xem xét lại mã nguên, tụ động kiểm thủ, và tiếp tục tích hợp vào sản phẩm

Tự động kiếm thử là một yếu tổ chủ đạo tạo nên thành công của mồ hình XP

Cần kiểm thứ khi một đông mã lệnh mới được thêm vào và khi một phương thức hoặc một dòng mã lệnh được thay đổi hoặc bị xóa Mã lệnh thường thay đổi và tiên hóa liên

tục, và đôi khi lập trinh viên không nhận thức hết được những thay đổi sẽ điển tiền ra

sao Chi có dựa vào dấy tiến trình kiểm thử thì lập trình viên mới nhận ra được thay đổi của mã lệnh đã được xác thực, hay phê chuẩn

Củng với việc thay đổi các yêu câu, mô tả, và mã lệnh, kiểm thử cần được tự

ếi mã lệnh

động để gin chủ lại những thay đổi phá vỡ hệ thống Không giống việc

trong những mê hình khác, với mô hình XP thì mã lệnh có trang thái lỏng hơn Có thể được thiết kể lại, xóa, và tự hoàn thành Sau củng kiểm thử sẽ đầm bảo cho hệ thông, vẫn hoạt động Mô hình XP cần một kiểm thử lắp đi lặp lại cho những lớp giao điện (interface) ciia lop (class) va thanh phan (component) Sự thực thị cúa hệ thống dược thay đổi khi những kiểm thử tự động phê chuẩn hệ thống vẫn đáp ứng được giao kèo của các inlerface Chỉ san khi một chức rừng mới hoặc một hức năng dược thay dấi

đã được phê chuẩn bởi kiểm thứ thì nó mới được tích hợp vào hệ thông, Mọi thứ có

thể gây đỗ võ phải được kiếm thử trước Công cụ kiếm thử tự động được nghiên cứu

thử nghiệm trong T.uận văn này sẽ giúp tự động hóa quá trình kiểm thử oũa mô linh

XE

1.4.2 Đối với các kiểm thứ viên

Luan văn tập trung vào việc nghiên cứu đề phát triển một công, cụ đẻ tự dộng, kiếm thử phẩn mêm Sư thí hành kết hợp với quan điểm của kiếm thử viên với mục tiêu “kiểm thử dé tim ra lỗi” Với một công cụ kiểm thử tự động có thể sử dụng một sắn phẩm từ phổi cảnh của người dùng cuối, có yêu câu về chất lượng, và tí mỉ tới mức clñ tiết Nó là một công cụ hữu ích cho cả người dimg có hiểu biết về kỹ thuật cũng,

kỹ thuật Khiểu khi một kiểm thử viên cũng dược coi như

như chưa có hiểu biết

Trang 27

Ngày nay, thường thì những kiểm thử viên và lập trình viên làm việc chặt chẽ với nhau lrong một đự án Một công cụ kiểu thử phần mềm không có đủ khả năng để giải quyết tất cá các vẫn đề có thể xây ra Di với quản trị viên của dự án sẽ thực sự hữu

ích nên đưa vào sử đựng cả kiểm thử thủ công vả kiểm thử tự động trong củng một dự

án phân mềm

Với việc giao tiếp hiệu quả công việc kiểm thử tự động và thủ công sé bd sung

cho nhau và tầng năng lực của nhau Thực tế một quản trị viên có thế muôn cö các

thành viên trong đội gồm những người đã có nhiều kinh nghiệm trơng cả kỹ thuật kiểm thử thủ công và kỹ thuật tự động Một sản phẩm chát lượng được lợi từ dội kiểm thử với những thánh viên có những kinh nghiệm kiểm thứ khác nhau Vd, một số có thể có kinh nghiêm với những công cụ trên trường, một số có thể kiểm thử thủ công những vủng dúi do cao của một sản phẩm, trong khi số khác có thể có kinh nghiệm trong việc sử đụng C#, VEB, C/C+-+, Java, hoặc những ngôn ngữ lập trình khác,

1.5 Phương pháp để kiểm thứ tự động

Ngành công nghiệp phần mềm đã làm được rất nhiều việc lớn trong kiểm thử phan mém Nhiều cuỗn sách đã trình bày cách để xây dựng các kế hoạch kiếm thử và

các chính sách kiểm thứ và cách quản lý kiểm thứ tự động một phản mềm với các công,

cụ hiện có trên thị trường Các kỹ sư phân mềm đã tích lũy được rất nhiều hiển biết, và

các tổ chức phần mềm đã giúp đỡ những nôn kiểm thử của họ trong việc theo dõi

những tải liệu nảy

Những ngôn ngữ lập trinh bậc cao như Java, C#, và VH.NHT là những ngôn ngữ

tướng đổi lượng nhằm hỗ trợ các lập trình viên có thể xây dựng một loại ứng đụng

xột cách nhanh chóng, Mục tiêu của những ngôn ngữ này là rứt ngắn vòng dời phát

triển của phần mềm bằng cách cưng cấp Cornmon Language Runtme (CRL), Java Virus] Machine (TVM), hỗ trọ cross-language và cross-plalformn, và quân lý bộ nhớ lự

Trang 28

đông Lập trình viên vẫn có thể theo dõi, kiểm soát những vấn đẻ cấp thập, như tính toản vẹn kiểu (type safety), các thư viên cáp thập cỏ săn, kiêm soát mảng, vv Thực

tế các lập trình viên thực sự sử dụng thời gian vả công sức vảo những ứng dụng của họ

và vào lô gie nghiệp vụ (busmess logic) Những phương thức kiểm thử truyền thông không thể đáp ứng kịp với tiên triên của kỹ thuật Đề đáp ứng được yêu cầu vẻ khung

thời gian, cần tìm ra con đường nhanh và tốt hơn đề kiểm thử các sản phẩm phan mem

Kiểm thử tự động gây được sự chú ý lớn do sự tiến triển của kỹ thuật làm tăng tỉnh phức tạp của những sản phẩm phân mềm

Công cụ kiểm thử phần mêm tự động trong Luận văn này có các tính năng:

Nghiên cứu assembly dưới hình thức kiềm thử động

Điều khiên vả thực hiện lặp các tác vụ đơn giản một cách động

Tạo lập những kịch bản kiểm thử vả thực thí các kịch bản kiểm thử nay bằng từng gói theo lịch trinh (schedule manner.)

Kiểm thử Interface của các đối tượng và những thành phần phần mềm

khác (software component) voi mét tap dét liệu định sẵn

Truy cập một CSDL đề xác thực kết quả kiểm thử

Truy cập Window Registry đề xác thực kết quả kiểm thử

Dữ liệu kiểm thử và kết quả kiểm thử sẽ được thẻ hiện dưới dang XML va MS Excel worksheet Tiên trình kiểm thử tự động có thể được trình bảy với 6 bước như

Trang 29

28

Hình 1.4: 6 bước của kiêm thứ phân mém te déng 19/

Các công cụ kiểm thử tự dộng cỏ trên thị trường không dủ khả năng kiểm thứ một sản phẩm một cách kỹ lưỡng Khi nay sinh một tính năng kiểm thử mới thì nhà cưng cấp thường hủa hẹn sẽ tích hợp tính răng này vào công cụ trong phiên bản tiếp theo Để đáp ửng được sự đa dạng của phần mềm, công cụ kiểm thứ được phát triển trong luận văn này có đủ "các tổ bảo não" để đáp ứng được một yêu câu mới

Các kỹ sư kiểm thử đã quá quen và cé kinh nghiệm trong việc sử dụng các chức răng chụp màn hình và ghi lại kịch bên kiểm thử khi sử dụng các công cụ trên thị trường, nó sẽ dẫn hướng cho unit test, advance stress test, va capability test Céng cụ kiém tht ty déng khéng yêu câu thay đối kỹ thuật lập trinh heặc bất kỳ mật hãnh động giủ thủ công nào khác

Vi vay bang cách sử dụng các công cụ kiếm thử hoàn toàn tự dộng, các kiểm thử viên sẽ được giải phóng khỏi việc reverse-engineering, việt những kịch bản buôn tế, và

khu vực

tạo ra gác đữ liệu lưu Irữ Họ có thế đành nhiêu thời gian hơn để kiểm thử c¡

cỏ nguy cơ lỗi cao hơn của phản mềm Hơn nữa, lập trình trong mới trưởng nhu MS NET cung cấp cho các kiểm thủ viên khả năng phát triển một công cụ cao cấp trong, khung thời gian và ngân sách cho phép Đặc diễm này nay ding cho nhiều môi trường

và ngôn ngữ lập trình, chẳng hạn nbu Eelipsing NET, DotGNU Portable NET, Java, Visual Basic 6.0, C/C++, C #va Visual Basic NET

1.6 Kiểm thử phần mễm và các ngôn ngữ lập (rình

Như đã đề cập ở phản trước, có rất nhiều công oụ kiếm thử phần mềm trên thị

trường, và các tỗ chức đá gặt hái được nhiều thành công khi áp dụng các công cụ này vào quy trình phát triển phần mềm của mình Một vải công cụ kiêm thử phân mềm việt

kich bản kiếm thử bằng ngôn ngữ Visual Basic 6.0 và thực thi kịch bán trong Visual

Studio TDE Đồng thời cũng có nhiều tài liệu hướng dâu cách viết kịch bản kiểm thử

sử dụng ngôn ngữ Visual Basic 6.0 một cách thủ công, Một vải công cụ khảo được viết

Trang 30

Việc tự dòng hóa các mục tiêu tập trung chủ yêu vào các vẫn dễ từ một số khu vực được xác định rõ ràng Những vẫn dé va các khu vực đó đã từng xảy ra các lỗi

phần mềm trơng quá khứ Cáp công cụ kiểm thử thường viết những kịch bản kiểm thử với một số lặp di lặp lại các mẫu (parttern) dễ kiểm thủ các phương thức khác nhau trong một lớp (class)

Nhìn chung chúng mô bình kiểm thử gồm các bước sau

1 Thiết lập các thêng số cần thiết

2 Thực thả phương thức cẩn kiểm thử và bắt lỗi

3 Trình bày các kết quả nhận được Các phưng thức đưới quả trình kiểm thử hành xử theo các cách khác nhau Mỗi tiến trình kiểm thử sẽ về một giá trị Các kiểm thử viễn sẽ xemt xét liệu kết quả trả về

có giống với kết quả mong doi Do dé, giá trị của kết quả trả về sẽ được trình bay sau

khi thục thu kiểm thử

Một cảng cụ tự động kiểm thử sẽ được thực hiện để kiểm thử tất cả các khía cạnh của một sản phẩm phần mềm

Cé thé dé dang viết các đoạn mã nguồn một cách thủ công khi không có nhiều đổi tượng để kiểm thứ Nhưng mắt nhiễu thời gian để viết mã cho một tập hợp số lượng lớn lớp (class) và thành phản Ngoài ra các kiếm thử viên sẽ mật nhiêu thời gian

dé hiểu dược từng phương thức dễ có thể viết mã một cách chính xác Mặt khác rất khá khăn cho một công cụ để viết mã khác nhau giữa các phương thức phức tạp G8 lỗi luôn luôn cần thiết khi viết kịch bản kiếm thử một cách thủ công Với công cụ kiếm thử tự động các quy trình kiểm thử sẽ trở nên nhanh chỏng cho các công việc lắp dĩ lắp

lại và sẽ không cân tái gỡ lỗi (đebng) mĩa

vẫn đề mới sẽ được kiếm thử thủ công và tự đông hóa về sau.

Trang 31

kiểm thử Vân dé nay sẽ được sáng tỏ trong néi dung ctia Luan văn

Trong quá khử, Visual Basic và Java đã được sử đụng thường xuyên hơn các

tigôn ngữ khác để viết kịch bản kiểm thử Ví dụ, công cụ kiểm thử của Raliormal sử

dụng một phương thúc reverse-enginsering va tao ra các kich ban trong Visual Basic

Cuỗn sich Visual Basic cho cae kiểm thử viên (Sweeney 2001) giới thiệu một số kỹ thuật của việc tạo ra kịch bản kiểm thử, nhưng nó không bao gòm các kỹ thuật cho tự động hóa kịch bản kiểm thứ Lập trinh viên Java thưởng dùng JUnit như một công cụ kiểm thé tu động Sử dụng một ngôn ngữ lap tinh oh Ơ # làm công cụ kiểm thử là một khải niệm mới Luận văn sẽ không chỉ nghiền cứu cách làm thé nao dé viét một kịch bản kiểm thử cho một assembly, ma cén chỉ ra cách làm thể nào để phát triển một cổng cu dé vidt kich ban kiém thử một cách tự động, VẺ sau, các tổ chức khá nhau và các dự an phản mềm với chức năng khác nhau có thể sử dụng phương pháp nay cho

việc phát triển phân mềm Dẻ thực hiện giải pháp sẽ tập trưng vào giải quyết các vấn

«Lam thé nao dé (ao ra giao dién voi ohiimg thanh phan điều khiển đơn giản

mà có thể thể hiện được thông tin cũng như kết quả kiêm thủ

© Lam thế nảo dễ tạo và lưu giữ test case trong cơ sở dữ liệu (trong trường, hợp này là MS Excel và XML) đề tự động tạo các kịch bản kiểm thử

Trang 32

® Lâm thể nào để tạo một bản trình bảy các thông tỉn của một thành phản tong quá trình kiểm thử (rong trường hợp này là sử đụng một bang tinh xeel)

© Lâm thế nào thực hiện một cơ chế dễ tao ra tập lệnh kiểm thử để thử nghiệm một lớp (class), một thành phản dữ liệu, vả một phương thức (trong trường hợp này lá sử dụng NET CodeDom.)

œ Làm thế nào để cho phép các kịch bản kiếm thử có thẻ kiếm thử các tham

số thang qua vide truyền giá trị, truyền tham chiếu (relorencos), và truyền

déi trong

© Lam thé nio dé cho phép các kịch bản kiểm thử có thể kiểm thứ dựa vào

hệ thống Windows system registry

© Lâm thể nào trình bảy các kết quả kiểm thử để các nhà phát triển sẽ có thêm nhiễu thông tin tết nhất có thế đề sửa chữa lỗi được tìm ra trong quả trình kiểm thử

1.7 Kịch bản kiếm thử

Một kịch bản kiểm thử đóng vai trở như người dùng cuối sử dụng ứng dụng theo một kich bản định trước, theo đỏ một sản phẩm phản mềm được kiểm thứ tự động,

Theo truyện thông, mật tập lệnh kiếm thử tự động được viết bài một kiểm thử viên đề

kiểm thử các phương thức của một assembly, Khi các kiểm thử viên viết kịch bản kiểm thử họ phái mắt thời gian đề xác định vá phân tích các yêu cầu rong quá trình phát triển phân mềm các thông số này cũng thay đối và kiếm thử viên sẽ phải chỉnh

sửa hoặc viết kịch bản kiểm thủ Quả trình nảy sẽ được lặp di lặp lại cho đến khi sản phẩm ân định Sau đó, các kịch bản kiểm thử có thể được chạy đề thực hiện các dang kiểm thử: mút test, interpratien test (kiếm thử tích hợp), hoặc regression test (kiểm thử hồi quy) Trong toàn bộ quá trình, công việc của dội kiểm thử là cải thiên và gỡ lỗi các

kich bản kiếm thử đẻ đáp ump va luôn đáp ứng theo những thay đối của yêu cầu kiếm

Trang 33

32

phủ hợp Nếu câu trúc của phản mềm ổn định trong suốt quá trình phát triển, kịch bản kiểm thứ cỏ thể chạy unit test, integration test, và regression test trong suốt quá trình phái triển phần mềm

Nguyên lắc dễ phát triển một sản phẩm phần rẻ lốt là phải phát triển một kịch bản kiểm thứ tốt Để tạo ra một kịch bản kiểm thử hiệu quả, các công cụ cần có cơ chế

đề phản ánh (reflect) các thông tín chỉ tiết của dự án cân kiểm thủ Một kịch bản kiếm

thủ được tạo ra bỏi công cụ kiếm thử

m có các lính nẵng san đây Reusabill inh sử dụng lại: cần những nỗ lục rất lớn để phát triển

ra kịch bản Ví dụ, nếu các như cầu đặc biệt thường xuyên xây ra ta cân câp nhật lại những công cụ những công cụ kiểm thứ tự động, Nó làm cho công cụ kiếm thử được sử dụng để đảng hon che các dự án trong tương lai Nếu yêu cầu muới không phải là điển hình, kỹ sư kiểm thử có thể quyết định không để cập nhật các công cụ, thay vị thế sẽ sửa đổi các kịch ban kiểm thử

Maintainability — Khả năng bảo trì: cỏ rất nhiều yêu cầu vả hình thức khác nhau của một sẵn pham phan mém, mde đủ chúng có thể có những tỉnh năng phổ biến thường sẽ giống nhau Hiện tại thì các công cụ kiểm thủ tự động có khá đủ các tính năng đáp ứng cho hau hét các sản phẩm

Trang 34

phân mềm Khi các tỉnh năng mới dược kỳ vọng sẽ phát triển trọng tương, lai các dự án, các công cụ kiể thứ tự động có thê sẽ phải được cập nhật

« Portability — Tính khả chuyến: với một quả trình cải đặt đơn giản, các

sông cụ kiểm thử tụ động có khả năng thục hiện được yêu câu nhiệm vụ

kiểm thử trên nhiều hệ thống máy tính khác nhau

Cần ghủ nhớ một điều rằng sự thành công của dự án phẩu mỗm phụ thuộc vào việc áp dụng các công cụ kiểm thử Không cỏ lập trình viên hoản háo, một kiểm thứ viễn sẽ rải mủ mở trong việc tìm khuyết tật trong má của người khác Công cụ thử nghiệm phát triển trong luận văn có thể tao ra một tập lệnh thực thị kiểm thử mả không, cần gỡ lỗi, điều nảy sẽ tiết kiệm được rất nhiều thời gian Tuy nhiên cần phân chia đủ thời gian để gỡ lỗi và kiếm thữ các công cụ kiểm thử tự động trong và ngay cả sau khi phát triển cáo công cụ

là một yêu câu tắt yêu, mang tính chất sống còn đổi với mỗi sản phẩm phân mểm nói

riêng và ngành công nghiệp phần mm nói chung, Từ thực lễ nảy cũng đặt ra riiễu thách thức trong lĩnh vực kiểm thử phần mềm khi công sức cũng như chỉ phí phải bỏ

ra ngày cảng tăng Do đó việc nghiên cứu ap dung các công cụ kiếm thử tự động được cơi là một giải pháp tối ưu cho bài toán này, những lợi Ích mà kiểm thử tự động đem

lại là rất lớn

'thông qua Chương 1 tác giá đã tiếp cận được các yêu cầu và đặc điểm của các

công cụ kiểm thử tự động, về mô hỉnh hoạt động cũng như các thành phần của một

công cụ kiểm thử tự động Trong nội dung chương tiếp theo của luận văn, tác giá sẽ dĩ sâu tìm hiểu kiến trúc và các thể loại kiểm thử phần mềm, trước khi trực tiếp bắt tay vào nghiễn cứu xây dựng một công cụ kiếm thử tự động,

Trang 35

34

CHUONG 2: PHUONG PHAP VA CAC THE LOAI

KTEM THU PHAN MEM

21 Tổng quan

Kiểm thử phân mêm là mệt quá trình điều tra tiến hành thực nghiệm để cung cập cho các bên liên quan thông tin về chất lượng sản phẩm hoặc địch vụ đã được thử nghiệm, đựa trên bếi cảnh hoạt động của sản phẩm Kiểm thử phần mềm cũng là mục tiêu, một đánh giá độc lập cho phép các doanh nghiệp đánh giá vá hiểu được những rủi

To trong khi thực hiện các phản mém Các kỹ thuật kiểm thử báo gồm, sitng không giới hạn các quá trình thực thi chương trình hay ứng dụng với mục đích từm ra lỗi phần

mém

Thủ nghiệm phần mềm cũng có thể được xen nhu qua tinh phé chuẩn và xác

nh rằng một chương trình phan mém/ing dụng/sản phẩm

1 Dap img cdc yéu cầu nghiệp vụ và kỹ thuật được mồ tá trong thiết kế

2 Hoạt động như mong đợi

Cac mô hình phát triển phản mễm khác nhau sẽ tập trung công việc kiểm thử tại các điểm khác nhau trong quả trinh phát triển rong một mô hình truyền thông, hầu tiết các sông việc kiểm thủ được thục lện sau quá trình đặc tả yêu câu và viết mứã Các

mô hình phát triển mới hơn, chẳng hạn như Aaile hoặc XP, thưởng dược áp dụng phương pháp thử nghiệm hướng phát triển (Test Driven) và sử dụng trước một phần của thử nghiệm trong quá trình phát triển do chính các lập trình viên thực hiện

Việc tách và gỡ lỗi từ kiểm thử được giới thiệu lần dau tién boi Glenford J Myers vào năm 1979, "Một thứ nghiệm thánh công là một thứ nghiệm trong đỏ tìm

Trang 36

thấy lỗi", diễu này minh hoa cho các mong muốn của công déng céng nghệ phần mềm

là tách biệt các hoạt động phát triển phần mềm và hoạt động gỡ lỗi

2.2 Các phương pháp kiếm thứ

C6 2 phương pháp kiểm thứ chính là: Kiểm thứ tĩnh và Kiểm thứ động

Là phương pháp thủ phân mềm đòi hỏi phải duyệt lại các yêu cầu và các đặc tả

bang tay, théng qua việc sử dụng giây, bút dé kiếm tra logic, lần từng chỉ tiết mà không cần chạy chương trình Kiểu kiểm thử này thường dược sử dụng bởi chuyên viên thiết kế người mà viết mã lệnh một mình

Kiểm thử tĩnh cũng có thể được tự động hóa Nó sẽ thực hiện kiểm tra toàn bộ

bao gầm các chương trình được phân tích bởi một trình thông dịch hoặc biên địch mà xác nhận tính hợp lệ về củ pháp của chương trình

2.2.2 Kiểm thứ động — Dynamic testing

Là phương pháp thử phản mẻm thông qua việc dùng máy chay chương trình dé

điển tra trạng thải tác động của chương trình Đó là kiếm thử dựa trên cáo ca kiếm thử

xác định bằng sự thực hiện của đối tượng kiểm thủ hay chạy các chương trình Kiểm thử động kiểm tra cách thức hoạt dộng déng của mã lệnh, tức lả kiểm tra sự phản ửng, vật lý từ hệ thông tới các biên luôn thay đối theo thời gian Trang kiếm thử động, phân mềm phải thực sự dược biên địch và chạy Kiểm thử động thực sự bao gồm làm việc với phần mềm, nhập các giả trị đầu vào và kiểm tra xem liệu đầu ra có như mong, muốn hay không Các phương pháp kiêm thử động gồm có: Kiêm thử thành phần (Unit Test), Kiểm thử tích hợp (Intergration Test), Kiểm thi hé thang (System Test),

và Kiểm thử chấp nhận sản phẩm (Acceptanee Test)

2.3 Các chiến lược kiểm thử

Ba trong số những chiến lược kiểm thứ thông dụng nhất bao gồm: Kiểm thứ hộp đen, Kiểm thủ hộp trắng và Kiểm thử hộp xám

2.3.1 Kiếm thứ hộp đen— Black box testing

Trang 37

36

Một trong những chiến lược kiểm thử quan trong là kiểm thử hộp den, hướng dữ liệu, hay hưởng vảo/ra Kiểm thử hộp đen xem chương trinh như lá một “hộp đen” Mục đích của bạn là hoàn loàn không quan lâm về cách cư xử và câu trúc bên lzong,

của chương trình Thay vào dó, tập trung vào từn các trường hợp mà chương trinh

không thực hiện theo các đặc tả của nó Theo hướng tiếp cận này, đữ liệu kiểm tra được lẫy chỉ từ các đặc tả

Các phương nhảp kiểm thử hộp đen:

Phân lớp Lương đương — Equivalence partitioning, Phan tích gia iri 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 _Miodel-based testing,

Ma trận đâu vết — Traceability matrix

Kiém thi tham dé — Exploratory testing

v Kiém tht dua trén dic ta— Specification-base testing, Kiếm thử đựa trên đặc tã tập trung vao kiém tra tinh thiat thuc cia phan mém theo những yêu cầu thích hợp Do đó, kiểm thứ viên nhập dữ liệu vào, và chỉ thấy đữ

liệu ra từ đổi tượng kiểm thử Mức kiểm thử này thường yên cầu các ca kiếm thử triệt

đề được cưng cấp cho kiếm thử viên mà khi đó có thể xác xinh là đối với đữ liệu đầu vào dã cho, giá trị đầu ra (hay cách thức hoạt động) có giống với giá trị mong muốn đã được xác định trong ca kiểm thử đỏ hay không Kiểm thử dựa trên đặc tả là cần thiết,

nhưng không đã để để ngăn chắn những rỗi ro cÌ

Ưu, nhược điểm

Kiểm thử hộp den không cỏ mỗi liên quan nào tới mã lệnh, và kiểm thử viên chỉ rất don giản tâm niệm là: một mã lệnh phải có lỗi Sử đự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, người la cũng nói kiểm thứ hộp den “gidng nhi 1a

đ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 đựng như thế nảo Đó là lý do mà có nhiều

Trang 38

trường hợp mà một kiểm thử viên hộp den viết rất nhiễu ca kiểm thử dễ kiểm tra một thử gi đỏ 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 Irình không được kiểm tra chil nao

Do vay, 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 đỏ mù”,

2.3.2 Kiểm thứ hộp trang — White box testing

La mét chiến lược kiểm thử khác, trải ngược hoản toàn với kiểm thứ hộp den, +iểm thử hộp trắng hay kiểm thử hướng logic cho phép bạn khảo sát cầu trúc bên trong của chương trình Chiến lược nay xual phat tir dé liệu kiếm thử bằng sự kiểm thử trút logic của chương trinh Kiểm thứ viễn sẽ truy cập vào câu trúc dữ liệu vả giải thuật bên trong chương trình (và cả mã lệnh thực hiện chúng),

Các phương pháp kiếm thử hộp trăng:

⁄ Kiểm thử giao diện lap tinh dng dung - APT testing (application programming interface): 14 phuong pháp kiểm thử của ứng dụng sử dụng, các API công khai và riêng tư

* ˆ Bao phủ mã lệnh — Code coverage: tạo các kiểm tra để đáp ủng một số tiêu chuẩn về bao phú rnä lệnh

¥ Cae phuong phap gan 16i— Fault injection

ˆ Các phương pháp kiểm tủ hoàn chuyển Mutation testing methods

Y 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ử đụ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 nay 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 it 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.3.3 Kiểm thứ hộp xám — Gray box testing

Kiếm thử hộp xảm đôi hỏi phải có sự truy cập tới câu trúc đữ liệu và giải thuật biê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

Trang 39

38

người sử đụng hay mức hộp den Việc thao tác tới dữ liệu dầu vào và định dạng đữ

liệu đầu ra là không rõ ràng, giống như một chiếc xám”, bởi vị đầu vào vá đầu ra

Tố răng là ở bên ngoài “hộp den” ma chimg ta vẫn gọi về hệ thông được kiểm tra Sự khác biệt này dặc biệt quan trọng khi quản lý kiểm thử tích hợp Imtergartion 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 điện là được đưa ra để kiếm thứ Kiếm thử hộp xám eó 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.4 Các cấp độ kiểm thứ phần mềm

Các nhà sản xuất đã phát triển các công cụ để bao hàm được một loạt các nhiệm

vụ kiếm thử Tuy nhiên, sử đựng những công cụ nảy sẽ làm tang thêm tính phức tạp

của các phần riẻm ứng dung

Ngày nay, các tổ chức phát triển phẩn mẫm thường lổng ghép nhiền kỹ Huuật khác nhau, thiết kế và lập trình hướng đổi tượng, các loại giao dién, client-server va các ứng đụng phân tán, truyền dữ liệu, và các cơ sở đữ liệu quan hệ lớn, mà tắt cả làm chơ dộ phúc tạp của phản mềm tăng theo hàm số mũ Những lập trình viên lập trình công cụ kiểm thử không thể lâm tăng sắp đôi tính phức tạp trước khi tiên hành một dự

án, làm thé y khó khăn cho họ hoặc giả sẽ không thế giải quyết các vẫn đẻ họ đưa

ra một cách tối ưu

Ngoài ra, các kỹ sư phản mềm vẫn tiếp tục cải thiện công nghệ vả tăng thêm tính phức tạp vào các đự án phần mềm Các nhà phát triển công cụ không thể đụ đoán trước những cải tiền này, và vì vậy họ cũng phải được xem xéL một cách độc lập trên

cơ sở để xác định xem làm thế nào để có thể kiểm thử

Tôi với những lý do này, bắt buộc các tổ chức phát triển phần mềm phải tự phát triển cảng cụ của mình để giải quyết các vẫn đề đặc thù của mình Đề bảo đâm chất lượng sân phẩm trong một thời gian quy định, các tổ chức phải phải triển một cách

hiệu quả thứ nghiệm phương pháp tiếp cận với một trong phạm: vi tập trung,

Xác định một phạm vị kiểm thử lá quan trọng cho sự thành công của một đự án phần mềm Do có thời gian ngắn khung và các tương tác của con người liên kết với các công cụ kiểm thử phần mềm cỏ sẵn, nó có thể trở thành khó khăn để kiểm thứ tất

cả các thành phần của một ứng dụng theo sự phát triển Dó là luôn luôn mong muốn

Trang 40

các phân mềm đề kiêm thử kỹ lưỡng, nhưng không phải lúc nào cũng có thể do thời gian và ngân sách Nêu việc thử nghiệm các công cụ có khả năng thực hiện công việc

kiểm thử và kiếm thử các trưởng hợp soạn với đây đủ tự động hóa, con người xét

nghiêm sẽ có đủ thời gian đề tập trung vào các khu vực có nguy cơ cao,

Nếu không có công cụ kiểm thử tự động hoàn chỉnh, các kỹ sư kiểm thử thường,

xác định các yêu cầu quan trọng và các khu vực có nguy cơ cao bằng cách phân tích

được các yêu cau quan trọng nhất đối với khách hàng vả các lĩnh vực trong phạm vì ứng dụng được người sử dụng quan tâm nhất Các quyết định thường được đưa ra dé làm thử nghiêm không tính tới toàn bộ các trong khu vực không cỏ nguy cơ cao, điều

đó đó có thẻ gây ra các vẫn đề vả thâm chí rất nghiêm trọng trong tương lai và biến các van đề không nghiêm trong nảy thành những vân đẻ nghiêm trọng Do đỏ, phạm vi của

một công cụ kiêm thử tự động đây đủ phải kiểm thử được tất cả các dỏng mã, vả các

dòng mã phải được kiểm thử liên tục cả ngày lân đêm cho dén khi hau het các lôi được tìm thấy va sản phẩm được phát hảnh

Hình 2.1: Môi tương quan giữa phát triển và kiếm thử phần mềm

Sau khi phạm vi thử nghiệm được xác định, bạn thường cản phải lập kể hoạch

cho giai đoạn thử nghiệm, bao gồm các loại hình vả thời gian của các bải kiểm thử sẽ

được thực hiện ở cả trước và postrelease giai đoạn Các công cụ thử nghiệm thương

mại sẵn có được sử dụng đề thực hiện những loại thử nghiệm dưới đây trong một chủ

kỳ hoàn chỉnh

2.4.1 Kiểm thử mức đơn vị - Unit Test

Ngày đăng: 21/05/2025, 19:20

Nguồn tham khảo

Tài liệu tham khảo Loại Chi tiết
1, Alan Page, Ken Johnston, Bj Rollison (2008), “How We Test Software at Microsoft (Paperback)” Microsoft Press, 1, 405 Sách, tạp chí
Tiêu đề: How We Test Software at Microsoft (Paperback)
Tác giả: Alan Page, Ken Johnston, Bj Rollison
Nhà XB: Microsoft Press
Năm: 2008
2, Alan M, Davis (1993), “Software Requirements: Objects, Fumctions and States” Prentice-Hall, 2, 521 Sách, tạp chí
Tiêu đề: Software Requirements: Objects, Fumctions and States
Tác giả: Alan M, Davis
Nhà XB: Prentice-Hall
Năm: 1993
3. Boris Reiver (1995), “Rlack-Box Testing - Techniques for functional testing of software and systems” John Wiley and Sons, 1, 294 Sách, tạp chí
Tiêu đề: Rlack-Box Testing - Techniques for functional testing of software and systems
Tác giả: Boris Reiver
Nhà XB: John Wiley and Sons
Năm: 1995
4, Brett Pettichord, Cem Kaner, James Bac, (2002), “Lessous Leamed in Software Testing” John Wiley and Sons, 1, 286 Sách, tạp chí
Tiêu đề: Lessous Leamed in Software Testing
Tác giả: Brett Pettichord, Cem Kaner, James Bac
Nhà XB: John Wiley and Sons
Năm: 2002
6. Dorothy Graham, Mark Fewster (1999), “Software Test Automation” dddison- Wesley, 1, 574 Sách, tạp chí
Tiêu đề: Software Test Automation
Tác giả: Dorothy Graham, Mark Fewster
Nhà XB: Addison-Wesley
Năm: 1999
7, Elfriede Dustin, Jeff Rashka, John Paul (2000), “Automated Software Testing : Introduction, nmanagemont and performance” Addison-Wesley, 1, 575 Sách, tạp chí
Tiêu đề: Automated Software Testing : Introduction, nmanagemont and performance
Tác giả: Elfriede Dustin, Jeff Rashka, John Paul
Nhà XB: Addison-Wesley
Năm: 2000
8, Elfnede Dustin, Jeff Rashka, Douglas McDiarmid (2002), “Quality Web Systems: Performance, Security and Usability” Addison-Wesley, 1, 318 Sách, tạp chí
Tiêu đề: Quality Web Systems: Performance, Security and Usability
Tác giả: Elfnede Dustin, Jeff Rashka, Douglas McDiarmid
Nhà XB: Addison-Wesley
Năm: 2002
9, Kanglin Li, Mengi Wu (2004), “Effective Software Test Automation: Developing ati Aulomated Software Testing Tool” Syhex, 1. 400 Sách, tạp chí
Tiêu đề: Effective Software Test Automation: Developing ati Aulomated Software Testing Tool
Tác giả: Kanglin Li, Mengi Wu
Nhà XB: Syhex
Năm: 2004
10. Robert V. Binder (2000), “Testing Object-Oriented Systems : Models, patterns and tools” Addison-Wesley, 1, 1191 Sách, tạp chí
Tiêu đề: Testing Object-Oriented Systems : Models, patterns and tools
Tác giả: Robert V. Binder
Nhà XB: Addison-Wesley
Năm: 2000
11. Rex Black (1999). “Managing the Testing Process” Microsoft Press, 1, 381 Sách, tạp chí
Tiêu đề: Managing the Testing Process
Tác giả: Rex Black
Nhà XB: Microsoft Press
Năm: 1999
12. Shel Siegel (1996), “Object Oriented Software Testing: A lerarchical Approach” John Wiley and Sons, 1,511 Sách, tạp chí
Tiêu đề: Object Oriented Software Testing: A lerarchical Approach
Tác giả: Shel Siegel
Nhà XB: John Wiley and Sons
Năm: 1996

HÌNH ẢNH LIÊN QUAN

Bảng  Trang - Luận văn nghiên cứu kỹ thuật kiểm thử phần mềm và Ứng dụng trên môi trường dot net
ng Trang (Trang 10)
Hình  1.1:  Mô  hình  t6  chite  Visual  Studio  Team  System  2008  Team  Foundation  Server - Luận văn nghiên cứu kỹ thuật kiểm thử phần mềm và Ứng dụng trên môi trường dot net
nh 1.1: Mô hình t6 chite Visual Studio Team System 2008 Team Foundation Server (Trang 18)
Hình  2.1:  Môi  tương  quan  giữa  phát  triển  và  kiếm  thử phần  mềm - Luận văn nghiên cứu kỹ thuật kiểm thử phần mềm và Ứng dụng trên môi trường dot net
nh 2.1: Môi tương quan giữa phát triển và kiếm thử phần mềm (Trang 40)
Hình  3.2:  Mô  hình  xử  lý  sinh  kịch  bản  kiểm  thử - Luận văn nghiên cứu kỹ thuật kiểm thử phần mềm và Ứng dụng trên môi trường dot net
nh 3.2: Mô hình xử lý sinh kịch bản kiểm thử (Trang 50)
Bảng  3.9:  Xác  định  thông  tin  thể  loại  của  một  tiễn  trình  dang  chạy  [0ƒ - Luận văn nghiên cứu kỹ thuật kiểm thử phần mềm và Ứng dụng trên môi trường dot net
ng 3.9: Xác định thông tin thể loại của một tiễn trình dang chạy [0ƒ (Trang 62)
Bảng  3.10:  Làm  việc  voi  Lixcel  [97 - Luận văn nghiên cứu kỹ thuật kiểm thử phần mềm và Ứng dụng trên môi trường dot net
ng 3.10: Làm việc voi Lixcel [97 (Trang 63)
Hình  34:  Ca  sử  dụng  mức  gộp - Luận văn nghiên cứu kỹ thuật kiểm thử phần mềm và Ứng dụng trên môi trường dot net
nh 34: Ca sử dụng mức gộp (Trang 69)
Hình  3.5:  Trường  hợp  sử  dụng  của  công  cụ  Umit  Test - Luận văn nghiên cứu kỹ thuật kiểm thử phần mềm và Ứng dụng trên môi trường dot net
nh 3.5: Trường hợp sử dụng của công cụ Umit Test (Trang 70)
Hình  3.6:  Biểu  đồ  trình  tự - Luận văn nghiên cứu kỹ thuật kiểm thử phần mềm và Ứng dụng trên môi trường dot net
nh 3.6: Biểu đồ trình tự (Trang 71)
Hình  3.8:  Biểu  đồ  hợp  tác - Luận văn nghiên cứu kỹ thuật kiểm thử phần mềm và Ứng dụng trên môi trường dot net
nh 3.8: Biểu đồ hợp tác (Trang 72)
Hình  3.7:  Biéu  dé  trang  thái - Luận văn nghiên cứu kỹ thuật kiểm thử phần mềm và Ứng dụng trên môi trường dot net
nh 3.7: Biéu dé trang thái (Trang 72)
Hình  3.9:  Biêu đồ lớp  3.3.7  Mô hình dữ liệu - Luận văn nghiên cứu kỹ thuật kiểm thử phần mềm và Ứng dụng trên môi trường dot net
nh 3.9: Biêu đồ lớp 3.3.7 Mô hình dữ liệu (Trang 73)
Hình  3.10:  Cửa  số  giao  điện  chính - Luận văn nghiên cứu kỹ thuật kiểm thử phần mềm và Ứng dụng trên môi trường dot net
nh 3.10: Cửa số giao điện chính (Trang 74)
Hình  3.11:  Cửa  số  chọn file  phân  tích - Luận văn nghiên cứu kỹ thuật kiểm thử phần mềm và Ứng dụng trên môi trường dot net
nh 3.11: Cửa số chọn file phân tích (Trang 75)
Hình  3.12:  Cửa  số  chọn  thuộc  tinh  kiém  thir - Luận văn nghiên cứu kỹ thuật kiểm thử phần mềm và Ứng dụng trên môi trường dot net
nh 3.12: Cửa số chọn thuộc tinh kiém thir (Trang 76)

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN

🧩 Sản phẩm bạn có thể quan tâm

w