(备注:这是两年前找工作的心得,希望能给学弟学妹们一些指点)

      

    每每想起找工作期间刻骨铭心的经历，都让我激动不已，时刻警醒自己，努力工作，珍惜机会。

   

    无法忘记每天早上都在漆黑徘徊中坚强起来，努力的去微笑，努力的去自信，努力的给自己多一些希望、多一些坚持，期待一天的收获。

   

    无法忘记每天晚上托着疲惫的身体，回到熟睡中的校园，在闭上眼的那一刻还不忘给自己打气“坚持下来，一定会有收获的”。

     

    记得刚开始出去时都没有经验，每次投的简历都石沉大海，在冷落中我学会了观察，观察招聘人都对什么形式的简历感兴趣。他们喜欢找项目经验，实践经验，学校表现奖励，还有联系方式等等，这些最好都写在第一页，排版要有自己的风格，最好在页眉页角都写上联系方式便于查找。在开始的一个多星期里，我每天招聘回去都会重新做一份简历，直到简历的命中率不断的提高。

   

   过了简历这关才会有下一步的机会，笔试是少不了，特别是搞计算机的。题目很基础，也很灵活，综合能力强。刚开始时都凭感觉去做，机会也就在我没准备中错过，立刻让我清楚目前的弱势，于是我开始疯狂的啃书，把以前的C，C++，数据库，网络知识，软件工程等都翻出来，每次笔试下来回来的第一件事就是啃书，争取下次出现类似的题型时不再犯同样的错误，该要调试的上机调试程序；坐车的时间长，路上也不忘带本书在身边随时温故，从来没有这么如饥似渴过知识，一本本的书温故了一遍又一遍，在一次次的坚持中机遇开始亲临我，带我走过的第二关的关口。在这里我想提醒大家特别是女同胞们，不要太注重分数的多少，而是掌握了多少知识，真正属于自己的有多少。决定从事专业工作的同学，就要学好专业知识，不要认为学校教育和企业完全脱节，学校打的是根基，企业要的是根基好的人才，看的就是你掌握专业知识的程度。

    

    我一直都觉得面试的表现是我的强项，不管考官问什么，我都能轻松做答，微笑自如，当然这些也都是有充分准备为前提的，一个精辟的自我介绍，职业规划，需要的素质等，随时收集，随时派上用场，这些都成为我的法宝随身带着。在面试中要注意的问题，你可以不刻意装扮自己，但必须整洁大方；你可以没有非常明确的目标，但必须让他们知道你是积极进取的；你可以大胆的说“不知道”，但必须让他们知道我会努力学习；你可以心理不够自信，但必须始终保持微笑；他们也可以不录用你，离开时别忘了真诚的说句：感谢贵公司给我笔试和面试的机会！

     

    对于面试时所具备的素质，在这里我要感谢学校对我的培养，感谢老师的信任，感谢同学的支持，让我在这四年里得到很好的锻炼。我一直都觉得，大学是个很好发展个人的舞台，不要错过每个锻炼自己的机会，不管是文体活动，干部竞选，还是勤工俭学等，都要勇于尝试，努力体验，有意识的全面发展自己让自己的综合素质不断的提高，换来的都将是一笔无价的财富。

    

     这里有两次深刻的求职的经历，想和大家一起分享。

    

     第一次北京紫光软件公司当天在武大招聘，由于没有充分的简历准备我落选了，得知公司第二天要到华科招聘，决定再尝试一次，用自己的执着打动招聘人。第二天直接找到招聘人，准备了很充分的言辞来说服她，让她知道我的勇气，我的坚持，我强有力的竞争力，还有我的积极进取；也许就是这么一点坚持，让我得到第一张笔试和面试的机会，给我莫大的鼓励和动力。

     

    第二次是去参加中兴的面试，来自五个不同高校的对手一起，分为技术和能力素质的测试。刚开始有点心虚，面对这些强大的高手拿什么和别人较量，但是很快的调整心态，我能和他们一起面试说明我也不弱，很快的投入进去，尽情的表现自己的团队合作意识，抗压能力，语言表达能力，学习能力，沟通能力，良好的精神面貌。

     

   记得在测试团队合作素质的时候，我们五个对手作为一个团队，讨论“每天中国要消费多少个乒乓球”的题目，将最后的结论选代表告诉考管，在讨论过程中，我主动发言说出个人见解，征求对友意见，当队友有更好提议时，赞成并支持，尽量和每个队友都能说上几句，特别在最后时需要选代表总结，虽然我很想起来表现，但是我主动推选对友来总结，当时给出的理由是“我觉得你在讨论过程中有很清晰的思路，分析问题很全面，就选你来总结吧，有什么不全面的我们再来补充”也许我这“似退实进“的招数得到考官的欣赏，在团队合作上给我最高的分；考官问我们的近几年的职业规划时，在对手们差不多一致逻辑的情况下，我给出了挺经典的开场白“我不能明确我这几年会发展到什么样的职位，但是我可以保证的是我的事业规划必须是积极进取的，所做的事必须是能够将我的精力和知识融入我所在行业与我的工作需要的地方，很清楚的理解自己的公司行业，最大挑战以及机会之所在，到那时，我未来的发展目标应该会清晰的显露出来。”我记得当时考官和对手们都看着我，我自己都被自己的言词感动了。

     

    还有在专业知识的考察上，考官出的专业知识我都能对答出来，对手不会的我能补充出来，这些来源于每天对专业知识温故的坚持，让我在这组中表现很出色。从考场上下来，我对自己说的第一句话“终于给自己争口气了”，虽然学校没有别人有名，但是不代表自己不优秀，不能无形的低估自己，其实你身边没有几个强人的，大家都是差不多的，不能说学校好的人就一定很优秀，在竞争面前人人平等，靠的是你的真才实学去争取机会。

    

    通过这么多次笔试面试，收获的是经验，培养的是能力，得到的是锻炼，学会了坚强，学会了承受，体验找工作的艰辛，多了一点坚持，也就多了一些机遇，才换来了今天的成功。过程走好了，结果是水到渠成的。

   

   祝愿学弟学妹们好好珍惜大学的美好时光，好好把握每一次机会，机会是给有准备头脑人的！

                                                       

                                                                                      

