中国的CMMB，真够戗！

自从俺们一帮人开始做CMMB，耗时耗力不说，标准还总是在变！一个措手不及，就推迟了俺们项目的进展。哎，如今的CMMB，已经成为俺们组众多项目中的一个，没办法，原本指望它带来桶金，可是，靠不住了！

不仅如此，CMMB又整了CA加密，这标准也都不是很透明，哎，大卡，小卡，又SMD的，听说主流是SMD，结果俺们又把时间都耗在了小卡上！呜呼哀哉！

何时才有出路啊？

到目前为止我测过的功能如下：

１．CMMB移动电视　（CMMB）

２．DVB-T移动电视 （DVB）

３．音乐播放器　（MusicPlayer）

４．电影播放器 （VideoPlayer）

５．图片播放器 （PhotoPlayer）

６．电子书播放器 （eBook）

７．文件浏览器 （File Browser）

８．GPS导航 （GPS）

９．无限上网 （Wifi）

１０．网络浏览器 （Web Browser）

１１．设置　（Setting）

１２．视频输入　（TV in）

１３．视频输出　（TV out）

１４．电纸书　（epbooks）

 

大家测过什么功能或产品，来分享吧！

 

１年没来这里溜达，所以１年没写日记了！

翻看上一篇惊讶地发现，去年的１月还憧憬着新来的经理可以教我们做白盒测试。实际呢，只是磨刀霍霍，这１年没啥本质改变。并且测试组不负责白盒测试的，我们就是QC，本该踏踏实实写测试用例、设计测试流程、按用例做测试、报bug、重现bug、测试总结、测试报告。。。

如此这般，我来这公司，做了１年半的测试了，重复的工作也做了不少，但其实测试的觉悟还是提升了不少！

至少我现在明白我一天该干啥，测试该干啥，不是白盒测试、也莫提单元测试、集成测试！咱按流程办事，单元测试是开发人员做的，集成测试是集成人员做的！咱做啥呢，就是系统测试和确认测试！我刚来时，测试同仁都羡慕做过白盒测试的人！哎，实在是不懂管子。。。

在这辞旧迎新之际，畅想一下未来吧！我作为小小的test team leader，艰苦奋斗了一年半，把这不毛之地，没啥测试流程和理念的开发团队和测试团队，变的有些春意盎然了，我定会继续努力，改善测试流程，改善管理流程。。。

期待明年的总结！

This is new year 2009.

It seems better than before for me.

I'm testing embedded software, although only testing function in black-box ways.

But I'm happy and have hope for future.

In the future, we'll have a new comer for white-box testing engineer, maybe he can teach us or we can study from him.

Now I believe God love me and He love my effort. He'll give me his new year gift--

gaining and pleasure.

Thanks God--my dear father and friend and best teacher.

 

 

        “又是一年毕业时”，看到一批批学子离开人生的象牙塔，走上各自的工作岗位；想想自己也曾经意气风发、踌躇满志，不觉感叹万千……本文是自己工作6年的经历沉淀或者经验提炼，希望对所有的软件工程师们有所帮助，早日实现自己的人生目标。本文主要是关于软件开发人员如何提高自己的软件专业技术方面的具体建议，前面几点旨在确定大的方向，算是废话吧。

        谨以此文献给那个自己为你奉献3年青春与激情的开发团队。还有团队成员：PPL、YT、YK 、TYF、LGL、CHL、CDY、CB、DPD。

        1、分享第一条经验：“学历代表过去、能力代表现在、学习力代表未来。”其实这是一个来自国外教育领域的一个研究结果。相信工作过几年、十几年的朋友对这个道理有些体会吧。但我相信这一点也很重要：“重要的道理明白太晚将抱憾终生！”所以放在每一条，让刚刚毕业的朋友们早点看到哈！

        2、一定要确定自己的发展方向，并为此目的制定可行的计划。不要说什么，“我刚毕业，还不知道将来可能做什么？”，“跟着感觉走，先做做看”。因为，这样 的观点会通过你的潜意识去暗示你的行为无所事事、碌碌无为。一直做技术，将来成为专家级人物？向管理方向走，成为职业经理人？先熟悉行业和领域，将来自立 门户？还是先在行业里面混混，过几年转行做点别的？这很重要，它将决定你近几年、十年内“做什么事情才是在做正确的事情！”。

        3、软件开发团队中，技术不是万能的，但没有技术是万万不能的！在技术型团队中，技术与人品同等重要，当然长相也比较重要哈，尤其在MM比较多的团队中。 在软件项目团队中，技术水平是受人重视和尊重的重要砝码。无论你是做管理、系统分析、设计、编码，还是产品管理、测试、 文档、实施、维护，多少你都要有技术基础。算我孤陋寡闻，我还真没有亲眼看到过一个外行带领一个软件开发团队成功地完成过软件开发项目，哪怕就一个，也没 有看到。倒是曾经看到过一个“高学历的牛人”(非技术型)带一堆人做完过一个项目，项目交付的第二天，项目组成员扔下一句“再也受不了啦！”四分五裂、各 奔东西。那个项目的“成功度”大家可想而知了。

        4、详细制定自己软件开发专业知识学习计划，并注意及时修正和调整(软件开发技术变化实在太快)。请牢记：“如果一个软件开发人员在1、2年内都没有更新 过自己的知识，那么，其实他已经不再属于这个行业了。”不要告诉自己没有时间。来自时间管理领域的著名的“三八原则”告诫我们：另外的那8小时如何使用将 决定你的人生成败！本人自毕业以来，平均每天实际学习时间超过2小时。

        5、书籍是人类进步的阶梯，对软件开发人员尤其如此。书籍是学习知识的最有效途径，不要过多地指望在工作中能遇到“世外高人”，并不厌其烦地教你。对于花 钱买书，我个人经验是：千万别买国内那帮人出的书！我买的那些家伙出的书，!00%全部后悔了，无一本例外。更气愤的是，这些书在二手市场的地摊上都很难 卖掉。“拥有书籍并不表示拥有知识；拥有知识并不表示拥有技能；拥有技能并不表示拥有文化；拥有文化并不表示拥有智慧。”只有将书本变成的自己智慧，才算 是真正拥有了它。

        6、不要仅局限于对某项技术的表面使用上，哪怕你只是偶尔用一、二次。“对任何事物不究就里”是任何行业的工程师所不应该具备的素质。开发Windows应 用程序，看看Windows程序的设计、加载、执行原理，分析一下PE文件格式，试试用SDK开发从头开发一个Windows应用程序；用VC＋＋、 Delphi、Java、.Net开发应用程序，花时间去研究一下MFC、VCL、J2EE、.Net它们框架设计或者源码；除了会用J2EE、 JBoss、Spring、Hibernate等等优秀的开源产品或者框架，抽空看看大师们是如何抽象、分析、设计和实现那些类似问题的通用解决方案的。 试着这样做做，你以后的工作将会少遇到一些让你不明就里、一头雾水的问题，因为，很多东西你“知其然且知其所以然”！

        7、在一种语言上编程，但别为其束缚了思想。“代码大全”中说：“深入一门语言编程，不要浮于表面”。深入一门语言开发还远远不足，任何编程语言的存在都 有其自身的理由，所以也没有哪门语言是“包治百病”的“灵丹妙药”。编程语言对开发人员解决具体问题的思路和方式的影响与束缚的例子俯拾皆是。我的经验 是：用面对对象工具开发某些关键模块时，为什么不可以借鉴C、C51、汇编的模块化封装方式？用传统的桌面开发工具(目前主要有VC++、Delphi) 进行系统体统结构设计时，为什么不可以参考来自Java社区的IoC、AOP设计思想，甚至借鉴像Spring、Hibernate、JBoss等等优秀 的开源框架？在进行类似于实时通信、数据采集等功能的设计、实现时，为什么不可以引用来自实时系统、嵌入式系统的优秀的体系框架与模式？为什么一切都必须 以个人、团队在当然开发语言上的传统或者经验来解决问题？？？“他山之石、可以攻玉”。

        8、养成总结与反思的习惯，并有意识地提炼日常工作成果，形成自己的个人源码库、解决某类问题的通用系统体系结构、甚至进化为框架。众所周知，对软件开发 人员而言，有、无经验的一个显著区别是：无经验者完成任何任务时都从头开始，而有经验者往往通过重组自己的可复用模块、类库来解决问题（其实这个结论不应 该被局限在软件开发领域、可以延伸到很多方面）。这并不是说，所有可复用的东西都必须自己实现，别人成熟的通过测试的成果也可以收集、整理、集成到自己的 知识库中。但是，最好还是自己实现，这样没有知识产权、版权等问题，关键是自己实现后能真正掌握这个知识点，拥有这个技能。

        9、理论与实践并重，内外双修。工程师的内涵是：以工程师的眼光观察、分析事物和世界。一个合格的软件工程师，是真正理解了软件产品的本质及软件产品研发 的思想精髓的人（个人观点、欢迎探讨）。掌握软件开发语言、应用语言工具解决工作中的具体问题、完成目标任务是软件工程师的主要工作，但从软件工程师这个 角度来看，这只是外在的东西，并非重要的、本质的工作。学习、掌握软件产品开发理论知识、软件开发方法论，并在实践中理解、应用软件产品的分析、设计、实 现思想来解决具体的软件产品研发问题，才是真正的软件工程师的工作。站在成熟理论与可靠方法论的高度思考、分析、解决问题，并在具体实践中验证和修正这些 思想与方式，最终形成自己的理论体系和实用方法论。

        10、心态有多开放，视野就有多开阔。不要抱着自己的技术和成果，等到它们都已经过时变成垃圾了，才拿出来丢人现眼。请及时发布自己的研究成果：开发的产 品、有创意的设计或代码，公布出来让大家交流或者使用，你的成果才有进化和升华的机会。想想自己2000年间开发的那些Windows系统工具，5、6年 之后的今天，还是那个样子，今天流行的好多Windows系统工具都比自己的晚，但进化得很好，且有那么多用户在使用。并且，不要保守自己的技术和思想， 尽可能地与人交流与分享，或者传授给开发团队的成员。“与人交换苹果之后，每个人还是只有一个苹果；但交换思想之后，每个人都拥有两种思想”，道理大家都 懂，但有多少人真正能做到呢？

        11、尽量参加开源项目的开发、或者与朋友共同研制一些自己的产品，千万不要因为没有钱赚而不做。网络早已不再只是“虚拟世界”，网上有很多的开源项目、 合作开发项目、外包项目，这都是涉猎工作以外的知识的绝好机会，并且能够结识更广的人缘。不要因为工作是做ERP，就不去学习和了解嵌入式、实时、通信、 网络等方面的技术，反过来也是一样。如果当别人拿着合同找你合作，你却这也不会，那也不熟时，你将后悔莫及。

        12、书到用时方恨少，不要将自己的知识面仅仅局限于技术方面。诺贝尔经济学奖得主西蒙教授的研究结果表明： “对于一个有一定基础的人来说，他只要真正肯下功夫，在6个月内就可以掌握任何一门学问。”教育心理学界为感谢西蒙教授的研究成果，故命名为西蒙学习法。 可见，掌握一门陌生的学问远远没有想想的那么高难、深奥。多方吸取、广泛涉猎。极力夯实自己的影响圈、尽量扩大自己的关注圈。财务、经济、税务、管理等等 知识，有空花时间看看，韬光养晦、未雨绸缪。

        13、本文的总结与反思：

        A：不要去做技术上的高手，除非你的目标如此。虽然本文是关于提高软件开发知识的建议，做技术的高手是我一向都不赞同的。你可以提高自己的专业知识，但能胜任工作即止。

        B：提高软件知识和技术只是问题的表面，本质是要提高自己认识问题、分析问题、解决问题的思想高度。软件专业知识的很多方法和原理，可以很容易地延伸、应用到生活的其它方面。

        C：在能胜任工作的基础上，立即去涉猎其它领域的专业知识，丰富自己的知识体系、提高自己的综合素质，尤其是那些目标不在技术方面的朋友。

