一. 1、PM: Product Manager，产品经理，又称品牌经理。举凡产品从创意到上市，所有相关的研发、调研、生产、编预算、广告、促销活动等等，都由产品经理掌控。
2、RD: Research and Development engineer，研发工程师，对某种不存在的事物进行系统的研究和开发并具有一定经验的专业工作者,或者对已经存在的事物进行改进以达到优化目的的专业工作者。
3、QA: Quality Assurance，品质保证。QA的主要职责就是质量保证工作。
4、OP: Operator，操作员，管理员。
扩展资料：
1、PM：（Project Manager），项目主管或项目经理，主要负责统筹规划项目进及产品生命，其工作职能直接对公司高层负责。作为项目的管理者，PM通常会参与到一个或多个项目的管理与决策工作中。
2、RD：模拟、数字，高频、低频，软件、硬件，模具、结构，甚至文字功底也必不可少，因为撰写产品使用手册、工艺指导书等等也可看出一个人的专业水准。要具备完善的知识体系，因此，全面的知识架构对于迅速完成产品开发任务非常重要，复合型人才更为难得。
3、QA：QUALITY ASSURANCE，中文意思是“质量保证”
4、OP：操作员是负责维护SQL SERVER系统的人员，操作员可以由一人担任，在那些拥有很多服务器的大型企业中，操作员也可以由多人担任。
二. 测试过程中遇到了不能复现的bug怎么办？
在测试过程中遇到不能复现的bug很正常，如果按照自己的想法，没有提交bug或者匆匆关闭bug。线上出现问题，那就只能自己背锅了。不能复现的bug大概有两种
1、第一种
在测试阶段，执行了一个用例未覆盖的场景，或者随机测试，盲目点点点，一旦产生了` bug ，很容易忘记之前操作了什么。对于这样的情况，通常根据 bug 的现象和当前的操作页面，可以大概推断出进行了哪些操作，尝试几次可能路径后，一般会找到导致缺陷的步骤。但是还有少量情况，无论怎么操作都无法复现刚才的 bug 。
2、第二种
对于已经提交给开发的 bug，在开发环境怎么也复现不了，开发要求关闭该 bug 。这种情况，就要分析提交给开发的 bug 描述是不是准确详细，有没有必要的前置条件，操作步骤是否详细，是否提供必要的截图信息。排查测试环境和开发环境的配置是否相同，可以要求开发在测试环境中验证通过再关闭该 bug 。一些没有经验的测试人员，在遇到第一种情况时，认为这种 bug 的概率非常小，可以不用提交 bug 。而且，开发人员有时候也要求必须有重新路径才能提交 bug，这样一旦线上出现问题，背锅的自然就是测试了。
作为软件测试人员，正确的做法是什么呢？
1.首先，在遇到非必然重现的 bug ，一定要提 bug ，并且要在 bug 单中说明复现的概率。
2.在发现 bug 时，要分析产生的原因，尽量多尝试可能出现的步骤。排除环境和自己电脑配置的原因，比如浏览器的版本，系统的版本等。
3.如果还未复现，在接下来的测试中，时刻保持关注，每次执行同样或者相近的步骤的时候，看下是否能够复现之前的 bug 。
4.那些一直未能复现的 bug ，需要测试经理定期将这些 bug 汇总，选择优先级高的缺陷，组织开发人员和测试人员专门投入到复现问题。
5.上线后及时关注用户的使用反馈，如果持续3或者4个版本没有出现，那么可以将 bug 暂时关掉了，同时关掉的时候要进行备注说明。
三.测试过程中遇到开发不认为是bug的bug怎么办？
开发人员说不是bug，有2种情况，
1. 需求没有确定。
可以找来产品经理进行确认需不需要改动，三方商量确定好后再看要不要改。
2. 这种情况不可能发生，所以不需要修改。
这个时候，我可以先尽可能的说出是BUG的依据是什么？如果被用户发现或出了问题，会有什么不良结果？程序员可能会给你很多理由，你可以对他的解释进行反驳。如果还是不行，那我可以把这个问题提出来，跟开发经理和测试经理进行确认，如果要修改就改，如果不要修改就不改。其实有些真的不是bug，我也只是建议的方式写进TD中，如果开发人员不修改也没有大问题。如果确定是bug的话，一定要坚持自己的立场，让问题得到最后的确认。
其实参考答案已经很完整了，但是可以看到上面的答案明显是偏向测试人员的，但有时开发说的并没错，测试要站在对方的角度换位思考。所以回答这个问题还可以从开发人员的角度延伸。
分析什么Bug会让开发认为不是bug
1. 测试人员描述不清晰
工作中也有测试人员把某些“Bug操作步骤”描述的只有自己看得懂，开发人员按照步骤复现Bug不知所云，搞错了问题所在。
解决方法：
修改Bug操作步骤：清晰描述、无歧义、无冗余步骤，要达到即使给一个不懂的人去重现这个Bug，也能按照你的操作步骤复现。
2. 难以复现的Bug
不是所有的问题都能用同样的操作步骤来复现的，有的Bug概率出现甚至偶现，或者是只在测试环境里出现。
解决办法：
针对难以复现的Bug，需要保存截图或者记录log保留证据；对于只在测试环境下才会出现的，找研发在测试环境进行确认。这类Bug要慎重对待，规避风险。
3. 有争议的Bug
有争议的Bug多发生于建议类型的Bug：与同类软件不符、易用性、美观性等类型的Bug。
解决办法：
这种问题是否要修改需要根据公司的项目类型进行讨论。开Bug评审会，在开发能实现的情况下说出自己的理由，改善产品。
4. 功能性Bug
与需求不符、与原型设计不符。有时候研发对需求没有深入了解可能会忽略或者搞错个别功能。
解决办法：
拿证据（需求、设计说明书）给他看，这种bug自然合情合理。
四.性能测试的指标有哪些？
1.吞吐量（Throughput）：指的是单位时间内处理的客户端请求数量，直接体现软件系统的性能承载能力。通常情况下，吞吐量用“请求数/秒”或者“页面数/分钟”来衡量。
2.并发（Concurrency）：它最简单的描述就是指多个同时发生的请求操作。（例如，1000个用户同时单击点击生成订单的操作。）
3.响应时间：指用户从客户端发起一个请求开始，到客户端接收到从服务器端返回结果整个过程所耗费的时间
4.点击数：是衡量Web服务器处理能力的一个重要指标。它的统计是客户端向Web服务器发了多少次HTTP请求计算的。通常我们也用每秒点击次数（Hits per Second）指标来衡量Web服务器的处理能力。
5.资源利用率：是指系统各种资源的使用情况，一般用“资源的使用量/总的资源可用量×100%”形成资源利用率的数据。
6.错误率：指系统在负载情况下，失败交易的概率。错误率＝(失败交易数/交易总数)*100%。
1. 不同系统对错误率要求不同，但一般不超过千分之五；
2. 稳定性较好的系统，其错误率应该由超时引起，即为超时率。
