标签：快速 采集 导出 解决 项目开发 不能 提交 元素 提醒
分为三个模型分别为：瀑布模型、快速原型模型、螺旋模型
1、瀑布模型是线性模型的一种，在所 有模型中占有重要地位，是所 有其他模型的一个基础。
2、每一个阶段执行一次，按 线性顺序进行软件开发。
测试阶段处于软件实现后，必 须在代码完成后留出足够的时 间给测试活动，否则将导致测 试不充分，很多问题到项目后 期才暴露
开发的各个阶段比较清 晰。
强调早期计划及需求调 查。
适合需求稳定的产品开 发。
开发的各个阶段比较清晰。
强调早期计划及需求调查。
适合需求稳定的产品开发。
依赖于早期的需求调查，不 适应需求的变化。
单一流程不可逆。
风险往往延至后期才显露， 失去及早纠正的机会。
问题在项目后期才开始暴露。
前面未发现的错误会传递并扩散 到后面的阶段，可能导致项目失败。
沿用瀑布模型的线性思想，细化了各个阶段，在某些重要关注的阶段之间 掺入迭代的思想。
在开发真实系统之前，构造一个原型，在该原型的基础上，逐渐完成整个系 统的开发工作。
第一步是建造一个快速原型，实现用户与系统的交互，用户对原型进行评 价，进一步细化待开发软件的需求。通过逐步调整原型使其满足用户的要 求，开发人员可以确定用户的真正需求是什么。
第二步是在第一步的基础上开发出用户满意的软件产品。
克服瀑布模型的缺点，更好地
满足用户的需求并减少由于软
件需求不明确带来的项目开发
风险。适合预先不能确切定义
需求的软件系统的开发。
不适合大型系统的开发（适合 开发小型的、灵活性高的系 统）。前提要有一个展示性的 产品原型，因此在一定程度上 可能会限制开发人员的创新
螺旋模型螺旋模型将开发过程分为几个螺旋周期，每个螺旋周期大致和瀑布模型相 符合，螺旋模型沿着螺旋线旋转，即在坐标的4个象限上分别表示了4个方 面的活动，如图所示：
制定计划、风险分析、实施开发、客户评估
螺旋模型很大程度上是一种风
险驱动的方法体系，因为在每
个阶段之前及经常发生的循环
之前，都必须首先进行风险评
估。
采用螺旋模型需要具有相当丰
富的风险评估经验和专门知识，
在风险较大的项目开发中, 如
果未能够及时标识风险，势必
造成重大损失。过多的迭代次
数会增加开发成本，延迟提交
时间
测试模型也分为三种分别为：V模型、W模型、H模型
V模型：
• 需求分析
用户需求、业务需求、需求 规格说明书
• 概要设计
系统架构、模块划分、模块 与模块之间的接口。
• 详细设计
模块内部实现的逻辑和方法。
• 编码
实现上面的设计。
• 单元测试
检测代码的开发是否符合详 细设计的要求。
• 集成测试
检测此前测试过的各组成部 分是否能完好地结合到一起。
• 系统测试
检测已集成在一起的产品是 否符合系统规格说明书的要 求。
• 验收测试
检测产品是否符合最终用户 的需求。
V模型的优点
– 测试V模型即包含了底层测试又包含了高层测试；
• 底层测试：检验源代码质量的测试，如：单元测试；
• 高层测试：检验整个系统的需要，如：系统测试；
– V模型清楚地标识出了软件开发的阶段。– 它采用自顶向下逐步求精的方式把整个开发过程分成不同的阶段， 每个阶段的工作都很明确，因此便于控制开发过程。当所有的阶
段都完成之后，该软件的开发过程也随之结束。
– V模型一大缺点正是它自身的顺序性所导致的。到了测试阶段，程 序已经完成，错误已经产生，很多前期的错误一直到测试阶段才 发现，甚至无法发现，往往无从修改了。
– 同时实际的开发过程中，在需求阶段很难把用户的需求完全明确 下来，因此，当需求变更时将会导致阶段反复，而且都要重复需 求、设计、编码、测试等过程，返工量非常大，模型灵活性比较 低。
开发强调测试伴随着整个软 件开发周期，而且测试的对 象不仅仅是程序，需求和概 要设计同样要测试；
更早地接入测试，可以发现 开发初期的缺陷，那么可以 用更加低的成本进行缺陷修 复。
同样是分阶段的工作，便于 控制项目过程。
W模型的缺点：
依赖于软件开发和软件测试依 然保持一前一后的线性关系， 依然无法支持迭代、自发性和 需求等变更调整；
对于当前很多项目，在执行的 过程中根本不产生文档，那么 W模型基本无法适用；
使用起来技术复杂度很高，对 于需求和设计的测试要求很高， 实践起来困难
• 测试流程
– 测试准备：所有测试执行活动的准备；判断是否到测试就绪点；
– 测试就绪点：测试准入准则，即是否可以开始执行测试的条件；
– 测试执行：具体的执行测试的程序。
• 其他流程
– 具体开发中的流程，如：设计流程
开发的H模型揭示了软件测试除测 试执行外，还有很多工作；
软件测试完全独立，贯穿整个生 命周期，且与其他流程并发进行；
软件测试活动可以尽早准备、尽 早执行，具有很强的灵活性；
软件测试可以根据被测物的不同 而分层次、分阶段、分次序的执 行，同时也是可以被迭代的。
管理型要求高：由于模型很灵活，必 须要定义清晰的规则和管理制度，否 则测试过程将非常难以管理和控制；
技能要求高：H模型要求能够很好的定 义每个迭代的规模，不能太大也不能 太小；
测试就绪点分析困难：测试很多时候， 你并不知道测试准备到什么时候是合 适的，就绪点在哪里，就绪点的标准 是什么，这就对后续的测试执行的启 动带来很大困难；
对于整个项目组的人员要求非常高： 在很好的规范制度下，大家都能高效 的工作，否则容易混乱。例如：你分 了一个小的迭代，但是因为人员技能 不足，使得无法有效完成，那么整个 项目就会受到很大的干扰。
边界值就是对一个数两边的值进行测试，比如99的边界值100和98进行测试，若没有提示错误就是发生错误。
一个计算机提示的错误就是99到-99的内容，测试就是测试两个数的边界值，若提示错误表示没有问题，若没有则有错误。
因果图法是一种利用图解法分析输入的各种组合情况，从 而设计测试用例的方法，它适合于检查程序输入条件的各 种组合情况
• 特点：
• 考虑输入条件的相互制约及组合关系
• 考虑输出条件对输入条件的依赖关系
• 因果图法比较适合输入条件比较多的情况，测试所有的输入条件的排列组合。 所谓的原因就是输入，所谓的结果就是输出。
• 因果图的“因”——输入条件
• 因果图的“果”——输出结果
• 因果图法要注意考虑：
• 所有输入/输出条件的相互制约关系以及组合关系
• 输出结果对输入条件的依赖关系，也就是什么样的输入组合会产生怎样 的输出结果，即“因果关系”
• 通常在因果图中用Ci表示原因，用Ei表示结果，各结点表示 状态，可取值“0”或“1”。“0”表示某状态不出现， “1”表示某状态出现。
• 利用因果图导出测试用例需要经过以下几个步骤:
• ① 找出所有的原因，原因即输入条件或输入条件的等价类。
• ② 找出所有的结果，结果即输出条件。
• ③ 明确所有输入条件之间的制约关系以及组合关系。
• 哪些条件不能组合到一起，哪些条件可以组合到一起
• ④ 明确所有输出条件之间的制约关系以及组合关系。
• 哪些输出结果不能同时输出，哪些输出结果可以同时输出
• ⑤ 找出什么样的输入条件组合会产生哪种输出结果
• ⑥ 把因果图转换成判定表/决策表。
• ⑦ 为判定表/决策表中的每一列表示的情况设计测试用例。
看上面的黑线表示：输入50然后充值五十输出给我们的内容是提示充值成功和退卡。
把那些内容填入表格并用1表示填入。
• 通常在确定测试方法时，有以下几条参考原则：
• （1）拿到一个测试任务时，先关注它的主要功能和业务流程、业务逻辑是否正确实现， 考虑使用场景法。
• （2）需要输入数据的地方，考虑采用等价类划分法，包括输入条件和输出条件的等价 划分，将无限测试变成有限测试。
• （3）在任何情况下都必须采用边界值分析法。这种方法设计出的测试用例发现程序错 误的能力最强。
• （4）如果程序的功能说明中含有输入条件的组合情况，则一开始就应考虑选用因果图 和判定表法。
• 测试用例可以写的很简单，也可以写的很复杂。
• 最简单的测试用例是测试的纲要，仅仅指出要测试的内容。
• 测试用例写的过于简单，则可能失去了测试用例的意义。过于简 单的测试用例设计其实并没有进行“设计”，只是需要把测试的 功能模块记录下来而已，它的作用仅仅是在测试过程中作为一个 简单的测试计划，提醒测试人员测试的主要功能包括哪些而已。
• 最复杂的测试用例则会指定输入的每项数据，期待的结果即检验 方法，具体到界面元素的操作步骤，指定测试的方法和工具等。
• 测试用例写得过于复杂或详细，会带来两个问题：一个是效率 问题，另一个是维护成本问题。另外，测试用例设计的过于详 细，留给测试执行人员的思考空间就比较少，容易限制测试人 员的思维。
如图所示
报告注意：不能一次性报告几条错误，报的的名字要用别名
• 对软件问题的功能域分布进行分析，找出系统的薄弱环节。
• 要详细采集每个功能模块或系统构件的缺陷数据，并按功能、错误类型、严重程度等分类。
• 二八定理：80%的软件问题总是发生在大约20%的功能模块中。
• 对缺陷的注入阶段的分布进行分析，并与历史数据相比较。应按不同的开发阶 段详细采集缺陷的数据。
• 应对软件缺陷类型进行分析，以便针对各自的特点，先修复严重缺陷。
• 应动态采集每个测试周期中发现的缺陷数，并有效地控制缺陷的修复率。
• 应密切观察缺陷的状态，并及时跟踪其状态的变化，以检查测试和开发人员的 工作情况。
• TSVN通过右键菜单与Windows资源管理器集成，没有自己的窗口 界面
创建版本库是因为：可能有不同的人来操作同一个文件，有时我们需要查看这个操作 是谁完成的，或者想要回退到某一版本，则需要知道对应的版本是哪个。
• “删除”仅是对客户端的文件进行操作，并不改变服务器上的内 容，需要执行“提交”操作才会将删除操作上传到服务器
• 将“删除”操作“提交”到服务器后，仅是从服务器的最新版本 中删除了此文件或文件夹，在历史版本中仍可找回此文件或文件 夹
标签：快速 采集 导出 解决 项目开发 不能 提交 元素 提醒
原文地址：https://www.cnblogs.com/jy81/p/13073162.html
