功能测试点总结-CSDN博客

控件测试

注册表单控件
- 用户名文本编辑框
- email文本编辑框
- 密码文本编辑框
- 确认密码
- 文本编辑框
- 复选框
- 注册按钮

页面元素
- 编辑框
- 按钮
- 图片/音频/视频
- 下拉列表
- 单选按钮
- 复选框
- Flash插件

编辑框

默认焦点
输入长度
输入内容类型（字母、汉字、特殊符号、脚本代码等）
输入格式限制
能否粘贴输入
能否删除文本等因素
注：测试用例设计方法有等价类、边界值等
隐性需求：是否重名

按钮

默认焦点
按钮视图
按钮功能
脚本触发等方面
HTML中的按钮属性：Button、Submit、Reset(判断其实现方式是否正确，是否能够触发相关操作)

<input type="button" value="弹出窗口" onclick="window.open('/test.html'','_blank')">
复制代码

Submit是Button最常用的类型，当需要表单数据提交至服务器时，可利用Submit按钮，可利用Submit按钮，自动提交数据信息。需注意的是，如果代码中增加了输入验证类的JS脚本，提交数据时可能出现重复提交数据的缺陷。

input name="Submit" type="submit" vulue="" class="us_Submit_reg">
Reset
复制代码

当页面数据信息输入错误或需重新填写时，可使用Button的“Reset”属性。测试工程师测试此类按钮时需关注reset功能是否实现，并且光标位于第一个必填项。
除了Button类型需验证外，还需验证Button文字描述及UI设计

图片测试

图片测试包括图片内容、大小、显示、Alt属性、链接等几个方面内容。
图片内容应该准确表述当前需表述的主题
图片容量大小关乎页面响应性能，因此应适当降低图片容量大小，选择更便于网络传输的图片格式，如：jpg、png等
图片容量大小外，尺寸大小也应当考虑，不能造成整体界面显示变形，有任何违和感
图片的显示清晰度、协调性，如果因系统设计了图片压缩功能，导致图片显示不清晰，则需提出缺陷。

Alt属性

音频

自动播放功能是否实现
音频文件是否正确
播放插件能否正常启动
不允许用户下载音频文件，需进行音频链接安全性测试

视频

与音频类似
播放控件
播放插件
链接安全性
视频的压缩格式
数据缓冲情况

下拉列表

下拉列表在多元化的数据信息展示传输过程中经常被用到，在测试过程中需关注其列表值是否正确，是否有重复，选中后是否正确传递、是否可以多选等方面
某些下拉列表中的数据来源于其他功能，测试时需要考虑功能间的耦合及先后逻辑关系（例:该类别下存在商品，是否允许删除，是否有提示）

单选按钮

实现多选一功能
单选按钮是否有默认设置以及选中后能否保存数据

复选框

当需要选中多个数据时，需使用复选框
多选功能是否能够实现
批量设置
批量删除
能否提交请求
触发应该触发的脚本代码

Flash插件

或其他应用程序插件与用户进行交互
需考虑单独功能的实现情况
以及其与应用系统的接口能否正确传递参数，保证业务流程的正确性
单个逻辑功能测试时，需考虑的因素较多，因为无法确切模拟最终用户的业务活动，仅能尽可能地模拟它们，降低系统发布后出错的可能性

链接测试

对页面链接功能，测试工程师需要考虑其链接文字描述正确性、链接地址跳转正确性、链接触发脚本正确性、是否存在404错误等
如小型Web系统，链接较少，人工测试即可，如果被测试对象包含很多链接，则可利用Xenu链接测试工具进行
Xenu是测试工程师应用较多的链接测试工具，小巧、便捷。可以对本地网页文件测试链接，也可以输入任何公网网站进行测试。测试完成后自动生成测试报告，如果链接存在错误，Xenu用红色显示。

缓存测试

