Nghiên cứu quy trình và phương pháp kiểm thử Unit Test và TDD

ĐẠI HỌC KINH TẾ QUỐC DÂN
VIỆN CNTT KINH TẾ
BM CÔNG NGHỆ THÔNG TIN

BÁO CÁO
CHUYÊN ĐỀ TỐT NGHIỆP
Tªn ®Ò tµi:
NGHIÊN CỨU QUY TRÌNH và
PHƯƠNG PHÁP KIỂM THỬ PHẦN MỀM UNIT TEST, TDD

Sinh viên thực hiện: VŨ THỊ THU TRANG
Giảng viên hướng dẫn : Th.s NGUYỄN TRUNG TUẤN
Hà Nội 08/2011
Báo cáo thực tập tốt nghiệp
MỤC LỤC
LỜI NÓI ĐẦU 1
CHƯƠNG 1: GIỚI THIỆU CHUNG VỀ CƠ SỞ THỰC TẬP 2
1.1 Giới thiệu chung về công ty cổ phần Thiên Đức 2
1.2. Lĩnh vực hoạt động của công ty cổ phần Thiên Đức 3
1.3. Sơ đồ tổ chức của công ty 3
1.4. Mục tiêu của công ty 4
CHƯƠNG 2: NGHIÊN CỨU QUY TRÌNH VÀ PP KIỂM THỬ 5
1. Tổng quan 5
2. Các định nghĩa 5
3. Kiểm thử phần mềm 6
4. Các thuật ngữ 7
5. So sánh giữa thẩm tra và xác nhận 9
6. Vòng đời 9
7. Phạm vi 9
8. Kiểm thử chức năng - phi chức năng 10
9. Lỗi và Hỏng 10

10. Phát hiện lỗi 11
11. Khả năng tương thích 11
12. Kiểm thử tĩnh và động 12
13. Các đội kiểm thử PM 12
14. Quản lý chất lượng PM 12
15. Phương pháp kiểm thử 13
15.1. Kiểm nghiệm hộp trắng 13
15.2. Kiểm nghiệm hộp đen 13
16. Các cấp độ kiểm thử 14
16. 1.Kiểm thử đơn vị 14
Vũ Thị Thu Trang - Lớp LT -CNTT -K10b
ii
Báo cáo thực tập tốt nghiệp
16.2. Kiểm thử hệ thống 14
16.3. Kiểm thử tích hợp 16
16.4. Kiểm thử phát hành 19
16.5. Kiểm thử hiệu năng 23
16.6. Kiểm thử thành phần 25
16.7. Kiểm thử giao diện 27
CHƯƠNG 3 : KIỂM THỬ ĐƠN VỊ 31
1. UNIT TEST 31
1.1 Vòng đời của UT 32
1.2. Thiết kế UT 32
1.3 Ứng dụng của UT 33
1.4. Lợi ích của UT 33
1.5. Chiến lược viết mã hiệu quả với UT 34
1.6 . Xây dựng UT với mô hình đối tượng ảo 36
1.6.1. Định nghĩa 36
1.6.2. Đặc điểm 37
1.6.3. Lợi ích 37

1.6.4. Phạm vi sử dụng 37
1.6.5 Thiết kế MO 38
THUẬT NGỮ SỬ DỤNG 40
CHƯƠNG 4: PHƯƠNG PHÁP KIỂM THỬ TDD 41
1. Đặc điểm 41
2. Lợi ích 41
3. Vòng đời T DD 42
3.1. Add to test 43
3.2. Lặp lại (Repeat) 44
3.3. Phong cách lập trình 45
3.4 Quy trình thực hiện 46
3.5. Chiến lược phát triển với TDD 47
Vũ Thị Thu Trang - Lớp LT -CNTT -K10b
iii
Báo cáo thực tập tốt nghiệp
3.6. Lỗ hổng 48
CHƯƠNG 5: ỨNG DỤNG KIỂM THỬ PHẦN MỀM 50
1. Kịch bản Test 50
1.1 Test Case cho phần đăng nhập 50
1.2 Test cho phần nhập hồ sơ nhân viên 51
1.3 Test Case cho phần Điều động, khen thưởng/ kỷ luật 55
1.4 Test Case cho phân thồng kê 58
2. Đánh giá kết quả kiểm thử với bản test 61
KẾT LUẬN 62
TÀI LIỆU THAM KHẢO 63
ĐÁNH GIÁ CỦA GIÁO VIÊN HƯỚNG DẪN 64
Vũ Thị Thu Trang - Lớp LT -CNTT -K10b
iv
Báo cáo thực tập tốt nghiệp
LỜI NÓI ĐẦU

Quản lý chất lượng phần mềm là vấn đề không mới nhưng theo một số
đánh giá là còn yếu
của
các công ty phần mềm Việt Nam. Một số công ty trong
nước hiện đã đạt các chuẩn quốc
t
ế
CMM/CMMI trong nâng cao năng lực và
quản lý chất lượng phần mềm, song chỉ đếm được
trên
đầu ngón tay, và hiện
cũng chỉ gói gọn trong vài công ty gia công cho thị trường nước
ngoài.
Lâu nay, nói đến chất lượng phần mềm, không ít người nghĩ ngay đến
vấn đề là xác định
xem
phần mềm đó có phát sinh lỗi hay không, có "chạy" đúng
như yêu cầu hay không và cuối
cùng
thường quy về vai trò của hoạt động kiểm thử
phần mềm (software testing) như là hoạt động chịu trách
nhiệm

chính.
Với quan điểm của khách hàng, điều này có thể đúng, họ không cần quan
tâm nội tình của
hoạ
t
động phát triển phần mềm, điều họ cần quan tâm là liệu sản
phẩm cuối cùng giao cho họ có

đúng

