在我们的工作中，有很多的客户问到关于华为的面试的问题，希望我们能提供一些关于华为面试的经验，也有很多的客户建议我们能开设这样一个板块，向大家介绍如何面对知名企业的面试，我们也将相关的面试经验收集整理，供大家参阅，今天要讲的是华为的面试经验！
    面试过程中，面试官会向应聘者发问，而应聘者的回答将成为面试官考虑是否接受他的重要依据。对应聘者而言，了解这些问题背后的“猫腻”至关重要。本文对面 试中经常出现的一些典型问题进行了整理，并给出相应的回答思路和参考答案。读者无需过分关注分析的细节，关键是要从这些分析中“悟”出面试的规律及回答问 题的思维方式，达到“活学活用”。

    问题一：“请你自我介绍一下”

    ■思路：1、这是面试的必考题目。

    2、介绍内容要与个人简历相一致。

    3、表述方式上尽量口语化。

    4、要切中要害，不谈无关、无用的内容。

    5、条理要清晰，层次要分明。

    6、事先最好以文字的形式写好背熟。

    问题二：“谈谈你的家庭情况”

    ■思路：1、况对于了解应聘者的性格、观念、心态等有一定的作用，这是招聘单位问该问题的主要原因。

    2、简单地罗列家庭人口。

    3、宜强调温馨和睦的家庭氛围。

    4、宜强调父母对自己教育的重视。

    5、宜强调各位家庭成员的良好状况。

    6、宜强调家庭成员对自己工作的支持。

    7、宜强调自己对家庭的责任感。

    问题三：“你有什么业余爱好？”

    ■思路：1、业余爱好能在一定程度上反映应聘者的性格、观念、心态，这是招聘单位问该问题的主要原因。

    2、最好不要说自己没有业余爱好。

    3、不要说自己有那些庸俗的、令人感觉不好的爱好。

    4、最好不要说自己仅限于读书、听音乐、上网，否则可能令面试官怀疑应聘者性格孤僻。

    5、最好能有一些户外的业余爱好来“点缀”你的形象。

    问题四：“你最崇拜谁？”

    ■思路：1、最崇拜的人能在一定程度上反映应聘者的性格、观念、心态，这是面试官问该问题的主要原因。

    2、不宜说自己谁都不崇拜。

    3、不宜说崇拜自己。

    4、不宜说崇拜一个虚幻的、或是不知名的人。

    5、不宜说崇拜一个明显具有负面形象的人。

    6、所崇拜的人人最好与自己所应聘的工作能“搭”上关系。

    7、最好说出自己所崇拜的人的哪些品质、哪些思想感染着自己、鼓舞着自己。

    问题五：“你的座右铭是什么？”

    ■思路：1、座右铭能在一定程度上反映应聘者的性格、观念、心态，这是面试官问这个问题的主要原因。

    2、不宜说那些医引起不好联想的座右铭。

    3、不宜说那些太抽象的座右铭。

    4、不宜说太长的座右铭。

    5、座右铭最好能反映出自己某种优秀品质。

    6、参考答案——“只为成功找方法，不为失败找借口”

    问题六：“谈谈你的缺点”

    ■思路：1、不宜说自己没缺点。

    2、不宜把那些明显的优点说成缺点。

    3、不宜说出严重影响所应聘工作的缺点。

    4、不宜说出令人不放心、不舒服的缺点。

    5、可以说出一些对于所应聘工作“无关紧要”的缺点，甚至是一些表面上看是缺点，从工作的角度看却是优点的缺点。

    问题七：“谈一谈你的一次失败经历”

    ■思路：1、不宜说自己没有失败的经历。

    2、不宜把那些明显的成功说成是失败。

    3、不宜说出严重影响所应聘工作的失败经历4、所谈经历的结果应是失败的。

    5、宜说明失败之前自己曾信心白倍、尽心尽力。

    6、说明仅仅是由于外在客观原因导致失败。

    7、失败后自己很快振作起来，以更加饱满的热情

