Nghiên cứu phát triển phần mềm hướng hành vi ứng dụng công cụ behat

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

PHAN THI ̣GẤM

NGHIÊN CƢ́U PHÁ T TRIỂN PHẦN MỀM
HƢỚNG HÀ NH VI VÀ Ƣ́NG DỤNG CÔNG CỤ BEHAT

LUẬN VĂN THẠC SĨ NGÀ NH CÔNG NGHỆ THÔNG TIN

HÀ NỘI 12– 2013


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

PHAN THI ̣GẤM

NGHIÊN CƢ́U PHÁ T TRIỂN PHẦN MỀM
HƢỚNG HÀ NH VI VÀ Ƣ́NG DỤNG CÔNG CỤ BEHAT
Ngành: Công nghê ̣thông tin
Chuyên ngành: Công nghê ̣phầ n mềm
Mã số: 60 48 10

LUẬN VĂN THẠC SĨ

NGƢỜI HƢỚNG DẪN KHOA HỌC
TS. TRƢƠNG ANH HOÀ NG

HÀ NỘI – 2013


i

LỜI CAM ĐOAN
Tôi xin cam đoan kết quả đạt đƣợc trong luận văn là sản phẩm nghiên cứu,
tìm hiểu của riêng cá nhân tôi. 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 tôi hoặc là đƣợ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 hình thức kỷ luật theo quy
định cho lời cam đoan của mình.

Học viên thực hiện

Phan Thị Gấm


ii

LỜI CẢM ƠN
Tôi xin bày tỏ lòng biết ơn sâu sắc đến tất cả mọi ngƣời đã giúp đỡ, hỗ trợ
thực hiện luận văn này, xin cảm ơn Khoa Công nghê ̣ thông tin , Trƣờng Đa ̣i học
Công nghê ̣, Đa ̣i học Quốc g ia Hà Nô ̣i đã cho phép và tạo điều kiện để tôi thực
hiện luận văn này.
Luận văn này sẽ không thể hoàn thành nếu không có sự giúp đỡ và chỉ bảo
tận tình của Thầygiáo, Tiế n siT
̃ rƣơng Anh Hoàng , giáo viên hƣớng dẫn của tôi.
Em xin chân thành biết ơn về những chỉ bảo, định hƣớng nghiên cứu, hỗ trợ, tạo

những điều kiện tốt nhất cho em trong suốt quá trình thực hiện đề tài.
Con xin bày tỏ lòng biết ơn sâu sắc đến nhƣ̃ng ngƣời thân trong gia đình
đă ̣c biê ̣t là Bố , Mẹ, Chồng và con gái đã động viên, ủng hộ trong những lúc khó
khăn để con có đƣợc nhƣ ngày hôm nay.
Xin chân thành cảm ơn tất cả quý Thầy,Cô trong Khoa, Trƣờng đã tận tình
chỉ bảo, rèn luyện, truyền đạt những tri thức, kỹ năng, kinh nghiệm quý báu cho
tôi trong suốt nhƣ̃ng năm học vừa qua.
Học viên thực hiện

Phan Thị Gấm


iii

MỤC LỤC
LỜI CAM ĐOAN................................................................................................... i
LỜI CẢM ƠN ....................................................................................................... ii
DANH MỤC CÁC TƢ̀ VIẾT TẮT....................................................................... v
DANH MỤC BẢNG BIỂU ................................................................................. vi
DANH MỤC HÌNH VẼ ....................................................................................... vi
CHƢƠNG – MỞ ĐẦU ........................................................................................ 1
CHƢƠNG 1. KIỂM THỬ TRONG PHƢƠNG PHÁP PHÁT TRIỂN PHẦN
MỀM LINH HOA ̣T............................................................................................. 5
1.1. Mô hình phát triển lặp trong phƣơng pháp phát triển linh hoạt ........... 5
1.1.1. Quy trình Scrum ........................................................................................ 6
1.1.2. Lập trình cực hạn .................................................................................... 10
1.2. Kiểm thử trong phƣơng pháp triển linh hoạt ........................................ 11
1.2.1. Kiểm thử đơn vị ...................................................................................... 13
1.2.2. Kiểm thử chấp nhận trong lâ ̣p trình cƣ̣c ha ̣n XP .................................... 13
1.3. Đặc tả yêu cầu hệ thống bằng câu chuyện ngƣời dùng ......................... 13

1.4. Các kỹ thuâ ̣t phát triển phần mềm theo hƣớng kiểm thử .................... 16
1.4.1. Phát triển phần mềm theo hƣớng kiểm thử ............................................. 16
1.4.2. Phát triển phần mềm theo hƣớng kiểm thử chấp nhận ........................... 20
1.4.3. Mô ̣t số vấ n đề của phát triể n phầ n mề m dƣ̣a vào kiể m thƣ̉ .................... 22
CHƢƠNG 2. PHÁT TRIỂN PHẦN MỀM HƢỚNG HÀNH VI ................. 24
2.1. Tổng quan về phát triển phần mềm hƣớng hành vi .............................. 24
2.2. Nguyên lý hoạt động.................................................................................. 25
2.3. Quy trình phát triển phần mềm theo hƣớng hành vi ............................ 27
2.3.1. Đặc tả hành vi của ƣ́ng du ̣ng................................................................... 29
2.3.2. Viế t kiể m thƣ̉ cho các bƣớc .................................................................... 30
2.3.3. Lă ̣p để cài đă ̣t ƣ́ng du ̣ng .......................................................................... 31
2.4. Ngôn ngữ đặc tả ứng dụng ....................................................................... 31
CHƢƠNG 3. CÔNG CỤ BEHAT ................................................................... 35
3.1. Giới thiệu công cụ Behat .......................................................................... 35
3.1.1. Công cụ dòng lệnh của Behat ................................................................. 35
3.1.2. Cấu trúc thƣ mục ..................................................................................... 36
3.2. Cách sử dụng Behat .................................................................................. 36
3.2.1. Xác định các tính năng ............................................................................ 36
3.2.2. Sử dụng Gherkin để viết các tính năng ................................................... 37
3.2.3. Xây dƣ̣ng các định nghĩa bƣớc ............................................................... 43
3.2.4. Móc nối quá trình kiểm thử và các sự kiện............................................. 48
3.2.4.1. Các sự kiện trong Behat .................................................................. 48


iv
3.2.4.2. Hooks .............................................................................................. 49
3.2.5. Kiểm thử các tính năng – lớp FeatureContext ........................................ 50
3.3. Phát triển ứng dụng Web với Mink ........................................................ 51
3.4. Lớp MinkContext ...................................................................................... 52
3.5. Cấu hình Behat với behat.yml ................................................................. 55

CHƢƠNG 4. ÁP DỤNG PHÁT TRIỂN PHẦN MỀM HƢỚNG HÀNH VI
VÀ CÔNG CỤ BEHAT..................................................................................... 60
4.1. Giai đoa ̣n chuẩ n bi ....................................................................................
60
̣
4.2. Tiế n trin
̀ h thƣ̣c hiêṇ ƣ́ng du ̣ng ................................................................. 61
4.3. Áp dụng phát triển hƣớng hành vi và công cụ Behat............................ 63
4.3.1. Tính năng “Xem trang chủ” .................................................................... 63
4.3.2. Tính năng “Đăng ký thành viên” ............................................................ 70
4.4. Nhận xét và kết luận ................................................................................. 92
KẾT LUẬN 95
TÀI LIỆU THAM KHẢO ................................................................................... 97
PHỤ LỤC ............................................................................................................ 98


v

DANH MỤC CÁC TƢ̀ VIẾT TẮT
JS
CSS
HTTP
API
Ajax
DOM
XP
TDD
ATDD
BDD

JavaScript
Cascading Style Sheets
Giao thƣ́c HTTP
Application Programming Interface
Asynchronous Javascript and XML
Document Object Model
eXtreme Programming
Test Driven Development
Acceptance Test Driven Development
Behaviour Driven Development


vi

DANH MỤC BẢNG BIỂU
Bảng 3-1. Các thuộc tính của lệnh behat ............................................................ 35
Bảng 3-2 MinkContext với các đinh
̣ nghiã bƣớc để ta ̣o yêu cầ u ........................ 53
Bảng 3-3 MinkContext các đinh
̣ nghiã với bƣớc tƣơng tác Form ...................... 54
Bảng 3-4 MinkContext định nghĩa các bƣớc cho DOM ..................................... 55
Bảng 3-5 MinkContext với các bƣớc kiểm tra hồi đáp trang ............................. 55

DANH MỤC HÌ NH VẼ
Hình 1-1. Mô hình phát triển lặp........................................................................... 5
Hình 1-2. Quy trin
̀ h Scrum.................................................................................... 7
Hình 1-3. Vòng đời của dự án XP ....................................................................... 11
Hình 1-4. Nguyên lý TDD................................................................................... 17
Hình 1-5. Vòng đời của phần mềm phát triển theo TDD.................................... 18

