做了5年多的测试，一直都没有好好的思考和总结。回想当年刚入行时的那份激情都已经被重复性的测试工作和自己的惰性给磨没了。最近想着换工作，发现面试时很难把工作经验和个人优势给表现出来。思考了一下，确实是缺少对平时工作的总结。

　　毕业后一直在一个公司一个大项目做系统测试人员。手工测试4年半，自动化测试1年。作为通信业的系统测试人员，大部分都是做功能性测试，和业务强相关，所以工作几年的系统测试人员都会成为业务专家，而非测试技术专家。但是通信设备的更新换代太快了，业务也会变的截然不同。业务需要从头学起。因而，大部分时间都花费在业务知识的学习上。对测试技术的研究就显得不那么重视。在去年需要学习新业务的时候，我做了个决定，想对测试技术进行研究。申请轮岗做自动化测试。

　　就我们现在的项目内手工测试和自动化测试工作职责，手工测试更注重对测试的思考，即如何进行测试方案或测试用例的编写，使得更有效的发现故障。自动化测试工作，更多的在实现和执行上。依照测试方案和现有的自动化测试模式进行测试用例的代码编写。缺少对测试的思考。

　　总结一下4年半的手工测试，头3年对业务好好的学习了一把，对sdh业务知识倒是了解的很全面，也对功能测试得出了一些经验总结。

　　1、通信业的独特性，业务的理解越深刻，就越能发现故障。对设备的了解越多，对网管软件的测试也越有帮助。所以对业务知识，设备知识的深入理解是成为一个通信业测试人员必不可少的能力。

　　2、对故障库中其他人提的故障学习，不管是自己项目的，还是其他相关项目（如设备项目）的故障进行定期分析，可以学习到其他人测试思路，不同的人不同的测试思路，集思广益。对测试方法的能力提升也是大有裨益的。还想到之前测试组展开的月例会，会将这个月发现的感觉有价值的故障进行描述，所用的测试方法，测试思路广而告之。大家在一起头脑风暴。这种也是测试的学习方法。

　　3、在手工测试中，常有的软件测试方法就已经覆盖的很全面了。如：边界值测试，等价类划分，错误推测法等，对于等价类，边界值和错误推测就已经够平常的测试使用，前两种一般用于正常流测试。第三种用于异常流测试。随着软件的逐渐成熟，异常流测试会在软件测试后期地位越来越高。

　　4、对需求的理解也是非常重要的，在测试前，需要对所测模块的需求文档进行学习。所有的东西都是依据需求文档进行的，虽然在实现过程中，需求更新不及时，这个时候要和需求人员进行有效的沟通，了解好实现细节，对功能模块的理解.

　　5、想到前段时间，一个玩的很好的同事（一个很有想法的人）和我提到她在测试中将测试用例用图表的方法表现出来，其实就是把一个业务流图表化，不同的操作，不同的测试结果，让人一目了然，比起用文字堆砌的用例来说，可读性更好。此外，测试点的编写比起把一步一步都详细的描述出来的用例更容易让人接受。特别对有经验的测试人员来说。

　　6、对于一个大型软件来说，多客户端测试和关联性测试也是故障发现点。在不同的客户端对同一个网元同一个功能同时进行操作，会出现什么问题。对一个功能模块做操作后，其他相关联的功能模块会出现什么情况，是否更新及时。在我这几年的测试经验发现的结论。

　　7、此外，细心和敏锐的观察力也是测试需要的能力，一个例子，删除一条配置，界面快闪了两次，后来开发人员定位是在数据库中更新数据后上报了两次导致的。

　　8、发散性思维也是测试人员的重要能力之一，多想想“如果...就会怎么样”，各种可能的情况都要想一想。

　　以上就是对手工测试的工作总结，如何把测试经验理论化，还需要再多加思考。

　　对于不到1年的自动化测试，其实还属于菜鸟阶段。我们项目的网管测试是使用QTP进行GUI界面测试。由于进入时间相对晚，错过了自动化框架搭建的初期阶段，主要工作是在这个框架上进行功能的操作开发。学习了vbs的脚本编写，对自动化工作流程熟悉起来。刚进入自动化测试组，是做用例迁移。把几个公共函数的功能了解了，后来对数据同步模块进行自动化测试开发，对数据同步的自动化实现是我感觉进入自动化测试组提高最快的时候。从函数设计，到代码实现，环境的搭建，数据准备等。但是不足的地方，是代码编写的还是太少，需要多多练习，对自动化测试框架的学习还是不太深入。如，用例的调度机制，错误处理机制都不太理解，如果让我自己搭建测试框架应该从哪些方面入手，还没有明确的思路。

　　在目前找工作时，这方面的定位有点不清，个人倾向于找自动化测试的工作，但是自己大部分时间还是做得手工测试。手工测试经验更足一些。从个人发展方向看，更想做得是对测试技术深入全面的学习。从用例设计，功能，自动化，性能都能掌握。

版权声明：本文出自 billylj 的51Testing软件测试博客：http://www.51testing.com/?477057

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。