TÌM HIỂU VỀ KIỂM THỬ PHẦN MỀM VÀ ỨNG DỤNG KIỂM THỬ ĐỂ ĐÁNH GIÁ CHẤT LƯỢNG WEBSITE “SHOP HOA ONLINE” - Full 10 điểm

UBND TỈNH QUẢNG NAM
TRƯỜNG ĐẠI HỌC QUẢNG NAM
KHOA CÔNG NGHỆ THÔNG TIN

----------

KHÓA LUẬN TỐT NGHIỆP ĐẠI HỌC

Tên đề tài:

TÌM HIỂU VỀ KIỂM THỬ PHẦN MỀM VÀ
ỨNG DỤNG KIỂM THỬ ĐỂ ĐÁNH GIÁ
CHẤT LƯỢNG WEBSITE
“SHOP HOA ONLINE”

Sinh viên thực hiện: LÊ THỊ THẢO
Lớp: DT13CTT01
CHUYÊN NGÀNH: CÔNG NGHỆ THÔNG TIN
KHÓA 2013 – 2017
Giảng viên hướng dẫn: ThS. NGUYỄN THỊ MINH CHÂU

Quảng Nam tháng 4 năm 2017

LỜI CẢM ƠN

Để hoàn thành khóa luận này, em xin tỏ lịng biết ơn sâu sắc đến ThS.
Nguyễn Thị Minh Châu, đã tận tình hướng dẫn trong suốt quá trình viết báo
cáo tốt nghiệp.

Em chân thành cảm ơn quý Thầy, Cô trong khoa Công Nghệ Thông
Tin, Trường Đại Học Quảng Nam đã tận tình truyền đạt kiến thức trong

những năm em học tập. Với vốn kiến thức được tiếp thu trong q trình học
khơng chỉ là nền tảng cho q trình nghiên cứu khóa luận mà cịn là hành
trang qúy báu để em bước vào đời một cách vững chắc và tự tin.

Trong quá trình làm bài báo cáo khóa luận tốt nghiệp, do trình độ cịn
hạn hẹp, đề tài rộng, thời gian có hạn, nên khơng tránh khỏi những thiếu
sót, mong q Thầy Cơ góp ý kiến để em học hỏi thêm được nhiều kinh
nghiệm.

Em xin chân thành cảm ơn!

MỤC LỤC

Phần 1. MỞ ĐẦU ......................................................................................1
1.1. Lý do chọn đề tài..................................................................................1
1.2. Mục tiêu của đề tài ...............................................................................1
1.3. Đối tượng và phạm vi nghiên cứu........................................................1
1.3.1. Đối tượng nghiên cứu........................................................................1
1.3.2. Phạm vi nghiên cứu...........................................................................1
1.4. Nội dung và phương pháp nghiên cứu .................................................2
1.5. Lịch sử nghiên cứu...............................................................................2

1.6. Đóng góp của đề tài………………………………………………….2

1.7. Bố cục của đề tài ..................................................................................2
Phần 2. NỘI DUNG NGHIÊN CỨU .......................................................3
Chương 1: CƠ SỞ LÝ THUYẾT VỀ KIỂM THỬ PHẦN MỀM ........3
1.1. Tổng quan về kiểm thử phần mềm.......................................................3
1.2. Các mục tiêu chính của kiểm thử phần mềm .......................................4
1.3. Lỗi (Bug) ..............................................................................................4

1.4. Nguyên tắc kiểm tra lỗi chung ............................................................5
1.5. Kiểm thử với mơ hình trong phát triển phần mềm .............................7
1.6. Test case là gì? ...................................................................................14
1.7. Các kỹ thuật trong kiểm thử...............................................................15
1.8. Các giai đoạn kiểm thử .....................................................................23
1.9. Mơ hình kiểm thử...............................................................................26
1.10. Sơ đồ tổ chức phổ biến của đội kiểm thử.........................................26
1.11. Quy trình kiểm thử phần mềm theo tiêu chuẩn CMMI5 .................27
1.11.1. Lập kế hoạch test...........................................................................27
1.11.2. Phân tích và thiết kế test ...............................................................29
1.11.3. Review thiết kế test .......................................................................30
1.11.4. Chuẩn bị môi trường test...............................................................30
1.11.5. Thực hiện test ...............................................................................30
1.11.6. Review kết quả Test ......................................................................31
1.11.7. Báo cáo kết quả Test .....................................................................31
1.12. Trách nhiệm của người kiểm thử. ....................................................31

