Tên ngắn gọn, súc tích

Một phần của tài liệu (LUẬN văn THẠC sĩ) nghiên cứu và ứng dụng kiểm thử chấp nhận tự động với robot framework (Trang 33)

Đối với từ khóa (Keyword), tên cũng cần đƣợc mô tả rõ ràng. Tên từ khóa cần đặt sao cho thể hiện đƣợc thông tin từ khóa đó làm gì, không cần mô tả nó làm nhƣ thế nào. Ví dụ, nên đặt là “Login With Valid Credentials” thay vì “Input Valid Username And Valid Password And Click Button”.

Đối với setup và teardown, tên nên đặt sao cho mô tả đƣợc cái nó thực hiện. Nhiều tên trừu tƣợng chấp nhận đƣợc nếu một setup/teardown bao gồm các bƣớc sau. Các bƣớc liệt kê trong tên là trùng lặp và một vấn đề bảo dƣỡng (Listing steps in name is duplication and a maintenance problem), ví dụ nhƣ: Login to system, add user, activate alarms and check balance. Hay, cần sử dụng cái gì đó chung, nhƣ: Initialize system. Một ngƣời làm việc với các ca kiểm thử luôn luôn cần hiểu những gì một setup / teardown làm.

3.4.6.2. Tài liệu hướng dẫn

Tài liệu hƣớng dẫn đối với bộ kiểm thử, thƣờng một ý tƣởng tốt là bổ sung tài liệu tới các bộ kiểm thử ở mức thấp nhất có chứa các ca kiểm thử. Các bộ ở mức cao hơn thì không cần. Tài liệu nên chứa các thông tin cơ bản

nhƣ, tại sao bài kiểm tra đƣợc tạo ra, những lƣu ý về môi trƣờng thực hiện. Tài liệu không nên chỉ là nhắc lại tên của bộ kiểm thử đó. Nó không nên chứa quá nhiều chi tiết về các ca kiểm thử. Các bài kiểm thử cần đƣợc rõ ràng và đủ để hiểu. Các thông tin trùng lặp là lãng phí và vấn đề bảo trì. Tài liệu có thể chứa các liên kết đến nhiều tài liệu khác. Xem xét sử dụng bộ kiểm thử siêu dữ liệu nếu cần tài liệu thông tin đại diện là name – value, minh họa nhƣ Hình 3.11. Và, nếu không thật cần thiết thì tài liệu hƣớng dẫn này có thể bỏ qua.

Hình 3.11. Tài liệu hướng dẫn của một bộ kiểm thử

Tài liệu hƣớng dẫn đối với ca kiểm thử thƣờng là không cần thiết. Tên và tài liệu hƣớng dẫn của bộ kiểm thử và tên của ca kiểm thử nên cung cấp đủ thông tin cơ bản. Cấu trúc của ca kiểm thử nên đƣợc rõ ràng đủ để không cần tài liệu hƣớng dẫnhay ý kiến nào khác. Các thẻ nói chung là linh hoạt hơn và cung cấp nhiều chức năng hơn là tài liệu hƣớng dẫn, minh họa Hình 3.12. Tuy nhiên,đôi khi tài liệu kiểm thử rất hữu ích, có thể sử dụng, minh họa Hình 3.13.

Hình 3.13. Test case có chứa tại liệu hướng dẫn.

Tài liệu hƣớng dẫn từ khóa ngƣời dùng là không cần thiết nếu đơn giản, tên tốt và cấu trúc rõ ràng là đủ. Sử dụng quan trọng là tài liệu lý luận và giá trị trả lại.

3.4.6.3. Cấu trúc

Trong một bộ kiểm thử, các ca kiểm thử là liên quan đến nhau, có cùng setup/teardown. Trong một bộ kiểm thử không nên có quá nhiều ca kiểm thử, tối đa là mƣời ca trên một bộ. Các bộ kiểm thử dựa trên hƣớng dũ liệu có thể là ngoại lệ. Các ca kiểm thử tong một bộ nên độc lập với nhau trừ phần setup/teardown.Tuy nhiên vẫn khó tránh đƣợc một số trƣờng hợp phụ thuộc vào nhau. Nhƣ, thời gian để khởi tạo setup/teardown cho tất cả các ca kiểm thử riêng biệt là khá lớn. Các ca kiểm thử phụ thu vào nhau không nên quá dài. Để xem xét, xác nhận tình trạng của các ca kiểm thử trƣớc, sử dụng biến ${PREV TEST STATUS}.

