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

Với sự phát triển ma ̣nh mẽ của các quy trình 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, Seleni

-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

-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

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

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 gia 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 sĩTrươ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

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

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 trình thực hiê ̣n ứ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

DANH MỤC CÁC TƢ̀ VIẾT TẮT

ATDD Acceptance Test Driven Development BDD Behaviour Driven Development

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 đi ̣nh nghĩa bước để ta ̣o yêu cầu 53

Bảng 3-3 MinkContext các đi ̣nh nghĩa 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 trình 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 trình ATDD 21

Hình 2-1 Tiến trình 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 hình 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

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 tính năng và tiê ̣n ích 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á trình sử du ̣ng sẽ là m ảnh hưởng nghiêm tro ̣ng tới danh tiếng , thương hiê ̣u và uy tín 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 lĩnh 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 tính năng phỏng đoán và trong trường hợp tồi tê ̣ các tính 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 tính 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 thay đổ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 trình 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

tí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 trình 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 chính 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 đi ̣nh 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 trình 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 tính năng Mỗi tính 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 tính 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 tích hợp thêm các tính 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

cá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á trình 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 trình 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 Agile 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 trình 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 trình 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 mình 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

về 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 tính 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 tính năng, đi ̣nh nghĩa các tiêu chí kiểm thử chấp nhâ ̣n như là các bước của ki ̣ch 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 cụ

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

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

và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 rãi nhất đó là quy trình Scrum

và lập trình cực hạn XP

1.1.1 Quy trình 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 đi ̣nh 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 ̣,

cho 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 trình bày chi tiết ở các phần sau

Hình 1-2 Quy trình 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á trình 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ự

giao 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 trình 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 trình Scrum là c ác thành viên tự chịu trách n hiê ̣m cho công viê ̣c của mình 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 trình 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

nhằ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 lãnh đ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 trình 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

Việ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 trình 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]

Lâ ̣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 trình 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 trình 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 tính 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

Để 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 trình 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 mình 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 trình 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 trình 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:

1.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 trình 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)

 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ê ̣nít 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

 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 đi ̣nh 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>

So 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 đích 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á trình di ̣ch 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

Development-TDD) 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ị

mô 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 trình viên tiến hành cài đă ̣t cho chức năng đó càng nhanh 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 trình 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

ngoại lệ để có thể viết kiểm thử cho nó Các phương thức kiểm thử thường được viết với sự hỗ trợ của công cu ̣ phù hợp với môi trường phát triển phần mềm

Hình 1-5 Vòng đời của phần mềm phát triển theo TDD

b Thực hiê ̣n và kiểm tra trạng thái tất cả các kiểm thử

Sau khi thực hiê ̣n xong bước viết kiểm thử , lâ ̣p trình viên sẽ phải thực hiê ̣n các kiểm thử đó để kiểm tra độ tin cậy Phải đảm bảo các kiểm thử mới được viết và chư a có mã nguồn cài đă ̣t tương ứng luôn ở tra ̣ng thái thất ba ̣i và mô ̣t kiểm thử được đánh dấu là thành công thì ít nhất tính năng tương ứng với kiểm thử đó p hải được cài đặt Giai đoa ̣n này thường được sử du ̣ng với các côn g cu ̣ kiểm thử tự đô ̣ng

c Cài đặt mã nguồn

Sau khi viết các kiểm thử mới và đảm bảo kiểm thử đó ở tra ̣ng thái thất ba ̣i ,

lâ ̣p trình viên tiến hành cài đặt mã nguồn cho tính năng tương ứng cho đến khi kiểm thử đó thành công Mục đích chính của giai đoạn này là làm cho các kiểm thử từ tra ̣ng thái thất ba ̣i chuyển sang thành công , do đó mã nguồn được cài đă ̣t

có thế chưa phải là hoàn toàn phù hợp , chúng có thể được cả i tiến, tinh chỉnh ở giai đoa ̣n sau

d Thực hiê ̣n các kiểm thử

Giai đoa ̣n này nhằm mu ̣c đích để lâ ̣p trình viên biết tra ̣ng thái phát triển của

hê ̣ thống Nếu còn tồn ta ̣i phương thức kiểm thử ở tra ̣ng thái thất ba ̣i thì lâ ̣p trình viên phải tiến hà nh rà soát , cài đặt mã nguồn cho tính năng đó Nếu tra ̣ng thái

của tất cả các kiểm thử đều thành công thì có thể đảm bảo rằng phần mã nguồn được cài đă ̣t đáp ứng các yêu cầu kiểm thử

e Điều chỉnh mã nguồn

Viê ̣c cài đ ặt mã nguồn cho các tính năng mới luôn luôn được bổ sung vào quá trình phát triển để các kiểm thử đã viết chuyển từ tra ̣ng thái thất ba ̣i sang thành công Điều này cũng dẫn đến một thực tế là một các mã nguồn đã cài đă ̣t

có thể dư thừa hoă ̣c chưa thực sự tối ưu, lúc này lâ ̣p trình viên sẽ phải điều chỉnh lại phần mã nguồn đã được viết nhằm giảm thiểu sự trùng lặp và làm cho mã nguồn sáng sủa, dễ hiểu

Quá trình trên được lặp đi lặ p la ̣i cho đến khi thực hiê ̣n xong các yêu cầu của ứng dụng TDD thường được sử du ̣ng trong các quy trình phần mềm lă ̣p và

nó là một kỹ thuật nhằm đảm bảo toàn bộ mã nguồn của hệ thống được kiểm thử mức đơn vị Tuy nhiên, thực hiện tốt mức kiểm thử đơn vị chưa đảm bảo được

dự án thành công và không có lỗi trong quá trình vận hành Do đó, khi sử dụng TDD vẫn cần xem xét các kỹ thuật kiểm thử khác như kiểm thử chấp nhận hay kiểm thử dò hỏi, …

