Home Blog

DryRun option trong Cucumber là gì?

0

Khi làm việc với Cucumber có bao giờ các bạn gặp trường hợp khi bạn có quá nhiều Step Definition mà không biết cái nào chưa được define, hoặc đã bị chỉnh sửa nhưng chưa ai sửa ở ngoài file feature không?

Nếu có trường hợp gì sẽ xảy ra, khi bạn chạy feature đó, sẽ failed cả Scenario đó. Giả sử là 5-10 Scenario thì chúng ta còn có thể scan tay được. Nếu như là 10,000 Scenarios thì sao. Do đó, Cucumber đã cung cấp cho chúng ta 1 option để có thể scan undefined test step trước khi run. Và nó có tên là dryRun.

Dùng dryRun scan file feature để nhận biết undefined Test Step trong Cucumber

dryRun được giới thiệu là 1 option của Cucumber giúp chúng ta có thể chạy qua các feature cần thiết để scan ra được các undefined test step mà không cần phải run thật tế các test step còn lại.

Các bạn trước hết cần có 1 FW chạy Cucumber hoàn chỉnh và được setup để run bởi JUnit. Cùng lúc đó, dhthsare đã chuẩn bị sẵn 1 feature file, có 2 step undefined ở đầu và cuối scenario:

  • And I use invalid statement first
  • And I use invalid statement 2

Và 1 JUnit configuration để run feature file đó

Bước 1:

Ở runner file, nên các bạn setup @CucumberOptions được import từ io.cucumber.junit, hãy thêm cho mình 1 option trong đó là dryRun=true, (mặc định sẽ là false)

Bước 2: Cho run JUnit configure ở trên và quan sát log của runner, và ta sẽ thấy được các undefined test step sẽ hiện ra ở đây:

Mong rằng dthshare có thể giúp bạn dễ dàng hơn trong việc truy vết các test steps chưa được define nhé. Chúc các bạn thành công

Reference: https://cucumber.io/

Implicit wait và Explicit wait của Selenium Webdriver

0

Khi các bạn implement automation sẽ có nhiều trường hợp các bạn thấy rằng thao tác của selenium là quá nhanh và và khi trang web đang loading mà các bạn đã cho click một element nào đó. Thì trong trường hợp các bạn nên dùng “wait”, cụ thể sẽ là: implicit wait, explicit wait và fluent wait

Các trường hợp nên dùng wait

Với sự phát triển đến từ công nghệ Web Application, các trang web đã dần trở thành Single-page Application và ít khi cần đến phải reload page. Nên việc sử dụng những method wait page load đã trở nên không sử dụng được.

Do đó, Selenium đã phát triển các Selenium wait bao gồm: Implicit wait, Explicit wait và Fluent wait để cho chúng ta có thể wait hoặc kéo dài thời gian timeout của việc find element ra.

Implicit wait

Trình bày một cách đơn giản, Implicit wait chính là đang cài đặt cho selenium “wait” một khoảng thời gian nhất định trước khi Selenium báo lỗi “No Such Element Exception” (thường được set cho findElement).

Implicit wait syntax:

WebDrivers.manage().timeouts().implicitlyWait(0,TimeUnit.SECONDS);

implicitlyWait method được dùng với 2 parameters:

  • Thời gian với giá trị là integer
  • Đơn vị thời gian, bao gồm: SECONDS, MINUTES, MILISECOND, ….

Explicit wait

Explicit wait được dùng để “wait” với một điều kiện nhất định (ExpectedConditions) hoặc là với một khoảng thời gian nhất định. Explicit wait sử dụng WebDriverWait để wait cho đến khi các điều kiện được đáp ứng.

Explicit wait syntax:

WebDriverWait wait = new WebDriverWait(driver, 20);