Với ca kiểm thử, cấu trúc nên dễ hiểu. Một ca kiểm thử chỉ nên kiểm tra một thứ, nhƣ một phần của tính năng đơn, hay lớn hơn là end- to- end. Nên chọn mức độ trừu tƣợng thích hợp. Mức độ trừu tƣợng ngƣời dùng – mức thấp nhất của quy tắc trừu tƣợng. Cấu trúc chỉ nên bao gồm thông tin liên quan đến ca kiểm thử. Cấu trúc của ca kiểm thử thƣờng có hai loại: kiểm thử luồng công việc (Workflow tests) và kiểm thử hƣớng dữ liệu.

Với kiểm thử luồng công việc, thƣờng đƣợc chia ra thành các giai đoạn. Đầu tiên là các điều kiện tiên quyết nhƣ các tùy chọn, thƣờng nằm trong thiết lập setup. Tiếp đến là các hành động cho biết làm những gì với hệ thống, cần xác minh phải có một. Giai đoạn cuối là làm sạch các tùy chọn, nên đặt chúng trong teardown để chắc chắn nó đƣợc thực hiện. Các từ khóa

trong ca kiểm thử phải mô tả đƣợc cái mà bài kiểm thử muốn thực hiện. Từ khóa đƣợc sử dụng cần có tên rõ ràng và mức độ trừu tƣợng chấp nhận đƣợc. Các từ khóa nên chứa đủ thông tin để có thể chạy bằng tay, không cần tài liệu đi kèm hoặc phản hồi (comment) để giải thích cái mà bài kiểm thử thực hiện. Các bài kiểm thử có thể có mức độ trừu tƣợng khác nhau. Kiểm thử cho một chức năng chi tiết chính xác hơn. Kiểm thử end to end có thể thực hiện ở mức rất cao. Một bài kiểm thử chỉ nên sử dụng một mức trừu tƣợng. Các ca kiểm thử loại này không có cấu trúc phức tạp, không có cấu trúc lặp hay cấu trúc if/else, sử dụng lệnh gán cẩn thận. Mỗi ca kiểm thử có không quá mƣời bƣớc.

Với kiểm thử dựa vào dữ liệu, một từ khóa ở mức cao cho một ca kiểm thử, các tham số khác nhau tạo ra các ca kiểm thử khác nhau, từ khóa thƣờng chứa luồng công việc giống nhƣ kiểm thử luồng công việc và đƣợc tạo ra trong cùng tập tin ca kiểm thử. Nó đƣợc khuyến khích sử dụng chức năng mẫu kiểm thử, không cần lặp lại nhiều lần từ khóa, dễ hơn trong việc kiểm tra nhiều biến thể trong một bài kiểm tra. Và, nếu một số thực lớn các ca kiểm tra là cần thiết, nên xem xét tạo ra chúng dựa trên một mô hình bên ngoài. Hình 3.14 là một minh họa xây dựng ca kiểm thử dựa vào dữ liệu.

Hình 3.14. Kiểm thử dựa vào dữ liệu

3.4.6.4. Từ khóa người dùng và các biến

Từ khóa ngƣời dùng nên dễ hiểu, các quy tắc giống nhƣ kiểm thử luồng dữ liệu, các mức trừu tƣợng khác nhau. Nó có thể chứa các cấu trúc lập trình logic nhƣ vòng lặp, cấu trúc if/else, đặc biệt là các từ khóa ở mức thấp, nhƣng những logic phức tạp này nằm ở các thƣ viện xây dựng sẵn hơn là ở mức ngƣời dùng.

