Một ví dụ về mô tả kiểu test:
Kỹ thuật:
Đối với chu trình sự kiện của mỗi UC, sẽ xác định một tập các giao dịch đại diện cho mỗi hành động của tác nhân khi thực hiện UC.
Tối thiểu phải có 2 TC cho mỗi giao dịch, một TC để phản ánh điều kiện tích cực và một phản ánh điều kiện tiêu cực (không được chấp nhận)
Trong giai đoạn đầu tiện, các UC 1-4 và 12 sẽ được test, theo hình thức sau:
UC 1 bắt đầu với tác nhân đã truy cập thành công vào ứng dụng và tại cửa sổ chính, và kết thúc khi người dùng xác định SAVE.
Mỗi TC sẽ được tiến hành và thực hiện bằng cách sử dụng Rational Robot.
Việc kiểm tra và đánh giá việc thực hiện mỗi TC sẽ được thực hiện theo phương pháp sau:
Thực hiện Test script (Mỗi test script có được thực hiện thành công như mong muốn không?)
Tình trạng Window hoặc phương pháp kiểm tra Object Data (tiến hành trong các test script) sẽ được dùng để kiểm tra sự hiển thị của các màn hình chính và dữ liệu được xác định được nắm bắt/hiển thị bởi mục tiêu test trong khi thực hiện test.
Cơ sở dữ liệu của các mục tiêu test (sử dụng Microsoft Access) sẽ được kiểm tra trước khi test và kiểm tra lại sau khi test để kiểm chứng rằng các thay đổi thực hiện trong quá trình test đã được phản ánh chính xác trong dữ liệu.
Với mỗi UC, xác định một tập các giao dịch, như định nghĩa trong tài liệu phân tích workload, sẽ được tiến hành và thực hiện bằng Rational Suite PerformanceStudio và Rational Robot (GUI scripts)
Ít nhất 3 workloaf được phản ánh trong test script và lịch trình thực hiện test, bao gồm:
Stressed workload: 750 người dùng (15 % quản lý, 50 % bán hàng, 35 % marketing)
Peak workload: 350 người dùng (10 % quản lý, 60 % bán hàng, 30 % marketing)
Nominal workload: 150 người dùng (2 % quản lý, 75% bán hàng, 23 % marketing)
Test script dùng để thực hiện mỗi giao dịch sẽ bao gồm bộ đếm thời gian tương tự để đo thời gian phản hồi, ví dụ tổng thời gian giao dịch (như định nghĩa trong tài liệu phân tích workload), và các hoạt động giao dịch chính hoặc thời gian xử lý.
Test script sẽ thực hiện các workload trong 1 giờ (trừ phi được ghi chú khác trong tài liệu phân tích workload).
Kiểm tra và đánh giá việc thực hiện mỗi thực hiện test (của một workload) bao gồm:
Thực hiện test được theo dõi bằng biểu đồ trạng thái (để xác định rằng việc test và workload được thực hiện như mong muốn)
Thực hiện test script (mỗi test script có được thực hiện thành công như mong đợi không?)
Ghi nhận và đánh giá thời gian phản hồi đã định nghĩa bằng các báo cáo sau:
- Performance Percentile
- Response Time
Điều kiện hoàn thành :
Tất cả các TC có trong kế hoạch đều đã được thực hiện
Tất cả các lỗi được xác định phải được ghi nhận vào một giải pháp đã thỏa thuận (All identified defects have been addressed to an agreed upon resolution)
Tất cả các TC có trong kế hoạch đã được thực hiện lại và toàn bộ các lỗi mở đã được ghi nhận như đã thỏa thuận và không có lỗi mới nào được phát hiện
Hoặc
Toàn bộ các TC đặt mức ưu tiên cao đều đã được thực hiện
Toàn bộ các lỗi tìm thấy đều được ghi nhận vào một giải pháp đã thỏa thuận
Toàn bộ các lỗi có trọng số 1 và 2 đều được giải quyết
Tất cả các TC có mức ưu tiên cao đều đã được thực hiện lại và toàn bộ các lỗi mở đã được ghi nhận như đã thỏa thuận và không có lỗi mới nào được phát hiện
Các vấn đề đặc biệt
- Cơ sở dữ liệu test yêu cầu người thiết kế hoặc quản trị CSDL hỗ trợ để tạo mới, cập nhật và làm tươi dữ liệu test
- Việc test hiệu suất hệ thống sử dụng máy chủ trong mạng hiện tại (có hỗ trợ cả các giao dịch khác không thuộc việc test). Việc test sẽ phải được lập lịch vào những giờ không còn các giao dịch khác trên mạng.
- Mục tiêu test phải đồng nhất với hệ thống hợp lệ (hoặc giả lập đồng bộ) để việc test chức năng có thể được tiến hành và thực hiện
- Việc test có thể bị dừng khi
- Cán bộ test có thể dừng test khi lập trình viên không thực hiện unit test, ...
>
Test chức năng (Function Testing)
| Mục đích test: | <Đảm bảo mục tiêu test đúng đắn của chức năng, bao gồm định hướng, dữ liệu đầu vào, xử lý và dữ liệu nhận được> |
| Cách thực hiện: | |
| Điều kiện hoàn thành: | - |
| Các vấn đề đặc biệt: | |
>
Test giao diện người sử dụng (User Interface Testing)
| Mục đích test: | |
| Cách thực hiện: | |
| Điều kiện hoàn thành: | |
| Các vấn đề đặc biệt: | |
Test dữ liệu và tích hợp dữ liệu (Data and Database Integrity Testing)
| Mục đích test: | <Đảm bảo rằng các phương pháp truy cập và chức năng xử lý là đúng và không có sai lệch dữ liệu> |
| Cách thực hiện: | |
| Điều kiện hoàn thành: | |
| Các vấn đề đặc biệt: | |
>
Test chu trình nghiệp vụ (Business Cycle Testing)
| Mục đích test: | <Đảm bảo mục đích của test là đúng đắn và các tiến trình chạy ngầm thực hiện đúng yêu cầu về mô hình nghiệp vụ và lịch trình> |
| Cách thực hiện: | |
| Điều kiện hoàn thành: | |
| Các vấn đề đặc biệt: | |
Test hiệu suất (Performance testing)
Performance Profiling
Chú ý: Các giao dịch dưới đây tham chiếu đến “các giao dịch nghiệp vụ logic”. Các giao dịch này được định nghĩa như xác định các UC mà tác nhân của hệ thống hy vọng được thực hiện bằng cách sử dụng mục tiêu test, như thêm mới hoặc sửa một hợp đồng>
| Mục đích test: | |
| Cách thực hiện: | |
| Điều kiện hoàn thành: | |
| Các vấn đề đặc biệt: | |
Load Testing
| Mục tiêu test: | |
| Cách thực hiện: | |
| Điều kiện hoàn thành: | |
| Các vấn đề đặc biệt: | |
Stress Testing
| Mục đích test: | |
| Cách thực hiện: | |
| Điều kiện hoàn thành: | |
| Các vấn đề đặc biệt: | |
Volume Testing
| Mục đích test: | |
| Cách thực hiện: | |
| Điều kiện hoàn thành: | |
| Các vấn đề đặc biệt: | |
Test Bảo mật và Kiểm soát truy cập (Security and Access Control Testing)
- Bảo mật ở mức ứng dụng, bao gồm truy cập dữ liệu và các chức năng nghiệp vụ
- Bảo mật ở mức hệ thống, bao gồm truy cập vào hệ thống hoặc truy cập từ xa
Bảo mật mức ứng dụng đảm bảo rằng, dựa trên bảo mật đã yêu cầu, người dùng bị hạn chế sử dụng một số chức năng hoặc tình huống sử dụng, hoặc bị hạn chế trong giới hạn dữ liệu phù hợp với họ. Ví dụ, mọi người có thể được phép nhập dữ liệu để tạo account nhưng chỉ có người quản lý có thể xóa chúng. Nếu là bảo mật ở mức dữ liệu, việc test đảm bảo rằng “người dùng nhóm 1” có thể nhìn thấy các thông tin khách hàng, bao gồm dữ liệu tài chính, tuy nhiên “người dùng nhóm 2” chỉ nhìn thấy các thông tin chung chung cho cùng một khách hàng.
Bảo mật mức hệ thống đảm bảo rằng chỉ những người dùng được cho quyền truy cập vào hệ thống mới có khả năng truy cập vào ứng dụng và chỉ bằng các cổng thích hợp
>
| Mục đích test: | Bảo mật mức ứng dụng: Đảm bảo rằng một người dùng chỉ có thể truy cập vào những chức năng hoặc dữ liệu mà nhóm người dùng đó được phép Bảo mật mức hệ thống: Đảm bảo rằng chỉ những người được phép truy cập hệ thống và ứng dụng được phép truy cập chúng |
| Cách thực hiện: | Bảo mật ứng dụng: Xác định và liệt kê từng nhóm người dùng và các chức năng hoặc dữ liệu mà họ được phép truy cập Tạo test case cho mỗi nhóm người dùng và kiểm tra từng quyền bằng cách tạo các giao dịch xác định cho mỗi nhóm Sửa lại nhóm người dùng và chạy lại tình huống test cho cùng những người dùng. Với mỗi trường hợp, kiểm tra các chức năng thêm vào hoặc dữ liệu có đúng không hay bị từ chối. Truy cập mức hệ thống: tham khảo các điều kiện đặc biệt dưới đây |
| Điều kiện hoàn thành: | |
| Các vấn đề đặc biệt: | |
Test hồi qui (Regression Testing)
| Mục đích test: | Test hồi qui dùng để kiểm tra các phần được sửa chữa 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: | . > <80% các TC được chọn ngẫu nhiên> |
| Điều kiện hoàn thành: | |
| Các vấn đề đặc biệt: | |
