我的测试生活感悟(2)

　　说实话，挺高的。我们目前对自己的要求是至少70%，我们认为追求过高的代码覆盖率的意义并没有想象中的大。相反，过度要求高的代码覆盖率，可能会造成反面影响。

　　* 测试用例中对接口业务规则的验证是否完整。

　　关键词：业务规则，保证了业务规则，就保证了用户使用的大部分功能。

　　* 测试用例中是否覆盖接口之间的关联性测试。

　　* 遗留的 bug对系统的影响程度。

　　* 测试用例与测试代码是否一致。

　　我们主要通过CodeReview和自己的人品，并没有做太多严格的审核。

　　* 测试用例是否可持续回归。

　　* 经过测试的接口是否达到了调用方的标准，调用方能否使用该接口来开发出产品设计说明书所设计的应用。

　　可以看出，淘宝的接口测试评估标准还是挺全面的，做的确实不错!非常值得学习!

　　5. 还可以继续提高的地方(都是我们想要做的，就不一一点评了)：

　　* 测试数据管理框架构建与统一

　　* 接口测试项目构建基础框架

　　* mock 框架化

　　* 高比例代码自动生成框架

　　* 接口测试工具集与三方库的本地化应用

　　6. 测试未来遐想(想象力确实很丰富啊，同样也是我的梦想)：

　　* 测试虚拟化：提供接口测试虚拟机，构建测试虚拟化层。将被测系统运行在虚拟机中，与外部系统剥离，进行内部代码检测、内存检测、数据校验与逻辑检测。

　　* 测试智能化：智能分析系统代码，智能生成测试代码，智能 mock 外部系统，智能执行测试代码，智能分析测试结果，智能定位缺陷，智能修复缺陷。

　　7. 测试框架及工具组合：JUnit+DbUnit+Spring TestContext Framework+Unitils+TestNG+CruiseControl+Clover

　　感叹一下Java相关的框架就是多啊，不像C++，难啊!我们的组合是：GTest + GMock + CCNET(MSBUILD+Svn) + 自己开发的C++代码覆盖率统计工具

　　谈谈面试

　　我是一个没有什么经验的面试官，偶尔才参与几次面试。发现面试他人是一件技术要求非常高的工作，我们必须在很短的时间内了解一个人，如果方法不当，很有可能错失一个人才或是招入不合适的人。最近又参加了一个结构化面试的培训，由于之前并没有专门去研究面试，整个讲座听下来还是蛮有收获的。在讲座之后，我们又继续分享和交流了自己面试的一些感想和对结构化面试的一些看法。

　　1. 什么是结构化面试?按照我的理解就是：面试官使用精心设计的题目，让应聘者作答，作答过程中对题目只重复不解释，对解答的结果进行严格的评分。可以说，结构化面试对面试官的要求非常低，不需要解释题目意思，不回答应聘者提问，不需要随机问任何其他问题，只需要对照答案填1或是0。因此，可以看出，结构化面试对题目的要求是非常高的。

　　2. 为什么需要结构化面试?很多时候，面试官都是依靠感觉去面试别人，问的问题也比较即兴，感觉好了就招进来。然而，并不是每个面试官的感觉都是对的，依靠感觉做出的判断经常会出现偏差。因此，就需要对面试过程进行结构化，形成固定的模式，依靠高质量的、全面的、科学的试题，来衡量一个人的综合素质。

　　3. 应聘者只往好的方面答怎么办?结构化面试的试题中，并不一定往好的方面答就能给分。

　　4. 冰山以上的职业技能容易被发现，冰山以下的职业素质、道德、心态是比较难发掘和衡量的。

　　5. 面试他人前一定要提前了解应聘者履历，应聘职位的要求，准备一个安静舒适的环境进行面试。

　　6. 面试时不要轻易打断应聘者，不要发表自己的观点，不要告诉应聘者你答错了，不要把面试结果当场告诉应聘者。

　　7. 有的面试官比较自大，他们认为从来都不会输，因为被他们拒绝的应聘者根本没有机会展示他们的才能，而被他们招聘进来的人却总是最好的。

　　8. 有的面试官优越感太强，总是想方设法难倒应聘者，以显示其的威信。

　　9. 有的面试官不注重形象，给应聘者带来非常不好的印象，从而对整个的公司的形象造成影响。

　　10. 应该先对职业技能进行面试还是对性格态度心理素质进行面试?我认为应该先对职业技能进行考核，然后再对其他方面进行考核。职业技能的要求就是最基本的，在其上再讨论比如团队合作，工作心态才有意义。

　　11. 我觉得不应该只招聘同样性格的人，性格可以有多样化，内向的，外向的，都可以。

　　12. 照搬结构化面试其实是不行的，一定要依据自身特点，进行合理的运用才能获得最好的效果。

　　13. 面试是一个很大的学问，我现在只能领悟到这么多了。

　　不要被代码覆盖率蒙蔽双眼

　　新年新开始，继续我的测试生活感悟。“代码覆盖率”是一个有意思的话题，围绕它的讨论有很多。基本上，人们都认识到了，代码覆盖率并不能说明测试的好坏，它只是一个度量方法，用于度量我们测试的广度。它只能告诉你，你的测试代码覆盖了哪些被测的代码，并没有告诉你，覆盖的被测代码是否测试好。

　　代码覆盖率有诸多好处：

　　1. 能一定程度上说明测试覆盖的广度。

　　2. 通过代码覆盖率结果，能够比较直观的了解到哪些代码未被测试，哪些分支未被覆盖，进而补充相应的测试案例。

　　3. 代码覆盖率具有非常好的可操作性，可以在一定程度上衡量测试人员的工作。

　　4. 代码覆盖率给程序员和测试人员以信心。

　　但是，即使你的代码覆盖率达到了80%或者更高，不要被代码覆盖率蒙蔽了双眼!

　　1. 好好回想一下覆盖的80%的代码中，你一共发现了几个Bug?

　　2. 剩下的20%代码，极有可能产生80%的Bug!

　　3. 覆盖的80%代码中，你真正进行验证的代码函数有多少?

　　4. 覆盖的80%代码中，你真正了解的代码有多少?或者说，有多少代码是无意间被执行的。

　　5. 你是否保证了不同操作系统下测试案例的执行?

　　6. 这80%覆盖的代码中，你是否偷懒省去了某些复杂的检查点的检查?

原文转自：http://www.ltesting.net