|
回复 4# Ivy.xu 33. 你对测试最大的兴趣在哪里？为什么？
最大的兴趣就是测试有难度，有挑战性！做测试越久越能感觉到做好测试有多难。曾经
在无忧测试网上看到一篇文章，是关于如何做好一名测试工程师。一共罗列了 11，12 点，
有部分是和人的性格有关，有部分需要后天的努力。但除了性格有关的 1，2 点我没有把握，
其他点我都很有信心做好它。
刚开始进入测试行业时，对测试的认识是从无忧测试网上了解到的一些资料，当时是冲
着做测试需要很多技能才能做的好，虽然入门容易，但做好很难，比开发更难，虽然当时我
很想做开发（学校专业课我基本上不缺席，因为我喜欢我的专业），但看到测试比开发更难
更有挑战性，想做好测试的意志就更坚定了。
不到一年半的测试工作中，当时的感动和热情没有减退一点（即使环境问题以及自身经
验，技术的不足，做测试的你一定也能理解）。
我觉得做测试整个过程中有 2 点让我觉得很有难度（对我来说，有难度的东西我就非常
感兴趣），第一是测试用例的设计，因为测试的精华就在测试用例的设计上了，要在版本出
来之前，把用例写好，用什么测试方法写？（也就是测试计划或测试策略），如果你刚测试
一个新任务时，你得花一定的时间去消化业务需求和技术基础，业务需求很好理解（多和产
品经理和开发人员沟通就能达到目的），而技术基础可就没那么简单了，这需要你自觉的学
习能力，比如说网站吧，最基本的技术知识你要知道网站内部是怎么运作的的，后台是怎么
响应用户请求的？测试环境如何搭建？这些都需要最早的学好。至少在开始测试之前能做好
基本的准备，可能会遇到什么难题？需求细节是不是没有确定好？这些问题都能在设计用例
的时候发现。
第二是发现 BUG 的时候了，这应该是测试人员最基本的任务了，一般按测试用例开始
测试就能发现大部分的bug，还有一部分bug 需要测试的过程中更了解所测版本的情况获得
更多信息，补充测试用例，测试出bug 。还有如何发现bug ？这就需要在测试用例有效的情
况下，通过细心和耐心去发现bug 了，每个用例都有可能发现bug，每个地方都有可能出错，
所以测试过程中思维要清晰（测试过程数据流及结果都得看仔细了，bug 都在里面发现的）。
如何描述bug 也很有讲究，bug 在什么情况下会产生，如果条件变化一点点，就不会有这个
bug，以哪些最少的操作步骤就能重现这个bug，这个bug 产生的规律是什么？如果你够厉
害的话，可以帮开发人员初步定位问题。
34. 你的测试职业发展是什么？
测试经验越多，测试能力越高。所以我的职业发展是需要时间累积的，一步步向着高级
测试工程师奔去。而且我也有初步的职业规划，前 3 年累积测试经验，按如何做好测试工程
师的 11，12 点要求自己，不断的更新自己改正自己，做好测试任务。
35. 你自认为测试的优势在哪里？
优势在于我对测试坚定不移的信心和热情，虽然经验还不够，但测试需要的基本技能我
有信心在工作中得以发挥。
36. 你以前工作时的测试流程是什么？
公司对测试流程没有规定如何做，但每个测试人员都有自己的一套测试流程。我说下我
1 年来不断改正（自己总结，吸取同行的方法）后的流程吧。需求评审（有开发人员，产品
经理，测试人员，项目经理）－>需求确定(出一份确定的需求文档)－>开发设计文档（开发
人员在开始写代码前就能输出设计文档）－>想好测试策略，写出测试用例－>发给开发人
员和测试经理看看（非正式的评审用例）－>接到测试版本－>执行测试用例（中间可能会
补充用例）－>提交 bug （有些bug 需要开发人员的确定（严重级别的，或突然发现的在测
试用例范围之外的，难以重现的），有些可以直接录制进 TD）－>开发人员修改（可以在测
试过程中快速的修改）－>回归测试（可能又会发现新问题，再按流程开始跑）。
37. 当开发人员说不38. 是BUG 时，39. 你如何应付？
开发人员说不是bug，有2 种情况，一是需求没有确定，所以我可以这么做，这个时候
可以找来产品经理进行确认，需不需要改动，3 方商量确定好后再看要不要改。二是这种情
况不可能发生，所以不需要修改，这个时候，我可以先尽可能的说出是BUG 的依据是什么？
如果被用户发现或出了问题，会有什么不良结果？程序员可能会给你很多理由，你可以对他
的解释进行反驳。如果还是不行，那我可以给这个问题提出来,跟开发经理和测试经理进行
确认,如果要修改就改,如果不要修改就不改。其实有些真的不是 bug，我也只是建议的方式
写进TD 中，如果开发人员不修改也没有大问题。如果确定是bug 的话，一定要坚持自己的
立场，让问题得到最后的确认。 | 
/1 
关于我们
发表于 2012-2-10 14:46:05
QQ好友和群
QQ空间
腾讯微博
腾讯朋友
微信
收藏
置顶服务
换色服务
楼主