hạn
hay không và làm việc đúng như họ
muốn hay
không.
Với thực tế trên, Em chọn đề tài “ Nghiên cứu quy trình và phương pháp
kiểm thử Unit Test và TDD” cho báo cáo thực tập
.
Em xin b à y t ỏ l ời cảm ơn chân thành tới Thạc Sĩ Nguyễn Trung Tuấn,
người đã
tận
tình hướng dẫn em trong suốt quá trình em thực hiện đề tài. Em xin
gửi lời cảm ơn sâu sắc tới ban lãnh đạo và toàn thể các cán bộ công ty cổ
phần Thiên Đức nơi em đã thực tập, các thầy cô trong khoa CNTT đã cung cấp một
số tài liệu, số liệu để em có thể hoàn thành được đề tài này.
Hà nội, ngày tháng năm 2011
Sinh viên
Vũ Thị Thu Trang
Vũ Thị Thu Trang - Lớp LT -CNTT - K10b
1
Báo cáo thực tập tốt nghiệp
CHƯƠNG 1
GIỚI THIỆU CHUNG VỀ CƠ SỞ THỰC TẬP
1.1. Giới thiệu chung về công ty cổ phần Thiên Đức
Công ty cổ phần Thiên Đức là một công ty trẻ có tiềm năng phát triển trong
lĩnh vực viễn thông và công nghệ thông tin tại tỉnh Vĩnh Phúc. Tuy mới thành lập
nhưng công ty đã có những bước tiến đáng kể, công ty chuyên cung cấp các giải pháp
viễn thông tổng thể cho các doanh nghiệp, các tổ chức tài chính, khách sạn với đội
ngũ chuyên nghiệp phát triển phần mềm ( website, phần mềm quản lý, mã vạch ).

Công ty đã và đang tiếp tục khai thác những tiềm năng của công nghệ Internet, tri
thức và nội lực sáng tạo để tạo nên những sản phẩm và dịch vụ phần mềm chất lượng
cao phục vụ góp phần cho sự phát triển kinh tế của tỉnh Vĩnh Phúc.
Tóm tắt về công ty:
Tên công ty: Công ty cổ phần Thiên Đức
Tên viết tắt: Thiên Đức .,JSC
Trụ sở chính:Số 68, đường Mê Linh, phường Liên Bảo, tp Vĩnh Yên, tỉnh Vĩnh Phúc
Số điện thoại: 02113.717 801 Fax: 02113.717 809
Vốn điều lệ: 5tỷ VNĐ
Nguồn nhân lực: 36 người
Để xây dựng uy tín của Thiên Đức .,JSC, công ty luôn coi trọng công tác quản
lý doanh nghiệp, mọi hoạt động đều hướng tới thực hiện tốt, năng động và hiệu quả
của các dự án khách hàng. Với một tập thể kỹ sư, cử nhân có khả năng làm chủ, nắm
bắt nhanh các công nghệ mới, có phong cách làm việc khoa học, tâm huyết, lao động
hăng say và luôn luôn đoàn kết một lòng vì công việc. Đội ngũ nhân sự công ty là
nhân tố quan trọng, phục vụ tận tuỵ và luôn làm hài lòng khách hàng, luôn suy nghĩ
và hành động nhằm giải quyết các vấn đề của khách hàng đặt ra một cách hiệu quả
nhất.
Vũ Thị Thu Trang - Lớp LT -CNTT - K10b
2
Báo cáo thực tập tốt nghiệp
Yếu tố quan trọng dẫn đến thành công trong kinh doanh công ty là sự chủ
động quan hệ hợp tác với các đối tượng trong và ngoài nước. Được sự hỗ trợ công ty
đã nắm bắt được các công nghệ mới, đáp ứng tốt nhất cho các nhu cầu của khách
hàng.
1.2. Lĩnh vực hoạt động của công ty cổ phần Thiên Đức
* Viễn thông:
- Cung cấp, tư vấn các giải pháp tổng đài viễn thông.
- Cung cấp, tư vấn các giải pháp thiết bị mạng viễn thông.
- Cung cấp hệ thống tính cước, truy nhập cho các hệ thống tổng đài, hệ thống truy

nhập Internet qua cáp Ethernet, Wifi, Wimax
- Lắp đặt, bảo trì, bảo dưỡng các hệ thống viễn thông ( thiết bị mạng viễn thông, cáp
quang, mạng không dây, các hệ thống viễn thông khác).
* Công nghệ thông tin:
- Tư vấn giải pháp phát triển hệ thống phần mềm.
- Cung cấp, thiết kế và gia công phần mềm
- Xác thực và bảo mật trong giao dịch online.
- Quảng cáo trực tuyến và khai thác các dịch vụ giá trị gia tăng trên nền VAS và Web
1.3. Sơ đồ tổ chức của công ty cổ phần Thiên Đức
Công ty có đội ngũ nhân viên đầy nhiệt huyết và giàu kinh nghiệm về lĩnh vực
công nghệ thông tin và truyền thông, đã từng tham gia nhiều dự án tin học viễn
thông.
* Ban Giám Đốc
1. Giám đốc
2. Phó Giám Đốc
* Các phòng ban
1. Phòng Lập trình
2. Phòng Viễn thông
Vũ Thị Thu Trang - Lớp LT -CNTT - K10b
3
Báo cáo thực tập tốt nghiệp
3. Phòng Tài chính - Kế toán
4. Phòng Kinh doanh.
Nguồn nhân lực trong công ty 70% nhân lực trình độ Đại học và 30% nhân lực trình
độ Cao đẳng và trung cấp.
Hình 1. Sơ đồ các phòng ban của công ty
1.4. Mục tiêu của công ty
Mong muốn của công ty cổ phần Thiên Đức là trở thành một trong những nhà
cung cấp tốt cho các doanh nghiệp, tổ chức trong và ngoài nước, trở thành tổ chức
vững mạnh và được cộng đồng tôn trọng bằng nỗ lực áp dụng công nghệ tri thức. Công

ty đã và đang phát triển, cải thiện và nâng cao chất lượng sản phẩm, áp dụng các công
nghệ mới, hoàn thiện dịch vụ, tiến đến thỏa mãn các yêu cầu của khách hàng với chất
lượng cao nhất. Mục tiêu của công ty là mở rộng thị trường, tập trung phát triển quản
lý cho hệ thống các doanh nghiệp lớn, các tập đoàn sản xuất có quy mô lớn và phức tạp
hơn.
CHƯƠNG 2
Vũ Thị Thu Trang - Lớp LT -CNTT - K10b
Phó Giám đốc
Phòng Viễn
thông
Phòng Lập
trình
P. Tài chính -
Kế toán
Phòng Kinh
Doanh
Giám đốc
4
Báo cáo thực tập tốt nghiệp

NGHIÊN CỨU QUY TRÌNH VÀ PHƯƠNG PHÁP KIỂM THỬ
PHẦN MỀM (Software Test)
1. Tổng quan
Kiểm thử có thể không bao giờ hoàn toàn xác định tất cả các khiếm khuyết
trong phần mềm. Thay vào đó, nó cung cấp được một lời phê bình hay so sánh, so sánh
phát biểu và hành vi của sản phẩm đối với tài liệu hướng dẫn - nguyên tắc hoặc các cơ
chế mà người ta có thể nhận ra một vấn đề. Tài liệu hướng dẫn có thể bao gồm (nhưng
không giới hạn) chi tiết kỹ thuật, hợp đồng, sản phẩm tương đương, các phiên bản
trước của cùng một sản phẩm, suy luận về dự định hoặc dự kiến mục đích, người dùng
hoặc khách hàng mong đợi, các tiêu chuẩn liên quan, pháp luật, hoặc tiêu chuẩn khác.