面对以后的工作。

    问题八：“你为什么选择我们公司？”

    ■思路：1、面试官试图从中了解你求职的动机、愿望以及对此项工作的态度。

    2、建议从行业、企业和岗位这三个角度来回答。

    3、参考答案——“我十分看好贵公司所在的行业，我认为贵公司十分重视人才，而且这项工作很适合我，相信自己一定能做好。”

    问题九：“对这项工作，你有哪些可预见的困难？”

    ■思路：1、不宜直接说出具体的困难，否则可能令对方怀疑应聘者不行。

    2、可以尝试迂回战术，说出应聘者对困难所持有的态度——“工作中出现一些困难是正常的，也是难免的，但是只要有坚忍不拔的毅力、良好的合作精神以及事前周密而充分的准备，任何困难都是可以克服的。”

    问题十：“如果我录用你，你将怎样开展工作”

    ■思路：1、如果应聘者对于应聘的职位缺乏足够的了解，最好不要直接说出自己开展工作的具体办法。

    2、可以尝试采用迂回战术来回答，如“首先听取领导的指示和要求，然后就有关情况进行了解和熟悉，接下来制定一份近期的工作计划并报领导批准，最后根据计划开展工作。”

    问题十一：“与上级意见不一是，你将怎么办？”

 ■思路：1、一般可以这样回答“我会给上级以必要的解释和提醒，在这种情况下，我会服从上级的意见。”

    2、如果面试你的是总经理，而你所应聘的职位另有一位经理，且这位经理当时不在场，可以这样回答：“对于非原则性问题，我会服从上级的意见，对于涉及公司利益的重大问题，我希望能向更高层领导反映。”

    问题十二：“我们为什么要录用你？”

    ■思路：1、应聘者最好站在招聘单位的角度来回答。

    2、招聘单位一般会录用这样的应聘者：基本符合条件、对这份共组感兴趣、有足够的信心。

    3、如“我符合贵公司的招聘条件，凭我目前掌握的技能、高度的责任感和良好的饿适应能力及学习能力 ，完全能胜任这份工作。我十分希望能为贵公司服务，如果贵公司给我这个机会，我一定能成为贵公司的栋梁！”

    问题十三：“你能为我们做什么？”

    ■思路：1、基本原则上“投其所好”。

    2、回答这个问题前应聘者最好能“先发制人”，了解招聘单位期待这个职位所能发挥的作用。

    3、应聘者可以根据自己的了解，结合自己在专业领域的优势来回答这个问题。

    问题十四：“你是应届毕业生，缺乏经验，如何能胜任这项工作？”

    ■思路：1、 如果招聘单位对应届毕业生的应聘者提出这个问题，说明招聘单位并不真正在乎“经验”，关键看应聘者怎样回答。

    2、对这个问题的回答最好要体现出应聘者的诚恳、机智、果敢及敬业。

    3、如“作为应届毕业生，在工作经验方面的确会有所欠缺，因此在读书期间我一直利用各种机会在这个行业里做兼职。我也发现，实际工作远比书本知识丰富、复 杂。但我有较强的责任心、适应能力和学习能力，而且比较勤奋，所以在兼职中均能圆满完成各项工作，从中获取的经验也令我受益非浅。请贵公司放心，学校所学 及兼职的工作经验使我一定能胜任这个职位。”

    问题十五：“你希望与什么样的上级共事？”

    ■思路：1、通过应聘者对上级的“希望”可以判断出应聘者对自我要求的意识，这既上一个陷阱，又上一次机会。

    2、最好回避对上级具体的希望，多谈对自己的要求。

    3、如“做为刚步入社会新人，我应该多要求自己尽快熟悉环境、适应环境，而不应该对环境提出什么要求，只要能发挥我的专长就可以了。”

    问题十六：“您在前一家公司的离职原因是什么？”

    ■思路：1、最重要的是：应聘者要使找招聘单位相信，应聘者在过往的单位的“离职原因”在此家招聘单位里不存在。

    2、避免把“离职原因”说得太详细、太具体。

    3、不能掺杂主观的负面感受，如“太幸苦”、“人际关系复杂”、“管理太混乱”、“公司不重视人才”、“公司排斥我们某某的员工”等。

    4、但也不能躲闪、回避，如“想换换环境”、“个人原因”等。

    5、不能涉及自己负面的人格特征，如不诚实、懒惰、缺乏责任感、不随和等。

    6、尽量使解释的理由为应聘者个人形象添彩。 7、如“我离职是因为这家公司倒闭。我在公司工作了三年多，有较深的感情。从去年始，由于市场形势突变，公司的局面急转直下。到眼下这一步我觉得很遗憾，但还要面对显示，重新寻找能发挥我能力的舞台。”

    同一个面试问题并非只有一个答案，而同一个答案并不是在任何面试场合都有效，关键在于应聘者掌握了规律后，对面试的具体情况进行把握，有意识地揣摩面试官提出问题的心理背景，然后投其所好。

22 什么是“软件测试”？

  Software testing is the process of analyzing a software item to detect the differences between existing and required conditions (that is, bugs) and to evaluate the features ofthe software item

1就是一个通过分析软件和需求之前差异，发现bug,对软件的功能进行评价的过程。

2.软件测试就是在受控制的条件下对系统或应用程序进行操作并评价操作的结果。

3.软件测试是为了发现错误而执行程序的过程。

23 什么是“测试案例”?

 测试案例是一份文档，它描述了一个输入、反应、或者是与其相应的预期的响应，以便来判断应用软件的工作是否正常。测试案例应当包括测试标识、测试案例的名称、目标、测试条件/设置、输入数据要求、步骤、以及预期的结果。

24 如果时间不够，无法进行充分的测试怎么办?

使用风险分析，确定测试的重点。由于很少有机会对一个应用软件进行所有可能的测试 (包括所有可能的事件组合、所有的相关性、或者一切可能出错的东西)，对大多数软件开发项目来说，利用风险分析是适当的。这需要判断技能、常识、感觉和经 验。如果有正当理由，也可采用正式的方法。需要考虑下列因素：

1) 对于该项目的用途而言，哪种功能最重要?

2) 哪种功能对用户最明显?

3) 哪种功能对安全影响最大?

4) 哪种功能对用户最有用?

5)对客户来说，该应用软件的哪个部分最重要?

6)在开发过程中，该应用软件的哪个部分可以最先测试?

7)哪一部分代码最复杂，容易导致出现错误?

8)哪一部分的应用程序是在急迫或在惊恐的情况下开发出来的?

9)哪一部分程序与过去项目中引起问题的部分相类似/有关?

10)哪一部分程序与过去项目中需要大量维护的部分相类似/有关?

11)需求和设计的那些部分不清楚或不容易读?

12)开发人员认为在应用软件中哪些部分是高风险的?

13)哪些问题能造成最差的发行?

14)哪些问题最能引起用户抱怨?

15)哪些测试可以容易地覆盖多种功能?

16)哪些测试在覆盖高风险部分的测试时使用时间最少?

25 如果需求一直在变化怎么办?

1)如果可能，尽早与承担该项目风险的人接触，以便了解需求会怎样改变，从而可以尽早地改变测试计划和策略。

2)如果在对应用程序进行初始设计时多考虑一些适应性，那么以后在发生需求的改变时，就不需要再为改变做很多事情了。

3)好的代码注释和好的文档有助于开发人员作出相应的改变。

4)只要有可能，就应使用快速原型 (rapid prototyping)，以帮助用户确认他们的需求，从而减少变更。

5)在项目的时间表中应当留出余量，以应付可能出现的变更。

6)尽量把新的需求纳入应用软件的“下一版”，而把原始需求作为“第一版”。

7)通过谈判，把易于实现的新的变更列入项目，而把难于实现的新需求列入该应用软件的以后的版本。

8)要确保让客户和管理人员了解变更对进度表的影响、所带来的风险、以及因变更所引起的大量资金消耗。

9)在应付改变时，应在为建立自动测试而作的努力和重新进行测试所做的努力之间取得平衡。

10)在设计自动测试剧本时，试图使其有一些灵活性。

11)在对应用软件进行自动测试时，要把注意力集中在看来不大会改变的部分。

12)对变更进行适当的风险分析，以减少回归测试的要求。

13)在设计测试案例时要有一定的灵活性。做到这一点并不容易，所以要降低测试案例的详细程度，或者只建立高级的通用型的测试计划。

14)少注意详细的测试计划和测试案例，要把重点放在专门的测试 (ad hoc testing) 上。

15、集成测试通常都有那些策略？

1、在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；
2、各个子功能组合起来，能否达到预期要求的父功能；
3、一个模块的功能是否会对另一个模块的功能产生不利的影响；
4、全局数据结构是否有问题；
5、单个模块的误差积累起来，是否会放大，从而达到不可接受的程度。

