当前位置：文档之家 › 功能及UI测试标准

功能及UI测试标准

  • 格式：doc
  • 大小：148.00 KB
  • 文档页数：10

常用功能及UI测试标准2017年3月1.版本变更记录目录1 概述错误!未定义书签。

2 测试点错误!未定义书签。

重复提交问题错误!未定义书签。

弹出框提示信息问题错误!未定义书签。

验证提示信息问题错误!未定义书签。

常用的键盘命令错误!未定义书签。

翻页功能错误!未定义书签。

查询功能错误!未定义书签。

注销功能错误!未定义书签。

上传功能错误!未定义书签。

下载功能错误!未定义书签。

3 GUI图形用户界面错误!未定义书签。

4 UI控件错误!未定义书签。

5 补充错误!未定义书签。

流程测试错误!未定义书签。

兼容性测试错误!未定义书签。

链接测试错误!未定义书签。

易用性测试错误!未定义书签。

性能测试指标规范错误!未定义书签。

概述为了减少测试过程中的漏测等情况以及避免各种不必要的争议，所以制定这样一个标准来对测试进行规范和约束，以后测试人员在测试的时候按照该规范中列出的测试点进行测试。

下面将会对一些比较常见的测试点和以往测试中有争议的问题、在需求规格说明书中客户又没有明确要求的功能点及UI进行描述，同时，也会对相应的BUG级别进行说明(特殊情况另行考虑)，可能会不太全面，以后在测试过程中会慢慢积累和完善。

