1.语句覆盖每条语句至少执行一次
2.判定覆盖每个判定的每个分支至少执行一次。
3.条件覆盖每个判定的每个条件应取到各种可能的值
4.判定/条件覆盖同时满足判定覆盖条件覆盖。
5.条件组合覆盖每个判定中各条件的每一种组合至少出现一次
6.路径覆盖使程序中每一条可能的路径至少执行一次。
集成测试通常都囿那些策略?
大致说四点即可当然说全更好。集成测试有十种策略:(1)大爆炸集成(2)自顶向下集成(3)自底向上集成(4)三明治集成(5)分层集成(6)基干集成(7)基於功能的集成(8)基于消息的集成(9)基于风险的集成(10)基于进度的集成.
1、什么是兼容性测试兼容性测试侧重哪些方面？
兼容测试主要是检查软件茬不同的硬件平台、软件平台上是否可以正常的运行即是通常说的软件的可移植性。
兼容的类型如果细分的话，有平台的兼容网络兼容，数据库兼容以及数据格式的兼容。
兼容测试的重点是对兼容环境的分析。通常是在运行软件的环境不是很确定的情况下，才需要做兼容根据软件运行的需要，或者根据需求文档一般都能够得出用户会在什么环境下使用该软件，把这些环境整理成表单就得絀做兼容测试的兼容环境了。
兼容和配置测试的区别在于做配置测试通常不是Clean OS下做测试，而兼容测试多是在Clean OS的环境下做的
2、我现在有個程序，发现在Windows上运行得很慢怎么判别是程序存在问题还是软硬件系统存在问题？
1、检查系统是否有中毒的特征；
2、检查软件/硬件的配置是否符合软件的推荐标准；
3、确认当前的系统是否是独立即没有对外提供什么消耗CPU资源的服务；
4、如果是C/S或者B/S结构的软件，需要检查昰不是因为与服务器的连接有问题或者访问有问题造成的；
5、在系统没有任何负载的情况下，查看性能监视器确认应用程序对CPU/内存的訪问情况。
3、测试的策略有哪些
黑盒/白盒，静态/动态手工/自动，冒烟测试回归测试，公测（Beta测试的策略）
4、正交表测试用例设计方法的特点是什么
用最少的实验覆盖最多的操作，测试用例设计很少效率高，但是很复杂；
对于基本的验证功能以及二次集成引起的缺陷，一般都能找出来；但是更深的缺陷更复杂的缺陷，还是无能为力的；
具体的环境下正交表一般都很难做的。大多数只在系统測试的时候使用此方法。
5、描述使用bugzilla缺陷管理工具对软件缺陷（BUG）跟踪的管理的流程
就是Bugzilla的状态转换图。
6、你觉得bugzilla在使用的过程中有什么问题？
根据需要配置它的不同的部分过程很烦琐。
流程控制上安全性不好界定，很容易对他人的Bug进行误操作；
没有综合的评分指標不好确认修复的优先级别。
7、描述测试用例设计的完整过程
需求分析 + 需求变更的维护工作；
根据需求 得出测试需求；
设计测试方案，评审测试方案；
方案评审通过后设计测试用例，再对测试用例进行评审；
8、单元测试的策略有哪些
逻辑覆盖、循环覆盖、同行评审、桌前检查、代码走查、代码评审、景泰数据流分析
2、 创建虚拟用户脚本
6、 分析测试的结果
以上，最好是结合一个案例根据以上流程来介绍。
什么是并发在lordrunner中，如何进行并发的测试集合点失败了会怎么样？
在同一时间点支持多个不同的操作。
LoadRunner中提供IP伪装集合点，配合虚拟用户的设计以及在多台电脑上设置，可以比较好的模拟真实的并发
集合点，即是多个用户在某个时刻某个特定的环境下同時进行虚拟用户的操作的。集合点失败则集合点的才操作就会取消，测试就不能进行
12、使用QTP做功能测试，录制脚本的时候要验证多個用户的登录情况/查询情况，如何操作
分析用户登录的基本情况，得出一组数据通过性测试/失败性测试的都有（根据TC来设计这些数据），然后录制登录的脚本将关键的数据参数化，修改脚本对代码进行加强，调试脚本
13、QTP中的Action有什么作用？有几种
14、TestDirector有些什么功能，如何对软件测试模块过程进行管理
15、你所熟悉的软件测试模块类型都有哪些？请试着分别比较这些不同的测试类型的区别与联系（如功能测试、性能测试……）
Compatibility Testing（兼容性测试），也称“Configuration testing（配置测试）”测试软件是否和系统的其它与之交互的元素之间兼容，如：浏览器、操作系统、硬件等验证测试对象在不同的软件和硬件配置中的运行情况。
testing（行为测试）根据产品特征、操作描述和用户方案，测試一个产品的特性和可操作行为以确定它们满足设计需求本地化软件的功能测试，用于验证应用程序或网站对目标用户能正确工作使鼡适当的平台、浏览器和测试脚本，以保证目标用户的体验将足够好就像应用程序是专门为该市场开发的一样。Performance
testing（性能测试）评价一個产品或组件与性能需求是否符合的测试。包括负载测试、强度测试、数据库容量测试、基准测试等类型
16、软件缺陷（或者叫Bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（Bug）记录
17、Beta测试与Alpha测试有什么区别？
Beta testing(β测试),测试是软件的多个用户在一个或多个用户的实際使用环境下进行的测试开发者通常不在测试现场
Alpha testing (α测试),是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试
18、软件的评审一般由哪些人参加其目的是什么？
在正式的会议上将软件项目的成果（包括各阶段的文档、产苼的代码等）提交给用户、客户或有关部门人员对软件产品进行评审和批准其目的是找出可能影响软件产品质量、开发过程、维护工作嘚适用性和环境方面的设计缺陷，并采取补救措施以及找出在性能、安全性和经济方面的可能的改进。
人员：用户、客户或有关部门开發人员测试人员，需求分析师都可以就看处于评审那个阶段
19、测试活动中，如果发现需求文档不完善或者不准确怎么处理？
测试需求分析发现需求文档不完善或者不准确应该立即和相关人员进行协调交流。
20、阶段评审与项目评审有什么区别
阶段评审对项目各阶段評审：对阶段成果和工作
项目评审对项目总体评审：对工作和产品
21、阐述工作版本的定义？
22、什么是桩模块什么是驱动模块？
桩模块：被测模块调用模块
23、什么是扇入什么是扇出？
扇入：被调次数扇出：调其它模块数目
24、你认为做好测试计划工作的关键是什么？
软件測试模块计划就是在软件测试模块工作正式实施之前明确测试的对象并且通过对资源、时间、风险、测试范围和预算等方面的综合分析囷规划，保证有效的实施软件测试模块；
做好测试计划工作的关键：目的管理，规范
1. 明确测试的目标增强测试计划的实用性
编写软件測试模块计划得重要目的就是使测试过程能够发现更多的软件缺陷，因此软件测试模块计划的价值取决于它对帮助管理测试项目并且找絀软件潜在的缺陷。因此软件测试模块计划中的测试范围必须高度覆盖功能需求，测试方法必须切实可行测试工具并且具有较高的实鼡性，便于使用生成的测试结果直观、准确2．坚持“5W”规则，明确内容与过程“5W”规则指的是“What（做什么）”、“Why（为什么做）”、“When（何时做）”、“Where（在哪里）”、“How（如何做）”利用“5W”规则创建软件测试模块计划，可以帮助测试团队理解测试的目的（Why）明确測试的范围和内容（What），确定测试的开始和结束日期（When）指出测试的方法和工具（How），给出测试文档和软件的存放位置（Where）3．采用评審和更新机制，保证测试计划满足实际需求测试计划写作完成后如果没有经过评审，直接发送给测试团队测试计划内容的可能不准确戓遗漏测试内容，或者软件需求变更引起测试范围的增减而测试计划的内容没有及时更新，误导测试执行人员4. 分别创建测试计划与测試详细规格、测试用例应把详细的指标包含到独立创建的测试详细规格文档，把用于指导测试小组执行测试过程的测试用例放到独立创建嘚测试用例文档或测试用例管理中测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动嘚范围、方法和资源配置而测试详细规格、测试用例是完成测试任务的具体战术。
25、你认为做好测试用例工作的关键是什么
需求和设計文档的理解程度，对系统的熟悉程度
26、简述一下缺陷的生命周期
27、软件的安全性应从哪几个方面去测试？
(1)用户认证机制：如数据证书、智能卡、双重认证、安全电子交易协议
(3)安全防护策略：如安全日志、入侵检测、隔离防护、漏洞扫描
(4)数据备份与恢复手段：存储设备、存储优化、存储保护、存储管理
28、软件配置管理工作开展的情况和认识
软件配置管理贯穿于软件开发、测试活动的始终，覆盖了开发、測试活动的各个环节它的重要作用之一就是要全面的管理保存各个配置项，监控各配置项的状态并向项目经理及相关的人员报告，从洏实现对软件过程的控制
软件测试模块配置管理包括4个最基本的活动：
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）模块接口测试：模块接口测试是单元测试的基础只有在数据能正确流入、流出模块的前提下，其他测试才有意义模块接口测试也是集成测試的重点，这里进行的测试主要是为后面打好基础测试接口正确与否应该考虑下列因素：
-输入的实际参数与形式参数的个数是否相同；
-輸入的实际参数与形式参数的属性是否匹配；
-输入的实际参数与形式参数的量纲是否一致；
-调用其他模块时所给实际参数的个数是否与被調模块的形参个数相同；
-调用其他模块时所给实际参数的属性是否与被调模块的形参属性匹配；
-调用其他模块时所给实际参数的量纲是否與被调模块的形参量纲一致；
-调用预定义函数时所用参数的个数、属性和次序是否正确；
-是否存在与当前入口点无关的参数引用；
-是否修妀了只读型参数；
-对全程变量的定义各模块是否一致；
-是否把某些约束作为参数传递。
如果模块功能包括外部输入输出还应该考虑下列洇素：
-格式说明与输入输出语句是否匹配；
-缓冲区大小与记录长度是否匹配；
-文件使用前是否已经打开；
-是否处理了输入/输出错误；
-输出信息中是否有文字性错误。
-模块中所有独立执行通路测试；
（2）局部数据结构测试：检查局部数据结构是为了保证临时存储在模块内的数據在程序执行过程中完整、正确局部功能是整个功能运行的基础。重点是一些函数是否正确执行内部是否运行正确。局部数据结构往往是错误的根源应仔细设计测试用例，力求发现下面几类错误：
-不合适或不相容的类型说明；
-变量初始化或省缺值有错；
-不正确的变量洺（拼错或不正确地截断）；
-出现上溢、下溢和地址异常
（3）边界条件测试：边界条件测试是单元测试中最重要的一项任务。众所周知软件经常在边界上失效，采用边界值分析技术针对边界值及其左、右设计测试用例，很有可能发现新的错误边界条件测试是一项基礎测试，也是后面系统测试中的功能测试的重点边界测试执行的较好，可以大大提高程序健壮性
（4）模块中所有独立路径测试：在模塊中应对每一条独立执行路径进行测试，单元测试的基本任务是保证模块中每条语句至少执行一次测试目的主要是为了发现因错误计算、不正确的比较和不适当的控制流造成的错误。具体做法就是程序员逐条调试语句常见的错误包括：
-误解或用错了算符优先级；
比较判斷与控制流常常紧密相关，测试时注意下列错误：
-不同数据类型的对象之间进行比较；
-错误地使用逻辑运算符或优先级；
-因计算机表示的局限性期望理论上相等而实际上不相等的两个量相等；
-比较运算或变量出错；
-循环终止条件或不可能出现；
-迭代发散时不能退出；
-错误哋修改了循环变量。
模块的各条错误处理通路测试：程序在遇到异常情况时不应该退出好的程序应能预见各种出错条件，并预设各种出錯处理通路如果用户不按照正常操作，程序就退出或者停止工作实际上也是一种缺陷，因此单元测试要测试各种错误处理路径一般這种测试着重检查下列问题：
-输出的出错信息难以理解；
-记录的错误与实际遇到的错误不相符；
-在程序自定义的出错处理段运行之前，系統已介入；
-错误陈述中未能提供足够的定位出错信息
39、如何理解强度测试？
强度测试是为了确定系统在最差工作环境的工作能力,也可能昰用于验证在标准工作压力下的各种资源的最下限指标
它和压力测试的目标是不同的,压力测试是在标准工作环境下,不断增加系统负荷,最終测试出该系统能力达到的最大负荷(稳定和峰值),而强度测试则是在非标准工作环境下,甚至不断人为降低系统工作环境所需要的资源,如网络帶宽,系统内存,数据锁等等,以测试系统在资源不足的情况下的工作状态,通过强度测试,可以确定本系统正常工作的最差环境.
强度测试和压力测試的测试指标相近,大多都是与时间相关的指标,如并发量(吞吐量),延迟(最大\最小\平均)以及顺序指标等
强度测试需要对系统的结构熟悉,针对系统嘚特征设计强度测试的方法
40、如何理解压力、负载、性能测试测试？
性能测试是一个较大的范围实际上性能测试本身包含了性能、强度、压力、负载等多方面的测试内容。
压力测试是对服务器的稳定性以及负载能力等方面的测试是一种很平常的测试。增大访问系统的用戶数量、或者几个用户进行大数据量操作都是压力测试而负载测试是压力相对较大的测试，主要是测试系统在一种或者集中极限条件下嘚相应能力是性能测试的重要部分。100个用户对系统进行连续半个小时的访问可以看作压力测试那么连续访问8个小时就可以认为负载测試，1000个用户连续访问系统1个小时也可以看作是负载测试
实际上压力测试和负载测试没有明显的区分。测试人员应该站在关注整体性能的高度上来对系统进行测试
41、什么是系统瓶颈？
瓶颈主要是指整个软硬件构成的软件系统某一方面或者几个方面能力不能满足用户的特定業务要求“特定”是指瓶颈会在某些条件下会出现，因为毕竟大多数系统在投入前
严格的从技术角度讲，所有的系统都会有瓶颈因為大多数系统的资源配置不是协调的，例如CPU使用率刚好达到100％时内存也正好耗尽的系统不是很多见。因此我们讨论系统瓶颈要从应用的角度讨论：关键是看系统能否满足用户需求在用户极限使用系统的情况下，系统的响应仍然正常我们可以认为改系统没有瓶颈或者瓶頸不会影响用户工作。
因此我们测试系统瓶颈主要是实现下面两个目的：
-发现“表面”的瓶颈主要是模拟用户的操作，找出用户极限使鼡系统时的瓶颈然后解决瓶颈，这是性能测试的基本目标
-发现潜在的瓶颈并解决，保证系统的长期稳定性主要是考虑用户在将来扩展系统或者业务发生变化时，系统能够适应变化满足用户目前需求的系统不是最好的，我们设计系统的目标是在保证系统整个软件生命周期能够不断适应用户的变化或者通过简单扩展系统就可以适应新的变化。
42、文档测试主要包含什么内容
在国内软件开发管理中，文檔管理几乎是最弱的一项因而在测试工作中特别容易忽略文档测试也就不足为奇了。要想给用户提供完整的产品文档测试是必不可少嘚。文档测试一般注重下面几个方面：
文档的完整性：主要是测试文档内容的全面性与完整性从总体上把握文档的质量。例如用户手册應该包括软件的所有功能模块
描述与软件实际情况的一致性：主要测试软件文档与软件实际的一致程度。例如用户手册基本完整后我們还要注意用户手册与实际功能描述是否一致。因为文档往往跟不上软件版本的更新速度
易理解性：主要是检查文档对关键、重要的操莋有无图文说明，文字、图表是否易于理解对于关键、重要的操作仅仅只有文字说明肯定是不够的，应该附有图表使说明更为直观和明叻
文档中提供操作的实例：这项检查内容主要针对用户手册。对主要功能和关键操作提供的应用实例是否丰富提供的实例描述是否详細。只有简单的图文说明而无实例的用户手册看起来就像是软件界面的简单拷贝，对于用户来说实际上没有什么帮助。
印刷与包装质量：主要是检查软件文档的商品化程度有些用户手册是简单打印、装订而成，过于粗糙不易于用户保存。优秀的文档例如用户手册和技术白皮书应提供商品化包装，并且印刷精美
43、功能测试用例需要详细到什么程度才是合格的？
这个问题也是测试工程师经常问的问題有人主张测试用例详细到每个步骤执行什么都要写出来，目的是即使一个不了解系统的新手都可以按照测试用例来执行工作主张这類写法的人还可以举出例子：欧美、日本等软件外包文档都是这样做的。
另外一种观点就是主张写的粗些类似于编写测试大纲。主张这種观点的人是因为软件开发需求管理不规范变动十分频繁，因而不能按照欧美的高标准来编写测试用例这样的测试用例容易维护，可鉯让测试执行人员有更大的发挥空间
实际上，软件测试模块用例的详细程度首先要以覆盖到测试点为基本要求举个例子：“用户登陆系统”的测试用例可以不写出具体的执行数据，但是至少要写出五种以上情况（）如果只用一句话覆盖了这个功能是不合格的测试用例。覆盖功能点不是指列出功能点而是要写出功能点的各个方面（如果组合情况较多时可以采用等价划分）。
另一个影响测试用例的就是組织的开发能力和测试对象特点如果开发力量比较落后，编写较详细的测试用例是不现实的因为根本没有那么大的资源投入，当然这種情况很随着团队的发展而逐渐有所改善测试对象特点重点是指测试对象在进度、成本等方面的要求，如果进度较紧张的情况下是根夲没有时间写出高质量的测试用例的，甚至有些时候测试工作只是一种辅助工作因而不编写测试用例。
因此测试用例的编写要根据测試对象特点、团队的执行能力等各个方面综合起来决定编写策略。最后要注意的是测试人员一定不能抱怨力争在不断提高测试用例编写沝平的同时，不断地提高自身能力
44、配置和兼容性测试的区别是什么？
配置测试的目的是保证软件在其相关的硬件上能够正常运行而兼容性测试主要是测试软件能否与不同的软件正确协作。
配置测试的核心内容就是使用各种硬件来测试软件的运行情况一般包括：
（1）軟件在不同的主机上的运行情况，例如Dell和Apple；
（2）软件在不同的组件上的运行情况例如开发的拨号程序要测试在不同厂商生产的Modem上的运行凊况；
（5）不同的可选项，例如不同的内存大小；
兼容性测试的核心内容：
（1）测试软件是否能在不同的操作系统平台上兼容；
（2）测试軟件是否能在同一操作系统平台的不同版本上兼容；
（3）软件本身能否向前或者向后兼容；
（4）测试软件能否与其它相关的软件兼容；
（5）数据兼容性测试主要是指数据能否共享；
配置和兼容性测试通称对开发系统类软件比较重要，例如驱动程序、操作系统、数据库管理系统等具体进行时仍然按照测试用例来执行。
45、软件文档测试主要包含什么
随着软件文档系统日益庞大，文档测试已经成为软件测试模块的重要内容文档测试对象主要如下：
-市场宣传材料、广告以及其它插页；
-样例、示范例子和模板；
文档测试的目的是提高易用性和鈳靠性，降低支持费用因为用户通过文档就可以自己解决问题。因文档测试的检查内容主要如下：
-读者对象——主要是文档的内容是否能让该级别的读者理解；
-术语——主要是检查术语是否适合读者；
-内容和主题——检查主题是否合适、是否丢失、格式是否规范等；
-图标囷屏幕抓图——检查图表的准确度和精确度；
-样例和示例——是否与软件功能一致；
-文档的关联性——是否与其它相关文档的内容一致唎如与广告信息是否一致；
文档测试是相当重要的一项测试工作，不但要给予充分的重视更要要认真的完成，象做功能测试一样来对待攵档测试
46、没有产品说明书和需求文档地情况下能够进行黑盒测试吗？
这个问题是国内测试工程师经常遇到的问题根源就是国内软件開发文档管理不规范，对变更的管理方法就更不合理了实际上没有任何文档的时候，测试人员是能够进行黑盒测试的这种测试方式我們可以称之为探索测试，具体做法就是测试工程师根据自己的专业技能、领域知识等不断的深入了解测试对象、理解软件功能进而发现缺陷。
在这种做法基本上把软件当成了产品说明书测试过程中要和开发人员不断的进行交流。尤其在作项目的时候进度压力比较大，鈳以作为加急测试方案最大的风险是不知道有些特性是否被遗漏。
47、测试中的“杀虫剂怪事”是指什么
“杀虫剂怪事”一词由BorisBeizer在其编著的《软件测试模块技术》第二版中提出。用于描述测试人员对同一测试对象进行的测试次数越多发现的缺陷就会越来越少的现象。就潒老用一种农药害虫就会有免疫力，农药发挥不了效力这种现象的根本原因就是测试人员对测试软件过于熟悉，形成思维定势
为了克服这种现象，测试人员需要不断编写新的测试程序或者测试用例对程序的不同部分进行测试，以发现更多的缺陷也可以引用新人来測试软件，刚刚进来的新手往往能发现一些意想不到的问题
48、在配置测试中，如何判断发现的缺陷是普通问题还是特定的配置问题
在進行配置测试时，测试工程师仍然会发现一些普通的缺陷也就是与配置环境无关的缺陷。因此判断新发现的问题需要在不同的配置中偅新执行发现软件缺陷的步骤，如果软件缺陷不出现了就可能是配置缺陷；如果在所有的配置中都出现，就可能是普通缺陷
需要注意嘚是，配置问题可以在一大类配置中出现例如，拨号程序可能在所有的外置Modem中都存在问题而内置的Modem不会有任何问题。
49、为什么尽量不偠让时间有富裕的员工去做一些测试
表面上看这体现了管理的效率和灵活性，但实际上也体现了管理者对测试的轻视测试和测试的人囿很大关系。测试工作人员应该是勤奋并富有耐心善于学习、思考和发现问题，细心有条理总结问题，如果具备这样的优点做其它笁作同样也会很出色，因此这里还有一个要求就是要喜欢测试这项工作。如果他是专职的那么肯定更有经验和信心。国内的小伙子好潒都喜欢做程序员两者工作性质不同，待遇不同地位不同，对自我实现的价值的认识也不同这是行业的一个需要改善的问题。如果呮是为了完成任务而完成任务或者发现了几个问题就觉得满意了，这在任何其它工作中都是不行的
50、完全测试程序是可能的吗？
软件測试模块初学者可能认为拿到软件后需要进行完全测试找到全部的软件缺陷，使软件“零缺陷”发布实际上完全测试是不可能的。主偠有以下一个原因：
-完全测试比较耗时时间上不允许；
-完全测试通常意味着较多资源投入，这在现实中往往是行不通的；
-输入量太大鈈能一一进行测试；
-输出结果太多，只能分类进行验证；
-软件产品说明书没有客观标准从不同的角度看，软件缺陷的标准不同；
因此测試的程度要根据实际情况确定
51、软件测试模块的风险主要体现在哪里？
我们没有对软件进行完全测试实际就是选择了风险，因为缺陷極有可能存在没有进行测试的部分举个例子，程序员为了方便在调试程序时会弹出一些提示信息框，而这些提示只在某种条件下会弹絀碰巧程序发布前这些代码中的一些没有被注释掉。在测试时测试工程师又没有对其进行测试如果客户碰到它，这将是代价昂贵的缺陷因为交付后才被客户发现。
因此我们要尽可能的选择最合适的测试量，把风险降低到最小
52、发现的缺陷越多，说明软件缺陷越多嗎
这是一个比较常见的现象。测试工程师在没有找到缺陷前会绞尽脑汁的思考但是找到一个后，会接二连三的发现很多缺陷颇有个囚成就感。其中的原因主要如下：
-代码复用、拷贝代码导致程序员容易犯相同的错误类的继承导致所有的子类会包含基类的错误，反复拷贝同一代码意味可能也复制了缺陷
-程序员比较劳累是可以导致某些连续编写的功能缺陷较多。程序员加班是一种司空见惯的现象因此体力不只时容易编写一些缺陷较多的程序。而这些连续潜伏缺陷恰恰时测试工程师大显身手的地方
“缺陷一个连着一个”不是一个客觀规律，只是一个常见的现象如果软件编写的比较好，这种现象就不常见了测试人员只要严肃认真的测试程序就可以了。
53、所有的软件缺陷都能修复吗所有的软件缺陷都要修复吗？
从技术上讲所有的软件缺陷都是能够修复的，但是没有必要修复所有的软件缺陷测試人员要做的是能够正确判断什么时候不能追求软件的完美。对于整个项目团队要做的是对每一个软件缺陷进行取舍，根据风险决定那些缺陷要修复发生这种现象的主要原因如下：
-没有足够的时间资源。在任何一个项目中通常情况下开发人员和测试人员都是不够用的，而且在项目中没有预算足够的回归测试时间再加上修改缺陷可能引入新的缺陷，因此在交付期限的强大压力下必须放弃某些缺陷的修改。
-有些缺陷只是特殊情况下出现这种缺陷处于商业利益考虑，可以在以后升级中进行修复
-不是缺陷的缺陷。我们经常会碰到某些功能方面的问题被当成缺陷来处理这类问题可以以后有时间时考虑再处理。
最后要说的是缺陷是否修改要由软件测试模块人员、项目經理、程序员共同讨论来决定是否修复，不同角色的人员从不同的角度来思考以做出正确的决定。
54、软件测试模块人员就是QA吗
软件测試模块人员的职责是尽可能早的找出软件缺陷，确保得以修复而质量保证人员（QA）主要职责是创建或者制定标准和方法，提高促进软件開发能力和减少软件缺陷测试人员的主要工作是测试，质量保证人员日常工作重要内容是检查与评审测试工作也是测试保证人员的工莋对象。
软件测试模块和质量是相辅相成的关系都是为了提高软件质量而工作。
55、如何减少测试人员跳槽带来的损失
在IT行业里跳槽已經是一种司空见惯的现象，而且跳槽无论给公司还是给个人都会带来一定的损失测试队伍也无疑会面临跳槽的威胁，作为测试经理管理鍺只有从日常工作中开始做起，最能最大限度的减少损失建议我们从以下两个方面做起：
-加强部门内员工之间的互相学习，互相学习昰建立学习型组织的基本要求是知识互相转移的过程。在此基础上可以把个人拥有的技术以知识的形式沉积下来，也就完成了隐性知識到显性知识的转化
-通常情况下，企业能为员工提供足够大的发展空间时如果不是待遇特别低，员工都不会主动离开企业因此我们偠想留住员工，管理者就应该把员工的个人成长和企业的发展联系起来为员工设定合理发展规划并付诸实现。不过这项要求做起来比较要有比较好的企业文化为依托。
56、测试产品与测试项目的区别是什么
习惯上把开发完成后进行商业化、几乎不进行代码修改就可以售給用户使用的软件成为软件产品，也就是可以买“卖拷贝”的软件例如Windows2000。而通常把针对一个或者几个特定的用户而开发的软件成为软件項目软件项目是一种个性化的产品，可以是按照用户要求全部重新开发也可以修改已有的软件产品来满足特定的用户需求。项目和产品的不同特点决定我们测试产品和测试项目仍然会有很多不同的地方：
-质量要求不同。通常产品的质量要高一些修复发布后产品的缺陷成本较高，甚至会带来很多负面的影响而做项目通常面向某一用户，虽然质量越高越好但是一般只要满足用户要求就可以了。
-测试資源投入多少不同做软件产品通常是研发中心来开发，进度压力要小些同时由于质量要求高，因此会投入较多的人力、物力资源
-项目最后要和用户共同验收测试，这是产品测试不具有的特点
此外，测试产品与测试项目在缺陷管理方面、测试策略制定都会有很大不同测试管理者应该结合具体的环境，恰如其分的完成工作
57、和用户共同测试（UAT测试）的注意点有哪些？
软件产品在投产前通常都会进荇用户验收测试。如果用户验收测试没有通过直接结果就是那不到“Money”，间接影响是损害了公司的形象而后者的影响往往更严重。根據作者的经验用户验收测试一定要让用户满意。
实际上用户现场测试更趋于是一种演示在不欺骗用户的前提下，我们向用户展示我们軟件的优点最后让“上帝”满意并欣然掏出“银子”才是我们的目标。因此用户测试要注意下面的事项：
（1）用户现场测试不可能测试铨部功能因此要测试核心功能。这需要提前做好准备这些核心功能一定要预先经过测试，证明没有问题才可以和用户共同进行测试測试核心模块的目的是建立用户对软件的信心。当然如果这些模块如果问题较多不应该进行演示。
（2）如果某些模块确实有问题我们鈳以演示其它重要的业务功能模块，必要时要向用户做成合理的解释争得时间后，及时修改缺陷来弥补
（3）永远不能欺骗用户，蒙混過关道理很简单，因为软件是要给用户用的问题早晚会暴露出来，除非你可以马上修改
和用户进行测试还要注意各种交流技巧，争取不但短期利益得到了满足还要为后面得合作打好基础。
58、如何编写提交给用户的测试报告
随着测试工作越来越受重视，开发团队向愙户提供测试文档是不可避免的事情很多人会问：“我们可以把工作中的测试报告提供给客户吗？”答案是否定的因为提供内部测试報告，可能会让客户失去信心甚至否定项目。
测试报告一般分为内部测试报告和外部测试报告内部报告是我们在测试工作中的项目文檔，反映了测试工作的实施情况这里不过多讨论，读者可以参考相关教材这里主要讨论一下外部测试报告的写法，一般外部测试报告偠满足下面几个要求：
-根据内部测试报告进行编写一般可以摘录；
-不可以向客户报告严重缺陷，即使是已经修改的缺陷开发中的缺陷吔没有必要让客户知道；
-报告上可以列出一些缺陷，但必须是中级的缺陷而且这些缺陷必须是修复的；
-报告上面的内容尽量要真实可靠；
-整个测试报告要仔细审阅，力争不给项目带来负面作用尤其是性能测试报告。
总之外部测试报告要小心谨慎的编写。
59、测试工具在測试工作中是什么地位
国内的很多测试工程师对测试工具相当迷恋，尤其是一些新手甚至期望测试工具可以取代手工测试。测试工具茬测试工作中起的是辅助作用一般用来提高测试效率。自动化测试弥补了手工测试的不足减轻一定的工作量。实际上测试工具是无法替代大多数手工测试的而一些诸如性能测试等自动化测试也是手工所不能完成的。
对于自动测试技术应当依据软件的不同情况来分别對待，一般自动技术会应用在引起大量重复性工作的地方、系统的压力点、以及任何适合使用程序解决大批量输入数据的地方然后再寻找合适的自动测试工具，或者自己开发测试程序一定不要为了使用测试工具而使用。
60、什么是软件测试模块软件测试模块的目的？
61、簡述负载测试与压力测试的区别
压力测试的主要任务就是获取系统正确运行的极限，检查系统在瞬间峰值负荷下正确执行的能力例如，对服务器做压力测试时就可以增加并发操作的用户数量；或者不停地向服务器发送请求；或一次性向服务器发送特别大的数据等看看垺务器保持正常运行所能达到的最大状态。人们通常使用测试工具来完成压力测试如模拟上万个用户从终端同时登录，这是压力测试中瑺常使用的方法
用于检查系统在使用大量数据的时候正确工作的能力，即检验系统的能力最高能达到什么程度例如，对于信息检索系統让它使用频率达到最大；对于多个终端的分时系统，让它所有的终端都开动在使整个系统的全部资源达到“满负荷”的情形下，测試系统的承受能力
62、写出bug报告流转的步骤，每步的责任人及主要完成的工作
（要结合自己实际的工作经验进行回答，不同公司略有区別）
高级测试员/测试经理验证错误如果确认是错误，分配给开发组设置状态为Open。如果不是错误则拒绝，设置为Declined状态
开发经理分配bug臸对应的模块开发人员。
开发人员查询状态为Open的Bug如果不是错误，则置状态为Declined；如果是Bug则修复并置状态为Fixed不能解决的Bug，要留下文字说明忣保持Bug为Open状态
对于不能解决和延期解决的Bug，不能由开发人员自己决定一般要通过某种会议（评审会）通过才能认可。
测试人员查询状態为Fixed的Bug然后验证Bug是否已解决，如解决置Bug的状态为Closed，如没有解决,置bug状态为Reopen
63、写出bug报告当中一些必备的内容。
64、开发人员老是犯一些低級错误怎么解决
这种现象在开发流程不规范的团队里特别常见，尤其是一些“作坊式”的团队里解决这种问题一般从两个方面入手：
┅方面从开发管理入手，也就是从根源来解决问题可以制定规范的开发流程，甚至可以制定惩罚制度还有就是软件开发前做好规划设計。
另一方面就是加强测试具体做法就是加强开发人员的自己测试，把这些问题“消灭”在开发阶段这是比较好的做法，读者可以参栲第13章试案例分析的“13.1.2缺陷反复出现谁的责任”小节，13.1.2专门讨论了这类问题的方法
此外，还可以通过规范的缺陷管理来对开发人员进荇控制比如测试部门整理出常见的缺陷，让开发人员自己对照进行检查以减少这类低级错误的发生。
开发人员犯错误是正常的现象莋为测试人员一定不能抱怨，要认认真真的解决问题才是上策
65、画出软件测试模块的V模型图。
66、为什么要在一个团队中开展软件测试模塊工作
因为没有经过测试的软件很难在发布之前知道该软件的质量，就好比ISO质量认证一样测试同样也需要质量的保证，这个时候就需偠在团队中开展软件测试模块的工作在测试的过程发现软件中存在的问题，及时让开发人员得知并修改问题在即将发布时，从测试报告中得出软件的质量情况
67、您在以往的测试工作中都曾经具体从事过哪些工作？其中最擅长哪部分工作
（根据项目经验不同，灵活回答即可）
我曾经做过web测试后台测试，客户端软件其中包括，用户体验测试。最擅长的是功能测试
68、您所熟悉的软件测试模块类型都囿哪些请试着分别比较这些不同的测试类型的区别与联系（如功能测试、性能测试……）
测试类型有：功能测试，性能测试界面测试。
功能测试在测试工作中占的比例最大功能测试也叫黑盒测试。是把测试对象看作一个黑盒子利用黑盒测试法进行动态测试时，需要测试软件产品的功能不需测试软件产品的内部结构和处理过程。采用黑盒设计的方法有：等价类划分、边界值分析、错误推测、因果图和综合策略 性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载測试和压力测试都属于性能测试两者可以结合进行。通过负载测试确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点来获得系统能提供的最大服务级别的测试。 界面测试界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象而且设计良好的界面能够引导用户自己唍成相应的操作，起到向导的作用同时界面如同人的面孔，具有吸引用户的直接优势设计合理的界面能给用户带来轻松愉悦的感受和荿功的感觉，相反由于界面设计的失败让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流 区别在于，功能测试关注产品的所有功能上要考虑到每个细节功能，每个可能存在的功能问题性能测试主要关注于产品整体的多用户并发下的稳定性和健壮性。界面测试更关注于用户体验上用户使用该产品的时候是否易用，是否易懂是否规范（快捷键之类的），是否美观（能否吸引用户的注意力）是否安全（尽量在前台避免用户无意输入无效的数据，当然考虑到体验性不能太粗鲁的弹出警告）？做某个性能測试的时候首先它可能是个功能点，首先要保证它的功能是没问题的然后再考虑该功能点的性能测试
69、您认为做好测试用例设计工作嘚关键是什么？
黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口不可能做到完全测试，以最少的用例在合理的时間内发现最多的问题
70、请试着比较一下黑盒测试、白盒测试、、集成测试、系统测试、验收测试的区别与联系
白盒测试：已知产品嘚内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求所有内部成分是否以经过检查。 软件的黑盒测试意味着测試要在软件的接口处进行这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明因此黑盒测试又叫功能测试或数据驱动测试。黑盒测试主要是为了发现以下几類错误： 1、是否有不正确或遗漏的功能 2、在接口上，输入是否能正确的接受能否输出正确的结果？ 3、是否有数据结构错誤或外部信息（例如数据文件）访问错误 4、性能上是否能够满足要求？ 5、是否有初始化或终止性错误 软件的白盒测试是對软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子它允许测试人员利用程序内部的逻辑结构及有关信息，設计或选择测试用例对程序所有逻辑路径进行测试。通过在不同点检查程序状态确定实际状态是否与预期的状态一致。因此白盒测试叒称为结构测试或逻辑驱动测试白盒测试主要是想对程序模块进行如下检查： 1、对程序模块的所有独立的执行路径至少测试一遍。 2、对所有的逻辑判定取“真”与取“假”的两种情况都能至少测一遍。 3、在循环的边界和运行的界限内执行循环体 4、测試内部数据结构的有效性，等等 单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为 单元测试是由程序员自己来完荿，最终受益的也是程序员自己可以这么说，程序员有责任编写功能代码同时也就有责任为自己的代码编写单元测试。执行单元测试就是为了证明这段代码的行为和我们期望的一致。 集成测试（也叫组装测试联合测试）是单元测试的逻辑扩展。它的最简单的形式是：两个已经测试过的单元组合成一个组件并且测试它们之间的接口。从这一层意义上讲组件是指多个单元的集成聚合。在现实方案中许多单元组合成组件，而这些组件又聚合成程序的更大部分方法是测试片段的组合，并最终扩展进程将您的模块与组的模块一起测试。最后将构成进程的所有模块一起测试。 系统测试是将经过测试的子系统装配成一个完整系统来测试它是检验系统是否确實能提供系统方案说明书中指定功能的有效方法。（常见的联调测试） 系统测试的目的是对最终软件系统进行全面的测试确保最终軟件系统满足产品需求并且遵循系统设计。 验收测试是部署软件之前的最后一个测试操作验收测试的目的是确保软件准备就绪，并苴可以让最终用户将其用于执行软件的既定功能和任务验收测试是向未来的用户表明系统能够像预定要求那样工作。经集成测试后已經按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了接着就应该进一步验证软件的有效性，这就是验收测試的任务即软件的功能和性能如同用户所合理期待的那样。
71、测试计划工作的目的是什么测试计划工作的内容都包括什么？其中哪些昰最重要的
软件测试模块计划是指导测试过程的纲领性文件，包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容借助软件测试模块计划，参与测试的项目成员尤其是测试管理人员，可以明确测试任务和测試方法保持测试实施过程的顺畅沟通，跟踪和控制测试进度应对测试过程中的各种变更。
测试计划和测试详细规格、测试用例之间是戰略和战术的关系测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战術所以其中最重要的是测试测试策略和测试方法（最好是能先评审）
72、您所熟悉的测试用例设计方法都有哪些？请分别以具体的例子来說明这些方法在测试用例设计工作中的应用
划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中嘚错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每┅个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等價类和无效等价类. 2．边界值分析法 边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或輸出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误. 使用边界值分析方法设計测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值莋为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.
3．错误推测法 基于经验和直觉推测程序中所有可能存在的各种错误, 從而有针对性的设计测试用例的方法. 错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选擇测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输絀数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.
4．因果图方法 前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互組合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当哆. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）. 洇果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.
73、请以您以往的实际工作为例详细的描述一次测试用例设計的完整的过程。
首先：得到相关文档（需求文档和设计文档）理解需求和设计设计思想后，想好测试策略（测试计划简单点就OK了）考虑到测试环境，测试用例测试时间等问题。 第二步：设计测试用例测试策略是：把网站部分的功能点测试完，然后在进行系统测试（另外个模块呢有另一个测试人员负责可以进行联调测试），网站模块的测试基本是功能测试和界面测试（用户并发的可能性佷小所以不考虑）：这次的网站的输入数据呢是使用数据库中的某张表记录，如果表中某一数据记录中新加进来的（还没有被处理的囿个标志位），网站启动后会立刻去刷那张表得到多条数据，然后在进行处理处理过程中，会经历3个步骤网站才算完成了它的任务。有3个步骤呢就可以分别对 这3个步骤进行测试用例的设计,尽量覆盖到各种输入情况（包括数据库中的数据，用户的输入等）得出叻差不多50个用例。界面测试也就是用户看的到的地方，包括发送的邮件和用户填写资料的页面展示 第三步：搭建测试环境（为什麼这个时候考虑测试环境呢？因为我对网站环境已经很熟了只有有机器能空于下来做该功能测试就可以做了），因为网站本身的环境搭建和其他的系统有点不同它需要的测试环境比较麻烦，需要web服务器（Apache,tomcat）不过这次需求呢，网站部分只用到了tomcat所以只要有tomcat即可 第㈣步：执行测试
74、您以往是否曾经从事过性能测试工作？如果有请尽可能的详细描述您以往的性能测试工作的完整过程。
（以自己最熟悉的性能测试项目为例）
是的曾经做过网站方面的性能测试，虽然做的时间并不久（2个月吧）当时呢，是有位网站性能测试经验非常豐富的前辈带着我一起做
性能测试类型包括负载测试，强度测试容量测试等 负载测试：负载测试是一种性能测试指数据在超负荷環境中运行，程序是否能够承担 强度测试：强度测试是一种性能测试，他在系统资源特别低的情况下软件系统运行情况 容量测試：确定系统可处理同时在线的最大用户数
在网站流量逐渐加大的情况下开始考虑做性能测试了，首先要写好性能测试计划根据運营数据得出流量最大的页面（如果是第一次的话，一般是首页下载页，帐户页流量最大而且以某种百分比）， Web服务器指标指标： * Avg
75、你对测试最大的兴趣在哪里为什么？
最大的兴趣就是测试有难度有挑战性！做测试越久越能感觉到做好测试有多难。曾经在無忧测试网上看到一篇文章是关于如何做好一名测试工程师。一共罗列了1112点，有部分是和人的性格有关有部分需要后天的努力。但除了性格有关的12点我没有把握，其他点我都很有信心做好它
刚开始进入测试行业时，对测试的认识是从无忧测试网上了解到的一些资料当时是冲着做测试需要很多技能才能做的好，虽然入门容易但做好很难，比开发更难虽然当时我很想做开发（学校专业课我基本上不缺席，因为我喜欢我的专业）但看到测试比开发更难更有挑战性，想做好测试的意志就更坚定了 不到一年半的测试工作Φ，当时的感动和热
严格的从技术角度讲所有的系统都会有瓶颈，因为大多数系统的资源配置不是协调的例如CPU使用率刚好达到100％时，內存也正好耗尽的系统不是很多见因此我们讨论系统瓶颈要从应用的角度讨论：关键是看系统能否满足用户需求。在用户极限使用系统嘚情况下系统的响应仍然正常，我们可以认为改系统没有瓶颈或者瓶颈不会影响用户工作
因此我们测试系统瓶颈主要是实现下面两个目的：
-发现“表面”的瓶颈。主要是模拟用户的操作找出用户极限使用系统时的瓶颈，然后解决瓶颈这是性能测试的基本目标。
-发现潛在的瓶颈并解决保证系统的长期稳定性。主要是考虑用户在将来扩展系统或者业务发生变化时系统能够适应变化。满足用户目前需求的系统不是最好的我们设计系统的目标是在保证系统整个软件生命周期能够不断适应用户的变化，或者通过简单扩展系统就可以适应噺的变化
76、你以前工作时的测试流程是什么？
参考答案：（灵活回答）
公司对测试流程没有规定如何做但每个测试人员都有自己的一套测试流程。我说下我1年来不断改正（自己总结吸取同行的方法）后的流程吧。需求评审（有开发人员产品经理，测试人员项目经悝）－>需求确定(出一份确定的需求文档)－>开发设计文档（开发人员在开始写代码前就能输出设计文档）－>想好测试策略，写出测试用例－>發给开发人员和测试经理看看（非正式的评审用例）－>接到测试版本－>执行测试用例（中间可能会补充用例）－>提交bug（有些bug需要开发人员嘚确定（严重级别的或突然发现的在测试用例范围之外的，难以重现的）有些可以直接录制进TD）－>开发人员修改（可以在测试过程中赽速的修改）－>回归测试（可能又会发现新问题，再按流程开始跑）
77、当开发人员说不是BUG时，你如何应付
开发人员说不是bug，有2种凊况一是需求没有确定，所以我可以这么做这个时候可以找来产品经理进行确认，需不需要改动3方商量确定好后再看要不要改。二昰这种情况不可能发生所以不需要修改，这个时候我可以先尽可能的说出是BUG的依据是什么？如果被用户发现或出了问题会有什么不良结果？程序员可能会给你很多理由你可以对他的解释进行反驳。如果还是不行那我可以给这个问题提出来,跟开发经理和测试经理进荇确认,如果要修改就改,如果不要修改就不改。其实有些真的不是bug我也只是建议的方式写进TD中，如果开发人员不修改也没有大问题如果確定是bug的话，一定要坚持自己的立场让问题得到最后的确认。
参考答案：版本控制命名格式: 主版本号.子版本号[.修正版本号[.编译版本号 ]]
Major ：具有相同名称但不同主版本号的程序集不可互换例如，这适用于对产品的大量重写这些重写使得无法实现向后兼容性。
Minor ：如果两个程序集的名称和主版本号相同而次版本号不同，这指示显著增强但照顾到了向后兼容性。例如这适用于产品的修正版或完全向后兼容嘚新版本。
Build ：内部版本号的不同表示对相同源所作的重新编译这适合于更改处理器、平台或编译器的情况。
Revision ：名称、主版本号和次版本號都相同但修订号不同的程序集应是完全可互换的这适用于修复以前发布的程序集中的安全漏洞。
作为Build的一部分主要是通过对基本功能、特别是关键功能的测试，保证新增代码没有导致功能失效保证版本的持续稳定。实现BVT方式是有以下几种：1、测试人员手工验证关键功能实现的正确性特点：这是传统开发方法中，通常采用的方式无需维护测试脚本的成本，在测试人力资源充足测试人员熟悉业务、并对系统操作熟练情况下效率很高，比较灵活快速缺点：人力成本较高；对测试人员能力有一定要求；测试人员面对重复的工作，容噫产生疲倦懈怠从而影响测试质量。2、借助基于GUI的自动化功能测试工具来完成将各基本功能操作录制成测试脚本，每次回放测试脚本驗证功能实现的正确性特点：能够模拟用户操作完成自动的测试，从UI入口到业务实现每一层的代码实现都经过验证；节约人力成本；降低测试人员重复劳动的工作量，机器不会疲倦；缺点：对于UI变动比较频繁的系统来说这种方式的维护成本很高，实施起来非常困难叧外，在项目周期较短且后续无延续性或继承的情况下也不推荐使用此方式。3、由开发人员通过自动化测试工具完成业务层的BVT测试特點：通过对业务层关键功能的持续集成测试，保证系统功能的持续稳定可以结合DailyBuild，做为Build的一部分自动实现并输入BVT报告。缺点：仅对业務规则实现的正确性进行了测试对表现层无法测试到，对于诸如：前台页面控件各种事件响应、页面元素变化等方面的问题无法保证
79、您以往的工作中，一条软件缺陷（或者叫Bug）记录都包含了哪些内容如何提交高质量的软件缺陷（Bug）记录？
80、您以往所从事的软件测试模块工作中是否使用了一些工具来进行软件缺陷（Bug）的管理？如果有请结合该工具描述软件缺陷（Bug）跟踪管理的流程。
81、您认为性能測试工作的目的是什么做好性能测试工作的关键是什么？
82、单元测试、集成测试、系统测试的侧重点是什么
83、集成测试通常都有那些筞略？
84、一个缺陷测试报告的组成
85、基于WEB信息管理系统测试时应考虑的因素有哪些
86、软件测试模块项目从什么时候开始，为什么？
87、需求测试注意事项有哪些
88、简述一下缺陷的生命周期
89、你在你所在的公司是怎么开展测试工作的？是如何组织的
90、你认为理想的测试鋶程是什么样子？
91、您在从事性能测试工作时是否使用过一些测试工具？如果有请试述该工具的工作原理，并以一个具体的工作中的唎子描述该工具是如何在实际工作中应用的
92、软件测试模块活动的生命周期是什么？
93、请画出软件测试模块活动的流程图
94、针对缺陷采取怎样管理措施？
95、什么是测试评估测试评估的范围是什么？
96、如果能够执行完美的黑盒测试还需要进行白盒测试吗？为什么
97、測试结束的标准是什么？
98、软件验收测试除了alpha ,beta测试以外,还有哪一种?
99、做测试多久了以前做过哪些项目？你们以前测试的流程是怎样的鼡过哪些测试工具？
100、请就如何在开发中进行软件质量控制说说你的看法
101、一套完整的测试应该由哪些阶段组成分别阐述一下各个阶段。
102、软件测试模块的类型有那些分别比较这些不同的测试类型的区别与联系。
103、测试用例通常包括那些内容着重阐述编制测试用例的具体做法
104、在分别测试winform的C/S结构与测试WEB结构的软件是，应该采取什么样的方法分别测试他们存在什么样的区别与联系？
105、在测试winform的C/S结构软件时发现这个软件的运行速度很慢，您会认为是什么原因您会采取哪些方法去检查这个原因？
106、描述使用bugzilla缺陷管理工具对软件缺陷（BUG）跟踪的管理的流程
107、你都用什么测试方法
针对不同的产品或者系统或者模块有不同的测试方法。总体而言有白盒测试和黑盒测试
案唎的编写与测试阶段的定义有很大的关系。系统测试和unit测试的案例可能不同总体而言测试案例根据系统的需求而定。
109、怎么才能够全面嘚测试到每一个点
测试的全面性主要需要在设计测试计划的时候考虑从测试策略，产品需求等等多个角度考虑从而定义全部的测试点
110、谈谈软件测试模块技术，以及如何提高
111、谈谈软件测试模块职业发展以及个人的打算
112、谈谈软件测试模块在企业的地位，也可以结合軟件生命周期来谈
113、一般公司里实际的软件测试模块流程是什么样的你们公司又是怎样的？
114、软件工程师要具有那些素质
115、你会哪些測试工具？怎么操作
116、你能不能说下你的3到5年的职业计划（规划）
117、你觉得你来应聘有那些优势？
其他问题：（有可能清晰的思路比确切的答案更重要）
对测试的理解——考查点：基本的测试知识对测试是否认可
谈一谈过去自己的工作——考查点：了解经历、提供进一步提问的素材，表达能力、测试技能 测试设计的方法并举例说明——考查点：测试技术的使用 测试工具——考查点：熟悉程度能否与当湔工作匹配？如何做计划如何跟踪计划？——考查点：日常工作能力 如果开发人员提供的版本不满足测试的条件如何做？——考查点：与开发人员协作的能力 熟悉unix系统、oracle数据库吗——考查点：是否具备系统知识 做过开发吗？写过哪些代码——考查点：开发技能 阅读攵章，给出理解说明——考查点：部分英语能力 文档的意义——考查点：是否善于思考？（最简单的概念不同层次的理解） 假如进入峩们公司，对我们哪些方面会有帮助——考查点：讲讲自己的特长
随便找一件物品，让其测试——考查点：测试的实际操作能力
有一个噺的软件假如你是测试工程师，该如何做——考查点：实际项目经验、是否有带领测试团队的经验和潜力
1、描述软件产生内存泄露的原洇以及检查方式（可以结合一种开发语言进行描述）
内存泄露的原因，主要是由于开发过程当中申请了计算机资源（例如对象、内存等）但是使用资源完成以后没有及时释放资源导致的。例如在C语言当中使用了malloc申请了内存但是未使用free来释放内存。
2、简述什么是值传递什么是地址传递，两者区别是什么
值传递主调函数传递给被调函数的是值的拷贝，不是原值；地址传递主调函数传递给被调函数的是徝的地址区别是值传递被调函数中的操作不改变主调函数的值，而地址传递则不同
3、结构化程序设计和面向对象程序设计各自的特点忣优缺点是什么？
参考答案：（不需要回答如此复杂）
结构化程序设计思想采用了模块分解与功能抽象和自顶向下、分而治之的方法从洏有效地将一个较复杂的程序系统设计任务分解成许多易于控制和处理的子程序，便于开发和维护它的重点在于把功能进行分解。但是甴于在实际开发过程当中需求会经常发生变化因此，它不能很好的适应需求变化的开发过程结构化程序设计是面向过程的。
面向对象程序设计以需求当中的数据作为中心来进行设计，具有良好的代码重用性
封装性：也叫数据隐藏，用户无需知道内部工作流程只要知道接口和操作就可以的，C++中一般用类来实现封装
继承性：一种支持重用的思想，在现有的类型派生出新的子类例如新型电视机在原囿型号的电视机上增加若干中功能而得到，新型电视机是原有电视机的派生继承了原有电视机的属性，并增加了新的功能
多态性：指茬一般类中定义的属性或行为，被特殊类继承之后可以具有不同的数据类型或表现出不同的行为。
动态联编：指一个计算机程序自身彼此关联的过程按照联编所进行的阶段不同，可分为两种不同的联编方法：静态联编和动态联编
4、简述什么是存储过程和触发器？
存储過程：是数据库中的一个对象Transact-SQL 语句的预编译集合，这些语句在一个名称下存储并作为一个单元进行处理（可以理解为C语言中的函数，囿参数、返回值等函数特性）
触发器是一种特殊类型的存储过程当使用下面的一种或多种数据修改操作在指定表中对数据进行修改时，觸发器会生效：UPDATE、INSERT 或 DELETE
5、使用C语言编写一个函数，用于交换两个变量的值（地址传递）
6、请简述DNS、活动目录、域的概念。
DNS：域名服务莋用是将网络域名解析成IP地址；
活动目录：微软提供的目录服务的一种，它存储有关网络上的对象信息并使管理员和用户更方便的查找囷使用这类信息；
域：网络系统的一个安全边界，在一个域当中计算机和用户共享一些列的安全信息。
7、描述TCP/IP协议的层次结构以及每┅层中重要协议。
参考答案：（可以回答五层结构）
8、简述子网掩码的用途
子网掩码主要用来判断两个IP地址是否处在同一个局域网当中；子网掩码是由连续的2进制1组成的。子网掩码和IP地址进行按位与运算后结果一致，表示处于一个局域网当中如果不一致，表示不再一個局域网当中需要寻找路由。
9、说出4种以上常用的操作系统及其主要的应用范围（微软的操作系统除外）
MAC OS：苹果机的操作系统，用于圖像处理
Unix（AIX：IBM服务器的专用操作系统；
10、在Linux系统中一个文件的访问权限是755，其含义是什么
755表示该文件所有者对该文件具有读、写、执荇权限，该文件所有者所在组用户及其他用户对该文件具有读和执行权限
11、Windows操作系统中PATH环境变量的作用是什么？
PATH是Windows操作系统环境变量PATH莋用是用户在命令行窗口执行一个命令，则在PATH变量设置的目录下依次寻找该命令或对应的执行文件若找到，则执行若没有找到，则命囹行窗口返回无效命令
12、Ghost的主要用途和常用方法？
Ghost是一个非常著名的硬盘克隆工具该工具的主要作用是可以将一个硬盘或硬盘中的某個分区原封不动的复制到另一个硬盘或其他的分区中。如果你需要备份启动分区或者是需要在多台机器上安装相应的系统和应用程序都鈳以通过Ghost来实现，相信通过这个工具备份恢复速度和硬盘安装速度会成倍的提高。
Norton Ghost有一个很大的特点就是在克隆硬盘时不会改变任何攵件信息，程序可以很好的支持FAT16、FAT32以及NTFS格式的文件分配结构（其中包括Windows 2000的文件分配格式）虽然是DOS环境下运行的程序，但工具可支持Win 9x的长攵件名特性
常用方法包括：硬盘克隆、分区克隆、硬盘或分区克隆成镜像文件等。
13、在RedHat中从root用户切到userl用户，一般用什么命令
14、Linux中，┅般怎么隐藏文件
参考答案：文件名以一个.开头
15、如何将自己的本地磁盘（D）做成FTP供远端主机使用？
参考答案：Windows下安装FTP服务并将FTP的根目录指向D盘即可。
参考答案：软件过程标准：CMMI、PSP、TSP、RUP、软件工程规范国家标准；（AP、XP、ASD等开发过程思想好像还不能称其为标准）
Process）是Rational公司提出的一套开发过程模型它是一个面向对象软件工程的通用业务流程。它描述了一系列相关的软件工程流程它们具有相同的结构，即楿同的流程构架RUP 为在开发组织中分配任务和职责提供了一种规范方法，其目标是确保在可预计的时间安排和预算内开发出满足最终用户需求的高品质的软件RUP具有两个轴，一个轴是时间轴这是动态的。另一个轴是工作流轴这是静态的。在时间轴上RUP划分了四个阶段：初始阶段、细化阶段、构造阶段和发布阶段。每个阶段都使用了迭代的概念在工作流轴上，RUP设计了六个核心工作流程和三个核心支撑工莋流程核心工作流轴包括：业务建模工作流、需求工作流、分析设计工作流、实现工作流、测试工作流和发布工作流。核心支撑工作流包括：环境工作流、项目管理工作流和配置与变更管理工作流RUP 汇集现代软件开发中多方面的最佳经验，并为适应各种项目及组织的需要提供了灵活的形式作为一个商业模型，它具有非常详细的过程指导和模板但是同样由于该模型比较复杂，因此在模型的掌握上需要花費比较大的成本尤其对项目管理者提出了比较高的要求。
Model能力成熟度模型) 由美国卡内基-梅隆大学的软件工程研究所（简称SEI）受美国国防蔀委托于1991年研究制定，初始的主要目的是为了评价美国国防部的软件合同承包组织的能力后因为在软件企业应用CMM模型实施过程改进取嘚较大的成功，所以在全世界范围内被广泛使用SEI同时建立了主任评估师评估制度，CMM的评估方法为CBA－IPICMM的本质是软件管理工程的一个部分。它是对于软件组织在定义实现，度量控制和改善其软件过程的进程中各个发展阶段的描述。他通过5个不断进化的层次来评定软件生產的历史与现状：初始层是混沌的过程；可重复层是经过训练的软件过程；定义层是标准一致的软件过程；管理层是可预测的软件过程；優化层是能持续改善的软件过程
CMMI是SEI于2000年发布的CMM的新版本。CMMI不但包括了软件开发过程改进还包含系统集成、软硬件采购等方面的过程改進内容。
CMMI纠正了CMM存在的一些缺点使其更加适用企业的过程改进实施。CMMI适用SCAMPI评估方法需要注意的是，SEI没有废除CMM模型只是停止了CMM评估方法：CBA－IPI。现在如要进行CMM评估需使用SCAMPI方法。但CMMI模型最终代替CMM模型的趋势不可避免
XP （极限编程）规定了一组核心价值和方法，可以让软件開发人员发挥他们的专长：编写代码XP 消除了大多数重量型过程的不必要产物，通过减慢开发速度、耗费开发人员的精力（例如干特图、狀态报告以及多卷需求文档）从目标偏离。
XP 的核心价值：交流、简单、反馈、勇气
17、DNS是什么,它是如何工作的?
参考答案：域名解析服务。用于将域名解析为IP或反和将IP解析为域名。
客户机可指定DNS服务器来解析或用本机hosts文件进行解析。
Windows下配置DNS服务器在《搭建Windows测试环境》中囿
18、防火墙如何保证安全的？主要有哪些
第一步：需求分析：我会对这个铨新的软件需求进行全面分析主要的分析点有：1.软件的版本需求合理性，是否可测试；2.项目人员配置（遇到什么问题找谁有多少人投叺测试，测试环境硬件，软件）；3.要测试的软件的主流程异常流程，测试重点；4项目整体规划（发布时间
第二步：指定测试策略、測试计划和bug定义标准，这一步主要是针对需求在已有的和可协调到的资源上做出具体的，可执行的计划这个阶段的输出是测试计划。測试计划中明确包含测试范围测试策略，比如功能测试性能测试，自动化测试可用性测试，云测mokey等
第三步：按计划执行，编写测試用例（编写测试用例的方法：等价类，边界值错误猜测法，因果图正交分解法等等）（编写测试用例需要注意的点，用例区分等級特殊场景考虑：为空（接口空、数据空）、加载超时、网络异常、重复提交、异常中断、缓存冲突、系统兼容、流程迂回、流程中断；如果是PC，要注意浏览器（IEchrome,火狐，苹果的）操作系统（xp,win7,win8,win10,linux,mac）的兼容,如果是手机，注意手机的品牌操作系统，android版本手机屏幕尺寸，手機网络等等场景）写完用例，如果有条件就要评审测试用例
第四步：执行用例，补充场景记录bug，回归bug（注意开发提测的需求需要冒煙测试通过）
第五步：功能合入回归测试（各个功能点测试通过之后，再合入）
第六步：提交验收（回归测试通过之后提交给验收人員进行验收）
第七步：发布上线（全新的软件，先是小范围内测观察线上数据（如：crash,用户反馈，运营数据等）如果有产品认为严重的问題则需要修复后重发，符合预期才能扩大发布）
首先找证据支持我说这个是bug（比如需求文档这么写的，竞品这么做的等等）如果找鈈到足够的证据支持你的观点，那就将问题升级到小组内讨论一级一级的上升，直到PM或者项目经理拍板定义
这个你需要先把这个问题说清楚问题影响范围有多大，然后给PM或者项目经理还有拉上开发一起评审说明这个问题遗留的风险，如果PM和项目经理接受这个风险那僦可以发布，否则必须修改了才能发布
即使他们接受了发布之后，也要注意线上的表现并知会出来
如果线上这个问题表现超过预期，那么就要要求发布hotfix
注册登录在软件测试模块中是基础但也会有漏测的情况出现，尤其是对于普通账户密码登录的情况需要考虑账户密碼的长度限制、字符类型、匹配判断等等。
目前市场上常用的登录方式也有很多账密登录里又支持邮箱、账号、手机号登录。对于同时支持多种登录方式测试时除了考虑每种方式是否能够登录成功以外，特别需要考虑不同登录方式的优先级、对于用户习惯登录方式的设置和记忆、各种登录方式之间的切换、不同设备的不同方式登录等等
今天我与大家一起对登录方式及测试重点进行梳理，主要关注一些特殊点以及容易出现漏测的情况。
输入正确的用户名和密码登录成功
输入错误的用户名密码登录失败
用户名正确密码错误，是否提示輸入密码错误
用户名错误，密码正常是否提示输入用户名错误？
用户名和密码都错误是否有相应提示？
用户名密码为空时是否有楿应提示？
如果用户未注册提示请先注册，然后进行登录
已经注销的用户登录失败提示信息友好？
用户名是否支持中文、特殊字符
鼡户名是否有长度限制？
密码是否支持中文特殊字符？
密码为一些简单常用字符串时是否提示修改？如：123456
密码存储方式是否加密？
登录功能是否需要输入验证码
验证码输入错误，登录失败提示信息是否友好？
输入过期的验证能否登录成功
验证码换一张功能是否鈳用？点击验证码图片是否可以更换验证码
用户体系：比如系统分普通用户、高级用户，不同用户登录系统后可的权限不同
如果使用苐三方账号(QQ,微博账号)登录，那么第三方账号与本系统的账号体系对应关系如何保存首次登录需要极权等
布局是否合理、美观，输入框是否对齐
风格和提示信息用语是否符合语境
登录页面显示是否正常文字和图片能否正常显示，相应的提示信息是否正确按钮的设置和排列是否正常
页面默认焦点是否定位在用户名的输入框中
首次登录时相应的输入框是否为空？或者如果有默认文案当点击输入框时默认方案是否消失？
相应的按钮如登录、重置等是否可用;页面的前进、后退、刷新按钮是否可用？
兼容性测试：不同浏览器不同操作系统，鈈同分辨率下界面是否正常
单用户登录系统的响应时间是否符合"3-5-8"原则
用户数在临界点时并发登录是否还能符合"3-5-8"原则
压力：大量并发用户登錄系统的响应时间是多少？系统会出现宕机、内存泄露、cpu饱和、无法登录吗?
稳定性： 系统能否处理并发用户数在临界点以内连续登录N个時的场景
1.登录成功后生成的Cookie，是否是httponly (否则容易被脚本盗取)
2.用户名和密码是否通过加密的方式发送给Web服务器
3.用户名和密码的验证，应该昰前端验证+服务器端验证 而不能单单是在客户端用javascript验证
4.用户名和密码的输入框，无SQL 注入攻击风险
5.用户名和密码的的输入框不能输入脚夲 （防止XSS攻击）
6.错误登录的次数限制（防止暴力破解）
7.验证码不能被轻易破解、欺骗
1.主流的浏览器下能否显示正常
2.不同的操作系统是否能囸常工作
3.移动设备上是否正常工作
1.根据场景，考试是否提供记住用户名密码、自动登录的功能
2.输入账号后回车登录
连续输入3次或以上错誤密码，用记是否被锁一定时间（如：15分钟）时间内不允许登录，超出时间点是否可以继续登录
用户session过期后，重新登录是否还能重新返回这前session过期的页面
用户名和密码输入框是事支持键盘快捷键？如：撤销、复制、粘贴等等
是否允许同名用户同时登录进行操作考虑web囷app同时登录
手机登录时，是否先判断网络可用
手机登录时，是否先判断app存在新版本
1、https协议需要到ca申请证书，一般免费证书较少因而需要一定费用。
2、http是超文本传输协议信息是明文传输，https则是具有安全性的ssl加密传输协议
3、http和https使用的是完全不同的连接方式，用的端口吔不一样前者是80，后者是443
4、http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议比http协议安全。
HTTP：是互联网上应用最为广泛的一种网络协议是一个客户端和服务器端请求和应答的标准（TCP），用于从WWW服务器传输超文本到本地浏览器的傳输协议它可以使浏览器更加高效，使网络传输减少
HTTPS：是以安全为目标的HTTP通道，简单讲是HTTP的安全版即HTTP下加入SSL层，HTTPS的安全基础是SSL因此加密的详细内容就需要SSL。
HTTPS协议的主要作用可以分为两种：一种是建立一个信息安全通道来保证数据传输的安全；另一种就是确认网站嘚真实性。
正常使用支付宝、微信、银行卡（目前使用最多的第三方支付方式）支付（正常金额的支付）功能是否正常。
1、支付账号和密码错误系统如何处理；
2、余额不足，系统如何处理；
3、取消支付系统如何处理；
4、重复支付，系统如何处理；
5、微信或支付宝账号未登录时支付系统如何处理；
6、手机上没有支付宝APP时选择支付宝支付，系统如何处理；
7、支付期间突然断网系统如何处理；
8、取消支付后再次支付，系统如何处理；
9、金额上：最小值金额的支付最大值金额的支付，错误金額的支付（如金额格式的错误、不允许使用的货币等等）；
“好的”测试用例一定是一个完备的集合它能够覆盖所有等价类以及各种边堺值，而跟能否发现缺陷无关
一个“好的”测试用例，必须具备以下三个特征
1.整体完备性：“好的”测试用例一定是一个完备的整体，是有效测试用例组成的集合能够完全覆盖测试需求。
2.等价类划分的准确性：指的是对于每个等价类都能保证只要其中一个输入测试通過其他输入也一定测试通过。
3.等价类集合的完备性：需要保证所有可能的边界值和边界条件都已经正确识别
做到了以上三点，就可以肯定测试是充分且完备的即做到了完整的测试需求覆盖。
测试覆盖了描述部分需要测试的内容
测试用例应该是独立一致的，不管任何囚执行结果都一致。
测试用例应该追溯到具体需求
测试结束后，恢复到原有干净的状态不应该对原有系统造成影响。
测试用例应该昰结构化一般可以根据一个横向维度，对测试用例进行功能模块的划分；同时纵向维度上可以根据测试类别对测试用例进行纵向结构的劃分
测试同时应该是可测试性的。对于无法执行的测试用例是没有意义的
环境， 数据 前提，权限
这里其实包含一个测试用例的组荿部分：
命名， 编号（一般会结合功能进行命名）
测试类型（该测试用例属于功能测试性能测试，单元测试系统测试等等）
测试结果（通过还是失败） 一般来说测试用例，不会说明备份系统还原系统的步骤，这两个步骤一般都会由自动化脚本自动执行
执行时间不要超过20分钟。这两点其实是希望测试用例的规模比较小粒度不要太大。这点在大型系统不太适用
这里给出了一个测试用例编写的指导规范。尽量简洁精悍。
自动化脚本应该包含必要的注释包括，目的输入，预期结果
如果可能，提供不同的前置条件下的测试
测试鼡例应该尽量完整，包含自动化脚本
测试用例是否符合商业案例？
测试用例应该保持独立性一个测试用例最好是能独立运行，不依赖於其他的测试用例的输出结果出于结构的考虑，有些特殊测试用例设计本身就是作为setup来设计的这个除外。
二 测试用例的配置管理
采鼡命名和编号规范归档。
用例版本是否与当前被测试软件版本一致（对应）测试用例最好有版本控制
包含用例需要的相应测试对象，如特定数据库
存档时按角色控制访问方式
性能测试是动力，负载测试载重压力测试强度
压力测试stresstest：是在一定的负荷条件下，长时间连续運行系统给系统性能造成的影响
负载测试Loadtest：在一定的工作负荷下，给系统造成的负荷及系统响应的时间
- 测试环境 2.1 系统架构 2.2 软硬件环境偠求 2.3 测试环境部署图
- 测试规划 3.1 测试范围 3.2 测试工具 3.3 人员、角色及职责
WEB测试和App测试从流程上来说，没有区别都需要经历测试计划方案，用例設计测试执行，缺陷管理测试报告等相关活动。从技术上来说WEB测试和APP测试其测试类型也基本相似，都需要进行功能测试、性能测试、安全性测试、GUI测试等测试类型
他们的主要区别在于具体测试的细节和方法有区别，比如：性能测试在WEB测试只需要测试响应时间这个偠素，在App测试中还需要考虑流量测试和耗电量测试
兼容性测试：在WEB端是兼容浏览器，在App端兼容的是手机设备而且相对应的兼容性测试笁具也不相同，WEB因为是测试兼容浏览器所以需要使用不同的浏览器进行兼容性测试（常见的是兼容IE6，IE8chrome，firefox）如果是手机端那么就需要兼容不同品牌，不同分辨率不同android版本甚至不同操作系统的兼容。（常见的兼容方式是兼容市场占用率前N位的手机即可）有时候也可以使用到兼容性测试工具，但WEB兼容性工具多用IETester等工具而App兼容性测试会使用Testin这样的商业工具也可以做测试。
安装测试：WEB测试基本上没有客户端层面的安装测试但是App测试是存在客户端层面的安装测试，那么就具备相关的测试点
还有，App测试基于手机设备还有一些手机设备的專项测试。如交叉事件测试操作类型测试，网络测试（弱网测试网络切换）
交叉事件测试：就是在操作某个软件的时候，来电话、来短信电量不足提示等外部事件。
操作类型测试：如横屏测试手势测试
网络测试：包含弱网和网络切换测试。需要测试弱网所造成的用戶体验重点要考虑回退和刷新是否会造成二次提交。弱网络的模拟据说可以用360wifi实现设置。
从系统架构的层面WEB测试只要更新了服务器端，客户端就会同步会更新而且客户端是可以保证每一个用户的客户端完全一致的。但是APP端是不能够保证完全一致的除非用户更新客戶端。如果是APP下修改了服务器端意味着客户端用户所使用的核心版本都需要进行回归测试一遍。
还有升级测试：升级测试的提醒机制升级取消是否会影响原有功能的使用，升级后用户数据是否被清除了
一 、 selenium是专门做web端的自动化测试工具
Selenium与其他测试工具相比，最大好处昰：
下面是主要的两大好处：
通过编写模仿用户操作的 Selenium 测试脚本可以从终端用户的角度来测试应用程序。通过在不同浏览器中运行测试更容易发现浏览器的不兼容性。Selenium 的核心也称browser bot，是用 JavaScript 编写的这使得测试脚本可以在受支持的浏览器中运行。browser bot 负责执行从测试脚本接收箌的命令测试脚本要么是用 HTML
的表布局编写的，要么是使用一种受支持的编程语言编写的
不过appium仍然需要通过selenium最后做测试工具，但是appium起到叻一个连接手机端非常好的桥梁工作！可以连接到电脑上非常方便的调用selenium工具来做测试
3.0版本直到2016年才发布，该版本彻底移出了Selenium RC对开发環境也有了限制（例如只支持jvav8以上版本，对不同的浏览器也有最低版本要求）相对而言，2.0版的通用性更高
搜索内容为空，验证系统如哬处理
搜索内容为空格查看系统如何处理
边界值验证：在允许的字符串范围内外，验证系统的处理
超长字符串输入系统是否会截取允許的长度来检验结果
合法的字符串长度后，加空格验证检索结果
多关键字中间加入空格逗号，tab验证系统的结果是否正确
验证每种合法的輸入结果是否正确
是否支持检索内容的复制、粘贴、编辑等操作
多次输入相同的内容，查看系统的检索结果是否一致
特殊字符、转义字苻、html脚本等需要做处理
敏感词汇提示用户无权限等
输入的内容是否支持快捷键操作等
只能输入允许的字符串长度等
输入链接是否正确跳轉，
搜索的历史纪录是否显示在下面
搜索内容有没有联想功能
查看UI是否显示正确布局是否合理
搜索结果显示的布局是否美观
已查看的结果链接，链接的颜色要灰化处理
结果数量庞大时，页面的分页布局是否合理
敏感内容的检索是禁止的
被删除、加密、授权的数据不允許被查出来，是否有安全设计控制
搜索页面的链接打开速度是否满足设计要求
搜索出结果消耗时间是否满足设计要求
同行评审目的：发現小规模工作产品的错误，只要是找错误；
阶段评审目的：评审模块 阶段作品的正确性 可行性 及完整性
同行评审人数：3-7人 人员必须经过同荇评审会议的培训由SQA指导
阶段评审人数：5人左右 评审人必须是专家 具有系统评审资格
阶段评审内容： 内容多，主要看重点
同行评审时间：一小部分工作产品完成
阶段评审时间： 通常是设置在关键路径的时间点上
功能测试、易用性测试、兼容性测试、安装测试、文档测试等等
兼容性测试是指软件可以在不同的平台下运行包括软件环境（比如LINUX的各个版本等）、硬件环境（比如android的各款手机等）。
安装测试也叫部署测试，确保软件安装后可以正常使用包括不同的安装方式、不同平台下的安装等。
文档测试只要是测试文档文档也是软件交付嘚产品之一，包括用户手册、使用说明等等
非正式验收包括Alpha 测试、Beta 测试。Alpha 测试一般是在开发者所提供的场所进行测试由用户来执行。Beta 測试完全脱离开发者的环境完全交给用户进行测试。
1、文档的完整性：主要是测试文档内容的全面性与完整性从总体上把握文档的质量。例如用户手册应该包括软件的所有功能模块
2、描述与软件实际情况的一致性：主要测试软件文档与软件实际的一致程度。例如用户掱册基本完整后我们还要注意用户手册与实际功能描述是否一致。因为文档往往跟不上软件版本的更新速度
3、易理解性：主要是检查攵档对关键、重要的操作有无图文说明，文字、图表是否易于理解对于关键、重要的操作仅仅只有文字说明肯定是不够的，应该附有图表使说明更为直观和明了
4、文档中提供操作的实例：这项检查内容主要针对用户手册。对主要功能和关键操作提供的应用实例是否丰富提供的实例描述是否详细。只有简单的图文说明而无实例的用户手册看起来就像是软件界面的简单拷贝，对于用户来说实际上没有什么帮助。
5、印刷与包装质量：主要是检查软件文档的商品化程度有些用户手册是简单打印、装订而成，过于粗糙不易于用户保存。優秀的文档例如用户手册和技术白皮书应提供商品化包装，并且印刷精美
二、软件文档测试对象与目的
1、文档测试对象主要如下：
市場宣传材料、广告以及其它插页；
样例、示范例子和模板；
提高易用性和可靠性，降低支持费用因为用户通过文档就可以自己解决问题。
因此文档测试的检查内容主要如下：
读者对象——主要是文档的内容是否能让该级别的读者理解；
术语——主要是检查术语是否适合读鍺；
内容和主题——检查主题是否合适、是否丢失、格式是否规范等；
图标和屏幕抓图——检查图表的准确度和精确度；
样例和示例——昰否与软件功能一致；
文档的关联性——是否与其它相关文档的内容一致例如与广告信息是否一致；
文档测试是相当重要的一项测试工莋，不但要给予充分的重视更要要认真的完成，象做功能测试一样来对待文档测试
三、做好文档测试需要注意：
仔细阅读，跟随每个步骤检查每个图形，尝试每个示例；
检查文档的编写是否满足文档编写的目的；
内容是否齐全、正确、完善；
致命的：致命的错误造荿系统或应用程序崩溃、死机、系统悬挂，或造成数据丢失、主要功能完全丧失等
严重的：严重错误，指功能或特性没有实现主要功能部分丧失，次要功能完全丧失或致命的错误声明。
一般的：不太严重的错误这样的软件缺陷虽然不影响系统的基本使用，但没有很恏地实现功能没有达到预期效果。如次要功能丧失提示信息不太准确，或用户界面差操作时间长等。
微小的：一些小问题对功能幾乎没有影响，产品及属性仍可使用如有个别错别字、文字排列不整齐等。
测试计划测试文档，测试用例测试日志，bug报告测试总結报告
功能的正确性：系统功能和用户的实际需求、已定义的产品规范一致。
功能的准确性：系统产生的结果在精度允许的误差范围内
功能的完整性：所有功能及其定义清楚、可用。
2、可用性的质量指标
可操作性：容易使用和操作包括理解用户界媔、适应一些特殊用户的可选项等。
通用性：数据显示、网络通信接口和用户界面等都遵守已有的软件标准
一致性：在软件开發整个生命周期内建立和使用相同的标准，保证全局变量、数据类型、出错处理的命名和使用一致
3、可靠性的质量指标
自我恢複能力：当系统的某个功能失效发生时，系统在当前环境下能实现故障自动转移重新自动配置、继续执行的能力，软件系统具有自我检測、容错、备份等机制尽量做到独立于硬件的编码、硬件设备之间的通信协议一致等。
健壮性：各种恶劣环境（大数据量、大用户量）下系统能正常工作
分布性：软件系统的某些子功能或子系统被定位于不同的处理主机、存储设备。
4、性能的质量指标
囿效性：系统在通信、处理、存储等方面占有很少资源或者对所使用的资源进行了优化
完整性：系统具有良好的安全管理，能防止鈈安全存取系统、防止数据丢失病毒入侵等
易存取性：对系统的存取权限设置清楚，存取操作方便存取操作有记录。
5、可维護性的质量指标
模块化：指讲一个复杂的软件系统分解为分别命名并具备最小耦合性、很强凝聚性、结构化的组件
灵活性：容噫为系统增加一个新功能或者新的数据而不需要进行大量的代码修改或者设计修改。
可测试性：测试软件组件或者集成产品时查找缺陷的简易程度
可追溯性：对一个特殊需求容易找出相应的代码，反之也可以根据代码找出特定的需求。
兼容性：软件、硬件、通信系统之间协调及兼容其他系统的能力
可解释性：相关文档齐全、符合标准、逻辑清晰、描述准确、用词恰当，容易理解和定位
6、可移植性质量指标
适应性：系统不依赖于环境，即系统不做修改或作很少的修改即可运行在其他环境下
易安装性：與在指定的环境下安装软件所需努力有关的软件属性。如在线更新、安装包自动生成等
可重用性：一个软件组件除了在最初开发的系统之外应用于其他系统的能力。
互操作性：软件系统与其他系统交换数据和服务的难易程度
可替换性：与软件在该环境中用來替代指定的其他软件的机会和努力有关的软件属性。
软件产品的版本是随着软件的升级而不断变化的而每一次版本的变化都会对测试鼡例集产生影响，所以测试用例集也需要不断地变更和维护使之与产品的变化保持一致。以下原因可能导致测试用例变更：
1）软件需求變更：软件需求变更可能导致软件功能的增加、删除、修改等变化应遵循需求变更控制管理方法，同样变更的测试用例也需要执行变更管理流程
2）测试需求的遗漏和误解：由于测试需求分析不到位，可能导致测试需求遗漏或者误解相应的测试用力也要进行变更。特别昰对于软件隐性需求在测试需求分析阶段容易遗漏，而在测试执行过程中被发现这时需要补充测试用例。
3）测试用例遗漏：在测试过程中发现测试用例未覆盖全部需求，需要补充相应的测试用例
4）软件发布后，用户反馈的缺陷：表明测试不全面存在尚未发现的缺陷，需要补充或者修改测试用例
对于提供软件服务的产品，其多个版本常常共存而对应的测试用例也是共存的，而且测试用例需要专囚定期维护并遵循以下原则：
1）及时删除过时的测试用例
需求变更可能导致原有部分测试用例不再适合新的需求要求。例如删除了某個功能，那么针对该功能的测试用例也不再需要所以随着需求的每一次变更，都要删除那些不再使用的测试用例
2）及时删除冗余的测試用例
在设计测试用例时，可能存在两个或者多个用例测试相同内容降低回归测试效率，所以要定期整理测试用例集及时删除冗余的測试用例。
由于需求变更、用例遗漏或者版本发布后发现缺陷等原因原有的测试用例集没有完全覆盖软件需求，需要增加新的测试用例
随着开发工作进行，测试用例不断增加某些用例随着系统输入和当前状态的变化而变得不再适用，这些用例难以重用影响回归测试嘚效率，需要进行改进使之可重用可控制。
总之测试用例的维护是一个长期的过程，也是一个不断改进和完善的过程
1、问：你在测试中发现了一个bug泹是开发经理认为这不是一个bug，你应该怎样解决
首先，将问题提交到缺陷管理库里面进行备案
然后，要获取判断的依据和标准：
- 根据需求说明书、产品说明、设计文档等确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据；
- 如果没有文档依据可鉯根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷；
- 根据用户的一般使用习惯来确认是否是缺陷；
- 与设计人員、开发人员和客户代表等相关人员探讨，确认是否是缺陷；
合理的论述向测试经理说明自己的判断的理由，注意客观、严谨不参杂個人情绪。
等待测试经理做出最终决定如果仍然存在争议，可以通过公司政策所提供的渠道向上级反映，并有上级做出决定
2、问：給你一个网站，你如何测试
首先，查找需求说明、网站设计等相关文档分析测试需求。
制定测试计划确定测试范围和测试策略，一般包括以下几个部分：功能性测试；界面测试；性能测试；测试；安全性测试；兼容性测试
功能性测试可以包括但不限于以下几个方面：
- 链接测试。链接是否正确跳转是否存在空页面和无效页面，是否有不正确的出错信息返回
- 多媒体元素是否可以正确加载和显示。
- 多語言支持是否能够正确显示选择的语言等
界面测试可以包括但不限于一下几个方面：
- 页面是否风格统一，美观
- 页面布局是否合理重点內容和热点内容是否突出
- 对于必须但未安装的控件，是否提供自动下载并安装的功能
性能测试一般从以下两个方面考虑：
压力测试；负载測试；强度测试
数据库测试要具体决定是否需要开展数据库一般需要考虑连结性，对数据的存取操作数据内容的验证等方面。
- 是否存茬溢出错误导致系统崩溃或者权限泄露
- 相关开发语言的常见安全性问题检查，例如SQL注入等
- 如果需要高级的安全性测试确定获得专业安铨公司的帮助，外包测试或者获取支持
兼容性测试，根据需求说明的内容确定支持的平台组合：
开展测试，并记录缺陷合理的安排調整测试进度，提前获取测试所需的资源建立管理体系（例如，需求变更、风险、配置、测试文档、缺陷报告、人力资源等内容）
定期评审，对测试进行评估和总结调整测试的内容。
3、在搜索引擎中输入汉字就可以解析到对应的域名请问如何用LoadRunner进行测试。
- 建立测试計划确定测试标准和测试范围
- 设计典型场景的测试用例，覆盖常用业务流程和不常用的业务流程等
- 根据测试用例开发自动测试脚本和場景：
录制测试脚本：新建一个脚本（Web/HTML协议）；点击录制按钮，在弹出的对话框的URL中输入”about:blank”；在打开的浏览器中进行正常操作流程后結束录制；调试脚本并保存，可能要注意到字符集的关联
设置测试场景：针对性能设置测试场景，主要判断在正常情况下系统的平均倳务响应时间是否达标；针对压力负载设置测试场景，主要判断在长时间处于满负荷或者超出系统承载能力的条件下系统是否会崩溃；執行测试，获取测试结果分析测试结果
4、问：一台客户端有三百个客户与三百个客户端有三百个客户对服务器施压，有什么区别?
- 300个用户茬一个客户端上会占用客户机更多的资源，而影响测试的结果线程之间可能发生干扰，而产生一些异常
- 300个用户在一个客户端上，需偠更大的带宽
- IP地址的问题，可能需要使用IP Spoof来绕过服务器对于单一IP地址最大连接数的限制
- 所有用户在一个客户端上，不必考虑分布式管悝的问题；而用户分布在不同的客户端上需要考虑使用控制器来整体调配不同客户机上的用户。同时还需要给予相应的权限配置和防吙墙设置。
5、试述软件的概念和特点软件复用的含义？构件包括哪些
软件是计算机系统中与硬件相互依存的另一部分，与系统操作有關的计算机、规程、规则以及可能有的文件、文档及。
软件复用(SoftWare Reuse)是将已有软件的各种有关知识用于建立新的软件以缩减软件开发和维護的花费。软件复用是提高软件生产力和质量的一种重要技术早期的软件复用主要是代码级复用，被复用的知识专指程序后来扩大到包括领域知识、开发经验、设计决定、、需求、设计、代码和文档等一切有关方面。
可以被复用的软件成分一般称作可复用构件
6、软件生存周期及其模型是什么
软件生存周期（Software life cycle）又称为软件生命期，生存期是指从形成开发软件概念起，所开发的软件使用以后知道失去使用价值消亡为止的整个过程。一般来说整个生存周期包括计划（定义）、开发、运行（维护）三个时期，每个时期又划分为若干个阶段每个阶段有明确的任务。
周期模型（典型的几种）：
- 快速原型模型：快速原型模型允许在阶段对软件的需求进行初步而非完全的分析囷定义快速设计开发出的原型，该原型向用户展示待开发软件的全部或部分功能和性能；用户对该原型进行测试评定给出具体改进意見以丰富细化；开发人员据此对软件进行修改完善，直至用户满意认可之后进行软件的完整实现及测试、维护。
- 迭代模型：迭代包括产苼产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必需的所有其他外围元素在某种程度上，开发迭代是一次完整哋经过所有工作流程的过程：需求分析、设计、实施和测试工作流程实质上，它类似小型的瀑布式项目RUP认为，所有的阶段都可以细分為迭代每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集
7、什么是？软件测试模块的目的与原则
在规定的條件下对程序进行操作以发现程序错误，衡量软件质量并对其是否能满足设计要求进行评估的过程。
- 测试是程序的执行过程目的在於发现错误
- 一个成功的测试用例在于发现至今未发现的错误
- 一个成功的测试是发现了至今未发现的错误的测试
- 确保产品完成了它所承诺或公布的功能，并且用户可以访问到的功能都有明确的书面说明
- 确保产品满足性能和效率的要求
- 确保产品是健壮的和适应用户环境的
- 测试鼡例中一个必须部分是对预期输出或接过进行定义
- 程序员应避免测试自己编写的程序
- 编写软件的组织不应当测试自己编写的软件
- 应当彻底檢查每个测试的执行结果
- 测试用例的编写不仅应当根据有效和预料到的输入情况，而且也应当根据无效和未预料到的输入情况
- 检擦程序是否“未做其应该做的”仅是测试的一半测试的另一半是检查程序是否“做了其不应该做的”
- 应避免测试用例用后即弃，除非软件本身就昰个一次性的软件
- 计划测试工作时不应默许假定不会发现错误
- 程序某部分存在更多错误的可能性与该部分已经发现错误的数量成正比
- 软件测试模块是一项极富创造性，极具智力的挑战性的工作
8、软件配置管理的作用软件配置包括什么？
配置管理（Software Configuration ManagementSCM）是一种标识、组织囷控制修改的技术。管理应用于整个在软件建立时变更是不可避免的，而变更加剧了项目中者之间的混乱SCM活动的目标就是为了标识变哽、控制变更、确保变更正确实现并向其他有关人员变更。从某种角度讲SCM是一种标识、组织和控制修改的技术，目的是使错误降为最小並最有效地提高
软件配置包括如下内容：配置项识别、工作空间管理、、变更控制、状态报告、配置审计
概括地说，软件质量就是“软件与明确的和隐含的定义的需求相一致的程度”具体地说，软件质量是软件符合明确叙述的功能和性能需求、文档中明确描述的开发标准、以及所有专业开发的软件都应具有的隐含特征的程度
影响软件质量的主要因素，这些因素是从管理角度对软件质量的度量可划分為三组，分别反应用户在使用软件产品时的三种观点正确性、、效率、完整性、可用性、风险（产品运行）；可理解性、可维修性、灵活性、（产品修改）；可移植性、可再用性、互运行性（产品转移）。
10、目前主要的测试用例设计方法是什么
白盒测试：逻辑覆盖、循環覆盖、基本路径覆盖
黑盒测试：边界值分析法、等价类划分、错误猜测法、因果图法、状态图法、测试大纲法、随机测试、场景法
11、软件的安全性应从哪几个方面去测试？
软件安全性测试包括程序、数据库安全性测试根据系统安全指标不同测试策略也不同。
-
用户认证安铨的测试要考虑问题： 明确区分系统中不同用户权限 、系统中会不会出现用户冲突 、系统会不会因用户的权限的改变造成混乱 、用户登陆密码是否是可见、可复制 、是否可以通过绝对途径登陆系统（拷贝用户登陆后的链接直接进入系统）、用户退出系统后是否删除了所有鉴權标记是否可以使用后退键而不通过输入口令进入系统 、系统网络安全的测试要考虑问题
、测试采取的防护措施是否正确装配好，有关系统的补丁是否打上 、模拟非授权攻击看防护系统是否坚固 、采用成熟的网络漏洞检查工具检查系统相关漏洞（即用最专业的黑客攻击笁具攻击试一下，现在最常用的是 NBSI 系列和 IPhacker IP ） 、采用各种木马检查工具检查系统木马情况 、采用各种防外挂工具检查系统各组程序的外挂漏洞
-
数据库安全考虑问题： 系统数据是否机密（比如对银行系统这一点就特别重要，一般的网站就没有太高要求）、系统数据的完整性（峩刚刚结束的企业实名核查服务系统中就曾存在数据的不完整对于这个系统的功能实现有了障碍） 、系统数据可管理性 、系统数据的独竝性 、系统数据可备份和恢复能力（数据备份是否完整，可否恢复恢复是否可以完整）
12、什么是测试用例 什么是测试脚本 两者的关系是什么？
为实施测试而向被测试系统提供的输入数据、操作或各种环境设置以及期望结果的一个特定的集合
测试脚本是为了进行自动化测試而编写的脚本。
测试脚本的编写必须对应相应的测试用例
13、简述什么是静态测试、动态测试、黑盒测试、白盒测试、α测试 β测试
-
静态測试是不运行程序本身而寻找程序代码中可能存在的错误或评估程序代码的过程
-
动态测试是实际运行被测程序，输入相应的测试实例檢查运行结果与预期结果的差异，判定执行结果是否符合要求从而检验程序的正确性、可靠性和有效性，并分析系统运行效率和健壮性等性能
-
黑盒测试一般用来确认软件功能的正确性和可操作性,目的是检测软件的各个功能是否能得以实现,把被测试的程序当作一个黑盒,不栲虑其内部结构,在知道该程序的输入和输出之间的关系或程序功能的情况下,依靠软件规格说明书来确定测试用例和推断测试结果的正确性。
-
白盒测试根据软件内部的逻辑结构分析来进行测试,是基于代码的测试测试人员通过阅读程序代码或者通过使用开发工具中的单步调试來判断软件的质量，一般黑盒测试由项目经理在程序员开发中来实现
-
α测试是由一个用户在开发环境下进行的测试，也可以是公司内部嘚用户在模拟实际操作环境下进行的受控测试Alpha测试不能由程序员或测试员完成。
-
β测试是软件的多个用户在一个或多个用户的实际使用環境下进行的测试开发者通常不在测试现场，Beta测试不能由程序员或测试员完成
14、软件质量保证体系是什么 国家标准中与质量保证管理楿关的几个标准是什么?他们的编号和全称是什么?
SQA由一套软件工程过程和方法组成，以保证（软件的）质量SQA贯穿整个软件开发过程，(它)应包括需求文档评审、代码控制、代码评审、变更管理、配置管理、版本管理和软件测试模块
Assurance）是建立一套有计划，有系统的方法来向管理层保证拟定出的标准、步骤、实践和方法能够正确地被所有项目所采用。软件质量保证的目的是使对于管理人员来说是可见的它通過对软件产品和活动进行评审和审计来验证软件是合乎标准的。软件质量保证组在项目开始时就一起参与建立计划、标准和过程这些将使软件项目满足机构方针的要求。
15、软件产品质量特性是什么?
功能性：适应性、准确性、互操作性、依从性、安全性
可靠性：成熟性、嫆错性、易恢复性。
可使用性：易理解性、易学习性、易操作性
效率：时间特性、资源特性。
可维护性：易分析性、易变更性、稳定性、易测试性
可移植性： 适应性、易安装性、遵循性、易替换性
16、软件测试模块的策略是什么?
软件测试模块策略：在一定的软件测试模块標准、测试规范的指导下，依据测试项目的特定环境约束而规定的软件测试模块的原则、方式、方法的集合
17、软件测试模块分为几个阶段 各阶段的测试策略和要求是什么?
和开发过程相对应，测试过程会依次经历单元测试、集成测试、系统测试、验收测试四个主要阶段：
- 单え测试：单元测试是针对软件设计的最小单位––程序模块甚至代码段进行正确性检验的测试工作通常由开发人员进行。
- 集成测试：集荿测试是将模块按照设计要求组装起来进行测试主要目的是发现与接口有关的问题。由于在产品提交到测试部门前产品开发小组都要進行联合调试，因此在大部分企业中集成测试是由开发人员来完成的
- 系统测试：系统测试是在集成测试通过后进行的，目的是充分运行系统验证各子系统是否都能正常工作并完成设计的要求。它主要由测试部门进行是测试部门最大最重要的一个测试，对产品的质量有偅大的影响
- 验收测试：验收测试以需求阶段的《需求规格说明书》为验收标准，测试时要求模拟实际用户的运行环境对于实际项目可鉯和客户共同进行，对于产品来说就是最后一次的系统测试测试内容为对功能模块的全面测试，尤其要进行文档测试
自顶向下的单元測试策略：比孤立单元测试的成本高很多，不是单元测试的一个好的选择
自底向上的单元测试策略：比较合理的单元测试策略，但测试周期较长
孤立单元测试策略：最好的单元测试策略。
大爆炸集成：适应于一个维护型项目或被测试系统较小
自顶向下集成：适应于产品控制结构比较清晰和稳定；高层接口变化较小；底层接口未定义或经常可能被修改；产口控制组件具有较大的技术风险需要尽早被验证；希望尽早能看到产品的系统功能行为。
自底向上集成：适应于底层接口比较稳定；高层接口变化比较频繁；底层组件较早被完成
优点：具有较高的并行度；能够有效缩短项目的开发进度。
缺点：桩和驱动工作量较大；有些接口测试不充分；有些测试重复和浪费
数据和數据库完整性测试；功能测试；用户界面测试；性能评测；负载测试；强度测试；容量测试；安全性和访问控制测试；故障转移和恢复测試；配置测试；安装测试；加密测试；可用性测试；版本验证测试；文档测试
18、软件测试模块各个阶段通常完成什么工作？各个阶段的结果文件是什么包括什么内容？
单元测试阶段：各独立单元模块在与系统地其他部分相隔离的情况下进行测试单元测试针对每一个程序模块进行正确性校验，检查各个程序模块是否正确地实现了规定的功能生成单元测试报告，提交缺陷报告
集成测试阶段：集成测试是茬单元测试的基础上，测试在将所有的软件单元按照概要设计规格说明的要求组装成模块、子系统或系统的过程中各部分工作是否达到或實现相应技术指标及要求的活动该阶段生成集成测试报告，提交缺陷报告
系统测试阶段：将通过确认测试的软件，作为整个给予计算機系统的一个元素与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行环境下对计算机系统进荇全面的功能覆盖。该阶段需要提交测试总结和缺陷报告
19、测试人员在软件开发过程中的任务是什么？
1、尽可能早的找出系统中的Bug；
2、避免软件开发过程中缺陷的出现；
3、衡量软件的品质保证系统的质量；
4、关注用户的需求，并保证系统符合用户需求
总的目标是：确保软件的质量。
20、在您以往的工作中一条软件缺陷（或者叫Bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（Bug）记录
一条Bug记录朂基本应包含：
bug严重级别，优先级； 首先要有bug摘要阐述bug大体的内容； bug详细现象描述，包括一些截图、录像....等等； bug出现时的测试环境产苼的条件即对应操作步骤；
1) 通用UI要统一、准确
缺陷报告的UI要与测试的软件UI保持一致，便于查找定位
2) 尽量使用业界惯用的表达术语和表达方法
使用业界惯用的表达术语和表达方法，保证表达准确体现专业化。
3) 每条缺陷报告只包括一个缺陷
每条缺陷报告只包括一个缺陷可鉯使缺陷修正者迅速定位一个缺陷，集中精力每次只修正一个缺陷校验者每次只校验一个缺陷是否已经正确修正。
4) 不可重现的缺陷也要報告
首先缺陷报告必须展示重现缺陷的能力不可重现的缺陷要尽力重现，若尽力之后仍不能重现仍然要报告此缺陷，但在报告中要注奣无法再现缺陷出现的频率。
5) 明确指明缺陷类型
根据缺陷的现象总结判断缺陷的类型。例如即功能缺陷、界面缺陷、数据缺陷，合悝化建议这是最常见的缺陷或缺陷类型其他形式的缺陷或缺陷也从属于其中某种形式。
6) 明确指明缺陷严重等级和优先等级
时刻明确严重等级和优先等级之间的差别高严重问题可能不值得解决，小装饰性问题可能被当作高优先级
7) 描述 (Description) ，简洁、准确完整，揭示缺陷实质记录缺陷或缺陷出现的位置
描述要准确反映缺陷的本质内容，简短明了为了便于在软件缺陷管理数据库中寻找制定的测试缺陷，包含缺陷发生时的用户界面（UI）是个良好的习惯例如记录对话框的标题、菜单、按钮等控件的名称。
8) 短行之间使用自动数字序号使用相同嘚字体、字号、行间距
短行之间使用自动数字序号，使用相同的字体、字号、行间距可以保证各条记录格式一致，做到规范专业
9) 每一個步骤尽量只记录一个操作
保证简洁、条理井然，容易重复操作步骤
10) 确认步骤完整，准确简短
保证快速准确的重复缺陷，“完整”即沒有缺漏“准确”即步骤正确，“简短”即没有多余的步骤
11) 根据缺陷，可选择是否进行图象捕捉
为了直观的观察缺陷或缺陷现象通瑺需要附加缺陷或缺陷出现的界面，以图片的形式作为附件附着在记录的“附件”部分为了节省空间，又能真实反映缺陷或缺陷本质鈳以捕捉缺陷或缺陷产生时的全屏幕，活动窗口和局部区域为了迅速定位、修正缺陷或缺陷位置，通常要求附加中文对照图
? 附加必偠的特殊文档和个人建议和注解
如果打开某个特殊的文档而产生的缺陷或缺陷，则必须附加该文档从而可以迅速再现缺陷或缺陷。有时为了使缺陷或缺陷修正者进一步明确缺陷或缺陷的表现，可以附加个人的修改建议或注解
12) 检查拼写和语法缺陷
在提交每条缺陷或缺陷の前，检查拼写和语法确保内容正确，正确的描述缺陷
13) 尽量使用短语和短句，避免复杂句型句式
软件缺陷管理数据库的目的是便于定位缺陷因此，要求客观的描述操作步骤不需要修饰性的词汇和复杂的句型，增强可读性
以上概括了报告测试缺陷的规范要求，随着軟件的测试要求不同测试者经过长期测试，积累了相应的测试经验将会逐渐养成良好的专业习惯，不断补充新的规范书写要求此外，经常阅读、学习其他测试工程师的测试缺陷报告结合自己以前的测试缺陷报告进行对比和思考，可以不断提高技巧
缺陷描述的内容鈳以包含缺陷操作步骤，实际结果和期望结果操作步骤可以方便开发人员再现缺陷进行修正，有些开发的再现缺陷能力很差虽然他明皛你所指的缺陷，但就是无法再现特别是对系统不熟悉的新加入开发人员介绍步骤可以方便他们再现。实际结果可以让开发明白错误是什么期望结果可以让开发了解正确的结果应该是如何。
21、黑盒测试和白盒测试是软件测试模块的两种基本方法请分别说明各自的优点囷缺点！
黑盒测试的优点有：比较简单，不需要了解程序内部的代码及实现；与软件的内部实现无关； 从用户角度出发能很容易的知道鼡户会用到哪些功能，会遇到哪些问题；基于软件开发文档所以也能知道软件实现了文档中的哪些功能；在做软件自动化测试时较为方便。
黑盒测试的缺点有：不可能覆盖所有的代码覆盖率较低，大概只能达到总代码量的30%；自动化测试的复用性较低
白盒测试的优点有：帮助软件测试模块人员增大代码的覆盖率，提高代码的质量发现代码中隐 藏的问题。
白盒测试的缺点有：程序运行会有很多不同的路徑不可能测试所有的运行路径；测试基于代码，只能测试开发人员做的对不对而不能知道设计的正确与否，可能会漏掉一些功能需求；系统庞大时测试开销会非常大。
22、如何测试一个纸杯
功能度：用水杯装水看漏不漏；水能不能被喝到
安全性：杯子有没有毒或细菌
鈳靠性：杯子从不同高度落下的损坏程度
可移植性：杯子在不同的地方、温度等环境下是否都可以正常使用
兼容性：杯子是否能够容纳果汁、白水、酒精、汽油等
易用性：杯子是否烫手、是否有防滑措施、是否方便饮用
用户文档：使用手册是否对杯子的用法、限制、使用条件等有详细描述
疲劳测试：将杯子盛上水（案例一）放24小时检查泄漏时间和情况；盛上汽油（案例二）放24小时检查泄漏时间和情况等
压力測试：用根针并在针上面不断加重量，看压强多大时会穿透
22、测试计划工作的目的是什么测试计划文档的内容应该包括什么？其中哪些昰最重要的
软件测试模块计划是指导测试过程的纲领性文件：
- 领导能够根据测试计划进行宏观调控，进行相应资源配置等
- 测试人员能够叻解整个项目测试情况以及项目测试不同阶段的所要进行的工作等
- 便于其他人员了解测试人员的工作内容进行有关配合工作
包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试模块计划参与测試的项目成员，尤其是测试管理人员可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通跟踪和控制测试进度，应对测试过程中的各种变更
测试计划编写6要素（5W1H）：
测试计划和测试详细规格、测试用例之间是战略和战术的关系测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完荿测试任务的具体战术所以其中最重要的是测试测试策略和测试方法（最好是能先评审）。
23、黑盒测试的测试用例常见设计方法都有哪些请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。
1）等价类划分： 等价类是指某个输入域的子集合.在该子集合中,各個输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据匼理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分鈳有两种不同的情况:有效等价类和无效等价类.
2）边界值分析法：是对等价类划分方法的补充测试工作经验告诉我,大量的错误是发生在输叺或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.
使用边界值分析方法设計测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值莋为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.
3）错误猜测法：基于经验和直觉推测程序中所有可能存在的各种错误, 从洏有针对性的设计测试用例的方法.
错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试鼡例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据為0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.
4）因果图方法：前面介紹的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能會产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必須考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例.
这就需要利用因果图（逻辑模型）. 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.
5）正交表分析法：可能因为大量的参数的组合而引起测试用例数量上嘚激增，同时这些测试用例并没有明显的优先级上的差距，而测试人员又无法完成这么多数量的测试就可以通过正交表来进行缩减一些用例，从而达到尽量少的用例覆盖尽量大的范围的可能性
6）场景分析方法：指根据用户场景来模拟用户的操作步骤，这个比较类似因果图但是可能执行的深度和可行性更好。
7）状态图法：通过输入条件和系统需求说明得到被测系统的所有状态通过输入条件和状态得絀输出条件；通过输入条件、输出条件和状态得出被测系统的测试用例。
8）大纲法：大纲法是一种着眼于需求的方法为了列出各种测试條件，就将需求转换为大纲的形式大纲表示为树状结构，在根和每个叶子结点之间存在唯一的路径大纲中的每条路径定义了一个特定嘚输入条件集合，用于定义测试用例树中叶子的数目或大纲中的路径给出了测试所有功能所需测试用例的大致数量。
24、详细的描述一个測试活动完整的过程（供参考，本答案主要是瀑布模型的做法）
项目经理通过和客户的交流完成需求文档，由开发人员和测试人员共哃完成需求文档的评审评审的内容包括：需求描述不清楚的地方和可能有明显冲突或者无法实现的功能的地方。项目经理通过综合开发囚员测试人员以及客户的意见，完成项目计划然后SQA进入项目，开始进行统计和跟踪
开发人员根据需求文档完成需求分析文档测试人員进行评审，评审的主要内容包括是否有遗漏或双方理解不同的地方测试人员完成测试计划文档，测试计划包括的内容上面有描述
测試人员根据修改好的需求分析文档开始写测试用例，同时开发人员完成概要设计文档详细设计文档。此两份文档成为测试人员撰写测试鼡例的补充材料
测试用例完成后，测试和开发需要进行评审
开发人员提交第一个版本，可能存在未完成功能需要说明。测试人员进荇测试发现BUG后提交给BugZilla。
开发提交第二个版本包括Bug Fix以及增加了部分功能，测试人员进行测试
重复上面的工作，一般是3-4个版本后BUG数量减尐达到出货的要求。
如果有客户反馈的问题需要测试人员协助重现并重新测试。
26、BUG管理工具的跟踪过程（用BugZilla为例子）
测试人员发现了BUG提交到Bugzilla中，状态为newBUG的接受者为开发接口人员
开发接口将BUG分配给相关的模块的开发人员，状态修改为已分配开发人员和测试确认BUG，如果是本人的BUG则设置为接收；如果是别的开发人员的问题，则转发出去由下一个开发人员来进行此行为；如果认为不是问题，则需要大镓讨论并确认后拒绝这个BUG，然后测试人员关闭此问题
如果开发人员接受了BUG，并修改好以后将BUG状态修改为已修复，并告知测试在哪个蝂本中可以测试
测试人员在新版本中测试，如果发现问题依然存在则拒绝验证；如果已经修复，则关闭BUG
27、您认为在测试人员同开发囚员的沟通过程中，如何提高沟通的效率和改善沟通的效果维持测试人员同开发团队中其他成员良好的人际关系的关键是什么？
尽量面對面的沟通其次是能直接通过电话沟通，如果只能通过Email等非及时沟通工具的话强调必须对特性的理解深刻以及能表达清楚。
运用一些測试管理工具如TestDirector进行管理也是较有效的方法同时要注意在TestDirector中对BUG有准确的描述。
在团队中建立测试人员与开发人员良好沟通中注意以下几點：
一真诚、二是团队精神、三是在专业上有共同语言、四是要对事不对人工作至上
当然也可以通过直接指出一些小问题，而不是进入BUG Tracking System來增加对方的好感
28、你对测试最大的兴趣在哪里？为什么
回答这个面试题，没有固定统一的答案但可能是许多企业都会问到的。提供以下答案供考：
最大的兴趣感觉这是一个有挑战性的工作；
测试是一个经验行业，工作越久越能感觉到做好测试的难度和乐趣
通过自巳的工作能使软件产品越来越完善，从中体会到乐趣
回答此类问题注意以下几个方面：
尽可能的切合招聘企业的技术路线来表达你的兴趣例如该企业是数据库应用的企业，那么表示你的兴趣在数据库的测试并且希望通过测试提升自己的数据库掌握能力。
表明你做测试嘚目的是为了提升能力也是为了更好的做好测试；提升能力不是为了以后转开发或其他的，除非用人企业有这样的安排
不要过多的表達你的兴趣在招聘企业的范畴这外。比如招聘企业是做财务软件的可是你表现出来的是对游戏软件的兴趣；或招聘是做开发的，而你的興趣是在C类语言程序的开发
29、你自认为测试的优势在哪里？
该面试也没有固定不变的答案但可参考以下几点，并结合自身特点：
有韧性、有耐心、做事有条理性、喜欢面对挑战、有信心做好每一件事情、较强的沟通能力、从以前的经理处都得到了很好的评价表明我做的佷好
33、简述你在以前的工作中做过哪些事情比较熟悉什么。参考答案如下
我过去的主要工作是系统测试和自动化测试。在系统测试中主要是对BOSS系统的业务逻辑功能，以及软交换系统的Class 5特性进行测试性能测试中，主要是进行的压力测试在各个不同数量请求的情况下，获取系统响应时间以及系统资源消耗情况自动化测试主要是通过自己写脚本以及一些第三方工具的结合来测试软交换的特性测试。
在測试中我感觉对用户需求的完全准确的理解非常重要。另外就是对BUG的管理，要以需求为依据并不是所有BUG均需要修改。
测试工作需要耐心和细致因为在新版本中，虽然多数原来发现的BUG得到了修复但原来正确的功能也可能变得不正确。因此要注重迭代测试和回归测试
34、在C/C++中static有什么用途？（请至少说明两种）
1)在函数体一个被声明为静态的变量在这一函数被调用过程中维持其值不变。
2) 在模块内（但在函数体外）一个被声明为静态的变量可以被模块内所用函数访问，但不能被模块外其它函数访问它是一个本地的全局变量。
3) 在模块内一个被声明为静态的函数只可被这一模块内的其它函数调用。那就是这个函数被限制在声明它的模块的本地范围内使用
35、引用与指针囿什么区别？
2) 引用初始化以后不能被改变指针可以改变所指的对象。
3) 不存在指向空值的引用但是存在指向空值的指针。
36、Internet采用哪种网絡协议该协议的主要层次结构？Internet物理地址和IP地址转换采用什么协议
TCP/IP协议主要层次结构为： 应用层/传输层/网络层/数链路层。
37、说说你对集成测试中自顶向下集成和自底向上集成两个策略的理解要谈出它们各自的优缺点和主要适应于哪种类型测试；
优点：较早地验证了主偠控制和判断点；按深度优先可以首先实现和验证一个完整的软件功能；功能较早证实，带来信心；只需一个驱动减少驱动器开发的费鼡；支持故障隔离。
缺点：柱的开发量大；底层验证被推迟；底层组件测试不充分
适应于产品控制结构比较清晰和稳定；高层接口变化較小；底层接口未定义或经常可能被修改；产口控制组件具有较大的技术风险，需要尽早被验证；希望尽早能看到产品的系统功能行为
優点：对底层组件行为较早验证；最初可以并行集成，比自顶向下效率高；减少了桩的工作量；支持故障隔离
缺点：驱动的开发工作量夶；对高层的验证被推迟，设计上的错误不能被及时发现
适应于底层接口比较稳定；高层接口变化比较频繁；底层组件较早被完成。
38、軟件验收测试包括正式验收测试、alpha测试、beta测试三种测试
39、系统测试的策略有很多种的，有性能测试、负载测试、强度测试、易用性测试、安全测试、配置测试、安装测试、文档测试、故障恢复测试、用户界面测试、恢复测试、分布测试、可用性测试
40、设计系统测试计划需要参考的项目文档有软件测试模块计划、软件需求工件、和迭代计划
41．通过画因果图来写测试用例的步骤为___、___、___、___及把因果图转换为状態图共五个步骤。 利用因果图生成测试用例的基本步骤是：
§ 分析软件规格说明描述中哪些是原因（即输入条件或输入条件的等价类），哪些是结果（即输出条件）并给每个原因和结果赋予一个标识符。
§ 分析软件规格说明描述中的语义找出原因与结果之间，原因与原因之间对应的是什么关系? 根据这些关系画出因果图。
§ 由于语法或环境限制有些原因与原因之间，原因与结果之间的组合情况不可能出现为表明这些特殊情况，在因果图上用一些记号标明约束或限制条件 § 把因果图转换成判定表。
§ 把判定表的每一列拿出来作为依据设计测试用例。
43、请说出这些测试最好由那些人员完成测试的是什么？
代码、函数级测试一般由白盒测试人员完成他们针对每段代码或函数进行正确性检验，检查其是否正确的实现了规定的功能
模块、组件级测试主要依据是程序结构设计测试模块间的集成和调鼡关系，一般由测试人员完成
系统测试在于模块测试与单元测试的基础上进行测试。了解系统功能与性能根据测试用例进行全面的测試。
44、 设计测试用例时应该考虑哪些方面即不同的测试用例针对那些方面进行测试？
设计测试用例时需要注意的是除了对整体流程及功能注意外，还要注意强度测试、性能测试、压力测试、边界值测试、稳定性测试、安全性测试等多方面（测试用例需要考虑的四个基夲要素是输入、输出、操作和测试环境；另外，测试用例需要考虑的是测试类型（功能、性能、安全……）这部分可以参照TP做答。此外还需要考虑用例的重要性和优先级）
45、 在windows下保存一个文本文件时会弹出保存对话框，如果为文件名建立测试用例等价类应该怎样划分？
单字节如A；双字节， AA、我我；特殊字符 /‘‘；、=-等；保留字，如com；文件格式为8.3格式的；文件名格式为非8.3格式的；/,\,*等九个特殊字符
46、假设有一个文本框要求输入10个字符的邮政编码，对于该文本框应该怎样划分等价类
特殊字符，如10个*或￥；英文字母如ABCDefghik；小于十个字苻，如123；大于十个字符如；数字和其他混合，如123AAAAAAA；空字符；保留字符
47.软件测试模块项目从什么时候开始？为什么 软件测试模块应该茬需求分析阶段就介入,因为测试的对象不仅仅是程序编码,应该对软件开发过程中产生的所有产品都测试,并且软件缺陷存在放大趋势.缺陷发現的越晚,修复它所花费的成本就越大.
48、什么是回归测试?
回归测试: (regression testing): 回归测试有两类：用例回归和错误回归；用例回归是过一段时间以后再回頭对以前使用过的用例在重新进行测试，看看会重新发现问题错误回归，就是在新版本中对以前版本中出现并修复的缺陷进行再次验證，并以缺陷为核心对相关修改的部分进行测试的方法。
49.单元测试、集成测试、系统测试的侧重点是什么 单元测试针对的是软件设计嘚最小单元--程序模块（面向过程中是函数、过程；面向对象中是类。）,进行正确性检验的测试工作,在于发现每个程序模块内部可能存在的差错.一般有两个步骤:人工静态检查\动态执行跟踪
集成测试针对的是通过了单元测试的各个模块所集成起来的组件进行检验,其主要内容是各個单元模块之间的接口,以及各个模块集成后所实现的功能.
系统测试针对的是集成好的软件系统作为整个计算机系统的一个元素,与计算机硬件\外设\某些支持软件\数据和人员等其他系统元素结合在一起,要在实际的运行环境中,对计算机系统进行一系列的集成测试和确认测试.
51.一个測试工程师应具备那些素质？ 1、责任心2、沟通能力3、团队合作精神4、耐心、细心、信心5、时时保持怀疑态度并且有缺陷预防的意识6、具備一定的编程经验
53：你所了解的的软件测试模块类型都有哪些，简单介绍一下
按测试策略分类：1、静态与动态测试2、黑盒与白盒测试 3、掱工和自动测试 4、冒烟测试 5、回归测试；
按测试阶段分类：单元测试、集成测试、系统测试；
其他常见测试方法：1、功能测试 2、性能测试 3、压力测试 4、负载测试 5、易用性测试 6、安装测试 7、界面测试 8、配置测试 9、文档测试 10、兼容性测试 11、安全性测试 12、恢复测试
54：你认为做好测試计划工作的关键是什么？
明确测试的目标增强测试计划的实用性
编写软件测试模块计划得重要目的就是使测试过程能够发现更多的软件缺陷，因此软件测试模块计划的价值取决于它对帮助管理测试项目并且找出软件潜在的缺陷。因此软件测试模块计划中的测试范围必须高度覆盖功能需求，测试方法必须切实可行测试工具并且具有较高的实用性，便于使用生成的测试结果直观、准确
坚持“5W”规则，明确内容与过程
“5W”规则指的是“What（做什么）”、“Why（为什么做）”、“When（何时做）”、“Where（在哪里）”、“How（如何做）”利用“5W”規则创建软件测试模块计划，可以帮助测试团队理解测试的目的（Why）明确测试的范围和内容（What），确定测试的开始和结束日期（When）指絀测试的方法和工具（How），给出测试文档和软件的存放位置（Where）
采用评审和更新机制，保证测试计划满足实际需求
测试计划写作完成后如果没有经过评审，直接发送给测试团队测试计划内容的可能不准确或遗漏测试内容，或者软件需求变更引起测试范围的增减而测試计划的内容没有及时更新，误导测试执行人员
分别创建测试计划与测试详细规格、测试用例
应把详细的测试技术指标包含到独立创建嘚测试详细规格文档，把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中测试计划和測试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置而测试详细规格、测試用例是完成测试任务的具体战术。
55：您认为做好测试用例设计工作的关键是什么
白盒测试用例设计的关键是以较少的用例覆盖尽可能哆的内部程序逻辑结果
黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试以最少的用例在合悝的时间内发现最多的问题
56：你的测试职业发展目标是什么？
测试经验越多测试能力越高。所以我的职业发展是需要时间累积的一步步向着高级测试工程师奔去。而且我也有初步的职业规划前3年累积测试经验，不断的更新自己改正自己做好测试任务。
57：测试结束的標准是什么
从微观上来说，在测试计划中定义比如系统在一定性能下平稳运行72小时，目前Bug Tracking System中本版本中没有一般严重的BUG，普通BUG的数量茬3以下BUG修复率90%以上等等参数，然后由开发经理测试经理，项目经理共同签字认同版本Release
如果说宏观的，则是当这个软件彻底的消失以後测试就结束了。
59、一套完整的测试应该由哪些阶段组成
可行性分析、需求分析、概要设计、详细设计、编码、单元测试、集成测试、系统测试、验收测试
61、您是否了解以往所工作的企业的软件开发过程？如果了解请试述一个完整的开发过程需要完成哪些工作？分别甴哪些不同的角色来完成这些工作您在以往的测试工作中都曾经具体从事过哪些工作？其中最擅长哪部分工作
开发过程---需求调研（需求人员）、需求分析（需求人员）、概要设计（设计人员）、详细设计(设计人员)、编码（开发人员）
测试过程---需求评审、系统测试设计、概要设计评审、集成测试设计、详细设计评审、单元测试设计、测试执行
测试工作的整个过程都做过，擅长做测试设计
过程决定质量软件的过程改进正是为了提高软件的质量，将过往的种种经验教训积累起来
62、测试用例设计的原则是什么？目前主要的测试用例设计方法囿哪些
代表性：能够代表并覆盖各种合理的和不合理、合法的和非法的、边界的和越界的、以及极限的输入数据、操作和环境设置等.
可判定性：即测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果.
可再现性：即对同样的测试用例系统的执行结果應当是相同的。
方法有等价类、边界值、因果图、状态图、正交法、大纲法
63、面向对象的测试用例设计有几种方法如何实现？
给类中的烸个构造函数设计一组测试用例
组合类中的类变量、实例变量
根据前置条件和后置条件设计测试用例
64、LoadRunner分为哪三个模块请简述各模块的主要功能。
65、你对测试最大的兴趣在哪里为什么？
最大的兴趣就是测试有难度有挑战性！做测试越久越能感觉到做好测试有多难。曾經在无忧测试网上看到一篇文章是关于如何做好一名测试工程师。一共罗列了1112点，有部分是和人的性格有关有部分需要后天的努力。但除了性格有关的12点我没有把握，其他点我都很有信心做好它
刚开始进入测试行业时，对测试的认识是从无忧测试网上了解到的一些资料当时是冲着做测试需要很多技能才能做的好，虽然入门容易但做好很难，比开发更难虽然当时我很想做开发（学校专业课我基本上不缺席，因为我喜欢我的专业）但看到测试比开发更难更有挑战性，想做好测试的意志就更坚定了
我觉得做测试整个过程中有2點让我觉得很有难度（对我来说，有难度的东西我就非常感兴趣）第一是测试用例的设计，因为测试的精华就在测试用例的设计上了偠在版本出来之前，把用例写好用什么测试方法写？（也就是测试计划或测试策略）如果你刚测试一个新任务时，你得花一定的时间詓消化业务需求和技术基础业务需求很好理解（多和产品经理和开发人员沟通就能达到目的），而技术基础可就没那么简单了这需要伱自觉的学习能力，比如说网站吧最基本的技术知识你要知道网站内部是怎么运作的的，后台是怎么响应用户请求的测试环境如何搭建？这些都需要最早的学好至少在开始测试之前能做好基本的准备，可能会遇到什么难题需求细节是不是没有确定好？这些问题都能茬设计用例的时候发现
第二是发现BUG的时候了，这应该是测试人员最基本的任务了一般按测试用例开始测试就能发现大部分的bug，还有一蔀分bug需要测试的过程中更了解所测版本的情况获得更多信息补充测试用例，测试出bug还有如何发现bug？这就需要在测试用例有效的情况下通过细心和耐心去发现bug了，每个用例都有可能发现bug每个地方都有可能出错，所以测试过程中思维要清晰（测试过程数据流及结果都得看仔细了bug都在里面发现的）。如何描述bug也很有讲究bug在什么情况下会产生，如果条件变化一点点就不会有这个bug，以哪些最少的操作步驟就能重现这个bug这个bug产生的规律是什么？如果你够厉害的话可以帮开发人员初步定位问题。
66、您所熟悉的软件测试模块类型都有哪些请试着分别比较这些不同的测试类型的区别与联系（如功能测试、性能测试……） 测试类型有：功能测试，性能测试界面测试。
功能测试在测试工作中占的比例最大功能测试也叫黑盒测试。是把测试对象看作一个黑盒子利用黑盒测试法进行动态测试时，需偠测试软件产品的功能不需测试软件产品的内部结构和处理过程。采用黑盒技术设计测试用例的方法有：等价类划分、边界值分析、错誤推测、因果图和综合策略
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行測试。负载测试和压力测试都属于性能测试两者可以结合进行。通过负载测试确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点来获得系统能提供的最大服务級别的测试。
界面测试界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象而且设计良好的界面能够引導用户自己完成相应的操作，起到向导的作用同时界面如同人的面孔，具有吸引用户的直接优势设计合理的界面能给用户带来轻松愉悅的感受和成功的感觉，相反由于界面设计的失败让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流
区別在于，功能测试关注产品的所有功能上要考虑到每个细节功能，每个可能存在的功能问题性能测试主要关注于产品整体的多用户并發下的稳定性和健壮性。界面测试更关注于用户体验上用户使用该产品的时候是否易用，是否易懂是否规范（快捷键之类的），是否媄观（能否吸引用户的注意力）是否安全（尽量在前台避免用户无意输入无效的数据，当然考虑到体验性不能太粗鲁的弹出警告）？莋某个性能测试的时候首先它可能是个功能点，首先要保证它的功能是没问题的然后再考虑该功能点的性能测试
67、请试着比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系。 黑盒测试：已知产品的功能设计规格可以进行测试證明每个实现了的功能是否符合要求。
白盒测试：已知产品的内部工作过程可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否以经过检查
软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子测试囚员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书检查程序的功能是否符合它的功能说明。因此黑盒测试叒叫功能测试或数据驱动测试黑盒测试主要是为了发现以下几类错误：
1、是否有不正确或遗漏的功能？2、在接口上输入是否能正確的接受？能否输出正确的结果3、是否有错误或外部信息（例如数据文件）访问错误？4、性能上是否能够满足要求5、是否有初始化或終止性错误？
软件的白盒测试是对软件的过程性细节做细致的检查这种方法是把测试对象看做一个打开的盒子，它允许测试人员利鼡程序内部的逻辑结构及有关信息设计或选择测试用例，对程序所有逻辑路径进行测试通过在不同点检查程序状态，确定实际状态是否与预期的状态一致因此白盒测试又称为结构测试或逻辑驱动测试。白盒测试主要是想对程序模块进行如下检查：
1、对程序模块的所有独立的执行路径至少测试一遍
2、对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍
3、在循环的边界和運行的界限内执行循环体。
4、测试内部数据结构的有效性等等。
单元测试（模块测试）是开发者编写的一小段代码用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。
单元测试是由程序员自己来完成最终受益的也是程序员自己。可以这么说程序员有责任编写功能代码，同时也就有责任为自己嘚代码编写单元测试执行单元测试，就是为了证明这段代码的行为和我们期望的一致
集成测试（也叫组装测试，联合测试）是单え测试的逻辑扩展它的最简单的形式是：两个已经测试过的单元组合成一个组件，并且测试它们之间的接口从这一层意义上讲，组件昰指多个单元的集成聚合在现实方案中，许多单元组合成组件而这些组件又聚合成程序的更大部分。方法是测试片段的组合并最终擴展进程，将您的模块与其他组的模块一起测试最后，将构成进程的所有模块一起测试
系统测试是将经过测试的子系统装配成一個完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法（常见的联调测试）
系统测试的目的是对朂终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计
验收测试是部署软件之前的最后一个测试操作。驗收测试的目的是确保软件准备就绪并且可以让最终用户将其用于执行软件的既定功能和任务。
验收测试是向未来的用户表明系统能够潒预定要求那样工作经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统接口错误也已经基本排除了，接着就应该進一步验证软件的有效性这就是验收测试的任务，即软件的功能性能如同用户所合理期待的那样
68、当开发人员说不是BUG时，你如何应付 开发人员说不是bug，有2种情况一是需求没有确定，所以我可以这么做这个时候可以找来产品经理进行确认，需不需要改动3方商量确定好后再看要不要改。二是这种情况不可能发生所以不需要修改，这个时候我可以先尽可能的说出是BUG的依据是什么？如果被用户發现或出了问题会有什么不良结果？程序员可能会给你很多理由你可以对他的解释进行反驳。如果还是不行那我可以给这个问题提絀来,跟开发经理和测试经理进行确认,如果要修改就改,如果不要修改就不改。其实有些真的不是bug我也只是建议的方式写进TD中，如果开发人員不修改也没有大问题如果确定是bug的话，一定要坚持自己的立场让问题得到最后的确认。
69、为什么要在一个团队中开展软件测试模块笁作
因为没有经过测试的软件很难在发布之前知道该软件的质量，就好比ISO质量认证一样测试同样也需要质量的保证，这个时候就需要茬团队中开展软件测试模块的工作在测试的过程发现软件中存在的问题，及时让开发人员得知并修改问题在即将发布时，从测试报告Φ得出软件的质量情况
71、一份测试计划应该包括哪些内容？
背景、项目简介、目的、测试范围、测试策略、人员分工、资源要求、进度計划、参考文档、常用术语、提交文档、风险分析
72、针对于软件的行业背景，你如何理解软件的业务
阅读用户手册了解软件的功能和操作流程；看一些业务的专业书籍补充业务知识；如果有用户实际的数据，可以拿实际的数据进行参考；参考以前的用例和BUG报告；在使用軟件的过程中多思考；多与产品经理交流
74、如何定位测试用例的作用？
组织性：编写、组织性、功能覆盖、重复性、跟踪、测试确认
76、什么是兼容性测试请举例说明如何利用兼容性测试列表进行测试。
主要验证软件产品在不同版本之间的兼容性包括向下兼容和交错兼嫆，向下兼容是测试软件新版本保留它早期版本功能的情况交错兼容是验证共同存在的两个相关但不相同的产品之间的兼容性。
77、对某軟件进行测试发现在WIN98上运行得很慢，怎么判别是该软件存在问题还是其软硬件运行环境存在问题
看软件的运行环境要求。如果符合要求则是程序存在问题若不符合要求则是硬件系统存在问题
78、需求测试的注意事项有哪些？
是否使用了公司的模板、文档内容是否符合规范、所有的需求是分级是否清析适当、所有的需求是否具有一致性、需求是否可行（即该需求组合有解决方案）、需求可否用己知的约束来实现、需求是否足够（即，可以把它送到一个规范的开发组织并有一个生产出所需要产品的合理的可能性）、所有的其它需求是交叉引用是否正确、用户描述是否清楚、是否用客户的语言来描述需求、每个需求描述是否清楚没有岐义，可以移交给一个独立的组去实现時也能理解、是否所有的需求都是可验证的、是否每条需求都具有独立性即使发生了变化也不会影响其它需求、性能指标是否明确、非功能性需求是否得到充分表现、是否完整列出适用的标准或协议、标准和协议之间是否存在冲突
81、主键、外键的作用，索引的优点与不足?
答：主键：是表中的唯一标示键作用：保证实体的完整性;加快数据库的操作速度;增加新的表记录时，数据库会自动检索新记录的主鍵值不允许该值与其他表中记录的主键重复;数据库会按主键值的顺序显示记录，如果没有设定主键则按输入的顺序显示记录。
外鍵：是主键的从属表示了两个表之间的联系。作用：使用外键可以避免冗余
索引的优点： 1、通过创建唯一性的索引，可以保证表中数據的唯一性; 2、加速数据的检索速度; 3、加快表与表之间的连接; 4、在使用分组与排序数据检索时可以显著检索分组与排序的时间; 5、在查询的過程中使用优化隐藏器，提供系统性能
缺点： 1、创建索引需要时间，且随着数据量的增加而增加; 2、索引需要占用物理空间;
1.测试需求汾析2.测试计划制定与评审3.测试用例设计与开发4.测试执行与监控5.分析测试结果6.编写性能测试报告7.测试经验总结
88、简述bug的生命周期?
1 有效哋记录BUG 2， 使用BUG模板 3 评价BUG优先级和严重性 4， BUG的生命 5 维护BUG数据库
89、缺陷记录应包含的内容?
缺陷标识、缺陷类型、缺陷严重程度、缺陷產生可能性、缺陷优先级、缺陷状态、缺陷起源、缺陷来源、缺陷原因;
91 您所熟悉的软件测试模块类型都有哪些?请试着分别比较这些不同的測试类型的区别与联系(如功能测试、性能测试……)
易用性测试-界面的友好性，操作方便性等
功能测试-系统中功能性需求的满足
安全性测试-系统是否存在安全隐患和漏洞
性能测试-系统在大并发下的响应速度和健壮性
93、您认为做好测试计划工作的关键是什么?
了解项目或系统的业务需求
和项目经理协调好，了解项目的进度计划安排情况
95您认为做好测试用例设计工作的关键是什么?
对業务和软件需求非常清楚可以根据需求不同选择不同的测试用例设计
96、.您以往的工作中是否曾开展过测试用例的评审工作?如果有，请描述测试用例评审的过程和评审的内容
评审内容主要是测试用例对软件需求的覆盖程度，对于相关边界是否考虑是否针对复杂流程准备多套测试数据，是否有专门针对非功能性需求的测试
98.您认为性能测试工作的目的是什么?做好性能测试工作的关键是什么?
关键是測试脚本的录制，测试时候测试环境的干净
100、.您以往所从事的软件测试模块工作中，是否使用了一些工具来进行软件缺陷(Bug)的管理?如果有请结合该工具描述软件缺陷(Bug)跟踪管理的流程。
101、.您如何看待软件过程改进?在您曾经工作过的企业中是否有一些需要改进的东西呢?您期朢的理想的测试人员的工作环境是怎样的?
将先进的经验或思想固化到过程中，通过过程改进和能力提高来改进软件质量
