请大家谈谈软件测试升职路线及各阶段应该掌握的技术

软件测试职业发展方向，大体上可以分为管理路线、技术路线、管理+技术路线。

测试初级阶段： 测试工程师，属于软件测试职业生涯的初级域，其适用范围是入行软件测试3年内的常规测试从业者，其主要工作内容是按照测试主管（即直接上司）分配的任务计划，编写测试用例、执行测试用例、提交软件缺陷，包括提交阶段性测试报告、参与阶段性评审等。 管理+技术路线： 首先是常规路线，这条发展路线要求管理与技术并重，因为软件测试的行业特点决定了这个因素：测试工程师向上晋升到测试主管、测试经理、测试总监，直至咨询域的更高方向！ 测试主管是企业项目级主管，对于中小型软件公司也可以是企业级主管，属于中级发展域，适用范围是2到5年职业经验的测试从业者。

其工作内容是根据项目经理或测试经理的计划安排，调配测试工程师执行模块级或项目级测试工作，并控制与监督软件缺陷的追踪，保证每个测试环节与阶段的顺利进行。严格来说，这个级别更多属于测试的设计者，因为企业的测试流程搭建是由更高级别的测试经理或相关管理者来做的，测试主管负责该流程的具体实施；而更多的工作，是思考如何对软件进行更加深入、全面的测试。

测试主管比较有创造性的工作内容就是测试设计，而恰恰很多公司忽略了或没有精力来执行此工作内容！应该说，在一个企业里做了3年左右测试工作的人员，很容易晋升到该职位，而之所以晋升，是与个人测试技术的过硬、测试方法的丰富，加上对测试流程的监控力与执行力的职业素质息息相关！ 测试经理是更高级别的测试管理者，属于高级测试方向域。对于大中型软件公司，该职位尤为重要，并且对其职业要求也比较高，一般适合4到8年的测试从业者，在管理与技术能力双双比较成熟的情况下，可以结合具体环境晋升到该级别。

测试经理负责企业级或大型项目级总体测试工作的策划与实施。测试经理除了需要统筹整个企业级或项目级测试流程外，还要对于不同软件架构、不同开发技术下的测试方法进行研究与探索，为企业的测试团队成员提供指导与解决思路，同时还要合理调配不同专项测试的人力资源（如业务测试工程师、自动化测试工程师、白盒测试工程师、性能测试工程师），对软件进行全面的测试；另外，一些企业里，测试经理还需要与客户交流与沟通，负责部分的销售性或技术支持性工作。

测试总监，属于常规发展路线的最高域，该职位一般在大型或跨国型软件企业，或者专向于测试服务型企业有所设立，一般设立测试总监的企业，该职位都相当于CTO或副总的级别，是企业级或集团级测试工作的最高领导者，驾驭着企业全部的测试与测试相关资源，管理着企业的全部测试及质量类工作。而其职业要求，也是技术与管理双结合。

技术路线： 技术路线中级域： 技术路线，划分为三个半方向，分别是自动化测试工程师、白盒测试工程师、性能测试工程师和认证测试工程师；前三者适用于通用软件测试领域，认证测试工程师乃嵌入式测试领域职位，至少目前仅出现在嵌入式领域。 自动化测试工程师，定义在功能测试范畴，指通常所说的依靠自动化测试工具进行软件黑盒测试的工程师。

从大环境讲，自动化测试是软件测试执行阶段的必然趋势，社会对于软件测试的认可度以及对自动化测试人才的需求必将日益增加。 白盒测试工程师，定位于在软件测试周期的单元测试阶段对软件进行的代码级测试的人，包括代码走读、代码功能与逻辑测试、代码内存泄漏检查、代码运行效率检查、代码测试覆盖率分析等。

