头疼的单元测试
做单元测试的过程，我们兴奋过，低落过，冷静过，改革过，现在良性发展中，刚开始做的时候很兴奋，一天只知道写啊写啊，到头来写了很多单元测试用例，但到现在扔掉的也很多。当然原因也很多，主要还是测试目的的不明确，测试范围的不明确，测试标准不明确，对模块本向在产品中为何存在，为什么是这样存在没有弄清楚，走了很多湾路。
当然接到一个模块的测试任务时，应该与开发人员，系统测试人员和产品人员，了觖这个模块为什么存在，有什么功能，在产品中是怎么样的一个位置和作用。
要多读开发的代码，测试用例写完后，一定要调试一次测试案例，跟到开发的代码里面去，一行一行的看状态是不是正确，一般都会发现很多bug的。
测试一个模块不光要看是否正确实现了想要的功能，还要看开发这样写是不是合理，有没有改进的地方，并提出改进方案，开心的就是我们周围的一群同事常常在测试一个模块的时候就会写一封改进方案的邮件发给开发人员，并抄送给相关上级，在算法的简单，性能的提高，成本的减少都引到了很好的作用。这也是人们的开发人员很尊重我们测试人员提出的任务意见的原因，原因他们知道这个模块还有一个测试人员和他们自己一样对这个模块里的每一行代码都很熟悉。
测试的标准很难，怎么样才算这个模块测试好了，因为上级不用看你写的测试用例，他只要数据，但是给什么他才有说服力，我们在案例数，bug数等很多数据里选了代码覆盖率做为标准，虽然这个数据也不能充分说明测试的完整性，但相对来说还是比较有信服性。
测试用例在后期维护的时候，我们就头疼过，而且是很头疼，模块内部实现变了，接口变了，在产品里的位置变了，数据结构变了，我们的用例就天天跟着开发也在变。目前没有特别好的办法，只能看具体问题具体处理，在写用例的时候还是有一点点技巧的。
可恨的setup和teardown，之前对它的理解就是测试前的事情和测试后做的事情，所以不太注意这个地方，就引起测试用例一个一个运行是正常的，一批一批运行就失败了；一个人写的案例运行是正常的，两个写的案例在一起运行就失败了。一失败就是几百个，要找出是那个用例引起的测试环境的破坏，很痛苦。真的很痛苦！！！“吃掉自己的狗食”这句话用到这里绝对合适，不要仅把自己的setup做好，自己的teardown比setup更重要。
测试用例常失败的几个原因：
1、行为敏感性-如果系统的行为发生变化，如需求变了，这时测试就会失败。
2、接口敏感性
3、数据敏感性测试
4、上下文敏感。 顶，希望继续了解单元测试。 单元测试第一要明确测试对象-应该是模块设计而不是用户需求。还有在后期需求变动导致前期编写的很多单元测试失败，其实是一件好事，也是白盒测试的一大意义所在，就是实现代码控制。很多时候，这些失败的测试意味着你的设计改动对现有的功能模块产生了影响。需要仔细区分哪些是应该的更改导致的测试失败，哪些是没有想到的对模块的原有功能的影响。这里面就隐藏着BUG和改进空间。 说的很好 我现在也很头疼啊，因为什么都不会啊 {:4_83:} :hug: {:4_104:} {:3_68:}{:4_88:} {:3_69:} {:3_68:} :hug: {:4_89:} {:4_90:} :):victory: {:3_69:} {:3_69:} 写的很好啊，学习中 我建议还是做接口测试； 楼主说得好啊，在实际的过程中去编写单元测试挺难的，即使是给自己开发的代码写单元测试，也是不容易的，需要在平时的不断积累。
页:
[1]