2007-11

 

 

n       AM是一种最近才出现的软件思想

n       AM是一种轻方法论

n       XP（极限编程）就是一种AM的具体实现

 

Agile Modeling (AM) is a practice-based methodology for effective modeling and documentation of software-based systems.   Simply put, Agile Modeling (AM) is a collection of values, principles, and practices for modeling software that can be applied on a soxiftware development project in an effective and light-weight manner.  As you see in Figure 1 AM is meant to be tailored into other, full-fledged methodologies such as XP or RUP, enabling you to develop a software process which truly meets your needs.

  UML（unified model language) 统一建模语言

  UML是一门用于软件产品的建模语言

  UML是重量级的软件过程（大而全）

  UML给软件产业带来了工程化的设计理念

  UML不是方法、不是过程、不是思想。它只是一种交流工具 .

CMM(Capability Maturity Model，能力成熟度模型)是美国国防部对软件承包商软件能力评估的一种模型，也是承包商改进其软件过程的一种途径

n       其模型分为五个等级 ：

n       始级，软件生产过程的特征是随机的，有时甚至是杂乱的。很少过程被定义，成功依赖于个人的努力。

n       可重复级，建立基本的项目管理过程，以跟踪费用、进度和功能。设定必要的过程纪律以重复以往在相同应用的项目的成功。

n       已定义级，管理和工程活动的软件过程已文档化、标准化、集成化到一个标准的组织的软件过程。组织内所有的项目使用的软件过程是集体同意、裁剪过的标准开发和维护软件的版本

