功能测试工作的一点总结.docx

功能测试工作的一点总结一直在做功能测试工作，负责过三四个不大不小的项目的功能测试工作，却很少静下心来总结工作中的得失。很多不了解测试的人，认为功能测试不过就是拿鼠标点来点去，没有什么技术含量，随便招个应届毕业生就能干的工作。我也曾经认为功能测试没什么前途，现在看来觉得自己太浮躁了。功能测试的门槛可能比较低，做测试工作的人大多都是从功能测试开始，但要做好功能测试却不容易，需要学习的知识还很多，比如操作系统、数据库、网络。下面主要结合工作实践谈谈我对功能测试的一点总结。功能测试最重要的是理解业务和需求。知道系统要实现什么功能，业务流程是怎样的，然后就可以根据需求编写测试计划和测试用例了。测试书籍上介绍常用的编写测试用例的方法有：等价类、边界值、因果图、判定表等，在实际工作中，我使用较多的有等价类、边界值、场景法和错误猜测法。在这里需要提一点，将测试用例按测试目的进行分类，比如用户界面、功能点、业务场景等，会让测试用例的结构看起来更清晰，执行测试用例的效率也更高。要做好功能测试，还需要对整个系统的数据库结构比较清楚，每个功能点涉及哪些数据表，对数据的操作方式是怎样的。这样就不单从前台页面来进行测试，通过对数据库中数据的验证，可以发现隐藏的一些bug。比如库表没有进行关联删除，从前台页面是看不出来的，但实际可能导致程序出现问题。对一些比较复杂的组合查询或数据排序，也可以自己编写sql语句对结果进行验证。除此之外，了解程序的框架结构和一些开发知识也有助于更好地测试程序和定位错误。做完一个业务，可以通过系统日志来查看错误原因，结合数据库结构，可以更好帮助开发人员定位错误。比如日志记录执行哪条sql语句出错了，错误的原因是字段长度设置不够。我在这方面做得不太好，现在在努力学习一些开发知识，期待在以后的工作能做得更好。最后，对bug的分析和总结有助于积累测试经验。比如哪种类型的bug数量多，哪些测试用例发现的bug较多，有助于测试用例的编写和修改。在探索测试时，发现bug的测试过程也要加入测试用例库中。通过测试用例的累积，可以更好地了解系统常出现的错误，积累更多的测试经验。功能测试用例设计从单元测试开始，经过集成测试、系统测试，一直到最后的验收测试，功能测试始终都会涉及到，而且功能测试几乎是系统测试的核心内容，因此功能测试用例编写的是否成功，决定着最后测试结果的成败。功能测试关注的是系统功能是否正确实现，其主要依据文档是需求分析文档，集成测试中相关的功能测试会涉及概要设计和详细设计文档。在目前的大多数测试工作中，测试人员的分工还不像开发人员分工那样明确，经常是测试经理不但要编写测试计划和设计测试，还要执行具体的测试工作，尤其在功能测试过程中，编写测试用例和执行测试用例的经常是一个人。因此针对功能测试，本着提高效率的宗旨，提出下面的编写原则：1、用例应该编写的少而精：建议越少越好，但是功能用例的覆盖面应该是全部的功能需求，这是针对目前大多数企业提供的测试资源较少提出的一个原则，目前的大多数公司没有能力给测试用例足够的编写时间，是少的用例节省时间便于执行和维护，随着企业软件开发过程的规范化，测试人员分工会更加明确，这个时候需要编写较为全面的功能测试用例，由专门的测试员执行；2、尽量包括更多的测试内容：比如一些易用性测试、健壮性、界面测试，都可以包含在功能测试中，这用做不但可以减少测试次数，更能提高测试效率，同时把相关联的测试用例一起执行，会发现更多的缺陷。本小节主要介绍功能测试用例的基本编写方法和一些功能测试用例的编写实例。10.2.1.1功能测试用例设计基本方法功能测试的用例设计方法常见的有等价类划分、边界值分析、因果图、比较法和错误推测法，这些方法在测试书籍、网上文章中都可以找到，在这里就不重复了。本节给大家介绍一种比较新的用例设计方法：使用用例场景来设计测试用例。用例场景来设计法的重要概念是测试点：在系统的用例模型描述中应明确指出每个用例模型的优先级和用例工作流程，每个用例模型为一个测试点，用例模型中每个测试需求至少应编写两个测试用例。这个概念经常被误解和误用，请大家注意。用例场景的定义：用例场景是通过描述流经用例的路径来确定的过程，这个流经过程要从用例开始到结束遍历其中所有基本流和备选流。为什么引入用例场景？现在的软件几乎都是由事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果形成事件流。这种在软件设计方面的思想也可被引入到软件测试中，可以生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时测试用例也更容易得到理解和执行。用例场景示例：下图中经过用例的每条不同路径都反映了基本流和备选流，备选流用箭头来表示。基本流用直黑线来表示，是经过用例的最简单的路径。每个备选流自基本流开始，之后，备选流会在某个特定条件下执行。备选流可能会重新加入基本流中（备选流1和3），还可能起源于另一个备选流（备选流2），或者终止用例而不再重新加入某个流（备选流2和4）。遵循上图中每个经过用例的可能路径，可以确定不同的用例场景。从基本流开始，再将基本流和备选流结合起来，可以确定以下用例场景：场景1 基本流场景2 基本流 备选流1场景3 基本流 备选流1 备选流2场景4 基本流 备选流3场景5 基本流 备选流3 备选流1场景6 基本流 备选流3 备选流1 备选流2场景7 基本流 备选流4场景8 基本流 备选流3 备选流4注：为方便起见，场景5、6和8只描述了备选流3指示的循环执行一次的情况。测试用例：生成每个场景的测试用例是通过确定某个特定条件来完成的，这个特定条件将导致特定用例场景的执行。测试用例例子：假定上图描述的用例对备选流3规定如下：“如果在上述步骤2输入提款金额中输入的美元量超出当前帐户余额，则出现此事件流。系统将显示一则警告消息，之后重新加入基本流，再次执行上述步骤2输入提款金额，此时银行客户可以输入新的提款金额。”据此，可以开始确定需要用来执行备选流3的测试用例：测试用例ID场景条件预期结果TCx场景4步骤2-提款金额帐户余额在步骤2处重新加入基本流TCy场景4步骤2-提款金额帐户余额不执行备选流3，执行基本流TCz场景4步骤2-提款金额=帐户余额不执行备选流3，执行基本流注：由于没有提供其他信息，以上显示的测试用例都非常简单。测试用例很少如此简单。10.2.1.2功能用例编写策略 功能用例的编写策略一般是这样的： 1)首先确定测试点和其自有工作流程。 2)按业务（系统测试）或功能（单元和集成测试）将测试点进行编号和排序。 3)使用用例场景方法确定测试用例。 要点：使用场景，类似于白盒测试的基本路径法。能清晰的描述出系统的功能或业务流程，将测试用例的实际测试效果提升到最大。又因描述出各测试点之间的关系从而降低测试用例的设计难度和复杂度。10.2.1.3功能用例编写例子下面是一个由用例生成测试用例的更符合实际情况的例子。一台ATM机器的主角和用例。下表包含了上图中提款用例的基本流和某些备用流：以从这个用例生成下列场景注：为方便起见，备选流3和6（场景3和7）内的循环以及循环组合未纳入上表。对于这7个场景中的每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。下面显示了一种通用格式，其中各行代表各个测试用例，而各列则代表测试用例的信息。本示例中，对于每个测试用例，存在一个测试用例ID、条件（或说明）、测试用例中涉及的所有数据元素（作为输入或已经存在于数据库中）以及预期结果。通过从确定执行用例场景所需的数据元素入手构建矩阵。然后，对于每个场景，至少要确定包含执行场景所需的适当条件的测试用例。例如，在下面的矩阵中，V（有效）用于表明这个条件必须是VALID（有效的）才可执行基本流，而I（无效）用于表明这种条件下将激活所需备选流。下表中使用的“n/a”（不适用）表明这个条件不适用于测试用例。在上面的矩阵中，六个测试用例执行了四个场景。对于基本流，上述测试用例CW1称为正面测试用例。它一直沿着用例的基本流路径执行，未发生任何偏差。基本流的全面测试必须包括负面测试用例，以确保只有在符合条件的情况下才执行基本流。这些负面测试用例由CW2至6表示（阴影单元格表明这种条件下需要执行备选流）。虽然CW2至6对于基本流而言都是负面测试用例，但它们相对于备选流2至4而言是正面测试用例。而且对于这些备选流中的每一个而言，至少存在一个负面测试用例（CW1-基本流）。每个场景只具有一个正面测试用例和负面测试用例是不充分的，场景4正是这样的一个示例。要全面地测试场景4-PIN有误，至少需要三个正面测试用例（以激活场景4）：输入了错误的PIN，但仍存在输入机会，此备选流重新加入基本流中的步骤3-输入PIN。输入了错误的PIN，而且不再有输入机会，则此备选流将保留银行卡并终止用例。最后一次输入时输入了“正确”的PIN。备选流在步骤5-输入金额处重新加入基本流。注：在上面的矩阵中，无需为条件（数据）输入任何实际的值。以这种方式创建测试用例矩阵的一个优点在于容易看到测试的是什么条件。由于只需要查看V和I（或此处采用的阴影单元格），这种方式还易于判断是否已经确定了充足的测试用例。从上表中可发现存在几个条件不具备阴影单元格，这表明测试用例还不完全，如场景6-不存在的帐户/帐户类型有误和场景7-帐户余额不足就缺少测试用例。一旦确定了所有的测试用例，则应对这些用例进行复审和验证以确保其准确且适度，并取消多余或等效的测试用例。测试用例一经认可，就可以确定实际数据值（在测试用例实施矩阵中）并且设定测试数据。以上测试用例只是在本次迭代中需要用来验证提款用例的一部分测试用例。需要的其他测试用例包括：场景6-帐户不存在/帐户类型有误：未找到帐户或帐户不可用场景6-帐户不存在/帐户类型有误：禁止