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

ĐẠ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
HƢỚNG HÀNH VI VÀƢ́NG DUNG ̣ 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
HƢỚNG HÀNH VI VÀƢ́NG DUNG ̣ 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ịhọc
Công nghê, ̣Đaịhọc Quốc g ia HàNôị đã 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 siTrƣơ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 đinh̀
đăc ̣ biêṭ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 MUC ̣ CÁC TƢ̀ VIÊT TĂT.................................................................................................... v

DANH MỤC BẢNG BIỂU............................................................................................................. vi
DANH MUC ̣ HÌNH VE..................................................................................................................... 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 HOAT................................................................................................................................ 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 trinh̀ 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 ̣ trinh̀ cƣc ̣ haṇ 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 ky ̃thuâṭ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ôṭsốvấn đềcủa phát triển phần mềm dƣạ 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 dung ̣......................................................................................... 29
2.3.2. Viết kiểm thƣƣ cho các bƣớc........................................................................................... 30
2.3.3. Lăp ̣ đểcài đăṭƣ́ng dung ̣...................................................................................................... 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ṇ chuẩn bi.... ̣ .............................................................................................................. 60
4.2. Tiến trinh̀ thƣc ̣ hiêṇ ƣ́ng dung ̣............................................................................................. 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 MUC ̣ 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 đinḥ nghiã bƣớc đểtaọ yêu cầu........................53
Bảng 3-3 MinkContext các đinḥ 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 MUC ̣ HÌNH VE
Hình 1-1. Mô hình phát triển lặp...........................................................................5
Hình 1-2. Quy trinh̀ 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 trinh̀ ATDD.................................................................................................21
Hình 2-1 Tiến trinh̀ phát triển phần mềm hƣớng hành vi...................................................................... 28

Hình 3-1. Cấu trúc thƣ muc ̣ làm viêc ̣ của Behat................................................ 36
Hình 3-2. Cấu trúc chung của môṭtinh́ 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 hinh̀ behat.yml..............................................................................................56
Hình 4-2 Tiến hinh̀ áp dung ̣ BDD vàBehat đểphát triển ƣ́ng dung ̣....................................................... 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ôṭtrong nhƣ̃ng yếu tốquan trong ̣ nhất của sản phẩm phần
mềm. Lỗi phần mềm không chi anh hƣơng đến dƣ liêụ, hoạt động của cơ quan tổ
chƣc sƣ dung ̣ phần mềm ma đôi khi con anh hƣơng đến tinh maṇ
́́
́ƣ
Nhƣng haṇ chếhay
́̃
thống đo mang laị. Đặc biệt, trong thi ̣trƣơng canḥ tranh chất lƣơng ̣ cao nhƣ hiêṇ
́́
nay môṭphần mềm
nghiêm trong ̣ tới danh tiếng , thƣơng hiêụ vàuy tin ́ 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 linh̃ vƣc ̣ phát triển phần mềm.

Tuy nhiên, môṭphần mềm chất lƣơng ̣ cao cũng cóthểgăp ̣ thất baị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 tinh ́ năng
mới đểcanḥ 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ƣ khach hang
năng phong đoan va trong trƣơng hơp ̣ tồi tê ̣cac tinh năng đo
́ƣ
hơp ̣ vơi mong muốn cua khach hang
́́

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átrinh̀ sƣƣ dung ̣ phần mềm , ngƣời sƣƣ dung ̣ se ̃dê ̃hinh ̀ 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 dung ̣ , khi

đókhách hàng dê đ̃ ƣa ra các ýtƣởng cho tinh́ 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 ̣ cai
đăṭhoàn thiện, do đo viêc
́̀


đung vơi yêu cầu khach hang rất dê ̃xay ra
́́

́́

́́

hiêṇ đaịđƣơc ̣ coi làmôṭgiải pháp khắc phuc ̣ vấn đềthay đổi yêu cầu củ a ngƣời sƣƣ
dung ̣. Ý tƣởng cơ bản trong các quy trình lặp hiêṇ đaịlà phần mềm đƣợc sản xuất
theo tƣ̀ng bƣớc, mỗi bƣớc chỉthƣc ̣ hiêṇ môṭsốtinh ́ 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ƣạ 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ṇ 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 tinh́ năng quan trong ̣ thƣờng đƣơc ̣ choṇ để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 canḥ nhƣng lơị ich
́̃
triển phần mềm theo phƣơng phap lăp ̣ cung taọ ra nhƣng thach thƣc mơi cho
giai đoaṇ kiểm thƣ phần mềm . Ở quy trinh phat triển truyền thống , kiểm thƣ la
́ƣ

