1.Tổng quát

1.1 Định nghĩa

Một kế hoạch kiểm thử dự án phần mềm (test plan) là một tài liệu mô tả các mục tiêu, phạm vi, phương pháp tiếp cận, và tập trung vào nỗ lực kiểm thử phần mềm. Quá trình chuẩn bị test plan là một cách hữu ích để suy nghĩ tới những nỗ lực cần thiết để xác nhận khả năng chấp nhận một sản phẩm phần mềm. Các tài liệu đã hoàn thành sẽ giúp mọi người bên ngoài nhóm test hiểu được ‘tại sao’ và ‘như thế nào’ chấp nhận sản phẩm. Nó cần phải hoàn hảo đủ để dùng được nhưng không đủ hoàn hảo vì không ai bên ngoài nhóm test sẽ đọc nó.

Nói một cách khác cho dễ hiểu thì Test Plan là tài liệu tổng quan về việc test 1 project. Scope của project, hướng tiếp cận, STLC(Software Testing Life Cycle), resource và nhân lực cần có, các features cần được test và không phải test, các tool test và môi trường test cần có. Có thể ví test plan là 1 cái xương sống của 1 testing project và là cái được chuẩn bị đầu tiên khi có 1 project. alt tex

1.2 Các hạng mục phổ biến của một kế hoạch kiểm thử

Tiêu đề
Định nghĩa version của phần mềm (version release)
Lưu lại quá trình hiệu chỉnh tài liệu như tác giả, ngày cập nhật, duyệt
Mục lục
Mục đích của tài liệu, ý kiến chung
Mục tiêu của chi phí kiểm thử (test)
Giới thiệu tổng quan về sản phẩm
Danh sách tài liệu liên quan như spec, tài liệu thiết kế, các kế hoạch test khác,…
Các tiêu chuẩn thích hợp, các yêu cầu hợp lệ
Nguồn gốc của các sự thay đổi
Relevant naming conventions and identifier conventions
Overall software project organization and personnel/contact-info/responsibilties
Test organization and personnel/contact-info/responsibilities
Assumptions and dependencies
Phân tích rủi ro của dự án
Các vấn đề ưu tiên và tập trung test
Phạm vi và giới hạn test
-Test outline – a decomposition of the test approach by test type, feature, functionality, process, system, module, etc. as applicable

Outline of data input equivalence classes, boundary value analysis, error classes
Test environment – hardware, operating systems, other required software, data configurations, interfaces to other systems
Test environment validity analysis – differences between the test and production systems and their impact on test validity.
Test environment setup and configuration issues
Software migration processes
Software CM processes
Test data setup requirements
Database setup requirements
Outline of system-logging/error-logging/other capabilities, and tools such as screen capture software, that will be used to help describe and report bugs
Discussion of any specialized software or hardware tools that will be used by testers to help track the cause or source of bugs
Test tự động – giải thích và tổng quan
Các công cụ test được sử sụng, bao gồm các version, bản vá lỗi,…v.v
Các qui trình bảo trì và quản lý version của test script/test code
Theo dõi và giải quyết vấn đề – Các công cụ và qui trình
Các thước đo về test sản phẩm được sử dụng
Báo cáo các yêu cầu và khả năng giao test
Điều kiện đầu vào và đầu ra của phần mềm
Giai đoạn và điều kiện test ban đầu
Điều kiện dừng test và test lại
Sự bố trí nhân sự
Những người cần training trước khi tham gia
Nơi test
Các tổ chức test bên ngoài sẽ sử dụng và mục đích, trách nhiệm, khả năng hoàn thành, người liên hệ và các vấn đề hợp tác của họ
Các vấn đề độc quyền thích hợp, phân loại, bảo mật và bản quyền.
Các vấn đề mở
Phụ lục – bảng chú giải, các từ viết tắt, …v.v… ###2. Các bước cơ bản để lập test plan
Xác định yêu cầu kiểm tra.
Khảo sát rủi ro.
Xác định chiến lược kiểm tra.
Xác định nhân lực, vật lực cần thiết.
Lập kế hoạch chi tiết.
Tổng hợp và đưa ra kế hoạch kiểm tra.
Xem xét các kế hoạch kiểm tra.

2. Bố cục nội dung cơ bản của một test plan

2.1. Chiến lược kiểm tra

• Chiến lược kiểm tra đưa ra phương pháp tiếp cận để kiểm tra mục tiêu.
• Chiến lược kiểm tra bao gồm các kỹ thuật được áp dụng và điều kiện để biết khi nào việc kiểm tra hoàn thành.
• Mô tả các kiểu kiểm tra dùng trong dự án.
• Có thể liệt kê với mỗi kiểu kiểm tra tương ứng kiểm tra cho chức năng nào.
• Việc kiểm có thể dừng khi nào.

2.2. Các kỹ thuật kiểm tra

• Mỗi kiểu kiểm tra phải bao gồm các đìều kiện:
• Kỹ thuật: Mô tả việc kiểm tra như thế nào, những gì sẽ được kiểm tra, các hoạt động chính được thực hiện trong quá trình kiểm tra và các phương pháp đánh giá kết quả.
• Điều kiện hoàn thành: Xác định chất lượng chương trình được chấp nhận và Thời điểm kiểm tra hoàn tất.
• Các vấn đề đặc biệt:
• Các vấn đề gây ảnh hưởng đến việc kiểm tra

2.2.1. Functional testing – kiểm tra chức năng

• Function testing – kiểm tra chức năng
• User interface testing – kiểm tra giao diện người sử dụng
• Data & database integrity testing – kiểm tra DL & tích hợp DL
• Business cycle testing – kiểm tra chu trình nghiệp vụ

2.2.2. Performance testing – kiểm tra hiệu xuất

• Performance profiling
• Load testing
• Stress testing
• Volume testing

2.2.3. Security & Access control testing – kiểm tra bảo mật & kiểm soát truy cập

2.2.4. Regression testing – kiểm tra hồi quy

3. Môi trường kiểm tra

Tuỳ vào mỗi giai đoạn Unit test, Intergration test, System test, acceptance test sẽ ứng với môi trường kiểm tra nhất định. Từ đó xác định các yếu tố để xây dựng môi trường kiểm tra, sử dụng như môi trường thật hay tạo môi trường giả lập gần giống với môi trường chạy thật của chương trình.

Khi test chạy chương trình bằng bản dịch hay chạy trên code. Thông thường, các giai đoạn System test, Acceptance test phải chạy trên bản dịch

Với CSDL thì thông thường, từ Intergration test, ta phải thiết lập CSDL riêng và thiết lập các thông số cho CSDL gần giống hoặc giống hệt như khi chương trình sẽ chạy thật.

Điều kiện về mạng: sẽ sử dụng mạng LAN hay Dial up… Thông thường, khi Unit test, có thể sử dụng mạng LAN nhưng khi System test trở đi thì nên sử dụng hệ thống đường truyền giống như hoặc gần giống như môi trường chạy thật.

Mô hình sẽ cài đặt chương trình test: số lượng máy chủ, máy trạm; việc chia tách các server, các máy trạm, việc cài đặt các domain … Thông thường, trong Unit test có thể sử dụng viếc thiết lập như khi lập trình, nhưng khi System test trở đi, phải chú ý thiết lập sao cho gần giống mô hình sẽ chạy trong thực tế nhất.