Company NameTest PlanRevision CFor

Company Name
Test Plan

Revision C

For more Testing/QA Templates please visit http://www.softwaretestinghelp.com

Revision History

DATE REV AUTHOR DESCRIPTION
5/14/07 A First Draft
5/21/07 B Second Draft
5/25/07 C Added FTBT

Table of Contents

1. Introduction 4
1.1. Test Plan Objectives 4
2. Scope 4
2.1. Data Entry 4
2.2. ReportsFile Transfer 4
2.3. File Transfer 4
2.4. Security 4
3. Test Strategy 5
3.1. System Test 5
3.2. Performance Test 5
3.3. Security Test 5
3.4. Automated Test 5
3.5. Stress and Volume Test 5
3.6. Recovery Test 5
3.7. Documentation Test 5
3.8. Beta Test 5
3.9. User Acceptance Test 5
4. Environment Requirements 6
4.1. Data Entry workstations 6
4.2 MainFrame 6
5. Test Schedule 6
6. Control Procedures 6
6.1 Reviews 6
6.2 Bug Review meetings 6
6.3 Change Request 6
6.4 Defect Reporting 6
7. Functions To Be Tested 7
8. Resources and Responsibilities 7
8.1. Resources 7
8.2. Responsibilities 7
9. Deliverables 8
10. Suspension / Exit Criteria 9
11. Resumption Criteria 9
12. Dependencies 9
12.1 Personnel Dependencies 9
12.2 Software Dependencies 9
12.3 Hardware Dependancies 9
12.3 Test Data & Database 9
13. Risks 9
13.1. Schedule 9
13.2. Technical 9
13.3. Management 9
13.4. Personnel 10
13.5 Requirements 10
14. Tools 10
15. Documentation 10
16. Approvals 11

1. Introduction

The company has outgrown its current payroll system & is developing a new system that will allow for further growth and provide additional features. The software test department has been tasked with testing the new system.

The new system will do the following:
 Provide the users with menus, directions & error messages to direct him/her on the various options.
 Handle the update/addition of employee information.
 Print various reports.
 Create a payroll file and transfer the file to the mainframe.
 Run on the Banyan Vines Network using IBM compatible PCs as data entry terminals
1.1. Test Plan Objectives
This Test Plan for the new Payroll System supports the following objectives:
 Define the activities required to prepare for and conduct System, Beta and User Acceptance testing.
 Communicate to all responsible parties the System Test strategy.
 Define deliverables and responsible parties.
 Communicate to all responsible parties the various Dependencies and Risks

2. Scope
2.1. Data Entry
The new payroll system should allow the payroll clerks to enter employee information from IBM compatible PC workstations running DOS 3.3 or higher. The system will be menu driven and will provide error messages to help direct the clerks through various options.
2.2. Reports
The system will allow the payroll clerks to print 3 types of reports. These reports are:
 A pay period transaction report
 A pay period exception report
 A three month history report
2.3. File Transfer
Once the employee information is entered into the LAN database, the payroll system will allow the clerk to create a payroll file. This file can then be transferred, over the network, to the mainframe.
2.4. Security
Each payroll clerk will need a userid and password to login to the system. The system will require the clerks to change the password every 30 days.

3. Test Strategy
The test strategy consists of a series of different tests that will fully exercise the payroll system. The primary purpose of these tests is to uncover the systems limitations and measure its full capabilities. A list of the various planned tests and a brief explanation follows below.
3.1. System Test
The System tests will focus on the behavior of the payroll system. User scenarios will be executed against the system as well as screen mapping and error message testing. Overall, the system tests will test the integrated system and verify that it meets the requirements defined in the requirements document.
3.2. Performance Test
Performance test will be conducted to ensure that the payroll system’s response times meet the user expectations and does not exceed the specified performance criteria. During these tests, response times will be measured under heavy stress and/or volume.
3.3. Security Test
Security tests will determine how secure the new payroll system is. The tests will verify that unauthorized user access to confidential data is prevented.
3.4. Automated Test
A suite of automated tests will be developed to test the basic functionality of the payroll system and perform regression testing on areas of the systems that previously had critical/major defects. The tool will also assist us by executing user scenarios thereby emulating several users.

3.5. Stress and Volume Test
We will subject the payroll system to high input conditions and a high volume of data during the peak times. The System will be stress tested using twice (20 users) the number of expected users.
3.6. Recovery Test
Recovery tests will force the system to fail in a various ways and verify the recovery is properly performed. It is vitally important that all payroll data is recovered after a system failure & no corruption of the data occurred.
3.7. Documentation Test
Tests will be conducted to check the accuracy of the user documentation. These tests will ensure that no features are missing, and the contents can be easily understood.
3.8. Beta Test
The Payroll department will beta tests the new payroll system and will report any defects they find. This will subject the system to tests that could not be performed in our test environment.
3.9. User Acceptance Test
Once the payroll system is ready for implementation, the Payroll department will perform User Acceptance Testing. The purpose of these tests is to confirm that the system is developed according to the specified user requirements and is ready for operational use.

4. Environment Requirements
4.1. Data Entry workstations
 20 IBM compatible PCs (10 will be used by the automation tool to emulate payroll clerks).
 286 processor (minimum)
 4mb RAM
 100 mb Hard Drive
 DOS 3.3 or higher
 Attached to Banyan Vines network
 A Network attached printer
 20 user ids and passwords (10 will be used by the automation tool to emulate payroll clerks).

4.2 MainFrame
 Attached to the Banyan Vines network
 Access to a test database (to store payroll information transferred from LAN payroll system)

5. Test Schedule
 Ramp up / System familiarization 6/01/07 - 6/15/07
 System Test 6/16/07 - 8/26/07
 Beta Test 7/28/07 - 8/18/07
 User Acceptance Test 8/29/07 - 9/03/07

