本文详细介绍了软件生命周期中的各种开发模型，如瀑布模型、敏捷模型（Scrum和Kanban）、螺旋模型、迭代模型和快速原型模型。同时，讨论了软件测试的重要模型，包括V模型、W模型、H模型和X模型。此外，还涵盖了软件质量的六大特性、软件缺陷管理、测试方法（黑盒、白盒、灰盒测试）以及等价类划分法和边界值分析法等测试策略。内容全面，旨在帮助读者理解软件开发和测试的全过程。
目录
常见的软件生命周期
软件开发模型
瀑布模型
瀑布模型是将软件生存周期的各项活动规定为按固定顺序而连接的若干阶段工作，包括问题定义及规划、需求分析、软件设计、程序编码、软件测试和运行维护等六个基本活动。每个阶段规定的文档需进行评审，评审完后才可以进入下一个阶段。
瀑布模型要求每一个阶段必须有结果产出，这就势必增加了文档的数量，使软件开发的工作量变大。
迅捷模型（目前比较流行的模型）
是一种以用户需求进化为核心（强调沟通、弱化文档）、迭代、循序渐进的开发方法。把一个大项目分为多个相互联系，但也可以独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态，注重人与人的沟通。
敏捷模型开发方式（两种）：scrum和kanban
scrum
把整个项目划分成细小的可交付成果的子项目，分别由不同的小组完成，并对各小组的工作划分优先级，估算每个小组的工作量。
kanban
kanban（看板）源于丰田的生产模式，它将工作细分成任务，将工作流程显示在「看板卡」上，每个人都能及时了解自己的工作任务及工作进度。这种生产理念后来被引入到软件开发中，利用可视化软件将开发的软件项目细分成小任务，并分配给团队成员，每个成员都可以在「看板」上了解自己的工作任务及整个团队的工作进度。
螺旋模型
该模型融合了瀑布模型、快速原型模型，结合两者优点，它最大的特点是引入了其他模型所忽略的风险分析，每个阶段开始都有风险分析。
迭代模型（增量模型/演化模型）
将项目分成多个组件，多个组件可以同时进行开发，测试后迭代。第一个组件往往是核心，迭代模型可以很好地适应客户需求变更降低了软件开发的成本与风险。但是迭代模型需要将开发完成的组件集成到软件体系结构中，这样会有集成失败的风险。
快速原型模型
先快速构建原型，实现基本功能，再和客户讨论详细开发需求
软件测试模型
V模型
通过开发和测试同时进行的方式来缩短开发周期，提高开发效率（一 一对应关系）
局限性：把测试作为编码之后的最后一个活动，需求分析等前期产生的错误直到后期的验收测试才能发现。
w模型
W模型是V模型的发展，强调的是测试伴随着整个软件开发周期，
软件开发和测试保持一种线性的前后关系，需要有严格的指令表示上一阶段完全结束，才可以正式开始下一个阶段。
W模型和V模型都把软件的开发视为需求、设计、编码等一系列串行的活动，无法支持迭代、自发性以及变更调整。
H模型（H模型融入了探索模型）
H模型中, 软件测试过程活动完全独立,贯穿于整个产品的周期,与其他流程并发地进行，某个测试点准备就绪时,就可以从测试准备阶段进行到测试执行阶段。软件测试可以尽早的进行,并且可以根据被测物的不同而分层次进行。
X模型
X模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试，此后将进行频繁的交接，通过集成最终成为可执行的程序，然后再对这些可执行程序进行测试。
软件缺陷严重程度
严重等级
一般分为5个等级:
系统崩溃，严重，一般，次要，建议
按优先级分:
修正优先级：高，中，低
软件产生缺陷原因
技术问题
软件本身
团队工作
缺陷可存在阶段
软件缺陷可存在于软件需求分析、架构设计、编程开发等各个阶段。
软件质量模型（6大特性，27个子特性）
.ISO/IEC 9126:1991标准
软件测试的分类
按开发阶段： 单元测试、集成测试、系统测试、确认测试（冒烟测试）、验证测试
按测试技术： 黑盒测试、白盒测试、灰盒测试
按代码运行： 静态测试、动态测试
按软件特性： 功能测试、性能测试、安全性测试
其他测试类型： 回归测试、冒烟测试、随机测试、猴子测试
按测试运行主体： 手工测试（功能测试）、自动化测试（利用工具软件，或者编写代码的方式，测试被测的软件系统）
黑盒测试
通过软件的外部表现来发现其缺陷和错误。黑盒测试法是把测试对象看成一个黑盒子，完全不考虑程序内部结构和处理结果。黑盒测试是在程序界面处进行测试，它只是检查程序是否按照需求规格说明书的规定正常实现。只考虑输入的数据输出时是否满足预期结果。
白盒测试
通过对程序内部结构的分析、检测来寻找问题。白盒测试可以把程序看成是装在一个透明的盒子里，检查是否所有的结构及路径都是正确的，检查软件内部动作是否按照设计说明的规定正常进行。白盒测试又称结构测试。（对程序的逻辑结构、路径与运行过程进行的测试）
灰盒测试
介于白盒测试与黑盒测试之间的测试。灰盒测试关注输出对于输入的正确性；同时也关注内部表现，但这种关注不像白盒测试那样详细、完整，只是通过一些表征型的现象、事件、标志来判断内部的运行状态。
静态测试
静态测试是指不实际运行被测对象，而只是静态地检查程序代码、界面或文档中可能存在错误地过程
代码测试：主要测试代码是否符合相应的标准和规范
界面测试：主要测试软件的实际界面与需求中的说明是否相符
文档测试：主要测试用户手册和需求说明是否真正符合用户的实际需求
动态测试
动态测试是指实际运行被测对象，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程。
所以我们判断一个测试属于动态测试还是静态测试唯一的标准就是看是否运行程序。
单元测试
单元测试是开发自己编写的针对代码某个功能模块验证其行为的测试单元模块；单元测试贯穿在开发的整个过程，并伴随着新功能模块的产生而进行；单元测试并不会花费更多的时间，与之相反，在提高代码效率、减少bug数量、有序开展开发工作上，单元测试发挥着很大的作用。，每写一个函数就添加一个简单的测试来判断函数功能和所期望的是否一致；在未对刚写的函数做出确认之前，开发者并不会接着写新代码
功能测试
是黑盒测试的一方面，它检查实际软件的功能是否符合用户需求
逻辑功能测试
界面测试
易用性测试
安装/卸载测试
兼容性测试
性能测试
功能的另一个指标，主要关注软件中的某一功能在指定的时间、空间条件下，是否使用正常,软件的性能包括很多方面，主要有 时间性能 和 空间性能 两种
安全性测试
验证安装在系统内的保护机制能否在实际应用中对系统进行保护，使之不被菲菲入侵，不受各种因素的干扰。
回归测试
是指对软件的新版本测试时，重复执行之前某一个重要版本的所有测试用例。
目的：
1）验证之前版本产生的所有缺陷已全部被修复。
2）确认修复这些缺陷没有引发新的缺陷。
冒烟测试
是指在对一个新版本进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。也叫可测性测试。
随机测试
是指测试人员基于经验和直觉的测试，发现一些边缘性的错误。
猴子测试
把自己当成不懂产品的笨蛋或者小动物，随便乱点，没有任何的主观意识和想法参与进来，让一些意想不到的操作造成错误的结果。
处理软件缺陷的流程
分别是制定测试计划、测试需求分析、测试用例设计与编写以及测试用例评审。
软件测试基本流程
分析测试需求→制定测试计划→设计测试用例→执行测试→编写测试报告。
等价类划分法
等价类划分法是把所有可能的输入数据，即程序的输入划分成若干部分（子集），然后从每一个子集中选取少量具有代表性的数据作为测试用例。这些子集称为等价类。
等价类的划分类型
等价类的划分有2种不同的情况
-有效等价类
-无效等价类
有效等价类
-对需求规格说明而言，有意义，合理的输入数据所组成的集合。
-校验程序是否实现了需求规格说明预先规定的功能和性能。
无效等价类
-对需求规格说明而言，无意义、不合理的输入数据组成的集合
-检查被测对象的功能和性能的实现是否有不符合需求规格说明要求的地方
等价类测试用例设计
针对是否对无效数据进行测试，可以将等价类测试分为标准等价测试类和健壮等价类测试
1.标准等价类测试--不考虑无效数据值，测试用例使用每个等价类中的一个值。
2.健壮等价类测试--主要的出发点是考虑了无效等价类，对有效输入，测试用例从每个有效等价类中取一个值；对无效输入，一个测试用例有一个“无效值”，其他均值有效值”。
等价类划分法设计测试用例的步骤
1、确定等价类
2、建立等价类表，列出所有划分出的等价类
3、从划分的等价类中按以下原则设计测试用例：
4、为每一个等价类规定一个唯一的编号
5、设计一个新的测试用例，使其尽可能多的覆盖未被覆盖的有效等价类，重复这一步。
6、设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步。
边界值划分法
大量的错误常常发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。如果输入条件确定了取值范围，则在取边界值时一般取5个或7个，既：
5：最大值，最小值，中间值，略大于最小值，略小于最大值。
测试用例个数：4n+1
7：最大值，最小值，中间值，略大于最小值，略小于最大值，略大于最大值，略小于最小值。
测试用例个数：6n+1（考虑健壮性）
----边界值划分法只能作为等价类的补充测试
因果图和决策表法
因果图
等价类划分法和边界值分析法没有考虑输入之间的关系，如组合，约束等，所以需要用一种方法来描述多个输入组合之间的约束关系：因果图。
因果图考虑输入与输入，输入与输出之间的相互制约的关系和各种组合情况。例如：软件需要输入地址：具体到市区：海南-à海口
在输入第二个时需要受到第一个输入的制约。
因果图使用使用一些简单的逻辑符号和直线将程序连接起来，一般原因用Ci表示，结果用ei表示，ci和ei可以取[0]或[1] 0表示状态不出现，1表示状态出现。
Ci和ei的关系类型
恒等关系，与（^），非（~），或（v）
- 恒等关系：ci和ei输入输出保持一致，一个输入一个输出，ci为1时，ei为1.
- 非：一个输入一个输出，ci和ei保持相反—ci为1，ei 则为0
3．或：c1,c2,c3有一个是1，则e1为1
4.与：c1,c2,c3有一个是0，输出都是0，都是1输出才是1
约束的类别（输入与输入的关系）
约束的类别可分为 4 种：E（Exclusive，异）、I（at least one，或）、O（one and only one，唯一）、R（Requires，要求）
（1）E（异）： a 和 b 中最多只能有一个为 1，即 a 和 b 不能同时为 1。
（2）I（或）： a 、 b 和 c 中至少有一个必须是 1，即 a、b、c 不能同时为 0。
（3）O（唯一）： a 和 b 有且仅有一个为 1。（4）R（要求）： a 和 b 必须保持一致，即 a 为 1 时， b 也必须为 1； a 为 0 时， b 也必须为 0。
输出条件的约束：
Mask强制
a----M--àb
a为1，b为0
决策表法
如果输入较多，因果图会比较混乱，所以在测试时一般用决策表法代替因果图。决策表是由因果图演化而来
决策表也称为判定表，其实质就是一种逻辑表。在程序设计发展初期，判定表就已经被当作程序开发的辅助工具，帮助开发人员整理开发模式和流程，因为它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确。利用决策表可以设计出完整的测试用例集合。
决策表法的组成
（1）条件桩（问题条件）：列出问题的所有条件，除了某些问题对条件的先后次序有要求之外，通常决策表中所列条件的先后次序都无关紧要。
（2）条件项（采取的操作）：条件项就是条件桩的所有可能取值。
（3）动作桩（结果）：动作桩就是问题可能采取的操作，这些操作一般没有先后次序之分。
（4）动作项（采取的动作）：指出在条件项的各组取值情况下应采取的动作。
条目合并
合并：将无关条目去除
规则数：2的n次方（n为条件桩个数）
要考虑条件桩是否可共存，不可共存n-1
决策表步骤：
1）列出所有条件桩和动作桩
2）确定规则个数（2^n）
3)填入条件项
4）填入动作项—得到优化决策表
5）简化合并。
1183
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
