软件开发模型、软件测试模型和软件测试的分类

软件开发模型：

概念：一套知道软件开发的流程或制度。

分类：

一，瀑布模型：阶段（6个）和时序 【重要】

（1）需求分析：BA（需求分析师，产品经理，项目经理）。产出：需求说明说。 说明：一切软件测试活动的依据
（2）概要设计：架构师（开发）技术型文档。产出： 概要设计说明书
（3）详细设计：开发。产出：详细设计书
（4）编码：开发。【编码之后开启相关测试工作】
（5）软件测试：测试。
（6）软件维护：运维

特点：线性模型，其他模型的基础。比较重要的地位
优点：阶段清楚。一个阶段只执行一次，当前阶段结束后，只需要关注后续阶段工作。文档驱动。
缺点：不适用需求变化的项目，返工量大
应用场景：需求清晰的大型项目。建筑，银行，保险等…

二，快速原型模型—— 敏捷开发模型（app项目）【了解】
概念：在开发系统之前先做一个原型（demo/小样）,然后让用户参与进来从而收集整理相关反馈信息。以此类推，最终完成整个项目的开发
步骤：分析，构造，运行，评价（反馈）
优点：用户参与。降低需求变化带来的项目失败的风险。
缺点：不适用于大型项目
应用场景：需求变化的中小型项目。

【迭代：分阶段、分目标实现】

三，螺旋模型 【了解】
特点：结合了瀑布模型与快速模型的优点。引入了一种风险分析的方法论。
优点：引入了风险防范的意识
缺点：风险需要专业的风险分析人士评估
应用场景：需求不清晰的大型项目

迭代模型：冲刺，迭代，spint
敏捷开发模型：迭代。

测试为什么要了解开发模式： 沟通，协调，测试的工作职责。

软件测试模型：

概念：一套知道软件而是的流程或制度。

3大主流的软件测试模型：
V模型（重点）：
组成：阶段（8个） ，时序
需求分析→概要设计→详细设计→编码→单元测试→集成测试→系统测试→验收测试
优点：线性模型、其他模型的基础。 文档驱动。阶段清晰。
缺点：不适用于需求变化。返工量大。

W模型（重点）：双V模型
组成：阶段和时序
开发V：需求分析→概要设计→详细设计→编码→集成→实施→交付
测试V：验收或系统测试设计→集成测试设计→单元测试设计→ 单元测试→集成测试→系统测试→验收测试
优点：测试全程参与（参与软件的全流程）。测试对象（需求文档。测试设计文档。代码/系统/软件）
缺点：流程性太强。越晚发现Bug，修复成本越高，指数式增长。灵活度低。很强的业务知识背景。
测试要早介入、早发现、早解决。

H模型（了解）
组成：测试准备。测试就绪点。测试执行。
优点：强调了测试执行之后还有很多其他工程（环境搭建，测试数据准备，需求分析，各部门与角色之后的沟通协调）。把测试流程独立出来。
缺点：测试就绪点不容易明确（定量的标准把握）。管理成本增加。

软件测试的分类：

按阶段分类：
（1）单元测试：
针对单独的模块进行功能测试（如：登录，注册，购物车，支付，订单管理等）。【测试工程师】
针对代码的测试（C语言的函数，Java的类等）。【开发工程师→测试开发岗（TDD：测试驱动开发）。面试中更多的提法】
（2）集成测试：
对已通过单元测试的多个模块的进行组合测试。

     （3）系统测试：
站在系统的高度，整体把控与测试整个软件系统中，强调系统的整体性。（软件+硬件）

      （4） 验收测试：
客户组织的基于最开始的需求进行的验证性测试，只要检验乙方（软件实施方）完成的系统是否满足甲方（付款方）的业务需求。

     分类：
α测试（内测版本）
β测试（公测版本）
γ测试（待发布版本）

     负责人（扩展）：客户（甲方）。委托第三方评测机构（中国软件评测中心）。乙方（软件实施方）

按是否运行划分：
（1）静态测试：
概念：静态方法就是指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口来检查程序的正确性。
测试对象：需求说明书。各类设计文档。源程序做结构分析、流程图分析、符号执行等【代码走查】

（2）动态测试
概念：动态测试方法是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率、正确性和健壮性等性能。
测试对象：代码/系统/软件。
步骤：测试用例设计（需求分析）。执行测试用例。检查运行结果与预期结果。

按是否查看源代码：
一，黑盒测试【重点】——【不看代码】——测试的输入和测试的输出

概念：也称为功能测试、业务功能测试、逻辑功能测试，是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求说明书的规定正常使用，程序是否能适当地接受输入数据而产出正确的输出信息。
测试依据：需求说明书。
重点：不需要考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。是以用户的角度，从输入数据和输出数据的对应关系出发进行测试的。
缺点：如果外部特性本身设计有问题或规格说明的规定有误，用黑盒测试方法是发现不了的。
一般运用在：单元测试（测试单独的模块）
    分类：
   （1）功能测试：
业务功能测试，界面测试（UI），易用性测试，安装测试，升级或卸载测试

   （2） 性能测试：
时间特性，稳定性能，压力测试（资源匮乏），负载测试（资源充足）。
1

二，白盒测试【了解】——【看代码】——代码的逻辑

概念：又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。白盒测试是一种测试用例设计方法，盒子指的就是被测试的软件，白盒指的是盒子是可观的，清楚盒子内部的东西以及里面东西是如何运作的。
方法：白盒法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。
重点：在使用这一方法时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试依据。
缺点：白盒法是穷举路径测试，贯穿程序的独立路径是天文数字。
一般运用在：单元测试（开发）

三，灰盒测试【了解】
概念：介于黑盒测试与白盒测试，往往需要在测试阶段的后续活动中使用到。
可能运用在：集成测试、系统测试阶段。

按是否自动化划分：
手工测试：手工的方式去执行测试。
自动化测试：需要借助工具或代码去完成手工测试工作。

其他分类：
冒烟测试【重点】：针对最基本的功能或者流程进行的测试。
回归测试【重点】：是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。
应用场景：bug回归； 旧功能回归。
回归原则：每一个版本都需要进行前一个版本的回归测试工作（除了第一个版本）。
需要轮次：取决于实际项目计划、开发计划、测试计划和项目本身规模与复杂度。
缺点：工作量大。
解决方案：自动化测试：自动回归测试将大幅度降低系统测试、维护升级等阶段的成本。
随机测试【了解】：需要一定的相关经验。测试一些重要功能。测试其他没有到的模块。
探索性测试【了解】测试思维技术。具体问题具体分析。测试设计与测试执行同时执行。

软件测试用例：
概念：一个为了特地目的而设计，包含测试输入、执行条件、预期结果的文档

八大要素：
编号ID【唯一性】
标题【见名知意】
优先级【在资源受限制（时间、人员）时，测试用例执行的先后顺序。】
项目/模块
测试数据
前置条件：外在环境（网络、系统服务正常与否）。本模块的前置模块
预期结果：需求文档。
测试步骤：

作用：	
（1）便于理清测试思路，确保须覆盖测试的功能点无遗漏
（2）便于测试工作的评估
（3）便于提前准备测试数据
（4）便于把控测试工作进度
（5）便于回归测试
（6）便于测试工作的组织、提高测试效率、降低测试交接成本。