功能测试点总结

控件测试

• 注册表单控件
  • 用户名文本编辑框
  • 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测试进度状况，从第一个版本开始到最后一个版本）

• 测试环境（描述当前Sprint测试时所用的测试环境信息，包括硬件与软件环境）

• 测试过程（对测试工程师在敏捷开发团队的工做流程、内容进行概要描述及总结，可结合测试任务分配进行阐述。）
• 用例执行（描述当前Sprint共有多少用例，每一个版本执行用例数量及执行结果状况）
• 缺陷分析（描述最后一轮版本测试缺陷数据信息，如版本Bug数量、模块Bug数量、Bug严重度、Bug类型、Bug状态等，可利用禅道直接生成相关图表）
• 遗留问题（列出当前Sprint测试遗留问题，便于敏捷开发团队作质量评估）
• 测试结论（给出明确测试结论，便于产品团队及其利益相关者决定后续工做计划及下一个Sprint是否能够开展。测试结论通常有经过、不经过两种结果）
• 经过（测试到达测试目的，测试经过，进入下一个阶段的工做）
• 不经过（须要重测：测试没有达到测试目标，敏捷开发团队需从新制定测试任务，从新开展测试活动。测试报告见《附录》）