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

功能测试工作的一点总结一直在做功能测试工作，负责过三四个不大不小的项目的功能测试工作，却很少静下心来总结工作中的得失。　　很多不了解测试的人，认为功能测试不过就是拿鼠标点来点去，没有什么技术含量，随便招个应届毕业生就能干的工作。我也曾经认为功能测试没什么前途，现在看来觉得自己太浮躁了。功能测试的门槛可能比较低，做测试工作的人大多都是从功能测试开始，但要做好功能测试却不容易，需要学习的知识还很多，比如操作系统、数据库、网络。下面主要结合工作实践谈谈我对功能测试的一点总结。　　功能测试最重要的是理解业务和需求。知道系统要实现什么功能，业务流程是怎样的，然后就可以根据需求编写测试计划和测试用例了。测试书籍上介绍常用的编写测试用例的方法有：等价类、边界值、因果图、判定表等，在实际工作中，我使用较多的有等价类、边界值、场景法和错误猜测法。在这里需要提一点，将测试用例按测试目的进行分类，比如用户界面、功能点、业务场景等，会让测试用例的结构看起来更清晰，执行测试用例的效率也更高。　　要做好功能测试，还需要对整个系统的数据库结构比较清楚，每个功能点涉及哪些数据表，对数据的操作方式是怎样的。这样就不单从前台页面来进行测试，通过对数据库中数据的验证，可以发现隐藏的一些bug。比如库表没有进行关联删除，从前台页面是看不出来的，但实际可能导致程序出现问题。对一些比较复杂的组合查询或数据排序，也可以自己编写sql语句对结果进行验证。　　除此之外，了解程序的框架结构和一些开发知识也有助于更好地测试程序和定位错误。做完一个业务，可以通过系统日志来查看错误原因，结合数据库结构，可以更好帮助开发人员定位错误。比如日志记录执行哪条sql语句出错了，错误的原因是字段长度设置不够。我在这方面做得不太好，现在在努力学习一些开发知识，期待在以后的工作能做得更好。　　最后，对bug的分析和总结有助于积累测试经验。比如哪种类型的bug数量多，哪些测试用例发现的bug较多，有助于测试用例的编写和修改。在探索测试时，发现bug的测试过程也要加入测试用例库中。通过测试用例的累积，可以更好地了解系统常出现的错误，积累更多的测试经验。功能测试用例设计从单元测试开始，经过集成测试、系统测试，一直到最后的验收测试，功能测试始终都会涉及到，而且功能测试几乎是系统测试的核心内容，因此功能测试用例编写的是否成功，决定着最后测试结果的成败。　　功能测试关注的是系统功能是否正确实现，其主要依据文档是需求分析文档，集成测试中相关的功能测试会涉及概要设计和详细设计文档。　　在目前的大多数测试工作中，测试人员的分工还不像开发人员分工那样明确，经常是测试经理不但要编写测试计划和设计测试，还要执行具体的测试工作，尤其在功能测试过程中，编写测试用例和执行测试用例的经常是一个人。因此针对功能测试，本着提高效率的宗旨，提出下面的编写原则：　　1、用例应该编写的少而精：建议越少越好，但是功能用例的覆盖面应该是全部的功能需求，这是针对目前大多数企业提供的测试资源较少提出的一个原则，目前的大多数公司没有能力给测试用例足够的编写时间，是少的用例节省时间便于执行和维护，随着企业软件开发过程的规范化，测试人员分工会更加明确，这个时候需要编写较为全面的功能测试用例，由专门的测试员执行；　　2、尽量包括更多的测试内容：比如一些易用性测试、健壮性、界面测试，都可以包含在功能测试中，这用做不但可以减少测试次数，更能提高测试效率，同时把相关联的测试用例一起执行，会发现更多的缺陷。　　本小节主要介绍功能测试用例的基本编写方法和一些功能测试用例的编写实例。　　10.2.1.1功能测试用例设计基本方法　　功能测试的用例设计方法常见的有等价类划分、边界值分析、因果图、比较法和错误推测法，这些方法在测试书籍、网上文章中都可以找到，在这里就不重复了。本节给大家介绍一种比较新的用例设计方法：使用用例场景来设计测试用例。　　用例场景来设计法的重要概念是测试点：在系统的用例模型描述中应明确指出每个用例模型的优先级和用例工作流程，每个用例模型为一个测试点，用例模型中每个测试需求至少应编写两个测试用例。这个概念经常被误解和误用，请大家注意。　　用例场景的定义：用例场景是通过描述流经用例的路径来确定的过程，这个流经过程要从用例开始到结束遍历其中所有基本流和备选流。　　为什么引入用例场景？　　现在的软件几乎都是由事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果形成事件流。这种在软件设计方面的思想也可被引入到软件测试中，可以生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时测试用例也更容易得到理解和执行。　　用例场景示例：　　下图中经过用例的每条不同路径都反映了基本流和备选流，备选流用箭头来表示。基本流用直黑线