môṭpha đƣơc ̣ thƣc ̣ hiêṇ vao cuối dƣ a ̣ n, khi hê ̣thống đa đƣơc ̣ cai
nhƣngvơi cac hê ̣thống sƣ dung ̣
́́

́́

trong mỗi vong lăp ̣. Khách hàng thƣờng xuyên đƣợc sử dụng các

́̀

của hệ thống , nên lỗi phần mềm hoăc ̣ cac tinh năng sai sot se sơm đƣơc ̣ phat
hiêṇ va giai quyết trƣơc khi san phẩm chinh thƣc
́̀

Trong điều kiêṇ ly tƣơng , sau mỗi vong lăp ̣ khach hang

́ƣ

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ṭ, 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ṇ nhƣ các kỹ
thuâṭlâp ̣ trinh̀ 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ính năng đúngchƣa hẳn đa ̃phù
hơp ̣ yêu cầu của khách hàng , và để kiểm tra điều đó cần môṭphƣơng pháp kiểm
thƣƣ ởmƣ́c đô ̣cao hơn , đólàkiểm thƣƣ chấp nhâṇ 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 trong ̣ nhất đểxác đinḥ 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 trinh lăp ̣ , phần mềm đƣơc ̣ phat triển qua cac vong lăp ̣ va co sƣ ̣
́̀
thay đổi liên tuc ̣ se co lơị cho viêc ̣ kiểm tra cac tinh năng
́̃ ́
kiểm thƣ it nhất m ột lần , thâṃ chi nhƣng tinh năng quan trong ̣ đƣơc ̣ kiểm thƣ
́ƣ ́
nhiều lần thông qua cac vong lăp ̣ khi bổsung cac tinh năng mơi
́́ ̀

thế,kiểm thƣƣ hồi quy trởnên n
trình phát triển phần mềm, viêc ̣ kiểm thƣƣcác tinh ́ năng ban đầu quan trong ̣ 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 tich́

́́


hơp ̣ thêm các tinh́ 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ƣƣ dung ̣


-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átrinh̀ kiểm thƣƣ . Kiểm thƣƣ tƣ đ ̣ ông ̣ giúp công viêc ̣ thƣc ̣
hiêṇ môṭ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átrinh̀ kiểm thƣƣ. Kiểm thƣƣ tƣ đ ̣ ông ̣ đăc ̣ biêṭhƣ̃u hiêụ trong vấn đềkiểm
thƣƣ hồi quy , bởi có thểthƣc ̣ hiêṇ hằng ngày , hằng giờ, cho moịvòng lăp ̣ mà
không hềnhàm chán.
Hiêṇ nay cókhánhiều công cu đ ̣ ểkiểm thƣƣ tƣ ̣đông ̣ vànótrởthành môṭ
phần không thểthiếu đối vơi cac hê ̣thống phat triển theo phƣơng phap linh hoaṭ.
Tuy nhiên, để tự động hóa quá trình kiểm thử chấp nhận thì cần
môṭky thuâṭphu hơp ̣ đểmô ta yêu cầu cua khach hang . Viêc ̣ sƣ dung ̣ công cu
́̃
phần lơn phu ̣thuôc ̣ vao ngôn ngƣ lâp ̣ trinh va ky thuâṭđăc ̣ ta yêu cầu ngƣơi
́́
dùng. Vơi sƣ ̣phat triển manḥ me cua cac quy trinh
́́

phƣơng pháp linh hoaṭ 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ôṭ 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ôịdung luâṇ văn tâp ̣ trung vào những vấn đề sau:


Giới thiêụ tổng quan vềphƣơng pháp phát triển phần mềm linh hoaṭ; Giới

