【软件测试】概念知识&用例设计

1.如何理解理解软件测试? 

软件测试试图发现程序中的错误(假定其存在)的破坏性的过程

不只是为了证明程序能够正确运行而去测试程序,一开始假设程序中隐藏着错误,然后测试程序发现尽可能多的错误
一个成功的测试用例,通过诱发程序错误促进软件质量的改进

QA的含义:软件质量保证

软件测试的目的:  测试软件功能是否成功实现验证软件是否满足各类文档说明书等 软件质量要求
找出缺陷  为软件产品的质量测量和评价提供依据

2.怎么测一个接口?哪些方式?

可从这些方向扩展:协议,url,参数,请求方式,头部信息,返回;然后性能上响应时间,并发

3. 如何设计测试用例?

结合不同方法的应用：

a) 等价类划分

将输入值分为有效等价类和无效等价类。如果输入规定了输入区间，可划分出一个有效等价类，两个无效等价类;

b) 边界值

任何测试场景下都可以使用边界值法做设计，输入类型可以数值、字符等，要测试的边界包括上点、下点、离点。

c) 错误推测法

错误推测法，即猜测可能和常出现的错误，来提前制定用例，规避风险。错误推测法很受设计人员的测试经验影响，测试经验不同，设计出来的测试用例区别会很大。

d) 因果图法

罗列出所有的输入和输出，将输入和输出整理出因果图和依赖关系，根据每一个依赖做设计。因果图方法考虑输入的组合，特别适用于多个输入条件相关有关联又相互约束的情况。

e) 判定表驱动法

判定表适合于解决多个逻辑条件的组合，将各种逻辑的组合罗列出来，避免遗漏。列出每个对应条件所有可能情况下的取值，不需要考虑条件和顺序，再列出结果动作项，对每个条件进行结果判定。最后可以适当的进行规则简化和合并。

f) 正交法

当输入条件很多时，因果图等设计方法设计出来的用例数往往多的惊人，用正交法可有效减少用例数。正交法的核心思想是从大量测试数据中选取有代表性的点来测试，从而减少测试用例数。

g) 场景法

画出程序流程图，再把流程图转换成控制流图，根据控制流图设计出场景，再根据场景设计测试用例。

4. 什么是接口测试?

开发人员把这个接口实现了，他需要去验证这个接口的实现是否正确
用户输入一串数据，然后让这个接口或者让这个后台功能来处理，然后检查输出结果跟期望是否一致。
接口测试有一个比较明显的区别，就是输入不再是界面的，而是一个基于HTTP的请求；输出也不再是界面，而是基于HTTP的响应。所以需要通过请求和响应分别来输入我们的数据以及检查我们的结果。

5.为什么要做接口测试？

第一个：开发人员把这个接口或者把后台代码开发好了，他会去做接口测试。开发人员自测完成后，测试人员可以对这个接口做一个全面的测试。
第二个：接口测试不会受到输入界面的影响，那界面所做出的一些限制也就不存在了，直接测的就是后台这一块儿，可以检查后台有没有做到相应的限制。
一个常见的问题，页面的输入框可能会有长度限制，比如限制只能输入十个字符，但是后台并没有做限制，这样很容易会导致出现一些数据库的异常，这样的问题可能在功能测试里面没办法发现，但是接口测试可以。所以很多时候，接口测试，可以认为是功能测试的一种补充。它可以让我们的测试做得更深入，更全面。
 

6.App怎样做测试?

需求分析 设计测试用例 接受app版本 
1.冒烟测试
2.业务功能测试：业务逻辑测试、功能点测试、关联性测试，对需求和测试用例覆盖
3.稳定性及异常性测试：交互性测试如：待机拔插线等操作 、 断网 断电异常情况
4.性能测试：服务器接口，多线程压测，不同网络下的响应速度
5.易用性测试：界面与交互性测试，符合交互规范，用户体验好，使用方便
6.适配性测试：分辨率，不同版本系统，不同尺寸等支持
7.回归测试
8.手机流量及电量测试：客户端使用监控电量和流量软件，确定符合规范
9.内存泄漏测试
10.外网测试 wifI 4g 5g 
11.在线升级测试
 

7.接口测试和单元测试的区别?

单元测试:

注重代码逻辑，接口测试注重业务逻辑；关注的是代码的实现和逻辑，测试范围较小，保证实现逻辑通过就行；接口测试因为关注业务，所以测试范围较广，会用更多的测试数据去测试

