关于黑盒测试的探讨及感悟

1、关于工作中黑盒测试的探讨及感悟关于工作中黑盒测试的探讨及感悟 FSCTest:zhuhl概述从事黑盒测试工作一年多了，经过对项目需求文档的学习，评审，编写并维护测试用例，使用被测软件执行测试用例，提交bug单并做相关处理等测试相关活动的亲身实践体验，现总结一些自己对黑盒测试的看法与大家探讨交流，互相学习，共同提高目录目录 根据相关黑盒测试理论，结合自己的项目测试经历，把自己的理解及感悟融入下面的讨论话题中。 1，在工作中加强静态测试的重要性 2，测试用例的设计，更新维护和评审 3，有利于减少功能缺陷漏测的流程 4，回归测试的测试策略的选择 1，关于加强静态测试的重要性1.1静态测试（文档的检查

2、和审阅，不运行程序）静态测试（文档的检查和审阅，不运行程序） 静态测试的对象：项目开发过程的一切文档静态测试的对象：项目开发过程的一切文档（设计、需求，开发及测试文档等）（设计、需求，开发及测试文档等） 黑盒静态测试的对象： 主要是：（产品说明）需求文档及测试文档（需求的二义性，完整性，可测性，一致性，必要性等）1.2静态测试重要性的理论依据静态测试重要性的理论依据 1.2.1测试理论中的尽早测试原则： 越早的进行测试，修复问题花费的成本越小。据统计显示项目中的问题在需求阶段如果修改的成本是1，那么在开发编码阶段修改的成本会变成10，在测试阶段修改的成本大约是40或更高. 1.2.2静态测试的

3、其他优点： 加深对项目需求的理解和熟悉，可以有效提高测试用例的编写质量和覆盖度等。 1.2.3心理学研究告诉我们，人们常常愿意看到想要看到的事物。就是说我们进行静态测试时，要抱着找出需求文档描述有问题的心理，看完某段需求后，想想是否有异议，是否还存在其他问题等。1.3加强静态测试重要性的加强静态测试重要性的举例说明举例说明 我参与的某个项目需求中，有一个创建交易单的需求，该需求对允许的最小交易量值没有说明。结果后来开发人员做出来的该功能模块，可以成功创建交易量为0的交易单。 这明显是违反常识，没有实际意义，不正常的交易单（不应该被创建成功）。 如果我们测试员在静态测试时（检查或评审需求文档）或

4、者在设计测试用例阶段，对这一隐性需求向需求人员提出异议，也许就可以避免软件中出现的这类问题。1.4代价和说明代价和说明 1.4.1由于项目相关人员都没有尽早发现这个问题，现在要想修复它，需要需求人员修改需求文档，开发人员修改软件代码，测试人员需要提交bug单，修复后重新回归测试，对测试用例，bug单进行相应处理，还存在因为修改代码可能引起其他问题的潜在风险，成本大幅增加。 1.4.2当然静态测试不可能发现所有问题，我借这个例子，只是想让测试人员意识到加强静态测试的必要性和重要性，培养把问题解决在萌芽状态的习惯，比通过动态测试，发现问题，再”亡羊补牢”要好的多。1.5静态测试的方法 1.5.1R

5、ichard Bender的RBT基于需求的测试。 每个测试人员，分别各自审阅项目需求，对发现的需求问题进行记录。 1.5.2结对需求评审法（效率更高）。 测试人员对项目需求有一定理解后，2个测试人员组成一个小组，用一台电脑，看完同一条需求（1-3分钟），一人讲述对需求的理解，另一人无异议，继续看下一条需求。 如果二人理解不一致，分别记录二人的理解，对需求理解不一致的到达一定数量或阶段，进行相应处理。 2，关于测试用例的设计，更新维护和评审 2.1测试用例的设计技术： 2.1.1设计原则： 设计尽可能少的测试用例去尽可能多的发现软件的缺陷（测试用例的有限性，代表性和特殊性）。 2.1.2设计技

6、术： 在正确理解项目需求文档的基础上，综合运用等价类划分，边界值分析，因果图法，错误推测法等编写验证软件功能实现，界面，数据库等方面的测试用例。 2.1.3 等价类： A，有效等价类：对软件来说是期望的，有意义的数据集合。 检验是否实现了预期的功能及性能。 B，无效等价类：对客户需求来说是不合理和无意义的数据集合，它验证软件对无效数据的处理能力。 边界值：选取需求中要求的刚好等于，刚刚大于或小于，常用值等代表性的值。 因果图：利用图解法分析输入的各种组合情况，转换为判定表，设计测试用例。 判定表：规则规则1规则规则2规则规则3条件条件1条件条件2等等等等结果结果1结果结果2关于测试用例的设计方

7、法 举例：2= x=5 3= yB-C-D）改为 (A-D-C-B)非标准的操作步骤顺序，若缺乏容错处理则容易出现程序错误。 3.4.3混票法：把不常用的功能与常用功能组合 4，关于回归测试的测试策略的选择 4.1回归测试： 提交的bug被修复后并发布新版本，需要对以前的测试用例进行重新测试。 4.2回归测试的策略： 4.2.1全部用例回归测试（回归量大，手工测试不可取） 4.2.2基于风险选择测试 运行重要及可疑的测试用例（该模块部分用例） 4.2.3再测试修改的功能模块的用例 (该模块所有部用例） 执行限于被改变的模块和它的接口的测试用例4.3回归测试的意义和手工回归测试的策略选择 意义： 回归测试的执行是必要的：开发人员在为修复bug而修改 代码的过程中，不可避免的会对软件质量造成某种潜在不利影响，比如修复某个bug后，可能会产生新的问题或之前修改的bug又出现在系统中，不回归测试就会影响软件质量。 策略： 回归测试比较理想的情况下，是通过自动化测试执行大部分测试用例的。如果暂不具备自动化回归测试的条件，就应该根据实际情况选择相应的策略进行手工回归测试。结束语结束语 测试的过程是一个不断学习，实践，探讨，总结，优化的过程。 祝大家在工作中不断进步，事业