1.13. Một số loại hình kiểm thử phổ biến. ................................................32
CHƯƠNG 2: XÂY DỰNG WEBSITE “SHOP HOA ONLINE”.......33
2.1. Đặt vấn đề...........................................................................................33
2.2. Giải pháp ............................................................................................33
2.3. Đặc tả bài tốn....................................................................................33
2.4. Phân tích u cầu ...............................................................................35
2.5 Cơ sở dữ liệu của website “Shop hoa online”.....................................37
2.6. Demo chương trình ............................................................................40
CHƯƠNG 3: THIẾT KẾ TEST CASE VÀ THỰC THI TEST .........42
3.1. Thực hiện Unit test.............................................................................43
3.1.1. Quy trình test...................................................................................43
3.2. Thực hiện test case black_box testing theo đặc tả yêu cầu................47
3.2.1. Quy trình test...................................................................................47

Phần 3. KẾT LUẬN ................................................................................49
TÀI LIỆU THAM KHẢO ......................................................................51

Phần 1. MỞ ĐẦU

1.1. Lý do chọn đề tài
Ngày nay công nghệ thông tin ngày càng phát triển, kéo theo đó là hệ

thống mạng và phần mềm cũng gia tăng cả về số lượng theo chiều rộng và
chất lượng phần mềm theo chiều sâu. Nhưng cũng từ đó đã nảy sinh ra
nhiều vấn đề về lỗi hỏng hóc phần mềm khơng đáng có, gây ra khơng ít ảnh
hưởng đến kinh tế và xã hội… Những lỗi này có thể do tự bản thân phần
mềm bị hỏng do không được kiểm tra kĩ lưỡng trước khi đến tay khách
hàng, hay cũng có thể do có người cố tình phá hoại nhằm đánh cắp thơng
tin cá nhân như mã số tài khoản ngân hàng, số điện thoại, danh bạ, tin nhắn,
…., từ đây ta dể dàng nhận ra là mặc dù phần mềm phát triển ngày càng
nhiều nhưng vấn đề chất lượng vẫn là một dấu hỏi lớn cần xem xét cẩn
thận. Do đó yêu cầu đặt ra là cần có cơng tác kiểm thử phần mềm thật kĩ
lưỡng nhằm ngăn chặn các lỗi hay hỏng hóc còn tiềm tàng bên trong phần
mềm mà ta chưa kịp nhận ra.

Đó chính là lý do em chọn đề tài này để nghiên cứu tìm hiểu kỹ về
“Kiểm Thử Phần Mềm” và ứng dụng để đánh giá “website Shop Hoa
Online”.
1.2. Mục tiêu của đề tài

- Tìm hiểu rõ hơn về kiểm thử phần mềm
- Xây dựng một Website “Shop Hoa Online” hoàn chỉnh bao gồm
các chức năng cần thiết trong thương mại điện tử.
- Sử dụng kiểm thử để đánh giá website vừa xây dựng.

1.3. Đối tượng và phạm vi nghiên cứu
1.3.1. Đối tượng nghiên cứu
- Đối tượng nghiên cứu: Kiểm thử phần mềm
1.3.2. Phạm vi nghiên cứu
- Về nội dung: Áp dụng kiểm thử vào website “Shop hoa online”

1

- Về không gian: Kiểm thử phần mềm
- Về thời gian: Đề tài được thực hiện trong 5 tháng kể từ tháng 11
năm 2016.
1.4. Nội dung và phương pháp nghiên cứu
- Phương pháp nghiên cứu tự luận: Nghiên cứu tài liệu, tìm hiểu nhiều
vấn đề kiểm thử thơng qua các diễn đàn trên internet.
- Phương pháp tổng kết kinh nghiệm: Qua việc làm việc thực tế trên
một vài công ty.
- Phương pháp lấy ý kiến chuyên gia: Lấy ý kiến giảng viên trực tiếp
hướng dẫn, các giảng viên bộ mơn để hồn thiện về mặt nội dung và hình thức
của khóa luận.
- Để thực hiện đề tài này, em sử dụng phương pháp phân tích và thiết
kế hệ thống theo hướng đối tượng, hoạt động khảo sát, phân tích, thiết kế…
1.5. Lịch sử nghiên cứu

Đề tài nghiên cứu về kiểm thử phần mềm được bắt đầu từ tháng 12
năm 2016, trải qua quá trình nghiên cứu hơn 4 tháng và kết thúc vào tháng
4 năm 2017.

1.6. Đóng góp của đề tài

Trải qua quá trình nghiên cứu giúp chúng ta hiểu rõ hơn về kiểm thử

phần mềm. Nắm rõ hơn về các định nghĩa cũng như các quy trình, cách
thức thực hiện trong kiểm thử phần mềm.
1.7. Cấu trúc của đề tài

