黑盒测试

黑盒测试 一、黑盒测试的概述 黑盒测试（Black-box Testing）被称为 功能测试 或 数据驱动测试 。 黑盒测试说白了就是一个 黑盒子 ， 不考虑 程序 内部逻辑结构 和 内部特性 ，只关注软件的功能需求。 二、黑盒测试需要发现的几个问题 功能是否正确，是否有遗漏。 界面是否错误。 数据结构或外部数据库访问错误。 性能错误。 初始化和终止错误。 三、常见的黑盒测试方法 功能性测试 性能测试 安全性测试 兼容性测试 稳定性测试 可靠性测试 安装卸载测试 四、黑盒测试用例设计的方法 1、等价类划分法 将程序所有可能的 输入域（有效的和无效的） 划分成 若干个等价类 。然后从每个部分中选取少数 具有代表性 的数据进行测试，可以避免穷举产生的大量用例。 等价类是指某个 输入域 的 子集合 。 等价类划分一般划分为两种情况： 有效等价类 和 无效等价类 。 1.1 有效等价类 对需求规格说明而言， 合理的、有效的 输入数据构成的集合。 1.2 无效等价类 对需求规格说明而言， 不合理的、无效的 输入数据构成的集合。 1.3 等价类划分的要求 划分的子集是 互不相交 的， 符合完备测试 ， 避免出现冗余 。 1.4 等价类划分的方法 按区间划分 按数值划分 按数值集合划分 按限制条件或规则划分 按处理方式划分 1.5 等价类划分法常用的的划分原则 如果规定输入的 取值范围或个数 时

什么是软件测试： 软件测试（英语：software testing），描述一种用来促进鉴定软件的正确性、完整性、安全性和质量的过程。换句话说，软件测试是一种实际输出与预期输出间的审核或者比较过程。软件测试的经典定义是：在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。 为什么要进行软件测试： 软件测试的目的,第一是确认软件的质量，其一方面是确认软件做了你所期望做的事情（Do the right thing），另一方面是确认软件以正确的方式来做了这个事情（Do it right）。第二是提供信息，比如提供给开发人员或程序经理的回馈信息，为风险评估所准备的信息。第三软件测试不仅是在测试软件软件产品本身，而且还包括软件开发的过程。如果一个软件产品开发完成之后发现了很多问题，这说明此软件开发过程很可能是有缺陷的。因此，软件测试的第三个目的是保证整个软件开发过程是高质量的。 黑盒测试： 黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。

本周课程把第六章测试的内容提前讲了一部分，主要为实验1服务，讲了有关测试的概念、作用和基本方法。 有关测试 1.好的测试：能发现错误，不冗余，具有最佳特性，复杂度适中。 2.测试种类：分为单元测试、集成测试、系统测试。 图1-测试的种类 3.测试需要有正确的态度：测试时要让程序尽快出错，因为只有发现了错误才有改正错误的机会。把错误改正后，代码质量才能得到提升。 测试用例 1.测试用例是输入+执行条件+期望结果。测试用例的开发是有其特定目的的，一般来说是测试程序某一部分的正确性或性能。 2.测试流程 ： 写测试用例->组织测试用例（一般在和src同级的文件夹test中）->执行测试用例->获取状态和报告->根据报告修改并重新测试直到测试通过 测试优先编程/测试驱动开发（TDD） 1.在写源代码之前先写测试，尽早而经常地经常测试，而不是把测试留到最后。最后测试通常会降低效率，因为总体测试之前没有对代码的任何部分进行测试，每一处都有可能出错。 2.步骤：写规范（即指定输入和输出的关系）->写规范的测试用例->写代码->执行测试 3.规范也有可能是有漏洞的。写测试可以发现规范中的错误或者不完整，及时修正有利于程序的开发。 图2-规范的书写 使用JUnit进行自动化单元测试 1.JUnit是一个Java语言的单元测试框架。Junit 测试也是程序员测试，即所谓的白盒测试

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

0.认识需求 1. 业务需求：组织或客户的高层次目标、 描述为什么要开发系统 (Why)，希望达到什么样的目标、 一般 2-5 条，记录在 《 软件愿景和范围 》 文档中。 2. 用户需求： 从 用户角度 ，描述 用户使用产品必须要完成什么任务； 用户能使用系统来做什么(What)；通过用户访谈、调查、对用户使用场景进行整理等方法获取。 3. 功能需求： 描述 开发 人员 在产品中实现的软件功能， 描述开发 人员如何设计具体的解决方案来实现这些 需求 ( how )， 数量 往往比用户需求高一个数量级， 属于 《 软件需求规格说明书 》 的一部分。 <0>软件需求规格说明书 其包括： 功能需求： 1. 用户需求 2. 系统需求： 用于描述包含多个子系统的产品 ( 即系统 ) 的顶级需求，它是从系统实现的角度描述的需求，有时还需要考虑相关的硬件、环境方面的需求。 3. 业务规则： 业务规划本身并非软件需求，因为它们不属于任何特定软件系统的范围。然而，业务规则常常会限制谁能够执行某些特定用例，或者规定系统为符合相关规则必须实现某些特定功能。它包括企业方针、政府条例、工业标准、会计准则和计算方法等。有时，功能中特定的质量属性（通过功能实现）也源于业务规则。所以，对某些功能需求进行追溯时，会发现其来源正是一条特定的业务规则。 非功能需求： 1. 质量属性：产品 必须具备的属性或品质

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

