请问it行业平时说的p4,p5级别的工程师需要达到什么标准？

请问it行业平时说的p4,p5级别的工程师需要达到什么标准？

IT行业说的p4,p5级别的工程师要根据不同公司的级别来看，比如阿里巴巴，p4,p5是属于初级工程师，大概就是本科刚毕业就能到p5左右。

IT工程师是一个认证考试，具体地说是从事软件职业的人员的一种职业能力的认证，通过它说明具备了工程师的资格。

IT工程师的技术要求是比较全面的，除了最基础的编程语言（C语言/C++/JAVA等）、数据库技术（SQL/ORACLE/DB2等）等，还有诸多如JAVA script、AJAX、HIBERNATE、SPRING等前沿技术。此外，关于网络工程和软件测试的其他技术也要有所涉猎。

扩展资料：

IT工程师的职业需求

1、外包开发行业快速发展，对“人才”在代码和文档方面的规范性、技能和工具的熟练程度要求越来越高；

2、Java和.NET技术在市场上平分秋色，都有大量的岗位需求，同时值得庆幸的是二者在应用层面上的技术差异越来越少；

3、软件开发企业对开发人员的基本技术素养强调得越来越多，例如：面向对象的程序设计思想和代码组织方法、HTML/CSS/Javascript客户端技术；

4、为了保证质量和工期，企业中大量使用各种框架技术，要求开发人员至少熟悉一种框架技术。

软件缺陷管理

The First “Computer Bug” | 首个“计算机Bug”

1947年9月9日，哈佛大学测试马克II型艾肯中继器计算机，操作员在电板编号为70的中继器触点旁发现了一只飞蛾。然后操作员把飞蛾贴在计算机日志上了，并写下了“首个发现bug的实际案例”。他们提出了一个词，“debug（调试）”了机器，从而引入新术语“debugging a computer program（调试计算机程序）”。

In 1988,the log,with the moth still taped by the entry,was in the Naval Surface Warfare Center Computer Museum at Dahlgren,Virginia.

1988年，这个仍然贴着飞蛾的日志，保存于弗吉尼亚州达尔格伦的海军水面作战中心计算机博物馆。

以下的两句话明确了缺陷的产生。

软件缺陷的产生主要有软件产品的特点和开发过程决定的。比如需求不够清晰，频繁变更等；或者软件由于竞争非常激烈，技术日新月异，使用新技术也容易产生问题。大致有以下几种主要原因：

软件测试就是为了更早、更快的发现缺陷。换句话说，缺陷的发现可以看作是测试工作的主要成果之一。软件缺陷管理的实施，至少有如下三个基本目的：

软件缺陷（Defect），常常又被叫做Bug。所谓软件缺陷，即为计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。

bug 和 defect

飞蛾或者虫子爬进主机引起短路，造成计算机失效的事件中，我们可以看到bug就是虫子或者是虫子引发失效这样的事件。那么defect又是什么呢？

真正的Defect是计算机维护工程师提出来的那个问题：在主机的散热孔那里可以加装一层更加细密的金属网，即不影响散热，又可以防止虫子爬到主机里。这是计算机设计人员疏忽的地方，是产品真正的Defect。而虫子引发的那个故障只是这个Defect导致的故障的其中一种表现形式。也就是说，Bug是Defect的一种表现形式，而一个Defect是可以引起多种Bug的。

软件测试使用各种术语描述软件出现的问题，通用的术语如下：

在可以预见的时期内，软件仍将由人来开发。在整个软件生存期的各个阶段，都贯穿者人的直接或间接的干预。然而，人难免犯错误，这必然给软件留下不良的痕迹。软件错误是指在软件生存期内的不希望或不可接受的人为错误，其结果是导致软件缺陷的产生。可见，软件错误是一种人为过程，相对于软件本身，是一种外部行为。

软件缺陷是存在于软件（文档、数据、程序）之中的那些不希望或不可接受的偏差，如少一个逗号、多一语句等。其结果是软件运行于某一特定条件时出现软件故障，这时称软件缺陷被激活。

软件故障是指软件运行过程中出现的一种不希望或不可接受的内部状态。譬如，软件处于执行一个多余循环过程时，我们说软件出现故障。此时若无时当的措施（容错）加以及时处理，便产生软件失效。显然，软件故障是一种动态行为。

软件失效是指软件运行时产生 的一种不希望或不可接受的外部行为结果。失效是指功能部件执行其规定功能的能力丧失。软件失效是指软件运行时产生的一种不希望或不可接受的外部行为。

