同步课 / 2016级测试方向—Web系统测试

TEST PLAN OUTLINE(IEEE 829 Format)

摘自：http://www.fit.vutbr.cz/study/courses/ITS/public/ieee829.html#8

TEST PLAN OUTLINE(IEEE 829 Format)

1. Test Plan Identifier2. References3. Introduction4. Test Items5. Software Risk Issues6. Features to be Tested7. Features not to be Tested8. Approach9. Item Pass/Fail Criteria10. Suspension Criteria and Resumption Requirements11. Test Deliverables12. Remaining Test Tasks13. Environmental Needs14. Staffing and Training Needs15. Responsibilities16. Schedule17. Planning Risks and Contingencies18. Approvals19. Glossary

Some type of unique company generated number to identify this test plan, its level and the level of software that it is related to. Preferably the test plan level will be the same as the related software level. The number may also identify whether the test plan is a Master plan, a Level plan, an integration plan or whichever plan level it represents. This is to assist in coordinating software and testware versions within configuration management.

Keep in mind that test plans are like other software documentation, they are dynamic in nature and must be kept up to date. Therefore, they will have revision numbers.

You may want to include author and contact information including the revision history information as part of either the identifier section of as part of the introduction.

List all documents that support this test plan. Refer to the actual version/release number of the document as stored in the configuration management system. Do not duplicate the text from other documents as this will reduce the viability of this document and increase the maintenance effort. Documents that can be referenced include:

• Project Plan
• Requirements specifications
• High Level design document
• Detail design document
• Development and Test process standards
• Methodology guidelines and examples
• Corporate standards and guidelines

State the purpose of the Plan, possibly identifying the level of the plan (master etc.). This is essentially the executive summary part of the plan.

You may want to include any references to other plans, documents or items that contain information relevant to this project/process. If preferable, you can create a references section to contain all reference documents.

Identify the Scope of the plan in relation to the Software Project plan that it relates to. Other items may include, resource and budget constraints, scope of the testing effort, how testing relates to other evaluation activities (Analysis & Reviews), and possible the process to be used for change control and communication and coordination of key activities.

As this is the "Executive Summary" keep information brief and to the point.

These are things you intend to test within the scope of this test plan. Essentially, something you will test, a list of what is to be tested. This can be developed from the software application inventories as well as other sources of documentation and information.

This can be controlled and defined by your local Configuration Management (CM) process if you have one. This information includes version numbers, configuration requirements where needed, (especially if multiple versions of the product are supported). It may also include key delivery schedule issues for critical elements.

Remember, what you are testing is what you intend to deliver to the Client.

This section can be oriented to the level of the test plan. For higher levels it may be by application or functional area, for lower levels it may be by program, unit, module or build.

Identify what software is to be tested and what the critical areas are, such as:

1. Delivery of a third party product.
2. New version of interfacing software
3. Ability to use and understand a new package/tool, etc.
4. Extremely complex functions
5. Modifications to components with a past history of failure
6. Poorly documented modules or change requests

There are some inherent software risks such as complexity; these need to be identified.

1. Safety
2. Multiple interfaces
3. Impacts on Client
4. Government regulations and rules

Another key area of risk is a misunderstanding of the original requirements. This can occur at the management, user and developer levels. Be aware of vague or unclear requirements and requirements that cannot be tested.

The past history of defects (bugs) discovered during Unit testing will help identify potential areas within the software that are risky. If the unit testing discovered a large number of defects or a tendency towards defects in a particular area of the software, this is an indication of potential future problems. It is the nature of defects to cluster and clump together. If it was defect ridden earlier, it will most likely continue to be defect prone.

One good approach to define where the risks are is to have several brainstorming sessions.

• Start with ideas, such as, what worries me about this project/application.

This is a listing of what is to be tested from the USERS viewpoint of what the system does. This is not a technical description of the software, but a USERS view of the functions.