Ngoài hai phần mở đầu và kết luận, nội dung đề tài gồm 3 nội dung
chính:

Chương 1: Cơ sở lý thuyết về kiểm thử phần mềm
Chương 2: Xây dựng website “Shop Hoa Online”
Chương 3: Thiết kế Test Case, thực thi test

2

Phần 2. NỘI DUNG NGHIÊN CỨU
Chương 1: CƠ SỞ LÝ THUYẾT VỀ KIỂM THỬ

PHẦN MỀM

1.1. Tổng quan về kiểm thử phần mềm
1.1.1 Kiểm thử phần mềm là gì?

- Kiểm thử phần mềm là một cuộc kiểm tra nhằm cung cấp cho các
bên liên quan (khách hàng, nhóm phát triển) thông tin về chất lượng sản
phẩm dịch đang kiểm thử.

- Mục đích của kiểm thử phần mềm là chỉ ra rằng phần mềm thực
hiện đúng các chức năng mong muốn.

- Kiểm thử phần mềm là quy trình thiết lập sự tin tưởng về việc phần
mềm hay hệ thống thực hiện được điều mà nó hỗ trợ.

- Kiểm thử phần mềm là quy trình thi hành phần mềm với ý định tìm
kiếm các lỗi của nó.

- Kiểm thử phần mềm được xem là quy trình cố gắng tìm kiếm các
lỗi của phần mềm.
1.1.2. Tại sao kiểm thử phần mềm là cần thiết?

- Kiểm thử phần mềm là thực sự cần thiết vì nó chỉ ra những khiếm
khuyết và sai sót đã được thực hiện trong giai đoạn phát triển.

- Nó quan trọng vì nó đảm bảo độ tin cậy của khách hàng và sự hài
lòng của họ trong ứng dụng.

- Nó là rất quan trọng vì nó đảm bảo chất lượng của sản phẩm.
- Kiểm thử là cần thiết cho một hoạt động hiệu quả của ứng dụng
phần mềm hoặc sản phẩm.
- Điều quan trọng là để đảm bảo rằng các ứng dụng khơng có bất kỳ
kết quả nào khơng như mong đợi, bởi vì chi phí sẽ tăng cao nếu phát hiện
lỗi trong các giai đoạn sau phát triển phần mềm.
- Đó là yêu cầu thiết yếu giúp sản phẩm tồn tại trong kinh doanh.

3

1.2. Các mục tiêu chính của kiểm thử phần mềm
- Phát hiện càng nhiều lỗi càng tốt trong thời gian kiểm thử xác định

trước.
- Chứng minh rằng sản phẩm phần mềm phù hợp với các đặc tả yêu

cầu của nó.
- Tạo các test case chất lượng cao, thực hiện kiểm thử hiệu quả và tạo

ra các báo cáo vấn đề đúng và hữu dụng.
1.3. Lỗi (Bug)

1.3.1. Định nghĩa
Lỗi: Là những gì hoạt động khơng đúng như mong đợi từ khách hàng

hoặc nhà sản xuất.
1.3.2. Tại sao lại xảy ra lỗi?

- Các lỗi có thể bị phát sinh do nhiều lý do, nhưng trong quá trình phân
tích các dự án mẫu thì lý do chính có thể được tìm thấy trong q trình truy
vết theo bản đặc tả.

- Những lý do liên quan đến bản đặc tả là nguyên nhân chính làm xuất
hiện lỗi tài liệu đặc tả.

- Một số bản đặc tả không viết cụ thể, khơng đủ kỹ lưỡng, hoặc nó liên
tục thay đổi, nhưng lại khơng có sự phối hợp, trao đổi thông tin kịp thời với
các đội phát triển dự án.

- Lý do quan trọng tiếp theo mà dễ phát sinh lỗi là quá trình thiết kế.
Các lỗi xuất hiện ở đây với những lý do tương tự như khi chúng xuất hiện
trong bản đặc tả. Nó bị dồn lại, thay đổi, hoặc giao tiếp khơng tốt.

- Cuối cùng là viết mã
- Những lỗi về viết mã có thể được xem là quen thuộc nhất, lỗi về viết
mã thường xảy ra do giao tiếp không tốt giữa người lập trình và người phân

tích dự án, áp lực của lịch trình hay phần mềm phức tạp và nguyên nhân
thường gặp nhất phát sinh ra lỗi ở người lập trình là sao chép mà quên
chỉnh sửa.

4

1.3.3. Chi phí cho việc sửa lỗi ?

