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,