n       已管理级，详细的软件过程和产品质量的特征已被收集。软件过程和产品已被定量管理和控制。

n       优化级，能自觉利用各种经验和来自新技术、新思想的先导试验的定量反馈信息，不断改进和优化组织统一的标准软件过程。

n       全世界已有近万家软件机构通过认证，绝大部分通过2级，16%的企业通过3级，14家通过4级，6家通过5级。通过2级评审即可向欧美国家接订单

5. 软件的缺陷等级应如何划分？

   1．致命错误，可能导致本模块以及其他相关模块异常，死机等问题；
   2．严重错误，问题局限在本模块，导致模块功能失效或异常退出
   3．一般错误，模块功能部分失效；
   4．建议问题，由问题提出人对测试对象的改进意见；

 附加: 软件缺陷的分类与管理

　 在软件缺陷中还有一种分法，跟据缺陷内容来分，主要分为需求Bug与程序Bug，对于这种分法的好处就是明确了Bug处理的责任人。对于程序Bug我们都知道是由相关开发人员进行处理。下面主要讨论一下需求Bug,需求Bug从名称上来就知道是要交由需求人员进行处理，可怎么处理，怎样在处理的过程中有效的让这些创意得到体现。现在我们都有Bug管理系统，这时我们的测试人员将需求Bug不是提交给程序员，而是提交给需求分析人员，由他们进行处理，不过这里我想强调的是对需求Bug的定位，如果这个Bug在软件需求说明书中明确提到了，这时就不可能定位它为需求Bug，它是必需让程序员实现的，称为软件功能缺陷，提交由程序员进行处理。但如果需求说明书没有明确提到的，我们则可以定位为需求Bug.

6. 如果能够执行完美的黑盒测试，还需要进行白盒测试吗？(白盒与黑盒的区别)

   任何工程产品（注意是任何工程产品）都可以使用以下两种方法之一进行测试。 
   黑盒测试：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。 
   白盒测试：已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否以经过检查。
   软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。黑盒测试主要是为了发现以下几类错误：

　  1、是否有不正确或遗漏的功能？

    2、在接口上，输入是否能正确的接受？能否输出正确的结果？

    3、是否有数据结构错误或外部信息（例如数据文件）访问错误？

    4、性能上是否能够满足要求？

    5、是否有初始化或终止性错误？

   软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。白盒测试主要是想对程序模块进行如下检查：

　  1、对程序模块的所有独立的执行路径至少测试一遍。

    2、对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍。

    3、在循环的边界和运行的界限内执行循环体。

    4、测试内部数据结构的有效性，等等。

   以上事实说明，软件测试有一个致命的缺陷，即测试的不完全、不彻底性。由于任何程序只能进行少量（相对于穷举的巨大数量而言）的有限的测试，在未发现错误时，不能说明程序中没有错误。   

7. 测试退出标准

    测试退出标准为完成测试需求中列出的所有功能及测试过程中发现缺陷的回归测试。

    1. 单元测试退出标准

    1) 单元测试用例设计已经通过评审 
    2) 核心代码100％ 经过Code Review 
    3) 单元测试功能覆盖率达到100％ 
    4) 单元测试代码行覆盖率不低于80％ 
    5) 所有发现缺陷至少60％都纳入缺陷追踪系统且各级缺陷修复率达到标准
    6) 不存在A、B类缺陷 
    7) C、D、E类缺陷允许存在 
    8) 按照单元测试用例完成了所有规定单元的测试 
    9) 软件单元功能与设计一致

    2. 集成测试退出标准

    1) 集成测试用例设计已经通过评审 
    2) 所有源代码和可执行代码已经建立受控基线，纳入配置管理受控库，不经过审批不能随意更改 
    3) 按照集成构件计划及增量集成策略完成了整个系统的集成测试 
    4) 达到了测试计划中关于集成测试所规定的覆盖率的要求 
    5) 集成工作版本满足设计定义的各项功能、性能要求 
    6) 在集成测试中发现的错误已经得到修改，各级缺陷修复率达到标准 
    7) A、B类BUG不能存在 
    8) C、D类BUG允许存在,但不能超过单元测试总BUG的50％ 
    9) E类BUG允许存在

    3. 系统测试退出标准

    1) 系统测试用例设计已经通过评审 
    2) 按照系统测试计划完成了系统测试 
    3) 系统测试的功能覆盖率达100％ 
    4) 系统的功能和性能满足产品需求规格说明书的要求 
    5) 在系统测试中发现的错误已经得到修改并且各级缺陷修复率达到标准 
    6) 系统测试后不存在A、B、C类缺陷 
    7) D类缺陷允许存在，不超过总缺陷的5％ 
    8) E类缺陷允许存在，不超过总缺陷的10％