6. Control Procedures
6.1 Reviews
The project team will perform reviews for each Phase. (i.e. Requirements Review, Design Review, Code Review, Test Plan Review, Test Case Review and Final Test Summary Review). A meeting notice, with related documents, will be emailed to each participant.
6.2 Bug Review meetings
Regular weekly meeting will be held to discuss reported defects. The development department will provide status/updates on all defects reported and the test department will provide addition defect information if needed. All member of the project team will participate.
6.3 Change Request
Once testing begins, changes to the payroll system are discouraged. If functional changes are required, these proposed changes will be discussed with the Change Control Board (CCB). The CCB will determine the impact of the change and if/when it should be implemented.
6.4 Defect Reporting
When defects are found, the testers will complete a defect report on the defect tracking system. The defect tracking Systems is accessible by testers, developers & all members of the project team. When a defect has been fixed or more information is needed, the developer will change the status of the defect to indicate the current state. Once a defect is verified as FIXED by the testers, the testers will close the defect report.

7. Functions To Be Tested
The following is a list of functions that will be tested:

 Add/update employee information
 Search / Lookup employee information
 Escape to return to Main Menu
 Security features
 Scaling to 700 employee records
 Error messages
 Report Printing
 Creation of payroll file
 Transfer of payroll file to the mainframe
 Screen mappings (GUI flow). Includes default settings
 FICA Calculation
 State Tax Calculation
 Federal Tax Calculation
 Gross pay Calculation
 Net pay Calculation
 Sick Leave Balance Calculation
 Annual Leave Balance Calculation

A Requirements Validation Matrix will “map” the test cases back to the requirements. See Deliverables.
8. Resources and Responsibilities
The Test Lead and Project Manager will determine when system test will start and end. The Test lead will also be responsible for coordinating schedules, equipment, & tools for the testers as well as writing/updating the Test Plan, Weekly Test Status reports and Final Test Summary report. The testers will be responsible for writing the test cases and executing the tests. With the help of the Test Lead, the Payroll Department Manager and Payroll clerks will be responsible for the Beta and User Acceptance tests.
8.1. Resources
The test team will consist of:
 A Project Manager
 A Test Lead
 5 Testers
 The Payroll Department Manager
 5 Payroll Clerks

8.2. Responsibilities
Project Manager Responsible for Project schedules and the overall success of the project. Participate on CCB.

Lead Developer Serve as a primary contact/liaison between the development department and the project team.
Participate on CCB.

Test Lead Ensures the overall success of the test cycles. He/she will coordinate weekly meetings and will communicate the testing status to the project team.
Participate on CCB.

Testers Responsible for performing the actual system testing.

Payroll Department Manager Serves as Liaison between Payroll department and project team. He/she will help coordinate the Beta and

Company Name
Test Plan

Revision C

For more Testing/QA Templates please visit http://www.softwaretestinghelp.com

Revision History

DATE REV AUTHOR DESCRIPTION
5/14/07 A First Draft
5/21/07 B Second Draft
5/25/07 C Added FTBT

Table of Contents

1. Introduction 4
1.1. Test Plan Objectives 4
2. Scope 4
2.1. Data Entry 4
2.2. ReportsFile Transfer 4
2.3. File Transfer 4
2.4. Security 4
3. Test Strategy 5
3.1. System Test 5
3.2. Performance Test 5
3.3. Security Test 5
3.4. Automated Test 5
3.5. Stress and Volume Test 5
3.6. Recovery Test 5
3.7. Documentation Test 5
3.8. Beta Test 5
3.9. User Acceptance Test 5
4. Environment Requirements 6
4.1. Data Entry workstations 6
4.2 MainFrame 6
5. Test Schedule 6
6. Control Procedures 6
6.1 Reviews 6
6.2 Bug Review meetings 6
6.3 Change Request 6
6.4 Defect Reporting 6
7. Functions To Be Tested 7
8. Resources and Responsibilities 7
8.1. Resources 7
8.2. Responsibilities 7
9. Deliverables 8
10.  Suspension / Exit Criteria 9
11. Resumption Criteria 9
12. Dependencies 9
12.1 Personnel Dependencies 9
12.2 Software Dependencies 9
12.3 Hardware Dependancies 9
12.3 Test Data & Database 9
13. Risks 9
13.1. Schedule 9
13.2. Technical 9
13.3. Management 9
13.4. Personnel 10
13.5 Requirements 10
14. Tools 10
15. Documentation 10
16. Approvals 11

1. Introduction

The company has outgrown its current payroll system & is developing a new system that will allow for further growth and provide additional features. The software test department has been tasked with testing the new system.

The new system will do the following:
 Provide the users with menus, directions & error messages to direct him/her on the various options.
 Handle the update/addition of employee information.
 Print various reports.
 Create a payroll file and transfer the file to the mainframe.
 Run on the Banyan Vines Network using IBM compatible PCs as data entry terminals
1.1. Test Plan Objectives
This Test Plan for the new Payroll System supports the following objectives:
 Define the activities required to prepare for and conduct System, Beta and User Acceptance testing.
 Communicate to all responsible parties the System Test strategy.
 Define deliverables and responsible parties.
 Communicate to all responsible parties the various Dependencies and Risks

2. Scope
2.1. Data Entry
The new payroll system should allow the payroll clerks to enter employee information from IBM compatible PC workstations running DOS 3.3 or higher. The system will be menu driven and will provide error messages to help direct the clerks through various options.
2.2. Reports
The system will allow the payroll clerks to print 3 types of reports. These reports are:
 A pay period transaction report
 A pay period exception report
 A three month history report
2.3. File Transfer
Once the employee information is entered into the LAN database, the payroll system will allow the clerk to create a payroll file. This file can then be transferred, over the network, to the mainframe.
2.4. Security
Each payroll clerk will need a userid and password to login to the system. The system will require the clerks to change the password every 30 days.

3. Test Strategy
The test strategy consists of a series of different tests that will fully exercise the payroll system. The primary purpose of these tests is to uncover the systems limitations and measure its full capabilities. A list of the various planned tests and a brief explanation follows below.
3.1. System Test
The System tests will focus on the behavior of the payroll system. User scenarios will be executed against the system as well as screen mapping and error message testing. Overall, the system tests will test the integrated system and verify that it meets the requirements defined in the requirements document. 
3.2. Performance Test
Performance test will be conducted to ensure that the payroll system’s response times meet the user expectations and does not exceed the specified performance criteria. During these tests, response times will be measured under heavy stress and/or volume.
3.3. Security Test
Security tests will determine how secure the new payroll system is. The tests will verify that unauthorized user access to confidential data is prevented.
3.4. Automated Test
A suite of automated tests will be developed to test the basic functionality of the payroll system and perform regression testing on areas of the systems that previously had critical/major defects. The tool will also assist us by executing user scenarios thereby emulating several users.