我的理想很简单：拥有一份职业。然后开开心心的去工作。开开心心地生活。开开心心地学习。开开心心地走完人生之路。。。

      为什么不把面试看成是一场难得的对话？试着更多地把自己定位为一个前来学习人生和工作经验的学生，而面试官作为一个愿意与你分享关于工作、职业发展和 人生经验的前辈。你会发现，抱着这种心态，面试压抑的气氛在不知不觉中从一问一答，而慢慢地变成了一个双向的交流。事实上，甚至应该这么说，能够和杰出的 职场人士如此平等、轻易地交流（特别是想到这些人将来可能会是你好几个级别以上的老板时），面试真是再理想不过的一个机会了。
      对于那些平日忙于在商业世界里打拼的面试官们来说,有机会回想到自己的过去，见到一张张写满渴望、勇气的脸庞，为什么不和眼前的这个看上去聪明、可爱和善解人意的孩子聊聊自己的过去，指点一下他未来的发展，多获得一些崇敬的目光呢？他们当然会这样做，只要你给他们机会。
      对于任何一个富有远见的组织来说，招揽到出色的人才，无论对于公司还是其他机构，都是成功地完成自己的使命的基础。面试对于公司的意义在于，提供一个认识 候选人的机会，从而在此基础上判断，谁是更加适合公司需要的人才。尽管，每家公司的面试组织程序会有所不同，但是它们还是有基本相同的先后顺序。了解这些 基本的程序，能够帮助面试者减少对面试的神秘感，增加信心，更好地设计自己的面试策略。
通常面试程序可以被分成以下几个部分：
　　（1）确定所需要招聘的职位的工作描述、薪酬范围和应聘者所需要的资格。
　　（2）通过招聘会、海报、广告等形式，把招聘信息传达给潜在的应聘者。
　　（3）收集应聘者的简历，筛选简历得到可以进一步面试的合适数量的应聘者。
　　（4）电话面试。一般由人力资源部门或者资历比较浅的分析员或者咨询员打来，在面试中进一步确认应聘者的背景、语言表达能力等。通过筛选得到可以进一步面试的合适数量的应聘者。
　　（5）第一轮面试。
　　（6）第二轮面试。
　　（7）确定入选的候选人，人力资源部门和他们保持联系，推销公司，确保他们接受合同。同时，公司也可能继续和几个作为万一“正选”拒绝接受要约后的“后备”候选人保持“暧昧”的关系。
　　（8）人力资源部最后检查应聘者的背景、提供的材料无误。

　    你在申请公司的时候不一定会经历所有的程序。比方说，电话面试往往只是那些非常强调英语口语能力的外企才有的步骤，他们希望借此道程序排除一部分口语能力不强的应聘者，国企、私营企业或者政府机关，基本上不会有这道门槛。
        爱因斯坦曾经这样对年轻学生解释过相对论：当你和一个美丽的姑娘坐上两个小时，你会感到好像坐了1分钟；但要是在炽热的火炉边，哪怕只坐上1分钟，你却感到好像是坐了两小时。
　 　  同样，面试可能是世界上最漫长的30分钟，也可能是世界上最短暂的30分钟。当你和你的面试官都有一种频频想看表的冲动时，抱歉，你的这场面试看起来是 失败了。而当你走出面试间，一低头看表，发现不知不觉地已经超出了30分钟时，这往往是证明你刚才的面试进行得很顺利。
　　   一个面试官就曾经告诉我，当他在面试开始5分钟后，就决定不可能给这个应聘者任何机会的时候，他恨不得立刻就结束这场面试。但是，他不能，因此，他只好盯着手表，等到刚过25分钟的时候，立刻开始问应聘者：你还有什么问题吗？
       对你而言，控制时间和节奏成为了和给出好的答案同样重要的任务，如果前者不是更重要的话。有几个重要的原则你必须记住：
（1）你必须努力掌握对节奏的控制权，而不要把它交给你的面试官。
　　 如果你回答问题总是拖沓冗长、毫无逻辑也看不出什么时候能结束，面试官会不得不总是打断你的回答：“我明白你的意思了，那么，下一个问题是……”这种被打断回答的情况往往会带来紧张，出现几次，你就会发现清晰的思维和顺畅的表达就这样被打断了。
　　 所以，千万不要给面试官这种机会。通常情况下，只要你把握得当，他们也并不会主动地抢。
　 　 然而也有这样的面试，面试官无意或者故意地不断打断你的回答，试图获得面试节奏的控制权。那么，在这种情况下，你必须保持冷静，努力地把节奏感再抢回 来。你可以在面试官突然打断你的回答，插入一个问题时，有意识地保持10秒钟的沉默，装作在思索这个问题，实际上是在冷静，找回自信和节奏，然后用一种和 刚才回答问题不同的语速重新开始。还有的时候，当你觉得你是在回答到关键时刻被打断的话，不要就此罢休，你应该在回答被打断之后的新问题前，有礼貌地说： “在我回答这个问题之前，我觉得我应该对刚才那个问题的回答补充一点……”然后尽快完成你刚才没有机会完成的观点。

（2）永远不要在一个问题上纠缠太久。
　 　 这15分钟，或者说整个面试，就是一张你无法先看到整张试卷的试题，有点像GRE的机考，更糟糕的是，你实际上连每道题的分值都不知道。在面试的时候， 你不知道你在努力地向面试官说清楚的那个复杂的问题究竟能给你增加多少分，而你花了七八分钟在这个问题上，也可能下一个问题对你来说既简单、分数又多。所 以，当一个问题开始出现你很难说清的情况时，不要纠缠太久，简单地说：“关于这个问题，我想我现在只能说出这么多了。”让面试向你的下个机会走去。

