一、需求分析
1、测试人员要充分了解需求，得出测试点和测试需求。
2、需求评审会议
在需求评审会议上，测试人员要确认每个功能的异常状态、数量以及如何转化，要多问为什么（用户是谁，软件的整体框架，要解决什么问题，变更需求影响的点有哪些，是否需要确认等）。
目的：了解产品，为写测试用例提供支持，为提bug找依据。
人员：需求分析师/产品经理(BA/PM)主讲，开发人员和测试人员参加
文档：产品需求文档
流程：BA/PM整理出产品需求文档后，开发人员和测试人员提前学习，在需求评审会议上，先是需求人员主讲，开发人员和测试人员提出问题和建议，需求人员给出答复，开发人员和测试人员确认需求后，进行反串讲，在这过程中有问题，需求人员再讲解，最终需求人员整理出完整的产品需求说明书。
二、测试计划
测试计划是一个叙述了预定的测试范围、测试资源（软硬件）以及进度安排的文档。
主要包含：产品概述、测试策略、测试方法、测试范围、时间安排、测试人力和风险分析等。
目的：规范软件测试的内容、方法和过程，使软件测试工作更易于管理，使软件测试工作更顺利，促进项目相关人员的沟通。
原则：应尽早开始、简洁易读、多渠道评审、计算测试投入。
三、测试用例设计
测试人员通过需求了解开发计划，进行测试用例设计。
测试用例要能让人看懂在测什么，如何测，结果是什么。
1、编写原则
系统性：大系统与小系统的跳转关系。
连贯性：各个子系统是如何联系在一起的。
全面性：应包括各种路径和各个业务点，并要考虑大数据和特殊数据的构造。
正确性：实际的输入与输出应与测试文档记录的一致。
2、编写标准
统一的模板；
清楚、精简；
数据要全面，包括正确数据、非法数据和特殊数据；
按照业务逻辑场景梳理，保证正确性；
需求变更要及时更新测试用例。
3、用例级别
①critical极为重要的②important重要的③general一般的④low低级的
4、测试用例包含编号、模块、场景、用例名称、用力级别、前提条件、操作步骤、预期结果、实际结果、是否通过、是否自动化、是否冒烟用例、备注等内容。
5、测试用例设计方法
详细内容请参照这篇文章：/hpwalk/article/details/107330892
四、测试执行
结合测试方法和测试知识，暴露软件缺陷。
要求：把我软件质量，满足软件需求，注意不能出现明显bug：如404，505等。
五、测试评估
测试给出测试评估，做出测试报告总结，包括软件是否满足需求，是否关闭严重bug等，保证软件正常上线。
如果觉得《软件测试生命周期——需求分析 测试计划 测试用例设计 测试执行和测试评估》对你有帮助，请点赞、收藏，并留下你的观点哦！
