Phần mềm quản lý ký túc xá Test Plan

Trang 1

PHẦN MỀM QUẢN LÝ KÝ TÚC XÁ

TEST PLAN Phiên bản 1.0

Trang 2

Revision History

Date Version Description Author

30/03/2011 1.0 Viết mục lục cho Test Plan Lâm Quang Thiện 30/03/2011 1.0.1 Thêm vào 1 số thông tin chi tiết Lâm Quang Thiện 02/04/2011 1.0.2 Thêm vào thông tin các phương thức kiểm

thử

Lâm Quang Thiện

MỤC LỤC

1 Giới thiệu

1.1 Mục đích

1.2 Phạm vi

1.3 Độc giả hướng tới

1.4 Các thuật ngữ và từ chuyên môn

1.5 Các tài liệu tham khảo

1.6 Cấu trúc tài liệu

2 Chiến lược đánh giá và động lực kiểm thử

2.1 Các thông tin sơ lược

2.2 Chiến lược đánh giá

2.3 Động lực kiểm thử

3 Những đối tượng sẽ được kiểm thử

4 Mục lục những phần sẽ được kiểm thử

4.1 Mục lục những phần sẽ được thực hiện kiểm thử

4.2 Mục lục những phần tiềm năng, có thể đưa vào kiểm thử

4.3 Mục lục những phần sẽ không đưa vào kiểm thử

5 Hướng tiếp cận kiểm thử

5.1 Những ý tưởng đầu tiên và những nguồn tài nguyên tham khảo

5.2 Các loại kiểm thử và phương thức kiểm thử

5.2.1 Kiểm thử dữ liệu và kết nối CSDL

5.2.2 Kiểm thử các chức năng

5.2.3 Kiểm thử giao diện người dùng

Trang 3

6 Điều kiện vào và ra

6.1 Kế hoạch kiểm thử

6.1.1 Điều kiện bắt đầu kế hoạch kiểm thử

6.1.2 Điều kiện kết thúc kế hoạch kiểm thử

6.1.3 Điều kiện tạm dừng và tiếp tục

6.2 Vòng lặp kiểm thử

6.2.1 Điều kiện bắt đầu vòng lặp

6.2.2 Điều kiện kết thúc vòng lặp

6.2.3 Điều kiện hủy vòng lặp khi có bất thường

7 Thành phẩm

7.1 Những tóm tắt đánh giá kiểm thử

7.2 Báo cáo về mức độ phủ

7.3 Báo cáo về chất lượng đạt được

7.4 Ghi chú các sự kiện và thay đổi

7.5 Bộ kiểm thử Smoke Test và những mã test hỗ trợ

7.6 Những thành phẩm khác

7.6.1 Kết quả kiểm thử chi tiết

7.6.2 Những mã test chức năng tự động khác

7.6.3 Hướng dẫn kiểm thử

7.6.4 Ma trận lần vết

8 Tiến trình kiểm thử

9 Những yêu cầu về môi trường kiểm thử

9.1 Phần cứng cơ bản cho hệ thống

9.2 Các yếu tố phần mềm cơ bản trong môi trường kiểm thử

9.3 Các công cụ hỗ trợ

9.4 Các cấu hình cho môi trường kiểm thử

10 Trách nhiệm, đội ngũ làm việc và huấn luyện

10.1 Các thành viên và vai trò

10.2 Đội ngũ làm việc và nhu cầu huấn luyện

11 Các mốc sự kiện quan trọng

12 Những rủi ro, phụ thuộc, giả định và ràng buộc

13 Quá trình quản lý

13.1 Đo lường và định mức quy mô của quá trình kiểm thử

Trang 4

13.2 Định mức thành phẩm của kế hoạch kiểm thử

13.3 Báo cáo lỗi và cách giải quyết

13.4 Quản lý vòng lặp kiểm thử

13.5 Chiến lược lần vết

13.6 Xác nhận và ký tên

Trang 5

1 Giới thiệu

1.1 Mục đích

Mục đích của Test Plan là để tập hợp tất cả các thông tin cần thiết để lên kế hoạch và kiểm sáot quá trình thực hiện kiểm thử hệ thống phần mềm quản lý ký túc xá Tài liệu này mô tả hướng tiếp cận để kiểm thử, cùng với kế hoạch chi tiết để người quản lý có thể hướng dẫn thực hiện quá trình kiểm thử

