Web测试中,各类web控件测试点总结（推荐）

第一篇：Web测试中,各类web控件测试点总结（推荐）

Web测试中，各类web控件测试点总结

一、界面检查

进入一个页面测试，首先是检查title，页面排版，字段等，而不是马上进入文本框校验

1、页面名称title是否正确

2、当前位置是否可见您的位置：xxx>xxxx3、文字格式统一性

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）、未规定字段长度（或者数值大小），不按死板输入，输入非常多字符（或者非常大的数值）时，做允许动作的正确性校验，看是否报错。(要达到的结果：不管有没有长度限制(没有给最长、最大限制让你去测？)，最终页面不能抛数据库异常。)monkey test

说明：通过不断输入长字符串，看是否有长度校验；最终都会出现以下两种情况的一种：

A、页面(前台)有校验长度、大小；或者

B、无校验，数据库报错。

所以： 所有字段都要做长度、大小限制(不管需求有没有给出明确要求，不管测试颗粒度，都要限制长度，不允许报数据库错误，都要测！！)。最大长度限制可限定方法：

1、不允许再输入；

2、自动截断处理，并且给用户提示

关于长度概念：

1、数据库规定的字节长度A2、页面上可以输入的字符数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）性能测试

第二篇：WEB测试总结

WEB测试总结(架构,设计)精华部分

1、总计架构测试

1）瘦客户端，业务逻辑规则多数在服务器端执行。如新闻站点、门户网站、信息发布网站等。

2）胖客户端，安全性要求较高、交互操作频繁、业务逻辑复杂。银行系统、网络游戏、网上办公系统等。

2、Web架构组成部分是否满足需求

成本、功能、安全性要求、容量要求、传输实时性。

3、服务器配置分布是否满足要求

Web服务器、应用服务器、数据库服务器可以分布在不同物理机器上也可以分布相同的物理机器上，一般优先考虑独立数据库服务器，Web服务器、应用服务器可以在相同的机器上。

4、客户端设计测试

1）功能设置测试：信息服务、办公自动化、Internet支持； 2）信息组织结构测试：线性结构、分层结构、非线性结构； 3）页面设计测试：a.页面一致性测试

b.用户界面友好性及导航直观性测试；、c.是否适合多种浏览器； d.页文件的命名； e.页面布局技术。

5、服务器端设计测试

1）容量规划测试：点击率、延迟和流量、服务器资源；

2）系统安全测试：a.常识性安全策略，取消不必要的协议、控制写权限、取消服务器目录浏览属性、记录日志等； b.使用加密技术；

c.构造防火墙，网络级、应用级、电路级； d.构建网络防毒体系。3）数据库设计测试。

6、Web开发测试

1）源代码分析，主要是使用检查工具来完成； 2）链接测试，主要借助工具来完成； 3）框架测试：a.自动调整窗口大小； b.是否提供滚动条；

c.打开新页面是否正常。4)表格测试，随窗体变化自动调整大小； 5）图形测试：a.颜色饱和度及对比度； b.链接标识；

c.图形显示是否正确。

1、与一般应用软件相比，Web测试有以下区别：

第一、Web测试的侧重点是性能、安全、易用性、兼容

第二、测试工具有所不同，如链接测试、表单测试、界面测试

2、功能测试

一、客户端的选择，优先测试流行的客户客户端；

二、客户端浏览器的配置

三、客户端的显示设置

四、内容测试

3、链接测试

一、该链接将用户带到它所说明的地方

二、被链接的页面是存在的

三、保证没有孤立页面

工具有WEBCHECK、LINKBOT、TESTPARTNER、XENU等

4、链接测试工具的优势：

一、简单易用

二、在实现上采用多线程技术，检查速度特别快；

三、对断开的链接可以再次测试，可以避免误判；

四、没有检查链接的数量限制，只受系统资源的约束；

五、可以分析Web应用的结构；

六、检查结果可以分类查看，自动生成HTML格式的报告；

