WEB测试相关

  1. 云栖社区>
  2. 博客>
  3. 正文

WEB测试相关

浮生递归 2018-02-22 09:02:06 浏览1025
展开阅读全文

1:易用性:
按钮名称应该易懂,用词准确,屏弃没楞两可的字眼,要与同一界面上的其他按钮易于区分,能望文知意最好。理想的情况是用户不用查阅帮助就能知道该界面的功能并进行相关的正确操作。
易用性细则:
1):完成相同或相近功能的按钮用Frame框起来,常用按钮要支持快捷方式。
2):完成同一功能或任务的元素放在集中位置,减少鼠标移动的距离。
3):按功能将界面划分局域块,用Frame框括起来,并要有功能说明或标题。
4):界面要支持键盘自动浏览按钮功能,即按Tab键的自动切换功能。
5):界面上首先应输入的和重要信息的控件在Tab顺序中应当靠前,位置也应放在窗口上较醒目的位置。
6):同一界面上的控件数最好不要超过10个,多于10个时可以考虑使用分页界面显示。
7):分页界面要支持在页面间的快捷切换,常用组合快捷键Ctrl+Tab
8):默认按钮要支持Enter及选操作,即按Enter后自动执行默认按钮对应操作。
9):可写控件检测到非法输入后应给出说明并能自动获得焦点。
10):Tab键的顺序与控件排列顺序要一直,目前流行总体从上到下,同时行间从左到右的方式。
11):复选框和选项框按选择几率的高底而先后排列。
12):复选框和选项框要有默认选项,并支持Tab选择。
13):选项数相同时多用选项框而不用下拉列表框。
14):界面空间较小时使用下拉框而不用选项框。
15):选项数叫少时使用选项框,相反使用下拉列表框。
16):专业性强的软件要使用相关的专业术语,通用性界面则提倡使用通用性词眼。
2: 规范性:
通常界面设计都按Windows界面的规范来设计,即包含“菜单条、工具栏、工具厢、状态栏、滚动条、右键快捷菜单”的标准格式,可以说:界面遵循规范化的程度越高,则易用性相应的就越好。小型软件一般不提供工具厢。
规范性细则:
1):常用菜单要有命令快捷方式。
2):完成相同或相近功能的菜单用横线隔开放在同一位置。
3):菜单前的图标能直观的代表要完成的操作。
4):菜单深度一般要求最多控制在三层以内。
5):工具栏要求可以根据用户的要求自己选择定制。
6):相同或相近功能的工具栏放在一起。
7):工具栏中的每一个按钮要有及时提示信息。
8):一条工具栏的长度最长不能超出屏幕宽度。
9): 工具栏的图标能直观的代表要完成的操作。
10):系统常用的工具栏设置默认放置位置。
11):工具栏太多时可以考虑使用工具厢。
12):工具厢要具有可增减性,由用户自己根据需求定制。
13):工具厢的默认总宽度不要超过屏幕宽度的1/5。
14): 状态条要能显示用户切实需要的信息,常用的有:
目前的操作、系统状态、用户位置、用户信息、提示信息、错误信息等,如果某一操作需要的时间较长,还应该显示进度条和进程提示。
15):滚动条的长度要根据显示信息的长度或宽度能及时变换,以利于用户了解显示信息的位置和百分比。
16):状态条的高度以放置五好字为宜,滚动条的宽度比状态条的略窄。
17):菜单和工具条要有清楚的界限;菜单要求凸出显示,这样在移走工具条时仍有立体感。
18):菜单和状态条中通常使用5号字体。工具条一般比菜单要宽,但不要宽的太多,否则看起来很不协调。
19):右键快捷菜单采用与菜单相同的准则。
3:帮助设施:
系统应该提供详尽而可靠的帮助文档,在用户使用产生迷惑时可以自己寻求解决方法。
帮助设施细则:
1):帮助文档中的性能介绍与说明要与系统性能配套一致。(我们的系统帮助文档都是系统的祖先时期的说明,让人困惑)。
2):打包新系统时,对作了修改的地方在帮助文档中要做相应的修改。
3):操作时要提供及时调用系统帮助的功能。常用F1。
4):在界面上调用帮助时应该能够及时定位到与该操作相对的帮助位置。也就是说帮助要有即时针对性。
5):最好提供目前流行的联机帮助格式或HTML帮助格式。
6):用户可以用关键词在帮助索引中搜索所要的帮助,当然也应该提供帮助主题词。
7):如果没有提供书面的帮助文档的话,最好有打印帮助的功能。
8 ):在帮助中应该提供我们的技术支持方式,一旦用户难以自己解决可以方便的寻求新的帮助方式。
4:合理性:
屏幕对角线相交的位置是用户直视的地方,正上方四分之一处为易吸引用户注意力的位置,在放置窗体时要注意利用这两个位置。
合理性细则:
1):父窗体或主窗体的中心位置应该在对角线焦点附近。
2):子窗体位置应该在主窗体的左上角或正中。
3):多个子窗体弹出时应该依次向右下方偏移,以显示窗体出标题为宜。
4):重要的命令按钮与使用较频繁的按钮要放在界面上注目的位置。
5):错误使用容易引起界面退出或关闭的按钮不应该放在易点位置。横排开头或最后与竖排最后为易点位置。
6):与正在进行的操作无关的按钮应该加以屏蔽(Windows中用灰色显示,没法使用该按钮)。
7):对可能造成数据无法恢复的操作必须提供确认信息,给用户放弃选择的机会。
8):非法的输入或操作应有足够的提示说明。
9): 对运行过程中出现问题而引起错误的地方要有提示,让用户明白错误出处,避免形成无限期的等待。
10):提示、警告、或错误说明应该清楚、明了、恰当。
5:美观与协调性:
界面应该大小适合美学观点,感觉协调舒适,能在有效的范围内吸引用户的注意力。
美观与协调性细则:
1): 长宽接近黄金点比例,切忌长宽比例失调、或宽度超过长度。
2): 布局要合理,不宜过于密集,也不能过于空旷,合理的利用空间。
3): 按钮大小基本相近,忌用太长的名称,免得占用过多的界面位置。
4): 按钮的大小要与界面的大小和空间要协调。
5): 避免空旷的界面上放置很大的按钮。
6):放置完控件后界面不应有很大的空缺位置。
7): 字体的大小要与界面的大小比例协调, 通常使用的字体中宋体9-12较为美观,很少使用超过12号的字体。
8): 前景与背景色搭配合理协调,反差不宜太大,最好少用深色,如大红、大绿等。常用色考虑使用Windows界面色调。
9): 如果使用其他颜色,主色要柔和,具有亲和力与磁力,坚决杜绝刺目的颜色。
10): 大型系统常用的主色有"#E1E1E1"、"#EFEFEF"、"#C0C0C0"等。
11): 界面风格要保持一致,字的大小、颜色、字体要相同,除非是需要艺术处理或有特殊要求的地方。
12): 如果窗体支持最小化和最大化或放大时,窗体上的控件也要随着窗体而缩放;切忌只放大窗体而忽略控件的缩放。
13):对于含有按钮的界面一般不应该支持缩放,即右上角只有关闭功能。
14): 通常父窗体支持缩放时,子窗体没有必要缩放。
15):如果能给用户提供自定义界面风格则更好,由用户自己选择颜色、字体等。
6:菜单位置:
菜单是界面上最重要的元素,菜单位置按照按功能来组织。
菜单设测试细则:
1):菜单通常采用“常用--主要--次要--工具--帮助”的位置排列,符合流行的Windows风格。
2):常用的有“文件”、“编辑”,“查看”等,几乎每个系统都有这些选项,当然要根据不同的系统有所取舍。
3):下拉菜单要根据菜单选项的含义进行分组,并切按照一定的规则进行排列,用横线隔开。
4): 一组菜单的使用有先后要求或有向导作用时,应该按先后次序排列。
5): 没有顺序要求的菜单项按使用频率和重要性排列,常用的放在开头, 不常用的靠后放置;重要的放在开头,次要的放在后边。
6): 如果菜单选项较多,应该采用加长菜单的长度而减少深度的原则排列。
7): 菜单深度一般要求最多控制在三层以内。
8): 对常用的菜单要有快捷命令方式,组合原则见8。
9):对与进行的操作无关的菜单要用屏蔽的方式加以处理,如果采用动态加载方式——即只有需要的菜单才显示——最好。
10):菜单前的图标不宜太大,与字高保持一直最好。
11):主菜单的宽度要接近,字数不应多于四个,每个菜单的字数能相同最好。
12):主菜单数目不应太多,最好为单排布置。
。7:独特性:
如果一味的遵循业界的界面标准,则会丧失自己的个性.在框架符合以上规范的情况下,设计具有自己独特风格的界面尤为重要。尤其在商业软件流通中有着很好的迁移默化的广告效用。
1):安装界面上应有单位介绍或产品介绍,并有自己的图标。
2):主界面,最好是大多数界面上要有公司图标。
3):登录界面上要有本产品的标志,同时包含公司图标。
4):帮助菜单的“关于”中应有版权和产品信息。
5):公司的系列产品要保持一直的界面风格,如背景色、字体、菜单排列方式、图标、安装过程、按钮用语等应该大体一致。
8:快捷方式的组合
在菜单及按钮中使用快捷键可以让喜欢使用键盘的用户操作得更快一些 在西文Windows及其应用软件中快捷键的使用大多是一致的。
菜单中:
1):面向事务的组合有:
Ctrl-D 删除 ;Ctrl-F 寻找 ;Ctrl –H替换;Ctrl-I 插入 ;Ctrl-N 新记录 ;Ctrl-S 保存 Ctrl-O 打开。
2):列表:
Ctrl-R ,Ctrl-G定位;Ctrl-Tab下一分页窗口或反序浏览同一页面控件;。
3):编辑:
Ctrl-A全选;Ctrl-C 拷贝;Ctrl-V 粘贴;Ctrl-X 剪切;Ctrl-Z撤消操作;Ctrl-Y恢复操作。
4)文件操作:
Ctrl-P 打印;Ctrl-W 关闭。
5):系统菜单
Alt-A文件;Alt-E编辑;Alt-T工具;Alt-W窗口;Alt-H帮助。
6):MS Windows保留键:
Ctrl-Esc 任务列表 ;Ctrl-F4 关闭窗口; Alt-F4 结束应用;Alt-Tab 下一应用 ;Enter 缺省按钮/确认操作 ;Esc 取消按钮/取消操作 ;Shift-F1 上下文相关帮助 。
按钮中:
可以根据系统需要而调节,以下只是常用的组合。
Alt-Y确定(是);Alt-C取消;Alt-N 否;Alt-D删除;Alt-Q退出;Alt-A添加;Alt-E编辑;Alt-B浏览;Alt-R读;Alt-W写。
这些快捷键也可以作为开发中文应用软件的标准,但亦可使用汉语拼音的开头字母。
9:安全性考虑:
在 界面上通过下列方式来控制出错几率,会大大减少系统因用户人为的错误引起的破坏。开发者应当尽量周全地考虑到各种可能发生的问题,使出错的可能降至最小。 如应用出现保护性错误而退出系统,这种错误最容易使用户对软件失去信心。因为这意味着用户要中断思路,并费时费力地重新登录,而且已进行的操作也会因没有 存盘而全部丢失。
安全性细则:
1):最重要的是排除可能会使应用非正常中止的错误。
2):应当注意尽可能避免用户无意录入无效的数据。
3):采用相关控件限制用户输入值的种类。
4):当用户作出选择的可能性只有两个时,可以采用单选框。
5):当选择的可能再多一些时,可以采用复选框,每一种选择都是有效的,用户不可能输入任何一种无效的选择。
6):当选项特别多时,可以采用列表框,下拉式列表框。
7):在一个应用系统中,开发者应当避免用户作出未经授权或没有意义的操作。
8):对可能引起致命错误或系统出错的输入字符或动作要加限制或屏蔽。
9):对可能发生严重后果的操作要有补救措施。通过补救措施用户可以回到原来的正确状态。
10):对一些特殊符号的输入、与系统使用的符号相冲突的字符等进行判断并阻止用户输入该字符。
11):对错误操作最好支持可逆性处理,如取消系列操作。
12):在输入有效性字符之前应该阻止用户进行只有输入之后才可进行的操作。
13):对可能造成等待时间较长的操作应该提供取消功能。
14):特殊字符常有;;’”><,`‘:“[”{、/|}]+=)-(_*&&^%$#@!~,.。?/还有空格。
15):与系统采用的保留字符冲突的要加以限制。
16):在读入用户所输入的信息时,根据需要选择是否去掉前后空格。
17):有些读入数据库的字段不支持中间有空格,但用户切实需要输入中间空格,这时要在程序中加以处理。
10:多窗口的应用与系统资源:
设计良好的软件不仅要有完备的功能,而且要尽可能的占用最底限度的资源。
1): 在多窗口系统中,有些界面要求必须保持在最顶层,避免用户在打开多个窗口时,不停的切换甚至最小化其他窗口来显示该窗口。
2):在主界面载入完毕后自动卸出内存,让出所占用的WINDOWS系统资源。
3):关闭所有窗体,系统退出后要释放所占的所有系统资源 ,除非是需要后台运行的系统。
4):尽量防止对系统的独占使用。

1.输入验证 输入验证主要包括:数字输入验证、非法字符输入验证、输入长度验证、必填项验证和信息提示 1.数字输入验证:分别输入数字(正数、负数、零值、单精度、双精度)、字符串、空白值、空值、临界数值。不合法的输入,系统给出必要的判断提示信息

2.字符输入验证:分别输入单字节字符、双字节字符、大小写字符、特殊字符、空白值、空值。不合法的输入,系统给出必要的判断提示信息

  1. 日期、时间输入验证:分别输入任意字符、任意数字、非日期格式的数据、非正确日期(错误的闰年日期)、空值、空白值。不合法的输入,系统给出必要的判断提 示信息。注:有些系统会不让输入当日以后或者以前的日期、时间;有些系统会通过JavaScript来自动填写日期时间,这时需要注意是否能否人工主观填 写输入

4.多列表选择框:测试是否能否多选,列表框中的数据是否能否显示完全。当列表框的数据过多时,需要对数据有一定格式的排序

5.单列表下拉框:测试是否能否手工输入,下拉框中的数据是否能否显示完整。当下拉框的数据很多时,需要对数据有一定格式的排序。如果下拉框数据值过多时,下拉框可能会超出IE显示范围,此种情况不能够被接收

6.大文本输入框(textArea):虽然它能够满足大数据量的输入,但最好能够显示地标明输入字符的长度限制,并且应该结合“字符输入验证”进行。需要注意的是,应该允许标点的存在

  1. 文件输入框输入验证:该输入框主要用做文件上传操作。在测试过程中,应该注意输入文件的扩展名。从测试角度来看,要求开发人员必须对扩展名进行输入限制, 并且在适当的地方输入格式提示。当输入是空值等不合法的输入时,系统给出必要的判断提示信息。另外,对于上传的文件大小应该做限制,不宜太大

8.输入字符长度验证:输入字符的长度是否超过实际系统接收字符长度的能力。当输入超出长度时,系统给出必要的判断提示信息

9.必填项验证:输入不允许为空的时候,系统需要有提示用户输入信息功能

10.格式、规则输入验证:当输入需要一定的格式时,系统需要有提示用户输入信息功能。比如身份证号码可以输入18位或者15位,部分身份证最后一位为字母,身份证上生日与身份证号码有一定规则

11.系统错误定位的输入验证:当输入存在问题时,被系统捕获到,此时页面上的光标能够定位到发生错误的输入框

  1. 单选框、多选框的输入验证:单选框需要依次验证单选框的值是否都有效;多选框需要依次验证多选框的值是否都有效 13.验证码验证:做验证码输入验证时,先结合“字符输入验证”进行测试,然后注意的地方是,当利用IE回退或者刷新时,显示的验证码应该和实际系统验证 码一致。如果验证码以图片形式显示,但图片由于其他原因(如网络)不能看到或者显示不完整,系统应该允许进行重新获取,最好不要做整个页面刷新 2.操作验证(CZ) 该用例库主要针对页面操作

1.页面链接检查:每一个链接是否都有对应的页面,并且页面之间切换正确

2.相关性检查:删除/增加一项会不会对其他项产生影响,如果产生影响,这些影响是否都正确

3.检查按钮的功能是否正确:如增、删、改、查等功能是否正确

4.重复提交表单:一条已经成功提交的记录,用IE回退后再提交,看看系统是否做了处理

5.多次IE回退:检查多次使用IE回退的情况,在有回退的地方,回退,回到原来页面,再回退,重复多次,看是否出错

6.快捷键检查:是否支持常用快捷键,如Ctrl+C、Ctrl+V、Backspace等,对一些不允许输入信息的字段,如选人、选日期对快捷方式是否也做了限制

7.回车键检查:在输入结束后直接回车键,看系统处理如何,能否报错

8.上传下载文件检查:上传下载文件的功能是否实现,上传文件是否能打开,对上传文件的格式有何规定,系统是否有解释信息,并检查系统是否能否做到

9.其他验证:在页面上图片的大小不宜太大,需要第三方软件支持时,应该给出必要的信息,比如需要jre的支持,但用户机器还没有安装jre,那么此时在页面上应该有显著的标志来提醒用户进行安装

3.登录模块测试用例 该用例库主要针对登录模块。需要结合“访问控制验证(FWKZYZ)”用例库 1.登录名输入:进行“输入验证”。需要注意登录名是否区分大小写和空格

2.密码输入:进行“输入验证”

3.提交操作:结合“访问空值验证(FWKZYZ)”。当输入正确的登录名和密码后,该用户能够进入到指定的正确页面。当输入的登录名和密码有误时,系统限制其登录,并且给出适当的提示信息。当遇到错误时,应该进行“错误页面测试”

4.重设操作:当进行重设操作时,当前页面上所有输入项被清空

4.增加操作测试用例(ZJ) 该用例库主要针对增加操作

  1. 添加输入内容,进行“输入验证” 2.应该限制重复增加,具体操作:利用网络传输以及服务器的延迟,多次单击“增加”按钮,经常在数据库发现重复提交的数据 3.当增加成功或者失败后,应该有必要的信息提示 4.文件数据的增加:有些增加包含了数据库数据的增加,和一些文件的增加,此时的数据会保存在两个地方,所以测试时,需要对相关的数据做全面的验证 5.文件数据验证:进行“输入验证”值“文件输入框输入验证”。注意:当上传的文件为中文文件名时,上传到服务器后,可能会出现乱码现象。现在一般的做法 是将原文件名替换成字母和数字的组合,以克服汉字文件名的弊端,另外,可以增加文件的安全性 5.删除操作测试用例(SC) 该用例库主要针对删除操作
  2. 选择需要删除的数据字段。有时候系统会根据ID来删除,有时候系统会根据名称来删除,测试的时候应该多注意,一般要求按照ID来删除,因为根据名称来删 除,名称可能会存在重名问题 2.应该限制重复删除。具体操作:利用网络传输以及服务器的延迟,多次单击“删除”按钮,经常在数据库中发现重复提交的数据 3.当删除的数据还有文件时,西药去验证存在数据库中的数据,以及硬盘下的文件是否都被同时删除 4.当数据被删除成功或者失败后,要有响应的信息提示 5.进行“操作验证” 6.修改操作测试用例(XG) 该用例库主要针对修改操作

1.打开需要修改的数据页面,注意与增加页面相 比,只能修改部分数值,例如关键字等是不能被修改的,并且二者数据应该是一致的 2.增加页面上的输入限制与修改页面的输入限制应该一致 3.修改成功或者失败后,应该有相应的信息提示 7.查询操作测试用例(CX) 该用例库主要针对查询操作

1.条件输入查询,先进行 条件输入框的“输入验证” 2.条件组合查询,将多个条件进行组合查询,结果可以通过数据库验证。需要注意的是,整个数据查询和条件查询数据结果条数要一致,另外,如果遇到某天的查 询时间段,有的数据库认为一天不包括零点零分,有的数据库认为包括 3.所有查询结果,必须进行一定顺序的排列,可以按照ID或按照名称来排列 4.当查询成功或者失败后,系统应给出必要的信息提示

8.翻页操作测试用例(FY) 该用例库主要针对翻页操作

1.当数据量很大的时候,需要进行分页显示,每页显示的行数最好不要超过20行,每页列表上最好有序号标识,行与行之间颜色要有一定区分,这样有利于用户的查找

2.翻页按钮应该包括:首页、前一页、后一页、尾页、当前X页、共X页,这些常用按钮和显示,并且按钮都能正常翻页

3.翻页按钮的每页显示的数据要准确,确保没有查不出来的数据,最好的做法就是和数据库结合起来验证

4.页面太多,翻页数据不能全部显示时,系统应该有完善的应对机制,比如值显示当前页的前三页和该页的后三页的页数码 5.当翻到某页时,系统应该有明显的标识,标出该页面所处的页码

9.错误页面测试(CW) 错误页面是在遇到系统异常的情况产生的友好界面

1.当系统遇到致命错误时,不能将服务器的调试信息出现在页面上,因为这样做会带来不安全,应该给出一个合适的提示信息

2.由于系统繁忙,无法及时给出正确信息时,系统可以给出友好的错误页面,如:“请用户稍后再试”等提示信息

Web测试中,各类web控件测试点总结
一 、界面检查
  进入一个页面测试,首先是检查title,页面排版,字段等,而不是马上进入文本框校验
  1、页面名称title是否正确
  2、当前位置是否可见 您的位置:xxx>xxxx
  3、文字格式统一性
  4、排版是否整齐
  5、列表项显示字段是否齐全,列表项字段名称是否跟表单统一
  6、同一页面,是否出现 字段名称相同、值取不同的问题。
  7、数据加载情况:除了文本框的值,还要注意:
  复选框,是否保存打√,或者保存不打√
  下拉框,是否保存选择的值
  多文本框,值是否都被保存,空格,换行是否保存
二、单文本框(type=text)
  边界:字段长度
  判空:是否可以为空
  唯一性:是否唯一 (小归结:边界、判空、唯一性、特殊字符、正确性)
  考虑语言,操作环境
  特殊符号测试输入:
  ' or 1<>'1   ' or '1'='1  ' or '1'<>'2  "|?><
  where a='xxx'   下划线是否允许  输入全部空格 输入 单引号
  >>
  特殊字段输入限定:
  框内容是否合法(tel,ip,url,email)序号等,直接限制输入数字,其他过滤掉
  输入金额文本框,整数首位为0,过滤掉,小数点后面,一般保留两个有效数字。
  正确性测试:(必不可少的步骤)
  1)、(字段长度输入最大允许长度时)数据允许长度的测试:
  a、页面是否被挤出的测试(都输入长英文字符串,是否断行);
  b、数据库是否允许最大字符(都输入汉字、都输入英文、混合……);
  c、最短长度的正确流程,最大长度的正确流程覆盖。
  2)、对于允许为空的字段,不填入,再次数据传递后,看是否报500错误。
  3)、未规定字段长度(或者数值大小),不按死板输入,输入非常多字符(或者非常大的数值)时,做允许动作的正确性校验,看是否报错。(要达到的结果:不管有没有长度限制(没有给最长、最大限制让你去测?),最终页面不能抛数据库异常。)monkeytest
  说明:通过不断输入长字符串,看是否有长度校验;
  最终都会出现以下两种情况的一种:
  A、页面(前台)有校验长度、大小; 或者
  B、无校验,数据库报错。
  所以: 所有字段都要做长度、大小限制(不管需求有没有给出明确要求,不管测试颗粒度,都要限制长度,不允许报数据库错误,都要测!!!)。最大长度限制可限定方法:1、不允许再输入;2、自动截断处理,并且给用户提示。
关于长度概念:
  1、 数据库规定的字节长度A
  2、 页面上可以输入的字符数B
  控制方法:
  1)、页面上,不管输入什么字符(全角如汉字、半角如字母),统一规定不能超过B个字符,此种限制,
  测试点:全部输入全角B个,测试(B*3字节)会不会超过数据库字节长度
  全部输入半角B个,测试(B*1字节)会不会超过数据库字节长度
  混合输入全角X半角Y,测试(X*3+Y字节)会不会超过数据库长度
  2)、页面上,不以字符统计,以总的输入字节数统计,比如,全部输入全角字符,允许可以输入A/3个字符,全部输入半角字符,允许输入A个字符( 民生网的设计)
  测试点:全部输入全角,看是否允许输入A/3个字符
  全部输入半角,看是否允许输入A个字符
  混合输入全角X,半角Y,看是否允许X*3+Y=A
  (5个:判空、唯一、边界值、特殊字符、正确流程(多种数据、多种分支))
  +测试校验位置:ajax鼠标事件校验、前台提交按钮js校验,服务器拿到数据后再次验证
  三、多文本框(type=textarea)
  1)、空格和换行的问题,看需求,是否需要做支持HTML Encoding
  输入全部空格时,是否判空处理?””空格, 。
  输入折行,是否也显示折行?
  比如:列点说明原因,就需要支持。
  2)、字母截断的问题
  对于一串字母,开发人员往往会忘掉做截断,这样如果展示在我们的平台上的话,这一串字母就会把我们的UI撑开
  3)、长度控制格式, 您还可以输入*个字符
  四、添加按钮
  添加动作检查范围:
  失败:是否提示
  提示内容是否正确
  失败时:保存用户已输入的内容,避免重新再输入
  成功:对话框消失
  记录是否可直接查看(还需要刷新?)
  列表记录顺序
  重复提交情况,点击一次后,是否变成disable
  上传附件的添加:
  A. 文件名称:文件名称很长;文件名称字符多样化(汉字,英文,符号);文件名称重复。
  B. 判空?
  C. 附件格式类型支持?
  D. 附件个数?
  E. 附件空间大小。
五、移除按钮
  1.一般都要在前台先给出一个提示操作“确定移除该……”
  2.相关联的东西,是否需要限制移除“该类型下存在应用,无法移除”有到后台比较
  3.确定后,真正执行移除操作。
  结果:
  移除后,列表数据是否立即消失。
  必须有确认删除的提示信息
  六、列表
  1)、列表记录顺序
  2)、是否需要翻页、有没有翻页功能
  3)、字段名称是否与表单一致

  七、搜索-文本框
  1、功能点、需求点考虑:
  是否提供模糊查询、输入数值有种类有限定时,是否考虑换成下拉框搜索;
  2、检查点:
  文本框值是否消失(是否回填条件值),再次点击“查询”可查看所有记录;
  考虑搜索结果:是否存在分页,分页是否正常;是否有序;
  注意:分页是否仍保存查询条件,检查后面的记录是否符合条件
  3、查询数据多样性:
  输入不存在的字段值测试、包括特殊字符查询测试例如:' or '1'='1;
  输入类似程序语句的条件时是否执行查询,如:XXXX”、XXX and ;
  4、操作类型:
  1) 不输入的查询
  2) 输入全部空格的查询
  3) 模糊查询(输入部分字段,或者说,输入英文字母,查询到相关中文数据)
  4) 输入不存在的查询
  5) 输入存在的查询
  6) 单个查询和多个条件复合查询。
  八、搜索-下拉框
  检查点:
  a) 搜索结果是否有序;
  b) 下拉框值是否齐全;(下拉框值本身也是一个动态查询的结果)
  c) 下拉框值是否自动消失,再次点击“查询”可查看所有记录(是否要回填条件值);
  d) 分页时,是否保存搜索条件。
  (从UI、开发、业务逻辑、用户使用等角度测试)
  PS:
  以上总结的, 是比较纯粹的从页面控件角度测试点出发, 对于完整测试一个整体页面,需要各类测试有机结合起来:
  1)UI测试:
  页面布局; 页面样式检查;控件长度是否够长;显示时,是否会被截断;支持的快捷键,Tab键切换焦点顺序正确性等。
  2)功能测试:页面上各类控件的测试范围,测试点,可参考上方
  结合控件的实际作用来补充检查点: 比如, 密码框是否*显示, 输入是否做trim处理等
  3)安全测试:输入特殊字符,sql注入,脚本注入测试
  后台验证测试,对于较重要的表单 ,绕过js检验后台是否验证
  数据传输是否加密处理,比如, 直接请求转发,地址栏直接显示发送字符串?
  数据库存储,特别密码等,是否加密形式存储
  4)兼容性测试
  5)性能测试

二.常见功能点测试思路
根据经验,总结常见的功能点的测试思路:
  1. 新增 或 创建(Add or Create)
  .1 操作后的页面指向
  .2 操作后所有绑定此数据源的控件数据更新,常见的排列顺序为栈Stack类型,后进先出
  .3 取消操作是否成功
  2.编辑 或 更新 (Edit or Update)
  .1 操作后的页面指向
  .2 操作后所有绑定此数据源的控件数据更新
  .3 取消操作是否成功
  .4 编辑界面是否读取出正确、全部的数据源
  .5 记录在工作流中的编辑功能可用性
  .6 操作成功的生效时刻及生效范围
  3.删除 或 移除 (Delete or Remove)
  .1 操作后的页面指向
  .2 操作后所有绑定此数据源的控件数据更新 (如下就是删除后,Tab数据没有立即刷新的bug)
3 取消操作是否成功
  .4 记录在工作流中的编辑功能可用性
  .5 操作成功的生效时刻及生效范围(比如:购物网站,店家商品下架后,并没有同时删除买家的购买记录)
  4.选中 或 全选 (Check or Check all)
  .1 多页面中,全选对所有页面是否有效
  .2 支持多页面的个别选中,且返回查看时保留选中状态
  .3 界面上的按钮的操作范围是否均受选中功能控制
  .4 前一页选中状态,在翻页后,应保留原来状态
  .5 先全选-》移除某个单选-》全选按钮是否移除选中状态

谈谈性能测试分类
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试,两者可以结合进行。通过负载测试,确定在各种工作负载下系统的性能,目标是测试当负载逐渐增加时,系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点,来获得系统能提供的最大服务级别的测试。
  验收性能测试(狭义)   性能测试方法是通过模拟生产运行的业务压力量和使用场景组合,测试系统的性能是否满足生产性能要求。通俗地说,这种方法就是要在特定的运行条件下验证系统的能力状态。
  特点: 1、这种方法的主要目的是验证系统是否有系统宣称具有的能力。 2、这种方法要事先了解被测试系统经典场景,并具有确定的性能目标。 3、这种方法要求在已经确定的环境下运行。 也就是说,这种方法是对系统性能已经有了解的前提,并对需求有明确的目标,并在已经确定的环境下进行的。
  负载测试(Load Test)通过在被测系统上不断加压,直到性能指标达到极限(例如“响应时间”)超过预定指标或都某种资源已经达到饱和状态。
  特点: 1、这种性能测试方法的主要目的是找到系统处理能力的极限。 2、这种性能测试方法需要在给定的测试环境下进行,通常也需要考虑被测试系统的业务压力量和典型场景、使得测试结果具有业务上的意义。 3、这种性能测试方法一般用来了解系统的性能容量,或是配合性能调优来使用。 也就是说,这种方法是对一个系统持续不段的加压,看你在什么时候已经超出“我的要求”或系统崩溃。

  压力测试(强度测试)(Stress Test)压力测试方法测试系统在一定饱和状态下,例如cpu、内存在饱和使用情况下,系统能够处理的会话能力,以及系统是否会出现错误
  特点: 1、这种性能测试方法的主要目的是检查系统处于压力性能下时应用的表现。 2、这种性能测试一般通过模拟负载等方法,使得系统的资源使用达到较高的水平。 3、这种性能测试方法一般用于测试系统的稳定性。 也就是说,这种测试是让系统处在很大强度的压力之下,看系统是否稳定,哪里会出问题。
  并发测试(Concurrency Testing)并发测试方法通过模拟用户并发访问,测试多用户并发访问同一个应用、同一个模块或者数据记录时是否存在死锁或其者他性能问题。
  特点: 1、这种性能测试方法的主要目的是发现系统中可能隐藏的并发访问时的问题。 2、这种性能测试方法主要关注系统可能存在的并发问题,例如系统中的内存泄漏、线程锁和资源争用方面的问题。 3、这种性能测试方法可以在开发的各个阶段使用需要相关的测试工具的配合和支持。 也就是说,这种测试关注点是多个用户同时(并发)对一个模块或操作进行加压。
  配置测试(Configuration Testing)配置测试方法通过对被测系统的软硬件环境的调整,了解各种不同对系统的性能影响的程度,从而找到系统各项资源的最优分配原则。
  特点: 1、这种性能测试方法的主要目的是了解各种不同因素对系统性能影响的程度,从而判断出最值得进行的调优操作。 2、这种性能测试方法一般在对系统性能状况有初步了解后进行。 3、这种性能测试方法一般用于性能调优和规划能力。 也就是说,这种测试关注点是“微调”,通过对软硬件的不段调整,找出这他们的最佳状态,使系统达到一个最强的状态。
  可靠性测试通过给系统加载一定业务压力(例如资源在70%-90%的使用率),使系统运行一段时间,以此检测系统是否稳定运行。
  特点: 1、这种性能测试方法的主要目的是验证是否支持长期稳定的运行。 2、这种性能测试方法需要在压力下持续一段时间的运行。(2~3天) 3、测试过程中需要关注系统的运行状况。 如果测试过程中发现,随着时间的推移,响应时间有明显的变化,或是系统资源使用率有明显波动,都可能是系统不稳定的征兆。 也就是说,这种测试的关注点是“稳定”,不需要给系统太大的压力,只要系统能够长期处于一个稳定的状态。
  失效恢复测试如果系统局部发生故障,用户是否能够继续使用系统,以及如果这种情况发生,用户将受到多大程度的影响。
  特点: 1.这种性能测试方法的主要目的是验证在局部故障情况下,系统能否继续使用。 2.这种性能测试方法还需要指出,当问题发生时,“能支持多少用户访问”的结论和“采取何种应急措施”的方案。 3.一般来说,只有对系统持续运行指标有明确要求的系统才需要进行这种类型的测试。
  大数据量测试针对某些系统存储、传输、统计查询等业务进行大数据量的测试。
  疲劳强度测试主要特点是长时间对目标测试系统加压,目的是测试系统的稳定性,持续时间一般在1小时以上;感觉等同于可靠性测试。
  注意:在做性能测试时请忘掉分类.例如,运行8个小时来测试系统是否可靠,而这个测试极有可能包含了可靠性能测、强度测试、并发测试、负载测试,等等。因此,在实施性能测试时决不能割裂它们的内部联系去进行,而应该分析它们之间的关系,以一种高效率的方式来设计性能测试。

Web测试中的几个case
一、页面上对引起 大量数据提交的 按钮/链接 点击一次后, disable
  需求:
  对于重要的表单、数量庞大/响应慢的系统,在做提交时, 又有页面还在loading状态, 此时连续做两次点击, 经常引起各种报错,这种情况下, 需要提出 对 按钮/链接 点击一次后, 做 disable
  测试:
  1)、查看页面源代码是否有脚本控制,例如:
Next
function buttonDisable(){
$("#nextButton").attr("disabled", "disabled");
}
2)、对脚本进行调试,
  可以借助firebug工具,在Script Tab上,在$("#nextButton").attr("disabled", "disabled");这行脚本设置disable, 点击nextButton,检查运行到断点处停止,按钮无法再次点击。运行断点后, disable解除。
  二、新增数据库字段测试需要考虑的几个点
  1)、从数据库检查起, 检查相关表: 原表、历史表、与其同步库的表 有没有都添上该字段,并且注意在每个表中, 字段类型是否统一
  2)、校验:考虑字段本身类型, 判空、边界、唯一性、特殊字符、正确性允许的data
  特别, 在做判空时,若字段不允许为空时,考虑: 需要提交脚本初始化历史数据set dafault value
  3)、流程覆盖:考虑该字段覆盖到哪几个相关页面, 测试到整个流程, 每个页面校验要一致;
  三、查log测试的几个操作
  一般情况下, 项目都部署在linux环境上, 测试时, 有些需要查log, 或者有些服务需要自己去重启, 此时就需要一些基本的linux操作命令:
  1)、首先连接到linux系统的机器上,可以使用putty软件, 要有 服务器地址+端口+协议 loginName+password,就可以登录
  2)、cd到脚本或者log放置的文件夹位置去重启服务或查看log,还有一些常用的命令
  less 文件名(W向上翻页、F向下翻页,Shift+F自动翻页,Ctrl+C停止自动翻页);
  grep "findString" 文件名;
  执行脚本: ../脚本名 或者 sh./脚本名

web常见安全问题以及测试方法
Web安全是我们测试组一直以来作为和性能测试并驾齐驱的两个重点。开发的过程中还需要着重注意,该转义的地方转义;该屏蔽的地方屏蔽,该过滤的地方过滤等等。年底又到了,势必又有大批的发号抽奖之类的活动开发、上线,在这个过程中,安全问题是我们每个人应该紧绷的神经,对于我们测试人员来说,每个活动需要做到手动安全测试加自动化安全测试相结合。
  常见的web安全问题有:
  SQL注入、跨站点脚本攻击、跨站点伪造请求、目录遍历、邮件表头注入、页面错误信息等。
  对于手动安全测试来说,一般常用的有三点:
  1、URL有参数的,手动修改参数,看是否得到其他用户的信息和相关页面;
  2、在登录输入框的地方输入‘ or 1=1--或 “ or 1=1--等看是否有SQL注入;
  3、在注重SQL注入的同时,一般在有输入框的地方输入
  对于自动化安全测试来说:
  测试组目前使用的安全测试工具为IBM的AppScan(当然,是破解版,34上已经放过该工具的安装包)
  1、在使用之前务必确认自己绑定的Host;
  2、配置URL、开发环境、错误显示类型;
  3、结果保存后可根据提示的问题类型和解决建议进行分析。
  Web安全测试通常要考虑的测试点:
  1、输入的数据没有进行有效的控制和验证
  2、用户名和密码
  3、直接输入需要权限的网页地址可以访问
  4、认证和会话数据作为GET的一部分来发送
  5、隐藏域与CGI参数
  6、上传文件没有限制
  7、把数据验证寄希望于客户端的验证
  8、跨站脚本(XSS)
  9、注入式漏洞(SQL注入)
  10、不恰当的异常处理
  11、不安全的存储
  12、不安全的配置管理
  13、传输中的密码没有加密
  14、弱密码,默认密码
  15、缓冲区溢出
  16、拒绝服务
SQL注入:
所谓SQL注入,就是通过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串,最终达到欺骗服务器执行恶意的SQL命令,比如先前的很多影视网站泄露VIP会员密码大多就是通过WEB表单递交查询字符暴出的,这类表单特别容易受到SQL注入式攻击.(
(select * form 表 where id=1 or 1
1 or 1是输入框输入的
这样会导致满足 id=1 或 1 的数据都查出来
而所有的数据都满足 1
这样就查出来了很多不该被查出来的数据
这就是sql注入)

网友评论

登录后评论
0/500
评论
浮生递归
+ 关注