一个测试工程师应具备那些素质和技能?
    一个好的测试工程师，不仅要基础扎实，对自身的性格、责任心都有非常高的要求。具体如下：

(1)掌握基本的测试基础理论
(2)本着找出软件存在的问题的态度进行测试,即客观吧,不要以挑刺形象出现(3)可熟练阅读需求规格说明书等文档
(4)以用户的观点看待问题
(5)有着强烈的质量意识
(6)细心和责任心
(7)良好的有效的沟通方式(与开发人员及客户)
(8)具有以往的测试经验
(9)能够及时准确地判断出高危险区在何处.
    集成测试通常都有那些策略?
    大致说四点即可，当然说全更好。集成测试有十种策略:
(1)大爆炸集成
(2)自顶向下集成
(3)自底向上集成
(4)三明治集成
(5)分层集成
(6)基干集成
(7)基于功能的集成
(8)基于消息的集成
(9)基于风险的集成
(10)基于进度的集成.
    1、什么是兼容性测试？兼容性测试侧重哪些方面？
    兼容测试主要是检查软件在不同的硬件平台、软件平台上是否可以正常的运行，即是通常说的软件的可移植性。
    兼容的类型，如果细分的话，有平台的兼容，网络兼容，数据库兼容，以及数据格式的兼容。
    兼容测试的重点是，对兼容环境的分析。通常，是在运行软件的环境不是很确定的情况下，才需要做兼容。根据软件运行的需要，或者根据需求文档，一般都能够得出用户会在什么环境下使用该软件，把这些环境整理成表单，就得出做兼容测试的兼容环境了。
    兼容和配置测试的区别在于，做配置测试通常不是Clean OS下做测试，而兼容测试多是在Clean OS的环境下做的。