如果说，自动化测试只是依靠脚本语言完成测试脚本编写与调试的过程（因为自动化测试工程师的工作重点不在编写脚本），对于自动化测试工程师的技术要求要相对偏低的话，那么白盒测试工程师就要对大型程序开发语言的完全掌握，因此其技术要求相对偏高！ 性能测试工程师，即在系统测试阶段、功能测试后对软件系统性能指标进行采集分析和运行效率检测的人。在一个尽量压缩的测试流程里，功能测试可以手工进行，白盒测试可以不做，但是性能测试必须要做，除非该软件非网络类软件即单机版软件！软件测试，从宏观上可以划分为三个大方面：功能测试、性能测试、安全性测试，功能测试说明软件做对了，功能测试+性能测试说明软件做好了，三者结合起来说明软件做的非常好！安全测试暂且抛之不提，这是下一个发展域的内容，但是为了把软件做好，为了真正保证软件的质量，性能测试绝不容忽视；只因目前很多企业由于时间、成本、人力条件的限制，暂且不做性能测试。

性能测试工程师相对来说，是三个技术路线里技术要求最高的，因为软件的性能瓶颈归根结底落实到代码的运行效率这个问题上，因此性能测试要做好，性能测试工程师起码要懂开发；而为了发现性能问题，要懂软件开发架构；为了定位性能问题，要懂操作系统、网络协议、应用服务器乃至数据库的原理与使用；为了最终解决性能问题，要根据定位的问题有针对性的对代码、操作系统、网络架构、服务器、数据库进行优化！当然性能测试是一个系统工程师，绝对不是一两个人的事情，对于常规性能测试工程师。

软件测试报告例文

以前写的东西 省略着写 XX软件测试报告 共 x 页 拟制 年 月 日审核 年 月 日会签 年 月 日批准 年 月 日 1 范围本文档适用于XX软件的单元/集成测试。

1.2 系统概述1.3 文档概述本文档用于对XX软件的测试工作阶段成果的描述。包括对软件测试的整体描述，软件测试的分类和级别，软件测试的过程描述，软件测试的结果等内容。

2 引用文档《XX软件需求规格说明》《XX软件设计说明》《XX系统接口协议》3 测试概述3.1被测软件的基本概况使用的编程语言：XXX 汇编语言程序行数：1590子程序个数：11单行注释行数：669注释率：约为42%3.1.1. 测试小结本次测试对XX软件进行了静态分析和动态测试。测试工作分为两个阶段。

第一阶段进行了软件静态分析，软件测试人员和开发人员分别对软件V1.00版本的代码进行走读。在此基础上软件开发人员对代码走查中发现的问题进行了修改，做了97处代码变更并提交了V1.01版本进行动态测试。

在测试过程中针对发现的软件缺陷进行了初步分析，并提交程序设计人员对原软件中可能存在的问题进行考查。在软件测试中首先根据软件测试的规范进行考核，将书写规范，注释等基础问题首先解决，其次考核软件测试中的问题是否存在设计上的逻辑缺陷，如果存在设计缺陷则应分析该缺陷的严重程度以及可能引发的故障。

软件开发人员在以上基础上对软件的不足做出相应的修改，同时通过软件回归测试验证软件修改后能够得到的改善结果。 软件代码1.00与1.01版变更明细表： 编号 1.00版行号 1.01版行号 更改说明 1 19 22 注释变更 2 26 29 注释变更 3 29 32 注释变更 4 95 98 注释变更 5 108行后 113~116 增加新变量 6 171、172 180、181 命令字大小写变更 7 以下略 从上表可以看出，注释变更一共有15处，主要排除了对原程序的理解错误问题；根据程序的书写规范要求，一行多条语句改为一行一条语句的更改一共有42处；命令字大小写变更一共有7处；在代码走查中对冗余和无用的代码作了更改，将这些代码注释掉，此类更改一共有14处。

上述4类更改一共有78处，这些更改对程序本身的功能没有任何影响，但从软件规范的角度来看提高了程序的可读性和规范性。其余19处变更为代码变更，主要是在软件测试中发现原程序的可靠性不足，在不改变原程序功能的基础上相应的增加了新变量、新语句、新程序以提高整个程序的可靠性。