接口测试:

也是属于功能测试，所以跟我们以往的功能测试流程并没有太大区别，测试流程依旧是：

1.测试接口文档（需求文档）

2.根据接口文档编写测试用例（用例编写完全可以按照以往规则来编写，例如等价类划分，边界值等设计方法）

3. 执行测试，查看不同的参数请求，接口的返回的数据是否达到预期。.

8.通用功能测试点:

业务流程测试:正常场景-异常场景
特殊字符
参数类型
参数有或者null
所有的必选参数
组合可选参数
边界值测试
 

9.什么是黑盒测试?

将程序设定为一个黑匣子,测试目标与程序的内部机制和结构完全无关,重点集中放在发现程序不按其规范正确运行的环境条件,因为程序不知道内部结构,能够确定语句存在的唯一方法,就是试验所有的输入情况
通过有限的测试用例,最大限度提高发现问题的数量,以取得最好的测试效果

10.什么是灰度测试?

指如果软件要在不久的将来推出一个全新的功能，或者做一次比较重大的改版的话，要先进行一个小范围的尝试工作，然后再慢慢放量，直到这个全新的功能覆盖到所有的用户，也就是说在新功能上线的黑白之间有一个灰，所以这种方法也通常被称为灰度测试。类似于我们通常所说的内测。

11.测试用例设计概念

测试用例(Test Case)，是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。
1、 理清测试思路

有的系统本来就是一个大而复杂的项目，因此需要把项目功能细分，根据每一个功能通过编写用例的方式来整理测试系统的思路，避免遗漏掉要测试的功能点。

2、 明确测试任务

编写完用例后，可以明确自己需要执行的用例总数，以便预估测试工作量。并且可以很清楚的知道实际测试执行的进度，还很容易统计和跟踪我们的剩余工作量和回归工作量。

3、 规范测试行为

每个人对于功能和开发原理的理解都是不同的，同一条案例，每个人的理解程度和扩展都是不一样的。对于没有测试经验的新人来讲，更是需要详细明确的用例来规范，以减少遗漏。

12.如何编写用例

1、 测试用例的来源

(a)分析需求文档

需求文档是编写测试用例的第一依据，需求分析的目的一般是：

了解需求的背景;

分析需求的合理性;

明确需求的范围;

l挖掘隐含需求;

b) 了解开发原理

确定开发的实现框架;

明确输入输出代码规则;

减少测试方向偏差;

2、 测试用例的要素

a) 测试环境

测试的系统是什么?硬件软件的要求是什么?

b) 测试数据

测试执行的输入值

c) 测试步骤

提供测试执行过程的步骤。一般控制在三个步骤完成。否则需要考虑用例是否需要拆分，因为每条用例对应的测试目的应该是具有唯一性的。

d) 预期结果

预期结果根据软件需求中的输出得出。那么实际测试过程中，实际测试结果如果与预期结果不符，则就测试不通过;反之则测试通过。

e) 用例标题

用例标题是对测试用例主旨的描述，既要言简意赅，也要能够清楚表达测试用例的目的

f) 用例编号

定义测试用例编号，用来标示每个用例的唯一性，进行测试用例的跟踪和维护。

13.用例覆盖：

包含正面和反面的用例
（1）、正面用例：根据功能模块划分，针对要测试的功能模块，所有正常输入数据的测试用例都写出来
（2）、反面用例：例如登录失败等，输入非法数据，违反唯一约束等等

14.缺陷(bug)的定义

从产品内部看，缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题；从产品外部看，缺陷是系统所需要实现的某种功能的失效

缺陷的严重级别

致命：系统崩溃，404报错，报500，造成系统或应用程序崩溃，死机，系统悬挂，造成数据丢失，页面出现错误乱码，蓝屏等

严重：功能未实现，逻辑错误，影响用户正常操作，与需求完全不符，或因此BUG导致后续功能无法测试

一般：功能实现但不正确，功能上的错误，页面中的错误，逻辑实现但不正确

建议：文案内容与实际不符，错别字，图片错误，建议性BUG

缺陷类型:代码错误  设计缺陷  性能问题  安全相关

(bug状态扭转)提交缺陷  确认缺陷 打开缺陷  修复缺陷 回归测试  关闭

15.测试计划具体内容

