ui常见测试用例（通用4篇）
ui常见测试用例 篇1
大家在编写测试用例时，往往分不清什么是UI，什么是功能。最近特意整理了工作中经常进行的UI测试项。UI测试内容包括以下内容： 1.窗口测试主要测试内容如下：
窗口与窗口之间的调用情况；
窗口尺寸变化时窗口中控件能否自适应；
多个窗口同时打开和调用的情况；
窗口拖动是否正常；
主窗口和子窗口调用能否正常处理；
窗口能否根据浏览器大小进行缩放【双击浏览器、浏览器最大化、最小化和还原查看窗口的变化情况】；
窗口显示标题是否正确。
2.工具条测试主要测试内容如下：
工具条能否正常显示；
工具条能否隐藏；
可移动工具条在窗口中间位置其形状是否正确；
工具栏上工具按钮功能是否能正常实现；
工具按钮显示是否正确、友好、醒目易懂；
工具栏上的工具按钮是否有鼠标悬停提示；
工具栏上的工具按钮是否可以任意定制；
是否有输入框；
是否有个人用工具条；
是否有网站型工具条；
是否有专项型工具条；
是否有企业型工具条。
3.工具条测试主要测试内容如下：
输入正常的字母或数字；
输入已存在的文件的名称；
输入超长字符，例如在“名称”框中输入超过允许边界个数的字符，假设最多255个字符，尝试输入 256个字符，检查程序能否正确处理；
输入默认值，空白，空格；
若只允许输入字母，尝试输入数字；反之；尝试输入字母；
利用复制，粘贴等操作强制输入程序不允许的输入数据；
输入特殊字符集，例如，NUL及n等；
输入特殊字符集，例如，NUL及n等；
输入不符合格式的数据，检查程序是否正常校验，如，程序要求输入年月日格式为yy/mm/dd，实际输入yyyy/mm/dd，程序应该给出错误提示；
输入非法数据；
输入默认值；
输入特殊字符集；
输入使缓冲区溢出的数据；
输入相同的文件名；
输入超过文本框长度的字符或文本，检查所输入的内容是否正常显示。4.菜单测试主要测试内容如下：
菜单项是否符合需求，能否正常工作，是否与实际执行的内容一致；
菜单措辞是否准确；
菜单位置及顺序是否合理；
菜单图形布局是否一致；
下拉菜单是否根据选项含义进行分组；
菜单的热键、快捷键能否有效使用和重复；
帮助菜单的“关于”中应有版权和产品信息；
界面菜单公司信息和产品信息显示是否正确。5.页面布局测试主要测试内容如下：
页面布局是否根据分辨率大小自动调整；
页面长宽比例合理是否合适；
界面风格要一致；
背景色彩搭配要协调。6.图标测试主要测试内容如下：
是否符合表达习惯；
不同目标是否采用不同图标；
图标尺寸是否合适；
图标是否有标注，包括公司图标和产品图标。7.界面按钮测试主要测试内容如下：
按钮位置是否合适，是否有正常响应，是否有相应的匹配按钮如：按钮；
单选框和复选框按钮的测试；
功能按钮图标上或在鼠标经过时是否给予正确提示信息。8.时间控件测试主要测试内容如下：
时间年月日选择（开始时间不可大于结束时间）；
时间有效期；
时间年月日显示是否正确；
时间查询。
9.界面文字测试主要测试内容如下：
界面文字描述是否准确，无异议；
文字大小是否合适（一般9-12号）；
是否出现中英文混合；
界面文字是否可根据浏览器的编码方式自适应。10.界面信息提示测试主要测试内容如下：
提示信息是否具有可理解性的语言描述；
对重要、具有破坏性的操作命令是否有确认信息；
提示信息是否具有统一的标记和标准；
提示信息不易过长。
11.鼠标和快捷键测试主要测试内容如下：
是否支持滑轮；
鼠标点击右键是否显示菜单，取消右键是否隐藏；
无规则点动鼠标，查看界面的响应；
经过键盘或鼠标复制粘贴；
支持快捷键使用；
支持键盘自动浏览按钮（Tab键、Enter键）。
“确定”和“取消”当然在设计UI窗口测试用例时，要根据以上大的测试项，逐渐细分，尽可能多的设计较全面的测试用例，但是还要根据测试软件的具体实现架构进行设计用例
测试用例书写标准 篇2
在编写测试用例过程中，需要参考和规范一些基本的测试用例编写标准，在ANSI/IEEE829-1983标准中列出了和测试设计相关的测试用例编写规范和模板。标准模板中主要元素如下。
标识符（identification）：每个测试用例应该有一个唯一的标识符，它将成为所有和测试用例相关的文档/表格引用和参考的基本元素，这些文档/表格包括设计规格说明书、测试日志表、测试报告等。
测试项（test item）：测试用例应该准确地描述所需要测试地项及其特征，测试项应该比测试设计说明书中所列出地特性描述更加具体，例如做windows计算器应用程序地窗口设计，测试对象是整个地应用程序用户界面，这样测试项就应该是应用程序地界面地特性要求，例如缩放测试、界面布局、菜单等。
测试环境要求（test environment）：用来表征执行该测试用例需要地测试环境，一般来说，在整个的测试模块里面应该包含整个的测试环境的特殊要求，而单个测试用例的测试环境需要表征该测试用例所单独需要的特殊环境需求。
输入标准（input criteria）：用来执行测试用例的输入需求。这些输入可能包括数据、文件，或者操作（例如鼠标的左键单击，鼠标的按键处理等），必要的时候，相关的数据库、文件也必须被罗列。
输出标准（output criteria）：标识按照指定的环境和输入标准得到的期望输出结果。如果可能的话，尽量提供适当的系统规格说明书来证明期望的结果。
测试用例之间的关联：用来标识该测试用例与其它的测试（或其它测试用例）之间的依赖关系，例如，用例A需要基于B的测试结果正确的基础上才能进行，此时需要在A的测试用例中表明对B的依赖性，从而保证测试用例的严谨性。
综上所述，如果使用一个数据库的表来表征测试用例的话，它应该有以下的格式：
例一：对Windows记事本程序进行测试，选取其中的一个测试项――文件菜单栏的测试 测试对象：记事本程序文件菜单栏（测试用例标识1000，下同），所包含的子测试用例描述如下：
|---------文件/新建（1001）
|---------文件/打开（1002）
|---------文件/保存（1003）
|---------文件/另存（1004）
|---------文件/页面设置（1005）
|---------文件/打印（1006）
|---------文件/退出（1007）
|---------菜单布局（1008）
|---------快捷键（1009）
选取其中的一个子测试用例――文件/退出（1007）作为例子，测试用例如下表所示：
通过这个例子了解了测试用例的组成方法。要组织成一个完整的良好测试用例，还需要更多的技巧，并要考虑一些常见的因素。
测试用例设计考虑因素
测试是不可能实现穷举测试的，因此试图用所有的测试用例来覆盖所有测试可能遇到的情形是不可能的，所以，在测试用例的编写、组织过程中，尽量考虑有代表性的典型的测试用例，来实现以点带面的穷举测试。这要求在测试用例设计中考虑一些基本因素： 测试用例必须具有代表性、典型性。
测试用例设计时，要浓缩系统设计。
例二：常见的web登录页面，通过这个例子来阐述从功能规格说明书到具体测试用例编写的过程
A）用户登录的功能设计规格说明书（摘选）
―――――――――――――――――――――――――――――――――――――――
1． 用户登录
1．1满足基本页面布局（图示，略）
1．2当用户没有输入用户名和密码时，不立即弹出错误对话框，而是在页面上使用红色字体来提示，见2描述
1．3用户密码使用掩码号（*）来标识。
1．4*代表必选字段，将出现在输入文本框的后面。
2． 登录出现错误
当出现错误时，在页面的顶部会出现相应的错误提示。错误提示的内容见3。错误提示是高亮的红色字体实现。
3． 错误信息描述
3．1
3．2密码为空
3，3用户名/
（注：本例子中的页面图示，消息编号如WMSG001的描述均为给出。）
―――――――――――――――――――――――――――――――――――――――
B）通用安全性设计规格说明书（摘选）
―――――――――――――――――――――――――――――――――――――――
1． 安全性描述
1．1输入安全性：在用户登录或者信用卡验证过程中，如果三次输入不正确，页面将需要重新打开才能生效。
1．2密码：在所有的用户密码中，都必须使用掩码符号（*），数据在数据库中存储使用统一的加密和解密算法。
1．3Cookie：在信用卡信息验证，用户名输入时，Cookie都是被禁止的，当用户第一次输入后，浏览器将不再提供是否保存信息的提示，自动完成功能将被禁用。
1．4SSL校验：所有的站点访问时，都必须经过SSL校验。
2． 错误描述（略）
―――――――――――――――――――――――――――――――――――――――
C）测试用例
结合相关的规格说明书，理解和掌握测试用例设计的关键点，测试用例设计如下表所示。
测试用例需要考虑到正确的输入，也需要考虑错误的或者异常的输入，以及需要分
析怎样使得这样的错误或者异常能够发生。
用户登录功能测试用例
完善的测试用例
编写测试用例方法心得体会 篇3
编写测试用例方法心得体会
编写背景：
一直以来都不太想把技术方面的文章写出来给大家看，一个是怕写作功底不好误导哪些刚入门的测试同行，自己的表达能力有限，另一方面怕有的同行拿出去炒作，再者测试网站论坛上关于测试用例的资料已经实在是多。但是看到同行纷纷都在问我测试用例的问题，都很想知道我写测试用例的心得体会。我就抱着试试看的心态写写吧，希望测试的老前辈看见了，可以给我多提提建议。
编写测试用例方法心得体会
在我的个人邮箱和MSN上，通常同行都问我类似下面这样的问题：
１、一个测试用例要写到什么程度才比较好?
２、刚开始做测试的时候，你是怎么学习写测试用例的？
３、你对黑盒测试用例的编写的体会是什么？有什么好的版本或者标准吗？
对于测试用例，而我目前正在思考的问题是：怎么写出对公司有价值的测试用例，对公司来说，怎么测试才是最有价值的测试？
下面先来分析第一个问题吧：一个测试用例要写到什么程度才比较好？
这个问题，没有定语，没有说是在什么样的一个情况下，因此我这里只能就我工作中碰到的情况说说了。说起来比较长阿，大家要有耐心看才行哈。^_^ 在我测试工作中，碰上的测试类型我自己划分成这么４种： ^
对项目、产品的测试，测试的时候通常要考虑这个项目的周期和测试资源。我所在的公司，通常项目开发时间都很短４到５个月，然而测试通常都是在开发即将结束的时候才真正介入。测试就是１个人负责。因此时间和人力资源对测试来说是完成测试工作的一个风险。为此在这种情况下，我都是先熟悉系统的业务，把握重点业务和功能后，参考需求，把测试需求、测试计划和测试大纲给制定好。由于时间关系，测试用例都是先写重点的业务，也就是集成测试的测试用例。另外测试用例是根据测试大纲来的。通常都是先挑最重要的测试项和风险大的业务功能编写测试用例。由于测试用例是本人执行，所以测试用例可以写的简单些，但是一定要开发人员能够看明白。可惜我所在的公司，都没有人来看我的测试用例。测试用例对我来说是用来提示我不要忘记了要测试哪些项。一些很有价值的ｂｕｇ通常不是在写测试用例的时候发现的，而是在测试软件的过程中，我在家睡觉前的思考和回家的路上思考出来的。这就是手动测试的魅力，有些软件的缺陷是在你使用软件的一瞬间和思考的一刹那突然发现的。所以要我回答测试用例要写到什么程度才比较好，我觉的只要你所写的测试用例在你的公司能够顺利的执行，不影响你的测试执行工作就可以了。因为测试用例写的太详细，你要花费时间和人力成本，这样出来的测试用例是最好的也是最贵的，一旦需求变更，也需要修改，这时你会发现这种详细的测试用例是最不挣钱的。测试用例写的太粗，别人看不懂，不能执行，那你要花费你的时间去解释，这就加大了测试的工作量。这也不是好的方法。
第二个问题，刚开始做测试的时候，你是怎么学习写测试用例的？
我之所以选择测试这个工作是因为：我毕业后，在第一家公司做技术支持，产品的问题很多，导致技术支持工作很辛苦、很累。为了让用户买到的产品的质量是好的，我选择了做测试，到了现在的公司。我刚做测试的时候，对测试一无所知，什么测试流程阿、文档阿都不知道，公司的测试和管理也不规范。对测试，大家都认为不就是拿个鼠标点来点去，谁都可以来做。为此，我经常上网查测试的资料，看看自己到底适合不适合做测试，测试到底是什么样的一个职业，怎么去规划自己的个人发展。其实要做好测试，真是不容易。不喜欢，真是不能做这个职业。
现在想想自己刚开始写测试用例的时候，真是好笑。就像小孩子学习写字一样。先是在网上狂搜索了一把测试用例的模板，综合了几个，就形成了。我之所以不用公司原有的测试用例模板，是因为太不适用了。还好，公司没有严格要求必须要那个模板，只要适用就行。模板找好了，可是写就费劲了。对于刚做测试的新人，看似简单的一个填表工作，要写好真是不简单。一开始写的比较不自然，有些生搬硬套，而且还很慢。没有办法，那时候没有人指导我，全靠自己自学和领悟，所以那段日子很苦阿！多写几次后，就知道和领悟了，测试用例要根据测试大纲来写，测试大纲要根据测试计划来写。测试大纲更多的是把握住测试项的方向，而测试用例是指导怎么去执行测试。还好，我有编程的经验，所以对我熟悉软件帮了一个很大的忙。熟悉了软件的业务才能去写测试用例，才能更好的去测试。这也是我一点一点的领悟出来的。说了这么多，不知道这样的回答是否是回答了这个问题。
最后一个问题了，我尽量少写些，文字太多了大家看的也累，我写的也累。嘿嘿。^_^ 你对黑盒测试用例的编写的体会是什么？有什么好的版本或者标准吗？ 我的体会：
１、测试用例要根据测试大纲来编写
２、测试用例也要分测试项进行归类，这样比较好分析和阅读。如：业务流程测试、安装测试、功能测试、用户友好性测试、兼容性测试、性能测试、安全性测试等等。
３、编写测试用例要考虑各种情况，精力主要集中在软件的主要业务流程和风险高的地方。能分出测试优先级别就最好了。
４、熟悉系统，对编写测试用例很有帮助。
５、即使对测试很熟悉了，在时间非常紧的时候，编写测试用例还是很有必要和好处的。
今天就想到那么些了，以后想到了在补充上了。我把我用的模板给你们粘贴一份上来，只能给你们做些参考，具体还是要看对你所在的公司适用不适用。测试项的归类我就不列举了，因为每个公司的都不太一样。
北京测试空间科技发展有限公司是注册于北京市海淀区高新技术园的软件企业，目前主要业务范围包括软件测试管理 工具研发、软件测试项目外包和软件测试专业技术人才培养及派遣。在软件测试管理工具研发领域已成功开发具有
ui常见测试用例 篇4
测试用例复用是指测试工程师在执行一项新的测试工作时，通过直接调用或修改现有的、合适的测试用例，并将其应用在测试执行中的过程。如果搜索后得到的测试用例与需求完全一致，则直接复用现有测试用例，但是一般情况下，直接复用测试用例的情况很少;如果搜索到的测试用例与需求近似，则对其进行修改，得到新的测试用例之后再复用。在一定程度上，测试用例复用可以节省重新设计测试用例的时间，减少测试工程师的工作量，提高软件测试的效率。
然而，并非所有的测试用例都适合复用，有些测试用例定制化程度较高，只适合某些特定的测试场景，这样的测试用例可复用程度不高。由此可知，测试用例要能进行复用，须具备一定的可复用特性。
1.2 可复用测试用例特性
经过对大量可复用测试用例的收集以及分析，本文认为可复用测试用例需满足以下5个特性：标准化、通用性、有效性、独立性、小粒度1]。
1) 标准化。测试用例通常用自然语言进行描述，但由于自然语言的非结构化特性，无统一结构的测试用例不利于测试用例复用。因此，测试用例的设计必须使用统一的格式或结构，以消除由于自然语言的表述的差异带来的问题。标准化不仅强调测试用例的可复用能力，更偏向于测试用例管理。采用明确无歧义的语言描述测试用例并用统一结构进行存储，如表1测试用例描述案例所示2]。其中，加粗字体表示测试用例的字段，中括号 ]里的内容表示测试用例的具体内容或相关属性。
2) 有效性：测试用例的目标是发现软件中的问题或者验证功能是否正确，因此测试用例必须是针对它的测试目的而设计，并且经审核后必须是正确、完整、适用于被测对象并且是可执行的。
3) 通用性：测试用例不局限于具体的应用，不过分依赖于被测软件的需求、设计、环境、其他功能以及其他业务流程，可复用测试用例可多次适用于不同版本的软件测试或广泛应用于某同类软件或类似功能模块的测试。
4) 独立性：测试用例不过分受制于测试环境、相关业务流程以及前置测试用例。理论上，测试用例与其他因素的耦合度越小，则独立性也就越高，其测试用例的可复用程度相对较高。
5) 小粒度：通常指一个被测模块的末梢功能，测试用例的粒度设计追求功能的不可分割性。粒度越小并且相对独立的功能，针对其功能设计的用例，可复用性也就越高。
以登录功能举例，该功能相对于整个应用系统来说粒度最小，并且与其他功能相对独立，同时，针对登录功能设计的测试用例具有较强的通用性，所以通常情况下，登录功能的测试用例具有较高的可复用性。
1.3 测试用例复用场景
然而，并非所有的软件测试过程都适合进行测试用例复用。测试用例复用是为了避免测试用例的重复设计，提供现有的测试用例给测试工程师直接使用。因此，只有在需要重复执行的测试用例时，测试用例的复用才能真正发挥作用。通常情况下，测试用例复用主要由三类测试场景3]：
1) 软件升级：包括版本升级、缺陷修复等升级行为。例如：一家公司的业务管理系统的升级，或某个功能的改进。通常不会引起非常大的业务流程变动或界面改动，因此前一个版本的测试用例可被大量复用。
2) 产品测试：此类场景多存在于软件研发公司，多从事于某个领域的软件研发工作，通常此类公司有着自己的测试用例库。比如：从事ERP(企业资源计划)软件开发的公司。虽然不同行业的业务流程都不完全一致，但也有存类似的可复用业务流程，例如员工管理模块等。
3) 第三方测评4]：第三方测评机构适用于此类测试用例复用场景。由于第三方测试机构会对大量的软件进行测评，其中不乏相同领域的软件产品。如果对每个测试软件重新设计测试用例，必然增加工作成本。因此，对于第三方测评机构测试用例复用是十分有必要的。测试用例复用在不同领域和场景中有着广泛应用，对于大量测试用例的复用需要建立在大量测试用例基础上，需要将以往设计的测试用例加以存储和管理，因此设计一套测试用例管理系统是测试用例复用成为可能的先决必要条件。
2 测试用例复用库模型设计与实现
测试用例复用就是对已经执行的测试用例进行重复使用或修改使用。要实现测试用例复用，则需要对以往设计的测试用例进行有效的存储以及分类管理以供后续使用。对测试用例的管理就需要创建一个测试用例复用库来存储测试用例，在测试用例复用库中使用统一的规范数据格式对测试用例进行管理。当测试工程师要设计测试用例时，可先在测试用例库中进行搜索，查找合适的测试用例进行复用。但是，随着时间的增长以及测试项目的增加，测试用例库也随之扩充，测试用例数目与日俱增，这就增加了搜索的工作量。为了提高搜索的效率，根据测试用例适用的行业领域，对测试用例进行划分存储，并打上行业领域的标记。其原因在于，相同行业领域的软件其测试用例的通用性更高，可复用性也更高。
为了提高在测试用例库中的搜索效率和准确度，将分词技术应用于测试用例搜索功能中，对用户的搜索输入进行分词、筛选，得出有效的搜索关键字，根据关键字在测试用例复用库中进行搜索，减少了非关键字的干扰，提高了查询速度，并且搜索结果更准确。
通常情况下，测试用例复用分为直接使用以及修改使用，但无论何种情况，都需要对新测试用例进行审核，确定其有效性和唯一性方能进入测试用例复用库，测试用例复用模型如图1所示。
3 测试用例复用搜索设计与实现
3.1 分词词库
测试工程师进行测试用例复用时，需要对查询输入进行处理，常用方法是使用分词技术提取其中的关键字进行查询。分词技术中，英文单词之间以空格作为自然分界符，而中文是以字为基本的书写单位，词与词之间没有明显的区分标记，因此，对中文信息处理相对比较复杂。语义分析是中文信息处理的基础与关键，常见的.分词算法有两种：
算法1：建立词库，对待分析字符串逐词匹配，分离关键字;
算法2：建立词库，对目标串构造全文索引，然后将结果集与词库进行笛卡尔积匹配，获取匹配结果。
以上算法如果用于较大规模词库时，存在如下效率问题：
1) 当词库较大时，逐词匹配耗时较长;
2) 采用全文索引方式消耗多余内容，同时不适用于测试用例复用查询功能，因为用户输入的查询信息较短，而全文索引多适用于长文本字符串搜索功能。
在测试用例复用查询功能中，用户查询输入相对简单，但需要进行精确分词，因此针对此类特点，本文对文献5]中提出的索引方法加以改进，采用二级索引对中文词条进行分词(这里只讨论中文分词，英文分词可使用Lucene工具进行分词)，以确保能快速并精确地进行分词。由于长度为2的中文词条占整个汉字词条约70%5]以上，同时假设汉字词长度2、3、4的词条个数比例为7：2：1，因此，大约90%的情况下，执行两次检索便能定位一个汉字词条，以保证较高的分词效率。同时为减少磁盘I/O，在系统启动时，将词库载入至内存，使所有计算可在内存中进行，进一步提高分词效率。根据《中国大百科全书》目前收录约6 000万个词条为例，整个中文词库大约适用300MB～400MB内存，因此，常见的主机可满足其硬件需求。
3.2 搜索算法
随着软件测试项目的日益增加，测试用例复用库不断扩充，这势必会影响到搜索的效率。本文中，当接收到用户的查询输入，程序首先将其与分词词库进行匹配，对查询输入进行分词，然后根据被测软件的行业领域，查询对应领域的测试用例数据，并且根据排序算法对查询结果进行排序。由于该分词算法仅用于测试用例查询，因此对于中文分词算法中歧义词的处理可以忽略不计，其伪代码如下所示：
由于词库在初建之时，未必能覆盖所有中文词条，并且随着各个行业的高速发展，每天都可能会有新词条出现，因此必然存在无法匹配的词条。当出现新词时，分词算法将自动定位到下一个可匹配词条，然后继续进行拆分，而新词则被单独作为一个分词加载至分词结果中。同时存储该用户输入，待管理员进行审核，人工加入到词库中。采用人工添加新词而非程序自动添加新词的原因在于，程序还不够智能，也无意义做到足够智能，同时对于新词的理解或判断的正确率远低于人判断的正确率。
3.3 结果排序
针对测试工程师进行测试用例的复用查询，其查询结果可能是几条，也可能是几十条，甚至是几万条数据，然而并非所有查询到的测试用例都是查询者所需要的，当查询结果数量庞大时，逐条查看筛选所消耗的时间可能早已超过了重新设计一个测试用例所需的时间，必然导致时间成本上的浪费，这与测试用例复用的初衷相违背。由此可见，根据查询到的测试用例与用户所需测试用例的相关性，为用户推荐一个“好”的测试用例是十分必要的。
可复用测试用例的查询结果的排序可以为用户提供选择测试用例的依据，针对查询主要针对教育期刊网
关键词 的搜索，因此对查询结果中的测试用例按照一个三元组方式排序，其中K表示搜索的教育期刊网
关键词 集合，ki是该教育期刊网
关键词 集合中的某个教育期刊网
关键词 ，则排序三元组表示如下：
C(ki)表示当前查询结果中是否有与ki匹配的教育期刊网
关键词 ，如有，则C(ki)记为1，如没有，则C(ki)记为0。
C(ki)是K中每个教育期刊网
关键词 在本次查询中是否匹配的计数之和，始终大于0，因为查询结果中显示的是至少有一个查询关键字匹配的搜索结果。S(ki)表示当前查询结果中教育期刊网
关键词 ki出现的频次。S(ki)是K中每个教育期刊网
关键词 在本次查询中出现频次之和。Creuse则表示查询结果中该条测试用例被复用的次数。
通过上述三元组对测试用例的查询结果进行排序。首先按照C(ki)列进行降序排序，若该列数值相同，则按S(ki)列进行降序排序，若此列数值相同，则按Creuse列进行降序排列。由此可以发现，查询关键字匹配越完全，其满足查询需求的程度就越高，同时，复用次数越多的测试用例，越具有通用性。
4 总结