等价类

windows基础 软件定义 计算机=硬件加软件 软件=程序(program)+文档(document) 软件测试的对象：程序和文档都要测试 软件开发阶段划分 阶段一：需求分析阶段(由需求分析人员完成；产出物：《需求规格说明书》) 阶段二：设计阶段(由系统架构师/分析师完成；产出物：《概要设计说明书》和《详细设计说明书》) 阶段三：编码阶段(由开发人员完成/程序员完成；产出物：程序/代码) 不同的开发阶段引入的bug比例如何? 需求分析阶段引入的bug最多（大概占bug总数的55%左右） 其次是设计阶段（大概占缺陷总数的25%左右） 最少的是编码阶段（大概占缺陷总数的15%左右） 还有5%左右的缺陷是由系统兼容性或者配置原因造成的。 需求分析阶段引入的bug最多，其次是设计阶段，引入bug阶段最少的是编码阶段 因此：1）在测试中不能只测程序，文档也必须测 2）测试工作应尽早介入，并且贯穿整个开发周期始终(尽早测试原则，不断测试原则) 什么是软件缺陷 1.软件的缺陷–defect,bug 2.软件缺陷的定义：1）需求要求的功能没有实现 2）实现了需求没有的功能(画蛇添足) 3）软件出现了指明不应出现的错误 4）需求虽未明确指明，但是应该实现的功能没有实现 eg:法规； 说明：需求不是完美的，有可能有遗漏，但是测试人员应该专业，发现bug就要提交，即使需求中没有提及 5）软件不易使用

软件测试的基本知识点 软件的分类 C/S与B/S架构 软件测试的定义 软件测试的目的 软件测试的分类 软件生命周期 生命周期模型 1.瀑布型生命周期模型 2.V模型 3.敏捷开发模型 软件测试的基本流程 测试设计用例设计方法 等价类划分法 边界值分析法 场景法 错误推测法 测试用例的编写与评审 软件的分类 软件分为两大类：系统软件、应用软件。 软件测试的对象是：程序、数据、文档。（主要为程序） C/S与B/S架构 C/S ：就是我们一定要安装安装一个客户端才能够使用的软件。 缺点：每次更新都要更新服务端和客户端。 B/S ：只需一个浏览器就可以访问服务。 优点：只需更新服务器不需要更新浏览器，用户主动性比较高。 软件测试的定义 使用人工和自动的手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。 软件测试的目的 1.软件测试是为了发现程序存在的代码或业务逻辑错误 2.软件测试是为了检验产品是否符合客户的需求 3.软件测试是为了提高用户的体验 软件测试的分类 按测试技术划分：白盒测试、黑盒测试、灰盒测试 对象是否运行划分：动态测试、静态测试 按不同测试手段划分：手工测试、自动化测试 按测试包含的内容划分：功能测试、界面测试、安全测试、兼容性测试、易用性测试、性能测试 其他测试：冒烟测试、回归测试、探索性测试/自由测试 冒烟测试–>主干

1.黑盒测试： 功能测试：1.逻辑功能测试 2.界面测试 3.易用性测试 4.安装测试 5.兼容性测试 性能测试： 1.时间性能 2.空间性能 3.一般性能 4.稳定性 5.负载测试 6.压力测试：压力测试是给软件不断加压，强制其在极限的情况下运行，观察它可以运行到何种程度，从而发现性能缺陷 压力测试是测试软件的瓶颈和极限 负载测试是性能在极限情况下能坚持多久 回归测试：我们提了一个bug，开发人员改完后再次测试，包括和这个bug有关的模块 冒烟测试：测试主要功能 随机测试（探索测试 ）：对于软件的一些重要功能，新增的功能，和容易出错的地方进行复测，可以结合回归测试一起测试 等值分析测试=等价类划分+边界值分析测试 3.等价类划分法：我们发现我们用户所有可能输入的数据，划分成了若干份（也可称为子集），然后从每一个子集中选取 少数具有代表性的数据作为测试用例，这种测试用例称为‘等价类划分法’ 等价类划分是一种重要的，常用的黑盒测试方法，它将不能穷举的测试过程进行合理分类，从而保证完整性和代表性 有效等价类：输入合理的数据集合 无效等价类：输入不合理的数据集合 思考步骤： 1.确定有效等价类和无效等价类 2.有效等价类划分（题目条件，注意边界值，中间再随意找个值） 3.无效等价类划分（跟有效等价类相反，和其他特殊情况（中文，英文，特殊符号，空格，空值）） 一个框输入正确的值