8. 测试计划的目的是什么？

   答：测试的目的是想以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷，通过修正种错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患带来的商业风险。

9. 软件测试应该划分几个阶段?简述各个阶段应重点测试的点?各个阶段的含义？

   大体上来说可分为单元测试,集成测试,系统测试,验收测试,每个阶段又分为以下五个步骤:

   测试计划，测试设计，用例设计，执行结果，测试报告

   初始测试集中在每个模块上，保证源代码的正确性，，该阶段成为单元测试，主要用白盒测试方法。
   接下来是模块集成和集成以便组成完整的软件包。集成测试集中在证实和程序构成问题上。     主要采用黑盒测试方法，辅之以白盒测试方法。
   软件集成后，需要完成确认和系统测试。确认测试提供软件满足所有功能、性能需求的最后保证。确认测试仅仅应用黑盒测试方法。

   单元测试  
   单元测试是对软件中的基本组成单位进行的测试，如一个模块、一个过程等等。它是软件动态测试的最基本的部分，也是最重要的部分之一，其目的是检验软件基本组成单位的正确性。
   集成测试  
   集成测试是在软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的接口是否正确。
   系统测试 
   系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等满足其规约所指定的要求，检查软件的行为和输出是否正确并非一项简单的任务，它被称为测试的“先知者问题”。
   验收测试  
   验收测试旨在向软件的购买者展示该软件系统满足其用户的需求。它的测试数据通常是系统测试的测试数据的子集.
   回归测试  
   回归测试是在软件维护阶段，对软件进行修改之后进行的测试。其目的是检验对软件进行的修改是否正确。

10. 针对缺陷采取怎样的管理措施？

   1. 要更好的管理缺陷，必须引入缺陷管理工具，商用的或者开源的都可。
   2. 根据缺陷的生命周期，考虑缺陷提交的管理、缺陷状态的管理和缺陷分析的管理。
   3. 所有发现的缺陷（不管是测试发现的还是走读代码发现的）都必须全部即时的、准确的提交 到缺陷管理工具中，这是缺陷提交的管理。
   4. 缺陷提交后，需要即时的指派给相应的开发人员，提交缺陷的人需要密切注意缺陷的状态， 帮助缺 陷的尽快解决。缺陷解决后需要即时对缺陷的修复进行验证。这样的目的有两个：一个是让缺陷尽快解决；二是方便后面缺陷的分析（保证缺陷相关的信息准确，如龄期等），这是缺陷状态的管理。
   5. 为了更好的改进开发过程和测试过程，需要对缺陷进行分析，总结如缺陷的类别、缺陷的龄期分布等信息，这是缺陷分析的管理。