Các biến thƣờng phức tạp hoặc đóng gói có giá trị lâu dài, dùng để truyền thông tin từ dòng lệnh hoặc truyền thông tin giữa các từ khóa. Về cách đặt tên biến, tên biến cần đặt rõ ràng nhƣng không quá dài, có thể sử dụng các ý kiến, nhận xét (comment) trong bảng Variables để hiểu rõ hơn. Tên biến nên đƣợc đặt theo quy tắc nhất định. Biến đặt bằng các kí tự in thƣờng dùng cho biến địa phƣơng chỉ có sẵn bên trong các ca kiểm thử nhất định hoặc từ khóa. Biến đặt bằng các kí tự in hoa dùng cho biến toàn cục, hay ở mức bộ kiểm thử, mức kiểm thử. Cả khoảng trống và dấu gạch dƣới đƣợc sử dụng cho việc tách từ. Nên liệt kê các biến mà đƣợc thiết lập tự động trong bảng Variables. Thiết lập thƣờng đƣợc sử dụng cho các từ khóa biến toàn cục, biến bộ kiểm thử và biến ca kiểm thử. Giá trị ban đầu của biến nên đƣợc giải thích ở đâu, khi nào giá trị thực của biến đƣợc thiết lập. Hình 3.15 là một ví dụ về tên biến. Giá trị truyền qua và trả về của các biến, phƣơng pháp phổ biến nhất là trả về giá trị từ các từ khóa, minh họa Hình 3.16, giao cho các biến và sau đó truyền kết quả qua chúng nhƣ các đối số cho các từ khóa khác. Cách tiếp cận này rõ ràng, dễ tiếp cận và trông giống nhƣ một chƣơng trình. Một phƣơng pháp tiếp cận khác là sử dụng từ khóa thiết lập biến kiểm thử (Set Test Variable), minh họa Hình 3.17. Với cách tiếp cận này, không cần có bất kỳ phong cách lập trình nào trong mức ca kiểm thử, không phức tạp để làm theo, khả năng tái sử dụng các từ khóa khó, tránh dƣới mức ca kiểm thử.

Hình 3.16. Giá trị trả về của biến thông qua từ khóa

CHƯƠNG 4. ỨNG DỤNG ROBOT FRAMEWORK VÀO KIỂM THỬ TRANG WEB

Trong chƣơng này tôi sẽ mô tả việc ứng dụng Robot Framework vào thực tế. Phần mềm tôi áp dụng là phần mềm trên nền web đang chạy ở trang web http://truongnha.com. Tôi sẽ mô tả chức năng bài toán vàhƣớng dẫn tạo kịch bản kiểm thử trong Robot Framework.

4.1.Mô tả bài toán

Hệ thống đƣợc kiểm thử trong luận văn này là ứng dụng http://truongnha.com.Hình 4.1 là hình ảnh trang chủ của ứng dụng.

Trong khuôn khổ luận văn này, tôi sẽ kiểm thử chức năng đăng nhập, báo cáo và đăng xuất với hệ thống http://truongnha.com.

Chức năng đăng nhập của hệ thống cần đảm bảo những điều sau. Ngƣời dùng gõ đúng vào hai trƣờng tên đăng nhập và mật khẩu sau đó nhấn đăng nhập thì đăng nhập vào hệ thống thành công. Nếu ngƣời dùng gõ tên đăng nhập hoặc mật khẩu sai hoặc hai trƣờng để trống thì đăng nhập thất bại.

Chức năng báo cáo, sẽ kiểm tra chức năng báo cáo sổ gọi tên ghi điểm, và báo cáo phiếu báo điểm. Ngƣời dùng có khả năng vào đƣợc các mục này để tải dữ liệu về.

Cuối cùng là chức năng đăng xuất, khi không muốn làm việc với hệ thống ứng dụng nữa, ngƣời dùng phải có khả năng thoát ra khỏi ứng dụng.

Thực hiện kiểm thử trên Robot Framework, cùng với thƣ viện mở rộng của nó SeleniumLibrary và công cụ hỗ trợ RIDE.

4.2. Kiểm thử chức năng đăng nhập

Dƣới đây, luận văn sẽ hƣớng dẫn hai cách xây dựng kịch bản để kiểm thử chức năng đăng nhập vào hệ thống ứng dụng.

4.2.1. Kịch bản kiểmthử xây dựngdựa trên từ khóa thông thường

