一软件测试概述
1.软件和软件分类
软件是计算机系统中与硬件相互依存的一部分，它包括程序，文档，数据的完整集合
软件的特点
逻辑实体，没有制造过程，没有磨损老化，随时间退化
对计算机系统又依赖性
没有摆脱手工开发方式，实现起来愈加复杂
成本昂贵
软件分类
软件：按功能划分：系统软件（操作系统，系统驱动程序，扩展工具），支持软件（协助用户开发的工具软件：vb,vc,eclipse,版本管理软件），应用软件（订票系统）
按部署结构划分：单机版软件，分布式软件（协同工作软件：）：B/S架构 安装浏览器 C/S架构 需要安装客户端
2.软件测试的概念，产生背景，目的和原则
软件测试的产生背景：开发商为了占有市场，用户为了保证业务的顺利完成
软件测试的意义：保证发布出去的软件质量
系统架构有问题，没有想到这么多人
压力测试：模拟好多人访问；人数不对；
软件测试的概念：Glenford J Myers 1979 软件测试是为了发现错误而运行程序的过程
IEEE 1983 使用人工或自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果（用户期望结果）与实际结果（软件实际运行结果）之间的差别
分析用户需求，实际运行结果
软件测试的目的：1.软件测试是程序的执行过程，目的在于发现错误
2. 通过分析错误，发现当前所采用的软件过程缺陷，改进软件过程
3. 通过对测试业务的深入了解，对新产品的改进提出有意义的建议
4. 验证产品符合质量标准
软件测试的原则
软件测试的职业前景和必备素质
考核：测试用例
上线后出现BUG
捕获用户观点，站在用户的角度，强烈追求高质量的意识，对细节的关注，对高风险的意识
必备技能：测试知识，编程技能，可以写自动化脚本，提高测试效率，数据库知识，网络知识（http协议，安全性压力测试会用到）
二软件测试分类
1.了解黑盒测试 白盒测试 按测试技术划分
黑盒测试：是指不基于内部设计和代码的任何知识，而基于需求和功能性的测试；黑盒测试也成功能测试或数据驱动测试
白盒测试：是基于一个应用代码的内部逻辑知识，即基于覆盖全部代码，分支，路径，条件的测试；白盒测试也成为结构测试或逻辑驱动测试
黑盒测试和白盒测试的对比
白盒测试 黑盒测试
测试依据程序内部结构 需求规则说明书
优点 能够对程序内部的特定部位进行覆盖测试 能够站在用户的立场上进行测试
缺点 无法检验程序的外特性，无法对未实现规格说明的程序欠缺部分进行测试 不能测试程序内部特定部位，如果需求规则说明书有误，则无法发现
2.掌握单元测试，集成测试，系统测试，验收测试 按测试阶段划分
单元测试
单元测试又称为模块测试，是针对程序模块（软件设计的最小单位）来进行正确性检验的测试工作
单元测试的目的：
验证单元代码和详细设计文档的一致性
发现在编码过程中引入和错误
减少开发人员的调试代码的时间
大幅度减少后期缺陷的数量
集成测试
集成测试是在单元测试的基础上，将所有模块按照概要设计要求（如根据流程图）组装成子系统而进行的测试
集成测试的目的：
验证各个子模块组合起来，能否达到预期要求的结果
验证一个模块的功能是否会对另一个模块的功能产生不利的影响
冒烟测试：发版时，开发或者测试人员对软件进行最基本的，正常的功能测试（半个小时）
系统测试：5个（功能测试，性能测试，安全性测试，易用性测试，兼容性测试）
系统测试是将通过集成测试的软件，作为整个计算机系统的一个元素，与计算机硬件，外设，某些支持软件，数据和人员等其他系统元素结合在一起，在实际运行环境下，对计算机系统记性全面的功能覆盖
系统测试的目的：
验证软件产品是否满足用户需求
功能测试：对产品的各个功能进行验证，检查产品是否达到用户要求的功能
性能测试：通过自动化工具模拟正常，峰值，异常负载条件，检查系统各项性能指标是否满足需求压力测试，负载测试
安全性测试：验证应用程序的安全级别和识别潜在安全性缺陷（工具对页面，ＳＱｌ注入）
易用性测试；测试用户在使用软件时，软件交互的适应性，功能性和有效性
兼容性测试：测试软件在不同的平台，不同的网络环境，不同的应用软件之间能否友好的运行
配置测试，文档测试
验收测试
验收测试是软件交付用户正式使用前的最后一道工序，它是以用户为主的测试，软件开发和测试人员也应参加
验收测试的目的：
确认系统满足用户需求并且能够发行
验收测试常用方法：
α测试：由软件开发公司组织内部人员模拟各类用户对即将面世的软件产品进行测试，试图发现错误并修正。俗称：内部测试
β测试：由软件的最终用户们在一个或多个场所进行，定期将这些问题报告给开发者，开发者对软件产品进行必要的修改，并准备向全体客户发布最终软件产品。俗称：公开测试
阶段关系
测试阶段 主要依据 测试方法 主测内容
单元测试 系统设计文档 程序员执行白盒测试 模块测试
集成测试 系统设计文档，需求规格说明书 程序员执行白盒测试和黑盒测试 模块测试，接口测试，功能测试
系统测试 需求规格说明书 黑盒测试
验收测试 需求规格说明书 黑盒测试 功能测试，性能测试，安全性测试，易用性测试，兼容性测试
按实施组织：
了解开发商测试，外包测试
开发商测试：本公司负责测试发布维护
外包测试专门的测试组织进行测试，检查产品是否达到用户的使用标准
三软件测试流程
软件开发模型:瀑布模型，V模型，敏捷模型
软件开发模型：软件开发的全部过程，活动和任务的结构框架
它能清晰，直观的表达软件开发全过程，明确规定了要完成的活动和任务
软件开发中最常用的模型：瀑布模型，从上往下，有次序，不可逆
计划，需求分析，设计，编码，测试，运行-维护
瀑布模型的特征：
软件开发的各项活动严格按照线性方式进行
当前活动接受上一项活动的工作结果
当前活动的工作结果需要进行验证
瀑布模型的缺点：
由于开发模型是线性的，增加了开发的风险
早期错误可能要等到开发后期的阶段才能发现
V模型
v的左端表示传统的瀑布开发模型，v的右端表示相应的测试阶段
用户需求 验收测试
需求分析 系统测试
概要设计 集成测试
详细设计 单元测试
编码
敏捷模型
产品Backlog 迭代Backlog 开发 可执行软件 测试 产品缺陷
测试计划，测试周期，测试用例
特点：开发周期短，增量开发
软件测试流程1
需求分析和讨论-编写测试计划-测试设计-测试执行-缺陷管理-测试报告
需求分析和讨论：需求实现的可行性和测试点，给出合理建议，分析在软件测试过程中可能遇到的风险
工作成果：测试大纲：需求那些点需要测试，那些点有风险
编写测试计划：讨论测试策略（性能测试，安全性测试），测试资源（需要多少人，懂什么技术），测试进度（那天内完成那个模块的测试），测试风险（由于测试技术不成熟），协助测试经理完成测试计划
工作成果：测试计划
测试设计：根据测试大纲，将输入输出数据，操作或各种环境设置以及期望结果的特定集合，形成测试规范
工作成果：测试用例：描述整个操作流程和预期结果（步骤-预期结果）
软件测试流程2
测试执行：执行软件项目测试，发现程序中缺陷，保证产品质量达到规定要求
工作成果：缺陷列表
三软件测试用例设计
测试用例的Excel模板
项目名称 程序版本
模块名称
设计人员 编制时间
功能特性
前置条件
用例编号 相关用例 用例说明 输入数据 预期结果 测试结果（通过/不通过） 缺陷编号 备注
二 测试用例的word模板
设计人员 审核人员 时间
项目名称 程序版本
模块名称
用例编号
操作步骤及输入数据
测试结果
缺陷编号
测试用例的依据：软件需求规格说明书
测试用例的用处：指导测试活动；提高功能测试覆盖率；发现缺陷的基准；
测试用例的设计方法:
等价类划分法
边界值分析法
判定表分刑法
因果图分析法
正交实验法
状态图分析法
场景分析法
等价类划分法：
1. 一种最为典型的黑盒测试方法
2. 把程序的输入划分为若干部分，从每个部分中选取少数代表性数据作为测试用例
3.每一类的代表性数据在测试中的作用等价于这一类中的其他值
有效等价类：有意义输入数据，检验程序是否实现了规格说明的功能，一个或多个；
无效等价类：没有意义和不合理的输入数据，检查程序的功能和性能，不符合规格说明书的部分；
I设计等价类表
每一个等价类分配一个编号；
II设计测试用例
设计一个测试用例，使她能够尽量覆盖尚未覆盖的有效等价类。
重复改操作，从而使所有有效等价类均被覆盖
设计一个测试用例，使她能够覆盖一个无效等价类
重复该操作，从而使所有无效等价类均被覆盖
测试用例编号 输入数值 所属等价类 预期输出
1 -50+24 2 正确输出：-26
2 -130+77 1 错误信息
3 -9+125 3 错误信息
划分等价类的案列
1. 在输入条件规定了取值范围或值得个数的情况下，可以确定一个有效等价类，两个无效等价类
案列：录入学生成绩，范围是0~100
2. 在输入条件规定了输入值得集合或者规定必须如何的条件下，可以确立一个有效等价类，一个无效等价类
案列：录入选修课程，最多选修3门课
3. 在输入条件是一个布尔量的情况下，可以确定一个有效等价类，一个无效等价类
案例：录入性别
4.在规定了输入数据的一组值（假定n个），并且程序要求对每一个输入值分别处理的情况下，可以确立n个有效等价类和一个无效等价类
案列：录入学历;大专，本科，硕士，博士
等价类划分的原则
在规定输入数据必须遵守的规则的情况下，可以确定一个有效等价类，若干个无效等价类
案列：录入年龄，必须是数字
边界值分析法
一种与等价类划分相关的 黑盒测试方法
测试用例编号 输入数值 测试边界 预期输出
1 -100+25 -99 错误提示
边界值分析方法
应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据
重点测试最后一个肯定合法的数据和刚刚超过边界的非法数据
通常和等价类划分一起使用，产生一套完整的测试用例
边界值分析法案列
1. 如果输入条件对取值范围进行了界定，则应以边界内部以及恰巧超过边界外的值作为测试用例
案列：输入范围0~50
2. 如果对取值的个数进行了界定，则应当分别以最大个数，最小个数，比最大个数大1或小1，比最小个数大1或小1作为测试用例
案列：课程名称最多输入12个字符
3. 对于输出条件，同样可以应用前2条提到的两条原则进行测试永烈设计
案例：课程列表每页显示10条记录
四缺陷和缺陷管理
缺陷的产生
缺陷的概念：在软件工程整个生命周期中任何背离需求，无法正确完成用户所要求的功能的问题，包括存在于组件，设备或系统软件中因异常条件不支持而导致系统的失败等都属于缺陷
发现的bug记录下来；那块容易出现bug；
缺陷产生原因：沟通交流不够，程序设计本身错误；软件的复杂性；工期短，任务重；软件开发工具和系统软硬件不完备；
缺陷的特点；
普遍认为的随机缺陷就是重现率低或者在特定的场合只出现一次；找规律；10遍后还没发现规律，记录下来；
从某种意义上来说，是不存在随机的缺陷的。既然是缺陷那就一定存在问题的，其随机性是有其必然性，应该引起足够的重视；
BUG的质量
重现缺陷：
1. 检查系统日志log，看有没有异常出现
2. 检查数据库配置，网络，硬件配置是否和开发环境有差异
3. 状态缺陷是否仅在特定软件状态中出现（第一次安装；重连后）
4. 检查被测对象的版本信息，确认测试的版本是否是正式的软件测试版本
5.借助于别的工具，如fiddler工具去分析（抓包，把客户端和服务器端之间的请求记录下来，给服务器发了什么，服务器返回了什么）
重现缺陷的经验：
1. 抓住细节，善于总结经验；
2. 善于推理，善于运用逆向思维；
3. 简化问题规律的步骤，弄清楚问题产生的原因，总结程序员的教训，对类似问题可以触类旁通；这个bug是怎么产生的，可以找一找有没有类似的问题；
缺陷报告
缺陷报告的用途，记录方法，分类，处理流程
缺陷报告的用途：记录缺陷；缺陷分类()；缺陷跟踪；缺陷统计（严重bug,每个模块有什么bug）；
完整的缺陷报告：
简单描述：
用一句话简单的描述清楚问题；
详细描述：
描述问题的基本环境（软硬件环境）
使用最少的步骤去重现测试工程师的操作步骤和使用的数据；
测试工程师根据上述信息可以给出对问题的简单分析
被测试软件版本
状态，严重级别，优先级别
提交日志，提交人
相关附件
如果从图形界面上反映软件的异常，最好采用截图
被测试软件运行时候的相关日志文件
对于开发工程师而言，不能重现的缺陷报告是没有意义的缺陷报告
缺陷报告实例：
简单描述
详细描述：
软件的测试环境
该问题的重现概率约为~
相关附件：截图
缺陷原因与分析：
一个缺陷一个报告；
报告小缺陷；及时报告缺陷
缺陷报告的分类：按照所属模块分类；按照缺陷严重级别分类；（致命，严重，一般，较小错误（体验方面））；按照缺陷优先级别分类；（特急，加急，高，中，低）；按照缺陷引入原因分类（新功能开发，代码修改代入，项目后期有新的需求）；按复现率分类；（总是，有时，随机，无法重现）
缺陷的处理流程
新建bug
缺陷管理报告系统
mantis
界面测试：确认系统界面清晰美观
确认提示框或提示文字显示合理
确认数据输出准确，格式正确
确认逻辑功能清楚，符合用户的使用习惯
功能测试：确认每个功能都正常使用
确认每项功能都实现了需求规格说明书的要求
确认接受输入数据输出正确的的结果
确认对不同的数据进行容错处理
确认菜单，按钮操作正常
软件升级后能够支持旧版本的数据
性能测试
安全性测试
易用性测试
稳定性测试
1. 搜索功能测试：
搜索框页面检查
按默认条件搜索
是否支持模糊搜索
是否支持精确搜索
对搜索结果：搜索内容为空时候，结果显示，给用户一个友好的提示信息
搜索内容多条显示
正确理解软件测试
网络：在测试过程中，与网络相关的必须考虑到断网或网络不好：友好的提示信息
测试数据：避免使用123.abc等测试数据，所有的测试数据接近实际
账号：避免使用超级管理员进行测试
测试人员尽量不使用同一个用户测试
提示信息：给用户的提示信息准确，详细
容错性：程序出现问题时的容错性，对数据的保护；错误的数据必须不能写到数据库中；
运行速度：运行的快慢，带宽占用情况；流量；
没有修复的bug，一定要追根到底；了解需求的最新情况；
测试是设计好的；
了解你测试的功能，局限性，代码的变动
交叉测试，防止疲劳测试
软件测试要诀：
先测试程序的核心功能，再测试辅助功能
先测试常见情况，再测试异常情况
先测试变更部分，再测试没有变更部分
先测试影响大的部分，再测试影响小的部分
先测试必须要测试的部分，然后测试可选或没有要求测试的部分