1.首先，当与开发出现分歧意见后，测试工程师应首先做如下分析：
一、问题确认与评估
再次论证该问题确实是程序缺陷，并评估该缺陷的重要程度并对其分类。比如可存在以下分类：
1、设计文档范围内的功能性缺陷
2、影响到程序的安全性和稳定性缺陷
3、界面缺陷
4、一般性错误（如未考虑边界检查等）
5、边缘死角，规律不明显，不太容易重现的错误
6、兼容性错误（例如旧机型、CPU\MEM,旧标准等等）
7、安全性或易用性等的修改建议
……（可扩展）
二、明确Dev不修改该缺陷的确切原因
比如可存在以下原因：
1、规律不明显，不好重现
2、dev认为是不影响主要功能的一般性bug,因时间处于版本的稳定期，担心牵一发动全身引起更多错误
3、调用了第三方组件或库函，是第三方程序存在的缺陷
4、存在技术难点
5、设计本身存在问题，程序逻辑是正确的，但实现结果并非用户所需（换言之，dev说这是设计问题，不是程序问题）
6、Dev的个人主观意见：
该瑕疵可以容忍，没必要修改
修改该瑕疵会引起更大的问题
7、Tester和dev对错误的理解有分歧：
tester理解错误，该问题并不是bug
tester没有说服dev这是个bug
……（可扩展）
三、具体问题具体分析
分析完第一、二步之后，也就基本上明确了问题的争议焦点，然后具体问题具体分析。分析什么Bug会让开发认为不是bug？
1.测试人员描述不清晰
工作中也有测试人员把某些“Bug操作步骤”描述的只有自己看得懂，开发人员按照步骤复现Bug不知所云，搞错了问题所在。
解决方法：
修改Bug操作步骤：清晰描述、无歧义、无冗余步骤，要达到即使给一个不懂的人去重现这个Bug，也能按照你的操作步骤复现。
2. 难以复现的Bug
不是所有的问题都能用同样的操作步骤来复现的，有的Bug概率出现甚至偶现，或者是只在测试环境里出现。
解决办法：
针对难以复现的Bug，需要保存截图或者记录log保留证据；对于只在测试环境下才会出现的，找研发在测试环境进行确认。这类Bug要慎重对待，规避风险。
3. 有争议的Bug
有争议的Bug多发生于建议类型的Bug：与同类软件不符、易用性、美观性等类型的Bug。
解决办法：
这种问题是否要修改需要根据公司的项目类型进行讨论。开Bug评审会，在开发能实现的情况下说出自己的理由，改善产品。
4. 功能性Bug
与需求不符、与原型设计不符。有时候研发对需求没有深入了解可能会忽略或者搞错个别功能。
解决办法：
拿证据（需求、设计说明书）给他看，这种bug自然合情合理。
四、发挥TM与PM的沟通职责
强调沟通
TM和PM有团队沟通的职责。在bug分类、指派和反馈过程中出现有争议的问题时，TM和PM有责任和义务进行干预。根据问题的重要程度和轻重缓急，采取不同的方式进行沟通，达成一致的解决意见，解决方法形成备忘录。
对因各种原因继续保留在发布版本中的bug,尤其可能影响功能的，应予以说明，提醒用户绕过。
经验教训库：这里的每个内容都是一个你犯过的错误，你在这里也记录的总结和反思；随着系统开发不断往前迭代，BUG的内容也会越来越丰富，沉淀了越来越多的经验，帮助我们了解错误原因所在，避免再犯。必须要说的是，一个团队要强大起来，先从自己的BUG系统开始做起。
2.LoadRunner分为哪三部分？
1.脚本生成器：录制调试脚本
捕获最终用户业务流程和创建自动性能测试脚本
2.场景控制器：用脚本生成场景、执行场景，并在场景执行时进行监控
用于组织、驱动、管理和监控负载测试
3.结果分析器：场景结束后将监控的指标整理成图标展现给用户
用于查看、分析和比较性能结果
3.LoadRunner进行测试的流程？
用LoadRunner进行负载测试的流程通常由五个阶段组成： 计划、脚本创建、场景定义、场景执行和结果分析。 (1)计划负载测试：定义性能测试要求，例如并发用户的数量、典型业务流程和所需响应时间。 (2)创建 Vuser 脚本：将最终用户活动捕获到自动脚本中。 (3)定义场景：使用 LoadRunner Controller 设置负载测试环境。 (4)运行场景：通过 LoadRunner Controller 驱动、管理和监控负载测试。 (5)分析结果：使用 LoadRunner Analysis 创建图和报告并评估性能。
-------------------------------------------------分割线-------------------------------------------------
LoadRunner 在负载下对基于 Web 的应用程序进行测试的过程（分六个步骤）： 1、计划测试 定义明确的测试计划将确保制定的 LoadRunner场景能完成您的负载测试目标。 2、创建 Vuser 脚本 Vuser通过与基于 Web 的应用程序的交互来模拟真实用户。Vuser 脚本包含场景执行期间每个 Vuser 执行的操作。 （1）每个 Vuser 执行 （2）同时多个 Vuser 执行 （3）选择具体的事务度量 3、创建场景 使用 LoadRunner Controller 创建场景。场景描述测试会话期间发生的事件。场景中包括运行 Vuser 的计算机列表、Vuser 运行的脚本列表以及场景执行期间运行的指定数量的 Vuser 或 Vuser 组。 通过定义 Vuser 组（将为这些组分配一些单独的 Vuser）、Vuser 脚本和运行脚本的负载生成器来创建场景。 或使用百分比模式来创建场景，在该模式下，您可以定义场景中要使用的 Vuser 的总数、负载生成器计算机以及要分配给每个 Vuser 脚本的 Vuser 占总数的百分比 4、运行场景 通过指示多个 Vuser 同时执行任务来模拟服务器上的用户负载。增加或减少同时执行任务的 Vuser 数可以设置负载级别。 创建手动场景模式： 运行场景之前，需要设置场景配置和计划。这将决定运行场景时所有负载生成器和 Vuser 的行为。可以运行整个场景、Vuser 组或单个 Vuser。场景运行时，LoadRunner 将度量并录制每个 Vuser 脚本中定义的事务。还可以联机监控系统的性能。 5、监控场景 使用 LoadRunner 监控运行时、事务、系统资源、Web 资源、Web 服务器资源、Web 应用程序服务器资源、数据库服务器资源、网络延时、流媒体资源、防火墙服务器资源、ERP/CRM 服务器资源、Java 性能、J2EE/.NET 事务细分、应用程序部署、中间件性能、应用程序组件和基础结构资源监控器来监控场景执行。 6、分析测试结果 在场景执行期间，LoadRunner 将录制不同负载下应用程序的性能。您可以使用 LoadRunner 的图和报告来分析应用程序的性能。
4.软件的评审一般由哪些人参加?其目的是什么?
人员:用户、客户或有关部门开发人员,测试人员,需求分析师都可以,就看处于评审那个阶段
在正式的会议上将软件项目的成果(包括各阶段的文档、产生的代码等)提交给用户、客户或有关部门人员对软件产品进行评审和批准。其目的是找出可能影响软件产品质量、开发过程、维护工作的适用性和环境方面的设计缺陷,并采取补救措施,以及找出在性能、安全性和经济方面的可能的改进。
5.什么时兼容性测试？侧重于那些方面？
一、兼容性测试就是测试电脑硬件之间是否有不兼容等问题或软件问题。
二、兼容性测试侧重哪些方面
1、向前兼容和向后兼容。向前兼容是指可以使用软件的未来版本，向后兼容是指可以使用软件的以前版本。
2、不同版本之间的兼容。实现测试平台和应用软件多个版本之间能够正常工作。
3、 标准和规范
高级标准是产品应当普遍遵守的。若应用程序声明与某个平台兼容，就必须接受关于该平台的标准和规范。低级标准是对产品开发细节的描述。
4、数据共享兼容。数据共享兼容是指要在应用程序之间共享数据，要求支持并遵守公开的标准，允许用户与其他软件无障碍的传输数据。
6.单元测试的内容有那些？
模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试
（1）模块接口测试：模块接口测试是单元测试的基础。只有在数据能正确流入、流出模块的前提下，其他测试才有意义。模块接口测试也是集成测试的重点，这里进行的测试主要是为后面打好基础。测试接口正确与否应该考虑下列因素：
-输入的实际参数与形式参数的个数是否相同
-输入的实际参数与形式参数的属性是否匹配
-输入的实际参数与形式参数的量纲是否一致
-调用其他模块时所给实际参数的个数是否与被调模块的形参个数相同；
-调用其他模块时所给实际参数的属性是否与被调模块的形参属性匹配；
-调用其他模块时所给实际参数的量纲是否与被调模块的形参量纲一致；
-调用预定义函数时所用参数的个数、属性和次序是否正确；
-是否存在与当前入口点无关的参数引用；
-是否修改了只读型参数；
-对全程变量的定义各模块是否一致；
-是否把某些约束作为参数传递。
如果模块功能包括外部输入输出，还应该考虑下列因素：
-文件属性是否正确；
-OPEN/CLOSE语句是否正确；
-格式说明与输入输出语句是否匹配；
-缓冲区大小与记录长度是否匹配；
-文件使用前是否已经打开；
-是否处理了文件尾；
-是否处理了输入/输出错误；
-输出信息中是否有文字性错误。
-局部数据结构测试；
-边界条件测试；
-模块中所有独立执行通路测试；
（2）局部数据结构测试：检查局部数据结构是为了保证临时存储在模块内的数据在程序执行过程中完整、正确，局部功能是整个功能运行的基础。重点是一些函数是否正确执行，内部是否运行正确。局部数据结构往往是错误的根源，应仔细设计测试用例，力求发现下面几类错误：
-不合适或不相容的类型说明；
-变量无初值；
-变量初始化或省缺值有错；
-不正确的变量名（拼错或不正确地截断）；
-出现上溢、下溢和地址异常。
（3）边界条件测试：边界条件测试是单元测试中最重要的一项任务。众所周知，软件经常在边界上失效，采用边界值分析技术，针对边界值及其左、右设计测试用例，很有可能发现新的错误。边界条件测试是一项基础测试，也是后面系统测试中的功能测试的重点，边界测试执行的较好，可以大大提高程序健壮性。
（4）模块中所有独立路径测试：在模块中应对每一条独立执行路径进行测试，单元测试的基本任务是保证模块中每条语句至少执行一次。测试目的主要是为了发现因错误计算、不正确的比较和不适当的控制流造成的错误。具体做法就是程序员逐条调试语句。常见的错误包括：
-误解或用错了算符优先级；
-混合类型运算；
-变量初值错；
-精度不够；
-表达式符号错。
比较判断与控制流常常紧密相关，测试时注意下列错误：
-不同数据类型的对象之间进行比较；
-错误地使用逻辑运算符或优先级；
-因计算机表示的局限性，期望理论上相等而实际上不相等的两个量相等；
-比较运算或变量出错；
-循环终止条件或不可能出现；
-迭代发散时不能退出；
-错误地修改了循环变量
7.性能测试指标？
响应时间
tps：每秒处理的事务数 吞吐量（描述的是服务器的处理能力）
资源利用率
用户数
8.性能测试流程？
需求分析 编写测试计划 编写测试方案 用例设计 测试执行 定位分析问题
9.性能测试计划
测试目标
测试人员组织
压测进度安排
压力机（配置，要求，数量）
风险
10.性能测试方案
测试工具：loadrunner （ HP：ALM缺陷管理工具 QTP/UFT自动化测试工具）
jmeter
测试环境：
数据库 服务器 架构设计 有条件的话尽量和生产环境一致
测试策略：单一场景 混合场景
监控工具：
linux （nmon rpc jvisualVm spotlight）
windows （spotlight perfmon.exe）
11.性能测试用例设计
测试脚本：基于脚本的用例
场景设计：基于场景的用例
12.性能测试用例执行
脚本编写 场景监控设计 运行场景 监控场景 测试报告
13.定位分析问题
后端： 代码
软件 （数据库， 应用服务器）
硬件
前端
网络
14.loadrunner三大组件
VuGen： 编写脚本
Controller： 运行脚本
Analysis： 分析运行结果
15.单元测试的策略
逻辑覆盖
循环覆盖
同行评审
桌前检查
代码走查
代码评审
静态数据流分析
16.中间件
个人理解：
将具体业务和底层逻辑解耦的组件。
大致的效果是：
需要利用服务的人（前端写业务的），不需要知道底层逻辑（提供服务的）的具体实现，只要拿着中间件结果来用就好了。