软件测试基础

软件测试的定义

以人工或者自动化手段，检测被测对象是否满足用户的需求或者实际结果是否与预期结果是否一致

测试和调试的区别

调试debug--开发--找到问题并修改
测试test--tester--找到问题并记录

软件的生命周期

1 市场需求调研
2 可行性研究
3 产品项目立项
4 需求调研开发
5 设计开发测试
6 发布运行维护

软件测试的对象

源代码，数据，文档

测试基础—开发测试模型

软件开发模型

瀑布模型

缺点：越往后发现缺陷修复的成功高，反功能
    需求分析阶段发现的问题修复成本最低
    软件长什么样在测试阶段才知道，有风险，可能不满足需求
优点：
	自上而下每个流程都很清晰
	适合周期很长的项目，强调早作计划
	

原型模型:

优点：克服瀑布模型的一个缺点：到测试阶段才看到软件长什么样
    在需求阶段就加入原型图
~~~原型图：设计　现在是专业的角色：交互~~~
缺点：限制了开发和设计的想法
适合稳定的项目:
demo  低保真（灰色）　高保真（彩色）

RUP模型

优点：用例驱动，以体系结构为核心，迭代及增量的软件过程模型
缺点：需要有架构师；
	适合耦合度比较低的项目；
	已经确定了的功能将不允许变更

敏捷模型

优点：以人为核心，迭代　，循序渐进的方法

软件测试模型

Ｖ模型

缺点：测试介入过晚，发现问题过晚，修复问题成本高

w模型

缺点：测试在需求阶段介入，但是测试写的文档太多了，任务繁重

软件测试的分类

1.需求测试
2.组件/单元测试
3.集成测试
4.系统测试
5.验收测试

需求测试

对需求文档的评审：不一致性　完整性　二义性
需求文档评审会：开发　测试　项目经理　产品
软件中７０－８０%的错误是由于需求文档造成的

	组件/单元测试	集成/接口测试	系统测试
执行人	开发人员	开发，测试	测试
测试对象	代码（函数，类）	接口	整个系统
参照文档	详细设计文档	概要文档	需求文档
代码可见度	白盒（可见）	灰盒（部分）	黑盒（不可见）
测试环境	开发环境	集成环境	现网环境

验收测试

1.Alpha测试：开发在场，发现一个问题开发直接改　
2.Beta测试：公测　开发不在场　有问题收集上来统一修改
3.UAT测试：用户可接受度测试

软件测试的工作流程

1.立项大会，项目成立-->需求文档的输出（测什么)
2.编写测试计划（一般由测试主管，偏管理）
	包含：人事物时间：写用例的时间，搭建环境的时间， 执行测试的时间 ，上线的时间
3.编写测试方案（解决怎么干，偏技术，遵行5w1h，who,when,where环境,why，what,how）：
	测试用例方法  测试的格式 缺陷的严重等级分类
4.搭建环境
5.写用例：
	评审（务必）：
		内评：测试组内
		外评：评审大会，产品和开发
6.等待开发转测：
	冒烟测试：一个产品的最核心的功能是通过的，冒烟通过率达到			98%，如果不通过，版本打回
	冒烟测试的用例：测试写的，从测试用例提取						  		级别最高的用例作为冒烟测试用例
	冒烟测试执行者：开发 	测试
7.系统测试：
	展开多轮，3次
	每轮测试都需要冒烟
	每一轮的用例通过率应不断大幅度升高
	bug发现率应不断大幅度减少
8.测试结束标志：
	需求上的功能实现了
	用例的覆盖率100%
	用例的通过率达到98%
	缺陷的遗留率	不超过10个问题 ，且10个问题中不应该有严重的	问题
9.编写测试报告（测试主管）：
	测试报告是对整个项目的总结
  内容：
		本次测什么（需求）
        哪些人测的
        测试的环境
        用例的每轮通过率
        缺陷		修复率		遗留缺陷的分析
        缺陷二维表描述：
        缺陷+开发
        缺陷+严重程度
        缺陷+模块
        缺陷+重新发现次数
        遗留缺陷的分析:客户同意不改没必要改；下一个版本改；这			些问题暂时不影响本次上线；测试通过的准则

软件的质量特性

iso9126

功能，可靠性，易用性，效率，可移植，可修改

iso25010— 八大特性

Exp：功能性：能接水，喝水
    性能：接多少水，耐摔
    兼容性：放牛奶放水放饮料，瓷杯马克杯大肚杯玻璃杯
    安全性：无毒
    易用：使用方便
    可靠：使用时间长
    可移植：杯帽可以换到另外一个杯子
    可修复：橡皮圈换一个新的继续用

测试类型

1 功能测试
2 性能测试：一般性能，压力测试，负载测试，容量测试
3 兼容
4 安全
5 可靠
6 易用
7 可移植
8 可维护
9 安装测试
10 本地化测试
11 回归测试和确认测试
策略：完全回归，部分回归

测试项分析

测试需求的来源：需求规格说明书，开发需求，协议/规范/标准，用户需				求，继承性需求，测试经验库，同行竞争分析

缺陷

缺陷产生 的原因

遗漏	错误	冗余	不满意

缺陷提交的过程

缺陷报告的内容

缺陷标题、操作步骤、提交人、下一步执行人、优先级、严重级别、所属模块、时间、状态

软件测试的原则

1.测试应该尽早介入，早介入早发现问题，节省成本
2.测试不应该穷尽测试
3.二八法则	80%的问题存在20%的模块中
4.软件测试是为了寻找缺陷，但是不能保证缺陷
5.杀虫剂原则	通过测试用例发现缺陷	杀虫剂=用例	用例基本上要三个月一次，当用例发现不了问题时就要更新用例
6.测试依赖特殊的环境
7.软件没有问题是个谬论

测试用例

测试用例的主要内容

编号、用例标题、优先级、预置条件、操作步骤、预期结果、实际结果

测试用例的重要性

有效性		可复用性	易组织性	可评估		可管理

用例依赖的文档

需求文档
设计文档
遗留系统相关文档
与相关人员讨论
需求规格说明书
测试计划

测试用例的基本准则

测试用例的代表性
结果的可判定性
测试结果的可再观性

测试用例的要素

测什么     怎么测      测的结果

方法：

等价类

有效类把所有有效值并起来，但那时无效类有一个不满足就不满足，单独的算一条

边界值

大量的程序错误不是发生在边界内，而是发生在边界外
	开中间，闭两边
	上点，内点，离点

判定表

正交表

多因子多水平  
均匀分散，齐整可比
正交工具方法
１在allpairs安装目录下输入cmd
２创建一个表格，在表格　里输入所有的因素和水平
３把表格里的数据复制到一个新的记事本里１.txt
４执行命令allpairs.ext 1.txt > 2.txt
自成的2.txt就是正交工具生成的结果文件

场景法

流程，不在乎暗具的某一个输入框，也不在乎框与框之间的关系
用在冒烟测试用法
场景法：主场景　扩展展示　异常场景

所有用例方法

先场景法然后再等价和边界，正交混着用