Set the level of risk for each feature. Use a simple rating scale such as (H, M, L): High, Medium and Low. These types of levels are understandable to a User. You should be prepared to discuss why a particular level was chosen.

It should be noted that Section 4 and Section 6 are very similar. The only true difference is the point of view. Section 4 is a technical type description including version numbers and other technical information and Section 6 is from the User’s viewpoint. Users do not understand technical software terminology; they understand functions and processes as they relate to their jobs.

This is a listing of what is NOT to be tested from both the Users viewpoint of what the system does and a configuration management/version control view. This is not a technical description of the software, but a USERS view of the functions.

Identify WHY the feature is not to be tested, there can be any number of reasons.

• Not to be included in this release of the Software.
• Low risk, has been used before and is considered stable.
• Will be released but not tested or documented as a functional part of the release of this version of the software.

Sections 6 and 7 are directly related to Sections 5 and 17. What will and will not be tested are directly affected by the levels of acceptable risk within the project, and what does not get tested affects the level of risk of the project.

This is your overall test strategy for this test plan; it should be appropriate to the level of the plan (master, acceptance, etc.) and should be in agreement with all higher and lower levels of plans. Overall rules and processes should be identified.

• Are any special tools to be used and what are they?
• Will the tool require special training?
• What metrics will be collected?
• Which level is each metric to be collected at?
• How is Configuration Management to be handled?
• How many different configurations will be tested?
• Hardware
• Software
• Combinations of HW, SW and other vendor packages
• What levels of regression testing will be done and how much at each test level?
• Will regression testing be based on severity of defects detected?
• How will elements in the requirements and design that do not make sense or are untestable be processed?

If this is a master test plan the overall project testing approach and coverage requirements must also be identified.

Specify if there are special requirements for the testing.

• Only the full component will be tested.
• A specified segment of grouping of features/components must be tested together.

Other information that may be useful in setting the approach are:

• MTBF, Mean Time Between Failures - if this is a valid measurement for the test involved and if the data is available.
• SRE, Software Reliability Engineering - if this methodology is in use and if the information is available.

How will meetings and other organizational processes be handled?

What are the Completion criteria for this plan? This is a critical aspect of any test plan and should be appropriate to the level of the plan.

• At the Unit test level this could be items such as:
  • All test cases completed.
  • A specified percentage of cases completed with a percentage containing some number of minor defects.
  • Code coverage tool indicates all code covered.
• At the Master test plan level this could be items such as:
  • All lower level plans completed.
  • A specified number of plans completed without errors and a percentage with minor defects.

This could be an individual test case level criterion or a unit level plan or it can be general functional requirements for higher level plans.

What is the number and severity of defects located?

• Is it possible to compare this to the total number of defects? This may be impossible, as some defects are never detected.
  • A defect is something that may cause a failure, and may be acceptable to leave in the application.
  • A failure is the result of a defect as seen by the User, the system crashes, etc.

Know when to pause in a series of tests.

• If the number or type of defects reaches a point where the follow on testing has no value, it makes no sense to continue the test; you are just wasting resources.

Specify what constitutes stoppage for a test or series of tests and what is the acceptable level of defects that will allow the testing to proceed past the defects.

Testing after a truly fatal error will generate conditions that may be identified as defects but are in fact ghost errors caused by the earlier defects that were ignored.

What is to be delivered as part of this plan?

• Test plan document.
• Test cases.
• Test design specifications.
• Tools and their outputs.
• Simulators.
• Static and dynamic generators.
• Error logs and execution logs.
• Problem reports and corrective actions.

One thing that is not a test deliverable is the software itself that is listed under test items and is delivered by development.

If this is a multi-phase process or if the application is to be released in increments there may be parts of the application that this plan does not address. These areas need to be identified to avoid any confusion should defects be reported back on those future functions. This will also allow the users and testers to avoid incomplete functions and prevent waste of resources chasing non-defects.

If the project is being developed as a multi-party process, this plan may only cover a portion of the total functions/features. This status needs to be identified so that those other areas have plans developed for them and to avoid wasting resources tracking defects that do not relate to this plan.

