III.1. Chiến lược kiểm thử
III.1.1. Kiểm thử giao diện người sử dụng (User Interface Testing)
Kiểm thử giao diện người sử dụng (UI) mục đích là kiểm tra so sánh giao diện phát triển so với thiết kế ban đầu và yêu cầu khách hàng, đảm bảo hoạt động của các thành phần trên giao diện. Bên cạnh đó cần đảm bảo tính thẩm mỹ, tiện dụng cho người dùng.
Mục đích: Mục đích đảm bảo:
- Việc sử dụng thông qua mục tiêu kiểm thử phản ánh đúng các chức năng và yêu cầu nghiệp vụ, bao gồm màn hình đến màn hình, trường đến trường và sử dụng các phương pháp truy cập (phím tabs, di chuột, tổ hợp phím)
- Các đối tượng và thuộc tính màn hình như menus, size, position, state và tập trung vào việc tương thích yêu cầu
Cách thực hiện: Tạo ra và chỉnh sửa kịch bản kiểm thử cho mỗi màn hình để kiểm tra
việc sử dụng đúng cách và tình trạng các đối tượng cho mỗi màn hình và đối tượng của ứng dụng
Kiểm tra giao diện hiển thị dựa trên đúng các điều kiện môi trường & cấu hình yêu cầu.
Điều kiện hoàn thành:
Mỗi màn hình được kiểm tra đảm bảo đúng với phiên bản kiểm tra hoặc phạm vi chấp nhận được
<PSTM>
KẾ HOẠCH KIỂM THỬ Phiên bản: 1.0
Lưu ý: Việc hiển thị các trường thông tin trên giao diện có thể gắn với phân
quyền người dùng.
III.1.2. Kiểm thử luồng nghiệp vụ (Business Flow Testing)
Kiểm thử luồng nghiệp vụ căn cứ trên các tài liệu yêu cầu nghiệp đặc thù của từng ứng dụng. Mục tiêu của kiểu kiểm thử này là kiểm tra tính đúng đắn của các dữ liệu, qui trình và báo cáo cũng như việc thực hiện đúng những qui tắc nghiệp vụ. Bảng sau liệt kê một số gợi ý đối với mỗi ứng dụng:
Mục đích: Kiểm thử luồng nghiệp vụ đảm bảo các yêu cầu sau:
- Các công thức tính toán và điều kiện ràng buộc xử lý đúng. - Luồng nghiệp vụ đúng.
- Quá trình xử lý dữ liệu và kết quả đầu ra phải đúng. - Phục hồi được dữ liệu.
Cách thực hiện: Thực hiện các chức năng, sử dụng các dữ liệu hợp lệ và
không hợp lệ để kiểm tra. Cụ thể như sau: - Kết quả mong đợi với dữ liệu hợp lệ.
- Đưa ra các cảnh báo với dữ liệu không hợp lệ.
- Các qui tắc nghiệp vụ đã được thỏa thuận đều được áp dụng đúng
Điều kiện hoàn thành:
Toàn bộ kế hoạch kiểm thử đã được thực hiện.
Các vấn đề đặc biệt:
Xác định hoặc mô tả các vấn đề (nội bộ hoặc bên ngoài) ảnh hưởng đến việc kiểm thử chức năng
III.1.3. Kiểm thử dữ liệu và tích hợp dữ liệu (Data and Database Integrity Testing)
Cơ sở dữ liệu và xử lý cơ sở dữ liệu phải đảm bảo đúng với thiết kế dữ liệu đã thống nhất. Nghiên cứu thêm về DBMS để xác định các công cụ và kỹ thuật có thể có giúp hỗ trợ cho việc kiểm thử:
Mục đích: Đảm bảo rằng việc lưu trữ, thao tác, truy vấn thông tin được trả lại
đúng như đặc tả yêu cầu.
Cách thực hiện: Thực hiện kiểm tra thiết kế cơ sở dữ liệu
Thực hiện truy vấn, thao tác (thêm/sửa/xóa/tìm kiếm) để đảm bảo dữ liệu đang trả về đúng.
Điều kiện hoàn thành:
Tất cả các phương pháp truy cập và chức năng xử lý đều giống như thiết kế và không có sai lệch dữ liệu.
<PSTM>
KẾ HOẠCH KIỂM THỬ Phiên bản: 1.0
Phân quyền đủ để thực hiện đủ các thao tác dữ liệu (nếu có phân quyền)
Cơ sở dữ liệu có kích thước nhỏ hoặc tối thiểu (giới hạn số bản ghi) phải được dùng để làm rõ thêm các sự kiện không được phép chấp nhận
III.1.4. Kiểm thử hồi quy (Regression Testing)
Kiểm thử hồi quy là một hoạt động cấn thiết với các hệ thống bảo trì hoặc nâng cấp, mục đích đảm bảo hệ thống hoạt động tốt khi có sự thay đổi, cập nhật của 1 số module.
Mục đích: Kiểm thử hồi qui dùng để kiểm tra các phần được sửa chữa, thêm
mới trong phần mềm, để đảm bảo rằng những sự thay đổi đó không gây ra lỗi trong những phần khác
Cách thực hiện: Tái sử dụng các TC từ những phần kiểm thử trước để kiểm thử các
module đã được sửa chữa
80% các TC được chọn ngẫu nhiên
Thực hiện các TC tương tác giữa các module để đảm bảo hệ thống hoạt động tốt.
Điều kiện hoàn thành:
Toàn bộ các trường hợp kiểm thử được thực hiện và đạt yêu cầu Toàn bộ các trường hợp kiểm thử được chọn được thực hiện và đạt yêu cầu
Các vấn đề đặc biệt: Đòi hỏi hiểu biết về hệ thống.
III.1.5. Kiểm thử hiệu năng (Performance Testing)
Kiểm thử hiệu năng nhằm kiểm tra và đánh giá thời gian phản hồi, tỉ lệ giao dịch, và các yêu cầu liên quan tới thời gian khác. Mục tiêu của kiểm thử hiệu năng là nhằm để xác minh các yêu cầu về hiệu năng như wordload hoặc cấu hình phần cứng.
Lưu ý: Giao dịch (transacton) ở đây là “logical business transactions”. Các giao dịch này được định nghĩa như một chức năng cụ thể như đăng kí tín chỉ.
Mục đích: Xác minh hiệu năng của các hành vi cho các giao dịch đã thiết kế
hoặc chức năng nghiệp vụ theo các điều kiện:
- Workload trường hợp dự đoán là thông thường
- Workload trường hợp dự đoán là xấu nhất
-
Cách thực hiện: Sử dụng các test case đã viết cho các chức năng hoặc luồng nghiệp
vụ:
- Sửa file dữ liệu để tăng số giao dịch hoặc script để tang số lần lặp của mỗi giao dịch xảy ra
- Script cần chạy trên 1 máy (Single user, single transaction) và lặp lại với nhiều khách hàng (ảo hoặc thực, xem Các vấn đề đặc biệt bên dưới)
<PSTM>
KẾ HOẠCH KIỂM THỬ Phiên bản: 1.0
Điều kiện hoàn thành:
Single transaction or single user: hoàn thành test script mà không bị lỗi với thời gian mong muốn cho mỗi giao dịch
Mulitple transaction or multiple users: hoàn thành test script mà không bị lỗi nào trong thời gian cho phép.
Các vấn đề đặc biệt: Thực hiện kiểm thử hiệu năng bao gồm cả các workload trên server.
Có một số cách để thực hiện, bao gồm:
- “drive transaction” trực tiếp tới server, thường là các lời gọi SQL
- Tạo các người dùng ảo để mô phỏng nhiều người dùng
(thường là vài trăm người), có thể sử dụng các công cụ mô phỏng.
- Sử dụng nhiều người dùng thật, mỗi người chạy các test
scripts ở 1 địa điểm
Kiểm thử hiệu năng nên được thực hiện trên 1 máy điển hình vào thời gian điển hình để có đánh giá chính xác.
Cơ sở dữ liệu sử dụng cho kiểm thử hiệu năng nên có kích thước đủ lớn hoặc kích thước thật.
III.1.6. Kiểm thử bảo mật và truy cập (Security and Access Control Testing)
Kiểm thử bảo mật và truy cập có 2 mục tiêu:
Bảo mật mức ứng dụng, bao gồm truy cập tới dữ liệu hoặc các tính năng nghiệp vụ Bảo mật mức hệ thống, bao gồm đăng nhập vào hệ thống hoặc truy cập hệ thống từ xa Bảo mật mức ứng dụng đảm bảo chỉ người được phân quyền mới có quyền truy cập dữ liệu hoặc tính năng tương ứng. Ví dụ, ai cũng được phép nhập thông tin và tạo tài khoản, nhưng chỉ managers mới có quyền xoá. Nếu có bảo mật mức dữ liệu, kiểm thử đảm bảo là “người dùng loại 1” có thể xem toàn bộ thông tin khách hàng, nhưng “người dung loại 2” thì không.
Bảo mật mức hệ thống đảm bảo là chỉ các người dùng được cấp phép được quyền truy cập vào hệ thống.
Mục đích: Bảo mật mức ứng dụng đảm bảo chỉ người được phân quyền
mới có quyền truy cập dữ liệu hoặc tính năng tương ứng. Bảo mật mức hệ thống đảm bảo là chỉ các người dùng được cấp phép được quyền truy cập vào hệ thống
Cách thực hiện: Bảo mật mức ứng dụng: xác định và liệt kê với mỗi loại người dùng
các chức năng, dữ liệu mà được quyền truy cập
Tạo ca kiểm thử cho mỗi loại người dùng và xác minh quyền bằng các tạo các transactions cho từng loại người dùng.
Chỉnh sửa loại người dùng và chạy lại ca kiểm thử cho đúng người dung này. Sau đó, xác minh các chức năng, dữ liệu thay đổi có được thêm/xoá chính xác hay không.
<PSTM>
KẾ HOẠCH KIỂM THỬ Phiên bản: 1.0
Bảo mật mức hệ thống: Xem nội dung <Các vấn đề đặc biệt>
Điều kiện hoàn thành:
Với mỗi loại người dùng, các chức năng và dữ liệu được truy cập hoạt động đúng.
Các vấn đề đặc biệt: Truy cập vào hệ thống phải được review với mạng thích hợp hoặc
quản trị hệ thống. Kiểm thử này có thể không cần thiết nếu là một tính năng của mạng hoặc systems administration.
III.2. Quy trình kiểm thử
Thực hiện kiểm thử tích hợp cho các chức năng, module đã liệt kê trong mục II.1 trên môi trường test. Lưu ý:
- Khi viết testcase loại bỏ các “Bước kiểm thử” để tiết kiệm thời gian. - Dự án không thực hiện kiểm thử tự động nên không tạo test script Quy trình kiểm thử:
- Step 1: Đội tester xây dựng checklist test chung cho toàn dự án, PM review - Step 2: Đội tester xây dựng testcases cho từng chức năng, Test Leader review
- Step 3: SelftTest của dev. Do loại bỏ bước unit test, nên Dev cần tự review chức năng của mình trước khi chuyển sang đội Test
- Step 4: Test của đội Tester -
III.3. Phương pháp kiểm soát
Việc kiểm soát lỗi được đề xuất như sau: Công cụ log bug: Excel + Skype + Redmine Quy trình kiểm soát lỗi:
- Step 1: Tester log lỗi vào Redmine
- Step 2: Tester skype với DEV để nhắc check bug trên Redmine & trao đổi trong quá trình sửa lỗi.
- Step 3: Dev & Tester làm việc, update Bug trên redmine theo quy trình sửa lỗi (PSTM_CRM_RedmineHelpv1.0.pdf)
III.4. Testing convention
- Quy tắc đặt mã Test cases: T<mã chức năng>_<Tên chức năng viết tắt>_<số>
- Quy tắt đặt tên file test cases: <TC><mã chức năng>_<Tên chức năng>_<ngày tháng> _v<version>
- Quy tắc đặt tên sheets: <đánh số><mô tả>
- Thống nhất template test cases: check file template đính kèm
- Thống nhất template Test report: : check file template đính kèm
- Check list review test cases cho từng loại test ở III.1.x : check file template đính kèm
- Template để chuẩn bị data test: : check file template đính kèm
III.5. Kế hoạch chuẩn bị dữ liệu kiểm thử
Tên/ Loại dữ liệu Điều kiện của dữ liệu Người thu thập dữ liệu Phương thức thu thập dữ liệu Người/ Đơn vị cung cấp dữ liệu Ngày thu thập
<PSTM>
KẾ HOẠCH KIỂM THỬ Phiên bản: 1.0
N/A N/A N/A N/A N/A N/A
III.6. Kế hoạch báo cáo
STT Loại báo cáo Thời gian báo
cáo Hình thức báo cáo Người báo cáo Người nhận báo cáo 1 Báo cáo định
kỳ 2 tuần/lần Email Đỗ Thị Bích Ngọc - - PM Đội dự án 2
Báo cáo kết
thúc chức năng Khi kết thúc kiểm thử 1 chức năng
Email Đỗ Thị Bích
Ngọc - - PM Đội dự án 3 Báo cáo kết
thúc giai đoạn Khi kết thúc giai đoạn Email Đỗ Thị Bích Ngọc - - PM Đội dự án 4 Báo cáo kết
thúc dự án Khi kết thúc dự án Email Đỗ Thị Bích Ngọc
- PM - Đội dự án
III.7. Công cụ kiểm thử
STT Công cụ Mục đích Ghi chú
1. Microsoft Office Lịch trình N/A
2. Trình duyệt web: FF,
Chrome Thực hiện kiểm thử trên trình duyệt N/A
3. Excel Quản lý lỗi N/A
4. Gmail Quản lý lỗi , Trao đổi nghiệp vụ với dự án N/A
5. Skype Quản lý lỗi , Trao đổi nghiệp vụ với dự án N/A
6. Jmeter Kiểm thử hiệu năng N/A
III.8. Tiêu chuẩn kiểm thử
- Điều kiện bắt đầu thực hiện kiểm thử
Công việc kiểm tra phần mềm bắt đầu được thực hiện khi các điều kiện sau thỏa mãn: + Theo kế hoạch kiểm thử đã thống nhất.
+ Dự án đã hoàn thành review code và selft check cho module tương ứng.
+ Dự án hoàn thành việc cài đặt trên server và bàn giao chức năng/module cần kiểm tra cho nhóm Test.
- Điều kiện dừng quá trình kiểm thử
<PSTM>
KẾ HOẠCH KIỂM THỬ Phiên bản: 1.0
+ Đạt được ngưỡng kiểm thử thành công.
+ Dự án bị hủy/ tạm ngừng (do chương trình build không đạt, hoặc theo chỉ đạo). + Hết thời gian kiểm thử.
- Tiêu chuẩn kiểm thử thành công
+ 100% Intergration test case được thực hiện
+ 95% các lỗi trên được đóng; không còn lỗi Fatal, Serious đang mở - Điều kiện thực hiện kiểm thử hồi quy
Khi có sự thay đổi về mã nguồn hoặc môi trường phần mềm.