测试点重复提交问题测试时如果存在重复提交问题，作为BUG；缺陷严重级别定义为：一般(如果一直进行重复提交造成系统连接中断、系统崩溃等，严重级别定义为：致命)；1、在进行添加或修改数据操作时要考虑到重复提交问题的测试；2、测试方法：功能按钮(如：提交按钮)反应时间延迟时（限制客户端网络带宽等方式来模拟实现），在短时间内重复点击该功能键，容易出现重复提交问题；提交之后紧接着按F5或点击IE上的刷新按钮或者点击IE后退按钮之后再重新提交，进行刷新页面操作，容易出现重复提交问题；弹出框提示信息问题以下几种情况如果没有提示信息，一定作为BUG：对于用户来说非常重要的信息在进行删除操作时没有提示信息提示用户否要删除；缺陷严重级别定义为：一般；与其它信息有关联的信息在进行删除操作时没有提示信息；缺陷严重级别定义为：一般；在操作之后页面没有任何变化(用户体验方面)，也没有提示信息；缺陷严重级别定义为：严重或一般(功能没有实现的缺陷严重级别定义为：严重，功能实现的缺陷严重级别定义为：一般)；弹出框提示信息内容错误；缺陷严重级别定义为：一般；登录失败没有提示信息；缺陷严重级别定义为：一般；1、在进行添加、修改和删除数据的操作时都应该考虑到提示信息问题的测试；2、测试方法：对功能按钮进行操作，查看相应的提示信息；验证提示信息问题见，结合控件一起说明常用的键盘命令以下几种情况没有键盘命令，一定作为BUG：缺陷严重级别定义为：一般；目前主要考虑的常用的键盘命令如下：Tab键Enter键翻页功能常见功能点：首页、上一页、下一页、尾页总页数、当前页数指定每页显示条数指定跳转页还有一种分页：少于多少页的时候全部以数字的形式显示，达到多少页的时候显示下一页要考虑的测试点如下：整个系统的分页风格要是一致的；如果不一致，作为BUG；缺陷严重级别定义为：一般；无数据和有数据时，总页数、当前页数显示要是正确合理的；如果不正确不合理，作为BUG；缺陷严重级别定义为：微小；在指定跳转页的文本框中输入数字(存在的页码和不存在的页码)、字母、特殊字符，系统做了处理并且处理是正确合理的；输入存在的页码，要能正确跳转到指定的页；如果不能跳转到指定页或者跳转报错，作为BUG；缺陷严重级别定义为：严重；输入不存在的页码(也要考虑超长字符)，系统要做处理(如：默认跳转到首页或当前页)；如果没有做处理的可以跳转到不存在的页，作为BUG；缺陷严重级别定义为：一般(如果报错，缺陷严重级别定义为：严重)；输入字母、特殊字符，系统要做处理(如：默认跳转到首页或当前页)；如果没有做处理，作为BUG；缺陷严重级别定义为：一般(如果报错，缺陷严重级别定义为：严重)；指定每页显示条数时，列表中显示的数据条数要和指定显示的条数一致；如果指定的条数和显示的不一致，作为BUG；缺陷严重级别定义为：一般；处于第一页时，首页、上一页按钮不可用；如果可用，作为BUG；缺陷严重级别定义为：一般(如果报错，缺陷严重级别定义为：严重)；处于最后一页，尾页、下一页按钮不可用；如果可用，作为BUG；缺陷严重级别定义为：一般(如果报错，缺陷严重级别定义为：严重)；多页情况下，中间页的首页、上一页、下一页、尾页按钮可用；对查询出来的结果，点击分页按钮时，不能影响查询结果(如：点击分页之后，数据又显示的是全部数据了，而不是先前查询出来的数据)；如果影响了查询结果，作为BUG；缺陷严重级别定义为：严重；查询功能考虑的测试点如下：输入的查询条件为数据库中存在的数据，能够查询出来；如果不能查询出来，作为BUG；缺陷严重级别定义为：严重；输入格式或范围不符合的数据(如果是文本输入框也要考虑超长字符)作为查询条件，给出提示或者列表中显示为空；如果没有提示或列表显示不为空或报错，作为BUG；缺陷严重级别定义为：一般(报错的，缺陷严重级别定义为：严重)；输入数据库中不存在的，但是格式和范围都是符合要求的查询条件，列表中显示为空；如果列表中有数据，作为BUG；缺陷严重级别定义为：严重；注：对于模糊查询，比较有争议的是：是否过滤空格；如果模糊查询没有过滤空格，作为BUG；缺陷严重级别定义为：一般；注销功能要考虑的测试点如下:点击注销按钮，返回到登录页面；如果不能返回到登陆页面的，作为BUG；缺陷严重级别定义为：严重；复制页面URL地址，注销后，通过该地址再尝试访问，此时不能访问应该跳转到登陆页面；如果可以访问或报错，作为BUG；缺陷严重级别定义为：严重；注销后，点击后退按钮，不能继续操作；如果可以继续操作，作为BUG；缺陷严重级别定义为：严重；上传功能要考虑的测试点如下：没有选择上传资料时，点上传按钮要有提示信息；如果没有提示信息，作为BUG；缺陷严重级别定义为：一般；上传格式、大小符合要求的文件或图片，可以上传成功；如果不能上传成功，最为BUG；缺陷严重级别定义为：严重；上传格式或大小不符合要求的文件或图片，有提示信息不能上传，并且不能上传成功；如果没有提示信息或上传成功的，作为BUG；缺陷严重级别定义为：严重；正在使用的文件不能上传；如果支持批量上传，批量上传的资料的数量是否有限制，如果超出限制要有提示信息；如果没有提示信息或超过限制都上传成功，作为BUG；缺陷严重级别定义为：一般；如果支持批量上传，上传资料数量在限制范围内，都要上传成功；如果没有全部上传成功，有漏掉的或只第一个上传成功的，作为BUG；缺陷严重级别定义为：严重；上传成功之后显示的文件名中不能有乱码；如果有乱码，作为BUG；缺陷严重级别定义为：严重；下载功能要考虑的测试点如下：点击下载按钮，能弹出下载页面；如果不能弹出下载页面，作为BUG；缺陷严重级别定义为：严重；下载弹出框中的文件名等显示正常；如果显示不正常，如：显示乱码，作为BUG；缺陷严重级别定义为：一般；下载下来的文件名要和目标文件名一致；如果不一致，作为BUG；缺陷严重级别定义为：一般；打开下载的文件，内容显示正确，没有乱码或内容丢失(如：应该是2KB，下载下来的是1KB)；如果有乱码或内容丢失，作为BUG；缺陷严重级别定义为：严重；GUI图形用户界面1、整个系统页面标签风格要一致；如果不一致，作为BUG；缺陷严重级别定义为：一般；2、文字方面：标题等对客户来说很重要的文字要正确不能出错；如果出错，作为BUG；缺陷严重级别定义为：严重；3、页面是否美观；4、各控件的操作方式统一；如果不一致作为BUG；缺陷严重级别定义为：一般；UI控件如果下面的验证出现错误和不符合需求的，就作为BUG；缺陷严重级别定义为：一般；1、以下是输入框中各字符类型输入验证的详细信息：截止时间不能小于起始时间，如果截止时间小于起始时间又没有提示信息，作为BUG；缺陷严重级别定义为：一般；补充流程测试流程测试涉及到多个表单模块之间数据的传递，所以在测试业务流程时要考虑每个表单模块之间的数据的正确性和一致性；每个流程是否能从起点走到结点；如果不能走通，作为BUG；缺陷严重级别定义为：严重；指定流转目标，如果该目标有处理该流程的权限，查看该目标能否正确接收到数据；如果传递过来的数据不正确或没有传递过来，作为BUG；缺陷严重级别定义为：严重；指定流转目标，如果该目标没有处理该流程的权限，查看该目标能否正确接收到数据；如果数据传递过来了，作为BUG；缺陷严重级别定义为：严重；流程驳回，是否能驳回到相关人；如果不能驳回到相关人，作为BUG；缺陷严重级别定义为：严重；流程拒绝，是否能中止流程；如果不能终止流程，作为BUG；缺陷严重级别定义为：严重流程图显示，是否清晰；如果流程图显示节点、线路混乱，作为BUG；缺陷严重级别定义为：严重注：测试流程一定要注意各个模块各个流程之间的数据的关联。