在动态测试阶段进行了单元测试和集成测试。此阶段发现的软件问题经软件测试人员修改，提交了V1.02版本，软件测试人员对此版本的软件代码进行了回归测试，确认对前阶段发现的软件问题进行了修改，消除了原有的软件问题并且确认没有引入新的软件问题。

认定V1.02版为可以发行的软件版本。3.1.1.1 静态分析小结静态测试采用人工代码走查的方式进行。

参加代码走查的软件开发人员有：（略）；参加代码走查的软件测试人员有：（略）。代码走查以代码审查会议的形式进行。

静态分析过程中共进行了四次会议审查。静态测试阶段的主要工作内容是：l 根据对软件汇编源代码的分析绘制详细的程序流程图和调用关系图（见附件1）;l 对照软件汇编源代码和流程图进行程序逻辑分析、算法分析、结构分析和接口分析；l 对软件汇编源代码进行编程规范化分析。

通过静态测试查找出软件的缺陷18个，其中轻微的缺陷4个，占所有缺陷的22.2%中等的缺陷11个，占所有缺陷的61.1%严重的缺陷：3个，占所有缺陷的16.7%上述软件缺陷见附件《软件问题报告单》3.1.1.2 动态测试小结动态测试使用的测试工具为XXX软件集成开发环境。总共的测试用例数：143个。

全部由测试人员人工设计。其中单元测试用例138个，集成测试用例5个。

发现的软件缺陷有2个，都是在单元测试过程中发现的。集成测试阶段未发现新的软件缺陷。

在发现的软件缺陷中：中等的缺陷1个，占所有缺陷的50%严重的缺陷1个，占所有缺陷的50%上述软件缺陷见附件《软件问题报告单》动态测试中代码覆盖率：代码行覆盖率 100%分支覆盖率 100%程序单元调用覆盖率 100%3.1.1.3 回归测试小结对软件测试过程中发现的缺陷经软件开发人员确认后进行了代码更改，并对更改后的代码进行了回归测试。本报告中的数据是回归测试后的测试数据。

3.1.1.4 测试分析下面将对此次软件测试中的所有缺陷以及改进设计进行分析。1. 静态测试中的缺陷分析： 1) 4个轻微缺陷属于代码冗余，由于在程序设计中加入了部分调试程序，在程序设计完成后未将这些调试代码注释或删除掉而造成代码冗余，但对程序本身的功能并无影响。

修改后程序的效率得到提高。2) 11个中等缺陷属于注释变更，在原程序代码的注释中存在注释不准确的问题，会影响程序员对程序的理解，修改后的程序提高了程序的可读性。

3） 重点分析3个严重缺陷：第一个严重缺陷属于XX号的无效判别和相应的处理问题，程序对XX号进行无效判别时，判别界限并不完全，在本跟踪程序中XX号的有效数为01-10（用4位表示），而判别无效时只判了为00的情况，没有判别大于10的情况。而且在为00时也没有作相应的处理，修改后的程序对设计进行了改进，详见改进设计分析3。

第二个严重。

软件测试报告怎么写

