web端测试笔记。

一、好的测试用例的标准

  • 覆盖到所有的功能需求点。
  • 覆盖到所有的业务逻辑(包括正常逻辑和异常逻辑),即正常流和异常流。
  • 覆盖到所有的典型用户场景。
  • 测试目标明确,并且测试步骤能够最快的达到测试目的。
  • 没有冗余的用例。

二.如何达到好的用例标准

  • 了解软件的原始需求,明确测试目的。
  • 熟悉软件的功能需求和实现原理,梳理测试点,基于需求编写测试用例。
  • 梳理业务逻辑,基于逻辑编写测试用例。
  • 基于用户场景编写测试用例。

三、测试用例框架

  • UI测试
  • 功能测试
  • 业务测试
  • 场景测试
  • 稳定性测试
  • 容错性测试
  • 兼容性测试
  • 易用性测试
  • 本地化测试
  • 安全测试
  • 性能测试

四、测试用例设计

1、UI测试
(1)静态测试

  • 对于用户界面的布局、风格、字体、图片等与显示相关的部分测试应该采用静态测试,比如点检表测试。

(2)内容测试

  • 用来检验Web应用系统提供信息的正确性、准确性和相关性。如文字标题是否与文字内容符合,是否存在不需要的文字,是否有相应的操作提示信息(成功、失败、不符合校验等)。

(3)图形测试

  • 要确保图形有明确的用途,图片或动画不要胡乱地堆在一起,以免浪费传输时间。图片尺寸要尽量地小,并且要能清楚地说明某件事情。
  • 验证所有页面字体的风格是否一致。
  • 背景颜色应该与字体颜色和前景颜色相搭配。
  • 图片的大小和质量也是一个很重要的因素,一般采用JPG 或GIF 压缩。

(4)整体界面测试

  • 测试整个网站系统的页面结构设计是否符合用户需求规范。
  • 是否凭直觉就知道要找的信息在什么地方。
  • 整个We 应用系统的设计风格是否一致。

2、功能测试
(1)基本功能

  • 是否正确实现了功能需求定义。

(2)界面测试

  • 新增:

    • 新增的记录必须排在首页首行。
    • 提交失败后必须保留用户已输入的内容,以便再次提交。
    • 提交时或提交前需对主要标识字段进行重复值、空值(空格)判断。
    • 需要验证字段的类型、最大长度限制验证。
    • 可输入/选择框以正常色显示;不可输入/选择框以灰色显示。
  • 删除:

    • 必须有确认删除的提示信息。
    • 删除成功后刷新不显示被删除的记录。
    • 删除成功后返回到原记录所在页面;而当原记录所在页不存在时,则返回上一页。
    • 当被删除的记录与其它记录存在关联时,视实际需求给予不允许删除、更明细提示等信息。
  • 修改:

    • 如界面存在复选按钮,勾选多条记录进行修改时,需给予只能对一条记录进行修改,默认为第一条的提示信息。
    • 修改时加载的内容都为该记录的实际内容,而不再为默认值。
    • 修改完成后必须回到原记录所在位置,且刷新显示修改后的值。
    • 提交失败后必须保留用户已修改的内容,以便再次提交。
    • 在查询条件下修改返回后如不满足查询条件则不显示。
    • 需对主要标识字段进行重复值、空值(空格)判断。
    • 需要验证字段的类型、最大长度限制验证
    • 可输入/选择框以正常色显示;不可输入/选择框以灰色显示;
    • 检查修改时的验证与新增时的验证是否一致。例如很多时候开发人员会想着在新增时做验证,但是做修改功能时容易忽略验证
  • 查询:

    • 每次查询后定位到首页。
    • 每次查询后保留当前查询条件。
    • 当查询条件较多时,请配以重置按钮一同使用。
    • 当未查询到任何记录时,需给予未查找相关记录的提示信息。
    • 除用户明确要求不需要外,需提供模糊查询及组合查询功能。
  • 查看:

    • 一般是选择列表中某一记录点击查看按钮显示记录的详细信息或是双击列表中某一项显示该记录的详细信息
    • 注意设置查看窗口的高度和宽度的合理值。超过最佳设置值时,显示滚动条。
  • 取消:

    • 在数据量较多的页面中,当进行了修改后,取消请给予提示。
    • 取消返回到原记录所在位置。
  • 保存:

    • 当保存所费时间较长时,需给予进度界面提示。
    • 必须控制不可以重复保存。
    • 保存操作是否成功应该给出结果信息,成功或是失败。
  • 重置:

    • 必须保证重置后与初始进入此页面时一致性。
  • 返回:

    • 当从一个页面点击按钮或链接进入子页面时,子页面必须提供返回按钮。
    • 若没有特殊要求,返回应该是返回当前页面的上一页。
  • 翻页:

    • 带条件进行翻页时,翻页同时可执行查询功能。
    • 如翻页后进入子页面,子页面需从首页开始显示。
    • 如有单页复选功能,翻页后不保留选中状态。
  • 全选:

    • 勾选全选则选中当页所有记录。
    • 去掉当页某个记录的勾选,则全选也去掉勾选。
    • 翻页后,自动去掉已勾选的记录及全选的勾选。
    • 单个勾选当前页面所有记录时,全选按钮应该是选中状态。