3、测试的策略有哪些？
黑盒/白盒，静态/动态，手工/自动，冒烟测试，回归测试，公测（Beta测试的策略）4、正交表测试用例设计方法的特点是什么？
用最少的实验覆盖最多的操作，测试用例设计很少，效率高，但是很复杂；对于基本的验证功能，以及二次集成引起的缺陷，一般都能找出来；但是更深的缺陷，更复杂的缺陷，还是无能为力的；具体的环境下，正交表一般都很难做的。大多数，只在系统测试的时候使用此方法。
5、描述使用bugzilla缺陷管理工具对软件缺陷（BUG）跟踪的管理的流程？
就是Bugzilla的状态转换图。
6、你觉得bugzilla在使用的过程中，有什么问题？
界面不稳定；
根据需要配置它的不同的部分，过程很烦琐。
流程控制上，安全性不好界定，很容易对他人的Bug进行误操作；没有综合的评分指标，不好确认修复的优先级别。
7、描述测试用例设计的完整过程？
需求分析 + 需求变更的维护工作；
根据需求 得出测试需求；
设计测试方案，评审测试方案；
方案评审通过后，设计测试用例，再对测试用例进行评审；8、单元测试的策略有哪些？
逻辑覆盖、循环覆盖、同行评审、桌前检查、代码走查、代码评审、景泰数据流分析9、LoadRunner分哪三部分？
脚本生成器；
场景控制器；
结果分析器；
10、LoadRunner进行测试的流程?
1、 测试测试
2、 创建虚拟用户脚本
3、 创建运行场景
4、 运行测试脚本
5、 监视场景
6、 分析测试的结果
以上，最好是结合一个案例，根据以上流程来介绍。
什么是并发？在lordrunner中，如何进行并发的测试？集合点失败了会怎么样？
在同一时间点，支持多个不同的操作。
LoadRunner中提供IP伪装，集合点，配合虚拟用户的设计，以及在多台电脑上设置，可以比较好的模拟真实的并发。
集合点，即是多个用户在某个时刻，某个特定的环境下同时进行虚拟用户的操作的。集合点失败，则集合点的才操作就会取消，测试就不能进行。
12、使用QTP做功能测试，录制脚本的时候，要验证多个用户的登录情况/查询情况，如何操作？
分析用户登录的基本情况，得出一组数据，通过性测试/失败性测试的都有（根据TC来设计这些数据），然后录制登录的脚本，将关键的数据参数化，修改脚本，对代码进行加强，调试脚本。
13、QTP中的Action有什么作用？有几种？
Action的作用
n       用Action可以对步骤集进行分组
n       步骤重组，然后被整体调用
n       拥有自己的sheet
n       组合有相同需求的步骤，整体操作
n       具有独立的对象仓库
Action的种类
n       可复用Action
n       不可复用Action
n       外部Action
14、TestDirector有些什么功能，如何对软件测试过程进行管理？
需求管理
n       定义测试范围
n       定义需求树
n       描述需求树的功能点
测试计划
n       定义测试目标和测试策略。
n       分解应用程序，建立测试计划树。
n       确定每个功能点的测试方法。
n       将每个功能点连接到需求上，使测试计划覆盖全部的测试需求。
n       描述手工测试的测试步骤
n       指明需要进行自动测试的功能点
测试执行
n       定义测试集合。
n       为每个测试人员制定测试任务和测试日程安排。
n       运行自动测试。
缺陷跟踪
n       记录缺陷
n       查看新增缺陷，并确定哪些是需要修正的
n       相关技术人员修改缺陷
n       回归测试
n       分析缺陷统计图表，分析应用程序的开发质量。
15、你所熟悉的软件测试类型都有哪些？请试着分别比较这些不同的测试类型的区别与联系（如功能测试、性能测试……）？
Compatibility Testing（兼容性测试），也称“Configuration testing（配置测试）”，测试软件是否和系统的其它与之交互的元素之间兼容，如：浏览器、操作系统、硬件等。验证测试对象在不同的软件和硬件配置中的运行情况。
Functional testing (功能测试)，也称为behavioral testing（行为测试），根据产品特征、操作描述和用户方案，测试一个产品的特性和可操作行为以确定它们满足设计需求。本地化软件的功能测试，用于验证应用程序或网站对目标用户能正确工作。使用适当的平台、浏览器和测试脚本，以保证目标用户的体验将足够好，就像应用程序是专门为该市场开发的一样。
Performance testing（性能测试），评价一个产品或组件与性能需求是否符合的测试。包括负载测试、强度测试、数据库容量测试、基准测试等类型。
16、软件缺陷（或者叫Bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（Bug）记录？
5C标准
17、Beta测试与Alpha测试有什么区别？
Beta testing(β测试),测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场Alpha testing (α测试),是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试18、软件的评审一般由哪些人参加？其目的是什么？
在正式的会议上将软件项目的成果（包括各阶段的文档、产生的代码等）提交给用户、客户或有关部门人员对软件产品进行评审和批准。其目的是找出可能影响软件产品质量、开发过程、维护工作的适用性和环境方面的设计缺陷，并采取补救措施，以及找出在性能、安全性和经济方面的可能的改进。
人员：用户、客户或有关部门开发人员，测试人员，需求分析师都可以，就看处于评审那个阶段19、测试活动中，如果发现需求文档不完善或者不准确，怎么处理？
测试需求分析发现需求文档不完善或者不准确，应该立即和相关人员进行协调交流。
20、阶段评审与项目评审有什么区别？
阶段评审对项目各阶段评审：对阶段成果和工作
项目评审对项目总体评审：对工作和产品
21、阐述工作版本的定义？
构造号： BUILD
22、什么是桩模块？什么是驱动模块？
桩模块：被测模块调用模块
驱动模块调用被测模块
23、什么是扇入？什么是扇出？
扇入：被调次数，扇出：调其它模块数目
24、你认为做好测试计划工作的关键是什么？
软件测试计划就是在软件测试工作正式实施之前明确测试的对象，并且通过对资源、时间、风险、测试范围和预算等方面的综合分析和规划，保证有效的实施软件测试；做好测试计划工作的关键：目的，管理，规范
1. 明确测试的目标，增强测试计划的实用性
编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷，因此软件测试计划的价值取决于它对帮助管理测试项目，并且找出软件潜在的缺陷。因此，软件测试计划中的测试范围必须高度覆盖功能需求，测试方法必须切实可行，测试工具并且具有较高的实用性，便于使用，生成的测试结果直观、准确2．坚持“5W”规则，明确内容与过程
“5W”规则指的是“What（做什么）”、“Why（为什么做）”、“When（何时做）”、“Where（在哪里）”、“How（如何做）”。利用“5W”规则创建软件测试计划，可以帮助测试团队理解测试的目的（Why），明确测试的范围和内容（What），确定测试的开始和结束日期（When），指出测试的方法和工具（How），给出测试文档和软件的存放位置（Where）。
3．采用评审和更新机制，保证测试计划满足实际需求测试计划写作完成后，如果没有经过评审，直接发送给测试团队，测试计划内容的可能不准确或遗漏测试内容，或者软件需求变更引起测试范围的增减，而测试计划的内容没有及时更新，误导测试执行人员。
4. 分别创建测试计划与测试详细规格、测试用例
应把详细的测试技术指标包含到独立创建的测试详细规格文档，把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。
25、你认为做好测试用例工作的关键是什么？
需求和设计文档的理解程度，对系统的熟悉程度
26、简述一下缺陷的生命周期？
提交->确认->分配->修复->验证->关闭
27、软件的安全性应从哪几个方面去测试？
(1)用户认证机制：如数据证书、智能卡、双重认证、安全电子交易协议(2)加密机制
(3)安全防护策略：如安全日志、入侵检测、隔离防护、漏洞扫描(4)数据备份与恢复手段：存储设备、存储优化、存储保护、存储管理(5)防病毒系统
28、软件配置管理工作开展的情况和认识？
软件配置管理贯穿于软件开发、测试活动的始终，覆盖了开发、测试活动的各个环节，它的重要作用之一就是要全面的管理保存各个配置项，监控各配置项的状态，并向项目经理及相关的人员报告，从而实现对软件过程的控制。
软件测试配置管理包括4个最基本的活动：
配置项标识
配置项控制
配置项状态报告
配置审计
       软件配置管理通常借助工具来辅助，主要有MS SourceSafe、Rational ClearCase等29、你觉得软件测试通过的标准应该是什么样的？
    缺陷密度值达到客户的要求
