1.5. Kiểm thử tự động
1.5.2. Lựa chọn công cụ kiểm thử tự động
Có rất nhiều công cụ KTTĐ với các ƣu và nhƣợc điểm khác nhau. Mỗi ứng dụng phần mềm hay các ứng dụng web lại đƣợc xây dựng trên một nền tảng với những đặc điểm riêng. Vì thế việc lựa chọn công cụ kiểm thử cho phù hợp không hề đơn giản. Trong tƣơng lai, với sự phát triển không ngừng của công nghệ phần mềm, vai trò của kiểm thử đƣợc đánh giá cao hơn, sẽ cần những đội ngũ chuyên gia chuyên nghiên cứu và tìm ra bộ công cụ kiểm thử phù hợp với từng sản phẩm phần mềm.
Dƣới đây là các tiêu chí cơ bản, có thể dựa trên đó để lựa chọn công cụ kiểm thử phù hợp với ứng dụng cần kiểm thử.
1.5.1.1. Tiêu chí 1: Mục tiêu nhóm kiểm thử
Mục tiêu của nhóm kiểm thử là một trong những chìa khóa cho mọi thành công. Nếu nhóm là một phần của đội QA hay R&D, onsite hay offshore, tất cả các thông số
sẽ ảnh hƣởng tới giao diện mà các tester sẽ cần từ hệ thống, đầu ra, báo cáo, cấu hình,…
Lựa chọn công cụ kiểm thử tốt là cách lựa chọn sao cho hệ thống kết hợp tốt với các thành phần xung quanh, đảm bảo phƣơng pháp làm việc mới là ít nhất. Cách thức làm việc của nhóm, sẽ tác động tới khả năng viết kịch bản (scripting) của công cụ, trong một số trƣờng hợp, script có hiệu quả tốt hơn, và nếu không, cần xem xét lại nhóm kiểm thử, môi trƣờng và phƣơng pháp làm việc.
1.5.1.2. Tiêu chí 2: Nền tảng và ứng dụng hỗ trợ
Công cụ kiểm thử phải phù hợp và tƣơng thích với các công cụ phát triển cũng nhƣ công cụ kiểm soát chất lƣợng đƣợc dùng trong tổ chức. Sự tƣơng thích này đảm bảo toàn bộ quá trình kiểm thử sẽ đƣợc kết hợp nhuần nhuyễn với quá trình phát triển phần mềm và dễ dàng hơn cho nhóm phát triển cũng nhƣ nhóm kiểm thử. Ngƣợc lại, sẽ gây khó khăn trong quá trình xây dựng và phát triển kịch bản kiểm thử.
Kiểm tra nền tảng mà các sản phẩm công ty đang chạy trên đó. Công cụ kiểm thử cũng phải chạy trên cùng nền tảng đó. Windows, Linux, Mobile là một vài ví dụ về platform tồn tại trên thị trƣờng hiện nay. Kiểm thử ứng dụng, kiểm thử web, kiểm thử server,… thƣờng đều cần sự hỗ trợ đặc biệt của các công cụ kiểm thử, có nghĩa là nó sẽ có khả năng điều khiển luồng hoạt động và đầu ra của ứng dụng.
1.5.1.3. Tiêu chí 3: Các kiểu kiểm thử
Không nhiều công cụ KTTĐ có thể thực hiện tất cả các kiểu kiểm thử và phƣơng pháp kiểm thử, cũng có một số linh hoạt hơn. Lựa chọn tool theo kiểu kiểm thử mà ứng dụng cần, trong một vài trƣờng hợp ứng dụng đang làm việc với nhiều giao diện ngƣời dùng, GUI, Web, Linux, giao diện Java, các ứng dụng qua bên thứ 3. Đôi khi tổ chức chế độ làm việc cần thích hợp hơn, nhƣ kiểm thử chức năng, kiểm thử đơn vị, kiểm thử chấp nhận làm việc đứng trên vai trò khách hàng,…
Phân tích môi trƣờng hoạt động, sẽ cho biết cần kiểu kiểm thử nào. Sau khi xác định đƣợc các kiểu kiểm thử cần tiến hành, sắp xếp mức độ ƣu tiên và mức độ quan trọng của chúng. Không phải mọi công cụ đều hỗ trợ tất cả các kiểu kiểm thử, nên phải đảm bảo chúng sẽ hỗ trợ những loại có mức ƣu tiên cao, nếu chúng làm việc, và đã lựa chọn đƣợc một framwork tự động, sẽ có thể xây dựng đƣợc những hỗ trợ cần thiết còn lại.
1.6.1.4. Tiêu chí 4: Khả năng lập trình
Một vài công cụ có khả năng viết kịch bản, một số không, một số có cả hai lựa chon. Dựa trên khả năng lập trình của nhóm kiểm thử và nhu cầu sử dụng chức năng tạo kịch bản của công cụ kiểm thử mà lựa chọn công cụ phù hợp. Viết kịch bản KTTĐ yêu cầu khả năng lập trình và có thể khó khăn đối với các kiểm thử viên ít kinh
nghiệm. Từ trình độ của nhóm kiểm thử viên mà quyết định lựa chọn công cụ cho hợp lý.
Nếu quyết định hƣớng công cụ KTTĐ có khả năng tạo script, cần lựa chọn công cụ đƣợc phát triển với ngôn ngữ tƣơng đồng với hầu hết ngƣời dùng. Ví dụ, nếu hầu hết kiểm thử viên hay lập trình viên biết nhiều về Java, thì nên lựa chọn công cụ KTTĐ với khả năng lập trình bằng Java. Khi đó, không chỉ nhận đƣợc một công cụ mà hầu hết mọi ngƣời đều biết cách xử lý, nếu mọi ngƣời quen với ngôn ngữ lập trình đó, việc phát triển và bảo trì sẽ nhanh hơn và tin cậy hơn.
Nếu quyết định chọn công cụ KTTĐ không có khả năng viết script, cần phải thử khả năng giao diện của nó, các phƣơng pháp thiết kế kiểm thử khác nhƣ là: thiết kế Moular trực quan, thiết kế Keyword Driven, ghi lại lịch sử ngƣời dùng, hay khả năng ghi âm. Các kịch bản KTTĐ rất hữu ích ngay cả khi công cụ KTTĐ cung cấp những cách thức dễ dàng để KTTĐ, bởi vì script thƣờng cung cấp tính năng mạnh mẽ hơn, nó cho phép thi hành những hành động mà các kiểu KTTĐ không thực hiện đƣợc.
Một lƣu ý trƣớc khi lựa chọn công cụ với khả năng tạo script hay không, đó là công cụ đó cần có sẵn sự hỗ trợ tốt về trợ giúp, các tài liệu tham khảo hay các diễn đàn trao đổi. Các thông tin này sẽ rất hữu ích và giúp kiểm thử viên tiếp cận và sử dụng công cụ đƣợc thuận lợi hơn.
1.6.1.5. Tiêu chí 5: Khả năng ghi sự kiện
Hiện nay trên thị trƣờng có hai loại ghi âm (ghi sự kiện). Loại thứ nhất là kiểu ghi lại các bƣớc kịch bản, công cụ KTTĐ bật trạng thái ghi, sau đó tester thực hiện theo luồng kịch bản. Khi kết thúc quá trình ghi sẽ có một mô tả đầy đủ về scenario. Ngày nay loại hình ghi âm này có thể chơi, không chỉ mô tả script, không chỉ mô tả lại GUI / blocks. Loại hình ghi âm thứ 2, đó là ghi âm thành video. Tester thực hiện kịch bản kiểm thử và phát hiện ra một khiếm khuyết hay những thứ có thể gây ra khiếm khuyết, loại hình ghi âm này sẽ tạo ra một tệp tin movie từ chính luồng hoạt động của kịch bản.
1.6.1.6. Tiêu chí 6: Công nghệ ứng dụng
Cho dù bạn đang kiểm thử giao diện hay kiểm thử Web, đảm bảo hệ thống KTTĐ, sẽ biết làm thế nào để vận hành kiểm soát một cách đáng tin cậy nhất. Dù ứng dụng cần kiểm thử giao diện là ứng dụng web hay phần mềm nghiệp vụ,… khi KTTĐ phải biết làm thế nào để vận hành kiểm soát một cách đáng tin cậy nhất. Một số trƣờng hợp, ứng dụng không có bất kỳ giao diện GUI nào hay chỉ một phần GUI hoạt động, trong trƣờng hợp đó xem xét phƣơng pháp làm việc của kiểm thử viên, lựa chọn làm việc kết hợp hay thông qua các công cụ của bên thứ ba, cũng có thể coi nhƣ kiểm thử thủ công.
Công cụ KTTĐ phải hỗ trợ công nghệ ứng dụng, nhƣng đồng thời cũng phải hỗ trợ phƣơng pháp làm việc của kiểm thử viên. Công cụ KTTĐ phải hỗ trợ, cho kiểm thử GUI, tất cả các điều khiển chuẩn hay không chuẩn để kích hoạt chúng và phân tích kết quả trả về.
1.6.1.7. Tiêu chí 7: Nguồn dữ liệu kiểm thử
Trong nhiều trƣờng hợp cần thiết phải kiểm thử dữ liệu các trƣờng, cùng một scenario nhƣng có thể có nhiều dữ liệu đầu vào khác nhau, việc kiểm thử nguồn dữ liệu hay tích hợp nguồn dữ liệu là cần thiết, triệt để kiểm thử các nguồn dữ liệu khác nhau để đảm bảo quá trình xử lý của ứng dụng chính xác. Khi lựa chọn công cụ KTTĐ, cần kiểm tra xem định dạng dữ liệu nó có thể sử dụng, nhƣ file text, XML, bảng cơ sở dữ liệu hay các dạng khác. Hầu hết các trƣờng hợp này kiểm thử viên đều có thể tự thực hiện, tuy nhiên nếu có sự hỗ trợ của công cụ KTTĐ, có thể tiết kiệm đƣợc nhiều thời gian ngay từ khi bắt đầu. Các hoạt động này luôn có hai chi phí chính: chi phí tức thì (Immediate) và chi phí tiếp diễn (Continued). Chi phí tức thì là chi phí cho tài nguyên khi bắt đầu tạo và kích hoạt hành động tích hợp, chi phí tiếp diễn là chi phí để duy trì và cập nhật về sau.
1.6.1.8. Tiêu chí 8: Thực thi kiểm thử tự động
Ngày nay chúng ta muốn thấy đƣợc quá trình phát triển, ngay cả thời gian chạy nếu có thể, và quá trình kiểm thử là một phần trong quy trình phát triển và triển khai phần mềm. Nắm bắt đƣợc xu hƣớng này, rất nhiều tổ chức phát triển công cụ KTTĐ đã phát triển tính năng này cho công cụ. Để có thể lựa chọn công cụ phù hợp, cần thực hiện một số bƣớc kiểm tra dƣới đây.
Trƣớc tiên, kiểm tra khả năng tích hợp vào hệ thống kiểm thử hay quản lý dự án. Sau đó, quyết định sẽ thực thi nó tại đâu, các lựa chọn có thể là:
Từ giao diện công cụ (tool interface)
Từ giao diện công cụ quản lý kiểm thử (Test Management tool interface) Đƣợc liệt kê thông qua ứng dụng desktop khác
Mỗi trƣờng hợp đều có ƣu và nhƣợc điểm riêng, một điều mà cần xem xét khi lựa chọn đó là yếu tố đầu ra. Các công cụ đƣợc tích hợp, trong nhiều trƣờng hợp không đƣợc tích hợp bằng cách thực hiện và trong nhiều trƣờng hợp đƣợc tích hợp bằng cách thu thập đầu ra và quản lý kết quả. Bên cạnh đó, nên chạy tất cả các trƣờng hợp kiểm thử để áp dụng khi cần chạy theo chu kỳ, thông thƣờng chúng chạy trong thời gian dài và không cần kiểm thử viên phải giám sát, do đó hệ thống phải có khả năng tự khắc phục một số lỗi trong quá trình chạy, thông báo các lỗi đó và tiếp tục chạy.
Thông thƣờng sau phát triển một phần nhỏ ứng dụng, hoặc sau khi khắc phục những khiếm khuyết gây ảnh hƣởng một phần ứng dụng, chúng ta mong muốn chạy thử ngay lập tức và trong thời gian ngắn, do đó sẽ sử dụng tool ở chế độ này.
Một số công cụ có khả năng hoạt động trên các hệ thống khác tốt hơn là trên chính hệ thống nội bộ. Đây là lựa chọn tốt khi kiểm thử việc phân phối và các ứng dụng đa hệ thống.
1.6.1.9. Tiêu chí 9: Khả năng phân tích dữ liệu đầu ra
Trong kiểm thử phần mềm, không nhất thiết cần phân tích dữ liệu đầu ra của ứng dụng. Tuy nhiên, trong một số trƣờng hợp điều này là cần thiết. Trong kiểm thử hộp đen, hay kiểm thử ứng dụng đầu cuối, cần tập trung vào giao diện khách (client), không cần phân tích đầu ra ứng dụng mà không phải giao diện đồ họa client. Nhƣng đối với kiểm thử hộp trắng, chúng ta mong muốn công cụ KTTĐ có khả năng phân tích, thậm chí so sánh kết quả đầu ra với kết quả mong đợi. Đầu ra bên ngoài có thể là các tệp tin văn bản, xml, log, ivr, hay ảnh,.. Khi đó nên lựa chọn công cụ có khả năng hỗ trợ phân tích đầu ra sẽ hữu ích hơn.
1.6.1.10. Tiêu chí 10: Đầu ra các công cụ kiểm thử
Nói một cách đơn giản nhất, đầu ra của công cụ kiểm thử chính là các thông báo hay các phản hồi trả về của công cụ sau các bƣớc kiểm thử ứng dụng. Nếu mọi ca kiểm thử đều thất bại, cần đặt ra câu hỏi, đã kiểm thử những gì, có thể tái tạo lại nó một cách thủ công hay không? Mọi công cụ kiểm thử, đều đƣợc yêu cầu thông báo lại các hành động và các bƣớc thực hiện hay luồng làm việc của nó, đồng thời sẽ thông báo lại các lỗi xảy ra và các trƣờng hợp nghi ngờ có thể gây ra lỗi.Trong trƣờng hợp công cụ KTTĐ đƣợc tích hợp vào hệ thống Test Management, cần biết trạng thái chạy trong thời gian thực hiện, kết quả cuối cùng là đạt hay không đạt khi quá trình kiểm thử kết thúc. Nếu công cụ KTTĐ tạo và xuất một báo cáo, cần biết định dạng dữ liệu nào là phù hợp nhất: HTML, XML hay một định dạng dữ liệu nào. Một số hệ thống muốn tích hợp các báo cáo của công cụ KTTĐ vào hệ thống báo cáo, hay platform của họ, để đảm bảo tất cả các báo cáo có chung một định dạng.
1.6.1.11. Tiêu chí 11: Khả năng mở rộng
Nếu công cụ KTTĐ không hỗ trợ tất cả các kiểu hay công nghệ kiểm thử cần thiết, cần xem xét công cụ đó có hỗ trợ các tùy biến giúp chúng ta có thể kích hoạt các tính năng khác của hệ thống theo yêu cầu. Các tùy chỉnh này có thể bao gồm:
- Hỗ trợ các API mở rộng, có thể làm việc với các tổ hợp COM, DLL, ActiveX hay công nghệ OLE.
- Hỗ trợ dòng lệnh
- Làm việc với các hệ thống kiểm soát tài nguyên
- Kiểm thử hệ thống đa ngôn ngữ, hỗ trợ OCR và các kiểu ký tự - Tích hợp với hệ thống Defect
- Tích hợp vào IDE nội bộ hay các hệ thống quản lý kiểm thử, quản lý dự án
1.6.1.12. Tiêu chí 12: Hỗ trợ công nghệ
Công cụ tốt là công cụ đƣợc nhiều ngƣời sử dụng với các tài liệu hƣớng dẫn chi tiết với các ví dụ cụ thể, đƣờng dây hỗ trợ và cá diễn đàn công nghệ phản hồi nhanh chóng. Sự trợ giúp là một yếu tố quan trọng trong lựa chọn công cụ KTTĐ. Nếu công cụ không có sự hỗ trợ thích hợp, sẽ phải tiêu tốn rất nhiều thời gian để tìm hiểu cách sử dụng và đặc biệt khó khăn mỗi khi xảy ra sự cố.
1.6.1.13. Tiêu chí 13: Chính sách giá cả
Với KTTĐ sẽ phải bỏ ra một phần chi phí khi mua và nâng cấp các công cụ có bản quyền. Vì vậy cần cân nhắc tới giá cả và chính sách dịch vụ trƣớc khi lựa chọn công cụ kiểm thử phần mềm tự động. Có thể dựa trên:
- Phí bản quyền trên mỗi ngƣời dùng/ nhiều ngƣời dùng, cố định hay thay đổi, có thời hạn hay vô thời hạn.
- Phí hỗ trợ và các lựa chọn hỗ trợ có sẵn.
1.6.1.14. Tiêu chí 14: Dùng thử và đánh giá
Cách đơn giản để lựa chọn công cụ kiểm thử phù hợp đó là dùng thử. Rất nhiều công cụ bản quyền đƣợc đăng tải trên mạng có các bản dùng thử. Dựa trên các tiêu chí đã nêu, có thể lựa chọn một số công cụ, tải bản dùng thử về cài đặt và dùng thử. Trong quá trình đó, có các nhận xét đánh giá xem công cụ nào hiệu quả và phù hợp với ứng dụng của mình.
CHƢƠNG II – GIAO DIỆN VÀ CÁC VẤN ĐỀ CẦN QUAN TÂM KHI THIẾT KẾ GIAO DIỆN