兼容性测试目前主要考虑的测试点如下：浏览器的兼容性(如：IE内核与非IE内核浏览器测试)；操作系统的兼容性；分辨率的兼容性；链接测试各链接指向目标正确；各链接之间切换正确；链接已切换，是否用旧URL地址仍可访问。

假定程序第一版已经对外运营，客户收藏了某个页面，在第二版中，相应功能作出了调整，且更换了新的URL。

新版本发布时只对导航的指向做了修改，而对旧链接未作处理。

则会造成用户可能访问到老版本页面易用性测试1、操作符合大众习惯；2、如若是工作流等系统，是否任一模块在三个操作步骤以内找到目标在选值时就加以控制，最大化避免错误。

例如：选择日期如果只能选择当天以前的，则可以将日期控件之后的日期设定为灰色不可选择的标记等等；性能测试指标规范在客户要求做性能测试，但是又没有明确性能通过指标的情况下，我们将按以下指标进行测试(主要考虑用户的体验)：复杂的列表查询或树查询操作，平均响应时间在5S以内(可以根据复杂程度以及服务器的硬件环境灵活处理)；页面展示(读取数据展示在页面)，平均响应时间不超过3S；。

合集下载

UI测试要点

UI测试要点

UI测试要点一．UI测试概念UI测试指测试用户界面的风格是否满足客户要求，文字是否正确，页面美工是否好看，文字，图片组合是否完美，背景是否美观，操作是否友好等等。

用户界面 (UI) 测试用于核实用户与软件之间的交互。

UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。

另外，UI 测试还可确保 UI 中的对象按照预期的方式运行，并符合公司或行业的标准。

包括用户友好性，人性化，易操作性测试。

UI测试比较主观，与测试人员的喜好有关，比如：页面基调颜色刺眼；用户登入页面比较难于找到，文字中出现错别字，页面图片范围太广等都属于UI测试中的缺陷，但是这些缺陷都不太严重。

二． UI测试要点1. 按功能将界面划分局域块，完成相同或相近功能的按钮框起来, 并要有功能说明2. 界面要支持按Tab键的自动切换功能;Tab键切换是否正确; Tab键的顺序与控件排列顺序要一直，目前流行总体从上到下，同时行间从左到右的方式;3. 默认按钮要支持Enter及选操作，即按Enter后自动执行默认按钮对应操作4. 菜单点击,窗口初始化5. 父窗体或主窗体的中心位置应该在对角线焦点附近;子窗体位置应该在主窗体的左上角或正中;多个子窗体弹出时应该依次向右下方偏移，以显示窗体出标题为宜6. 在各种分辨率下是否显示正常7. 前景与背景色搭配合理协调，反差不宜太大，最好少用深色，如大红、大绿等。