16、一个缺陷测试报告的组成

测试软件项目名称,每个要测试软件项目都有唯一的名称，有的公司对项目还有特定的编号。

测试软件版本号,测试周期内，一般需要测试多个软件版本，报告错误时，一定要正确填写产生错误的软件版本号。

测试者名称,便于分清责任，便于管理。

测试日期与时间,便于分析和统计错误报告信息。

测试软件环境,包括操作系统和其他必要的软件程序。

测试硬件环境,包括测试计算机和其他测试设备的配置信息。

错误描述,简明的描述错误的特征，便于查询和快速浏览。

错误标识编号 (ID#) ,每个错误都有一个唯一的标识编号，方便查询。

错误类型,根据错误类型，分配给适当的人员处理错误。

错误级别,错误的严重程度和处理的优先级，优先处理高级别的错误。

错误状态,错误状态表明错误是否已经处理和将怎样处理，根据错误状态，采用适当的处理方法。

错误处理者名称,便于分清责任，便于管理。

重现错误的操作步骤,便于重现错误，修复错误和验证错误。

期望的结果,描述满足设计要求的结果。

实际测试结果,描述实际测试后得到的结果。

必要的附图,便于确认错误的表现形式和错误位置。

测试者的建议等注释,便于错误处理者快速和正确处理错误

17、基于WEB信息管理系统测试时应考虑的因素有哪些？

一、功能测试

    1、链接测试 

    2、表单测试

    3、Cookies测试

    4、设计语言测试 

    5、数据库测试

二、性能测试

    1、连接速度测试 

    2、负载测试  

    3、压力测试  

三、可用性测试

    1、导航测试  

    2、图形测试

    3、内容测试

    4、整体界面测试

四、客户端兼容性测试

    1、平台测试   

    2、浏览器测试  

五、安全性测试

18、软件本地化测试比功能测试都有哪些方面需要注意？

 软件本地化测试的测试策略：

1.本地化软件要在各种本地化操作系统上安装并测试。

2.源语言软件安装在另一台相同源语言操作系统上，作为对比测试。

3.重点测试因本地化引起的软件的功能和软件界面的错误。

4.测试本地化软件的翻译质量。

5.手工测试和自动测试相结合

19、软件测试项目从什么时候开始？为什么？

  软件测试应该在需求分析阶段就介入,因为测试的对象不仅仅是程序编码,应该对软件开发过程中产生的所有产品都测试,并且软件缺陷存在放大趋势.缺陷发现的越晚,修复它所花费的成本就越大.

20、需求测试注意事项有哪些？

一个良好的需求应当具有一下特点：
完整性：每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。

正确性：每一项需求都必须准确地陈述其要开发的功能。

一致性：一致性是指与其它软件需求或高层（系统，业务）需求不相矛盾。

可行性：每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。

无二义性：对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的用户性的语言表达出来。

健壮性：需求的说明中是否对可能出现的异常进行了分析，并且对这些异常进行了容错处理。

必要性：“必要性”可以理解为每项需求都是用来授权你编写文档的“根源”。要使每项需求都能回溯至某项客户的输入，如Use Case或别的来源。

可测试性：每项需求都能通过设计测试用例或其它的验证方法来进行测试。

可修改性：每项需求只应在S R S 中出现一次。这样更改时易于保持一致性。

另外，使用目录表、索引和相互参照列表方法将使软件需求规格说明书更容易修改。

可跟踪性：应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，这种可跟踪性要求每项需求以一种结构化的，粒度好（f i n e - g r a i n e d ）的方式编写并单独标明，而不是大段大段的叙述。

21、简述一下缺陷的生命周期

    软件缺陷的生命周期指的是一个软件缺陷被发现、报告到这个缺陷被修复、验证直至最后关闭的完整过程。

简单的软件缺陷生命周期：
1、发现——打开：测试人员找到软件缺陷并将软件缺陷提交给开发人员；
2、打开——修复：开发人员再现、修复缺陷，然后提交测试人员去验证；
3、修复——关闭：测试人员验证修复过的软件，关闭已不存在的缺陷。

但是这是一种理想的状态，在实际的工作中是很难有这样的顺利的，需要考虑的各种情况都还是非常多的。

复杂的软件缺陷生命周期：
1、新建一个软件缺陷，这个软件缺陷是（open）状态，进行bug审查，不是代码问题，就是设计需要修改；
2、新建一个软件缺陷，这个软件缺陷是（open）状态，进行bug审查，以后修改的，就可以延期；
3、新建一个软件缺陷，这个软件缺陷是（open）状态，进行bug审查，实际没有这个bug，可以将其关闭；
4、新建一个软件缺陷，这个软件缺陷是（open）状态，看是否 清楚可重现，如果不能重现，就是缺少信息，需要返回到（open）状态；如果能够重现，就进行修正，修正后关闭，进行回归测试。
 软件缺陷生命

11.专业词语解释

α测试:

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

β测试

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

驱动模块:

驱动模块在大多数场合称为"主程序"，它接收测试数据并将这些数据传递到被测试模块.单元测试一个函数单元时，被测单元本身是不能独立运行的，需要为其传送数据，为此  写驱动

驱动模块主要完成以下事情：
1、接受测试输入；
2、对输入进行判断；
3、将输入传给被测单元，驱动被测单元执行；
4、接受被测单元执行结果，并对结果进行判断；
5、将判断结果作为用例执行结果输出测试报告。

桩模块

比如对函数A做单元测试时，被测的函数单元下还包括了一个函数B，为了更好的错误，定位错误，就要为函数B写桩，来模拟函数B的功能，保证其正确。

白盒测试

白盒测试(White-box Testing，又称逻辑驱动测试,结构测试),它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内 部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。

对开发语言的支持：白盒测试工具是对源代码进行的测试，测试的主要内容包括词法分析与语法分析、静态错误分析、动态检测等。目前测试工具主要支持的开发语言包括：标准C、C＋＋、Visual C＋＋、Java、Visual J＋+等。

静态测试

动态通过评审文档、阅读代码等方式测试软件称为静态测试,通过运行程序测试软件称为测试.在动态测试中,通常使用白盒测试和黑盒测试从不同的角度设计测试用例,查找软件代码中的错误.

12、 回归测试

回归测试的目的是在程序有修改的情况下，保证原有功能正常的一种测试策略和方法。
说白了就是，我们测试人员在对程序进行测试时发现bug， 然后返还程序员修改，程序员修改后发布新的软件包或新的软件补丁包给我们测试人员，我们就要重新对这个程序测试，已保证程序在修正了以前bug的情况下， 正常运行，且不会带来新的错误的这样一个过程。  一般情况下是不需要全面测试的，而是根据修改的情况进行有效的测试。

13、单元测试、集成测试、系统测试的侧重点是什么？

单元测试是在软件开发过程中要进行的最低级别的测试活动，在单元测试活动中，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试，测试重点是系统的模块，包括子程序的正确性验证等。

集成测试，也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求，组装成为子系统或系统，进行集成测试。实践表明，一些模块虽然能 够单独地工作，但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。测试重点是模块间的衔接 以及参数的传递等。

系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。测试重点是整个系统的运行以及与其他软件的兼容性。

14、设计用例的方法、依据有那些？  

白盒测试用例设计有如下方法:基本路径测试\等价类划分\边界值分析\覆盖测试\循环测试\数据流测试\程序插桩测试\变异测试.这时候依据就是详细设计说明书及其代码结构

黑盒测试用例设计方法:基于用户需求的测试\功能图分析方法\等价类划分方法\边界值分析方法\错误推测方法\因果图方法\判定表驱动分析方法\正交实验设计方法.依据是用户需求规格说明书,详细设计说明书。

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. 为了更好的改进开发过程和测试过程，需要对缺陷进行分析，总结如缺陷的类别、缺陷的龄期分布等信息，这是缺陷分析的管理。

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

 

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

 

3、什么是软件测试？  

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

 

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

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

=======================================================================

26.软件测试分哪两种方法？分别适合什么情况？
　
　　软件测试方法一般分为两种：白盒测试与黑盒测试。白盒测试又称为结构测试、逻辑驱动测试或基于程序本身的测试，它着重于程序的内部结构及算法，通常不关心功能与性能指标；黑盒测试又被称为功能测试、数据驱动测试或基于规格说明的测试，它实际上是站在最终用户的立场，检验输入输出信息及系统性能指标是否符合规格说明书中有关功能需求及性能需求的规定。
　
27.一套完整的测试应该由哪些阶段组成？分别阐述一下各个阶段。
　
　　计划阶段、设计阶段、白盒单元、白盒集成、黑盒单元、黑盒集成、系统测试、回归测试、验收测试一套完整的测试应该由五个阶段组成：

  1）测试计划首先，根据用户需求报告中关于功能要求和性能指标的规格说明书，定义相应的测试需求报告，即制订黑盒测试的最高标准。以后所有的测试工作都将围绕着测试需求来进行，符合测试需求的应用程序即是合格的，反之即是不合格的；同时，还要适当选择测试内容，合理安排测试人员、测试时间及测试资源等。
　
　　2）测试设计将测试计划阶段制订的测试需求分解、细化为若干个可执行的测试过程，并为每个测试过程选择适当的测试用例（测试用例选择的好坏将直接影响测试结果的有效性）。
　
　　3）测试开发建立可重复使用的自动测试过程。
　
　　4）测试执行执行测试开发阶段建立的自动测试过程，并对所发现的缺陷进行跟踪管理，测试执行一般由单元测试、组合测试、集成测试、系统联调及回归测试等步骤组成，测试人员应本着科学负责的态度，一步一个脚印地进行测试。
　
　　5）测试评估结合量化的测试覆盖域及缺陷跟踪报告，对于应用软件的质量和开发团队的工作进度及工作效率进行综合评价。
　
28.软件测试的类型有那些？分别比较这些不同的测试类型的区别与联系。
　
　　BVT （Build Verification Test）， 主要目的是验证最新生成的软件版本在功能上是否完整，主要的软件特性是否正确Scenario Tests（基于用户实际应用场景的测试），Scenario Tests优点是关注了用户的需求，缺点是有时候难以真正模仿用户真实的使用情况Smoke Test，修复Bug后，针对此次修复是否会对其他模 块造成影响而进行的专门测试。Smoke Test优点是节省测试时间，防止build失败。缺点是覆盖率还是比较低此外，还有Application Compatibility Test（兼容性测试），主要目的是为了兼容第三方软件，确保第三方软件能正常运行，用户不受影响。Accessibility Test（软件适用性测试），是确保软件对于某些有残疾的人士也能正常的使用，但优先级比较低。其它的测试还有Functional Test（功能测试）、Security Test（安全性测试）、Stress Test（压力测试）、Performance Test（性能测试）、Regression Test（回归测试）、Setup/Upgrade Test（安装升级测试）等

29.测试用例通常包括那些内容？着重阐述编制测试用例的具体做法不同结构的用例包括的不一样。（版本、编号、项目、设计人员、设计日期、输入、预期输出……）
　 
  软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果。

  用例编号： 测试用例的编号有一定的规则，比如系统测试用例的编号这样定义规则： PROJECT1-ST-001 ，命名规则是项目名称＋测试阶段类型（系统测试阶段）＋编号。定义测试用例编号，便于查找测试用例，便于测试用例的跟踪。

  测试标题： 对测试用例的描述，测试用例标题应该清楚表达测试用例的用途。比如 “ 测试用户登录时输入错误密码时，软件的响应情况 ” .重要级别： 定义测试用例的优先级别，可以笼统的分为 “ 高 ” 和 “ 低 ” 两个级别。一般来说，如果软件需求的优先级为 “ 高 ” ，那么针对该需求的测试用例优先级也为 “ 高 ” ；反之亦然，测试输入： 提供测试执行中的各种输入条件。根据需求中的输入条件，确定测试用例的输入。测试用例的输入对软件需求当中的输入有很大的依赖性，如果软件需求中没有很好 的定义需求的输入，那么测试用例设计中会遇到很大的障碍。

   操作步骤： 提供测试执行过程的步骤。对于复杂的测试用例，测试用例的输入需要分为几个步骤完成，这部分内容在操作步骤中详细列出。

   预期结果： 提供测试执行的预期结果，预期结果应该根据软件需求中的输出得出。如果在实际测试过程中，得到的实际测试结果与预期结果不符，那么测试不通过；反之则测试通过。

30.描述使用bugzilla缺陷管理工具对软件缺陷（BUG）跟踪的管理的流程

   1) 测试人员或开发人员发现bug后，判断属于哪个模块的问题，填写bug报告后，系统会自动通过Email通知项目组长或直接通知开发者。

   2) 经验证无误后，修改状态为VERIFIED.待整个产品发布后，修改为CLOSED. 

   3) 还有问题，REOPENED，状态重新变为“New"，并发邮件通知。

   4) 项目组长根据具体情况，重新reassigned分配给bug所属的开发者。

   5) 若是，进行处理，resolved并给出解决方法。（可创建补丁附件及补充说明）

   6) 开发者收到Email信息后，判断是否为自己的修改范围。

   7) 若不是，重新reassigned分配给项目组长或应该分配的开发者。

   8) 测试人员查询开发者已修改的bug，进行重新测试。（可创建test case附件）