软件错误是一种人为错误。一个软件错误必定产生一个或多个软件缺陷。当一个软件缺陷被激活时，便产生一个软件故障；同一个软件缺陷在不同条件下被激活，可能产生不同的软件故障。软件故障如果没有集市的容错措施加以处理，便不可避免地导致软件失效；同一个软件故障在不同条件下可能产生不同的软件失效。

测试执行过程中，发现软件失效后，提出书面的报告，提供给开发人员或者其他负责人员作为定位缺陷的依据，也作为日后缺陷度量的数据依据。

软件缺陷的描述是软件缺陷报告的基础部分，也是测试人员就一个软件问题与开发小组交流的最初并且最好的机会。一个好的描述，需要使用简单、准确、专业的语言来抓住缺陷的本质。否则，它就会使信息含糊不清，可能会误导开发人员。因此，准确的报告软件缺陷是非常重要的。

软件缺陷的属性从大的方面包括以下几部分：

综上所述，一个完整的缺陷报告需要包括以下内容。

| 缺陷的状态 | 描述 |

| ---------------------------- | ----------------------- |

| 激活的或打开的（Active or Open） | 缺陷的起始状态，问题还没有解决，等待修复 |

| 已修正的或已修复的（Fixed or Resolved） | 已被开发人员检查和修复，等待验证人员验证 |

| 关闭的或非激活的（Close or Inactive） | 验证通过，确认缺陷已经可以关闭 |

| 重新打开 （Reopen） | 验证不通过，需要 |

| 推迟 （Deferred） | 缺陷不严重，在下一个版本中解决 |

| 保留 （On hold） | 由于技术原因或者其他原因，暂时无法解决 |

| 功能增强 | 发现的缺陷符合当前说明书。是一个有待改进的问题 |

| 不是缺陷 | |

| 不能重现 | |

| 需要更多信息 | |

| 缺陷的严重级别 | 描述 |

| ------------ | -------------------------------- |

| 致命（Fatal） | 系统的主要功能完全失效，用户利益受到损失、系统崩溃、死机等 |

| 严重（Critical） | 系统的主要功能部分失效，数据无法保存、提供的服务受到影响 |

| 一般（Major） | 系统的次要功能没有完全实现，不影响用户的正常使用，如提示不准确等 |

| 较小（Minor） | 用户体验不好，不影响功能实现 |

| 缺陷的优先级 | 描述 |

| -------- | ----------------------- |

| 立即解决（P1） | 缺陷导致系统不可使用，无法测试或者测试无法继续 |

| 高优先级（P2） | 缺陷严重，影响测试，需要优先考虑 |

| 正常排队（P3） | 缺陷需要正常排队等待修复 |

| 低优先级（P4） | 缺陷可以在开发人员有时间的时候被修正 |

缺陷的严重性和优先级是含义不同但相互联系密切的两个概念。它们都从不同的侧面描述了软件缺陷对软件质量和最终用户的影响程度和处理方式。

一般地，严重性程度高的软件缺陷具有较高的优先级。严重性高说明缺陷对软件造成的质量危害性大，需要优先处理，而严重性低的缺陷可能只是软件不太尽善尽美，可以稍后处理。

但是，严重性和优先级并不总是一一对应。有时候严重性高的软件缺陷，优先级不一定高，甚至不需要处理，而一些严重性低的缺陷却需要及时处理，具有较高的优先级。

生命周期的概念是从诞生到消亡所经历的过程。软件缺陷经历了从被发现、报告、到其被修复、验证、直至最后关闭的过程。为了完整的描述这个过程，设定了不同阶段的缺陷状态来体现缺陷不同的生命阶段。对于测试人员来说，需要关注软件缺陷状态的变化，并和开发人员保持良好的沟通，使缺陷能够及时得到处理和修正。

缺陷状态的跟踪

缺陷趋势的分析

缺陷分布分析

累计缺陷趋势分析

高分求软件测试的测试计划与测试用例,(详情如下)