Hình 1.1. Chi phí cho việc sửa lỗi
- Chi phí cho việc sửa lỗi có thể tăng đột ngột trên tồn bộ dự án
- Chi phí được tính theo hàm loga, mỗi lần chúng tăng lên gấp 10 lần.
Lỗi được tìm thấy và sửa lại trong thời gian gần nhất khi bản đặc tả bắt đầu
được viết thì chi phí có thể khơng là gì cả, hoặc chỉ là 1$ cho ví dụ của
Hình 1.1 ở trên. Cũng với lỗi tương tự, nếu nó khơng được tìm thấy cho đến
khi phần mềm được được lập trình và kiểm thử thì chi phí có thể lên tới 10$
đến 100$. Nếu để một khách hàng tìm ra nó, thì chi phí có thể lên tới hàng
nghìn thậm chí hàng triệu dollar.
Từ ví dụ trên, ta có thể kết luận, việc tìm ra lỗi là càng sớm càng tốt, để
giảm chi phí cho việc sửa lỗi.
1.4. Nguyên tắc kiểm tra lỗi chung
- Kiểm thử chứng minh sự hiện diện của lỗi: Kiểm thử chỉ chứng
minh được rằng phần mềm đang có lỗi, kiểm thử không thể chứng minh
được sản phẩm không cịn lỗi. Nghĩa là sản phẩm ln ln có lỗi dù có
kiểm thử bao nhiêu đi nữa. Do đó, điều quan trọng là chúng ta phải thiết kế
các trường hợp kiểm thử (test case) sao cho có thể tìm được càng nhiều lỗi
càng tốt.
- Kiểm thử tồn bộ là khơng khả thi: Kiểm tra tất cả các trường hợp
là không khả thi, do các yếu tố về thời gian và chi phí, vì vậy việc phân tích
rủi ro và đưa ra các mức độ ưu tiên để kiểm tra các trường hợp cần thiết

5

nhất, rồi sau đó tùy thuộc vào tiến trình của dự án mà kiểm tra các trường
hợp còn lại theo mức độ ưu tiên thấp hơn.

- Kiểm thử càng sớm càng tốt: Hoạt động kiểm thử được triển khai
càng sớm càng tốt, kiểm tra ngay từ giai đoạn đầu lấy yêu cầu khách hàng
hay thiết kế tài liệu sản phẩm. Thông thường, thời gian cho kiểm thử
thường bị co lại khi sản phẩm gần ra thị trường. Do đó, việc kiểm thử sớm
trong giai đoạn đầu sẽ giúp chúng ta có thời gian để tiến hành kiểm thử
trong từng giai đoạn một cách đầy đủ. Việc phát hiện lỗi càng trễ bao nhiêu
thì chi phí để sửa lỗi càng cao bấy nhiêu, tương tự việc thay đổi yêu cầu
không đúng ngay từ đầu thường tốn ít chi phí thay đồi tính năng trong hệ
thống.

- Lỗi phân bố tập trung: Trong q trình kiểm thử, chúng ta có thể dễ
dàng quan sát thấy, 80% số lỗi được tìm thấy trong 20% tính năng của hệ
thống. Điều này cho thấy, lỗi thường tập trung ở một vài tính năng chính
của chương trình.

- Nghịch lý thuốc trừ sâu: Trong cuộc sống nếu ta cứ phun một loại
thuốc trừ sâu với liều lượng như nhau thì một số loại sau nhờn thuốc sẽ
không được diệt sạch. Cũng như trong kiểm thử phần mềm, nếu bạn cứ
thực thi lặp đi lặp lại một bộ test case thì có khả năng rất thấp bạn sẽ tìm
được lỗi từ những trường hợp kiểm thử này. Nguyên nhân là do khi hệ
thống ngày càng hồn thiện, những lỗi được tìm thấy lúc trước đã được sửa
trong khi những trường hợp kiểm thử đã cũ. Do đó, khi một lỗi được sửa
hay một tính năng mới được thêm vào, chúng ta nên tiến hành làm
regression (kiểm thử hồi qui) nhằm mục đích đảm bảo những thay đổi này
không ảnh hưởng đến những vùng khác của sản phẩm. Tuy nhiên, các

trường hợp kiểm thử trong regression test cũng cần phải được cập nhật để
phản ánh sự thay đổi tương ứng của hệ thống.

6

- Kiểm thử phụ thuộc vào ngữ cảnh: Tùy vào loại cũng như bản
chất của ứng dụng mà chúng ta sẽ áp dụng những phương thức, kỹ thuật,
cũng như loại kiểm thử khác nhau. Chẳng hạn như phần mềm trong các
thiết bị y khoa cần sẽ được kiểm thử kỹ lưỡng hơn một trò chơi điện tử.
Quan trọng hơn, việc kiểm thử trên loại thiết bị này đòi hỏi phải dựa trên
đánh giá rủi ro, đáp ứng những quy định nghiêm ngặt trong y khoa cũng
như một bộ kiểm thử đặc thù. Tương tự, một website “lớn” cần phải được
kiểm thử một cách đầy đủ từ hiệu năng đến tính năng nhằm đảm bảo server
khơng bị ảnh hưởng khi có nhiều người truy cập vào hệ thống.

