软件测试完整学习

############软件的概念############
错误观点：“软件就是程序，软件开发就是编程序”
软件是计算机系统中与硬件相互依存的另一部分，它是包括程序、数据及其相关文档的完整集合；
程序是按事先设计的功能和性能要求执行的指令序列；
数据是使程序能正常操纵信息的数据结构；
文档是与程序开发，维护和使用有关的图文材料；
############软件十大特性############
形态特性：软件是无形的、不可见的逻辑实体。度量常规产品的几何尺寸、物理性质和化学成分对它确实毫无意义的。
智能特性：软件是复杂的智力产品，它的开发凝聚了人们的大量脑力劳动，它本身也体现了知识实践经验和人类的智慧，具有一定的智能。它可以帮助我们解决复杂的计算、分析、判断和决策问题；
开发特性：尽管已经有了一些工具（也是软件）来辅助软件开发工作，但到目前为止尚未实现自动化。软件开发中仍然包含了相当份量的个体劳动，使得这一大规模知识型工作充满了个人行为和个人因素；
质量特性：软件是个人编写的，由于其开发特性存在，所以不存在完全没有缺陷的软件；
生产特性：与硬件或传统的制造业产品的生产完全不同，软件一旦设计开发出来，如果需要提供多个用户，它的复制十分简单，其成本也极为有限；
管理特性：由于上面的特性存在，所以软件过程中的管理显得更为重要，相比传统行业，也更为独特；
环境特性：软件的开发和运行都离不开相关的计算机系统环境，包括支持它的开发和运行的相关硬件和软件。软件对于计算机系统的环境有着不可摆脱的依赖性；
维护特性：软件投入使用以后需要进行维护，但这种维护与传统产业产品的维护概念有着很大差别，维护体现在升级、优化、功能更新等方面，甚至可以全盘重构；
废弃特性：与硬件不同，软件并不是由于被“用坏”而被废弃的；
应用特性：软件的应用极为广泛，如今它已经渗入国民经济和国防的各个领域，现已成为信息产业、先进制造业和现代服务业的核心，占据了无可取代的地位；
############软件的分类############
系统软件
系统软件是负责管理计算机系统中各种独立的硬件，使得它们可以协调工作；
服务性程序：如诊断程序、排错程序、练习程序等
语言程序：如汇编程序、编译程序、解释程序；
操作系统
数据库管理系统
应用软件
应用软件是为了某种特定的用途而被开发的软件，它可以是一个特定的程序，比如一个图像浏览器，也可以是一组功能联系紧密，可以互相协作的程序的集合；
############软件生命周期############
软件的生命周期，又称为软件的生存周期。它是按照按开发软件的规模和复杂程度，从时间上把软件开发的整个过程（从计划开发开始到软件报废为止的整个历史阶段）进行分解，形成相对独立的几个阶段；
每个阶段又分解成几个具体的任务，然后按规定顺序依次完成各阶段的任务并规定一套标准的文档作为各个阶段的开发成果，最后生产出高质量的软件；

软件开发模型：
由于项目、需求的模式不同，所以在软件生命周期过程中选择的软件开发模型也会有所不同，在历史上，软件开发模型经历了“边做边改”、瀑布、原型、螺旋、敏捷等模式的变更；
瀑布模型：
计划===>需求分析 ===>设计 ===>编码 ===>测试 ===>运行维护
特点：1 软件开发的各项活动严格按照线性方式进行；
2 当前活动接受上一项活动的工作结果；
缺点：1 由于开发模型是线性的，增加了开发的风险
2 早期的错误可能要等到开发后期的阶段才能发现
原型模型：
客户与开发公司紧密联系，开发周期长，开发会受到需求变更的影响；
特点：1 实现客户与系统的交互
2 进一步细化待开发软件需求
3 开发人员可以确定客户的真正需求是什么
螺旋模型：
制定计划 ===>风险分析 ===>实施工程（需求确认、软件需求、软件产品设计、设计确认与认证、详细设计、开发、测试） ===>客户评估
特点：1 螺旋模型是将瀑布模型与快速模型结合起来；
2 强调了其他模型所忽视的风险分析；
3 每一次螺旋包括4个步骤：制定计划、风险分析、实施工程、客户评估；
缺点：1 强调风险分析，但要求许多客户接受并相信这种分析，是不容易的；
敏捷模型：
敏捷开发是一种以人为核心、迭代、循序渐进的开发方法；
特点：1 短周期开发 2 增量开发
3 由程序员和测试人员编写的自动化测试来监控开发进度；
4 通过口头沟通、测试和源代码来交流系统的结构和意图；
5 编写代码之前先写测试代码，也叫作测试先行；
重沟通 少文档
缺点：1 团队的组建较难，人员素质要求较高；
2 对测试员要求掌握各种脚本语言编程，能执行单元测试、自动化测试；

###################PART3 软件开发文档###################

下面是必须的一些文档

生命周期各测试方法对比

	单元测试	集成测试	冒烟测试	系统测试	验收测试