csdn测试用例设计白皮书文档地址： https://blog.csdn.net/vincetest/article/details/1478552 用例编写步骤： 拿到测试需求 -> 分析需求（画思维导图） -> 编写用例 -> 划分用例优先级 用例编写特性： · 一致性：主要包括用例模板一致；各同事的编写手法一致；以及用例的细粒度一致。 · 覆盖率：主要包括对需求的覆盖（也包含隐含的需求）；新需求可能对那些功能会产生影响的覆盖；对各种场景的覆盖等 。 ·可执行性：主要是指步骤易于理解、信息描述准确、且能快速识别出测试点 。 ·执行准确性：是指用例执行的准确度，本身没什么技术含量。但这里需要注意的是执行人对待执行用例的态度。不要因为用例简单或者一些外界的因素，导致部分用例未实际执行标为通过的情况。 ·持续更新：要及时不断的更新，要尽量减少用例库中失效的用例 。 ·复用性：主要用例可以被不断的复用，从而减少维护成本 用例设计方法： 1. 等价类与边界值 （重点方法） 等价类：等价类划分法是把所有可能输入的数据，有无效等价类和有效等价类（即正确输入和非法输入），即程序的输入域划分策划国内若干部分（子集），然后从每一个子集中选取少数具有代表性的数据作为测试用例。方法是一种重要的、常用的黑盒测试用例设计方法。 边界值：边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法

概述 Polya定理或者更多时候Burnside引理是用来解决等价类计数的有力手段 考验构造能力 等价类计数 定义 通过某些操作相同称为等价，等价的只算一次 性质 自反性 对称性 传递性 这几个性质间接说明了，关于这些操作，不同的等价类是一个群 \(e.g.\) 1.由 \(a,b\) 构成的长度为 \(2n\) 的串，翻转同构计数 回文串:前一半与后一半对应: \(2^n\) 非回文串，两两配对: \(\frac{2^{2n}-2^n}{2}\) \(Ans=2^n+\frac{2^{2n}-2^n}{2}=\frac{2^{2n}+2^n}{2}\) 这给了我们一种思路， 为每个元素分配权重:不能让这个元素变化的操作方法数 2.四方块问题: \(2*2\) 红蓝涂色方格旋转同构 首先说明一个问题,虽然"旋转"这个操作有无数种，但旋转 \(\pi\) 与 \(-\pi\) 这样同样效果的变换只会算一种,而且旋转后不符合条件的(如旋转不是 \(90\) 倍数度)也不算进去，因此这题中合法的就只有 \(4\) 种旋转方法 真实情况: 分配权重后(每一列都是一个等价类): Burnside引理 对刚才那题，如果变成 \(3*3\) 甚至 \(4*4\) 方格，枚举元素就很困难了 考虑转换枚举对象，枚举少的，算出多的 具体而言就是枚举数量比 计数对象 更少的 变换

The world is big and life is short . Live the life the way you want . 世界很大 生命很短，要过成自己想要的样子呀才行 在这里对测试过程中如何保障覆盖率做个简单的总结，希望对大家有所帮助 一、测试需求分析需全面 需求分析分两步： 1.测试需求的来源 　　　　1）显式需求 　　　　　　a.原始需求说明书或需求矩阵列表 　　　　　 b.产品规格书 　　　　　　c.软件需求文档 　　　　　　d.有无继承文档 　　　　　　e.经验库 　　　　　　f.通用的协议规范 　　　　2）隐式需求 　　　　　　用户的主观感受，市场的主流观点，专业人士的评价分析 　　2.需求分析，产生测试需求文档 　　　　将不同的需求来源划分成一个个需求点，针对每一点进行测试分析： 　　　　　　1）界定测试范围 　　　　　　2）利用各种测试设计的方法差生测试点 　　　　在测试方面，注意： 　　　　　　1)分析出口入口。从入口分析，将可能出现的环境，条件，操作等内容分类分类组合，然后根据测试达人的方法进行整合，逐一验证。从出口分析，将可能出现的结果进行统计，根据结果的不同追根溯源，再找到不同的操作以及条件等内容，统计成文档，逐一验证。 　　　　　　2）多种测试手法的学习和使用。大家可能更多的关心测试方法，但是具体操作的手法也是需要注意的

在过去的几周里，我们学习了黑盒测试，今天对黑盒测试进行总结。 黑盒测试： 方法概述： 　　　这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。黑盒测试又叫做功能测试或数据驱动测试。 测试目标： 　　（1）检查程序功能能否按需求规格说明书的规定正常使用，测试各个功能是否有遗漏，检测性能等特性要求是否满足。 　　（2）检测人机交互是否错误，检测数据结构或外部数据库访问是否错误，程序是否能适当地接收输入数据而产生正确的输出结果，并保持外部信息（如数据库或文件）的完整性。 　　（3）检测程序初始化和终止方面的错误。 黑盒测试的方法分为：等价类划分法，边界值分析法，因果图法 由于等价类划分法在前面已经介绍过，在此不再赘述，详见： http://www.cnblogs.com/yueyingky/p/4357729.html 下面介绍边界值分析法： 概念： 　　边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。 使用边界值分析法的原因： 　　无数的测试实践表明，大量的故障往往发生在输入定义域或输出值域的边界上，而不是在其内部。因此，针对各种边界情况设计测试用例，通常会取得很好的测试效果。