Trong kiểm thử truyền thống, một ca kiểm thử thành công khi nó phát hiện

ra một hoặc nhiều lỗi chương trình Tương tự với TDD, khi một mẫu kiểm thử thất bại giúp lập trình viên biết phải cải thiện lại phần mã của mình TDD giúp tăng độ tin cậy của hệ thống đang phát triển

Trong phương pháp kiểm thử truyền thống, hệ thống càng có nhiều rủi ro lớn càng cần phải có nhiều mẫu kiểm thử được thực hiện, nhưng việc đảm bảo kiểm thử hết tất cả các hàm, các đường đi của mã nguồn rất khó thực hiện Trong khi đó, sử dụng TDDđảm bảo kiểm thử độ phủ mã nguồn đạt gần như 100% - mọi dòng mã đều được kiểm thử, điều này giúp tăng độ tin cậy của kiểm thử đơn vị Không có gì ngạc nhiên khi nói rằng TDD là một kỹ thuật đặc

tả với một tác dụng phụ có giá trị là nó đem lại kết quả trong việc kiểm thử mã nguồn tốt hơn đáng kể so với các kỹ thuật truyền thống

Ưu điểm của TDD:

 Một lợi thế đáng kể của TDD là nó cho phép thực hiện các bước nhỏ khi viết phần mềm.Đây là một lợi thế đã phát huy trong nhiều năm quabởi vì

nó mang lại hiệuquả cao hơn so viếtmã trong những bước lớn Chẳng ha ̣n như , khi lâ ̣p trình viên cần viết mã cho mô ̣t chức năng mới , sau đó biên di ̣ch và kiểm thử thì khả năng rất lớn là kiểm thử đó sẽ bi ̣ thất bại bởi những lỗi phát sinh trong phần mã nguồn vừa bổ sung Trong trường hợp này , viê ̣c thực hiê ̣n các

bước nhỏ phát huy tác du ̣ng bởi viê ̣c kiểm tra vài dòng mã dễ dàng hơn rất nhiều viê ̣c kiểm tra vài nghìn dòng mã.

 Nhiều người cho rằng các kỹ thuật trong phương pháp phát triển linh hoạt Agile hoạt động rất ổn với những dự án nhỏ, cần một số ít người trong một vài tháng, nhưng với những dự án lớn thì Agile có nhiều hạn chế Tuy nhiên, thực tế thì điều này không hoàn toàn đúng, có những hệ thống Smalltalk sử dụng hoàn toàn phương pháp hướng kiểm thửđể thực hiện trong thời gian 4 năm với chi phí nhân công 40 man-year, ra kết quả gồm 250,000 dòng mã cho các chức năng và 250,000 dòng mã kiểm thử Có 4000 mẫu kiểm thử chạy dưới 20 phút, còn với

bộ mẫu kiểm thử đầy đủ thì cần chạy vài ngày Điều đó chứng tỏ rằng TDD vẫn hoạt động tốt với những dự án có kích thước lớn

Các công cụ phục vụ cho TDD, thường là các nền tảng cho kiểm thử mã nguồn mức đơn vị, chẳng hạn như: cppUnit, csUnit (.Net), CUnit, DUnit (Delphi), DBFit, DBUnit, HTMLUnit, HTTPUnit, JMock, JUnit, NDbUnit, NUnit, OUnit, PHPUnit, PyUnit (Python), SimpleTest, TestNG, Test::Unit (Ruby), VBUnit, XTUnit

Thiết kế dựa trên kiểm thử là một kỹ thuật phát triển phần mềm, trong đó trước tiên lập trình viên phải viết một mã kiểm thử chạy thất bại, trước khi viết

mã nguồn cho chức năng mới TDD đang nhanh chóng được nhiều công tysản xuất phần mềm theo phương pháp linh hoạt Agile sử dụng để phát triển mã nguồn ứng dụng, và thậm chí còn được thông qua bởi những nhà quản trị cơ sở

dữ liệu theo phương pháp Agile để phát triển cơ sở dữ liệu TDD không thay thế phương pháp kiểm thử truyền thống, thay vào đó nó định nghĩa một cách thức

để đảm bảo việc thực hiện các kiểm thử đơn vị một cách hiệu quả Hiệu ứng phụ của TDD là các kiểm thử cung cấp một đặc tả hoạt động cho mã nguồn, thông qua đó lâ ̣p trình viên có thể hiều mình các công viê ̣c , các đoạn mã cần cài đặt cho tính năng tương ứng

1.4.2 Phát triển phần mềm theo hướng kiểm thử chấp nhận

Phát triển phần mềm theo hướng kiểm thử chấp nhận (Acceptance Driven Development - ATDD) là một quy trình kiểm chứng và đặc tả yêu cầu phần mềm ATDD nhằm tự động hóa kiểm thử chấp nhận và đặc tả yêu cầu phần mềm thông qua các ví dụ cụ thể Mục đích viê ̣c kiểm thử chấp nhận tự động nhằm giữ cho các thành phần tham gia vào quy trình tập trung vào mục đích của dự án phần mềm trong khi khách hàng vẫn nắm đượctính năng và các thuộc tính kiểm thử chấp nhận

Test-Trong quy trình ATDD có 3 nhóm tác nhân chính gồm: khách hàng, kiểm thử viên và lập trình viên Kết quả của ATDD là một tập các kiểm thử chấp nhận

có thể thực hiện được Quy trình phát triển phần mềm theo hướng kiểm thử chấp nhậnthực hiê ̣n ba hoạt động như sau (Hình 1-6):

Hình 1-6 Quy trình ATDD

1 Viết các kiểm thử chấp nhận

Một kiểm thử viên sẽ làm việc cùng với khách hàng để tìm ra các kiểm thử

mô tả hành vi dự kiến tương ứng với một yêu cầu

