catch_dreamer的博客

1. 概述一、软件测试的生命周期1.软件测试的生命周期需求分析–>测试计划–>测试设计、测试开发–>测试执行–>测试评估2.软件测试&软件开发的生命周期需求阶段测试人员需要了解需求，对需求进行分解，得出测试需求计划阶段根据要求编写测试计划书或方案设计阶段测试人员适当的了解设计，搭建测试用例框架编码阶段测试人员不需要进行编码，需要对需求进行测试测试阶段软件测试人员最重要的一个阶段，编写测试报告运行维护测试人员需要参与项目的实施工作，需

1. 概述2. bug级别的分类及其具体划分的参考意见一. 严重问题定义： 不能完全满足系统要求，系统停止运行，系统的重要部件无法运行，系统崩溃或挂起等导致系统不能继续运行。修改优先级为最高，该级别问题需要立即修改。系统崩溃导致程序重启,死机或非法退出死循环数据丢失或异常数据通讯错误。硬件故障，系统悬挂二. 高级问题定义： 严重地影响系统要求或基本功能的实现，且没有更正办法（重新安装或重新启动该软件不属于更正办法）。使系统不稳定、或破坏数据、或产生错误结果，或部分功能无法执行，而且

1. 概述这类问题是考察面试者测试思路和测试策略的常见问题，主要要根据软件质量的六个特性(功能性、易用性、效率、可靠性、可维护性、可移植性)来进行思考，进而需要结合实际测试软件时考虑的角度，比如功能方面、接口方面、性能方面、维护难度方面、兼容性方面、界面或者说外观方面(比如本地化的一些内容以及界面美观等等)、操作难度或者说易用性方面、可靠度(比如应对异常情况的能力)方面、安全性方面等，根据这些角度结合具体要测试的内容进行思考并作答， 例如，在下例中，分别从功能、界面、易用、兼容、安全、性能这六个角度结合业

同行评审，定义为“由软件工作产品生产者的同行遵循已定义的规程对产品进行的技术评审”,是一种通过作者的同行来确认缺陷和需要变更区域的检查方法按照CMMI模型的提法，将同行评审分为3类。（1）正式评审（Inspection），通常是由经过同行评审培训的项目经理或PPQA主持，规模在3～7人之间为宜，一般在完成了一个工作产品后对其进行的评审。正式评审的目的在于定位并除去工作产品中的缺陷。（2）技术审查（Technical Reviews），或称内部评审，通常由技术负责人或项目经理召集，三人以上参加。技术审查

1. 概述

1. 概述在测试用例的设计方法中，等价类、边界值及判定表等测试用例设计方法只能够解决针对单点功能的测试用例设计，而无法针对涉及业务流程的软件系统进行测试。这时候就要用到场景法来设计测试用例，也就是说场景法主要是针对业务流程来设计测试用例的。现在的软件几乎都是通过事件触发来控制流程的，事件触发时的场景便形成了场景，而同一事件不同的触发顺序和处理结果就形成了事件流。 这原本是一种软件设计的思想，不过依然可以用来指导软件测试用例的设计，可以生动的描述事件触发时的情景，有利于测试用例的设计和对测试用例的理解和执

1. 概述程序的功能说明通常由动态说明和静态说明组成， 动态说明描述的是输入数据的次序和转移的次序，而静态说明描述的是输入条件与输出条件之间的对应关系。当程序中过于复杂并且存在大量的组合时，仅仅使用静态说明设计的测试用例，往往是考虑不够的，所以采用动态说明来补充一定的测试用例时必要的。而功能图法就是使用动态描述来生成测试用例的方法，其本质是一种白盒和黑盒测试方法组合的测试用例设计方法。2. 定义功能图方法是用功能图形象的描述程序的功能说明，并机械的生成功能图的测试用例。功能图由状态迁移图和逻辑功能模型

1、概述在利用因果图和判定表驱动法来设计测试用例时，作为输入条件的原因和输出结果之间的关系有时候很难从需求规格说明中得到；或者因果关系非常庞大，导致利用因果图得到的测试用例数目非常大，为了有效地、合理地减少测试的工时与费用(测试用例的数量)，就可以使用正交实验法。2、定义此方法是由数理统计学科中正交实验方法演化而来的一种用于测试多条件多输入的用例设计方法， 是根据Galois(伽罗瓦)理论导出的“正交表”，合理安排实验的一种科学实验设计方法，是研究多因子(因素)多水平(状态)的一种实验方法。 其根据实