Xây dựng bốn ca kiểm thử trong tập tin LoginTest.txt. Các ca kiểm thử thực hiện các công việc sau. Thứ nhất, ngƣời dùng gõ tên đăng nhập đúng và mật khẩu đúng sau đó nháy “Đăng nhập” thì hệ thống phải đăng nhập thành công. Thứ hai, ngƣời dùng gõ tên đăng nhập sai và mật khẩu đúng sau đó nháy “Đăng nhập” thì hệ thống phải đăng nhập không thành công. Thứ ba, ngƣời dùng gõ tên đăng nhập đúng và mật khẩu sai sau đó nháy “Đăng nhập” thì hệ thống cũng phải đăng nhập không thành công. Cuối cùng, ngƣời dùng để trống tên đăng nhập và mật khẩu sau đó nháy “Đăng nhập” thì hệ thống thất bại.

Kịch bản kiểm thử đƣợc xây dựng trên Robot Framework có sử dụng thƣ viện mở rộng SeleniumLibrary. Kịch bản kiểm thử đƣợc xây dựng trong tập tinLoginTest.txt, toàn bộ mã nguồn đƣợc trình bày ở phụ lục 1.

Dƣới đây xét đoạn kịch bản mô phỏng kiểm thử chức năng đăng nhập vào hệ thống thành công khi gõ đúng tên đăng nhập và mật khẩu.

1. *** Testcases ***

2. Login Should Succeed When the Correct Username and Password are Entered

3. Start Selenium Server

4. Open Browser http://truongnha.com/login/ GoogleChrome

5. Maximize Browser Window

6. Input Text id_username hientt 7. Input Text id_password hientt 8. Click Button login

9. Page Should Contain hientt 10. Close Browser

11. Stop Selenium Server

Trên đây là kịch bản của một ca kiểm thử, lần lƣợt từng dòng lệnh đƣợc phân thành các bƣớc với những mục đích: thiết lập (Setup), hành động (Action), xác minh (Verification), Teardown.

Dòng 1 : Dòng đầu tiên là tên bảng TestCases chứa một hoặc nhiều ca kiểm thử.

Dòng 2 : Tên của ca kiểm thử đƣợc sử dụng trong các báo cáo và các bản ghi.

Dòng 3: Thiết lập tác vụ, Server của Selenium đƣợc bắt đầu để nhận lệnh và kiểm soát trình duyệt.

Dòng 4: Thiết lập tác vụ, một trình duyệt đƣợc mở ra cho các trang nhất định, mặc định Firefox đƣợc sử dụng, có thể quy định sử dụng Internet Explorer hoặc Google Chrome. Trƣờng hợp này, Google Chrome đƣợc chọn, trang đƣợc mở là http://truongnha.com/login/.

Dòng 5: Thiết lập tác vụ, điều chỉnh mở hết cỡ trình duyệt. Theo mặc định, cửa sổ trình duyệt không đƣợc mở hết cỡ.

Dòng 6: Hành động kiểm thử, sử sụng từ khóa “Input Text” để nhập văn bản (text) vào trƣờng đƣợc xác định id của phần tử là “id_username” và văn bản cần nhập vào là “hientt”.

Dòng 7: Tƣơng tự dòng 6, là hành động kiểm thử, sử sụng từ khóa “Input Text” để nhập văn bản vào trƣờng đƣợc xác định id của phần tử là “id_password” và văn bản cần nhập vào là “hientt”.

Dòng 8: Là hành động kiểm thử nháy chuột vào nút đƣợc xác định bởi từ khóa “Click Button”. Đối số đƣợc truyền cho nó xác định bởi “login”.

Dòng 9: Xác nhận kiểm thử bởi từ khóa “Location Should Be”, nó sẽ kiểm tra url đang mở trên trình duyệt, nếu đúng thì ca kiểm thử sẽ qua.

Dòng 10: Thiết lập Teardown đóng trình duyệt. Dòng 11: Thiết lập Teardown tắt Selenium Server.

Tƣơng tự nhƣ kịch bản trên, ta xây dựng đƣợc kịch bản kiểm thử cho ca kiểm thử ngƣời dùng gõ tên đăng nhập đúng và mật khẩu sai sau đó nháy “Đăng nhập” thì hệ thống đăng nhập không thành công.

Login Should not Succeed When the Correct Username and Wrong Password

Start Selenium Server

Open Browser http://truongnha.com/login/ GoogleChrome

Maximize Browser Window

Input Text id_username hientt Input Text id_password demo Click Button login

Run Keyword And Expect Error * Page Should Contain hientt

Close Browser

