初级测试总结

软件的概念
软件是计算机系统中与硬件相互依存的部分，包括程序、数据以及与其相关文档的完整结合。
软件测试的概念
使用人工或自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。
测试和开发的区别
1.人员不同
测试：开发人员和测试人员
开发：只有开发人员
2.所处阶段不同
测试：贯穿整个软件开发生命周期
调试：在软件开发编码阶段以及测试过程中对BUG进行测试
3.对bug处理结果不同
测试：只找出错误，不解决
调试：找出错误并解决
什么是需求
1.用户解决问题或达到目标所需的条件或权能
2.系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或权能
测试生命周期模型
V模型、W模型、瀑布模型、 螺旋模型、敏捷H模型
软件测试流程
1、需求分析，需求评审
2、制定测试计划、计划评审
3、编写测试用例、用例评审
4、测试实施阶段、执行测试用例
按照设计好的用例、准备好的数据和制定的测试策略，实施进行具体的测试过程
5、测试评估阶段
测试总结、缺陷分析、过程评估
V模型

W模型

瀑布模型

需求评审内容
①对需求的描述是否易于理解？
②是否存在有二义性的需求？
③是否定义了术语表，对特定含义的专业术语给予了定义？
④最终产品的每个特征是用唯一的术语描述的吗？
⑤需求中的条件和结果是不是合理，有没有遗漏一些异常因果关系？
⑥需求中有没有包含不确定行描述，如：大约、可能、等
⑦每个规格是不是都有明确说明？
⑧环境搭建是否可能或有困难？
需求分类
1.业务需求
2.用户需求
3.系统需求
什么是测试用例
为实施测试而向被测试系统提供的输入数据、操作或各种环境设置以及期望结果的一个特定的集合。也就是解决要测什么、怎么测和如何衡量的问题
（尽可能的百分百覆盖需求）
什么是测试计划
软件测试计划就是在软件测试工作正式实施之前明确测试的对象，并且通过对资源、时间、风险、测试范围和预算等方面的综合分析和规划，保证有效的实施软件测试。
用例优先级
高：最常执行以保证功能性是稳定的，目标的行为和能力可以正常的工作，和重要的错误和边界被测试的测试用例的集合。
中：这是使给出的功能区域或功能变得更详细，检查功能的多数方面包括边界，错误和配置测试的测试用例。
低：这是通常最少被执行的测试用例。但这并不意味着这些测试都不重要，只是说他们在项目的生命期间里不是常常被运行，例如GUI，错误信息，可用性
用例内容
主要分为三大部分：基本信息、用例主体、执行记录
基本信息：项目名称、功能模块名、用例设计人、测试执行人、功能特性、测试目的、参考信息
用例主体：用例编号、测试对象、检查点、预置条件、操作步骤、优先级、预期结果
执行记录：测试结果、缺陷编号、备注
用例执行结果
通过，不通过，未运行，无法运行
测试计划内容
1.测试目的
2.测试背景
3.文件受众
4.术语和定义
5.测试参考文档
6.测试提交文档
7.测试范围
8.测试策略
9.测试资源
10.测试进度 里程碑
11.系统错误、优先级
12.测试阶段进入退出标准和通过标准
测试阶段
①单元测试（组件测试）
②集成测试 ：自顶向下集成测试 、 自底向上集成测试
③系统测试
④验收测试
黑盒测试方法
1.B/S架构
故障转移和恢复测试
配置测试
容量测试
UI测试
数据和数据库完整性测试
易用性测试
功能测试
性能测试
自动化测试
健壮性测试
稳定性测试
场景测试
逻辑测试
随机测试
兼容性测试
表单值域测试
逆向思维测试
本地化测试
接口测试
回归测试
Cookie测试
Alpha测试
Beta测试
安全性和访问控制测试

2.C/S架构
弱网测试
耗电量监控
流量监控
安装测试
卸载测试
更新测试
权限测试
后台统计
增值业务
兼容性测试
内存溢出
推送消息
稳定性/健壮性/中断测试
安全测试
用户体验交互测试
白盒和黑盒区别
白盒测试：是通过程序的源代码进行测试而不使用用户界面。
黑盒测试：是通过使用整个软件或某种软件功能来严格地测试
①测试特点不同
黑盒测试：测试功能
白盒测试：测试程序接口与结构
②测试依据不同
黑盒测试：需求规格说明书
白盒测试：软件程序
③侧重点不同
黑盒测试：关注功能逻辑实现
白盒测试：关注内部代码结构
测试类型
黑盒 白盒 灰盒
回归测试
更新新版本以后确保老版本的功能依然可以使用
alpha测试—内部测试（未公开）
beta测试—用户公测
冒烟测试
确保软件满足系统测试的要求
系统测试标准
不存在致命或严重级别的BUG
不存在优先级为P1的BUG
遗留问题不能大于总BUG数的8%
遗留问题不能明显影响用户使用
集成模块
驱动模块、存根模块
验收测试内容
合同验收测试、法规性验收测试、alpha测试、beta测试、确保实际效果与需求一致
确认测试
缺陷修复后再对其进行测试，确保真正被修复
设计用例原则
100%的覆盖需求
编写测试用例的方法
等价类
边界值
因果图
场景法
正交法
（有经验的老司机还可采用错误推断法）
正则表达式
bug优先级
P1应立即修复的问题
P2在产品发布之前必须修复的问题
P3如果时间允许应该修复的问题
P4可以在发布版本中存在的问题
P5可改可不改，无伤大雅
BUG严重程度
致命
严重
一般
轻微
建议
常用的BUG管理工具
禅道、JIRA、Bugfree、QC
符合下边5个规则的才能叫做软件缺陷
①软件未达到产品说明书标明的功能
②软件出现了产品说明书指明不会出现的错误
③软件功能超出产品说明书指明范围
④软件未达到产品说明书虽未指出但应达到的目标
⑤软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好
缺陷产生的原因
程序设计错误、文档不完善、需求不断变化、软件的复杂性、沟通交流不够 、工期短，任务大、软硬件支持不完善
判断发现的问题是否是缺陷的方法
①通过参考文档来确认缺陷
②通过了解软件产品的行业背景（或参考同类典型软件）来发现缺陷
③通过沟通来确认和识别缺陷
缺陷报告原则
①Correct（准确）：每个组成部分的描述准确，不会引起误解；
②Clear（清晰）：每个组成部分的描述清晰，易于理解；
③Concise（简洁）：只包含必不可少的信息，不包括任何多余的内容；
④Complete（完整）：包含复现该缺陷的完整步骤和其他本质信息；
⑤Consistent（一致）：按照一致的格式书写全部缺陷报告。
缺陷报告的用途是什么
①记录缺陷
②缺陷分类
③缺陷跟踪
缺陷报告的生命周期（处理流程）
激活、待确认、已解决、待反测、重新激活、已关闭
缺陷报告内容
三部分：基本信息、缺陷主体、跟踪记录
①基本信息：编号、版本号、软件名称、编译号、测试人员、日期、指定处理人、硬件平台、操作系统、严重程度、优先级
②缺陷主体：缺陷概述、预置条件、详细描述、预期结果、实际结果
③跟踪记录：处理报告、处理日期、修改记录、返测人、返测版本、返测日期、返测记录
OSI网络7层协议
1、物理层
2、数据链路层
3、网络层
4、传输层
5、会话层
6、表示层
7、应用层
APP的兼容性测试包含哪些
1、浏览器
2、系统
3、分辨率
4、网络