软件的信息
软件的概念
是计算机系统中与硬件相互依存的另一部分，它是包括程序，数据以及相关文档的完整集合。
程序：
按实现设计的功能和性能要求执行的指令序列。
数据：
是程序能正常操纵信息的数据结构。
文档：
与程序开发，维护和使用有关的图文材料。
3.1十大特性
形态特性：
软件是无形的、不可见得逻辑实体。度量常规产品的几何尺寸、物理性质和化学成分对它却是毫无意义的。
智能特性：
软件是复杂的智力产品，它的开发凝聚了人们的大量脑力劳动，它本身也体现了只是知识实践经验和人类的智慧，具有一定的智能。它可以帮助我们解决复杂的计算、分析、判断和决策问题。
开发特性：
尽管已经有了一些工具（也是软件）来辅助软件开发工作，但到为止位置尚未实现自动化。软件开发中仍然包含了相当份量的个体劳动，使得这一大规模知识型工作充满了个人行为和个人因素。
质量特性：
软件是由人编写的，由于其开发特性存在，所以不存在完全没有缺陷的软件。
生产特性：
与硬件或传统的制造业产品的生产完全不同，软件一旦设计开发出来，如果需要提供多个用户，它的复制十分简单，其成本也极为有限。
管理特性：
由于上面的特性存在，所以软件过程中的管理显得更为重要，相比传统行业，也更为独特。
环境特性：
软件的开发和运行都离不开相关的计算机系统环境，包括支持它的开发和运行的相关硬件和软件。软件对于计算机系统的环境有着不可摆脱的依赖性。
维护特性：
软件投入使用以后需要进行维护，但这种维护与传统产业产品的维护概念有着很大的差别，维护体现在升级、优化、功能更新等方面。甚至可以全盘重构。
废弃特性：
与硬件不同，软件并不是由于被“用坏”而被废弃的。
应用特性：
软件的应用极为广泛，如今它已渗入国民经济和国防的各个领域，现先已成为信息产业、先进制造业和现代服务的核心，占据了无可取代的地位。
3.2软件的分类：
系统软件：
负责管理计算机系统中各种独立的硬件，使得它们可以协调工作。
应用软件：
为了某种特定的用途而被开发的软件。它可以是一个特定的程序，比如一个图像浏览器。也可以是一组功能联系紧密，可以相互协作的程序的集合。
3.3软件的生命周期
基本概念：
软件的生命周期，又称为软件的生存周期。它是按开发软件的规模和复杂程度，从时间上把软件开发的整个过程（从计划开发到软件报废为止的整个历史阶段）进行分解，形成相对独立的几个阶段。
每个阶段有分解成几个具体的任务，然后按规定顺序一次完成个阶段的任务并规定一套标准的文档作为各个阶段的开发成果，最后生产出高质量的软件。
软件的一生：
问题定义：确定好要解决的问题是什么（what）
可行性研究：确定该问题是否存在一个可以解决的方案
需求分析：深入具体的了解用户的需求
概要设计：设计出实现目标系统的几种可能方案，设计程序的体系结构
详细设计：详细的设计每个模块，确定实现模块功能所需的算法和数据结构
3.5软件开发模型
由于项目、需求的模式不同，所以在软件生命周期过程中选择的软件开发模型也会有所不同，在历史上，软件开发模型经历了“边做边改”、瀑布、原型、螺旋、敏捷等模式的变更。
瀑布模型：
计划→需求分析→设计→编码→测试→运行维护
特点：
1、软件开发的各项活动严格按照线性方式进行
2、当前活动接受上一项活动的工作结果
3、当前活动的工作结果需要进行验证
缺点：
1、由于开发模型是线性的，增加了开发的风险
2、早起的错误可能要等到开发后期的阶段才能发现
原型模式
客户与开发公司紧密联系，开发周期长。开发会受到需求变更的影响。
特点：
1、实现客户与系统的交互
2、进一步细化待开发软件需求
3、开发人员可以确定客户的真正需求是什么
螺旋模型
制定计划→风险分析→实施工程（需求确定、软件需求、软件产品设计、设计确认与认证、详细设计、开发、测试）→客户评估。
特点：
1、螺旋模型是将瀑布模型与快速原型模型结合起来
2、强调了其他模型所忽视的风险分析
3、每一次螺旋包括4个步骤：制定计划、风险分析、实施工程、客户评价
缺点：
强调风险分析，但要求许多客户接受并相信这种分析，是不容易的
敏捷模型
敏捷开发是一种以人为核心、迭代、循序渐进的开发方法
特点：
1、短周期开发
2、增量开发
3、由程序员和测试人员编写的自动化测试来监控开发进度
4、通过口头沟通、测试和源代码来交流系统的结构和意图
5、编写代码之前先写测试代码，也叫作测试先行
缺点：
1、团队的组件较难，人员素质要求较高
2、对测试员要求完全掌握各种脚本语言编程，能执行单元测试、自动化测试
3.6软件开发文档
需求分析文档、概要设计文档、详细设计文档、测试设计文档、测试用例、测试报告。
3.7阿里系开发模型的变迁史
3.8项目的一生--BAT测试猿媛
3.9软件测试方法
软件测试概念
经典定义：
软件测试(Software Testing),在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。
标准定义：
软件测试是使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差距。
软件测试的目的：
软件测试目的在于发现问题，检查系统是否满足需求。
软件测试方法和分类
3.10生命周期各个测试方法的对比
3.11软件测试常用术语
C/S：
C指的是客户端(Client),S指的是服务器端(Server)，这种软件是基于局域网或互联网的，需要一台服务器来安装服务器端软件，每台客户端都需要安装客户端软件。比如我们经常用的QQ和各种网络游戏就术语C/S结构的软件。
B/S:
B指的是浏览器(Browser),S指的是服务器(Server)，这种软件同样是基于局域网或互联网的，它与结C/S结构软件的区别就在于，不需要安装客户端(client),只需要有浏览器，就可以直接使用。比如搜狐、新浪等门户网站及163邮箱都术语B/S结构的，软件B/S结构软件是现在软件的主流，与C/S结构软件相比，便于升级和维护，是测试的重点。
缺陷【Bug/Defect】:
软件的Bug指的是软件中(包括程序和文档)不符合用户需求的问题。
测试环境：
软件测试环境就是软件运行的平台，包括软件、硬件和网络的集合。用一个等式来表示：测试环境=软件+硬件+网络。
测试用例【Test Case】:
在测试执行之前设计的一套详细的测试方案，包括测试环境、测试步骤、测试数据和预期结果。
用一个等式来简单表示：测试用例=输入+输出+测试环境
其中，“输入”包括测试数据和操作步骤
“输出”指的是期望结果
“测试环境”指的是系统环境设置
冒烟测试【Smoke Testing】
在对一个新版本进行系统大规模地测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。
α测试：
验收测试的一种，指的是由用户、测试人员、开发人员等共同参与的内部测试。
β测试：
验收测试的一种，指的是内测后的公测，即完全交给最终用户测试。
3.12软件测试常见模型
V模型
V模型是我们熟知的瀑布模型的一种改进，瀑布模型将软件生命周期划分为计划、分析、设计、编码、测试和维护六个阶段，由于早期的错误可能要等到开发后的测试阶段才能发现，所以可能带来严重的后果。
V模型就是在这点改进了瀑布模型，在软件开发的生存期，开发活动和测试活动几乎同时开始，这两个并行的动态的过程就会极大的减少bug和error出现的几率。
W模型：
一些高性能高风险的系统、互联网软件，或一个系统难以被具体模块化的时候，就比较难做成V模型所需的各种构建，需要更强迭代的开发模型或者敏捷开发模型。
W模型从V模型演化过来，实际上开发是V,测试是并行的V；相对于V模型，W模型增加了软件个开发阶段中应同步进行的验证和确认活动，W明确表示出了测试与开发的并行关系。测试与开发是同步进行的，有利于尽早的全面的发现问题。
其他模型
H模型：
真正的测试级别之间不存在严格的次序关系，各阶段间可以反复触发、迭代、增量。
为了解决V模型和W模型存在的问题，有专家提出了H模型。它将测试活动完全独立出来，形成一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。
X模型：
3.13软件测试覆盖率—测试完整性的度量
测试覆盖率
定义：
覆盖率是用来度量测试完整性的一个手段，同时也是测试技术有效性的一个度量。
计算公式： 覆盖率=(至少被执行一次的item数)/item的总数
特点：
1、通过覆盖率测试，可以检测我们的测试是否充分
2、分析出测试的弱点在哪方面
3、指导我们设计能够增加覆盖率的测试用例，有效提高测试质量，但是测试用例设计不能一味追求覆盖率，因为测试成本随覆盖率的增加而增加。
测试覆盖对于黑盒测试来说，主要是指两个方面：①需求覆盖②用例覆盖。
需求覆盖
定义：
它表示在测试中，有哪些函数被测试到了，其被测试到的频率有多大，这些函数在系统所有函数中占的比例有多大通过设计一定的测试用例，要求每个需求点都被测试到。
计算公式： 需求覆盖=(被检验到的需求数量)/(总的需求数量)
用例覆盖
定义:
主要体现在我们每轮测试验证通过的用例数在总用例数中的比重。
计算公式：用例覆盖=(验证通过的用例数量)/(总的用例总数)
尽量保证覆盖要高要全面
3.14测试覆盖率的实际运用—减少上线后的风险
测试覆盖率的运用
① 简单的测试覆盖率：本次测试执行的用例数/所有用例数
上述覆盖率统计建立在认为总用例数编写全面，一般对于大型系统测试要求覆盖率100%。
覆盖率的审核：抽样验收
② 基于产品的测试覆盖率：已测试需求点/设计所有需求数
以产品、需求维护统计，无论大型项目或是小需求迭代都要求覆盖率达到100%。
覆盖率的审核：抽样验收
③基于白盒的测试覆盖率：大多工具判断语句覆盖，即单元测试代码覆盖代码行/总代码行
更多考察研发人员；更多时候要求覆盖率达到80%。
缺陷：
覆盖率数据只能代表测试过哪些代码，不能代表是否测试好这些代码；容易遗漏逻辑、判断等场景。
④基于自动化的测试覆盖率：自动化覆盖的测试场景(测试用例)/所有测试场景(用例)
80/20原则：比如用户80%的时间在使用20%的功能，20%的功能就可以支撑起用户最关键的业务场景，自动化测试的用例选择更着重于这20%的核心功能。
用途：
自动化测试更着重于回归验证，没必要追求过高的覆盖率，而要考虑用例设计。
测试覆盖率的最终意义：
①应用最多的地方在测试停止标准。
②单纯讨论测试覆盖率，在瀑布式开发模型中并不重要，但在螺旋式、敏捷开发模型中，由于不断迭代累加，很难确定哪些模块在考法过程中没有给予足够的测试。
③在短迭代、DevOps中，更强调用单元测试覆盖率来评估不断增加的代码数量。
3.15测试团队的组织架构—没有完美的个人但有完美的团队
金字塔管理模式
矩阵化管理模式
3.16软件测试原则—软件测试人员必备
软件测试人员需要的知识体系
软件测试人员具备的素质
软件测试的原则
原则1：所有的测试都应追溯到用户需求
“产品缺陷的80%以上是在产品开发过程中的需求定义阶段引入的，如果需求得到了准确的验证，则可以消除80%的返工问题，节省总项目投入费用的45%”。
原则2：尽早启动测试工作
原则3：Pareto法则应用于软件测试
① Pareto（帕累托）法则是由意大利经济学家帕累托提出的，又称为28效率法则。
②测试中的Pareto法则是说一般情况下，在分析、设计、实现夹断的复审和测试工作能够发现和避免80%的缺陷，而系统测试又能找出其余缺陷中的80%，最后4%的缺陷可能只有在用户的大范围、长时间使用才会曝露出来。
原则4：穷尽测试是不可能的
由于很少有机会对一个应用软件进行所以可能的测试，对大多数软件开发项目来说，利用风险分析是适当的。这需要判断技能、常识、感觉和经验。如果有正当理由，也可采用正式的方法。
原则5：杀虫剂怪事
① 软件测试越多，其对测试的免疫力越强的现象。
②为了克服杀虫剂怪事，软件测试员必须不断编写不同的、新的测试程序，对程序的不同部分进行测试，以找出更多软件缺陷。
原则6：前进两步，后退一步
①测试中的一个基本问题是—缺陷修复总是会以（20-50）%的记录引入新的缺陷。
②每次修复之后，必须重新运行先前所有的测试用例，从而确保系统不会以隐蔽的方式被破坏。
原则7：三心二意
①三心：细心、信心、耐心。
②二意：团队合作的沟通意识、时刻保持怀疑的态度且有缺陷防御意识。
3.17软件测试规范—软件工程标准
国内通用的软件工程标准主要有ISO9000及CMM。
ISO9000系列标准是ISO国际标准化组织TC/176技术委员会制定的所有国际标准，其核心标准是质量保证标准（ISO9001/2/3）和质量管理标准（ISO9004）。
CMM（Capability Maturity Model）即软件能力成熟度模型，是向软件组织提供如何增加其开发和维护软件过程的控制能力。
ISO9000:
ISO9000系列标准的基本思想，最主要的有两条：
①控制的思想，即对产品形成的全过程—从采购原材料、加工制造到最终产品的销售、售后读物进行控制。
②预防的思想，通过对产品形成的全过程进行控制以及建立并有效运行自我完善机制达到预防不合格，从根本上减少或消除不合格产品。
CMM：
CMM准确来说不是标准，知识对过程能力的评估结果。
CMM对软件企业的评估从初始级开始，共分为5级，一级一级的改进，一级一级的向上提高。等级的上升过程是一个“动态渐进”的过程。
CMM是转为软件开发组织设计的，侧重于软件开发和改进过程，在产品的设计和开发的细节作了较多要求。
软件测试规范
测试系统主要由下面6个相互关联、相互作用的过程组成。
①测试规划
②测试设计
③测试实施
④配置管理
⑤资源管理
⑥测试管理
软件测试过程中一般会从以下几个方面来入手规范过程，并在每个子过程明确角色、职责、活动描述及所需资料。
