Bài viết được tham khảo từ nguồn:
https://www.nagarro.com/en/blog/bdd-behavior-driven-development-agile-project-experience
Tóm Tắt
1. BDD là gì?
- BDD là viết tắt của ( Behavior Driven Development ) là một chiêu thức được ý tưởng bởi Dan North, tập trung chuyên sâu vào việc diễn đạt hành vi ứng dụng thay vì tập trung chuyên sâu vào tăng trưởng ứng dụng theo hướng kiểm thử. Khi tiến hành BDD trong một dự án Bất Động Sản trong thực tiễn, kể đến đó là nhiều thuận tiện trong việc chia tách những case dễ làm, dễ tưởng tượng, những thành viên trong đội dự án Bất Động Sản được tương tác với nhau từ tiến trình đầu ( clarify requirement ) … nhưng lại cũng có 1 số ít khó khăn vất vả nhất định và trong bài này tất cả chúng ta sẽ cùng xem khó khăn vất vả mà BDD tác động ảnh hưởng đến dự án Bất Động Sản như thế nào và dự án Bất Động Sản cần làm gì để BDD được tiến hành đúng trong dự án Bất Động Sản của mình nhé .
-
Dựa vào yêu cầu của hệ thống, cách mà BDD triển khai là viết theo ngôn ngữ tự nhiên gồm ba bước như sau:
Bước 1 : Viết user story ( Given )Bước 2 : Viết tiêu chuẩn đồng ý ( End )Bước 3 : Viết ra scenario ( Then )Given-end-then : Có thể được so sánh với những báo cáo lỗi vì cả hai đều miêu tả những bước để tạo ra một hành vi mạng lưới hệ thống mong đợi. Tuy nhiên, Given-When-Then thường được viết trước khi mạng lưới hệ thống được tiến hành và bỏ lỡ hành vi có lỗi, trong khi báo cáo lỗi được viết sau khi mạng lưới hệ thống đã được tiến hành và cũng chứa lỗi :
Given-end-then cũng hoàn toàn có thể được so sánh với mẫu thử nghiệm “ Triple-A ” nổi tiếng Unit test :
2. Tổng quan về dự án
Mục tiêu của chúng tôi là văn minh hóa cổng thông tin điện tử trải qua kiến trúc hướng dịch vụ. Các dịch vụ độc lập được nhóm lại thành những mô-đun để kích hoạt công dụng được sử dụng bởi những tiến trình kinh doanh thương mại .Để tăng trưởng và test những dịch vụ như vậy, chúng tôi quyết định hành động sử dụng chiêu thức BDD .
3. Cơ sở lý luận đằng sau việc triển khai BDD
Để tiến hành những mô-đun và dịch vụ được nhu yếu, chúng tôi đã chọn cách tiếp cận lặp đi lặp lại theo quy mô Agile với chu kỳ luân hồi một Sprint trong vòng 2 tuần. Điều này có nghĩa là chúng tôi có một luồng câu truyện không thay đổi trong nhóm, trong đó một câu truyện thường miêu tả khoanh vùng phạm vi của một dịch vụ sẽ được tăng trưởng .
Chúng tôi đã sử dụng phát triển theo BDD để:
- Minh họa rõ ràng hành vi ứng dụng bằng cách diễn đạt những trường hợp sử dụng đơn cử
- Tạo sự hiểu biết chung về những nhu yếu trong nhóm dự án Bất Động Sản
- Bao gồm những tiêu chuẩn gật đầu với những trường hợp BDD
- Xác định cơ sở cho Auto test
=> Sau một vài lần chạy nước rút, chúng tôi đã xác lập được nhiều giải pháp và thực tiễn có ích khác nhau đã hoạt động giải trí trong dự án Bất Động Sản của mình .
3.1. Mười con mắt nhìn thấy nhiều hơn hai
Cú pháp “ “ Given, When, Then ” ” được đề xuất kiến nghị để tăng trưởng theo hướng hành vi giúp nhóm tâm lý rõ ràng về hành vi của mạng lưới hệ thống hoặc tác dụng mong ước của một công dụng được diễn đạt. Trong những phiên nâng cấp cải tiến câu truyện của chúng tôi xuất hiện một người từ mọi vai trò ( tester, developer, nhà nghiên cứu và phân tích, product owner, kiến trúc sư ứng dụng, v.v. ), chúng tôi nhanh gọn nhận ra rằng BDD được cho phép chúng tôi tạo ra hiểu biết chung về nhu yếu. Điều này cũng có lợi cho chúng tôi trong việc củng cố lòng tin vào mục tiêu của câu truyện và hiểu được nhu yếu của end-user .
3.2. Kiểm tra tính khả dụng của dữ liệu
- Khi diễn đạt những trường hợp với tư cách là tester hoặc test lead, điều quan trọng là phải xem xét tài liệu thử nghiệm bạn cần để thực thi. Nếu hoàn toàn có thể, hãy nỗ lực gồm có tài liệu thực và ẩn danh từ mạng lưới hệ thống của bạn hoặc thử nghiệm .
- Sau đó, điều này giúp thực thi những ngữ cảnh dưới dạng những trường hợp thử nghiệm tự động hóa và tích hợp chúng vào môi trường tự nhiên thử nghiệm .
Ví dụ: Yêu cầu là kiểm tra xử lý dữ liệu cho một địa chỉ giao hàng nhất định như:
“Đường: Phạm Hùng – Thành phố: Hà nội”, có thể dễ dàng tích hợp trên một giai đoạn sử dụng mô hình thử nghiệm nhưng sẽ không bao giờ chạy trên một giai đoạn sử dụng dữ liệu thực.
- Bao gồm cả doanh nghiệp hoặc end-user trong quy trình tạo hoặc xem xét những ngữ cảnh BDD hoàn toàn có thể phát hiện ra một số ít trường hợp cạnh hoặc những chòm sao tài liệu đặc biệt quan trọng cũng hoàn toàn có thể được gồm có trong những thử nghiệm .
- Bằng cách xác lập tài liệu thử nghiệm thiết yếu, chúng tôi thường gặp phải những trường hợp và trường hợp không được đề cập trong phần miêu tả của câu truyện. Xử lý những định dạng ngày / giờ đơn cử cho những vương quốc khác nhau .
3.3. Phân loại kịch bản
Việc gắn thẻ các tình huống ngay lập tức khi tạo chúng rất hữu ích, vì vậy bạn có thể biết ngay loại kịch bản mà mình đang xử lý (ví dụ: @Regression, @Smoketest, @ System-Integration, v.v.). Làm như vậy sẽ cho phép bạn tìm thấy một số testcase dễ dàng hơn và nhóm chúng lại với nhau để thực hiện chúng trong một lần chạy, đặc biệt nếu chúng được tự động hóa.
Ví dụ : Sau khi tiến hành, tổng thể những testcase với hạng mục “ Smoketest ” sẽ vượt qua trước khi tham gia vào bất kể hoạt động giải trí thử nghiệm nào tiếp theo .
3.4. Giữ các điều kiện tiên quyết ở mức tối thiểu
Một trong những điều quan trọng nhất trong quy trình thực thi dự án Bất Động Sản là giữ cho dàn ý ngữ cảnh ( diễn đạt khoanh vùng phạm vi của ngữ cảnh ) và những khối “ Cho trước ” càng nhỏ càng tốt. Nếu không, việc giải quyết và xử lý và tự động hóa những ngữ cảnh sẽ nhanh gọn trở nên rất phức tạp và lộn xộn. Các ngữ cảnh phức tạp hoàn toàn có thể phản ánh chất lượng và quy mô của câu truyện. Thông thường, nếu diễn đạt câu truyện không đủ cụ thể hoặc tổng lực, những ngữ cảnh có xu thế không đúng mực. Một nguyên tắc nhỏ là chia một câu truyện nếu nó có nhiều hơn 8-10 tiêu chuẩn đồng ý .
3.5. Quản lý sự phức tạp
Mặc dù ký hiệu hoặc cú pháp của tăng trưởng theoBDD khá rõ ràng, nhưng có những trường hợp bạn có nhiều năng lực để diễn đạt những user story nhất định trong những trường hợp của mình .Ví dụ về BDD như sau :
Given: I am on the “Choose Size“ tab in the UI
And: the Size is 0 When I click the “Edit“ Button
And: I click in the Input field
And: I enter the value “50“
And: I click the save Button
Then: the new Size should be 50
Mô tả này rất chi tiết cụ thể và đa phần dựa vào những yếu tố giao diện người dùng như “ button ” hoặc “ input field ”. Nó cũng giống như một miêu tả về quy trình thay vì hành vi. Việc này sẽ tốn nhiều thời hạn ở quy trình tiến độ bảo dưỡng nếu 1 số ít nút UI biến hóa hoặc nếu tính năng chuyển sang tab khác .
Sau đây là một cách tiếp cận tốt hơn:
Scenarion: User muốn edit size của một ứng dụng để mua hàng
Given: the Size is
When: the User changes the Size to
Then: the new Size should be
Ví dụ :
| Initial | newSize | ResultSize |
|---|---|---|
| 0 | 50 | 50 |
| 50 | 20 | 20 |
| 20 | 0 | 0 |
Trong trường hợp này, không quan trọng những nút được gọi là gì hoặc tìm công dụng ở đâu – đó chỉ là hành vi được minh họa bằng ba ví dụ. Hành vi sẽ giống nhau mặc dầu có bất kể cụ thể tiến hành nào được miêu tả .Trong quy trình làm dự án Bất Động Sản, mọi người trong team phải mất một vài lần chạy nước rút để tâm lý ở mức độ trừu tượng hơn chỉ tập trung chuyên sâu vào hành vi .
3.6. Xác định trách nhiệm
BDD giúp ích rất nhiều trong việc hiểu nghĩa vụ và trách nhiệm của những vai trò khác nhau trong nhóm tăng trưởng ứng dụng. Có một nhóm phân tán, điều này nhiều lúc khiến việc tiếp xúc trở nên phức tạp. Với BDD, bạn hoàn toàn có thể tạo ra những trách nhiệm cho những thành viên khác nhau trong nhóm theo những trường hợp, do đó làm cho mọi thứ rõ ràng hơn .Ví dụ :Tester chịu nghĩa vụ và trách nhiệm cung ứng tài liệu thử nghiệm .
Developer và kỹ sư Automation test chịu trách nhiệm triển khai kịch bản dưới dạng mã.
Product owner nhận được quan điểm góp phần về những trường hợp tiên tiến và phát triển từ người dùng .Kiến trúc sư ứng dụng bảo vệ rằng bất kể lỗ hổng tính năng nào được phát hiện trong những nhu yếu đều được xem xét trong một dịch vụ mới .
Kết luận:
Phát triển theo khuynh hướng BDD đã giúp ích rất nhiều trong việc tăng cường sự hiểu biết giữa những thành viên trong nhóm, đặc biệt quan trọng là khi có sự rõ ràng về những nghĩa vụ và trách nhiệm khác nhau và đàm đạo về những trường hợp giữa những vai trò khác nhau. Bắt đầu với BDD hoàn toàn có thể hơi khó khăn vất vả, nhưng gắn bó với nó thực sự mang lại hiệu suất cao, miễn là bạn luôn thích nghi và cải tổ cách bạn sử dụng nó như một nhóm. Lợi ích điển hình nổi bật nhất mà BDD mang lại là nó khuyến khích, nhu yếu tiếp xúc và phối hợp trong nhóm, do đó bảo vệ chất lượng cao ngay từ quy trình tiến độ đầu của dự án Bất Động Sản .
Source: https://final-blade.com
Category : Kiến thức Internet
