1.白盒测试和黑盒测试是什么？什么是回归测试？
白盒测试要了解软件内部的结构，测试代码是否正确实现了功能。
黑盒测试是不需要了解软件内部节构，依据软件的需求规格说明书，检查程序的功能是否符合需求说明。
回归测试一是检查所作的修改是否达到预定目的，如错误得到改正，能够适应新的运行环境等等；二是不影响软件的其他功能的正确性。
2.单元测试、集成测试、系统测试的侧重点是什么？
单元测试的重点是系统的模块，包括子程序的正确性验证等。
集成测试的重点是模块间的衔接以及参数的传递等。
系统测试的重点是整个系统的运行以及与其它软件的兼容性。
3.设计用例的方法、依据是哪些？
白盒测试用例设计有如下方法：基本路径测试、等价类划分、边界值分析、覆盖测试、循环测试、数据流测试、程序插桩测试、变异测试。这时候依据就是详细设计说明书及其代码结构。
黑盒测试用例设计方法：等价类划分、边界值分析、错误推测方法、因果图方法、场景设计法；依据是用户需求规格说明书，详情设计说明书。
4.一个测试工程师应具备哪些素质和技能？
掌握基本的测试基础理论
本着找出软件存在的问题的态度进行测试，即客观，不要以挑刺形象出现
可熟练阅读需求规格说明书等文档
以用户的观点看待问题
有着强烈的质量意识
细心和责任心
良好的有效的沟通方式（与开发人员及客户）
具有以往的测试经验
能够及时准确地判断出高危险区在何处
5.集成测试通常都有哪些策略？
大爆炸集成；自顶向下集成；自底向上集成；三明治集成；分层集成；基干集成；基于功能的集成；基于消息的集成；基于风险的集成；基于进度的集成；
6.你用过的测试工具的主要功能、性能及其他？
QTP全名HP QuickTest Professional software ，最新的版本为HP QuickTest
Professional 11.0QTP是quicktest
Professional的简称，是一种自动测试工具。使用QTP的目的是想用它来执行重复的手动测试，主要是用于回归测试和测试同一软件的新版本。因此你在测试前要考虑好如何对应用程序进行测试，例如要测试那些功能、操作步骤、输入数据和期望的输出数据等QuickTest针对的是GUI应用程序，包括传统的Windows应用程序，以及现在越来越流行的Web应用。它可以覆盖绝大多数的软件开发技术，简单高效，并具备测试用例可重用的特点。其中包括：创建测试、插入检查点、检验数据、增强测试、运行测试、分析结果和维护测试等方面。
7.一个缺陷测试报告的组成？
8.基于WEB信息管理系统测试时应考虑的因素有哪些？
a.功能测试：链接测试，表单测试，Cookie测试，设计语言测试，数据库测试
b.性能测试：连接速度测试，负载测试，压力测试
c.可用性测试：导航测试，图形测试，内容测试，整体界面测试
d.客户端兼容性测试：平台测试，浏览器测试
e.安全性测试
9.软件本地化测试比功能测试都有哪些方面需要注意？
Professional 11.0QTP是quicktest
Professional的简称，是一种自动测试工具。使用QTP的目的是想用它来执行重复的手动测试，主要是用于回归测试和测试同一软件的新版本。因此你在测试前要考虑好如何对应用程序进行测试，例如要测试那些功能、操作步骤、输入数据和期望的输出数据等QuickTest针对的是GUI应用程序，包括传统的Windows应用程序，以及现在越来越流行的Web应用。它可以覆盖绝大多数的软件开发技术，简单高效，并具备测试用例可重用的特点。其中包括：创建测试、插入检查点、检验数据、增强测试、运行测试、分析结果和维护测试等方面。
7.一个缺陷测试报告的组成？
缺陷的标题，缺陷的基本信息，复现缺陷的操作步骤，缺陷的实际结果描述，期望的正确结果描述，注释文字和截取的缺陷图象。
()
()
8.基于WEB信息管理系统测试时应考虑的因素有哪些？
a.功能测试：链接测试，表单测试，Cookie测试，设计语言测试，数据库测试
b.性能测试：连接速度测试，负载测试，压力测试
c.可用性测试：导航测试，图形测试，内容测试，整体界面测试
d.客户端兼容性测试：平台测试，浏览器测试
e.安全性测试
9.软件本地化测试比功能测试都有哪些方面需要注意？
本地化测试需要注意翻译为目标语言后，是否符合当地人民的风俗习惯，文化风格。不要出现当地敏感的信息。
如果看不懂目标语言，就很简单了，只需要注意该翻译的都翻译了，不该翻译的没有被翻译，然后没有图片或文字的截断，翻译明显不合适的这些点就ok了。
此外还要大体的点一点功能，没有严重的功能问题，就可以了.
10.软件测试项目从什么时候开始，为什么
软件测试应该在需求分析阶段就介入，因为测试的对象不仅仅是程序编码，应该对软件开发过程中产生的所有产品都测试，并且软件缺陷存在放大趋势，缺陷发现的越晚，修复它所花费的成本就越大。
11.需求测试注意事项有哪些？
一个良好的需求应当具有以下特点：
完整性：每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。
正确性：每一项需求都必须准确地陈述其要开发的功能。
一致性：一致性是指与其它软件需求或高层（系统，业务）需求不相矛盾。
可行性：每一项需求都必须是与已知系统和环境的权能和限制范围内可以实施的。
无二义性：对所有需求说明的读者都只能有一个明确统一的解释，由于自然语方极易导致二义性，所以尽量把每项需求用简洁明了的用户性的语方表达出来。
健壮性：需求的说明中是否对可能出现的异常进行了分析，并且对这些异常进行了容错处理。
必要性：可以理解为每项需求都是用来授权你编写文档的“根源”。要使用每项需求都能回溯至某项客户的输入，如Use Case或别的来原。
可测试性：每项需求只应在SRS中出现一次。这样更改时易于保持一致性。另外，使用目录表、索引和相互参照列表方法将使软件需求规格说明书更容易修改。
可跟踪性：应能对每项软件需求与它的根源和设计元素、源代码、测试用例之间建立链接链，这种可跟踪性要求每项需求以一种结构化的，粒度好的方式编写并单独标明，而不是大段大段的叙述。
12.简述一下缺陷的生命周期。
新建--提交--确认--分配--修复--验证--关闭
13.分析测试用例注意（事项）？
a.为什么要写用例
我们编写测试用例，有如下的好处：
便于团队交流：假如说一个测试团队有10个成员，大家测试的时候都各自为政，没有统一的标准，测试的效率无疑会大打折扣；如果大家都遵循统一的用例规范去写，就会解决这一问题。
便于重复测试：大家知道，软件在实际开发过程中是会有不同的版本的，比如会从1.0升级为10.0，那么如果不写测试用例的话，在测试10.0版本的时候，你能完全记得1.0版本时你做过哪些测试吗？测试用例就像一个备忘录一样，便于重复测试。
便于跟踪统计：
这一点是针对测试经理或是项目经理来说的，项目负责人通过看测试用例的执行情况，就能了解到项目目前的概况，比如已经执行了哪些测试，还有哪些测试没有执行，测试没有通过的地方主要集中在哪些模块等。
便于用户自测：尤其是项目软件，有的时候用户希望自己测试一下软件产品，但是用户大都是非专业人士，他需要根据你写好的用例来更好的检验产品的质量。
说了这么多测试用例的优点，那它有没有缺点呢？有一个明显的缺点就是需要花费大量的时间，通常编写测试用例的时间比实际执行测试的时间还要长，这一点大家会在实际工作中有深刻的体会。
b.什么时候写用例
测试用例要尽早编写，通常我们都会在测试设计阶段来写用例，即《需求规格说明书》和《测试计划》都已完成之后。
14.测试结束的标准是什么？
用例全部测试；覆盖率达到标准；缺陷率达到标准；其他指标达到质量标准
如果看不懂目标语言，就很简单了，只需要注意该翻译的都翻译了，不该翻译的没有被翻译，然后没有图片或文字的截断，翻译明显不合适的这些点就ok了。
此外还要大体的点一点功能，没有严重的功能问题，就可以了.
10.软件测试项目从什么时候开始，为什么
软件测试应该在需求分析阶段就介入，因为测试的对象不仅仅是程序编码，应该对软件开发过程中产生的所有产品都测试，并且软件缺陷存在放大趋势，缺陷发现的越晚，修复它所花费的成本就越大。
11.需求测试注意事项有哪些？
一个良好的需求应当具有以下特点：
完整性：每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。
正确性：每一项需求都必须准确地陈述其要开发的功能。
一致性：一致性是指与其它软件需求或高层（系统，业务）需求不相矛盾。
可行性：每一项需求都必须是与已知系统和环境的权能和限制范围内可以实施的。
无二义性：对所有需求说明的读者都只能有一个明确统一的解释，由于自然语方极易导致二义性，所以尽量把每项需求用简洁明了的用户性的语方表达出来。
健壮性：需求的说明中是否对可能出现的异常进行了分析，并且对这些异常进行了容错处理。
必要性：可以理解为每项需求都是用来授权你编写文档的“根源”。要使用每项需求都能回溯至某项客户的输入，如Use Case或别的来原。
可测试性：每项需求只应在SRS中出现一次。这样更改时易于保持一致性。另外，使用目录表、索引和相互参照列表方法将使软件需求规格说明书更容易修改。
可跟踪性：应能对每项软件需求与它的根源和设计元素、源代码、测试用例之间建立链接链，这种可跟踪性要求每项需求以一种结构化的，粒度好的方式编写并单独标明，而不是大段大段的叙述。
12.简述一下缺陷的生命周期。
新建--提交--确认--分配--修复--验证--关闭
13.分析测试用例注意（事项）？
a.为什么要写用例
我们编写测试用例，有如下的好处：
便于团队交流：假如说一个测试团队有10个成员，大家测试的时候都各自为政，没有统一的标准，测试的效率无疑会大打折扣；如果大家都遵循统一的用例规范去写，就会解决这一问题。
便于重复测试：大家知道，软件在实际开发过程中是会有不同的版本的，比如会从1.0升级为10.0，那么如果不写测试用例的话，在测试10.0版本的时候，你能完全记得1.0版本时你做过哪些测试吗？测试用例就像一个备忘录一样，便于重复测试。
便于跟踪统计：
这一点是针对测试经理或是项目经理来说的，项目负责人通过看测试用例的执行情况，就能了解到项目目前的概况，比如已经执行了哪些测试，还有哪些测试没有执行，测试没有通过的地方主要集中在哪些模块等。
便于用户自测：尤其是项目软件，有的时候用户希望自己测试一下软件产品，但是用户大都是非专业人士，他需要根据你写好的用例来更好的检验产品的质量。
说了这么多测试用例的优点，那它有没有缺点呢？有一个明显的缺点就是需要花费大量的时间，通常编写测试用例的时间比实际执行测试的时间还要长，这一点大家会在实际工作中有深刻的体会。
b.什么时候写用例
测试用例要尽早编写，通常我们都会在测试设计阶段来写用例，即《需求规格说明书》和《测试计划》都已完成之后。
14.测试结束的标准是什么？
用例全部测试；覆盖率达到标准；缺陷率达到标准；其他指标达到质量标准