·· 报告名称（软件名称+版本号+用户端类型（android，iphone，后台管理等等）+测试范围（单元，集成，系统，模块等等）+测试报告）

·· 报告委托方，报告责任方，报告日期等

·· 版本变化历史

·· 密级

2、引言

2.1编写目的

本测试报告的具体编写目的，指出预期的读者范围。

2.2 项目背景

对项目目标和目的进行简要说明。必要时包括简史，这部分不需要脑力劳动，直接从需求或者招标文件中拷贝即可。

2.3 系统简介

如果设计说明书有此部分，照抄。注意必要的框架图和网络拓扑图能吸引眼球。

2.4 术语和缩略语

列出设计本系统/项目的专用术语和缩写语约定。对于技术相关的名词和与多义词一定要注明清楚，以便阅读时不会产生歧义。

2.5 参考资料

3、测试概要

测试的概要介绍，包括测试的一些声明、测试范围、测试目的等等，主要是测试情况简介。（其他测试经理和质量人员关注部分）

3.1测试方法(和工具)

简要介绍测试中采用的方法(和工具)。

3.2测试范围

介绍本次所测试的软件功能

3.3测试环境与配置

简要介绍测试环境及其配置。

4、测试结果与缺陷分析

整个测试报告中这是*激动人心的部分，这部分主要汇总各种数据并进行度量，度量包括对测试过程的度量和能力评估、对软件产品的质量度量和产品评估。对于不需要过程度量或者相对较小的项目，例如用于验收时提交用户的测试报告、小型项目的测试报告，可省略过程方面的度量部分；而采用了CMM/ISO或者其他工程标准过程的，需要提供过程改进建议和参考的测试报告－主要用于公司内部测试改进和缺陷预防机制－则过程度量需要列出。

4.1测试执行情况与记录

描述测试资源消耗情况，记录实际数据。（测试、项目经理关注部分）

4.1.1测试组织

可列出简单的测试组架构图

4.1.2测试时间

列出测试的跨度和工作量，*好区分测试文档和活动的时间。数据可供过程度量使用。

4.1.3测试版本

4.2覆盖分析

4.2.1需求覆盖

需求覆盖率是指经过测试的需求/功能和需求规格说明书中所有需求/功能的比值，通常情况下要达到100%的目标。

4.2.2测试覆盖

需求/功能（或编号） 用例个数 执行总数 未执行 未/漏测分析和原因

测试覆盖率计算 执行数/用例总数 ×100%

.3缺陷的统计与分析

缺陷统计主要涉及到被测系统的质量，因此，这部分成为开发人员、质量人员重点关注的部分。

4.3.1缺陷汇总

被测系统系统测试回归测试总计

合计

按严重程度

严重 一般 微小

按缺陷类型

用户界面 一致性 功能 算法 接口 文档 用户界面 其他

按功能分布

功能一 功能二 功能三 功能四 功能五 功能六 功能七

*好给出缺陷的饼状图和柱状图以便直观查看。俗话说一图胜千言，图标能够使阅读者迅速获得信息，尤其是各层面管理人员没有时间去逐项阅读文章。

4.3.2缺陷分析

本部分对上述缺陷和其他收集数据进行综合分析

缺陷综合分析

缺陷发现效率 = 缺陷总数/执行测试用时

可到具体人员得出平均指标

用例质量 = 缺陷总数/测试用例总数 ×100%

缺陷密度 = 缺陷总数/功能点总数

缺陷密度可以得出系统各功能或各需求的缺陷分布情况，开发人员可以在此分析基础上得出那部分功能/需求缺陷*多，从而在今后开发注意避免并注意在实施时予与关注，测试经验表明，测试缺陷越多的部分，其隐藏的缺陷也越多。

4.3.3残留缺陷与未解决问题

残留缺陷

评价：对这些问题的看法，也就是这些问题如果发出去了会造成什么样的影响

5、测试结论与建议

5.1 测试结论