Hình 1-6. Quy trin
̀ h ATDD.................................................................................. 21
Hình 2-1 Tiế n trin
̀ h phát triể n phầ n mề m hƣớng hành vi ................................... 28
Hình 3-1. Cấ u trúc thƣ mu ̣c làm viê ̣c của Behat ................................................. 36
Hình 3-2. Cấ u trúc chung của mô ̣t tính năng bằ ng Gherkin ............................... 38
Hình 3-3. Mô tả các tính năng ............................................................................. 41
Hình 3-4. Các sự kiện Hook của Behat ............................................................... 49
Hình 3-5 Cấ u hin
̀ h behat.yml .............................................................................. 56
Hình 4-2 Tiế n hình áp du ̣ng BDD và Behat để phát triể n ƣ́ng du ̣ng .................. 62
Hình 4-3 Tính năng trang chủ hệ thống .............................................................. 63
Hình 4-4. Sử dụng bộ điều khiển trình duyệt Selenium...................................... 80


-1-

CHƢƠNG – MỞ ĐẦU
Chấ t lƣơ ̣ng là mô ̣t trong nhƣ̃ng yế u tố quan tro ̣ng nhấ t của sản phẩ m phầ n
mề m. Lỗi phầ n mề m không chỉ ảnh hƣởng đế n dƣ̃ liê ̣u, hoạt động của cơ quan tổ
chƣ́c sƣ̉ du ̣ng phầ n mề m mà đôi khi còn ảnh hƣởng đế n tính ma ̣n g con ngƣờ i.
Nhƣ̃ng ha ̣n chế hay lỗi phầ n mề m sẽ che lấ p các tiń h năng và tiê ̣n ić h mà hê ̣
thố ng đó mang la ̣i. Đặc biệt, trong thi ̣trƣờng ca ̣nh tranh chấ t lƣơ ̣ng cao nhƣ hiê ̣n
nay mô ̣t phầ n mề m phát sinh lỗi trong quá triǹ h sƣ̉ du ̣ng sẽ là m ảnh hƣởng
nghiêm tro ̣ng tới danh tiế ng , thƣơng hiê ̣u và uy tiń của công ty sản xuấ t phầ n
mề m. Chính vì lý do đó đảm bảo chất lƣợng phần mềm là một vấn đề quan trọng
và ngày càng cầ n đƣơ ̣c quan tâm hàng đầ u trong liñ h vƣ̣c phát triển phần mềm.
Tuy nhiên, mô ̣t phầ n mề m chấ t lƣơ ̣ng cao cũng có thể gă ̣p thấ t ba ̣i trên thi ̣
trƣờng nế u phầ n mề m đó không đáp ƣ́ng đƣơ ̣c nhu cầ u của khách hàng. Các
công ty sản xuấ t phầ n mề m luôn cố gắ ng đƣa ra các hệ thố ng với các tính năng

mới để ca ̣nh tranh với các nhà cung cấ p khác . Với đa phầ n các hê ̣ thố ng thƣơng
mại, tại thời điểm bắt đầu dự án , có thể đội phát triển không thu thập đƣợc các
yêu cầ u thƣ̣c sƣ̣ tƣ̀ khách hàng , phầ n mề m sẽ đƣơ ̣c phát triể n dƣ̣a trên các tiń h
năng phỏng đoán và trong trƣờng hơ ̣p tồ i tê ̣ các tiń h năng đó có thể không phù
hơ ̣p với mong muố n của khách hàng . Viê ̣c thu thâ ̣p yêu cầ u khách hàng và sử
dụng các mô tả tƣờng minh đ ể yêu cầu đó không bị sai lệch trong quá trình phát
triể n phầ n mề m là vấn đề lớn của các nhà sản xuấ t.
Thông qua quá trình sƣ̉ du ̣ng phầ n mề m , ngƣời sƣ̉ du ̣ng sẽ dễ hình dung ra
các hoạt động của hệ thống và hiể u rõ hơn về nghiê ̣p vu ̣ và miề n ƣ́ng du ̣ng , khi
đó khách hàng dễ đƣa ra các ý tƣởng cho tiń h năng mới và bổ sung chúng. Đây
là hạn chế lớn nhất của các phƣơng pháp phát triển phần mềm truyền thống , bởi
khi có sƣ̣ bổ sung hoă ̣c t hay đổ i yêu cầ u phầ n mề m đang phát triển sẽ dễ phá vỡ
cấ u trúc hê ̣ thố ng. Trong phƣơng pháp phát triể n phầ n mề m truyề n thố ng , khách
hàng cũng chỉ đƣợc tiếp xúc với phần mềm sau khi các yêu cầu phần mềm đã
đƣơc̣ cài đă ̣t hoàn thiện, do đó viê ̣c phát hiê ̣n sai sót hoă ̣c cài đă ̣t hê ̣ thố ng không
đúng với yêu cầ u khách hàng rấ t dễ xảy ra . Quy triǹ h phát triể n phầ n mề m lă ̣p
hiê ̣n đa ̣i đƣơ ̣c coi là mô ̣t giải pháp khắ c phu ̣c vấ n đề thay đổ i yêu cầ u củ a ngƣời
sƣ̉ du ̣ng. Ý tƣởng cơ bản trong các quy trình lặp hiê ̣n đa ̣i là phần mềm đƣợc sản
xuấ t theo tƣ̀ng bƣớc, mỗi bƣớc chỉ thƣ̣c hiê ̣n mô ̣t số tính năng tƣơng đố i đô ̣c lâ ̣p
để đƣa ra một phần mềm nhỏ có thể dùng đƣợc . Sau mỗ i vòng lă ̣p , khách hàng
có thể dùng thử phần mềm để đƣa ra các phản hồi về hệ thống và dƣ̣a vào các
phản hồi đó đội phát triển sẽ bổ sung các tính năng hữu ích hoặc cải thiện các
tính năng đã đƣợc phát triển theo hƣ ớng tốt hơn cho khách hàng . Viê ̣c cho ̣n các


-2tính năng để đƣa vào mỗi vòng lặp thƣờng căn cứ vào độ ƣu tiên của chúng , do
đó các tính năng quan tro ̣ng thƣờng đƣơ c̣ cho ̣n để phát triể n trƣớc. Điề u này cho
phép khách hàng sử dụ ng hê ̣ thố ng sớm hơn các phƣơng pháp phát triể n phầ n
mề m truyề n thố ng.
Bên ca ̣nh nhƣ̃ng lơ ̣i ích đáp ƣ́ng sƣ̣ thay đổ i yêu cầ u , các quy trình phát

triể n phầ n mề m theo phƣơng pháp lă ̣p cũng ta ̣o ra nhƣ̃ng thách thƣ́c mới cho
giai đoa ̣n kiể m thƣ̉ phầ n mề m . Ở quy triǹ h phát triể n truyề n thố ng , kiể m thƣ̉ là
mô ̣t pha đƣơ ̣c thƣ̣c hiê ̣n và o cuố i dƣ̣ án , khi hê ̣ thố ng đã đƣơ ̣c cài đă ̣t hoàn thiện,
nhƣngvới các hê ̣ thố ng sƣ̉ du ̣ng phƣơng pháp lă ̣p , phầ n mề m sẽ đƣơ ̣c kiể m tra
trong mỗi vòng lă ̣p. Khách hàng thƣờng xuyên đƣợc sử dụng các phiên bản nhỏ
của hệ thống , nên lỗi phầ n mề m hoă ̣c các tính năng sai sót sẽ sớm đƣơ ̣c phát
hiê ̣n và giải quyế t trƣớc khi sản phẩ m chiń h thƣ́c đƣơ ̣c bàn giao cho khách hàng.
Trong điề u kiê ̣n lý tƣởng , sau mỗi vòng lă ̣p khách hàng sẽ nhận đƣợc mô ̣t sản
phẩ m có chất lƣợng cao, phù hợp với yêu cầu.
Trong phƣơng pháp phát triể n phầ n mề m linh hoa ̣t , nhu cầ u kiể m thƣ̉ đƣơ ̣c
hiể u là c ác quy tắc hay hoạt động đƣợc sử dụng để đảm bảo chất lƣợng phần
mề m. Quá trình phát triển phần mềm thƣờng sử dụng các kỹ thuật và công cụ hỗ
trơ ̣ để mã nguồn viết cho mỗi tính năng hoạt động đúng , chẳ ng ha ̣n nhƣ các kỹ
thuâ ̣t lâ ̣p trình theo că ̣p , kỹ thuật phát triển hệ thống lấy kiểm thử làm trọng tâm
hay kỹ thuật kiể m thƣ̉ trƣớc, ... . Tuy nhiên, mô ̣t tính năng đúngchƣa hẳ n đã phù
hơ ̣p yêu cầu của khách hàng, và để kiểm tra điều đó cầ n mô ̣t phƣơng pháp kiể m
thƣ̉ ở mƣ́c đô ̣ cao hơn , đó là kiể m thƣ̉ chấ p nhâ ̣n hay kiể m thƣ̉ của khách hàng .
Yêu cầ u của khác h hàng là yế u tố quan tro ̣ng nhấ t để xác đinh
̣ các trƣờng hơ ̣p
kiể m thƣ̉ , viê ̣c kiể m thƣ̉ nhằ m đảm bảo phầ n mề m làm ra đáp ƣ́ng nhu cầ u của
khách hàng.
Trong quy trin
̀ h lă ̣p , phầ n mề m đƣơ ̣c phát triể n qua các vòng lă ̣p và có sƣ̣
thay đổ i liên tu ̣c sẽ có lơ ̣i cho viê ̣c kiể m tra các tiń h năng . Mỗi tiń h năng đƣơ ̣c
kiể m thƣ̉ ít nhấ t m ột lần, thâ ̣m chí nhƣ̃ng tính năng quan tro ̣ng đƣơ ̣c kiể m thƣ̉
nhiề u lầ n thông qua các vòng lă ̣p khi bổ sung các tính năng mới
. Chính vì
thế ,kiể m thƣ̉ hồ i quy trở nên n hàm chán và khó thực hiện ; càng gần cuối chu
trình phát triể n phầ n mề m , viê ̣c kiể m thƣ̉ các tiń h năng ban đầ u quan tro ̣ng nhấ t
dễ bi ̣ tiế n hành lỏng lẻo bởi tâm lý chủ quan của kiểm thử viên . Trái lại, khi tić h