Boffice软件系统测试计划
Windows计算器的测试计划
修订历史记录
版本 日期 添加/修改/删除 修订者 说明
2009-5-5 张XX
目录
1.简介
1. 1目的
Windows计算器的测试计划文档有助于实现以下目标：
1.确定现有项目的信息和应测试的软件构件
2.列出推荐的测试需求
3．推荐可采用的测试策略，并对这些策略加以说明
4.确定所需的资源，并对测试的工作量进行估计
5.对整个测试工作的工作量进行估计
6.对测试活动的进程进行有计划的实施
7.列出测试项目的可交付元素
1. 2背景
项目名称：计算器
任务提出者：
开发者：
用 户：个人
项目背景：windows自带软件••••••••
1. 3范围
测试的各个阶段：
测试设计：根据软件行业标准,制定测试计划、测试方案，包括收集测试方法、测试用例及可能的测试工具等。
系统测试：主要针对功能、界面、安装、版本验证进行测试，对经常使用的模块进行重点测试。
2.测试参考文档和测试提交文档
2.1. 测试参考文档
无
2.2. 将要用到文档
测试时间表、人员安排、测试总体计划、测试方案、测试分析报告、测试用例模版、测试报告单模版、测试用例通过情况统计表、各个模块的测试用例。
2.3. 测试提交文档
测试报告、测试记录、测试总结、工作日志。
2.4. 测试项目里程碑
里程碑任务 工作量 开始日期 结束日期
制订测试计划 X人/1.0天
设计测试用例 X人/0.5天
系统测试 X人/0.5天
测试总结 X人/0.5天
2.5. 各测试阶段资源要求及时间安排
人员 设备 时间安排
测试计划 5台计算机
测试设计 5台计算机
系统测试 5台计算机
测试总结 5台计算机
2.6. 问题优先级描述
严重程度：
Blocker 阻碍开发和/或测试工作
Critical 死机，数据丢失，内存溢出
Major 较大的功能缺陷
Normal 普通的功能缺陷
Minor 较轻的功能缺陷
Trivial 产品外观的问题或不影响使用的小毛病
Enhancement 建议或意见
优先级：
描述 响应时间
P1 用户使用频率高 督促开发发现问题后立即修改
P2 Minor轻微的缺陷 督促1-2个工作日修改
P3 Normal用户经常使用的功能 发布之前
P4 Trivial用户很少使用的功能 可以在发布后修改的问题
2.7. 备注
3.术语和定义

4.测试策略
4. 1．功能测试
测试目标： 系统提供的功能正常实现
方法： 测试开始阶段主要针对的功能实现进行测试。重要的功能应投入更多的精力进行测试，并及时小结
开始标准： 各个模块集成一起，即可开始
需考虑的特殊事项： 注意其中一些重要功能与实际效果相关，并不是简单的功能实现
4.2．界面测试：
测试目标 程序界面符合相关的规范
方法 按照规定逐项检查，包括菜单项，按钮，提示信息检查提示信息中的文字和标点符号，图标等
完成标准 程序界面与相关规定的要求统一
需考虑的特殊事项 注意启动画面和安装程序的版权信息注意版本信息
4.4.兼容性测试（资源不足，无法测试）
测试目标： 测试软件在当前微软系列操作系统中的运行情况，以及和同类文字处理软件的兼容性问题
方法： 1，在Microsoft Windows 98,ME,NT(Service Pack 6 之上),2000 及 XP中安装软件并能够正常运行，
2，测试软件与同类软件word97,word2000,word2003，WPS之间的兼容性问题。
3，与其它相关软件web浏览器，绘图程序等进行兼容性测试。
完成标准： 能够在微软系列操作系统中正常安装并且运行，可以识别和处理其它厂商同类软件生成的文件，同时产生的文件可以被其它厂商同类软件所正确识别和处理，对于其它相关软件如web浏览器，绘图软件等可以兼容运行。
需考虑的特殊事项： 无

如何看待软件测试在保证产品质量中所起的作用？

1. 软件测试基础（P1-3）
测试基础知识的学习目标
本章的学习目标：完成下面模块(module)的学习后，将明确能做什么。
1.1测试的必要性
 通过具体的例子，来描述软件中的缺陷(defect)会以什么样的方式损害个人、损害环境或者损害公司利益。
 区分引起缺陷的根本原因及其影响之间的区别。
 通过举例的方式说明为什么需要测试。
 描述为什么测试是质量保证(quality assurance)的一部分，通过举例说明测试是如何来提高软件质量的。
 理解术语错误(mistake)、缺陷、失效(failure)以及相应的术语错误(error)和bug之间的区别。
1.2 什么是测试 (K2)
 认识测试的共同目标。
 描述测试作为发现缺陷的一种手段，测试在软件开发、维护和运行中的目的，同时通过测试，可以增强对被测软件的信心并获得一些相关的信息，从而用来预防缺陷。
1.3 测试的基本原则
 说明测试的基本原则。
1.4 基本的测试过程
再次认识从计划到测试结束过程中测试的基本活动，以及在每个活动中的主要任务（K1）。
1.5 测试的心理学
 认识测试的成功与否，会受测试心理因素的影响：
 清楚的目标；
 自己测试和独立测试之间的平衡；
 认识到谦恭的沟通和缺陷反馈在测试中的作用。
 对比测试员(tester)和开发员(developer)的心理差异。
