[20071101]工作总结

工作总结

从单元测试开始，经过集成测试、系统测试，一直到最后的验收测试，功能测试始终会涉及到，所以就有人说掌握了功能测试的精髓就掌握了软件测试外包市场的制高点。

功能测试到底什么才是精髓呢？我的理解有以下几点：①设计好的功能测试用例，以精简的用例发现尽可能多的bug。②能够根据发现的bug分析出该bug出现的原因。③根据bug分析系统的各方面数据。④熟练使用自动化的功能测试工具。

      现在我们做的最多的就是上面的第一点，这里总结的也是第一点，功能测试用例制作和功能测试的执行工作。测试执行是要根据测试用例的，所以这里的总结归根结底是功能测试用例制作的总结。

虽然我们现在测试基本上不按照测试用例的，但是并不代表我们拿起鼠标乱点一通，因为随着对系统的越来越熟悉，测试用例基本上已经在我们脑海里了。

下面是我总结的功能测试用例制作的流程或者是在没有用例的情况下功能测试的流程。

1）熟悉被测系统的业务逻辑。

如果不熟悉系统的业务逻辑就开始测试，只能拿着鼠标乱点一通，也很难发现问题。我们对SPIF进行功能测试的时候，SPIF已经做好几年了，所以我们熟悉系统是从使用SPIF开始的，不过我觉得，既然所有的测试都应该追溯到需求，那么熟悉业务逻辑最好是从需求开始。可以很早参与进项目，或者熟读需求规格说明书等。   

2）明确被测对象，分解被测对象的功能，找到测试点。

我个人觉得最难的就在这里了。要做好这点是建立在对系统业务逻辑很熟悉的基础上的。根据系统的业务逻辑把系统分解为一个一个的功能模块，然后把功能模块当成一个测试对象，再逐步分解，分解为一个一个的测试点。我的一般做法是把一个功能模块当成一个测试对象，比如SPIF的评审管理功能模块，而评审管理的功能模块又是由一系列相关的页面组成，测试的时候，暂且先不考虑这些页面之间的数据传递，这些页面可以先作为一个个被测对象。也就是说最终的被测对象是页面（这是针对web应用程序的），然后可以从以下几个方面进行测试。

界面测试。①如果有系统每个页面的风格一致的需求的话，要注意风格的一致性。②看页面上的各个控件是否表示正确。如页面是否出现了前后台代码，下拉框中的内容是否为空等等。界面测试可以作为一个测试点。

页面迁移测试。当点击链接或者进行引起页面迁移的其他操作时，是否能迁移到正确的页面。这方面测试很容易忽略，因为上个星期的今日工作模块测试时，我发现有几个页面点击返回按钮时并没有返回到上一个查看得页面。这个也可以作为一个测试点。

功能点测试。可以把引起某个事件的操作当成一个功能点。如保存操作、删除操作等等。在保存操作时，正确保存正确显示才是正确的。这个就不赘述了，以前也总结过，还是比较全面的。

页面之间数据传递的正确性测试。在页面可以正确迁移，以及各功能点都没有问题的情况下，就要开始测试页面之间数据传递的正确性了。

权限测试。我觉得这个测试要单独出来做。不然的话，也很容易会忽略。SPIF系统中，登陆人员可以通过组织过程资产库查看本部门的其他项目组的项目情况。这个就涉及到权限问题了。以前也没有考虑到，后来想到了测试时还真的发现了点问题。不是测试用例中没有涉及到，但是由于一句话带过，没有引起足够的重视。权限问题也不是小问题吧，所以我想单独出来还是很有必要的。

3）做好回归测试工作。

我们现在做的基本上就是回归测试，但是这里的回归测试指的是bug被解决后的确认测试。回归测试首先要看的是bug是否真的解决了，然后要看有没有引起其他的bug，这个就涉及到回归测试的深度了，一般说比较难把握的。在工作中，通常是把可能会影响的模块测试一遍。

以上就是总结的工作流程。肯定有不合理之处，能指出最好了。另外我觉得最好多到网上的测试论坛逛逛，在看别人讨论的过程中，自己的测试知识面也会拓宽，也会了解一些测试方面的常识，如8020原则等等，这对测试肯定是有帮助的。