- Quan niệm sai lầm về việc hết lỗi: Việc khơng tìm thấy lỗi trên sản
phẩm không đồng nghĩa với việc sản phẩm đã sẵn sàng để tung ra thị
trường. Việc khơng tìm thấy lỗi cũng có thể là do bộ test case được tạo ra
chỉ nhằm kiểm tra những tính năng được làm đúng theo yêu cầu thay vì
nhằm tìm kiếm lỗi mới.
1.5. Kiểm thử với mơ hình trong phát triển phần mềm
1.5.1.Mơ hình thác nước

Hình 1.2. Mơ hình thác nước
- Trong mơ hình thác nước, năm pha trên phải được thực hiện một cách
tuần tự; kết thúc pha trước, rồi mới được thực hiện pha tiếp theo.

7

+ Phân tích yêu cầu và tài liệu đặc tả (Requirements and

Specifications): là giai đoạn xác định những “đòi hỏi” (“What”) liên quan
đến chức năng và phi chức năng mà hệ thống phần mềm cần có. Giai đoạn
này cần sự tham gia tích cực của khách hàng và kết thúc bằng một tài liệu
được gọi là “Bản đặc tả yêu cầu phần mềm” hay SRS (software requirement
specification), trong đó bao gồm tập hợp các yêu cầu đã được duyệt
(reviewed) và nghiệm thu (approved) bởi những người có trách nhiệm đối
với dự án (từ phía khách hàng). SRS chính là nền tảng cho các hoạt động
tiếp theo cho đến cuối dự án.

+ Phân tích và thiết kế hệ thống (System Analysis and Design): là
giai đoạn định ra “làm thế nào” (“How”) để hệ thống phần mềm đáp ứng
những “đòi hỏi” (“What”) mà khách hàng yêu cầu trong SRS. Đây là chính
là cầu nối giữa “địi hỏi” (“What”) và mã (Code) được hiện thực để đáp ứng
yêu cầu đó.

+ Mã hóa (Coding): là giai đoạn hiện thực “làm thế nào” (“How”)
được chỉ ra trong giai đoạn “Phân tích hệ thống và thiết kế” mã hóa thành
câu lệnh.

+ Kiểm thử (Test): giai đoạn này sẽ tiến hành kiểm thử mã (code) đã
được hiện thực, bao gồm kiểm thử tích hợp cho nhóm các thành phần và
kiểm thử tồn hệ thống (system test). Một khâu kiểm thử cuối cùng thường
được thực hiện là nghiệm thu (acceptance test), với sự tham gia của khách
hàng trong vai trị chính để xác định hệ thống phần mềm có đáp ứng yêu
cầu của họ hay không.

+ Bảo trì (Maintenance): đây là giai đoạn cài đặt, cấu hình và hướng
dẫn khách hàng. Giai đoạn này sửa chữa những lỗi của phần mềm (nếu có)
và phát triển những thay đổi mới được khách hàng yêu cầu (như sửa đổi,
thêm hay bớt chức năng/đặc điểm của hệ thống).

8

- Nhược điểm chính của mơ hình thác nước là rất khó khăn trong việc
thay đổi các pha đã được thực hiện, phát hiện lỗi trễ dẫn đến chi phí sửa lỗi
cao.

- Mơ hình này chỉ thích hợp khi các yêu cầu đã được tìm hiểu rõ ràng
và những thay đổi sẽ được giới hạn một cách rõ ràng trong suốt q trình
thiết kế.
1.5.2. Mơ hình V-Shape

Hình 1.3. Mơ hình chữ V
Bước 1: Phân tích u cầu

Đóng vai trị xác định u cầu bài tốn, tính chất của cơng việc, khi
step này được hồn thành, thì được đưa vào một bước test gọi là Kiểm thử
chấp nhận.
Bước 2: Thiết kế cấp cao

Bước này được xảy ra trên kỹ thuật hệ thống và thiết kế, nó là bước
mức độ cao vì thời điểm này, nó phải cung cấp được tổng quan về giải pháp
xử lý, nền tảng xây dựng, hệ thống sản phẩm, và các dịch vụ. Sau khi bước
này được hồn thành, nó được đưa vào cơng đoạn test kiểm tra đó là giai
đoạn kiểm thử hệ thống.