1． 测试执行是否充分（可以增加对安全性、可靠性、可维护性和功能性描述）

2． 对测试风险的控制措施和成效

3． 测试目标是否完成

4． 测试是否通过

5． 是否可以进入下一阶段项目目标

5.2 建议

1．对系统存在问题的说明，描述测试所揭露的软件缺陷和不足，以及可能给软件实施和运行带来的影响

2．可能存在的潜在缺陷和后续工作

3．对缺陷修改和产品设计的建议

4．对过程改进方面的建议

6、附录

· 缺陷列表

· 缺陷等级定义标准

· 测试通过标准

八、测试策略

策略，百度解释为：“策略”就是为了实现某一个目标，首先预先根据可能出现的问题制定的若干对应的方案，并且，在实现目标的过程中，根据形势的发展和变化来制定出新的方案，或者根据形势的发展和变化来选择相应的方案，*终实现目标。

软件测试的目标是验证软件的功能，找出存在的问题，评估软件质量是否达到要求。软件测试策略要围绕这么目标去考虑和制定。测试策略描述了测试项目和测试任务之间的关系。它用来说明要测什么，如何测，如何协调测试资源和测试时间等。他的目的和作用是指导测试工程师进行测试工作的总体方向和侧重点。测试策略制定的是否合理高效会对测试项目的进度产生很大的影响。

测试策略分为了以下几个模块：

1. 测试安排、发布计划

这个模块用来罗列测试项目本身重要的里程碑，每个里程碑都需要有明确的结束时间，这个时间可以指导我们后续的测试。如果测试时间安排不足，我们就可以在后续的测试范围中挑选优先级比较高的特性来执行测试，这样可以*大限度的保证产品的质量。

2. 测试范围（按优先级排列）

这一部分分为In Scope和Out Of Scope.这一部分需要说明哪些产品模块是在测试范围中的，哪些是本阶段测试不考虑的。对于在测试范围中的模块，需要给出优先级以便相应测试时间不足的情况；对于不在测试范围中的模块，需要给出原因（为什么在本测试阶段不考虑测）。

3. 测试资源

测试资源在测试策略中也是很重要的一环，它分为人力和工具两部分。人力资源主要说明参与测试的人员，当然可以包括很多的角色，如何专业测试人员，客户，产品经理等。工具主要是指可能用到其他软件（可能需要license）。

4. 测试环境

测试环境主要包括推荐环境解决方案，操作系统要求，软硬件要求。

5. 测试方法

测试方法的罗列主要是为了说明针对测试项目我们要开展哪些类型的测试，功能测试是必须的，非功能测试是可选的。测试方法的选择主要根据软件的所要达到的质量特性来决定。软件的6大质量特性为：功能性、可靠性、易用性、效率性、易用性、可维护性、可移植性

6. 用例设计方法

用例设计普遍的方法为等价类划分、边界值、因果图、判定表、场景之类。我想说的是，要提高用例的有效性和对验证点的覆盖度，设计用例时需要以软件所要具备的27个质量子特性为出发点功能性（适合性、正确性、互操作性、安全保密性、功能依从性）；可靠性（成熟性、容错性、易恢复性、可靠性依从性）；易用性（易操作性、易理解性、易学习性、吸引性、易用性依从性）；效率性（时间特性、资源特性、效率性依从性）；可维护性（易分析性、易修改性、稳定性、易测试性、可维护性依从性）；可移植性（适应性、易安装性、易替换性、共存性、可移植性依从性）

7. 文档管理

对于一个完整的产品来说，文档是很重要的一环。它一般包括安装、升级文档，用户指南等。文档不单单是一个文件，它需要经过完整的测试才能发布给客户。差的文档很可能会误导用户，从而使他们对测试项目失去信心（虽然客户很少看文档……：））

8. 风险管理

风险管理模块需要罗列出来现在已知的可能会出现不确定性的因素，这些因素可能来自技术，资源或者其他方面的。

9. 发布包验证