（3）在15分钟内取得尽量多的共识。
　　 在一般情况下，面试官不是来寻找一个永远的“持异议者”的。当你在回答一些关于观点、价值、方法方面的问题时，你会发现，也许经常会出现面试官频频点头，或者他面无表情，甚至摇头的情况。点头很大程度上说明你们的共识，而通常，共识比异议更容易给你的表现加分。
　　 熬过了这15分钟后，接下来是你最后的机会了。面试官通常会问你有没有任何问题问他。永远别说没有，除非他之前告诉你他已经决定录用你了。最后的问题可能毁了你之前的所有的努力，也可能把你从一场失败的面试中挽救回来。
　　 然而想出一个好的、最后的问题往往比准备一个好的自我介绍还要难。有的时候，你希望通过一个好的问题，让人对你刮目相看。但是通常你会发现，更容易的是问一个面试官有话可回答的问题，然后你加上几句评价，把这个面试画上句号。
　 　 如果你之前的面试进行得都很顺利的话，在最后一个问题上应该保守一些，只要不犯错误就行。所以你可以问问面试官怎么走进这一行的，怎么看待这一行等等。 如果你之前的面试感觉不佳，你希望通过最后一个问题来绝地反击的话，你不妨问面试官一个让他给你出主意的问题，顺带着你可以说出一个你没有来得及在面试中 提起的卖点，加深面试官对你正面的评价。
　　 比方说，我知道的一个聪明的问题，我的一个好朋友明白自己在面试中的英语口语能力令面试官一 直表现得对她缺乏兴趣，于是她最后问道：“您知道，我在高中的时候一直是学俄语的，进入大学后我才从ABC开始学英语，现在刚刚学了3年。虽然我已经可以 在托福考试中取得630分的成绩，但我知道我的英语口语还需要很大的提高，您能在这方面给我一些好的指点吗？”
　　 那位香港长大、哈佛毕业的面试官立刻有些羞涩地说：“不、不，你的英语已经很让人满意了。我是中国人，我的中文说得还没有你的英文好。你只学了3年就已经这么好了，应该是你给我一些指点。”
　　 结果，这个只学了3年英语的女孩子击败了其他学了十几年英文、口语比她好得多的竞争者——我觉得她就只用了这最后一个问题即确定胜势。

[1]好好规划自己的路，不要跟着感觉走！根据个人的 理想决策安排，绝大部分人并不指望成为什么院士或教授，而是希望活得滋润一些，爽一些。那么，就需要慎重安排自己的轨迹。从哪个行业入手，逐渐对该行业深 入了解，不要频繁跳槽，特别是不要为了一点工资而转移阵地，从长远看，这点钱根本不算什么，当你对一个行业有那么几年的体会，以后钱根本不是问题。频繁地 动荡不是上策，最后你对哪个行业都没有摸透，永远是新手！

[2]可以做技术，切不可沉湎于技术。千万不可一门心思钻研技术！给自己很大压力，如果你的心思全部放在这上面，那么注定你将成为孔乙己一类的人物！适可而止为之，因为技术只不过是你今后前途的支柱之一，而且还不是最大的支柱，除非你只愿意到老还是个工程师！

[3]不要去做技术高手，只去做综合素质高手！在企业里混，我们时常瞧不起某人，说他“什么都不懂，凭啥拿那么多钱，凭啥升官！”这是普遍的典型的工程师的迂腐之言。

很牛吗？人家能上去必然有他的本事，而且是你没有的本事。你想想，老板搞经营那么多年，难道见识不如你这个新兵？人家或许善于管理，善于领会老板意 图，善于部门协调等等。因此务必培养自己多方面的能力，包括管理，亲和力，察言观色能力，攻关能力等，要成为综合素质的高手，则前途无量，否则只能躲在角 落看示波器！技术以外的技能才是更重要的本事！！从古到今，美国日本，一律如此！

[4]多交社会三教九流的朋友！不要只和工程师交往，认为有共同语言，其实更重要的是和其他类 人物交往，如果你希望有朝一日当老板或高层管理，那么你整日面对的就是这些人 。了解他们的经历，思维习惯，爱好，学习他们处理问题的模式，了解社会各个角落的现象和问题，这是以后发展的巨大的本钱，没有这些以后就会笨手笨脚，跌跌 撞撞，遇到重重困难，交不少学费，成功的概率大大降低！

[5]知识涉猎不一定专，但一定要广！多看看其他方面的书，金融，财会，进出口，税务， 法律等等，为以后做一些积累，以后的用处会更大！会少交许多学费！！

[6]抓住时机向技术管理或市场销售方面的转变！要想有前途就不能一直搞开发，适当时候 要转变为管理或销售，前途会更大，以前搞技术也没有白搞，以后还用得着。搞管理可以培养自己的领导能力，搞销售可以培养自己的市场概念和思维，同时为自己 以后发展积累庞大的人脉！应该说这才是前途的真正支柱！！！
[7]逐渐克服自己的心里弱点和性格缺陷！多疑，敏感，天真（贬义，并不可爱）， 犹豫不决，胆怯，多虑，脸皮太薄，心不够黑，教条式思维。。。这些工程师普遍存在的性格弱点必须改变！很难吗？只在床上想一想当然不可能，去帮朋友守一个 月地摊，包准有效果 ，去实践，而不要只想！不克服这些缺点，一切不可能，甚至连项目经理都当不好--尽管你可能技术不错！
[8]工作的 同时要为以后做准备！建立自己的工作环境！及早为自己配置一个工作环境，装备电脑，示波器（可以买个二手的），仿真器，编程器等，业余可以接点活，一方面 接触市场，培养市场感觉，同时也积累资金，更重要的是准备自己的产品，咱搞技术的没有钱 ，只有技术，技术的代表不是学历和证书，而是产品，拿出象样的产品，就可技术转让或与人合作搞企业！先把东西准备好，等待机会，否则，有了机会也抓不住！

[9]要学会善于推销自己！不仅要能干，还要能说，能写，善于利用一切机会推销自己，树 立自己的品牌形象，很必要！要创造条件让别人了解自己，不然老板怎么知道你能干？外面的投资人怎么相信你？提早把自己推销出去，机会自然会来找你！搞个个 人主页是个好注意！！特别是培养自己在行业的名气，有了名气，高薪机会自不在话下，更重要的是有合作的机会...