QA活动的理解与实施
文章出处：转载 作者：不详 发布时间：2005-12-19
	摘要：QA活动是CMMI实施中较难贯彻的过程。本文针对目前国内的QA过程实施情况，从QA的地位、原则、活动、实施等方面进行了阐述。同时讨论了QA与QC、测试之间的关系，以及实施QA活动的最佳实践，为组织实施过程改进提供了基础。 1 概述 在使用CMMI模型实施过程改进时，需建立QA（Quality Assurance）的组织职能和角色，并实施“过程和产品质量保证”活动。这些活动目的在于使项目工作人员和所有各层管理者能适当地了解整个项目生存周 期中工作产品和过程的情况，从而支持交付高质量的产品和服务。 由于CMMI模型是建立在西方的企业文化背景下，包含有三权分立的思想，所以对于国内IT及软件企业而言，如何理解和建 立QA机制，更好地利用CMMI模型进行过程改进就显得非常重要。但是，目前国内IT及软件企业对于QA的意义和认识存在误区，导致在实施过程改进活动 中，QA活动流于形式或没有发挥出其真正作用。到底QA在组织中应扮演什么样的角色，CMMI的QA的与ISO9000的QA或QC（Quality Control）概念有何区别，QA与测试是什么关系，如何实施QA活动，等等，本文针对这些进行阐述，以解决企业CMMI实施过程中的薄弱环节。 2 QA的地位及活动 2.1 QA的地位 图1显示了在CMMI实施过程中QA所处的地位。 　　　　　　　　　　　　　　　　　　　　　图1 QA的组织结构 QA活动的目标是以独立审查方式，从第三方的角度监控软件开发任务的执行，就项目是否正遵循已制定的计划、标准和规程给开发人员和管理层提供反映产 品和过程质量的信息和数据，提高项目透明度，同时辅助软件工程组交付高质量的软件产品。所以对过程和产品质量保证的客观评价是项目成功的关键，一般是通过 独立于项目的QA小组来提供这种客观性。每个从事QA活动的人都要进行质量保证方面的培训。从事某个产品的QA活动的那些人不应该是直接介入该工作产品开 发或维护的人。同时，应该有一条向适当的管理层独立报告问题的渠道，以便在必要时逐级上报不符合问题。 不过，在某些组织里，不要求这种独立性而实现过程和产品质量保证角色可能更合适。例如，在一个具有开放的、面向质量的文化环境的组织里，可以由同行担任（部分或全部）过程和产品质量保证角色，可以把质量保证功能镶嵌在过程中。 QA应具备以下职责： 通过监控开发过程来保证工作产品质量 保证开发出来的产品和开发过程符合相应标准与规程； 保证产品、过程中存在的不符合问题得到处理，必要时将问题反映给高级管理者 确保项目组制定的计划、标准和规程适合项目组需要，同时满足评审需要 向开发人员提供反馈 2.2 QA的活动 QA的工作内容为： 1) 客观评价过程和工作产品：对于所实施的过程和相关工作产品以及服务对适用的过程描述、标准和规程的遵循情况进行客观评价。 2) 提供客观情况：客观地跟踪和通报不符合问题，并且确保解决它们。 　　因此，QA的活动步骤如图2所示。 　　　　　　　 　　　　　　　　　　　　　　　　　　　　　图2 QA的活动步骤 由上可知，QA涉及以下活动： 对照适用的过程描述、标准和规程客观地评价所执行的过程、工作产品和服务； 识别不符合问题，并形成文件： 向项目工作人员和管理者反馈质量保证活动情况； 确保不符合问题得到处理。 3 QA与QC、测试之间的关系 3.1 QA和QC QA和QC区别在于： QC：检验产品的质量，保证产品符合客户的需求；是产品质量检查者； QA：评审过程和产品的质量，特别要保证过程被正确执行，通过保证过程质量来保证产品质量 。 由上面的区别可知，QC进行质量控制，向管理层反馈质量信息；QA则确保QC和过程实施者按照过程进行质量控制活动，按照过程将检查结果向管理层汇报。软件开发过程和的QC工作通常就是对软件工作产品的技术评审（如同行评审等）。 在这样的原则下，简单而言QA只要检查项目按照过程进行了某项活动没有，产出了某个产品没有；而QC来检查产品是否符合质量要求。 3.2 QA与测试 下图显示了一个企业的开发过程、支持过程的关系。 　　　　　　 从现代软件工程的观点来看，测试应是软件生命周期过程的一个不可缺少的阶段，是确保规定的需求得以满足，上图的流程模型体现了这一点。而QA活动则 是贯穿于整个软件生命周期过程及其支持过程，包括培训、采购等活动，以确保所策划的过程得以实施。QA活动和测试过程可能同时关注同一个产品，但是关注的 角度不同。 应该在项目的早期阶段开始QA过程，以便确定有益于项目的计划、过程、标准和规程并且满足项目需求和组织方针。从事质量保证的人要参加计划、过程、标准和规程的确定，以确保它们适合于项目的需要和适合于进行质量保证评价。 4 实施QA活动的方法 4.1 QA的工作流程 图4描述了QA的一般工作流程。 　　　　　　 　　　　　　　　　　　　　　　　　　图4 QA的工作流程 应指定在生存周期中将进行评价的特定过程和产品。可以根据抽样方式或客观准则进行指定；这些准则要与组织的方针和项目需求以及需要一致。 识别出不符合问题后，首先是在项目内部处理，如果可能，就地加以解决。任何不能在项目组内部解决的不符合问题，要逐级上报适当的管理者予以解决。 在过程中，QA一般比较注重的是过程是否符合规范？测试是否合理、充分？评审是否及时、有效等，这些是重要的“检验”过程，可以列为重点。过程是否 符合规范，一般要看过程有没有计划，计划详细与否，可行与否，工作量评估是否可行（主要是检查评估方法）？日常管理是否可行？配置管理是否可行？过程遵循 那些标准？实施什么样的裁减，等等。 在整个QA过程的评审活动中，QA需要具备一定的数据意识，要不断的收集各种数据，尤其是质量数据。最好具备一定的项目管理经验，要不然，只能是一 种边缘参与，是进入不了项目的。QA最好能帮助PM将问题分析清楚。PM会思考要将问题做成什么样子，而QA可以思考如何去做，这样就可以达到一种配合的 效果。 其次还要注意一点，就是QA以什么心态去监控项目组，我们公司提出的是“质量服务”，也就是说，项目组是我们的客户，我们是为他们提供质量服务的。 4.2 最佳实践 实施QA活动的最佳实践应该根据不同的企业情况而不同，但以下几条是实施过程改进活动中总结出来的，具有一般意义。 1) QA人员要求 服务精神：QA应定位为教练、服务的角色，而不是警察的角色。 了解过程：熟悉过程规范。 了解开发：如果QA有过开发经验，则可更好地实施评审活动。 沟通技巧：通过好的沟通技巧发现问题，解决问题。 专门培训：QA人员最好经过专门的培训，以提高评审技巧。 2) 制定QA计划 计划中可能包含以下内容： 质量目标（与度量的数据相关联） 人员安排 时间 检查工具（检查表） 检查对象（活动和产品） 检查点及频次 3) 编制检查表 检查表是QA人员进行评审活动的工具。编制检查表时应考虑以下问题： 何时需要检查表 检查表包括什么内容 如何使用检查表 如何调整检查表 4) 形成QA报告 QA应对检查的结果形成报告，以便跟踪、解决、关闭所发现的问题。形成QA报告时应考虑： 报告目的 报告内容 问题沟通 问题跟踪 问题上报 5) 几个参见问题 QA价值开始不被项目组认可 一个全职的QA可以同时兼任多少个项目的QA工作 QA与项目组的关系难处理 项目组有了QA，可是需求文档和设计文档的质量还是不高 5 结束语 总之，QA活动对于过程改进具有重要的意义，这是由人治到法治的一个必经阶段。所以，只要国内IT及软件企业能够认真贯彻CMMI模型规范的要求，持之以恒，随时解决实施中发现的问题，就会体会到QA活动的巨大效益。