(3)导航测试

  • 导航测试是导航描述了用户在一个页面内操作的方式,在不同的用户接口控制之间,例如按钮、对话框、列表和窗口等。
  • 或在不同的连接页面之间。常采用手工对网页进行浏览、根据一般用户的浏览习惯来进行评判。导航测试的内容:
    • 导航是否直观。
    • Web 系统主要部分是否可以通过主页访问。
    • Web系统是否需要站点地图、搜索引擎或其他的导航器帮助。
    • 是否缺少返回上一目录的导航功能(虽然可以通过直接点击来实现,但是加入这个功能会更方便,因为大多数用户查找问题或文档时都是先查找同一个目录)。
    • 导航条、菜单、连接的风格是否一致。
    • 各种提示是否准确,确保用户凭直觉就知道是否还有内容,内容在什么地方。一般最好让最终用户参与导航测试,效果将更加明显。

(4)链接测试

  • 首先,测试所有链接是否按指示的那样确实链接到了该链接的页面。
  • 其次,测试所链接的页面是否存在。
  • 最后,保证Web应用系统上没有孤立的页面,所谓孤立页面是指没有链接指向该页面。

(5)表单测试

  • 当用户使用表单进行用户注册、登陆、信息提交等操作时,我们必须测试提交操作的完整性,以校验提交给服务器的信息的正确性。例如:用户填写的出生日期与职业是否恰当,填写的所属省份与所在城市是否匹配等。如果使用了默认值,还要检验默认值的正确性。如果表单只能接受指定的某些值,则也要进行测试。例如:只能接受某些字符,测试时可以跳过这些字符,看系统是否会报错。

(6)页面缓存

  • Cookie:Cookies是否能正常工作,Cookies是否按预定的时间进行保存,刷新对Cookies 有什么影响等,点击商务网站可添加商品信息后删除Cookie,刷新后查看购物车中的商品是否成功清除。
  • Session:测试过程中需关注Session的实效时间。
  • Cache:在web系统前端性能测试时,需关注Cache对测试结果的影响。

(7)脚本功能

  • 为了实现一些特殊的效果或功能,系统往往会使用JavaScript、VBSScript脚本编程技术。

(8)上传下载

  • 在测试时需要考虑文件上传格式、上传内容、上传能否正确打开、上传过程中如果出现异常是否有提示信息。对于文件下载则需要考虑的文件能否正确打开使用、下载过程能否中断,中断是否能续传,下载保存的文件是否正确等。

(9)数据库测试

  • 数据校验:根据业务规则,需要对用户输入进行校验,则要保证这些校验功能正常工作。一般测试数据的一致性错误和输出错误。
  • 数据一致性错误:主要是由于用户提交的表单信息不正确而造成的;
  • 输出错误:主要是由于网络速度或程序设计问题等引起的