9

Bước 3: Thiết kế chi tiết
Đây là bước mức độ thấp của thiết kế, là giai đoạn mà sản phẩm phần

mềm đã được tiến hành thiết kế thực tế, bắt đầu đi vào xác định các yếu tố
logic, các sơ đồ lớp với mọi phương thức, giai đoạn này có thể phát sinh
các mâu thuẫn, sự phù hợp hay không phù hợp….Sau khi bước này được
thực hiện thành cơng thì được chuyển đến cơng đoạn test gọi là : Kiểm thử
tích hợp
Bước 4: Viết Mã

Là bước bắt đầu tiến hành triển khai dự án, mỗi thành viên đảm nhiệm
một chức năng nhiệm vụ của riêng mình, bắt đầu sử dụng ngơn ngữ lập
trình và các thuật tốn để coding ra một phần chức năng của phần mềm.

Bước này được thực hiện xong sẽ tiến hành đưa vào một công đoạn
test, người ta gọi đó là cơng đoạn kiểm thử đơn vị.
*Ưu điểm của “Mơ hình chữ V”

- Đơn giản dễ sử dụng
- Có hoạt động, kế hoạch cụ thể cho quá trình tes
- Tiết kiệm được thời gian, và có cơ hội thành cơng cao hơn Waterfall
(Mơ hình thác nước)
- Chủ động trong việc phát hiện lỗi (bug), sớm tìm ra lỗi ngay từ
những bước đầu
* Nhược điểm “Mơ hình chữ V”
- Độ linh hoạt ít và cịn tồn tại sự cứng nhắc. Nó thể hiện ở chỗ cứ sau
mỗi bước thì lại phải có một cơng đoạn test, nếu u cầu dự án khơng q
phức tạp và dễ hiệu, thì việc thực hiện nhiều công đoạn test như vậy là tốn
thời gian.
- Giống với mơ hình thác nước, sản phẩm của dự án chỉ được xuất
hiện khi tất cả các bước được hồn thành xong, khơng có nguyên mẫu ngay

10

từ ban đầu. Không đáp ứng được yêu cầu dịch vụ vừa phát triển, song song
với vừa bán sản phẩm.

- Nếu có sự thay đổi về kỹ thuật ở nữa chừng, thì sẽ phải quay lại các
bước đầu tiên, thực hiện lại, cập nhật (update) lại tài liệu.
1.5.3 Mơ hình Agile Scrum

Hình 1.4. Mơ hình Agile Scrum
Agile là phương pháp phát triển phần mềm linh hoạt để làm sao đưa
sản phẩm đến tay người dùng nhanh nhất và tốt nhất. Nguyên tắc của Agile
là :
- “Cá nhân và sự tương tác hơn là quy trình và công cụ”
- “Phần mềm chạy tốt hơn là tài liệu đầy đủ”
- “Cộng tác với khách hàng hơn là đàm phán hợp đồng”
- “Phản hồi với sự thay đổi hơn là bám theo kế hoạch”
* Cá nhân và sự tương tác hơn là quy trình và cơng cụ
Ý tưởng là đặt trọng tâm vào con người và sự tương hỗ giữa những
thành viên trong nhóm. Cơ bản là nếu dự án có những thành viên có năng
lực, chịu làm việc cùng nhau thì sẽ mang đến thành cơng cho dự án. Nếu dự
án của bạn có quy trình làm việc tốt, được hỗ trợ những cơng cụ tốt nhất
nhưng những thành viên khơng “cùng nhìn về một hướng” thì khả năng dự
án thất bại là rất lớn. Nói điều này khơng có nghĩa là phủ nhận tầm quan

11

trọng của quy trình và cơng cụ nhưng trong Agile nó được đặt sau yếu tố
con người.
* Phần mềm chạy tốt hơn là tài liệu đầy đủ

Trong một số quy trình phát triển phần mềm, việc tạo ra và cập nhật
các tài liệu về sản phẩm là bắt buộc. Nhóm phát triển khơng thể hoặc khơng
đồng ý tiến hành cơng việc nếu khơng có tài liệu đặc tả về yêu cầu, thiết kế
hệ thống. Nhóm kiểm thử thì u cầu tài liệu về sản phẩm để có thể viết
trường hợp kiểm thử và kiểm thử được. Nhóm kiểm định chất lượng địi tất
cả các tài liệu phải được viết trước khi sản phẩm được giao cho khách hàng
nếu khơng thì khơng đủ điều kiện, chuẩn để giao sản phẩm cho khách hàng.
Thực ra đứng với góc độ khách hàng thì khách hàng chỉ quan tâm đến sản
phẩm có hoạt động được và tốt hay không. Trong khi việc tạo và cập nhật
tài liệu mất nhiều thời gian và được cho là buồn tẻ. Vậy tại sao phải tập
trung quá nhiều cho việc không cần thiết mà khơng dành thời gian đó để
trao đổi để hiểu thêm về công việc phải làm. Mọi người đừng hiểu lầm là
làm Agile là không viết tài liệu. Ý tưởng là chỉ viết những gì mà mọi người
cần đọc.
* Cộng tác với khách hàng hơn là đàm phán hợp đồng