Tất cả các sản phẩm phần mềm có một đối tượng mục tiêu. Ví dụ, các khán giả
dành cho phần mềm trò chơi video là hoàn toàn khác nhau từ phần mềm ngân hàng. Vì
vậy, khi một tổ chức phát triển hoặc đầu tư vào một sản phẩm phần mềm, kiểm thử có
thể đánh giá liệu các sản phẩm phần mềm sẽ được chấp nhận cho người dùng cuối,
khán giả mục tiêu của mình, người mua sản phẩm, và các bên liên quan khác. Kiểm
thử phần mềm cố gắng đưa ra đánh giá này.
Một nghiên cứu tiến hành bởi NIST năm 2002 báo cáo rằng chi phí cho lỗi phần
mềm ở Mỹ 59.5 tỷ Đô la Mỹ mỗi năm. Hơn một phần ba chi phí này có thể tránh được
nếu sử dụng phần mềm kiểm thử tốt hơn.
2. Các định nghĩa
“Lỗi phần mềm là chuyện hiển nhiên của cuộc sống. Chúng ta dù cố gắng đến
mức nào thì
thực

t
ế
là ngay cả những lập trình viên xuất sắc nhất cũng không có
thể lúc nào cũng viết được
những
đoạn mã không có lỗi. Tính trung bình, ngay cả
một lập trình viên loại tốt thì cũng có từ 1 đến 3
l
ỗ
i
trên 100 dòng lệnh. Người ta ước
Vũ Thị Thu Trang - Lớp LT -CNTT - K10b
5
Báo cáo thực tập tốt nghiệp
lượng rằng việc kiểm tra để tìm ra các lỗi này chiếm phân
nửa

khố
i
lượng công việc
phải làm để có được một phần mềm hoạt động được”. (Software
Testing
Techniques, Second Edition, by Boris Beizer, Van Nostrand Reinhold, 1990, ISBN
1850328803).
Trên đây là một nhận định về công việc kiểm nghiệm (testing) chương
trình.
Thật vậy, ngày nay càng ngày các chương trình (các phần mềm) càng trở
lên phức tạp
và

đồ
sộ. Việc tạo ra một sản phẩm có thể bán được trên thị trường đòi
hỏi sự nổ lực của
hàng
chục, hàng trăm thậm chí hàng ngàn nhân viên. Số lượng
dòng mã lên đến hàng triệu. Và
để
tạo ra một sản phẩm thì không phải chỉ do một tổ
chức đứng ra làm từ đầu đến cuối, mà đòi
hỏ
i
sự liên kết, tích hợp của rất nhiều sản
phẩm, thư viện lập trình, … của nhiều tổ chức
khác
nhau… Từ đó đòi hỏi việc
kiểm nghiệm phần mềm càng ngày càng trở nên rất quan trọng

và
rất phức
tạp.
Song song với sự phát triển các công nghệ lập trình, các ngôn ngữ lập trình…
thì các công
nghệ
và kỹ thuật kiểm nghiệm phần mềm ngày càng phát triển và
mang tính khoa học.
Bản báo cáo
này với mục đích là tập hợp, nghiên cứu, phân
tích các kỹ thuật, các công
nghệ
kiểm nghiệm phần mềm đang được sử dụng và
phát triển hiện nay.
3. Kiểm thử phần mềm:
Là hoạt động khảo sát thực tiễn sản phẩm hay dịch vụ phần mềm trong đúng
môi trường chúng dự định sẽ được triển khai nhằm cung cấp cho người có lợi ích liên
quan những thông tin về chất lượng của sản phẩm hay dịch vụ phần mềm ấy. Mục đích
của kiểm thử phần mềm là tìm ra các lỗi hay khiếm khuyết phần mềm nhằm đảm bảo
hiệu quả hoạt động tối ưu của phần mềm trong nhiều ngành khác nhau.
Vũ Thị Thu Trang - Lớp LT -CNTT - K10b
6
Báo cáo thực tập tốt nghiệp
Kiểm thử phần mềm cũng có thể được ghi như quá trình kiểm chứng và thẩm
định rằng một chương trình phần mềm / ứng dụng / sản phẩm:
 Đáp ứng các yêu cầu chức năng và kỹ thuật và hướng dẫn thiết kế và phát
triển của nó.
 Các công việc như dự kiến
 Có thể được thực hiện với những đặc điểm tương tự.
Kiểm thử phần mềm tùy thuộc vào phương pháp thử nghiệm được sử dụng, có

thể được thực hiện tại bất kỳ thời gian trong quá trình phát triển. Tuy nhiên, hầu hết
các nỗ lực thử nghiệm xảy ra sau khi các yêu cầu đã được xác định và quá trình mã hóa
đã được hoàn thành. Như vậy, các phương pháp thử nghiệm được quy định bởi các
phương pháp phát triển phần mềm.
Mô hình phát triển phần mềm khác nhau sẽ tập kiểm thử tại các thời điểm khác
nhau trong quá trình phát triển. Mô hình phát triển mới hơn, chẳng hạn như Agile,
thường sử dụng phương pháp TDD và đặt một phần gia tăng của các thử nghiệm vào
tay các nhà phát triển, trước khi nó đến tay đội kiểm thử. Trong một mô hình truyền
thống, hầu hết các thực hiện thử nghiệm xảy ra sau khi các yêu cầu đã được xác định
và quá trình mã hóa đã được hoàn thành.
4. Các thuật ngữ:
4.1 Lỗi
(Error):
– Là các lỗi lầm do con người gây
ra.
4.2. Sai sót
(Fau
lt
):
– Sai sót gây ra lỗi. Có thể phân loại như
sau
:
Vũ Thị Thu Trang - Lớp LT -CNTT - K10b
7
Báo cáo thực tập tốt nghiệp
• Sai sót do đưa ra dư thừa – chúng ta đưa một vài thứ không chính xác
vào
mô tả yêu cầu phần
mềm.
• Sai sót do bỏ sót – Người thiết kế có thể gây ra sai sót do bỏ sót, kết quả

