1、前言
过年回来之后，业务的功能测试渐渐多了起来，我之前一直负责的是PC方面的测试，而现在除了负责PC的业务测试之外，还负责无线业务的测试。骤然间自己所有的时间差不多都被功能测试任务占据了，到2月份末的时候，关于测试任务的排期都排到了4月初。
在这功能测试的狂轰滥炸中，慢慢的对于服务端重服务的功能测试有了更多的体会，趁着周末空闲的时间整理一下，以飨各位读者。
2、功能测试就是手工测试？
早些时候一直有这样的误区，认为功能测试就是手工测试。现在在脉脉的匿名区还有好多同学在感叹，不想做功能测试了，咨询自动化测试好不好学之类的问题。
在某些同学的潜意识里，认为web端的功能测试就是点点点，服务端方面的功能测试也就是手动构造数据，验证逻辑，这虽然比点点点好上一些，但仍没有跳出手工测试的范畴。对于以上的观点，我个人是不认同的，我认为将功能测试完全等同于手动测试是不恰当的，同样将功能测试与自动化测试完全分开来看也是不合理的。
从我自己功能测试的经验来看，将功能测试转变为自动化测试的一部分是效率最高的一种方法。在阐述这个问题之前，我先大致说一下我之前测试的一般情况。当开发提交测试之后，就根据测试单中的信息，手动构造数据，然后启动服务，验证本次提测的业务逻辑，其实这也是最典型的服务端功能测试的流程。这样做的好处就是可以快速的验证本次提测的业务功能，弊端就是当需要构造的数据量太大的时候，时间的成本也会很高。
除此之外，使用手动构造数据进行功能测试，在多次功能回归的情况下，测试人员是崩溃的，因为开发每修改一些代码，你就要把之前的case都过一遍。PC业务线之前就是这样的做法，先进行手工功能测试，后续抽时间在填充相关的测试case。无线业务线恰恰采用了另一个方法，先抽时间将case写完，然后根据提测需要完善相关case。
在两条业务线实验了一段时间发现，无线业务线所采用的方法，也就是将功能测试变为自动化测试的一部分，效率要高很多。特别是由于一些需求变动，或者少量代码修改，需要验证是否影响之前所测功能的时候，效果尤为明显。这个时候我就让开发人员自己去跑一遍自动化case，而我也从重复的功能性结果验证中解放了出来。这个小主题的意义在于，是否能将现有的功能测试，整合进自动化测试中，当然不同的业务的要求也不一定一致，大家根据自己业务的特点，自行评估即可。
3、讨论维护自动化case的必要性
虽然自动化测试有很多的好处，但是维护自动化case确充满了痛苦，甚至有些时候你恨不得从此再也不用它了。让人如此仇恨的原因，每次跑case失败的太多，而且失败的case大部分是很久之前的功能，很多时候你根本就从来没有听说过这个功能，这种情况下去查看与之相关的case为何失败，我相信很多人面对这种情况，心情都不会太好。
通常情况下，你排查了良久，也无法判断为何某些case失败，郁闷的心情可想而知，这个时候你可能会想，如果只是回归当前提测的功能该是多么幸福的一件事。在经历了多次这种事情后，慢慢的也察觉了一些规律，以及排除某些错误case的方法。就像电视上或者生活中没有无缘无故的爱，也没有无缘无故的恨一样，在自动化case的回归的世界中，也没有无缘无故就失败的case，每一个失败的case都有其失败的原因。
当错误的case发生时，需要排查代码的上一个版本中该case是不是失败。一般情况下，上一个版本的case应该都是全部通过的，因为如果case不通过肯定无法上线嘛。这个时候你就对比当前代码的版本和上一个代码版本，看看究竟是修改了那些内容使得case失败了。通过代码文件静态对比，以及运行期间的gdb单步调试，我想找出失败case的原因不是难事。
经历过多次这样的事情后，就看的比较开了，出现失败的case也会慢慢的去分析原因，不用一出现问题就去喊开发。在这里多说一句，测试人员和开发人员应该保持相对的独立性，不要什么都依靠着开发，如果真的需要找开发来解决某些问题，你应该能大致知道问题出错可能的原因在什么地方。
过年回来之后，业务的功能测试渐渐多了起来，我之前一直负责的是PC方面的测试，而现在除了负责PC的业务测试之外，还负责无线业务的测试。骤然间自己所有的时间差不多都被功能测试任务占据了，到2月份末的时候，关于测试任务的排期都排到了4月初。
在这功能测试的狂轰滥炸中，慢慢的对于服务端重服务的功能测试有了更多的体会，趁着周末空闲的时间整理一下，以飨各位读者。
2、功能测试就是手工测试？
早些时候一直有这样的误区，认为功能测试就是手工测试。现在在脉脉的匿名区还有好多同学在感叹，不想做功能测试了，咨询自动化测试好不好学之类的问题。
在某些同学的潜意识里，认为web端的功能测试就是点点点，服务端方面的功能测试也就是手动构造数据，验证逻辑，这虽然比点点点好上一些，但仍没有跳出手工测试的范畴。对于以上的观点，我个人是不认同的，我认为将功能测试完全等同于手动测试是不恰当的，同样将功能测试与自动化测试完全分开来看也是不合理的。
从我自己功能测试的经验来看，将功能测试转变为自动化测试的一部分是效率最高的一种方法。在阐述这个问题之前，我先大致说一下我之前测试的一般情况。当开发提交测试之后，就根据测试单中的信息，手动构造数据，然后启动服务，验证本次提测的业务逻辑，其实这也是最典型的服务端功能测试的流程。这样做的好处就是可以快速的验证本次提测的业务功能，弊端就是当需要构造的数据量太大的时候，时间的成本也会很高。
除此之外，使用手动构造数据进行功能测试，在多次功能回归的情况下，测试人员是崩溃的，因为开发每修改一些代码，你就要把之前的case都过一遍。PC业务线之前就是这样的做法，先进行手工功能测试，后续抽时间在填充相关的测试case。无线业务线恰恰采用了另一个方法，先抽时间将case写完，然后根据提测需要完善相关case。
在两条业务线实验了一段时间发现，无线业务线所采用的方法，也就是将功能测试变为自动化测试的一部分，效率要高很多。特别是由于一些需求变动，或者少量代码修改，需要验证是否影响之前所测功能的时候，效果尤为明显。这个时候我就让开发人员自己去跑一遍自动化case，而我也从重复的功能性结果验证中解放了出来。这个小主题的意义在于，是否能将现有的功能测试，整合进自动化测试中，当然不同的业务的要求也不一定一致，大家根据自己业务的特点，自行评估即可。
3、讨论维护自动化case的必要性
虽然自动化测试有很多的好处，但是维护自动化case确充满了痛苦，甚至有些时候你恨不得从此再也不用它了。让人如此仇恨的原因，每次跑case失败的太多，而且失败的case大部分是很久之前的功能，很多时候你根本就从来没有听说过这个功能，这种情况下去查看与之相关的case为何失败，我相信很多人面对这种情况，心情都不会太好。
通常情况下，你排查了良久，也无法判断为何某些case失败，郁闷的心情可想而知，这个时候你可能会想，如果只是回归当前提测的功能该是多么幸福的一件事。在经历了多次这种事情后，慢慢的也察觉了一些规律，以及排除某些错误case的方法。就像电视上或者生活中没有无缘无故的爱，也没有无缘无故的恨一样，在自动化case的回归的世界中，也没有无缘无故就失败的case，每一个失败的case都有其失败的原因。
当错误的case发生时，需要排查代码的上一个版本中该case是不是失败。一般情况下，上一个版本的case应该都是全部通过的，因为如果case不通过肯定无法上线嘛。这个时候你就对比当前代码的版本和上一个代码版本，看看究竟是修改了那些内容使得case失败了。通过代码文件静态对比，以及运行期间的gdb单步调试，我想找出失败case的原因不是难事。
经历过多次这样的事情后，就看的比较开了，出现失败的case也会慢慢的去分析原因，不用一出现问题就去喊开发。在这里多说一句，测试人员和开发人员应该保持相对的独立性，不要什么都依靠着开发，如果真的需要找开发来解决某些问题，你应该能大致知道问题出错可能的原因在什么地方。
