首先会召开需求分析会议，参加人员有产品、开发和测试，主要是探讨需求主要的一些功能点，完了之后，开发就排期进行开发，我们就根据主管写出来的计划、分配到的任务编写测试用例，写完之后会进行用例评审，有评审修改的就修改整理形成最终的用例版本，之后开发人员版本编译完成后，我们会依据测试用例来执行测试，测试过程中，提交bug， 跟踪bug，直至关闭，测试完后编写测试报告。

我的上家公司环境蛮不错的，整个项目组的成员都很团结，氛围很浓郁，遇到不懂的问题我能够和同事们进行沟通，但是考虑到我自身发展的因素，我还是被迫辞职了

首先，将问题提交到缺陷管理库里面进行备案。

然后，要获取判断的依据和标准：根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据；

如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷；

根据用户的一般使用习惯，来确认是否是缺陷；与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷；合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不参杂个人情绪。

等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并由上级做出决定。

软件生存周期是软件开发全部过程、活动和任务的结构框架，是从可行性研究到需求分析、软件设计、编码、测试、软件发布维护的过程。

在经历需求、分析、设计、实现、部署后，软件将被使用并进入维护阶段，直到最后由于缺少维护费用而逐渐消亡。这样的一个过程，称为"生命周期模型"（Life Cycle Model）。

系统测试是指针对软件产品系统进行的测试，是做完单元测试和集成测试后进行的测试，总体包含功能测试与非功能测试。

功能测试是验证软件系统功能是否实现系统需求规格的测试过程，而非功能测试是验证系统是否在实现功能测试的基础上，测试系统的容错性、稳定性、异常处理能力，以及高强度输入的处理能力、可用性、性能等是否符合用户要求的测试过程。

●界面测试

●功能测试

●可用性测试

●客户端兼容性测试

●安全性测试

（1）黑盒测试也称功能测试，通过测试来检测每个功能是否都正常使用，测试中把程序看成一个黑盒子，在完全不考虑内部程序结构和特性的情况下 ，执行测试。黑盒测试是以用户角度，从输入数据与输出数据的对应关系出发进行的测试。 缺点是：发现不了本身设计或规格说明的问题。黑盒测试设计测试用例的方法包括：等价类划分法、边界值分析法、判定表法、因果图法、正交法、错误猜测法等；

（2）白盒测试是基于代码测试，白盒是指盒子是可视的，清楚内部是如何运作的，白盒测试人员要全面了解程序内部逻辑结构、对所有的逻辑路径进行测试。 常用的白盒测试用例设计方法有：语句覆盖法、判定覆盖法、条件覆盖法、判定条件覆盖法、路径覆盖法 ；

冒烟测试是对应用程序的重点功能进行测试，主要是看测试的软件主要功能能否实现，环境通不通

Why:为什么要进行测试，测试的目的是什么

What:测试哪些方面，不同阶段的工作内容

When:测试不同阶段的起止时间

Where:相应的文档、缺陷存放位置，测试环境等

Who:测试的人员安排

How:测试的策略方法以及测试工具

录入缺陷后，测试人员应该跟踪一个缺陷的整个生命周期，从new到closed的所有状态包括new、open、fixed、rejected、delay、closed和reopen这些状态。

提交缺陷到缺陷管理工具，这时缺陷的状态是new。当确认是bug后，打开缺陷，此时缺陷状态为open，并且指派给相应的开发人员。开发人员进行修改把缺陷状态置为fixed修改状态，修改好后等待测试人员回归测试。如果开发人员认为不是bug有权拒绝修改把缺陷状态改为rejected。如果开发人员认为暂时不需要修改或暂时不能修改，则延后修改，缺陷状态为delay。修改状态的bug经过测试人员复测通过后，则关闭bug，状态为closed。如果复测不通过，则重新打开bug这时的缺陷状态是reopen，等待开发人员重新修改。

QA是质量保证人员 QC是质量控制人员

他们都是对质量进行管理，都是在查找错误，但是QC查找的是产品错误，而QA查找的是过程错误

功能性方面：首先看看这部电梯是否能够使用，能不能承载重物，看看使用说明；

安全性方面： 看这部电梯有没有产品安全标识，验证在使用过程中是否能够保证安全使用；

易用性方面：看看这部电梯操作是否都能正常，按键能不能操作，门能否能打开；

界面方面 ：先看看电梯外观是否完好无损，有没有破坏的地方，或者设计不合理的地方；

兼容性方面 ：看看这样的电梯安装在不同地区的楼层是都都能正常使用，在不同的温度，人员重量下是否正常使用；

性能测试方面：看看电梯的控制主板是否正常，是否需要等很长时间；

压力测试方面 ：实验用此电梯的极限重量的物品放在电梯里面，看电梯是否会报警；

可靠性方面：长时间使用这部电梯看看电梯正常工作的最长时间是多少。

1、寻找Bug；

2、避免软件开发过程中的缺陷；
3、衡量软件的品质；
4、关注用户的需求。
总的目标是：确保软件的质量。

黑盒测试的优点有：

●比较简单，不需要了解程序内部的代码及实现；

●与软件的内部实现无关；