3.5. Stress and Volume Test 
We will subject the payroll system to high input conditions and a high volume of data during the peak times. The System will be stress tested using twice (20 users) the number of expected users.
3.6. Recovery Test 
Recovery tests will force the system to fail in a various ways and verify the recovery is properly performed. It is vitally important that all payroll data is recovered after a system failure & no corruption of the data occurred. 
3.7. Documentation Test 
Tests will be conducted to check the accuracy of the user documentation. These tests will ensure that no features are missing, and the contents can be easily understood. 
3.8. Beta Test
The Payroll department will beta tests the new payroll system and will report any defects they find. This will subject the system to tests that could not be performed in our test environment. 
3.9. User Acceptance Test
Once the payroll system is ready for implementation, the Payroll department will perform User Acceptance Testing. The purpose of these tests is to confirm that the system is developed according to the specified user requirements and is ready for operational use.

4. Environment Requirements
4.1. Data Entry workstations
 20 IBM compatible PCs (10 will be used by the automation tool to emulate payroll clerks).
 286 processor (minimum)
 4mb RAM
 100 mb Hard Drive
 DOS 3.3 or higher
 Attached to Banyan Vines network
 A Network attached printer
 20 user ids and passwords (10 will be used by the automation tool to emulate payroll clerks).

4.2 MainFrame
 Attached to the Banyan Vines network
 Access to a test database (to store payroll information transferred from LAN payroll system)

5. Test Schedule
 Ramp up / System familiarization  6/01/07 - 6/15/07
 System Test 6/16/07 - 8/26/07
 Beta Test 7/28/07 - 8/18/07 
 User Acceptance Test 8/29/07 - 9/03/07

6. Control Procedures
6.1 Reviews
The project team will perform reviews for each Phase. (i.e. Requirements Review, Design Review, Code Review, Test Plan Review, Test Case Review and Final Test Summary Review). A meeting notice, with related documents, will be emailed to each participant.
6.2 Bug Review meetings
Regular weekly meeting will be held to discuss reported defects. The development department will provide status/updates on all defects reported and the test department will provide addition defect information if needed. All member of the project team will participate.
6.3 Change Request
Once testing begins, changes to the payroll system are discouraged. If functional changes are required, these proposed changes will be discussed with the Change Control Board (CCB). The CCB will determine the impact of the change and if/when it should be implemented.
6.4 Defect Reporting
When defects are found, the testers will complete a defect report on the defect tracking system. The defect tracking  Systems is accessible by testers, developers & all members of the project team. When a defect has been fixed or more information is needed, the developer will change the status of the defect to indicate the current state. Once a defect is verified as FIXED by the testers, the testers will close the defect report.

7. Functions To Be Tested
The following is a list of functions that will be tested:

 Add/update employee information
 Search / Lookup employee information
 Escape to return to Main Menu
 Security features
 Scaling to 700 employee records
 Error messages
 Report Printing
 Creation of payroll file
 Transfer of payroll file to the mainframe
 Screen mappings (GUI flow). Includes default settings
 FICA Calculation
 State Tax Calculation
 Federal Tax Calculation
 Gross pay Calculation
 Net pay Calculation
 Sick Leave Balance Calculation
 Annual Leave Balance Calculation

A Requirements Validation Matrix will “map” the test cases back to the requirements. See Deliverables.
8. Resources and Responsibilities
The Test Lead and Project Manager will determine when system test will start and end. The Test lead will also be responsible for coordinating schedules, equipment, & tools for the testers as well as writing/updating the Test Plan, Weekly Test Status reports and Final Test Summary report. The testers will be responsible for writing the test cases and executing the tests. With the help of the Test Lead, the Payroll Department Manager and Payroll clerks will be responsible for the Beta and User Acceptance tests.
8.1. Resources
The test team will consist of:
 A Project Manager
 A Test Lead 
 5 Testers
 The Payroll Department Manager
 5 Payroll Clerks

8.2. Responsibilities
 Project Manager Responsible for Project schedules and the overall success of the project. Participate on CCB.
 
 Lead Developer Serve as a primary contact/liaison between the development department and the project team.
Participate on CCB.
 
 
 Test Lead Ensures the overall success of the test cycles. He/she will coordinate weekly meetings and will communicate the testing status to the project team.
Participate on CCB.
 
 Testers Responsible for performing the actual system testing.
 
 Payroll Department Manager Serves as Liaison between Payroll department and project team. He/she will help coordinate the Beta and

0/5000

Từ: -

Sang: -

Kết quả (Việt) 1: [Sao chép]

Sao chép!

