测试基础—通用测试点（重点）

一、给你一个水杯该怎么测试？

按照总分的思路回答即可，没有所谓的对不对，只有你考虑不考虑的问题，是思维发散的问题。

总：对于这个水杯，可以从水杯的功能性、性能、安全性、易用性、兼容性、可靠性、可移植性等角度进行测试。

分:

1、在功能性方面，会测试水杯能装水吗，水杯能装热水吗、保温、漏水吗等

2、性能方面，水杯的容量，保温性、隔热性、耐摔吗等

3、安全性方面，水杯的材质是有毒、水杯杯口是否圆滑、是否防滑、隔热设计等

4、易用性方面，防滑、隔热设计、是否有把手、易于携带等

5、兼容性方面，能装汽油、能装酒精吗、石头吗等、北极能用吗、外太空能用吗

....

二、web前端系统的测试点（重点）

1、超链接测试

• 超链接跳转到页面是否正确
• 超链接的文本信息显示是否正确
• 超链接是否是空链（没有指定要跳转到页面的URL地址）
• 是否是死链接（404），可以工具去直接测，不能手工

2、表单测试

• 单选框：选择后提交的值和页面显示的值要一致
• 复选框测试
• 下拉列表：边界（第一、最后一个）、默认值、关联性的
• 文本框：空、null、none、1‘、1 or 1=1#、最大长度、最小长度、最前面带空格、黑名单数据、UI
  • 密码文本框：隐藏显示
  • 邮箱类文本框：格式要求
• 按钮：文本、表单提交功能、UI cutoff问题、可用和不可用
• 提交表单数据的完整性
• 必填和选填项目：必填的不填、选填的都填等
• 快捷键的使用：tab、enter、复制、粘贴

3、cookie和session的测试

cookie是解决http协议无状态特点的一种技术，是在同一浏览器内通过cookie管理器实现多个请求的数据关联的

cookie的时效性

• 具体的时间：到了时间才失效
• session：会话的期间，浏览器打开的期间是有效的、关闭之后就失效了
• 设置的时效值是否合理

session即为会话技术，数据是存储在服务器端，cookie管理器中只是存了对应的id号，更安全一些

• session的值的有效性
• session的值是否在服务器端清理后的情况

4、性能测试

1）前端性能

• 页面组件、标签的加载速度
• JS脚本处理的效率

2）后端性能（重点）

• 并发：大量的用户同时访问某个系统

• 响应时间
• TPS：服务器每秒能处理的请求的数量
• 事务的失败率
• CPU的使用率
• 内存的使用率等

3）性能测试分类

• 压力测试
• 负载测试、极限测试
• 稳定性测试
• 专项测试

5、安全性测试

• 操作系统、中间件的漏洞，导致软件的安全性问题：log4j日志插件的重大漏洞
• 代码是否进行sql注入风险的加固（防sql注入）
• 密码加密，保存在数据库中的密码数据都是经过加密的（md5加密、sha256加密等）
• 数据传输过程的加密（对称加密和非对称加密），就是网络上传输的数据加密
• 系统功能设计上的安全性要求
  • 要根据软件安全等级，要求设置符合等级的密码（数字字母下划线、大小写区分、最少8位）
  • 密码错误次数的限制，防止暴力破解的很关键的点
  • 首次登录系统后台管理员账户，要求修改密码
  • 隔一段时间就要求更新一次密码
  • 跳过登录，直接访问系统（验证cookie、session有效性问题）
• 日志审计功能设计，所有系统使用过程必须被日志记录，防止日志被删除（不一定被别人删除）
• SSL（安全套接层）+证书+http——>https，采用这种协议传输数据更安全

6、兼容性测试

• 防火墙的兼容性（分服务器和客户端的防火墙）
• 操作系统
  • 服务器：Linux、Windows server 2018等
  • 客户端：Windows、macos、Linux等
• web服务器（服务端）
  • Apache：php语言和Python语言比较多
  • Tomcat：结合Java用的比较多
  • Iis-Internet information service：.net语言比较多
• 硬件兼容性
  • 服务器：服务器采用设备厂商
  • 客户端：手机端、pad端、pc端等
• 数据库
  • 关系型：mysql、oracle
  • 非关系型数据库：redis、MongoDB、高斯数据库（华为）
• 浏览器（客户端）
  • Chrome及不同的版本
  • firefox浏览器
  • sarifa浏览器
  • edge浏览器（兼容chrome）
  • 百度浏览器

7、UI测试