là
thiếu một số phần đáng ra phải có trong mô tả yêu cầu phần mềm.
4.3. Hỏng hóc
(Failure):
– Xảy ra khi sai sót được thực thi. (Khi thực thi chương trình tại các nơi bị
sa
i
th
ì
sẽ xảy ra trạng thái hỏng
hóc).
4.4. Kết quả không mong đợi, hậu quả
(Incident)
– Là những kết quả do sai sót đem đến. Hậu quả là các triệu chứng liên kết
vớ
i
một hỏng hóc và báo hiệu cho người dùng biết sự xuất hiện của hỏng
hóc.
4.5. Trường hợp thử (Test
case)
– Trường hợp thử được liên kết tương ứng với hoạt động của chương trình.
Một trường hợp thử bao gồm một tập các giá trị đầu vào và một danh
sách

các
kết
quả đầu ra mong
muốn.
4.6. Thẩm định
(Verification)

– Thẩm định là tiến trình nhằm xác định đầu ra của một công đoạn trong việc
phát triển phần mềm phù hợp với công đoạn trước
đó.
4.7. Kiểm chứng
(Valida
t
ion)
– Kiểm chứng là tiến trình nhằm chỉ ra toàn hệ thống đã phát triển xong phù
hợp
vớ
i
tài liệu mô tả yêu
cầu.
Vũ Thị Thu Trang - Lớp LT -CNTT - K10b
8
Báo cáo thực tập tốt nghiệp
5. So sánh giữa Thẩm tra và Xác nhận:
¨ Thẩm định: thẩm định quan tâm đến việc ngăn chặn lỗi giữa các công đoạn.
¨ Kiểm chứng: kiểm chứng quan tâm đến sản phẩm cuối cùng không còn lỗi.
6. Vòng đời của việc kiểm nghiệm (testing life cycle):
Bảng dưới đây mô tả các công đoạn phát triển một phần mềm và cách khắc
phục lỗi. Lỗi có thể xảy ra trong tất cả các công đoạn từ “Mô tả yêu cầu”, “Thiết kế”
đến “Lập trình”. Từ công đoạn này chuyển sang công đoạn khác thường nảy sinh các
sai sót (do dư thừa hoặc thiếu theo mô tả yêu cầu). Đến công đoạn kiểm nghiệm
chúng ta sẽ phát hiện ra các hậu quả (các kết quả không mong muốn). Quá trình sửa
lỗi bao gồm “phân loại lỗi”, “cô lập lỗi” (tìm ra nguyên nhân và nơi gây lỗi), đề ra
“giải pháp sửa lỗi” và cuối cùng là khắc phục lỗi.


Hình 2.1

7. Phạm vi
Mục đích chính của kiểm thử là phát hiện các lỗi phần mềm đó là các khuyết
điểm có thể được phát hiện và sửa chữa. Đây là một sự theo dõi quan trọng. Kiểm thử
không thể thiết lập một chức năng sản phẩm đúng theo tất cả các điều kiện nhưng có
Vũ Thị Thu Trang - Lớp LT -CNTT - K10b
Vòng đời của kiểm
nghiệm
Lỗi
Mô tả yêu cầu Giải pháp sửa lỗi
Sai sót
Lỗi
Thiết kế
Cô lập lỗi
Lỗi
Lập
trtrình
trình
Phân loại lỗi
Sai sót
Sai sót
Hậu quả
Kiểm
nghiệm
9
Báo cáo thực tập tốt nghiệp
thể thiết lập cho nó hoạt động đúng theo các điều kiện cụ thể. Phạm vi của kiểm thử
phần mềm thường bao gồm kiểm tra mã cũng như thực thi mã trong các môi trường
khác nhau và điều kiện cũng như xem xét các khía cạnh của mã như: hiện nó thực hiện
những gì và làm những gì nó cần phải làm. Trong môi trường phát triển phần mềm
hiện tại, bộ phận thử nghiệm có thể được tách biệt với nhóm phát triển. Các thành viên

trong đội kiểm thử có vai trò khác nhau. Thông tin thu được từ thử nghiệm phần mềm
có thể được sử dụng để sửa các lỗi trong quá trình phát triển phần mềm.
8. Kiểm thử chức năng - kiểm thử phi chức năng
Chức năng kiểm thử liên quan đến hoạt động kiểm thử một hành động cụ thể
hoặc chức năng của mã này. Đây là những mã được tìm thấy trong tài liệu yêu
cầu.Chức năng kiểm thử trả lời câu hỏi "người sử dụng có thể làm được tính năng này"
hoặc "không thực hiện được tính năng đặc biệt này".
Kiểm thử phi chức năng đề cập đến các khía cạnh của phần mềm mà có thể
không được liên quan đến một chức năng cụ thể hoặc hành động của người dùng,
chẳng hạn như khả năng mở rộng hoặc bảo mật. Kiểm thử phi chức năng có xu hướng
để trả lời những câu hỏi như "có bao nhiêu người có thể đăng nhập cùng một lúc".
9. Lỗi và hỏng
Không phải tất cả lỗi phần mềm gây ra bởi mã lỗi. Một trong những nguồn gốc
của các khuyết điểm thông thường là do khoảng cách yêu cầu, ví dụ như, yêu cầu
không được công nhận, dẫn đến lỗi của thiếu sót của người thiết kế chương trình. Một
nguồn gốc của thiếu sót yêu cầu là yêu cầu phi chức năng như khả năng kiểm thử, khả
năng mở rộng, bảo trì, khả năng sử dụng, hiệu suất, và bảo mật.
Phần mềm xảy ra lỗi trong xử lý: Lập trình viên gây ra lỗi (sai lầm), kết quả có
một lỗi trong mã nguồn. Nếu lỗi này được thực hiện, trong những tình huống nhất định
hệ thống sẽ tạo ra kết quả sai, gây ra một thất bại. Không phải tất cả các khuyết điểm
nhất thiết sẽ dẫn đến thất bại. Ví dụ, lỗi trong mã đã chết sẽ không bao giờ dẫn đến thất
bại. Một khuyết điểm có thể chuyển thành thất bại một khi môi trường thay đổi. Ví dụ
Vũ Thị Thu Trang - Lớp LT -CNTT - K10b
10
Báo cáo thực tập tốt nghiệp
về những thay đổi trong môi trường bao gồm các phần mềm đang chạy trên một phần
cứng nền tảng mới, thay đổi trong nguồn dữ liệu hay tương tác với phần mềm khác
nhau. Một khiếm khuyết duy nhất có thể dẫn đến một loạt các triệu chứng thất bại.
10. Phát hiện lỗi:
Thông thường chi phí cho việc tìm lỗi rẻ hơn việc sửa lỗi. Bảng sau đây cho