这部分有一定的特殊性，并不适用于所有的产品。这部分主要是对测试项目安装包进行验证。

九、测试方案（没搞清楚和测试策略的区别）十、测试计划（没搞清楚和测试策略的区别）十一、操作系统命令、数据库命令

熟悉window和linux系统的基本操作命令、因为客户端基本使用的是window，服务器大多采用了linux。*起码得掌握这两个操作系统中：文件的新建、查找、修改、删除，压缩、解压缩；软件的安装、卸载；程序的启动、停止。

对于数据库，很多人说我是测试，我只关心业务，我为啥要懂数据库的操作。其实业务的本质就是操作数据库中的存储的数据。数据是开展业务的基础，很多情况下，我们不能只关注页面的显示变化，而是要到数据库中查看数据是不是符合业务结果的预期。所以测试人员*起码要掌握sql server、mysql、Oracle这几种主流数据的增删改查操作命令。一般面试也就问这几种

十二、UI自动化

现在自动化测试已经成为测试人员提高薪资的一个必要技能，这里推荐几个我知道的UI自动化的方案：web页面的自动化Python+selenuim；移动端的自动化（ios+android）Python+appium。其他的方案还有很多，介于我没接触过也没了解过，所有就不瞎说了。要做UI自动化，还需要了解的知识有html、css、javascript。

十三、接口测试（手工+自动化）

同样的，提高薪资的技能包，这里我用过两个方案，一个是手动做接口测试，推荐postman，适用于对数量比较少的接口去做测试，比如集成其他系统时的技术验证。多接口的批跑测试我接触到的是ant+jmeter工具，jmeter可以批跑接口，在每个请求里加上检查点。ant是Java的一种文件打包集成工具，可以控制调用jmeter，生产html格式的结果报告，方便查看结果

十四、性能测试

同样的，提高薪资的技能包。性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的*大服务级别的测试。

在实际工作中我们经常会对两种类型软件进行测试：bs和cs，这两方面的性能指标一般需要哪些内容呢？

Bs结构程序一般会关注的通用指标如下（简）：

Web服务器指标指标：

* Avg Rps: 平均每秒钟响应次数=总请求时间 / 秒数；

* Avg time to last byte per terstion （mstes）：平均每秒业务脚本的迭代次数，有人会把这两者混淆；

* Successful Rounds：成功的请求；

* Failed Rounds ：失败的请求；

* Successful Hits ：成功的点击次数；

* Failed Hits ：失败的点击次数；

* Hits Per Second ：每秒点击次数；

* Successful Hits Per Second ：每秒成功的点击次数；

* Failed Hits Per Second ：每秒失败的点击次数；

* Attempted Connections ：尝试链接数；

CS结构程序，由于一般软件后台通常为数据库，所以我们更注重数据库的测试指标：

* User 0 Connections ：用户连接数，也就是数据库的连接数量；

* Number of deadlocks：数据库死锁；

* Buffer Cache hit ：数据库Cache的命中情况

性能测试我主要接触过两个工具 loadrunner、jmeter。jmeter比较适合公司自己内部做一个性能评估，他是免费的，轻量型的，安装和使用都很方便，就是在报表和结果分析上没有那么完善和漂亮。loadrunner，大名鼎鼎，很多对外提供的数据报告都是只认可loadrunner，能生成完善的数据分析和漂亮的报表。

十五、团队管理

具备团队管理能力，意味着你不止能自己独立工作，你还可以带领、指导其他人一起完成工作，是一个升职的必备能力。

团队管理即是组建和管理一个测试团队，制定和落实一个有效的测试流程，计划、设计、执行并跟踪输出项目的测试报告，为项目质量提供有效保障。

由于我本身没做过什么管理，看了一篇比较好的文章，这么转发一下：

测试团队的管理划分为6个部分：人员管理、流程管理、团队管理、质量管理、风险管理、资源管理。

人员管理：

确定招聘需求和招聘要求，为团队招募合适的人才。

