标签：软件开发 模型 质量保证 测试 设计 model 软件测试 2.4
文章目录
1. 软件测试与软件开发过程关系概述
- 软件开发和软件测试都是软件生命周期中重要的组成部分
- 软件开发特点：自顶向下、逐步细化
- 软件测试特点：自底向上、逐步集成
- 软件生命周期模型：瀑布模型、原型模型、快速应用开发模型、增量模型、螺旋模型、V模型、形式方法模型、RUP（Rational Unified Process）模型、敏捷过程模型、构件组装模型、并发开发模型等。
- 软件生命周期模型几种比较流行的模型
（1）传统的瀑布模型（Waterfall Model）
（2）原型模型（Prototyping Model）
（3）螺旋模型（Spiral Model） - 软件测试定义
（1）狭义：测试总是在程序设计之后。这里的测试专指测试程序代码
（2）广义：测试活动可以在软件开发生命周期的任何阶段进行。但越大后期，找出错误并改正它的代价就越大 - 全新的软件开发模式：以测试驱动开发。软件测试贯穿整个开发过程，参与到了软件开发生命周期的各个阶段
2. 软件测试在软件开发生命周期中的位置
2.1 软件开发生命周期
- 软件生命周期的三个阶段：
（1）软件规划阶段
（2）开发阶段。开发阶段还可以细分为软件设计、编码和测试阶段
（3）运行与维护阶段
2.1.1 软件规划阶段测试
（1）产品策划：由项目经理确定进度计划、项目范围和开发产品所需的资源
（2）需求分析：由产品市场开发团队根据客户提出的要求来描述产品的需求
2.1.2 软件设计阶段测试
- 软件设计阶段测试：软件设计阶段是设计人员将软件需求转换为语言文字或图表集合，设计分为外部设计和内部设计，或分为高层设计（或概要设计）和低层设计（或详细设计）
- 外部设计主要从用户角度对产品进行描述，内部设计则描述产品的外部工作机制。他们并行展开，相互制约，相互要求。
- 概要设计描述总体系统架构应包含的组成元素，各个模块之间的关系。详细设计主要描述各个模块如何实现及所用的算法和数据结构
- 软件设计阶段测试的对象：设计文档
软件设计阶段测试的内容：评审设计文档是否满足需求、完备、可行
2.1.3 软件开发阶段测试
- 软件开发编码阶段测试
在编码阶段通过白盒测试对编写代码、程序进行测试。主要结构测试、集成测试等 - 软件测试阶段测试
2.2 软件测试在软件开发生命周期中的位置
- 软件测试与软件开发的关系
- 软件测试方法在软件开发过程的运用
（1）在软件需求分析与建模阶段中：测试的对象是相关文档材料，如需求规格说明书等。采用静态测试方法
（2）在概要设计与详细设计阶段：用静态测试方法，对文字、图表等进行评审
（3）在编码工作阶段：主要由程序员来进行测试，通过采用高级语言对详细设计模块进行编程。主要是对已有的程序代码进行白盒测试，可以是动态和静态相结合，采用各种覆盖方法进行测试（白盒测试）
（4）在测试阶段：此时进行集成与系统测试。集成测试采用灰盒测试方法（白盒与黑盒相结合），主要测试产品的接口以及各模块之间的关系。而系统测试一般采用黑盒测试方法，主要测试系统的功能、性能等；由测试人员来完成测试。
（5）在检验交付与维护阶段，模拟或实际客户环境，对系统进行验收测试。大多采用自动化测试工具进行测试验收。包括功能测试、性能测试、回归测试、发布测试等 - 软件测试与软件开发过程之间的关系。习惯上程序设计在前，测试在后。对于一些复杂的程序，可将测试分为同步测试与总测试
- 软件测试过程模型：
（1）单元测试：是基于代码测试，最初由开发人员执行，已验证其可执行代码的各个部分是否已达到预期的功能要求
（2）集成测试：是为了验证2个或多个单元之间的集成是否正确，并有针对性地对详细设计中所定义的各个单元之间的接口进行检查。
（3）系统测试：在所有的单元测试和集成测试完成后，系统测试开始完整的模拟客户环境，运行系统进行测试，以验证系统是否到达了在概要设计中所定义的功能和性能
（4）验收测试：当技术部门完成了所有的测试工作后，有业务专家或用户进行验收测试，以确保产品能真正符合用户业务上的需要
3. 软件测试模型
3.1 V model
- V model特点
（1）V模型是软件开发瀑布模型的变种
（2）反映了测试活动与分析和设计的关系
（3）V模型软件测试策略包括
低层测试，为了源代码的正确性
高层测试，为了使整个系统满足用户 - V模型局限性：仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段，忽视了测试对需求分析、系统设计的验证，一直到后期的验收测试才被发现
3.2 W model
- W模型的特点：
（1）W模型由两个V字形模型形成，分别代表测试与开发过程
（2）W模型强调，测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样要测试
（3）测试与开发是同步进行 - W模型的局限性
（1）把软件的开发视为需求、设计、编码等一系列串行的活动
（2）把软件开发和测试保持一种线性的前后关系，需要有严格的指令表示上一阶段完全结束，才可以正式开始下一个阶段
（3）无法支持迭代开发模型
3.3 H model
- H模型特点
（1）H模型将测试活动完全独立活动，形成一个完全独立的流程，贯穿于整个产品周期，与其他流程并发地进行
（2）尽早准备，尽早执行
（3）测试准备与测试执行分离，有利于资源调配、降低成本，提高效率
（4）充分体现测试过程
3.4 X model
- X模型的特点
（1） X模型左边描述的是针对单独程序片段所进行的相互分离的编码和测试，此后，将进行频繁的交接，通过集成最终合成为可执行的程序；
（2） x模型还定位了探索性测试，这是不进行事先计划的特殊类型的测试，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误 - X模型的局限性
（1）提出了测试设计，却没有指出在软件测试的各个阶段都应该进行测试设计;
（2）过于关注低级别即程序级别的行为，而没有抽象成一个系统的模型
（3）可能对测试造成人力、物力和财力的浪费，对测试员的熟练程度要求比较高型.
3.5 pretest model
pretest-model是将测试和开发紧密结合的模型
3.6 测试模型的比较
- V-model强调了在整个软件项目开发中需要经历的若干个测试级别，而且每一个级别都与一个开发级别相对应，但它忽略了测试对象不仅仅包括程序，或者说它没有明确地指出应该对软件的需求、设计进行测试。
- W-model强调了测试计划等工作的先行和对系统需求和系统设计的测试，但W-model和V-model一样也没有专门对软件测试流程予以说明，因为事实上，随着软件质量要求越来越为大家所重视，软件测试也逐步发展成为一个独立于软件开发部的组织，就每一个软件测试的细节而言，它都有一个独立的操作流程。比如，现在的第三方测试，就包含了从测试计划和测试案例编写，到测试实施以及测试报告编写的全过程，
- H-model强调测试是独立的，只要测试准备完成，就可以执行测试了。
- X-model和Pretest-model又在此基础上增加了许多不确定因素的处理情况，因为在真实项目中，经常会有变更的发生，例如需要重新访问前一阶段的内容，或者跟踪并纠正以前提交的内容，修复错误，排除多余的成分，以及增加新发现的功能等
4. 软件测试过程
- ISTQB定义的软件测试过程逻辑框图
4.1 测试计划和控制
- 软件测试应贯穿于整个软件开发生命周期
- 测试计划的内容：
（1）测试范围
（2）测试策略
（3）测试资源
（4）进度安排
（5）发布标准
（6）风险预防
4.1.1 测试范围
测试范围来自于需求文档，依据是项目的交互稿和需求分析的结果
- 功能测试的范围：功能点的拆分、接口测试、UI测试
- 系统测试范围
1)容错处理。如断网、业务处理过程中断等
2)兼容性要求
3)配置要求
4)性能要求
5)安全性要求
6)可靠性、日志文件
4.1.2 测试策略
测试策略定义了项目的测试目标和实现方法。因此，测试策略决定了测试的工作量和成本
- 基于测试技术的测试策略
(1).任何情况下都要使用边界值分析方法
(2).等价类划分法是对边界值分析方法的有效补充
(3).如果功能的输入数据/条件存在多种组合情况，则使用因果图
(4).错误推测法
(5).对照程序逻辑来审查已有测试用例的逻辑覆盖程度
(6).白盒测试 - 分阶段的测试策略
(1).严格执行代码审查
(2).单元测试和集成测试，准备自动化测试
(3).系统测试中，以每次发布用户基线为结束标志
(4).不能忽略安全性测试、可用性测试、配置测试和数据完整性测试
(5).在功能测试、安全性测试、配置测试中进行探索性测试 - 基于测试方案的综合测试策略
(1).测试优先级，优先级越高，越早测试，测试力度越大
(2).使用尽可能少的测试用例，发现尽可能多的程序错误
(3).测试策略尽量简单、清晰
(4).基于缺陷分析的测试策略
4.1.3 资源安排
- 测试人力资源主要有两个维度
（1）测试人员数量
（2）测试人员经验、能力 - 环境资源一般包括
（1）测试环境（尽量与线上环境保持一致）
（2）终端环境（PC配置，手机型号）
（3）测试工具（bug管理工具，用例管理工具，性能测试工具等）
在测试计划中，测试人员分配、测试环境资源、网络资源、工具使用都要明确写出来。
4.1.4 进度安排
测试工作的进度安排依赖于开发工作的节点和提交测试进度的时间，并且直接影响预期的上线时间。需要根据产品业务的复杂度、所需要进行的不同的测试类型的复杂度、产品上线的质量要求的高低、测试人员的数量、能力和经验这些因素，来评估不同阶段、不同类型的测试工作的工作量。
- 工作分解结构表方法评估工作量：
（1）列出本项目需要完成的各项任务；
（2）细化每个任务，尤其是测试阶段，需要对模块进行拆分，拆分到可衡量和细化的维度；
（3）预先设计测试点，按照测试点来估算；
（4）给每个维度估算时间，需要优化和重复操作的部分；
（5）在已估算结果上浮动10%-15%；
4.1.5 发布标准
主要包括：
1、测试计划里所有测试类型都已经完成了
2、功能上、兼容性上没有影响用户使用的Bug
3、允许遗留小部分影响不是很大的Bug，但这个数量应该小于一个值
4、性能上符合设计目标和上线要求 这些标准都是针对测试工作本身的要求
4.1.6 风险预防
测试风险分类
- 测试范围的风险：一开始测试需求分析不准确，漏了测试点
- 测试进度的风险：做计划时工作量估计的不准，导致项目延期
- 产品质量的风险：开发的代码质量比较低或测试人员是新人对业务不熟悉
测试风险的控制方法
- 根据风险发生的概率和带来的影响确定风险的优先级，然后采取措施避免那些可以避免的风险
- 风险转移，比如去掉新功能
- 对于不可避免的风险就设法降低风险，如提高测试用例的覆盖率
- 事先做好风险管理计划
- 有一套应急、有效的处理方法，比如全员了解，注意日常观察，及时发现风险出现的征兆；
- 做计划时，要留有余地
- 制定文档标准
4.2 测试设计和分析
- 测试计划完成后，测试过程就进入了软件测试设计和开发阶段。这个阶段的第一个任务是对测试依据进行评审
- 测试用例的规格说明主要分为两步
（1）定义逻辑测试用例
（2）选择实际输入，将逻辑测试用例转换为具体测试用例
4.3 测试实现和执行
测试的执行包括：手工测试和自动化测试
-
手工测试优点
（1）测试人员具有经验和对错误的猜测能力。
（2）测试人员具有审美能力和心理体验。
（3）测试人员具有是非判断和逻辑推理能力。 -
手工测试缺点
（1）重复的手工回归测试，代价昂贵、容易出错。
（2）依赖于软件测试人员的能力 -
自动化测试的优点：
（1）对程序的回归测试更方便。
（2）可以运行更多更繁琐的测试。
（3）可以执行一些手工测试困难或不可能进行的测试。
（4）更好地利用资源。
（5）测试具有一致性和可重复性
（6）测试的复用性
（7）增加软件信任度 -
自动化测试的缺点：
（1）不能取代手工测试
（2）手工测试比自动测试发现的缺陷更多
（3）对测试质量的依赖性极大
（4）测试自动化不能提高有效性
（5）测试自动化可能会制约软件开发。由于自动测试比手动测试更脆弱，所以维护会受到限制，从而制约软件的开发。
（6）工具本身并无想像力 -
执行测试流程
执行测试流程描述
（1）首先需要进行完整性测试：将所有的测试对象都安装在一个有效的测试环境中，来判定它是否可以正常启动并运行主要业务流程。
（2）其次需要测试软件是否能够运行主要功能，如果在测试中发现了缺陷或是未能完成的功能，应该进行更正或是修复后再继续进行测试。
（3）进行其它的测试。
4.4 测试出口准测的评估和报告
软件测试出口准则的评估是指检验测试对象是否符合预先定义的一组测试目标和出口准则的活动。
软件测试出口准则的评估可能出现的结果：
- 测试结果满足所有出口准则，可以正常结束测试。
- 测试结果满足所有出口准则，要求执行一些附加测试用例。
- 测试出口准则要求过高，需要对测试出口准则进行修改
除了测试覆盖率以外，测试出口准则还可以包括其他条目，例如失效发现率，也叫缺陷发现百分比，根据失效发现率评估测试出口准则时还应考虑失效的严重程度，对失效进行分类并区别对待
4.5 测试活动结束
测试全部完成，并不意味着测试项目的结束，还需做以下工作
（1）在测试过程的背后，有可能会遗漏一些活动
（2）书写测试报告或质量报告
（3）对测试计划、测试设计和测试执行等进行检查分析，完成项目总结，编写总结报告
标签：软件开发,模型,质量保证,测试,设计,model,软件测试,2.4 来源： https://blog.csdn.net/qq_44807176/article/details/117569984
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。