Làm thế nào để viết test plan tốt - good test plan

Nơi trao đổi thảo luận các thông tin liên quan đến Test plan.
Forum rules
Các bạn chỉ được post tất cả các thông tin liên quan đến Test plan tại đây.
Nên search trước khi post bài mới, mẫu test plan được post riêng ở Mục Template.
Post Reply
tvn
Admin
Posts: 4751
Joined: Tue 10 Aug, 2010 10:11 am
Location: HCM
Contact:

Làm thế nào để viết test plan tốt - good test plan

Post by tvn » Thu 02 Dec, 2010 3:05 pm

How to Write a Test Plan
By paigeturner, eHow Member

A test plan is a detailed hardware or software verification document that provides specifics on how the validator will test all aspects of the hardware or software design. Test plans are test specifications used as guides for writing test case suites for design validation in both the hardware and software engineering fields. Typically a test plan is written by a test or validation engineer. A test plan contains a description of product functionality, a description of test cases to be written for each function, and a description of the testing platform to be used. For hardware testing, test plans are needed for pre-silicon and post silicon validation.


Instructions

1. Review the Product Design Specification that the Test Plan is based On

Review every aspect of the product design specification. Flag any constraint or functionality omissions with the specification document. The hardware/software architect or owner of the product design specification document should be responsible for fleshing out any missing details in the design specification. Go through as many review iterations as necessary until all your questions have been answered. Your test plan will be based on the design specification so this step is extremely important.

2. Write the First Draft of Your Test Plan

Your test plan should contain a brief description of the design, the regression test and validation methodology to be used at both the unit and global levels, the testing architecture and a listing of the actual tests that will be performed. It should detail:
a) Design/Product description and features

b) Test Code Architecture

c) Test Methodology description

. (i) Unit Level

. (ii) System/Global Level

d) Type of testing (random, focused/directed, focused random, global, local) to be done.

e) Description of the function of each piece of the design and a listing of test cases that cover that functionality

f) All exceptions and special corner case conditions for functionality listed in the test plan.

g) Reuse/Modification Information: If validation/test code is being re-used from a different project, this should be specified and code changes to be made should be listed.

h) Functionality not to be tested(due to re-use of that portion of the design or other reasons) should be specifically noted and reviewed closely.

i) Test case constraints and coverage details for corner conditions

j) Test case error conditions for test cases in test plan.

k) Strategy for coverage of any testing/validation methodology holes.

3. Hold a Test Plan Review

Schedule a test plan review that includes the team that will be working on the tests, any design architects or product experts and and technical leads that could provide valuable test plan input. Tabulate all comments and input so that you can add to the test plan as necessary.

4. Finalize Your Test Plan

Add all the comments and input obtained during your test plan review and email out your final version to your review team to ensure that you haven't missed anything. Place your finalized test plan in a global repository so your entire team can have access to it. Any future edits should be visible to the entire team along with test plan completion status. Product release should only take place when all the test cases on your test plan have been run successfully so continual documentation of test case completion and pass/fail statistics is necessary.

Theo eHow.com



hoamuoigio130992
Hoc Tester
Posts: 3
Joined: Wed 27 Feb, 2013 7:09 pm
Contact:

Re: Làm thế nào để viết test plan tốt - good test plan

Post by hoamuoigio130992 » Mon 22 Sep, 2014 2:04 pm

tvn wrote:How to Write a Test Plan
By paigeturner, eHow Member

A test plan is a detailed hardware or software verification document that provides specifics on how the validator will test all aspects of the hardware or software design. Test plans are test specifications used as guides for writing test case suites for design validation in both the hardware and software engineering fields. Typically a test plan is written by a test or validation engineer. A test plan contains a description of product functionality, a description of test cases to be written for each function, and a description of the testing platform to be used. For hardware testing, test plans are needed for pre-silicon and post silicon validation.


Instructions

1. Review the Product Design Specification that the Test Plan is based On

Review every aspect of the product design specification. Flag any constraint or functionality omissions with the specification document. The hardware/software architect or owner of the product design specification document should be responsible for fleshing out any missing details in the design specification. Go through as many review iterations as necessary until all your questions have been answered. Your test plan will be based on the design specification so this step is extremely important.

2. Write the First Draft of Your Test Plan

Your test plan should contain a brief description of the design, the regression test and validation methodology to be used at both the unit and global levels, the testing architecture and a listing of the actual tests that will be performed. It should detail:
a) Design/Product description and features

b) Test Code Architecture

c) Test Methodology description

. (i) Unit Level

. (ii) System/Global Level

d) Type of testing (random, focused/directed, focused random, global, local) to be done.

e) Description of the function of each piece of the design and a listing of test cases that cover that functionality

f) All exceptions and special corner case conditions for functionality listed in the test plan.

g) Reuse/Modification Information: If validation/test code is being re-used from a different project, this should be specified and code changes to be made should be listed.

h) Functionality not to be tested(due to re-use of that portion of the design or other reasons) should be specifically noted and reviewed closely.

i) Test case constraints and coverage details for corner conditions

j) Test case error conditions for test cases in test plan.

k) Strategy for coverage of any testing/validation methodology holes.

3. Hold a Test Plan Review

Schedule a test plan review that includes the team that will be working on the tests, any design architects or product experts and and technical leads that could provide valuable test plan input. Tabulate all comments and input so that you can add to the test plan as necessary.

4. Finalize Your Test Plan