When a third party is developing the software, this section may contain descriptions of those test tasks belonging to both the internal groups and the external groups.

Are there any special requirements for this test plan, such as:

• Special hardware such as simulators, static generators etc.
• How will test data be provided. Are there special collection requirements or specific ranges of data that must be provided?
• How much testing will be done on each component of a multi-part feature?
• Special power requirements.
• Specific versions of other supporting software.
• Restricted use of the system during testing.

Training on the application/system.

Training for any test tools to be used.

Section 4 and Section 15 also affect this section. What is to be tested and who is responsible for the testing and training.

Who is in charge?

This issue includes all areas of the plan. Here are some examples:

• Setting risks.
• Selecting features to be tested and not tested.
• Setting overall strategy for this level of plan.
• Ensuring all required elements are in place for testing.
• Providing for resolution of scheduling conflicts, especially, if testing is done on the production system.
• Who provides the required training?
• Who makes the critical go/no go decisions for items not covered in the test plans?

Should be based on realistic and validated estimates. If the estimates for the development of the application are inaccurate, the entire project plan will slip and the testing is part of the overall project plan.

• As we all know, the first area of a project plan to get cut when it comes to crunch time at the end of a project is the testing. It usually comes down to the decision, ‘Let’s put something out even if it does not really work all that well’. And, as we all know, this is usually the worst possible decision.

How slippage in the schedule will to be handled should also be addressed here.

• If the users know in advance that a slippage in the development will cause a slippage in the test and the overall delivery of the system, they just may be a little more tolerant, if they know it’s in their interest to get a better tested application.
• By spelling out the effects here you have a chance to discuss them in advance of their actual occurrence. You may even get the users to agree to a few defects in advance, if the schedule slips.

At this point, all relevant milestones should be identified with their relationship to the development process identified. This will also help in identifying and tracking potential slippage in the schedule caused by the test process.

It is always best to tie all test dates directly to their related development activity dates. This prevents the test team from being perceived as the cause of a delay. For example, if system testing is to begin after delivery of the final build, then system testing begins the day after delivery. If the delivery is late, system testing starts from the day of delivery, not on a specific date. This is called dependent or relative dating.

What are the overall risks to the project with an emphasis on the testing process?

• Lack of personnel resources when testing is to begin.
• Lack of availability of required hardware, software, data or tools.
• Late delivery of the software, hardware or tools.
• Delays in training on the application and/or tools.
• Changes to the original requirements or designs.

Specify what will be done for various events, for example:

Requirements definition will be complete by January 1, 19XX, and, if the requirements change after that date, the following actions will be taken:

• The test schedule and development schedule will move out an appropriate number of days. This rarely occurs, as most projects tend to have fixed delivery dates.
• The number of test performed will be reduced.
• The number of acceptable defects will be increased.
  • These two items could lower the overall quality of the delivered product.
• Resources will be added to the test team.
• The test team will work overtime (this could affect team morale).
• The scope of the plan may be changed.
• There may be some optimization of resources. This should be avoided, if possible, for obvious reasons.
• You could just QUIT. A rather extreme option to say the least.

Management is usually reluctant to accept scenarios such as the one above even though they have seen it happen in the past.

The important thing to remember is that, if you do nothing at all, the usual result is that testing is cut back or omitted completely, neither of which should be an acceptable option.

Who can approve the process as complete and allow the project to proceed to the next level (depending on the level of the plan)?

At the master test plan level, this may be all involved parties.

When determining the approval process, keep in mind who the audience is:

• The audience for a unit test level plan is different than that of an integration, system or master level plan.
• The levels and type of knowledge at the various levels will be different as well.
• Programmers are very technical but may not have a clear understanding of the overall business process driving the project.
• Users may have varying levels of business acumen and very little technical skills.
• Always be wary of users who claim high levels of technical skills and programmers that claim to fully understand the business process. These types of individuals can cause more harm than good if they do not have the skills they believe they possess.

