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 lă ̣p.Tính năng càng quan tro ̣ng thì đƣợc kiểm thƣ̉ càng nhiều lần . Nếu trong vòng lặp đó xuất hiện kiểm thử ở trạn g thái thất ba ̣i thì ngay lâ ̣p tƣ́c đô ̣i phát triển phải tìm nguyên nhân lỗi và cải thiê ̣n hê ̣ thống ở vòng lă ̣p tiếp theo cho đến khi tất cả các kiểm thƣ̉ đều thành công. Hê ̣ thống phát triển bằng kỹ thuâ ̣t phát triển phần mề m hƣớng hành vi đáp ƣ́ng mo ̣i tiêu chí kiểm thƣ̉ chấp nhâ ̣n của ngƣời dùng, do đó chất lƣợng sản phẩm đƣợc nâng lên rõ rê ̣t.
Tuy nhiên, BDD chỉ làm viê ̣c hiê ̣u quả khi có công cu ̣ hỗ trợ , đó là các hê ̣ thống đƣợc sƣ̉ du ̣ng để đo ̣c tài liê ̣u mô tả tính năng và lần lƣợt kiểm thƣ̉ cho tƣ̀ng tính năng. Viê ̣c lƣ̣a cho ̣n công cu ̣ tùy thuô ̣c vào môi trƣờng lâ ̣p trình và sở thích của đội phát triển . Tuy nhiên, do BDD là một kỹ thuật khá mới mẻ , chƣa đƣợc áp du ̣ng phổ bi ến và chƣa có nhiều tài liê ̣u tham khảo nên số lƣợng các công cu ̣ hỗ trợ còn khá ha ̣n chế so với các kỹ thuâ ̣t khác . Mô ̣t số công cu ̣ hỗ trợ BDD đƣợc chính tác giả Dan North cùng với cô ̣ng đồng nhƣ̃ng ngƣời sƣ̉ du ̣ng BDD xây dƣ̣ng nhƣ công cu ̣ Rspec cho ngôn ngƣ̃ Ruby, SpecFlow cho các ngôn ngƣ̃ .Net, …
Thời gian gần đây , các hệ thống trên nền web phát triển vƣợt bậc dần dần thay thế cho các ƣ́ ng du ̣ng Windows truyền thống, sƣ̣ di ̣ch chuyển này phần lớn nhờ vào các mã nguồn mở dành cho ƣ́ng du ̣ng web . Theo thống kê , hiê ̣n các trang web đƣợc viết bằng ngôn ngƣ̃ PHP chiếm tỷ lê ̣ cao. Chính vì thế nhu cầu kiểm thƣ̉ các ƣ́ng du ̣ng web nói chung và ƣ́ng du ̣ng web viết bằng PHP nói riêng là rất cần thiết . Qua tìm hiểu các công cu ̣ BDD thì số lƣợng các công cu ̣ hỗ trợ ngôn ngƣ̃ PHP không nhiều, chỉ có hai công cụ nổi bật là PHPSpec và Behat , cơ chế hoa ̣t đô ̣ng của hai công cu ̣ này tƣơng tƣ̣ nhau , nhƣng Behat đƣợc đa phần ngƣời dùng đánh giá tốt hơn. Trong chƣơng tiếp theo của luâ ̣n văn , tác giả sẽ giới thiê ̣u về công cu ̣ Behat.
CHƢƠNG 3. CÔNG CỤ BEHAT 3.1. Giới thiệu công cụ Behat
Behat là một công cu ̣ mã nguồn mở hỗ trợ phát triển phần mềm dƣ̣a tr ên viê ̣c đă ̣c tả các hành vi của ƣ́ng du ̣ng . Behat đƣợc viết cho ngôn ngữ PHP ở các phiên bản PHP 5.3 và PHP 5.4. Mục đích của Behat giúp cho việc xây dựng ứng dụng dƣ̣a vào mô tả các hành vi của chúng theo ngôn ngữ tự nhiên, nhằm chỉ ra các tính năng của ứng dụng, cách thức làm việc và cách cài đặt ứng dụng[8].
Behat đƣợc phát triển cho môi trƣờng Linux , trên trang thông tin của công cụ này chƣa có hƣớng dẫn c ụ thể để cài đặt nó trên các hệ điều hành khác . Quá trình cài đặt Behat đƣợc trình bày cụ thể trong phần phụ lục.
3.1.1. Công cụ dòng lệnh của Behat
Behat là một công cụ làm việc thông qua màn hình dòng lệnh. Để sử dụng công cu ̣ Behat cho ứng dụng thì sử dụng lệnh: behat
Tùy thuộc nhu cầu sử dụng , lê ̣nh này có thể đi kèm với các thuô ̣c tính . Cách gọi lệnh behat cùng thuô ̣c tính:
behat -- [thuộc tính] [giá trị]
Ví dụ: behat -- format html
Mô ̣t số thuô ̣c tính của lê ̣nh behat đƣợc mô tả trongBảng 3-1.
Thuộc tính Ý nghĩa
-h Hiển thị tất cả các lệnh và các thuộc tính của Behat -v Xem thông tin về phiên bản Behat hiện tại
--init Thực hiện khởi tạo cấu trúc thƣ mục của Behat trong ứng dụng --format
Thiết đặt định dạng của kết quả trả ra: prety, progress, html, junit, fail, snippets
Để xuất ra file thêm thuộc tính --out tên file …
--story-syxtax Hiển thị cú pháp Gherkin để định nghĩa một câu chuyê ̣n ngƣời dùng
-dl Hiển thị tất cả các biểu thức chính quy định nghĩa bƣớc khả dụng
-d Tìm kiếm định nghĩa bƣớc
--profile Tải một profile
3.1.2. Cấu trúc thƣ mục
Behat quy đi ̣nh mô ̣t cấu trúc thƣ mu ̣c để làm viê ̣c . Ở cấu hình mặc định , Behat hoạt động trong các thƣ mu ̣c nhƣ hình Hình 3-1. Các thƣ m ục này đƣợc sinh ra khi go ̣i lê ̣nh:
behat -- init
Project root Features Chứa tất cả các tập tin có đuôi .feature bootstrap Chứa tất cả các file PHP
FeatureContext.php Chứa các phƣơng thức định nghĩa bƣớc
Hình 3-1. Cấu trúc thƣ mu ̣c làm viê ̣c của Behat
Behat quản lý tất cả các tính năng của hê ̣ thống bằng cách quy định mỗi tính năng tƣơng ứng với một tập tin có phần mở rộng là .feature và đƣợc đặt trong thƣ mu ̣c features . Quá trìnhlàm việc, Behat sẽ duyệt toàn bộ thƣ mục này để thực hiện lần lƣợt các tính năng, các kịch bản, các bƣớc cho đến khi mọi tính năng đƣợc kiểm tra. Các thƣ viện, các thành phần mở rộng đƣợc viết thêm nhằm phục vụ cho việc kiểm thử đều đƣợc viết bằng ngôn ngữ PHP và đƣợc đặt trong thƣ mục bootstrap. Các phƣơng thức định nghĩa bƣớc cho các bƣớc đƣợc viết trong lớp ngƣ̃ cảnh , mă ̣c đi ̣nh nằm ta ̣i tập tin FeatureContext.php. Mỗi phƣơng thức định nghĩa bƣớc có một biểu thức chính quy tƣơng ứng với định nghĩa bƣớc đã nêu trong đi ̣nh nghĩa tính năng.
3.2. Cách sử dụng Behat
Behat là công cu ̣ hỗ trợ viê ̣c áp du ̣ng kỹ thuâ ̣t phát triển phần mềm hƣớng hành vi cho các ứng dụng web . Behat sƣ̉ du ̣ng ngôn ngƣ̃ PHP để đi ̣nh nghĩa các phƣơng thƣ́c kiểm thƣ̉ . Quá trình sử dụng Behat tƣơng tự nhƣ các tiến trình áp dụng BDD, bao gồm các bƣớc nhƣ mô tả dƣới đây.
3.2.1. Xác định các tính năng
Khi xây dựng hệ thống, trƣớc mỗi vòng lặp đội phát triển dự án cùng các bên liên quan phải chuẩn bị các câu chuyện ngƣời dùng để đƣa vào vòng lặp, BDD gọi đó là các tính năng. Mỗi tính năng mô tả các yêu cầu nghiệp vụ của khách hàng theo các khía cạnh nhƣ vai trò, mục đích, các hoạt động chính cần thực hiện trong tính năng để đạt đƣợc mục đích. Tâ ̣p các tính năng của hê ̣ thống vừa làm tài liệu chung cho các bên liên quan, vừa chƣ́a các tiêu chí để kiểm thử chấp nhận để kiểm thử tự động . Behat sử dụng ngôn ngữ Gherkin để đi ̣nh nghĩa tính năng, mỗi tính năng có dạng nhƣ sau [8]:
Feature:Tên tính năng Mô tả tính năng
Tính năng đƣợc viết theo cấu trúc của một câu chuyê ̣n ngƣời dùng đã mô tả ở mục1.3.
As a <User Role>
I want <Action or Goal> So that <Business value>
Ví dụ:
Feature: Contact form As a visitor
I want to contact an email address
So that I need to be able to submit a contact form
Tính năng bắt đầu với từ khóa Feature:, theo sau là tên của tính năng. Các dòng tiếp theo sẽ mô tả mục đích, ngƣời sƣ̉ du ̣ng và các hoạt động cơ bản. Các phần mô tả này chỉ mang tính chất giúp cho ngƣời đọc có thể hiểu tính năng, chúng không có vai trò trong việc kiểm thử chấp nhận. Mỗi tính năng bao gồm một số kịch bản tƣơng ƣ́ng với các trƣờng hợp sƣ̉ du ̣ng và chúng sẽ đƣợc định nghĩa với các bƣớc cụ thể bằng một tập các từ khóa của ngôn ngữ Gherkin.Phần kịch bản đó là các ví dụ cụ thể về hành vi của hệ thống, chúng mô tả các tiêu chí kiểm thƣ̉ chấp nhâ ̣n vàsẽ đƣợc chuyển thành các phƣơng thức kiểm thử ở giai đoa ̣n sau.
Tính năng có thể đƣợc viết bởichính khách hàng hoặc có sự hỗ trợ ngƣời phát triển, nhằm đảm bảo cho các tính năng thể hiện đƣợc mong muốn thực sự của ngƣời sử dụng vào hệ thống đang xây dựng. Đây chính là một yếu tố đảm bảo cho việc kiểm thử chấp nhận hệ thống thành công.
3.2.2. Sử dụng Gherkin để viết các tính năng
Gherkin là ngôn ngữ thể hiện nghiệp vụ và c ó miền ngữ nghĩa xác định, nó giúp cho ngƣời đọc có thể hiểu kịch bản và hoạt động của hê ̣ thống mà không