软件测试需要具备的知识体系 #CSDN博文精选# #软件测试# #IT# #系统化学习#

大家好~我是小C，又见面啦！“文章过滤器”精选大咖干货、助力学习之路。

《5天20篇CSDN精选博文带你掌握系统化学习方法》专栏将挑选有关“系统化学习方法”的20篇优质文章，帮助大家掌握更加科学的学习方法~

在这里，你将收获：

• 快速掌握系统化学习的理论基础，探究其本质和原理
• 学会将已有知识体系化，形成自己的知识图谱，离学霸更近一步
• 系统化学习必备工具推荐与使用方法教学，实现高效学习
• 尝试将系统化学习思维运用于工作、学习中，实践出真知

转眼间专栏文章已经都过了四天，大家掌握的怎么样了呢？今天就来检验一下吧~为你们精选了系统学习IT技术的四篇文章~

本文转载自CSDN博主@yy19890521

一、软件的生命周期(SDLC，Systems Development Life Cycle,SDLC)

软件计划与可行性研究（问题定义、可行性研究）；需求分析；软件设计（概要设计、详细设计）；编码；软件测试；运行与维护

• 生存周期划分

         各阶段的任务彼此间尽可能相对独立，同一个阶段各项任务的性质尽可能相同，从而降低每个阶段任务的复杂性，简化不同阶段之间的联系，有利于软件开发过程的组织管理。

• 生存周期基线

       

       功能基线(functional baseline)

       功能基线是指在系统分析与软件定义阶段结束时，经过正式评审和批准的系统设计规格说明书中对待软件生命周期开发系统 的规格说明；或是指经过项目委托单位和项目承办单位双方签字同意的协议书或合同中所规定的对待开发软件系统的规格说明；或是由下级申请经上级同意或直接由上级下达的项目任务书中所规定的对待开发软件系统的规格说明。功能基线是最初批准的功能配置标识。

       指派基线(allocated baseline)

       指派基线是指在软件需求分析阶段结束时，经过正式评审和批准的软件需求的规格说明。指派基线是最初批准的指派配置标识。

       产品基线(product baseline)

       产品基线是指在软件组装与系统测试阶段结束时，经过正式评审的批准的有关所开发的软件产品的全部配置项的规格说明。         产品基线是最初批准的产品配置标识。

• SDLC的六个阶段

       定义及规划

       此阶段是软件开发方与需求方共同讨论，主要确定软件的开发目标及其可行性。

       需求分析

       在确定软件开发可行的情况下，对软件需要实现的各个功能进行详细分析。需求分析阶段是一个很重要的阶段，这一阶段做得好，将为整个软件开发项目的成功打下良好的基础。"唯一不变的是变化本身。"，同样需求也是在整个软件开发过程中不断变化和深入的，因此我们必须制定需求变更计划来应付这种变化，以保护整个项目的顺利进行。

       软件设计

       此阶段主要根据需求分析的结果，对整个软件系统进行设计，如系统框架设计，数据库设计等等。软件设计一般分为总体设计和详细设计。好的软件设计将为软件程序编写打下良好的基础。

       程序编码

       此阶段是将软件设计的结果转换成计算机可运行的程序代码。在程序编码中必须要制定统一，符合标准的编写规范。以保证         程序的可读性，易维护性，提高程序的运行效率。

       软件测试

       在软件设计完成后要经过严密的测试，以发现软件在整个设计过程中存在的问题并加以纠正。整个测试过程分单元测试、组装测试以及系统测试三个阶段进行。测试的方法主要有白盒测试和黑盒测试两种。在测试过程中需要建立详细的测试计划并         严格按照测试计划进行测试，以减少测试的随意性。

       运行维护

       软件维护是软件生命周期中持续时间最长的阶段。在软件开发完成并投入使用后，由于多方面的原因，软件不能继续适应用户的要求。要延续软件的使用寿命，就必须对软件进行维护。软件软件生存周期的维护包括纠错性维护和改进性维护两个方 面。

• 周期模型

       典型的几种生命周期模型包括瀑布模型、快速原型模型、迭代模型

二、软件测试在软件生命周期（瀑布模型）中的对应关系

 

三、软件测试过程

第一步：对要执行测试的产品/项目进行分析，确定测试策略，制定测试计划。该计划被审核批准后转向第二步。测试工作启动前一定要确定正确的测试策略和指导方针，这些是后期开展工作的基础。只有将本次的测试目标和要求分析清楚，才能决定测试资源的投入。

第二步：设计测试用例。设计测试用例要根据测试需求和测试策略来进行，进度压力不大时，应该设计的详细，如果进度、成本压力较大，则应该保证测试用例覆盖到关键性的测试需求。该用例被批准后转向第三步。

第三步：如果满足“启动准则”（EntryCriteria），那么执行测试。执行测试主要是搭建测试环境，执行测试用例。执行测试时要进行进度控制、项目协调等工作。

第四步：提交缺陷。这里要进行缺陷审核和验证等工作。