Used to define terms and acronyms used in the document, and testing in general, to eliminate confusion and promote consistent communications.

top

项目安装包下载地址：

链接: https://pan.baidu.com/s/1rLzassBUNPtxaSE_f6ZEFA 提取码: f2pn 

如何编写测试计划

测试计划是很重要的。俗话说：凡事预则立，不预则废！软件测试同样，在测试项目之初就要制定相应的测试计划。接下来谈下如何编写测试计划问题。

一．首先了解以下几个问题：

 1．  为什么要编写测试计划？

１）领导能够根据测试计划做宏观调空，进行相应资源配置等；

２）测试人员能够了解整个项目测试情况以及项目测试不同阶段的所要进行的工作等；

3）便于其他人员了解测试人员的工作内容，进行有关配合工作

2．  什么时间开始编写测试计划？

（测试需求分析前总体测试计划书／测试需求分析后详细测试计划书）

3．  由谁来编写测试计划？

具有丰富经验的项目测试负责人

4．  测试计划编写6要素？（5W1H）

1）why——为什么要进行这些测试；

2) what—测试哪些方面，不同阶段的工作内容；

3) when—测试不同阶段的起止时间；

4) where—相应文档，缺陷的存放位置，测试环境等；

5) who—项目有关人员组成，安排哪些测试人员进行测试

6) how—如何去做，使用哪些测试工具以及测试方法进行测试。

二．测试计划主要内容：

 １．引言

１．１项目背景

１．２参考资料（计划编写依据：可行性分析报告／软件需求定义／软件概要设计／软件详细设计／用户使用说明书／……）

１．３测试术语

１．４有关项目人员组成以及联系方式（开发人员／版本控制人员／测试人员／软、硬、结构、营销人员等）

２．任务概述

２．１测试范围

２．２测试目标

２．３广义上还包含测试需求分析／测试用例编写／测试环境搭建／测试培训／测试执行等

３．测试策略

３．１测试人员需求、分工

３．２测试方法（自动化测试／手动测试；白盒测试／黑盒测试；中断测试／临界测试／压力测试等）

３．３工具引用及测试培训（内训／外训）

３．４测试阶段计划（工作内容、人员安排、起止时间等）

３．５测试停止及恢复条件

３．６测试文档及缺陷提交管理等

３．７测试环境

４．测试资源

４．１硬件资源需求

４．２软件资源需求

４．３测试环境需求

４．４测试人员需求

４．５其他（仪器、服务器等）

５．风险评估

５．１人力方面；

５．２时间方面；

５．３环境方面；

５．４资源方面

５．５部门合作方面

6．其他内容

除以上内容有关项外，还要包括测试计划制定者、日期、修改记录、评审人员（开发负责人／测试负责人／项目经理）等信息

三．编写测试计划注意事项：

１．测试计划不一定要尽善尽美，但一定要切合实际，要根据项目特点、公司实际情况来编制，不能脱离实际情况；

２．测试计划一旦制定下来，并不就是一层不变的，世界万事万物时时刻刻都在变化，软件需求、软件开发、人员流动等都在时刻发生着变化，测试计划也要根据实际情况的变化而不断进行调整，以满足实际测试要求．

３．测试计划要能从宏观上反映项目的测试任务、测试阶段、资源需求等，不一定要太过详细．

四．评审总结

1.计划评审

   测试计划编写完成后，一般要对测试计划的正确性、全面性以及可行性等进行评审，评审人员的组成包括软件开发人、营销人员、测试负责人以及其他有关项目负责人。

2.计划总结

项目完成后，应该对计划的执行情况进行评审，看有哪些不合理的地方，以便为编写下一个项目测试计划做经验积累。

你知道测试大牛怎么写测试计划的吗？

前言：

       相信大多数的软件测试工程师都听说过或者简单了解过测试计划，但是你真的知道什么是测试计划么？你真的知道如何编写测试计划么？

大多数人应该是一脸茫然。