4、因果图加判定表设计测试用例实例这里以一个《软件评测师教程》上面的例子为例，来说明和演示因果图和判定表驱动法设计设计用例的过程与方法。该实例描述具体如下。1. 需求规格描述有一个处理单价为1元5角钱的盒装饮料的自动售货机软件。若投入一元五角硬币，按下“可乐”、“雪碧”或“红茶”按钮，相应的饮料就送出来，若投入的是两元硬币，在送出饮料的同时退还5角硬币。2. 分析需求中包含的因果根据上面的描述，可以分析提取出上面这段话中包含的原因和结果，分别如下所示：>原因投入一元五角硬币投入两元硬

1. 因果图法1. 概述在利用判定表设计方法设计测试用例的过程中，往往会遇到输入与输入之间存在约束的情况，简单业务逻辑关系可用判定表解决，但较为复杂的约束关系可能就不合适了。这种情况下使用因果图就就会比较容易理解业务的逻辑关系，因果图又称鱼骨图，用于描述被测对象输入与输入、输入与输出之间的约束关系，因果图绘制的过程中，可以理解为用例设计者针对因果关系业务的建模过程。利用因果图设计用例的大致过程为首先根据需求规格绘制因果图，然后将其转为判定表再进行用例设计，一般将因果图理解为判定表的前置过程，如果逻辑关系

1. 概述在等价类的设计方法中，虽然详细考虑到了需求输入域，但是对于输入域及输入域存在关联时无法覆盖，因此需要一种能考虑输入域相互关联的用例设计方法来考虑业务描述性的测试需求。而如果考虑输入条件的各种组合，可能的组合数将非常大，所以要考虑各种条件的组合，相应的产生多个动作的形式来考虑设计测试用例，这种情况下就需要用到因果图，并且在绘制出因果图后，也需要将其转化为判定表，最后再抽取测试用例，在设计时需要为判定表的每一列设计一条测试用例。 如果可以直接绘制出判定表，那么也就没有必要绘制因果图了。2. 判定

错误推测法不同于等价类划分和边界值分析等设计方法，其是基于测试人员的经验和直觉推测

1. 概述在长期的测试工作中，人们发现大量的错误都是出现在了输入和输出域的边界范围上，而并不是输入范围的内部。因此要对各种边界情况设计测试用例，以查找出更多的错误。边界值属于等价类方法的特定输入域，包含在有效等价类或无效等价类中，根据等价类推断理论，边界值方法产生的测试数据测试效果和等价类方法相同，只是边界值方法产生的数据更具有针对性，通常选取输入域的边界值。2. 边界条件和次边界条件>边界条件边界条件是特殊情况，比如要求输入的长度为6-10,位，那么边界条件就是长度为6和长度为10以及两种

1、等价类划分2、边界值分析

1、测试用例的八大要素1. 用例编号和其他编号一样，测试用例编号是用来唯一识别测试用例的编号，要求具有易识别和易维护性，用户可以很容易根据用例编号获取到相应用例的目的和作用，在系统测试用例中，编号的一般格式为A-B-C-D这几部分的作用分别如下：A：产品或项目类型，如CMS(内容管理系统)、CRM(客户关系管理系统)B：一般用来说明用例的属性，如ST(系统测试)、IT(集成测试)、UT(单元测试)C：测试需求的表示，说明该用例针对的需求点，可包括测试项和测试子项等，如文档管理、客户投诉信息管理

1、软件质量的定义软件质量是软件特性的综合，指软件满足规定或潜在用户需求的能力，其主要从内部质量、外部质量、使用质量和过程质量这四个方面来衡量。2、软件质量模型测度与度量：在软件质量中用于测量的一种量化的标度和方法即为测度，而名词的度量即用来指测量的结果。1. McCail质量模型这是由McCall和他的同事在早期提出的软件质量模型，指出了影响软件质量因素的分类，其主要集中在以下三个方面：操作特性(产品运行)承受可改变的能力(产品修订)新环境适应的能力(产品变迁)具体的模型图如下(来源

按照开发阶段划分按照开发阶段，软件测试可以划分为如下几个阶段：单元测试： 单元测试又称模块测试，是针对软件设计的最小单位——程序模块进行正确性检验的测试工作，其目的在于检查每个程序单元是否能够正确的实现详细设计说明书中的模块功能、性能、接口和设计约束等要求，发现模块内部可能存在的各种错误。集成测试： 集成测试也可以称为组装测试，通常在单元测试得基础上，将所有的程序模块进行有序的、递增的测试模...

软件测试的定义软件测试的经典定义是在规定条件下对程序进行操作，以发现错误，对软件质量进行评估。因为软件是由文档、数据以及程序组成的，所以软件测试的对象也就不仅仅是程序本身，而是包括软件形成过程的文档、数据以及程序。随着软件工程化越来越被重视以及软件规模的不断扩大，软件分析、设计的作用越来越突出，而在实践中，越来越多的错误是在刚开始的分析与设计阶段就已经存在，所以对于软件需求和设计阶段的测试就显...