thấy chi phí sửa chữa các lỗi phụ thuộc vào theo giai đoạn được tìm thấy. Ví dụ, nếu
một vấn đề trong các yêu cầu chỉ được tìm thấy sau phát hành, sau đó nó sẽ có chi phí
1-10 lần để sửa chữa hơn là nếu nó đã được tìm thấy bởi các xem xét các yêu cầu.
Chi phí để khắc phục một
khiếm khuyết
Thời gian phát hiện
Yêu
cầu
Thiết
kế
Xây
dựng
Kiểm thử hệ
thống
Phát
hành
Thời gian giới
thiệu
Yêu cầu 1 × 3 × 5-10 × 10 × 1-10 ×
Kiến trúc - 1 × 10 × 15 × 25-100 ×
Xây dựng - - 1 × 10 × 10-25 ×
Hình 2.2 Bảng chi phí khắc phục một khiếm khuyết
11. Khả năng tương thích
Một nguyên nhân phổ biến của các lỗi phần là một thiếu khả năng tương thích
với các phần mềm ứng dụng, hệ điều hành (phiên bản hệ điều hành, cũ hay mới), hoặc
các môi trường mục tiêu mà khác rất nhiều so với bản gốc (chẳng hạn như một thiết bị
đầu cuối hoặc ứng dụng đồ họa dùng để chạy trên các máy tính để bàn hiện nay đang
được yêu cầu để trở thành một ứng dụng web, mà phải làm trong một trình duyệt web).
Ví dụ, trong một trường hợp thiếu tính tương thích ngược, điều này có thể xảy ra bởi vì
các lập trình viên phát triển và thử nghiệm phần mềm duy nhất trên phiên bản mới nhất

của môi trường mục tiêu, mà không phải tất cả người dùng có thể chạy. Điều này dẫn
đến hậu quả không lường trước rằng phiên bản mới nhất không có chức năng trên các
phiên bản trước đó của môi trường mục tiêu, hoặc trên phần cứng cũ hơn phiên bản
Vũ Thị Thu Trang - Lớp LT -CNTT - K10b
11
Báo cáo thực tập tốt nghiệp
trước của môi trường mục tiêu là khả năng sử dụng. Đôi khi các vấn đề như vậy có thể
được cố định bằng cách chủ động trừu tượng hóa chức năng hệ điều hành vào một
chương trình riêng biệt module hay thư viện.
12. Kiểm thử tĩnh và động
Có nhiều phương pháp để kiểm thử phần mềm: Trao đổi, thảo luận nhóm phát
triển, hoặc xét duyệt được coi là kiểm thử tĩnh, trong khi thực hiện mã lập trình với
một tập hợp các trường hợp thử nghiệm được gọi là thử nghiệm động. Kiểm thử tĩnh có
thể được bị bỏ đi. Kiểm thử động diễn ra khi chương trình chính nó là sử dụng lần đầu
tiên (mà thường được coi là sự khởi đầu của giai đoạn thử nghiệm). Kiểm thử động có
thể bắt đầu trước khi chương trình được hoàn thành 100% để kiểm tra phần cụ thể của
mã (mô-đun hoặc chức năng). Kỹ thuật tiêu biểu cho điều này là một trong hai phương
pháp Stubs/ drives hoặc thực hiện từ một trình gỡ rối.
13. Các đội kiểm thử phần mềm
Kiểm thử phần mềm được thực hiện bằng cách thử phần mềm. Cho đến những
năm 1980 thuật ngữ "phần mềm kiểm thử" đã được sử dụng chung, nhưng sau đó nó
cũng được xem là một nghề riêng biệt. Về các thời kỳ và các mục tiêu khác nhau trong
kiểm thử phần mềm, vai trò khác nhau đã được thiết lập: quản lý, Nhóm trưởng, kiểm
thử thiết kế, Kiểm thử viên, phát triển tự động hóa, và quản trị kiểm thử.
14. Quản lý chất lượng phần mềm (SQA)
Mặc dù gây tranh cãi, kiểm thử phần mềm có thể được xem như là một phần
quan trọng trong quá trình quản lý chất lượng phần mềm (SQA).

Trong SQA, phần
mềm chuyên xử lý và kiểm thử viên có một cái nhìn rộng hơn về phần mềm và phát

triển của nó. Họ kiểm tra và thay đổi quy trình công nghệ phần mềm riêng của mình để
giảm số lượng lỗi mà kết thúc trong các phần mềm được gửi: được gọi là Tỷ lệ lỗi.
Vũ Thị Thu Trang - Lớp LT -CNTT - K10b
12
Báo cáo thực tập tốt nghiệp
Điều tạo nên "tỷ lệ lỗi chấp nhận được" phụ thuộc vào bản chất của các phần
mềm; Một trò chơi mô phỏng chuyến bay video sẽ có sự khoan dung lỗi cao hơn nhiều
so với phần mềm cho một máy bay.
Mặc dù có liên kết chặt chẽ với SQA, đội kiểm thử thường tồn tại độc lập, và có
thể không có chức năng SQA trong một số công ty.
Kiểm thử phần mềm là một công việc dự định để phát hiện lỗi trong phần mềm
bằng cách so sánh kết quả của một chương trình máy tính dự kiến với kết quả thực tế
của nó trong một tập hợp của các yếu tố đầu vào. Ngược lại, QA (đảm bảo chất lượng)
là việc thực hiện các chính sách và thủ tục nhằm ngăn ngừa các khuyết điểm ngay từ
đầu.
15. Phương pháp kiểm thử
15.1 Kiểm nghiệm hộp trắng (white-box
testing)
Còn gọi là kiểm nghiệm cấu trúc. Kiểm nghiệm theo cách này là loại kiểm
nghiệm sử dụng các
thông
tin về cấu trúc bên trong của ứng dụng. Việc kiểm nghiệm
này dựa trên quá trình thực hiện xây
dựng
phần
mềm.
Tiêu chuẩn của kiểm nghiệm hộp trắng phải đáp ứng các yêu cầu như
sau:
 Bao phủ dòng lệnh: mỗi dòng lệnh ít nhất phải được thực thi 1
l

ần
 Bao phủ nhánh: mỗi nhánh trong sơ đồ điều khiển (control graph) phải
được đi qua
mộ
t

l
ần.
 Bao phủ đường: tất cả các đường (path) từ điểm khởi tạo đến điểm cuối
