《黑盒测试流程和方法》由会员分享，可在线阅读，更多相关《黑盒测试流程和方法（21页珍藏版）》请在金锄头文库上搜索。
1、.测试流程依次如下：1.需求：阅读需求,理解需求,与客户、开发、架构多方交流,深入了解需求。-testing team2.测试计划: 根据需求估算测试所需资源人力、设备等、所需时间、功能点划分、如何合理分配安排资源等。-testing leader or testing manager3.用例设计：根据测试计划、任务分配、功能点划分,设计合理的测试用例。-testing leader, senior tester4.执行测试：根据测试用例的详细步骤,执行测试用例。-every tester5.执行结果记录和bug记录：对每个case记录测试的结果,有bug的在测试管理工具中编写bug记录。-e
2、very tester6.defect tracking：追踪leader分配给你追踪的bug.直到 bug fixed。-every tester7.测试报告：通过不断测试、追踪,直到被测软件达到测试需求要求,并没有重大bug.8.用户体验、软件发布等详细测试步骤： 1. 书写测试计划 2. 审核测试计划,未通过返回第一步 3. 书写测试用例； 4. 审核测试用例,未通过返回第三步 5. 测试人员按照测试用例逐项进行测试活动,并且将测试结果填写在测试报告上；测试报告必须覆盖所有测试用例 6. 测试过程中发现bug,将bug填写在bugzilla上发给集成部经理；bug状态NEW 7. 集成部
3、经理接到bugzilla发过来的bug 7.1 对于明显的并且可以立刻解决的bug,将bug发给开发人员；bug状态ASSIGNED; 7.2 对于不是bug的提交,集成部经理通知测试设计人员和测试人员,对相应文档进行修改; bug状态RESOLVED,决定设置为INVALID; 7.3 对于目前无法修改的,将这个bug放到下一轮次进行修改；bug状态RESOLVED,决定设置为REMIND 8. 开发人员接到发过来的bug立刻修改;bug状态RESOLVED,决定设置为FIXED 9. 测试人员接到bugzilla发过来的错误更改信息,应该逐项复测,填写新的测试报告测试报告必须覆盖上一次中所
4、有REOPENED的测试用例； 10. 如果复测有问题返回第六步bug状态REOPENED 11. 否则关闭这项BUGbug状态CLOSED 12. 本轮测试中测试用例中有95%一次性通过测试,结束测试任务； 13. 本轮测试中发现的错误有98%经过修改并且通过再次测试即bug状态CLOSED,返回第五步进行新的一轮测试； 14. 测试任务结束后书写测试总结报告； 15. 正规测试结束进入非正规测试,首先是ALPHA测试,请公司里其他非技术人员以用户角色使用系统。发现bug通知测试人员,测试人员以正规流程处理bug事件； 16. 然后是BETA测试,请用户代表进行测试。发现bug通知测试人员,
5、测试人员以正规流程处理bug事件。Bugzilla是Mozilla公司提供的一款开源的免费Bug错误或是缺陷追踪 系统,用来帮助你管理软件开发,建立完善的BUG跟踪体系。Bugzilla是一开源Bug Tracking System,是专门为Unix定制开发的。但是在windows平台下依然可以成功安装使用.Bugzilla是一个搜集缺陷的数据库。它让用户报告软件的缺陷从而把它们转给合适的开发者。开发者能使用bugzilla保持一个要做事情的优先表,还有时间表和跟踪相关性。不是所有的bugs都是软件缺陷。一些数据库中的内容是作为增强的请求RFE。一个RFE是一个严重级别字段被设为enhance
6、ment的Bug.人们常说bug,实际上意思是Bugzilla中的记录,所以RFEs经常被称作bug。黑盒测试黑盒测试也称功能测试,它是通过测试来检测每个功能是否都能正常使用。在测试中,把程序看作一个不能打开的黑盒子,在完全不考虑程序内部结构和内部特性的情况下,在程序接口进行测试,它只检查程序功能是否按照需求规格说明书的规定正常使用,程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构,不考虑内部逻辑结构,主要针对软件界面和软件功能进行测试。黑盒测试法注重于测试软件的功能需求,主要试图发现下列几类错误。功能不正确或遗漏；界面错误；输入和输出错误；数据库访问错误；性能错误
7、；初始化和终止错误等。从理论上讲,黑盒测试只有采用穷举输入测试,把所有可能的输入都作为测试情况考虑,才能查出程序中所有的错误。实际上测试情况有无穷多个,人们不仅要测试所有合法的输入,而且还要对那些不合法但可能的输入进行测试。这样看来,完全测试是不可能的,所以我们要进行有针对性的测试,通过制定测试案例指导测试的实施,保证软件测试有组织、按步骤,以及有计划地进行。黑盒测试行为必须能够加以量化,才能真正保证软件质量,而测试用例就是将测试行为具体量化的方法之一。具体的黑盒测试用例设计方法包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、正交试验设计法、功能图法、场景法等。等价类划分的
8、办法是把程序的输入域划分成若干部分子集,然后从每个部分中选取少数代表性数据作为测试用例。每一类的代表性数据在测试中的作用等价于这一类中的其他值。该方法是一种重要的,常用的黑盒测试用例设计方法。划分等价类1 划分等价类： 等价类是指某个输入域的子集合。在该子集合中,各个输入数据对于揭露程序中的错误都是等效的,并合理地假定：测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况：有效等价类和无效等价类。有效等价类：是指对于程序的规格说明
9、来说是合理的,有意义的输入数据构成的集合.利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。无效等价类：与有效等价类的定义恰巧相反。设计测试用例时,要同时考虑这两种等价类.因为,软件不仅要能接收合理的数据,也要能经受意外的考验.这样的测试才能确保软件具有更高的可靠性。划分等价类准则2划分等价类的方法：下面给出六条确定等价类的原则。在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类。在输入条件规定了输入值的集合或者规定了必须如何的条件的情况下,可确立一个有效等价类和一个无效等价类.在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类
10、。在规定了输入数据的一组值假定n个,并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类。在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类符合规则和若干个无效等价类从不同角度违反规则。在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类。3设计测试用例：在确立了等价类后,可建立等价类表,列出所有划分出的等价类：输入条件输入条件 有效等价类 无效等价类然后从划分出的等价类中按以下三个原则设计测试用例：为每一个等价类规定一个唯一的编号。设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖地有效等价类,重复这一步.
11、直到所有的有效等价类都被覆盖为止。设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步.直到所有的无效等价类都被覆盖为止。边界值分析法边界值分析是通过选择等价类边界的测试用例。边界值分析法不仅重视输入条件边界,而且也必须考虑输出域边界。它是对等价类划分方法的补充。1边界值分析方法的考虑：长期的测试工作经验告诉我们,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误。使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚
12、小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据。2基于边界值分析方法选择测试用例的原则：1如果输入条件规定了值的范围,则应取刚达到这个范围的边界的值,以及刚刚超越这个范围边界的值作为测试输入数据。2如果输入条件规定了值的个数,则用最大个数,最小个数,比最小个数少一,比最大个数多一的数作为测试数据。3根据规格说明的每个输出条件,使用前面的原则1。4根据规格说明的每个输出条件,应用前面的原则2。5如果程序的规格说明给出的输入域或输出域是有序集合,则应选取集合的第一个元素和最后一个元素作为测试用例。6如果程序中使用了一个内部数据结构,则应当选择这个内部数据结构的边界上的值作
13、为测试用例。7分析规格说明,找出其它可能的边界条件。错误推测法错误推测法是基于经验和直觉推测程序中所有可能存在的各种错误,从而有针对性的设计测试用例的方法.错误推测方法的基本思想： 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例。 例如,在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等,这些就是经验的总结。还有,输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例。因果图法前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系
14、,相互组合等。 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情,即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图逻辑模型。因果图方法最终生成的就是判定表。它适合于检查程序输入条件的各种组合情况。生成测试用例1 分析软件规格说明描述中,哪些是原因即输入条件或输入条件的等价类,哪些是结果即输出条件,并给每个原因和结果赋予一个标识符。 分析软件规格说明描述中的语义。找出原因与结果之间,原因与原因之间对应的关系. 根据这些关系,画
15、出因果图。 由于语法或环境限制,有些原因与原因之间,原因与结果之间的组合情况不可能出现. 为表明这些特殊情况,在因果图上用一些记号标明约束或限制条件。 把因果图转换为判定表。 把判定表的每一列拿出来作为依据,设计测试用例。从因果图生成的测试用例局部,组合关系下的包括了所有输入数据的取TRUE与取FALSE的情况,构成的测试用例数目达到最少,且测试用例数目随输入数据数目的增加而线性地增加。前面因果图方法中已经用到了判定表。判定表Decision Table是分析和表达多逻辑条件下执行不同操作的情况下的工具.在程序设计发展的初期,判定表就已被当作编写程序的辅助工具了.由于它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确。判定表组成法条件桩Condition Stub：列出了问题的所有条件.通常认为列出的条件的次序无关紧要。动作桩Action Stub：列出了问题规定可能采取的操作.这些操作的排列顺序没有约束。条件项Condition Entry：列出针对它左列条件的取值.在所有可能情况下的真假值。动作项Actio