---

软件测试管理常见问题及其回答

1、测试负责人要进行严格的测试进度跟踪吗？
很多时候，由于人力资源的不足，测试项目负责人都是在执行测试，这样就使整个项目缺乏控制，一些问题（例如：有些成员的缺陷质量不够合格；开发人员修改不 及时，系统某些功能发生严重问题导致部分功能无法测试。）得不到解决，耽误了进度。所以测试负责任必须全程监控项目，尽可能多的掌握信息。通常，测试负责 人需要完成下面这些内容的管理工作：
测试用例执行情况；
每个测试员提交的缺陷情况；
测试中是否发生突发问题。


2、 测试也有版本控制吗？
这里的版本主要是指测试对象的版本控制，也就是指对开发部提交的产品进行版本控制。在开发小组版本管理不规范的情况下，测试小组进行版本控制十分重要，要 保证测试对象是可以控制的。建议开发和测试双方进行明确的约定，可以各自指定专门的测试版本负责人，制定提交原则，对提交情况进行详细的记录，这样基本避 免了版本失控导致的测试失误或无效。


3、如何处理测试人员的流动问题？
人员流动不仅仅是测试部门，这是IT行业的普遍现象。从管理者角度，主管需要多多和团队内成员进行沟通，建立一个融洽的团队环境，及时掌握情况，可以早些 进行相应的调整。但是只有企业建立好的用人制度，给员工提高广阔的发展空间和好的培训学习机会，才能从根本上解决这一问题。
加强项目管理，强化文档管理并保证文档的有效性，可以大大减少由于人员流失带来的损失。同时，测试部门要建立培训机制，使新到员工接受直接或者间接的培训，快速适应工作。