根据Web系统体系架构不同，在系统开发过程中可能采用Cookie、Session、Cache等方法来优化、处理数据信息
Cookie
- 当用户访问一个Web系统后，服务器为了在下一次用户访问时，判断该用户是否为合法用户、是否需要重新登录，或者希望客户端记录某些数据信息时，可设计Cookie以某种具体的数据格式记录在客户端硬盘中
- 通常情况下，Cookie可记录用户登录状态，服务器可保留用户信息，在下一次访问时可显示该用户上一次访问时间，对于购物类网站，也可以利用Cookie实现购物车功能
- 进行Cookie测试时需关注Cookie信息的正确性（服务器给出信息格式），当用户主动删除Cookie信息后，再次访问时，验证能否无须重新登录。电子商务类网站可添加商品信息后删除Cookie，刷新后查看购物车中商品能否成功清除。
Session
- Session为会话，在web系统中表示一个访问者从发出第一访问者从发出第一个请求到最后离开服务，这个过程维持的通信对话时间。
- 当然，Session除了表示时间外，还可能根据实际的应用范围包含用户信息和服务器信息。
- 当某个用户访问Web系统时，服务器将在服务器端为该用户生成一个Session,并将相关数据记录在内存或文件中，某个周期后，如果用户未做任何操作，则服务器将释放该Session。为了识别每个用会话，服务器生成Sessionid来标识
- 从安全性角度考虑，用户使用软件系统进行操作时，除了需提供正确的账号信息外，还可能需要提供正确的Sessionid,服务器将会对账号及Sessionid进行验证。以QQ邮箱为例，用户登录成功后，服务器将会产生一个sid来保证该用户的安全性。如果登录邮箱后，浏览器记录了该链接，关闭浏览器后重新打开该链接时，因为服务器端分配的sid已经变更，服务器将拒绝该访问，需重新登录，以此来保证安全性。

Cache
- Web系统将用户或系统经常访问或使用的数据信息存放在客户端Cache（缓存）或服务器端Cache中，以此来提高响应速度。与Cookie和Session不同，Cache是服务器提供的响应数据，为了提高响应速度，存放在客户端或服务器端。
- 用户发出请求后，首先根据请求的内容从本地读取，如果本地存在所需的数据，则直接加载，减轻服务器的压力，若本地不存在相关数据，则从服务器的Cache中查询，若还不存在，则进行进一步的请求响应操作。
- 很多时候，服务器用Cache提高访问速度，优化系统性能。在web系统前端性能测试时，需关注Cache对测试结果的影响。
- 当网页访问以后，客户端将保存相关的数据信息，再次访问时，浏览器首先判断本地是否有待请求的数据，如果有，则直接读取，不再从服务器获取。

脚本功能

用户进行相应的输入操作后，能否触发输入合法性判断的JavaScript脚本

文件上传下载

业务系统中可能会使用一些文件上传下载的控件
测试时需要考虑文件上传格式、上传内容、上传后能否正常打开、上传过程中如果出现异常是否有信息提示。
对于文件下载则需考虑下载的文件能否正确打开使用、下载过程中能否中断、中断后可否续传、下载保存的文件名是否正确等。
此类控件会使用比较成熟的功能组件，因此测试难度相对较小
如果上传完成后存在预览功能，测试预览是否实现，并且预览的图片是否清晰，软件系统如果对上传的图片进行压缩，测试需要保证压缩后的照片清晰可用，如果碰到App将图片压缩后清晰度不够，导致无法通过系统验证，需重试很多次才符合，这样的实际对用户来说是极其糟糕的。

表格测试

