目录
关于个人笔记总结归纳
软件概述
相对于硬件而言，软件是一系列按照特定顺序组织的计算机数据和指令的集合
1.软件生命周期：从“出生”到“消亡”的过程。
问题定义-->需求分析-->软件设计-->软件开发-->软件测试-->软件维护-->淘汰
问题定义：由软件开发方与需求方共同讨论（确定软件开发目标及可行性）
需求分析：对软件需求进行更深入的分析，划分软件出软件需要实现的功能模块，并制成文档。（根据需求的变化随时进行需求分析）
软件设计：对整个软件系统进行设计（如系统框架设计、数据库设计等）
软件开发：选择一种编程语言进行开发。在开发过程中，必须制订统一、符合标准的程序编写规范，保证程序的可读性、易维护性以及可移植性。
软件测试：软件开发完成后对软件进行测试，以查找软件设计与软件开发中存在的问题并加以修正（软件测试的过程包括单元测试、集成测试、系统测试）（测试方法以黑盒测试、白盒测试或两者结合的形式进行）在此过程中，为减少测试的随意性，需要制订详细的测试计划并严格遵守，完成之后对测试结果进行分析并对测试结果以文档形式汇总。
软件维护：纠错性维护和改进性维护（是软件生命周期中持续时间最长的阶段）
2、软件开发模型（规定软件开发应遵循的步骤）
瀑布模型：遵循从上到下一次性完成整个软件产品的开发模式（软件定义--开发--维护）
过程：计划-->需求分析-->软件设计-->编码-->测试-->运行维护
优点：利于大型软件开发人员的组织管理及工具的使用与研究，可以提高开发的效率
缺点：严格按照线性方式进行，无法适应用户需求的变更，用户只能等到最后才能看到开发成果，增加了开发风险。不适合现代软件开发，已经逐渐废弃（现代软件开发各阶段之间的关系大部分不会是线性）
快速原型模型
优点：克服需求不明确带来的风险，适用于不能预先确定需求的软件项目。快速构建软件模型。
缺点：不利于开发人员对产品进行扩展
迭代模型（增量模型/演化模型）
优点：适应客户需求的变更，可逐个组件地交付产品，客户可以经常看到产品，降低软件开发的成本与风险。
缺点：会有集成失败的风险，逐个组件地开发修改，很容易退化为“边做边改”的开发形式，失去对软件开发过程的整体控制。
螺旋模型（融合瀑布模型、快速原型模型）最大特点是引入了其他模型所忽略的风险分析
4个象限：制订计划、风险分析、实施工程、客户评估
制订计划：确定软件目标，制订实施方案，并列出项目开发的限制条件
风险分析：评价所制订的实施方案，识别风险并消除风险
实施工程：开发产品并进行验证
客户评估：客户对产品进行审核评估，提出修正建议，制订下一步计划。
优点：有助于将产品质量作为特殊目标融入产品开发中，以小分段构建大型软件，使成本计算变得简单，而客户始终参与每个阶段的开发，保证了项目不偏离正确方向和项目的可控制性。
敏捷模型（开发未动，测试先行）2种开发方式：Scrum与Kanban
原则：
（1）个体和交互重于过程和工具
（2）可用软件重于完备文档
（3）客户协作重于合同谈判
（4）响应变化重于遵循计划
优点：及时响应客户需求变更，不断适应新的趋势
缺点：一定程度的混乱(缺乏文档资料，软件之前版本的可重现性、可回溯性较低，对于较大的项目，人员越多面对面的有效沟通越困难)
因此敏捷模型比较适用于小型项目开发，不太适用于大型项目
软件质量概述:指软件产品满足基本需求及隐式需求的程度
软件质量的三个层次
1、满足需求规定：软件产品符合开发者明确定义的目标，并且能可靠运行
2、满足用户需求：软件产品的需求是由用户产生，软件的最终目的是满足用户需求，解决用户的实际问题
3、满足用户的隐式需求：除了满足用户的显示需求，软件产品如果满足用户隐式需求，即潜在的可能需要在将来的开发的功能，将会极大地提升用户满意度，这就意味着软件质量更高
ISO/IEC 9126：1991是最通用的一个评价软件质量的国际标准。由6个特性和27给子特性组成
影响软件质量的因素
1、需求模糊
2、软件开发缺乏规范性文件指导
3、软件开发人员问题
4、缺乏软件质量控制管理
软件缺陷是通常所说的bug，它是指软件中（包括程序和文档）存在的影响软件正常运行的问题。
IEEE 729-1983标准对软件缺陷有一个标准的定义：
从产品内部看，缺陷是产品开发或维护过程中存在的错误、毛病等各种问题；
从产品外部看，缺陷是系统运行过程中某种功能的失效或违背
软件缺陷的产生是由软件产品的特点和开发过程决定的，比如需求不清晰、需求频繁变更、开发人员水平有限等。
软件缺陷产生的原因
1、需求不明确 2、软件结构复杂 3、编码问题 4、项目期限短 5、使用新技术
软件缺陷分类
软件缺陷处理流程
具体：
1、提交：测试人员发现缺陷之后，将缺陷提交给测试组长
2、分配：测试组长接受到测试人员提交的缺陷之后，将其移交给开发人员
3、确认：开发人员接收到移交的缺陷之后，会与团队甚至测试人员一起商议，确定该缺陷是否是一个缺陷
4、拒绝/延期：如果经过商议之后，缺陷不是应该真正的缺陷则拒绝处理，关闭缺陷；如果经过商议之后，确定其是一个真正的缺陷，则可以根据缺陷的严重程度或优先级等选择立即处理或延期处理。
5、处理：开发人员修改缺陷
6、复测：开发人员修改好缺陷后，测试人员重新进行（复测），检查缺陷是否确实已经修改。如果未被正确修改，则重新提交缺陷。
7、关闭：测试人员重新测试之后，如果缺陷已经被正确修改，则将缺陷关闭，整个缺陷处理完成
编写缺陷报告注意点：
1、每个缺陷都有一个唯一的编号，这是缺陷的标识
2、缺陷要有重现步骤
3、一个缺陷生成一份报告
4、缺陷报告要整洁、完整
常见的软件缺陷管理工具：Bugzilla 禅道 Jira
软件测试分类
按测试阶段分类
1、单元测试：是软件开发的第一步测试，目的是为了验证软件单元是否符合软件需求与设计。大多是开发人员进行的自测
2、冒烟测试：最初由电路板测试得来，在软件测试中，冒烟测试是指软件构建版本后，对系统的基本功能进行简单的测试，这种测试重点验证的是程序的主要功能，而不会对具体功能进行深入测试（对新构建版本进行的最基本测试）
3、集成测试：是在冒烟测试之后进行的测试，它是将已经测试过的软件单元组合在一起测试它们之间的接口，用于验证软件是否满足设计需求
4、系统测试：是将经过测试的软件在实际环境中运行，并与其他系统的成分（如数据库、硬件和操作人员等）组合在一起进行的测试
5、验收测试：主要是对软件产品说明进行验证，逐行逐字地按照说明书的描述对软件产品进行测试，确保其符合客户的各项需求。
按照测试技术分类
1、黑盒测试：把软件（程序）当作一个有输入与输出的黑匣子，它把程序当作一个输入域到输出域的映射，只要输入的数据能输出预期的结果即可，不必关心程序内部是怎样实现的。
2、白盒测试（透明盒测试）：指测试人员了解软件程序的逻辑结构、路径与运行过程，在测试时，按照程序的执行路径得出结果。
按照软件质量特性分类
1、功能测试：指测试的功能是否满足客户的需求，包括准确性，易用性、适合性、互操作性等。
2、性能测试：指测试软件的性能是否满足客户的需求，性能测试包括负载测试、压力测试、兼容性测试、可移植性测试和健壮性测试等。
按照自动化程度分类
1、手工测试：比较耗时费力
2、自动化测试：借助脚本、自动化测试工具等完成相应的测试工作，也需要人工的参与
按照测试类型分类
1、界面类测试
2、安全性测试
3、文档测试
其他分类
1、a测试：对软件最初版本进行测试
2、b测试：对上线之后的软件版本进行测试
3、回归测试：重新测试的过程（软件开发的各阶段都会进行多次回归测试）
4、随机测试：随机抽查，是根据测试用例说明书执行测试用例的重要补充手段，是保证测试覆盖完整性的有效方法和过程
软件测试与软件开发的关系
常见的软件测试模型
1、V模型（主要反映测试活动分析与设计之间的关系，左边是自上而下、逐步细化的开发过程，右边是自下而上、逐步集成的的过程，应用瀑布模型思想将复杂的测试工作分成了目标明确的小阶段来完成，具有阶段性、顺序性和依赖性。
缺点：具有一定的局限性，只有在编码之后才能开始测试。不能发现需求分析等早期的错误，为后期的系统测试、验收测试埋下隐患）
W模型（双V模型：软件开发是一个V模型，而软件测试是与开发同步进行的另一个V模型）
优点：测试范围不仅包括程序，还包括需求分析、软件设计等前期工作，这样有利于尽早地全面发现问题
缺点：具有局限性，它将软件开发过程分成需求、设计、编码、集成等一系列的串行活动，无法支持迭代、自发性等需要变更调整的项目
H模型（测试流程和其他的工作流程是并发执行）
优点：在H模型中，测试级别不存在严格的次序关系，软件生命各阶段的测试工作可以反复触发、迭代，即不同的测试可以反复迭代的进行
X模型（将程序分成多个片段反复迭代测试）
软件测试的原则
1、测试应基于客户需求
2、测试应尽早进行
3、穷尽测试是不可能的
4、遵循GoodEnough原则
5、测试缺陷要符合“二八”定理
6、避免缺陷免疫
软件测试流程
分析测试需求-->制订测试计划（1、确定测试范围 2、制订测试策略 3、安排测试资源 4、安排测试进度 5、预估测试风险）-->设计测试用例-->执行测试-->编写测试报告
扫一扫
2094
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