测试阶段	编码后	单元测试完成后	提测后	冒烟测试通过后	发布前
测试对象	最小模块	模块间的接口	整个系统	整个系统	整个系统
测试人员	白盒测试或开发	白盒测试或开发	黑盒测试	黑盒测试	最终用户需求或需求方
测试依据	代码、注释、详细设计文档	单元测试模块、概要设计文档	冒烟测试用例	需求说明文档、测试方案、测试用例	用户需求、验收标准
测试方法	白盒测试	黑盒与百盒结合	黑盒测试（手工或与自动化结合）	黑盒测试	黑盒测试

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出现的几率。

其他模型-H模型：真正的测试级别之间不存在严格的次序关系，各阶段间可以反复触发、迭代、增量。
为了解决V模型和W模型存在的问题，有专家提出了H模型，它将测试活动完全独立出来，形成了一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。
其他模型-X模型：



原则2：尽早的启动测试工作

原则4：穷尽测试是不可能的

原则6：前进两步，后退一步

ISO9000：

CMM：


4-4 测试策划概述

4-5 需求测试







测试安排、发布计划：
罗列测试项目本身重要的里程碑
每个里程碑都需要有明确的结束时间
这个时间可以指导我们后续的测试
如果我们测试时间安排不足，我们就可以在后续的测试范围中挑选优先级比较高的特性来执行测试
这样可以最大限度的保证产品的质量
测试范围（按优先级排列）：
分为In Scope和Out Of Scope
需要说明哪些模块是在测试范围中的，哪些是本阶段测试不考虑的
对于在测试范围中的模块，需要给出优先级，以便相应测试时间不足的情况
对于不在测试范围中的模块，需要给出原因，为什么在本测试阶段不考虑测
测试资源：
测试资源在测试策略中也是很重要的一环，它分为人力和工具两部分
人力资源主要说明参与测试的人员，当然可以包括很多的角色，如专业测试人员、客户、产品经理等
工具主要是指可能用到其他软件
测试环境：
测试环境主要包括推荐环境解决方案，操作系统要求，软硬件要求
对于推荐解决方案，需要陈述的是对测试项目对其他软件的依赖
比如测试项目对JAVA有依赖，推荐版本可能就是1.7
测试方法：
测试方法的罗列主要是为了说明针对测试项目我们要开展哪些类型的测试
功能测试是必须的，非功能测试是可选的
文档管理：
对于一个完整的产品来说，文档是很重要的一环
他一般包括安装、升级文档，用户指南等
文档不单单是一个文件，它需要经过完整的测试才能发布给客户，差的文档很可能会误导用户，从而使他们对测试项目失去信心
风险管理：
风险管理模块需要罗列出来现在已经知道的可能会出现不确定性的因素，这些因素可能来自技术、资源或者其他方面的
4-8 测试方案设计–方案何等重要


我们来看看正常情况下一个测试方案：

5-1 测试设计与测试用例
测试设计是将概括的目标转化为具体的测试条件和测试用例的一系列活动
测试分析和设计的主要任务：
评审测试依据（需求，系统架构、设计和接口说明）
评估测试依据和测试对象的可靠性
通过对测试项、规格说明、测试对象行为和结构的分析，识别测试条件并确定优先级
设计测试用例，并确定优先级（最为重要）
确定测试条件和测试用例所需的必要的测试数据
确定测试条件：
依据在测试策略或测试计划中确定的测试技术
通过对测试依据和测试目标的分析，可以确定需要测试的内容，获得测试条件

测试用例常用设计方法
等价类划分法
边界值法
因果图设计法
判定表设计法
正交实验法
5.2 等价类划分法的特点





回到计算器的例子：等价类划分实战
STEP1：根据测试需求可以分为三个等价类：
一个有效数据的等价类，两个无效数据等价类
有效数据等价类就是：由哪些对程序的规格说明有意义的、合理的输入数据所构成的集合
无效数据等价类就是：哪些对程序的规格说明不合理的或无意义的输入数据所构成的集合







5-4 边界值法





5-5 因果图和判定表

因果图-判定表：
因果图法基于这样的思想：一些程序的功能可以用决策表的形式来表示，并根据输入条件的组合情况规定相应的操作。
因此，可以考虑为决策表中的每一列设计一个测试用例，以便测试程序在输入条件的某种组合下的输出是否正确。
概括的说，因果图方法就是从程序规格说明书的描述中找出因（输入条件）和果（输出结果或程序状态的改变）。
将因果图转换为判定表，为决策表中的每一列设计一个测试用例。
这种方法考虑到了输入情况的各种组合以及各个输入情况之间的相互制约关系。
判定表：
判定表（Decision Table）是分析和表达多逻辑条件下执行不同操作的工具。
在程序设计发展的初期判定表就已被当作编写程序的辅助工具了。
因为它可以把复杂的逻辑关系和多种条件组合的情况表达的既具体又明确。

来源：憨憨老婆伍