Nghiên cứu và ứng dụng công cụ kiểm thử tự động selenium trong kiểm thử phần mềm

ĐẠI HỌC QUỐC GIA HÀ NỘI VIỆN CÔNG NGHỆ THÔNG TIN ĐẶNG THỊ PHƯƠNG NGHIÊN CỨU VÀ ỨNG DỤNG CÔNG CỤ KIỂM THỬ TỰ ĐỘNG SELENIUM TRONG KIỂM THỬ PHẦN MỀM Ngành: Công nghệ thông tin Chuyên ngành: Quản lý hệ thống thông tin Mã số: Chuyên ngành đào tạo thí điểm TĨM TẮT LUẬN VĂN THẠC SĨ CƠNG NGHỆ THÔNG TIN Hà Nội – Năm 2015 MỤC LỤC MỤC LỤC Chương 1: TỔNG QUAN VỀ BDD - CUCUMBER - SELENIUM - PAGE OBJECT 1.1 Tổng quan kiểm thử phần mềm 1.2 TDD (Test Driven Development) .3 1.2.1 TDD gì? 1.2.2 Ba điều luật áp dụng TDD 1.2.3 Các bước thực chu trình TDD .4 1.2.4 Các cấp độ TDD 1.3 BDD (Behaviour Driven Development) 1.3.1 Khái niệm 1.3.2 Quy trình phát triển phần mềm truyền thống 1.3.3 Quy trình phát triển theo hướng BDD 1.4 Cucumber 1.4.1 Khái niệm 1.4.2 Ngôn ngữ Gherkin 1.4.3 Chạy Cucumber Junit test 1.4.4 Chu trình 1.4.5 Sơ đồ workflow xử lý steps cucumber 1.4.6 Cấu trúc dự án cài đặt Cucumber 1.4.7 Các thư viện cần thiết để chạy Cucumber 1.5 Selenium WebDriver 1.5.1 Selenium WebDriver 1.5.2 Tổng quan đối tượng UI (Locators) 1.5.2.2 Xác định phần tử Web theo Name 10 1.5.2.3 Xác định phần tử Web theo LinkText 10 1.5.2.4 Xác định phần tử Web theo TagName 10 1.5.2.5 Xác định phần tử Web theo ClassName .11 1.5.2.6 Xác định phần tử Web theo CSS 11 1.5.2.7 Xác định phần tử Web theo Xpath 11 1.5.3 Các thư viện cần thiết để chạy Selenium WebDriver 12 1.5.4 Các hàm xử lý chung Selenium WebDriver 12 1.6 Page Object Model (POM) 13 1.6.1 Tại phải dùng POM 13 1.6.2 Page Object gì? 13 1.6.3 Lợi ích Page Object 13 Chương 2: HỆ THỐNG QUẢN LÝ TESTCASE – TESTLINK VÀ HỆ THỐNG TÍCH HỢP LIÊN TỤC 14 2.1 Hệ thống quản lý testcase - TestLink 14 2.1.1 Giới thiệu TestLink 14 2.1.2 Lợi ích TestLink .14 2.1.3 Các bước cài đặt TestLink 14 2.1.4 Kết hợp TestLink kiểm thử tự động 14 2.2 Hệ thống tích hợp liên tục (CI) 15 2.2.1 Khái niệm 15 2.2.2 Thực tiễn hệ thống tích hợp liên tục (Practices of Continuous Integration) 16 2.2.3 Lợi ích việc tích hợp liên tục 16 2.2.4 Jenkin 17 Chương 3: ÁP DỤNG KIỂM THỬ TỰ ĐỘNG TẠI CÔNG TY EXOPLATFORM SEA VÀ ĐÁNH GIÁ KẾT QUẢ 18 3.1 Phân tích hoạt động kiểm thử cơng ty trước áp dụng kiểm thử tự động 18 3.1.1 Giới thiệu tổng quan công ty, sản phẩm, môi trường kiểm thử công ty 18 3.1.2 Quy trình kiểm thử hoạt động kiểm thử trước 18 3.2 Cài đặt áp dụng kiểm thử tự động trình phát triển 19 3.2.1 Cấu trúc dự án 19 3.2.2 Cấu trúc mã nguồn 20 3.2.3 Tích hợp Jenkins 20 3.2.4 Report kết chạy test 21 3.3 Đánh giá kết 22 3.4 Những khó khăn triển khai hệ thống kiểm thử tự động công ty 22 3.5 Hướng phát triển framework 22 KẾT LUẬN 23 Chương 1: TỔNG QUAN VỀ BDD - CUCUMBER - SELENIUM - PAGE OBJECT 1.1 Tổng quan kiểm thử phần mềm ● ● Kiểm thử phần mềm giai đoạn quy trình phát triển phần mềm để đảm bảo độ tin cậy chất lượng phần mềm Các mục tiêu kiểm thử phần mềm : ○ Phát nhiều lỗi tốt thời gian kiểm thử xác định trước ○ Chứng minh sản phẩm phần mềm phù hợp với đặc tả yêu cầu ○ Xác thực chất lượng kiểm thử phần mềm dùng chi phí nỗ lực tối thiểu ○ Tạo kịch kiểm thử (testcase) chất lượng cao, thực kiểm thử hiệu tạo báo cáo vấn đề ₫úng hữu dụng 1.2 TDD (Test Driven Development) 1.2.1 TDD gì? ● Phát triển hướng kiểm thử TDD (Test-Driven Development) phương pháp triển kết hợp phương pháp Phát triển kiểm thử trước (Test First Development) phương pháp Điều chỉnh lại mã nguồn (Refactoring) Hình 1.1 Chu trình TDD qua màu sắc (từ trang 1minus1.com) 1.2.2 Ba điều luật áp dụng TDD ● ● ● Không cho phép viết mã chương trình làm test bị fail trở nên pass Không cho phép viết nhiều unit test mà cần unit test cung đủ để fail Hãy chuyển sang viết code function để pass test trước Khơng cho phép viết nhiều mã chương trình mà đủ làm test bị fail chuyển sang pass 1.2.3 Các bước thực chu trình TDD Hình 1.2 Các bước thực TDD 1.2.4 Các cấp độ TDD ● Mức chấp nhận (Acceptance TDD (ATDD)): hay gọi Behaviour Driven Development (BDD) Ta viết acceptance test hay đặc tả hành vi viết xử lý để đáp ứng test Thường mức đặc tả yêu cầu khách hàng Hay gọi nôm na Thoả mãn khách hàng ● Mức lập trình (Developer TDD): thường gọi ngắn gọn Test Driven Development, tương đương với mức unit test, thường mức xử lý chi tiết thiết kế chương trình Vậy nên, thực chất BDD loại TDD, người ta thường gọi Developer TDD TDD 1.3 BDD (Behaviour Driven Development) 1.3.1 Khái niệm ● BDD trình phát triển phần mềm dựa kiểm thử hướng hành vi BDD quy định developer product owner cần hợp tác xác định hành vi người sử dụng BDD sinh hướng tới feature test mà người thực Acceptance Tester Hình 1.3 TDD kết hợp với BDD Hình 1.4 Work flow kết hợp TDD BDD 1.3.2 Quy trình phát triển phần mềm truyền thống Hình 1.5 Quy trình phát triển truyền thống 1.3.3 Quy trình phát triển theo hướng BDD Hình 1.6 Quy trình phát triển BDD 1.4 Cucumber 1.4.1 Khái niệm ● ● ● Cucumber công cụ kiểm thử tự động dựa việc thực thi chức mô tả dướng dạng plain-text, mục đích để hỗ trợ cho việc viết BDD Cucumber hỗ trợ viết hành vi kiểm thử cho khoảng 60 ngôn ngữ khác (Ngôn ngữ Gherhin) Các plain-text đọc mã nguồn viết nhiều ngôn ngữ Java, Net, Python 1.4.2 Ngôn ngữ Gherkin ● ● Cucumber thực thi feature file Các feature files chứa đặc tả (step) thực thi, step viết ngôn ngữ Gherkin Gherkin ngôn ngữ mà Cucumber đọc ngôn ngữ chuyển thành test Gherkin dễ hiểu, người đọc hiểu kịch hành động mà không cần biết chi tiết chúng cài đặt 1.4.3 Chạy Cucumber Junit test 1.4.4 Chu trình Hình 1.7 Chương trình chạy test với Cucumber ● ● ● ● Mô tả lại hành vi dạng plain-text (sử dụng ngôn ngữ Gherhin) Định nghĩa step Chạy test xem test fail Viết code làm cho step pass ● ● Chạy lại test xem step pass Lặp lại bước đến toàn step pass 1.4.5 Sơ đồ workflow xử lý steps cucumber Hình 1.8 Workflow Cucumber 1.4.6 Cấu trúc dự án cài đặt Cucumber Hình 1.9 Cấu trúc dự án cài đặt Cucumber 1.4.7 Các thư viện cần thiết để chạy Cucumber ● Danh sách thư viện Cucumber cần cài đặt Hình 1.10 Thư viện Cucumber cần cài đặt 1.5 Selenium WebDriver Trong phần trước, tơi trình bày khái niệm TDD, BDD việc sử dụng Cucumber cho phát triển BDD Công cụ Cucumber hỗ trợ cho kiểm thử viên lập trình viên mơ tả hành vi người dùng dạng ngôn ngữ tự nhiên Ngôn ngữ tự nhiên giúp toàn thành viên đội phát triển khách hàng có nhìn chung hệ thống mà không cung cấp thư viện để thao tác với thành phần giao diện Web Câu hỏi đặt làm để thao tác với thành phần Web để tái lại hành vi người dùng mô tả Cucumber Selenium WebDriver làm điều Đây cơng cụ mã nguồn mở, hồn tồn miễn phí cung cấp đầy đủ thư viện thao tác ứng dụng Web Framework kiểm thử tự động em xây dựng thiếu Cucumber định khơng thể thiếu Selenium WebDriver Do đó, nói Selenium WebDriver thành phần cốt lõi framework 1.5.1 Selenium WebDriver ● Selenium WebDriver công cụ kiểm thử tự động ứng dụng Web 1.5.2 Tổng quan đối tượng UI (Locators) ● Trong selenium, phần tử web (WebElement) có vai trị quan trọng Selenium hỗ trợ người dùng cách để xác định phần tử web (Locator) 1.5.2.1 Xác định phần tử Web theo ID 1.5.2.2 Xác định phần tử Web theo Name 1.5.2.3 Xác định phần tử Web theo LinkText 1.5.2.4 Xác định phần tử Web theo TagName 1.5.2.5 Xác định phần tử Web theo ClassName 1.5.2.6 Xác định phần tử Web theo CSS 1.5.2.7 Xác định phần tử Web theo Xpath ● ● ● ● ● Xpath việc sử dụng biểu thức để duyệt node XML/HTML XPath phương thức sử dụng nhiều Dưới ví dụ cấu trúc HTML trang web cách dùng Xpath để duyệt phần tử trang web Absolute XPath (XPath tuyệt đối) ○ Bắt đầu với node gốc dấu ‘/’ ○ Ưu điểm: tìm element nhanh ○ Nhược điểm: có thay đổi node xpath sai ○ Ví dụ: html/body/div/form/select/option ○ Khi có thêm tag body divà xpath khơng tìm element html/body/table/div/form/select/option Relative XPath (XPath tương đối) ○ Có thể bắt đầu node với dấu ‘//’ ○ Ưu điểm: xpath ngắn ● ○ Nhược điểm: tìm element lâu xpath tuyệt đối ○ Ví dụ: //select/option Kết hợp xpath tuyệt đối, tương đối ○ Có thể kết hợp xpath tuyệt đối tương đối ○ Ví dụ: html//table/tbody/tr/th 1.5.3 Các thư viện cần thiết để chạy Selenium WebDriver ● Danh sách thư viện Selenium WebDriver cần cài đặt Hình 1.11 Thư viện cần thiết để chạy Selenium WebDriver ● Sử dụng Maven để cài đặt thư viện 1.5.4 Các hàm xử lý chung Selenium WebDriver ● Locate element sử dụng WebDriver By.className value class attribute findElement(By.className("someClassName")) By.cssSelector locator css findElement(By.cssSelector("input#email")) By.id value id attribute findElement(By.id("someId")) By.linkText locator value findElement(By.linkText("REGISTRATION")) By.tagName name tag findElement(By.tagName("div")) By.xpath locator xpath findElement(By.xpath("//html/body/div") By.name value name attribute findElement(By.name("someName")) ● Các hàm hay sử dụng init webdriver WebDriver driver = new FirefoxDriver(); open url driver.get(baseUrl); init webelement WebElement element=driver.findElement(By.className("someClassName")) click an element driver.findElement(By.className("someClassName")).click() type text to textbox driver.findElement(By.className("someClassName")).sendkey(“test”) refresh current page driver.navigate().refresh() back page driver.navigate().back() forward page driver.navigate().forward() close browser driver.close() or driver.quit() pause Thread.sleep(5000); 1.6 Page Object Model (POM) 1.6.1 Tại phải dùng POM Page Object Model (POM) làm cho mã nguồn dễ đọc hơn, dễ bảo trì dễ sử dụng lại Hình 1.12 Cấu trúc POM 1.6.2 Page Object gì? ● POM mẫu thiết kế (Design Pattern) có đặc điểm sau: ○ Tạo Kho đối tượng (object repository) cho phần tử giao diện web (UI elements) ○ Dưới mơ hình này, trang web ứng dụng viết tương ứng với lớp ○ Lớp tìm kiếm tất phần tử web (WebElements) chứa phương thức để thực thao tác phần tử trang web ○ Các phương thức nên đặt tên nhiệm vụ (task) mà chúng thực Nó dễ dàng ánh xạ với hành động (actions) xảy giao diện với người dùng Ví dụ, Nếu muốn nhập user cho textbox user trang, tên phương thức “setUserName” 1.6.3 Lợi ích Page Object ● ● Làm cho code trở nên rõ ràng dễ hiểu hơn, tránh lặp lại nhiều lần code Do đó, Mơ hình trở nên dễ dàng việc bảo trì tái sử dụng Các kho lưu trữ độc lập với kịch test Vì vậy, sử kho lưu trữ giống cho mục đích khác với tool khác Ví dụ, chũng ta tích hợp POM với TestNG cho việc test chức hay Cucumber cho Acceptance Test (Kiểm thử chấp nhận) Chương 2: HỆ THỐNG QUẢN LÝ TESTCASE – TESTLINK VÀ HỆ THỐNG TÍCH HỢP LIÊN TỤC 2.1 Hệ thống quản lý testcase - TestLink 2.1.1 Giới thiệu TestLink ● ● ● Testlink công cụ quản lý test case sử dụng rộng rãi dựa mã nguồn mở Nó kết hợp đồng thời hai requirements specification Test specification Công cụ hỗ trợ người dùng tạo test project kịch kiểm thử Ta tạo tài khoản cho nhiều người dùng assign quyền người dùng khác Testlink hỗ trợ hai thực test case tay tự động thực thi test case Với tool người kiểm thử sử dụng để xuất file test report tài liệu Test plan phút Nó hỗ trợ xuất file Test report MS Word, Excel, HTML formats 2.1.2 Lợi ích TestLink ● ● ● ● ● ● ● Hỗ trợ nhiều project Dễ dàng import export test case Dễ dàng tích hợp với nhiều tool quản lý defect Tự động thực test case thông qua XML-RPC Dễ dàng lọc test case theo keywords, version testcase ID Dễ dàng để assign test case tới nhiều user Dễ dàng xuất test plan, test report Hình 2.1 Giới thiệu TestLink 2.1.3 Các bước cài đặt TestLink ● Xem thêm phụ lục (Cài đặt môi trường) - Cài đặt công cụ quản lý test case - TestLink) 2.1.4 Kết hợp TestLink kiểm thử tự động ● Để selenium giao tiếp với TestLink, TestLink cung cấp chức giúp người dùng tạo API key cho phép người dùng xác thực quyền truy cập vào TestLink ● Sau thực chạy test selenium/cucumber, ta cập nhật kết chạy test vào TestLink với hàm sau: Hình 2.2 Báo cáo TestLink 2.2 Hệ thống tích hợp liên tục (CI) 2.2.1 Khái niệm ● ● Tích hợp liên tục hoạt động phát triển phần mềm mà thành viên nhóm tích hợp cơng việc họ với liên tục, thường thành viên tích hợp cơng việc theo ngày, dẫn đến có nhiều tích hợp ngày Mỗi tích hợp kiểm tra công cụ build tự động (bao gồm test) để phát lỗi tích hợp sớm tốt Hiểu đơn giản, tích hợp liên tục gồm bước Hình 2.3 Quá trình tích hợp liên tục CI ● Dưới hệ thống tích hợp liên tục Hình 2.4 Hệ thống tích hợp liên tục 2.2.2 Thực tiễn hệ thống tích hợp liên tục (Practices of Continuous Integration) ● ● ● ● ● ● ● ● Quản lý source code Tự động hóa quy trình build ○ Q trình build thực tự động đoạn script cài sẵn ○ Thực thường xuyên ○ Tạo script khác để chạy nhiều mơi trường khác ○ Công cụ: Ant, Maven Tạo build bao gồm test ○ Chèn test vào chương trình ○ Nhận dạng source code có khả phát sinh lỗi (test code) ○ Công cụ: JUnit, HtmlUnit Commit thay đổi ngày Lấy source code nơi lưu trữ (mainline) Mỗi code có thay đổi build lại (mainline) thông qua build server Kiểm thử tự động ○ Được thực đoạn script viết sẵn ○ Thực sau build xong ○ Thực trình developer build máy họ vào lúc CI server build mainline Báo cáo kết cho lập trình viên thành viên liên quan 2.2.3 Lợi ích việc tích hợp liên tục ● ● ● ● Giảm thiểu rủi ro Dễ lập kế hoạch Dễ dàng phát loại bỏ lỗi Nhận phản hồi nhanh 2.2.4 Jenkin ● ● Jenkins công cụ đại diện cho khái niệm CI (continuous integration) Jenkins cung cấp giao diện trực quan hơn, percentage, graph, coverage report, code convention checking ,v.v… hoàn tồn tự động, wake up theo svn git Jenkins có nhiều plugin support hầu hết test framework Hình 2.5 Giao diện Jenkins Chương 3: ÁP DỤNG KIỂM THỬ TỰ ĐỘNG TẠI CÔNG TY EXOPLATFORM SEA VÀ ĐÁNH GIÁ KẾT QUẢ 3.1 Phân tích hoạt động kiểm thử công ty trước áp dụng kiểm thử tự động 3.1.1 Giới thiệu tổng quan công ty, sản phẩm, môi trường kiểm thử công ty ● ● ● eXo Platform công ty phần mềm cung cấp Platform bao gồm nhiều ứng dụng dành cho doanh nghiệp, Quản Lý Hồ Sơ Cá Nhân, Lưu Trữ Chia Sẻ Tài Liệu (ECMS), Calendar, (Social), Wiki, Forums, FAQs, Answer, Chat, Video call … Công ty liên tục phát triển feature để phục vụ cho yêu cầu xu hướng khách hàng Sản phẩm công ty ứng dụng web, chạy nhiểu môi trường khác (windows, Ubuntu, Android, IOS …) Hàng năm, cơng ty ln có kế hoạch cải tiến sản phẩm feature đồng thời tạo sản phẩm feature Mỗi sản phẩm hay feature xuất thị trường, sản phẩm feature sản phẩm feature cũ phải tiến hành kiểm thử môi trường mà sản phẩm hỗ trợ Các ứng dụng phát triển cài đặt môi trường khác ○ Hệ điều hành: Windows, Ubuntu, Android, IOS … ○ Browser: IE, Firefox, Chrome … ○ Database: MySQL, HSQL, Oracle, PSQL … ○ Triển khai sản phẩm: Tomcat, Jboss, Cloud, Cluster … 3.1.2 Quy trình kiểm thử hoạt động kiểm thử trước ● Các giai đoạn cần kiểm thử sản phẩm: ○ Số lượng kịch kiểm thử cho ứng dụng (như ECMS, Calendar, Wiki, Forums, FAQ …) giao động từ 100 đến khồng 1000 trường hợp kiểm thử cho môi trường Dưới số thống kê số lượng kịch kiểm thử vài chức hệ thống Số lượng tính theo mơi trường (Ví dụ: môi trường Ubuntu+Firefox+MySQL+Tomcat) Feature Số lượng testcase Wiki 342 Gatein 235 PLF 795 Forum 283 ECMS 1132 Calendar 455 Social 620 ● ● ● ● Để kiểm thử cho tất ứng dụng, hệ điều hành, trình duyệt sở liệu khác nhau, số lượng kịch kiểm thử lớn Bên cạnh feature phải tiến hành kiểm thử song song với feature cũ Có thể thấy nguồn lực cho kiểm thử hồi quy (Regression test) kiểm thử cho feature lớn Ngồi ra, cơng ty sử dụng CI để deploy sản phẩm hàng ngày Để phát sớm vấn để sản phẩm, kiểm thử tự động tích hợp CI để test sản phẩm hàng ngày Từ lợi ích BDD-Cucumber-Selenium-TestLink-CI, tơi bạn đồng nghiệp xây dựng Framework tích hợp điểm mạnh BDD-Cucumber-Selenium-TestLink-CI để hỗ trợ trình kiểm thử, build dự án, phát hành sản phẩm với chất lượng tốt Dưới kết cài đặt, chạy thử đánh giá kết framework Do quy định luật bảo mật dự án quy định vê luật bảo mật công ty, không sử dụng mã nguồn chi tiết dự án triển khai công ty mà sử dụng mã nguồn viết để kiểm thử trang web application (live.guru99.com) Tuy nhiên cấu trúc dự án, cấu trúc mã nguồn kết đánh giá dựa vào dự án thực tế triển khai 3.2 Cài đặt áp dụng kiểm thử tự động trình phát triển 3.2.1 Cấu trúc dự án Hình 3.1 Cấu trúc dự án thực tế 3.2.2 Cấu trúc mã nguồn Hình 3.2 Cấu trúc mã nguồn cài đặt thực tế ● Mã nguồn dự án: https://github.com/phuongdt/auto-project.git 3.2.3 Tích hợp Jenkins Dự án có sử dụng Maven để chạy test tích hợp Selenium/Cucumber Jenkins TestLink 3.2.4 Report kết chạy test ● Cucumber report Hình 3.3 Cucumber Report ● Thucydides report Hình 3.4 Thucydides report ● TestLink report Hình 3.5.TestLink report 3.3 Đánh giá kết ● ● Hiện viết kịch kiểm thử cho khoảng 50% số lượng kịch kiểm thử áp dụng chạy thử cho vài giai đoạn kiểm thử Dưới bảng thống kê nguồn nhân lực Số lượng testcase Kiểm thử thủ công Kiểm thử tự động 820 60 cases/manday 2-3 manday  Cần 14 manday để chạy test ● Từ kết ta thấy kiểm thử tự động giúp giảm bớt nguồn nhân lực q trình kiểm thử 3.4 Những khó khăn triển khai hệ thống kiểm thử tự động cơng ty ● ● ● ● Việc tìm nhân lực vừa có kỹ kiểm thử vừa có kỹ lập trình gặp khó khăn nhiều bạn nhân viên kiểm thử có kỹ kiểm thử tốt tư lập trình khơng tốt, bạn có kỹ lập trình tốt khơng muốn làm kiểm thử Khi feature có nhiều thay đổi cách tổ chức UI nhiều thời gian để maintain mã nguồn framework Kiểm thử tự động có hiệu cao dự án dài, có regression test nhiều Các dự án ngắn, địi hỏi release sớm việc triển khai kiểm thử tự động không hiệu Hệ thống chạy ổn định firefox chrome, số lỗi chạy IE việc xử lý IE Firefox có số điểm khác 3.5 Hướng phát triển framework ● ● Xây dựng thêm phần DataDriven framework DataDriven giúp cho hệ thống đọc liệu đầu vào từ hệ thống quản lý file từ hệ quản trị sở liệu Cải tiến framework để hỗ trợ cho bạn kiểm thử khơng có kỹ lập trình sử dụng dễ dàng KẾT LUẬN Trong trình tìm hiểu nghiên cứu, luận văn đưa khái niệm hướng áp dụng Selenium công cụ liên quan khác kiểm thử phần mềm Dựa vào kết nghiên cứu áp dụng kiểm thử tự động công ty Exo Platform Sea, thấy việc ứng dụng selenium công cụ liên quan dự án phần mềm hoàn toàn khả thi Do thời gian có hạn, tơi đưa framework để áp dụng chạy thử nghiệm ln, framework cịn nhiều phần cần phải cải tiến cập nhật thêm (ví dụ: DataDriven, Dynamic Locator, tốc độ chạy kịch kiểm thử, tích hợp thành cloud test) Việc cải tiến framework nghiên cứu cập nhật thời gian tới  ... sử dụng dễ dàng KẾT LUẬN Trong trình tìm hiểu nghiên cứu, luận văn đưa khái niệm hướng áp dụng Selenium công cụ liên quan khác kiểm thử phần mềm Dựa vào kết nghiên cứu áp dụng kiểm thử tự động. .. Chương 3: ÁP DỤNG KIỂM THỬ TỰ ĐỘNG TẠI CÔNG TY EXOPLATFORM SEA VÀ ĐÁNH GIÁ KẾT QUẢ 3.1 Phân tích hoạt động kiểm thử cơng ty trước áp dụng kiểm thử tự động 3.1.1 Giới thiệu tổng quan công ty, sản... viết kịch kiểm thử cho khoảng 50% số lượng kịch kiểm thử áp dụng chạy thử cho vài giai đoạn kiểm thử Dưới bảng thống kê nguồn nhân lực Số lượng testcase Kiểm thử thủ công Kiểm thử tự động 820