刚刚走出校园的实习生，和社招的资深测试工程师的能力和经验自然是不一样的，所以对于社招和应届生的招聘要求需要分开。

通常我在面试社招时，更多关注的是社招同学的项目经验，以及过往所承担的职责，自动化工具能力，软性素质上更看重协调能力和推动能力。

而在实习生的面试时，不会过多去关注实习生的项目经验，更多关注的是实习生的学习能力和主观能动性，如果能有一些对软件测试岗位的基础知识学习和理解，那么是很加分的。

制定学习目标和计划，因人而异施教，安排专业的导师，及时跟进新人学习进度并解疑。使招聘的人才在*短的时间内快速适应项目的流程，胜任项目的任务。

对于新入职的人而言，一个类似于这样的明确的工作任务和目标非常重要。

1、职能明确：各岗位职能职责区分清楚，避免团队成员之间职能混乱，出现工作交叉干预、重复劳动的现象，也避免出现踢皮球的场景。

有的测试团队会按照测试技术、测试设计、测试执行的组织结构来管理，这样每个团队都术有专攻，管理上也会更容易

有的测试团队会按照个人全方位能力培养，要求个人同时具备测试技术、测试设计和测试执行的能力，这样对每个人的长远发展更有利，但是会因为每个人的能力参差不齐，导致团队的成员能力不均衡，个人优势不够突出

2、知人善任：依据各人的特质、能力层级、优势劣势进行任务分配，给团队成员充分展示优点的机会，避其缺点，合适的人做合适的事情。

比如有的测试人员擅长测试设计，有的测试人员擅长挖掘工具自动化搭建，有的测试人员沟通协调能力比较强，根据每个人的意愿和长处来安排任务。

3、善于倾听：尊重团队里的每个人，确保成员能够无所顾忌地表达个人观点，并能够及时觉察成员情绪上的波动，换位思考，及时建立疏通、宣泄的渠道，做好正面引导。

4、敢于授权：在明确的目标要求下，适当的放手，让团队成员有能力与权力去承担并对结果负责，但是在过程中，管理者也需要随时去抽查，以便及时发现落实过程中的偏差或者问题

5、激发潜能：不畏惧新人犯**次错误，因为错误中的总结，才能令人印象更深刻，后续不再犯。而不断的尝试新事物，才能够挖掘团队成员的潜力。

6、等级淡化：成为团队成员的朋友，在成员迷茫时能给出合适的建议，在困难时伸出援手，必要的时候需要言传身教，做成员的坚实后盾。

这些主要讲的是向下管理，另外还有向上管理，如何处理自己与上级之间的关系，如何向上级述职，更好的展现自己和团队的工作成绩，也是管理的一门学问。

测试团队管理

1、共同目标：

可以是时间、项目等，团队成员有着共同的目标，才能提高整个团队的凝聚力和斗志，从而取得1+1大于2的效果。

2、团队规划：

制定半年、一年，短期和长期的规划，让团队成员了解公司的远景，让大家对团队、个人的发展有信心。

3、树立标杆：

一个团队中各个成员都是不同的个体，素质和能力颇有差异，树立标杆，推广优秀成员的成绩和经验，才能提升团队的能力，使团队能力*大化。

4、奖惩激励：

团队成立阶段，多奖励，少惩治。及时的给予鼓励和奖励，会让团队成员的被尊重、被信任、被认同感提高，工作动力和积极性提高。但是，团队成长成熟阶段，要多规范，建立多种合理的制度来管理与约束。奖励是激扬人性，惩治是压抑个性。二者结合起来，合适的应用。

5、绩效管理：

有一套公开、公正的绩效激励体系。结合每个成员的自身特点和能力制定，制定合理的绩效。

通过团队活动、团队培训等方式，培养协作精神和团队精神，提升团队整体的能力，创造一种良好的氛围，提高团队的凝聚力。