Stop Selenium Server

Dƣới đây là kịch bản kiểm thử cho ca kiểm thử ngƣời dùng gõ tên đăng nhập sai và mật khẩu đúng sau đó nháy “Đăng nhập” hệ thống đăng nhập không thành công.

Login Should not Succeed When the Wrong Username and Correct Password

Start Selenium Server

Open Browser http://truongnha.com/login/ GoogleChrome

Maximize Browser Window

Input Text id_password hientt Click Button login

Run Keyword And Expect Error * Page Should Contain hientt

Close Browser

Stop Selenium Server

Cuối cùng, kịch bản kiểm thử cho ca kiểm thử ngƣời dùng để trống tên đăng nhập và mật khẩu sau đó nháy “Đăng nhập” hệ thống đăng nhập thất bại.

Login Should not Succeed When the Username and Password are Emty

Start Selenium Server

Open Browser http://truongnha.com/login/ GoogleChrome

Maximize Browser Window

Input Text id_username ${empty} Input Text id_password ${empty} Click Button login

Run Keyword And Expect Error * Page Should Contain hientt

Close Browser

Stop Selenium Server

Sau khi thực hiện chạy bộ kiểm thử “LoginTest” từ tệp “LoginTest.txt” thu đƣợc kết quả nhƣHình 4.2. Kết quảcho biết các thông tin cơ bản nhƣ: tên các ca kiểm thử thành công, tên các ca kiểm thử thất bại, tổng số các ca kiểm thử thực hiện, số luợng ca thành công, số lƣợng ca thất bại.

Hình 4.2. Kết quả sau khi chạy xong bộ LoginTest.

Kết quả báo cáo còn cung cấp tệp đầu ra có tên output.xml đƣợc minh họa ở Hình 4.3. Tập tin này cung cấp chi tiết các thông tin nhƣ phiên bản Robot sử dụng, phiên bản Python, loại hệ điều hành đƣợc dùng, đƣờng dẫn các tập tin dữ liệu kiểm thử v.v.

Hình 4.3. Tập tin đầu ra output.xml.

Tập tin báo cáo tổng quan bộ kiểm thử có tên log.html và minh họa Hình 4.4. Tập tin có chứa các thông tin nhƣ tên bộ kiểm thử, tên các ca kiểm thử, tổng số ca kiểm thử và số ca bị lỗi, thời gian bắt đầu, thời gian kết thúc và thời gian thực hiện của bộ kiểm thử, v.v.

Hình 4.4. Báo cáo tổng quan bộ kiểm thử.

Cuối cùng là tập tin report.html báo cáo tổng quan quá trình kiểm thử nhƣ Hình 4.5 và báo cáo chi tiết và Hình 4.6. Báo cáo cho biết tổng số ca kiểm thử, tên bộ kiểm thử, tên các ca kiểm thử, thời gian thực hiện của mỗi ca kiểm thử, thời gian bắt đầu và kết thúc của mỗi ca kiểm thử, thông điệp lỗi nếu có.

Hình 4.5. Báo cáo quá trình thực hiện kiểm thử.

4.2.2. Kịch bản kiểm thử xây dựng theo hướng dữ liệu

Phần này sẽ chuyển đổi các ca kiểm thử trong tập tin LoginTest.txt

dƣới dạng thƣ mục cũng đặt tên là AppTest.

Đầu tiên thiết lập setup/teardown cho bộ kiểm thử thay vì cho từng ca kiểm thử trong bảng Setting:

*** Settings ***

Library Selenium Library Suite Setup Start Selenium Server Suite Teardown Stop Selenium Server

Test Setup OpenBrowser http://truongnha.com/login/ GoogleChrome

Test Teardown Close Browsers

Khi đó số dòng lệnh của ca kiểm thử trong bảng Testcases đƣợc giảm đi tƣơng ứng:

*** Testcases ***

Login Should Succeed When the Correct Username and Password are Entered

Maximize Browser Window

Input Text id_username hientt Input Text id_password hientt Click Button login

Location Should Be hientt

Một phần của tài liệu (LUẬN văn THẠC sĩ) nghiên cứu và ứng dụng kiểm thử chấp nhận tự động với robot framework (Trang 33)

Tải bản đầy đủ (PDF)

(62 trang)