1.测试目标
2.人员安排
3.时间进度
4.测试环境:系统架构  软/硬件配置 测试数据
5.测试工具:性能测试工具 监控工具
6.测试策略: 负载测试 压力测试 稳定性测试 并发测试
单一场景:服务器同时间进行同一业务操作 抢红包
混合场景:服务器处理多个不同业务操作 搜索商品 加入购物车 下订单 支付等
7.风险控制

16.性能测试流程:

需求分析:
1.测试对象(数据量,并发量 如:登录 注册 搜索 下单 支付 添加购物车)    
2.确定性能指标(1.吞吐量 TPS 服务器每秒处理的请求数量  2.响应时间 3.用户数  资源利用率(2/8定律)每小时平均负载*4 ) 
3.测试场景

16.性能测试目的

测试需求指标 后端服务器代码  服务器 数据库 存在的瓶颈(能力上限 配置问题) 优化性能 服务器资源的消耗情况
评估当前系统的性能  分析线上问题的瓶颈 
是否满足业务需求场景 
时间:软件的响应时间
空间:服务器磁盘使用率  CPU使用率 内存空闲率

17.性能测试重点关注指标:

吞吐量(服务器每秒处理业务请求的数量 体现服务器的承载能力  业务上:访问人数/天 网络上:每天字节数 技术上: TPS QPS)
并发数(同时访问系统服务器提交的请求用户数)
响应时间(等待时间+执行时间)
点击数(HTTP 发request请求数 图片 js脚本 文本 框架 链接 css样式 数据) 服务器的业务处理能力
资源利用率(CPU利用率 内存利用率(页交换率) 带宽利用率)  用户数
错误率(应该是超时引起的)
TPS 每秒事务数 = (并发数/平均响应时间)
QPS 每秒查询数

18.性能测试分类

特定运行条件下验证系统能力状态
1.负载测试: 测试系统不断加压 直到性能指导达到极限  如:响应时间 超过预定指标或某种资源达到饱和状态 最大负载量(向服务器发生的请求数量)
特点:找到系统处理能力的极限:最优负载量 保证在能够正常稳定运行的情况下的一个负载量

2.压力测试: 系统在饱和状态下 如:CPU、内存在包含使用情况下 系统能处理的会话能力  系统是否会出现错误
特点:检查系统处于压力性能下应用的表现    测试系统的稳定性

3.并发测试: 多用户并发访问同一个应用 同一个功能模块或数据记录是否存在死锁或者其他性能问题
特点: 目的发现系统中可能隐藏的并发访问问题   如:内存泄漏 线程锁 资源争用

4.配置测试: 通过测试系统的软/硬件环境的调整 了解不同系统的性能影响程序,找到系统各项资源的最优分配原则
特点: 

5.可靠性测试: 给系统加载一定业务压力情况下:使系统运行一段时间,检查系统是否稳定
特点: 验证是否支持长期稳定的运行 在压力下持续一段时间的运行 测试过程关注系统的运行状况

19.系统性能调试优化

(硬件问题  网络问题 应用服务器 数据库等配置问题)

20.测试报告总结

(需求覆盖情况 性能测试过程中出现的问题 如:分析 调优 解决 测试人员 进度控制与实际执行偏差 性能测试过程遇到的各类风险如何控制)
获得的经验||测试不同的进度和产物 性能测试结果的分析  性能测试风险阶段风险的管理

21.测试APP的一个页面，怎么区分是原生Native页面，还是H5？

1、看断网情况
　　把手机的网络断掉。然后点开页面。然后可以正常显示的东西就是原生写的。

　　显示404或则错误页面的是html页面。

2.看布局边界
　　可以打开开发者选项中的显示布局边界，页面元素很多的情况下布局是一整块的是h5的，布局密密麻麻的是原生控件。页面有布局的是原生的否则为h5页面。

 3、看复制文章的提示，需要你通过对比才能得出结果
　　比如是文章资讯页面可以长按页面试试，如果出现文字选择、粘贴功能的是H5页面，否则是native原生的页面。

　　有些原生APP开放了复制粘贴功能或者关闭了。而H5的css屏蔽了复制选择功能等等情况。需要通过对目标测试APP进行对比才可知。

判断页面 下拉刷新的时候　如果界面没有明显刷新现象的是原生的，如果有明显刷新现象（比如闪一下）的是H5页面

22.什么是白盒测试?