摘要 测试报告是把测试的过程和结果写成文档，并对发现的问题和缺陷进行分析，为纠正软件的存在的质量问题提供依据，同时为软件验收和交付打下基础。本文提供测试报告模板以及如何编写的实例指南。 关键字 测试报告 缺陷 正文 测试报告是测试阶段最后的文档产出物，优秀的测试经理应该具备良好的文档编写能力，一份详细的测试报告包含足够的信息，包括产品质量和测试过程的评价，测试报告基于测试中的数据采集以及对最终的测试结果分析。下面以通用的测试报告模板为例，详细展开对测试报告编写的具体描述。PARTⅠ 首页0.1页面内容： 密级 通常，测试报告供内部测试完毕后使用，因此密级为中，如果可供用户和更多的人阅读，密级为低，高密级的测试报告适合内部研发项目以及涉及保密行业和技术版权的项目。 XXXX项目/系统测试报告 报告编号 可供索引的内部编号或者用户要求分布提交时的序列号 部门经理 ______项目经理______ 开发经理______测试经理______ XXX公司 XXXX单位 （此处包含用户单位以及研发此系统的公司） XXXX年XX月XX日 0.2格式要求： 标题一般采用大体字（如一号），加粗，宋体，居中排列 副标题采用大体小一号字（如二号）加粗，宋体，居中排列 其他采用四号字，宋体，居中排列 0.3版本控制： 版本 作者 时间 变更摘要 新建/变更/审核 PARTⅡ 引言部分 1.1编写目的 本测试报告的具体编写目的，指出预期的读者范围。 实例：本测试报告为XXX项目的测试报告，目的在于总结测试阶段的测试以及分析测试结果，描述系统是否符合需求（或达到XXX功能目标）。预期参考人员包括用户、测试人员、、开发人员、项目管理者、其他质量管理人员和需要阅读本报告的高层经理。 提示：通常，用户对测试结论部分感兴趣，开发人员希望从缺陷结果以及分析得到产品开发质量的信息，项目管理者对测试执行中成本、资源和时间予与重视，而高层经理希望能够阅读到简单的图表并且能够与其他项目进行同向比较。此部分可以具体描述为什么类型的人可参考本报告XXX页XXX章节，你的报告读者越多，你的工作越容易被人重视，前提是必须让阅读者感到你的报告是有价值而且值得浪费一点时间去关注的。 1.2项目背景 对项目目标和目的进行简要说明。必要时包括简史，这部分不需要脑力劳动，直接从需求或者招标文件中拷贝即可。 1.3系统简介 如果设计说明书有此部分，照抄。注意必要的框架图和网络拓扑图能吸引眼球。 1.4术语和缩写词 列出设计本系统/项目的专用术语和缩写语约定。对于技术相关的名词和与多义词一定要注明清楚，以便阅读时不会产生歧义。 1.5参考资料 1.需求、设计、测试用例、手册以及其他项目文档都是范围内可参考的东东。 2.测试使用的国家标准、行业指标、公司规范和质量手册等等 PARTⅢ 测试概要 测试的概要介绍，包括测试的一些声明、测试范围、测试目的等等，主要是测试情况简介。（其他测试经理和质量人员关注部分） 2.1测试用例设计 简要介绍测试用例的设计方法。例如：等价类划分、边界值、因果图，以及用这类方法（3-4句）。 提示：如果能够具体对设计进行说明，在其他开发人员、测试经理阅读的时候就容易对你的用例设计有个整体的概念，顺便说一句，在这里写上一些非常规的设计方法也是有利的，至少在没有看到测试结论之前就可以了解到测试经理的设计技术，重点测试部分一定要保证有两种以上不同的用例设计方法。 2.2测试环境与配置 简要介绍测试环境及其配置。 提示：清单如下，如果系统/项目比较大，则用表格方式列出 数据库服务器配置 CPU： 内存： 硬盘：可用空间大小 操作系统： 应用软件： 机器网络名： 局域网地址： 应用服务器配置 ……. 客户端配置 ……. 对于网络设备和要求也可以使用相应的表格，对于三层架构的，可以根据网络拓扑图列出相关配置。 2.3测试方法（和工具） 简要介绍测试中采用的方法（和工具）。 提示：主要是黑盒测试，测试方法可以写上测试的重点和采用的测试模式，这样可以一目了然的知道是否遗漏了重要的测试点和关键块。工具为可选项，当使用到测试工具和相关工具时，要说明。注意要注明是自产还是厂商，版本号多少，在测试报告发布后要避免大多工具的版权问题。

软件测试评审报告咋写,画完用例图后老师让写评审报告,不知道咋写