30、引入测试管理的含义？
风险分析，进度控制、角色分配、质量控制
31、一套完整的测试应该由哪些阶段组成？
参考答案：测试计划、测试设计与开发、测试实施、测试评审与测试结论32、单元测试的主要内容？
　模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试33、集成测试也叫组装测试或者联合测试，请简述集成测试的主要内容？
（1）在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；　（2）一个模块的功能是否会对另一个模块的功能产生不利的影响；　（3）各个子功能组合起来，能否达到预期要求的父功能；　（4）全局数据结构是否有问题；
　（5）单个模块的误差累积起来，是否会放大，从而达到不能接受的程度。
34、简述集成测试与系统测试关系？
　（1）集成测试的主要依据概要设计说明书，系统测试的主要依据是需求设计说明书；　（2）集成测试是系统模块的测试，系统测试是对整个系统的测试，包括相关的软硬件平台、网络以及相关外设的测试。
35、软件测试的文档测试应当贯穿于软件生命周期的全过程，其中用户文档是文档测试的重点。那么软件系统的用户文档包括哪些？
　　用户手册
　　安装和设置指导
　　联机帮助
　　指南、向导
　　样例、示例和模板
　　授权/注册登记表
最终用户许可协议
36、软件系统中除用户文档之外，文档测试还应该关注哪些文档？
开发文档
软件需求说明书
　　　　数据库设计说明书
　　　　概要设计说明书
　　　　详细设计说明书
　　　　可行性研究报告
管理文档
　　　　项目开发计划
　　　　测试计划
　　　　测试报告
　　　　开发进度月报
　　　　开发总结报告
37、简述软件系统中用户文档的测试要点？
　（1）读者群。文档面向的读者定位要明确。对于初级用户、中级用户以及高级用户应该有不同的定位　（2）术语。文档中用到的术语要适用与定位的读者群，用法一致，标准定义与业界规范相吻合。
　（3）正确性。测试中需检查所有信息是否真实正确，查找由于过期产品说明书和销售人员夸大事实而导致的错误。检查所有的目录、索引和章节引用是否已更新，尝试链接是否准确，产品支持电话、地址和邮政编码是否正确。
　（4）完整性。对照软件界面检查是否有重要的分支没有描述到，甚至是否有整个大模块没有描述到。
　（5）一致性。按照文档描述的操作执行后，检查软件返回的结果是否与文档描述的相同。
　（6）易用性。对关键步骤以粗体或背景色给用户以提示，合理的页面布局、适量的图表都可以给用户更高的易用性。需要注意的是文档要有助于用户排除错误。不但描述正确操作，也要描述错误处理办法。文档对于用户看到的错误信息应当有更详细的文档解释。
　（7）图表与界面截图。检查所有图表与界面截图是否与发行版本相同。
　（8）样例与示例。像用户一样载入和使用样例。如果是一段程序，就输入数据并执行它。以每一个模块制作文件，确认它们的正确性。
　（9）语言。不出现错别字，不要出现有二义性的说法。特别要注意的是屏幕截图或绘制图形中的文字。
　（10）印刷与包装。检查印刷质量；手册厚度与开本是否合适；包装盒的大小是否合适；有没有零碎易丢失的小部件等等。
38、单元测试主要内容是什么？
单元测试大多数由开发人员来完成，测试人员技术背景较好或者开发系统软件时可能会安排测试人员进行单元测试，大多数进行的单元测试都是开发人员调试程序或者开发组系统联合调试的过程。讨论这个问题主要是扩充一下读者的视野。
单元测试一般包括五个方面的测试：
（1）模块接口测试：模块接口测试是单元测试的基础。只有在数据能正确流入、流出模块的前提下，其他测试才有意义。模块接口测试也是集成测试的重点，这里进行的测试主要是为后面打好基础。测试接口正确与否应该考虑下列因素：
-输入的实际参数与形式参数的个数是否相同；
-输入的实际参数与形式参数的属性是否匹配；
-输入的实际参数与形式参数的量纲是否一致；
-调用其他模块时所给实际参数的个数是否与被调模块的形参个数相同；-调用其他模块时所给实际参数的属性是否与被调模块的形参属性匹配；-调用其他模块时所给实际参数的量纲是否与被调模块的形参量纲一致；-调用预定义函数时所用参数的个数、属性和次序是否正确；-是否存在与当前入口点无关的参数引用；
-是否修改了只读型参数；
-对全程变量的定义各模块是否一致；
-是否把某些约束作为参数传递。
如果模块功能包括外部输入输出，还应该考虑下列因素：
-文件属性是否正确；
-OPEN/CLOSE语句是否正确；
-格式说明与输入输出语句是否匹配；
-缓冲区大小与记录长度是否匹配；
-文件使用前是否已经打开；
-是否处理了文件尾；
-是否处理了输入/输出错误；
-输出信息中是否有文字性错误。
-局部数据结构测试；
-边界条件测试；
-模块中所有独立执行通路测试；
（2）局部数据结构测试：检查局部数据结构是为了保证临时存储在模块内的数据在程序执行过程中完整、正确，局部功能是整个功能运行的基础。重点是一些函数是否正确执行，内部是否运行正确。局部数据结构往往是错误的根源，应仔细设计测试用例，力求发现下面几类错误：
-不合适或不相容的类型说明；
-变量无初值；
-变量初始化或省缺值有错；
-不正确的变量名（拼错或不正确地截断）；
-出现上溢、下溢和地址异常。
（3）边界条件测试：边界条件测试是单元测试中最重要的一项任务。众所周知，软件经常在边界上失效，采用边界值分析技术，针对边界值及其左、右设计测试用例，很有可能发现新的错误。边界条件测试是一项基础测试，也是后面系统测试中的功能测试的重点，边界测试执行的较好，可以大大提高程序健壮性。
（4）模块中所有独立路径测试：在模块中应对每一条独立执行路径进行测试，单元测试的基本任务是保证模块中每条语句至少执行一次。测试目的主要是为了发现因错误计算、不正确的比较和不适当的控制流造成的错误。具体做法就是程序员逐条调试语句。常见的错误包括：
-误解或用错了算符优先级；
-混合类型运算；
-变量初值错；
-精度不够；
-表达式符号错。
比较判断与控制流常常紧密相关，测试时注意下列错误：
-不同数据类型的对象之间进行比较；
-错误地使用逻辑运算符或优先级；
-因计算机表示的局限性，期望理论上相等而实际上不相等的两个量相等；-比较运算或变量出错；
-循环终止条件或不可能出现；
-迭代发散时不能退出；
-错误地修改了循环变量。
模块的各条错误处理通路测试：程序在遇到异常情况时不应该退出，好的程序应能预见各种出错条件，并预设各种出错处理通路。如果用户不按照正常操作，程序就退出或者停止工作，实际上也是一种缺陷，因此单元测试要测试各种错误处理路径。一般这种测试着重检查下列问题：
-输出的出错信息难以理解；
-记录的错误与实际遇到的错误不相符；
-在程序自定义的出错处理段运行之前，系统已介入；-异常处理不当；
-错误陈述中未能提供足够的定位出错信息。
39、如何理解强度测试？
强度测试是为了确定系统在最差工作环境的工作能力,也可能是用于验证在标准工作压力下的各种资源的最下限指标。
它和压力测试的目标是不同的,压力测试是在标准工作环境下,不断增加系统负荷,最终测试出该系统能力达到的最大负荷(稳定和峰值),而强度测试则是在非标准工作环境下,甚至不断人为降低系统工作环境所需要的资源,如网络带宽,系统内存,数据锁等等,以测试系统在资源不足的情况下的工作状态,通过强度测试,可以确定本系统正常工作的最差环境.
强度测试和压力测试的测试指标相近,大多都是与时间相关的指标,如并发量(吞吐量),延迟(最大\最小\平均)以及顺序指标等强度测试需要对系统的结构熟悉,针对系统的特征设计强度测试的方法40、如何理解压力、负载、性能测试测试？
性能测试是一个较大的范围，实际上性能测试本身包含了性能、强度、压力、负载等多方面的测试内容。
压力测试是对服务器的稳定性以及负载能力等方面的测试，是一种很平常的测试。增大访问系统的用户数量、或者几个用户进行大数据量操作都是压力测试。而负载测试是压力相对较大的测试，主要是测试系统在一种或者集中极限条件下的相应能力，是性能测试的重要部分。100个用户对系统进行连续半个小时的访问可以看作压力测试，那么连续访问8个小时就可以认为负载测试，1000个用户连续访问系统1个小时也可以看作是负载测试。
实际上压力测试和负载测试没有明显的区分。测试人员应该站在关注整体性能的高度上来对系统进行测试。