hơ ̣p thêm các tin
́ h năng mới, rấ t dễ phát sinh các lỗi ảnh hƣởng tới toàn hệ thống
và lỗi đó phát hiện càng muộn t hì chi phí sữa lỗi càng cao . Đặc biệt ở nhƣ̃ng
vòng lặp cuối thì rất khó để thực hiện , lúc này kiểm thử tự động trở thành một
giải pháp hữu hiệu để giải quyết vấn đề tr ên. Kiể m thƣ̉ tƣ̣ đô ̣ng là viê ̣c sƣ̉ du ̣ng


-3các phần mềm , các công cụ để kiểm thử phần mềm khác nhằm hỗ trợ cho con
ngƣời tƣ̣ đô ̣ng hóa quá trình kiể m thƣ̉ . Kiể m thƣ̉ tƣ̣ đô ̣ng giúp công viê ̣c thƣ̣c
hiê ̣n mô ̣t cách nhanh chóng , chính xác hơn , giải quyết các vấn đề về tâm lý
trong quá trin
̀ h kiể m thƣ̉ . Kiể m thƣ̉ tƣ̣ đô ̣ng đă ̣c biê ̣t hƣ̃u hiê ̣u trong vấ n đề kiể m
thƣ̉ hồ i quy , bởi có thể thƣ̣c hiê ̣n hằ ng ngày , hằ ng giờ , cho mo ̣i vòng lă ̣p mà
không hề nhàm chán.
Hiê ̣n nay có khá nhiề u công cu ̣ để kiể m thƣ̉ tƣ̣ đô ̣ng và nó trở thành mô ̣t
phầ n không thể thiế u đố i với các hê ̣ thố ng phát triể n theo phƣơng pháp linh hoa ̣t.
Tuy nhiên, để tự động hóa quá trình kiểm thử chấp nhận thì cần phải lựa chọn
mô ̣t kỹ thuâ ̣t phù hơ ̣p để mô tả yêu cầ u của khách hàng . Viê ̣c sƣ̉ du ̣ng công cu ̣
phầ n lớn phu ̣ thuô ̣c vào ngôn ngƣ̃ lâ ̣p trình và kỹ thuâ ̣t đă ̣c tả yêu cầ u ngƣời
dùng. Với sƣ̣ phát triể n ma ̣nh mẽ của các quy triǹ h phát triển phần mềm theo
phƣơng pháp linh hoa ̣t thì thời gian gần đây có rất nhiều công cụ hỗ trợ chẳ ng
hạn nhƣ PHPUnit, Selenium, TestPro, …
Nghiên cứu và tìm hiểu mô ̣t kỹ thuật phát triển phần mềm, có thể đặc tả
những tiêu chí kiểm thử chấp nhận từ ngƣời sử dụng và tái sử dụng các tiêu chí
đó cho việc tự động hóa kiểm thử chấp nhậnlà rất cần thiết. Chính vì lí do đó tôi
chọn đề tài “Nghiên cứu phát triển phần mềm hƣớng hành vi và ứng dụng
công cụ Behat”.
Nô ̣i dung luâ ̣n văn tâ ̣p trung vào những vấn đề sau:
 Giới thiê ̣u tổ ng quan về phƣơng pháp phát triể n phầ n mề m linh hoa ̣t ; Giới
thiê ̣u hai quy trình đƣơ ̣c sƣ̉ du ̣ng phổ biế n trong A gile là quy trình Scrum và lâ ̣p

trình cực hạn XP; Tổng kết mục đích và vai trò của kiểm thử trong phƣơng pháp
phát triển phần mềm linh hoạt , chỉ ra các mức kiểm thử thƣờng đƣợc áp dụng
nhƣ kiể m thƣ̉ đơn vi,̣ kiể m thƣ̉ chấ p nhâ ̣n, …
 Tìm hiểu một số kỹ thuật phát triển phần mềm thƣờng áp dụng trong
phƣơng pháp phát triể n linh hoa ̣t . Phầ n này chủ yế u triǹ h bày phƣơng pháp phát
triể n phầ n mề m lấ y kiể m thƣ̉ làm tro ̣ng tâm ; đƣa ra các khái niê ̣m và quy triǹ h
thƣ̣c hiê ̣n của phƣơng pháp phát triể n dƣ̣a vào kiể m thƣ̉ (TDD) và phƣơng pháp
phát triển dựa vào kiểm thử chấp nhận (ATDD). Phầ n này cũng nêu lên mô ̣t số
hạn chế của các kỹ thuật này.
 Nghiên cƣ́u phƣơng pháp phát triể n phầ n mề m hƣớng hành vi . Đây là mô ̣t
phƣơng pháp mới , chƣa đƣơ ̣c áp du ̣ng phổ biế n trong sản xuấ t phầ n mề m . Tuy
nhiên, thông qua nghiên cƣ́u của miǹ h tôi thấ y đây là mô ̣t kỹ thuâ ̣t hay, có thể áp
dụng rộng rãi , vì thế trong phần này , tôi trình bày nhƣ̃ng kiế n thƣ́c cơ bản nhấ t


-4về phƣơng pháp phát triể n phầ n mề m dƣ̣a vào hành vi của ƣ́ng du ̣ng nhƣ
:
nguyên lý , quy trình, các sản phẩm cũng nhƣ công cụ hỗ trợ ;chú trọng trình bày
dạng thức mô tả yêu cầu ứng dụng dƣới dạng một tính năng ; định dạng mô tả
tính năng, các kịch bản sƣ̉ du ̣ng tiń h năng, cũng nhƣ mô tả các tiêu chí kiểm thử
chấ p nhâ ̣n thông qua các bƣớc của kịch bản.
 Nghiên cƣ́u công cu ̣ Behat :Trình bày chi tiết về các h cài đặt , cấ u hình ,
kiế n trúc và cách thƣ́c sƣ̉ du ̣ng công cu ̣ này
;mô tả cách sử dụng ngôn ngữ
Gherkin để viế t tin
̣ nghiã các tiêu chí kiể m thƣ̉ chấ p nhâ ̣n nhƣ là các
́ h năng, đinh
bƣớc của kich
̣ bản ; Cách định nghĩa phƣơng thức kiểm thử chấp nhận trong lớp
ngƣ̃ cảnh.

 Áp dụng những nghiên cứu về phát triển phần mềm hƣớng hành vi và
công cụ Behat để xây dựng ứng dụng minh họa: giới thiê ̣u công cu ̣ và kỹ thuâ ̣t
hỗ trơ;̣ mô tả ƣ́ng du ̣ng và các bƣớc xây dƣ̣ng ƣ́ng du ̣ng ; tổ ng kế t, đánh giá viê ̣c
áp dụng.
Cấ u trúc của luâ ̣n văn gồ m bố n phầ n nhƣ sau:
 Chƣơng 1 –Kiểm thử phần mềm trong Agile:Trình bày các khái niệm