●从用户角度出发，能很容易的知道用户会用到哪些功能，会遇到哪些问题；

●基于软件开发文档，所以也能知道软件实现了文档中的哪些功能；

●在做软件自动化测试时较为方便。

黑盒测试的缺点有：

●不可能覆盖所有的代码，覆盖率较低，大概只能达到总代码量的30%；

●自动化测试的复用性较低。

白盒测试的优点有：

●帮助软件测试人员增大代码的覆盖率，提高代码的质量，发现代码中隐藏的问题。

白盒测试的缺点有：

●程序运行会有很多不同的路径，不可能测试所有的运行路径；

●测试基于代码，只能测试开发人员做的对不对，而不能知道设计的正确与否，可能会漏掉一些功能需求；

系统庞大时，测试开销会非常大。

软件测试计划是指导测试过程的纲领性文件。

包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。

测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。所以其中最重要的是测试测试策略和测试方法（最好是能先评审）。

划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.

边界值分析法

边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.

使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.

错误猜测法

基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.

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

因果图方法

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

正交表分析法

有时候，可能因为大量的参数的组合而引起测试用例数量上的激增，同时，这些测试用例并没有明显的优先级上的差距，而测试人员又无法完成这么多数量的测试，就可以通过正交表来进行缩减一些用例，从而达到尽量少的用例覆盖尽量大的范围的可能性。

场景分析方法

指根据用户场景来模拟用户的操作步骤，这个比较类似因果图，但是可能执行的深度和可行性更好。 

状态图法

通过输入条件和系统需求说明得到被测系统的所有状态，通过输入条件和状态得出输出条件；通过输入条件、输出条件和状态得出被测系统的测试用例。

大纲法

大纲法是一种着眼于需求的方法，为了列出各种测试条件，就将需求转换为大纲的形式。大纲表示为树状结构，在根和每个叶子结点之间存在唯一的路径。大纲中的每条路径定义了一个特定的输入条件集合，用于定义测试用例。树中叶子的数目或大纲中的路径给出了测试所有功能所需测试用例的大致数量。

在传统的BugZilla中，BUG描述应该包括以下的信息：

●和BUG产生对应的软件版本和模块

●开发的接口人员

●BUG的优先级

●BUG的严重程度

●BUG可能属于的模块，如果不能确认，可以用开发人员来判断

●BUG标题，需要清晰的描述现象

●BUG描述，需要尽量给出重新Bug的步骤

●BUG附件中能给出相关的日志和截图。

●高质量的BUG记录就是指很容易理解的BUG记录，所以，对于描述的要求高，能提供的信息多且准确，很好的帮助开发人员定位，因此提交高质量的软件缺陷记录需要注意对BUG记录的描述质量多且准确。

尽量面对面的沟通，其次是能直接通过电话沟通，如果只能通过Email等非及时沟通工具的话，强调必须对特性的理解深刻以及能表达清楚。

运用一些测试管理工具如TestDirector进行管理也是较有效的方法，同时要注意在TestDirector中对BUG有准确的描述。

在团队中建立测试人员与开发人员良好沟通中注意以下几点：

1、真诚；

2、有团队精神；

3、是在专业上有共同语言；

4、是要对事不对人，工作至上；

当然也可以通过直接指出一些小问题，而不是进入BUG Tracking System来增加对方的好感。

回答这个面试题，没有固定统一的答案，但可能是许多企业都会问到的。提供以下答案参考：

最大的兴趣，感觉这是一个有挑战性的工作；

测试是一个经验行业，工作越久越能感觉到做好测试的难度和乐趣；通过自己的工作，能使软件产品越来越完善，从中体会到乐趣。

回答此类问题注意以下几个方面：

1、尽可能的切合招聘企业的技术路线来表达你的兴趣，例如该企业是数据库应用的企业，那么表示你的兴趣在数据库的测试，并且希望通过测试提升自己的数据库掌握能力。表明你做测试的目的是为了提升能力，也是为了更好的做好测试；提升能力不是为了以后转开发或其他的，除非用人企业有这样的安排。

2、不要过多的表达你的兴趣在招聘企业的范畴之外。比如招聘企业是做财务软件的，可是你表现出来的是对游戏软件的兴趣；或招聘是做JAVA开发的，而你的兴趣是在C类语言程序的开发。

自顶向下集成

优点：较早地验证了主要控制和判断点；按深度优先可以首先实现和验证一个完整的软件功能；功能较早证实，带来信心；只需一个驱动，减少驱动器开发的费用；支持故障隔离。

缺点：柱的开发量大；底层验证被推迟；底层组件测试不充分。

适应于产品控制结构比较清晰和稳定；高层接口变化较小；底层接口未定义或经常可能被修改；接口控制组件具有较大的技术风险，需要尽早被验证；希望尽早能看到产品的系统功能行为。

自底向上集成

优点：对底层组件行为较早验证；工作最初可以并行集成，比自顶向下效率高；减少了桩的工作量；支持故障隔离。

缺点：驱动的开发工作量大；对高层的验证被推迟，设计上的错误不能被及时发现。
适应于底层接口比较稳定；高层接口变化比较频繁；底层组件较早被完成。