测试用例设计

复杂软件驱动系统的 UCM 与 UML 复杂软件驱动系统有许多类型，包括面向对象、基于代理、实时和分布式系统。它们具有许多属性，例如大规模、协同性、分散控制、及时性、可靠性、变化多端及特色丰富的功能、运行时组织的流畅性，以及系统的升级需求等，这些属性使得它们无论从技术还是从管理复杂性的角度来看都是难以理解的。这些复杂系统经常被用于电信、防卫、宇航和工业控制等领域。 UML （统一建模语言）是一种通用目的建模语言，它可用于详细说明和构造软件系统（特别是面向对象和基于组件的系统）工件并使其可视化与文档化，也可用于商业建模和非软件系统。它包括用于各种模型描述与文档化的许多概念和表示符，并且拥有技术和工业团体的坚定支持。 作为UML的重要特色，用例（Use Case）被定义为某一特定用户（执行者）看得见具体结果的系统运行动作序列。在过去几年中，用于脚本和用例的各种表示法，以及基于它们的设计过程已经非常流行了。例如，“Rational统一过程”就是一种用例驱动的（Use-case driven）基于UML的方法学。在这种方法中，用例将5类模型（需求、分析、设计、实现和测试）捆绑在一起，这种模型描述了系统的局部表示。UML 1.3允许使用9种不同的图描述复杂软件驱动系统及其模型，每一种图提供了特定角度的模型观点，每一种图在语义上必须与所有其他图一致。本文中，这些图被分为两类。第1类称为“行为图

白盒测试案例 白盒测试案例 案例 根据题目画出需求的流程图 根据所画流程图写出相应的程序 分别编写各种逻辑覆盖法的测试用例并执行测试用例写出测试结果 语句覆盖 判定覆盖 条件覆盖 判定条件覆盖 组合条件覆盖 基本路径覆盖 案例 编写循环程序，要求输入读入某汽车销售人员的销售数（以台 计）和每台销售的基础提成数（元）、以及销售人员工种（正式工或临时工），计算并输出他的销售提成。若销售人员销售超过40台且基础提成超过400元，则超过部分按基础提成的1.5倍的来计算。超过50台，如果是正式员工，则超过50台的部分按基础提成的2倍的来计算，否则销售提成仍按照基础提成的1.5倍的来计算。编写流程图，并使用各种逻辑覆盖法编写测试用例。 根据题目，画出需求的流程图； 根据所画流程图写出相应的程序； /************************************************************ FileName: CalculateSalComm.cpp Author: Switch Version : 1.0 Date: 2016-03-30 Description: 计算销售提成 // 模块描述 Function List: // 主要函数及其功能 1. main 输出销售提成 2. calculateSaleComm 计算销售提成 ****************

一、易用性 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。产品用例是一种通过用户的使用场景来获取需求的方式，每个用例提供了一个或多个场景，该场景说明了产品是如何和最终用户或其它产品互动，也就是谁可以用产品做什么，从而获得一个明确的业务目标。 分类 ① 用例图 用例图并不是画成了图形的用例。用例图包含一组用例，每一个用例用椭圆表示，放置在矩形框中；矩形框表示整个系统。矩形框外画如图所示的小人，表示参与者。参与者不一定是人

第一阶段学习总结报告 曾经心怀澎拜，曾经满怀激情，曾经翘首等待这为期四个月的实训终于拉开帷幕。2015年的这个暑假对于我来说是最幸运而同时有特别重要的一个暑假，因为我非常幸运的来到了济宁惠普软件人才实训基地进行为期四个月的实训学习。第一天来到惠普我变被浓厚的企业文化深深的吸引，作为一家跨国公司，她有强大的包容性和多元性。实训期间采取公司制的这一策略让我们真正融入到公司的文化中，时刻以惠普员工的高标准来严格要求自己，磨练自己。 我学习的专业是软件测试，虽然在大学也开过“软件工程”这门课，但对测试这门行业的了解基本为零。通过几天几位导师和班主任和蔼可亲的指导以及全心全意的关怀，我对测试行情以及职业要求和发展等都有了较深入的了解。几天的测试基础的学习也是我越来越喜欢测试了，也更加坚定了我的选择。 众所周知，做测试职业工具是必不可少的，在学习了一些理论知识后，我们的美女导师徐老师就带领我们学习了第一个开源测试工具——testLink。第一次接触这个工具的时候我是丈二的和尚摸不着头脑，简直一头雾水，什么都不知道，课上跟着老师的思路做了一遍，虽然能做出来但是完全不明白做每一步的原因是什么。课下老师给了我们一个安装压缩包，让我们自己搭建环境，我不管是在网上百度也好找同学给帮忙也好几次都安装失败。软件XAMPP里的Ahache和Mysql总是启动不了，最后通过问老师才知道电脑的80端口被占用