第五步：消除软件缺陷。通常情况下，开发经理需要审核缺陷，并进行缺陷分配。程序员修改自己负责的缺陷。在程序员修改完成后，进入到回归测试阶段。如果满足“完成准则”（ExitCriteria），那么正常结束测试。

第六步：撰写测试报告。对测试进行分析，总结本次的经验教训，在下一次的工作中改。

软件测试过程管理，主要包括软件测试是什么样的过程，如何评价一个软件测试过程，如何进行配置管理和测试风险分析以及测试成本的管理。

四、软件测试流程（与第三条对应）

1、制定测试计划

2、编辑测试用例

3、执行测试用例

4、发现并提交BUG

5、开发组修正BUG

6、对已修正BUG进行返测

7、修正完成的BUG将状态置为已关闭，未正确修正的BUG重新激活

五、测试用例

测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。

测试用例的要素为：版本号、模块名称、用例编号、用例名称、用例级别、预置条件、验证步骤、期望结果（含判断标准）、测试结果、测试时间、测试人员等。（其中核心要素为预置条件、验证步骤、期望结果）

测试用例的设计方法：等价类划分、边界值分析、错误推测法、因果图法、场景设计法

一份好的测试用例所要达到以下几点要求：测试用例必须完成对需求的完整覆盖（即用例和需求的双向可追溯性）；测试用例必须是可执行的；测试用例的结果唯一性；测试用例必须简洁明了

六、缺陷报告（提交bug）

一份有效的缺陷报告要素通常包括：标题、前提、测试环境、操作步骤、实际结果、期望结果、出现的频率、优先级、严重等级、附件（一般是图片形式）。
另外还会有一些附加信息，如测试人员、开发负责人等。

• 标题：简明扼要，无歧义

• 优先级 Priority（4个等级）：软件被修复的紧急程度
  1--立即解决：缺陷导致系统几乎不能运行使用 或 严重妨碍测试的执行（需立即修改）
  2--高优先级：缺陷严重，影响到测试了（当天或第二天要及时解决的）
  3--正常：一般错误
  4--低优先级：可以在开发有时间的时候处理，如页面文本框对齐显示

• 严重等级 Severity（4个等级）：缺陷引起的故障对用户使用系统的影响
  1--致命的：主流程不通，导致系统功能缺失、用户数据被破坏、系统崩溃、死机
  2--严重的：影响流程的 比较严重的，比如系统主要功能部分未实现
  3--一般：系统的次要功能没有完全实现，但不影响用户的正常使用
  4--较小：操作不方便或遇到麻烦，但不影响功能的使用，如字体不美观、按钮大小不合适、文字排列对齐等（属于建议性或者美观方面的）

一般来说，缺陷越严重，优先级越高，但也有例外：
1）从用户角度看，缺陷不是很严重，但可能影响到测试执行了（优先级高严重等级低）
2） 有些缺陷比较严重，但由于技术的限制，暂时没法修改。这时优先级就降低了

• 附件
  有时候，用文字很难清楚描述缺陷，此时用图片（画笔指明问题）就很直观了

如何有效的报告缺陷？

• 单一准确：每个报告只针对一个缺陷，如果有多个缺陷，可能开发只修正了其中一个，其他的没有得到修改，加长了缺陷的生命周期

• 可以再现：不能忽视或省略任何一项操作步骤，特别是关键性的操作，如描述的不够清楚，RD（Research and Development engineer）就会过来沟通怎么操作的，浪费了大家的时间

• 完整统一：完整的描述信息

• 短小简练：使用关键词

• 特定条件：有些问题只在特定环境下存在

七、测试报告

测试报告是指把测试的过程和结果写成文档，对发现的问题和缺陷进行分析，为纠正软件的存在的质量问题提供依据，同时为软件验收和交付打下基础。

一份详细的测试报告包含足够的信息，包括产品质量和测试过程的评价，测试报告基于测试中的数据采集以及对最终的测试结果分析。

测试报告的主体框架为：

1、首页

·· 报告名称（软件名称+版本号+用户端类型（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. 人员管理：

• 人员招聘

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

 

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

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

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

 

• 人员培养

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

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

• 人员管理

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

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

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

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

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

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

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

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

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

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

测试团队管理

• 团队建设

1、共同目标：

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

2、团队规划：

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

3、树立标杆：

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

4、奖惩激励：

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

5、绩效管理：

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

• 团队潜能

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

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

• 团队提升

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

流程管理

• 流程建立

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

• 流程实施

推动流程的落实

• 流程优化

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

质量管理

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

• 质量指标

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

• 质量管控

 

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

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

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

• 质量分析

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

资源管理

• 资源整合

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

• 资源共享

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

• 资源协调

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

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

风险管理

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

• 风险识别

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

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

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

• 风险评估

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

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

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

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

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

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

• 风险应对

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

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

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

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

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

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

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

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

 

 

 

如果你对这篇文章感兴趣，请戳链接前往博主首页查看更多https://blog.csdn.net/yy19890521

 

关注高校俱乐部，更多精彩内容等着你