设计师常用软件缩写 第1篇
若测试报告为不能更新UAT，但经项目经理及客户同意，将该功能更新到UAT，则测试人员可不对测试报告中提出的不能更新的功能点负责。
人员要求：了解被测试的系统，具备诊断和解决问题的技能，编程技能
负责软件产品安装调试和部署，完成项目相关系统工程工作，负责客户技术支持，负责编写系统部署方案和使用手册、维护手册，负责系统实施计划和规划。
参考资料：
设计师常用软件缩写 第2篇
从职业角度，是指企业建立以项目经理责任制为核心，对项目实行质量、安全、进度、成本管理的责任保证体系和全面提高项目管理水平设立的重要管理岗位。项目经理是为项目的成功策划和执行负总责的人。 项目经理是项目团队的领导者，项目经理首要职责是在预算范围内按时优质地领导项目小组完成全部项目工作内容，并使客户满意。为此项目经理必须在一系列的项目计划、组织和控制活动中做好领导工作，从而实现项目目标。 当然在互联网公司这个有着项目经理or产品经理的意思。
如：软件RD工程师就是软件研发工程师，诸如PHP程序猿，Java程序猿，无论是爱疯的还是安卓的都是属于这一类别。偏向于后端的技术实现。
前端开发（Front-End Development）
FE是web前端研发、前端开发的意思！
是一种纯主观的在用户使用一个产品（服务）的过程中建立起来的心理感受。因为它是纯主观的，就带有一定的不确定因素。 个体差异也决定了每个用户的真实体验是无法通过其他途径来完全模拟或再现的。但是对于一个界定明确的用户群体来讲，其用户体验的共性是能够经由良好设计的实验来认识到。 计算机技术和互联网的发展，使技术创新形态正在发生转变，以用户为中心、以人为本越来越得到重视，用户体验也因此被称做创新模式的精髓。 另外还有有个组合叫法：UED（产品交互设计师，用户体验师）。
UI设计则是指对软件的人机交互、操作逻辑、界面美观的整体设计。好的UI设计不仅是让软件变得有个性有品味，还要让软件的操作变得舒适、简单、自由、充分体现软件的定位和特点。 UI还有其它的意义，如Unit Interval，Univ of Iowa，Unlock Instruction，Urgent Interrupt。
其在ISO8402：1994中的定义是“为了提供足够的信任表明实体能够满足质量要求，而在质量管理体系中实施并根据需要进行证实的全部有计划和有系统的活动”。有些推行ISO9000的组织会设置这样的部门或岗位，负责ISO9000标准所要求的有关质量保证的职能，担任这类工作的人员就叫做QA人员。
OP这个词语代表的意思很多，这个简称来自于英文的Operations一词。我也不清楚谁最早用op代表运维工程师，不过2010年开始，这个词慢慢被很多人所知道。 OP工作内容主要就是维护公司的服务器能够正常提供服务，细分的话包括系统部分，网络部分，应用程序部分，数据库部分，具体根据公司的规模和职位职能不同，运维的定义也不同。现在市面上主要的OP有三种：网络游戏运维，网站运维，大型项目测试和生产环境运维。
是一个负责管理和维护数据库服务器的人。数据库管理员负责全面管理和控制数据库系统。这个职位对不同的人意味着不同的意义。 另外还有DB，既数据库（Database）。 还有就是互联网产品设计常用文档类型的缩写： BRD、MRD、PRD、FSD等
是基于商业目标或价值所描述的产品需求内容文档(报告)。其核心的用途就是用于产品在投入研发之前，由企业高层作为决策评估的重要依据。其内容涉及市场分析，销售策略，盈利预测等，通常是供决策层们讨论的演示文档，一般比较短小精炼，没有产品细节。
BRD不同于常见的MRD和PRD，既然是用于产品实施之前的决策评估依据，必然对其文档（报告）的内容和格式要求够直观、精炼，要点突出。作为报告的撰写者，你必须让高层明白，你的报告中将展现出怎样的商业价值，如何用有力的论据来说服企业对你这个项目的认可，并为之慷慨的投入研发资源及市场费用。如果说PRD的好坏，直接决定了项目的质量水平，那么BRD的作用，就是决定了你的项目的商业价值。优秀的BRD文档，可以让决策层充分被你的报告观点所吸引，或许财务主管会因为报告呈现的低投入高产出的经济效益预测而蠢蠢欲动；或许技术主管会因为项目的牵涉面广泛而头疼不已；又或许公司的VP之流因之报告而看到了未来一年业绩的飞速发展的广阔前景……说白了，BRD需要产品经理（产品设计师）像对待PRD一样，充分应用市场调查、用户研究、需求分析等各种设计手段来充分阐述报告的内容。
获得老大的认同后，产品进入实施，需要先出MRD，具体来说要有更细致的市场与竞争对手分析，通过哪些功能来实现商业目的，功能/非功能需求分哪几块，功能的优先级等等。实际工作中，这个阶段PD可能的产出物有Mind Manager的思维图，Excel的Feature List等。
文档意义：该文档在产品项目中是一个“承上启下”的作用，“向上”是对不断积累的市场数据的一种整合和记录，“向下”是对后续工作的方向说明和工作指导。文档核心：侧重的是对产品所在市场、客户（client）、购买者（buyer）、用户（user）以及市场需求进行定义，并通过原型的形式加以形象化
撰写MRD，大致下几个方面（按先后顺序）着手：
1、项目背景；
2、名词解释；
3、可行性分析（前期调研信息和数据+项目预期目标）；
4、综合描述（功能概述+对其他产品的影响）；
5、功能详述（功能需求+功能点）；
6、其他问题描述。
4文档核心
市场需求文档（MRD）重点放在为一个被提议的新产品或者现有产品的改进定义市场需求。与BRD指出商业问题和解决这些问题的解决方案不同，MRD更深入提议解决方案的细节。它包括一些或者所有这些细节： a. 解决商业问题所需要的特色 b. 市场竞争分析 c. 功能和非功能需求 d. 特色/需求的优先级 e. 用例
MRD通常是由拥有产品经理，产品营销经理或者行业分析师头衔的人撰写的。MRD通常是一份连续的5-25页Word文档，或者正如之后描述那样在一些机构中甚至更长。
进步一细化，这部分是PD写得最多的内容，也就是传统意义上的需求分析，我们这里主要指UC（use case）文档。主要内容有，功能使用的具体描述（每个UC一般有用例简述、行为者、前置条件、后置条件、UI描述、流程/子流程/分支流程，等几大块），Visio做的功能点业务流程，界面的说明，demo等。Demo方面，可能用dreamweaver、ps甚至画图板简单画一下，有时候也会有UI/UE支持，出高保真的demo，开发将来可以直接用的那种。 文档意义：该文档在产品项目中是一个“承上启下”的作用，“向上”是对MRD内容的继承和发展，“向下”是要把MRD中的内容技术化，向研发部门说明产品的功能和性能指标。文档核心：侧重的是对产品产品功能和性能（即“产品需求”）的说明，相对于MRD中的同样内容，要更加详细，并进行量化。通常在特点和功能需求上更深入细节，并也可能包括屏幕截图和用户界面流程。在那些MRD不包括具体需求和用例的机构中，PRD就包含这些具体内容。在一些国外的公司，是允许把MRD和PRD合并成一个文档的，通常叫做“Marketing & Product Requirements Document”。该文档一般可以包括以下内容：
开发工具推荐 ：
产品需求文档（PRD）重点放在为一个被提议的新产品或者现有产品的改进定义市场需求。与MRD侧重于从市场需要角度看需求的不同，PRD侧重于从产品本身角度看待需求。通常在特点和功能需求上更深入细节，并也可能包括屏幕截图和用户界面流程。在那些MRD不包括具体需求和用例的机构中，PRD就包含这些具体内容。
在PRD中，只重视“产品功能”的描述，而缺乏对产品其它指标项的说明。在一个完整的PRD中，一共需要对产品的10个产品需求项指标进行说明，分别是“功能要求、开发要求、兼容性要求、性能要求、扩展要求、产品文档要求、产品外观要求、产品发布要求、产品支持和培训要求、产品其它要求”。
PRD通常是由拥有产品经理，行业分析师或者产品分析师头衔的人撰写的。PRD通常是一份连续的20-50页Word文档，或者针对复杂产品甚至更长。 提醒：一些机构将这里描述的MRD和PRD合并成一个文档，并称最后的文档为MRD。在这种情况下，MRD包括本段描述的内容，也包括上一段描述PRD的内容，并且可能超过50页。
设计师常用软件缩写 第3篇
若发生需求描述不明确，或与系统不兼容，甚至不能实现等需求问题，开发人员有权利拒绝本需求的开发，并与需求人员沟通提起需求的再分析。若接收到的BUG非系统功能问题，开发人员可进行拒绝处理，并根据实际情况进行解释或提起讨论分析。
职责： 执行测试，描述测试结果，提出问题解决方案。
B. 需求评审：评审需求人员编写的需求规格说明书，共同把控需求质量。
C. 理解需求：深入理解需求人员给出的需求规格说明书，掌握业务需求要点。
D. 编写测试案例：编写能覆盖需求内容、且能覆盖绝大部分业务行为的测试案例。
E. 发起评审：重大功能或核心功能的测试案例应发现评审，共同把控案例完备性。
F. 执行测试案例。
G. 复测BUG。
H. 出具测试报告：给出能否更新UAT的结论，若不能更新UAT，需给出哪些点不能更新。
什么叫测试工程师或质量小组：小组的责任当然是发现在开发中所出现的技术问题和错误，及时的向项目小组报告情况，并督使项目小组相关的开发人员解决被发现的问题。质量小组的人员的组成，当然首先会是开发小组中的全部技术人员。除此以外可以邀请公司里其他非项目小组的同事加入发现问题的队伍。一般项目的质量测试有以下4个过程：
A、白盒测试：就是项目的开发人员自己在平时的开发中，或者是在一个小模块开发完成后。测试自己的所开发模块的过程。其测试内容主要是自己原代码的完整性和规范性，自己开发的模块流程是否清晰、逻辑正确等等。
B、黑盒测试：由开发小组的人员互相交换或者在空闲时间干脆请公司里非开发项目小组的同事来帮助测试各个模块。重要的内容是：检查各个模块的连接是否紧密，各个超级连接是否正确，软件中是否有JS等报错，表单区域中的文本筐等和用户交互的部分是否有长度的限制？是否有超文本语言的过滤？是否有非法字符的验证？在用户填写相关信息出错的时候，程序是否有相关的处理等等。
C、用户测试：主要是邀请本项目外的其他同事以用户的角色来测试项目的功能。其内容主要是：评价每个模块的风格和项目的总体的风格是否冲突？功能是否能否实现，流程是否清晰，界面是否友好，页面安排是否舒适？各种连接所放的位置是否舒适等等。
D、负载测试：当项目看来可以很好的工作了，就可以开始负载测试的阶段。项目小组这个时候应该在公司和客户的帮助下，安排尽量多的用户登陆开发基本完成的项目，使项目尽可能的承受长时间和高强度的测试。这个时候往往会发现相当多的问题（特别是以程序为主的WEB站点）。比如程序运行时服务器出现内存溢出？CUP资源占用瞬间涨满？两个用户在数据库中查询同一数据时造成冲突？一些查询过程时间过长？甚至是一些客户端脚本与浏览器版本不兼容等等。
在质量小组每完成一步测试的时候，都要详细的写好测试结果，测试环境以及问题描述的报告直接交给项目经理，再由项目经理了解大概情况分发给问题相关的开发人员并监督其解决问题。