• 各页面的风格是否统一
• 各页面的大小是否一致；同样的LOGO图片在各个页面中显示是否大小一致；页面及图片是否居中显示 、各页面的title是否正确
• 栏目名称、文章内容等处的文字是否正确，有错别字或乱码；同一级别的字体、大小、颜色是否统一
• 提示、警告或错误说明应该清楚易懂，用词准确，摒弃模棱两可的字眼
• 切换窗口大小，将窗口缩小后，页面是否按比例缩小或出现滚动条；
• 各个页面缩小的风格是否一致（按比例缩小或出现滚动条，不可二者兼有）
• 父窗体或主窗体的中心位置应该在对角线交点附近；子窗体位置应该在主窗体的左上角或正中；多个子窗体弹出时应该依次向右下方偏移，以显示出窗体标题为宜
• 按钮大小基本相似，忌用太长名称，免得占用太多的页面位置；避免空旷的页面放置很大的按钮；按钮的样式风格要统一；按钮之间的间距要一致
• 页面颜色是否统一；前景色与背景色搭配合理协调，反差不宜太大，最好用深色或刺目的颜色
• 若有滚动信息或者图片，将鼠标放置其上，查看滚动信息或图片是否停止
• 导航处是否按栏目相应的级别显示；导航文字是否在同一行显示
• 所有的图片是否被正确装载，在不同的浏览器，分辨率下图片是否能正常显示（包括位置、大小）
• 文章列表页，左侧的栏目是否与一级、二级栏目的名称、顺序一致
• 调整分辨率验证页面风格是否有错误现象
• 鼠标移动到Flash焦点特效上是否实现，移出焦点特效是否消失

8、分页测试

将来参与的系统以后台管理系统为主，涉及到数据的增删改查

• 当没有数据时，首页、上一页、下一页、尾页标签全部置灰
• 在首页时，“首页””上一页“标签置灰，在尾页时，"尾页”，下一页“标签置灰，在中间页时，四个标签均可点击，且跳转正确
• 翻页后，列表中的数据是否仍按照指定的顺序进行排序
• 各个分页标签是否在同一水平线上
• 各个页面的分页标签是否一致
• 分页的总页数及当前页数显示是否正确
• 是否能正确跳转到指定的页数
• 再分页处输入非数字字符(英文，特殊字符等)，输入0或超出总页数的数字，是否有友好提示信息
• 是否支持回车键的监听

三、移动端的测试点

移动端包括手机端、pad端、移动穿戴设备的app，从系统角度划分为ios、Android、鸿蒙、澎湃os

1、安装和卸载

1）Android、鸿蒙系统app的安装和卸载

Android的安装包是apk文件

• 从应用商城下载安装、从qq、邮件发来、浏览器下载的app进行安装
• 安装后是否有多余的、不应该存在的文件夹目录
• 安装过程中内存不足了、断网了、电量不足了
• 卸载软件之后是否有多余文件夹没有删除

2）iOS系统的安装和卸载

安装包的后缀ipa文件

app已经有了苹果给的企业证书，就可以随便安装

每个苹果设备都有udid的序列号，iTunes是可以获取这个序列号的，开发将这个序列号打包在app中，udid对应的设备就可以安装该App了

Appstore中提供了testflight的软件（就是内测团队使用的）

2、UI测试

要根据软件所在的硬件环境做相应调整

• app的一个页面上所展示的内容有限，就要考虑页面元素的显示、布局情况
• app的每一个页面的同一行上，要求文本、按钮等元素风格、大小要一致
• app的页面深度不能超过7层
• 交互上，以触摸、触碰为主
• 页面上有没有错别字、敏感词汇、图片等
• 元素和元素之间有重叠、被截断

3、交叉事件测试

• 在使用app的时候，突然接听了电话、闹钟响了、回复微信等情况
• 在使用app的时候，将app切到后台、锁屏、再切回来
• 在使用app的时候，电量低、断网状态等

4、功能测试

更新测试

注册、登录、注销等

免登录功能

业务功能（依据需求规格说明书进行测试）

push消息测试（app的消息是否可以推送到手机的任务栏上）

5、兼容性测试

兼容性测试不允许使用虚拟机、模拟器，一定要用真机

1）考虑点：

• 软件的兼容
• 系统的兼容
  • 类型：Android、ios、鸿蒙
  • 版本：
    • Android最新的四个版本：14、13、12、11
    • iOS的最新四个版本：17、16、15、14
    • 鸿蒙：3、4
• 硬件兼容
  • 设备厂商：华为、小米、vivo、OPPO等
  • 屏幕大小：6.x、5.x等
• 网络兼容
  • 4G
  • 5G

2）具体实施：

借：最不可取的