Test plan cho hệ thống phần mềm quản lý ký túc xá bao gồm những mục tiêu sau:

_ Xác định rõ những đối tượng được kiểm thử

_ Xác định rõ động lực và ý tưởng cho từng khu vực kiểm thử

_ Chỉ ra những hướng tiếp cận kiểm thử sẽ được sử dụng

_ Xác định những tài nguyên cần thiết và ước lượng công sức kiểm thử

_ Liệt kê những kết quả của quá trình kiểm thử

1.2 Phạm vi

Các mức độ kiểm thử:

_ Kiểm thử đơn vị

_ Kiểm thử tích hợp

Các loại kiểm thử:

_ Chức năng

_ Độ dễ sử dụng

_ Độ tin cậy

_ Hiệu năng

_ Mức độ hỗ trợ

1.3 Những độc giả hướng đến

Những đối tượng độc giả sẽ đọc tài liệu Test Plan này:

_ Các thành viên trong nhóm Testing: 2 và 6

_ Các thành viên trong nhóm coding

_ Các thành viên còn lại trong nhóm lớn I

_ Giáo viên phụ trách: thầy Ngô Huy Biên

1.4 Các thuật ngữ và từ chuyên môn

Không có

1.5 Các tài liệu tham khảo

Tài liệu Test plan này có tham khảo từ một số nguồn như:

_ Template Test Plan của RUP

_ Template Test Plan của Zonest

Trang 6

1.6 Cấu trúc tài liệu

Tham khảo phần mục lục

2 Chiến lược đánh giá và động lực kiểm thử

2.1 Các thông tin sơ lược

Test Plan này được thực hiện để kiểm thử dự án hệ thống phần mềm quản lý ký túc xá Sau khi kế hoạch kiểm thử được hoành thành, hệ thống phần mềm quản lý ký túc xá có thể hoạt động tốt và hiệu quả hơn, tin cậy hơn

2.2 Chiến lược đánh giá

Chiến lược đánh giá:

_ Tìm ra càng nhiều lỗi càng tốt

_ Tìm được những lỗi quan trọng, gây rủi ro về chất lượng

_ Xác thực những đặc tả, yêu cầu, thiết kế,

2.3 Động lực kiểm thử

Các động lực để thực hiện kiểm thử: những rủi ro về chất lượng, kỹ thuật, các chức năng của phần mềm,

3 Những đối tượng sẽ được kiểm thử

4 Mục lục những phần sẽ được kiểm thử

4.1 Mục lục những phần sẽ được thực hiện kiểm thử

4.2 Mục lục những phần tiềm năng, có thể đưa vào kiểm thử

4.3 Mục lục những phần sẽ không đưa vào kiểm thử

5 Hướng tiếp cận kiểm thử

5.1 Những ý tưởng đầu tiên và những nguồn tài nguyên tham khảo

5.2 Các loại kiểm thử và phương thức kiểm thử

5.2.1 Kiểm thử dữ liệu và kết nối CSDL Quá trình kiểm thử dữ liệu và cơ sở dữ liệu nên được tiến hành như một hệ thống độc lập Quá trình kiểm thử này sẽ kiểm tra hệ thống con đó mà không có giao diện người dùng

Technique Objective: Thực hiện các phương thức truy cập cơ sở dữ liệu và xử lý độc lập với

giao diện để có thể quan sát và ghi nhận lại những biểu hiện chức năng không đúng hoặc dữ liệu bị hư hỏng

Trang 7

Technique: Kỹ thuật:

_ Gọi lần lượt từng phương thức xử lý và truy cập cơ sở dữ liệu, đưa vào mỗi lần những dữ liệu hợp lệ và không hợp lệ, hoặc gửi yêu cầu lấy

dữ liệu

_ Kiểm tra cơ sở dữ liệu để chắc chắn rằng dữ liệu đã được điền vào đúng như mong muốn và tất cả các sự kiện trong cơ sở dữ liệu đã diễn

ra đúng cách, hoặc kiểm tra dữ liệu được trả về để chắc rằng đúng dữ liệu đã được trả về cho đúng lý do

Oracles: Cơ chế, nguyên tắc phát hiện lỗi: Tự động chạy các đoạn mã đánh giá