评审过程的规范性： 1、评审的准入； 2、评审的准出； 3、评审这个过程的一些要求： 如哪些评审员参加？计划性如何？使用检查单？预审情况？缺陷发现情况？缺陷修复情况？总结分析情况及评审结论？ 4、识别一些改进机会，记录NC自己整理吧 下面是模板2楼 性能测试目标中应对响应时间和处理能力指标进行明确的定义 性能测试模型评审完成 性能测试模型中应具备明确的测试场景名称以及使用该场景的原因说明 测试场景中应具备明确的虚拟用户名称、数量/百分比、思考时间（ThinkTime）、检查点、测试数据说明 测试场景应具备明确的测试环境说明，包括应用版本、网络架构、应用技术架构、服务器硬件设备信息、应用平台的版本和关键参数设置信息 测试场景应具备明确的被测应用系统基础数据信息，包括基础数据量、类型（模拟数据/生产数据） 性能测试过程评审完成 性能测试过程包含了性能测试规程中规定的所有不可裁减的测试任务 每项测试任务应具备明确的测试方法说明 每项测试任务应具备明确的状态（完成/未完成） 若某项测试任务未完成，则该项测试任务应具备明确的未完成原因以及解决方法说明 性能测试单项任务数据分析评审完成 每个单项任务应具备明确的测试目的 每个单项任务应具备明确的测试数据分析 性能测试结论评审完成 每个性能测试目标应具备至少一条结论 每条结论应针对一个具体的性能测试目标 性能测试缺陷评审完成 所有已发现缺陷都具备了明确的状态（已解决/未解决） 所有遗留缺陷都具备了明确的追踪解决方案（监督责任人、期望解决结果、期望解决时间、解决方法、解决责任人） 性能测试分析报告评审完成 若有一项评审结果为“不通过”，则此项为“不通过” 所有与会各方人员签字认可评审结果 若有一方人员未到场，此次评审视为无效。

评审会议结束后，将会议记录与会议结论发送给缺席方人员进行离线评审。 获得缺席方离线评审意见后，修订评审结果，此次评审方可视为有效。

3.3.3模版 名称：《性能测试分析报告评审报告》内容： 项目（群）组名称 会议召集时间 会议地点 与会人员、角色及部门名称 主持人员、角色及部门名称 记录人员、角色及部门名称 性能测试背景评审结果：通过/不通过 性能测试需求评审结果：通过/不通过 性能测试目标评审结果：通过/不通过 性能测试模型评审结果：通过/不通过 性能测试过程评审结果：通过/不通过 性能测试单项任务数据分析评审结果：通过/不通过 性能测试结论评审结果：通过/不通过 性能测试缺陷评审结果：通过/不通过 性能测试分析报告评审结果：通过/不通过 性能测试评审会议有效性：有效/无效 参与各方人员签字3.4 活动：评审结果的发布3.4.1准入标准 性能测试评审会议有效性：有效 性能测试分析报告：通过3.4.2准出标准 性能测试分析报告评审报告已经发送给所有相关各方，应包括：项目实施管理条线、业务IT管理条线、相关业务部门、数据中心、项目（群）组、测试管理部、技术测试部、业务测试部等 性能测试分析报告评审报告由技术测试部备案 3.4.3模版N/A 3.5 活动：评审结果的跟踪3.5.1准入标准性能测试分析报告中的所有遗留缺陷都具备了明确的追踪解决方案（监督责任人、期望解决结果、期望解决时间、解决方法、解决责任人） 给你个图，下载了看大图吧。很大，要放大看。

软件系统测试报告怎么写

二、软件测试报告的正文的格式

1 范围

1.1 标识

列出本文档的：

a. 已批准的标识号；

b. 标题；

c. 缩略语；

d. 本文档适用的系统计算机软件配置项（CSCI）。此外，还应包括在本报告中记录的每个正式合格性测试的名称和编号。

1.2 系统概述

概述本报告所适用的系统和CSCI 的用途。

1.3 文档概述

概述本报告的用途和内容。

2 引用文档

按文档号和标题列出本文档引用的所有文档。