Tất cả các biến thể của hành vi đó được quy định cụ thể thông qua các ví

dụ có đầu vào, đầu ra rõ ràng và được thêm vào các đặc tả mô tả tiêu chí kiểm thử chấp nhận Tài liệu kiểm thử phải được viết bằng ngôn mô hình hoặc ngôn ngữ tự nhiên để khách hàng có thể hiểu được

2 Kiểm thử chấp nhận tự động

Dựa vào tài liệu kiểm thử mô tả hành vi của hê ̣ thống đã viết ở bước trên để làm cơ sở cho việc kiểm thử chấp nhận Mặc dù các kiểm thử được mô tả bằng các ví dụ cụ thể nhưng không thể sử dụng trực tiếp để làm hướng dẫn kiểm thử

Ở giai đoạn này, mộtlập trình viên sẽ làm việc với một kiểm thử viên để chuyển các khái niệm trong ví dụ đó thành các hàm hay các phương thức kiểm thử viết bằng mã chương trình Viê ̣c cài đă ̣t các phương thức kiểm thử có thể được thực hiê ̣n tự động nhờ vào các công cu ̣ hỗ trợ , và lậptrình viên chỉ việc bổ sung các

mã nguồn theo đúng ví dụ mô tả

3 Cài đặt

Lập trình viên sẽ thiết kế và cài đặt các chức năng để hệ thống làm việc đúng với các yêu cầu, các chức năng sẽ được hoàn thiện dần để đáp ứng các tiêu chí kiểm thử chấp nhận đã được mô tả trong tài liê ̣u yêu cầu

Trong phương pháp này , đầu tiên các tiêu ch í kiểm thử chấp nhận có thể được viết cho tất cả các yêu cầu phần mềm, sau đó hê ̣ thống sẽ được cài đă ̣t và kiểm thử dần từng phần mô ̣t thông qua các vòng lă ̣p Viê ̣c kiểm thử thường xuyên và thông qua các công cu ̣ hỗ trợ kiểm thử chấ p nhâ ̣n tự đô ̣ng sẽ làm cho

hê ̣ thống cuối cùng dễ dàng đáp ứng các tiêu c hí mà người dùng mong muốn Tại mỗi vòng lă ̣p , hê ̣ thống được tự đô ̣ng kiểm thử hồi quy , giúp tránh các lỗi phát sinh trong quá trình bổ sung các tí nh năng mới mà các phương pháp kiểm thử khác hay gă ̣p phải

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ử

Phát triển phần mềm lấy kiểm thử làm trọng tâm được áp dụng khá phổ biến trong các quy trình phát triển phần mềm theo phương pháp linh hoa ̣t Agile Không thể phủ nhâ ̣n rằng TDD và ATDD mang lại nhiều lợi ích cho kiểm thử phần mềm , nâng cao chất lượng kiểm thử bao phủ mã nguồn của ứng du ̣ng ; Cùng với các công cụ hỗ trợ, những dự án áp du ̣ng TDD phần đa được kiểm thử tự đô ̣ng trong giai đoạn kiểm thử đơn vi ̣, giúp cho việc kiểm thử hồi quy trở nên nhanh chóng và chính xác hơn nhờ vào quá trình kiểm thử tự đô ̣ng Tuy nhiên, khi áp du ̣ng các kỹ thuâ ̣t phát triển phần mềm dựa vào kiểm thử cũng phát sinh

mô ̣t số nhược điểm:

Thứ nhất: Khó xác định điểm bắt đầu của quy trình

Trọng tâm của TDD là viết các kiểm thử trước khi vi ết mã nguồn của ứng dụng Các phương thức kiểm thử thườngđược viết bằng ngôn ngữ kỹ thuâ ̣t nên viê ̣c hiểu và viết kiểm thử không hềđơn giản Theo TDD, mỗi kiểm t hử được viết đều đă ̣t ở tra ̣ng thái thất ba ̣i , sau đó người lâ ̣p trình sẽ viết mã nguồn để kiểm thử thành công, điều này có vẻ như ngược la ̣i với lẽ tự nhiên Trong quá trình viết kiểm thử, rất khó để xác định chính xác mã nguồn cần cài đă ̣t cho tính năng tương ứng hay thế nào là kiểm thử thất ba ̣i Do vâ ̣y, viê ̣c viết đi viết la ̣i các kiểm thử và điều chỉnh mã nguồn có thể khiến lãng phí không ít thời gian của người lâ ̣p trình

Thứ hai: TDD chưa đảm bảo sự thành công dự án thông qua kiểm thử

TDD chỉ đáp ứng được kiểm thử đơn vi ̣ cho các chức năng , tuy nhiên mô ̣t số chức năng phức ta ̣p rất khó để viết kiểm thử đơn vi ̣ Trong trường hợp tối ưu, khi tất cả các kiểm thử tương ứng với các chức năng hê ̣ thống đều thành công

cũng chưa chắchệ thống đó đã thành công trên thị trường , bởi vì viê ̣c viết kiểm thử và cài đă ̣t mã nguồn đều thực hiê ̣n bởi lâ ̣p trình viên và không có tiêu chí cụ thể để đánh giá tra ̣ng thái thành công hay thất ba ̣i của hê ̣ thống TDD cũng cần được kết hợp thêm các phương pháp kiểm thử khác , như kiểm thử chi ̣u tải, kiểm thử kết hợp…

Thứ ba: TDD khóa thiết kế

Hạn chế lớn nhất khi sử du ̣ng TDD là khi có sự thay đổi yêu cầu , ngoài viê ̣c điều chỉnh mã nguồn tương ứng với yêu cầu đó lâ ̣p trình viên còn phải thay đổi toàn bô ̣ các kiểm thử liên quan Viê ̣c bổ sung mô ̣t yêu cầu mới hoă ̣c thay đổi yêu cầu cho các tính năng quan tro ̣ng đôi khi làm đảo lô ̣n cả hê ̣ thống , đều này rất dễ làm hê ̣ thống thất ba ̣i