数据显示
- 用户与系统的交互信息，很多时候通过数据形式记录在数据库中，通过逻辑代码处理，以表格形式展示相关信息，用户增加、修改、删除以及查询数据的最终结果都体现在表格上，因此验证数据显示的正确性是表格测试的核心
- 数据显示主要涉及标题栏、数据内容、字符编码、列宽等几方面
- 标题栏应该与产品需求/DEMO设计相同，字体设计一致，排序需遵从用户习惯确定，如果系统有增强数据的功能，则标题栏的内容、顺序应与增加界面的布局相同
- 现在的系统（管理信息系统Management Information System）
- 显示顺序是否一致。
数据内容
- 表格显示格式确定后，需验证数据内容是否正确，如果“名称”与内容不相符，则为很严重的缺陷，检查数据，尤其是通过字段名称跳转到新页面的数据信息，可打开该商品的详细信息，在测试过程中需仔细校对数据正确性。
- 字符编码一般跟程序代码有关，可能由于浏览器编码设置错误，导致乱码。
- 例：由于FireFox浏览器编码改为简体中文，导致数据显示乱码，将浏览器重新设置为Unicode格式后显示正常，测试工程师在执行测试时，需确认是由于浏览器编码原因导致乱码错误，还是因为程序代码字符集设计错误导致乱码。
- 例：有时候乱码错误可能是因为数据导入数据库时造成的错误，以Mysql数据库伪列，执行SQL导入时，如果不进行匹配的字符集设置，可能导致乱码，这种情况一般是环境搭建问题，与程序代码无关，设置好数据库字符集格式即可。
- （浏览器问题导致乱码不提交缺陷）
- （如果数据库显示是正确的而浏览器显示是乱码）
- （往数据库到数据时产生的错误则是环境搭建问题）
列宽
- 列宽设置不合理将会导致表格界面显示错乱，或者当前列表数据内容较多时，会导致页面被撑开，从而导致界面显示错误，这种情况下，需测试系统是否具有自适应功能，当数据超过界面定义的边界时自动截取或收缩，如果没有自适应功能，则具体情况具体分析，但必须保证界面显示美观
- 自动截取，显示固定列宽，解决界面被撑开、显示错乱的现象
- 单行容纳20个汉字，但在19个汉字换行，第二行仅有1个字，（1）建议加大列宽，（2）UI美化（仅建议）
翻页
- 翻页功能是绝大多数表格应该用到的功能，通常有第一页、最后一页、上一页、下一页、跳转到第几页等，这类功能测试根据字面意思测试即可，跳转功能这可能根据文本编辑框的测试方法进行，输入非数字、输入单引号等
- 有些翻页功能设计时，次页显示的第一条数据是前一页的最后一条数据，设计如此，并非缺陷，测试工程师在测试时应当与开发工程师确认。
附加功能
- 表格中有时候会提示查看、增加、修改、删除数据以及设置每页显示多少条数据的功能，测试工程师应当逐个测试，以确保每项功能正确。
查看数据
- 不同的设计方法，提供了不同的功能，有些表格通过记录名称打开数据详细信息，有些则通过功能按钮打开数据详细信息，无论哪种，需确保数据信息的正确性，这类测试如有条件，可连接数据库通过SQL语句直接查询相关数据，与界面数据信息进行对比测试。
增加数据
- 测试增加数据功能时，点击‘增加’按钮，如果是弹出窗口，则表格数据信息不应当刷新，在新的界面中添加相关数据，添加完成返回时，界面应当全部或局部刷新，显示新增加的数据。
- 如果新增加的数据未能出现在列表中，首先应当确认该数据是否应该显示在当前页面，如果是，再检查是否是因为浏览器缓存问题导致页面刷新错误，最后验证数据库是否存入成功数据。
修改数据
- 很多产品在设计修改功能时，要求将原来的数据读取出来，这点与根据产品设计确定。如果需读出原数据，测试工程师需确认原数据读取是否正确，其他测试方法与增加数据类似。
- 修改数据时，有些字段是不可重新编辑的，如系统自动生成的id号，或者分配的流水号，贷款申请单号等，如果进入修改页面，这些数据处于可编辑状态，无论是否能真正编辑，应提交缺陷。
- 修改数据时的必填项设置应该与增加数据设置一致
- 修改数据具有一定的破坏性，因此数据修改操作在提交时应该给予信息提示，提示信息应与产品需求一致
- 修改数据需考虑数据锁定问题，即数据被其他用户或操作打开时，该数据不可编辑（修改或删除），以保证数据的一致性与安全性。
删除数据
- 删除数据最具破环性，在执行删除数据操作前，系统应当给与提示，如有必要可进行二次确认，如果用户放弃删除操作，则列表不应当刷新，如果用户确认执行删除操作，删除操作完成后，列表进行刷新，已删除的信息不应当出现。
- 删除数据与修改数据一样，同样需考虑数据锁定问题，用户在打开某条记录时，其他用户或操作不可进行修改或删除操作。常用的一个测试方法是具有权限的两个用户同时打开某条记录，A用户先执行删除操作，B用户再执行修改操作，验证被测对象的处理方式。
- 已商城为列:后台管理分别利用两个浏览器登录后，选择某个商品类别进行修改及删除操作。先删除类别，再进行修改，商城提示修改i成功，但返回列表时，该类别并不存在，这种情况测试工程师应当提出缺陷，因为用户在实际应用过程中可能会出现类似冲突的问题，系统应当给与合理的处理与提示。
设置每页显示条数
- 与跳转功能一样，需测试合法输入与非法输入的情况，其他根据需求定。