5、Web应用链接主要测试点如下

一、测试内部链接和外部链接中成功和失败的链接点，以及应用中不被其他链接调用的页面；

二、测试链接中新网页、老网页、慢网页以及丢失的图象标题标签和属性标签等；

三、分析Web应用的结构是否合理，包括显示和某个URL相关的链接以及按照标题、描述、作者、大小、最后修改时间、类型为URL链接分类等。

6、易用性测试

易用性测试要考虑以下几个方面： 1）用户的计算机使用经验；

2）用户对浏览器以及Web的使用经验； 3）用户的业务专业知识。

7、Web系统的易用性测试分为三个方面： 1）界面测试

2）辅助功能测试 3）图形测试

一、界面测试要考虑以下几个问题 A．WEB应用系统的最终用户群是谁？ B．WEB应用界面的设计策略是什么？ C．页面中各元素布局的协调性 a.各元素位置的协调性 b.各元素颜色的协调性

c.各元素大小比例的协调性 D．不同页面风格的统一性

E．用户在界面中操作的便利性 F．界面动态操作测试

a.屏幕分辩率设置的影响

b.浏览窗口最大化/最小化的影响 c.选定目标元素的置中与缩放

二、辅助功能测试 A．使用说明，这个没有多大意义，WEB网页按F1弹出来的页面都是IE的帮助页面，除非有特定的帮助说明内容； B．导航功能 C．站点地图

D．帮助，这个没有多大意义，WEB网页按F1弹出来的页面都是IE的帮助页面，除非有特定的帮助说明内容；

第三篇：web测试心得

做电子商务网站测试已经一个月了，这一个月基本上是熟悉网站产品和流程的一个过程，对网站的各个部分基本上都进行了一次测试，感觉电子商务网站主要注意以下几点：

1、注册和登录模块的测试

在测试该部分时，给我印象最深的就是：

1)注册成功，但登陆失败：注册时，密码设置为一些特殊的符号，比如：空格、%等，但登录时，失败。

后来经开发人反映出现这样的问题，原因是：在登录模块，对密码设置了一些限定。

2)登录时，没区分大小写，就是说，用小写字母注册的，登录时，用相应的大写字母登录也能成功。

出现问题的原因：登录时，没用MD5加密进行验证

2、购物车的测试

1)测试产品能否放入购物车中

2)当某种产品有购物数量限制时，超过这一数值，能否也能放入购物车中

3)购物车中的购物限制是否正确

3、支付流程测试

1)购物车中的产品能否正常支付

2)当支付完成，不等页面跳转，直接关闭浏览器，数据传递是否正确

3)当支付完成，等待页面跳转，跳转到得页面是否正确

4、网站某个模块间的数据传递是否正确

当网站某个模块涉及的数据传递比较多而且比较复杂时，一定要搞清楚数据是怎么传递的，因为这是最容易出现bug的地方。比如：下拉菜单的数据没有传递过来，或传递过来了，但不正确，这时就要静下心来，慢慢滤清思考，耐心去测试。

最后一点就是，在购买的过程中，也要考虑到并发，比如，当某种产品只剩一件了，这时两个用户或更多同时并发点击该产品，放入购物车中，那么在多个用户同时点击这个只剩一件的产品时，系统是否有相应的提示，或是，该产品能否都放入不同用户的购物车中，我上周测试的过程中，该问题是存在的，等待明天程序的解答和修改。

第四篇：Web测试工具小结

Web测试工具小结

单元测试方面：（对开发人员比较有用）J-Unit工具。

功能测试方面：E-test是个不错的选择，功能很强大，由于不是采用Post URL的方式回放脚本，所以可以支持多内码的测试数据（当然要程序支持）。基本上可以应付大部分的Web Site。

如果只是利用脚本回放代替手工劳动，或者做对页面响应数的性能测试，Microsoft Web Application Stress Tool是个不错的选择。

