《软件测试计划模板-英文版.docx》由会员分享，可在线阅读，更多相关《软件测试计划模板-英文版.docx（9页珍藏版）》请在三一文库上搜索。
1、Software Test Plan (STP)TemplateSoftware Test Pla nINTRODUCTIONThe Introduction section of the Software Test Plan (STP) provides an overview of the project and the product test strategy, a list of testi ng deliverables, the pla n for developme nt and evolution of the STP, reference material, and age
2、ncy definitions and acronyms used in the STP.The Software Test Plan (STP) is designed to prescribe the scope, approach, resources, and schedule of all testing activities. The plan must identify the items to be tested, the features to be tested, the types of testing to be performed, the personnel res
3、ponsible for testing, the resources and schedule required to complete testing, and the risks associated with the plan1.1 Objectives(Describe, at a high level, the scope, approach, resources, and schedule of the testi ng activities. Provide a con cise summary of the test pla n objectives, the product
4、s to be delivered, major work activities, major work products, major milest on es, required resources, and master high-level schedules, budget, and effort requireme nts.)1.2 Testing StrategyTesting is the process of analyzing a software item to detect the differences between existing and required co
5、nditions and to evaluate the features of the software item.(This may appear as a specific docume nt (such as a Test Specification), or it may be part of the organization's standard test approach. For each level of testi ng, there should be a test pla n and an appropriate set of deliverables. The
6、 test strategy should be clearly defi ned and the Software Test Plan acts as the high-level test plan. Specific testing activities will have their own test pla n. Refer to sect ion 5 of this docume nt for a detailed list of specific test pla ns.)Specific test pla n comp onents in clude: Purpose for
7、this level of test, Items to be tested, Features to be tested, Features not to be tested, Man ageme nt and tech ni cal approach, Pass / Fail criteria, In dividual roles and resp on sibilities, Milest on es, Schedules, and Risk assumpti ons and con stra in ts.1.3 Scope(Specify the pla ns for produci
8、ng both scheduled and un scheduled updates to the Software Test Pla n (cha nge man ageme nt). Methods for distributi on of updates shall be specified along with versi on con trol and con figuratio n man ageme nt requireme nts must be defi ned.)Testing will be performed at several points in the life
9、cycle as the product is constructed. Testing is a very 'dependent' activity. As a result, test planning is a continuing activity performed throughout the system development life cycle. Test plans must be developed for each level of product testing.1.4 Refere nee Material(Provide a complete l
10、ist of all docume nts and other sources refere need in the Software Test Pla n. Refere nee to the followi ng docume nts (whe n they exist) is required for the high-level test pla n:* Project authorizatio n,* Project pla n,* Quality assura nee pla n,* Con figurati on man ageme nt pla n,* Orga ni zati
11、 on policies and procedures, and* Releva nt sta ndards.)1.5 Defin iti ons and Acronyms(Specify defi niti ons of all terms and age ncy acronyms required to properlyin terpret the Software Test Pla n. Refere nee may be made to the Glossary of Terms on the IRMC web page.)2. TEST ITEMS(Specify the test
12、items in eluded in the pla n. Supply refere nces to the followi ng item docume ntatio n: Requireme nts specificati on, Desig n specificati on, Users guide, Operati ons guide, In stallatio n guide, Features (availability, resp onse time), Defect removal procedures, and Verification and validation pla
13、ns.)2.1 Program Modules(Outl ine test ing to be performed by the developer for each module being built.)2.2 Job Con trol Procedures(Describe testi ng to be performed on job con trol la nguage (JCL), producti on scheduli ng and con trol, calls, and job seque ncin g.)2.3 User Procedures(Describe the t
14、esting to be performed on all user documentation to ensure that it is correct, complete, and comprehe nsive.)2.4 Operator Procedures(Describe the testing procedures to ensure that the application can be run and supported in a producti on en vir onment (in clude Help Desk procedures).3. FEATURES TO B
15、E TESTED(Ide ntify all software features and comb in ati ons of software features to be tested. Ide ntify the test desig n specificatio ns associated with each feature and each comb in ati on of features.)4. FEATURES NOT TO BE TESTED(Ide ntify all features and specific comb in ati ons of features th
16、at will not be tested along with the reas on s.)5. APPROACH(Describe the overall approaches to test ing. The approach should be described in sufficie nt detail to permit identification of the major testing tasks and estimation of the time required to do each task. Identify the types of testing to be
17、 performed along with the methods and criteria to be used in perform ing test activities. Describe the specific methods and procedures for each type of testing. Define the detailed criteria for evaluating the test results.)(For each level of testi ng there should be a test pla n and the appropriate
18、set of deliverables. Ide ntify the in puts required for each type of test. Specify the source of the in put. Also, ide ntify the outputs from each type of testi ng and specify the purpose and format for each test output. Specify the minimum degree of comprehe nsive ness desired. Ide ntify the tech n
19、iq ues that will be used to judge the comprehe nsive ness of the test ing effort. Specify any additi onal completi on criteria (e.g., error freque ncy). The tech niq ues to be used to trace requireme nts should also be specified.)5.1 Comp onent Test ing(Test ing con ducted to verify the impleme ntat
20、i on of the desig n for one software eleme nt (e.g., un it, module) or a collectio n of software eleme nts. Sometimes called un it test ing. The purpose of comp onent testi ng is to en sure that the program logic is complete and correct and en suri ng that the comp onent works as desig ned.)5.2 In t
21、egrati on Testi ng(Testi ng con ducted in which software eleme nts, hardware eleme nts, or both are comb ined and tested un til the en tire system has bee n in tegrated. The purpose of in tegrati on test ing is to en sure that desig n objectives are met and en sures that the software, as a complete
22、en tity, complies with operati onal requireme nts.In tegrati on test ing is also called System Testi ng.)5.3 Conversion Test ing(Testing to ensure that all data elements and historical data is converted from an old system format to the new system format.)5.4 Job Stream Test ing(Testi ng to en sure t
23、hat the applicati on operates in the product ion en vir onmen t.)5.5 In terface Testi ng(Testi ng done to en sure that the applicatio n operates efficie ntly and effectively outside the applicati on boun dary with all in terface systems.)5.6 Security Test ing(Testi ng done to en sure that the applic
24、ati on systems con trol and auditability features of the application are functional.)5.7 Recovery Test ing(Testi ng done to en sure that applicati on restart and backup and recovery facilities operate as desig ned.)5.8 Performa nee Test ing(Test ing done to en sure that that the applicatio n perform
25、s to customer expectations (response time, availability, portability, and scalability).5.9 Regressi on Test ing(Testi ng done to en sure that that applied cha nges to the applicati on have not adversely affected previously tested function ality.)5.10 Acceptanee Testi ng(Testi ng con ducted to determ
26、 ine whether or not a system satisfies the accepta nee criteria and to en able the customer to determ ine whether or not to accept the system. Accepta nee test ing en sures that customer requireme nts' objectives are met and that all comp onents are correctly in cluded in a customer package.)5.1
27、1 Beta Test ing(Testing, done by the customer, using a pre-release version of the product to verify and validate that the system meets bus in ess fun cti onal requireme nts. The purpose of beta testi ng is to detect applicati on faults, failures, and defects.)6. PASS / FAIL CRITERIA(Specify the crit
28、eria to be used to determ ine whether each item has passed or failed test in g.)6.1 Suspension Criteria(Specify the criteria used to suspe nd all or a porti on of the test ing activity on test items associated with the pla n.)6.2 Resumption Criteria(Specify the con diti ons that n eed to be met to r
29、esume testi ng activities aftersuspension. Specify the test items that must be repeated when testing is resumed.)6.3 Approval Criteria(Specify the conditions that need to be met to approve test results. Define the formal testi ng approval process.)7. TESTING PROCESS(Ide ntify the methods and criteri
30、a used in perform ing test activities. Define the specific methods and procedures for each type of test. Define the detailed criteria for evaluat ing test results.)7.1 Test Deliverables(Ide ntify the deliverable docume nts from the test process. Test in put and output data should be ide ntified as d
31、eliverables. Testi ng report logs, test in cide nt reports, test summary reports, and metrics' reports must be con sidered test ing deliverables.)7.2 Testing Tasks(Ide ntify the set of tasks n ecessary to prepare for and perform testi ng activities. Ide ntify all in tertask depe nden cies and an
32、y specific skills required.)7.3 Responsibilities(Ide ntify the groups resp on sible for managing, desig ning, prepari ng, executi ng, witnessing, checking, and resolving test activities. These groups may include the developers, testers, operations staff, technical support staff, data administrations
33、taff, and the user staff.)7.4 Resources(Ide ntify the resources allocated for the performa nee of test ing tasks. Ide ntify the orga ni zatio nal eleme nts or in dividuals resp on sible for perform ing testi ng activities. Assign specific responsibilities. Specify resources by category. If automated
34、 tools are to be used in testing, specify the source of the tools, availability, and the usage requirements)7.5 Schedule(Ide ntify the high level schedule for each test ing task. Establish specific milest ones for in itiati ng and completi ng each type of test activity, for the developme nt of a com
35、prehe nsive pla n, for the receipt of each test in put, and for the delivery of test output. Estimate the time required to do each test activity.)(Whe n pla nning and scheduli ng test ing activities, it must be recog ni zed that the testi ng process is iterative based on the testi ng task depe nden
36、cies.)8. ENVIRONMENTAL REQUIREMENTS(Specify both the n ecessary and desired properties of the test en vir onment in clud ing the physical characteristics, com muni cati ons, mode of usage, and testi ng supplies. Also provide the levels of security required to perform test activities. Identify specia
37、l test tools needed and other testing needs (space, machine time, and stationary supplies. Identify the source of all n eeds that is not curre ntly available to the test group.)8.1 Hardware(Ide ntify the computer hardware and n etwork requireme nts n eeded to complete test activities.)8.2 Software(I
38、de ntify the software requireme nts n eeded to complete test ing activities.)8.3 Security(Ide ntify the test ing en vir onment security and asset protect ion requireme nts.)8.4 Tools(Ide ntify the special software tools, tech niq ues, and methodologies employed in the test ing efforts. The purpose a
39、nd use of each tool shall be described. Pla ns for the acquisition, training, support, and qualification for each tool or technique.)8.5 Publications(Ide ntify the docume nts and publicati ons that are required to support test ing activities.)8.6 Risks and Assumptions(Ide ntify sig nifica nt con str
40、a ints on testi ng such as test item availability, test resource availability, and time constraints. Identify the risks and assumptions associated with testi ng tasks in cludi ng schedule, resources, approach and docume ntati on. Specify a con ti ngency pla n for each risk factor.)9. CHANGE MANAGEMENT PROCEDURES(Ide ntify the software test pla n cha nge man ageme nt process. Define the cha nge in itiati on, cha nge review, and cha nge authorizati on process.)10. PLAN APPROVALS(Ide ntify the pla n approvers. List the n ame, sig nature and date of pla n approval.)Plan First!9/22/20189:27:27 AM8