cơ bản , một số quy trình phát triển phần mềm theo phƣơng pháp phát triển linh
hoạt; Mục đích, tầm quan trọng, các loại hình kiểm thử trong phƣơng pháp phát
triể n linh hoạt.
 Chƣơng 2 – Phát triển phần mềm theo hƣớng hành vi – BDD: Trình
bày khái niệm, quy trình và một số kiến thức liên quan đến phát triển phần mềm
hƣớng hành vi.
 Chƣơng 3 – Công cụ Behat: Giới thiệu công cụ Behat và các thành phần
liên quan.
 Chƣơng 4 - Áp dụng phát triển phần mề m hƣớng hành vi và công cu ̣
Behat:Vâ ̣n du ̣ngphát triển phần mềm hƣớng hành vi và sử dụng công cụ Behat
để xây dựng ứng dụng minh họa.


-5-

CHƢƠNG 1.

KIỂM THỬ TRONG PHƢƠNG PHÁP PHÁT
TRIỂN PHẦN MỀM LINH HOA ̣T

1.1. Mô hình phát triển lặp trong phƣơng pháp phát triển linh hoạt
Phƣơng pháp phát triển phần mềm theo nguyên lý lặp đã xuất hiện nhiều
năm nay [1], biểu hiện trong mô hình xoắn ốc hay mô hình phát triển phần mềm
theo bản mẫu. Tuy nhiên, thƣ̣c tế các mô hình đó ít đƣợc áp dụng và chƣa đem

lại hiệu quả cao. Những năm gần đây, các phƣơng pháp phát triể n phầ n mề m
hoạt động theo nguyên lý lặp đƣợc áp dụng phổ biến và đem lại những lợi ích to
lớn cho ngành công nghiệp phần mềm, đó là nhóm các mô hình phần mềm trong
phƣơng pháp phát triển phần mềm linh hoạt (còn gọi là phƣơng phápAgile)[4].
Theo mô hình phát triển lặp, phần mềm sẽ đƣợc hoàn thiện dần thông qua nhiều
vòng lặp, mỗi vòng lặp tạo ra một phiên bản phần mềm tích hợp dần các chức
năng để hoàn thiện hệ thống.
Sử dụng phƣơng pháp này, hệ thống tăng trƣởngthông qua việc tích hợp
thêm các tính năng mới hoặc cải thiện tính năng cũ qua từng vòng lặp. Khách
hàng đƣa ra các tính năng của phần mềm, đồng thời đánh giá độ ƣu tiên của mỗi
tính năng và thông qua đó đội phát triển sẽ đƣa các tính năng vào các vòng lặp
và xác định điểm khởi tạo của mỗi vòng lặp để thực hiện dự án. Trong các quy
trình phát triển phần mềm theo nguyên lý lặp nhƣlập trình cực hạn (eXtreme
Programming viết tắt là XP)[4]hay quy trình Scrum[3] thì mỗi vòng lặp thƣờng
đƣợc triển khai từ 2 – 6 tuần để thực hiện các tính năng có liên quan với nhau
nhằm tạo ra một phần hoàn thiện của hệ thống[2]. Mỗi vòng lặp nhƣmột dự án
thu nhỏ, đƣợc tiến hành đầy đủ các pha nhƣ lập kế hoạch, phân tích, thiết kế, cài
đặt, kiểm thử và triển khai nhƣ Hình 1-1.

Hình 1-1. Mô hình phát triển lặp
Phƣơng pháp phát triển phần mềm linh hoạt Agile là phƣơng pháp phát
triển phần mềm hiện đại nhất và đƣợc áp dụng rộng rãi trong các công ty phần
mềm hiện nay. Nhân tố chính của phƣơng pháp phát triển linh hoạt là “lặp”, mặc
dù không có định nghĩa cụ thể cho phƣơng pháp này [4]nhƣng mục đích của các
quy trình phần mềm theo Agile là phát triển phần mềm có chất lƣợng cao trong
giới hạn tài nguyên cho phép. Phƣơng pháp phát triể n phầ n mề m linh hoạt Agile
đảm bảo phần mềm thành công bằng việc đƣa nhân tố ngƣời sử dụng tham gia


-6vào dự án để phần mềm sau khi hoàn thiện đáp ứng đúng các tiêu chí kiểm thử

chấp nhận.
Có nhiều quy trình phát triển phần mềm dựa trên các nguyên lý của phƣơng
pháp Agile, chẳng hạn nhƣ quy trình tinh gọn (Learn Software Development),
quy trình Kaban, quy trình Scrum hay lập trình cực hạn XP, … . Các quy trình
này có các thuộc tính, quy định, cũng nhƣ cách làm việc khác nhau, nhƣng
chúng đều là các quy trình phát triển phần mềm theo nguyên lý lặp. Những năm
gần đây, các quy trình phần mềm trong nhóm phƣơng pháp phát triển linh hoạt
Agile đƣợc sử dụng phổ biến và mang lại nhiều thành công cho các công ty phần
mềm, trong đó hai quy trình đƣơ ̣c áp du ̣ng rô ̣ng raĩ nhấ t đó là quy trình Scrum
và lập trình cực hạn XP.
1.1.1. Quy trin
̀ h Scrum
Thuật ngữ“Scrum”đƣợc trình bày lần đầu tiên trong bài báo của Takeuchi
và Nonakavào năm 1986 [3]vềkhả năng thích nghi, nhanh chóng, tính tự tổ chức
trong việc phát triển phần mềm. Thuật ngữ “Scrum” có nguồn gốc từ một chiến
thuật trong môn bóng bầu dục ám chỉ việc đƣa bóng vào cuộc.Kent Schwaber
lần đầu tiên mô tả về phƣơng pháp Scrum vào năm 1996, là một quá trình chấp
nhận và phát triển các yêu cầu chƣa đƣợc xác định trƣớc.
Nguyên tắc của phƣơng pháp Scrum là phát triển một phần mềm bằng việc
gia tăng dần viê ̣c cài đă ̣t các yêu cầu phầ n mề m . Phầ n mề m thƣờng xuyên đƣơ ̣c
bàn giao cho khách hàng theo hƣớng bổ sung thê m các tính năng mới hoă ̣c cải
thiê ̣n các tính năng của phiên bản trƣớc theo đúng yêu cầ u của khách hàng
.
Scrum làm viê ̣c theo quy trình lă ̣p , mỗi vòng lặp gọi là một Sprint thƣờng có
một khoảng thời gian cố định khoảng từ 2 đến 4 tuần. Cách thức làm việc của
từng vòng lặp mô tả nhƣHình 1-2[3].
Mô ̣t dƣ̣ án phầ n mề m áp dụng quy trình Scrum thƣ ờng đƣợc cài đặt theo
các bƣớc sau [3]:
Bƣớc 1: Thu thập các đặc điểm của sản phẩm.
Các đặc điểm của sản phẩm hay còn gọi là các yêu cầu đƣợ c thu thâ ̣p thông

qua cuô ̣c trao đổ i với khách hàng , các yêu cầu đƣợc tập hợp lại thành tập yêu
cầ u sản phẩm (product backlog). Đây là bƣớc quan trọng nhất, quyế t đinh
̣ sƣ̣
thành công của dự án . Ở bƣớc này , ngƣời quản lý dƣ̣ án cũng thành lập các đội
làm việc, các đội này thƣờng xuyên thảo luận với nhau về nghiệp vụ cần làm và
bổ nhiệm một ngƣời vào vị trí chủ sản phẩm (Product owner), ngƣời này có khả
năng trao đổi, bao quát công việc tốt, biết sắp xếp đô ̣ ƣu tiên cho cá c nhiê ̣m vu ,̣


-7cho các công viê ̣c . Sau đó tự tổ chức lại đội làm việc, đề xuất ra vị trí Scrum
master và thảo luận chi tiết các yêu cầu, sắp xếp chúng theo thứ tự ƣu tiên. Các
vai trò và sản phẩ m của Scrum đƣơ ̣c triǹ h bày chi tiế t ở các phầ n sau.

