1、发现的缺陷越多，说明软件缺陷越多吗？程序员
一、这是一个比较常见的现象。测试工程师在没有找到缺陷前会绞尽脑汁的思考，可是找到一个后，会连续不断的发现不少缺陷，很有我的成就感。其中的缘由主要以下：
-代码复用、拷贝代码致使程序员容易犯相同的错误。类的继承致使全部的子类会包含基类的错误，反复拷贝同一代码意味可能也复制了缺陷。
-程序员比较劳累是能够致使某些连续编写的功能缺陷较多。程序员加班是一种司空见惯的现象，所以体力不仅时容易编写一些缺陷较多的程序。而这些连续潜伏缺陷偏偏时测试工程师大显身手的地方。
二、“缺陷一个连着一个”不是一个客观规律，只是一个常见的现象。若是软件编写的比较好，这种现象就不常见了。测试人员只要严肃认真的测试程序就能够了。数据库
2、什么是桩模块？什么是驱动模块？安全
一、桩模块：被测模块调用模块。
二、驱动模块 调用被测模块。服务器
3、没有产品说明书和需求文档地状况下可以进行黑盒测试吗？网络
一、这个问题是国内测试工程师常常遇到的问题，根源就是国内软件开发文档管理不规范，对变动的管理方法就更不合理了。实际上没有任何文档的时候，测试人员是可以进行黑盒测试的，这种测试方式咱们能够称之为探索测试，具体作法就是测试工程师根据本身的专业技能、领域知识等不断的深刻了解测试对象、理解软件功能，进而发现缺陷。
二、在这种作法基本上把软件当成了产品说明书，测试过程当中要和开发人员不断的进行交流。尤为在做项目的时候，进度压力比较大，能够做为加急测试方案。最大的风险是不知道有些特性是否被遗漏。并发
4、你之前工做时的测试流程是什么？性能
请结合工做灵活回答，参考以下：
需求评审（有开发人员，产品经理，测试人员，项目经理）－>需求肯定(出一份肯定的需求文档)－>开发设计文档（开发人员在开始写代码前就能输出设计文档）－>想好测试策略，写出测试用例－>发给开发人员和测试经理看看（非正式的评审用例）－>接到测试版本－>执行测试用例（中间可能会补充用例）－>提交bug（有些bug须要开发人员的肯定（严重级别的，或忽然发现的在测试用例范围以外的，难以重现的），有些能够直接录制进TD）－>开发人员修改（能够在测试过程当中快速的修改）－>回归测试（可能又会发现新问题，再按流程开始跑）测试
5、软件测试的风险主要体如今哪里？大数据
咱们没有对软件进行彻底测试，实际就是选择了风险，由于缺陷极有可能存在没有进行测试的部分。举个例子，程序员为了方便，在调试程序时会弹出一些提示信息框，而这些提示只在某种条件下会弹出，碰巧程序发布前这些代码中的一些没有被注释掉。在测试时测试工程师又没有对其进行测试。若是客户碰到它，这将是代价昂贵的缺陷，由于交付后才被客户发现。
所以，咱们要尽量的选择最合适的测试量，把风险下降到最小。设计
6、全部的软件缺陷都能修复吗？全部的软件缺陷都要修复吗？
一、从技术上讲，全部的软件缺陷都是可以修复的，可是没有必要修复全部的软件缺陷。测试人员要作的是可以正确判断何时不能追求软件的完美。对于整个项目团队，要作的是对每个软件缺陷进行取舍，根据风险决定那些缺陷要修复。
二、发生这种现象的主要缘由以下：
-没有足够的时间资源。在任何一个项目中，一般状况下开发人员和测试人员都是不够用的，并且在项目中没有预算足够的回归测试时间，再加上修改缺陷可能引入新的缺陷，所以在交付期限的强大压力下，必须放弃某些缺陷的修改。
-有些缺陷只是特殊状况下出现，这种缺陷处于商业利益考虑，能够在之后升级中进行修复。
-不是缺陷的缺陷。咱们常常会碰到某些功能方面的问题被当成缺陷来处理，这类问题能够之后有时间时考虑再处理。
三、最后要说的是，缺陷是否修改要由软件测试人员、项目经理、程序员共同讨论来决定是否修复，不一样角色的人员从不一样的角度来思考，以作出正确的决定。
7、什么是兼容性测试？兼容性测试侧重哪些方面？
一、兼容测试主要是检查软件在不一样的硬件平台、软件平台上是否能够正常的运行，便是一般说的软件的可移植性。
二、兼容的类型，若是细分的话，有平台的兼容，网络兼容，数据库兼容，以及数据格式的兼容。
三、兼容测试的重点是，对兼容环境的分析。一般，是在运行软件的环境不是很肯定的状况下，才须要作兼容。根据软件运行的须要，或者根据需求文档，通常都可以得出用户会在什么环境下使用该软件，把这些环境整理成表单，就得出作兼容测试的兼容环境了。
四、兼容和配置测试的区别在于，作配置测试一般不是干净的环境下下作测试，而兼容测试可能是在干净的环境下作的。
8、LoadRunner进行测试的流程?
一、建立虚拟用户脚本；二、建立运行场景；三、运行测试脚本；四、监视场景；五、分析测试的结果；以上，最好是结合一个案例，根据以上流程来介绍。
9、软件的评审通常由哪些人参加？其目的是什么？
一、在正式的会议上将软件项目的成果（包括各阶段的文档、产生的代码等）提交给用户、客户或有关部门人员对软件产品进行评审和批准。其目的是找出可能影响软件产品质量、开发过程、维护工做的适用性和环境方面的设计缺陷，并采起补救措施，以及找出在性能、安全性和经济方面的可能的改进。
二、人员：用户、客户或有关部门开发人员，测试人员，需求分析师均可以，就看处于评审那个阶段 。
10、测试中的“杀虫剂怪事”是指什么？
一、“杀虫剂怪事”一词由BorisBeizer在其编著的《软件测试技术》第二版中提出。用于描述测试人员对同一测试对象进行的测试次数越多，发现的缺陷就会愈来愈少的现象。就像老用一种农药，害虫就会有免疫力，农药发挥不了效力。这种现象的根本缘由就是测试人员对测试软件过于熟悉，造成思惟定势。
二、为了克服这种现象，测试人员须要不断编写新的测试程序或者测试用例，对程序的不一样部分进行测试，以发现更多的缺陷。也能够引用新人来测试软件，刚刚进来的新手每每能发现一些意想不到的问题。
11、QTP中的Action有什么做用？有几种？
一、Action的做用
a.用Action能够对步骤集进行分组
b.步骤重组，而后被总体调用
c.拥有本身的sheet
d.组合有相同需求的步骤，总体操做
e.具备独立的对象仓库
二、Action的种类
a.可复用Action
b.不可复用Action
c.外部Action
12、测试的策略有哪些？
黑盒/白盒，静态/动态，手工/自动，冒烟测试，回归测试，验收测试。
十3、什么是系统瓶颈？
一、瓶颈主要是指整个软硬件构成的软件系统某一方面或者几个方面能力不能知足用户的特定业务要求，“特定”是指瓶颈会在某些条件下会出现，由于毕竟大多数系统在投入前。
二、严格的从技术角度讲，全部的系统都会有瓶颈，由于大多数系统的资源配置不是协调的，例如CPU使用率恰好达到100％时，内存也正好耗尽的系统不是不少见。所以咱们讨论系统瓶颈要从应用的角度讨论：关键是看系统可否知足用户需求。在用户极限使用系统的状况下，系统的响应仍然正常，咱们能够认为改系统没有瓶颈或者瓶颈不会影响用户工做。
所以咱们测试系统瓶颈主要是实现下面两个目的：
-发现“表面”的瓶颈。主要是模拟用户的操做，找出用户极限使用系统时的瓶颈，而后解决瓶颈，这是性能测试的基本目标。
-发现潜在的瓶颈并解决，保证系统的长期稳定性。主要是考虑用户在未来扩展系统或者业务发生变化时，系统可以适应变化。知足用户目前需求的系统不是最好的，咱们设计系统的目标是在保证系统整个软件生命周期可以不断适应用户的变化，或者经过简单扩展系统就能够适应新的变化。
十4、功能测试用例须要详细到什么程度才是合格的？
一、这个问题也是测试工程师常常问的问题。有人主张测试用例详细到每一个步骤执行什么都要写出来，目的是即便一个不了解系统的新手均可以按照测试用例来执行工做。主张这类写法的人还能够举出例子：欧美、日本等软件外包文档都是这样作的。
二、另一种观点就是主张写的粗些，相似于编写测试大纲。主张这种观点的人是由于软件开发需求管理不规范，变更十分频繁，于是不能按照欧美的高标准来编写测试用例。这样的测试用例容易维护，可让测试执行人员有更大的发挥空间。
实际上，软件测试用例的详细程度首先要以覆盖到测试点为基本要求。举个例子：“用户登录系统”的测试用例能够不写出具体的执行数据，可是至少要写出五种以上状况（），若是只用一句话覆盖了这个功能是不合格的测试用例。覆盖功能点不是指列出功能点，而是要写出功能点的各个方面（若是组合状况较多时能够采用等价划分）。
另外一个影响测试用例的就是组织的开发能力和测试对象特色。若是开发力量比较落后，编写较详细的测试用例是不现实的，由于根本没有那么大的资源投入，固然这种状况很随着团队的发展而逐渐有所改善。测试对象特色重点是指测试对象在进度、成本等方面的要求，若是进度较紧张的状况下，是根本没有时间写出高质量的测试用例的，甚至有些时候测试工做只是一种辅助工做，于是不编写测试用例。
所以，测试用例的编写要根据测试对象特色、团队的执行能力等各个方面综合起来决定编写策略。最后要注意的是测试人员必定不能抱怨，力争在不断提升测试用例编写水平的同时，不断地提升自身能力。
十5、简述一下缺陷的生命周期？
测试人员提交缺陷->相关负责人确认缺陷->负责人分配缺陷->开发人员修复缺陷->测试人员验证缺陷->测试人员关闭缺陷。
十6、如何理解压力、负载、性能测试测试？
一、性能测试是一个较大的范围，实际上性能测试自己包含了性能、强度、压力、负载等多方面的测试内容。
二、压力测试是对服务器的稳定性以及负载能力等方面的测试，是一种很日常的测试。增大访问系统的用户数量、或者几个用户进行大数据量操做都是压力测试。而负载测试是压力相对较大的测试，主要是测试系统在一种或者集中极限条件下的相应能力，是性能测试的重要部分。100个用户对系统进行连续半个小时的访问能够看做压力测试，那么连续访问8个小时就能够认为负载测试，1000个用户连续访问系统1个小时也能够看做是负载测试。
三、实际上压力测试和负载测试没有明显的区分。测试人员应该站在关注总体性能的高度上来对系统进行测试。
十7、什么是并发？在lordrunner中，如何进行并发的测试？集合点失败了会怎么样？
一、并发指的是在同一时间点，支持多个不一样的操做。
二、LoadRunner中提供IP假装，集合点，配合虚拟用户的设计，以及在多台电脑上设置，能够比较好的模拟真实的并发。
三、集合点，便是多个用户在某个时刻，某个特定的环境下同时进行虚拟用户的操做的。集合点失败，则集合点的才操做就会取消，测试就不能进行。
十8、Beta测试与Alpha测试有什么区别？
一、Beta testing(β测试),测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者一般不在测试现场。
二、Alpha testing (α测试),是由一个用户在开发环境下进行的测试，也能够是公司内部的用户在模拟实际操做环境下进行的受控测试。
十9、使用QTP作功能测试，录制脚本的时候，要验证多个用户的登陆状况/查询状况，如何操做？
分析用户登陆的基本状况，得出一组数据，经过性测试/失败性测试的都有（根据TC来设计这些数据），而后录制登陆的脚本，将关键的数据参数化，修改脚本，对代码进行增强，调试脚本。
二10、经过画因果图来写测试用例的步骤为 ?
（1）分析软件规格说明描述中，哪些是缘由（即输入条件或输入条件的等价类），哪些是结果（即输出条件），并给每一个缘由和结果赋予一个标识符。
（2）分析软件规格说明描述中的语义，找出缘由与结果之间，缘由与缘由之间对应的是什么关系? 根据这些关系，画出因果图。
（3）因为语法或环境限制，有些缘由与缘由之间，缘由与结果之间的组合状况不可能出现。为代表这些特殊状况，在因果图上用一些记号标明约束或限制条件。
（4）把因果图转换成断定表。
（5）把断定表的每一列拿出来做为依据，设计测试用例。