Ngoài ra khi sử dụng TDD hay ATDD , các kiểm thử được viết bằng các ngôn ngữ kỹ thuâ ̣t nên sẽ ha ̣n chế sự tham gia của người sử dụng , đôi khi hàm kiểm thử không mô tả được mong muốn thực sự của khách hàng về yêu cầu hê ̣ thống Viê ̣c chuyển các câu chuyê ̣n người dùng hay các trường hợp sử du ̣ng vào các hàm kiểm thử không có tiêu chí nào để đánh giá xem kiểm thử đó đã thực sự đúng hay không? mà phần lớn dựa vào cảm quan của người sử dụng Tuy nhiên cũng không thể phủ nhận những lợi ích của TDD trongkiểm thử đơn vị , đă ̣c biê ̣t

là kiểm thử bao phủ mã nguồn Cùng với các công cụ hỗ trợ kiểm thử tự động và các nền tảng tự động sinh kiểm thử v à mã nguồn, TDD cũng là kỹ thuâ ̣t được sử dụng phổ biến trong các quy trình phát triển phần mềm theo phương pháp linh hoạt Agile

CHƯƠNG 2 PHÁT TRIỂN PHẦN MỀM HƯỚNG HÀNH VI 2.1 Tổng quan về phát triển phần mềm hướng hành vi

Phát triển phần mềm hướng hành vi (Behaviour driven development , viết tắt là BDD ) là phương pháp phát tri ển phần mềm dựa trên viê ̣c mô t ả hành vi của chúng, từ quan điểm của các bên liên quan đến dự án phần mềm [7].Đó là

kỹ thuật cho phép các thành viên của dự án như lập trình viên , kiểm thử viên , khách hàng, … có thể hợp tác với nhau thông qua quá trình làm việc chung trên

mô ̣t tài liê ̣u đă ̣c tả yêu cầu ứng du ̣ng

Các quy trình phát triển phần mềm theo phương pháp linh hoạt Agile hiện đang được sử du ̣ng phổ biến bởi những lợi ích mà chúng mang lại Các quy trình này thường sử dụng các công cụ và kỹ thuật để nâng cao chất lượng sản phẩm

và hỗ trợ quá trình làm việc của đội phát triển Quy trình phát triển phần mềm theo phương pháp l inh hoa ̣t Agile thường sử du ̣ng kỹ thuật TDDnhằm giúp cho viê ̣c kiểm thử ứng du ̣ng được thực hiê ̣n triê ̣t để và tự đô ̣ng hóa quá trình kiểm thử thông qua các công cu ̣ hỗ trợ

Trong thị thường cạnh tranh gay gắt hiện nay , tiêu chí quyết đi ̣nh thành công của mô ̣t phần mềm nằm ở chỗ phần mềm đó có phù hợp với thị hiếu của khách hàng hay không Điều đó được thực hiê ̣n thông qua quá trình kiểm thử chấp nhâ ̣n Trong các phương pháp phát triển phần mềm truyền thống, kiểm thử chấp nhâ ̣n thường thực hiê ̣n ở giai đoa ̣n cuối khi hê ̣ thống đã hoàn chỉnh các chức năng, nhưng đối với phương pháp phát triển linh hoa ̣t điều này không còn phù hợp Kiểm thử chấp nhâ ̣n cần được tiến hành trong mỗi vòng lă ̣p nhằm kiểm tra các tính năng mới đư ợc bổ sung , hay điều chỉnh ta ̣i vòng lặp đó có thực sự hữu ích Viê ̣c kiểm thử chấp nhâ ̣n với các hê ̣ thống gia tăng từng phần nhỏ dễ gây nhàm chán cho người kiểm th ử, dẫn đến tâm lý càng về sau viê ̣c kiểm thử càng dễ bị thực hiện sơ sài Lúc này, nhu cầu về một kỹ thuật có thể tự đô ̣ng đo ̣c yêu cầu của người dùng và kiểm tra xem hê ̣ thống có phù hợp với yêu cầu đó hay không trở nên rất cần thiết Kiểm thử chấp nhâ ̣n tự đô ̣ng chỉ có thể thực hiê ̣n được khi công cu ̣ hiểu được yêu cầu của người dùng , mà các tài liệu yêu cầu thường được mô tả bằng các ngôn ngữ phi kỹ thuâ ̣t để khách hàng có thể hiểu được Phát triển phần mềm hướng hành vi BDD ra đời nhằm cung cấp một kỹ thuật đặc tả yêu cầu người dùng để tài liệu đặc tả yêu cầu dễ hiểu đối với khách hàng nhưng cũng có thể sử dụng để làm đầu vào cho các kiểm thử tự đô ̣ng BDD kết hợp các đặc tính của TDD vàkỹ thuật thiết kế hê ̣ thống dựa vào

mô tả miền ứng du ̣ng (Domain driven design - DDD) giúp cho quá trình phát triển phần mềm dễ thực hiện hơn, cũng như cho phép thẩm định chính xác các

yêu cầu chức năng và mã nguồn tương ứng bằng cách liên kết văn bản đặc tả yêu cầu với các kiểm thử

BDD được phát triển bởi Dan North từ những năm 2006 nhằm giải quyết những nhược điểm của TDD khi áp du ̣ng vào các dự án trong các môi trường khác nhau [7] TDD thường được dùng trong kiểm thử đơn vị, tuy nhiên việc bắt đầu một quy trình phần mềm với TDD gặp nhiều khó khăn trong viê ̣c xác đi ̣nh điểm khởi đầu của quy trình Lập trình viên cũng không biết khi nào thì kết thúc việc kiểm thử vì không cótài liệu mô tả tiêu chí kiểm thử cụ thể để đánh giá kiểm thử một chức năng là thành công hay thất bại [7] Để giải quyết những vấn