Hình 1-2. Quy triǹ h Scrum
Bƣớc 2: Ƣớc lƣợng các yêu cầu về sản phẩm đầu ra.
Bƣớc này còn go ̣i là bƣớc ƣớc lƣợng các yêu cầu ở mức độ cao:Chia sản
phẩm thành mô ̣t số danh mục backlog , số lƣơ ̣ng danh mu ̣c có thể đƣơ ̣c điề u
chỉnh, bổ sung trong quá trin
̀ h phát triể n ; Ƣớc lƣợng chi tiết từng backlog, ƣớc
lƣợng số lƣợng các đội làm việc, …
Bƣớc 3: Lên kế hoạch phát triển các vòng lặp Sprint.
Thông qua các cuộc trao đổi kế hoạch phát triển Sprint với tất cả các thành
viên để xác định chi tiết của Sprint . Giai đoa ̣n này cũng xác địnhmục tiêu của
Sprint là gì, sẽ đạt đƣợc gì, phân tích các yêu cầu của Sprint một cách rõ ràng.
Bƣớc 4: Lên kế hoạch phát triển các tác vu ̣ của Sprint.
Đầu tiên, đô ̣i dƣ̣ án sẽ ho ̣p la ̣i để xác định ngân sách của Sprint đó, sau đó
chia các đặc điểm thành các tác vụ nhỏ hơn, ƣớc lƣợng thời gian sẽ làm từng tác
vụ, hoàn tất các yêu cầu và nhận dạng tác vụ quan trọng.
Bƣớc 5: Tạo ra không gian làm việc cộng tác cho tất cả mọi ngƣời.
Môi trƣờng làm viê ̣c là yế u tố quan tro ̣ng trong viê ̣c áp du ̣ng

quy trình
Scrum; Các thành viên tự chịu trách nhiệm cho các tác vụ của mình và có sự


-8giao tiế p với các thành viên khác khi cần thiết. Với hê ̣ thố ng phát triể n theo quy
trình Scrum, quá trình làm việc đội dự án thƣờng sử dụng bảng trắng để nêu
những vấn đề cần thiết cho tất cả mọi ngƣời cùng đánh giá.
Bƣớc 6: Các thành viên bắt tay xây dựng từng Sprint.
Giai đoa ̣n này đô ̣i phát triể n t iế n hành các công viê ̣c l ập trình, kiểm thử và
điều chỉnh thời gian để có hiệu quả tốt nhất. Khi thƣ̣c hiê ̣n mô ̣t Sprint không
hiê ̣u quả hoă ̣c gă ̣p bế tắ c không giải quyế t đƣơ ̣c , các bên liên quan có thể điều
chỉnh, hủy bỏ Sprint đó để quay lại pha lập kế hoạch.
Bƣớc 7: Các thành viên báo cáo kết quả để tiếp tục làm việc.
Trong Scrum, các thành viên thƣờng xuyên báo cáo công việc thông qua
các cuộc họp ngắn. Các báo cáo tập trung vào các vấn đề: đạt đƣợc những gì so
với lần trao đổi trƣớc; sẽ hoàn thành những gì trong lần trao đổi tiếp theo; có
những trở ngại gì trong quá trình làm việc. Thông qua các báo cáo sẽ nhanh
chóng giải quyết các vấn đề còn tồn đọng để tiếp tục công viê ̣c.
Bƣớc 8: Tổng hợp kết quả trên biểu đồ.
Với dƣ̣ án áp du ̣ng quy triǹ h Scrum, quá trình làm việc và tiến độ công việc
sẽ thƣờng xuyên đƣợc cập nhật thông qua biểu đồ burn down . Đây là bức tranh
tổng quát về những việc đã làm đƣợc, những việc chƣa làm đƣợc, thời gian ƣớc
lƣợng còn lại, … . Biểu đồ burn down giúp cho ngƣời quản lý và đội phát triển
biết tình hìnhphát triển dự án để nhanh chóng có những điều chỉnh cho phù hợp
với thực tế.
Bƣớc 9: Xem xét để hoàn tất.
Mô ̣t ràng buô ̣c quan tro ̣ng nhấ t trong quy triǹ h Scrum là c ác thành viên tự
chịu trách n hiê ̣m cho công viê ̣c của miǹ h . Khi các thành viên thông báo công
việc đã hoàn thành có nghĩa là mọi thay đổi sẽ bị từ chối ở Sprint đó , nế u còn
tồ n đo ̣ng sẽ đẩy lại cho vòng lặp sau.

Bƣớc 10: Đánh giá, phản ánh và lặp lại.
Các thành viên tham gia dự án t hƣờng xuyên có các cuộc họp đánh giá lại
Sprint. Các cuộc họp tập trung vàokết quả đã đạt đƣợc
, phản hồi của khách
hàng, xem xét thời hạn thƣ̣c hi ện của Sprint. Thông qua biể u đồ burn down ở
bƣớc 8 để xác định lại toàn bộ hệ thống và tiếp nhận những đóng góp, bổ sung
để đƣa tiếp vào các vòng lặp Sprint tiếp theo.
Quy trin
̀ h phát triể n phầ n mề m Scrum chia các bên liên quan thành các
nhóm ngƣời riêng biệt và phân định quyền hạn cho mỗi nhóm. Viê ̣c chia nhóm


-9nhằ m đảm bảo cho dƣ̣ án đƣơ ̣c thƣ̣c hiê ̣n mô ̣t cách trôi chảy và thôi thúc các
thành viên tự chịu trách nhiệm cho công việc c ủa mình. Trong quy trình Scrum
có các nhóm ngƣời dùng sau:
 Chủ sở hữu sản phẩm (Product owner):Là mô ̣t ngƣời chịu trách nhiệm
cho toàn dự án; quản lý, kiểm soát và thống kê các yêu cầu chƣa đƣợc thực hiện
của cầu sản phẩm. Product owner đƣợc lựa chọn bởi nhƣ̃ng ngƣời lañ h đa ̣o
nhóm, khách hàng và quản lý dƣ̣ án.
 Trƣởng nhóm (ScrumMaster): Là ngƣời hỗ trợ đắc lực cho dự án, làm
việc chặt chẽ với ngƣời chủ sở hữu sản phẩm.Ngƣời này có trách nhiê ̣m kiểm tra
công việc của các thành viên và đảm bảo đội phát triển hoạt động năng suất,
hiệu quả.
 Đội phát triển (ScrumTeam): Là một đội tập trung khoảng từ 4 đến 10
thành viên có kinh nghiệm và có vai trò thiế t yế u trong một dự án. Đội phát triển
có quyền quyết định những hoạt động cần thiết để đạt đƣợc mục tiêu của Sprint.
 Khách hàng (Customer): Là những ngƣời t ham gia vào dƣ̣ án để thƣ̣c
hiê ̣n các nhiệm vụ mô tả yêu cầ u nhằ m kiể m soát chấ t lƣơ ̣ng sản phẩ m .
 Quản lý dƣ̣ án (Management): Là ngƣời q uyết định kết quả cuối cùng
của dự án, tham gia vào việc thiết lập các yêu cầu.

Việc phân chia các vai trò này nhằm mục đó gán trách nhiệm và quyền hạn
cho mỗi nhóm ngƣời và yêu cầu vai trò đó phải tự chịu trách nhiệm cho công
việc của mình. Chính sự quản lý chặt chẻ theo cấp bậc từ trên xuống dƣới tạo
cho các bên liên quan đến dự án có thể làm việc theo ý của mình mà không đi
lê ̣ch mục tiêu của vòng lặp là nhằm tạo sự hài lòng cho khách hàng.
Trong quy trình Scrum cũng rất chú trọng đến việc giao tiếp giữa các bên
liên quan để phát triển sản phẩm, nhằm tạo điều kiện cho các vòng lặp thực hiện
một cách trôi chảy. Có một số hình thức họp bàn nhƣ sau:
i.

Họp lập kế hoạch cho Sprint (Sprint planning)

Đội phát triển sẽ gặp gỡ với chủ sở hữu sản phẩm, ngƣời quản lý, khách
hàng nhằm lên kế hoạch làm việc cho một Sprint. Cuô ̣c ho ̣p này giải quyế t c ác
công việc nhƣ là: lựa chọn các yêu cầu cần phát triển, phân tích và nhận biết các
công việc phải làm kèm theo các ƣớc lƣợng thời gian cần thiết để hoàn tất các
công việc. Quy trin
̀ h Scrum sử dụng phƣơng thức lập kế hoạch từng phần và
tăng dần theo thời gian. Theo đó, việc lập kế hoạch không diễn ra duy nhất một
lần trong vòng đời của dự án mà đƣợc lặp đi lặp lại cho tƣ̀ng Sprint.


-10Việc giao tiếp thƣờng xuyên giữa khách hàng, chủ sở hữu sản phẩm và
ngƣời quản lý dự án sẽ giúp bổ sung các yêu cầu thiếu sót một cách liên tục và
nhanh chóng làm rõ các yêu cầu đang tồn đọng, giúp đội phát triển luôn luôn
thực hiện phần mềm đúng theo yêu cầu của khách hàng. Khi khách hàng có sự
thay đổi yêu cầu, các bên cần phải thảo luận các lý do thay đổi, mục đích của
việc thay đổi và kết quả của việc thay đổi nhằm phân tích xem sự thay đổi đó có
cải tiến chất lƣợng sản phẩm hay không? Hay chúng có ảnh hƣởng tới phầ n hê ̣
thố ng đã phát triể n hay không?

ii.

