满足用户期望或正式规定文档（合同、标准、规范）所具有的条件和权能，包含用户需求和软件需求。

用户需求：

五花八门的用户需求，该需求比较简略。

软件需求：

又叫功能需求，该需求会详细描述开发人员必须实现的软件功能。

大多数公司在进行软件开发的时候会把用户需求转化为软件需求。

为什么用户需求不能够直接作为开发人员和测试人员工作的依据？

有些用户需求要求不切实际，五彩斑斓的黑，不一定能实现，我们需要对用户需求进行需求分析。

市场可行性：        纯金声控灯（生产200万个，没人买）        没收益。

技术可行性：       

技术上能不能实现？       永动机

技术上实现是否有难度？        投入的人力成本和时间成本远远大于市场收益

需求是测试人员开展软件测试工作的依据！

测试开发人员要设计测试用例

为什么需求对软件测试人员如此重要？

从软件功能需求出发，无遗漏的识别出测试需求是至关重要的，这将直接关系到用例的测试覆盖

率

对于识别出的每个测试需求点，需要采用具体的设计测试用例的方法来进行测试用例的设计。 

如何让测试人员更好的了解需求呢？

从需求分析阶段测试人员就应该介入（测试应当贯穿与软件的整个生命周期）

什么是bug?

bug(软件缺陷)

软件的生命周期：

软件的生命周期可以分成6个阶段，即需求分析，计划，设计，编码，测试，运行维护。

需求分析：分析用户的需求是合理的（市场分析，技术上分析...）----->        软件需求文档

计划：制定需求执行计划（什么时候开始？什么时候结束？安排对少人力？

）

设计：将需求细化成一个个任务，进行技术设计（设计哪些接口，采用哪些技术）----->产出设计文档

编码：开发人员按照需求文档以及设计文档来进行编码

测试：测试人员参考测试用例来执行测试

运行维护：项目上线后对产品进行线上的维护，修复性维护：对项目中未发现的问题进行修复     

完善性维护：对功能进行完善，预防性维护：为了避免产品在线上出现一些其他的问题，进行      

一些预防的手段。

测试用例的概念：

测试用例为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境，操作步骤，测试数据，预期结果等要素。

测试用例解决了俩大问题：测什么？怎么测？