cùng trong
sơ
đồ dòng điều khiển phải được đi
qua.
15.2 Kiểm nghiệm hộp đen ( black-box testing )
Còn gọi là kiểm nghiệm chức năng. Việc kiểm nghiệm này được thực hiện
mà không cần quan
tâm
đến các thiết kế và viết mã của chương trình. Kiểm
nghiệm theo cách này chỉ quan tâm đến
chức
năng đã đề ra của chương trình. Vì
Vũ Thị Thu Trang - Lớp LT -CNTT - K10b
13
Báo cáo thực tập tốt nghiệp
vậy kiểm nghiệm loại này chỉ dựa vào bản mô tả chức
năng

của
chương trình, xem
chương trình có thực sự cung cấp đúng chức năng đã mô tả trong bản

chức
năng hay
không mà
thôi.
Kiểm nghiệm hộp đen dựa vào các định nghĩa về chức năng của chương trình.
Các trường hợp
thử
nghiệm (test case) sẽ được tạo ra dựa nhiều vào bản mô tả chức
năng chứ không phải dựa vào
cấu
trúc của chương
t
rình.
16. Các cấp độ kiểm thử
Các xét nghiệm thường được nhóm lại theo nơi họ được thêm vào trong quá trình
phát triển phần mềm, hoặc bằng mức độ đặc hiệu của thử nghiệm.
16.1 Kiểm thử đơn vị
Đơn vị kiểm tra đề cập đến bài kiểm tra xác minh các chức năng của một phần cụ
thể của mã, thường là ở cấp độ chức năng. Trong một môi trường theo định hướng đối
tượng, điều này thường là ở cấp lớp, và các xét nghiệm đơn vị tối thiểu bao gồm các hàm
tạo và hàm hủy.
Những loại bài kiểm tra thường được viết bởi nhà phát triển khi họ làm việc trên
mã (trắng-box phong cách), để đảm bảo rằng các chức năng cụ thể là làm việc như mong
đợi. Một chức năng có thể có nhiều thử nghiệm, để bắt kịp các trường hợp góc, ngành
khác trong các mã. Đơn vị kiểm tra một mình không thể xác minh các chức năng của
một phần mềm, mà là được sử dụng để đảm bảo rằng các khối xây dựng phần mềm sử
dụng làm việc độc lập với nhau.
Đơn vị kiểm tra còn được gọi là thành phần thử nghiệm.
16.2 Kiểm thử hệ
thống

Hệ thống gồm hai hoặc nhiều thành phần tích hợp nhằm thực hiện các chức năng
hoặc đặc tính của hệ thống. Sau khi tích hợp các thành phần tạo nên hệ thống, quá trình
kiểm thử hệ thống được tiến hành. Trong quá trình phát triển lặp đi lặp lại, kiểm thử hệ
Vũ Thị Thu Trang - Lớp LT -CNTT - K10b
14
Báo cáo thực tập tốt nghiệp
thống liên quan với kiểm thử một
lượng
công việc ngày càng tăng để phân phối cho
khách hàng; trong quy trình thác nước, kiểm thử hệ
thống
liên quan với kiểm thử toàn
bộ hệ
thống.
Với hầu hết các hệ thống phức tạp, kiểm thử hệ thống gồm hai giai đoạn riêng
biệt:
 Kiểm thử tích hợp: đội kiểm thử nhận mã nguồn của hệ thống. Khi
một vấn đề được
phát
hiện, đội tích hợp thử tìm nguồn gốc của vấn đề và nhận biết
thành phần cần phải gỡ
lỗi.
Kiểm thử tích hợp hầu như liên quan với việc tìm các
khiếm khuyết của hệ
thống.
 Kiểm thử phát hành: Một phiên bản của hệ thống có thể được phát
hành tới người dùng được kiểm thử. Đội kiểm thử tập trung vào việc hợp lệ các
yêu cầu của hệ thống và
đảm
bảo tính tin cậy của hệ thống. Kiểm thử phát hành

thường là kiểm thử “hộp đen”, đội
kiểm

thử
tập trung vào mô tả các đặc tính hệ
thống có thể làm được hoặc không làm được.
Các

vấn
đề được báo cáo cho đội phát
triển để gỡ lỗi chương trình. Khách hàng được bao
hàm
trong kiểm thử phát hành,
thường được gọi là kiểm thử chấp nhận. Nếu hệ thống
phát

hành
đủ tốt, khách hàng
có thể chấp nhận nó để sử
dụng.
Về cơ bản, bạn có thể nghĩ kiểm thử tích hợp như là kiểm thử hệ thống chưa
đầy đủ bao
gồm
một nhóm các thành phần. Kiểm thử phát hành liên quan đến
kiểm thử hệ thống phát hành
có
ý định phân phối tới khách hàng. Tất nhiên, có sự
gối chồng
lên
nhau, đặc biệt khi phát triển hệ thống và hệ thống đuợc phát hành khi

chưa hoàn thành. Thông thường, sự ưu tiên hàng đầu trong kiểm thử tích hợp là
phát hiện ra khiếm khuyết trong
hệ
thống và sự ưu tiên hàng đầu trong kiểm thử hệ
thống là làm hợp lệ các yêu cầu của hệ
thống.

Tuy
nhiên trong thực tế, có vài kiểm
thử hợp lệ và vài kiểm thử khiếm khuyết trong các
quá

trình.
16.3. Kiểm thử tích
hợp
Quá trình kiểm thử tích hợp bao gồm việc xây dựng hệ thống từ các thành
Vũ Thị Thu Trang - Lớp LT -CNTT - K10b
15
Báo cáo thực tập tốt nghiệp
phần và kiểm
thử
hệ thống tổng hợp với các vấn đề phát sinh từ sự tương tác giữa
các thành phần. Các
thành
phần được tích hợp có thể trùng với chính nó, các thành
phần có thể dùng lại được có thể
thêm
vào các hệ thống riêng biệt hoặc thành phần
mới được phát triển. Với rất nhiều hệ thống lớn,
có

tất cả 3 loại thành phần được sử
dụng. Kiểm thử tích hợp kiểm tra trên thực tế các thành
phần
làm việc với nhau,
được gọi là chính xác và truyền dữ liệu đúng vào lúc thời gian đúng thông
qua
giao
diện của
chúng.
Hệ thống tích hợp bao gồm một nhóm các thành phần thực hiện vài chức năng
của hệ thống
và
được tích hợp với nhau bằng cách gộp các mã để chúng làm việc
cùng với nhau.
Thỉnh
thoảng, đầu tiên toàn bộ khung của hệ thống được phát triển,
sau đó các thành phần được
gộp
lại để tạo nên hệ thống. Phương pháp này được gọi
là tích hợp từ trên xuống (top-down).
Một
cách lựa chọn khác là đầu tiên bạn tích hợp
các thành phần cơ sở cung cấp các dịch vụ
chung,
như mạng, truy cập cơ sở dữ liệu,
sau đó các thành phần chức năng được thêm vào.
Phương
pháp này được gọi là
tích hợp từ dưới lên (bottom-up). Trong thực tế, với rất nhiều hệ
thống,