Tên doanh nghiệpThử nghiệm kế hoạchPhiên bản CĐể thêm mẫu thử nghiệm/bảo đảm chất lượng, hãy truy cập http://www.softwaretestinghelp.comLịch sử sửa đổiNGÀY REV TÁC GIẢ MÔ TẢ5/14/07 bản dự thảo đầu tiên5/21/07 B thứ hai dự thảo5/25/07 C bổ sung FTBT Bảng nội dung1. giới thiệu 41.1. kiểm tra các mục tiêu kế hoạch 42. phạm vi 42.1. nhập dữ liệu 42.2. ReportsFile chuyển 42.3. tập tin chuyển 42.4. an ninh 43. kiểm tra chiến lược 53.1. Hệ thống thử nghiệm 53.2. hiệu suất thử nghiệm 53.3. an ninh kiểm tra 53.4. tự động thử nghiệm 53.5. căng thẳng và kiểm tra khối lượng 53.6. phục hồi thử nghiệm 53.7. tài liệu thử nghiệm 53.8. thử nghiệm Beta 53.9. người dùng chấp nhận thử nghiệm 54. môi trường yêu cầu 64.1. các máy trạm làm việc cho các mục nhập dữ liệu 64.2 máy tính lớn 65. kiểm tra lịch trình 66. kiểm soát quy trình 66.1 đánh giá 66.2 cuộc họp lỗi đánh giá 66.3 thay đổi yêu cầu 66.4 lỗi báo cáo 67. chức năng để thử nghiệm 78. tài nguyên và trách nhiệm 78.1. nguồn lực 78.2. trách nhiệm 79. phân phôi 810. tạm dừng / thoát khỏi tiêu chuẩn 911. vòng tiêu chí 912. phụ thuộc 912,1 nhân sự phụ thuộc 912.2 phần mềm phụ thuộc 912.3 phần cứng Dependancies 912.3 kiểm tra dữ liệu & cơ sở dữ liệu 913. rủi ro 913.1. lịch trình 913.2. 9 kỹ thuật13,3. quản lý 913.4. nhân viên 1013,5 yêu cầu 1014. công cụ 1015. tài liệu hướng dẫn 1016. chấp thuận 11 1. giới thiệuCông ty đã outgrown hệ thống biên chế hiện tại của nó và đang phát triển một hệ thống mới sẽ cho phép cho biết thêm sự phát triển và cung cấp các tính năng bổ sung. Bộ phận kiểm tra phần mềm đã được giao nhiệm vụ với các thử nghiệm hệ thống mới.Hệ thống mới sẽ thực hiện như sau: cung cấp cho người dùng với thực đơn, hướng dẫn & lỗi thông điệp trực tiếp anh/cô ấy vào các tùy chọn khác nhau. xử lý bổ sung/Cập nhật các thông tin nhân viên. In báo cáo khác nhau. Tạo một tập tin biên chế và chuyển các tập tin vào máy tính lớn. Chạy trên Banyan Vines mạng bằng cách sử dụng máy tính tương thích IBM là thiết bị đầu cuối mục nhập dữ liệu1.1. kiểm tra các mục tiêu kế hoạchThử nghiệm này kế hoạch cho các hệ thống mới hỗ trợ các mục tiêu sau đây: xác định các hoạt động cần thiết để chuẩn bị cho và tiến hành hệ thống, phiên bản Beta và người dùng chấp nhận thử nghiệm. truyền đạt cho tất cả các bên chịu trách nhiệm các chiến lược thử nghiệm hệ thống. xác định phân phôi và bên chịu trách nhiệm. giao tiếp với tất cả các bên chịu trách nhiệm khác nhau phụ thuộc và rủi ro2. phạm vi2.1. dữ liệu nhậpHệ thống biên chế mới nên cho phép nhân viên biên chế để nhập thông tin nhân viên từ máy trạm máy tính tương thích IBM chạy DOS 3.3 hoặc cao hơn. Hệ thống sẽ là menu hướng và sẽ cung cấp thông báo lỗi để giúp chỉ đạo các nhân viên thông qua các tùy chọn khác nhau.2.2. báo cáoHệ thống sẽ cho phép nhân viên biên chế in 3 loại báo cáo. Các báo cáo này là: A trả báo cáo thời gian giao dịch A trả ngoại lệ giai đoạn báo cáo A ba tháng lịch sử báo cáo2.3. tập tin chuyển giaoMột khi các thông tin nhân viên được nhập vào cơ sở dữ liệu mạng LAN, Hệ thống sẽ cho phép nhân viên để tạo ra một tập tin biên chế. Tập tin này sau đó có thể được chuyển giao, qua mạng, để các máy tính lớn.2.4. an ninhMỗi nhân viên biên chế sẽ cần một user và mật khẩu để đăng nhập vào hệ thống. Hệ thống sẽ yêu cầu nhân viên để thay đổi mật khẩu mỗi 30 ngày. 3. kiểm tra chiến lượcChiến lược thử nghiệm bao gồm một loạt các xét nghiệm khác nhau hoàn toàn sẽ thực hiện hệ thống biên chế. Mục đích chính của các xét nghiệm này là để phát hiện ra những hạn chế hệ thống và đo lường khả năng đầy đủ của mình. Một danh sách khác nhau lập kế hoạch xét nghiệm và một lời giải thích ngắn gọn sau dưới đây.3.1. Hệ thống thử nghiệmCác bài kiểm tra hệ thống sẽ tập trung vào hành vi của hệ thống biên chế. Người sử dụng kịch bản sẽ được thực hiện chống lại hệ thống cũng như màn hình lập bản đồ và lỗi thư kiểm tra. Nhìn chung, các bài kiểm tra hệ thống sẽ kiểm tra hệ thống tích hợp và xác minh rằng nó đáp ứng các yêu cầu được xác định trong các tài liệu yêu cầu. 3.2. hiệu suất thử nghiệmKiểm tra hiệu suất sẽ được tiến hành để đảm bảo rằng thời gian đáp ứng của hệ thống biên chế đáp ứng mong đợi của người sử dụng và không vượt quá tiêu chuẩn quy định hiệu suất. Trong những thử nghiệm này, thời gian đáp ứng sẽ được đo theo nặng căng thẳng và/hoặc khối lượng.3.3. bảo mật thử nghiệmBài kiểm tra an ninh sẽ xác định làm thế nào secure hệ thống mới là. Các bài kiểm tra sẽ xác minh rằng người dùng không được phép truy cập vào dữ liệu bí mật là ngăn chặn.3.4. tự động kiểm traMột bộ tự động thử nghiệm sẽ được phát triển để kiểm tra các chức năng cơ bản của hệ thống biên chế và thực hiện các hồi quy thử nghiệm vào các lĩnh vực của hệ thống mà trước đó đã có quan trọng/lớn Khuyết tật. Công cụ cũng sẽ giúp chúng tôi bằng cách thực hiện kịch bản người dùng do đó thi đua nhiều người sử dụng.3.5. căng thẳng và khối lượng thử nghiệm Chúng tôi sẽ chịu hệ thống biên chế để điều kiện đầu vào cao và một số lượng lớn của dữ liệu trong giờ cao điểm. Hệ thống sẽ là căng thẳng thử nghiệm bằng cách sử dụng hai lần (20 người dùng) số lượng dự kiến người dùng.3.6. phục hồi thử nghiệm Phục hồi bài kiểm tra sẽ buộc hệ thống thất bại trong một cách khác nhau và kiểm tra việc thu hồi được thực hiện đúng cách. Nó là cực kỳ quan trọng tất cả biên chế dữ liệu phục hồi sau khi một lỗi hệ thống & không tham nhũng dữ liệu xảy ra. 3.7. tài liệu thử nghiệm Bài kiểm tra sẽ được tiến hành để kiểm tra tính chính xác của tài liệu hướng dẫn người sử dụng. Các xét nghiệm này sẽ đảm bảo rằng không có tính năng bị thiếu, và nội dung có thể được hiểu một cách dễ dàng. 3.8. thử nghiệm BetaTỉnh biên chế sẽ Phiên bản beta thử nghiệm hệ thống biên chế mới và sẽ báo cáo bất kỳ Khuyết tật mà họ tìm thấy. Điều này sẽ chịu hệ thống thử nghiệm mà không có thể được thực hiện trong môi trường thử nghiệm của chúng tôi. 3.9. người dùng chấp nhận thử nghiệmMột khi hệ thống biên chế đã sẵn sàng cho việc thực hiện, tỉnh biên chế sẽ thực hiện người dùng chấp nhận thử nghiệm. Mục đích của các xét nghiệm này là để xác nhận rằng hệ thống được phát triển theo yêu cầu của người sử dụng được chỉ định và sẵn sàng để sử dụng.4. môi trường yêu cầu4.1. dữ liệu nhập máy trạm 20 máy tính tương thích IBM (10 sẽ được sử dụng bởi công cụ tự động hóa để thi đua nhân viên biên chế). 286 bộ xử lý (tối thiểu) 4mb RAM 100 mb ổ cứng DOS 3.3 hoặc cao hơn gắn liền với Banyan Vines mạng A mạng kết nối vào máy in 20 người sử dụng ID và mật khẩu (10 sẽ được sử dụng bởi công cụ tự động hóa để thi đua nhân viên biên chế).4.2 máy tính lớn gắn liền với mạng Banyan Vines quyền truy cập vào một bài kiểm tra cơ sở dữ liệu (để lưu trữ thông tin biên chế chuyển từ hệ thống mạng LAN)5. kiểm tra lịch trình đoạn đường nối lên / hệ thống familiarization 6/01/07-6/15/07É hệ thống kiểm tra 6/16/07 - 8/26/07 Phiên bản Beta thử nghiệm 7/28/07 - 8/18/07  người dùng chấp nhận kiểm tra 8/29/07 - 9/03/076. thủ tục kiểm soát6.1 đánh giáNhóm dự án sẽ thực hiện đánh giá cho mỗi giai đoạn. (tức là yêu cầu xem xét, đánh giá thiết kế, xem xét mã, thử nghiệm kế hoạch đánh giá, xem xét trường hợp thử nghiệm và cuối cùng thử nghiệm tóm tắt xem xét). Một thông báo cuộc họp, với các tài liệu có liên quan, sẽ được gửi qua email để mỗi người tham gia.6.2 lỗi xem lại cuộc họpThường xuyên cuộc họp hàng tuần sẽ được tổ chức để thảo luận về báo cáo lỗi. Phát triển sẽ cung cấp/Cập nhật trạng thái về tất cả lỗi báo cáo và tỉnh thử nghiệm sẽ cung cấp bổ sung Khuyết tật thông tin nếu cần thiết. Tất cả thành viên của nhóm dự án sẽ tham gia.6.3 yêu cầu thay đổiSau khi thử nghiệm bắt đầu, thay đổi đối với hệ thống được khuyến khích. Nếu thay đổi chức năng được yêu cầu, những thay đổi được đề xuất sẽ được thảo luận với hội đồng kiểm soát thay đổi (CCB). CCB sẽ xác định tác động của sự thay đổi và nếu/khi nó phải được thực hiện.6.4 lỗi báo cáoKhi lỗi được tìm thấy, các thử nghiệm sẽ hoàn thành một báo cáo lỗi về các khiếm khuyết theo dõi hệ thống. Lỗi hệ thống theo dõi có thể truy cập bởi xét nghiệm, nhà phát triển & tất cả các thành viên của nhóm dự án. Khi một lỗi đã được cố định hoặc cần thêm thông tin, các nhà phát triển sẽ thay đổi trạng thái của các khiếm khuyết để chỉ ra hiện trạng. Một khi một lỗi được xác minh là cố định bằng các thử nghiệm, các thử nghiệm sẽ đóng cửa báo cáo lỗi. 7. chức năng để được kiểm traBorder|phải|200px Đây là danh sách các chức năng mà sẽ được kiểm tra: Thêm/Cập nhật thông tin nhân viên Tìm kiếm / tra cứu thông tin nhân viên Thoát để trở về Menu chính tính năng bảo mật Rộng 700 nhân viên hồ sơ thông báo lỗi báo cáo in Ấn tạo ra các tập tin biên chế Chuyển biên chế tập tin vào máy tính lớn màn hình ánh xạ (GUI dòng chảy). Bao gồm các thiết lập mặc định FICA tính toán Thuế nhà nước tính toán Thuế liên bang tính toán Tổng trả tính Net trả tính Bệnh để tính toán cân bằng hàng năm để lại sự cân bằng tính toánMột ma trận xác nhận yêu cầu sẽ "bản đồ" trường hợp kiểm tra quay lại các yêu cầu. Xem phân phôi.8. tài nguyên và trách nhiệmKiểm tra dẫn và quản lý dự án sẽ xác định khi hệ thống thử nghiệm sẽ bắt đầu và kết thúc. Thử nghiệm dẫn cũng sẽ chịu trách nhiệm phối hợp lịch trình, thiết bị, và các công cụ cho các thử nghiệm cũng như văn bản/Cập Nhật thử nghiệm kế hoạch, lượt kiểm tra tình trạng báo cáo và báo cáo tóm tắt bài kiểm tra cuối cùng. Các thử nghiệm sẽ chịu trách nhiệm cho các trường hợp kiểm tra văn bản và thực hiện các bài kiểm tra. Với sự giúp đỡ của các thử nghiệm dẫn, biên chế vùng quản lý và biên chế nhân viên sẽ chịu trách nhiệm cho các phiên bản Beta và người dùng chấp nhận xét nghiệm.8.1. tài nguyênĐội kiểm tra sẽ bao gồm: Một người quản lý dự án Một dẫn thử nghiệm  5 xét nghiệm quản lý biên chế vùng 5 tiền lương nhân viên8.2. trách nhiệm Quản lý dự án chịu trách nhiệm cho dự án lịch trình và sự thành công tổng thể của dự án. Tham gia ngày CCB. Lãnh đạo phát triển phục vụ như một số liên lạc chính/liên lạc giữa phát triển và nhóm dự án.Tham gia ngày CCB. Kiểm tra dẫn đảm bảo sự thành công tổng thể của các chu trình thử nghiệm. Ông/bà sẽ điều phối cuộc họp hàng tuần và sẽ truyền đạt trạng thái thử nghiệm để dự án nhóm.Tham gia ngày CCB. Xét nghiệm chịu trách nhiệm để thực hiện thử nghiệm hệ thống thực tế. Biên chế vùng quản lý phục vụ như là liên lạc giữa vùng biên chế và nhóm dự án. Anh/cô ấy sẽ giúp phối hợp các phiên bản Beta và

