软件测试员
-
2023年2月17日发(作者：)软件测试⾯试题及答案【史上最全】
以下是软件测试相关的⾯试题及答案，欢迎⼤家参考!
1、你的测试职业发展是什么?
测试经验越多，测试能⼒越⾼。所以我的职业发展是需要时间积累的，⼀步步向着⾼级测试⼯程师奔去。⽽且我也有初步的职业规划，前
3年积累测试经验，按如何做好测试⼯程师的要点去要求⾃⼰，不断更新⾃⼰改正⾃⼰，做好测试任务。
2、你认为测试⼈员需要具备哪些素质
做测试应该要有⼀定的协调能⼒，因为测试⼈员经常要与开发接触处理⼀些问题，如果处理不好的话会引起⼀些冲突，这样的话⼯作上就
会不好做。还有测试⼈员要有⼀定的耐⼼，有的时候做测试很枯燥乏味。除了耐⼼，测试⼈员不能放过每⼀个可能的错误。
3、你为什么能够做测试这⼀⾏
虽然我的测试技术还不是很成熟，但是我觉得我还是可以胜任软件测试这个⼯作的，因为做软件测试不仅是要求技术好，还有有⼀定的沟
通能⼒，耐⼼、细⼼等外在因素。综合起来看我认为我是胜任这个⼯作的。
4、测试的⽬的是什么?
测试的⽬的是找出软件产品中的错误，是软件尽可能的符合⽤户的要求。当然软件测试是不可能找出全部错误的。
5、测试分为哪⼏个阶段?
⼀般来说分为5个阶段：单元测试、集成测试、确认测试、系统测试、验收测试
6、单元测试的测试对象、⽬的、测试依据、测试⽅法?
测试对象是模块内部的程序错误，⽬的是消除局部模块逻辑和功能上的错误和缺陷。测试依据是模块的详细设计，测试⽅法是采⽤⽩盒测
试。
7、怎样看待加班问题
加班的话我没有太多意见，但是我还是觉得如果能够合理安排时间的话，不会有太多时候加班的。
8、结合你以前的学习和⼯作经验，你认为如何做好测试。
根据我以前的⼯作和学习经验，我认为做好⼯作⾸先要有⼀个良好的沟通，只有沟通⽆障碍了，才会有好的协作，才会有更好的效率，再
⼀个就是技术⼀定要过关，做测试要有⾜够的耐⼼，和⼀个良好的⼯作习惯，不懂的就要问，实时与同事沟通这样的话才能做好测试⼯作。
9、你为什么选择软件测试⾏业
因为之前了解软件测试这个⾏业，觉得他的发展前景很好。
10、根据你以前的⼯作或学习经验描述⼀下软件开发、测试过程，由哪些⾓⾊负责，你做什么
要有架构师、开发经理、测试经理、程序员、测试员。我在⾥⾯主要是负责所分到的模块执⾏测试⽤例。
11、根据你的经验说说你对软件测试/质量保证的理解
软件质量保证与测试是根据软件开发阶段的规格说明和程序的内部结构⽽精⼼设计的⼀批测试⽤例(即输⼊数据和预期的输出结果)，并根
据这些测试⽤例去运⾏程序，以发现错误的过程。它是对应⽤程序的各个⽅⾯进⾏测试以检查其功能、语⾔有效性及其外观排布。
12、软件测试的流程是什么?
需求调查：全⾯了解系统概况、应⽤领域、软件开发周期、软件开发环境、开发组织、时间安排、功能需求、性能需求、质量需求及测试
要求等。根据系统概况进⾏项⽬所需的⼈员、时间和⼯作量估计以及项⽬报价。
制定初步的项⽬计划。
测试准备：组织测试团队、培训、建⽴测试和管理环境等。
测试设计：按照测试要求进⾏每个测试项的测试设计，包括测试⽤例的设计和测试脚本的开发等。
测试实施：按照测试计划实施测试。
测试评估：根据测试的结果，出具测试评估报告。
13、你对SQA的职责和⼯作活动(如软件度量)的理解?
SQA就是独⽴于软件开发的项⽬组，通过对软件开发过程的监控，来保证软件的开发流程按照指定的CMM规程(如果有相应的CMM规程),
对于不符合项及时提出建议和改进⽅案，必要时可以向⾼层经理汇报以求问题的解决。通过这样的途径来预防缺陷的引⼊，从⽽减少后期软
件的维护成本。SQA主要的⼯作活动包括制定SQA⼯作计划，参与阶段产物的评审，进⾏过程质量、功能配置及物理配置的审计等;对项⽬
开发过程中产⽣的数据进⾏度量等等。
14、说说你对软件配置管理的理解
项⽬在开发过程中要⽤相应的配置管理⼯具对配置项(包括各个阶段的产物)进⾏变更控制，配置管理的使⽤取决于项⽬规模和复杂性及风
险的⽔平。软件的规模越⼤，配置管理就越显得重要。还有在配置管理中，有⼀个很重要的概念，那就是基线，是在⼀定阶段各个配置项的
组合，⼀个基线就提供了⼀个正式的标准，随后的⼯作便基于此标准，并只有经过授权后才能变更这个标准。配置管理⼯具主要有
CC，VSS,CVS,SVN等，我只⽤过SVN，对其他的⼯具不是很熟悉。
15、怎样写测试计划和测试⽤例
简单点，测试计划⾥应有详细的测试策略和测试⽅法，合理详尽的资源安排等，⾄于测试⽤例，那是依赖于需求(包括功能与⾮功能需求)
是否细化到功能点，是否可测试等。
16、说说主流的软件⼯程思想(如CMM、CMMI、RUP,XP,PSP,TSP等)的⼤致情况及对他们的理解
CMM:SWCapabilityMaturityModel软件能⼒成熟度模型，其作⽤是软件过程的改进、评估及软件能⼒的评鉴。
CMMI:CapabilityMaturityModelIntegration能⼒成熟度模型集成CMMI融⼊了⼤部分最新的软件管理实践，同时弥补了SW-CMM模型中的
缺陷。
RUP:rationalunifiedprocess是软件⼯程话过程。
XP:extremeprogram，即极限编程的意思，适⽤于⼩型团队的软件开发，像上⾯第三个问题就可以结合原型法采⽤这样的开发流程。要明
⽩测试对于xp开发的重要性，强调测试(重点是单元测试)先⾏的理念。编程可以明显提⾼代码的质量，持续集成对于快速定位问题有好处。
PSP，TSP分别是个体软件过程和群体软件过程。⼤家都知道，CMM只是告诉你做什么但并没有告诉你如何做，所以PSP/TSP就是告诉
你企业在实施CMM的过程中如何做，PSP强调建⽴个⼈技能(如何制定计划、控制质量及如何与其他⼈相互协作等等)。⽽TSP着重于⽣产并
交付⾼质量的软件产品(如何有效的规划和管理所⾯临的项⽬开发任务等等)。总之，实施CMM，永远不能真正做到能⼒成熟度的提升，只有
将实施CMM与实施PSP和TSP有机结合起来，才能发挥最⼤的效⼒。因此，软件过程框架应该是CMM/PSP/TSP的有机集成。
17、你是怎样保证软件质量的，也就是说你觉得怎样才能最⼤限度的保证软件的质量?
测试并不能够最⼤限度的保证软件的质量，软件的⾼质量是开发和设计出来的，⽽不是测试出来的，它不仅要通过对软件开发流程的监
控，使得软件开发的各个阶段都要按照指定的规程进⾏，通过对各个阶段产物的评审，QA对流程的监控，对功能及配置的审计来达到开发
的最优化。当然测试也是保证软件质量的⼀个重要⽅式，是软件质量保证⼯程的⼀个重要组成部分。
18、基于⽬前中国的国情，⼤多数公司的项⽬进度紧张、⼈员较少、需求⽂档根本没有或者很不规范，你认为在这种情况下怎样保证软件
的质量?(⼤多数公司最想知道的就是在这种困难⾯前你该怎么保证软件的质量，因为这些公司⼀般就是这种情况--既不想投⼊过多⼜想保证
质量)
出现以上的情况，如果仅仅想通过测试来提⾼软件质量，那⼏乎是不可能的，原因是没有⾜够的时间让你去测试，少⽽不规范的⽂档导致
测试需求⽆法细化到⾜够且有针对⾏的测试。所以，作为公司质量保证的因该和项⽬经理确定符合项⽬本⾝是和的软件⽣命周期模型(⽐如
RUP的建材，原型法)，明确项⽬的开发流程并督促项⽬组按照此流程开展⼯作，所有项⽬组成员(项⽬经理更加重要)都要制定出合理的⼯作
计划，加强代码的单元测试，在客户既定的产品交付⽇期范围内，进⾏产品的持续集成等等，如果时间允许可以再配合客户进⾏必要的系统
功能测试。
19、⼀个测试⼯程师应该具备哪些素质和技能?
1-掌握基本的测试基础理论
2-本着找出软件存在的问题的态度进⾏测试，不要以挑刺的形象出现
3-可熟练阅读需求规格说明书等⽂档
4-以⽤户的观点看问题
5-有强烈的质量意识
6-细⼼和责任⼼
7-良好的有效的沟通⽅式(与开发⼈员及客户)
8-具有以往的测试经验能够及时准确的判断出⾼危险区在何处
20、做好软件测试的⼀些关键点
1-测试⼈员必须经过测试基础知识和理论的相关培训
2-测试⼈员必须熟悉系统功能和业务
3-测试要有计划，⽽且测试⽅案要和整个项⽬计划协调好
4-必须实现编写测试⽤例，测试执⾏阶段必须根据测试⽤例进⾏
5-易⽤性，功能，分⽀，边界，性能等功能⾏和⾮功能性需求都要进⾏测试
6-对于复杂的流程⼀定要进⾏流程分⽀，组合条件分析，再进⾏等价类划分准备相关测试数据
7-测试设计的⼀个重要内容是要准备好具体的测试数据，清楚这个测试数据是测试那个场景或分⽀的。
8-个⼈任务平均每三个测试⽤例⾄少应该发现⼀个BUG，否则只能说明测试⽤例质量不好
9-除了每天构建的重复测试可以考虑测试⾃动化外，其他暂时都不要考虑去⾃动话
21、软件测试员⾃⾝素质培养
1-⾸先，应对软件测试感兴趣和对⾃⼰有⾃信，如果具备了这两点，那么在开发过程中不管遇到什么样的困难，相信⼀定能克服
2-善于怀疑，实际上没有绝对正确的，总有错误的地⽅，具有叛逆⼼理，别⼈认为不可能发⽣的事情，我却认为可能发⽣，别⼈认为是对
的，我却认为不是对的。
3-打破沙锅问到底的精神，对于只出现过⼀次的BUG⼀定要找出原因，不解决誓不罢休。
4-保持⼀个良好的⼼情，否则可能⽆法把测试做好。不要把⽣活中的不愉快的情绪带到⼯作中来。
5-做测试时要细⼼，不是所有的BUG都能很容易找出，⼀定要细⼼才能找到这些BUG。
6-灵活⼀些，聪明⼀点，多造⼀些容易产⽣BUG的例⼦。
7-在有条件的情况下，多和客户沟通，他们⾝上有你所需要的。
8-设⾝处地为客户着想，从他们的⾓度去测试系统。
9-不要让程序员，以“这种情况不可能发⽣”这句话说服你，相反，你应该去说服他，告诉他在客户⼼理，并不是这样的
10-考虑问题要全⾯，结合客户的需求，业务流程和系统的架构等多⽅⾯考虑问题。
11-提出问题不要复杂化，这点和前⾯⽭盾，如果你是⼀个新⼿，暂时不要管这点，因为最终将有你的⼩组成员讨论解决。
12-追求完美，对于新测试员来说，努⼒追求完美，这对你很好，尽管有些事情⽆法做到，但你应该尝试。
13-幽默感，能和开发⼩组很好的沟通是关键，试着给你的开发⼩组找⼀个BUG杀⼿，或对他们说“我简直不敢相信，你写的程序居然到现
在没有找到BUG”。
22、为什要在⼀个团队中开展测试⼯作?
因为没有经过测试的软件很难在发布之前知道该软件的质量，就好⽐ISO质量认证⼀样，测试同样也需要质量认证，这个时候就需要在团
队中开展软件测试的⼯作。在测试的过程中发现软件中存在的问题，及时让开发⼈员得知并修改问题，在即将发布时，从测试报告中得出软
件的质量情况。
23、你所熟悉的软件测试类型有哪些?
测试类型有：功能测试、性能测试、界⾯测试
功能测试在测试⼯作中占有⽐例最⼤，功能测试也叫⿊盒测试。
性能测试是通过⾃动化的测试⼯具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进⾏测试。负载测试和压⼒测试都属于
性能测试，两者可以结合进⾏。
界⾯测试，界⾯是软件与⽤户交互的最直接的层，界⾯的好坏决定⽤户对软件的第⼀印象。
区别在于，功能测试关注产品的所有功能，要考虑到每个细节功能，每个可能存在的功能问题。性能测试主要关注产品整体的多⽤户并发
下的稳定性和健壮性。界⾯测试则关注与⽤户体验相关内容，⽤户使⽤该产品的时候是否已⽤，是否易懂，是否规范(⽤户⽆意输⼊⽆效的
数据，当然考虑到体验性，不能太粗鲁的弹出警告)。做某个性能测试的时候，⾸先它可能是个功能点，⾸先要保证她的功能是没有问题
的，然后再考虑性能的问题。
24、你认为做好测试⽤例设计⼯作的关键是什么
⽩盒测试⽤例设计的关键是以较少的⽤例覆盖尽可能多的内部程序逻辑结构。⿊盒测试⽤例设计的关键同样也是以较少的⽤例覆盖模块输
出和输⼊接⼝。不可能做到完全测试，以最少的⽤例在合理的时间内发现最多的问题。软件的⿊盒测试意味着测试要在软件的接⼝处进⾏，
这种⽅法是把测试对象看作是⼀个⿊盒⼦，测试⼈员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序
的功能是否符合它的功能说明。因此⿊盒测试⼜叫功能测试或者数据驱动测试。⿊盒测试主要是为了发现以下⼏类错误：、
1-是否有不正确或遗漏的功能
2-在接⼝上，输⼊是否能正确的接受?能否输出正确的结果。
3-是否有数据结构错误或外部信息(例如数据⽂件)访问错误
4-性能上是否能够满⾜要求
5-是否有初始化或终⽌性错误
软件的⽩盒测试是对软件的过程性细节做细致的检查。这种⽅法是把测试对象看作⼀个打开的盒⼦，它允许测试⼈员利⽤程序内部的逻辑
结构和有关信息，设计或者选择测试⽤例，对程序所有逻辑路径进⾏测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态⼀
直。因此⽩盒测试⼜称为结合测试或逻辑驱动测试。⽩盒测试主要是想对程序模块进⾏如下检查：
1-对程序模块的所有独⽴的执⾏路径⾄少测试⼀遍。
2-对所有的逻辑判定，取“真”与取“假”的两种情况都能⾄少测⼀遍。
3-在循环的边界和运⾏的界限内执⾏循环体。
4-测试内部数据结构的有效性，等等。
25、请详细介绍⼀下各种测试类型的含义
1-单元测试(模块测试)是开发者编写的⼀⼩段代码，⽤于检验被测试代码的⼀个很⼩的、很明确的功能是否正确。通常⽽⾔，⼀个单元测
试是⽤于判断某个特定条件(或者场景)下某个特定函数的⾏为。单元测试是由程序员⾃⼰来完成，最终受益的也是程序员⾃⼰。可以这么
说，程序员有责任编写功能代码，同时也就有责任为⾃⼰的代码编写单元测试。执⾏单元测试，就是为了证明这段代码的⾏为和我们期望的
⼀致。
2-集成测试(也叫组装测试、联合测试)是单元测试的逻辑扩展。它最简单的形式是：两个已经经过测试的单元组合成⼀个组件，并且测试
它们之间的接⼝。从这⼀层上讲，组件是指多个单元的集成聚合。在现实⽅案中，许多单元组合成组件，⽽这些组件⼜聚合成程序的更⼤部
分。⽅法是测试⽚段的组合，并最终扩展进程，将您的模块与其他组的模块⼀起测试。最后，将构成进程的所有模块⼀起测试。
3-系统测试是将经过测试的⼦系统装配成⼀个完整系统来测试。它是检验系统是否确实能提供系统⽅案说明书中制定功能的有效⽅法。(常
见的联调测试)。系统测试的⽬的是对最终软件系统进⾏全⾯的测试，确保最终软件系统满⾜产品需求⽽遵循系统设计。
4-验收测试是部署软件之前的最后⼀个测试操作。验收测试的⽬的是确保软件准备就绪，并且可以让⽤户将其执⾏软件的既定功能和任
务。验收测试是向未来的⽤户表明系统能够像预订要求那样⼯作。经集成测试后，已经按照设计把所有的模块组装成⼀个完整的软件系统，
接⼝错误也已经基本排除了，接着就应该进⼀步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能如同⽤户所合理期待的那
样。
26、测试计划⼯作的⽬的是什么?测试计划⼯作的内容都包括什么?其中哪些是最重要的?
软件测试计划是知道测试过程的纲领性⽂件，包含了产品概述、测试策略、测试⽅法、测试区域、测试配置、测试周期、测试资源、测试
交流、风险分析等内容。借助软件测试计划，参与测试的项⽬成员，尤其是测试管理⼈员，可以明确测试任务和测试⽅法，保持测试实施过
程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。
测试计划和测试详细规格、测试⽤例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、⽅法和资源配置，⽽测试详
细规格、测试⽤例是完成测试任务的具体战术。所以其中最重要的是测试策略和测试⽅法(最好能先评审)。
27、您认为做好测试计划⼯作的关键是什么?
1-明确测试的⽬标，增强测试计划的实⽤性
编写软件测试计划的重要⽬的就是使测试过程能够发现更多的软件缺陷，因此软件测试计划的价值取决于它对帮助管理测试项⽬，并且找
出软件潜在的缺陷。因此，软件测试计划中的测试范围必须⾼度覆盖功能需求，测试⽅法必须切实可⾏，测试⼯具并且具有较⾼的实⽤性，
便于使⽤，⽣成的测试结果准确
2-坚持“5W”规则，明确内容与过程
“5W”规则指的是“WHAT(做什么)”、“WHY(为什么做)”、\"WHEN(何时做)\"、\"WHERE(在哪⾥)\"、\"HOW(如何做)\"。利⽤“5W\"规则创建软件
测试计划，可以帮助测试团队理解测试的⽬的(WHY)，明确测试的范围和内容(WHAT)，确定测试的开始和结束⽇期(WHEN)，指出测试的
⽅法和⼯具(HOW)，给出测试⽂档和软件存放的位置(WHERE)。
3-采⽤评审和更新机制，保证测试计划满⾜实际需求
测试计划完成后，如果没有经过评审，直接发送给测试团队，测试计划内容的可能不准确或遗漏测试内容，或者软件需求变更引起测试范
围的增减，⽽测试计划的内容没有及时更新，误导测试执⾏⼈员。
4-分别创建测试计划与测试详细规格、测试⽤例
应把详细的测试技术指标包含到独⽴创建的测试详细规格⽂档，把⽤于指导测试⼩组执⾏过程的测试⽤例放到独⽴创建的测试⽤例⽂档或
测试⽤例管理数据库中。测试计划和测试详细规格、测试⽤例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、⽅法
和资源配置，⽽测试详细规格、测试⽤例是完成测试任务的具体战术。
28、当开发⼈员说不是BUG时，你如何应付?
开发⼈员说不是BUG，有2种情况，⼀是需求没有确定，所以我可以这么做，这个时候可以找来产品经理进⾏确认，需不需要改动。3⽅
商量确定好后再看要不要改。⼆是这种情况不可能发⽣，所以不需要修改，这个时候，我可以先尽可能的说出是BUG的⼀句是什么?如果被
⽤户发现或出了问题，会有什么不良结果?程序员可能会给你很多理由，你可以对他的解释进⾏反驳。如果还是不⾏，那我可以给这个问题
提出来，跟开发经理和测试经理进⾏确认，如果要修改就改，如果不要修改就不改。其实有些真的不是BUG，我也只是建议的⽅式写进测试
⽂档中，如果开发⼈员不修改也没有⼤问题。如果不是BUG的话，⼀定要坚持⾃⼰的⽴场，让问题得到最后的确认。
29、你⾃认为测试的优势在哪⾥?
优势在于我对测试坚定不移的信⼼和热情，虽然经验还不⾜，但测试需要的基本技能我有信⼼在⼯作中得以发挥。
30、什么是系统瓶颈?
瓶颈主要是指整个软硬件构成的软件系统某⼀⽅⾯或者⼏个⽅⾯能⼒不能满⾜⽤户的特定业务要求，“特定”是指瓶颈会在某些条件下会出
现，因为毕竟⼤多数系统在投⼊前。
严格的从技术⾓度讲，所有的系统都会有瓶颈，因为⼤多数系统的资源配置不是协调的，例如CPU使⽤率刚好达到100%时，内存也正好
耗尽的系统不是很多见。因此我们讨论系统瓶颈要从应⽤的⾓度讨论：关键是看系统能否满⾜⽤户需求。在⽤户极限使⽤系统的情况下，系
统的响应仍然正常，我们可以认为改系统没有瓶颈或者瓶颈不会影响⽤户⼯作。
因此我们测试系统瓶颈主要是实现下⾯两个⽬的：
-发现“表⾯”的瓶颈。主要是模拟⽤户的操作，找出⽤户极限使⽤系统时的瓶颈，然后解决瓶颈，这是性能测试的基本⽬标。
-发现潜在的瓶颈并解决，保证系统的长期稳定性。主要是考虑⽤户在将来扩展系统或者业务发⽣变化时，系统能够适应变化。满⾜⽤户
⽬前需求的系统不是最好的，我们设计系统的⽬标是在保证系统整个软件⽣命周期能够不断适应⽤户的变化，或者通过简单扩展系统就可以
适应新的变化。
31、⽂档测试主要包含什么内容?
在国内软件开发管理中，⽂档管理⼏乎是最弱的⼀项，因⽽在测试⼯作中特别容易忽略⽂档测试也就不⾜为奇了。要想给⽤户提供完整的
产品，⽂档测试是必不可少的。⽂档测试⼀般注重下⾯⼏个⽅⾯：
⽂档的完整性：主要是测试⽂档内容的全⾯性与完整性，从总体上把握⽂档的质量。例如⽤户⼿册应该包括软件的所有功能模块。
描述与软件实际情况的⼀致性：主要测试软件⽂档与软件实际的⼀致程度。例如⽤户⼿册基本完整后，我们还要注意⽤户⼿册与实际功能
描述是否⼀致。因为⽂档往往跟不上软件版本的更新速度。
易理解性：主要是检查⽂档对关键、重要的操作有⽆图⽂说明，⽂字、图表是否易于理解。对于关键、重要的操作仅仅只有⽂字说明肯定
是不够的，应该附有图表使说明更为直观和明了。
⽂档中提供操作的实例：这项检查内容主要针对⽤户⼿册。对主要功能和关键操作提供的应⽤实例是否丰富，提供的实例描述是否详细。
只有简单的图⽂说明，⽽⽆实例的⽤户⼿册看起来就像是软件界⾯的简单拷贝，对于⽤户来说，实际上没有什么帮助。
印刷与包装质量：主要是检查软件⽂档的商品化程度。有些⽤户⼿册是简单打印、装订⽽成，过于粗糙，不易于⽤户保存。优秀的⽂档例
如⽤户⼿册和技术⽩⽪书，应提供商品化包装，并且印刷精美。
32、功能测试⽤例需要详细到什么程度才是合格的?
这个问题也是测试⼯程师经常问的问题。有⼈主张测试⽤例详细到每个步骤执⾏什么都要写出来，⽬的是即使⼀个不了解系统的新⼿都可
以按照测试⽤例来执⾏⼯作。主张这类写法的⼈还可以举出例⼦：欧美、⽇本等软件外包⽂档都是这样做的。
另外⼀种观点就是主张写的粗些，类似于编写测试⼤纲。主张这种观点的⼈是因为软件开发需求管理不规范，变动⼗分频繁，因⽽不能按
照欧美的⾼标准来编写测试⽤例。这样的测试⽤例容易维护，可以让测试执⾏⼈员有更⼤的发挥空间。
实际上，软件测试⽤例的详细程度⾸先要以覆盖到测试点为基本要求。举个例⼦：“⽤户登陆系统”的测试⽤例可以不写出具体的执⾏数
据，但是⾄少要写出五种以上情况()，如果只⽤⼀句话覆盖了这个功能是不合格的测试⽤例。覆盖功能点不是指列出功能点，⽽是要写出功
能点的各个⽅⾯(如果组合情况较多时可以采⽤等价划分)。
另⼀个影响测试⽤例的就是组织的开发能⼒和测试对象特点。如果开发⼒量⽐较落后，编写较详细的测试⽤例是不现实的，因为根本没有
那么⼤的资源投⼊，当然这种情况很随着团队的发展⽽逐渐有所改善。测试对象特点重点是指测试对象在进度、成本等⽅⾯的要求，如果进
度较紧张的情况下，是根本没有时间写出⾼质量的测试⽤例的，甚⾄有些时候测试⼯作只是⼀种辅助⼯作，因⽽不编写测试⽤例。
因此，测试⽤例的编写要根据测试对象特点、团队的执⾏能⼒等各个⽅⾯综合起来决定编写策略。最后要注意的是测试⼈员⼀定不能抱
怨，⼒争在不断提⾼测试⽤例编写⽔平的同时，不断地提⾼⾃⾝能⼒。
33、配置和兼容性测试的区别是什么?
配置测试的⽬的是保证软件在其相关的硬件上能够正常运⾏，⽽兼容性测试主要是测试软件能否与不同的软件正确协作。
配置测试的核⼼内容就是使⽤各种硬件来测试软件的运⾏情况，⼀般包括：
(1)软件在不同的主机上的运⾏情况，例如Dell和Apple;
(2)软件在不同的组件上的运⾏情况，例如开发的拨号程序要测试在不同⼚商⽣产的Modem上的运⾏情况;
(3)不同的外设;
(4)不同的接⼝;
(5)不同的可选项，例如不同的内存⼤⼩;
兼容性测试的核⼼内容：
(1)测试软件是否能在不同的操作系统平台上兼容;
(2)测试软件是否能在同⼀操作系统平台的不同版本上兼容;
(3)软件本⾝能否向前或者向后兼容;
(4)测试软件能否与其它相关的软件兼容;
(5)数据兼容性测试，主要是指数据能否共享;
配置和兼容性测试通称对开发系统类软件⽐较重要，例如驱动程序、操作系统、数据库管理系统等。具体进⾏时仍然按照测试⽤例来执
⾏。
34、软件⽂档测试主要包含什么?
随着软件⽂档系统⽇益庞⼤，⽂档测试已经成为软件测试的重要内容。⽂档测试对象主要如下：
-包装⽂字和图形;
-市场宣传材料、⼴告以及其它插页;
-授权、注册登记表;
-最终⽤户许可协议;
-安装和设置向导;
-⽤户⼿册;
-联机帮助;
-样例、⽰范例⼦和模板;
-……
⽂档测试的⽬的是提⾼易⽤性和可靠性，降低⽀持费⽤，因为⽤户通过⽂档就可以⾃⼰解决问题。因⽂档测试的检查内容主要如下：
-读者对象——主要是⽂档的内容是否能让该级别的读者理解;
-术语——主要是检查术语是否适合读者;
-内容和主题——检查主题是否合适、是否丢失、格式是否规范等;
-图标和屏幕抓图——检查图表的准确度和精确度;
-样例和⽰例——是否与软件功能⼀致;
-拼写和语法;
-⽂档的关联性——是否与其它相关⽂档的内容⼀致，例如与⼴告信息是否⼀致;
⽂档测试是相当重要的⼀项测试⼯作，不但要给予充分的重视，更要要认真的完成，象做功能测试⼀样来对待⽂档测试。
35、没有产品说明书和需求⽂档地情况下能够进⾏⿊盒测试吗?
这个问题是国内测试⼯程师经常遇到的问题，根源就是国内软件开发⽂档管理不规范，对变更的管理⽅法就更不合理了。实际上没有任何
⽂档的时候，测试⼈员是能够进⾏⿊盒测试的，这种测试⽅式我们可以称之为探索测试，具体做法就是测试⼯程师根据⾃⼰的专业技能、领
域知识等不断的深⼊了解测试对象、理解软件功能，进⽽发现缺陷。
在这种做法基本上把软件当成了产品说明书，测试过程中要和开发⼈员不断的进⾏交流。尤其在作项⽬的时候，进度压⼒⽐较⼤，可以作
为加急测试⽅案。最⼤的风险是不知道有些特性是否被遗漏。
36、测试中的“杀⾍剂怪事”是指什么?
“杀⾍剂怪事”⼀词由BorisBeizer在其编著的《软件测试技术》第⼆版中提出。⽤于描述测试⼈员对同⼀测试对象进⾏的测试次数越多，发
现的缺陷就会越来越少的现象。就像⽼⽤⼀种农药，害⾍就会有免疫⼒，农药发挥不了效⼒。这种现象的根本原因就是测试⼈员对测试软件
过于熟悉，形成思维定势。
为了克服这种现象，测试⼈员需要不断编写新的测试程序或者测试⽤例，对程序的不同部分进⾏测试，以发现更多的缺陷。也可以引⽤新
⼈来测试软件，刚刚进来的新⼿往往能发现⼀些意想不到的问题。
37、在配置测试中，如何判断发现的缺陷是普通问题还是特定的配置问题?
在进⾏配置测试时，测试⼯程师仍然会发现⼀些普通的缺陷，也就是与配置环境⽆关的缺陷。因此判断新发现的问题，需要在不同的配置
中重新执⾏发现软件缺陷的步骤，如果软件缺陷不出现了，就可能是配置缺陷;如果在所有的配置中都出现，就可能是普通缺陷。
需要注意的是，配置问题可以在⼀⼤类配置中出现。例如，拨号程序可能在所有的外置Modem中都存在问题，⽽内置的Modem不会有任
何问题。
38、为什么尽量不要让时间有富裕的员⼯去做⼀些测试?
表⾯上看这体现了管理的效率和灵活性，但实际上也体现了管理者对测试的轻视。测试和测试的⼈有很⼤关系。测试⼯作⼈员应该是勤奋
并富有耐⼼，善于学习、思考和发现问题，细⼼有条理，总结问题，如果具备这样的优点，做其它⼯作同样也会很出⾊，因此这⾥还有⼀个
要求，就是要喜欢测试这项⼯作。如果他是专职的，那么肯定更有经验和信⼼。国内的⼩伙⼦好象都喜欢做程序员，两者⼯作性质不同，待
遇不同，地位不同，对⾃我实现的价值的认识也不同，这是⾏业的⼀个需要改善的问题。如果只是为了完成任务⽽完成任务，或者发现了⼏
个问题就觉得满意了，这在任何其它⼯作中都是不⾏的。
39、完全测试程序是可能的吗?
软件测试初学者可能认为拿到软件后需要进⾏完全测试，找到全部的软件缺陷，使软件“零缺陷”发布。实际上完全测试是不可能的。主要
有以下⼀个原因：
-完全测试⽐较耗时，时间上不允许;
-完全测试通常意味着较多资源投⼊，这在现实中往往是⾏不通的;
-输⼊量太⼤，不能⼀⼀进⾏测试;
-输出结果太多，只能分类进⾏验证;
-软件实现途径太多;
-软件产品说明书没有客观标准，从不同的⾓度看，软件缺陷的标准不同;
因此测试的程度要根据实际情况确定。
40、软件测试的风险主要体现在哪⾥?
我们没有对软件进⾏完全测试，实际就是选择了风险，因为缺陷极有可能存在没有进⾏测试的部分。举个例⼦，程序员为了⽅便，在调试
程序时会弹出⼀些提⽰信息框，⽽这些提⽰只在某种条件下会弹出，碰巧程序发布前这些代码中的⼀些没有被注释掉。在测试时测试⼯程师
⼜没有对其进⾏测试。如果客户碰到它，这将是代价昂贵的缺陷，因为交付后才被客户发现。
因此，我们要尽可能的选择最合适的测试量，把风险降低到最⼩。
41、发现的缺陷越多，说明软件缺陷越多吗?
这是⼀个⽐较常见的现象。测试⼯程师在没有找到缺陷前会绞尽脑汁的思考，但是找到⼀个后，会接⼆连三的发现很多缺陷，颇有个⼈成
就感。其中的原因主要如下：
-代码复⽤、拷贝代码导致程序员容易犯相同的错误。类的继承导致所有的⼦类会包含基类的错误，反复拷贝同⼀代码意味可能也复制了
缺陷。
-程序员⽐较劳累是可以导致某些连续编写的功能缺陷较多。程序员加班是⼀种司空见惯的现象，因此体⼒不只时容易编写⼀些缺陷较多
的程序。⽽这些连续潜伏缺陷恰恰时测试⼯程师⼤显⾝⼿的地⽅。
“缺陷⼀个连着⼀个”不是⼀个客观规律，只是⼀个常见的现象。如果软件编写的⽐较好，这种现象就不常见了。测试⼈员只要严肃认真的
测试程序就可以了。
42、所有的软件缺陷都能修复吗?所有的软件缺陷都要修复吗?
从技术上讲，所有的软件缺陷都是能够修复的，但是没有必要修复所有的软件缺陷。测试⼈员要做的是能够正确判断什么时候不能追求软
件的完美。对于整个项⽬团队，要做的是对每⼀个软件缺陷进⾏取舍，根据风险决定那些缺陷要修复。发⽣这种现象的主要原因如下：
-没有⾜够的时间资源。在任何⼀个项⽬中，通常情况下开发⼈员和测试⼈员都是不够⽤的，⽽且在项⽬中没有预算⾜够的回归测试时
间，再加上修改缺陷可能引⼊新的缺陷，因此在交付期限的强⼤压⼒下，必须放弃某些缺陷的修改。
-有些缺陷只是特殊情况下出现，这种缺陷处于商业利益考虑，可以在以后升级中进⾏修复。
-不是缺陷的缺陷。我们经常会碰到某些功能⽅⾯的问题被当成缺陷来处理，这类问题可以以后有时间时考虑再处理。
最后要说的是，缺陷是否修改要由软件测试⼈员、项⽬经理、程序员共同讨论来决定是否修复，不同⾓⾊的⼈员从不同的⾓度来思考，以
做出正确的决定。
43、软件测试⼈员就是QA吗?
软件测试⼈员的职责是尽可能早的找出软件缺陷，确保得以修复。⽽质量保证⼈员(QA)主要职责是创建或者制定标准和⽅法，提⾼促进软
件开发能⼒和减少软件缺陷。测试⼈员的主要⼯作是测试，质量保证⼈员⽇常⼯作重要内容是检查与评审，测试⼯作也是测试保证⼈员的⼯
作对象。
软件测试和质量是相辅相成的关系，都是为了提⾼软件质量⽽⼯作。
44、如何减少测试⼈员跳槽带来的损失?
在IT⾏业⾥跳槽已经是⼀种司空见惯的现象，⽽且跳槽⽆论给公司还是给个⼈都会带来⼀定的损失。测试队伍也⽆疑会⾯临跳槽的威胁，
作为测试经理管理者，只有从⽇常⼯作中开始做起，最能最⼤限度的减少损失。建议我们从以下两个⽅⾯做起：
-加强部门内员⼯之间的互相学习，互相学习是建⽴学习型组织的基本要求，是知识互相转移的过程。在此基础上，可以把个⼈拥有的技
术以知识的形式沉积下来，也就完成了隐性知识到显性知识的转化。
-通常情况下，企业能为员⼯提供⾜够⼤的发展空间时，如果不是待遇特别低，员⼯都不会主动离开企业。因此我们要想留住员⼯，管理
者就应该把员⼯的个⼈成长和企业的发展联系起来，为员⼯设定合理发展规划并付诸实现。不过这项要求做起来⽐较，要有⽐较好的企业⽂
化为依托。
45、测试产品与测试项⽬的区别是什么?
习惯上把开发完成后进⾏商业化、⼏乎不进⾏代码修改就可以售给⽤户使⽤的软件成为软件产品，也就是可以买“卖拷贝”的软件，例如
Windows2000。⽽通常把针对⼀个或者⼏个特定的⽤户⽽开发的软件成为软件项⽬，软件项⽬是⼀种个性化的产品，可以是按照⽤户要求
全部重新开发，也可以修改已有的软件产品来满⾜特定的⽤户需求。项⽬和产品的不同特点，决定我们测试产品和测试项⽬仍然会有很多不
同的地⽅：
-质量要求不同。通常产品的质量要⾼⼀些，修复发布后产品的缺陷成本较⾼，甚⾄会带来很多负⾯的影响。⽽做项⽬通常⾯向某⼀⽤
户，虽然质量越⾼越好，但是⼀般只要满⾜⽤户要求就可以了。
-测试资源投⼊多少不同。做软件产品通常是研发中⼼来开发，进度压⼒要⼩些。同时由于质量要求⾼，因此会投⼊较多的⼈⼒、物⼒资
源。
-项⽬最后要和⽤户共同验收测试，这是产品测试不具有的特点。
此外，测试产品与测试项⽬在缺陷管理⽅⾯、测试策略制定都会有很⼤不同，测试管理者应该结合具体的环境，恰如其分的完成⼯作。
46、和⽤户共同测试(UAT测试)的注意点有哪些?
软件产品在投产前，通常都会进⾏⽤户验收测试。如果⽤户验收测试没有通过，直接结果就是那不到“Money”，间接影响是损害了公司的
形象，⽽后者的影响往往更严重。根据作者的经验，⽤户验收测试⼀定要让⽤户满意。
实际上⽤户现场测试更趋于是⼀种演⽰。在不欺骗⽤户的前提下，我们向⽤户展⽰我们软件的优点，最后让“上帝”满意并欣然掏出“银⼦”才
是我们的⽬标。因此⽤户测试要注意下⾯的事项：
(1)⽤户现场测试不可能测试全部功能，因此要测试核⼼功能。这需要提前做好准备，这些核⼼功能⼀定要预先经过测试，证明没有问题才
可以和⽤户共同进⾏测试。测试核⼼模块的⽬的是建⽴⽤户对软件的信⼼。当然如果这些模块如果问题较多，不应该进⾏演⽰。
(2)如果某些模块确实有问题，我们可以演⽰其它重要的业务功能模块，必要时要向⽤户做成合理的解释。争得时间后，及时修改缺陷来弥
补。
(3)永远不能欺骗⽤户，蒙混过关。道理很简单，因为软件是要给⽤户⽤的，问题早晚会暴露出来，除⾮你可以马上修改。
和⽤户进⾏测试还要注意各种交流技巧，争取不但短期利益得到了满⾜，还要为后⾯得合作打好基础。
47、如何编写提交给⽤户的测试报告?
随着测试⼯作越来越受重视，开发团队向客户提供测试⽂档是不可避免的事情。很多⼈会问：“我们可以把⼯作中的测试报告提供给客户
吗?”答案是否定的。因为提供内部测试报告，可能会让客户失去信⼼，甚⾄否定项⽬。
测试报告⼀般分为内部测试报告和外部测试报告。内部报告是我们在测试⼯作中的项⽬⽂档，反映了测试⼯作的实施情况，这⾥不过多讨
论，读者可以参考相关教材。这⾥主要讨论⼀下外部测试报告的写法，⼀般外部测试报告要满⾜下⾯⼏个要求：
-根据内部测试报告进⾏编写，⼀般可以摘录;
-不可以向客户报告严重缺陷，即使是已经修改的缺陷，开发中的缺陷也没有必要让客户知道;
-报告上可以列出⼀些缺陷，但必须是中级的缺陷，⽽且这些缺陷必须是修复的;
-报告上⾯的内容尽量要真实可靠;
-整个测试报告要仔细审阅，⼒争不给项⽬带来负⾯作⽤，尤其是性能测试报告。
总之，外部测试报告要⼩⼼谨慎的编写。
48、测试⼯具在测试⼯作中是什么地位?
国内的很多测试⼯程师对测试⼯具相当迷恋，尤其是⼀些新⼿，甚⾄期望测试⼯具可以取代⼿⼯测试。测试⼯具在测试⼯作中起的是辅助
作⽤，⼀般⽤来提⾼测试效率。⾃动化测试弥补了⼿⼯测试的不⾜，减轻⼀定的⼯作量。实际上测试⼯具是⽆法替代⼤多数⼿⼯测试的，⽽
⼀些诸如性能测试等⾃动化测试也是⼿⼯所不能完成的。
对于⾃动测试技术，应当依据软件的不同情况来分别对待，⼀般⾃动技术会应⽤在引起⼤量重复性⼯作的地⽅、系统的压⼒点、以及任何
适合使⽤程序解决⼤批量输⼊数据的地⽅。然后再寻找合适的⾃动测试⼯具，或者⾃⼰开发测试程序。⼀定不要为了使⽤测试⼯具⽽使⽤。
49、常见的测试⽤例设计⽅法都有哪些?请分别以具体的例⼦来说明这些⽅法在测试⽤例设计⼯作中的应⽤。
1-等价类划分
常见的软件测试⾯试题划分等价类:等价类是指某个输⼊域的⼦集合.在该⼦集合中,各个输⼊数据对于揭露程序中的错误都是等效的.并合理
地假定:测试某等价类的代表值就等于对这⼀类其它值的测试.因此,可以把全部输⼊数据合理划分为若⼲等价类,在每⼀个等价类中取⼀个数据
作为测试的输⼊条件,就可以⽤少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和⽆效等价类.
2-边界值分析法
边界值分析⽅法是对等价类划分⽅法的补充。测试⼯作经验告诉我,⼤量的错误是发⽣在输⼊或输出范围的边界上,⽽不是发⽣在输⼊输出
范围的内部.因此针对各种边界情况设计测试⽤例,可以查出更多的错误.
使⽤边界值分析⽅法设计测试⽤例,⾸先应确定边界情况.通常输⼊和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚
⼤于或刚刚⼩于边界的值作为测试数据,⽽不是选取等价类中的典型值或任意值作为测试数据.
3-错误推测法
基于经验和直觉推测程序中所有可能存在的各种错误,从⽽有针对性的设计测试⽤例的⽅法.
错误推测⽅法的基本思想:列举出程序中所有可能有的错误和容易发⽣错误的特殊情况,根据他们选择测试⽤例-例如,在单元测试时曾列出
的许多在模块中常见的错误-以前产品测试中曾经发现的错误等,这些就是经验的总结。还有,输⼊数据和输出数据为0的情况。输⼊表格为空
格或输⼊表格只有⼀⾏-这些都是容易发⽣错误的情况。可选择这些情况下的例⼦作为测试⽤例.
4-因果图⽅法
前⾯介绍的等价类划分⽅法和边界值分析⽅法,都是着重考虑输⼊条件,但未考虑输⼊条件之间的联系,相互组合等-考虑输⼊条件之间的相
互组合,可能会产⽣⼀些新的情况-但要检查输⼊条件的组合不是⼀件容易的事情,即使把所有输⼊条件划分成等价类,他们之间的组合情况也
相当多-因此必须考虑采⽤⼀种适合于描述对于多种条件的组合,相应产⽣多个动作的形式来考虑设计测试⽤例-这就需要利⽤因果图(逻辑模
型)-因果图⽅法最终⽣成的就是判定表-它适合于检查程序输⼊条件的各种组合情况.
5-正交表分析法
有时候，可能因为⼤量的参数的组合⽽引起测试⽤例数量上的激增，同时，这些测试⽤例并没有明显的优先级上的差距，⽽测试⼈员⼜⽆
法完成这么多数量的测试，就可以通过正交表来进⾏缩减⼀些⽤例，从⽽达到尽量少的⽤例覆盖尽量⼤的范围的可能性。
6-场景分析⽅法
指根据⽤户场景来模拟⽤户的操作步骤，这个⽐较类似因果图，但是可能执⾏的深度和可⾏性更好。
50、您认为做好测试⽤例设计⼯作的关键是什么?
⽩盒测试⽤例设计的关键是以较少的⽤例覆盖尽可能多的内部程序逻辑结果
⿊盒法⽤例设计的关键同样也是以较少的⽤例覆盖模块输出和输⼊接⼝。不可能做到完全测试，以最少的⽤例在合理的时间内发现最多的
问题
51、详细的描述⼀个测试活动完整的过程。
1-项⽬经理通过和客户的交流，完成需求⽂档，由开发⼈员和测试⼈员共同完成需求⽂档的评审，评审的内容包括：需求描述不清楚的地
⽅和可能有明显冲突或者⽆法实现的功能的地⽅。项⽬经理通过综合开发⼈员，测试⼈员以及客户的意见，完成项⽬计划。然后sqa进⼊项
⽬，开始进⾏统计和跟踪
2-开发⼈员根据需求⽂档完成需求分析⽂档，测试⼈员进⾏评审，评审的主要内容包括是否有遗漏或者双⽅理解不同的地⽅。测试⼈员完
成测试计划⽂档，测试计划包括的内容上⾯有描述。
3-测试⼈员根据修改好的需求分析⽂档开始写测试⽤例，同时开发⼈员完成概要设计⽂档，详细设计⽂档。此两份⽂档成为测试⼈员撰写
测试⽤例的补充材料。
4-测试⽤例完成后，测试和开发需要进⾏评审。
5-测试⼈员搭建环境
6-开发⼈员提交第⼀个版本，可能存在未完成功能，需要说明。测试⼈员进⾏测试，发现bug后提交给bugzilla。
7-开发提交第⼆个版本，包括bugfix以及增加了部分功能，测试⼈员进⾏测试。
8-重复上⾯的⼯作，⼀般是3-4个版本后bug数量减少，达到出货的要求。
9-如果有客户反馈的问题，需要测试⼈员协助重现以及回归测试。
52、以往是否曾经从事过性能测试⼯作?请尽可能的详细描述您以往的性能测试⼯作的完整过程。
曾经做过⼀套⽹管系统的性能测试，主要测试该软件在同时管理⼤量终端的情况下，在响应时间，cpu/磁盘/内存等参数是否满⾜要求。
也曾经做过软交换系统的呼叫性能测试，主要是测试软交换系统在有⼤量呼叫的情况下，响应时间，呼叫成功率，cpu/磁盘/内存等参数是
否满⾜设计要求。
53、在您以往的⼯作中，⼀条软件缺陷(或者叫bug)记录都包含了哪些内容?如何提交⾼质量的软件缺陷(bug)记录?
1-在传统的bugzilla中，bug描述应该包括以下的信息
2-和bug产⽣对应的软件版本
3-开发的接⼝⼈员
4-bug的优先级
5-bug的严重程度
6-bug可能属于的模块，如果不能确认，可以⽤开发⼈员来判断
7-bug标题，需要清晰的描述现象
8-bug描述，需要尽量给出重新bug的步骤
9-bug附件中能给出相关的⽇志和截图。
⾼质量的bug记录就是指很容易理解的bug记录，所以，对于描述的要求⾼，能提供的信息多且准确，很好的帮助开发⼈员定位。
54、您在从事性能测试⼯作时，是否使⽤过⼀些测试⼯具?如果有，请试述该⼯具的⼯作原理，并以⼀个具体的⼯作中的例⼦描述该⼯具
是如何在实际⼯作中应⽤的。
测试⽹管系统中，使⽤的mimic来模拟终端，能够⼤量的节省成本。
测试软交换系统的时候，使⽤的prolab来模拟终端并发送呼叫软交换，他完成了同时数百⼈才能完成的摘机拨号⼯作，主要⼯作原理是产
⽣⼀些符合要求的ip包并发送给软交换系统，同时对软交换系统的回应进⾏处理，决定下⼀步动作。
55、您认为性能测试⼯作的⽬的是什么?做好性能测试⼯作的关键是什么?
主要是保障在⼤量⽤户的情况下，服务能正常使⽤。