一、软件需求与测试用例

1、软件需求

1.1、IEEE软件工程标准词汇表(1997年)中定义需求为：

(1)用户解决问题或达到目标所需的条件或权能(Capability)。
(2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。
(3)一种反映上面(1)或(2)所描述的条件或权能的文档说明。它包括功能性需求及非功能性需求，非功能性需求对设计和实现提出了限制，比如性能要求，质量标准，或者设计限制。

1.2、需求一般分为：用户需求、软件需求。

用户需求：可以简单理解为甲方提出的需求，如果没有甲方，那么就是终端用户使用产品时必须要完成的任务，该需求一般比较简略。

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

大多数公司在进行软件开发的时候会把用户需求转化为软件需求，开发人员和测试人员工作的直接依据就是软件需求。软件需求是测试人员进行测试工作的基本依据。

PS：详细普及：什么是软件需求 - 知乎 (zhihu.com)

2、测试用例

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

测试用例解决了两大问题：测什么，怎么测。

1.2、意义：

测试用例是测试人员执行测试的重要依据；是自动化测试的重要依据；可以降低测试人员的工作重复性；可以保证测试质量。

3、Bug

• 产品说明书中规定要做的事情，而软件没有实现。
• 产品说明书中规定不要做的事情，而软件却实现了。
• 产品说明书中没有提到过的事情，而软件却实现了。
• 产品说明书中没有提到但是必须要做的事情，软件却没有实现。
• 软件很难理解，很难使用，速度超慢，测试人员站在最终用户的角度看到的问题是平常的但不是正确的。
• 产品说明书中没有提到但是必须要做的事情，软件确没有实现。
• 软件实现了产品的功能，但是没有考虑软件在弱网络、低电量的情况下也能正常使用，而做出来的产品在弱网络或低电量的情况下报错，那么这也是一个bug。

PS：可参考：什么是bug?bug的分类 - 知乎 (zhihu.com)

二、软件的生命周期

软件生命周期是指从软件产品的设想开始到软件不再使用而结束的时间，软件的生命周期可以分为六个阶段：需求分析、计划、设计、编码、测试、运行维护。

需求分析：需求是否合理、完整。

计划：项目由谁开发、测试，生命时候开发结束、测试结束、项目上线。

设计：开发人员设计项目底层是如何实现，再输出一个技术文档（详细记录了软件技术上如何实现，接口、库表、定时任务、mysql等）；测试人员设计测试用例。

编码：开发人员开发软件；测试人员设计测试工具、测试用例。

测试：执行测试，提交bug，验收bug。

运行维护：将项目推到线上环境，若发现线上bug，此时需要修复重新上线。
 

三、软件开发的十大模型

• 软件生命周期模型

软件生命周期分为软件定义、软件开发、运行维护三个大方面。软件定义包括问题定义（要解决什么问题）、可行性研究（对于问题有哪些解决的办法）及需求分析（用户的要求有什么）；软件开发包括总体设计（总体概要）、详细设计（具体化）、编码（程序）、单元测试及综合测试（程序调试）；运行维护即通过维护活动持久满足用户的需求。

• 瀑布模型（结构化的软件生产模型）

瀑布模型包括六个基本活动并规定了它们自上而下、相互衔接的固定次序，如同瀑布流水逐级下落。各个阶段间具有顺序性和依赖性，上一个阶段完成才能进行下一个阶段，上一个阶段的输出为下一个阶段的输入。但是各个阶段的划分完全固定，工作量大；同时开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。

特点：每个阶段都是线性的。

优点：每个阶段做什么都是很明确的。

缺点： 测试人员介入需求太晚，以至于发现问题的时机也太晚了。若发现问题，就需要不断的向前回溯。适用于较小的项目。

• 需求分析模型

需求分析模型是结构化方法下的软件需求分析模型，目的是为了分析软件有什么功能。数据字典是用来描述数据的信息集合，是一种用户可以访问的目录，主要记录数据库和应用程序元数据的目录，是数据库的重要组成部分，对用户来说是一张可读的表。实体关系图是数据建模的基，描述数据对象及其关系。数据流图是功能建模的基础，描述数据怎样转换以及转换的功能。状态转换图是行为建模的基础，表示系统的各种行为状态以及状态间的转换方式。

• 软件设计模型

软件设计模型是是结构化方法下的软件设计模型。过程设计来源于状态转化图、控制规格说明以及加工规格说明，是把结构成分转化为软件的过程性描述。接口设计来源于数据流图根据数据流图来定义软件内部各成分之间、软件与其它协调系统之间以及软件与用户之间的交互机制。体系结构设计来源于数据流图，是定义软件系统各主要成分之间的关系。数据设计来源于数据词典和实体关系图，是把描述的关系和对象以及详细数据内容转化为数据结构的定义。

• 总体设计模型

    总体设计是面向对象方法下的总体设计模型，主要包括模块的划分、数据库的设计、模块与模块之间的设计（接口设计）。其中黑盒法即功能测试，测试中把被测试的软件当成一个黑盒子，不关心盒子的内部有什么结构，只关心软件的输入和输出数据；白盒法即结构测试，是打开盒子，研究里面的源代码和程序结果。

• 详细设计

详细设计即内部设计，也是过程设计，它的核心是算法设计，是对概要设计的一个细化，详细设计每个模块实现算法、所需的局部结构。在详细设计阶段，主要是通过需求分析的结果，设计出满足用户需求的软件产品。

• 喷泉模型

喷泉模型是面向对象方法下的喷泉模型，它的特点是无缝衔接、反复迭代，各个阶段相互重叠和反复多次的出现就像喷泉一样，水喷上去可以落下来，既可以落在中间，又可以落在底部。不同阶段的圆圈相互重叠表明两个活动之间存在交迭，维护期的圈比进一步开发的圈小是因为进一步开发的可发展空间更大。

 PS：增量迭代：

如：开发APP包括1、2、3。

增量：先开发1模块，再开发2模块，再开发3模块。

迭代：先开发1部分，再开发2部分，再开发3部分。

• 面向对象需求分析的模型（OOA模型）

需求分析是分析软件具备怎样的功能。该模型包括建立描述系统静态的对象模型（类图）、描述系统控制结构的动态模型（状态图）（是一个越来越...的过程）、描述系统功能的功能模型（用例图）。其中动态模型包括顺序图、协作图和状态转换图。

 PS：

一个用例图：

一个类图：

• 面向对象的软件设计模型（OOD模型）

    OOD模型包含人机交互部分（UI设计）、问题域部分、数据管理部分、任务管理部分。人机交互部分即人和系统之间的信息交流；问题域部分是由与问题有关的部分构成；数据管理部分即将系统中的对象进行在选定的数据管理系统中进行存储、管理、应用等。

• 系统建模

系统建模的主要步骤：先根据系统的目的，提出建立模型的目的；再根据建立模型的目的提出要解决的具体问题；再根据所提出的问题提出构思出要建立的模型；进而对模型进行求解、分析、检验；若模型合格，则该模型可以使用，若不合格，则应修正模型重新进行建模等过程。

建模的整个过程：将概念模型实例化，再转化为计算机执行所需要的设计模型。

PS：

（1）螺旋模型

 特点：每一次实施前都要进行风险分析。

优点：风险分析可以避免一些未知问题。适用于规模庞大、复杂度高、风险大的项目。

缺点：分线分析一旦分析错误就会出现损失；风险分析需要一定成本。

（2）敏捷开发 scrum

特点：轻流程，重交互，拥抱变化。 

scrum 基本流程：
产品负责人整理 user story（用户故事），形成 product backlog。

发布计划会议：制定出这一期迭代要完成的 story列表、sprint backlog（sprint迭代）。

迭代计划会议：项目团队分解 story，确定负责人。

每日例会：每天 scrum master（项目经理）召集站立会议，总结前一天工作，阐述今天的计划。

演示会议：迭代结束后，召开演示会议，演示成果，po（产品经理）整理并反馈记录。

回顾会议：项目团队对本期迭代进行总结。

（3）V模型

V模型是瀑布模型的变种。

特点：V模型指出，单元和集成测试应检测程序的执行是否满足软件设计的要求；系统测试应检测系统功能、性能的质量特性是否达到系统要求的指标；验收测试确定软件的实现是否满足用户需要或合同的要求。

缺点：仅仅把测试作为在编码之后的一个阶段，未在需求阶段就进入测试

 （4）W模型

W模型增加了软件各开发阶段中应同步进行的验证和确认活动。W模型由两个V字型模型组成，分
别代表测试与开发过程，图中明确表示出了测试与开发的并行关系 

特点：测试与开发是同步的。

优点：有利于尽早、全面的发现问题。对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，显著减少总体测试时间，加快项目进度。

缺点：需求、设计、编码等活动被视为串行的；测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，下一阶段才能开始。无法支持敏捷开发模式。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临着困惑