测试用例

一、易用性 1、便于使用、理解、并能减少用户发生错误选择的可能性 　　2、当数据字段过多时，使用便于用户迅速吸取信息的方式表现信息，突出重点信息，标红等方式 　　3、显示与当前操作相关的信息，给出操作提示。 　　4、界面要支持键盘自动浏览按钮功能，即按Tab键、回车键的自动切换功能 　　5、对于常用的功能，用户不需要阅读用户手册就能使用 二、一致性 1、是否符合广大用户使用同类软件的习惯 　　2、表现形式的一致性，字体、按钮、控件风格、颜色、术语、提示信息等。（需要有一个全局的概念，不要每个模块都按照他们自己的风格做，结果每个模块效果做出来都不一致，这也是至关重要的所有要测试人员认真检查） 　　3、交互习惯的一致性，查询、新增、编辑、删除等操作，并保证同一操作类型按钮名称一致。（顺序一致，页面位置也要尽量相同。） 　　4、当输入框为不可输入或控件为不可使用状态时，统一为灰色不可输入状态； 三、有序性 1、界面文字、表单、图标等元素根据业务规则、使用频率排列 　　2、Tab键的顺序与控件排列顺序要一致，目前流行总体从上到下，同时行间从左到右的方式 　　3、必填项提示信息按照从上到下，从左到右的提示方式依次提示 四、安全性 1、ID/密码验证方式中能否使用简单密码。如密码标准为6位以上，字母和数字混合，不能包含ID，连续的字母或数字不能超过n位 　　2、ID/密码验证方式中

认识测试用例 定义 测试用例（ Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。 构成 用例 ID 、用例名称、用例描述、前提条件、结束准则、测试步骤、预期结果、实际结果、判断准则。 重要性 测试用例的设计如此重要，原因在于完全的测试是不可能的，对任何程序的测试必定是不完全的。所以，最显然的测试策略就是努力使测试尽可能完全。下面是更为详尽的测试用例的好处： 1. 在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试效率 2. 测试用例的使用令软件测试的实施重点突出、目的明确 3. 在软件版本更新后只需修正少部分的测试用例便可开展测试工作，降低工作强度、缩短项目周期 4. 功能模块的通用化和复用化使软件易于开发，而相对于功能模块的测试用例的通用化和复用化则会使软件测试易于开展，并随着测试用例的不断精华，其效率也不断提高。 具体设计 黑盒测试 等价类划分：通过定义条件和错误类来帮助减少测试的工作量。这种划分假设某分类的一个代表值能够等价于属于该分类的所有值或者条件。 具体使用：可以参照《 测试用例之等价划分 》博客，具体说明。 边界值分析：测试等价类中的每一个分类取边界值时的情况，既要考虑输入等价类，也要考虑输出等价类。 具体使用：可以参照《 测试用例之边界值分析 》博客，具体说明。 因果图分析

一、接口测试的测试方案规格建议可以有如下几点： 1、需求所涉及的接口的背景描述 2、接口跟页面功能交互的关联关系 3、接口逻辑的流程图 4、接口文档定义 5、接口所涉及的缓存，以及缓存对应的key值，失效时间定义 6、接口所涉及的SQL，以及数据库表字段定义 7、接口历史功能验证（新增接口测试不需要） 8、接口涉及话单，短信，推送消息等描述 9、接口涉及的配置参数和开关等描述 10、接口设计的基本流程描述 11、接口涉及的正常用例测试点设计 12、接口涉及的异常用例测试点设计 二、页面测试用例设计 页面功能测试主要是由3大块的组成： 1.页面功能展示： 页面功能展示主要是校验一些页面的静态图片、字体、间距、排版等等之类的内容显示是否规范，具体的校验可以通过需求中的原型图比例标注进行校验。 2.页面跳转展示： 需要校验页面上所有可以点击的链接按钮是否都可以跳转到指定的页面，跳转过程中页面加载loading动画是否正确，具体的标准可以跟PD确认 3.页面逻辑校验： 页面展示的数据也是有逻辑的。（前端展示的状态需要跟后端配置的数据一致） 4.其他： 我们在做页面功能测试的时候也需要考虑一些异常的场景测试，暂时总结出来的主要包括几种： 数字，字母，符号，表情等输入校验 超长字符，最小字符长度验证 APP端和PC端同步操作时数据同步校验 网络连接中断后重新连接测试 三、页面测试用例编写