để xem bài kiểm tra pass hay fail

Cần cẩn thận với những rủi ro của test tự động

Required Tools: Các công cụ cần thiết:

_ Microsoft SQL Server

_ Công cụ tạo dữ liệu tự động

_ Công cụ chạy mã kiểm tra tự động

Success Criteria: Điều kiện thành công: Tất cả những phương pháp truy xuất và xử lý cơ

sở dữ liệu được hỗ trợ và kiểm tra thành công

Special Considerations: _ Cần có một môi trường phát triển DBMS hoặc drivers để thêm hoặc

sửa dữ liệu trực tiếp trong cơ sở dữ liệu

_ Các xử lý nên được gọi thủ công

_ Cơ sở dữ liệu nhỏ với số lượng dữ liệu có hạn nên được dùng để tăng

sự dễ nhìn cho các sự kiện không được chấp nhận

5.2.2 Kiểm thử các chức năng

Kiểm tra chức năng nên tập trung trên bất cứ chức năng nào có thể lần vết trực tiếp về use case hoặc chức năng nghiệp vụ và các quy định nghiệp vụ Mục tiêu của những bài kiểm tra này là để xác nhận việc xử lý, chấp nhận , lấy dữ liệu và cài đặt các quy định nghiệp vụ được đúng đắn

Trang 8

Technique Objective: Kiểm tra những chức năng, bao gồm di chuyển, nhập, xử lý, và rút trích

dữ liệu để quan sát và ghi nhận những hành vi của hệ thống

Technique: Kiểm tra từng dòng use case của từng trường hợp use case, hoặc những

chức năng, dùng những dữ liệu hợp lệ và không hợp lệ, để xác nhận:

_ Kết quả mong đợi được xuất hiện khi dữ liệu hợp lệ được dùng

_ Lỗi hoặc cảnh báo tương ứng được hiển thị khi dữ liệu không hợp lệ được dùng

_ Mỗi quy định nghiệp vụ được áp dụng đúng cách

_ Microsoft Visual Studio

_ Microsoft SQL Server

Success Criteria: Điều kiện thành công:

_ Tất cả những trường hợp sử dụng được kiểm tra

_ Tất cả những chức năng được kiểm tra

Special Considerations:

5.2.3 Kiểm thử giao diện người dùng

Kiểm tra giao diện xác nhận những tương tác của người dùng với hệ thống Mục tiêu là

để chắc chắn rằng giao diện người dùng cung cấp cho người dùng những truy xuất hợp lệ và những chức năng hợp lệ Kiểm tra giao diện còn chắc chắn rằng những đối tượng trong giao diện hoạt động đúng như mong muốn và đúng theo chuẩn

Trang 9

Technique Objective: Kiểm tra những thứ sau để quan sát và ghi nhận những hành vi hệ

thống:

_ Chuyển qua lại giữa các chức năng và yêu cầu thể hiện nghiệp vụ, bao gồm chuyển giữa các cửa sổ, giữa các trường nhập liệu, và dùng các phương thức truy cập (phím tab, di chuyển chuột, phím mũi tên, )

_ Các đối tượng và thuộc tính của Windows như menu, kích thước, vị trí, trạng thái,

Technique: Kỹ thuật kiểm tra: tạo hoặc sửa đổi bài kiểm tra cho từng cửa sổ để xác

nhận việc chuyển đổi đúng cách và các trạng thái của đối tượng cho từng ứng dụng

Success Criteria: Điều kiện thành công: hỗ trợ kiểm tra từng màn hình chính mà người

dùng sẽ dùng nhiều

Special Considerations: Không phải mọi thuộc tính của các đối tượng có thể truy cập được.

5.2.4 Kiểm thử sức chịu đựng

Kiểm tra sức chịu đựng là kiểm kiểm tra hiệu suất được cài đặt và chạy để hiểu được cách hệ thống fail do những điều kiện ở biên, hoặc bên ngoài vùng cho phép Thường có tài nguyên thấp Điều kiện tài nguyên thấp sẽ để lộ ra cách mà hệ thống fail Những lỗi khác có thể

là do tranh giành tài nguyên chung, như khóa cơ sở dữ liệu hoặc băng thông mạng

Trang 10

Technique Objective: Kiểm tra những chức năng của hệ thống trong những điều kiện quá giới