查询测试

查询功能极大的方便了用户根据条件检索所需的数据，通过不同条件的组合，得到不同价值的数据。
条件组合
- 查询通常至少包括2个以上的查询条件，包括商品分类、商品品牌、商品类型、供货商类型、商品状态、关键字等
- 设计测试用例方法（正交实验法）

《软件测试技术基础教程--理论、方法与工具》

需单独测试，即“商品类别”与“商品品牌”应当联动，“商品类别”发生变化后，“商品品牌”中的数据应当变化
结果显示
- 查询结果显示与表格测试一样，根据查询出来的结果判断查询是否正确。
- 测试过程中需考虑条件与条件间的逻辑关系，不同的系统对模糊查询的界定不同，需进一步确认

经验积累

功能设计
信息提示
系统交互
容错处理
数据边界
- 用户使用习惯或约定俗成的规则
- 功能冗余（功能越多出错率越高）
- 功能夸大（结合系统DEMO、宣传页、用户手册及用户需求进行多重验证，以判断是否存在夸大现象
- 功能过度（任何系统设计，越简洁越好）
- 功能无用（为了实现功能而实现功能）
- 功能错误
- 功能缺失（要实现确未实现的功能）
- 提示错误（提示无法指导当前的操作）
- 提示费解（用户不能根据提示信息找出错误位置及错误原因）
- 提示冗余
- 菜单错乱（相同类别的菜单应该在同一目录，查找与替换功能应该在一起）
- 不可退出（一些脚本错误出现后，无论确定还是取消，都无法退出当前状态，只能强制关闭进程
- 无限等待（加载预告时间，长时间给与一个大概的时间预告）
- 多重光标（）
- 输入限定（系统应当对超限输入做出明确的禁止）
- 输出限定（小数点保留几位，是否应该有个规则说明，多余的信息则以折叠方式展示或过滤掉）
- 错误恢复（异常的故障出现，系统能否恢复到故障前的状态，也是系统健壮性的重要表现。
- 异常调用（系统与系统间的调用，更要保证数据及逻辑的正确性）
- 软件边界
- 硬件边界（内存使用率已经99%了，系统还能运行吗？磁盘已经没有空间了，还需要写日志怎么办？）
- 时间边界（系统等待过程中，是否可以给其发送命令，还有1秒结束安装了，能否取消？还有1秒完成卸载了，能否取消？系统要求15秒内给予响应，否则托管，在15秒刚到时做出响应是否取消退管可能性）
- 空间边界（系统规定了控件的应用空间，如果把控件拖到区域外呢？是否存在“兔死”区域，是否有越界可能）

流程测试