[10]该出手时便出手！永远不可能有100%把握！！！条件差不多就要大胆去干，去闯出自己的事业，不要犹豫，不要彷徨，干了不一定成功，但至少为下一次冲击积累了经验，不干永远没出息，而且要干成必然要经历失败。不经历风雨，怎么见彩虹，没有人能随随便便成功。

        产品开发初期需要测试人员吗？如果需要，他们要作哪些工作？这些问题曾经被很多朋友问起。据我个人了解，很多国内中小型公司是不注重产品开发初期乃至整个开发过程中的测试工作的。例证一：有些公司认为在设计初期投入测试人员是代价高昂且无意义的，所以他们会要求产品开发的第一个周期结束后，开始设计测试用例。 例证二：认为测试工程师不需要参与到制定需求中，他们只要接受就可以了。于是乎，就出现了市场部门和开发部门直接沟通项目需求，测试经理直接参考需求设计 文档的状况。例证三：测试经理确实在产品开发初期参与项目需求的制定，并写出测试计划。但产品质量却是现场部署的工程师说了算。到了现场，发现这里不合用 户的意，那里运行不过。为了赶时间，只好坐在用户现场直接调试。改代码的改代码，调试的调试，哪里还管着产品是否需要全面的测试，只要能运行起来，用户能 用，就是胜利……

        权且不说这些管理行为是否更加浪费工钱，我们应该很容易得到关于“产品开发初期测试人员该做些什么”的一致答复：测试计划在开发初期能写挺好，不写也没什 么问题。测试一定要做的。但把怎样的产品交给用户是不确定的。目标就有一个，让用户用上再说——无论是对一个已经经营多年的产品，还是一个刚起步的公 司……

        其实，对测试的理解不是点头说，测试很重要就够了； 对测试的理解不是去声称，我们有一柜子完整的测试文档；对测试的理解也不是只关心“做与不做”，而全然不理测试的有效性。

        软件测试该如何理解如何执行，是一个很大的题目。在这里，我更关心的是在项目设计初期，我们该不该忽略测试人员，而测试人员又该做些什么样的工作。

        微软最 新的软件开发周期（product life cycle）分为产品定义（Product Definition），产品开发（Product Development），产品服务（Product Servicing）三个阶段。为了使资源得到最有效的使用，测试人员主要参与产品开发和后期服务这两个阶段。而在产品的定义阶段，则会有选择的要求一些 资深测试工程师和测试经理一起参与。他们主要负责：通过验证产品核心功能或用户使用场景，确定产品各功能的优先级；参加产品使用场景定义的评审；参加用户 体验文档的评审等。

        当然每个公司应该定义适合自己的开发模式。但是是否让测试工程师参与这些工作的主要目标应该是没有区别的：首先是熟悉客户需求；再来测试工程师应凭借自身 经验，从测试和维护的角度来判断被细分的客户需求中，哪些是合理的，哪些是不合理的，并反馈给项目经理或市场部门，以供他们参考；最后，则要根据这些项目 需求以及软件架构的文档，给出测试计划。

        上面这番描述是不是看上去并不很复杂，也不重要呢？非要在项目初期做吗？最终不都是根据需求文档来写测试计划嘛……

        这当然是很重要的环节。理由如下：

        1． 产品的可测性严重影响了后期测试团队的工作效率以及测试的有效性。越早提出此类相关问题，越可能进入开发工程师设计范围。同时，该项指标可为项目经理提供一个与“开发难度”并列的“测试难度”——这将会影响到项目负责人对开发周期的设计。

        2． 除项目经理外，测试工程师是最需要了解用户需求以及用户使用体验的角色。参与这些由产品经理，项目经理编写的文档评审，会让测试工程师们得到除了列在文档 上的核心需求外更多的信息——我们必须承认，因为人的因素，文档是不可能涵盖所有信息——这将会帮助工程师们以更快的速度对产品需求有更深层次的理解。

        3． 使得测试经理能够更早做出“是否需要提前编写测试工具或搭建测试平台”的决定。而这是很重要的一点。测试在开发流程中，因其所处位置，很容易因为开发团队中的突发事件导致周期被压缩。而自动化测试工 具虽然可以节省人力，但相比于手工测试，开发周期较长，见效较晚。通常一个工具从开发到可以用于测试需要一周到数月不等——完全取决于工具的规模。因此， 尽快确定“是否需要编写测试工具”是必要的。它可以帮助测试团队“抢回”更多的时间用于设计和调试测试工具，从而达到更好的测试效果。甚至可以避免掉因为 时间不够，而拒绝采用自动化工具转为手工测试的被动局面。

        理由其实还可以列出很多。但是，我觉得这几点应是最为主要的。它们能足够说明为什么测试人员需要参与产品开发初期的工作以及他们需要做些什么的问题。这里 再重复一下，在开发初期测试工程师需要：确定产品的可测性，了解用户需求，确定需要引入何种测试工具或平台。

        所以，在开发初期做好测试计划并不是可有可无的；用户需求不是只要工程师“买单”就可以的；不理会测试团队而埋头开发的产品，将会是一场“噩梦”，特别是当产品发布/部署的时候。

        但每个公司每个项目组不需要套用一样的模式。针对不同的需求，我们应该量体裁衣，做不同的剪裁。只是核心不该有变化，目标不该有变化。就如同国内一些公司对CMM的追宠——光有形，没有神，是实在不可取的。

工具类别	工具名称	生产厂商	相关网站
通用功能自动化测试工具	Winrunner	Mercury
	Quicktest pro	Mercury
	Xrunner	Mercury
	QARun	Compuware
	TestPartner	Compuware
	WebKing	Parasoft	http://www.parasoft.com
	Robot	IBM Rational	http://www.ibm.com/cn
	Visual Test	IBM Rational	http://www.ibm.com/cn
	Functional Tester	IBM Rational	http://www.ibm.com/cn
	SilkTest	Segue
	SilkTest International	Segue
	e-Tester	Empirix
	WebFT	Radview
	TestComplete	AutomatedQA
	QA Wizard	Seapine
	Software EggPlant	RedStone
	Test Edition	Microsoft Visual Studio
	PureTest	Minq
	Autotester	Autotester
	Testbench400	Original Software
	TestExpert	VEReCOMM
	TestRunner	Qronus
	TTCN suite	Telelogic	http://www.telelogic.com.cn
	QC/Replay	Centerline
	Web	AutoTester
	eValid	Software Research
	WebART	OCLC
	MaxQ	开源
	WebInject	开源
	Marathon	开源
性能测试/监控工具	LoadRunner	Mercury
	SiteScope	Mercury
	Topaz	Mercury
	QaLoad	Compuware
	PerformaSure/benchmark	Quest
	Silkperformer	Segue
	Silkperformer Lite	Segue
	SilkCentralTM Performance Manager	Segue
	e-Load	Empirix
	Robot	IBM Rational	http://www.ibm.com/cn
	Performance Tester	IBM Rational	http://www.ibm.com/cn
	WebLoad	RadView
	Web applicaton stress tool	Microsoft
	Application center test	Microsoft
	PureLoad	Minq
	Athene APR	Metron
	ForeCast	Facilita
	Impact/Impact for CBT	Cyrano
	Berkeley Laboratory sniffer	Lawrence
	Jmeter	开源
	openSTA	开源
	Siege	开源
	StressMark	开源
	DBMonster	开源
白盒测试/代码分析工具	VcTester	ezTester	http://www.eztester.com
	Jtest	Parasoft	http://www.parasoft.com
	C++test	Parasoft	http://www.parasoft.com
	SOA test	Parasoft	http://www.parasoft.com
	.test	Parasoft	http://www.parasoft.com
	Codewizard	Parasoft	http://www.parasoft.com
	Insure++	Parasoft	http://www.parasoft.com
	DataRecon	Parasoft	http://www.parasoft.com
	Numega devpartner studio	Compuware
	DevPartnerJavaEdition	Compuware
	BoundsChecker	Compuware
	SmartCheck	Compuware
	DBPartner	Compuware
	Bean-test	Empirix
	Aqtime	AutomatedQA
	QESatJava	AutomatedQA
	Visual Unit	Unitware
	PC-lint	Gimpel Software
	Macabe	Macabe
	Optimizeit Suite	Borland
	JProbe Suite	Quest Software
	Application assurance suite	Quest Software
	Sql optimizer	Quest Software
	Jprofiler	ej-technologies
	workbench	Cyrano
	Logiscope	TeleLogic	http://www.telelogic.com.cn
	rulecheck	TeleLogic	http://www.telelogic.com.cn
	SilkPerformer Component Test Edition	Segue
	Purifyplus	IBM rational	http://www.ibm.com/cn
	Rational Test Realtime	IBM rational	http://www.ibm.com/cn
	junit	开源
	cactus	开源
	Hansel	开源
	TestNG	开源
	StrutsTestCase	开源
	JFCUnit	开源
	Httpunit	开源
	Dunit	开源
	cppunit	开源	http://sourceforge.net/projects/cppunit
	Nunit	开源
	Xunit	开源
	JTR	开源
	MallocDebug	Linux平台工具
	Valgrind	Linux平台工具
	Kcachegrind	Linux平台工具
	dmalloc	Linux平台工具
	ElectricFence	Linux平台工具
	LeakTracer	Linux平台工具
	memprof	Linux平台工具
	ccmalloc	Linux平台工具
	mprof	Linux平台工具
	yamd	Linux平台工具
	njamd	Linux平台工具
	mpatrol	Linux平台工具
嵌入式测试工具	VcTester	ezTester	http://www.eztester.com
	codetest	Metrowerks
	Cantata/cantana++	IPL
	IceMaster	Reflex Technology
	System test	Reflex Technology
	scorecast	DDC-I
	Testquest	Testquest
	UniText	ATTOL
	vectorcast	Vector software
	testrunner	Qronus
	Logiscope	Telelogic	http://www.telelogic.com.cn
测试管理工具	TestDirector(QualityCenter)	Mercury
	QADirector	Compuware
	certify	Worksoft
	Product manager	Aimware
	SilkCentral Test Manager	Segue
	Doors	Telelogic	http://www.telelogic.com.cn
	e-manager	Empirix
	testmanager	IBM Rational	http://www.ibm.com/cn
	TestView Manager	RadView
	Professional	T-Plan
缺陷管理工具	TestDirector(QualityCenter)	Mercury
	ClearQuest	IBM Rational	http://www.ibm.com/cn
	TrackRecord	Compuware
	TestTrack pro	Seapine
	TrueTrack	McCabe
	Devtrack	Techexcel
	Notes	IBM Lotus
	SilkCentral Issue Manager	Segue
	PVCS Tracker	Merant
	AR System	Remedy
	URTrack	LealSoft
	Butterfly	Hansky
	Bugzilla	开源
	Mantis	开源
	JIRA	开源
	BugFree	开源
配置管理工具	ClearCase	IBM Rational	http://www.ibm.com/cn
	PVCS Version Manager	Merant
	VCS	Diamond
	StarTeam	Borland
	Perforce	Perforce
	TRUEchange	McCabe
	SYNERGY CM	Telelogic	http://www.telelogic.com.cn
	VSS	Microsoft
	Firefly	Hansky
	CVS	Subversion
	SCCS	RCS
	CCC/Harvest	Computer Associates