租：testin云测，平时有5、6块手机做测试，上线钱的testin租50块手机进行兼容性测试，拿到测试报告并修复

买：经常使用

四、小程序测试方法

小程序的特点：

1、即用即走、触手可及

2、拥有离线功能

3、基于微信跨平台

4、媲美原生操作的体验

5、流量大、容易裂变

6、体积小巧不占内存

小程序局限性

页面层级——十层

源码大小——16M（单包2M）

功能逻辑——建议简单

接口功能——数量有限

小程序的文件类型

HTML——WXML

CSS——WXSS

JavaScript——js

小程序和app的区别

app安装较为麻烦——>小程序不需要安装，直接即可使用

app开发成本高——>小程序开发是app的1/10

app需要注册登录——>小程序可关联微信账号登录

app分端开发：Android、los、鸿蒙——>基于微信的版本，webview开发，一次开发多处即可使用

功能测试（基于需求的测试）

小程序测试环境下测试（没有安装包、微信也查不到）

• 开发直接生成预览版二维码，测试人员手机微信扫二维码，就可以访问
• 开发提供访问的URL地址，通过浏览器也可以

功能测试点：

• 小程序功能测试流程和web的路程一样
• 在满足使用要求的前提下，应实现用户文档中描述的所有功能
• 所实现的功能应与其文档所描述明示的功能一致
• 应实现功能内在、外在及与业务直接相关的隐含性需求
• 所包含的功能应明示给用户，不应包含隐藏功能
• 终端断网、电话接入等中断或挂起微信时，小程序不应对终端设备产生破坏性影响如系统崩溃
• 反复操作使用小程序相关功能后，微信、移动设备不应出现异常现象
• 在通信信号不稳定、切换网络(2G/3G/WIFI)等的环境下运行小程序时，功能都能正常使用
• 功能上应可以随时停止或退出操作
• 终端锁屏、切换微信权限等操作，应不影响小程序功能的正常使用

功能测试方法：和web端一致

等价类、边界值、场景法、因果图、猜错法、正交实验法

小程序UI测试（和app端一致，相互借鉴使用）

• 是否易于导航，导航是否直观、导航与页面结构、菜单、连接页面的风格是否一致
• 横向比较，各控件操作方式统一、页面标签风格是否统一
• 自适应界面设计，内容根据窗口大小自适应，文字推荐sp比例像素单位
• 文案字体、字号、格式、规范一致
• 页面的图片清晰、尺寸一致、配色合理、风格一致
• 输入框说明文字的内容与系统功能是否一致
• 小程序界面上文字长度是否加以限制、文字内容是否表意不明是否有错别字、信息
• 是否为中文显示
• 是否有敏感性词汇、关键词、敏感性图片，如:涉及版权、专利、隐私等图片

易用性测试

• 本地化内容显示
• 帮助系统设计
• 易学
• 易用
• 用户差错防御性

兼容性测试

os版本兼容（Android和ios底层的函数库层是不同的），以当前主流使用的系统作为选择的参考

微信版本，小程序的基础库版本，基础库是依赖微信程序客户端的，客户端不同小程序的基础库也不同

小程序的功能是基于小程序基础库提供的api方法实现的

屏幕大小

屏幕分辨率

测试平台选择

• 小程序的功能性测试选择testin比较好
• 小程序的兼容性测试、安全性测试选择wetest比较好
• 小游戏的测试选择wetest比较好

注意：后续为补充类内容

五、本地化测试

对于基础开发语言版本转为其他语言后，对其他语言系统测试的过程为本地化测试

1、本地化测试分类

• 功能性测试
• UI界面测试
• 语言翻译测试

2、本地化概念

• G11N：全球化测试
  • 核心功能性测试：针对源开发语言的功能测试，验证和需求、设计的一致性
  • 国际化测试：源语言版本，主要是测试对全球其他国家语言的支持能力
  • 本地化：本地化语言版本，也要测功能，主要是测UI
  • G11N=I18N+L10N
  • 软件版本：英文
  • 系统版本：英文
  • bug修改团队：核心团队

• I18N：国际化测试
  • 软件版本：英文
  • 系统版本：本地化语言系统（中文、俄语、日语、韩语等）
  • bug修复团队：核心团队
• L10N：本地化测试
  • 软件版本：本地化版本
  • 系统版本：本地化语言系统
  • bug修复团队：核心团队（对英文版本）、本地化团队

3、本地化测试点