另外，在性能测试方面，PureLoad也是一个不错的工具，完全用Java写成，可以测试各种C/S程序，如SMTP Server等。这两个工具都是使用Post URL的方法测试Web Application的。对大量使用JavaScript的页面不太适合。当然，如果程序在Unix，linux下面运行的话，可以直接编写Shell脚本程序，更加方便。

另外，还有很多专门的工具，比如说Linkbot是专门作页面链接测试的。

另外，测试流程管理工具也有不少，个人用过也一直在用的是Test Plan Control，短小精悍，不错。

至于WinRunner和LoadRunner之类，因为没有License，所以都没怎么用过，惭愧。不过我看过一篇英国人评价英国测试市场上最流行的五个软件的文章。WinRunner得分最高。

测试工具从测试的方法上可以分为两种：白盒测试和黑盒测试

白盒测试工具主要有：

内存资源泄漏检查：Numega中的bouncechecker,Rational的Purify等

代码覆盖率检查：Numega中的truecoverage,Rational的Purecoverage，Telelogic公司的logiscope, Macabe公司的Macabe等

代码性能检查：Numega中的truetime,Rational的Quantify等

代码静态度量分析质量检查工具：logiscope和Macabe等

黑盒测试工具主要有：

客户端功能测试：MI公司的winrunner,compuware的qarun,Rational的SQA robot等等

服务器端压力性能测试： MI公司的winload,compuware的qaload,Rational的SQA load等等

Web测试工具：MI公司的Astra系列，rsw公司的e-test suite等等

测试管理工具：rational的test manager,compuware的qadirector等等，此外还有缺陷跟踪工具 trackrecord等。

数据库测试工具:TestBytes

黑盒测试工具：QACenter、SQATeamTest，Rational Viaual Test。

回归测试工具：Rational TeamTest，WinRunner（MI公司）

WEB系统测试工具：TEST，Workberch，Web Appication Stress Tool（WAS）

白盒测试工具：Numega、PuRe、软件纠错工具（Rational Purity）。

嵌入式测试工具：Logiscope（静态测试工具）、CodeTest。

系统负荷测试工具：RationalPerformance

涵盖测试工具范围评估工具

软件性能测试工具：LoadRunner（MI产品）、Rational Visual Qantify

测试管理工具：TestDirector（MI产品支持整个生命周期中测试流程管理）

第五篇：WEB软件测试总结报告

XXX管理平台

XXX项目测试总结报告

目录

1.项目测试结果........................................................................................................................2 1.1 BUG严重程度................................................................................................................2 1.2 BUG问题分布状况........................................................................................................3 2.测试结论................................................................................................................................4 2.1界面测试.........................................................................................................................4 2.2功能测试.........................................................................................................................4 2.3兼容性测试.....................................................................................................................4 2.4易用性.............................................................................................................................4 2.5 负载/压力测试...............................................................................................................5 3.软件问题总结与分析............................................................................................................6 4.建议........................................................................................................................................7

XXX管理平台

1.项目测试结果

1.1 BUG严重程度

测试发现的bug主要集中在次要功能和轻微，属于一般性的缺陷，但测试的时候出现了37个主逻辑级别的bug,以及严重级别的2个.XXX管理平台

1.2 BUG问题分布状况

由上图可以看出，主要为代码错误占36%,以及标准规范的问题占35%,界面优化占17%,设计缺陷占9%,其他占2%

XXX管理平台

2.测试结论

2.1界面测试

网站系统实现与设计稿一致。站点的导航条位置，导航的内容布局，首页呈现的样式与需求一致。网站的界面符合标准和规范，直观性强。

2.2功能测试

分不同账号 总权限账号,以及店长账号分别进行功能测试。1:链接测试无问题,不存在死链接,测试链接都存在.2:对页面各个不同数据的测试,主要的出入库,销售报表,订单查看管理等一一对应,不存在数据有误差的问题.2.3兼容性测试(Windows下)测试总的浏览器包括:360极速浏览器,火狐浏览器,谷歌浏览器,IE浏览器,测试通过,主要逻辑以及次要功能都没问题,因为浏览器的不同,导致界面浏览不一定相同,例如有的界面浏览页面显示正常,有的界面显示不一样。