灰盒测试 灰盒测试，是介于 白盒测试 与 黑盒测试 之间的一种测试，灰盒测试多用于 集成测试 阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。灰盒测试不像白盒那样详细、完整，但又比黑盒测试更关注程序的内部逻辑，常常是通过一些表征性的现象、事件、标志来判断内部的运行状态。 定义 灰盒 测试由方法和工具组成，这些方法和工具取材于应用程序的内部知识和与之交互的环境，能够用于 黑盒测试 以增强测试效率、错误发现和错误分析的效率。 学术含义 灰盒 (Gray Box)是一种程序或系统上的工作过程被局部认知的装置。灰盒 测试，也称作灰盒分析，是基于对程序内部细节有限认知上的 软件调试 方法。测试者可能知道 系统组件 之间是如何互相作用的，但缺乏对内部程序功能和运作的详细了解。对于内部过程，灰盒测试把程序看作一个必须从外面进行分析的 黑盒 。 灰盒 测试通常与web服务应用一起使用，因为尽管应用程序复杂多变，并不断发展进步， 因特网 仍可以提供相对稳定的接口。由于不需要测试者接触 源代码 ，因此灰盒测试不存在侵略性和偏见。开发者和测试者间有明显的区别，人事冲突的风险减到最小。然而，灰盒测试相对 白盒测试 更加难以发现并解决潜在问题，尤其在一个单一的应用中，白盒测试的内部细节可以完全掌握。 灰盒测试结合了白盒测试和 黑盒测试 的要素。它考虑了用户端、特定的系统知识和操作环境。它在

测试方法的划分 一般的，从看不看代码来划分黑、白盒测试。看代码和内部接口称为白盒测试，否则是黑盒测试方法。 而从软件是否运行的角度来划分静态和动态测试。不运行代码是静态测试，反之就是动态测试。 那么从我们人来参与的角度来看人工测试和自动化测试的。 黑、白、灰盒测试 刚才说了，我们从看不看代码来划分黑、白盒测试。 那黑盒测试可以有静态测试和动态测试，也可以有人工测试和自动化测试。 当然，白盒测试也是一样的。 比如我们要测这个自动售货机。 我们投币然后得到饮料；或者刷卡、扫码等都能得到想要的饮料。 我们做黑盒测试就是测试投币相关的逻辑、选择饮料相关的逻辑，找零或其他的逻辑。 这是我们不管内部结构，只是根据一些数据测试输入输出，比如投币5毛钱，却能得到一瓶2.5的饮料，这就是bug了。 等等等..... 除此之外，我们还需要看内部代码的逻辑，比如如何处理银行和第三方支付的接口逻辑，本地的饮料存储、统计等，看看相关关联的数据之间的交互。这些都是白盒测试范畴。 在测试之前，我们要搞清楚被测对象应该是什么样的，然后实际做出来的和预期进行比较，这样就能及时的发现缺陷；根据被测对象不同，而采用不同的测试方法。 白盒测试 白盒测试是依据被测软件分析程序内部构造，并根据内部构造设计用例，来对内部控制流程进行测试，可完全不顾程序的整体功能实现情况。 白盒测试是基于程序结构的逻辑驱动测试。

网上查找了大量关于状态迁移法的知识，都没有得到自己想要的内容，因此自己动手来记录这个测试用例设计方法，首先我在mantis上筛选了一些常用的缺陷状态，如下； 新建 new 测试人员新建一个缺陷记录 已分派 assigned 将缺陷指派给对应的开发 已确认 confirmed 开发确认这是的确是缺陷，并且后续会处理 打回 feedback 开发认为这不是缺陷，打回给测试，不做修改 已打开但未处理 open 将缺陷置为打开状态，开始修改 已解决但未验证 resolved 缺陷已被开发修改，但没有被测试 已解决并已验证 fixed 缺陷已被开发修改，并且测试通过 重新打开 reopen 被开发修改过的缺陷，未通过测试验证 延期 suspended 缺陷当前不做修改或无法修改，需要延期处理 已关闭 closed 缺陷已确认被修复，并没有再复现，关闭 除了上述的状态以外，还有acknowledged(公认)、unable to reproceduce(无法复现)、duplicate(重复问题)、not fixable(无法修复)、no change required(不是问题)、won't fix(不做修改)等等 既然状态已经得到了，那么接下来就开始尝试使用状态迁移法来设计用例， 第一步： 先在表格中找出有关联的状态，并标记出来：行中表示上一个状态，列中表示下一个状态，归纳出的表格如下图所示

软件工程知识技能水平高低的主要体现方面 1. 开发语言：至少熟练掌握一门编程语言 2. 数据结构与算法：算法是软件工程师的重点知识结构，算法的掌握情况往往能够决定软件工程师的成长高度 3. 开发环境：熟练掌握Windows、Linux等大型主流操作系统的操作，熟练掌握编程环境配置与软件环境部署 4. 软件开发流程： 熟悉掌握瀑布模型、敏捷开发等软件工程开发的流程。了解软件开发各周期或阶段的目标以及作用。了解软件开发的一些原则技术及方法 5. 团队协作能力：队员间在各个开发环节需要沟通协作 软件工程知识技能水平测评试题 一.选择题（共40分，一题4分） 1. 软件生命周期一般包括三个时期：软件定义期、软件开发期和软件运行期。下述（ ）不是软件开发期所应包含的活动。 A. 可行性分析 B. 需求获取和需求建模 C. 软件体系结构设计和数据设计 D. 软件集成与系统测试 答案：D 软件开发期所应包含的活动有：可行性分析、需求获取和需求建模和软件体系结构设计和数据设计。 2. “软件危机”是指（ ） A. 大众不适应软件的使用 B. 软件开发相关人才过少 C. 软件开发和维护中出现的一系列问题 D. 大量黑客出现 解析：C 软件危机指的是随着软件规模不断扩大而产生的一系列开发与维护的难题 3. 下列哪个不是瀑布模型的优点（ ） A. 项目提供了按阶段划分的检查点 B. 当前一阶段完成后