• 功能性：是属于全球化的国际化测试的重点，本地化测试要测但不是重点，发现了功能性问题，提G110N全球化问题
• UI界面：
  • Cutoff
  • Overlap
  • 没对齐：misalign
  • 文字长度超出控件范围
  • 乱码：因为编码字符集和解码字符集不一致的问题
  • 阅读顺序问题：RTL：从右侧往左侧阅读的习惯
  • 小数点、日期、千分位的格式问题：不同国家的规范不同
  • kinsoku：标点符号不允许出现在每行的首字符
• 语言翻译：
  • 未翻译
  • 过度翻译
  • 翻译错误
  • 漏翻译
  • 垃圾字符

六、白盒测试技术

白盒测试也称为结构测试、逻辑驱动测试，是按照程序的内部实现逻辑设计测试用例并完成测试的一种测试方法

白盒测试：

• 单元测试：Python的单元测试框架的时候
• 代码逻辑覆盖测试
• 路径测试
• 代码的静态走查：根据详细设计、概要设计文档，对源代码进行逐行的阅读、分析、校验的过程
• 代码的静态扫描：代码的安全漏洞、错误、警告（变量定义未使用、内存泄漏、变量使用但为定义等）
• 代码度量：注释率度量（20%+，圈复杂度度量）

1、逻辑覆盖测试

是基于程序的内部实现逻辑的一种覆盖技术

分类：

• 语句覆盖
• 判定覆盖
• 判定条件覆盖
• 条件覆盖
• 条件组合覆盖
• 修正条件判定覆盖（比较难，用工具实现）

1）语句覆盖

js语言中看到分好；就是一条语句

abe——1条用例就完成了覆盖（至少执行该语句一次），a=2；b=0；x=2

语句覆盖是覆盖性最差的一种覆盖技术，一般可以用于逻辑简单的代码，但是

对条件，无法覆盖

对判定，无法覆盖

对循环，无法覆盖

2）判定覆盖

设计测试用例，使得判定取真或者取假至少被执行一次，就是判定覆盖

• abe：ture、true
• acf：false、false

第二种覆盖用例：

• abf：true、false
• ace：false、true

优缺点：

• 判定覆盖要比语句覆盖能力强一些
• 判定覆盖一定能覆盖所有的语句
• 判定覆盖是对判定条件的的整体取真和取假进行覆盖，但是对于条件取真或取假覆盖不到

3）条件覆盖

设计用例，判定中的每个条件取真或者取假至少被覆盖一次的技术（达到100%）

• a>1：true\false
• b=0：true\false
• a=2：true\false
• x>1：true\false

设计用例：

• a=2，b=0，x=2——abe，满足第一个判定为T，第二个判定为T
• a=1，b=1，x=2——ace，满足第一个判定为F，第二个判定为T

条件覆盖的特点：

• 对条件取真取假的覆盖要求
• 条件覆盖100%，不一定满足判定覆盖100%

4）判定条件覆盖

设计用例，在保证所有的条件取真、取假的同时，也要保证判断结果取真、取假至少被执行一次

• a>1：true\false
• b=0：true\false
• a=2：true\false
• x>1：true\false

设计用例：

• a=2，b=0，x=2——abe，满足第一个判定T，第二个判定为T
• a=1，b=1，x=2——ace，满足第一个判定F，第二个判定为F

优缺点：

发现问题的能力要比判定覆盖和条件覆盖都要强一点

还是无法完成所有的路径的覆盖（程序流程图中覆盖箭头短线的至少有一条不一样的就是一个新的路径）

5）条件组合覆盖

设计用例，使得条件取真取假的组合至少被执行一次，最终完成100%覆盖。

分析条件有哪些

• a>1：true\false
• b=0：true\false
• a=2：true\false
• x>1：true\false

条件取值的组合有几种：2^4=16

优缺点：

• 只要完成条件组合覆盖，其他的覆盖一定没问题
• 但是条件组合的方式，测试用例的数量非常大

2、路径覆盖测试

通过逻辑控制数据所产生的路径的覆盖测试方法

前导技术：

• 控制流图
• 基本路径覆盖法（独立路径法）：每个路径中至少要包括其他路径没有出现过的一条分支

1）控制流图

是对程序流程图的一种简化画法

最后将结束位置和开始位置，画一条虚箭头，形成全连通图

2）计算圈复杂度

圈复杂度的值表示程序中独立路径的条数为多少

圈复杂度的计算公式（在全连通图中进行）：

方法1：将空间分割的数量，3个

方法2：m-n+p=3

• m指的是弧数：8
• n表示节点数：6
• 全连通（强连通）的p=1

方法3：判断节点数+1=3

判断节点：该节点往外的弧至少有两条

3）确定线性独立路径的条数