4、为什么开发人员经常抱怨测试工程师提交的缺陷质量太差？
我们经常听开发人员说：“这不是缺陷！”，“这个缺陷没有，因为我的系统上运行正常！”。测试工程师本身就是做质量工作的，提交的成果本身就应该质量高些，为什么还会有这种现象？
提交的缺陷引起争议是一种正常的现象，例如测试人员描述不清楚就会引起争议。减少甚至避免这种现象的方法是交叉测试，交叉测试是提高测试质量的一个有效手 段，当然交叉测试会增加一定的测试成本投入。在测试任务完成后，测试工程师之间互相验证彼此提交的缺陷，就会避免了缺陷描述不清、因运行环境而产生的缺陷 等一系列问题，从而大大降低了回归测试以及交流的成本，因而这种投入也是值得的，实际开发人员在单元测试阶段也会进行交叉测试，来提高开发质量。
另外，测试人员一定要按照规范描述测试中发现的缺陷，一个缺陷至少描述清楚概要描述、详细描述、重现步骤三方面的内容，缺陷管理参考第八章的内容。


5、“让那些新手来做测试，反正他们也不会什么”正确吗？
在实际项目开发中，我们常常看到有些单位忽视测试团队存在的意义，当要实施测试时，往往临时找几个程序员充当测试人员。也有些单位尽管认识到了组建测试团 队的重要性，但在具体落实的时候往往安排一些毫无开发经验的行业新手去做测试工作，这常常导致测试效率低下，测试人员对测试工作索然无味。
根据笔者的经验，测试团队应首先聘请一名资深的测试领域专家，他应具有极为丰富的同类项目软件测试经验，对软件开发过程中常见的缺陷或错误了然于胸;此 外，他还具有较好的亲和力和人格魅力。其次，项目测试团队还具有很多具备一技之长的成员，如对某些自动化测试工具运用娴熟或能轻而易举地编写自动化测试脚 本等。
另外，测试团队还应聘请一些兼职成员，如验证测试实施过程中，同行评审是最常使用的一种形式，这些同行专家就属于兼职测试团队成员的范畴。至于测试团队里里的测试新手，这部分人可以安排去从事交付验证或黑盒测试之类的


