Chương đánh giá cần trả lời hai câu: hệ thống có làm đúng điều đã phân tích không, và người dùng thật có dùng được không. Câu đầu trả lời bằng kế hoạch kiểm thử, ca kiểm thử, phép đo hiệu năng; câu sau bằng một buổi dùng thử nhỏ có ghi chép. Lỗi còn tồn tại phải ghi rõ.
Nhiều khoá luận xây hệ thống kết thúc bằng một mục “kiểm thử” vài dòng: “hệ thống đã được kiểm thử và chạy ổn định”. Câu này không cho hội đồng biết gì. Phần đánh giá là chỗ phân biệt một phần mềm bạn tin là chạy được với một phần mềm bạn đã chứng minh là chạy được, và nó không tốn nhiều công như sinh viên thường nghĩ.
Lập kế hoạch kiểm thử từ chương phân tích
Kế hoạch kiểm thử tốt là bản đối chiếu với chương phân tích yêu cầu. Viết nó ngay khi chốt yêu cầu, không đợi xong mã.
- Liệt kê yêu cầu chức năng chính và yêu cầu phi chức năng đã đặt con số.
- Với mỗi yêu cầu, xác định cách kiểm: kiểm thử đơn vị, kiểm thử tích hợp, kiểm thử chức năng qua giao diện, hay phép đo.
- Xác định môi trường kiểm thử: máy chủ, trình duyệt, thiết bị di động, dữ liệu mẫu.
- Đặt tiêu chí đạt cho từng nhóm, ví dụ mọi ca kiểm thử chức năng chính phải đạt, thời gian phản hồi dưới ngưỡng đã đặt.
- Dự kiến thời gian sửa lỗi sau vòng kiểm thử đầu tiên.
Kế hoạch này có thể là một bảng hai trang trong luận văn. Nó cho thấy kiểm thử của bạn có hệ thống, không phải bấm thử vài nút trước ngày nộp.
Viết ca kiểm thử: các trường cần có
Mỗi ca kiểm thử là một dòng trong bảng. Thân luận văn chỉ cần bảng tổng hợp và vài ca tiêu biểu; danh sách đầy đủ đưa vào phụ lục.
| Trường | Ý nghĩa | Ví dụ |
|---|---|---|
| Mã ca | Để truy vết với yêu cầu | TC-DL-03 |
| Yêu cầu liên quan | Ca này kiểm yêu cầu nào | Đặt lịch khám theo bác sĩ |
| Điều kiện trước | Trạng thái hệ thống trước khi thử | Bác sĩ đã có lịch làm việc thứ Hai |
| Các bước | Thao tác cụ thể | Chọn bác sĩ, chọn khung giờ đã có người đặt, xác nhận |
| Kết quả mong đợi | Điều phải xảy ra | Hệ thống báo khung giờ đã kín, gợi ý khung gần nhất |
| Kết quả thực tế | Điều đã xảy ra | Đạt hoặc mô tả lỗi |
| Ghi chú | Bối cảnh, mã lỗi | Lỗi khi hai người bấm cùng lúc, đã sửa ở phiên bản sau |
Đo hiệu năng ở mức khoá luận
Đo điều đã hứa
Nếu chương phân tích đặt yêu cầu thời gian tải trang danh sách với một số bản ghi nhất định, hãy đo đúng điều đó. Sinh dữ liệu mẫu đủ lớn, đo nhiều lần, báo trung bình và giá trị lớn nhất. Ghi rõ cấu hình máy chủ thử nghiệm để người đọc hiểu bối cảnh của con số.
Công cụ
Công cụ dành cho nhà phát triển có sẵn trong trình duyệt đủ để đo thời gian tải trang. Với kiểm thử tải nhiều người dùng đồng thời, có các công cụ mã nguồn mở như Apache JMeter hay k6. Không cần dựng kịch bản phức tạp; vài kịch bản sát với cách dùng thật là đủ.
Không phóng đại
Kết quả đo trên máy cá nhân với vài trăm bản ghi không cho phép kết luận hệ thống chịu được hàng nghìn người dùng. Viết đúng phạm vi đã đo.
Một câu trung thực kiểu “với dữ liệu mẫu và cấu hình thử nghiệm đã mô tả, thời gian phản hồi trung bình nằm dưới ngưỡng đặt ra; khả năng chịu tải lớn hơn chưa được kiểm chứng” vừa đúng vừa cho thấy bạn hiểu giới hạn của phép đo. Phần chưa kiểm chứng chuyển thành hướng phát triển ở chương kết luận.
Người dùng thử: nhỏ nhưng có phương pháp
Chọn người thử
Mời người gần với người dùng thật: nhân viên của cửa hàng mà bạn làm hệ thống, bạn bè có cùng nhu cầu. Số người không cần lớn; một nhóm nhỏ năm đến mười người thường đã phát hiện phần lớn vấn đề sử dụng nghiêm trọng. Ghi rõ cách chọn và số lượng.
Giao nhiệm vụ cụ thể
Thay vì để người thử tự khám phá, giao các nhiệm vụ ứng với use case chính, ví dụ đặt một lịch hẹn cho ngày mai, huỷ lịch đó, tìm lịch sử khám của một bệnh nhân. Ghi lại nhiệm vụ nào hoàn thành, mất bao lâu, vướng ở bước nào, người thử nói gì khi vướng.
Bảng hỏi sau buổi thử
Có thể dùng thang đo khả dụng phổ biến như System Usability Scale (SUS) gồm mười câu, kèm hai ba câu hỏi mở. Thang đo có sẵn giúp bạn không phải tự thiết kế câu hỏi và có cách tính điểm đã được mô tả trong tài liệu gốc; hãy trích dẫn nguồn khi dùng.
Trình bày lỗi còn tồn tại
Liệt kê, không giấu. Một bảng ngắn gồm lỗi, mức độ ảnh hưởng, điều kiện xảy ra, hướng xử lý. Hội đồng biết phần mềm nào cũng có lỗi; họ đánh giá bạn có biết lỗi của mình không.
Phân biệt lỗi và giới hạn phạm vi. Chức năng thanh toán trực tuyến không làm là giới hạn phạm vi; chức năng đặt lịch cho phép trùng giờ khi hai người bấm cùng lúc là lỗi.
Ghi điều đã sửa. Nếu lỗi phát hiện trong vòng kiểm thử đầu được sửa ở phiên bản sau, nói rõ, kèm kết quả kiểm thử lại.
Chuẩn bị cho buổi chạy thử trước hội đồng. Biết lỗi nằm ở đâu giúp bạn chọn kịch bản trình diễn tránh vùng chưa ổn định mà không phải giấu giếm, vì bảng lỗi đã nằm sẵn trong luận văn. Nếu hội đồng muốn xem đúng chỗ đó, bạn giải thích được nguyên nhân và hướng sửa thay vì lúng túng.
Trình bày kết quả đánh giá trong luận văn
Thứ tự gợi ý
Mở đầu bằng tóm tắt kế hoạch kiểm thử, tiếp theo là bảng tổng hợp kết quả theo nhóm yêu cầu (số ca, số đạt, số lỗi), rồi đến các ca tiêu biểu, kết quả đo hiệu năng, kết quả buổi dùng thử, và cuối cùng là bảng lỗi còn tồn tại. Người đọc đi từ bức tranh chung tới chi tiết.
Đọc kết quả, không chỉ đặt bảng
Dưới mỗi bảng, hai ba câu nói điều đáng chú ý: nhóm chức năng nào có nhiều lỗi nhất và vì sao, nhiệm vụ nào người dùng thử vướng nhiều nhất, phép đo nào gần ngưỡng. Những nhận xét này dẫn thẳng sang phần hạn chế và hướng phát triển ở kết luận.
Ví dụ một buổi dùng thử
Một sinh viên làm ứng dụng bán hàng cho nhà thuốc nhỏ mời chủ nhà thuốc và hai nhân viên dùng thử trong một buổi chiều. Cả ba hoàn thành nhiệm vụ bán thuốc lẻ, nhưng hai người không tìm được chức năng tra thuốc sắp hết hạn vì nó nằm sâu trong menu báo cáo. Sinh viên ghi điều này vào kết quả, chuyển chức năng ra màn hình chính ở phiên bản sau và mời một người thử lại. Đoạn kể này thuyết phục hội đồng hơn mọi con số trung bình.
Lỗi hay gặp ở chương đánh giá
Những điểm dưới đây hội đồng thường hỏi.
- Chỉ có câu “hệ thống chạy ổn định” mà không có ca kiểm thử.
- Ca kiểm thử chỉ có trường hợp nhập đúng, không có trường hợp nhập sai, dữ liệu biên.
- Người dùng thử là chính sinh viên trong nhóm phát triển.
- Đo hiệu năng một lần, không ghi cấu hình máy.
- Kết quả khảo sát người dùng thử chỉ có điểm trung bình, không có nhận xét nào.
Câu hỏi thường gặp
Khoá luận có bắt buộc viết kiểm thử tự động không?
Không phải trường nào cũng bắt buộc. Kiểm thử tự động cho các hàm xử lý chính là điểm cộng; kiểm thử chức năng thủ công có ca kiểm thử rõ ràng vẫn được chấp nhận.
Bao nhiêu ca kiểm thử là đủ?
Đủ khi mỗi yêu cầu chức năng chính có ca cho luồng đúng, luồng sai và trường hợp biên. Số lượng phụ thuộc quy mô hệ thống, không có con số chung.
Người dùng thử có cần ký phiếu đồng ý không?
Nên có một phiếu thông tin ngắn nêu mục đích, quyền dừng bất cứ lúc nào và cách bạn dùng ghi chép. Nếu ghi âm, ghi hình màn hình thì cần đồng ý rõ ràng.
Thang đo SUS có cần dịch sang tiếng Việt không?
Nếu người thử không quen tiếng Anh thì nên dịch, giữ nguyên ý từng câu và ghi rõ đã dịch. Nếu có bản dịch đã được công bố, dẫn nguồn bản dịch đó.
Có nên đưa lỗi chưa sửa được vào luận văn không?
Có. Ghi rõ lỗi, điều kiện xảy ra và hướng xử lý. Giấu lỗi rồi bị phát hiện khi chạy thử trước hội đồng gây ấn tượng xấu hơn nhiều.
Có cần đo hiệu năng cho ứng dụng nhỏ không?
Nên đo ít nhất những yêu cầu phi chức năng bạn đã đặt ra ở chương phân tích. Nếu không đặt yêu cầu nào về hiệu năng, hãy giải thích vì sao.