chiến lược
tích hợp là sự pha trộn các phương pháp trên. Trong cả hai phương pháp
top-down
và
bottom-up, bạn thường phải thêm các mã để mô phỏng các thành phần khác và cho
phép
hệ
thống thực
hiện.
Một vấn đề chủ yếu nảy sinh trong lúc kiểm thử tích hợp là các lỗi cục bộ. Có
nhiều sự
tương
tác phức tạp giữa các thành phần của hệ thống, và khi một đầu ra bất
thường được phát
hiện,

bạn
có thể khó nhận ra nơi mà lỗi xuất hiện. Để việc tìm
lỗi cục bộ được dễ dàng, bạn
nên
thường xuyên tích hợp các thành phần của hệ thống
và kiểm thử chúng. Ban đầu, bạn nên tích
hợp
một hệ thống cấu hình tối thiểu và
kiểm thử hệ thống này. Sau đó bạn thêm dần các thành
phần
vào hệ thống đó và
kiểm thử sau mỗi bước thêm
vào.
Vũ Thị Thu Trang - Lớp LT -CNTT - K10b

16
Báo cáo thực tập tốt nghiệp
Hình 3.3 Kiểm thử tích hợp lớn
dần
Hình 2.3
Trong ví dụ trên hình 2.4, A,B,C,D là các thành phần và T1, T2, T3, T4, T5
là tập các thử nghiệm kết hợp các đặc trưng của hệ thống. Đầu tiên, các thành
phần A và B được kết hợp
để
tạo nên hệ thống (hệ thống cấu hình tối thiểu), và
các thử nghiệm T1, T2, T3 được thực
hiện.
Nếu phát hiện có khiếm khuyết, nó
sẽ được hiệu chỉnh. Sau đó, thành phần C được tích
hợp

và
các thử nghiệm T1,
T2 và T3 được làm lặp lại để đảm bảo nó không tạo nên các kết
quả
không mong
muốn khi tương tác với A và B. Nếu có vấn đề nảy sinh trong các kiểm thử này,
nó
hầu như chắc chắn do sự tương tác với các thành phần mới. Nguồn gốc của vấn
đề đã
được
khoanh vùng, vì vậy làm đơn giản việc tìm và sửa lỗi. Tập thử nghiệm
T4 cũng được thực
hiện
trên hệ thống. Cuối cùng, thành phần D được tích hợp vào

hệ thống và kiểm thử được thực
hiện
trên các thử nghiệm đã có và các thử nghiệm
mới.
Khi lập kế hoạch tích hợp, bạn phải quyết định thứ tự tích hợp các thành
phần. Trong một
quá
trình như XP, khách hàng cũng tham gia trong quá phát
triển, khách hàng quyết định
các
chức năng nên được thêm vào trong mỗi bước
tích hợp hệ thống. Do đó, tích hợp hệ thống
được
điều khiển bởi sự ưu tiên của
khách hàng. Trong cách tiếp cận khác để phát triển hệ thống,
khi
các thành phần
và các thành phần riêng biệt được tích hợp, khách hàng có thể không tham
gia
vào quá trình tích hợp hệ thống và đội tích hợp quyết định thứ tự tích hợp các
thành
phần.
Vũ Thị Thu Trang - Lớp LT -CNTT - K10b
17
Báo cáo thực tập tốt nghiệp
Trong trường hợp này, một quy tắc tốt là đầu tiên tích hợp các thành phần
thực hiện hầu
hết
các chức năng thường sử dụng của hệ thống. Điều này có
nghĩa là các thành phần

thường

được
sử dụng hầu hết đã được kiểm thử. Ví dụ,
trong hệ thống thư viện, LIBSYS, đầu tiên
bạn
nên tích hợp chức năng tìm kiếm
trong hệ thống tối thiểu, để người dùng có thể tìm kiếm
các
tài mà họ cần. Sau
đó, bạn nên tích hợp các chức năng cho phép người dùng tải tài liệu từ
trên
Internet và dần thêm các thành phần thực hiện các chức năng khác của hệ
thống.
Tất nhiên, thực tế ít khi đơn giản như mô hình trên. Sự thực hiện các chức
năng của hệ
thống
có thể liên quan đến nhiều thành phần. Để kiểm thử một đặc
tính mới, bạn có thể phải tích
hợp
một vài thành phần khác nhau. Kiểm thử có thể
phát hiện lỗi trong khi tương tác giữa các
thành
phần riêng biệt và các phần khác
của hệ thống. Việc sửa lỗi có thể khó khăn bởi vì một nhóm
các
thành phần thực
hiện chức năng đó có thể phải thay đổi. Hơn nữa, tích hợp và kiểm thử
một
thành

phần mới có thể thay đổi tương tác giữa các thành phần đã được kiểm thử. Các lỗi
có
thể
được phát hiện có thể đã không được phát hiện trong khi kiểm thử hệ thống
cấu hình đơn
giản.
Những vấn đề này có nghĩa là khi một hệ thống tích hợp mới được tạo ra,
cần phải chạy
lại
các thử nghiệm trong hệ thống tích hợp cũ để đảm bảo các
yêu cầu các thử nghiệm đó
vẫn
thực hiện tốt, và các kiểm thử mới thực hiện tốt
các chức năng mới của hệ thống. Việc thực
hiện
kiểm thử lại tập các thử nghiệm
cũ gọi là kiểm thử hồi quy. Nếu kiểm thử hồi quy phát hiện
có
vấn đề, thì bạn
phải kiểm tra có lỗi trong hệ thống cũ hay không mà hệ thống mới đã phát
hiện
ra,
hoặc có lỗi do thêm các chức năng
mới.
Rõ ràng, kiểm thử hồi quy là quá trình tốn kém, không khả thi nếu không có
sự hỗ trợ tự
động.
Trong lập trình cực độ, tất cả các thử nghiệm được viết như
mã có thể thực thi, các đầu
vào

thử nghiệm và kết quả mong đợi được xác định
rõ và được tự động kiểm tra. Khi được sử
dụng
cùng với một khung kiểm thử tự
động như Junit (Massol và Husted, 2003), điều này có nghĩa
là
các thử nghiệm có
thể được tự động thực hiện lại. Đây là nguyên lý cơ bản của lập trình
cực