01. 为什么要在一个团队中开展软件测试工作？
　 　因为没有经过测试的软件很难在发布之前知道该软件的质量，就好比ISO质量认证一样，测试同样也需要质量的保证，这个时候就需要在团队中开展软件测试的 工作。在测试的过程发现软件中存在的问题，及时让开发人员得知并修改问题，在即将发布时，从测试报告中得出软件的质量情况。

02. 您在以往的测试工作中都曾经具体从事过哪些工作？其中最擅长哪部分工作？
　　我曾经做过web测试，后台测试，客户端软件，其中包括功能测试，性能测试，用户体验测试。最擅长的是功能测试

03. 您所熟悉的软件测试类型都有哪些？请试着分别比较这些不同04. 的测试类型的区别与联系（如功能测试、性能测试……）
　　测试类型有：功能测试，性能测试，界面测试。
　　功能测试在测试工作中占的比例最大，功能测试也叫黑盒测试。是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时，需要测试软件产品的功能，不需测试软件产品的内部结构和处理过程。采用黑盒技术设计测试用例的方法有：等价类划分、边界值分析、错误推测、因果图和综合策略。
　　性能测试是通过自动化的测试工具模 拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作 负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供 的最大服务级别的测试。
　　界面测试，界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户 自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于 界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。
　　区别在于，功能测试关注产品的所有功能上，要考虑到 每个细节功能，每个可能存在的功能问题。性能测试主要关注于产品整体的多用户并发下的稳定性和健壮性。界面测试更关注于用户体验上，用户使用该产品的时候 是否易用，是否易懂，是否规范（快捷键之类的），是否美观（能否吸引用户的注意力），是否安全（尽量在前台避免用户无意输入无效的数据，当然考虑到体验 性，不能太粗鲁的弹出警告）？做某个性能测试的时候，首先它可能是个功能点，首先要保证它的功能是没问题的，然后再考虑该功能点的性能测试

04．您认为做好测试用例设计工作的关键是什么？
白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果
黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试，以最少的用例在合理的时间内发现最多的问题

05. 请试着比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系。

　　黑盒测试：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。
　　白盒测试：已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否以经过检查。

　　软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序 内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。黑盒测试主要是 为了发现以下几类错误：
　　1、是否有不正确或遗漏的功能？
　　2、在接口上，输入是否能正确的接受？能否输出正确的结果？
　　3、是否有数据结构错误或外部信息（例如数据文件）访问错误？
　　4、性能上是否能够满足要求？
　　5、是否有初始化或终止性错误？

　　软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子，它允许测试人员利 用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此 白盒测试又称为结构测试或逻辑驱动测试。白盒测试主要是想对程序模块进行如下检查：
　　1、对程序模块的所有独立的执行路径至少测试一遍。
　　2、对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍。
　　3、在循环的边界和运行的界限内执行循环体。
　　4、测试内部数据结构的有效性，等等。

　　单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。

　　单元测试是由程序员自己来完成，最终受益的也是程序员自己。可以这么说，程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试。执行单元测试，就是为了证明这段代码的行为和我们期望的一致。

　　集成测试（也叫组装测试，联合测试）是单元测试的逻辑扩展。它的最简单的形式是：两个已经测试过的单元组合成一 个组件，并且测试它们之间的接口。从这一层意义上讲，组件是指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合成程序的更大部 分。方法是测试片段的组合，并最终扩展进程，将您的模块与其他组的模块一起测试。最后，将构成进程的所有模块一起测试。

　　系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。（常见的联调测试）

　　系统测试的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。

　　验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。
验收测试是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能如同用户所合理期待的那样。

06. 测试计划工作的目的是什么？测试计划工作的内容都包括什么？其中哪些是最重要的？
　　软件测试计划 是指导测试过程的纲领性文件，包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计 划，参与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变 更。
测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。所以其中最重要的是测试测试策略和测试方法（最好是能先评审）

07. 您认为做好测试计划工作的关键是什么？
　　1. 明确测试的目标，增强测试计划的实用性
　 　编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷，因此软件测试计划的价值取决于它对帮助管理测试项目，并且找出软件潜在的缺陷。因 此，软件测试计划中的测试范围必须高度覆盖功能需求，测试方法必须切实可行，测试工具并且具有较高的实用性，便于使用，生成的测试结果直观、准确
　　2．坚持“5W”规则，明确内容与过程
　 　“5W”规则指的是“What（做什么）”、“Why（为什么做）”、“When（何时做）”、“Where（在哪里）”、“How（如何做）”。利用 “5W”规则创建软件测试计划，可以帮助测试团队理解测试的目的（Why），明确测试的范围和内容（What），确定测试的开始和结束日期（When）， 指出测试的方法和工具（How），给出测试文档和软件的存放位置（Where）。
　　3．采用评审和更新机制，保证测试计划满足实际需求
测试计划写作完成后，如果没有经过评审，直接发送给测试团队，测试计划内容的可能不准确或遗漏测试内容，或者软件需求变更引起测试范围的增减，而测试计划的内容没有及时更新，误导测试执行人员。
　　4. 分别创建测试计划与测试详细规格、测试用例
　　应把详细的测试技术指标包含到独立创建的测试详细规格文档，把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。

08. 您所熟悉的测试用例设计方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。
　　1．等价类划分
　　划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.

　　2．边界值分析法
　　边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.
　　使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.

3．错误推测法
　　基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.
　 　错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.

4．因果图方法
　　前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之 间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）. 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.

09. 请以您以往的实际工作为例，10. 详细的描述一次测试用例设计的完整的过程。
　　就说最近的这次网站功能的测试吧
　　首先：得到相关文档（需求文档和设计文档），理解需求和设计设计思想后，想好测试策略（测试计划简单点就OK了），考虑到测试环境，测试用例，测试时间等问题。
　 　第二步：设计测试用例，测试策略是：把网站部分的功能点测试完，然后在进行系统测试（另外个模块呢有另一个测试人员负责，可以进行联调测试），网站模块 的测试基本是功能测试和界面测试（用户并发的可能性很小，所以不考虑）：这次的网站的输入数据呢是使用数据库中的某张表记录，如果表中某一数据记录中新加 进来的（还没有被处理的，有个标志位），网站启动后会立刻去刷那张表，得到多条数据，然后在进行处理。处理过程中，会经历3个步骤，网站才算完成了它的任 务。有3个步骤呢，就可以分别对　　这3个步骤进行测试用例的设计,尽量覆盖到各种输入情况（包括数据库中的数据，用户的输入等），得出了差不多50个用 例。界面测试，也就是用户看的到的地方，包括发送的邮件和用户填写资料的页面展示。
　　第三步：搭建测试环境（为什么这个时候考虑测试环境呢？因 为我对网站环境已经很熟了，只有有机器能空于下来做该功能测试就可以做了），因为网站本身的环境搭建和其他的系统有点不同，它需要的测试环境比较麻烦，需 要web服务器（Apache,tomcat），不过这次需求呢，网站部分只用到了tomcat，所以只要有tomcat即可
　　第四步：执行测试

11. 您以往是否曾经从事过性能测试工作？如果有，12. 请尽可能的详细描述您以往的性能测试工作的完整过程。
　　是的，曾经做过网站方面的性能测试，虽然做的时间并不久（2个月吧），当时呢，是有位网站性能测试经验非常丰富的前辈带着我一起做。
性能测试类型包括负载测试，强度测试，容量测试等
　　负载测试：负载测试是一种性能测试指数据在超负荷环境中运行，程序是否能够承担。
　　强度测试： 强度测试是一种性能测试，他在系统资源特别低的情况下软件系统运行情况
　　容量测试：确定系统可处理同时在线的最大用户数  
　　在网站流量逐渐加大的情况下，开始考虑做性能测试了，首先要写好性能测试计划，根据运营数据得出流量最大的页面（如果是第一次的话，一般是首页，下载页，个人帐户页流量最大，而且以某种百分比），

　　Web服务器指标指标：
　　* Avg Rps: 平均每秒钟响应次数＝总请求时间 / 秒数；
　　* Successful Rounds：成功的请求；
　　* Failed Rounds ：失败的请求；
　　* Successful Hits ：成功的点击次数；
　　* Failed Hits ：失败的点击次数；
　　* Hits Per Second ：每秒点击次数；
　　* Successful Hits Per Second ：每秒成功的点击次数；
　　* Failed Hits Per Second ：每秒失败的点击次数；
　　* Attempted Connections ：尝试链接数；　　

13. 您在从事性能测试工作时，14. 是否使用过一些测试工具？如果有，15. 请试述该工具的工作原理，16. 并以一个具体的工作中的例子描述该工具是如何在实际工作中应用的。

17. 您认为性能测试工作的目的是什么？做好性能测试工作的关键是什么？

18. 在您以往的工作中，19. 一条软件缺陷（或者叫Bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（Bug）记录？

20. 您以往所从事的软件测试工作中，21. 是否使用了一些工具来进行软件缺陷（Bug）的管理？如果有，22. 请结合该工具描述软件缺陷（Bug）跟踪管理的流程。