一个测试工程师应具备那些素质和技能?
    一个好的测试工程师，不仅要基础扎实，对自身的性格、责任心都有非常高的要求。具体如下：

(1)掌握基本的测试基础理论
(2)本着找出软件存在的问题的态度进行测试,即客观吧,不要以挑刺形象出现(3)可熟练阅读需求规格说明书等文档
(4)以用户的观点看待问题
(5)有着强烈的质量意识
(6)细心和责任心
(7)良好的有效的沟通方式(与开发人员及客户)
(8)具有以往的测试经验
(9)能够及时准确地判断出高危险区在何处.
    集成测试通常都有那些策略?
    大致说四点即可，当然说全更好。集成测试有十种策略:
(1)大爆炸集成
(2)自顶向下集成
(3)自底向上集成
(4)三明治集成
(5)分层集成
(6)基干集成
(7)基于功能的集成
(8)基于消息的集成
(9)基于风险的集成
(10)基于进度的集成.
    1、什么是兼容性测试？兼容性测试侧重哪些方面？
    兼容测试主要是检查软件在不同的硬件平台、软件平台上是否可以正常的运行，即是通常说的软件的可移植性。
    兼容的类型，如果细分的话，有平台的兼容，网络兼容，数据库兼容，以及数据格式的兼容。
    兼容测试的重点是，对兼容环境的分析。通常，是在运行软件的环境不是很确定的情况下，才需要做兼容。根据软件运行的需要，或者根据需求文档，一般都能够得出用户会在什么环境下使用该软件，把这些环境整理成表单，就得出做兼容测试的兼容环境了。
    兼容和配置测试的区别在于，做配置测试通常不是Clean OS下做测试，而兼容测试多是在Clean OS的环境下做的。
