Test Tool (TT) trong lĩnh vực PTPM là công cụ giúp thực hiện việc kiểm tra PM một cách tự động. Tuy nhiên không phải mọi việc kiểm tra đều có thể tự động hóa, câu hỏi đặt ra là trong điều kiện hoặc tình huống nào dùng TT là thích hợp? Việc dùng TT thường được xem xét trong một số tình huống sau:
Không đủ tài nguyên
Khi số lượng tình huống kiểm tra (test case) quá nhiều mà các KTV không thể hoàn tất bằng tay trong thời gian cụ thể nào đó.
Có thể lấy một dẫn chứng là khi thực hiện kiểm tra chức năng của một website. Website này sẽ được kiểm tra với 6 môi trường gồm 3 trình duyệt và 2 hệ điều hành
Tình huống này đòi hỏi số lần kiểm tra tăng lên và lặp lại 6 lần so với việc kiểm tra cho một môi trường cụ thể.
Kiểm tra hồi qui
Trong quá trình PTPM, nhóm lập trình thường đưa ra nhiều phiên bản PM liên tiếp để kiểm tra. Thực tế cho thấy việc đưa ra các phiên bản PM có thể là hàng ngày, mỗi phiên bản bao gồm những tính năng mới, hoặc tính năng cũ được sửa lỗi hay nâng cấp. Việc bổ sung hoặc sửa lỗi code cho những tính năng ở phiên bản mới có thể làm cho những tính năng khác đã kiểm tra tốt chạy sai mặc dù phần code của nó không hề chỉnh sửa. Để khắc phục điều này, đối với từng phiên bản, KTV không chỉ kiểm tra chức năng mới hoặc được sửa, mà phải kiểm tra lại tất cả những tính năng đã kiểm tra tốt trước đó. Điều này khó khả thi về mặt thời gian nếu kiểm tra thủ công.
Trình duyệt: IE, Netscape, Opera
Hệ điều hành:
WinXP, Linux
WinXP, IE
WinXP, Netscape
WinXP, Opera
Linux, IE
Linux, Netscape
Linux, Opera
Kiểm tra khả năng vận hành PM trong môi trường đặt biệt
Đây là kiểm tra nhằm đánh giá xem vận hành của PM có thỏa mãn yêu cầu đặt ra hay không. Thông qua đó KTV có thể xác định được các yếu tố về phần cứng, phần mềm ảnh hưởng đến khả năng vận hành của PM. Có thể liệt kê một số tình huống kiểm tra tiêu biểu thuộc loại này như sau:
• Đo tốc độ trung bình xử lý một yêu cầu của web server.
• Thiết lập 1000 yêu cầu, đồng thời gửi đến web server, kiểm tra tình huống 1000 người dùng truy xuất web cùng lúc.
• Xác định số yêu cầu tối đa được xử lý bởi web server hoặc xác định cấu hình máy thấp nhất mà tốc độ xử lý của PM vẫn có thể hoạt động ở mức cho phép.
Việc kiểm tra thủ công cho những tình huống trên là cực khó, thậm chí “vô phương”.
Cần lưu ý là hoạt động KTTĐ nhằm mục đích kiểm tra, phát hiện những lỗi của PM trong những trường hợp đoán trước. Điều này cũng có nghĩa là nó thường được thực hiện sau khi đã thiết kế xong các tình huống (test case). Tuy nhiên, như đã nói, không phải mọi trường hợp kiểm tra đều có thể hoặc cần thiết phải tự động hóa, trong tất cả test case thì KTV phải đánh giá và chọn ra những test case nào phù hợp hoặc cần thiết để áp dụng KTTĐ dựa trên những tiêu chí đã đề cập bên trên.
KHÁI QUÁT VỀ KTTĐ
Việc phát triển KTTĐ cũng tuân theo các bước PTPM, chúng ta phải xem việc phát triển KTTĐ giống như phát triển một dự án. Bạn đọc có thể tham khảo bài viết về kiểm tra phần mềm trên TGVT A tháng 12/2005 (ID: A0512_110). Hình 1 cho chúng ta thấy mối tương quan giữa KTTĐ và toàn bộ chu trình KTPM.
Hình 1
Giống như PTPM, để thành công trong KTTĐ chúng ta nên thực hiện các bước cơ bản sau:
• Thu thập các đặc tả yêu cầu hoặc test case; lựa chọn những phần cần thực hiện KTTĐ.
• Phân tích và thiết kế mô hình phát triển KTTĐ.
• Phát triển lệnh đặc tả (script) cho KTTĐ.
• Kiểm tra và theo dõi lỗi trong script của KTTĐ.
Bảng sau mô tả rõ hơn các bước thực hiện KTTĐ:
STT
Bước thực hiện
Mô tả
Tạo test script
Giai đoạn này chúng ta sẽ dùng test tool để ghi lại các thao tác lên PM cần kiểm tra và tự động sinh ra test script.
Chỉnh sửa test script
Chỉnh sửa để test script thực hiện kiểm tra theo đúng yêu cầu đặt ra, cụ thể là làm theo test case cần thực hiện.
Chạy test script để KTTĐ
Giám sát hoạt động kiểm tra PM của test script.
Đánh giá kết quả
Kiểm tra kết quả thông báo sau khi thực hiện KTTĐ. Sau đó bổ sung, chỉnh sửa những sai sót.
KTTĐ có một số thuận lợi và khó khăn cơ bản khi áp dụng:
Thuận lợi
Khó khăn
• KTPM không cần can thiệp của KTV.
• Giảm chi phí khi thực hiện kiểm tra số lượng lớn test case hoặc test case lặp lại nhiều lần.
• Giả lập tình huống khó có thể thực hiện bằng tay.
• Mất chi phí tạo các script để thực hiện KTTĐ.
• Tốn chi phí dành cho bảo trì các script.
• Đòi hỏi KTV phải có kỹ năng tạo script KTTĐ.
• Không áp dụng được trong việc tìm lỗi mới của PM.
GIỚI THIỆU CÔNG CỤ KTTĐ: QUICKTEST PROFESSIONAL
Trong lĩnh vực KTTĐ hiện có khá nhiều TT thương mại nổi tiếng, phổ biến như QuickTest Professional, WinRunner, Rational Robot, SilkTest, JTest,… Trong số đó, QuickTest Professional (QTP) phiên bản 8.2 của hãng Mercury khá tốt và mạnh, bao gồm nhiều chức năng điển hình của một công cụ kiểm tra tự động. Lưu ý là QTP 8.2 đã có một cái tên mới hơn là Mercury Functional Testing 8.2.
QTP là TT dùng để kiểm tra chức năng (functional test) và cho phép thực hiện kiểm tra hồi qui (regression test) một cách tự động. Đây cũng là công cụ áp dụng phương pháp Keyword-Driven, một kỹ thuật scripting (lập trình trong KTTĐ) hiện đại, cho phép KTV bổ sung test case bằng cách tạo file mô tả cho nó mà không cần phải chỉnh sửa hay bổ sung bất cứ script nào cả. Nó cũng phù hợp trong tình huống chuyển giao công việc mà người mới tiếp nhận chưa có thời gian hoặc không hiểu script vẫn có thể thực hiện kiểm tra PM theo đúng yêu cầu.
Loại phần mềm hỗ trợ
QTP giúp chúng ta KTPM theo hướng chức năng trên rất nhiều loại chương trình phần mềm khác nhau. Tuy nhiên Mercury chỉ hỗ trợ sẵn một số loại chương trình thông dụng như:
• Ứng dụng Windows chuẩn/Win32.
• Ứng dụng web theo chuẩn HTML, XML chạy trong trình duyệt Internet Explorer, Netscape hoặc AOL.
• Visual Basic.
• ActiveX.
• QTP hỗ trợ Unicode (UTF-8, UTF-16).
Một số loại chương trình khác đòi hỏi chúng ta phải cài đặt thêm thành phần bổ sung của QTP thì mới thực hiện kiểm tra được. Các loại chương trình đó là:
.NET
• NET Framework 1.0, 1.1, 2.0 beta
• Các đối tượng chuẩn của .NET và các đối tượng khác thừa kế từ các đối tượng chuẩn.
SAP
• SAP GUI HMTL 4.6D, 6.10, 6.20
• SAP Workplace 2.11
• SAP Enterprise Portal 5.0
Siebel
• Siebel 7.0, 7.5, 7.7
Terminal Emulators
• Attachmate EXTRA! 6.7, 7.1
• Attachmate EXTRA! Terminal Viewer 3.1 Java sessions
• IBM Personal Communications
•…
Đặc điểm
• Dễ sử dụng, bảo trì, tạo test script nhanh. Cung cấp dữ liệu kiểm tra rõ ràng và dễ hiểu.
• Kiểm tra phiên bản mới của ứng dụng với rất ít sự thay đổi. Ví dụ khi ứng dụng thay đổi nút tên “Login” thành “Đăng nhập”, thì chỉ cần cập nhật lại Object Repository (OR – được giải thích ở phần sau) để QTP nhận ra sự thay đổi đó mà không cần thay đổi bất cứ test script nào.
• Hỗ trợ làm việc theo nhóm thông qua sự chia sẻ thư viện, thống nhất quản lý Object Repository.
• Thực tế cho thấy, QTP thực hiện KTTĐ trên nhiều trình duyệt cùng lúc tốt hơn những TT khác.
• Với chức năng Recovery Scenarios, QTP cho phép xử lý những sự kiện hoặc lỗi không thể đoán trước có thể làm script bị dừng trong khi đang chạy.
• QTP có khả năng hiểu test script của Mercury Winrunner (một công cụ kiểm tra khác của Mercury).
Đặc biệt phiên bản v.8.2 có một số tính năng mới nổi bật:
Quản trị Object Repository
• Phối hợp giữa các KTV qua việc đồng bộ hóa dữ liệu, khả năng trộn, nhập/xuất ra file XML
Thư viện hàm mới
• Chia sẻ các thư viện hàm giữa các nhóm KTV
Kiểm tra tài nguyên
• Kiểm tra tài nguyên cần thiết trước khi thực thi lệnh kiểm tra tự động.
Nâng cấp khả năng kéo thả
• Kéo thả các bước kiểm tra trong môi trường ngôn ngữ tự nhiên.
Hỗ trợ XML cho báo cáo
• Lưu trữ kết quả kiểm tra dưới dạng XML, HTML, từ đó cho phép tùy biến báo cáo.
Trình phát triển mới (IDE)
• Môi trường soạn thảo mới, mềm dẻo cho tùy biến và sử dụng.
Trình dò lỗi mới
• Cho phép KTV kiểm soát lỗi khi viết test case.
Quản trị từ khóa
• Quản lý từ khóa trong quá trình sử dụng
Hỗ trợ đa giao tiếp
• Cho phép người dùng mở và soạn thảo đồng thời nhiều hàm thư viện và Object Repository.
Hỗ trợ Unicode
• Hỗ trợ Unicode với các ứng dụng đa ngôn ngữ (multi-language).
TẠI SAO PHẢI DÙNG TEST TOOL
Test Tool (TT) trong lĩnh vực PTPM là công cụ giúp thực hiện việc kiểm tra PM một cách tự động. Tuy nhiên không phải mọi việc kiểm tra đều có thể tự động hóa, câu hỏi đặt ra là trong điều kiện hoặc tình huống nào dùng TT là thích hợp? Việc dùng TT thường được xem xét trong một số tình huống sau:
Khi số lượng tình huống kiểm tra (test case) quá nhiều mà các KTV không thể hoàn tất bằng tay trong thời gian cụ thể nào đó.
Có thể lấy một dẫn chứng là khi thực hiện kiểm tra chức năng của một website. Website này sẽ được kiểm tra với 6 môi trường gồm 3 trình duyệt và 2 hệ điều hành
Tình huống này đòi hỏi số lần kiểm tra tăng lên và lặp lại 6 lần so với việc kiểm tra cho một môi trường cụ thể.
Trong quá trình PTPM, nhóm lập trình thường đưa ra nhiều phiên bản PM liên tiếp để kiểm tra. Thực tế cho thấy việc đưa ra các phiên bản PM có thể là hàng ngày, mỗi phiên bản bao gồm những tính năng mới, hoặc tính năng cũ được sửa lỗi hay nâng cấp. Việc bổ sung hoặc sửa lỗi code cho những tính năng ở phiên bản mới có thể làm cho những tính năng khác đã kiểm tra tốt chạy sai mặc dù phần code của nó không hề chỉnh sửa. Để khắc phục điều này, đối với từng phiên bản, KTV không chỉ kiểm tra chức năng mới hoặc được sửa, mà phải kiểm tra lại tất cả những tính năng đã kiểm tra tốt trước đó. Điều này khó khả thi về mặt thời gian nếu kiểm tra thủ công.
Trình duyệt: IE, Netscape, Opera
Hệ điều hành: WinXP, Linux WinXP, IE WinXP, Netscape WinXP, Opera
Linux, IE Linux, Netscape Linux, Opera
Đây là kiểm tra nhằm đánh giá xem vận hành của PM có thỏa mãn yêu cầu đặt ra hay không. Thông qua đó KTV có thể xác định được các yếu tố về phần cứng, phần mềm ảnh hưởng đến khả năng vận hành của PM. Có thể liệt kê một số tình huống kiểm tra tiêu biểu thuộc loại này như sau:
• Đo tốc độ trung bình xử lý một yêu cầu của web server.
• Thiết lập 1000 yêu cầu, đồng thời gửi đến web server, kiểm tra tình huống 1000 người dùng truy xuất web cùng lúc.
• Xác định số yêu cầu tối đa được xử lý bởi web server hoặc xác định cấu hình máy thấp nhất mà tốc độ xử lý của PM vẫn có thể hoạt động ở mức cho phép.
Việc kiểm tra thủ công cho những tình huống trên là cực khó, thậm chí “vô phương”.
Cần lưu ý là hoạt động KTTĐ nhằm mục đích kiểm tra, phát hiện những lỗi của PM trong những trường hợp đoán trước. Điều này cũng có nghĩa là nó thường được thực hiện sau khi đã thiết kế xong các tình huống (test case). Tuy nhiên, như đã nói, không phải mọi trường hợp kiểm tra đều có thể hoặc cần thiết phải tự động hóa, trong tất cả test case thì KTV phải đánh giá và chọn ra những test case nào phù hợp hoặc cần thiết để áp dụng KTTĐ dựa trên những tiêu chí đã đề cập bên trên.
KHÁI QUÁT VỀ KTTĐ
Việc phát triển KTTĐ cũng tuân theo các bước PTPM, chúng ta phải xem việc phát triển KTTĐ giống như phát triển một dự án. Bạn đọc có thể tham khảo bài viết về kiểm tra phần mềm trên TGVT A tháng 12/2005 (ID: A0512_110). Hình 1 cho chúng ta thấy mối tương quan giữa KTTĐ và toàn bộ chu trình KTPM.
Hình 1
Giống như PTPM, để thành công trong KTTĐ chúng ta nên thực hiện các bước cơ bản sau:
• Thu thập các đặc tả yêu cầu hoặc test case; lựa chọn những phần cần thực hiện KTTĐ.
• Phân tích và thiết kế mô hình phát triển KTTĐ.
• Phát triển lệnh đặc tả (script) cho KTTĐ.
• Kiểm tra và theo dõi lỗi trong script của KTTĐ.
Bảng sau mô tả rõ hơn các bước thực hiện KTTĐ:
STT Bước thực hiện Mô tả
Giai đoạn này chúng ta sẽ dùng test tool để ghi lại các thao tác lên PM cần kiểm tra và tự động sinh ra test script.
Chỉnh sửa để test script thực hiện kiểm tra theo đúng yêu cầu đặt ra, cụ thể là làm theo test case cần thực hiện.
Giám sát hoạt động kiểm tra PM của test script.
Kiểm tra kết quả thông báo sau khi thực hiện KTTĐ. Sau đó bổ sung, chỉnh sửa những sai sót.
KTTĐ có một số thuận lợi và khó khăn cơ bản khi áp dụng:
Thuận lợi
Khó khăn
• KTPM không cần can thiệp của KTV. • Giảm chi phí khi thực hiện kiểm tra số lượng lớn test case hoặc test case lặp lại nhiều lần. • Giả lập tình huống khó có thể thực hiện bằng tay.
• Mất chi phí tạo các script để thực hiện KTTĐ. • Tốn chi phí dành cho bảo trì các script. • Đòi hỏi KTV phải có kỹ năng tạo script KTTĐ. • Không áp dụng được trong việc tìm lỗi mới của PM.
GIỚI THIỆU CÔNG CỤ KTTĐ: QUICKTEST PROFESSIONAL
Trong lĩnh vực KTTĐ hiện có khá nhiều TT thương mại nổi tiếng, phổ biến như QuickTest Professional, WinRunner, Rational Robot, SilkTest, JTest,… Trong số đó, QuickTest Professional (QTP) phiên bản 8.2 của hãng Mercury khá tốt và mạnh, bao gồm nhiều chức năng điển hình của một công cụ kiểm tra tự động. Lưu ý là QTP 8.2 đã có một cái tên mới hơn là Mercury Functional Testing 8.2.
QTP là TT dùng để kiểm tra chức năng (functional test) và cho phép thực hiện kiểm tra hồi qui (regression test) một cách tự động. Đây cũng là công cụ áp dụng phương pháp Keyword-Driven, một kỹ thuật scripting (lập trình trong KTTĐ) hiện đại, cho phép KTV bổ sung test case bằng cách tạo file mô tả cho nó mà không cần phải chỉnh sửa hay bổ sung bất cứ script nào cả. Nó cũng phù hợp trong tình huống chuyển giao công việc mà người mới tiếp nhận chưa có thời gian hoặc không hiểu script vẫn có thể thực hiện kiểm tra PM theo đúng yêu cầu.
QTP giúp chúng ta KTPM theo hướng chức năng trên rất nhiều loại chương trình phần mềm khác nhau. Tuy nhiên Mercury chỉ hỗ trợ sẵn một số loại chương trình thông dụng như:
• Ứng dụng Windows chuẩn/Win32.
• Ứng dụng web theo chuẩn HTML, XML chạy trong trình duyệt Internet Explorer, Netscape hoặc AOL.
• Visual Basic.
• ActiveX.
• QTP hỗ trợ Unicode (UTF-8, UTF-16).
Một số loại chương trình khác đòi hỏi chúng ta phải cài đặt thêm thành phần bổ sung của QTP thì mới thực hiện kiểm tra được. Các loại chương trình đó là:
.NET • NET Framework 1.0, 1.1, 2.0 beta • Các đối tượng chuẩn của .NET và các đối tượng khác thừa kế từ các đối tượng chuẩn.
Java • Sun JDK 1.1 – 1.4.2 • IBM JDK 1.2 – 1.4
Oracle • Oracle Applications 11.5.7, 11.5.8, 11.5.9
People Soft • PeopleSoft Enterprise 8.0 – 8.8
SAP • SAP GUI HMTL 4.6D, 6.10, 6.20 • SAP Workplace 2.11 • SAP Enterprise Portal 5.0
Siebel • Siebel 7.0, 7.5, 7.7
Terminal Emulators • Attachmate EXTRA! 6.7, 7.1 • Attachmate EXTRA! Terminal Viewer 3.1 Java sessions • IBM Personal Communications •…
• Dễ sử dụng, bảo trì, tạo test script nhanh. Cung cấp dữ liệu kiểm tra rõ ràng và dễ hiểu.
• Kiểm tra phiên bản mới của ứng dụng với rất ít sự thay đổi. Ví dụ khi ứng dụng thay đổi nút tên “Login” thành “Đăng nhập”, thì chỉ cần cập nhật lại Object Repository (OR – được giải thích ở phần sau) để QTP nhận ra sự thay đổi đó mà không cần thay đổi bất cứ test script nào.
• Hỗ trợ làm việc theo nhóm thông qua sự chia sẻ thư viện, thống nhất quản lý Object Repository.
• Thực tế cho thấy, QTP thực hiện KTTĐ trên nhiều trình duyệt cùng lúc tốt hơn những TT khác.
• Với chức năng Recovery Scenarios, QTP cho phép xử lý những sự kiện hoặc lỗi không thể đoán trước có thể làm script bị dừng trong khi đang chạy.
• QTP có khả năng hiểu test script của Mercury Winrunner (một công cụ kiểm tra khác của Mercury).
Đặc biệt phiên bản v.8.2 có một số tính năng mới nổi bật:
Quản trị Object Repository
• Phối hợp giữa các KTV qua việc đồng bộ hóa dữ liệu, khả năng trộn, nhập/xuất ra file XML
Thư viện hàm mới
• Chia sẻ các thư viện hàm giữa các nhóm KTV
Kiểm tra tài nguyên
• Kiểm tra tài nguyên cần thiết trước khi thực thi lệnh kiểm tra tự động.
Nâng cấp khả năng kéo thả
• Kéo thả các bước kiểm tra trong môi trường ngôn ngữ tự nhiên.
Hỗ trợ XML cho báo cáo
• Lưu trữ kết quả kiểm tra dưới dạng XML, HTML, từ đó cho phép tùy biến báo cáo.
Trình phát triển mới (IDE)
• Môi trường soạn thảo mới, mềm dẻo cho tùy biến và sử dụng.
Trình dò lỗi mới
• Cho phép KTV kiểm soát lỗi khi viết test case.
Quản trị từ khóa
• Quản lý từ khóa trong quá trình sử dụng
Hỗ trợ đa giao tiếp
• Cho phép người dùng mở và soạn thảo đồng thời nhiều hàm thư viện và Object Repository.
Hỗ trợ Unicode
• Hỗ trợ Unicode với các ứng dụng đa ngôn ngữ (multi-language).
Hỗ trợ các môi trường mới ..... Nguồn : http://philong0920.wordpress.com/2008/07/14/tim-hi%E1%BB%83u-v%E1%BB%81-test-tool-quicktest-professional-8-2/