客户端自动化特点 客户端的自动化，通常做过的人都不是很愿意深入讨论。因为除了功能和逻辑之外，不得不面对各种界面变化，各种和环境交互，各种兼容问题以及想不到灰色地带，就算这样，也找不到太多有效的bug。然而即便如此，客户端的自动化必须去做，尤其是GUI的。它的自动化特点是： 复杂 成本高 不容易发现问题 技术要求高 架构很难通用 下面，从一些基本的东西开始一点点的讨论客户端GUI测试的一些问题和处理办法，以及自动化架构设计的一些思路。事实上就像上面说的，GUI的测试并不是为了发现bug，而是回归的一种方式，作为保证而已——它过了不能说明质量多么好，但是不过，质量肯定不达标。即使在微软内部，客户端的GUI一样不是个受欢迎的家伙，通常用来做BVT的测试（或一些重要性回归，冒烟等）。 客户端自动化简述 这里并不花过多的笔墨介绍什么是客户端，或者如何分类的种种——这些东西教材和网上的东西一坨一坨很多很多，这里可能“漫谈”的，是实际工作中，客户端和GUI自动化中可能遇到的一些底层技术，基本上原理，架构设计方法以及一些项目存在困惑，这些方面的一些处理的方法。 最早的自动化 我个人认为所谓的计算机行业的自动化，是一直跟着这个行业的发展在走，比如下面的这些： 老式计算机——CPU计算： 最早自动解决手工分配穿孔的卡片问题 内存分配任务调度：操作系统的核心就是内存和任务的自动管理 系统配置Loader

二、设计测试用例 什么样的测试用例算好的测试用例？ 1、不要以为“发现了软件缺陷的测试用例就是好的用例” 2、也不要以为“发现软件缺陷可能性大的测试用例就是好用例” 3、更不要以为““发现至今未被发现的软件缺陷的测试用例就是好用例” “好的”测试用例一定是一个完备的集合，它能够覆盖所有等价类以及各种边界值，而跟能否发现缺陷无关。 “好的”测试用例必须具备哪些特征？ 1. 整体完备性 ：“好的”测试用例一定是一个完备的整体，是有效测试用例组成的集合，能够完全覆盖测试需求。 2. 等价类划分的准确性 ：指的是对于每个等价类都能保证只要其中一个输入测试通过，其他输入也一定测试通过。 3. 等价类集合的完备性 ：需要保证所有可能的边界值和边界条件都已经正确识别。 边界值分析 是对等价类划分的补充，你从工程实践经验中可以发现，大量的错误发生在输入输出的边界值上，所以需要对边界值进行重点测试，通常选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据。 错误推测方法 是指基于对被测试软件系统设计的理解、过往经验以及个人直觉，推测出软件可能存在的缺陷，从而有针对性地设计测试用例的方法。这个方法强调的是对被测试软件的需求理解以及设计实现的细节把握，当然还有个人的能力。 来源： CSDN 作者： wjw290313631 链接： https://blog.csdn.net/weixin

用户界面（UI）测试初学者指南 本指南介绍了有关GUI测试的关键问题：它是什么？ 它为什么如此重要？ 什么是主要的GUI测试类型和技术？ 阅读此综合指南以发现这些问题的答案，并学习如何创建GUI测试计划并编写GUI测试用例。 什么是GUI测试？ 如果智慧的开始是术语的定义，那么对GUI测试的理解必须从术语 GUI 的定义开始 。 这是 图形用户界面 的缩写 ，或用户可见的应用程序的一部分。 GUI可能包含诸如菜单，按钮，文本框和图像等元素。 第一批成功的图形用户界面之一是Apple Macintosh，它通过文件夹，日历，垃圾桶和计算器来推广用户“桌面”的概念。 早期的GUI：1984年发布的Apple Macintosh。 图片来源： folklore.org CC许可 在当今的GUI测试环境中，“简单计算器应用程序”不再局限于计算机的桌面。 它可能是在所有主要移动平台上可用的移动应用程序。 或者，它可能是所有主流浏览器都必须支持的云应用程序。 测试人员必须执行跨浏览器和跨平台测试来识别缺陷并确保应用程序满足所有要求。 因此，GUI测试是指测试用户可见的应用程序的功能。 在计算器应用程序的示例中，这将包括验证应用程序是否正确响应诸如单击数字和功能按钮等事件。 GUI测试还会确认外观元素（如字体和图像）符合设计规范。 UI测试与GUI测试一样吗？