đề đó, Dan North đã ta ̣o ra BDD bằng cách phát triển TDD theo hướng giải quyết các vấn đề của người sử dụng đối với phần mềm dựa vào việc mô tả hành

vi của ứng dụng.BDD hiê ̣n thu hút được khá nhiều sự quan tâm của cô ̣ng đồng phát triển phần mềm BDD có thể áp dụng cho các dự án ở bất cứ quy mô nào, tuy nhiênBDD cũng mở rộng lâ ̣p trình cực ha ̣n XPnên rất thích hợp cho viê ̣c phát triển các dự án lớn[6]

BDD tập trungviê ̣c phát tri ển vào các ho ạt động mô tả hành vi của ứng dụng để đạt được giá trị nghiệp vụ BDD thường sử dụng phương pháp “phát triển dựa trên việc lặp” và “vòng lặp phát hành ngắn” để cấp phát hành vi của ứng dụng và kiểm thử phần mềm

2.2 Nguyên lý hoạt động

Mục đích chính BDD là cung cấp một kỹ thuật để phát triển phần mềm theo đúng mong muốn của khách hàng, việc áp dụng phát triển phần mềm hướng hành vi dựa trên ba nguyên lý cơ bản[7]:

 Đủ là đủ (enough is enough): đô ̣i phát triển cần nổ lực đủ để bàn giao cho khách hàng phần mềm đúng theo yêu cầu của họ Điều này có nghĩa là phải dành đủ thời gian cho việc phân tích, lập kế hoạch và thiết kế phần mềm, nhưng chỉ thực hiện những công việc trên mô ̣t số yêu cầu hê ̣ thống để đưa vào vòng lă ̣p đầu tiên cài đặt hê ̣ thống

 Phân phối giá trị của các bên liên quan (deliver stakeholder value): Các bên liên quan ở đây không đơn thuần chỉ những người trả tiền để phát triển phần mềm, mà bao gồm tất cả các nhân tố được hưởng lợi từ việc sử dụng phần mềm Trong quá trình phát triển phần mềm, chỉ chú trọng đến những công việc mang lại lợi ích vàcần sớm loa ̣i bỏ các công việc không mang lại lợi ích hoặc không cải thiện được lợi ích cho người dùng

 Tập trung vào hành vi: BDD tập trung mô tả hành vi của ứng dụng ở tất

cả các cấp độ

Trong kỹ thuật phát tr iển phần mềm hướng hành vi , sau khi xác đi ̣nh các mục đích và kết quả của dự án, đô ̣i phát triển sẽ sử du ̣ng sẽ mô tả hành vi của hê ̣ thống bằng BDD Đó chính là các câu chuyê ̣n người dùng được mô tả theo mô ̣t dạng thức quy định, mỗi câu chuyê ̣n còn go ̣i là tính năng của hê ̣ thống Các tính năng được mô tả chi tiết về các khía ca ̣nh người dùng , hoạt động, kết quả, giá trị nghiê ̣p vu ̣, … Phần mô tả tính năng cũng bao gồm các tiêu chí để đánh giá hê ̣ thống theo quan điểm của người sử du ̣ng , chúng chính là thước đo để xây dựng các phương thức kiểm thử chấp nhận cho hệ thống

Ngày nay, các hệ thống sử dụng phương pháp phát triển phần mềm hiện đại được hỗ trợ bởi rất nhiều công cu ̣ , đă ̣c biê ̣t là trong giai đoa ̣n kiểm thử Mô ̣t số công cu ̣ kiểm thử đơn giản dễ sử du ̣ng bằng cách thông qua tương tác với chuột

và bàn phím, … Tuy nhiên, kỹ thuật phát triển phần mềm hướng hành vi BDD ngoài mục đích kiểm thử chấp nhận tự động còn hỗ trợđô ̣i phát triển cài đặt mã nguồn dựa trên các đặc tả phần mềm BDD mô tả các yêu cầu hê ̣ thống theo từng ki ̣ch bản sử du ̣ng Mỗi kịch bản xác định rõ ràng các bước bao gồm ngữ cảnh sử dụng , các hoạt động , hành động và kết quả của kịch bản đó Chính vì thế BDD vừa làm tài liê ̣u đă ̣c tả ,làm tài liê ̣u thiết kế phần mềm , vừa làm tài liệu chung cho các bên liên quan

BDD tương đối đơn giản, dễ hiểu, nó thể hiện khuôn khổ hoạt động dựa trên ba nguyên tắc:

i Các hoạt động nghiệp vụ và kỹ thuật nên quy vào một mối, theo cùng một cách

BDD mô tả các yêu cầu nghiệp vụ dưới dạng các ngôn ngữ tự nhiên giúp cho các đối tượng không am hiểu ngôn ngữ kỹ thuật như khách hàng, người kiểm thử đọc được tài liê ̣u đă ̣c tả hê ̣ thống Khách hàng có thể dễ dàng biết hệ thống sẽ làm gì và tạo ra kết quả gì ở các chức năng mà họ mong muốn Kiểm thử viên biết được các tiêu chí để kiểm thử chấp nhận hê ̣ thống Đội phát triển dựa vào tài liệu mô tả bằng BDD để xây dựng các phương thức kiểm thử và cà i đặt các chức năng tương ứng Các phương thức kiểm thử có thể được sinh ra một cách tự động nhờ các công cụ hỗ trợ BDD cho ngôn ngữ lập trình mà đội phát triển muốn sử dụng

BDD giúp thống nhất cách nhìn giữa các bên liên quan đến hệ thống đang phát triển do hệ thốngđược xây dựng từ một tài liệu đặc tả duy nhất đểtránh các

lỗi hiểu nhầm yêu cầu, hoă ̣c lỗi xảy ra trong quá trình chuyển từ tài liê ̣u đă ̣c tả sang tài liệu thiết kế