“Khách hàng là thượng đế” hay “khách hàng ln ln đúng”. Tuy
nhiên có khách hàng am hiểu về cơng nghệ, có người khơng. Có người suy
nghĩ nhất qn có người thay đổi xồnh xoạch, có người lạnh lùng có người
cười nói suốt ngày, v.v và cách duy nhất để có thể làm việc tốt là phải cộng
tác với khách hàng để hiểu được khách hàng muốn gì và cần gì để có thể tư
vấn và điều chỉnh thay vì chỉ dựa vào những điều đã quy định trong hợp
đồng.
* Phản hồi với sự thay đổi hơn là bám theo kế hoạch

Có một điều thú vị là đa số trong chúng ta đều cơ bản đồng ý với 4
tuyên ngôn của Agile. Nhiều người hiểu tầm quan trọng của “cá nhân” hay

12

“cá nhân là tài sản quý giá nhất công ty” nhưng sẵn sàng thay đổi nhân lực
để tương thích với quy trình/cơng cụ hiện có. Nhiều người hiểu “khách
hàng là thượng đế” và “phải thích nghi với sự thay đổi” nhưng sẵn sàng
tun bố “Dẹp, khơng làm nữa” vì khách hàng thay đổi yêu cầu liên tục.
Hay như “sản phẩm xài được là quan trọng” nhưng vẫn cố gắng viết thêm
tài liệu với ý nghĩ rằng “biết đâu/lỡ sau này có ai cần thì có cái mà cung
cấp”.

Scrum: Là một quy trình tuân thủ theo phương pháp của Agile. Vì thế
nó tn thủ các nguyên tắc của Agile. Ngoài ra Scrum hoạt động dựa trên ba
giá trị cốt lõi, còn gọi là Ba chân của Scrum bao gồm Minh bạch, Thanh tra và
Thích nghi.

Minh bạch (transparency): Trong Scrum, tính minh bạch được đề
cao như là giá trị cốt lõi cơ bản nhất. Muốn thành công với Scrum, thông tin
liên quan tới quá trình phát triển phải minh bạch và thơng suốt. Các thơng
tin đó có thể là: tầm nhìn (vision) về sản phẩm, yêu cầu khách hàng, tiến độ
công việc, các khúc mắc và rào cản v.v. Từ đó mọi người ở các vai trị các
nhau có đủ thông tin cần thiết để tiến hành các quyết định có giá trị để nâng
cao hiệu quả cơng việc. Các công cụ và cuộc họp trong Scrum luôn đảm
bảo thông tin được minh bạch cho các bên.

Thanh tra (inspection): Công tác thanh tra liên tục các hoạt động
trong Scrum đảm bảo cho việc phát lộ các vấn đề cũng như giải pháp để
thông tin đa dạng và hữu ích đến được với các bên tham gia dự án. Truy xét
kỹ càng và liên tục là cơ chế khởi đầu cho việc thích nghi và các cải tiến
liên tục trong Scrum.

Thích nghi (adaptation): Scrum rất linh hoạt như các phương pháp

phát triển linh hoạt (agile software development) khác. Nhờ đó nó mang lại
tính thích nghi rất cao. Dựa trên các thơng tin minh bạch hóa từ các q

13

trình thanh tra và làm việc, Scrum có thể phản hồi lại các thay đổi một cách
tích cực, nhờ đó mang lại thành công cho dự án.
Trong Scrum, đội ngũ tham gia phát triển phần mềm được phân chia ra ba
vai trò với trách nhiệm rõ ràng để đảm bảo tối ưu hóa các cơng việc đặc
thù. Ba vai trị này bao gồm: Product Owner (chủ sản phẩm), Scrum Master
và Development Team (Đội sản xuất hay Nhóm Phát triển).

Product Owner (chủ sản phẩm): Là người chịu trách nhiệm về sự
thành công của dự án, người định nghĩa các yêu cầu và đánh giá cuối cùng
đầu ra của các nhà phát triển phần mềm.

Scrum Master: Là người có hiểu biết sâu sắc về Scrum và đảm bảo
nhóm có thể làm việc hiệu quả với Scrum.