(10)翻页测试

  • 对于[首页、上一页、下一页、尾页],翻页链接或按钮的测试:
    • 有无数据时控件的显示情况。
    • 在首页时,首页和上一页是否能点击。
    • 在尾页时,下一页和尾页是否能点击。
    • 在非首页和非尾页时,四个按钮功能是否正确。
    • 翻页后,列表中的记录是否仍然按照指定的排序进行了排序。
    • 第一页时,点跳转按钮go,页面会刷新,这样感觉不好。
    • 对记录进行增、删、改、查时,页面始终都会跳转到第一页,这样易用性不好。
  • 对于[总页数,当前页数],主要要检查的测试点:
    • 总页数是否等于总的记录数/指定每页条数。
    • 当前页数是否正确。
  • 对于[跳转页],主要要检查的测试点:
    • 是否能正常跳转到指定页数。
    • 输入的跳转页数非法时的处理。
  • 对于[指定每页显示条数[,主要要检查的测试点:
    • 是否有默认的指定每页显示条数。
    • 指定每页的条数后,列表显示的记录数,页数是否正常。
    • 输入的每页条数非法时的处理。

(11)输入框测试

  • 字符型输入框:
    • 字符型输入框:英文全角、英文半角、数字、空或者空格、特殊字符“~!@#¥%……&*?[]{}”特别要注意单引号和&符号。禁止直接输入特殊字符时,使用“粘贴、拷贝”功能尝试输入。
    • 长度检查:最小长度、最大长度、最小长度-1、最大长度+1、输入超工字符比如把整个文章拷贝过去。
    • 空格检查:输入的字符间有空格、字符前有空格、字符后有空格、字符前后有空格
    • 多行文本框输入:允许回车换行、保存后再显示能够保存输入的格式、仅输入回车换行,检查能否正确保存(若能,检查保存结果,若不能,查看是否有正常提示)、
    • 安全性检查:输入特殊字符串(null,NULL,,javascript,,,<html>,<td>)、输入脚本函数(<script>alert(“abc”)</script>)、doucment.write(“abc”)、<b>hello</b>)</td></html>
  • 数值型输入框:
    • 边界值:最大值、最小值、最大值+1、最小值-1
    • 位数:最小位数、最大位数、最小位数-1最大位数+1、输入超长值、输入整数
    • 异常值、特殊字符:输入空白(NULL)、空格或”~!@#$%^&*()_+{}|[]\:”<>?;’,./?;:’-=等可能导致系统错误的字符、禁止直接输入特殊字符时,尝试使用粘贴拷贝查看是否能正常提交、word中的特殊功能,通过剪贴板拷贝到输入框,分页符,分节符类似公式的上下标等、数值的特殊符号如∑,㏒,㏑,∏,+,-等、
      输入负整数、负小数、分数、输入字母或汉字、小数(小数前0点舍去的情况,多个小数点的情况)、首位为0的数字如01、02、科学计数法是否支持1.0E2、全角数字与半角数字、数字与字母混合、16进制,8进制数值、货币型输入(允许小数点后面几位)、
    • 安全性检查:不能直接输入就copy。
  • 日期型输入框:
    • 合法性检查:(输入0日、1日、32日)、月输入[1、3、5、7、8、10、12]、日输入[31]、月输入[4、6、9、11]、日输入[30][31]、输入非闰年,月输入[2],日期输入[28、29]、输入闰年,月输入[2]、日期输入[29、30]、月输入[0、1、12、13]
      考虑开始日期与结束日历的比较,特别是在查询的时候。
    • 异常值、特殊字符:输入空白或NULL、输入~!@#¥%……&*(){}[]等可能导致系统错误的字符。
    • 安全性检查:不能直接输入,就copy,是否数据检验出错?

(12)窗口测试

  • 窗口是否基于相关的输入和菜单命令适当地打开。
  • 窗口能否改变大小、移动和滚动。
  • 窗口中的数据内容能否用鼠标、功能键、方向键和键盘访问。
  • 当被覆盖并重新调用后,窗口能否正确地再生。
  • 需要时能否使用所有窗口相关的功能。
  • 所有窗口相关的功能是可操作的吗。
  • 是否有相关的下拉式菜单、工具条、滚动条、对话框、按钮、图标和其他控制可为窗口使用,并适当地显示。
  • 显示多个窗口时,窗口的名称是否被适当地表示。
  • 活动窗口是否被适当地加亮。
  • 如果使用多任务,是否所有的窗口被实时更新。
  • 多次或不正确按鼠标是否会导致无法预料的副作用。
  • 窗口的声音和颜色提示和窗口的操作顺序是否符合需求。
  • 窗口是否正确地被关闭。

(13)搜索功能

  • 如果支持模糊查询,搜索名称中任意一个字符是否能搜索到。
  • 关键字:有大小写混合的情况。
  • 关键字:含有一个或多个空格的情况,包含前空格、中空格、后空格。
  • 关键字:是否支持通配符。
  • 关键字:有效关键字,但是没有匹配搜索结果。
  • 输入html标签,如:&lt,html&gt。
  • 比较长的名称是否能查到。
  • 输入系统中不存在的与之匹配的条件。
  • 用户进行查询操作时,一般不进行查询条件清空。
  • 不同查询条件之间来回选择,是否出现页面错误。
  • 测试多个查询条件时,要注意查询条件的组合测试。

3、业务测试
(1)业务模块

  • 首先要保证单个模块功能的正确性

(2)业务流程

  • 对各个业务模块间传递的数据进行测试,这往往是容易出现问题的地方,测试时一定要设计不同的数据进行测试。如某一功能模块具有最基本的增删改查功能,则需要进行以下测试:
    • 单项功能测试(增加、修改、查询、删除)。
    • 增加——>增加——>增加 (连续增加测试)。
    • 增加——>删除。
    • 增加——>删除——>增加 (新增加的内容与删除内容一致)。
    • 增加——>修改——>删除。
    • 修改——>修改——>修改 (连续修改测试)。
    • 修改——>增加(新增加的内容与修改前内容一致)。
    • 修改——>删除。
    • 修改——>删除——>增加 (新增加的内容与删除内容一致)。
    • 删除——>删除——>删除 (连续删除测试)。

(3)用户权限(使用权限):

  • 赋予一个人员相应的权限后,在界面上看此人员是否具有此权限,并以此人员身份登陆,验证权限设置是否正确(能否超出所给予的权限)。
  • 删除或修改已经登陆系统并正在进行操作的人员的权限,程序能否正确处理。
  • 重新注册系统变更登陆身份后再登录,看程序是否能正确执行,具有权限是否正确。
  • 在有工作组或角色管理的情况下,删除包含用户的工作组或角色,程序能否正确处理。
  • 不同权限用户登录同一个系统,权限范围是否正确。
  • 覆盖系统所有权限设定。
  • 能否添加信息为空的用户(其中包括空用户名及空口令、空用户名非空口令、非空用户名及空口令)。
  • 能否添加长用户名及长口令,如果允许,新用户能否正确登录。
  • 系统是否允许删除系统管理员这一特殊用户或修改系统管理员口令,删除或修改后系统的实际情况。
  • 登录用户能否修改自己的权限。
  • 添加用户(有标识或编号):标识相同,用户名不同;标识相同,用户名相同;标识不同,用户名相同;标识不同,用户名不同。
  • 登录用户能否修改本人(或其他人)的信息,删除本人(或其他人)。
  • 修改用户的信息(包括权限,口令,基本信息等),对其他模块的影响。
  • 修改用户信息:修改后的用户信息和已经存在的用户信息相同;修改后的用户信息和已经存在的用户信息不同。
  • 不给用户授权,是否允许登录。
  • 改某些设置时,是否会影响具有上级权限及相同权限人员的设置。
  • 系统管理员修改了某些数据,以其他人员身份登录时数据是否改变。
  • 用户能否同时属于多个组,各个组的权限能否交叉;删除后重新添加的用户是否具有以前的权限;更改用户各项属性(包括权限)看对权限是否有影响。

4、场景测试

  • 以真实的用户场景进行测试

5、稳定性测试

  • 系统不间断运行(7*24),验证是否内存泄露、系统其他资源是否存在泄露。
  • 如果很紧急上线,可以跑一晚上或者周末跑两天。一般压力很大的情况下,数据库连接数问题、内存泄露问题会曝露的比较快,但是死锁可能不能体现,所以要看系统重要性,如12306稳定性则最好7*24小时。
  • 网络环境测试。

6、容错性测试

  • 输入系统不允许的数据作为输入。
  • 把某个相关模块或者子系统停掉,验证对当前系统的影响。
  • 配置文件删除或者配置错误。
  • 数据库注入错误数据。

7、兼容性测试
(1)浏览器兼容

  • 同一浏览器不同版本兼容。
  • 不同浏览器兼容:IE,FireFox、Chrome、Safari、QQ浏览器、UC浏览器、360浏览器等。浏览器的差异主要体现在javaScript、ActiveX和HTML解码方法处理不同,因此需要在web系统测试时注意,尤其是通过某个控件跳转浏览器时更需要注意。

(2)操作系统兼容

  • 同一操作系统不同版本兼容。
  • 不同操作系统兼容:Windows,MAC,Linux等。在测试过程中需要关注被测试对象在不同操作系统上的表现、尤其是有数据交互时。

(3)分辨率兼容

  • 常见的分辨率:1280X1024、1024X768、800X600等。不同的显示分辨率可能会导致web页面变形,严重时会导致功能无法使用,因此需要测试在不同分辨率下的系统表现。即使在某些分辨率下不能工作,也需要给出提示信息。

(4)插件兼容

  • 在web系统应用了一些控件,如文本编辑器,文件上传下载,这些控件也需要考虑在不同的操作系统,不同的分辨率下的应用表现。

(5)移动浏览

  • 在移动浏览器上测试您的网页,兼容性问题也可能在移动设备上。

8、体验性测试

  • 系统界面的控件是否可以通过tab键遍历,并且顺序合理。
  • 主要功能的入口和操作是否易于理解。
  • 界面是否布局合理,功能是否易于查找和使用。
  • 操作步骤。
  • 操作习惯。
  • 有足够的提示信息,且信息文字描述准确。
  • 风格、样式、颜色是否协调。
  • 界面布局是否整齐、协调(保证全部显示出来的,尽量不要使用滚动条。
  • 界面操作、标题描述是否恰当(描述有歧义、注意是否有错别字)。
  • 操作是否符合人们的常规习惯(有没有把相似的功能的控件放在一起,方便操作)。
  • 提示界面是否符合规范(不应该显示英文的cancel、ok,应该显示中文的确定等)。
  • 界面中各个控件是否对齐。
  • 日期控件是否可编辑。
  • 日期控件的长度是否合理,以修改时可以把时间全部显示出来为准。
  • 查询结果列表列宽是否合理、标签描述是否合理。
  • 查询结果列表太宽没有横向滚动提示。
  • 对于信息比较长的文本,文本框有没有提供自动竖直滚动条。
  • 数据录入控件是否方便。
  • 有没有支持Tab键,键的顺序要有条理,不乱跳。
  • 有没有提供相关的热键。
  • 控件的提示语描述是否正确。
  • 模块调用是否统一,相同的模块是否调用同一个界面。
  • 用滚动条移动页面时,页面的控件是否显示正常。
  • 日期的正确格式应该是XXXX-XX-XX或XXXX-XX-XXXX:XX:XX。
  • 页面是否有多余按钮或标签。
  • 窗口标题或图标是否与菜单栏的统一。
  • 窗口的最大化、最小化是否能正确切换。
  • 对于正常的功能,用户可以不必阅读用户手册就能使用。
  • 执行风险操作时,有确认、删除等提示吗。
  • 操作顺序是否合理。
  • 正确性检查:检查页面上的form, button, table, header, footer,提示信息,还有其他文字拼写,句子的语法等是否正确。
  • 系统应该在用户执行错误的操作之前提出警告,提示信息。
  • 页面分辨率检查,在各种分辨率浏览系统检查系统界面友好性。
  • 合理性检查:做delete, update, add, cancel, back等操作后,查看信息回到的页面是否合理。
  • 背景灰度冻结。

9、本地化测试

  • 本地化翻译
  • 本地化显示
  • 本地化网络

10、安全测试

  • 通过将内部URL直接粘贴到浏览器地址栏而不进行登录测试。内部页面不应打开。
  • 如果您使用用户名和密码登录,并浏览内部页面,请直接尝试更改URL选项。也就是说,如果您检查发布商站点ID = 123的发布商站点统计信息,请尝试直接将URL站点ID参数更改为与登录用户无关的不同站点ID。应该拒绝访问该用户查看其他统计信息。
  • 在登录用户名,密码,输入文本框等输入字段中尝试一些无效输入。检查系统对所有无效输入的反应。
  • Web目录或文件不能直接访问,除非它们具有下载选项。
  • 测试CAPTCHA以自动执行脚本登录。
  • 测试SSL是否用于安全措施。当用户从非安全的http://页面切换到安全的https://页面时,如果使用正确的消息应该被显示,反之亦然。
  • 所有事务,错误消息,安全漏洞尝试都应该在Web服务器上的某个地方登录日志文件。

11、性能测试

  • 响应速度
  • 负载测试
  • 压力测试

持续更新…

最后更新: 2018年05月11日 14:37

原始链接: http://pythonfood.github.io/2017/12/28/web测试/

× 多少都行~
打赏二维码