第一篇：黑盒测试心得
“黑盒”测“外”不测“内”
“黑盒”测的是功能
黑盒测试也称功能测试或数据驱动测试。它在已知产品应具有的功能的条件下，通过测试来检测每个功能是否都能正常使用。在测试时，把程序看作一个不能打 开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否 能适当地接收输入数据而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。
“黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使 用，才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。
“黑盒”的两种基本方法
黑盒测试有两种基本方法，即通过测试和失败测试。
在进行通过测试时，实际上是确认软件能做什么，而不会去考验其能力如何。软件测试员只运用最简单，最直观的测试案例。
在设计和执行测试案例时，总是先要进行通过测试。在进行破坏性试验之前，看一看软件基本功能是否能够实现。这一点很重要，否则在正常使用软件时就会奇怪地发现，为什么会有那么多的软件缺陷出现？
在确信了软件正确运行之后，就可以采取各种手段通过搞“垮”软件来找出缺陷。纯粹为了破坏软件而设计和执行的测试案例，被称为失败测试或迫使出错测试。
黑盒测试的设计方法
黑盒测试是以用户的观点，从输入数据与输出数据的对应关系出发进行测试的，它不涉及到程序的内部结构。很明显，如果外部特性本身有问题或规格说明的规 定有误，用黑盒测试方法是发现不了的。黑盒测试法注重于测试软件的功能需求，主要试图发现几类错误：功能不对或遗漏、界面错误、数据结构或外部数据库访问 错误、性能错误、初始化和终止错误。
具体的黑盒测试方法包括等价类划分、因果图、正交实验设计法、边值分析、判定表驱动法、功能测试等。在使用时，自然要针对开发项目的特点对方法加以适当的选择。
◆ 等价类划分
等价类划分是一种典型的黑盒测试方法，用这一方法设计测试用例可以不用考虑程序的内部结构，只以对程序的要求和说明，即需求规格说明书为依据，仔细分析和推敲说明书的各项需求，特别是功能需求，把说明中对输入的要求和输出的要求区别开来并加以分解。
由于穷举测试的数量太大，以致于无法实际完成，促使我们在大量的可能数据中选取其中的一部分作为测试用例。例如，在不了解等价分配技术的前提下，测试 了1+1、1+2、1+3和1+4之后，还有必要测试1+5和1+6吗?能否放心地认为它们正确吗?那么1+999…（可以
输入的最大数值）呢？这个测试 用例是否与其他用例不同？是否属于另外一种类别？另外一个等价区间？这是软件测试员必须考虑到的问题。
等价类别或者等价区间是指测试相同目标或者暴露相同软件缺陷的一组测试案例。1+999…和1+13有什么区别呢？至于1+13，就像一个普通的加法，与1+5或者1+392没有什么两样，而1+999…则属于邻界的极端情况。假 如输入最大允许数值，然后加1，就会出现问题——也许就是软件的缺陷。这个极端案例属于一个单独的区间，与常规数字的普通区间不同。
等价类划分的办法是把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据当作测试用例。每一类的代表性数据在测试中的作用等价于这一类 中的其他值，也就是说，如果某一类中的一个例子发现了错误，这一等价类中的其他例子也能出现同样的错误。使用这一方法设计测试用例，首先必须在分析需求规 格说明的基础上划分等价类，列出等价类表。
在考虑等价类划分时，先从程序的功能说明中找出每个输入条件，然后为每个输入条件划分两个或更多个等价类。等价类可分两种情况：有效等价类和无效等价 类。有效等价类是指对程序的规格说明是有意义的、合理的输人数据所构成的集合；无效等价类是指对程序的规格说明是不合理的或无意义的输人数据所构成的集 合。
◆ 边界值分析
软件测试常用的一个方法是把测试工作按同样的形式划分。对数据进行软件测试，就是检查用户输入的信息、返回结果以及中间计算结果是否正确。
即使是最简单的程序，要处理的数据也可能数量极大。还记得在计算器上简单加法的全部可能性吗？再想一想字处理程序、导航系统和证券交易程序。使这些数 据得以测试的技巧（如果称得上的话）是，根据下列主要原则进行等价分配，以合理的方式减少测试案列：边界条件、次边界条件、空值和无效数据。
边界值分析（Boundary Value Analysis，BVA）是一种补充等价划分的测试用例设计技术，它不是选择等价类的任意元素，而是选择等价类边界的测试用例。实践证明，在设计测试用 例时，对边界附近的处理必须给予足够的重视，为检验边界附近的处理专门设计测试用例，常常可以取得良好的测试效果。BVA不仅重视输人条件边界，而且也从 输出域导出测试用例。
第二篇：黑盒测试技术实验报告
黑盒测试技术 — 三角形问题 实验报告 一、问题描述 输入三个整数 a、b、c，分别作为三角形的三条边，通过程序判断这三条边是否能构成三角形？如果能构成三角形，则判断三角形的类型并输出（等边三角形、等腰三角形、一般三角形），如果不构成三角形输出不能构成三角形。
要求:(1)输入三个整数 a、b、c，必须满足以下条件：1≤a≤200；1≤b≤200；1≤c≤200。
(2)容错处理：输入空值的提示；输入的值满足类型的提示；(3)不限制开发环境，不限制开发语言；(4)尽可能不对自己的程序进行测试设计。
(5)请分别采用边界值分析法、等价类分析法、决策表分析法、基于场景分析法设计测试用例；(6)正文格式（除源代码用小五号单倍行距），其他行距固定值 20，字号小四。
二、程序主要源代码 (标注：测试的源代码是哪位同学（学号姓名）编写的。)
三、程序界面（截图）
四、设计测试用例
1.用边界值测试方法设计测试用例
用边界值分析法设计测试用例，按照下列步骤进行：
（（1）
分析各变量取值 三角形三条边的取值范围都是 1-200，所以边长 A 的边界点为 1 和 200，边长 B的边界点为 1 和 200，边长 C 的边界点为 1 和 200。
（（2）
测试用例数 输入条件 边界值 测试数据 A 1,200 0,1,2,199,200,201 B 1,200 0,1,2,199,200,201 C 1,200 0,1,2,199,200,201
设计测试用例（给出所有测试用例）
三角形问题的测试用例 测试用例 编号 输入数据 预期输出 测试结果 a b c 1 0 100 100 边长 A 不合法
边长 A 不合法1 100 100 等腰三角形 等腰三角形 3 2 100 100 等腰三角形 等腰三角形 4 199 100 100 等腰三角形 等腰三角形 5 200 100 100 不是三角形 不是三角形 6 201 100 100 边长 A 不合法
边长 A 不合法100 0 100 边长 B 不合法
边长 B 不合法100 1 100 等腰三角形 等腰三角形 9 100 2 100 等腰三角形 等腰三角形 10 100 199 100 等腰三角形 等腰三角形 11 100 200 100 不是三角形 不是三角形 12 100 201 100 边长 B 不合法
边长 B 不合法100 100 0 边长 C 不合法
边长 C 不合法100 100 1 等腰三角形 等腰三角形 15 100 100 2 等腰三角形 等腰三角形 16 100 100 199 等腰三角形 等腰三角形 17 100 100 200 不是三角形 不是三角形 18 100 100 201 边长 C 不合法
边长 C 不合法
2.用等价类测试方法设计测试用例
（（1）首先分析题目中给出的条件和隐含的输入要求，输入条件如下：
条件：1<=边长 A<=200,1<=边长 B<=200,1<=边长 C<=200
隐含条件:A 输入条件 有效等价类 无效等价类 是否是三角形 1.1<=A<=200 2.1<=B<=200 3.1<=C<=200 4.A (3)设计测试用例，覆盖上表中的等价类，如表 1-3 表所示。（至少 20 条） 表 表 1-3 三角形问题的测试用例 测试用例 编号 输入数据 预期输出 覆盖等价类 测试结果 a b c 1 100 100 100 等边三角形 1,2,3,4,5,6,17 等边三角形 2 50 50 50 等边三角形 1,2,3,4,5,6,17 等边三角形 3 150 150 150 等边三角形 1,2,3,4,5,6,17 等边三角形 4 50 100 100 等腰三角形 1,2,3,4,5,6,15 等腰三角形 5 100 50 100 等腰三角形 1,2,3,4,5,6,14 等腰三角形 6 100 100 50 等腰三角形 1,2,3,4,5,6,13 等腰三角形 0 2 3 边长 A 不合法 7 边长 A 不合法 8 2 1 3 不是三角形 12 不是三角形 9 3 0 1 边长 B 不合法 8 边长 B 不合法 10 3 1 2 不是三角形 10 不是三角形 11 1 3 0 边长 C 不合法 9 边长 C 不合法 12 2 3 1 不是三角形 11 不是三角形 13 50 51 52 不是等腰三角形 1,2,3,4,5,6,16 一般三角形 14 51 52 50 不是等腰三角形 1,2,3,4,5,6,16 一般三角形 15 52 50 51 不是等腰三角形 1,2,3,4,5,6,16 一般三角形 16 100 100 101 不是等边三角形 1,2,3,4,5,6,19,20 等腰三角形 17 100 101 100 不是等边三角形 1,2,3,4,5,6,18,20 等腰三角形 18 101 100 100 不是等边三角形 1,2,3,4,5,6,18,19 等腰三角形 19 50 50 51 不是等边三角形 1,2,3,4,5,6,19,20 等腰三角形 20 50 51 50 不是等边三角形 1,2,3,4,5,6,18,20 等腰三角形 21 51 50 50 不是等边三角形 1,2,3,4,5,6,18,19 等腰三角形 3.用决策表测试方法设计测试用例 （（1）构建决策表 （（2）化简 测试用例 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 输入条件 是三角形 Y Y Y Y Y Y Y Y N N N N N N N N A=B Y Y N Y N Y N N N Y Y Y N N Y N A=C Y N Y Y Y N N N N Y Y N Y N N Y B=C Y Y Y N N N Y N N Y N Y Y Y N N 预期输出 不是三角形 等腰三角形 等边三角形 一般三角形 出错提示 测试用例 1 2,3,4 5,6,7 8 9-16 输入条件 是三角形 A=B A=C B=C 预期输出 不是三角形 Y 等腰三角形 Y 等边三角形 Y 一般三角形 Y 出错提示 Y （（3）化简后的测试用例设计 测试用例 编号 输入数据 预期输出 覆盖等价类 测试结果 a b c 1 50 50 50 等边三角形 1,2,3,4,5,6,17 等边三角形 2 50 50 51 等腰三角形 1,2,3,4,5,6,13 等腰三角形 3 51 50 50 等腰三角形 1,2,3,4,5,6,15 等腰三角形 4 50 51 50 等腰三角形 1,2,3,4,5,6,14 等腰三角形 5 1 2 3 不是三角形 12 不是三角形 6 1 3 2 不是三角形 11 不是三角形 7 3 2 1 不是三角形 10 不是三角形 8 2 3 4 一般三角形 1,2,3,4,5,6 一般三角形 9 3 2 4 一般三角形 1,2,3,4,5,6 一般三角形 10 4 3 2 一般三角形 1,2,3,4,5,6 一般三角形 4.基于场景的测试 （1 1）基本流和备选流图 （2 2）场景设计 场景 1 1 ：基本流 场景 2 2 ：基本流+ + 备选流 1 1 场景 3 3 ：基本流+ + 备选流 2 2 场景 4 4 ：基本流+ + 备选流 3 3 场景 5 5 ：基本流+ + 备选流 4 4 （3 3）） 测试用例设计 开始输入 输入 A,B,C 判断各边边长是否是在 1-200 A+B>C && A+C>B && B+C>A 备选流 1:边长不符合条件 备选流 2:不是三角形 是三角形 备选流 3:是等腰三角形 备选流 4:是等边三角形 一般三角形 结束 场景 A A B B C C 预期输出 测试结果1234 一般三角形 一般三角形2 0 0 0 0 0 0 边长错误 边长错误3247 不是三角形 不是三角形4 等腰三角形 等腰三角形5 等边三角形 等边三角形 5.测试结果分析与总结（至少 0 150 字，对测试过程中失败用例的原因进行分析，对学习了黑盒测试技术的学习总结） 在用等价类测试方法时，在测试无效等价类的结果和预期结果不一致，其原因是在设计程序时没有考虑无效等价类的这些测试用例的输出语句，黑盒测试技术是我们常使用的软件测试的方法，在测试中，我们需要将边界值测试，等价类测试，决策表测试，基于场景测试联合使用。任何一款软件都不可能做到完全测试，所以我们需要做的就是将黑盒测试中的方法尽可能结合使用，争取让软件少一些 bug。 黑盒测试的测试流程简单介绍 话说我们一直在做黑盒自动化测试，那我们究竟处于测试中的哪个位置呢？ 其实我们更多的是在执行测试提交报告和发现的软件Error，测试用例是如何设计的，为什么要这样设计又有多少人想过呢？黑盒测试中的测试用例设计的简单方法又有多少了解呢？我们常做的测试中哪些地方用到了例如等价类划分法？ 下面仅仅对黑盒测试的简单的测试流程进行下说明关于黑盒测试的其他内容会在以后的帖子中说明。 首先来了解两个名词： Statement of Work（SOW）软件使用说明书 Software Requirement Specification(SRS)软件需求规格说明书 1.需求分析阶段：对业务的学习，分析需求点。 2.测试计划阶段：测试组长就要根据SOW开始编写《测试计划》，其中包括人员，软件硬件资源，测试点，集成顺序，进度安排和风险识别等内容。 3.测试设计阶段：测试方案一般由对需求很熟的高资深的测试工程师设计，测试方案要求根据《SRS》上的每个需求点设计出包括需求点简介，测试思路和详细测试方法三部分的方案。《测试方案》编写完成后也需要进行评审。 4.测试方案阶段：主要是对测试用例和规程的设计。测试用例是根据《测试方案》来编写的，通过《测试方案》阶段，测试人员对整个系统需求有了详细的理解。这时开始编写用例才能保证用例的可执行和对需求的覆盖。测试用例需要包括测试项，用例级别，预置条件，操作步骤和预期结果。其中操作步骤和预期结果需要编写详细和明确。测试用例应该覆盖测试方案，而测试方案又覆盖了测试需求点，这样才能保证客户需求不遗漏。同样，测试用例也需要评审。 5.测试执行阶段：执行测试用例，及时提交Error和测试报告等相关文档。 做电子商务网站测试已经一个月了，这一个月基本上是熟悉网站产品和流程的一个过程，对网站的各个部分基本上都进行了一次测试，感觉电子商务网站主要注意以下几点： 1、注册和登录模块的测试 在测试该部分时，给我印象最深的就是： 1)注册成功，但登陆失败：注册时，密码设置为一些特殊的符号，比如：空格、%等，但登录时，失败。 后来经开发人反映出现这样的问题，原因是：在登录模块，对密码设置了一些限定。 2)登录时，没区分大小写，就是说，用小写字母注册的，登录时，用相应的大写字母登录也能成功。 出现问题的原因：登录时，没用MD5加密进行验证 2、购物车的测试 1)测试产品能否放入购物车中 2)当某种产品有购物数量限制时，超过这一数值，能否也能放入购物车中 3)购物车中的购物限制是否正确 3、支付流程测试 1)购物车中的产品能否正常支付 2)当支付完成，不等页面跳转，直接关闭浏览器，数据传递是否正确 3)当支付完成，等待页面跳转，跳转到得页面是否正确 4、网站某个模块间的数据传递是否正确 当网站某个模块涉及的数据传递比较多而且比较复杂时，一定要搞清楚数据是怎么传递的，因为这是最容易出现bug的地方。比如：下拉菜单的数据没有传递过来，或传递过来了，但不正确，这时就要静下心来，慢慢滤清思考，耐心去测试。 最后一点就是，在购买的过程中，也要考虑到并发，比如，当某种产品只剩一件了，这时两个用户或更多同时并发点击该产品，放入购物车中，那么在多个用户同时点击这个只剩一件的产品时，系统是否有相应的提示，或是，该产品能否都放入不同用户的购物车中，我上周测试的过程中，该问题是存在的，等待明天程序的解答和修改。 从事测试到现在已有半年多的时间，刚开始做为新人时，面对未接触过的系统中的每个模块，心中是有些慌张的。仅凭业务学习和前辈们讲的测试方法还是很难做到完全让自己放心，这可能是新人的通病，害怕测试不全面不深入。至少我在测试之初，是比较胆怯的。随着时间的推移，我发现自己越来越自信，特别是面对新的模块新的功能消除了那种恐惧感。总结了以前的一些心得，供大家交流： 一、根据自己的实际情况，做一个学习计划，边学边测，以学来熟悉侧，以测来巩固学，做到二者的融合；一开始会比较苦，毕竟很多都不熟悉，有时单据不能保存，有时流程走不下去，一定要坚持住；业务知识熟悉了，就好多了。 二、刚开始时因为业务不熟悉，需求也不熟悉，就开始测试任务。这时自己就看看测试用例，随便测测，看功能能不能正常走通。 1、根据功能做一个基本的测试计划；当然在做这个测试计划时可以先问下你的主测或是开发经理，有什么建议，毕竟他们经验比我们丰富。 2、开始测试时，严格按照测试用例来执行，当然等业务熟练后，自己可以写测试用例来执行，毕竟原有测试用例并未覆盖整个模块的功能；这样就可以补缺补漏。 3、在学习或测试中，有不懂的或是不明白的地方，尽量去问主测或是其他同事，但要有个度，毕竟别人都有自己的任务，不要一有问题就问，你可以将今天学习或是测试中存在的问题一条条记录下来，等中午休息或是下班前一刻向别人求教；也可回家后自己上网上搜索相关的知识解决问题。 三、学会换位思考，将自己当客户，发挥自己的想象找出客户存在的应用场景，在客户操作的基础上寻找测试突破口，假如实际经验积累不多，可上网查找或是询问别人；因为每个客户的操作不一样，会存在比较复杂业务逻辑，这时可以分解成一小块一小块测试，最后再从整体的角度入手；由简单到复杂，简单的测试通过后再做复杂的测试，而不是一开始就做复杂的测试。 四、随时记录学习到的新知识，特别是其他相关模块的知识；同时记录工作心得，特别是好的测试方法和测试思考方法；好记忆不如烂笔头，何况在这科技发达的时代，键盘随便敲敲，即清晰又明了，下次碰到相同问题可查看。 最后说一句，路是自己走出来的，测试也是自己测出来的。第三篇：黑盒测试的测试流程简单介绍
第四篇：web测试心得
第五篇：软件测试心得
点击咨询 