6、测试同化现象是什么？
同化现象是指随着时间的推移，开发人员会逐渐影响测试人员的思维和对缺陷的判断能力，尤其是针对同一产品，同一组开发人员和同一组测试人员共同配合了很长 时间，很多本来是缺陷的问题，由于测试人员对软件“习惯成自然”的使用，会不被当成缺陷，尤其是在开发人员的解释和说服下。同化现象发生可能意味着“恶性 循环”的开始：测试人员会帮着开发人员解释一个个缺陷的合理性，一轮有一轮的测试都不会发现问题。
招聘新的人员，不同的测试项目组轮换去测试不同的产品，就可以避免。同时建议产品可以发布测试版，更多的人对其进行测试，就可以发现更多的问题。


7、测试工程师如何避免定位效应？
社会心理学家曾作过一个试验：在召集会议时先让人们自由选择位子，之后到室外休息片刻再进入室内入座，如此五至六次，发现大多数人都选择他们第一次坐过的位子。这种现象称为定位效应，说明人们习惯上凡是自己认定的，人们大都不想轻易改变它。
定位效应在开发人员和测试人员身上都有体现。例如开发工程师针对某一自己写的功能，经常进行代码移植，这种复制的“功能”，由于上一次经过调试，在新的地方往往不会认真调试，这些代码往往会带来共享变量冲突等许多种类型的缺陷。
定位效应体现在测试人员身上就是测试过的功能不再进行认真测试：在回归测试时，之前由于进行过认真的测试，往往会认为某些功能是可靠，只要验证一些以前发 现的缺陷是否修改完成就可以了。这种现象在反复多次回归时表现的更加突出，因为回归测试中很多功能都会进行多次反复测试。众所周知，开发人员在修改缺陷时 往往会引入新的缺陷，测试人员的疏于防范就会把这些缺陷带到用户这里。
解决这种问题的方案一般有两个：
(1)完整的执行测试用例：这种方法投入较大，但是在开发产品时最好在最后一次回归测试时测试的执行一次全部的测试用例。
(2)交叉测试：测试人员交叉测试，就可以很大程度的避免定位效应。测试工程师在回归测试时互相交换任务，反复测试某一功能的机会大大减少，从而也就不会“主观的”人员某些功能没有缺陷。
通常上面的两个方法都是结合使用的，既要进行交叉测试，又要全面执行测试用例，测试覆盖面要尽可能的广泛。


8、测试人员忽然辞职怎么办？
目前IT行业人员流动较大已经成为一种不争的事实，员工的辞职大多数都会给组织带来一定的影响，而这种影响基本是不可能避免的。在测试领域，员工忽然辞职也会带来很大的负面影响，尤其测试队伍规模较小时。面对这种情况，我们所能做的，就是如何最大限度的降低这种影响。
根据作者的经验，主要有两种方法：第一种是在测试人员内部建立一个良好的学习环境，大家互相学习，这样某些特有技术不会被某一个人所掌握，而互相学习和提 高自身，也是大多数成员愿意做的；第二种就是在组织中进行知识管理，把技术作为知识沉淀下来，这样新的员工在接手工作时容易上手，通过学习快速适应环境。
此外，日常还要注意工作规范化，例如形成尽可能多的文档，都可以降低员工离职带来的损失。


9、测试人员工作发生问题测试经理应该如何做？
测试人员工作发生问题是测试经理经常要面对的问题，作为测试部门的领导，首先要做的是指出测试人员所犯的错误，使其尽快改正错误。
唯一不能做的就是盯着下属的错误不放。总盯着下属的失误，是一个领导者的最大失误。英国行为学家波特说：当遭受许多批评时，下级往往只记住开头的一些，其 余就不听了，因为他们忙于思索论据来反驳开头的批评。身为测试经理要根据测试人员的心理来进行指导，最大限度的调动每个人员的积极性来参加工作。


10、不深入到具体测试工作时，测试经理如何考核员工？
这种现象在测试规模较大的组织中很常见。测试经理应该尽可能的安排每周与每个成员在不被打扰的环境下进行谈话，这样可以尽早发现和解决很多问题。
最为一个测试经理，主要工作之一就是定期的评定组织做了些什么并且是怎样做的。同时还要为员工做一个报告——关于充分了解测试人员正在做什么和怎样做的报告，以此来给测试人员做做工作成绩考核。这份报告要了解到每个人的动态。
测试经理和每个员工重点是谈谈目前的工作，例如大家在工作中的问题或意见；是否需要帮助等。许多管理者经常抱怨没有时间在一周会见每一个员工来谈他们的工 作。但是根据作者的经验，如果不能安排时间和员工进行每周的谈话，员工会来打扰测试经理的工作，因为员工很多问题还要要来找测试经理商议。
同时对待员工要用他们能接受的方式，而不是我们自己可以接受的方式。“己之不予，勿施于人”，这条黄金法则可能会对许多生活中的纯粹的社交因素有效，但是并不是总对工作有用。有效率的管理者知道应该逐渐了解每一个员工需要怎样的对待方式。
总之，只有尽可能多的和员工接触，才能更精确的进行考核。


11、测试经理如何面对加班问题？
大多数情况下，作者是不主张加班的。当员工每周工作超过40个小时的时候，他们开始在工作的时候关心自己的事。他们花钱，会给很久没有联系的人打电话，因 为员工们一直都在工作。员工不能在太疲劳的状态下完成工作，这是因为他们在工作时不能关心自己，这种情况下通常效率很低。
测试管理工作的重要任务之一就是要创造一个环境，让员工在工作时间内完成工作，同时还要鼓励他们每周不要超过40小时，甚至可以基于他们在40个小时能够完成的工作量给他们酬劳。通常情况下这样做能够提升创造力，从而会逐渐提高效率。
测试工作本身的一个突出特点就是不断重复枯燥、冗长的测试，如果在疲劳状态下，很有可能精力不集中，略过一些重要的测试环节。而且有的时候测试需要编写测试驱动程序，这种情况更需要较好的状态来工作。


12、测试管理者如何面对自己的错误？
每个人都会犯错。我们可能会因为忘记开会而使客户发怒，承认自己犯错是一件尴尬的事情，尤其是管理人员认为对自己负责的项目小组承认犯错可能会失去尊严。 如果我们不是经常犯错，承认错误的时候其实能够赢得尊敬。例如我们忘记一次会议，然后为此向同事或者客户道歉，其他的人会理解我们的。
不管做了什么，不要否认或故意忽略自己的失误。故意忽略不会让错误消失，这只会让错误成长为怪物。