3、测试的策略有哪些？
黑盒/白盒，静态/动态，手工/自动，冒烟测试，回归测试，公测（Beta测试的策略）4、正交表测试用例设计方法的特点是什么？
用最少的实验覆盖最多的操作，测试用例设计很少，效率高，但是很复杂；对于基本的验证功能，以及二次集成引起的缺陷，一般都能找出来；但是更深的缺陷，更复杂的缺陷，还是无能为力的；具体的环境下，正交表一般都很难做的。大多数，只在系统测试的时候使用此方法。
5、描述使用bugzilla缺陷管理工具对软件缺陷（BUG）跟踪的管理的流程？
就是Bugzilla的状态转换图。
6、你觉得bugzilla在使用的过程中，有什么问题？
界面不稳定；
根据需要配置它的不同的部分，过程很烦琐。
流程控制上，安全性不好界定，很容易对他人的Bug进行误操作；没有综合的评分指标，不好确认修复的优先级别。
7、描述测试用例设计的完整过程？
需求分析 + 需求变更的维护工作；
根据需求 得出测试需求；
设计测试方案，评审测试方案；
方案评审通过后，设计测试用例，再对测试用例进行评审；8、单元测试的策略有哪些？
逻辑覆盖、循环覆盖、同行评审、桌前检查、代码走查、代码评审、景泰数据流分析9、LoadRunner分哪三部分？
脚本生成器；
场景控制器；
结果分析器；
10、LoadRunner进行测试的流程?
1、 测试测试
2、 创建虚拟用户脚本
3、 创建运行场景
4、 运行测试脚本
5、 监视场景
6、 分析测试的结果
以上，最好是结合一个案例，根据以上流程来介绍。
什么是并发？在lordrunner中，如何进行并发的测试？集合点失败了会怎么样？
在同一时间点，支持多个不同的操作。
LoadRunner中提供IP伪装，集合点，配合虚拟用户的设计，以及在多台电脑上设置，可以比较好的模拟真实的并发。
集合点，即是多个用户在某个时刻，某个特定的环境下同时进行虚拟用户的操作的。集合点失败，则集合点的才操作就会取消，测试就不能进行。
12、使用QTP做功能测试，录制脚本的时候，要验证多个用户的登录情况/查询情况，如何操作？
分析用户登录的基本情况，得出一组数据，通过性测试/失败性测试的都有（根据TC来设计这些数据），然后录制登录的脚本，将关键的数据参数化，修改脚本，对代码进行加强，调试脚本。
13、QTP中的Action有什么作用？有几种？
Action的作用
n       用Action可以对步骤集进行分组
n       步骤重组，然后被整体调用
n       拥有自己的sheet
n       组合有相同需求的步骤，整体操作
n       具有独立的对象仓库
Action的种类
n       可复用Action
n       不可复用Action
n       外部Action
14、TestDirector有些什么功能，如何对软件测试过程进行管理？
需求管理
n       定义测试范围
n       定义需求树
n       描述需求树的功能点
测试计划
n       定义测试目标和测试策略。
n       分解应用程序，建立测试计划树。
n       确定每个功能点的测试方法。
n       将每个功能点连接到需求上，使测试计划覆盖全部的测试需求。
n       描述手工测试的测试步骤
n       指明需要进行自动测试的功能点
测试执行
n       定义测试集合。
n       为每个测试人员制定测试任务和测试日程安排。
n       运行自动测试。
缺陷跟踪
n       记录缺陷
n       查看新增缺陷，并确定哪些是需要修正的
n       相关技术人员修改缺陷
n       回归测试
n       分析缺陷统计图表，分析应用程序的开发质量。
15、你所熟悉的软件测试类型都有哪些？请试着分别比较这些不同的测试类型的区别与联系（如功能测试、性能测试……）？
Compatibility Testing（兼容性测试），也称“Configuration testing（配置测试）”，测试软件是否和系统的其它与之交互的元素之间兼容，如：浏览器、操作系统、硬件等。验证测试对象在不同的软件和硬件配置中的运行情况。
Functional testing (功能测试)，也称为behavioral testing（行为测试），根据产品特征、操作描述和用户方案，测试一个产品的特性和可操作行为以确定它们满足设计需求。本地化软件的功能测试，用于验证应用程序或网站对目标用户能正确工作。使用适当的平台、浏览器和测试脚本，以保证目标用户的体验将足够好，就像应用程序是专门为该市场开发的一样。
Performance testing（性能测试），评价一个产品或组件与性能需求是否符合的测试。包括负载测试、强度测试、数据库容量测试、基准测试等类型。
16、软件缺陷（或者叫Bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（Bug）记录？
5C标准
17、Beta测试与Alpha测试有什么区别？
Beta testing(β测试),测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场Alpha testing (α测试),是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试18、软件的评审一般由哪些人参加？其目的是什么？
在正式的会议上将软件项目的成果（包括各阶段的文档、产生的代码等）提交给用户、客户或有关部门人员对软件产品进行评审和批准。其目的是找出可能影响软件产品质量、开发过程、维护工作的适用性和环境方面的设计缺陷，并采取补救措施，以及找出在性能、安全性和经济方面的可能的改进。
人员：用户、客户或有关部门开发人员，测试人员，需求分析师都可以，就看处于评审那个阶段19、测试活动中，如果发现需求文档不完善或者不准确，怎么处理？
测试需求分析发现需求文档不完善或者不准确，应该立即和相关人员进行协调交流。
20、阶段评审与项目评审有什么区别？
阶段评审对项目各阶段评审：对阶段成果和工作
项目评审对项目总体评审：对工作和产品
21、阐述工作版本的定义？
构造号： BUILD
22、什么是桩模块？什么是驱动模块？
桩模块：被测模块调用模块
驱动模块调用被测模块
23、什么是扇入？什么是扇出？
扇入：被调次数，扇出：调其它模块数目
24、你认为做好测试计划工作的关键是什么？
软件测试计划就是在软件测试工作正式实施之前明确测试的对象，并且通过对资源、时间、风险、测试范围和预算等方面的综合分析和规划，保证有效的实施软件测试；做好测试计划工作的关键：目的，管理，规范
1. 明确测试的目标，增强测试计划的实用性
编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷，因此软件测试计划的价值取决于它对帮助管理测试项目，并且找出软件潜在的缺陷。因此，软件测试计划中的测试范围必须高度覆盖功能需求，测试方法必须切实可行，测试工具并且具有较高的实用性，便于使用，生成的测试结果直观、准确2．坚持“5W”规则，明确内容与过程
“5W”规则指的是“What（做什么）”、“Why（为什么做）”、“When（何时做）”、“Where（在哪里）”、“How（如何做）”。利用“5W”规则创建软件测试计划，可以帮助测试团队理解测试的目的（Why），明确测试的范围和内容（What），确定测试的开始和结束日期（When），指出测试的方法和工具（How），给出测试文档和软件的存放位置（Where）。
3．采用评审和更新机制，保证测试计划满足实际需求测试计划写作完成后，如果没有经过评审，直接发送给测试团队，测试计划内容的可能不准确或遗漏测试内容，或者软件需求变更引起测试范围的增减，而测试计划的内容没有及时更新，误导测试执行人员。
4. 分别创建测试计划与测试详细规格、测试用例
应把详细的测试技术指标包含到独立创建的测试详细规格文档，把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。
25、你认为做好测试用例工作的关键是什么？
需求和设计文档的理解程度，对系统的熟悉程度
26、简述一下缺陷的生命周期？
提交->确认->分配->修复->验证->关闭
27、软件的安全性应从哪几个方面去测试？
(1)用户认证机制：如数据证书、智能卡、双重认证、安全电子交易协议(2)加密机制
(3)安全防护策略：如安全日志、入侵检测、隔离防护、漏洞扫描(4)数据备份与恢复手段：存储设备、存储优化、存储保护、存储管理(5)防病毒系统
28、软件配置管理工作开展的情况和认识？
软件配置管理贯穿于软件开发、测试活动的始终，覆盖了开发、测试活动的各个环节，它的重要作用之一就是要全面的管理保存各个配置项，监控各配置项的状态，并向项目经理及相关的人员报告，从而实现对软件过程的控制。
软件测试配置管理包括4个最基本的活动：
配置项标识
配置项控制
配置项状态报告
配置审计
       软件配置管理通常借助工具来辅助，主要有MS SourceSafe、Rational ClearCase等29、你觉得软件测试通过的标准应该是什么样的？
    缺陷密度值达到客户的要求