ii Mọi hệ thống nên được xác định nghiệp vụ và các thuộc tính kiểm thử của nghiệp vụ đó

Với dự án phần mềm sử du ̣ng kỹ thuâ ̣t phát triển hướng hành vi BDD , các tính năng nên được xác định một cách rõ ràng Bên cạnh mô tả vai trò sử dụng, các hoạt động cơ bản thì quá trình mô tả các tính năng nên đưa ra các giá trị có thể làm tiêu chí kiểm thử chấp nhận Việc xác định nghiệp vụ cũng như giá trị

có thể kiểm thử rất quan trọng, nó quyết định thành công của dự án và cách thức làm việc của công cụ hỗ trợ

iii Phân tích, thiết kế, lập kế hoạch theo Up – Front

Trước khi mã hóa, mọi tính năng đều cần được phân tích, thiết kế và lập kế hoạch Với đa số dự án phần mềm , sau khi đã xác đi ̣nh yêu cầu hê ̣ thống , đô ̣i phát triển thường vội vàng cài đặt mã nguồn cho yêu cầu , điều này thường gây

ra lỗi khi có sự thay đổi yêu cầu BDD bắt buô ̣c đô ̣i ph át triển phải mô tả tính năng theo da ̣ng thức mô tả đầy đủ các tiêu chí kiểm thử chấ p nhâ ̣n, dữ liê ̣u kiểm thử trước khi viết các phương thức kiểm thử tương ứng với các tiêu chí đã đề ra Pha cài đă ̣t là pha cuối cùng trong mỗi vòng lă ̣p , viê ̣c cài đă ̣t ở đây nhằm mu ̣c đích đảm bảo cho các tiêu chí kiểm thử chấp nhâ ̣n không bi ̣ bỏ sót và ở tra ̣ng thái thành công trước khi chuyển sang vòng lặp kế tiếp

Câu chuyện người dùng được coi là phần tử nguyên tử của BDD Trong phương pháp phát triển phần mềm hướng hành vi, phần mềm được tạo ra bằng cách gia tăng từng phần thông qua các vòng lặp, trước mỗi vòng lặp đội phát triển sẽ chọn ra một tập các câu chuyện người dùng cho vòng lặp đó Do đó vấn

đề xác định câu chuyện người dùng cần được chú trọng để việc cài đặt diễn ra nhanh chóng

Khi viết một câu chuyện người dùng, cần cân bằng các chi tiết của câu chuyện bằng các tiêu chí kiểm thử chấp nhận, sau khi viết xong các tiêu chí kiểm thửđó thì mới bắt đầu quá trình cài đặt

2.3 Quy trình phát triển phần mềm theo hướng hành vi

Để phát triển mô ̣t phần mềm , người ta thường sử dụng các pha đặc tả yêu cầu, thiết kế, cài đặt và kiểm thử Tùy thuộc vào từng loa ̣i quy trình phát triển phần mềm sự sắp xếp cá c giai đoa ̣n này có thể khác nhau Phát triển phần mềm hướng hành vi BDD là một quy trình lặp và mỗi vòng lặp của BDD đều trải qua các pha trên Tuy nhiên trước khi khởi tạo vòng lặp đầu tiên, các thành viên đội

dự án phải hoàn thiện một số yêu cầu cho từng pha Mỗi pha có các hoạt động, vai trò và sản phẩm riêng[5]

 Hoạt động (Activitie):là các nhiệm vụ mà những người tham gia vào quá trình thực hiện

 Vai trò (Role):mỗi người tham gia dự án có thể có một hoặc nhiều vai trò, mỗi vai trò có một số hoạt động

 Sản phẩm: mỗi quy trình phần mềm thường tạo ra sản phẩm là mã nguồn phần mềm, tuy nhiên cũng có nhiều sản phẩm khác đi kèmnhư tài liệu, báo cáo, hướng dẫn, …

Để thực hiê ̣n mô ̣t dự án phần mềm , sau khi xác đi ̣nh mu ̣c đích và phân tích tính khả thi của dự án, đô ̣i phát triển sẽ phải làm viê ̣c với khách hàng để thu thâ ̣p các yêu cầu ban đầu trước khi tiến hành các vòng lặp.Giai đoa ̣n này nhằm đưa ra các mục tiêu của dự án , đó là các kết quả mà người dùng mong đợi ở hê ̣ thống trong tương lai Người phân tích yêu cầu sẽ làm viê ̣c với khách hàng để mô tả các mục tiêu đó dưới da ̣ng các câu lê ̣nh phục vụ cho quá trì nh phát triển ở các giai đoa ̣n sau Hệ thống được phát triển từ ý tưởng của khách hàng, có thể ban đầu mục tiêu của khách hàng chưa rõ ràng nhưng chúng sẽ tiếp tu ̣c được sửa đổi, bổ sung trong quá trình phát triển hê ̣ thống

Phát triển phần mềm hướng hành vi đă ̣t kiểm thử chấp nhâ ̣n làm trọng tâm của tiến trình thiết kế Các kiểm thử chấp nhận đều dựa trên các kịch bản của các tính năng được viết bằng ngôn ngữ tự nhiên Áp dụng BDD cho mỗi dự án phần mềm có thể có các biến thể khác nhau tùy thuộc vào sở thích người dùng Các dự án sử dụng kỹ thuật phát triển hướng hành vi thường được thực hiện theo tiến trình nhưHình 2-1