3 测试概述

分节描述本报告所覆盖的每项正式合格性测试的结果。

3.1 （正式合格性测试名称及项目的唯一标识号）

按名称和编号来说明正式合格性测试，并分小节概述测试结果。

3.1.1 （正式合格性测试名称）小结

总结正式合格性测试的结果。若失败，则要说明产生错误结果的测试步骤和问题报告。这些内容可参考表1 的测试结果一览表进行概括。

3.1.2 （正式合格性测试名称）测试记录

按时间顺序记录所有测试前、进行测试、分析、说明以及正式合格性测试结果等有关事件。同时，还庆提供测试日志，按时间顺序记录正式合格性测试中的工作，包括：

a.测试时间、地点、软硬件的配置。需要时，测试配置项的描述还要记录软件版本号、研制单位、升级号、批准日期及所有硬件型号和软件部件使用的名

称；

b.每一个测试相关活动的日期和时间、测试操作人员和参加人员；

c.测试过程中对所出现和产生的问题所采取的测试步骤，包括对问题的改

进的次数和每一次结果；

d.恢复重新测试的备份点或测试步骤。

4 测试结果

分节详述每个正式合格性测试的细节。

4.X （正式合格性测试的名称和项目的唯一标识号）测试结果

从4.1 节开始编号。按名称和项目唯一标识号标识正式合格性测试，并分小节详细描述每一正式合格性测试用例的结果。

表1 测试结果一览表示例

（缺）

1） 如果测试过程出现一个故障或错误，则记录发生故障或错误的各个步骤。

2) PR=问题报告。

4.X.Y （测试用例名称和项目的唯一标识号）

从4.1.1 节开始编号，按名称和项目的唯一标识号标识每一测试用例，并分小节详细说明测试用例的结果。

4.X.Y.1 （测试用例名称）测试结果

说明测试用例的测试结果。对测试过程的每一步都要记录测试结果和在测试

过程中出现的各种异常和矛盾情况。记录或引用有助于杜绝和纠正矛盾情况的信息（如存储器转储、寄存器记录、显示流程图），并分析导致矛盾的原因和改进的方法。

4.X.Y.2 （测试用例名称）测试过程中的差异情况

详细说明相应的软件测试说明中描述的测试过程中的差异情况（例如，所需设备的替换，支持软件的改变，测试计划的偏差）。对每一种差异情况，必须说明导致差异的原因和它对测试有效性的影响。

5 CSCI 评估和建议

5.1 CSCI 评估

全面分析测试结果，对CSCI 的能力作出评估。通过分析标出存在的缺陷、局限性和CSCI 的约束等，并写入软件问题/更改报告。对每一种偏差，局限性和约束应包括：

a. 说明它对于CSCI 及系统运行的影响；

b. 说明它对于CSCI 及为纠正偏差的系统设计的影响；

c. 提供改必的方法和建议。

5.2 改进建议

对系统设计、操作和CSCI 测试提出改进建议，并分析每一建议对CSCI 的影响。若无建议，则写“无”。

游戏软件测试报告怎么写

评测的主要内容：

1.操作性评测：即画面的质理，鼠标键盘的操作等方面

2.功能性评测：即是否达到游戏运营商所宣传的功能，

如：人物飞天功能，需测试人物飞天功能在何时3能触发，

飞行的感觉及飞行时的辅带情况。

3.性能评测：即游戏的运行速度及测试机型-每秒FPS,

CPU占用率，内存使用率等。

4.游戏特点：即列出所评测游戏的具体特点，适合的年龄

层次、性别、公会进驻的优劣。

5.其它：如网游的BUG，自己在游戏中的经验（可省）

具体测试工具，如测每秒帧数可直接在网上搜索即得。

一篇测评文章需要对各类评测内容进行评分，而评分的方式多种多样，但老K在这里也希望有一个评分规定，这需要各位能仔细思考下做一个综合评定标准。可能适合DW公会这一块占比例较大，其它各占其中。