也叫结构测试:主要是检查程序的内部结构、逻辑、循环和路径

语句覆盖:设计若干测试用例，运行被测程序，使程序中的每个可执行语句至少被执行一次
判定覆盖:设计若干用例，运行被测程序，使得程序中每个判断的取真分支和取假分支至少经历一次
条件覆盖: 每个判断中每个条件的可能取值至少满足一次
判定/条件覆盖:设计测试用例，使得判断条件中的所有条件可能取值至少执行一次，同时，所有判断的可能结果至少执行一次。
条件组合覆盖:程序中每个判断的所有可能的条件取值组合都至少出现一次
路径覆盖:覆盖程序中的所有可能的执行路径

23.群集效应含义

 发现的缺陷越多,证明软件存在的缺陷越多

80%的缺陷聚集在20%的关键核心业务模块中
重点分析测试20%的核心业务   做好需求分析

24.测试分为几个阶段?

单元测试 集成测试 系统测试 验收测试4个阶段
前三个阶段的目的是尽可能发现缺陷,验收测试是验证软件满足用户需求

25.回归测试

缺陷修复后,确保对程序的修改没有给软件其他未改变部分带来新的缺陷

26.APP测试关注点

APP兼容性测试特别重要 手机厂商 手机型号多 相关软/硬件差异性多  着重考虑分辨率 系统版本 尺寸 主流机型等
APP性能测试指标不一样:和WEB一样考虑APP客户端性能外 考虑电量 流量 GPU渲染等消耗
APP网络测试场景复杂性: 4G 5G wifl  切换网络 弱网环境等

APP极限测试:电量不足 内存不足

APP权限测试:摄像头权限  相册权限 位置权限 通讯录权限
APP手机载体存在交叉事件测试 前后台切换,安装/卸载/升级测试
APP用户载体一些用户操作习惯类测试 横竖屏切换 多点触控 事件触发区域 结束进程等

27.APP专项测试

兼容性测试

概念: app产品在不同的软件环境和硬件环境上都有很好的可移植性(都能正常工作)
测试关注点:  手机型号(腾讯移动分析大数据:设备活跃指数 ||百度研究院 浏览研究院 ) 
操作系统  
屏幕分辨率(1080*1920)、尺寸 网络环境(wifi 3G 4G 5G)  测试机的选取原则(Testin云测平台| 模拟器 genymotion Xcode) 
信息的获取渠道(腾讯移动分析大数据:设备活跃指数 ||百度研究院 浏览研究院  || 安卓/苹果官网)

交叉事件测试

(冲突测试或者干扰测试) 一个程序正在执行的过程中,另一个事件或对该过程干扰测试
测试关注点:拨打/接听电话  接受/发送短信   蓝牙耳机的中途断开/连接   网络切换  系统自带应用(摄像头等)

push消息推送测试:

消息推送测试

主要目的唤醒或者提醒用户 
全部推送:
部分推送:
精准推送:
消息形式:弹窗 | 消息通知栏
测试关注点: Push消息应该按规定发送特定用户
APP在后台运行时,应能正常收到其push消息
设备锁屏状态下,应能正常收到APP的Push消息
设备网络断开后再一次建立连接时,应能收到push消息
系统设置设置不接受该APP通知消息,用户应该不在收到PUSH消息
手机关掉APP以后还能收到推送消息: 
ios APNS服务器推送
安卓: 第三方的服务器来推送消息 百度云推送 等

安装、卸载、升级测试
安装类型:  
android(apk) 安装渠道(应用商城)

安装测试关注点
正常情况:正常安装检查是否安装成功
APP版本覆盖测试
回退版本测试
不同型号、系统 屏幕大小 分辨率的手机进行安装
安装完成后 能否正常启动应用程序
安装完成后 重启手机能否正确启动应用程序

异常情况:

安装时内存不足
安装过程中的意外情况(强行断电、断网、来电话、查询信息)
能否取消安装

卸载测试关注点:
正常情况:
用卸载程序进行卸载,检查是否卸载干净
用第三方工具,检查是否卸载干净
不同系统、硬件环境 网络环境下进行卸载
卸载后再次安装 是否正常适用

异常情况:
卸载中出现异常情况能否恢复(手机关机、内存 没电)程序是否还能运行
卸载后是否有残留,是否能够再次进行安装
是否可以取消卸载 软件恢复适用

升级测试关注点:
更新版本需要提示用户