　在软件缺陷中还有一种分法，跟据缺陷内容来分，主要分为需求Bug与程序Bug，对于这种分法的好处就是明确了Bug处理的责任人。对于程序Bug我们都知道是由相关开发人员进行处理。下面主要讨论一下需求Bug,需求Bug从名称上来就知道是要交由需求人员进行处理，可怎么处理，怎样在处理的过程中有效的让这些创意得到体现。现在我们都有Bug管理系统，这时我们的测试人员将需求Bug不是提交给程序员，而是提交给需求分析人员，由他们进行处理，不过这里我想强调的是对需求Bug的定位，如果这个Bug在软件需求说明书中明确提到了，这时就不可能定位它为需求Bug，它是必需让程序员实现的，称为软件功能缺陷，提交由程序员进行处理。但如果需求说明书没有明确提到的，我们则可以定位为需求Bug.

将收集到的软件测试方面的面试笔试题做个汇总,不断累积增加,尽量提供答案;一方面是对测试理论知识的学习,一方面为需要这方面资源的人提供参考.

 

1、软件测试的目的？
    答：测试的目的是想以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷，通过修正种错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患带来的商业风险。

 

 2、需求文档测试：主要测试需求中是否存在逻辑矛盾以及需求在技术上是否可以实现； 
    设计文档测试：测试设计是否符合全部需求以及设计是否合理。

 

3、什么是软件测试？  

答：软件测试是为了发现错误而执行程序的过程。或者说，软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例（即输入数据及其预期的输出结果），并利用这些测试用例去运行程序，以发现程序错误的过程。

 

4、白盒测试有哪几种方法？

   答：白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。“白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。“白盒”法是穷举路径测试。

现在如果你翻开报纸，经常能看到软件测试工程师的培训广告，很多读者看了会产生一个疑问：

 

从事软件测试行业到底有没有前途？学了这个职业未来的发展方向又会怎样？

　　微软公司的陈宏刚博士以微软公司为例告诉记者，软件测试工程师的发展途径一般有以下三种：一种选择是走软件测试的技术路线，成长为高级软件测试工程师，这时他能够独立测试很多软件，再向上可以成为软件测试架构设计师。第二种选择是向管理方向发展，从测试工程师到组长（Lead），再到测试经理（Manager），以至更高的职位。第三种选择是可以换职业，做项目管理或做开发人员都可以，很多测试工具软件开发工程师在写测试软件的过程中，因为开发方面积累了经验，同时对软件产品本身产生了自己的看法，很容易转去做产品编程。

　　有关专家指出，软件测试是正在快速发展、充满挑战的领域。尽管现在单机版桌面软件的测试已经成熟了很多，但对于网络时代的来临，包括知名跨国公司在内的大公司对基于网络的测试也没有一套完整的体系，也是处于探索中，所以说这一行业所面临的机遇与挑战是共存的。

　　曾在微软亚洲工程院测试组工作过、有三年软件测试经验的软件测试开发工程师刘俐以其自身经验告诉记者，以微软亚洲工程院为例，那里的测试工程师需要和开发工程师、规程经理一起合作，从产品定义到产品开发再到产品维护，在整个产品生命周期中不断贡献各种建议、测试文档以及测试数据。在这样一个开发团队中，测试工程师的地位和开发工程师、规程经理是一样的———是软件开发团队中不可或缺的部分。所以她个人认为，测试工程师是一个对专业技术和自身素质都有一定要求的职业。一个优秀的软件测试工程师无论在何处都是千金难求的。

　　她同时指出，正因为测试工程师与开发工程师的同等重要性，使得软件测试工程师和开发工程师的录用标准基本类似，但是由于国内的软件测试职业兴起的时间不长，社会对测试人才的供给严重不足，这就出现了所谓的软件测试工程师“千金难求”的现象。她认为一个软件测试工程师一般会与开发工程师配合工作，负责开发相应产品模块的自动化测试工具、测试用例、编写测试计划、执行测试等工作。而一般企业软件测试工程师岗位也可以根据能力和经验分为不同的等级，像在微软这样的成熟大公司中，从最初级测试工程师到高级的软件测试工程师之间可以有十几个晋升的职业等级。

 

软件测试工程师，未来计算机领域的香饽饽

 