概念 用例(Use Case)是一种描述产品需求的方法，使用用例的方法来描述产品需求的过程就是用例模型，用例模型是由用例图和每一个用例的详细描述文档所组成的。在技术和产品的工作领域里都有用例模型的技能知识。技术人员的用例主要是为了方便在多名技术人员协同工作，或者技术人员任务交接时，让参与者更好的理解代码的逻辑结构。产品人员的用例主要是为了方便技术研发和功能测试时，让参与者更好的理解功能的逻辑。 起源 用例起源和发展于软件时代的产品研发，后来被综合到UML规范之中，成为一种标准化的需求表述体系。虽然用例在软件研发和技术工作中应用的非常广泛，但是在互联网产品规划和设计中，并不经常使用，互联网产品的需求表达为了敏捷效率，通常采用原型加产品需求文档。 UML是英文Unified Modeling Language的缩写，中文称为统一建模语言或标准建模语言，是用例模型的建模语言，常用工具是Microsoft Office Visio。产品用例是一种通过用户的使用场景来获取需求的方式，每个用例提供了一个或多个场景，该场景说明了产品是如何和最终用户或其它产品互动，也就是谁可以用产品做什么，从而获得一个明确的业务目标。 分类 ① 用例图 用例图并不是画成了图形的用例。用例图包含一组用例，每一个用例用椭圆表示，放置在矩形框中；矩形框表示整个系统。矩形框外画如图所示的小人，表示参与者。参与者不一定是人

callback机制 callback机制提高代码的可重用性，还用于构建异常的测试用例。 广义的callback机制有post_randomize()，pre_body(),post_body(), pre_do(), mid_do()等，它们提供了额外的接口给用户。 原理 以在driver中提供callback函数接口为例，在发送transaction之前或之后需要对transaction进行处理，于是建立preSend()和postSend()任务，而不同的测试用例希望preSend或postSend进行不同的处理，所以这两个任务不能是Driver类的方法，这样毫无重用性可言，每搭建一个测试用例就需要新的Driver。 解决办法是 建立一个新的专门服务callback机制的类，将preSend()和postSend()放在该类中，之后在Driver中实例化该类，通过层次化引用的方法调用preSend和postSend ，这样就将两个任务和Driver分离开，不同的测试用例只需要重新定义不同的callback类，不需重新定义Driver。 这样还有一个问题，每一个测试用例需要不同的preSend()和postSend()也就是不同的callback类，如果将这些类都放在Driver中实例化的话，也丧失了可重复性

准备操作 首先需要在网上下载 HTMLTestRunner.py ，下载完成后将该文件放在Python根目录下的Lib目录中，例如 C:\Python27\Lib 代码 # 导入HTMLTestRunner from HTMLTestRunner import HTMLTestRunner import unittest # 用于识别测试用例 import time # 用于生成测试报告名称的后缀 # 识别得到要执行的测试用例 case_path = '...' # 测试用例文件所在的父目录 # test*.py代表测试用例文件都是以test开头.py结尾，文件名字必须符合变量命名规范 case_list = unittest . defaultTestLoader . discover ( case_path , pattern = 'test*.py' ) # 用w模式打开自动化测试报告文件 report_file = '...' # 测试报告的文件路径，文件可以不存在但父目录路径必须存在，报告文件是.html文件 with open ( report_file , 'w' ) as f : runner = HTMLTestRunner ( f , title = '报告标题' , description = '报告描述' ) runner . run ( case_list

转！！！！ 单元测试的重要性就不多说了，可恶的是python中有太多的单元测试框架和工具，什么unittest, testtools, subunit, coverage, testrepository, nose, mox, mock, fixtures, discover，再加上setuptools, distutils等等这些，先不说如何写单元测试，光是怎么运行单元测试就有N多种方法，再因为它是测试而非功能，是很多人没兴趣触及的东西。但是作为一个优秀的程序员，不仅要写好功能代码，写好测试代码一样的彰显你的实力。如此多的框架和工具，很容易让人困惑，困惑的原因是因为并没有理解它的基本原理，如果一些基本的概念都不清楚，怎么能够写出思路清晰的测试代码？ 今天的主题就是unittest，作为标准python中的一个模块，是其它框架和工具的基础，参考资料是它的官方文档： http://docs.python.org/2.7/library/unittest.html 和源代码，文档已经写的非常好了，我在这里记录的主要是它的一些重要概念、关键点以及可能会碰到的一些坑，目的在于对unittest加深理解，而不是停留在泛泛的表面层上。 unittest是一个python版本的junit，junit是java中的单元测试框架，对java的单元测试，有一句话很贴切：Keep the bar