面向对象软件工程知识点 1．封装是指把对象的（A）结合在一起，组成一个独立的对象。 A．属性和操作 B．信息流 C．消息和事件 D．数据的集合 2．状态图和活动图建立了UML面向对象开发过程中的对象动态（B）模型。 A．交互 B．状态 C．体系结构 D．软件复用 3．UML的（C）模型图由活动图、顺序图、状态图和合作图组成。 A．用例 B．静态 C．动态 D．系统 4．在UML的需求分析建模中，对用例模型中的用例进行细化说明应使用（A）。 A．活动图 B．状态图 C．配置图 D．构建图 5．设计模式就是对（D）的描述或解决方案，往往直接对应一段程序代码。 A．某个构件 B．成熟的设计 C．一个用例 D．特定问题 6．类和对象都有属性，它们的差别是：类描述了属性的类型，而对象的属性必须有（C）。 A．正负号 B．动作 C．具体值 D．私有成员 7．顺序图的模型元素有（A）、消息、生存线、激活期等，这些模型元素表示某个用例中的若干个对象和对象之间所传递的消息，来对系统的行为建模。 A．对象 B．箭头 C．活动 D．状态 8．状态图可以表现（B）在生存期的行为、所经历的状态序列、引起状态转移的事件以及因状态转移而引起的动作。 A．一组对象 B．一个对象 C．多个执行者 D．几个子系统 9．使得在多个类中能够定义同一个操作或属性名，并在每一个类中有不同的实现的一种方法是（B）。 A．继承

一、前置知识点： 1、了解软件相关概念； 2、有一定的软件测试基础； 3、了解测试流程； 4、了解测试生命周期 二、熟悉常用术语： 黑盒测试、灰盒测试、白盒测试（功能划分）； 功能测试、性能测试、安全测试（职业划分）; 兼容性测试 、易用性测试、 UI元素测试（易用点划分）; 三、测试用例是什么？ 答：测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个 程序 路径或核实是否满足某个特定需求。 测试用例是测试工作的核心、是一组在测试时输入输出的标准、是软件需求的具体对照。 四、测试用例有什么作用？ 1、检验软件是否满足客户需求； （1、通过编写测试用例，可以把产品文档的内容逐一进行测试防止遗漏；2、也可以能更好的知道软件的各个功能及作用；3、及时消除需求文档中的歧义及错误的地方，以便可以及时纠正，避免后期的不必要的麻烦与损失） 2、体现一个测试人员的工作量； （通过编写测试用例，按照自己每天的工作量，可以推测出完成该测试任务需要多久，以便可以合理划分时间，以及汇报该测试任务所需时间，以便进行团队及领导的后续安排） 3、展现测试用例的设计思路； （通过编写测试用例，可以理清思路，设计出合适的测试计划，对产品有一个更好的认识与把握） 五、测试员用例包含那些内容？ 用例编号、用例名称、测试背景、前置条件、优先级、重要级、测试数据、测试步骤

软件测试用例总结 测试用例的基本要素 测试用例的设计方法 基于需求的设计方法 等价类 边界值 因果图 正交排列 场景设计法 错误猜测法 测试用例的有效性 测试用例的粒度和评价 测试用例的基本要素 回归测试的的概念 ：测试用例是为了实施测试而向被测试系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。 （好的测试用例是一个不熟悉业务的人也能依据用例来很快的进行测试） 评价测试用例的标准： 用例表达清楚，无二义性 用例可操作性强 用例的输入与输出明确，一条用例只有一个预期结果 用力的可维护性好 用例对需求的覆盖性高 暴露程序Bug的能力强 测试用例给我们带来的好处 * 测试执行者的依据 * 使得工作可重复，自动化测试的基础 * 评估需求的覆盖率 * 用例的复用 * 积累测试的方法思路以供后续借鉴 使用中带来的困扰 测试用例的设计是费时费力的工作，往往设计测试用例所花费的时间比执行所花费的时间还多 解决如下问题 测试的覆盖率无法衡量；对新版本的重复测试很难实施 不确定是否较全面的测试了所有功能；存在大量冗余测试影响测试效率 测试用例的设计方法 基于需求的设计 RBT是基于需求的测试方法，会使测试更加高效，因为它使测试专注于质量问题产生的根源，即 需求 。 基于需求的测试是一种最根本的软件测试，重点关注于以下两个关键问题： 验证需求是否正确、完整、无二义性