根据有关职位统计资料显示，在国外大多数软件公司，1个软件开发工程师就需要辅有2个软件测试工程师。目前，软件测试自动化技术在我国则刚刚被少数业内专家所认知，而这方面的专业技术人员在国内更是凤毛麟角。根据对近期网络招聘IT人才情况的了解，许多正在招聘软件测试工程师的企业很少能够在招聘会上顺利招到合适的人才。

    随着中国IT行业的发展，产品的质量控制与质量管理正逐渐成为企业生存与发展的核心。从软件、硬件到系统集成，几乎每个中大型IT企业的产品在发布前都需要大量的质量控制、测试和文档工作，而这些工作必须依靠拥有娴熟技术的专业软件人才来完成。而软件测试工程师就是其中之一，目前已成为各类科技企业紧急征召的重要对象。

    了解，由于软件测试工程师处于重要岗位，所以必须具有电子、电机类相关专业知识背景，并且还应有两年以上的实际操作经验。他们应熟悉中国和国际软件测试标准，熟练掌握和操作国际流行的系列软件测试工具，能够承担比较复杂的软件分析、测试、品质管理等任务，并能独立担任测试、品质管理部门的负责人。一般情况，软件测试工程师可分为测试工程师、高级测试工程师和资深测试工程师三个等级。

   在具体工作过程中，测试工程师的工作是利用测试工具按照测试方案和流程对产品进行功能和性能测试，甚至根据需要编写不同的测试工具，设计和维护测试系统，对测试方案可能出现的问题进行分析和评估。对软件测试工程师而言，必须具有高度的工作责任心和自信心。任何严格的测试必须是一种实事求是的测试，因为它关系到一个产品的质量问题，而测试工程师则是产品出货前的把关人，所以，没有专业的技术水准是无法胜任这项工作的。同时，由于测试工作一般由多个测试工程师共同完成，并且测试部门一般要与其他部门的人员进行较多的沟通，所以要求测试工程师不但要有较强的技术能力而且要有较强的沟通能力。

     因此，在企业内部，软件测试工程师基本处于“双高”地位，即地位高、待遇高，有的人月薪可高达8000元。可以说他们的职业前景非常广阔，从近期的企业人才需求和薪金水平来看，软件测试工程师的年工资有逐年上升的明显迹象。测试工程师这个职位必将成为IT就业的新亮点。

 

 

     人是测试工作中最有价值也是最重要的资源，没有一个合格的、积极的测试小组，测试就不可能实现。然而，在软件开发产业中有一种非常普遍习惯，那就是让那些经验最少的新手、没有效率的开发者或不适合干其他工作的人去做测试工作。这绝对是一种目光短浅的行为，对一个系统进行有效的测试所需要的技能绝对不比进行软件开发需要的少，事实上，测试者将获得极其广泛的经验，他们将遇到许多开发者不可能遇到的问题。

    1、沟通能力

　　一名理想的测试者必须能够同测试涉及到的所有人进行沟通，具有与技术(开发者)和非技术人员(客户，管理人员)的交流能力。既要可以和用户谈得来，又能同开发人员说得上话，不幸的是这两类人没有共同语言。和用户谈话的重点必须放在系统可以正确地处理什么和不可以处理什么上。而和开发者谈相同的信息时，就必须将这些活重新组织以另一种方式表达出来，测试小组的成员必须能够同等地同用户和开发者沟通。

　　2、移情能力

　　和系统开发有关的所有人员都处在一种既关心又担心的状态之中。用户担心将来使用一个不符合自己要求的系统，开发者则担心由于系统要求不正确而使他不得不重新开发整个系统，管理部门则担心这个系统突然崩溃而使它的声誉受损。测试者必须和每一类人打交道，因此需要测试小组的成员对他们每个人都具有足够的理解和同情，具备了这种能力可以将测试人员与相关人员之间的冲突和对抗减少到最低程度。