Development Team (Đội sản xuất, hay Nhóm phát triển): Một nhóm
liên chức năng (cross-functional) tự quản lý để tiến hành chuyển đổi các
yêu cầu được tổ chức trong Product Backlog thành chức năng của hệ thống.
Scrum định nghĩa quy tắc cho bốn sự kiện chủ chốt (các cuộc họp) nhằm
tạo môi trường và quy cách hoạt động và cộng tác cho các thành viên trong
dự án. Các lễ nghi này diễn ra trước khi Sprint bắt đầu (Sprint Planning),
trong khi Sprint diễn ra (Daily Scrum) và sau khi Sprint kết thúc (Sprint
Review và Sprint Retrospective).
1.6. Test case là gì?

Test case mô tả dữ liệu đầu vào (input), hành động(action) hoặc sự

kiện (event) và một kết quả mong đợi (expected response) để xác định một
chức năng của ứng dụng phần mềm hoạt động đúng hay khơng. Một test
case có thể có phần đặc thù khác nhau như mã test case, tên test case, mục
tiêu test, các điều kiện test, các yêu cầu dữ liệu đầu vào, các bước thực hiện
và các kết quả mong đợi. Mức chi tiết có thể được định nghĩa khác nhau
dựa vào ngữ cảnh của dự án và quy mô của công ty sản xuất phần mềm.

14

1.7. Các kỹ thuật trong kiểm thử
Có nhiều kỹ thuật trong kiểm thử, nhưng có 2 loại được sử dụng nhiều

nhất là : Kiểm thử hộp đen, và kiểm thử hộp trắng.
1.7.1. Kiểm thử hộp đen (Black Box testing)

Dùng để kiểm tra chức năng mà không xem xét mã nguồn cũng như
cấu trúc chương trình bên trong. Thường kiểm thử hộp đen quan tâm nhiều
đến các bộ dữ liệu kiểm thử đầu vào.

Các kỹ thuật trong kiểm thử hộp đen
Phân vùng tương đương - Equivalence partitioning

Ý tưởng: Phân hoạch miền dữ liệu vào thành các dữ liệu có liên hệ với nhau
Mỗi vùng dùng để kiểm thử 1 chức năng , gọi là vùng tương đương.
Các bước :

- Đối với dữ liệu đầu vào , xác định các vùng tương đương từ miền
dữ liệu.

- Chọn dữ liệu đại diện cho mỗi vùng tương đương

- Kết hợp các dữ liệu thử bởi tích đề các để tạo ra bộ dữ liệu kiểm
thử.
* Nguyên tắc phân hoạch các vùng tương đương
Nếu dữ liệu vào phụ thuộc một khoảng, xây dựng

o 1 vùng các giá trị lớn hơn
o 1 vùng các giá trị nhỏ hơn
o N các giá trị hợp lệ
Nếu dữ liệu là tập hợp các giá trị, xây dựng
o 1 vùng tập rỗng
o 1 vùng quá nhiều các giá trị
o N vùng hợp lệ
Nếu dữ liệu đầu vào là điều kiện ràng buộc, xây dựng
o 1 vùng các ràng buộc được thỏa mãn.

15

o 1 vùng với ràng buộc không được thỏa mãn.
Ví dụ: Bài tốn đặt vé theo giờ

============+==== -=========+========-
Vé thường: ________|__________|_________|__________
=================9h30=======16h=====19h30

========== -=======+=======-========+
Vé tiết kiệm: _______|________|_________|___________
=================9h30=====16h======19h30
Các vùng hợp lệ là vùng thuộc dấu (+) và vùng không hợp là vùng thuộc
dấu (-).
Phân theo các vùng hợp lệ và không hợp lệ ta có 4 test case cho phân vùng

tương đương: (0 – 9h30) , (9hh31 – 16h), (16h01 – 19h30), (19h31 –
23h59).
Phân tích giá trị biên - Boundary value analysis
Cơ sở: lỗi thường xuất hiện gần các giá trị biên của miền dữ liệu.
Tập trung phân tích các giá trị biên của miền dữ liệu để xây dựng dữ liệu
kiểm thử.
Nguyên tắc kiểm thử các dữ liệu bao gồm:
- Giá trị nhỏ nhất.
- Giá trị gần kề lớn hơn giá trị nhỏ nhất.
- Giá trị bình thường.
- Giá trị gần kề nhỏ hơn giá trị lớn nhất
- Giá trị lớn nhất
Nguyên tắc chọn dữ liệu thử
- Nếu dữ liệu vào thuộc một khoảng, chọn :
2 Giá trị biên
4 giá trị = Giá trị biên ± sai số nhỏ nhất

16