Hình 2-1 Tiến trình phát triển phần mềm hướng hành vi

 Scenario (Kịch bản): Sử du ̣ng ngôn ngữ tự nhiên viết mô ̣t ki ̣ch bản mô tả hành vi của ứng dụng

 Step Definition (Đi ̣nh nghĩa bước):Từ tài liê ̣u đă ̣c tả được viết bằng ngôn ngữ tự nhiên là các ki ̣ch bản , lâ ̣p trình viên sẽ thiết kế cài đă ̣t mã nguồn tương ứng với mô tả Viê ̣c viết các đi ̣nh nghĩa bước n hằm mu ̣c đích kiểm tra sự phù hợp của mã nguồn ứng du ̣ng và tài liê ̣u đă ̣c tả yêu cầu Mỗi đi ̣nh nghĩa bước

Scenario Step Definition SkeletonCode Implementation

gồm hai phần : mô ̣t biểu thức chính quy tương ứng với đi ̣nh nghĩa bước (hay câu) và một khối mã nguồn tương ứng với định nghĩa đó khi được thực hiê ̣n

 Code skeleton (Viết khung mã nguồn): Viết các mã nguồn cơ bản để đi ̣nh nghĩa bước có thể biên di ̣ch được

 Implementation (Cài đặt): Cài đặt, bổ sung các mã nguồn chi tiết để các phương thức kiểm thử thành công

2.3.1 Đặc tả hành vi của ứng dụng

Phần lớn các dự án phần mềm , tại thời điểm bắt đầu chỉ thu thập được một phần nhỏ các yêu cầu của hệ thống do khách hàng khó có thể mô tả đầy đủ và chính xác các yêu cầu của họ đối với hê ̣ thống Chính vì vậy, quá trình phát triển phần mềm nên cho phép khách hàng có thể bổ sung, loại bỏ hay điều chỉnh yêu cầu của mình Trước mỗi vòng lă ̣p , đô ̣i phát triển sẽ phải làm viê ̣c với người sử dụng để xác định các yêu cầu cần đưa vào vòng lặp đó Trong kỹ thuâ ̣t phát triển phần mềm hướng hành vi , quá trình thu thập yêu cầu sẽ xác định các sản phẩm sau:

 Tính năng(Feature):là một dạng biểu diễn của yêu cầu hệ thống ở mức cao thường được sử du ̣ng trong kỹ thuâ ̣t phát triển phần mềm hướng hành vi Mỗi tính năng mô tả các thuộc tính về người sử du ̣ng , các hoạt động và kết quả của yêu cầu dưới dạng ngôn ngữ tự nhiên có cấu trúc Mỗi tính năng có dạng như sau:

Feature: <feature name>

In order to <bussiness value>

As a <role>

I should <behaviuor>

Ví dụ một mô tả tính năng sử dụng forum

Feature: Create new forum topic

In order to discuss a topic

As a site user

I should be able to post a new forum topic

 Kịch bản (Scenario): Kịch bản là các trường hợp sử dụng của một tính năng dưới những điều kiê ̣n khác nhau Mỗi ki ̣ch bản bao gồmcác bước thực hiê ̣n kịch bản đó theo các khía cạnh như ngữ cảnh sử du ̣ng, các hoạt động và kết quả tương ứng Kịch bản là yếu tố chính của kiểm thử chấp nhâ ̣n Mỗi kịch bản được hiểu tương tự như mô ̣t ca kiểm thử, nó cung cấp các dữ liệu kiểm thử và tiêu chí

để xác định trạng thái của kiểm thử Các thành phần của kịch bản thường được BDD mô tả bằng mô ̣t tâ ̣p các từ vựng , chúng cũng được sử dụng như các tiêu

chí kiểm thử chấp nhậ n trong các giai đoa ̣n phát triểntiếp theo Ví dụ kịch bản của tính năng “create new topic"

Scenario: View the forum topic page

When I follow "Support"

And I follow "Forums"

Then I should be on "/forum"

And I should see the link "Add new Forum topic"

And I should see "New forum topics" block in the right sidebar And I should see at least "5" links in the "right sidebar"

region

2.3.2 Viết kiểm thử cho các bước

Trong các dự án phần mềm hướng hành vi , sau khi đi ̣nh nghĩa các tính năng các kịch bản c ũng như các bước tương ứng , đô ̣i phát triển cần viết các kiểm thử Mỗi bước của ki ̣ch bản được mô tả bằng mô ̣t câu theo ngôn ngữ tự nhiên, vì thế để hệ thống có thể kiểm thử tự động cần phải có cách để liên kết chúng với mã nguồn được cài đặt Mỗi phương thức kiểm thử tươn g ứng mô ̣t bước còn được go ̣i là các đi ̣nh nghĩa bước, đó là mô ̣t cấu trúc gồm hai phần:

 Phần đầu là mô ̣t biểu thức chính quy tương ứng với mô tả bước

 Phần thứ hai là mô ̣t phương thức được viết bằng mã chương trình

Các ph ương thức kiểm thử thường được viết trước khi cài đă ̣t mã nguồn tương ứng để thực hiê ̣n tính năng đó , chính vì thế , ở trạng thái ban đầu các phương thức kiểm thử này đều ở tra ̣ng thái thất ba ̣i BDD thường đi kèm với

mô ̣t công cu ̣ hỗ trợ để viê ̣c sinh và kiểm thử các bước diễn ra nhanh chóng , chính xác

Ví dụ định nghĩa bước „I should see link “Create new topic” ‟

2.3.3 Lă ̣p để cài đă ̣t ứng du ̣ng

Phát triển phần mềm hướng hành vi là kỹ thuật hoạt động theo nguyên lý

lă ̣p Trước mỗi vòng lă ̣p đô ̣i phát triển sẽ xác đi ̣nh các t ính năng đưa vào vòng

lă ̣p đó và viết các kiểm thử cho chúng , sau đó sẽ tiến hành cài đă ̣t mã nguồn để các tính năng hoạt động Viê ̣c viết mã nguồn cho các tính năng được thực hiê ̣n nhằm mu ̣c đích để các phương thức kiểm thử đa ̣t tra ̣ng thái thành công Sau mỗi vòng lặp toàn bộ tính năng được phát triển sẽ được kiểm thử chấp nhận BDD giúp cho mã nguồn của ứng dụng thường xuyên được kiểm tra theo hướng phù hợp với các tiêu chí kiểm thử ch ấp nhận mà khách hàng đã liê ̣t kê trong bản mô