Add all the comments and input obtained during your test plan review and email out your final version to your review team to ensure that you haven't missed anything. Place your finalized test plan in a global repository so your entire team can have access to it. Any future edits should be visible to the entire team along with test plan completion status. Product release should only take place when all the test cases on your test plan have been run successfully so continual documentation of test case completion and pass/fail statistics is necessary.

Theo eHow.com
Hôm nay em dịch đoạn này, anh chị nào thấy sai đóng gióp ý kiến thêm nha cảm ơn nhiều

Viết plan như thế nào
By paigeturner, eHow Member

Kế hoạch kiểm tra là chi tiết phần cứng hoặc phần mềm được veritfication trong tài liệu mà cung cấp chi tiết cụ thể về cách xác nhận kiểm tra tất cả các khía cạnh của phần cứng hoặc phần mềm thiết kế như thế nào,Kế hoạch kiểm tra là kiểm tra các chi tiết kỹ thuật sử dụng như hướng dẫn để viết testcase xác nhận thiết kế trong cả hai lĩnh vực phần cứng và phần mềm, thông thường kế hoạch kiểm thử được viết bởi test hoặc người quản lý . Một kiểm thử kế hoạch chứa mô tả các chức năng của sản phẩ, , mô tả test case sẽ được viết cho mỗi chức năng, and mô tả các loại platform được sử dụng, đối với kiểm tra phần cứng, kế hoạch kiểm tra là cần thiết trước kiểm tra và xác nhậc sản phẩm

1.Xem lại các thiết kế kỹ thuật sản phẩm mà kế hoạch thử nghiệm dựa trên

Xem xét mọi khía cạnh các kỹ thuật thiết kế sản phẩm. flah bất kỳ hạn chế hoặc chức năng thiếu sót với các tài liệu đặc tả. Các phần cứng / kiến trúc sư phần mềm, chủ sở hữu của thiết kế sản phẩm tài liệu đặc tả phải có trách nhiệm bổ sung bất kỳ chi tiết còn thiếu trong các kỹ thuật thiết kế. Nhiều lần xem xét là cần thiết cho đến khi tất cả câu hỏi của bạn đã được trả lời. Kế hoạch kiểm tra của bạn sẽ được dựa trên các đặc điểm kỹ thuật thiết kế để bước này là cực kỳ quan trọng.

2 Đầu tiên viết nháp test plan của bạn
Kế hoạch kiểm thử của banh nên chứa mô tả ngắn gọn về thiết kế, kiểm tra hồi quy và các phương pháp kiểm thử sẽ được sử dụng ở cả unit và toàn quá trình, các kỹ thuật kiểm thử và list tất cả kết quả thực mà sẽ được thực hiện. Một kế hoạch kiểm thử sẽ gồm các chi tiết sau:
a) Thiết kế/ ,mô tả sản phẩm và tính năng

b) Các kỹ thuật kiểm thử code

c) Các phương thức kiểm thử được mô tả
(i) Mức độ unit
(ii) Mức dộ hệ thống/ tổng thể

d) Các loại kiểm thử( ngẫu nhiên , tập trung trực tiếp. ngẫu nhiên trực tiếp, local và global sẽ được thực hiện

e) Mô tả chức năng của mỗi phần được thiết kế và list các test case mà bao trùm chức năng

f) Tất cả ngoại trừ và yêu cầu đặc biệt điều kiên test của chức năng được list trong kế hoạch kiểm thử

g) Tái sử dụng / Sửa đổi Thông tin: Nếu xác nhận / thử nghiệm đang được sử dụng lại từ một dự án khác nhau, điều này sẽ được xác định và thay đổi mã được thực hiện sẽ được liệt kê.

h) Chức năng không được kiểm tra (do tái sử dụng lại một phần của thiết kế hoặc lý do khác) cần lưu ý đặc biệt và xem xét chặt chẽ.
i) Trường hợp kiểm thử sai và bao trùm chi tiêt tất cả các điều kiện

j) Kiểm tra điều kiện trường hợp lỗi đối với trường hợp kiểm tra trong kế hoạch kiểm tra.

k) Chiến lược để bao trùm của kiểm thử, các phương thức xác nhận lỗ hổng

3. Giữ một bản đánh giá Kế hoạch kiểm tra

Một lịch trình để kiểm tra plan bao gồm những công việc trong kiểm thử mà đội sẽ làm , bất kỳ thiết kế kỹ thuật or các chuyên gia sản phẩm và các technical leads mà có thể cung cấp giá trị kế hoạch kiểm thử đưa vào, Tất cả các ý kiến và đầu vào để mà bạn có thể cần thiết để thêm vào kế hoạch kiểm thử
4. Hoàn thành Kế hoach kiểm tra

Thêm tất cả các ý kiến và nhập kết quả thu được kế hoạch kiểm thử và gởi email tới những người có liên quan để đánh giá kế hoạch của bạn và đảm bảo rằng bạn không có bỏ qua bất cứ điều gì. Đặt kế hoạch kiểm thử cuối cùng của bạn trong kho lưu trữ chung để mà các thành viên trong nhóm có thể truy cập nó khi cần, trong tương lai có bất kỳ thay đổi nào toàn đội cũng có thể nhìn thấy để biết được tình trạng hoàn thành kế hoạch kiểm thử. Phát hành sản phẩn được diễn ra khi tất cả trường hợp kiểm thử trong kế hoach được chạy thành công để liên tục kiểm tra trường hợp kiểm thử và bản thống kê số testcase pass/fail là cần thiết.

Theo eHow.com



Post Reply

Return to “Test Plans - Kế hoạch kiểm thử”