Họp hằng ngày (Daily Scrum)

Mỗi ngày, toàn đội sẽ tập trung trong vòng 15 phút vào đầu buổi sáng để
tổng kết công việc ngày hôm qua, kế hoạch công việc sẽ làm trong ngày hôm
nay và kiểm tra các tình huống có thể cản trở công việc trong ngày đó. Các
vƣớng mắc về mặt kỹ thuật, cũng nhƣ về mặt nghiệp vụ sẽ đƣợc giải quyết một
cách nhanh chóng để toàn đội phát triển có thể tiếp tục công việc của mình.
iii.

Họp đánh giá (Sprint Review)

Cuối mỗi Sprint, đội phát triển cùng với chủ sở hữu sản phẩm sẽ rà soát lại
các công việc đã hoàn thành trong Sprint đó và đề xuất các chỉnh sửa hoặc thay
đổi cần thiết cho sản phẩm.
iv.

Họp cải tiến (Sprint Retrospective)

Dƣới sự chỉ đạo của đô ̣i trƣởng, toàn đội phát triển sẽ rà soát lại toàn diện
Sprint vừa kết thúc và tìm cách cải tiến quy trình làm việc cũng nhƣ sản phẩm
đƣợc tạo ra từ Sprint đó.
Việc kiểm tra sản phẩm thƣờng xuyên thông qua các cuộc họp giúp cho hê ̣
thố ng luôn phát triển đúng theo mục tiêu mà chủ sở hữu và khách hàng đề ra.
Nếu quá trình thực hiện Sprint có vấn đề phát sinh thì nó sẽ đƣợc xem xét dƣới
các góc độ kỹ thuật và về mặt nghiệp vụ để nhanh chóng giải quyết, đảm bảo
phần mềm phát triển đúng tiến độ vàtạo ra sản phẩm có chất lƣợngcao.
1.1.2. Lập trình cực hạn
Lâ ̣p trin

̀ h cƣ̣c ha ̣n(Extreme Programming viế t tắ t là XP) là một trong nhƣ̃ng
phƣơng pháp phát triể n phầ n mề m hiê ̣n đa ̣i đƣợc sử dụng khá phổ biế n , do
Martin Flower và Ron Jeffries đề xƣớng[2]. Phƣơng pháp này nhấn mạnh vào sự
cộng tác giƣ̃a các thành viên liên quan tới dƣ̣ án nhằ m tạo ra phần mềm một
cách nhanh chóng và dễ mở rộng trong quá trình thực hiện. Phƣơng pháp lâ ̣p
trình cực hạn đƣợc cô đọng trong bốn nguyên tắc: sự trao đổi(communication),
đơn giản hóa (simplicity), sự phản hồi (feedback), và sự dũng cảm (courage)[2].


-11Lâ ̣p trình cực hạn đƣơ ̣c đánh giá là quy trình phù hợp với các dự án khách
hàng thƣờng xuyên thay đổi yêu cầu và mong muốn sớm nhận đƣợc sản phẩm từ
ngƣời phát triển. Phƣơng pháp này khuyến khích các nhóm làm việc chung với
nhau, bàn giao các phiên bản phần mềm chất lƣợng cao hơn các phƣơng pháp
truyền thống.
Phƣơng pháp lâ ̣p trin
̀ h cƣ̣c ha ̣n đă ̣t ra mô ̣t tâ ̣p các quy tắc và các thực hành
giúp ngƣời lập trình mô tả chi tiết các hoạt động. Vòng đời của dƣ̣ án phầ n mề m
phát triển bằng lập trình cực hạn XP gồm có các pha: khảo sát, lập kế hoạch,lặp
để phát hành,sản xuất, bảo trì và kết thúcnhƣHình 1-3[2].

Hình 1-3. Vòng đời của dự án XP
Các dự án sử dụng lâ ̣p triǹ h cƣ̣c ha ̣n XP sẽ bắt đầu với một tập yêu cầu
đƣợc gọi là tâ ̣p câu chuyện ngƣời dùng. Các câu chuyện ngƣời dùng đƣợc viết
bởi khách hàng và đƣợc sắp xếp theo độ ƣu tiên. Lập trình cực hạn XP là quy
trình phát triển lặp, thông qua các vòng lă ̣p , phần mềm thƣờng xuyên đƣợc tích
hợp thêm các tính năng mới hoă ̣c cải thiê ̣n tiń h năng đã có; Cuối mỗi vòng lặp
sản phẩm sẽ đƣợc kiểm thử chấp nhận bởi khách hàng, nếu phiên bản đó đáp
ứng các tiêu chí kiểm thử chấp nhận thì các phần chức năng vừa đƣợc tiến hành
trong vòng lặp đó sẽ đƣợc tích hợp thêm vào hệ thống mới, ngƣợc lại sẽ phải bổ
sung hoặc chỉnh sữa các yêu cầu để đƣa vào vòng lặp tiếp theo. Với dƣ̣ án áp

dụng lập trình cực hạn , hệ thống đƣợc phát triển theo đúng yêu cầu của khách
hàng. Một vòng lặp không mang lại lợi ích cho khách hàng thì các tính năng của
vòng lặp đó sẽ sớm đƣợc loại bỏ hoặc cải thiện theo hƣớng tốt hơn.

1.2. Kiểm thử trongphƣơng pháp triển linh hoạt


-12Để dự án phát triển theo phƣơng pháp phát triển linh hoạt Agile thành công
thì kiểm thử đóng vai trò rất quan trọng. Ở đây, việc kiểm thử không đơn thuần
là kiểm tra tính đúng đắn của mã nguồn phần mềm so vớitài liê ̣u đặc tả yêu cầ u .
Chìa khóa quan trọng nhất vẫn là sự giao tiế p giữa thành phần phát triển dự án
và ngƣời kiểm thử. Trong các quy triǹ h phát triể n phầ n mề m của phƣơng pháp
phát triển linh hoạt ,kiểm thử viên tham gia vào dự án và kiểm thử phần mềm
ngay cả khi hệ thống chƣa hoàn thiện. Việc kiểm thử sớm nhằm tăng độ tin cậy
của quá trình phát triển phần mềm. Chẳng hạn trong lâ ̣p trình cƣ̣c ha ̣n XP, độ tin
cậy đƣợc xây dựng dựa trên hai mức kiểm thử: kiểm thử đơn vị thông qua quá
trình sử dụng phƣơng pháp phát triển phần mềm theo hƣớng kiểm thử TDD và
kiểm thử chấp nhận. Kiểm thử đơn vị để đảm bảo các yêu cầu của hệ thống làm
việc đúng và kiểm thử chấp nhận để đảm bảo rằng chƣơng trình đúng đã đƣợc
cài đặt phù hợp với yêu cầu khách hàng . Trong quy trình Scrum thì khái niệm
kiểm thử tích hợp và kiểm thử chấp nhận không đƣợc nêu rõ, vì thế các cá nhân
trong đội phát triển sẽ xác định các vấn đề liên quan đến kiểm thử và tự chịu
trách nhiệm cho các chức năng do miǹ h thƣ̣c hiê ̣n. Kiểm thử trong phƣơng pháp
phát triển linh hoạt cònthể hiện qua việc xây dựng một quy cách làm việc nhằm
đảm bảo chất lƣợng phần mềm.
Trong phƣơng pháp phát triể n linh hoa ̣t, việc đảm bảo chất lƣợng sản phẩm
đƣợc thực hiện bởi tất cả thành viên tham gia vào dự án. Các lập trình viên thực
hiện kiểm thử đơn vị và kiểm thử tích hợp. Đại diện khách hàng kiểm tra công
việc của lập trình viên và trợ giúp họ bằng cáckiểm thử của khách hàng. Khi các
kiểm thử viên tìm ra lỗi, cả đội cùng nhau phân tích nguyên nhân và tìm cách cải

tiến quy trình để ngăn ngừa lỗi tái diễn.Sƣ̉ du ̣ng các quy triǹ h trong phƣơng
pháp này việc phát triển phần mềm thƣờng gắn liền
với công cu ̣ kiể m thƣ̉ tƣ̣
đô ̣ng để hỗ trơ ̣ kiể m thƣ̉ hồ i quy hê ̣ thố ng mô ̣t cách nhanh chóng, chính xác. Các
kiểm thử hồi quythƣờng đƣợc thực hiện bởi các lập trình viên khi họ tích hợp
thêm mã nguồn mới vào hệ thống; phƣơng pháp l ập trình theo cặp cũng góp
phần nâng cao chất lƣợng công việc.
Sƣ̉ du ̣ng phƣơng pháp phát triể n linh hoa ̣t, các mức kiểm thử thƣờng chồng
chéo lên nhau để đảm bảo các phần của hệ thống làm việc đƣợc phát hành liên
tục. Không giống nhƣ trong kiểm thử truyền thống, cái khái niệm về các mức
kiểm thử cũng có sự thay đổi. Trong lâ ̣p triǹ h cƣ̣c ha ̣n XP thì kiểm thử đƣợc chia
theo hai mức đơn giản là kiểm thử đơn vị và kiểm thử chấp nhận, còn trong quy
trình Scrum thì không có khái niệm rõ ràng cho các mức kiểm thử. Tuy nhiên có
thể tạm chia kiểm thử thành các mức nhƣ sau:


-131.2.1. Kiểm thử đơn vị
Kiểm thử đơn vị hay còn gọi là kiểm thử do ngƣời phát triển thực hiện
đƣợc hiểu tƣơng tự nhƣ khái niệm kiểm thử đơn vị truyền thống. Tuy nhiên,
kiểm thử đơn vị ở đây thƣờng sử dụng cùng với phát triển hƣớng kiểm thử
TDD[2], tức là các hàm kiểm thử chochức năng sẽ đƣợc viết trƣớc khi viết mã
nguồn cho chức năng đó.
1.2.2. Kiểm thử chấp nhận tronglâ ̣p trin
̀ h cƣ̣c ha ̣n XP
Kiểm thử chấp nhận trong XP lại đƣợc định nghĩa rộng hơn so với kiểm
thử chấp nhận trong phƣơng pháp kiểm thử truyền thống. Kiểm thử chấp nhận
có thể bao gồm kiểm thử chức năng, kiểm thử tích hợp, kiểm thử đầu cuối, kiểm
thử hiệu năng, kiểm thử chịu tải, kiểm thử bảo mật, kiểm tra tính khả dụng, …
Trong XPkiểm thử chấp nhận còn đƣợc gọi là kiểm thử chức năng hay kiểm thử
của khách hàng[2].

Kiểm thử chấp nhận thƣờng đƣợc viết bởi khách hàng hoặc có sự hỗ trợ
của kiểm thử viên. Ở nhiều dự án, kiểm thử đôi khi còn đƣợc bàn bạc bởi toàn
đội phát triển dự án. Mục đích của kiểm thử chấp nhận là đảm bảo phần mềm
làm ra đáp ứng mong muốn của khách hàng, nhằm tăng độ tin cậy cho sản
phẩ m[2]. Kiểm thử chấp nhận không đòi hỏi phải thực hiện ở tất cả các chức
năng, cho tất cả các trƣờng hợp nhƣ ở kiểm thử đơn vị, mà ở đây chỉ kiểm thử
những tính năng mà khách hàng mong muốn. Việc kiểm thử chấp nhận thƣờng
đƣơ ̣c thƣ̣c hiê ̣n tƣ̣ đô ̣ng nhờ vào các công cu ̣ hỗ trơ ̣ , tuy nhiên việc kiểm thử tự
động tất cả các chức năng là vô cùng khó khăn và trong phƣơng pháp phát triển
linh hoạt Agile thì quan trọng nhất vẫn là nhóm phát triển tự chịu trách nhiệm về
phần việc do mình thực hiện.

1.3. Đặc tả yêu cầu hệ thống bằng câu chuyện ngƣời dùng
Trong quá trình phát triển phần mềm, để bàn giao đƣợc sản phẩm đáp ứng
các yêu cầu nghiệp vụ của khách hàng thì việc tiếp nhận và mô tả yêu cầu của hệ
thống cần có những cách thức phù hợp. Có một số phƣơng pháp thƣờng dùng
nhƣ: biể u đồ ca sử dụng (user – case); đặc tả yêu cầu phần mềm theo IEEE
830;thiết kế ngƣ̃ cản h tƣơng tác;câu chuyện ngƣời dùng (user story), …[5].
Trong các quy trình phát triển phần mềm theo phƣơng pháp linh hoạt Agile để
mô tả các yêu cầu hệ thống thƣờng sƣ̉ du ̣ng câu chuyê ̣n ngƣời dùng . Một câu
chuyện ngƣời dùng thƣờng bao gồm ba phần:
 Tiêu đề: Chứa một mô tả ngắn gọn, rõ ràng để xác định câu chuyện, còn
đƣợc gọi là mẫu chuyện (story card).


-14 Mô tả - thân (Narrative):Thân câu chuyê ̣n là các mô tả để làm rõ chi tiết
của câu chuyện, trong phầ n thân câu chuyê ̣nit́ chú tro ̣ng đế n viê ̣c viế t tài liê ̣u ,
thay vào đó là nhấn mạnh vào việc giao tiếp với khách hàng để cócâu chuyê ̣n.
Phần thân câu chuyê ̣n bao gồ m các thông tin:
+ Ai (khách hàng hoặc thành viên đội phát triển) giữ vai trò chính

trong câu chuyện đó.
+ Kết quả mà tác nhân đó mong muốn ở câu chuyện
+ Giá trị nghiệp vụmà tác nhân sẽ nhận đƣợc từ kết quả đó.
 Các tiêu chí kiểm thử chấp nhận: Là các tiêu chí để xác định điể m kế t
thúc câu chuyê ̣n, phần này mô tả các trƣờng hợp cụ thể cho từng câu chuyê ̣n:
+ Mô tả m ột hoặc nhiều mệnh đề giả định điều kiện đúng trƣớc khi
khởi tạo ngữ cảnh.
+ Tiế p theo, xác định các sự kiện khởi tạo ngữ cảnh.
+ Cuối cùng, xác định các kết quả mong muốn trong một hoặc nhiều
mệnh đề.
Một câu chuyện ngƣời dùng thƣờng mô tả một tính năng tƣơng đối hoàn
chỉnh và ít phụ thuộc vào câu chuyện ngƣời dùng khác, điều đó giúp việc thay
đổi yêu cầu trong quá trình phát triển dự án dễ dàng hơn, bởi khi thay đổi một
câu chuyện ngƣời dùng hay thay đổi độ ƣu tiên của nó thì dự án vẫn có thể tiếp
tục đƣơ ̣c tiến hành bằng cách đƣa vào vòng lặp các câu chuyện ngƣời dùng khác
mà không làm ảnh hƣởng đến tiến trình chung của dự án.
Quá trình xác định câu chuyện ngƣời dùng nên làm rõ các lớp ngƣời sử
dụng, vai trò của khách hàng, đối tƣợng sẽ tƣơng tác trực tiếp với hê ̣ thố ng ở câu
chuyê ̣n đó . Việc xác định vai trò của ngƣời sử dụng rất quan trọng, quyết đinh
giá trị mà hệ thống sẽ mang lại cho ngƣời sử dụng. Một câu chuyện ngƣời dùng
có thể rất quan trọng cho lớp ngƣời dùng này nhƣng lại ít quan trọng với các đối
tƣợng khác. Sau khi xác định đƣợc ngƣời dùng nắm vai trò sử dụng trực tiếp thì
câu chuyện ngƣời dùng đƣợc viết theo quan điểm của ngƣời dùng đó, điều này
giúp cho việc phát triển hệ thống theo đúng mong muốn của ngƣời sử dụng.
Kiểm thử chấp nhận là một phần của câu chuyện ngƣời dùng bởi vì trong
mỗi câu chuyện ngƣời dùngmô tả các tiêu chí để xác định khi nào thì câu chuyện
ngƣời dùng đƣợc đặt ở trạng thái kết thúc. Có hai vấn đề quan trọng trong kiểm
thử chấp nhận và các câu chuyện ngƣời dùng.

-15 Thƣ́ nhấ t : Kiểm thử chấp nhận là kết quả của việc trao đổi giữa khách
hàng và đội phát triển.
 Thƣ́ hai: Việc trao đƣợc tiến hành trƣớc khi một câu chuyện ngƣời dùng
đƣợc cài đặt.
Điều này có nghĩa là kiểm thử chấp nhận đƣợc tiến hành trƣớc khi cài đặt
chƣơng trình và kiểm thử đó phải do khách hàng viết hoặc đƣợc viết với sự tham
gia của khách hàng nhằm mục đích làm cho sản phẩm phần mềm đáp ứng đúng
mong muốn của ngƣời sử dụng, tăng độ tin cậy của sản phẩm. Để viế tcâu chuyện
ngƣời dùng có các bƣớc cơ bản nhƣ sau:
i.

Xác định mục đích của câu chuyện.

ii.

Phân rã câu chuyện: Đối với các câu chuyện đã đƣợc định nghĩa quá
dài và phức tạp thì ta có thể chia nhỏ chúng thành nhiều câu chuyện
nhỏ hơn, tuy nhiên việc chia nhỏ này vẫn phải đảm bảo tính chất khép
kín của câu chuyện.

iii.