百度的结果五花八门，有没有相对规范的标准呢？答案是没有，至少我没有找到。

那么今天我就结合经验和对一些国内技术前沿的公司跟大家聊一聊什么是测试计划以及如何编写测试计划。

计划的必要性

在我们日常的工作和生活中，经常需要做计划。古人云：凡事预则立，不预则废（《礼记.中庸》），也就是强调预先计划的重要性和必要性。

我们做项目，项目需要定项目计划；测试作为项目中的一部分，当然也需要制定测试计划。

• 测试计划就像是我们写论文一样，首先做好提纲，才能一步一步的完善填充，有了测试计划就掌握了整个项目的进度和方向，在工作中可以有个指导的作用，不至于偏离工作方向

• 测试计划规定预期的目标，以什么样的程度完成和在预期多久内完成，这样的规定能够使工作人员做好心理准备，合理的期限和目标能够使工作人员不松懈，有效率的完成一个项目

• 计划作为对未来工作的规划，肯定会受到突发的或者不稳定的因素影响而导致整个项目出现延期甚至无法进行的结果。因此计划中对于风险评估的必要性就在于罗列出影响整个项目进行的因素，并制定相应紧急方案，将损失降至最小化。

• 人员的安排呈现合理化。任何一个项目内的工作都有难易繁简的划分，因而才需要有专长的工程师进行对应的测试。难度较大的由资深测试人员安排，难度小的由新进实习生来进行，整个项目的进行就会显得合理化层次化条理化。同时将职责清晰地具体划分到个人身上，也有利于日后的纠错，及时发现哪个环节出现问题。

• 测试计划的制作是在需求分析完成之后所进行，所以测试计划的执行在一定程度上也是对需求分析的进一步的检验，若在制定过程中，发现有不合理的因素存在，还能及时反馈，进行调整，不至于使众多的人力做了无用功。

• 测试计划的安排也是一个项目中多个部门间合作的工作指导，一环扣一环，工作的交接在时间上做好详细的备注，才能让部门的合作显得默契。

一个测试计划制定者的素养

• 有多年从事测试工作的经验，能够条例清晰的罗列出测试中的流程和应当留心的步骤，以及不可缺少的风险规避的意识

• 对于部门的员工能力要有一定程度的了解，才能合理的安排工作内容

• 高压下的冷静处理能力，一旦项目出现突发的严重问题，能够冷静找出出错环节。

• 人际沟通的能力，一个测试计划也是有与其他部门之间的合作关系，需要与其保持及时有效的沟通，了解到他们的需求

那么我们什么时候来做测试计划呢？

一般来说，在产品需求确认，做过测试需求分析之后我们就要开始编写测试计划。当然测试计划编写的工作要根据工作实际来决定，也就是具体情况具体分析（政治课学的哈~）

其实，要想做好测试计划必须有一定的测试经验。那么下面我就结合工作实际，跟大家聊一聊测试计划的内容。

测试计划的内容

• 测试范围 明确测什么？比如：产品的具体业务需求有哪些？产品是web端的还是移动端的，还是两者都有？

• 测试策略 明确怎么测。对不同业务需求，具体要有哪些测试类型、测试场景、测试方法。

• 资源安排 包括测试人员的安排，测试环境是怎样的，测试工具的选择等。

• 进度安排 在明确测试范围、方法和人员之后，我们要考虑什么时候开始测试，预计要测试多久？以便和开发计划、上线计划衔接。

• 发布标准 发布标准是测试完成和产品上线需要满足的条件，以便项目内所有角色都有一致认可的目标。怎样才算是测完了？达到怎样的标准才可以上线？

• 风险预防 最后，我们需要对整个测试过程中可能存在的风险，以及当这些风险发生时的应对措施提前进行一些考虑和准备，并在测试计划中体现出来。

我们把这些内容模板化，形成测试计划的模板。无论是在实际的工作中还是大家学习编写测试计划，都可以用这样的模板来使用。