3.4.3. Các loại bảng dữ liệu kiểm thử
Dữ liệu kiểm thử đƣợc cấu trúc trong bốn loại bảng: Setting, Variable, Test case và Keyword.
Bảng Setting dùng nhập khẩu các thƣ viện kiểm thử, các tập tin tài nguyên, các tập tin biến, dùng để định nghĩa các siêu dữ liệu cho các bộ kiểm thử và các trƣờng hợp kiểm thử.
Bảng Variable dùng để định nghĩa các biến mà có thể sử dụng ở bất cứ nơi đâu trong dữ liệu kiểm thử.
Bảng Test case dùng để tạo ra các ca kiểm thử từ những từ khóa có sẵn trong các thƣ viện hoặc do ngƣời dùng tạo ra.
Bảng Keyword dùng để tạo các từ khóa ở mức ngƣời dùng từ những từ khóa ở mức thấp hơn đã tồn tại. Các từ khóa ở mức thấp này có thể nằm
trong các thƣ viện chuẩn, các thƣ viện mở rộng đã đƣợc xây dựng sẵn của Robot Framework.
3.4.4. Các quy tắc phân tích dữ liệu
Dữ liệu bị bỏ qua: Khi phân tích các dữ liệu kiểm thử , Robot Framework sẽ bỏ qua các dữ liệu sau. Tất cả các bảng mà không bắt đầu với một tên bảng đƣợc ghi nhận ở ô đầu tiên. Mọi phần tử trên hàng đầu tiên của một bảng ngoài trừ phần tử ở ô đầu, tất cả các dữ liệu trƣớc khi bảng đầu tiên đƣợc nhận dạng. Nếu định dạng dữ liệu cho phép dữ liệu giữa các bảng, cũng đƣợc Framework bỏ qua. Nó cũng bỏ qua tất cả các dòng trống đƣợc sử dụng để làm các bảng dễ đọc hơn, tất cả các ô trống ở cuối mỗi hàng, tất cả những dấu xổ ngƣợc (\), tất cả các ký tự theo sau kí tự thăng (#), khi nó là ký tự đầu tiên của một ô. Điều này có nghĩa rằng dấu thăng có thể đƣợc sử dụng để nhập các ý kiến trong các dữ liệu kiểm thử. Nó bỏ qua tất cả các dữ liệu định dạng HTML không phải là bảng trong dữ liệu kiểm thử.
Khi Robot khung bỏ qua một số dữ liệu, các dữ liệu này sẽ không có sẵn trong bất kỳ báo cáo kết quả nào. Thêm vào đó, hầu hết các công cụ đƣợc sử dụng với Robot khung cũng bỏ qua chúng.Vì vậy, muốn dữ liệu này tồn tại để hiển thị thông tin trong kết quả đầu ra của Framework, đặt nó vào văn bản tài liệu hoặc siêu dữ liệu khác của các ca kiểm thử hoặc bộ kiểm thử, hoặc nhập nó vào với các từ khóa trong thƣ viện Builtin là Log hoặc Comment.
Xử lý khoảng trắng: Robot Khung xử lý khoảng trắng theo cách giống nhƣ xử lý trong mã nguồn HTML. Dòng mới, dấu xuống dòng, và các tab đƣợc chuyển đổi thành khoảng trắng. Hàng đầu và dấu khoảng trắng trong tất cả các ô đều đƣợc bỏ qua. Nhiều khoảng trống liên tiếp đƣợc gộp vào một khoảng trống duy nhất. Bên cạnh đó, không gian không bị phá vỡ
(non-breaking) đƣợc thay thế bằng không gian bình thƣờng. Điều này giúp tránh phải debug lỗi khó khi một không gian không bị phá vỡ đƣợc vô tình sử dụng thay vì một không gian bình thƣờng. Nếu hàng đầu, hoặc khoảng trống liên tiếp là cần thiết, chúng phải đƣợc thoát ra. Dòng mới, dấu xuống dòng, các tab, và không gian không bị phá vỡ có thể đƣợc tạo ra bằng cách sử dụng trình tự thoát \ n, \ r, \ t, và \ xA0 tƣơng ứng.
Chia dữ liệu kiểm thử: Nếu có dữ liệu thì có thể đẩy dữ liệu xuống dòng dƣới cho phù hợp và dễ dàng trong soạn thảo các bài kiểm thử. Nó cho phép sử dụng dấu chấm lửng (...) để tiếp tục các dòng trƣớc đó. Trong bảng Test case và bảng dấu chấm lửng (…) phải đƣợc đặt trƣớc ít nhất một ô trống. Trong các bảng Settings và Variable có thể đƣợc đặt trực tiếp dƣới thiết lập hoặc tên biến. Trong tất cả các bảng, tất cả các ô trống trƣớc dấu chấm lửng đƣợc bỏ qua. Hình 3.5 dƣới đây minh họa dữ liệu nằm trên cùng một hàng chƣa đƣợc chia, và Hình 3.6 dữ liệu đã đƣợc chia xuống các dòng dƣới .
Hình 3.5. Dữ liệu kiểm thử khi chưa được chia.
Hình 3.6. Dữ liệu kiểm thử đã được chia.
3.4.5. Tạo các ca kiểm thử
Phần này mô tả cú pháp trƣờng hợp kiểm tra tổng thể. Tổ chức các trƣờng hợp thử nghiệm vào dãy phòng thử nghiệm bằng cách sử dụng kiểm
tra hồ sơ vụ án và thƣ mục thử nghiệm bộ phần mềm đƣợc thảo luận trong phần tiếp theo.
Phần này mô tả tổng quan cú pháp sinh ca kiểm thử. Tổ chức các ca kiểm thử vào bộ kiểm thử bằng cách sử dụng tập tin chứa các ca kiểm thử.
Các ca kiểm thử đƣợc xây dựng trong bảng Test case từ những từ khóa có sẵn. Từ khóa có thể đƣợc nhập khẩu từ các thƣ viện kiểm thử, các tập tin tài nguyên hoặc tạo ra trong bảng Keyword của chính tập tin chứa ca kiểm thử.Các từ khóa có thể sử dụng tham số khác nhau. Một từ khóa có thể không hoặc nhận nhiều tham số. Một trong các tham số có thể có giá trị mặc định.
Cột đầu tiên trong bảng Test case chứa tên của các ca kiểm thử. Một ca kiểm thử bắt đầu từ hàng với tên của ca kiểm thử đó cho tới hàng chứa tên của một ca kiểm thử khác hoặc đến hàng cuối của bảng. Cột thứ hai thƣờng là tên của các từ khóa. Một ngoại lệ cho quy tắc này là các biến thiết lập từ giá trị trả về từ khóa. Kể từ cột thứ hai và cũng có thể các cột tiếp theo sẽ chứa tên biến và tên một từ khóa đƣợc đặt sau chúng. Trong cả hai trƣờng hợp, các cột sau tên từ khóa có thể chứa tham số đến từ khóa cụ thể. Hình 3.7 là một minh họa.
Hình 3.7. Cú pháp của ca kiểm thử.
Tiếp theo, phần này sẽ trình bày thiết lập trong bảng Test case. Các ca kiểm thử có thể có các thiết lập của riêng chúng. Tên của thiết lập luôn nằm trong cột thứ hai của bảng ,đây là vị trí các từ khóa thƣờng đứng nếu không có thiết lập, giá trị của chúng nằm trong các cột tiếp theo. Tên thiết lập phải nằm trong dấu ngoặc vuông để phân biệt chúng với các từ khóa. Các thiết lập có sẵn đƣợc liệt kê trong Bảng 3.2 dƣới đây và giải thích trong phần sau.
Bảng 3.2. Các thiết lập sẵn
[Documentation] Đƣợc sử dụng để chỉ một tài liệu ca kiểm thử cụ thể. [Tags] Đƣợc sử dụng cho việc gắn thẻ các ca kiểm thử.
[Setup], [Teardown] Xác định Setup và Teardown cho các ca kiểm thử cụ thể.
[Template] Chỉ định từ khóa mẫu để sử dụng. Chính các ca kiểm thử sẽ chỉ chứa dữ liệu để sử dụng nhƣ các đối số đến từ khóa đó.
[Timeout] Đƣợc sử dụng để thiết lập timeout cho một ca kiểm thử.
Hình 3.8 là ví dụ minh họa về ca kiểm thử với các thiết lập của nó.
Hình 3.8. Thiết lập trong bảng Test case.
3.4.6.Để tạo các ca kiểm thử tốt
Phần này sẽ hƣớng dẫn ở mức ngƣời dùng, để viết đƣợc các ca kiểm thử tốt. Quan trọng nhất của một ca kiểm thử tốt là dễ hiểu nhất có thể đối với ngƣời quen thuộc với tên miền, hay dễ hiểu với khách hàng – ngƣời tham gia vào khâu kiểm thử chấp nhận.
3.4.6.1. Cách đặt tên
Với bộ kiểm thử (Test suite), nên đặt tên mô tả đƣợc nhiều nhất có thể. Tên của bộ đƣợc tạo tự động từ tên tập tin hoặc tên thƣ mục chứa bộ kiểm thử đó. Vì vậy cần lƣu ý khi đặt tên tệp hay thƣ mục, tên có thể đặt dài nhƣng không nên quá 40 kí tự. Tên của bộ đƣợc tạo tự động từ tên tập tin hoặc tên thƣ mục chứa bộ kiểm thử đó. Với quy tắc, phần mở rộng của tập tin đƣợc lƣợc bỏ, dấu gạch dƣới đƣợc chuyển thành khoảng trống. Nếu tất cả các kí tự trong tên tệp hoặc thƣ mục là viết thƣờng thì khi đƣợc chuyển sang tên bộ kiểm thử kí tự đầu của mỗi từ trong tên đƣợc viết hoa. Ví dụ login_tests.txt đƣợc chuyển thành Login Test và TEST1_and_TEST2 đƣợc chuyển thành TEST1 and TEST2.
Với ca kiểm thử (Test case), tên của ca kiểm thử nên đƣợc đặt tƣơng tự tên của bộ kiểm thử. Nếu trong bộ có chứa nhiều ca kiểm thử với mục đích
tƣơng tự nhau và tên của bộ kiểm thử đã mô tả tốt mục đích đó thì tên ca kiểm thử nên đặt ngắn gọn xúc tích, minh họa Hình 3.9 và Hình 3.10 . Tên của ca kiểm thử là giữ nguyên, chính xác nhƣ tên đƣợc đặt trong tập tin mà không có sự chuển đổi nào.
Hình 3.9. Tên dài
Hình 3.10. Tên ngắn gọn, súc tích
Đố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ử.