2.4易用性

网站实现了如下易用性： 1.输入限制的正确性

2.输入限制提示信息的正确性，可理解性，一致性 3.界面排版美观

4.web应用系统易于导航，直观

5.web应用系统的页面结构、导航、菜单、连接的风格一致

XXX管理平台

2.5 负载/压力测试

主要测试了压了测试: 测试

结

果

60秒内发请求,一次1000个请求,总共请求了2230个请求,成功了2208个失败两个 1:每个请求用时30ms(吞吐量)2:服务器收到请求，响应页面要花费的时间:332ms 3: 并发的每个请求平均消耗时间 :33.ms 4:请求一共花了:72s

XXX管理平台

第一个1000个人同时发出1000个请求 总共1004个请求失败4个,成功1000 1:每个请求用时9ms(吞吐量)2:服务器收到请求，响应页面要花费的时间:109128ms 3: 并发的每个请求平均消耗时间 :109.ms 4:请求一共花了:109s

1:如上图当同时在线人数达到45时候,服务器崩溃,导致成功率一直下降到达40%,直到结束总请求达到:26796.平均每个请求响应时间为281ms,系统吞吐量(tps)20.89/s.因为系统被困导致数据反映不准.3.软件问题总结与分析

从测试过程中发现bug的严重程度与分布状况来看，引起缺陷主要有以下几方面：

1.没有需求文档

需求文档只是个大纲的形式，没有详细的需求文档。没有相应的输入输出字段限制及统一的字段名称，使得开发人员根据需求进行设计时，没有考虑相关功能的关联性。在没有详细需求的指引下，开发人员根据自己的经验进行设计，负着不同模块开发的人员没有统一设计。在测试过程中，需求相关联的问题表现出来，及风格统一的问题。例外没有需求文档导致测试,无法根据需求文档来进行用例的设计,只有靠自己自己测试经验来测试排除BUG.2.功能性错误

在测试的过程中，部分功能没有现实，导致部分模块无法进行功能的测试。功能实现错误，在功能模块的开发时，是进行先开发后调整的策略，没有具体的需求文档，部分模块的功能实现有所偏差。

3.页面设计易用性缺陷 页面输入字段限制不统一，系统中多个页面存在相同的字段，但用户输入相

XXX管理平台

同的数据，提示输入的限制不相同，没有统一输入字段的限制。

提示信息错误，不同模块相同结果的提示信息不一致，用户操作后，相应的提示信息不明确，引起用户误解。

提示信息一致性，用户在不同页面执行相同的操作，提示信息不同。4.开发人员疏忽引起的缺陷

网站在开发的过程中，不断的追加新需求，或调整。开发人员修复或修改问题时，有时疏忽没对相关联的地址进行修改验证。导致因修改修复问题而引入更多的问题。

5.开发版本的控制

在测试一个版本(代理商版)，发现问题重复出现，还会引入新的bug,开发人员修改的问题时，提交的版本相互覆盖。引起上一个版本已关闭的问题，在下一版本重复出现。

4.建议

在项目开始的时候，应该制定相应的标准，编码标准，需求变更标准等，开发和测试人员严格按照标准进行，可以在后期减少因为开发，测试不一致而导致的问题，同时可以降低沟通成本。

发布版本的时候，正确布置测试环境，减少因为测试环境，测试数据库数据的问题而出现的无效bug。

开发人员解决bug的时候，填写bug原因以及解决方式，方便bug的跟踪。开发人员在开发版本上发现bug，可以通知测试人员，因为开发人员发现的bug很有可能在测试版本上出现，而测试人员和开发人员的思路不同，有可能测试人员没有发现该bug，而且，这样可以保证发现的bug都能够被跟踪。

做好版本的控制，从开发版本，测试版本做好每个环节的版本控制。