软件的概念
1、软件是计算机系统中与硬件相互依存的另一部分，他是包括程序、数据及其相关文档的完整集合，例如操作系统是一个软件，包括相关的数据库文档都是其一部分
2、程序是按实现设计的功能和性能要求执行的指令序列
3、数据是使程序能正常操纵信息的数据结构
4、文档是与程序开发，维护和使用有关的图文材料
软件十大特性
1、形态特性：软件是无形的，不可见的逻辑实体
2、智能特性：软件是复杂的治理产品，可以帮助我们解决复杂的计算、分析、判断和决策问题
3、开发特性：程序开发不能自动化，但是有软件来辅助开发，使得开发行为充满了个人行为和个人因素
4、质量特性：软甲是由人编写的，由于开发特性存在，所以不存在完全没有缺陷的软件
5、生产特性：软件一旦设计开发出来，如果需要提供多个用户，他的复制十分简单，其成本非常低
6、管理特性：软件管理显得很重要，架构非常重要！
7、环境特性：软件的开发和运行离不开相关的软件和硬件（即计算机系统环境），不可摆脱的依赖性，比如java需要jdk
8、维护特性：软件投入使用之后需要维护，维护体现在升级、优化、功能更新等方面，甚至可以全盘重构。
9、废弃特性：与硬件不同，软件不可能被用坏的，是由于其他原因被废弃的，比如使用者不满意
10、应用特性：软件应用及其广泛
软件的分类
1、系统软件：服务性程序、语言程序、操作性同、DBMS
2、应用软件：为了特定的用途被开发的软件，比如浏览器
软件的生命周期
1、定义：软件的生命周期按照开发软件的规模和复杂程度，从时间上把软件开发的整个过程进行分截，形成相对独立的几个阶段。
每个阶段又分截成几个具体的任务，然后按规定顺序一次完成各阶段的任务并规定一套标准的文档作为各个阶段的开发成果，最后生产出高质量的软件。
2、软件的生命周期
问题定义 （出现想法，我要做一个什么功能的系统）
可行性研究
需求分析（深入具体的了解用户需求）
概要设计（设计出实现目标系统的几种可能方案，设计程序的体系结构、流程架构）
详细设计（从概要设计中选择一个最合适实现的方案，详细设计每个模块，确定是实现模块功能所需要的算法和数据结构）
编码和单元测试（对简单的方法进行测试）
综合测试（编写测试用例。经过此阶段后，软件会上线）
软件维护
软件开发模型
由于项目、需求的模型不同，所以在软件生命周期过程中选择的软件开发模型也会有所不同。在历史上，软件开发模型经历了“边做边改”、瀑布、原型、螺旋、敏捷式的开发模型
瀑布模型
计划
需求分析
设计
编码
测试
运行维护
特点：
1、软件开发的各项活动严格按照线性方式进行，不会循环
2、当前活动接受上一项活动的工作结果
3、当前活动的工作结果需要验证才能进入下一个阶段
缺点：
1、由于开发模型是线性的，增加了开发的风险（可能由于某一个阶段出错，就要推倒重来）
2、早期的错误可能要等到开发后期的阶段才能实现（错误维护的成本非常大）
原型模型
客户与开发公司紧密联系，开发周期长。开发会收到需求变更的影响。
特点：
1、实现客户与系统的交互，开发与客户实时交互（即可以设计一部分之后，客户不满意，需要实时调整系统）
2、进一步细化待开发软件需求（需求不断不断颗粒化，客户满意才进行开发）
3、开发人员可以确定客户的真正需求是什么
螺旋模型
制定计划
风险分析
实施工程（需求确认、软件需求、软件产品设计、设计确认与认证、详细设计、开发、测试）->即瀑布模型
客户评估
特点：
1、螺旋模型是将瀑布模型与快速原型模型结合起来
2、强调了其他模型所忽视的风险分析
3、每一次螺旋包括4个人步骤：制定计划、风险分析、实施工程、客户评估
缺点：
1、强调风险分析，但要求许多客户接收并详细这种分析，是不容易的
敏捷模型（BAT常用开发模型）
敏捷开发是一种以人为核心、迭代、循序渐进的开发方法
（将非常大的需求拆分成小需求，增长开发）
特点：
1、短周期开发
2、增量开发
3、由程序员和测试人员编写的自动化测试来监控开发进度
4、通过口头沟通、测试和源代码来交流系统的结构和意图（敏捷开发提倡抛弃文档，以人为本）
5、编写代码之前先写测试代码，也叫测试先行（先写测试代码进行模拟）
缺点：
1、团队的组件较难，人员素质要求高
2、对测试员要求完全掌握各种脚本语言编程，能执行单元测试、自动化测试
软件开发文档
需求分析文档
概要设计文档（需求分析的内容进行方案大体设计并查查看有无包含所有需求）
详细设计文档（包含所有方案、策略、架构体系、接口、数据库存储结构）
测试设计文档（跨部门联合测试等）
测试用例（进行测试的依据，针对系统功能的规范条文）
测试报告（测试完成之后，通过了多少，未通过多少等等）
阿里系开发模型的变迁史
开发模型是在开发过程中不断改变的
开发模型的变迁
最早期：边做边改 （不稳定，测试很难插手，由于边做边改项目没有完整的体系）
稳定期：瀑布式（二期是架构变化历程，比如oralce->mysql、redis等，解决了边做边改的问题，比如解决了没有完善版本的发布，但是新增的需求不能很快地融入到项目中，只能在下一期开发，每次都像一个新项目）
发展期：敏捷（需求更有灵活性，周期可以不断变更，快速迭代）
创新期：DEVOPS（更加注重自动化使用；更加强的自动化工具的使用，小型需求保证2周左右上线，开发周期压缩在1周，回归测试+项目发布保证在1小时内（注重自动化工具跑测试用例） - > 211）
BAT测试员项目的一生
项目阶段
编程阶段：单元（白盒）—— 测试参与
编程完成 - 开发联调（集成测试） - 开发为主，测试为辅（日志校验等）
提测 - 冒烟测试（集中在项目里面的核心业务（20%的功能点），自动化为主，手工为辅） - 测试执行
测试阶段 - 系统测试 （黑盒功能测试为主，自动化/接口测试为辅，根据项目进行性能、安全测试）系统单测、系统联测（系统业务全流程测试）
验收阶段 - 验收测试 - 测试配合用户或需求
软件测试（Software Testing）
软件测试经典定义：在规定的条件下对程序进行操作已发现程序的错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。（附带才是发现错误，目的是说明软件是否合格，是否满足上线要求）
软件测试标准定义：软件测试是使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别
测试用例包括预期结果和实际结果
软件测试目的：在于发现问题，检查系统是否满足需求
软件测试和方法
单元测试一般融合在开发中，开发自己完成
冒烟测试简单验证步骤的集合，检测能不能用
集成测试模块与模块之间的测试
系统测试通过测试用例的执行来完成
验收测试
静态分析：直接看代码，不去运行
动态分析：执行代码
生命周期各测试方法对比
集成测试：开发人员之间的模块联调测试，最后由测试人员看是否通过
冒烟测试用例：用户使用最多的流程
验收测试：是由用户、需求方来做的，依赖于用户真实的需求文档
软件测试常用术语
C/S：client-server 这种软件是基于局域网或互联网的，需要一台服务器来安装服务器端软件，每台客户端软件都需要安装客户端软件。比如我们经常用的QQ和各种网络游戏就属于C/S结构的软件
B/S：browser-server 他与C/S结构软件的区别就在于，不需要安装客户端（client），只需要有浏览器，就可以直接使用，与C/S结构软件相比，便于升级和维护，是测试的重点
APP：应用程序客户端
缺陷（Bug/Defect）：软件的bug是指软件（包括程序和文档）不符合用户需求的问题
测试环境：软件、硬件、网络的总和
测试用例(（test case）：在测试执行之前设计的一套详细的测试方案，包括测试环境、测试步骤、测试数据和预期结果。
测试用例=输入+输出+测试环境
其中，输入包括测试数据和操作步骤，输出指期望结果，测试环境指系统环境设置
冒烟测试（smoke test）：在对一个新版本进行系统大规模地测试之前，先验证一下软件的基本功能是否实现，是否具备可测性
a测试：验收测试的一种，指的是由用户、测试人员、开发人员等共通过参与的内部测试
beta测试：验收测试的一种，指的是内测后的公测，即完全交给最终用户测试
软件测试常见模型
V模型
V模型是瀑布模型的一种改进，瀑布模型将软件生命周期划分为计划、分析、设计、编码、测试和维护六个阶段，由于早期的错误可能要等到开发后期的测试阶段才能发现，所以可能带来严重的后果。
V模型就是在这点改进了瀑布模型，在软件开发的生存期，开发活动和测试活动几乎同时开始，这两个并行的过程就会极大的减少bug和error出现的几率。
单元测试依据详细设计；集成测试依据概要设计；系统测试依据需求分析；验收测试依据用户需求；
W模型
一些高性能高风险的模型、互联网软件，或一个系统难以被具体模块的时候，就比较难做成V模式所需的各种构件，需要更强调迭代的开发模型或者敏捷开发模型
W模型从V模型演化过来，实际上开发时V，测试是并行的V；相对于V模型，W模型增加了软件各开发阶段中应同步进行的验证和确认活动，W明确表示出了测试与开发的并行关系。测试与开发是同步进行的，有利于尽早地全面的发现问题。
H模型
真正的测试级别之间不存在严格的次序关系，个极端间可以反复触发、迭代、增量
为了解决V模型和W模型存在的问题，有专家提出了H模型。他将测试活动完全独立出来，形成一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。——只要测试条件成熟，即可进行测试。
X模型
将一个程序分成无数各程序片段，最后集成成一个可以执行的程序，然后在执行测试程序。（多跟并生 ）
用的最多是W H模型结合的模型，测试的周期，测试的方法，进度以H为指导，测试的内容以W为指导，X模型是最终测试或熟练测试的一种模板，来进行分块化，增量化的测试模式。
软件测试的覆盖率
覆盖率是用来度量测试完整性的一个手段，同时也是测试技术有效性的一个度量
覆盖率=（至少被执行一次的item数）/item的总数
特点：
1、通过覆盖率数据，可以检测我们的测试是否充分
2、分析出测试的弱点在哪方面
3、指导我们设计能够增加覆盖率的测试用例，有效提高测试质量，但是测试用例设计不能一味追球覆盖率，因为测试成本随覆盖率的增加而增加
测试覆盖率对于黑盒测试来说，主要指两个方面：
需求覆盖和用例覆盖
需求覆盖：
1、定义：他表示在测试中，有哪些函数被测试到了，其被测试到的频率有多大，这些函数在系统所有函数中占的比例有多大通过设计一定的测试用例，要求每个需求点都被测试到。
2、需求覆盖=（被验证到的需求数量）/（总的需求数）【依据需求文档来计算】
用例覆盖：
1.定义：主要体现在我们每轮测试验证通过的用例数在总用例中的比重
2.计算公式：用例覆盖=（验证通过的用例数量）/总的用例总数
验证通过的用例数量包括自动化和手工测试的用例数量
测试覆盖率的运用（主要是三种场景）
1、简单的测试覆盖率（基于用例，考察测试人员）：本次测试执行的用例数 / 所有用例数
上述覆盖率统级建立在认为总用例数编写全面，一般对于大型系统测试要求覆盖率100%，对于小型迭代可以不达到100%
覆盖率的审核：抽样验收
2、基于产品的测试覆盖率（基于需求）：已测试需求点 / 设计所有需求数
以产品、需求维度统计，无论大型项目或是小需求迭代都要求覆盖率达到100%，结果提交给产品方，告知项目风险等
覆盖率的审核：抽样验收
3、基于白盒的（单元）测试覆盖率：大多工具判断语句覆盖，即单元测试代码覆盖代码行 / 总代码行
更多考察研发人员；更多时候要求覆盖率达到 80%+
缺陷：覆盖率数据只能代表测试过那些代码，不能代表是否测试好这些代码（即不知道用 例是否通过）；容易遗漏逻辑、判断等场景
4、基于自动化的测试覆盖率：自动化覆盖的测试场景
（测试用例）/ （所有测试场景（用例））
二八原则，比如用户80%的时间在使用20%的功能，20%的功能就可以支撑起用户最关键的业务场景，自动化测试的用例选择更着重这20%的核心功能
用途：自动化测试更着重于回归验证，没必要追球过高的覆盖率，而要考虑用例设计
测试覆盖率的最终意义：应用最多的地方在测试停止标准
单纯讨论测试覆盖率，在瀑布式开发模型中并不重要（因为瀑布开发模型规定100%），但在螺旋式、敏捷开发模型中，由于不断迭代累加，很难确定哪些模块在开发过程中没有给予足够的测试
在短迭代、DevOps中，更强调用白盒单元测试覆盖率来评估不断增加的代码数量
测试团队组织结构
金字塔管理模式
一般会有一个单独的测试部门，每层都是一对多关系
矩阵式管理模式
测试人员以项目为主，再在自己专业领域增加专业技术
软件测试人员
知识体系
测试用例设计方法：黑盒
测试工具使用：自动化测试
软件测试人员具备的素质
软件测试的原则
1、所有的测试都应追溯到用户需求
2、今早启动测试工作
3、Pareto法则应用软件测试（帕累托）
4、穷尽测试是不可能的
由于很少有机会对一个一个用软件进行所有可能的测试，对大多软件开发项目来说，利用风险分析是适当的。这需要判断集能、常识、感觉和经验。
5、杀虫剂怪事
软件测试越多，其对测试的免疫力越强的现象。开发知道测试的思维，会有自动避开。
6、前进两步，后退一步
一个bug可能会引起其他bug
7、三心二意
细心、信心、耐心、
团队合作以是、缺陷预防意识
软件工程标准
国内通用的软件工程标准：ISO9000 以及 CMM
ISO9000基本思想：
1、控制的思想，即对产品形成的全过程 —— 从采购原材料、加工制造到最终产品的销售、售后服务进行控制（针对整个产品链）
2、预防的思想，通过对产品形成的全过程进行控制以及建立并有效运行自我完善机制达到预防不合格，从根本上减少或消除不合格产品（对整体过程达到自我完善机制）
ISO9000的过程管控 ↑
CMM
CMM准确来说不是标准，只是对过程能力的评估结果
CMM对软件企业的评估从初始级开始，共分为5级，一级一级的改进，一级一级的向上提高。等级的上升过程是一个“动态渐进”的过程。
CMM是专为软件开发组织设计，侧重于软件开发和改进过程，在产品的设计和开发的细节作了较多要求。
软件测试规范
由 ISO9000 和 CMM 总结得出软件测试规范，由6个相互关联的过程组成的
一般会从下面几个方面来规范过程，并在每个子过程明确角色、职责、活动描述以及所需资料