管理信息系统（填写信息-->提交-->人工审核-->发卡）
大多数业务系统
- 用户管理
- 权限管理
- 工作流管理
- 基础数据维护
理解业务结构，根据用户需求有优先级制定合理的测试计划与策略
从用户期望软件完成其所需的业务流程，其他功能则是辅助流程的，因此流程测试是日常测试工作中非常重要的内容
流程测试是测试工程师将被测对象的各个功能通过业务流程贯穿起来运行，模拟真实用户实际的工作流程，从而验证流程的正确性。
流程需求分析、流程测试设计、流程测试执行
业务流程，一般可能由多个功能、多种角色、多种权限组合而成，过程中涉及较多的测试点，进行流程时，需分析业务流程涉及哪些具体的功能、角色及权限
角色
- 涉及几种角色，每种角色对应的权限不同，从用户角色考虑流程的合理性，而不仅仅关注系统实现
权限
- 不同角色对应不同的权限，通过流程测试，可发现权限设计方面的缺陷，例：部门领导应该具有审批普通员工的请假单权限，但不应当具有审批公司领导请假单的权限。测试流程前需确保权限功能的正确性
路径
- 流程包含的分支路径。分支路径说明了业务流程的复杂度。
- 基本流
- 基本流从流程开始直至流程结束，中间无任何异常分支，往往表述一个正向的业务流程，也是也是优先级较高的流程，简单而言，即流程中所有功能都输入软件系统可接受的数据，从而完成整个业务流程。例：普通员工提交请假单->部门领导->同意->人事记录请假信息。
- 备选流
- 尽管在流程流转过程中出现了异常，但仍然能回到基本流主线，最终完成用户期望的业务行为，这样的流程称为备选流。
- 异常流
- 异常流是在备选流的基础上，违反系统约束最终导致用户期望结果未能达成的路径。同样以订单支付为例，系统调用支付接口，用户密码输入错误超过3次，导致支付行为锁定，无法完成后续业务，这样的处理路劲，理解为异常流。
- 确保对用户期望实现的业务清晰
- 判定条件、边界数据、异常处理以及是否符合实际用户应用场景（人工审核）
涉及较大量的数量，可利用一些数据生成工具来制找测试数据
敏捷测试中以一个Sprint为节点，通常Sprint中包括的用户故事具有较强的耦合度，根据业务流程从而开展测试活动
当产品功能逐步集成后，进行冒烟测试时，应当以基本流作为冒烟测试用例执行，验证被测对象是否具备可测性。冒烟测试通过后在进行正式测试。

安全测试（AppScan/Appium）

工具进行扫描安全测试

下载扫描工具（NBSI）（fidder/charles）
口令测试（用户名密码不正确）
授权验证（未登录是否可以浏览、未授权是否可以使用功能、权限重叠是否能正确分配）
有权限可见无权限不可见（都可见，但无权限不可用，不可修改）（都可见但，无权限为灰色）
有无提示再，根据设计进一步确认

日志文件

记录管理员操作和其他人的操作
验证日志管理功能是否实现，其他角色的用户即使赋予了日志管理权限，但也只能查看admin用户的操作日志。

Session和Cookie

SQL注入

屏蔽法

跨站点脚本攻击(AppScan扫描)

平台兼容性

操作系统、浏览器及显示屏幕分辨率的型号、规格越来越多，B/S与C/S结构一样，以验证被测对象能否在不同的操作系统、浏览器及分辨率正常工作
Web兼容性测试一般分为平台、分辨率、浏览器（Windows、Linux、MacOS）

平台兼容性

分辨率兼容性(市场分辨率情况或根据需求来)在相应分辨率下走下冒烟（各功能实现是否正常）

浏览器兼容性