tả tính năng Các tính năng đưa vào vòng lă ̣p sớm hay muô ̣n dựa vào đô ̣ ưu tiên của chúng, do đó các tính năng quan tro ̣ng được thực hiê ̣n sớm hơn Điều này giúp cho chúng đượ c kiểm tra thường xuyên nhằm sớm phát hiê ̣n các lỗi để có những điều chỉnh phủ hợp

2.4 Ngôn ngữđặc tả ứng dụng

Khách hàng là một nhân tố quan trọng đảm bảo sự thành công của các sản phẩm, đó là những đối tượng sẽ trực tiếp sử du ̣ng hê ̣ thống , họ am hiểu các yêu cầu nghiê ̣p vu ̣ mà hê ̣ thống cần cài đă ̣t Vì đa số khách hàng không am hiểu ngôn ngữ kỹ thuâ ̣t nên t rong các phương pháp phát triển phần mềm truyềnthống, yêu cầu hê ̣ thống thường được mô tả bằng ngôn ngữ tự nhiên Quá trình chuyển đă ̣c tả yêu cầu từ ngôn ngữ tự nhiên vào mã nguồn đôi khi có sự sai lê ̣ch

do lỗi của quá trình phân tích , thiết kế làm cho hê ̣ thống sau khi hoàn thiện không đáp ứn g đúng yêu cầu của khách hàng Đối với các dự án áp dụng kỹ thuâ ̣t phát triển phần mềm hướng hành vi , khách hàng là người trực tiếp mô tả các yêu cầu nghiệp vụ của hệ thống Các yêu cầu này kh ông những làm tài liê ̣u

đă ̣c tả, mà chúng còn làm tài liệu thiết kế và chứa các tiêu chí để kiểm thử chấp nhâ ̣n tự đô ̣ng , chính vì thế cần phải có phương pháp để mô tả yêu cầu cho phù hợp

Ngôn ngữ đă ̣c tả miền ứng du ̣n g được hiểu là ngôn ngữ cho phép khách hàng viết các quy tắc phần mềm mà không cần đến lập trình viên Nó là ngôn ngữ thể hiê ̣n nghiê ̣p vu ̣ và có miền ngữ nghĩa xác đi ̣nh giúp cho người đo ̣c

không am hiểu kỹ thuâ ̣t vẫn có thể hiểu được Đồng thời tài liệu được viết bằng ngôn ngữ miền ứng du ̣ng có thể được hiểu bởi các công cu ̣ hoă ̣c máy tính Các ngôn ngữ đă ̣c tả miền ứng du ̣ng thường sử du ̣ng ngôn ngữ mô hình hoă ̣c ngôn ngữ tự nhiên có cấu trúc

Kỹ thuâ ̣t phát triển phần mềm hướng hành vi thường sử du ̣ng ngôn ngữ đă ̣c

tả miền ứng dụng để đă ̣c tả yêu cầu Các tính năng được đi ̣nh nghĩa dựa trên mô ̣t

tâ ̣p các từ vựng c hỉ ra mô ̣t dãyhoạt động vàcách chúng sẽ được xử lý trong các giai đoạn phát triển tiếp theo Các yêu cầu hệ thống được đặc tả một cách dễ hiểu cho cả người sử dụng phần mềm lẫnđội phát triển.Phần mềm được cài đă ̣t thông qua các vòng lă ̣p , viê ̣c lựa cho ̣n tính năng đưa vào mỗi vòng lă ̣p dự a trên

đô ̣ ưu tiên,các tính năng quan trọng sẽ được thực hiện sớm vì thế chúng sẽ được kiểm thử nhiều lần trong suốt quá trình phát triển phần mềm

Sử du ̣ng ngôn ngữ đă ̣c tả miền ứng du ̣ng để viết các tính năng còn cải thiê ̣n quá trình giao tiếp giữa khách hàng với đội phát triển Khách hàng có thể tự viết yêu cầu của mình bằng mô ̣t ngôn ngữ dễ hiểu, và tài liệu yêu cầu này được dùng làm tài liệu để cài đặt ứng dụng, cũng như làm tiêu chí để kiểm thử chấp nhâ ̣n Toàn bộ các thành viên liên quan đến dự án cùng làm việc chung trên tài liệu đặc

tả này, giúp giảm thiểu sự hiểu lầm yêu cầu nghiê ̣p vu ̣

Trong kỹ thuật phát triển phần mềm hướng hành vi ở giai đoạn thu thập yêu cầu, đại diện khách hàng làm việc với một người phân tích nghiệp vụ để xác định các yêu cầu nghiệp vụ Trong phương pháp phát triển linh hoạt Agile thì phần yêu cầu này được hiểu là một câu chuyện người dùng và thường được mô

tả bằng ngôn ngữ miền ứng dụng theo cấu trúc như sau[6]:

vụ Hành vi ở đây được hiểu đơn giản là các tiêu chí kiểm thử chấp nhận Trong trường hợp hệ thống đáp ứng được tất cả các tiêu chí kiểm thử chấp nhận đó thì

hệ thống có chất lượng , ngược lại hệ thống không đạt yêu cầu của người dùng [6]

Trong phần giới thiệu về phát triển phần mềm hướng hành vi – BDD,Dan North đã đưa ra đi ̣nh da ̣ng để mô tả các tiêu chí kiểm thử chấp nhận của một câu chuyê ̣n người dùng[7]có dạng như sau:

Given:ngữ cảnh,

When:một sự kiện xảy ra,

Then:Đảm bảo một số kết quả

Ví dụ với tính năng quản lý thông tin người dùng