常用色考虑使用Windows界面色调。

8. 如果窗体支持最小化和最大化或放大时，窗体上的控件也要随着窗体而缩放；对于含有按钮的界面一般不应该支持缩放，即右上角只有关闭功能。

9. 窗体能否多次正确关闭，打开10. 滚动条是否能拖动，并可通过键盘自动拖动11. 与正在进行的操作无关的按钮应该加以屏蔽(Windows中用灰色显示，没法使用该按钮)。

12. 对可能造成数据无法恢复的操作必须提供确认信息,给用户放弃选择的机会,如删除确认提示,退出前确认是否保存13. 可写控件的数据类型及长度,尽量在前台进行控制14. 非法的输入或操作应有足够的提示说明, 让用户明白错误出处，避免形成无限期的等待,提示、警告、或错误说明应该清楚、明了、恰当;提示顺序按Tab顺序15. 对一些特殊符号的输入、与系统使用的符号相冲突的字符等进行判断并阻止用户输入该字符, 特殊字符常有；;’”><,｀‘：“［”｛、\|｝］+=)-(_*&&^%$#@!,.。

ul测试标准

ul测试标准

ul测试标准首先，ul测试标准需要对用户界面进行全面的测试。

这包括对界面的布局、颜色、字体、图标等进行测试，以确保界面的美观和易用性。

在测试过程中，需要检查界面的各个元素是否符合设计要求，是否能够吸引用户的注意力，以及是否能够提供良好的用户体验。

其次，ul测试标准还需要对用户操作流程进行测试。

这包括对用户在软件中的各种操作进行测试，以确保用户能够顺利完成各项操作，并且能够得到及时的反馈。

在测试过程中，需要模拟用户的各种操作场景，包括正常操作、异常操作、以及边界情况下的操作，以确保软件能够正确地响应用户的操作。

另外，ul测试标准还需要对用户体验进行全面的测试。

这包括对用户在软件中的各种交互过程进行测试，以确保用户能够得到良好的交互体验。

在测试过程中，需要检查软件的响应速度、动画效果、以及各种交互元素的设计是否合理，以确保用户能够得到流畅的交互体验。

在进行ul测试时，需要注意以下几点：1. 确保测试用例的全面性和准确性。

测试用例需要覆盖软件的各个功能模块和用户操作流程，以确保测试的全面性和准确性。

2. 注意测试环境的搭建。

在进行ul测试时，需要搭建符合实际使用环境的测试环境，以确保测试结果的可靠性和准确性。

3. 关注用户反馈。

在进行ul测试时，需要关注用户的反馈意见，以及用户在使用软件时的体验和感受，以便及时调整和优化软件。

4. 注意测试结果的记录和分析。

在进行ul测试时，需要及时记录测试结果，并对测试结果进行分析和总结，以便及时发现和解决问题。

总之，ul测试标准是确保软件质量和用户体验的重要手段，通过对用户界面和用户体验进行全面的测试，可以确保软件具有良好的用户界面和用户体验。

在进行ul测试时，需要注意测试用例的全面性和准确性，测试环境的搭建，用户反馈的关注，以及测试结果的记录和分析，以确保测试的全面性和准确性。

软件测试之功能测试篇

软件测试之功能测试篇

软件测试之功能测试篇⼀、软件测试的⽬的：发现缺陷错误，并且尽最⼤可能找出最多的错误，也是对软件质量进⾏评估，以提⾼软件质量。

⼆、什么是软件：软件=程序+⽂档软件是计算机系统中与硬件相互依存的⼀部分，它是包括程序、⽂档的完整集合。

程序（program）是按事先设计的功能和性能要求执⾏的指令序列。

⽂档（document）是与开发、维护和使⽤有关的图⽂材料。

三、软件缺陷的定义：1、软件没有实现产品说明书要求的功能；2、出现了产品说明书指明的不应该出现的错误；3、实现了说明书中未提及的功能；4、未实现产品说明书虽未明确，但应实现的功能；5、软件难以理解，不易操作，运⾏缓慢等问题；6、缺陷是系统在开发或者维护过程中就存在的错误；7、缺陷是系统某种功能失效；四、什么是软件测试：1、找bug；2、找到【预期结果】和【实际结果】的差异，保证项⽬质量；3、根据需求⽂档（客户要求）进⾏测试；P.s：⼀般把软件缺陷（defect）称为bug（臭⾍）五、操作系统：1、Windows2、Linux3、Android4、IOS5、Unix六、BS架构和CS架构：1、BS架构——基于浏览器；优点：分布性强，维护⽅便，成本低；缺点：个性化特点明显降低，跨浏览器实现差，响应速度低，容易给服务器造成较⼤的压⼒；2、CS架构——基于客户端；优点：⽤户体验佳，速度快，处理能⼒强；缺点：需要专门的客户端安装程序，开发、维护成本⾼，升级⼀次所有的客户端程序都需要改变。

七、职业素质要求：1、专业知识2、沟通能⼒3、团结合作能⼒4、耐⼼、细⼼、⾃信⼼5、责任⼼6、不管做什么测试，基础⼀定要牢，才能继续提升⼋、V模型：【⽤户需求】由需求⼈员（BA）根据客户需求整理⼀个⽂档叫需求⽂档【需求分析】项⽬经理—测试经理—开发—测试—BA开会讨论：1、需求怎么做？——开发2、需求是否合理？——两个⽅⾯：需求、时间3、测试⼈员的作⽤？（1）搞清楚这个需求的来源是做什么的；（2）通过测试思维去考虑它，如何去测试它；4、需求讨论阶段也是需求确认的⼀个阶段【概要设计】开发⼈员对需求进⾏梳理；——开会评审，检查开发⼈员对需求的理解程度；【详细设计】开发⼈员需要通过什么样的技术去实现这个功能，⽤⽂档的形式写出来——后期也需要评审【编码】编程。

功能UI测试方案

功能UI测试方案

功能UI测试方案功能测试方案：一、介绍功能测试：功能测试是软件测试的一种类型，主要是针对软件系统的各项功能进行验证和测试，以确保软件系统按照设计和需求的要求正常运行。

功能测试的目标是发现并报告软件系统中的功能缺陷和问题，以便修复和改进。

二、功能测试的步骤：1.确定测试目标：了解软件系统的功能需求和设计文档，确定要测试的功能点和测试的目标。

2.制定测试计划：根据测试目标，制定详细的测试计划，包括测试的时间、资源、人员分配等。

3.设计测试用例：根据功能需求和设计文档，设计详细的测试用例，包括正常情况下的功能验证以及异常情况下的处理和反应。

4.执行测试用例：按照设计的测试用例，执行功能测试，并记录测试结果和问题。

5.分析测试结果：对测试得到的结果进行分析和总结，确定功能是否达到要求，是否存在问题。

6.缺陷修复和验证：根据测试结果，对发现的问题进行修复，并验证修复后的功能是否正常。

7.测试报告：根据测试结果和情况，制作详细的测试报告，包括测试目标、测试过程、测试结果、问题列表等。

三、功能测试的策略：1.分层测试：根据软件系统的结构和功能的不同，将功能测试分为不同的层次，逐层进行测试，确保每个功能模块的正确性和整体功能的一致性。

2.边界值测试：对于输入和输出的边界值，进行测试，以验证软件系统对于边界情况的处理是否正确。

3.异常处理测试：测试软件系统在接收到非法或异常输入时的处理和响应，以确保系统的稳定性和安全性。

4.兼容性测试：验证软件系统在不同的操作系统、浏览器等环境下的兼容性，以确保软件系统在不同环境下的可用性和可靠性。

5.性能测试：对于涉及到大数据量或高并发的功能，进行性能测试，以验证系统的响应速度和负载能力。

UI测试方案：一、介绍UI测试：UI测试是软件测试的一种类型，主要是针对用户界面的可用性和用户体验进行验证和测试，以确保用户界面的设计和功能满足用户的需求和期望。

UI测试的目标是发现并报告用户界面中的问题和缺陷，以便修复和改进。