wait.until(ExpectedConditions.visibilityOfElement(elemnent);

WebDriverWait bao gồm 2 parameters:

  • 1 là WebDriver mà ta đang khởi tạo và sử dụng
  • 2 là timeout in seconds được sử dụng trong WebDriverWait

Sau khi đã khởi tạo WebDriverWait (tạm đặt tên biến là wait), chúng ta có thể sử dụng syntax là wait.until và bên trong đó chính là những điều kiện để chúng ta wait những trường hợp đặc thù.

Các ExpectedConditions bao gồm:

  1. titleIs
  2. titleContains
  3. urlToBe
  4. urlCOntains
  5. urlMatches
  6. presenceOfElementLocated
  7. visibilityOfElementLocated
  8. invisibilityOfElementLocated

Cách thức WebElement.clear() hoạt động

0

Khi làm việc với Selenium, chúng ta sẽ có được một object type với cái tên WebElement để làm việc và tương tác trực tiếp với Element mà ta đã “find” trên web. Cùng với đó, WebElement cũng cung cấp cho chúng ta rất nhiều các method để tương tác với nó, như là: click, sendKeys,..

Và trong số các method mà WebElement cung cấp, có một method với cái tên là “clear()” là khá đặc biệt so với các method còn lại. Vậy method này thực sự sẽ hoạt động như thế nào. Hãy cùng dthshare tìm hiểu method WebElement.clear() này nhé.

Định nghĩa về WebElement.clear()

Theo định nghĩa cơ bản nhất đến từ Selenium, thì WebElement.clear(), sẽ xóa đi dữ liệu đang hiển thị trên Element đó với điều kiện Element đó phải là một Editable Element (có thể edit hoặc type text).

Cách thức WebElement.clear() hoạt động

Không giống với những method khác có cùng sứ mệnh với nó là giải lập thao tác của người dùng trên browser. Như click(). chính là giả lập lại thao tác click() một khu vực nào đó trên browser, nếu bị che bởi một gì đó trên màn hình, click sẽ báo lỗi là không unclickable element.

Hoặc, như sendKeys() chính là giả lập lại hành động truyền tải dữ liệu từ keyboard vào element nào đó trên browser từng từ 1 và cũng như click, sẽ báo lỗi, nếu element đó invisible.

Nhưng với WebElement.clear() đã dường như dùng vài thủ thuật nhỏ để xóa đi dữ liệu trong element đó mà không phải theo cách một “user” sẽ làm (trỏ chuột vào field, bấm delete).

Theo w3.org, thật chất, method này đang đi clear một attribute của Element đó mà không phải thao tác thật tế như một người dùng thật sự và Attribute đó là innerHTML.

Bởi vì điều đó khiến nhiều trường hợp mà dù cho có gọi method clear() nhưng element vẫn giữ value đó. Có thể là vì field đó đã được setup những event handler cao cấp mà với việc clear innerHTML vẫn không thể xóa đi dữ liệu của nó.

Vì vậy, nếu là đối với dthshare thì cách xóa triệt để dữ liệu một field nào đó, sẽ hạn chế dùng clear method mà sẽ dùng tổ hợp phím Ctrl + A + Delete (for Windows) and Command + A + Delete (for MacOS) để xóa dữ liệu.

Điều này sẽ giúp ta thật tế thiết lập được hành động của người dùng hơn là dùng clear method. Mong rằng kiến thức này của dthshare có thể giúp ích được đến với các bạn.

Reference: https://www.w3.org/TR/webdriver1/#element-clear

Sự khác biệt giữa io.cucumber và info.cukes

0
io.cucumber
io.cucumber

Đều cùng là maven dependencies, nhưng io.cucumber và info.cukes khiến nhiều bạn khi mới tiếp cận với Cucumber trở nên gặp nhiều trắc trở rằng không biết nên dùng library nào. Nay dthshare sẽ giúp các bạn giải đáp thắc mắc về vấn đề này nhé.

Cucumber và Cucumber JVM

Cucumber là một open-source Test Automation Framework được dùng cho Behavior-driven development. Cucumber dùng một ngôn ngữ nghiệp vụ có thể đọc được tựa như ngôn ngữ tự nhiên: Gherkin để cho sự tiện lợi trong việc trao đổi giữa các team với nhau.

Cucumber JVM là một port chính thức của bên JAVA. Mỗi Gherkin statement (step) đều được “glue” (dẫn đến) một method để thực thi nó. Ngôn ngữ được dùng cho Gherkin (có thể là tiếng Anh, Pháp,..) đều được glue thông qua những annotation hay regex.

For Ex:

Và những annontation đó hay regex đều được tim thấy thông qua Cucumber JVM.

Sự khác biệt giữa io.cucumber và info.cukes

io.cucumber

Vậy như ta đã biết mỗi library mà muốn sử dụng trong JAVA thường được add vào thông qua Maven (hoặc có thể add bằng JAR hay những cách khác). Nhưng hiện tại, lại tồn tại 2 Maven Group Id là io.cucumber và info.cukes để sử dụng được Cucumber JVM. Vậy sự khác biệt của chúng là gì?

Cả 2 đều là Maven groups id. Nhưng info.cukes được dùng cho version Cucumber từ 1.2.5 trở về trước mà io.cucumber thì được chứa nó version mới nhất của Cucumber (từ version 2.0.0 trở đến version hiện tại)

Trong năm 2017, Cucumber JVM 2.0 đã được công bố và mang vào sử dụng cho các project Cucumber JVM. Và version mới đó ta có thể dễ dàng tìm được trong Maven Group Id: io.cucmber. Phiên bản cũ hơn (từ 2.0 trở về trước: 1.x) có thể tìm được trong Maven Group Id: info.cukes. 

Nếu các bạn đang tạo mới cho bản thân mình một dự án sử dụng Cucumber JVM thì mình có thể khuyên dùng Maven Group ID: io.cumber để có những trải nghiệm và support mới nhất đến từ Cucumber JVM.

Mong với những thông tin trên dthshare đã có thể giúp bạn hiểu rõ hơn về io.cucumber và info.cukes

Performance Testing là gì

0
Performance Testing là gì
Performance Testing là gì

Trong thế giới công nghệ phần mềm như hiện nay, 1 sản phẩm được tạo ra trên thế giới này đều không phải chỉ được dùng bởi 1-2 người dùng mà còn sẽ là của 100,1000,1 vạn người dùng. Theo nhu cầu đó, phương pháp Testing căn bản sẽ không thể bao quát hết những yếu tố cần test cho việc chịu tải của 1 hệ thống. Vì vậy, Performance Testing được tạo ra.

I. Performance Testing là gì?

Performance Testing là một phương pháp testing được dùng để kiểm định tốc độ phản hồi, độ ổn định, độ mở rộng của một hệ thống trong một sức chịu tải nhất định.

Mục tiêu chính của Performance Testing chính là:

  • Đảm bảo cho hệ thống có thể hoạt động một cách ổn định trong một chu trình chịu tải nhất định. (Ví dụ: 500 Concurrent User* trong một giờ chạy, hệ thống vẫn ổn định, CPU/Memory/Database không vượt quá mức quy định, thời gian phản hồi vẫn trong con số đã định từ đầu)
  • Tìm ra được “điểm tắt nghẽn” (bottle neck) mà hệ thống đang mắc phải.
  • Hạn chế được số lần downtime có thể xảy ra khi hệ thống đã onlaunch cho khách hàng sử dụng

II. Các loại của hình của Performance Testing

Vì performance testing khá rộng so với những gì mà 1 phương pháp test có thể bao hàm hết, nên nó được tạo ra cùng với nhiều loại hình khác nhau:

  • Load Testing: Mục tiêu của load test đơn giản vẫn là đảm bảo cho hệ thống có thể chạy được với một sức chịu tải nhất định (low to peak), và đồng thời là có thể dò xét các bottleneck mà hệ thống có thể mắc phải trước khi on launch ra thị trường sử dụng
  • Stress Testing: Nếu load test là việc ta chạy dưới giới hạn chịu tải của hệ thống, thì stress test sẽ là phương pháp test vượt qua mức hạn định đó nhầm mục tiêu đánh giá rằng hệ thống sẽ hoạt động như thế nào khi ở tình trạng quá tải.
  • Volume Test: Nếu hệ thống bao gồm FE. BE thì có một hình thức sẽ được dùng để chuyên đo cho Database, với tên Volume Test, phương pháp test này sẽ focus nhiều vào lượng data được “boom” vào database và xem hệ thống sẽ hoạt động như thế nào trong tình trạng trên.

Và cùng với nhiều phương pháp khác để giúp cân đo đong đếm được đa dạng sức chịu tải của một hệ thống.

III. Các testing tool dùng để hỗ trợ trong Performance Testing

Khác với testing bình thường 1 chút là chúng ta sẽ không hoạt động chính trên giao diện hay hệ thống mà sẽ hoạt động thông qua các tool hỗ trợ.

Các tool này có công việc sẽ record lại các request của hệ thống theo 1 scenario nhất định (do mình tạo ra) và thực thi lại các request đó theo 1 sức chịu tải nhất định cho mình điều chỉnh. Và đương nhiên chúng sẽ thường đi kèm các report để chúng ta theo dõi dễ hàng

Lưu ý rằng: Report không phải thứ duy nhất chúng ta cần theo dõi, mà còn phải là các thông số trong hệ thống bao gồm CPU/Memory/Database mới có thể đưa ra được kết luận cuối cùng tốt nhất.

Sau đây là 2 trong những công cụ dùng để hỗ trợ trong Perfomance Testing tốt nhất mà DTH Share đã từng sử dụng qua:

JMeter

Apache JMeter

JMeter là một công cụ đắc lực trong Performance Testing, và hoàn toàn là một open source tool 100%. Được sử dụng phổ biến bởi nhiều performance tester với ngôn ngữ được sử dụng sẽ là Groovy.

HP LoadRunner

HP LoadRunner là cũng là một công cụ dùng cho Performance Testing, nhưng khác với JMeter, ngôn ngữ chính được dùng ở HP LoadRunner sẽ là C. Với một thế lực hùng mạnh là MicroFocus phía sau, nên HP LoadRunner khá chuộn được người dùng bởi UI/UX thân thiện, và hệ thống support hùng mạnh

Và các thông tin chính là sơ bộ nhất cho các bạn đọc về Perfomance Testing, mong là bài viết này đã có thể giúp các bạn có những kiến thức mở đầu cho công cuộc tìm hiểu Performance Testing.

Automation Tool và các định nghĩa về nó – Phần 1

0
AUTOMATION TOOL VÀ CÁC ĐỊNH NGHĨA VỀ NÓ – PHẦN 1
AUTOMATION TOOL VÀ CÁC ĐỊNH NGHĨA VỀ NÓ – PHẦN 1

Trong thế giới Automation này, có rất nhiều khái niệm tồn tại xung quanh công việc hằng ngày của chúng ta, nhưng liệu rằng chúng ta đã hết tất cả khái niệm đó không. Ngày hôm nay, hãy để DTHShare chia sẻ cho các bạn tất tần tật về Automation Tool, Automation Framework và những khái niệm khác nhé.

 

AUTOMATION TOOL VÀ CÁC ĐỊNH NGHĨA VỀ NÓ – PHẦN 1
AUTOMATION TOOL VÀ CÁC ĐỊNH NGHĨA VỀ NÓ – PHẦN 1

 

I. Software Development Approach là gì?

Software Development Approach là những cách thức được đưa vào quá trình phát triển phần mềm và được sử dụng xuyên suốt bởi các thành viên trong team, với mục đích giúp cho việc giao tiếp công việc trong team trở nên dễ dàng hơn.

Test-Driven Development (TDD)

TDD là một quy trình phát triển phần mềm được dựa trên việc sử dụng các yêu cầu phần mềm (software requirement) được defined từ trước và từ đó tạo nên những test case trước khi mà Phần mềm  được đưa lên môi trường UAT hoặc Staging.

Behavior-Driven Development (BDD)

BDD là cách ứng dụng quá trí phát triển phần mềm mà cho phép các Test Engineer/BA/PM có thể tạo ra được các test case (kể cả automation và manual test case) với ngôn ngữ tự nhiên chứ không dùng đến ngôn ngữ lập trình hoặc scripting.

 

II. Automation Tool là gì?

Có rất nhiều định nghĩa về phần Automation Tool, nhưng hôm nay, team mình sẽ đưa đến các bạn định nghĩa tốt nhất có thể:

Automation Tool là một phần mềm được dùng để giúp đỡ mọi người (cụ thể là: QA/QC/Tester) trong công việc tự động hóa công việc kiểm thử của họ, điều mà sau này sẽ giúp họ chạy các công việc mà không cần đến sự tác động của nhân lực (tối đa nhất có thể)

Rất nhiều Automation Tool trên thế giới đã được tạo ra nhằm mục đích giúp đỡ các anh em Tester chúng ta, như là: Selenium, Katalon và nhiều hơn nữa

 

Selenium

Selenium từ trước giờ đã được xem như một huyền thoại trong ngành công nghiệp Automation Testing này, nó là một (open-source) automated testing framework miễn phí dùng để kiểm định các web applications suốt các browsers và platform khác nhau. Chúng ta có thể sử dụng nhiều loại ngôn ngữ lập trình khác nhau để sử dụng Selenium như JAVA, C#, Python,.. để tạo nên Selenium Test Scripts

Và tất nhiên rằng, Selenium cũng cung cấp cho chúng ta một IDE để có thể làm việc với nó.

Link: https://www.selenium.dev

Katalon Studio

AUTOMATION TOOL, AUTOMATION FRAMEWORK AND MORE – PART 1

Katalon Studio là một robust automation solution dành cho kiểm thử ở WEB, API, Mobile và cả desktop. Nó được kết nối với hầu hết các công cụ cần thiết hiện tại bởi những builit-in keywords và project template bên trong một automation framework hoàn chỉnh.

Katalon Studio rất dễ sử dụng cho người mới tiếp cận với lập trình và kể cả là với automation, tuy vậy nó có rất nhiều những component mà dân chuyên có thể khai thác và phát triển.

Link: https://www.katalon.com

Cucumber

Cucumber là một công cụ dựa trên Behavior Driven Development (BDD) framework với mục tiêu được sử dụng để viết các Acceptance Test dành cho web application. Nó cho phép mình automate những function dùng để tương tác với browser (action and assertion) một cách dễ đọc và dễ hiểu nhất có thể, bởi chúng dùng ngôn ngữ tự nhiên.

Link: https://cucumber.io

 

III. Automation Framework

Framework là một khái niệm với độ phức tạp cao hơn cả Automation Tool, do đó, DTH Share chúng mình sẽ mang cho bạn một khái niệm đơn giản nhất, nhưng cũng gần đúng nhất về Automation Framework:

Automation Framework chính là những gì bạn làm với Automation để tạo nên Test Case và Report theo một tiêu chuẩn nhất định

Có rất nhiều dạng Automation Framework được các bạn QA/QC/Tester sử dụng:

Linear Scripting

Linear Scripting còn được biết với cái tên “Record & Playback”. Theo những gì chúng mình biết, Record & Playback sẽ là công cụ đầu tiên mà các bạn mới tiếp cận Automation Testing sẽ gặp.

Các Tester/User sẽ record lại từng hành động của mình trên website và lưu lại với các step (action), và cũng có thể mark các checkpoint (assertion) để verify pass/failed ở đấy, nhờ 2 khái niệm đó, mà Linear Scripting sẽ tạo ra Automation Test Case.

The Test Library Architecture Framework

Framework này được xem như dạng nâng cấp của Linear Scripting, sau khi record thành công, vì tồn tại riêng lẻ với nhau, nên các step sẽ được collect lại thành các function, và được sử dụng sau này thành. The Test Library Architecture Framework còn được xem là “Structured Scripting”.

The Data-Driven Testing Framework

Trong framework này, người sử dụng chúng sẽ dùng các loại dữ liệu bên ngoài cho cả action và assertion. Dữ liệu sẽ được giữ ở file CSV/Excel/… và được đọc vào bằng một số function nhất định để gán vào các biến trong Test Script.

Phần Test Script có thể sử dụng bằng Linear Scripting hoặc The Test Library Architecture Framework tùy ý.

The Keyword-Driven or Table-Driven Testing Framework

Keyword-Driven Framework là cách mà từng dùng những keyword (những function được define để thực hiện các action hoặc assertion trên website) được định nghĩa bởi các người dùng framework nhưng không thông qua Record.

Những keyword này sẽ được gọi trực tiếp trong Test Script (Test Case).

The Hybrid Test Automation Framework

Framework dường như được xem là Framework tốt nhất để sử dụng, vì nó được kết hợp giữa 2 framework lớn là Data-Driven Testing Framework (được dùng để quản lý testing data) và Keyword-Driven Framework (được dùng để quản lý các action và assertion function).

 

IV. Testing Framework (Unit Test Framework)

Khi ta đã có trong tay, một Automation Tool và Automation Framework thì bạn vẫn còn cần một công cụ nữa (đôi khi công cụ này đã được built-in trong Automation Tool, nhưng mình vẫn mong muốn các bạn biết về nó).

Testing Framwork, hay Assertion Framework hoặc là Unit Test Framework được dùng để xác định Test Case đó sẽ là pass hay fail cụ thể ở step nào. Có rất nhiều Testing Framework, như: JUnit (Java), CUnit (C#), Mocha/Jasmine (Javascript)

 

Có rất nhiều định nghĩa nữa còn tồn tại trong thế giới Automation này. và cũng như còn rất nhiều Automation Tool chưa được giới thiệu trong bài post này. Hãy cùng đồng hành với DTH Share với các bài kế tiếp để đi sâu hơn vào thế giới Automation. Xin cảm ơn các bạn đã theo dõi bài viết này.