30、引入测试管理的含义？
风险分析，进度控制、角色分配、质量控制
31、一套完整的测试应该由哪些阶段组成？
参考答案：测试计划、测试设计与开发、测试实施、测试评审与测试结论32、单元测试的主要内容？
　模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试33、集成测试也叫组装测试或者联合测试，请简述集成测试的主要内容？
（1）在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；　（2）一个模块的功能是否会对另一个模块的功能产生不利的影响；　（3）各个子功能组合起来，能否达到预期要求的父功能；　（4）全局数据结构是否有问题；
　（5）单个模块的误差累积起来，是否会放大，从而达到不能接受的程度。
34、简述集成测试与系统测试关系？
　（1）集成测试的主要依据概要设计说明书，系统测试的主要依据是需求设计说明书；　（2）集成测试是系统模块的测试，系统测试是对整个系统的测试，包括相关的软硬件平台、网络以及相关外设的测试。
35、软件测试的文档测试应当贯穿于软件生命周期的全过程，其中用户文档是文档测试的重点。那么软件系统的用户文档包括哪些？
　　用户手册
　　安装和设置指导
　　联机帮助
　　指南、向导
　　样例、示例和模板
　　授权/注册登记表
最终用户许可协议
36、软件系统中除用户文档之外，文档测试还应该关注哪些文档？
开发文档
软件需求说明书
　　　　数据库设计说明书
　　　　概要设计说明书
　　　　详细设计说明书
　　　　可行性研究报告
管理文档
　　　　项目开发计划
　　　　测试计划
　　　　测试报告
　　　　开发进度月报
　　　　开发总结报告
37、简述软件系统中用户文档的测试要点？
　（1）读者群。文档面向的读者定位要明确。对于初级用户、中级用户以及高级用户应该有不同的定位　（2）术语。文档中用到的术语要适用与定位的读者群，用法一致，标准定义与业界规范相吻合。
　（3）正确性。测试中需检查所有信息是否真实正确，查找由于过期产品说明书和销售人员夸大事实而导致的错误。检查所有的目录、索引和章节引用是否已更新，尝试链接是否准确，产品支持电话、地址和邮政编码是否正确。
　（4）完整性。对照软件界面检查是否有重要的分支没有描述到，甚至是否有整个大模块没有描述到。
　（5）一致性。按照文档描述的操作执行后，检查软件返回的结果是否与文档描述的相同。
　（6）易用性。对关键步骤以粗体或背景色给用户以提示，合理的页面布局、适量的图表都可以给用户更高的易用性。需要注意的是文档要有助于用户排除错误。不但描述正确操作，也要描述错误处理办法。文档对于用户看到的错误信息应当有更详细的文档解释。
　（7）图表与界面截图。检查所有图表与界面截图是否与发行版本相同。
　（8）样例与示例。像用户一样载入和使用样例。如果是一段程序，就输入数据并执行它。以每一个模块制作文件，确认它们的正确性。
　（9）语言。不出现错别字，不要出现有二义性的说法。特别要注意的是屏幕截图或绘制图形中的文字。
　（10）印刷与包装。检查印刷质量；手册厚度与开本是否合适；包装盒的大小是否合适；有没有零碎易丢失的小部件等等。
38、单元测试主要内容是什么？
单元测试大多数由开发人员来完成，测试人员技术背景较好或者开发系统软件时可能会安排测试人员进行单元测试，大多数进行的单元测试都是开发人员调试程序或者开发组系统联合调试的过程。讨论这个问题主要是扩充一下读者的视野。
单元测试一般包括五个方面的测试：
（1）模块接口测试：模块接口测试是单元测试的基础。只有在数据能正确流入、流出模块的前提下，其他测试才有意义。模块接口测试也是集成测试的重点，这里进行的测试主要是为后面打好基础。测试接口正确与否应该考虑下列因素：
-输入的实际参数与形式参数的个数是否相同；
-输入的实际参数与形式参数的属性是否匹配；
-输入的实际参数与形式参数的量纲是否一致；
-调用其他模块时所给实际参数的个数是否与被调模块的形参个数相同；-调用其他模块时所给实际参数的属性是否与被调模块的形参属性匹配；-调用其他模块时所给实际参数的量纲是否与被调模块的形参量纲一致；-调用预定义函数时所用参数的个数、属性和次序是否正确；-是否存在与当前入口点无关的参数引用；
-是否修改了只读型参数；
-对全程变量的定义各模块是否一致；
-是否把某些约束作为参数传递。
如果模块功能包括外部输入输出，还应该考虑下列因素：
-文件属性是否正确；
-OPEN/CLOSE语句是否正确；
-格式说明与输入输出语句是否匹配；
-缓冲区大小与记录长度是否匹配；
-文件使用前是否已经打开；
-是否处理了文件尾；
-是否处理了输入/输出错误；
-输出信息中是否有文字性错误。
-局部数据结构测试；
-边界条件测试；
-模块中所有独立执行通路测试；
（2）局部数据结构测试：检查局部数据结构是为了保证临时存储在模块内的数据在程序执行过程中完整、正确，局部功能是整个功能运行的基础。重点是一些函数是否正确执行，内部是否运行正确。局部数据结构往往是错误的根源，应仔细设计测试用例，力求发现下面几类错误：
-不合适或不相容的类型说明；
-变量无初值；
-变量初始化或省缺值有错；
-不正确的变量名（拼错或不正确地截断）；
-出现上溢、下溢和地址异常。
（3）边界条件测试：边界条件测试是单元测试中最重要的一项任务。众所周知，软件经常在边界上失效，采用边界值分析技术，针对边界值及其左、右设计测试用例，很有可能发现新的错误。边界条件测试是一项基础测试，也是后面系统测试中的功能测试的重点，边界测试执行的较好，可以大大提高程序健壮性。
（4）模块中所有独立路径测试：在模块中应对每一条独立执行路径进行测试，单元测试的基本任务是保证模块中每条语句至少执行一次。测试目的主要是为了发现因错误计算、不正确的比较和不适当的控制流造成的错误。具体做法就是程序员逐条调试语句。常见的错误包括：
-误解或用错了算符优先级；
-混合类型运算；
-变量初值错；
-精度不够；
-表达式符号错。
比较判断与控制流常常紧密相关，测试时注意下列错误：
-不同数据类型的对象之间进行比较；
-错误地使用逻辑运算符或优先级；
-因计算机表示的局限性，期望理论上相等而实际上不相等的两个量相等；-比较运算或变量出错；
-循环终止条件或不可能出现；
-迭代发散时不能退出；
-错误地修改了循环变量。
模块的各条错误处理通路测试：程序在遇到异常情况时不应该退出，好的程序应能预见各种出错条件，并预设各种出错处理通路。如果用户不按照正常操作，程序就退出或者停止工作，实际上也是一种缺陷，因此单元测试要测试各种错误处理路径。一般这种测试着重检查下列问题：
-输出的出错信息难以理解；
-记录的错误与实际遇到的错误不相符；
-在程序自定义的出错处理段运行之前，系统已介入；-异常处理不当；
-错误陈述中未能提供足够的定位出错信息。
39、如何理解强度测试？
强度测试是为了确定系统在最差工作环境的工作能力,也可能是用于验证在标准工作压力下的各种资源的最下限指标。
它和压力测试的目标是不同的,压力测试是在标准工作环境下,不断增加系统负荷,最终测试出该系统能力达到的最大负荷(稳定和峰值),而强度测试则是在非标准工作环境下,甚至不断人为降低系统工作环境所需要的资源,如网络带宽,系统内存,数据锁等等,以测试系统在资源不足的情况下的工作状态,通过强度测试,可以确定本系统正常工作的最差环境.
强度测试和压力测试的测试指标相近,大多都是与时间相关的指标,如并发量(吞吐量),延迟(最大\最小\平均)以及顺序指标等强度测试需要对系统的结构熟悉,针对系统的特征设计强度测试的方法40、如何理解压力、负载、性能测试测试？
性能测试是一个较大的范围，实际上性能测试本身包含了性能、强度、压力、负载等多方面的测试内容。
压力测试是对服务器的稳定性以及负载能力等方面的测试，是一种很平常的测试。增大访问系统的用户数量、或者几个用户进行大数据量操作都是压力测试。而负载测试是压力相对较大的测试，主要是测试系统在一种或者集中极限条件下的相应能力，是性能测试的重要部分。100个用户对系统进行连续半个小时的访问可以看作压力测试，那么连续访问8个小时就可以认为负载测试，1000个用户连续访问系统1个小时也可以看作是负载测试。
实际上压力测试和负载测试没有明显的区分。测试人员应该站在关注整体性能的高度上来对系统进行测试。