加强测试团队在整个项目中的地位和影响力，影响力越强，团队成员的成就感会更强，工作的动力和信心会更大，更积极正能量的心态面对工作。

通过各种各样的途径，培训分享，共享资源库，或者是团队图书馆也好，提升团队整理硬性软性能力。

流程管理

大到项目研发流程和职责分工，小到测试缺陷跟踪流程、案例评审流程，都有一个从无到有制定和完善的阶段。

推动流程的落实

流程的落实过程中，不断的总结经验，及时调整和完善流程。

质量管理

测试质量的保证，是测试团队的职责所需，也是首要标准。

前期要确定一些项目中质量的指标，比如交付时间要求、BUG修复率的要求、用例通过率的要求等等。

再通过不同的手段来管控，从而实现和达成目标。

在达成的过程中需要研发、产品、测试、项目经理等多个角色的共同推动规范项目研发流程、代码管理流程、缺陷管理流程、测试案例评审流程等等。

并且做好测试分层，从代码级、接口级和ui级别进行测试，从工具自动化和手工多层面进行考虑，从功能、性能、兼容安全性等多纬度进行覆盖。从某些方面来讲，流程的管理，是质量管理的前提。

通过对质量的可视化数据分析，从而加强管控机制，改善测试流程，丰富质量指标。

资源管理

整合测试相关的技术、文档、工具、专利等，成为测试团队的知识资产；整合测试内部、外部的人力、物力、财力，成为测试团队的能量储备。并且对存档的资源进行维护和更新。

建立统一的共享平台，将测试资源共享，管理测试用例、管理缺陷、管理测试方法、测试技术工具，减少团队成员的重复劳动。

协调测试组内的各种资源，协调组外的各种资源，共同达成目标。

在人力的协调上，一方面需要和团队内、团队外的人员建立良好的关系，取得他们的支持，另一方面，建立跨部门的利益相关性，成为利益共同体。

风险管理

通过对风险的识别和分析，选择有效的方式，主动地、有计划地处理风险，以*小成本获得*大的保证。

项目运行的各个环节可能出现的风险都应关注，风险信息收集时需要注重全面性和多样性。

l 比如需求上存在的缺失，开发实现上可能存在的漏洞，测试案例上可能存在的遗漏，都是项目中常见的风险。

l 常见信息收集手段如现场访谈、会议研讨、问卷调查等。

通常可以用可能性、严重性，结合可控性、相关性几个指标来描述风险。

比如当判断一个不能固定重现的BUG到底是否重要需要在上线前修复时，可以参考如下风险评测标准：

这个BUG发生的概率有多高？

这个BUG对用户的体验和使用影响有多大？

这个BUG如果在生产上出现了，怎样可以解决和减少影响？

这个BUG可能引发其他的问题吗？

采取各种措施减小风险事件发生的可能性，或者把可能的损失控制在一定的范围内，以避免在风险事件发生时带来的难以承担的损失。

风险应对和控制的四种基本方法是：回避、控制、转移和自留。

比如新增加了一个功能是展示列表，根据我对项目组产品和开发的了解，他们经常会忘记页面为空白时怎么显示。而这一次我相信如果不提前提出来他们仍会出现这个问题。那么我可以采取如下几种措施：

我知道可能出现这种风险，但是不打算提出来，也不打算搭理他。准备直接带着这个问题上线。——这是回避。

我把风险提出来，然后声明，这个问题一旦出现，需要开发承担责任。——这是转移。

我默默的认为这个风险影响不大，仅保留给自己知悉。后续等问题暴露出来，再去处理——这是自留。

我把这个可能出现的问题提出来，让产品完善需求，开发提前处理。避免提测后这个bug的出现。——这是控制。

以上所有就是我认为一个测试人员应该具备的知识体系。其实还有好多我没接触过的，比如渗透测试、单元测试、安全测试之类的。接触的越多，越能感觉到自己会的太少，共勉。

目前100000+人已关注加入我们

欢迎同学们扫描二维码报名吧！