功能测试工作的一点总结
一直在做功能测试工作，负责过三四个不大不小的项目的功能测试工作，却很少静下心来总结工作中的得失。
很多不了解测试的人，认为功能测试不过是拿鼠标点来点去，没有什么技术含量，随便招个应届毕业生能干的工作。我也曾经认为功能测试没什么前途，现在看来觉得自己太浮躁了。功能测试的门槛可能比较低，做测试工作的人大多都是从功能测试开始，但要做好功能测试却不容易，需要学习的知识还很多，比如操作系统、数据库、网络。下面主要结合工作实践谈谈我对功能测试的一点总结。
功能测试重要的是理解业务和需求。知道系统要实现什么功能，业务流程是怎样的，然后可以根据需求编写测试计划和测试用例了。测试书籍上介绍常用的编写测试用例的方法有：等价类、边界值、因果图、判定表等，在实际工作中，我使用较多的有等价类、边界值、场景法和错误猜测法。在这里需要提一点，将测试用例按测试目的进行分类，比如用户界面、功能点、业务场景等，会让测试用例的结构看起来更清晰，执行测试用例的效率也更高。
要做好功能测试，还需要对整个系统的数据库结构比较清楚，每个功能点涉及哪些数据表，对数据的操作方式是怎样的。这样不单从前台页面来进行测试，通过对数据库中数据的验证，可以发现隐藏的一些bug。比如库表没有进行关联删除，从前台页面是看不出来的，但实际可能导致程序出现问题。对一些比较复杂的组合查询或数据排序，也可以自己编写sql语句对结果进行验证。
除此之外，了解程序的框架结构和一些开发知识也有助于更好地测试程序和定位错误。做完一个业务，可以通过系统日志来查看错误原因，结合数据库结构，可以更好帮助开发人员定位错误。比如日志记录执行哪条sql语句出错了，错误的原因是字段长度设置不够。我在这方面做得不太好，现在在努力学习一些开发知识，期待在以后的工作能做得更好。
后，对bug的分析和总结有助于积累测试经验。比如哪种类型的bug数量多，哪些测试用例发现的bug较多，有助于测试用例的编写和修改。在探索测试时，发现bug的测试过程也要加入测试用例库中。通过测试用例的累积，可以更好地了解系统常出现的错误，积累更多的测试经验。