23. 您认为在测试人员同24. 开发人员的沟通过程中，25. 如何提高沟通的效率和改善沟通的效果？维持测试人员同26. 开发团队中其他成员良好的人际关系的关键是什么？

27. 在您以往的测试工作中，28. 最让您感到不29. 满意或者不30. 堪回首的事情是什么？您是如何来对待这些事情的？

31. 在即将完成这次笔试前，32. 您是否愿意谈一些自己在以往的学习和工作中获得的工作经验和心得体会？（可以包括软件测试、过程改进、软件开发或者与此无关的其他方面）

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的话，一定要坚持自己的立场，让问题得到最后的确认。

38．你为什么想离开目前的职务？
　　因为公司运作情况并不理想，公司需要调整部门体系，公司考虑到缩减部门人 员，所以大批量的裁员（有6，7个），这是我的第一份工作，对公司也有较深的感情，因为在这里我找到了职业理想（就是测试），所以公司需要精简人员，我自 愿退出。虽然很舍不得，但我将会有新的发挥能力的舞台。

39.你找工作时，最重要的考虑因素为何？
　　工作的性质和内容是否能让我发挥所长，并不断成长。

40.为什么我们应该录取你？
　　您可以由我过去的工作表现所呈现的客观数据，明显地看出我全力以赴的工作态度。

41.请谈谈你个人的最大特色。
　　我的坚持度很高，事情没有做到一个令人满意的结果，绝不罢手。

42.你们以前测试的流程是怎样的？
　　<答：测试计划－测试用例设计－测试执行－测试分析报告>

43.为什么选择测试这行？
　　<答：它是一个新兴的行业，有发展潜力，而且很锻炼人，需要掌握更多的技能，比做开发要更难>

44.如果你接到一个客户抱怨的电话，你确知无法解决他的问题，你会怎么处理
　　　　为什么抱怨？是怎么样的问题？
　　　　如果是客服问题，提交客服部门解决
　　　　如果是质量问题，分析原因，下一版本改进

45.通常你对于别人批评你会有什么样的反应
　　虚心接受,有错即改，无措勉之

46.你觉得什么样的人最难相处
　　　　自以为是的人吧

47.你在五年内的个人目标和职业目标分别是什么？
   从现在起的五年之内，我希望能够在一个很好的职位上待几年，而且最好有一次晋升，然后就期待着下一步。不管是向上提升，还是在企业内横向调动，对我个人来说，我希望找到一家企业——一家愿意做相互投入的企业——待上一段时间。

48. 你都用什么测试方法
   针对不同的产品或者系统或者模块，有不同的测试方法。总体而言有白盒测试和黑盒测试。

49.怎么编写案例
   案例的编写与测试阶段的定义有很大的关系。系统测试和unit测试的案例可能不同。总体而言测试案例根据系统的需求而定。

50.怎么才能够全面的测试到每一个点
   测试的全面性主要需要在设计测试计划的时候考虑，从测试策略，产品需求等等多个角度考虑从而定义全部的测试点。

经过三周的投简历面试我终于找到了满意的工作，谢谢一直关心我的人，也谢谢给我指点帮助我的人，在这三周里我成长了许多，也总结了一些面试时的经验，和大家分享一下，希望对大家能有帮助。

1，你在投简历的时候除了简历内容，最好加上自己近照比较好看的相片。

2，在简历开始最好有一句两句比较引人注目的话，我写的是“给我一次面试的机会，我会让贵公司增加一位优秀的员工”。

3，在网站上投简历的时候，先到招聘网站上找到你要去的公司，然后到这个公司的网站上去看看，公司网站上有没有招聘信息和HR的邮箱，如果有就直接 往这个公司的邮箱里投，因为公司看招聘网站上的简历要给钱的，所以公司往往会在招聘网站上进行筛选在看简历，如果投到公司的HR邮箱里，这样就不会被筛选 掉了。

4，准备一个文档，投一家公司在文档上记录一个，以免一家公司投了两次，公司收到你的简历重复，会对你这个人评价不好的，觉得你不够细心，投过一次都忘记了。

5，接到公司的面试通知的时候，首先要看看公司招聘软件测试工程师要求了些什么，尽可能的补充一些知识符合他招聘的要求，那方面你懂就要懂得多一点，然后突出自己的特点。

6，要仔细看公司的网站，了解公司的业务信息和最近的动态，详细掌握公司的内容，别面试官问你我们公司做什么的你知道吗，你觉得这方面应该有哪些测试呢？

7，要针对自己的经历总结一段长3-5分钟的自我介绍，写好了背着说几遍，看看时间是不是在3-5分钟内，说话的语速尽量清楚放慢速度，不要说话快，这样会让面试官觉得你紧张，没有准备充分。

8，在自我介绍里一定要突出自己适合做软件测试工程师的性格，比如细心，认识，学习能力强，有责任感，团队合作能力强，善于沟通等等，一搜一大堆呢。

9，面试的时候一定要诚实，不会的就不会，不要胡说，面试官可比你测试方面强，你说错了人家一下就知道了，如果你觉得自己虽说不知道但是也能答得很好，你可以说自己对这方面不了解，但是我有些自己的观点。

10，面试的时候要告诉公司你会认真完成公司交给自己的工作，为公司创造价值，达到自我价值的一个实现，公司成长自己也会随着成长。一定要把自己和 公司紧密的结合在一起，这样面试官会觉得你把他的公司当成了自己的公司，这么热爱这家公司，就算你能力不行他也会考虑培养你的。

   Mature，self-motivated and strong interpersonal skills.思想成熟、上进心强，并具极丰   富的人际关系技巧。软件测试专业网站:51Testing软件测试网'W3Bi9g#d
软件测试专业网站:51Testing软件测试网zF Y3d(@r@^
　　Energetic，fashion-minded person.精力旺盛、思想新潮。软件测试专业网站:51Testing软件测试网
N)H ks�I;H&S
软件测试专业网站:51Testing软件测试网9]D7T CU/Qp
　　With a pleasant mature attitude.开朗成熟。软件测试专业网站:51Testing软件测试网 T9szqV+m;Vy aO
软件测试专业网站:51Testing软件测试网(h
zx(BG�M@'?Fi6G
　　Strong determination to succeed．有获得成功的坚定决心。
?+D*nX5eb*K"Q+G0软件测试专业网站:51Testing软件测试网&Qi-](y#ht-H4J
　　Strong leadership skills．有极强的领导艺术。
0xXrJ5V)ou/D4fQ0
-S4^X5h(~2Y `?7p0　　Ability to work well with others.能够同他人一道很好地工作。
YweZ(r"QT.Y y0软件测试专业网站:51Testing软件测试网gx v'FD@)LX�C
　　Highly-motivated and reliable person with excellent health and pleasant personality.上进心强又可靠者，并且身体健康、性格开朗。软件测试专业网站:51Testing软件测试网6vZQ'B4N


DiE%jo0　　The ability to initiate and operate independently.有创业能力，并能独立地从业。
!o^#a Ehu0软件测试专业网站:51Testing软件测试网%CDm"^/w3t4k'^
　　Strong leadership skill while possessing a great team spirit.有很高的领导艺术和很强的集体精神。软件测试专业网站:51Testing软件测试网 v1{ y7OBZ)T%`E
软件测试专业网站:51Testing软件测试网zbCBN4{}&LT1Q
　　Be highly organized and effecient．工作很有条理，办事效率高。
M@)|B6b(?!z2F1tZ#v0
!RXKI:N}0　　Willing to learn and progress．肯学习进取。
R Ttz�cYk0软件测试专业网站:51Testing软件测试网0x7e!YP(UP
　　Good presentation skills.有良好的表达能力。
;}!Qp5E&X+M^-v0
%E#Weh6c@0　　Positive active mind essential．有积极、灵活的头脑。
"iJFQ,V j0软件测试专业网站:51Testing软件测试网1o M.xg-i
　　Ability to deal with personnel at all levels effectively.善于同各种人员打交道。
*m|
a-k_W%lk$M0软件测试专业网站:51Testing软件测试网,D }6vEk:G`)eH
　　Have positive work attitude and be willing and able to work diligently without supervision.有积极的工作态度，愿意和能够在没有监督的情况下勤奋地工作。软件测试专业网站:51Testing软件测试网j#h
]ID:` t
软件测试专业网站:51Testing软件测试网 B�SB6q9Q#g
　　Young，bright，energetic with strong career-ambition.年轻、聪明、精力充沛，并有很强的事业心。软件测试专业网站:51Testing软件测试网8Lt9Da8|-]

