软件开发过程模型
开发人员在实际企业中的工作流。
瀑布模型
特点：
- 他是线性模型的一种。
- 按照线性的顺序进行软件开发，每个阶段都要执行一次。
流程：
- 需求分析 ---产品经理（PM）---需求文档
- 设计 ---UI设计师（UI）---设计图
- 编码 ---开发（RD）---软件
- 实现
- 测试 ---软件测试工程师（QA）---测试报告
- 完成
- 维护 ---一般由QA执行软件上线后的维护工作
优点：
- 每个阶段都清晰明了。
- 当前阶段完成后只需要关注后续阶段即可。
缺点：
- 不适应需求的变化。
- 会导致错误需求的蔓延和传递，返工量大。
- 测试人员介入时间较晚，对于早期的错误不能及时发现，失去了提前纠正的机会。
快速原型模型*
定义：快速的构造出产品的框架，直接给到用户使用，再收集用户的反馈和建议，再做出针对性的修改，循环往复，直到用户满意。
流程：
- 快速分析
- 构造
- 运行
- 评价
优点：克服了瀑布模型的缺点，适应了需求的变化。
缺点：不适应大型系统的开发，只适应小型的，灵活度高的系统的开放。
螺旋模型*
定义：类似于瀑布模型。在每一步执行之前都要进行一轮风险分析。
优点：在很大程度上是一种风险驱动的方法体系。
缺点：如果预测失败，势必会给公司带来损失。
软件测试的分类
- 按照测试阶段划分
- 单元测试：对每一个小的单元进行测试。
- 集成测试：将每个小的单元集成在一起进行测试。
- 系统测试：对开发好的产品的功能、性能、兼容性进行的测试。
- 验收测试：用户完成的测试。
alpha版本（内测版）：一般是由公司内部专业测试人员使用的版本。
beta版本（公测版）：开发人员给到一些想要体验的用户使用的版本，然后收集用户的反馈和建议，再做出针对性的修改。
gamma版本：正式版本的候选版。
- 按照是否查看源代码划分
- 黑盒测试：不关注程序的源代码，只关注程序的输入和输出。
功能测试：
- 逻辑功能测试
- 界面测试
- 易用性测试
- 安装、升级、卸载测试
性能测试：
- 时间性能
- 空间性能
- 稳定性能
- 负载压力
- 白盒测试：不关注程序的输入和输出，只关注程序的源代码。
- 灰黑测试：介于黑盒和白盒之间的一种测试。
- 按照是否运行划分
- 静态测试：不运行被测程序，只是静态的查看界面、文档、代码是否存在错误的过程。
- 动态测试：运行被测程序，输入测试数据，对比实际结果和预期结果是否存在差异的过程。
- 按照是否自动化划分
- 手工测试
- 自动化测试
特点：以代码的形式代替手工测试。（不能完全代替）
需要在手工测试完成之后才能进行自动化测试。
自动化测试不是用来发现问题的，而是用来验证程序是没有问题的。
注意：自动化不能验证程序完全没有问题，验证的是用户使用程序时的操作流程没有问题。
- 其他类型
- 冒烟测试：在拿到一个新的版本后，对该版本的主要功能和流程进行的测试。
- 回归测试：回归到开发人员修复过的bug的功能点，再次进行测试。
- 随机测试：在测试完成后，对该版本的主要功能再次进行测试的过程。
- 探索性测试：在没有需求文档和设计图的情况下，根据测试人员的经验进行的测试。
软件测试模型
- V模型
- 用户关注的层面在上面，用户不关注的层面在下面。
流程：
- 需求分析
- 概要设计
- 详细设计
- 编码
- 单元测试
- 集成测试
- 系统测试
- 验收测试
优点：
- 每个阶段都清晰明了。
- 当前阶段完成后只需要关注后续阶段即可。
- 即包含了底层测试（单元测试），又包含了高层测试（系统测试）。
缺点：
- 不适应需求的变化。
- 会导致错误需求的蔓延和传递，返工量大。
- 测试人员介入时间较晚，对早期的错误不能及时的发现和改正。
- W模型（双V模型）
| 开发一个V模型 | 测试一个V模型 |
| 需求分析 | 系统/验收测试设计 |
| 概要设计 | 集成测试设计 |
| 详细设计 | 单元测试设计 |
| 编码 | 单元测试 |
| 集成 | 集成测试 |
| 实施 | 系统测试 |
| 交付 | 验收测试 |
优点：
- 测试伴随整个周期，测试的对象不仅仅是程序，还包括需求文档和UI设计图。
- 测试人员介入时间较早，降低修复成本。
- 同样是分阶段工作，更便于把控整个项目。
缺点：
- 不适用于小型企业，适用于大型企业。
- H模型
流程：
- 测试准备。
- 到达测试就绪点。
- 执行测试。
优点：测试工作相对独立、贯穿整个生命周期、与其他工作人员并发进行。
缺点：测试就绪点不好分析。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