1.1 为什么需要测试 （P4-5）
术语
缺陷(bug)、缺陷(defect)、错误(error)、失效(failure)、故障（fault）、错误(mistake)、质量（quality）、风险(risk)、软件(software)、测试(testing)。
1.1.1 软件系统的状况
在当今社会，软件系统(system)越来越成为生活中不可或缺的一部分，包括从商业应用（比如银行系统）到消费产品（比如汽车）各个领域。然而，很多人都有这样的经历：软件并没有按照预期进行工作。软件的不正确执行可能会导致许多问题，包括经济的损失、时间的浪费和商业信誉的丢失等等，甚至导致人身伤害和死亡。
1.1.2 引起软件缺陷的原因
所有的人都会犯错误。该错误error会成为设计的代码、软件、系统和文档中的缺陷。当存在缺陷的代码被执行时，系统就可能无法执行期望的指令（或者做了不应该执行的指令），从而引起软件失效（故障）。虽然软件、系统和文档中的缺陷可能会引起失效，但并不是所有的缺陷都会这样。
产生缺陷的原因是多种多样的：人们本身容易犯错误、时间的压力、复杂的代码、复杂的系统架构、技术的革新、或者系统之间的配合工作等。
失效也可能是由于环境条件引起的：放射、电磁辐射和污染等都有可能引起硬件的故障，或者由于硬件条件的改变而影响软件的执行。
※ error（错误） → 缺陷（fault，bug） → 故障
1.1.3 在软件开发、维护和运行中测试的角色
对软件系统和文档进行严格的测试,可以减少软件系统在运行环境中的风险，假如在软件正式发布之前发现和修正了缺陷，就可以提高软件系统的质量。
进行软件测试也可能是为了满足合同和法律法规的需求，或者是为了满足行业标准。
1.1.4 测试和质量
通过测试，根据发现的缺陷，就可能发现软件系统在功能(functional)和非功能(non-functional)需求方面的缺陷，对软件质量(software quality)进行评判。飞功能需求包括：可靠性(reliability)、可用性(usability）、效率(efficiency)和可维护性(maintainability)等方面，关于非功能测试方面的更多信息，可以参考第二章。更多关于软件特征的信息，可以参考[ Software Engineering - Software Product Quality (ISO9126) ]。※ISO9126对应与国内规格：JIS-X0129。
当测试发现很少或者没有发现缺陷的时候，就会对软件的质量充满信心。一个设计正确、合理的测试过程完成并顺利通过，可以降低整个系统存在问题的风险。而对测试过程中发现的缺陷进行了修正，则软件系统的质量就会提高。
我们应该从以前的项目中总结经验教训。通过分析在其他项目中发现的缺陷和引起缺陷的根本原因，我们就可以改进测试过程(process)。相继地，过程的改进又可以预防相同的缺陷再次发生，从而提高以后系统的质量。
测试应该作为质量保证的各种作业中（例如：开发标准、教育、缺陷分析）的不可或缺的一部分。
1.1.5 测试是否充分
测试应该进行到哪种程度，取决于技术、产品、项目风险的水平，以及在时间和预算等方面项目上的限制。（风险将在第5章进行详细描述）
测试需要给利益相关者提供足够的信息，帮助他们决定是否发布被测的软件或系统，是否继续进行下阶段的开发或直接将产品交给用户。
追求完全的品质，从成本的角度来看没有效果

缺陷成本：为了修正而产生的成本、产生不良结果的成本
Joseph M. Juran 1.テストの必要性（3/3
1.2 什么是测试（P7-8）
术语
代码(code)、调试(debugging)、（软件）开发(development)、需求(requirement)、评审(review)、测试依据(test basis)、测试用例(test case)、测试(testing)、测试目标(test objectives)。
背景
在一般人的理解当中，测试活动只包含了运行测试，也就是执行软件。但实际上这只是测试的一部分，而不是测试的所有活动。
测试的活动包含了测试执行之前和之后的一些活动，包括计划(planning)和控制(control)、选择测试条件(test condition)、设计测试用例(test case)、检查测试结果(result)、评估完成准则(completion criteria)、报告测试过程(test process)及被测系统、测试结束或总结。测试同时也包括文档的评审(review)（包括代码）和静态分析(static analysis)。
动态测试(dynamic testing)和静态测试这两种手段都可以达到相似的目标，即以提供信息来改进被测试软件系统的质量，以及改善开发和测试的过程。