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

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” ‟

/**

* @Then /^I should see link "([^"]*)"$/ */

public function iShouldSeeLink($agr) {

$element = $this->getSession()->getPage(); $result = $element->findLink($agr);

if (empty($result)) {

throw new \Exception(sprintf("No link to '%s' on the page %s", $link, $this->getSession()->getCurrentUrl()));

}

//throw new PendingException(); }

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ền thố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]:

As a [X] I want [Y] So that [Z]

Trong đó Y đƣợc hiểu là một chức năng của hệ thống. Z là giá trị hay lợi ích mà Y đem lại, X là nhóm ngƣời hay bộ phận sẽ hƣởng lợi từ Z.

Quá trình xác định và mô tả yêu cầu ngƣời dùng với các dự án áp dụng BDD là rất quan tro ̣ng để quyết đi ̣nh chất lƣợng sản phẩm . Mô ̣t câu chuyê ̣n ngƣời dùng nên tâ ̣p trung vào viê ̣c mô tả hành vi hê ̣ thống để đạt giá trị nghiệp 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ả.

Feature: Testing sample REST services

In order to maintain user information through the services As a service user

I want to see if the services work as expected

Mỗicâu chuyện ngƣời dùng thƣờng có một số kịch bản sử dụng , mỗi ki ̣ch bản tƣơng ứng với một trƣờng hợp sử dụng nào đó . Ví dụ với tính năng quản lý thông tin ngƣời dùng ở trên gồm các kịch bản nhập thông tin cho một nhân viên mới, tìm kiếm thông tin hoặc cập nhật thông tin cho nhân viên đã tồn tại trên hệ thống, … . Mỗi kịch bản thƣờng có nhiều lê ̣nh hay còn go ̣i là bƣớc, chúng mô tả ngữ cảnh, hoạt động hay kết quả của kịch bản đó. Mỗi bƣớc nằm trên một dòng với các từ khóa cụ thểđứng đầu mỗi dòng.

Scenario: Creating a New Employee

Given that I want to add a new employee

And that employee ID of the employee is "007" And that name of the employee is "James Bond" And that age of the employee is "27"

When I request "/employee"

Then the response status code should be 200 And the response is JSON

And the response should be "true" Scenario: Finding an Existing Employee Given that I want to find an employee When I request "/employee/007"

Then the response status code should be 200 And the response is JSON

And in the response name of the employee is "James Bond" And in the response age of the employee is "27"

And in the response there is no field called "gender" Scenario: Updating an Existing Employee

Given that I want to update an employee

And that employee ID of the employee is "007" And I'm changing age of the employee to "38" When I request "/employee"

Then the response status code should be 200 And the response is JSON

And the response should be "true"

BDD đƣợc sử dụng để đặc tả và thiết kế phần mềm, nhƣng lợi ích lớn nhất mà BDD mang lại chính là việc mô tả các tiêu chí kiểm thử chấp nhận đến từ ngƣời sử dụng bằng ngôn ngữ tựa tự nhiên. Các tiêu chí này có thể dễ dàng đƣợc chuyển thành các phƣơng thức kiểm thử nhờ vào các công cụ hỗ trợ BDD. BDD thƣờng đi kèm với một ngôn ngữ mô tả miền ứng dụng để mô tả các hành vi của

ứng dụng, việc mô tả này giúp cho việc giao tiếp giữa các bên liên quan đến dự án phần mềm diễn ra dễ dàng hơn nhờ việc dùng chung một tài liệu đặc tả duy nhất mà các bên tham gia đều có thể hiểu đƣợc.

Kỹ thuật phát triển phần mềm hƣớng hành vi ngoài việc hỗ trợ kiểm thử chấp nhâ ̣n tƣ̣ đô ̣ng , còn đảm bảo kiểm thử bao phủ mọi yêu cầu. BDD đƣợc áp dụng cùng với các phƣơng pháp phát triển phần mềm theo nguyên lý lặp , mỗi vòng lặp tích hợp hoặc cải tiến mô ̣t số tính năng của hê ̣ thống. Các tính năng có đô ̣ ƣu tiên cao thƣờng đƣợc phát triển sớm hơn cá c tính năng có đô ̣ ƣu tiên thấp giúp cho việc kiểm thử chấp nhận diễn ra thƣờng xuyên , liên tu ̣c sau mỗi vòng