13、为什么计划定期的培训?
测试工作和开发工作一样，不但要面对日新月异的新技术，还要学习相关系统的领域知识。只有在不断的学习中，才能做好工作，跟上行业的发展。如果测试管理者 没有基于不断的变化而培训员工，就会给组织带来一定的损失。日常培训可以是关于特定项目或者是技术，通常采用下面几种方法：
（1）测试部门内自由交流方式的培训。这种培训的交流比较随意，可以在周五的例会上进行交流，也可以大家一起坐在茶馆里进行交流。方法可以采用“头脑风暴 法”，让每个组员讨论一个特定的领域，这种交流方法特别对同时要做很多不同项目的小组比较有益处。当每个人做不同的项目，这会有助于每个人了解你小组所有 的工程。
（2）跨部门的互相学习。测试工作需要很多领域以及技术知识，这些知识单靠自学是远远不够的。和其它部门的同事进行交流是一个相当好的办法，大家在工作中可以在技术等各个方面互相得到提高。
（3）外部培训。外部培训尽管投入较高，但也是值得的。这些专家一般在自己的领域非常精通，可以快速提高整个测试团队的水平。也可以通过测试小组介绍一些朋友来进行培训，这种方式可以降低成本。
培训是构造学习型组织的基本条件，也是提高员工水平的重要方法。经常的定期培训，可以增强组织凝聚力，使员工更加愿意长期留在组织中发展。做为测试负责人，定期的进行培训是十分必要的。


14、时间上不允许进行全部测试，测试负责人应该如何做？
这个问题也许十分可笑，可是现实中我们的测试经理们却不得不面对这个问题。这里的全部测试不是指对软件进行遍历测试，而是指测试负责人制定的测试计划包含的全部测试内容。
通常，不管是开发产品还是做具体的项目，都会发生耽误进度的情况。一旦整体进度不能向后延迟，项目相关人员习惯上的做法就是缩减测试时间。尤其在功能还没有开发完成的情况下，这种现象更为突出。
担负着质量重任的测试经理，如何来解决这个问题呢？比较好的做法是按照下面的步骤逐步来完成和改进工作：
（1）按照测试任务的轻重缓急，尽最大努力完成测试任务。在时间不足的情况下，我们应该对测试任务按照优先级来划分，重要紧急的任务先完成。这个时候的测 试任务是一种辅助性工作，其目的就是尽最大努力来提高质量。因此，面对这种情况，测试负责人要做的就是带领测试小组充分利用所有资源来保证质量。
（2）在实际工作中和开发人员共同配合，逐步改进工作。只有整个团队的软件开发能力提高了，才能从根源上解决问题。因此，测试负责人要带领团队和开发小组共同寻找适合自己的开发模式，从而使项目规划的更加合理，进而按照预定计划来开展测试工作。
总之，在任何情况下，测试负责人都不应该抱怨。只有积极的面对问题，才能更好的解决问题。


15、公司不重视测试，测试负责人如何开展测试工作？
目前国内的软件公司不重视测试仍然是一种普遍现象。尽管很多公司在意识上已经开始重视测试，但是在具体工作中，往往由于追赶进度、节省资源等方面原因而忽略测试工作。在这种情况下，测试负责人仍要对软件质量负主要责任。在这种环境下，测试负责人应该如何开展工作呢？
首先，要主动去配合开发人员完成工作。尤其是不能抱怨环境，在任何情况下抱怨是不能解决问题的，只能加重矛盾的激化。在此基础上，逐渐显出测试工作的重要性，然后再逐步健全测试体系。
其次，用实际行动来证明测试工作的重要性。只有测试工作的业绩逐步表现出来，人们才会真正的注意到测试的重要性。因此，测试负责人从点滴开始做起，才能逐步做好测试工作。
要想做好软件，把开发的软件产品形成商品，测试工作必须和开发一样重视。否则，质量不好的产品，很快会被市场淘汰的。现代的软件规模越来越大，测试工作也会越来越重要，因此测试负责人只要坚持做好工作，可发挥作用的空间会越来越大。
最后要说的是，如果真的是在一个没有希望的团队里，测试负责人可以考虑辞职。辞职也是一个不错的选择，到新的环境去发挥自己的能力，要比长时间的怀着“郁闷”的心情去工作好的多。


16、测试管理者需要是技术专家吗？
测试管理者在测试项目中的主要任务是制定测试策略，管理测试计划的落实情况，并且还要为测试项目的进行创造良好的执行环境。同时还要调动员工的创造性，对员工的工作作出评估。这些工作不一定要求测试管理者达到专家的水平。
但是在实际工作中，由于测试人员的短缺，测试管理者常常做为测试员来执行具体的测试任务。尤其在规模较小的测试团队，测试管理者的日常工作通常以具体的测试执行工作为主，这个时候更需要测试管理者有较好的背景知识。
总体说来，技术方面的背景知识对测试管理者是十分有益的。例如：分配工作任务、做进度预算，以及一些具体的执行工作，都需要一定的背景知识。当然，做为一 个测试管理者，没有必要精通所有的技术，那也是办不到的。测试管理者做到正确的帮助员工最好地完成工作，并且提供最好的完成工作的环境就可以了

　　bug描述的标准有：

　　1、基本标准：需要让开发人员能根据描述理解这个bug。

　　2、最好能让开发人员能明确这个bug在哪可以找到（定位）、需要怎样修复。

 

　因此我对bug描述的建议就是：

　　1. 有条理的把每个小问题列出来，分123，不要怕条目多。

　　2. 描述问题时一定要把背景交代清楚，即在哪些操作后或者什么环境中会出现，不要忽视那些你看来可能不会引起问题的操作，越细致越好。

　　3. 善于使用截图和视频录制，这些可以更直观的说明bug的产生过程和结果。

   4.再现：尽量三次再现故障。如果问题是间断的，那么最好报告问题发生的概率；例如，每3次出现一次，每3次出现2次等；

   5.推广：确定系统其他部分是否可能出现这种错误，以及使用不同的数据是否可能出现这种问题，特别是那些存在严重影响的问题。

   6.使用清晰的语言，尤其要避免使用那些有多个不同或相反含义的词汇。

   7.中立：公正地表达自己的意思，对错误及其特征的事实进行描述，避免夸张或忽略的语句，引起过度的注意力或忽视。

   8.走察：在你提交测试报告或测试评估报告之前先自己读一遍，最好是另有一个有测试工程师或测试经理走察一遍。