đang được dịch, vui lòng đợi..

Kết quả (Việt) 2:[Sao chép]

Sao chép!

Tên công ty
Test Plan Revision C Để biết thêm thử nghiệm / QA Templates vui lòng truy cập http://www.softwaretestinghelp.com Lịch sử Revision NGÀY REV TÁC GIẢ TẢ 5/14/07 A Bản thảo đầu tiên 5/21/07 B Thứ hai Dự thảo 5/25/07 C Added FTBT lục 1. Giới thiệu 4 1.1. Kế hoạch kiểm tra Mục tiêu 4 2. Phạm vi 4 2.1. Nhập dữ liệu 4 2.2. Chuyển ReportsFile 4 2.3. File Transfer 4 2.4. Security 4 3. Chiến lược Kiểm tra 5 3.1. Kiểm tra hệ thống 5 3.2. Hiệu suất thử nghiệm 5 3.3. An ninh Kiểm tra 5 3.4. Tự động kiểm tra 5 3.5. Stress và Khối lượng kiểm tra 5 3.6. Phục hồi thử nghiệm 5 3.7. Tài liệu Kiểm tra 5 3.8. Beta Test 5 3.9. Ký nghiệm thu 5 4. Yêu cầu Môi trường 6 4.1. Nhập dữ liệu máy trạm 6 4.2 mainframe 6 5. Kiểm tra Schedule 6 6. Thủ tục kiểm soát 6 6.1 Nhận xét 6 6.2 Bug cuộc họp đánh giá 6 6.3 Yêu cầu thay đổi 6 6.4 Defect Báo cáo 6 7. Chức năng To Be Tested 7 8. Tài nguyên và Trách nhiệm 7 8.1. Tài nguyên 7 8.2. Trách nhiệm 7 9. Phân phôi 8 10. Đình chỉ / Tiêu chuẩn Exit 9 11. Nối lại tiêu chí 9 12. Dependencies 9 12,1 Cán Dependencies 9 12,2 Dependencies Software 9 12,3 phần cứng dependancies 9 12,3 dữ liệu & Cơ sở dữ liệu thử nghiệm 9 13. Rủi ro 9 13.1. Biểu 9 13.2. Kỹ thuật 9 13.3. Quản lý 9 13.4. Cán 10 13.5 Yêu cầu 10 14. Công cụ 10 15. Tài liệu 10 16. Approvals 11 1. Giới thiệu Công ty đã phát triển nhanh hơn hệ thống bảng lương hiện tại của mình và đang phát triển một hệ thống mới này sẽ cho phép cho sự tăng trưởng và cung cấp các tính năng bổ sung. Các bộ phận kiểm tra phần mềm đã được giao nhiệm vụ thử nghiệm hệ thống mới. Hệ thống mới sẽ làm như sau:.  Cung cấp cho người dùng với các menu, hướng & các thông báo lỗi để chỉ đạo anh / cô ấy vào những tùy chọn khác nhau  Xử lý các cập nhật / bổ sung nhân viên thông tin.  In báo cáo khác nhau.  Tạo một tập tin bảng lương và chuyển các tập tin vào máy tính lớn.  Chạy trên Banyan Vines Mạng sử dụng máy tính cá nhân IBM tương thích như thiết bị đầu cuối nhập dữ liệu 1.1. Mục tiêu Kế hoạch kiểm tra này Kế hoạch kiểm tra cho các hệ thống lương mới hỗ trợ các mục tiêu sau đây:.  Xác định các hoạt động cần thiết để chuẩn bị và tiến hành các hệ thống, Beta và thử nghiệm User Acceptance  Giao tiếp với tất cả các bên có trách nhiệm chiến lược thử nghiệm hệ thống.  Xác định phân phôi và trách nhiệm các bên.  Giao tiếp với tất cả các bên có trách nhiệm các phần phụ thuộc nhiều và rủi ro 2. Phạm vi 2.1. Nhập dữ liệu Hệ thống bảng lương mới sẽ cho phép các nhân viên biên chế để nhập thông tin nhân viên từ IBM máy trạm PC tương thích chạy hệ điều hành DOS 3.3 hoặc cao hơn. Hệ thống sẽ được trình đơn định hướng và sẽ cung cấp các thông báo lỗi để giúp đỡ trực tiếp các nhân viên thông qua các tùy chọn khác nhau. 2.2. Báo cáo Hệ thống này sẽ cho phép các nhân viên biên chế để in 3 loại báo cáo. Những báo cáo này: ▪ Một báo cáo giao dịch kỳ lương  Một báo cáo ngoại lệ kỳ lương  Một báo cáo lịch sử ba tháng 2.3. File Transfer Một khi thông tin nhân viên được nhập vào cơ sở dữ liệu mạng LAN, hệ thống tính lương sẽ cho phép các nhân viên bán hàng để tạo ra một tập tin bảng lương. File này sau đó có thể được chuyển giao, qua mạng, với máy tính lớn. 2.4. An ninh Mỗi nhân viên biên chế sẽ cần một userid và mật khẩu để đăng nhập vào hệ thống. Hệ thống sẽ yêu cầu các nhân viên để thay đổi mật khẩu mỗi 30 ngày. 3. Chiến lược kiểm tra Các chiến lược kiểm thử bao gồm một loạt các xét nghiệm khác nhau mà hoàn toàn sẽ thực hiện hệ thống tính lương. Mục đích chính của các xét nghiệm này là để phát hiện ra những hạn chế hệ thống và đo lường khả năng đầy đủ của nó. Một danh sách các bài kiểm tra theo kế hoạch khác nhau và giải thích ngắn gọn sau đây. 3.1. Kiểm tra hệ thống kiểm tra hệ thống sẽ tập trung vào hành vi của hệ thống tính lương. Kịch bản người dùng sẽ được thực hiện đối với hệ thống cũng như lập bản đồ màn hình và kiểm tra thông báo lỗi. Nhìn chung, các bài kiểm tra hệ thống sẽ kiểm tra các hệ thống tích hợp và xác minh rằng nó đáp ứng các yêu cầu quy định tại các tài liệu yêu cầu. 3.2. Hiệu suất thử nghiệm hiệu suất sẽ được tiến hành để đảm bảo rằng thời gian đáp ứng hệ thống biên chế của đáp ứng mong đợi của người sử dụng và không vượt quá các tiêu chí thực hiện quy định. Trong các thử nghiệm, thời gian đáp ứng sẽ được đo stress nặng và / hoặc khối lượng. 3.3. Kiểm tra an ninh kiểm tra an ninh sẽ xác định mức độ an toàn hệ thống tính lương mới là. Các bài kiểm tra sẽ xác minh rằng người dùng truy cập trái phép vào dữ liệu bí mật được ngăn chặn. 3.4. Kiểm tra tự động Một bộ kiểm tra tự động sẽ được phát triển để kiểm tra các chức năng cơ bản của hệ thống trả lương và thực hiện các thử nghiệm hồi quy trên các lĩnh vực của hệ thống đó trước đây có / khiếm khuyết lớn quan trọng. Công cụ này cũng sẽ giúp chúng tôi bằng cách thực hiện các kịch bản sử dụng do đó cạnh tranh với một số người sử dụng. 3.5. Stress và Khối lượng thử nghiệm Chúng tôi sẽ tùy thuộc vào hệ thống biên chế các điều kiện đầu vào cao và một số lượng lớn các dữ liệu trong thời gian cao điểm. Hệ thống sẽ căng thẳng thử nghiệm bằng cách sử dụng hai lần (20 người) số lượng người dùng mong đợi. 3.6. Phục hồi thử nghiệm phục hồi sẽ buộc hệ thống thất bại trong một cách khác nhau và xác minh sự phục hồi được thực hiện đúng cách. Điều hết sức quan trọng là tất cả các dữ liệu bảng lương được phục hồi sau khi một lỗi hệ thống và không có tham nhũng của các dữ liệu xảy ra. 3.7. Kiểm tra tài liệu thử nghiệm sẽ được tiến hành để kiểm tra tính chính xác của các tài liệu hướng dẫn sử dụng. Những xét nghiệm này sẽ đảm bảo rằng không có tính năng bị thiếu, và các nội dung có thể được dễ hiểu. 3.8. Beta Test Các bộ phận tính lương sẽ beta thử nghiệm hệ thống tính lương mới và sẽ báo cáo bất kỳ khuyết tật họ tìm thấy. Điều này sẽ tùy thuộc hệ thống để kiểm tra mà không thể được thực hiện trong môi trường thử nghiệm của chúng tôi. 3.9. Ký nghiệm thu khi hệ thống tính lương đã sẵn sàng để thực hiện, bộ phận tính lương sẽ thực hiện User Acceptance Testing. Mục đích của các xét nghiệm này là để xác nhận rằng hệ thống được phát triển theo yêu cầu của người sử dụng chỉ định và đã sẵn sàng để sử dụng vào hoạt động. 4. Yêu cầu môi trường 4.1. Nhập dữ liệu máy trạm  20 IBM PC tương thích (10 sẽ được sử dụng bởi các công cụ tự động hóa để cạnh tranh với nhân viên biên chế).  286 bộ xử lý (tối thiểu)  4MB RAM  100 mb ổ cứng  DOS 3.3 hoặc cao hơn  Kèm theo Banyan Vines mạng  Một Mạng gắn máy in  20 id người dùng và mật khẩu (10 sẽ được sử dụng bởi các công cụ tự động hóa để cạnh tranh với nhân viên biên chế). 4.2 mainframe  Kèm theo Banyan Vines mạng  Truy cập vào một cơ sở dữ liệu thử nghiệm (để lưu trữ thông tin bảng lương chuyển từ hệ thống trả lương LAN) 5. Kiểm tra Schedule  Gia tăng / Hệ thống làm quen 6/01/07 - 6/15/07  Kiểm tra hệ thống 6/16/07 - 8/26/07  Beta Test 7/28/07 - 8/18/07  User Acceptance kiểm tra 8/29/07 - 9/03/07 6. Thủ tục kiểm soát 6.1 Nhận xét Các nhóm dự án sẽ thực hiện đánh giá cho từng giai đoạn. (tức là yêu cầu Xem xét, đánh giá thiết kế, Code Review, Test Plan Review, Test Case xét và thử nghiệm cuối cùng Summary Review). Một cuộc họp báo, với các tài liệu có liên quan, sẽ được gửi qua email cho mỗi người tham gia. 6.2 Bug cuộc họp đánh giá cuộc họp hàng tuần đều đặn sẽ được tổ chức để thảo luận về các khuyết tật báo cáo. Các bộ phận phát triển sẽ cung cấp tình trạng / cập nhật trên tất cả các khuyết tật báo cáo và các phòng xét nghiệm sẽ cung cấp thông tin bổ sung khiếm khuyết nếu cần thiết. Tất cả các thành viên của nhóm dự án sẽ tham gia. 6.3 Yêu cầu thay đổi khi thử nghiệm bắt đầu, thay đổi hệ thống biên chế được khuyến khích. Nếu thay đổi chức năng được yêu cầu, những đề xuất thay đổi sẽ được thảo luận với Ban kiểm soát thay đổi (CCB). Các CCB sẽ xác định tác động của sự thay đổi và nếu / khi nó cần được thực hiện. 6.4 Defect Reporting Khi khuyết tật được phát hiện, những người thử nghiệm sẽ hoàn thành một báo cáo lỗi trên hệ thống theo dõi lỗi. Hệ thống theo dõi lỗi có thể truy cập bằng cách xét nghiệm, các nhà phát triển và tất cả các thành viên của nhóm dự án. Khi một lỗi đã được cố định hoặc cần thêm thông tin, các nhà phát triển sẽ thay đổi trạng thái của các khiếm khuyết để chỉ trạng thái hiện tại. Khi một lỗi được xác nhận là đã FIXED bởi các xét nghiệm, các xét nghiệm sẽ đóng báo cáo lỗi. 7. Chức năng To Be Tested Sau đây là danh sách các chức năng đó sẽ được kiểm tra:  Thêm / cập nhật thông tin nhân viên  Tìm kiếm / Tra cứu thông tin nhân viên  Escape để trở về Menu chính tính năng  an  Mở rộng quy mô đến 700 hồ sơ nhân viên  Thông báo lỗi  Báo cáo In ấn  Tạo ra các tập tin bảng lương Chuyển  của tập tin biên chế cho các máy tính lớn màn hình ánh xạ  (dòng GUI). Bao gồm các thiết lập mặc định § FICA tính  Tính toán Thuế Nhà nước  Tính toán thuế liên bang  Gross tính lương  lương Net tính  Để lại Sick Balance tính  Để lại Balance hàng năm Tính toán Yêu cầu Một Validation Matrix sẽ "bản đồ" các trường hợp kiểm tra lại các yêu cầu. Xem Phân phôi. 8. Tài nguyên và Trách Nhiệm Các thử nghiệm chì và Quản lý dự án sẽ xác định khi thử nghiệm hệ thống sẽ bắt đầu và kết thúc. Các thử nghiệm chì cũng sẽ chịu trách nhiệm điều phối lịch trình, thiết bị, và các công cụ cho các xét nghiệm cũng như văn bản / cập nhật các kế hoạch kiểm tra, báo cáo kiểm tra tình trạng hàng tuần và báo cáo thử nghiệm Tóm tắt Cuối cùng. Các xét nghiệm sẽ chịu trách nhiệm viết các trường hợp kiểm tra và thực hiện các bài kiểm tra. Với sự giúp đỡ của các thử nghiệm chì, Quản lý Bộ lương và lương nhân viên sẽ chịu trách nhiệm về bản Beta và tài kiểm tra chấp nhận. 8.1. Tài Các đội thi sẽ bao gồm:  Một giám đốc dự án  A Test Lead  5 Testers  Vụ Biên chế quản lý  5 Payroll Clerks 8.2. Trách nhiệm quản lý dự án có trách nhiệm đối với lịch trình dự án và thành công chung của dự án. Tham gia vào CCB. Lead Developer Phục vụ như một liên hệ chính / liên lạc giữa các bộ phận phát triển và nhóm dự án. Tham gia vào Các CCB. Kiểm tra chì Đảm bảo sự thành công chung của các vòng kiểm tra. Ông / bà sẽ phối hợp các cuộc họp hàng tuần và sẽ thông báo các trạng thái thử nghiệm để nhóm dự án. Tham gia vào Các CCB. Testers Chịu trách nhiệm thực hiện việc thử nghiệm hệ thống thực tế. Vụ Biên chế quản lý Phục vụ như liên lạc giữa bộ phận tính lương và nhóm dự án. Ông / bà sẽ giúp phối hợp và Beta