考虑是否进行强制升级:软件存在严重缺陷  软件不能向上兼容 

是否能够跨版本升级
断电续传

APP专项测试-性能测试
内存
CPU
流量
电量
启动速度
界面切换速度
测试关注点:
APP的启动时间是否过长
APP使用对CPU 内存占用情况
APP使用电量 流量的消耗情况
反复长期的操作情况下 系统资源的使用情况

[兼容性测试  安装 卸载 升级测试
交叉事件测试 (手机应用的切换)
push消息推送测试
性能测试
用户体验
极限 边界
权限]

27.冷启动与热启动的含义?

1.APP被后台结束后,这个状态打开APP 这叫做冷启动
2.APP没被后台结束,还再后台运行,再去打开这个程序叫做热启动

28.测试方法

是否覆盖源代码:黑盒测试:

功能  1.业务功能测试 2.界面测试 3.易用性 4.安装 5.卸载升级

性能  1.稳定性测试 2.负载测试 3.压力测试

黑盒测试:等级类划分(满足需求框和不满足需求框验证 有效等价类 无效等价类)  边界值分析  因果图法  错误推测法
判定表的概念(存在多个输入或多个输出   输入和输入之间存在组合关系 输入和输出之间存在依赖关系)

是否允许: 静态测试 1.代码走查  2.设计与需求文档动态测试 1.程序 2.sql

具有输入功能,但输入之间没有组合关系 >>推荐等价类划分

输入有边界如长度 类型  >>边界值分析法

多输入、输出 输入与输出之间存在组合关系  输入与输出之间存在依赖和约束关系 >>因果图法和判断表

用最少的测试用例获取最大测试覆盖率 >>推荐使用正交法

多个功能的组合测试 >>流程图与场景法

29.如何进行测试需求分析?

收集各类文档 阅读文档 提出问题 分析问题 整理需求信息
编写测试需求分析说明书: 功能分解 编写检查点和测试点

需求分析 软件的主要功能 流程   开发语言 数据类型 数据库  运行环境 硬件 软件 网络 软件架构 用户群体 测试范围 测试优先级

冒烟测试: 用一组运行来确定这个给出的小版本是否可以测试的测试用例  主要测试软件的基本功能 来判断整个软件值不值得进行大规模测试

测试用例是一个文档: 用例编号 测试模块 优先级  测试标题 前置条件  测试步骤   测试数据  预期结果 

好的测试用例: 完善 简介 一致 表明测试的目的 覆盖程度要高  用例描述正确、规范  用例分类描述要足够清晰 测试用例宜于维护 可复用 可重复性 可追踪性

投入运行后需要测试;  维护测试 升级测试  数据迁移测试 备份恢复测试 灾难恢复测试等

指定测试计划  确认测试范围和测试策略 包括:功能性测试 界面测试 性能测试 数据库测试 安全性测试 兼容性测试
设计测试用例:

功能性测试 
链接测试  提交功能测试  HTML元素是否可以正确加载和显示 多语言支持能否正确选择语言
界面测试  控件是否正确使用
性能测试  压力测试 负载测试
数据库测试 基本功能的检查  是否存在溢出错误 导致系统崩溃或权限泄密

安全性测试 基本登录功能的检查 是否存在溢出错误
兼容性测试 浏览器的兼容性  操作系统的兼容性 软件平台的兼容性  数据库的兼容性 

软件质量:包括 正确性 健壮性 效率 完整性 可用性 风险 可理解性 可维修性 灵活性 可测试性 可移植性 

安全性测试:包括程序、数据库安全性测试
明确区分系统中不同用户权限、 系统中会不会出现用户冲突 

30.业务功能测试概念 

按照用户的需求(需求说明书、原型)去检验开发的代码实现是否满足用户的功能性需求

测试对象:
功能点(单模块) 单元测试
多模块 集成测试
业务流程 系统测试 验收测试 冒烟测试

测试方法:

测试理论阶段与测试用例设计方法
理论阶段方法:
等价类划分 边界值分析   因果图法  判定表 场景法 流程图 正交法  错误推测法

项目阶段测试用例设计方法:
等价类与边界值组合
需求>>测试点>>测试用例(一个测试点就是一条测试用例)
基于场景与业务流程设计测试用例
 

断言，就是结果和预期对比，如果一致，则用例通过，如果不一致，断言失败，用例失败。