软件测试总结

黑盒测试一、概念黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。黑盒测试方法示意图二、作用黑盒测试法注重于测试软件的功能需求，主要试图发现下列几类错误:功能不正确或遗漏；界面错误；输入和输出错误；数据库访问错误；性能错误；初始化和终止错误等。三、测试方法具体的黑盒测试用例设计方法包括：等价类划分法，边界值分析法，错误推测法，因果图法，判定表驱动法，正交试验设计法，功能图法等。（一）等价类划分法题目：某程序规定：“输入三个整数A、B、C分别作为三边的边长构成三角形。通过程序判定所构成的三角形的类型，当次三角形为一般三角形、等腰三角形及等边三角形时，分别作计算。。。。”等价类表输入条件有效等价类无效等价类是否三角形的3条边(A0)(1)(B0)(2)(C0)(3)(A+BC)(4)(B+CA)(5)(A+CB)(6)(A=0)(7)(B=0)(8)(C=0)(9)(A+B=C)(10)(B+C=A)(11)(A+C=B)(12)是否等腰三角形(A=B)(13)(B=C)(14)(C=A)(15)(A不等于B不等于C)(16)是否等边三角形(A=BandB=CAndC=A)(17)(A不等于B)(18)(B不等于C)(19)(C不等于A)(20)测试用例序号【A,B,C】覆盖等价类输出13，4，51,2,3,4,5,6一般三角形20，1，27不能构成三角形31,0,2841,2,0951,2,31061,3,21173,1,21283，3,41,2,3,4,5,6,13等腰三角形93,4,41,2,3,4,5,6,14103,4,31,2,3,4,5,6,15113,4,51,2,3,4,5,6,16非等腰三角形123,3,3,1,2,3,4,5,6,17等边三角形133,4,41,2,3,4,5,6,14,18非等边三角形143,4,31,2,3,4,5,6,15,19153,3,41,2,3,4,5,6,13,20（二）边界值分析法概念：边界点分为上点、内点和离点。边界值分析是通过选择等价类边界的测试用例。边界值分析法不仅重视输入条件边界，而且也必须考虑输出域边界。它是对等价类划分方法的补充。（1）边界值分析方法的考虑：长期的测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例，可以查出更多的错误。使用边界值分析方法设计测试用例，首先应确定边界情况.通常输入和输出等价类的边界，就是应着重测试的边界情况.应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。（2）基于边界值分析方法选择测试用例的原则：1）如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据。2）如果输入条件规定了值的个数，则用最大个数,最小个数，比最小个数少一，比最大个数多一的数作为测试数据。3）根据规格说明的每个输出条件，使用前面的原则1）。4）根据规格说明的每个输出条件，应用前面的原则2）。5）如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。6）如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试用例。7）分析规格说明，找出其它可能的边界条件（三）错误推测法错误推测法是基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法.错误推测方法的基本思想：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据他们选择测试用例。例如，在单元测试时曾列出的许多在模块中常见的错误.以前产品测试中曾经发现的错误等，这些就是经验的总结。还有，输入数据和输出数据为0的情况.输入表格为空格或输入表格只有一行.这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例。（四）因果图法前面介绍的等价类划分方法和边界值分析方法，都是着重考虑输入条件，但未考虑输入条件之间的联系，相互组合等。考虑输入条件之间的相互组合，可能会产生一些新的情况.但要检查输入条件的组合不是一件容易的事情，即使把所有输入条件划分成等价类，他们之间的组合情况也相当多.因此必须考虑采用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来考虑设计测试用例.这就需要利用因果图（逻辑模型）。因果图方法最终生成的就是判定表。它适合于检查程序输入条件的各种组合情况。生成测试用例（1)分析软件规格说明描述中，哪些是原因（即输入条件或输入条件的等价类），哪些是结果（即输出条件），并给每个原因和结果赋予一个标识符。(2)分析软件规格说明描述中的语义。找出原因与结果之间，原因与原因之间对应的关系.根据这些关系，画出因果图。(3)由于语法或环境限制，有些原因与原因之间，原因与结果之间的组合情况不可能出现.为表明这些特殊情况，在因果图上用一些记号标明约束或限制条件。(4)把因果图转换为判定表。(5)把判定表的每一列拿出来作为依据，设计测试用例。从因果图生成的测试用例（局部，组合关系下的）包括了所有输入数据的取TRUE与取FALSE的情况，构成的测试用例数目达到最少，且测试用例数目随输入数据数目的增加而线性地增加。前面因果图方法中已经用到了判定表。判定表（DecisionTable）是分析和表达多逻辑条件下执行不同操作的情况下的工具.在程序设计发展的初期，判定表就已被当作编写程序的辅助工具了.由于它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确。判定表的组成：条件桩（ConditionStub）：列出了问题得所有条件.通常认为列出得条件的次序无关紧要。动作桩（ActionStub）：列出了问题规定可能采取的操作.这些操作的排列顺序没有约束。条件项（ConditionEntry）：列出针对它左列条件的取值.在所有可能情况下的真假值。动作项（ActionEntry）：列出在条件项的各种取值情况下应该采取的动作。规则：任何一个条件组合的特定取值及其相应要执行的操作.在判定表中贯穿条件项和动作项的一列就是一条规则.显然，判定表中列出多少组条件取值，也就有多少条规则，既条件项和动作项有多少列。判定表的建立步骤①确定规则的个数。假如有n个条件.每个条件有两个取值（0,1），故有2n种规则。②列出所有的条件桩和动作桩。③填入条件项。④填入动作项.等到初始判定表。⑤简化.合并相似规则（相同动作）。B.Beizer指出了适合使用判定表设计测试用例的条件：①规格说明以判定表形式给出，或很容易转换成判定表。②条件的排列顺序不会也不影响执行哪些操作。③规则的排列顺序不会也不影响执行哪些操作。④每当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则。⑤如果某一规则得到满足要执行多个操作，这些操作的执行顺序无关紧要。判定表测试用例：例如：订购单的检查，如果金额超过500元，又未过期，则发出批准单和提货单；如果金额超过500元，但过期了，则不发批准单；如果金额低于500元，则不论是否过期都发出批准单和提货单，在过期的情况下还需要发出通知单。判定表金额500500=500=500状态未过期已过期未过期已过期发出批准单OOO发出提货单OOO发出通知单O规则合并表金额500=500状态未过期已过期已过期发出批准单OO发出提货单OO发出通知单O测试用例1测试用例编号ORDER_ST_CHECK_001测试项目订购单的检查测试标题状态为未过期重要级别高预置条件无输入499操作步骤1.输入金额：4992.选择未过期3.单击确定预期输出发出批准单和提货单（五）、正交试验设计法就是使用已经造好了的正交表格来安排试验并进行数据分析的一种方法，目的是用最少的测试用例达到最高的测试覆盖率。（六）、场景法现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可以引入到软件测试中，可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时使测试用例更容易理解和执行。基本流和备选流：如下图所示，图中经过用例的每条路径都用基本流和备选流来表示，直黑线表示基本流，是经过用例的最简单的路径。备选流用不同的色彩表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中（如备选流1和3）；也可能起源于另一个备选流（如备选流2），或者终止用例而不再重新加入到某个流（如备选流2和4）。四、流程（一）测试计划首先，根据用户需求报告中关于功能要求和性能指标的规格说明书，定义相应的测试需求报告，即制订黑盒测试的最高标准，以后所有的测试工作都将围绕着测试需求来进行，符合测试需求的应用程序即是合格的，反之即是不合格的；同时，还要适当选择测试内容，合理安排测试人员、测试时间及测试资源等。（二）测试设计将测试计划阶段制订的测试需求分解、细化为若干个可执行的测试过程，并为每个测试过程选择适当的测试用例（测试用例选择的好坏将直接影响到测试结果的有效性）。（三）测试开发建立可重复使用的自动测试过程。（四）测试执行执行测试开发阶段建立的自动测试过程，并对所发现的缺陷进行跟踪管理。测试执行一般由单元测试、组合测试、集成测试、系统联调及回归测试等步骤组成，测试人员应本着科学负责的态度，一步一个脚印地进行测试。（五）测试评估结合量化的测试覆盖域及缺陷跟踪报告，对于应用软件的质量和开发团队的工作进度及工作效率进行综合评价。Bug的生命周期Bug生命周期对Bug的处理开发组长/经理每天对Bug进行分配，标注处理意见，给定优先级（发版前必须三方：需求、开发、产品共同确定）。问题分配时，应尽可能将咨询类、理解错误类等问题处理掉，而不是留给开发人员。有可能是需求的问题，分配给需求人员。定期对Bug库分析，找出常出错的模块，进行代码审查开发人员分析Bug，写出问题原因，修改Bug；实行Bug优先原则，严重程度B-Major类或紧急程度3-High类以上（包含）bug5个或5个以上，停止新功能的开发。需求人员解释需求，给出处理意见，将Bug库中的建议整理成需求文档。评审确定后列入开发计划测试人员不参与问题的优先级的定位，只用Bug级别反映Bug的严重程度。验证Bug是否已被解决测试组长/经理审核测试人员提交的Bug。定期对Bug库进行分析，描绘出曲线图等，报告现状、预测趋势。在测试总结报告中给出意见产品人员可以对优先级和处理意见等进行审核，如果有意见，和项目组商量定夺Bug状态(Status)：指缺陷通过一个跟踪修复过程的进展情况。包括New、Open、Reopen、Fixed、Closed及Rejected等New为测试人员新问题提交所标志的状态。Open为任务分配人（开发组长/经理）对该问题准备进行修改并对该问题分配修改人员所标志的状态。Bug解决中的状态，由任务分配人改变。对没有进入此状态的Bug，程序员不用管。Reopen为测试人员对修改问题进行验证后没有通过所标志的状态；或者已经修改正确的问题，又重新出现错误。由测试人员改变。Fixed为开发人员修改问题后所标志的状态，修改后还未测试。Closed为测试人员对修改问题进行验证后通过所标志的状态。由测试人员改变。Rejected开发人员认为不是Bug、描述不清、重复、不能复现、不采纳所提意见建议、或虽然是个错误但还没到非改不可的地步故可忽略不计、或者测试人员提错，从而拒绝的问题。由Bug分配人或者开发人员来设置。Bug严重级别(Severity，Bug级别)：是指因缺陷引起的故障对软件产品的影响