Thực thi kiểm thử tự động
Theo Mohammad Saad
Chúng ta đã thảo luận nhiều vấn đề liên quan đến kiểm thử tự động. Chúng ta nói về cách để bắt đầu tự động hóa kiểm thử trong dự án, cách để lựa chọn công cụ kiểm thử tự động, các loại mô hình kiểm thử tự động mà chúng ta có thể phát triển và cách tạo ra mã kiểm thử với xu hướng chuẩn bị cho việc bảo trì.
Trong bài này, chúng ta sẽ thảo luận về kế hoạch thực thi các mã kiểm thử.
Kế hoạch thực thi
Vài lời khuyên cho một kế hoạch kiểm thử thành công
Vấn đề quan trọng nhất cho kế hoạch thực thi là nó nên được lên kế hoạch trước cả khi tạo ra các đoạn mã. Chúng ta cần phải biết vài điểm trước khi tạo ra các mã kiểm thử.
Ví dụ như, giả sử chúng ta đang làm kiểm thử cho một ứng dụng Web. Chúng ta cần tạo các mã kiểm thử cho chức năng đăng nhập của trang web.
Nó có vẻ khá đơn giản với cái nhìn đầu tiên, với việc tạo ra 8 hay 10 đoạn mã để kiểm thử chức năng đăng nhập mà bao gồm nhiều yếu tố. Nhưng, một khi chúng ta thực sự thực thi kịch bản kiểm thử, chúng ta sẽ đối mặt với nhiều vấn đề. Vậy nên, tốt nhất là nên hỏi những câu hỏi dưới đây trước khi bước vào việc tạo các đoạn mã.
Những câu hỏi bao gồm:
Q #1. Môi trường thực thi là gì?
Đây thực sự là câu hỏi quan trọng nhất. Môi trường có nghĩa là nơi kịch bản kiểm thử được thực thi.
Ví dụ, chúng ta kiểm thử một ứng dụng web được cài đặt ở môi trường địa phương. Chúng ta sẽ tạo kịch bản kiểm thử, với ý tưởng trong đầu là kiểm thử môi trường địa phương. Nhưng ở tương lai, nếu hệ thống được đưa lên một máy chủ trên mạng, chúng ta nên biết điều đó ngay từ đầu. Khi chúng ta biết được điều đó, chúng ta có thể khắc phục bằng cách giữ các giá trị bên ngoài kịch bản kiểm thử, và có thể thay đổi sau này một cách dễ dàng.
Các giá trị như đường dẫn, tên đăng nhập, mật khẩu, địa chỉ thư điện tử, v.v… nên được lưu trữ bên ngoài mã kiểm thử vì những giá trị này sẽ thay đổi khi chúng ta thay đổi máy chủ. Lưu trữ những giá trị này trong một cơ sở dữ liệu, như một tập tin Excel hay hệ thống cơ sở dữ liệu, sẽ giúp chúng ta thay đổi chúng một cách dễ dàng mà không cần chỉnh sửa mã kiểm thử của chúng ta.
Tiếp theo, câu hỏi sẽ là, mã kiểm thử sẽ được thực thi ở đâu? Nó có thực thi trên một máy ảo (VM) hay một máy vật lý thực sự? Nếu chúng ta dùng máy ảo, bao nhiêu máy là đủ và cấu hình cho máy ảo là như thế nào? Tất cả những câu hỏi này đều cần được trả lời.
Mội điều quan trọng nữa là – Liệu chúng ta có thể thực thi kịch bản kiểm thử mà không cần cài đặt công cụ lên những máy tính đó (máy ảo hay thực)? Bởi vì khi cài đặt thêm máy có nghĩa là chúng ta cần thêm giấy phép cho những công cụ đó, mà giấy phép thì thường là đắt tiền. Cùng với mục đích này, một số công cụ cung cấp những công cụ thực thi – phiên bản đã giảm bới một số chức năng và rẻ hơn và chỉ có khả năng thực thi kịch bản kiểm thử.
Ví dụ như, MS Coded UI có “MS Test Agent” và Test Complete thì có “TestExecution”.
Một ưu điểm nữa của việc sự dụng máy ảo là, chúng ta có thể thực thi và thu nhỏ máy ảo, rồi tiếp tục làm việc trên máy thực. Với điều này, thời gian để thực thi mã kiểm thử sẽ được sử dụng để tạo ra những mã kiểm thử khác.
Điều thử ba liên quan đến môi trường là, có bao nhiêu trình duyệt mà chúng ta cần phải thực thi mã trên nó? Nếu chúng ta cần thực thi với IE, Firefox và IE, chúng ta cần đảm bảo kỹ thuật mà chúng ta dùng để xác định các đối tượng UI là làm việc được với cả 3 trình duyệt. Nếu chúng ta dùng kỹ thuật CSS, chúng ta sẽ phải đảm bảo những thuộc tính CSS đó hỗ trợ cho những trình duyệt cần thực thi kiểm thử.
Q #2. Khi nào những kịch bản kiểm thử được thực thi và bởi ai?
Câu hỏi về “thời gian” dường như khá dễ đề trả lời: Bất cứ khi nào có phiên bản mới.
Nhưng mà đây không phải là bản chất của câu hỏi.
Ngày nay, nhiều công ty sử dụng Continuous Integration (CI).
CI là gì? Một cách đơn giản, chúng ta có thể nói là, ngay khi kỹ sư phát triển đưa ra một đoạn mã, một luồng công việc được kích hoạt, sẽ kết nối tất cả các phần của ứng dụng và đưa ra một phiên bản một cách tự động. Trong vài trường hợp, phiên bản này sẽ được triển khai và sẽ được kiểm thử tự động bởi các mã kiểm thử.
Mục đích của câu hỏi này là xác định liệu rằng mã kiểm thử tự động của chúng ta có là một phần của CI hay không? Nếu đúng, vậy thì chúng ta phải đảm bảo rằng mã kiểm thử là một phần tích hợp chính xác với hệ thống CI như Jenkins, MS Build hay Hudson.
Vài công ty sẽ dùng xây dựng phiên bản qua đêm. Với trường hợp này, chúng ta phải đảm bảo rằng mã kiểm thử có thể được khởi động và thực thi tự động, không cần đến bàn tay con người.
Vài công ty không dùng hệ thống ra phiên bản tự động. Họ đưa ra các phiên bản một cách thủ công và từ đó, họ cài đặt ứng dụng lên hệ thống và thực thi kiểm thử tự động sau. Với kịch bản này, đôi khi mã sẽ được thực thi bởi nhóm kiểm thử tự động.
Trong vài công ty khác, kỹ sư kiểm thử thủ công thực thi những mã kiểm thử hoặc một nhân sự chuyên biệt được thuê để thực thi mã. Nó phụ thuộc vào tỉ lệ của ứng dụng và số lượng môi trường. Nếu số lượng môi trường là cao, tốt nhất là thuê một nhân sư chuyên biệt để thực thi mã kiểm thử.
Q #3. Thực thi kiểm thử nên kết thúc ngay khi có một thất bại hay tiếp tục những kịch bản khác?
Vài ứng dụng mà luồng làm việc của nó có mức độ phụ thuộc lẫn nhau giữa các hành động khá lớn.
Ví dụ, giả sư như chúng ta đang kiểm thử một hệ thống trả lương cho một ứng dụng ERP. Những bài kiểm thử sẽ là, trong kịch bản đầu tiên, chúng ta cần tạo ra một nhân viên trong cơ sở dữ liệu. Và trong kịch bản kế tiếp, chúng ta cần in một bảng lương cho nhân viên đó.
Bây giờ, tình huống sẽ là:
Nếu nhân viên không được tạo ra (bởi vì một lỗi của chương trình), chúng ta không thể đưa lương cho anh ta. Vậy nên, nếu kịch bản đầu tiên thất bại, kịch bản thứ hai sẽ không thể thực thi.
Do đó, trước khi thiết kế các kịch bản kiểm thử, chúng ta nên xem xét sự phụ thuộc giữa các kịch bản kiểm thử. Nếu có một sự phụ thuộc giữa chúng, chúng ta nên sắp xếp thứ tự thực thi một cách tương ứng. Chúng ta nên kết thúc việc thực thi khi có một thất bại đầu tiên và báo cáo lỗi.
Trong vài công ty mà họ có một thứ, gọi là ‘trạng thái cơ bản‘.
Ví dụ như, một trang điều kiển mà chứa toàn bộ các liên kế đến những trang khác. Trang điều kiển này sẽ là một ‘trạng thái cơ bản’ cho những kịch bản kiểm thử của chúng ta. Mỗi một kịch bản sẽ bắt đầu từ ‘trạng thái cơ bản’ và kết thúc ở ‘trạng thái cơ bản’. Do đó, kịch bản kiểm thử sau sẽ không phụ thuộc vào trạng thái của kịch bản trước đó. Với cách này, chúng ta không cần phải kết thục thực thi khi có bất kỳ kịch bản nào thất bại.
Nếu có một kịch bản thất bại, chúng ta chỉ cần đánh dấu nó và trở về trạng thái cơ bản, và thực thi những kịch bản khác (đôi khi, nó cũng được gọi là chiến lược phục hồi). Khi kết thúc thực thi, chúng ta sẽ có một báo cáo bao nhiêu kịch bản thành công, bao nhiêu kịch bản thất bại. Chúng ta kiểm tra những kịch bản thất bại và xác định – báo cáo lỗi. (Các kịch bản đăng nhập, đã nói ở trên, cũng có thể coi là một ‘trạng thái cơ bản’).
Những câu hỏi trên cần được trả lời, và những câu trả lời cần phải được biết bởi tất cả kỹ sư tự động với mục tiêu phát triển những mã kiểm thử thành công và những lần thực thi liền mạch. Một kiểm thử tự động đơn giản về đăng nhập là rất dễ để tạo ra, nhưng thực thi nó thì khó khăn hơn nếu chúng ta chỉ cố gắng tạo ra các mã kiểm thử mà bỏ qua những điểm trên.