thiêụ hai quy trinh̀ đƣơc ̣ sƣƣ dung ̣ phổbiến trong A gile làquy trinh̀ 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âṇ, …


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ṭ. Phần này chủyếu trinh̀ bày phƣơng pháp phát
triển phần mềm lấy kiểm thƣƣ làm trong ̣ tâm ; đƣa ra các khái niêṃ vàquy trinh̀
thƣc ̣ hiêṇ của phƣơng pháp phát triển dƣạ 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ôṭ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ôṭ
phƣơng pháp mới , chƣa đƣơc ̣ áp dung ̣ phổ biến trong sản xuất phần mềm . Tuy
nhiên, thông qua nghiên cƣ́u của minh ̀ tôi thấy đây làmôṭkỹthuâṭhay, có thể áp dụng
rộng rãi , vì thế trong phần này , tôi trinh ̀ 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ƣạ vào hành vi của ƣ́ng dung ̣ nhƣ

:

nguyên lý, quy trinh̀, 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ƣƣ dung ̣ tinh́ năng, cũng nhƣ mô tả các tiêu chí kiểm
thử chấp nhâṇ 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 hinh̀ ,
kiến trúc vàcách thƣ́c sƣƣ dung ̣ công cu ̣này ;mô tả cách sử dụng ngôn ngữ
Gherkin đểviết tinh́ năng, đinḥ nghiã các tiêu chíkiểm thƣƣ chấp nhâṇ nhƣ làcác
bƣớc của kicḥ 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êụ công cu ̣ vàkỹthuâṭ
hỗtrơ; ̣ mô tảƣ́ng dung ̣ vàcác bƣớc xây dƣng ̣ ƣ́ng dung ̣ ; tổng kết, đánh giáviêc ̣
áp dụng.
Cấu trúc của luâṇ 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âṇ dungpháṭ 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 HOAT
̉̉

̀

̀

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 trinh̀ đƣơc ̣ áp dung ̣ rông ̣ raĩ nhất đólà
quy trình Scrum và lập trình cực hạn XP.
1.1.1. Quy trinh̀ 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 đăṭ 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 tinh́ năng mới hoăc ̣ cải
thiêṇ các tinh́ 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 trinh ̀ 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ôṭ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 đinḥ 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êṃ 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 ̣ trinh̀ bày chi tiết ởcác phần sau.

Hình 1-2. Quy trinh̀ 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ịlàbƣớc ƣớc lƣợng các yêu cầu ở mức độ cao:Chia sản
phẩm thành môṭsố danh mục backlog , sốlƣơng ̣ danh muc ̣ cóthểđƣơc ̣ điều
chỉnh, bổsung trong quátrinh̀ 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à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, đôịdƣ ̣ án se ̃ hop ̣ laịđể 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 lam viêc ̣ la yếu tốquan trong ̣ trong viêc ̣ ap dung ̣
́̀

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ày đôị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êṇ môṭSprint không hiêụ
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 se ̃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 dung ̣ quy trinh̀ 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ôṭràng buôc ̣ quan trong ̣ nhất trong quy trinh̀ Scrum làc ác thành viên tự
chịu trách n hiêṃ cho công viêc ̣ của minh̀ . 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 đong ̣ se đ̃ ẩ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 trinh̀ 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êṇ môṭ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 trinh̀ Scrum
có các nhóm ngƣời dùng sau:

Chủ sở hữu sản phẩm (Product owner):Là môṭ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 lanh̃ đaọ
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êṃ 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êṇ 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êcḥ 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 trinh̀ 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 ̣ hop ̣ 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 trinh̀ 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 đa ̃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 đôị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 ̣ trinh̀ cƣc ̣ haṇ(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êṇ đaị đƣợ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 trinh ̀ 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 ̣ trinh̀ cƣc ̣ haṇ đăṭra môṭ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 ̣ trinh̀ cƣc ̣ haṇ 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êṇ tinh ́ năng đa ̃ 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êụ đặ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 trinh̀ 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 ̣ trinh ̀ cƣc ̣ haṇ 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 trinh ̀ 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 minh̀ thƣc ̣ hiêṇ. 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ṭ, 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ƣƣ dung ̣ các quy trinh ̀ 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ôṭ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ƣƣ dung ̣ phƣơng pháp phát triển linh hoaṭ, 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 ̣ trinh ̀ cƣc ̣ haṇ 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 ̣ trinh̀ cƣc ̣ haṇ 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êṇ 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ƣƣ dung ̣ câu chuyêṇ 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êṇ 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ênịt́ chútrong ̣ đến viêc ̣ viết tài liêụ ,
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êṇ.
Phần thân câu chuyêṇ 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êṇ, phần này mô tả các trƣờng hợp cụ thể cho từng câu chuyêṇ:
+
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êṇ
đó. 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 chi ́để 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.