hạn để quan sát và ghi nhận những hành vi thể hiện những điều kiện hệ thống fail

_ Rất ít hoặc không còn bộ nhớ trên server

_ Số lượng tối đa client truy cập kết nối tại 1 thời điểm

_ Nhiều người dùng thực hiện cùng 1 giao tác tới 1 cùng 1 lượng dữ liệu hoặc tài khoản

Technique: Kỹ thuật kiểm tra:

_ Dùng những bài kiểm tra được phát triển cho kiểm tra hiệu năng và tải

_ Để kiểm tra những tài nguyên có giới hạn, bài kiểm tra nên được chạy trên một máy tính duy nhất, và RAM và dung lượng chứa trên server nên được giảm hoặc giới hạn

_ Cho những bài kiểm tra còn lại, nhiều client nên được dùng, hoặc chạy cùng 1 bài kiểm tra hoặc thể hiện trường hợp giao tác xấu nhất

_ Công cụ quản lý và chạy transaction theo lịch trình

Success Criteria: Điều kiện thành công: kỹ thuật hỗ trợ kiểm tra giả lập Hệ thống có thể

được giả lập thành công trong 1 hay nhiều điều kiện quá giới hạn và có thể ghi nhận lại tình trạng hệ thống

Trang 11

Special Considerations: _ Đưa mạng đi quá giới hạn có thể cần những công cụ mạng để làm tràn

mạng bằng những thông điệp và gói tin

_ Dung lượng cho hệ thống nên tạm thời bị giảm để giảm dung lượng

cơ sở dữ liệu

_ Đồng bộ hóa những client ở cùng thời điểm

5.2.5 Kiểm thử kiểm soát truy cập và bảo mật

Kiểm tra bảo mật và quản lý truy cập tập trung vào 2 khu vực chính của bảo mật:

_ Bảo mật mức ứng dụng, bao gồm bảo mật dữ liệu hoặc chức năng nghiệp vụ

_ Bảo mật mức hệ thống, bao gồm truy cập trực tiếp hoặc gián tiếp vào hệ thống

Bảo mật mức ứng dụng bảo đảm rằng các actor bị giới hạn vào một số chức năng hoặc use case cụ thể, hoặc bị giới hạn trong dữ liệu có sẵn Ví dụ ai cũng có thể nhập dữ liệu và tạo tài khoản, nhưng chỉ người quản lý có thể xóa chúng

Bảo mật mức hệ thống bảo đảm rằng chỉ những người được cho phép truy cập vào hệ thống có thể truy cập các ứng dụng và chỉ qua các cổng giao tiếp hợp lý

Technique Objective: Kiểm tra hệ thống trong những điều kiện sau để quan sát và ghi nhận lại

các hành vi:

_ Bảo mật mức ứng dụng: một actor có thể truy xuất chỉ những chức năng và dữ liệu được cho phép

_ Bảo mật mức hệ thống: chỉ những actor với quyền truy xuất hệ thống

và ứng dụng mới có quyền truy nhập chúng

Trang 12

Technique: Kỹ thuật kiểm tra:

_ Bảo mật mức ứng dụng: chỉ ra và liệt kê mỗi loại người dùng và chức năng hoặc dữ liệu tương ứng

+ Tạo những bài kiểm tra cho từng loại người dùng và xác nhận từng quyền bằng cách tạo các giao tác tới từng loại người dùng cụ thể

+Chỉnh sửa loại người dùng và chạy lại các bài test cho cùng những người dùng đó Trong từng trường hợp, kiểm tra những chức năng hoặc

dữ liệu thêm vào được có sẵn hoặc từ chối đúng cách

_ Bảo mật mức hệ thống

_ Công cụ chạy đoạn mã kiểm tra tự động

_ Các công cụ thử nghiệm hacker

_ Các công cụ quản trị hệ thống

Success Criteria: Điều kiện thành công: kỹ thuật hỗ trợ kiểm tra từng loại actor mà dữ

liệu và chức năng tương ứng có thể kiểm tra được

Special Considerations: Truy cập vào hệ thống phải được xem xét và thảo luận với người quản

trị mạng hoặc hệ thống tương ứng Bước kiểm tra này có thể không cần thiết vì nó có thể là một chức năng của mạng hoặc hệ thống