面试软件测试总结（常见的面试问题）
软件测试级别？
单元测试：单元测试是对软件组成单元进行测试。其目的是检验软件基本组成单位的正确性。测试的对象是软件设计的最小单位：模块。Findyou又称为模块测试，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。（测试内容：模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试）
集成测试：（集成测试也称联合测试、组装测试，将程序模块采用适当的集成策略组装起来，对系统的接口及集成后的功能进行正确性检测的测试工作。主要目的是检查软件单位之间的接口是否正确。方法是测试片段的组合，并最终扩展进程，将您的模块与其他组的模块一起测试。最后，将构成进程的所有模块一起测试。测试内容：模块之间数据传输、模块之间功能冲突、模块组装功能正确性、全局数据结构、单模块缺陷对系统的影响
系统测试：将软件系统看成是一个系统的测试。包括对功能、性能以及软件所运行的软硬件环境进行测试。系统测试的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。测试内容：功能、界面、可靠性、易用性、性能、兼容性、安全性等
验收测试:验收测试是部署软件之前的最后一个测试操作。它是技术测试的最后一个阶段，也称为交付测试。总结验收测试的目的是确保软件准备就绪，按照项目合同、任务书、双方约定的验收依据文档，向软件购买都展示该软件系统满足原始需求。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务，即软件的功能和性能如同用户所合理期待的那样。测试内容：同系统测试(功能...各类文档等)
软件测试类型？
功能测试：也叫黑盒测试，功能测试指测试软件各个功能模块是否正确，逻辑是否正确。对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接收、处理和检索是否正确，以及业务规则的实施是否恰当。此类测试基于黑盒技术，该技术通过图形用户界面(GUI) 与应用程序进行交互，并对交互的输出或结果进行分析，以此来核实应用程序及其内部进程。功能测试的主要参考为类似于功能说明书之类的文档。
性能测试：是指验证软件的性能可以满足系统规格给定的指定要求的性能指标。性能测试是一个比较大的范围，可以进一步衍生出负载测试、强度测试、压力测试、稳定性测试。通过自动化测试工具模拟多种正常、异常、峰值条件，对系统各项性能指标测试。
配置测试：用硬件来测试软件运行情况，1.软件在不同主机上运行的情况（Apple和Dell）2.在不同组件上运行情况（开发的拨号程序要测试不同厂商生产的Moden上运行情况）3.不同的外设、接口、内存的运行情况
强度测试：强度测试是一种性能测试，他在系统资源特别低的情况下软件系统运行情况。这类测试往往可以书写系统要求的软硬件水平要求。实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足，测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源（如数据库锁或网络带宽）而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。
负载测试：负载测试是一种性能测试指数据在超负荷环境中运行，程序是否能够承担。在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外，负载测试还要评估性能特征，例如，响应时间、事务处理速率和其他与时间相关的方面。
压力测试：测试出系统所能承受的最大极限。是指系统在极限下的压力情况，系统在什么样的压力下会导致系统得到失效，无法正常运行。100个用户连续访问1小时可以看做是压力测试，连续访问10小时可以认为是负载测试
稳定性测试：一般是稍大于业务量的一个负载，对系统进行的一个持续的，长时间的测试，比如24*3,连续3天的施加压力，确定系统在较长运行时间的情况下，系统的稳定性情况
网络测试：wifi、4G、3G、不同运营商网络测试、
UI界面测试：UI测试指测试用户界面的风格是否满足客户要求，文字是否正确，页面美工是否好看，文字，图片组合是否完美，背景是否美观，操作是否友好等等。
分辨率测试
测试在不同分辨率下，界面的美观程度,分为800*600，1024*768，1152*864，1280*768，1280*1024，1200*1600大小字体下测试。一个好的软件要有一个极佳的分辨率，而在其他分辨率下也都能可以运行。
安装测试
安装测试有两个目的。第一个目的是确保该软件在正常情况和异常情况的不同条件下: 例如，进行首次安装、升级、完整的或自定义的安装_都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。第二个目的是核实软件在安装后可立即正常运行。这通常是指运行大量为功能测试制定的测试。
内存测试：CPU测试、响应时间测试、唤醒率测试等，都属于性能测试。还有强度测试、容量测试、基准测试等。
文档测试：文档测试是检验样品用户文档的完整性、正确性、一致性、易理解性、易浏览性。包括用户手册、使用说明、用户帮助文档等
可靠性测试：这个主要是硬件方面的，比如高低温测试、防水防尘等测试
安全测试：对产品进行检验以验证产品符合安全需求定义和产品质量标准的过程。可确保只有具备系统访问权限的用户才能访问应用程序，而且只能通过相应的网管、关来访问。比如输入管理员账户，检查其密码是否容易猜取，或者可以从数据库中获得？
兼容测试：检查软件在不同软件、硬件平台是否可以正常运行。 主要查看在不同操作系统、浏览器、数据库、不同版本是否正常运行、向前兼容和向后兼容、、数据共享兼容
浏览器兼容性测试：测试软件在不同产商的浏览器下是否能够正确显示与运行、比如测试IE，Natscape浏览器
操作系统兼容性：测试软件在不同操作系统下是否能够正确显示与运行；比如测试WINDOWS98,WINDOWS 2000,WINDOWS XP,LINU, UNIX下是否可以运行这套软件？
硬件兼容性
测试与硬件密切相关的软件产品与其他硬件产品的兼容性，比如该软件是少在并口设备中的，测试同时使用其他并口设备，系统是否可以正确使用。比如在INTER,舒龙CPU芯片下系统是否能够正常运行？
测试方法：动态测试、静态测试；黑盒测试、白盒测试、灰盒测试。
黑盒测试
黑盒测试的优点：容易实施，不需要关注程序内部的实现，更贴近用户的使用角度
缺点：测试覆盖率较低，一般只能覆盖到代码量的40%，针对黑盒的自动化测试，复用率较低，维护成本较高。
黑盒测试也称功能测试，测试中把被测的软件当成一个黑盒子，不关心盒子的内部结构是什么，只关心软件的输入数据与输出数据。
白盒测试
白盒测试的优点:可以检测代码中的每条分支和路径，揭示隐藏在代码中问题，对代码的测试比较彻底
缺点：代价有些高，需要测试人员有编程能力，无法检测代码中遗漏的路径和数据敏感性错误，不能直接验证需求的正确性
白盒测试又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。白盒指的打开盒子，去研究里面的源代码和程序结果。
白盒测试覆盖方法：
1.语句覆盖：使程序中的每个可执行语句都能执行一次的测试用例
2.判定覆盖（分支覆盖）：对于判断语句，在设计用例的时候，要设计判断语句结果为True和False的两种情况
3.条件覆盖：设计用例时针对判断语句里面每个条件表达式true 和 false各取值一次，不考判断语句的计算结果
4.判定条件覆盖（分支条件覆盖）：设计测试用例时，使得判断语句中每个条件表达式的所有可能结果至少出现一次，每个判断语句本身所有可能结果也至少出现一次。
5.条件组合覆盖：设计测试用例时，使得每个判断语句中条件结果的所有可能组合至少出现一次
6.路径覆盖：设计测试用例时，覆盖程序中所有可能的执行路径
灰盒测试
定义：介于黑、白盒测试之间的，关注输出对于输入的正确性，同时也关注内部表现
静态测试
1，静态测试是指无需执行被测程序，而是通过评审软件文档或代码，度量程序静态复杂度，检查软件是否符合编程标准，借以发现编写的程序的不足之处，减少错误出现的概率
动态测试
1，动态测试是指通过运行被测程序，检查运行结果和预期结果的差异，并分析运行效率，正确性和健壮性等
2，静态（看外观）和动态（发动车走一段路）可以用买车来说明
手工测试
由专门的测试人员从用户视角来验证软件是否满足设计要求的行为。
更适用针对深度的测试和强调主观判断的测试
比如：众包测试和探索式测试
自动化测试
1.适用单独的测试工具软件控制测试的自动化执行以及对预期和结果进行自动检查。
2.手工测试和自动化测试的区别？
手动测试：优点：易发现缺陷、容易实施、灵活性 缺点：覆盖量低、重复测试效率低、可靠性低、人力资源依赖
自动化测试：优点：高效率，速度快、高复用性、覆盖率高、准确可靠、不知疲劳 缺点：机械发现缺陷率低、一次性投入大
安全测试
安全测试是在IT软件产品的生命周期中，特别是产品开发基本完成到发布阶段，对产品进行检验以验证产品符合安全需求定义和产品质量标准的过程 。
Findyou觉现在对安全知识的普及，大家意识都提上来了。比如现在越来越多的不支持HTTP协议，转用HTTPS等。
探索性测试
探索性测试可以是一种测试思维技术。它没有很多实际的测试方法、技术和工具，但是却是所有测试人员都应该掌握的一种测试思维方式。探索性强调测试人员的主观能动性，抛弃繁杂的测试计划和测试用例设计过程，强调在碰到问题时及时改变测试策略
随机测试
随机测试主要是根据测试者的经验对软件进行功能和性能抽查。
根据测试说明书执行用例测试的重要补充手段，是保证测试覆盖完整性的有效方式和过程。
随机测试主要是对被测软件的一些重要功能进行复测，也包括测试那些当前的测试用例(TestCase)没有覆盖到的部分。
冒烟测试
关于冒烟测试，就是开发人员在个人版本的软件上执行目前的冒烟测试项目，确定新的程序代码不出故障。冒烟测试目的是确认软件基本功能正常，现基本执行对象为测试人员，在正规测试一个新版本之前，投入较少的人力和时间验证基本功能，通过则测试准入。
α测试
α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。α测试的目的是评价软件产品的FLURPS(即功能、局域化、可使用性、可靠性、性能和支持)。
大型通用软件，在正式发布前，通常需要执行Alpha和Beta测试。α测试不能由程序员或测试员完成。
β测试
Beta测试是一种验收测试。Beta测试由软件的最终用户们在一个或多个客房场所进行。
alpha测试和beta测试的区别
1、测试时间不同：
Beta测试是软件产品完成了功能测试和系统测试之后，产品发布之前所进行的软件测试活动，它是技术测试的最后一个阶段。
alpha测试简称“α测试”，可以从软件产品编码结束之时开始，或在模块(子系统)测试完成之后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。
2、测试的目的不同：
α测试的目的是评价软件产品的(即功能、局域化、可用性、可靠性、性能和支持)。尤其注重产品的界面和特色。α测试即为非正式验收测试。
Beta测试是一种验收测试，通过了验收测试，产品就会进入发布阶段。
测试人员及场所不同：
α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，α测试不能由程序员或测试员完成。α测试发现的错误，可以在测试现场立刻反馈给开发人员，由开发人员及时分析和处理。
Beta测试由软件的最终用户们在一个或多个客户场所进行。开发者通常不在Beta测试的现场，因Beta测试是软件在开发者不能控制的环境中的“真实”应用。
测试设计方法：
等价类划分、边界值、因果图划分、正交、场景、随机、错误推断、测试大纲
等价类划分法： : 1:有效等价类: 2:无效等价类:
案例:比如一个登陆输入框,规定只能输入中文,同时长度为6-10,
通过等价类设计测试用例:
测试用例中重要的三步: 输入 操作 预计结果 如果与预期结果不符合就是bug
有效等价类: 输入:输入长度为6的中文,输入的为王小明,这就是有效等价类
无效等价类:
1: 输入长度为4的中文,输入位小名,点击登录,预计结果长度不符合要求
2: 输入长度为6,但是是英文的,点击登录,预计结果 请输入中文
3: 输入长度为4,而且不是中文的,是数字,1234,点击登录,预计结果请输入中文并且长度为6-10位
4:输入长度为12而且不是中文的,比如qwertyuiopas,点击登录,预计结果请输入中文并且长度为6-10位
二：边界值法:
应用场景:边界值往往和等价类划分法一起使用,形成一套更为完善的测试方案,找到有效数据和无效数据的分界点,
注解边界值一般和有效等价类划分法配合使用:
案例:比如一个登陆输入框,规定只能输入中文,同时长度为6-10,
上面输入框的边界的:如果固定大于等于6,并且小于等于10,
那左边界就是 5和 6
右边界是:10 和 11
测试用例:
1:输入的为王小明,这就是有效等价类和边界值的结合使用
2:输入小名,这就是边界值为5,同时有效等价类
3:输入欧阳致远家,这就是边界值10,同时等价类有效
4:输入欧阳致远啦啦,这就是边界值为11,同时有效等价类
三:因果图及判定表法:
应用场景:在一个界面中有多个控件,如果控件之间有组合关系或者限制关系,不同的控件组合会产生不同的输入结果,为了弄清楚不同的输入组合会产生咋样的输出结果,可以使用因果图及判定表法:
判断是儿童还是青年还是成年人:
条件1:年龄 age
条件2:身高height
条件3:体重weight
输入年龄5,体重80公斤,身高170,查无此人
输入提高80,身高170,输入年龄20,成年人
输入年龄5,体重30,身高60,小孩
四:正交表:
应用场景:在一个界面中有多个控件，每个控件有多个取值，测试时考虑不同的控件不同取值之间的多种组合，但组合数量巨大（>20种，20种以下一般考虑判定表因果图），没有必要全部测试，如何从所有的组合中挑选最少、最优的组合进行测试，可以使用正交排列法。
正交表的测试思想特点：
1）使用每个控件的每个取值参与组合的次数是基本相等的（均匀的）
2）在所有的组合数据中，选取数据时，应该均匀的选取，而不能从局部选取。
3）如果时间允许，尽可能的多测一些组合
正交表:主要针对一个输入框里面可能有多个值,而且数量巨大
年龄 体重 省 市 县
比如:输入年龄 18,体重45,山西 大同 阳高
五:测试大纲法
适用场合：程序包含多个窗口，每个窗口中又有多个功能，这些功能之间又有一定的联系。为了梳理清楚窗口之间以及窗口不同功能之间的联系，使用测试大纲法。
六:场景法
适用场合：大多数的业务比较复杂的软件系统都适合使用场景法（便于将各个功能点串起来，便于形成完整的业务感觉）是一种基于软件业务的测试方法，把自己当成最终用户，尽可能的模拟用户在使用此软件的操作
案例:
场景一:比如买东西:输入袜子,点击查询,出现列表,点击七匹狼,点击进入详情,点击加入购物车,点击去购物车结算,点击收获地址,点击支付,支付成功
场景二:比如买东西:输入袜子,点击查询,出现列表,点击七匹狼,点击进入详情,点击加入购物车,点击去购物车结算,点击收获地址,点击取消支付
七: 错误推断法
基于经验和直觉推测程序中所有可能存在的各种错误 , 从而有针对性的设 计测试用例的方法
在进行灰盒测试的时候经常用到此方法
八:随机测试
随意测试，不考虑任何用例和需求，完全站在一个用户或者的角度对产品进行使用。
适用场景：
1） 所有之前设定的用例已经 执行完毕
2）海量的条件组合无法一遍 历的时候
软件测试风险：
测试人员：业务不熟、人员变动、疲态、同化效应、定位效应
测试材料：需求变更、质量标准不一样、测试用例或测试数据设计不充分
测试环境：测试软件版本不统一、软件环境不统一、硬件环境不统一、硬件不到位
测试时间：测试时间不足、测试时间延长
测试方法：错误或缺失测试方法、场景缺失、测试用例实施不充分
软件作用：
jmeter： 接口自动化测试，支持录制、抓包、可进行压力测试（增加线程，考验服务器最大支持访问数）、弱网测试
ant： 生成测试报告并发送
jenkins： 生成测试报告并定时发送
monkey：进行稳定性测试，Android SDK提供的一个命令行工具
charles： 1.抓包（http、https）、2.弱网测试、3.网络请求的截取并动态修改、4.压力测试
selenium ：web自动化测试框架（测试浏览器的兼容性）优点:兼容更多的平台（ Windows、Linux 、 Macintosh等）以及浏览器（火狐，IE，谷歌等）
Bug的生命周期？新建，提交，确认，分配，修复，验证，关闭
软件开发过程中的角色分工？（测试的主要工作）
测试配合开发等进行需求分析和讨论，根据需求说明书指定《项目测试计划》，编写测试用例，建立测试环境。
测试负责新产品测试，原有产品的升级测试，负责软件问题解决过程跟踪，软件开发文档、开发工作的规范化，管理开发部 门的产品文档，制作用户手册、操作手册，产品上限测试，监督软件开发过程执行，提高软件质量。
缺陷（bug）等级分类？
致命：测试过程死机、系统崩溃、数据跌势、功能没有实现
严重：导致软件功能不稳定、功能实现错误、流程错误
一般：校验错误、罕见故障、错别字，不影响功能，影响体验
低级：没影响的小问题
使用bugzilla缺陷管理工具对软件缺陷（BUG）跟踪的管理的流程？
答:1) 测试人员或开发人员发现bug后，判断属于哪个模块的问题，填写bug报告后，系统会自动通过Email通知项目组长或直接通知开发者。
2) 经验证无误后，修改状态为VERIFIED（已证实）.待整个产品发布后，修改为CLOSED（关闭）
3) 还有问题，REOPENED（重新打开），状态重新变为“New"，并发邮件通知。
4) 项目组长根据具体情况，重新分配给bug所属的开发者。
5) 若是，进行处理，断言并给出解决方法。(可创建补丁附件及补充说明)
6) 开发者收到Email信息后，判断是否为自己的修改范围。
7) 若不是，重新分配给项目组长或应该分配的开发者。
8) 测试人员查询开发者已修改的bug，进行重新测试。确认无误后，关闭该bug。
缺陷报告由哪些组成？（测试报告，测试用例）
缺陷编号、日期、缺陷标题、 缺陷优先程度、缺陷所属模块、缺陷所属版本、执行流程、预计结果、输出结果、缺陷分析、缺陷所属开发 人员、缺陷描述缺陷有限等级等。提高质量：要有效的发现 Bug 需参考需求以及详细设计等前期文档设计出高效的测试用例，然后严格执行测试用例，对发现的问题要充分确认肯定，然后再向外发布如此才能提高提交 Bug 的质量。
测试报告：项目说明 测试依据 人员及进度 测试概要 测试环境 测试用例 测试方法 覆盖分析 需求覆盖 测试覆盖
如何设计测试用例？
测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。检验是否满足客户需求；度量测试人员的工作量；展现测试用例的思路。
测试用例包含：
用例编号 唯一的编号。
用例标题 当前测试用例的用途
测试背景 这个用例属于哪个项目
前置条件 用例执行前应该满足哪些条件
重要级别 定义优先级，分为高低级别
测试数据 具体输入内容
测试步骤 每步做些什么
预期结果 需求文档要求结果
实际结果 实际输出结果
备注
测试用例编写流程：需求分析--》提取测试点--》测试用例编写--》测试用例评审
测试用例常用设计方法：等价类划分法、 边界值分析法、因果图法、场景法、正交表、测试大纲法、错误推断法、随机测试
测试计划编写：
编写测试计： 测试环境准备、 第一次功能测试、 性能测试、 回归测试、 测试报告总结
1. 测试目标：根据xxx需求，提炼测试功能点、制定测试策略、评估测试 风险，预估编写测试用例、执行功能测试和回归测试的工作量，进行人员和进度 安排。
2. 测试范围：功能模块：（需要结合实际情况）
3. 测试策略：对需求中的功能改进进行完整测试，并根据应用场景和并发数考虑兼容性和性能测试方案。 并需要指定出测试工具
3.1 功能测试：见测试用例表
3.2 性能测试
3.3 系统兼容性测试
4. 测试资源
4.1 人员安排
4.2 测试环境
4.3 bug管理
5试进度安排：任务 时间 执行人员 工作量
5.2输出文档：测试计划、测试报告
6测试验收标准：1.完成所有类型测试 ,没有影响到用户业务使用的bug ,bug数量少于一定数量 , 功能业务，性能指标符合需求
6.2 产品上线标准：产品 checkelist
1. 已按照交互文档、需求文档完全的实现需求；
2. 符合交互稿的交互设计规范、符合视觉要求，已经通过设计评审；
3. 允许遗留可能会对用户正常使用造成一定影响的正常级缺陷，但应在发布前告知项目组，并经风险评估同意发布后方可发布
7. 风险说明
主要包括三个方面：1.测试范围风险 （测试遗漏，需求变更）、2.测试进度风险（预估量不准确，测试人员变动，其他业务工作，）、3.产品质量风险（代码质量，测试人员能力）
软件测试的原则：
1.测试软件存在缺陷。证明测试对象是有缺陷的。
2.测试尽早介入，缺陷发现越早，修复成本越小。
3.不可进行穷尽测试（无意义测试）。
4.缺陷集群性（2/8原则）80%的缺陷发现在20%的模块中。
5.杀虫剂悖论，如果一直使用相同的测试方法或手段，可能无法发现新的bug。
6.测试环境的特殊新，测试活动依赖测试内容，不同的行业，测试活动的开展都有所不同，比如测试技术、测试工具的选择，测试流程都不尽相同，所以软件测试的活动开展依赖于所测试的内容
7.不存在缺陷谬论，软件测试不仅是找出缺陷，同时也需要确认软件是否满足需求。
简述集成测试的环境？
1.硬件环境： 集成测试时，要尽可能的考虑用户使用的实际环境；当实际环境难以达到的时候，模拟环境考虑到与实际环境之间 可能存在的差异。
2.操作系统环境：考虑到不同的操作系统版本，对于可能使用的操作系统环境，要尽可能的测试到。
3.数据库环境：数据库的选择合乎实际情况。容量，性能，版本等多方面考虑。
4.网络环境：一般的网络环境可以使用以太网、wifi、3G、4G。
集成测试通常都有那些策略？
大爆炸集成
2、自顶向下集成
3、自底向上集成
4、三明治集成适应于大部分软件开发项目
5、基干集成
6、分层集成
7、基于功能的集成
8、基于消息的集成
9、基于风险的集成
10、基于进度的集成
测试策略:
功能测试，性能测试，压力测试，容量测试，安全性测试，GUI测试，可用性测试，安装测试，配置测试，
异常测试，备份测试，健壮性测试，文档测试，在线帮助测试，网络测试，稳定性测试
在：正常情况下测试；非正常情况下测试；边界测试；非法，极端测试；
什么是测试脚本？
测试脚本是为了进行自动化测试而编写的脚本，测试脚本的编写必须对应相应的测试用例
测试脚本是一段代码不假。但是这段代码可能是为了执行某一条，或很多条测试用例而写的。也有可能 ，本身就是一条用例。
用例本身并不局限，在基于功能。脚本和用例没有并列的可比性。脚本可能是用例，也可能是执行用例用的功能。用例也可能是脚本。
软件产品质量特性是什么? ?
功能性：适应性、准确性、互操作性、依从性、安全性。
可使用性：易理解性、易学习性、易操作性。
效率：时间特性、资源特性。
可维护性：易分析性、易变更性、稳定性、易测试性。
可移植性： 适应性、易安装性、遵循性、易替换性。
一台客户端有三百个客户与三百个客户端有三百个客户对服务器施压，有什么区别?
300个用户在一个客户端上，会占用客户机更多的资源，而影响测试的结果。线程之间可能发生干扰，而产生一些异常。300个用户在一个客户端上，需要更大的带宽。
IP地址的问题，可能需要使用IP Spoof来绕过服务器对于单一IP地址最大连接数的限制。
所有用户在一个客户端上，不必考虑分布式管理的问题；而用户分布在不同的客户端上，需要考虑使用控制器来整体调配不同客户机上的用户。同时，还需要给予相应的权限配置和防火墙设置。
使用QTP做功能测试，录制脚本的时候，要验证多个用户的登录情况/查询情况，如何操作？
分析用户登录的基本情况，得出一组数据，通过性测试/失败性测试的都有（根据TC来设计这些数据），然后录制登录的脚本，将关键的数据参数化，修改脚本，对代码进行加强，调试脚本。
QTP中的action主要是用来管理代码的，Action的作用 1）用Action可以对步骤集进行分组 2）步骤重组，然后被整体调用 3）拥有自己的sheet 4）组合有相同需求的步骤，整体操作 5）具有独立的对象仓库
TestDirector有些什么功能，如何对软件测试过程进行管理？
管理测试需求，测试计划以及缺陷跟踪分析，主要有五个模块：1.服务测试管理器、2.需求管理器、3.测试实验室、4.缺陷管理器、5.测试计划 保证各阶段之间顺畅的信息流，完全基于Web。
业务分析员：定义应用程序需求和测试目标
QA测试员：运用手动和自动测试，报告执行测试结果，输入缺陷
开发人员：数据库查看和解决缺陷
测试经理和项目经理：设计测试计划，开发测试案例
产品经理：决定是否准备发布应用
测试自动化和自动化测试的区别？
什么是测试自动化：这是一种让测试过程脱离人工的一次变革。对于控制成本，控制质量，回溯质量和减少测试周期都有积极影响的一种研发过程。
什么是自动化测试：通过将测试执行部分部分或者全部交由机器执行的一种测试，叫做自动化测试。这种测试不需要人的实时参与。同时这种测试在小规模应用时会比手动测试昂贵许多。
自动化测试可以看作测试自动化的一部分。
一个自动化工程师，会比较专注于测试工具的研发。最主要的是这个工程师会从成本的角度去考虑问题。这一点比较像PM。他所做的一切是为了减少自己或者团队的工作量，尽可能的将重复的，有规律可循的工作代码化，自动化。
一个自动化测试工程师，会比较专注于测试代码的开发，以及测试结果的分析。对于被测设备本身非常感兴趣。他们比较倾向于一种完美主义者，追求的是高质量而经常忽略成本。这一点更像开发人员。
公司的测试环境？
开发环境：开发环境是程序猿们专门用于开发的服务器，配置可以比较随意， 为了开发调试方便，一般打开全部错误报告。
测试环境：一般是克隆一份生产环境的配置，一个程序在测试环境工作不正常，那么肯定不能把它发布到生产机上。
生产环境：是指正式提供对外服务的，一般会关掉错误报告，打开错误日志。可以理解为包含所有的功能的环境，任何项目所使用的环境都以这个为基础，然后根据客户的个性化需求来做调整或者修改。
三个环境也可以说是系统开发的三个阶段：开发->测试->上线，其中生产环境也就是通常说的真实环境。
UAT环境：UAT，(User Acceptance Test),用户接受度测试 即验收测试，所以UAT环境主要是用来作为客户体验的环境。
仿真环境：顾名思义是和真正使用的环境一样的环境（即已经出售给客户的系统所在环境，也成为商用环境），所有的配置，页面展示等都应该和商家正在使用的一样，差别只在环境的性能方面。
公司做安全测试是怎么进行的？
软件安全性测试主要包括程序、数据库安全性测试。根据系统安全指标不同测试策略也不同。
详细的测试点：
1.跨网站脚本攻击：通过脚本语言的缺陷模拟合法用户，控制其账户，盗窃敏感数据
2.注入攻击：通过构造查询对数据库、LDAP和其他系统进行非法查询
3.恶意文件执行：在服务器上执行Shell 命令Execute，获取控制权
4.伪造跨站点请求：发起Blind 请求，模拟合法用户，要求转账等请求
5.不安全对象引用：不安全对象的引入，访问敏感文件和资源，WEB应用返回敏感文件内容
6.被破坏的认证和Session管理：验证Session token 保护措施，防止盗窃session
7.Session的失效时间限制：Session的失效时间设置是否过长，会造成访问风险
8.不安全的木马存储：过于简单的加密技术导致黑客破解编密码，隐秘信息被盗窃，验证其数据加密
9.不安全的通讯：敏感信息在不安全通道中以非加密方式传送， 敏感信息被盗窃，验证其通讯的安全性
10.URL访问限制失效：验证是否通过恶意手段访问非授权的资源链接，强行访问一些登陆网页，窃取敏感信息
11.信息泄露和不正确错误处理测试：恶意系统检测，防止黑客用获取WEB站点的具体信息的攻击手段获取详细系统信息
12.注册与登录测试：验证系统先注册后登录、验证登录用户名和密码匹配校验，密码长度及尝试登录次数，防止 非法用户登录
13.超时限制：验证WEB应用系统需要有是否超时的限制，当用户长时间不做任何操作的时候，需要重新登录才能使用
14.日志文件：验证服务器上日志是否正常工作，所有事务处理是否被记录
15.目录文件：验证WEB服务器目录访问权限或者每个目录访问时有index.htm，防止 WEB 服务器处理不适当，将整个目录暴露
16.身份验证：验证调用者身份、数据库身份、验证是否明确服务账户要求、是否强制式试用账户管理措施
17.授权：验证如何向最终用户授权、如何在数据库中授权应用程序，确定访问系统资源权限
18.会话：验证如何交换会话标识符、是否限制会话生存期、如何确保会话存储状态安全
19.配置管理：验证是否支持远程管理、是否保证配置存储安全、是否隔离管理员特权
20.备份与恢复：为了防止系统意外崩溃造成的数据丢失，验证备份与恢复功能正常实现、备份与恢复方式是否满足Web系统安全性要求
21.数据库关键数据是否进行加密存储，是否在网络中传递敏感数据
22.在登录或注册功能中是否有验证码存在，防止恶意大批量注册登录的攻击
23.Cookie文件是否进行了加密存储，防止盗用cookie内容
24.密码强度提醒：建议对密码的规则进行加强设置
25.密码内容禁止拷贝粘贴
用户身份认证安全的测试要考虑问题：
1.明确区分系统中不同用户权限
2.系统中会不会出现用户冲突
3.系统会不会因用户的权限的改变造成混乱
4.用户登陆密码是否是可见、可复制
5.系统的密码策略，通常涉及到隐私，钱财或机密性的系统必须设置高可用的密码策略。
5.是否可以通过绝对途径登陆系统（拷贝用户登陆后的链接直接进入系统）
6.用户推出系统后是否删除了所有鉴权标记，是否可以使用后退键而不通过输入口令进入系统
系统网络安全的测试要考虑问题：
1.测试采取的防护措施是否正确装配好，有关系统的补丁是否打上
2.模拟非授权攻击，看防护系统是否坚固
3.采用成熟的网络漏洞检查工具检查系统相关漏洞（即用最专业的黑客攻击工具攻击试一下，现在最常用的是 NBSI系列和 IPhacker IP ）
4.采用各种木马检查工具检查系统木马情况
5.采用各种防外挂工具检查系统各组程序的客外挂漏洞
数据库安全考虑问题：
1.系统数据是否机密（比如对银行系统，这一点就特别重要，一般的网站就没有太高要求）
2.系统数据的完整性（我刚刚结束的企业实名核查服务系统中就曾存在数据的不完整，对于这个系统的功能实现有了障碍）
3.系统数据可管理性
4.系统数据的独立性
5.系统数据可备份和恢复能力（数据备份是否完整，可否恢复，恢复是否可以完整）
浏览器安全
同源策略：不同源的“document”或脚本，不能读取或者设置当前的“document”
同源定义：host（域名，或者IP），port（端口号），protocol（协议）三者一致才属于同源。
要注意的是，同源策略只是一种策略，而非实现。这个策略被用于一些特定的点来保护web的安全。