Z&`;N*X,_+Pazb0　　Good people management and communication skills. Team player.有良好的人员管理和交际能力。能在集体中发挥带头作用。
HH;Ncy�n0软件测试专业网站:51Testing软件测试网[)zSx$aY
　　Able to work under high pressure and time limitation.能够在高压力下和时间限制下进行工作。软件测试专业网站:51Testing软件测试网 [0I5]k7p
软件测试专业网站:51Testing软件测试网 LDB5To3P-VM
　　Be elegant and with nice personality.举止优雅、个人性格好。软件测试专业网站:51Testing软件测试网4Wg~tf l#{&yL&^T

(y^;b.EeE0　　With good managerial skills and organizational capabilities.有良好的管理艺术和组织能力。
/s r;Z$SwGX:a0软件测试专业网站:51Testing软件测试网Z0]5[2?:D\
　 　The main qualities required are preparedness to work hard, ability to learn, ambition and good health.主要必备素质是吃苦耐劳精神好、学习能力优、事业心强和身体棒。软件测试专业网站:51Testing软件测试网7m!n0Wg*H~%AFV

I-aywT0z9l|0　　Having good and extensive social connections.具有良好而广泛的社会关系。软件测试专业网站:51Testing软件测试网"D"Pg/E3~Y6o
软件测试专业网站:51Testing软件测试网4O!t,IG2f#i~$bG7JQ
　　Being active, creative and innonative is a plus.思想活跃、有首创和革新精神尤佳。软件测试专业网站:51Testing软件测试网4t/u.n%faH/P)z.F

n0KyJ:s0　　With good analytical capability.有较强的分析能力。
5\\t7][t0   软件测试专业网站:51Testing软件测试网*CY)XA�vr$Z
       以上文章转载自：傲英英语学习网 http://www.oenglish.cn
'~UVFi0       还有一些其它求职英语资料，如果需要的话，就去看看吧：http://www.oenglish.cn/html/Job/Interview/

测试文档包括：测试计划、测试用例、测试方案、测试报告、性能测试报告、用户操作手册等。
主要是各个测试阶段的输出文档：
1、单元测试计划/设计/执行阶段，需要输出以下文档：
单元测试计划
单元测试方案
单元测试用例
单元测试日报
单元测试报告

2、集成测试计划/设计/执行阶段，需要输出以下文档：
集成测试计划
集成测试方案
集成测试用例
集成测试日报
集成测试报告

3、系统测试计划/设计/执行阶段，需要输出以下文档：
系统测试计划
系统测试方案
系统测试用例
系统测试日报
系统测试报告

各种输出文档之间不是完全独立的，所以采用TD之类的工具进行维护比较好。TD是test director的简称。是在windows平台上基于B/S框架的测试管理工具。TD的最高版本是8.2.现在的QC是TD的升级版本。而且QC支持多 版本的操作平台。如：windows ,solar's unlix等。而且QC有四大模块：需求管理、测试计划、测试执行、缺陷管理。

测试计划：需要确定测试对象、测试组织、测试任务划分、测试失败/通过的标准、挂起恢复的条件、时间安排、资源安排、风险估计和应急计划等；

测试方案：侧重于规划测试活动的技术因素。如：确定被测特性、测试组网、测试对象关系图、测试原理、测试操作流程、测试需求、工具的设计、测试用例的设计（只是说明用例的设计原则，具体的用例设计应该在用例文档指出）、测试数据的设计等等；

测试指导书：指测试过程文档，用来定义测试过程中的阶段、活动、输入输出、角色职责、模板、工具等等。

测试计划与测试方案的区别一:
1、测试计划是组织层面的文档，从组织管理角度对一次测试活动进行规划
   测试方案是技术层面的文档
2、测试计划：需要确定测试对象、测试组织、测试任务划分、测试失败/通过的标准、挂起恢复的条件、时间安排、资源安排、风险估计和应急计划等；
   测试方案：明确策略，细化测试特性、测试用例的规划、测试环境的规划，自动化测试框架的 设计、测试工具的设计和选择等
3、测试计划考虑“做什么”，测试方案考虑“怎么做”

测试方案和测试计划的区别二：
一、测试计划：
对测试全过程的组织、资源、原则等进行规定和约束，并制订测试全过程各个阶段的任务以及时间进度安排，提出对各项任务的评估、风险分析和需求管理。
二、测试方案：
描述需要测试的特性、测试的方法、测试环境的规划、测试工具的设计和选择、测试用例的设计方法、测试代码的设计方案。
三、测试计划是组织管理层面的文件，从组织管理的角度对一次测试活动进行规划。
四、测试方案是技术层面的文档，从技术的角度对一次测试活动进行规划。
五、测试计划要明确的内容：
1、明确测试组织的组织形式
○1测试组织和其他部门关系，责任划分。
○2测试组织内的机构和责任安排。
2、明确测试的测试对象（明确测试项，用于后面划分任务,估计工作量等）
3、完成测试的需求跟踪
4、明确测试中需要遵守的原则
○1测试通过/失败标准
○2测试挂起和回复的必要条件
5、明确测试工作任务分配是测试计划的核心
○1、进行测试任务划分
○2、进行测试工作量估计
○3、人员资源和物资源分配
○4、明确任务的时间和进度安排
○5、风险的估计和规避措施
○6、明确测试结束后应交付的测试工作产品
六、测试方案的具体内容：
○1、明确策略
○2、细化测试特性（形成测试子项）
○3、测试用例的规划
○4、测试环境的规划
○5、自动化测试框架的设计
○6、测试工具的设计和选择
七、测试方案需要在测试计划的指导下进行，测试计划提出“做啥”，而测试方案明确“咋做”。
八、详见测试计划模板和测试方案模板

一般测试用例的格式如下：
以计算器为例，进行系统测试用例的编写。实现计算器的加法功能。
用例编号：calc-st-add-001
测试项目：计算器的加法功能
测试标题：一个数在合法的取值范围内，另一个也在合法的取值范围内。
重要级别：高
预置条件：启动计算器
测试输入：参数1:3    参数贰2: +
               参数3:4    参数4:=
执行步骤：用计算机键盘依次输入上述参数
预期输出：参数：7

一、大型通用软件，在正式发布前，通常需要执行Alpha和Beta测试，目的是从实际终端用户的使用角度，对软件的功能和性能进行测试，以发现可能只有最终用户才能发现的错误。

Alpha测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由程序员或测试员完 成。Alpha测试发现的错误，可以在测试现场立刻反馈给开发人员，由开发人员及时分析和处理。目的是评价软件产品的功能、可使用性、可靠性、性能和支 持。尤其注重产品的界面和特色。Alpha测试可以从软件产品编码结束之后开始，或在模块（子系统）测试完成后开始，也可以在确认测试过程中产品达到一定 的稳定和可靠程度之后再开始。有关的手册（草稿）等应该在Alpha测试前准备好。

Beta测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。因而， Beta测试是在开发者无法控制的环境下进行的软件现场应用。在Beta测试中，由用户记下遇到的所有问题，包括真实的以及主管认定的，定期向开发者报 告，开发者在综合用户的报告后，做出修改，最后将软件产品交付给全体用户使用。Beta测试着重于产品的支持性，包括文档、客户培训和支持产品的生产能 力。只有当Alpha测试达到一定的可靠程度后，才能开始Beta测试。由于Beta测试的主要目标是测试可支持性，所以Beta测试应该尽可能由主持产 品发行的人员来管理。

由于Alpha和Beta测试的组织难度大，测试费用高，测试的随机性强、测试周期跨度较长，测试质量和测试效率难于保证，所以，很多专业软件可能不再进 行Beta测试。随着测试技术的提高，以及专业测试服务机构的大量涌现，很多软件的Beta测试外包给这些专业测试机构进行测试。

二、Alpha测试
Alpha测试由用户在开发者的场所进行，并且在开发者对用户的“指导”下进行测试。开发者负责记录发现在错误和使用中遇到的问题。总之，Alpha测试是在受控的环境中进行的。  
Beta，这个希腊字母的英文写法，怎么会变成了“测试”的含义。据我所知的，广义上对测试有三个传统的称呼，alpha、beta、gamma，用来标 识测试的阶段和范围。alpha 是指内测，即现在说的 CB，指开发团队内部测试的版本或者有限用户体验测试版本。beta 是指公测，即针对所有用户公开的测试版本。然后做过一些修改，成为正式发布的候选版本时（现在叫做 RC - Release Candidate），叫做 gamma。

这里不用程序员和测试人员测试，是因为这是验收测试，是程序员和测试人员已经做过单元测试、集成测试、系统测试了，是开发商已经认为基本可以交付用户使用 了，才开始的测试。这时，可以为来测试环境上测试用户提供打印的纸质文档，即：测试用例等，让他们根据文档测试，站在他们使用系统的角度，提出一些程序员 和测试人员想不到的问题，比如：一些易用性问题，希望改为他们能够接受的操作方式、报表上的打印数据增减等，测试人员可在旁指导用户使用新系统，开发人员 可根据他们的要求，修改系统，达到用户满意。所以，程序员和测试人员这时是不需要测试的。测试人员可以负责将用户的问题记录，反馈给开发人员，当然，一定 要理解用户的意思，因为，改完了，验证测试估计要测试人员先做，没有问题了，再让用户测试。有些重要的问题，可能要开发人员和用户直接交流了。

三、版本号问题

一般我们看到版本分为a/b/r。a就是公司内部测试的版本，一般包括验收测试还有所说的不是由测试人员和开发人员来执行的测试（公司内部其他人员，比如行政人员）。b就是公司以外的测试，一般都是客户来完成。r就是release，正式版（呵呵，收费了）。

        测试工作, 有轻松的时候,也有繁忙的时候,但总的来说忙大于轻松。记得刚上手测试时,不知道从何下手?产品的操作手册和命令手册,最基础的DD,却是新人最好的参考 资料;产品的操作手册和命令手册面向的就是用户,对于新产品,用户也是新人;产品资料,不仅仅是告诉你怎么使用它,里面还包括很多概念的阐述,功能的简 介,和部分实现方式;对于测试来说,都是很重要的资料.

        看产品资料的同时,也要学习产品所基于的协议,标准之类的;协议,标准阐述了功能的实现方式;在动手测试之前,需要有一定的了解.此时,不需要深究;以后随着测试的深入,自然而然会有更深的理解.

        当中,还应该初步掌握测试平台,测试工具和测试方法;不然开始工作时,那些测试工具会让你傻眼;虽然当你会用后是贼简单的DD,但是没有用过却是不怎么好用的DD!

        新人上手后,会经历这样的一个过程:自己测试的模块怎么问题很少,而其他同 事复杂的模块的问题那么多,为啥呢?实际上是这样的吗?答案是否定的!因为新人刚开始,对产品的熟悉程度还不够把产品里隐藏较深的问题发掘出来;还有,毕 竟是新人,还没有形成适合自己的一套测试方法和测试理论,这些都是需要通过长期的经验积累和总结才可以形成的.这时,新人可以查看前辈们的问题单,看看前 辈们是怎么样进行测试的,他们的测试过程,方法是怎么样的?对于新人来说,问题单是很多的学习资料.对于自己的测试方法和理论的形成有促进的作用.

        之后,信任就开始了漫长的测试执行阶段.测试是具有重复性的,相同的功能模块,相同的产品测试久了会有厌倦的心理;这时需要适当的调整下.可以和同事换模块测试;不仅可以避免测试的重复性,还可以学习新的技术,而因为人与人之间的测试方法和测试理论总是不一样的,一个模块让不同的人来测试,可以测试出不一样的问题来,对于产品的测试,更有覆盖性.

        而后,等测试时间的增长,测试人员除了测试执行外,其他测试工作会越来越多:测试设计(测试点,测试用例的写作)、外对测试用例的协作、各种开发\测试文 档资料的评审、对外测试支持、自动化脚本的写作、实验局开局等等;虽然这些工作对于测试执行来说,没有了相对的重复性,但是这些工作的难度或者说是复杂度 是大大增加了:因为测试执行只需要跟着测试点跑功能就成,而后面的这些,可没有那么简单.就举对外测试支持来说,外面运营商或是产家的测试注重实际运用的 测试,而新研发出来的产品在公司内部注重功能测试, 当然也是注重实际应用的;可是是新产品,外面还没有大规模应用的情况下,相对来说,实验室的测试和外面的测试差距还是蛮大的,所以需要测试人员反应要快, 能够在短时间内搭建好测试平台和测试环境,对对面突发性的测试需要进行验证;如果在产品不支持的情况下,需要研究出其他的解决方案来满足外面测试需要的功 能.

        对于测试人员来说,在测试过程中,或多或少总是会发现一些不是必现的问题.对测试人员来说,需要把问题出现时的现场在问题单中描述的很清楚,(配置文件, 操作过程log,流量的类型和大小等等)而且尽可能的对发现问题进行复现操作,当然这个过程也需要把握时间,因为测试版本的时间本来就是比较赶的,不能消 耗过多的时间在复现问题上.当整个版本在该论测试完成后,可以考虑集中时间对不能重现的问题进行复现工作.而在复现工作过程中,可以开发人员进行交流.因 为开发人员对于产品实现的流程比较测试人员要熟悉,一般来说开发可以提出一些很有价值的观点,有利于问题复线工作.

        测试产品时(测试资料,评审文档),测试人员需要带着怀疑的观点去测试,这个观点往往对于测试新人来说,是比较困难的.新人很容易是带着去验证的观点去测 试(总是认为产品,文档资料都是正确),所以发现的问题比较少;当如果换个角度,采用怀疑的观点去测试时,会发现很多原先没有发现的问题.特别是一些设计 方面的问题.虽然功能是没有问题的,但是实现的过程或是方法却不是最优的,这些问题是新人很难发现的,当然也是需要一定的经验积累的.

   首先，确保你所发现的问题是确实是一个bug，不要出现因为测试人 员操作错误或配置错误所引起的“bug”，这样会降低你在开发人员心中的可信度。在测试的时候，如果发现测试的实际结果与预期测试结果不符时，不要着急马 上报bug，先想想为什么会出现错误。作为专业的测试人员，应该能够对出现的问题进行跟踪，确认了在配置、操作没有错误的前提下，通过追踪分析确认所测试 的业务流程确实是存在bug，并能大概对bug的产生原因进行定位。测试人员，需要做到专业，尽量少给开发找麻烦，不要制造实际上并不存在的bug。
    确认了所发现的问题是一个bug之后，按照测试步骤再执行一次，确保bug是可重现的而不是随机的。如果bug不能重现，应该尽量找到bug重现的规律， 在一些比较难重现的问题可以找开发配合一起查找原因，如果还是无法重现则需要在bug report中对出现的问题描述清楚并说明出现的随机性。
    接下来就是填写bug report了，在填写bug report的时候，最重要的是bug的标题和bug描述。在bug报告中，首先用一句话对bug进行简要精确的描述作为bug的标题，让开发或项目经理 一看就知道存在什么问题，比如“XX模块在压力测试2小时后出现内存泄露”。而在bug的描述中，需要使用简明准确的语言描写出现bug的测试步骤、实际 的测试结果、预期的测试结果和结论；也就是说描述导致出现bug的操作步骤是怎样，由测试步骤所做的操作引起的测试结果是什么，而预期的结果应该是怎样， 并由实际结果与预期结果相对比说明问题所在。比如：“在管理网页新增用户，当新增的用户登录名名称很长（例如登录名长度为输入框允许的最大长度），按‘新 增’按纽新增后系统提示已经有该用户存在，而事实上该用户并不存在，建议对超长的用户名进行处理。”
    在测试人员发现了一个已隔离的，可重现的问题后，应该对问题进行归纳。同一个问题是否出现在其他的模块或其他的流程？同一个故障是否会引起更加严重的问题？如果存在，也需要提出来让开发一并处理。
     在开发对bug进行修改之后，测试需要报着怀疑的态度认真地对问题进行验证，需要严格按照测试步骤来进行测试，检查开发是否已经正确修改了所出现的问题， 以及开发对bug进行了修复之后是否会引进新的问题。不要相信开发说“已经修改好了，肯定没问题了”就不对问题进行细致的检查了，如果开发修改得不彻底， 问题仍然会存在的，或者可能会由于开发在修改bug的时候忽略了另一些细节导致了新bug的出现。尽量不要在关闭bug之后，才发现这个问题还没有修改彻 底；也不要出现bug关闭之后，出现了新的bug。
    测试对bug进行验证确认已经修改ok之后，关闭bug。在关闭的时候，应该对Bug最终修改结果进行简要描述，如果bug的修改引起配置或数据库或业务流程的变更，也需要在bug关闭描述中进行说明。

当你在固定电话上打电话时打不出去你应该对哪些测试?
本人以为
1 检查电话线路是否正确连接,比如是否接通,是否接错等
2  检查电话是否坏掉了
3  检查是否拨错号,导致拨了空号
4  检查是否错拨了功能键
5  检查通信连接是否畅通,信号是否良好
6  查看自己是否欠费

如果给你一张可以转的,可以伸缩有把手的椅子应该怎么测?
1 UI测试:测试椅子的外观是否完美养眼
2 易用性测试:看椅子转动是否正常,零件是否松动或过紧
3 性能测试:看椅子的耐压性如何,能承受的最大压力是多少
4 功能测试:看椅子的面积是多少,可坐几个人;伸缩性怎么样,把手稳不稳;舒适度怎么样,坐在上面3－4个小时是否很舒服,不能有不适的感觉;椅子的重量怎样，是否便于移动;椅子的大小，是否适合大众人群
5 安全测试:看看是不是能轻易的破坏掉
6 测试椅子的材料是否对人有害

另外的角度
1、如果有需求，应先检测这把椅子的设计是否符合需求
2、满足了需求后，再来验证功能
3、功能具有后，再来对边界值进行测试，如最大承重等,天天坐的话能坐多久,