đang được dịch, vui lòng đợi..

Kết quả (Việt) 3:[Sao chép]

Sao chép!

đang được dịch, vui lòng đợi..

Các ngôn ngữ khác

Hỗ trợ công cụ dịch thuật: Albania, Amharic, Anh, Armenia, Azerbaijan, Ba Lan, Ba Tư, Bantu, Basque, Belarus, Bengal, Bosnia, Bulgaria, Bồ Đào Nha, Catalan, Cebuano, Chichewa, Corsi, Creole (Haiti), Croatia, Do Thái, Estonia, Filipino, Frisia, Gael Scotland, Galicia, George, Gujarat, Hausa, Hawaii, Hindi, Hmong, Hungary, Hy Lạp, Hà Lan, Hà Lan (Nam Phi), Hàn, Iceland, Igbo, Ireland, Java, Kannada, Kazakh, Khmer, Kinyarwanda, Klingon, Kurd, Kyrgyz, Latinh, Latvia, Litva, Luxembourg, Lào, Macedonia, Malagasy, Malayalam, Malta, Maori, Marathi, Myanmar, Mã Lai, Mông Cổ, Na Uy, Nepal, Nga, Nhật, Odia (Oriya), Pashto, Pháp, Phát hiện ngôn ngữ, Phần Lan, Punjab, Quốc tế ngữ, Rumani, Samoa, Serbia, Sesotho, Shona, Sindhi, Sinhala, Slovak, Slovenia, Somali, Sunda, Swahili, Séc, Tajik, Tamil, Tatar, Telugu, Thái, Thổ Nhĩ Kỳ, Thụy Điển, Tiếng Indonesia, Tiếng Ý, Trung, Trung (Phồn thể), Turkmen, Tây Ban Nha, Ukraina, Urdu, Uyghur, Uzbek, Việt, Xứ Wales, Yiddish, Yoruba, Zulu, Đan Mạch, Đức, Ả Rập, dịch ngôn ngữ.