软件测试生命周期——需求分析、测试计划、测试用例设计、测试执行和测试评估_从质量评估的角度进行测试设计,包括测试用例设计,执行测试,完成测试及评估报告。

一、需求分析

1、测试人员要充分了解需求，得出测试点和测试需求。

2、需求评审会议

在需求评审会议上，测试人员要确认每个功能的异常状态、数量以及如何转化，要多问为什么（用户是谁，软件的整体框架，要解决什么问题，变更需求影响的点有哪些，是否需要确认等）。

目的：了解产品，为写测试用例提供支持，为提bug找依据。

人员：需求分析师/产品经理(BA/PM)主讲，开发人员和测试人员参加

文档：产品需求文档

流程：BA/PM整理出产品需求文档后，开发人员和测试人员提前学习，在需求评审会议上，先是需求人员主讲，开发人员和测试人员提出问题和建议，需求人员给出答复，开发人员和测试人员确认需求后，进行反串讲，在这过程中有问题，需求人员再讲解，最终需求人员整理出完整的产品需求说明书。

二、测试计划

测试计划是一个叙述了预定的测试范围、测试资源（软硬件）以及进度安排的文档。

主要包含：产品概述、测试策略、测试方法、测试范围、时间安排、测试人力和风险分析等。

目的：规范软件测试的内容、方法和过程，使软件测试工作更易于管理，使软件测试工作更顺利，促进项目相关人员的沟通。

原则：应尽早开始、简洁易读、多渠道评审、计算测试投入。

三、测试用例设计

测试人员通过需求了解开发计划，进行测试用例设计。

测试用例要能让人看懂在测什么，如何测，结果是什么。

1、编写原则

系统性：大系统与小系统的跳转关系。

连贯性：各个子系统是如何联系在一起的。

全面性：应包括各种路径和各个业务点，并要考虑大数据和特殊数据的构造。

正确性：实际的输入与输出应与测试文档记录的一致。

2、编写标准

统一的模板；

清楚、精简；

数据要全面，包括正确数据、非法数据和特殊数据；

按照业务逻辑场景梳理，保证正确性；

需求变更要及时更新测试用例。

3、用例级别

①critical极为重要的②important重要的③general一般的④low低级的

4、测试用例包含编号、模块、场景、用例名称、用力级别、前提条件、操作步骤、预期结果、实际结果、是否通过、是否自动化、是否冒烟用例、备注等内容。

5、测试用例设计方法

详细内容请参照这篇文章：https://blog.csdn.net/hpwalk/article/details/107330892

四、测试执行

结合测试方法和测试知识，暴露软件缺陷。

要求：把我软件质量，满足软件需求，注意不能出现明显bug：如404，505等。

五、测试评估

测试给出测试评估，做出测试报告总结，包括软件是否满足需求，是否关闭严重bug等，保证软件正常上线。