测试基础
<!doctype html>
测试基础
爬虫/接口测试
request #模拟浏览器发送请求
selenium #模拟人操作浏览器
基础内容
什么是测试
测试是一个获取信息的过程，用来降低决策风险
软件测试是使用人工或者自动化手段来运行或者测试某个系统的过程，检验它是否满足规定的需求或是弄清楚预期结果与实际结果之间的差别。
总结：软件测试的定义，通过手工或者相关工具，对被测对象进行测试操作。从而验证实际与预期结果是否存在差异。
测试的作用
通过测试工作可以发现并修复软件中的存在的缺陷，从而提高用户对产品的使用信心
测试可以通过记录软件运行过程中产生的一些数据，从而为决策提供数据支持
测试可以降低同类型产品开发遇到的问题风险
测试是干什么的
- 检查代码，评审开发文档
- 进行测试设计，写作测试文档、测试计划、测试方案、测试用例等等
- 执行测试，发现软件缺陷，提交权限报告，并追踪缺陷修复的过程
测试原则
测试远侧是指在执行测试工作时必须要遵守的一些规则：
- 测试证明软件存在缺陷，无论执行什么样的测试操作，都能保证当前软件是有缺陷的
- 不能执行穷尽测试，有些功能是没有办法将所有情况都罗列出来的，所以任何的测试操作都有结束的时间
- 缺陷存在群集现象，首先要了解二八理论，即对于软件的功能来说，核心功能占20%，非核心功能占80%（当然这不是绝对的）。所以，这部分发现缺陷的概率会远高于80%非核心部分。也因此我们遇到的缺陷都会集中在20%的核心功能。
- 某些测试需要依赖特殊的环境，有些测试依赖极端的条件，这种条件有时候很难满足
- 测试因尽早介入，越早发现和解决软件存在的缺陷，我们应该尽可能的尽早展开测试
- 杀虫剂现象，同样的测试用例不能重复多次执行，因为软件会对它产生免疫
- 不存在缺陷谬论，任何软件都不可能是完美的。
测试对象
对于当前的测试行业来说，我们最场测试的主体就是软件（主体功能），但是需要我们测试的也不仅仅是功能需求测试。我们可以将软件分为三部分：
功能合集
使用说明书
配置数据
测试整个过程分为不同的阶段，然后每个阶段都会有相应的测试对象：
需求分析阶段：各种需求规格说明书，比如以当前的技术手段能否实现，市场上是否存在类似的软件，这个时候会产生相应的说明书
软件架构设计：由CTO或一把手，总体构建软件的架构，然后生成API接口文档，然后交由专门的开发区具体实现。
具体编码阶段：这个时候，我们的测试对象就是源代码，（这对测试水平要求太高），所以我们会进行相应的白盒测试，单元测试。
系统功能使用：软件功能主体测试，也就是目前测试行业做的做多的一种测试，测试人员充当用户进行软件使用、测试。
软件架构
所谓软件架构，简单理解为用来软件开发的一种思想，目前来说，最常见的两种模式：
B/S:浏览器和服务器
C/S：客户端和服务端
两种架构的比较：
效率：B/S架构的数据都是由服务器处理，浏览器只负责展示结果，对于服务端压力相对较大，而C/S架构的客户端可以承担一些数据处理，所以执行效率高。
安全：B/S架构的数据客户端都是根据HTTP协议进行的，所以安全性相对C/S架构来说，安全性较低一些
升级：B/S架构的升级只需要升级服务器即可，而C/S架构则是需要两端都需要升级
开发成本：相对于 B/S架构来说，C/S架构的客户端也需要自己开发，所以成本会高一些
测试用例
测试屏幕是否有漏光，案件是否好使，这些都是测试用例
定义：视为特定的目的而设计的一组测试输入、执行条件和预期结果，以便测试是否满足某个也定的需求，通过大量的测试用例来检验软件的运行效果，它是指导测试工作进行的重要依据。
为什么需要测试用例
测试用例的优势在于：
避免盲目测试，提高测试效率，使测试活动规范有序
减轻测试设计的工作量，减少回归测试的复杂程度
根据测试用例的多少和执行难度，估算表测试工作量，便于追踪项目的时间进度和资源分配
测试用例的意义
测试用例是软件测试的核心
软件测试的重要性，测试用例实测实工作的指导，是软件测试质量稳定的根本保障。
影响软件测试的因素很多，如软件本身的复杂程度，开发质量，测试方法合和计术的运用。也有客观因素存在，如人员变动，环境，情绪等
评估测试结果的基准
测试用例的通过率，以及错误率是测试结束的一个重要依据，用来判断该软件测试结果是否可以通过，能否达到上线标准
保证测试的时候不遗漏测试功能点。可以对测试进行牵引。
在编写测试用例的过程中，可以熟悉需求，对系统架构或者业务流程有一个整体深入的了解
测试用例的生命周期
确定测试条件--设计测试用例--实现测试用例--执行测试用例--管理测试用例
测试环境设计
测试环境
为了运行被测软件、完成测试工作所必需的的硬件、软件和网络环境的集合
稳定可控的测试环境可以使测试人员化肥减少的时间，完成测试用例的执行
测试环境内容包括
硬件环境
软件环境
网络环境
测试数据
测试工具
测试环境设计原则
尽可能用真实的环境，少用模拟器和虚拟机
机器配置根据软件不同，不得低于软件运行最低要求
选择主流的操作系统以及软件平台，例如Android系统和iOS系统
测试环境要干净，独立、排除干扰。例如无用的杀毒软件，无用的播放器等等
测试环境所需 的知识
常见的操作系统安装
安装程序所需驱动，解决驱动报错问题
数据库使用
浏览器调试
模拟器和虚拟机的使用
系统镜像和备份与还原工具的使用
测试用例的八大要素：
用例编号：产品名字-测试阶段
测试项目：对应一个功能模块
测试标题：直接对测试点进行细化得出
重要级别：高/中/低
预置条件：需要满足一些前提条件，否则用例无法执行
测试输入：需要加工的输入信息根据具体情况设计
操作步骤：明确给出每个步骤的描述，执行人员根据该步骤执行工作
预期结果：根据预期输出对比实际结果，判断被测对象是否符合需求。
实际结果：根据实际结果，填写报告
输出测试用例
Excel、word、HTML
测试力度
测试用例力度
测试用例可以写的简单也可以复杂
测试用例的设计本质：
设计用例的过程中理解需求、检验需求，并对软件系统的测试方法的思路记录下来，以便指导将来的测试。
基于需求的测试用例设计：
基于需求的用例场景来设计测试用例是直接最有效的方法，因为它直接覆盖了需求，而需求是软件系统的根本，验证对需求的覆盖是软件测试的根本目的
要把测试用例当成活的文档，因为需求是活的，善变的。因此在设计测试用例方面应该要把敏捷方法的这一原则体现出来
测试计划书
测试范围、测试策略、测试资源、测试进度、测试风险
测试计划书是一个叙述了预定的测试活动的范围、途径、资源以及进度安排的文档，我们亲切的称为测试计划书。
此文档确认了测试项、被测特征、测试任务、人员安排，以及任何偶发事件风险
测试计划书使得软件测试是有计划，有组织的软件质量保证活动。如果没有计划，工作就会很松散，随意
测试计划的意义
测试流程规范：测试模型--传统金字塔形--冰淇淋模型--菱形模型--测试过程改进
测试计划书内容包含哪些内容：
人力以及时间资源分配
责任划分
风险控制
如何制定测试计划
- 任务送达：测试经理接到软件测试需求书和需求说明
- 分析测试任务：充分理解被测试软件的需求、评估被测试软件的进度，状态，复杂度和风险。
浙公网安备 33010602011771号