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

关于工作中黑盒测试的探讨及感悟 FSCTestzhuhl,,概述,从事黑盒测试工作一年多了，经过对项目需求文档的学习，评审，编写并维护测试用例，使用被测软件执行测试用例，提交bug单并做相关处理等测试相关活动的亲身实践体验，现总结一些自己对黑盒测试的看法与大家探讨交流，互相学习，共同提高,目录,根据相关黑盒测试理论，结合自己的项目测试经历，把自己的理解及感悟融入下面的讨论话题中。 1，在工作中加强静态测试的重要性 2，测试用例的设计，更新维护和评审 3，有利于减少功能缺陷漏测的流程 4，回归测试的测试策略的选择,,1，关于加强静态测试的重要性,1.1静态测试（文档的检查和审阅，不运行程序） 静态测试的对象项目开发过程的一切文档（设计、需求，开发及测试文档等）,黑盒静态测试的对象 主要是（产品说明）需求文档及测试文档（需求的二义性，完整性，可测性，一致性，必要性等）,1.2静态测试重要性的理论依据,1.2.1测试理论中的尽早测试原则 越早的进行测试，修复问题花费的成本越小。据统计显示项目中的问题在需求阶段如果修改的成本是1，那么在开发编码阶段修改的成本会变成10，在测试阶段修改的成本大约是40或更高. 1.2.2静态测试的其他优点 加深对项目需求的理解和熟悉，可以有效提高测试用例的编写质量和覆盖度等。 1.2.3心理学研究告诉我们，人们常常愿意看到想要看到的事物。就是说我们进行静态测试时，要抱着找出需求文档描述有问题的心理，看完某段需求后，想想是否有异议，是否还存在其他问题等。,1.3加强静态测试重要性的举例说明,我参与的某个项目需求中，有一个创建交易单的需求，该需求对允许的最小交易量值没有说明。结果后来开发人员做出来的该功能模块，可以成功创建交易量为0的交易单。 这明显是违反常识，没有实际意义，不正常的交易单（不应该被创建成功）。 如果我们测试员在静态测试时（检查或评审需求文档）或者在设计测试用例阶段，对这一隐性需求向需求人员提出异议，也许就可以避免软件中出现的这类问题。,1.4代价和说明,1.4.1由于项目相关人员都没有尽早发现这个问题，现在要想修复它，需要需求人员修改需求文档，开发人员修改软件代码，测试人员需要提交bug单，修复后重新回归测试，对测试用例，bug单进行相应处理，还存在因为修改代码可能引起其他问题的潜在风险，成本大幅增加。 1.4.2当然静态测试不可能发现所有问题，我借这个例子，只是想让测试人员意识到加强静态测试的必要性和重要性，培养把问题解决在萌芽状态的习惯，比通过动态测试，发现问题，再”亡羊补牢”要好的多。,1.5静态测试的方法,1.5.1Richard Bender的RBT基于需求的测试。 每个测试人员，分别各自审阅项目需求，对发现的需求问题进行记录。 1.5.2结对需求评审法（效率更高）。 测试人员对项目需求有一定理解后，2个测试人员组成一个小组，用一台电脑，看完同一条需求（1-3分钟），一人讲述对需求的理解，另一人无异议，继续看下一条需求。 如果二人理解不一致，分别记录二人的理解，对需求理解不一致的到达一定数量或阶段，进行相应处理。,,2，关于测试用例的设计，更新维护和评审,,2.1测试用例的设计技术 2.1.1设计原则 设计尽可能少的测试用例去尽可能多的发现软件的缺陷（测试用例的有限性，代表性和特殊性）。 2.1.2设计技术 在正确理解项目需求文档的基础上，综合运用等价类划分，边界值分析，因果图法，错误推测法等编写验证软件功能实现，界面，数据库等方面的测试用例。,,2.1.3 等价类 A，有效等价类对软件来说是期望的，有意义的数据集合。 检验是否实现了预期的功能及性能。 B，无效等价类对客户需求来说是不合理和无意义的数据集合，它验证软件对无效数据的处理能力。 边界值选取需求中要求的刚好等于，刚刚大于或小于，常用值等代表性的值。,因果图利用图解法分析输入的各种组合情况，转换为判定表，设计测试用例。,,关于测试用例的设计方法,举例 2 x5 3 y6,,,,,,,x,y,2,5,3,6,,有效等价类,,边界值,2.2测试用例更新维护的重要性,2.2.1设计高质量的测试用例是测试人员重要的价值体现，也有很大挑战性。 2.2.2测试用例的质量和完整性，对软件的测试效果和质量保证十分重要，随着项目进度和需求变化，编写的测试用例的维护（新增，修改用例和删除无效的用例）变得很重要，无效甚至是错误或互相冲突的测试用例可能会对以后测试用例的再次执行造成较大的干扰及困惑。 2.2.3项目测试用例的质量的高低（有效，完整，简洁），直接影响着我们测试的效果，也是部门工作的重要体现。,2.2.3测试用例需要维护的几种情况,1、软件需求的改变 遵循“需求变更控制”进行相应的用例变更。 2、测试人员对需求的理解错误 导致设计的用例错误 3、开发人员的设计文档进行变动 用例修改更新 4、测试用例中没有体现的测试点的遗漏 测试用例补充 5、版本发布后，用户反馈的缺陷 重现缺陷，补充或修改用例。 通过测试人员适时进行用例维护，用例库会不断的完善，也就保证了测试用例的正确，完整，高效。,2.2.4测试用例更新维护中可能存在的问题,实际项目中，随着测试的深入，测试用例的维护被淡化，主要表现在后期的测试中有些测试是比较复杂的条件组合，错误推测和探索测试，这些测试一般没有变成测试用例被更新到用例库中。 有些后期提交的bug单，在对应模块的测试用例中找不到对应的用例（没新增）。 测试用例的维护不足，导致测试用例的正确性，覆盖率和完整性下降，会对回归测试和用例的复用造成不良影响。 另外测试用例执行情况（状态）的更新也应做好维护。,2.3测试用例的评审,2.3.1测试用例评审的原因和目的 原因 测试用例是软件测试的核心，但由于用例开发人员的设计经验和对需求理解的深度，出发点各不相同，所以编写的测试用例难免会有不同程度的差异，测试点遗漏及用例描述错误。 目的 就是集合多人的智慧和力量，提高测试用例的质量（正确性，完整性，高效性，覆盖度，复用性等。,2.3.2测试用例评审的作用,1，用例设计的是否合理，是否利于高效测试。 2，是否覆盖测试需求上的所有功能点（用例覆盖度）。 3，用例是否具有很好可执行性。例如前提、步骤、输入和预期是否清晰、正确描述的准确，简洁，复用性强。 4，是否已经删除了冗余的用例无效用例或内容重复。 5，是否包含充分的负面测试用例。就是约4倍于正面测试用例的数量，80的代码都是在“保护”20的功能实现。 6，是否从用户层面来设计使用场景和流程的测试用例。,2.3.3实践中测试用例评审存在的问题及建议,问题 在实际的项目实施过程中，由于各种原因，测试用例评审工作有时不能及时进行，造成测试用例的质量有一定程度的降低，对项目软件质量的提高造成一定的负面影响。 建议 在今后的工作中，应该协调一定的资源对测试用例评审工作更好的开展起来。,3，关于减少功能缺陷漏测的流程,,3.1第一步 功能测试（点）分析 目的 提取功能测试对象，准备功能测试数据 减少因为功能测试对象遗漏的漏测 3.2 第二步功能验证 目的检查功能是否已基本正确实现 （减少功能的基本逻辑错误和数据处理错误的漏测） 测试方法 基于生命期（某个功能的系列完整流程） 对象创建 -使用- 销毁 的验证 数据测试方法 静态和动态数据测试方法边界值和等价类,3.3 第三步多功能间组合测试 用户场景系统测试 目的发现功能间配合工作时存在的缺陷，减少多功能间组合错误的漏测 测试方法基于用户场景的测试,,3.4用户场景的探索测试,3.4.1收藏家法同时开启多个功能，同时工作。 同时多个功能交互容易出现资源竞争处理的错误（不同功能（配置）相互间的影响）。 3.4.2地标法改变一系列操作的先后顺序。（ A-B-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又出现在系统中，不回归测试就会影响软件质量。 策略 回归测试比较理想的情况下，是通过自动化测试执行大部分测试用例的。如果暂不具备自动化回归测试的条件，就应该根据实际情况选择相应的策略进行手工回归测试。,结束语,测试的过程是一个不断学习，实践，探讨，总结，优化的过程。 祝大家在工作中不断进步，事业有成。呵呵。,备注,1，该演示文档文字描述偏多，对应的图形配合偏少，建议图文并茂较好（大约平均每3张幻灯片配一张图）。 2，注意格式的规范化（不同级别的文字大小设置，美观等方面） 3，内容建议要有广度（横向和纵向的扩展）及深度（内涵，意义）。,