用不同浏览器查看显示是否正常（如：FireFox/Chrome/IE/360/QQ/Safari等）
不同浏览器对Java、Javascript、ActiveX甚至HTML支持都不相同。
IE8一下版本对HTML5的支持不好，而IE8又是Windows 7系统默认浏览器，测试Windows 7+IE8组合
Web系统在交互过程中可能以弹出页面形式进行，如果浏览器开启了广告过滤功能，则可验证浏览器是否能够正确识别该弹出网页，避免出现误拦截。

前端性能测试

资源数量

在服务器传输过程中，如果资源文件太多，同样会降低网络的传输速度，因此坚决杜绝无效资源文件在服务器与客户端之间传输。
测试时需确认每一个资源是否确实需要，并杜绝在过程中出现404错误的访问问题。
利用HttpWatch录制客户端与服务器端的交互过程，生成汇总图。

本地缓存

大型业务系统中，通常会将动态的业务响应转化成静态文件传输至客户端并写入缓存，当用户再次访问时，可根据，可根据实际情况从本地Cache文件读取，以此加快访问感受，减轻服务器压力。测试工程师可通过测试工具检测本地缓存设置对访问速度的影响。

请求数量

尽量减少HTTP请求（Make Fewer HTTP Request）
减少HTTP请求数量带来的显而易见的好处是：减少DNS请求所耗费的时间、减少服务器压力、减少HTTP请求头。

接口测试（badboy.exe）

内部接口（接口文档）
- 测试用例（格式csv格式）
- jemter 导入

读取测试用例

替换参数

正则表达式测试器（RegexTest）

请求结果

系统外部接口

支付接口

快递接口

测试执行规范

集成测试先保功能点后包流程
回归是先保流程后各功能点

缺陷跟踪处理（禅道）

严重程度
BUG状态
缺陷类型
所属模块

不合理
不清晰
未能实现
设计错误
有无校验

确认回归测试

开发工程师修复缺陷后，应将对应的测试用例再次执行，以确认缺陷是否真正成功修复，这个确认过程，称为确认测试。
回归测试是对已被测试的程序在修复缺陷后再次进行用例执行，以确认缺陷修复活动没有引发新的缺陷或导致缺陷被屏蔽。
- 这些缺陷可能存在于被测试的软件中，也可能在与之不相关的其他软件组件中。
- 当软件发生变更或者应用软件的环境发生变化时，需要进行回归测试。
- 实际测试实施过程中，确认测试和回归测试可以并行实施。
- 回归测试可以在所有的测试级别上进行，同时适用于功能测试、非功能测试和结构测试。如果回归测试套件需执行多次，并且变更较少时，可考虑回归测试实现自动化，以提高效率。
- 对于任何一个项目前三轮测试版本迭代过程中，都建议使用回归测试策略。将所有测试用例全部回归。当被测对象是升级或者维护性的版本时，可采用选择性回归策略实施。
确认缺陷是否修复
- 测试工程师提交的缺陷，经过开发工程师处理，如果确实是缺陷，并且已经修复，则测试工程师需在下一个版本上确认缺陷是否已经修复完成，这个过程一般称为缺陷校验。
- 对于状态是“拒绝”的缺陷，测试工程师应当确认开发工程师拒绝的理由是否成立，如果不成立，则需新激活缺陷，如果拒绝理由成立，则关闭缺陷。
执行用例回归测试
- 校验缺陷活动完成后，测试工程师根据测试任务分配进行执行用例活动，重新开展测试活动。
补充：选择性回归测试
- 目标达成发
- 周边影响法（覆盖率按相应要求来）

缺陷报告

版本Bug数量
模块Bug数量
Bug严重度（优先级）
Bug类型
Bug状态
- 当前版本缺陷的处理情况
敏捷测试报告（用例执行情况、缺陷分布、遗留缺陷情况、版本质量评价等）
完整测试报告
- 版本概述（描述当前测试版本的基本信息，如包括的需求、涉及的模块等）
- 团队成员（描述当前Sprint开发团队成员信息）
- 进度回顾（描述当前Sprint测试进度情况，从第一个版本开始到最后一个版本）