độ,
khi
tập các thử nghiệm toàn diện được thực hiện bất cứ lúc nào mã mới được tích
hợp
và
các mã mới này không được chấp nhận cho đến khi tất cả các thử nghiệm
Vũ Thị Thu Trang - Lớp LT -CNTT - K10b
18
Báo cáo thực tập tốt nghiệp
được thực hiện
thành

công.
16.4 Kiểm thử phát
hành
Kiểm thử phát hành là quá trình kiểm thử một hệ thống sẽ được phân
phối tới các khách hàng. Mục tiêu đầu tiên của quá trình này là làm tăng sự tin
cậy của nhà cung cấp rằng
sản
phẩm họ cung cấp có đầy đủ các yêu cầu. Nếu

thỏa mãn, hệ thống có thể được phát hành
như
một sản phẩm hoặc được phân phối
đến các khách hàng. Để chứng tỏ hệ thống có đầy đủ
các

yêu
cầu, bạn phải chỉ
ra nó có các chức năng đặc tả, hiệu năng, và tính tin cậy cao, nó
không
gặp sai
sót trong khi được sử dụng bình
thường.
Kiểm thử phát hành thường là quá trình kiểm thử hộp đen, các thử nghiệm
được lấy từ đặc
tả
hệ thống. Hệ thống được đối xử như chiếc hộp đen, các hoạt
động của nó chỉ có thể được
nhận
biết qua việc nghiên cứu đầu vào và đầu ra của
nó. Một tên khác của quá trình này là kiểm
thử
chức năng, bởi vì người kiểm tra
chỉ tập trung xem xét các chức năng và không quan tâm
sự
thực thi của phần
mềm.
Hình 2.5 Kiểm thử hộp
đen
Vũ Thị Thu Trang - Lớp LT -CNTT - K10b

19
Báo cáo thực tập tốt nghiệp
Hình 2.5 minh họa mô hình một hệ thống được kiểm thử bằng phương
pháp kiểm thử hộp
đen.
Người kiểm tra đưa đầu vào vào thành phần hoặc hệ
thống và kiểm tra đầu ra tương ứng.
Nếu

đầu
ra không như dự báo trước (ví dụ,
nếu đầu ra thuộc tập O
e
), kiểm thử phát hiện một
lỗi

trong
phần
mềm.
Khi hệ thống kiểm thử được thực hiện, bạn nên thử mổ sẻ phần mềm bằng
cách lựa chọn
các
trường hợp thử nghiệm trong tập I
e
(trong hình 2.5). Bởi vì,
mục đích của chúng ta là
lựa
chọn các đầu vào có xác suất sinh ra lỗi cao (đầu ra
nằm trong tập O
e

). Bạn sử dụng các
kinh
nghiệm thành công trước đó và các
nguyên tắc kiểm thử để đưa ra các lựa
chọn.
Các tác giả như Whittaker (Whittaker, 2002) đã tóm lược những kinh
nghiệm kiểm thử
của
họ trong một tập các nguyên tắc nhằm tăng khả năng tìm
ra các thử nghiệm khiếm
khuyết.
Dưới đây là một vài nguyên
tắc:
 Lựa chọn những đầu vào làm cho hệ thống sinh ra tất cả các thông
báo
lỗi.
 Thiết kể đầu vào làm cho bộ đệm đầu vào bị
tràn.
 Làm lặp lại với các đầu vào như nhau hoặc một dãy các đầu vào
nhiều
lần.
 Làm sao để đầu ra không đúng được sinh
ra.
 Tính toán kết quả ra rất lớn hoặc rất
nhỏ.
Để xác nhận hệ thống thực hiện chính xác các yêu cầu, cách tiếp cận tốt
nhất vấn
đề
này là kiểm thử dựa trên kịch bản, bạn đưa ra một số kịch bản và
tạo nên các

trường
hợp thử nghiệm từ các kịch bản đó. Ví dụ, kịch bản dưới
đây có thể mô tả cách
hệ
thống thư viện LIBSYS, đã thảo luận trong chương
trước, có thể được sử
dụng:
Một sinh viên ở Scốt-len nghiên cứu lịch sử nước Mỹ đã được yêu cầu
viết một bài luận
về
“Tâm lý của người miền Tây nước Mỹ từ năm 1840 đến
năm 1880”. Để làm việc đó, cô
ấy
cần tìm các tài liệu từ nhiều thư viện. Cô ấy
đăng nhập vào hệ thống LIBSYS và sử
dụng

chức
năng tìm kiếm để tìm xem cô
ấy có được truy cập vào các tài liệu gốc trong khoảng
thời
gian ấy không. Cô ấy
tìm được các nguồn tài liệu từ rất nhiều thư viện của các trường đại
học
của Mỹ,
Vũ Thị Thu Trang - Lớp LT -CNTT - K10b
20
Báo cáo thực tập tốt nghiệp
và cô ấy tải một vài bản sao các tài liệu đó. Tuy nhiên, với một vài tài liệu, cô ấy
cần

phải có sự xác nhận từ trường đại học của cô ấy rằng cô ấy thật sự là một sinh
viên và các
tài
liệu được sử cho những mục đích phi thương mại. Sau đó, sinh
viên đó sử dụng các phương
tiện
của LIBSYS để yêu cầu sự cho phép và đăng ký
các yêu cầu của họ. Nếu được xác nhận, các
tài
liệu đó sẽ được tải xuống từ máy
chủ của thư viện và sau đó được in. Cô ấy nhận được
một
thông báo từ LIBSYS
nói rằng cô ấy sẽ nhận được một e-mail khi các tài liệu đã in có giá
trị

để
tập
hợp.
Từ kịch bản trên, chúng ta có thể áp dụng một số thử nghiệm để tìm ra
mục đích
của LIBSYS:
 Kiểm thử cơ chế đăng nhập bằng cách thực hiện các đăng nhập đúng
và đăng nhập sai
để
kiểm tra người dùng hợp lệ được chấp nhận
và người dùng không hợp lệ không
được

chấp

nhận.
 Kiểm thử cơ chế tìm kiếm bằng cách sử dụng các câu hỏi đã biết
các tài liệu cần tìm
để
kiểm tra xem cơ chế tìm kiếm có thực sự tìm
thấy các tài liệu
đó.
 Kiểm thử sự trình bày hệ thống để kiểm tra các thông tin về tài liệu
có được hiển thị
đúng

không.
 Kiểm thử cơ chế cho phép yêu cầu tải tài liệu
xuống.
 Kiểm thử e-mail trả lời cho biết tài liệu đã tải xuống là sẵn sàng sử
dụng.
Vũ Thị Thu Trang - Lớp LT -CNTT - K10b
21