Giới hạn kích thƣớc câu chuyện: Chi tiết của câu chuyện quyế t đinh
̣
cách cài đặt câu chuyê ̣n đó . Do vâ ̣y, tùy thuộc vào kích thƣớc, tầ m
quan tro ̣ng câu chuyện sẽ đƣợc xếp hạng ƣu tiên để làm tiêu chí đƣa
vào các vòng lặp.

iv.

Không áp đặt giao diện sử dụng cho câu chuyê ̣n : Khi xác định câu
chuyện chỉ nên tổng quát hóa, câu chuyê ̣n không đƣơ ̣c phụ thuộc vào
giao diện ngƣời dùng. Giao diện ngƣời dùng nên để phát triển ở giai
đoạn sau.

v.

Mô tả vai trò của ngƣời sƣ̉ du ̣ng trong câu chuyện: Khi mô tả câu
chuyê ̣n ngƣời dùng cầ n mô tả cả vai trò của ngƣời sƣ̉ du ̣ng nó vào nô ̣i
dung câu chuyê ̣n . Điề u này giúp cho câu chuyê ̣n dễ hiể u và các tiêu
chí kiểm thử chấp nhận đƣợc rõ ràng hơn.

Câu chuyê ̣n ngƣời dùng thƣờng đƣơ ̣c viế t dƣới da ̣ng ngôn ngƣ̃ tƣ̣ nhiên để
khách hàng có thể hiểu đƣợc và tự viết câu chuyện ngƣời dùng cho sản phẩm .
Tuy nhiên, câu chuyện ngƣời dùng thƣờng đƣơ ̣c mô tả theo mô ̣t da ̣ng thƣ́c thố ng
nhấ t, giúp cho đội phát triển và ngƣời dùng cùng thống nhất cách hiểu về câu
chuyê ̣n đó , viê ̣c lƣ̣a cho ̣n da ̣ng thƣ́c biể u diễn tùy tƣ̀ng dƣ̣ án , tùy thuộc vào văn
hóa và ngôn ngữ của ngƣời sƣ̉ du ̣ng . Mô ̣t da ̣ng thƣ́c phổ biế n để biể u diễn câu
chuyê ̣n ngƣời dùng nhƣ sau:
As a <User Role>
I want <Action or Goal>


-16So that <Business value>

Trong đó:
 User Role: Thể hiê ̣n mô ̣t nhóm ngƣời dùng hay hê ̣ thố ng sƣ̉ du ̣ng chƣ́c
năng mà câu chuyện mô tả.
 Action or Goal: Thể hiê ̣n mu ̣c đić h hay hoa ̣t đô ̣ng câu chuyê ̣n mang la ̣i.
 Business value: Thể hiê ̣n giá tri ̣nghiê ̣p vu ̣ của câu chuyê ̣n.

Ví dụ: Thể hiê ̣n chƣ́c năng liên hê ̣ của mô ̣t trang web.
As a visitor
I want to contact an email address
So that I can submit a contact form

Câu chuyện ngƣời dùng có vai trò quyết định sự thành công của ứng dụng
phần mềm, nó mô tả yêu cầu nghiệp vụ, cũng nhƣ đặt ra một số thuộc tính kiểm
thử chấp nhận cho yêu cầ u mà câu chuyê ̣n đó mô tả . Câu chuyê ̣n ngƣời dùng
thƣờng đƣơ ̣c mô tả bằ ng ngôn ngƣ̃ tƣ̣ nhiên để khách hàng có thể hiể u đƣơ ̣c , tuy
nhiên để tránh viê ̣c thƣ̣c hiê ̣n sai yêu cầ u ngƣời dùng bởi quá triǹ h dich
̣ tƣ̀ ngôn
ngƣ̃ tƣ̣ nhiên thành các ngôn ngƣ̃ k ỹ thuâ ̣t, trong các phƣơng pháp phát triể n
phầ n mề m hiê ̣n đa ̣i thƣờng có mô ̣t số quy ƣớc về da ̣ng thƣ́c mô tả câu chuyê ̣n
ngƣời dùng. Mô tả phổ biế n nhấ t là sƣ̉ du ̣ng các ngôn ngƣ̃ mô hình , hoă ̣c ngôn
ngƣ̃ tƣ̣ nhiên có cấ u trúc để viế t câu chuyê ̣n ngƣời dùng . Đối với các quy trình
phát triển phầ n mề m có sƣ̉ du ̣ng các công cu ̣ hỗ trơ ̣
kiể m thƣ̉ tƣ̣ đô ̣ng , câu
chuyê ̣n ngƣời dùng nên bao hàm cả các tiêu chí kiể m thƣ̉ chấ p nhâ ̣n, để các tiêu
chí đó làm tiền đềcho quá trình kiể m thƣ̉.

1.4. Các kỹ thuật phát triển phần mềmtheo hƣớng kiểm thử
1.4.1. Phát triển phần mềm theo hƣớng kiểm thử
Phát triển phần mềm theo hƣớng kiểm thử (Test-Driven DevelopmentTDD) là yế u tố cơ bản trong các quy trình phát triển phần mềm theo phƣơng
pháp phát triển linh hoạt Agile nhằm đáp ứng sự thay đổi yêu cầu ngƣời dùng
trong quá trình cài đặt phần mềm, đólà một phƣơng pháp tiếp cận cải tiến để
phát triển phần mềm, trong đó kết hợp phƣơng pháp phát triển kiểm thử trƣớc
(Test First Development) và phƣơng pháp điều chỉnh lại mã nguồn
(Refactoring). Mục tiêu của TDD là viết mã nguồn sáng sủa, rõ ràng và có thể
chạy đƣợc.Nguyên lý làm việc của TDD theo 3 điểm chính nhƣHình 1-4:
 Viế t các hàm kiể m thƣ̉ , ban đầ u đă ̣t chúng ở trạng thái thất bại : Trƣớc khi

viế t mã cài đă ̣t mô ̣t chƣ́c năng , các lập trình viên sẽ tạo ra một kiểm thử đơn vị


-17mô tả cách mà chức năng đó sẽ đƣợc cài đặt theo đúng tài liệu yêu cầu. Kiểm
thử này ban đầu ở trạng thái thấ t ba ̣i.
 Cài đặt mã nguồn chƣơng trình để kiểm thử đó thành công :Sau khi có
hàm kiểm thử , lâ ̣p trin
càng nhanh
̀ h viên tiế n hành cài đă ̣t cho chƣ́c năng đó
càng tốt. Viê ̣c viế t mã nguồn đƣợc thực hiện cho tới khi các kiểm thử tƣơng ứng
ở trạng thái thành công.
 Điề u chỉnh mã nguồn: Sau khi hoàn thiê ̣n giai đoa ̣n cài đă ̣t mã nguồ n cho
chƣ́c năng, lâ ̣p trin
̀ h viên cầ n loại bỏ các phần mã cài đặt bịtrùng lặp hoặc không
phù hợp nhằ m làm cho mã nguồ n ƣ́ng du ̣ng sáng sủa, rõ ràng hơn.

Hình 1-4. Nguyên lý TDD
Phát triển phần mềm dựa vào kiểm thử thay đổi hoàn toàn so với cách phát
triển phầ n mề m theo phƣơng pháp truyền thống. Trong phƣơng pháp này , khi
bắt đầu thực hiện một tính năng mới, câu hỏi đầu tiên đặt ra là liệu thiết kế hiện
tại có phải là thiết kế tốt nhất cho phép lập trình viên thực hiện các chức năng
hay không? Nếu có, tiến hành thực hiện thông qua một phƣơng pháp phát triển
kiểm thử trƣớc. Nếu không, nhà phát triển cần điều chỉnh lại nó một cách cục bộ
để thay đổi riêng phần thiết kế bị ảnh hƣởng bởi tính năng mới, điều này giúp dễ
dàng bổ sung thêm các tính năng còn thiếu sót, nâng cao chất lƣợng của thiết
kế.
Vòng đời của một dự án áp dụng quy TDD đƣợc mô tả nhƣ Hình 1-5 gồ m
các bƣớc sau:
a. Thêm một kiểm thử
Trong phƣơng pháp phát triể n hƣớng kiể m thƣ̉ TDD , phát triển một tính

năng mới bắ t đầ u bằ ng viê ̣c viế t mô ̣t kiể m thƣ̉ , trạng thái của kiểm thử này ban
đầ u đƣơ ̣c đă ̣t là thấ t ba ̣i vì chƣa có mã nguồ n cài đă ̣t tƣơng ƣ́ng. Dƣ̣a vào đă ̣c tả
yêu cầ u, các trƣờng hợp sử dụng, các tiêu chí kiểu thử chấp nhận của câu chuyện
ngƣời dùng, lâ ̣p trình viên phải hiể u , bao quát đƣơ ̣c yêu cầ u và các trƣờng hơ ̣p