　　3、技术能力

　　就总体言，开发人员对那些不懂技术的人持一种轻视的态度。一旦测试小组的某个成员作出了一个错误的断定，那么他们的可信度就会立刻被传扬了出去。一个测试者必须既明白被测软件系统的概念又要会使用工程中的那些工具。要做到这一点需要有几年以上的编程经验，前期的开发经验可以帮助对软件开发过程有较深入的理解，从开发人员的角度正确的评价测试者，简化自动测试工具编程的学习曲线。

　　4、自信心

　　开发者指责测试者出了错是常有的事，测试者必须对自己的观点有足够的自信心。如果容许别人对自己指东指西，就不能完成什么更多的事情了。

　　5、外交能力

　　当你告诉某人他出了错时，就必须使用一些外交方法。机智老练和外交手法有助于维护与开发人员的协作关系，测试者在告诉开发者他的软件有错误时，也同样需要一定的外交手腕。如果采取的方法过于强硬，对测试者来说，在以后和开发部门的合作方面就相当于“赢了战争却输了战役”。

　　6、幽默感

　　在遇到狡辩的情况下，一个幽默的批评将是很有帮助的。

　　7、很强的记忆力

　　一个理想的测试者应该有能力将以前曾经遇到过的类似的错误从记忆深处挖掘出来，这一能力在测试过程中的价值是无法衡量的。因为许多新出现的问题和我们已经发现的问题相差无几。

　　8、耐心

　　一些质量保证工作需要难以置信的耐心。有时你需要花费惊人的时间去分离、识别和分派一个错误。这个工作是那些坐不住的人无法完成的。

　　9、怀疑精神

　　可以预料，开发者会尽他们最大的努力将所有的错误解释过去。测式者必须听每个人的说明，但他必须保持怀疑直到他自己看过以后。

　　10、自我督促

　　干测试工作很容易使你变得懒散。只有那些具有自我督促能力的人才能够使自己每天正常地工作。

　　11、洞察力

　　一个好的测试工程师具有“测试是为了破坏”的观点，捕获用户观点的能力，强烈的质量追求，对细节的关注能力。应用的高风险区的判断能力以便将有限的测试针对重点环节。

 

 

 01.什么是软件测试？

   软件测试是为了发现错误而执行程序的过程。或者说，软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例（即输入数据及其预期的输出结果），并利用这些测试用例去运行程序，以发现程序错误的过程。

   软件测试在软件生存期中横跨两个阶段：通常在编写出每一个模块之后就对它做必要的测试（称为单元测试）。模块的编写者与测试者是同一个人。编码与单元测试属于软件生存期中的同一个阶段。在这个阶段结束之后，对软件系统还要进行各种综合测试，这是软件生存期的另一个独立的阶段，即测试阶段，通常由专门的测试人员承担这项工作。

02.白盒测试有哪几种方法？

   白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。“白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。“白盒”法是穷举路径测试。

03.Alpha和Beta测试的区别.

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

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

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

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

　开发人员说不是bug，有2种情况，一是需求没有确定，所以我可以这么做，这个时候可以找来产品经理进行确认，需不需要改动，商量确定好后再看要不要改。二是这种情况不可能发生，所以不需要修改，这个时候，我可以先尽可能的说出是BUG的依据是什么？如果被用户发现或出了问题，会有什么不良结果？程序员可能会给你很多理由，你可以对他的解释进行反驳。如果还是不行，那我可以给这个问题提出来,跟开发经理和测试经理进行确认,如果要修改就改,如果不要修改就不改。其实有些真的不是bug，我也只是建议的方式写进TD中，如果开发人员不修改也没有大问题。如果确定是bug的话，一定要坚持自己的立场，让问题得到最后的确认。

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

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

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

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

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

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

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

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

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

　　系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。（常见的联调测试）
    系统测试的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。

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

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

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

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

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

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

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