几乎从零开始建立测试部门

Gertie

说是测试部门都夸张了，50多人的研发团队，我是第一个专职做测试的，而且之前还过了CMMI2级……先写了个测试工作开展计划，大家指导下。

jameswang1018

要做的事确实很多，先抓重点：

1）和领导明确短期和长期的目标
     万事开始之前，先确定你的目标是什么，以及将来如何用一种认可的方式进行衡量。务必坐下来和领导交谈，了解他希望测试部门帮助他完成什么目标。根据他的要求把测试团队3个月到1年的目标规划出来，再去和领导确认。这里不要担心浪费领导时间，尽量多确认几次，以确保将来不要产生吃力不讨好的结果。

2）设计测试流程关键点
     测试流程可以写很多，但在这个阶段，重要的是确保测试的流程能和公司整体的大流程融合，要着重明确对外的部分，即和开发，产品，运维以及其它部门的合作方式。哪些是你承诺它们要做到的，哪些是需要他们承诺你做到的，需要官方的正式确认。正如设计一个产品先要设计对外的接口，在这里也是一样的道理。

3）招聘核心人员。
     记住，第一批的几个人很大程度上决定了你团队今后的文化。相比技术能力而言，这几个人的观念，工作方式，性格，积极程度更为重要。强悍的男生和泼辣的女生会协助你将测试和开发协同的工作流程推行下去，在最初的几个月中纠正开发人员长期在无测试人员的环境下工作的方式，为后面推行你的计划打下基础。

jingzizx

没有附件
测试团队建设确实是一个比较复杂的问题

applepen

论坛里应该有测试部门的leader。希望他们能给你一个满意的回答。
毕竟leader对整体测试的流程更清晰。

Gertie

1.   引言1.1  目的

本文档描述了一般项目下，软件测试的工作过程，并给出测试过程中常用文档的模板。文档描述了常见测试类型和测试方法，可作为测试过程中的参考。

1.2  范围

本文档用于指导软件测试工作开展。

2.   测试过程2.1  总则

软件测试过程是一种抽象的模型，用于定义软件测试的流程和方法。软件测试过程和软件开发过程一样，都遵循软件工程原理，遵循管理学原理。本章节将对测试模型进行介绍，并对关键节点进行详细说明。

2.2  测试模型2.2.1   W模型

（图）

W模型，由两个V字型模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等开发输出的文档同样要测试也就是说，测试与开发是同步进行的。

W模型有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需求文档的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，这将显著减少总体测试时间，加快项目进度。

但W模型也存在局限性。在W模型中，需求、设计、编码等活动被视为串行的，同时，测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。这样就无法支持迭代的开发模型。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临的困惑。

2.2.2   H模型

（图）

相对于W模型，H模型将测试活动完全独立出来，形成了一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。

这个示意图仅仅演示了在整个生产周期中某个层次上的一次测试“微循环”。图中标注的其他流程可以是任意的开发流程。例如，设计流程或编码流程。也就是说，只要测试条件成熟了，测试准备活动完成了，测试执行活动就可以（或者说需要）进行了。

H模型揭示了一个原理：软件测试是一个独立的流程，以独立完整“微循环”流程，参与产品生命周期的各个阶段，与其他流程并发地进行。H模型指出软件测试要尽早准备，尽早执行，只要某个测试达到准备就绪点，测试执行活动就可以开展，并且不同的测试活动可按照某个次序先后进行，但也可以是反复进行的。

2.3  测试计划

测试人员根据软件需求说明书、设计文档或其它等效文件等进行测试策划，输出软件测试计划。一般包括：

1)     确定测试策略，测试策略要能清楚描述测试的思路；

2)     确定测试需要的技术或者方法；

3)     确定用于测试的资源要求，包括硬件设备、软件环境、人员数量和技能等要求；

4)     进行风险分析，如技术风险、人员风险、资源风险、进度风险等；

5)     确定测试任务的结束条件；

6)     确定被测软件的评价准则和方法；

7)     确定测试活动的进度；

8)     测试计划应经过评审，并应受到变更控制和版本控制；

9)     项目计划变更时，应及时调整测试计划。

输出文档：

《XXX软件测试计划》

2.4  测试设计和实现

测试计划通过评审后，根据测试计划和软件需求规格说明、用户手册等文档，对软件实现的目标进行细化和分解，进行测试设计。

2.3.1   测试方案

测试人员依据测试需求和测试计划编写测试方案。

1)     按需要进行测试项分解。将需要测试的测试项进行层次化的分解并进行标识，若有接口测试，还应有接口图说明所有接口和要测试的接口；

2)     测试方案中需要描述测试用例设计方法的具体使用、测试数据的选择依据等；

3)     确定测试用例的执行顺序；

4)     准备测试数据。针对测试输入要求，设计测试用的数据，如数据类型、输入方法等；

5)     准备并获取测试计划中提到的测试资源，如测试环境必须的软、硬件资源；

6)     搭建和核对测试环境，记录和标识测试环境的偏差。

输出文档：

《XXX软件测试方案》

《XXX软件测试策略》

2.3.2   测试用例

测试用例为测试执行的依据，以避免遗漏掉要测试的功能点。

1)     测试用例要追踪到测试说明中的测试项；

2)     每个测试用例要包含用例编号、测试步骤、期望测试结果、前提和约束、终止条件等信息；

3)     测试步骤应包括每一步测试操作动作、测试程序输入或设备操作等；

4)     期望测试结果应由具体的数值，不应是不确切的概念或笼统的描述；必要时，应提供中间的期望结果；

5)     测试前提和约束为测试步骤开始前应具备的条件。

输出文档：

《XXX软件测试用例》

《XXX软件需求跟踪矩阵》

2.5  测试执行

测试应按照测试用例的步骤，根据测试方案中的测试顺序进行执行。在多个人同时进行测试时，测试负责人进行分工同时进行测试。测试人员根据每个测试用例的期望测试结果、实际测试结果和评估准则，判定测试用例是否通过。

1)     当测试用例不通过时，根据不同的问题类型采取相应的措施：

a)       对测试过程中的问题，如测试文档、测试数据、测试环境的问题，实施相应的变更，并更新问题涉及的文档版本；

b)       被测软件的问题根据缺陷管理流程提交开发人员进行修改，直至问题关闭。

2)     当所有用例执行完毕后，分析测试工作是否充分，是否需要进行补充测试：

3)     对整个测试执行结果要做真实的记录，对于数据类的测试结果要记录具体的数值。

2.6  测试总结

测试执行完毕之后，需要对缺陷的数量、严重程度分布情况，测试工作量、测试工作效率等进行总结和分析，得出测试结论，并对被测软件进行评价。

输出：

《XXX软件测试报告》

Gertie

3.   测试类型3.1  总则

测试类型一般有：文档审查、代码审查、代码走读、静态分析、功能测试、性能测试、接口测试、GUI测试、可靠性测试、安全性测试、安装性测试、兼容性测试等。

测试过程中根据具体情况确定所进行的测试类型，或增补其它测试类型，并在测试方案中进行说明。

3.2  常见测试类型说明

测试类型名称	说明
文档审查	对软件开发过程中产生的文档所进行完整性、一致性、准确性检查
代码审查	检查代码和设计的一致性、代 码执行标准、代码逻辑表达的正确定、代码结构的合理性以及代码的可读性
代码走读	测试人员准备一批有代表性的测试用例，由开发人员和测试人员组成小组，集体扮演计算机的角色，沿程序的逻辑运行用例，主要的目的是为了发现程序中的逻辑错误
静态分析	使用静态分析工具对代码进行分析，主要目的是为了检查代码是否符合编码规范
功能测试	验证软件是否能满足用户特定功能要求并做出正确响应
接口测试	验证模块之间、子系统之间以及系统间的接口是否正确
性能测试	验证软件某项功能的时间和资源使用情况
负载测试	验证软件在一定的负载下长时间运行的情况
压力测试	对系统持续加压，测试软件可承受的最大压力
GUI测试	验证软件界面的正确性，以及与用户交互过程是否友好
鲁棒性测试	验证软件对错误数据、异常情况和非法操作的处理是否合理
安全性测试	验证软件是否有数据保护能力，并能在一定范围内承受恶意攻击
安装性测试	验证软件能否正确安装和运行
兼容性测试	验证软件能否和其它相关软件顺利对接

4.   测试方法6.1  总则

测试方法一般包括等价类划分、边界值分析、错误推测法、因果图法、判定表法、正交试验法、功能图法、场景法等。

测试过程中根据软件特点和实际需要选择相应的几种测试方法进行测试。

6.2  常见测试方法说明

测试方法名称	说明
等价类划分	根据输入数据和输出数据的范围分为有效等价类和无效等价类，确保软件可接收和处理正确的数据，也可接受意外的考验
边界值分析	作为等价类的补充，在输入数据或输出数据的边界和次边界进行 测试用例设计
错误推测法	列举出程序中所有可能发生错误和容易发生错误的特殊情况，以及历史版本中发生错误较多的地方进行测试
因果图法	考虑各种输入的组合以及它们之间的制约关系，相应的产生多个动作的情况来设计测试用例
判定表法	判定表是在因果图方法中用到的工具，用于分析和表达多逻辑条件下执行不同操作的情况。
正交试验法	利用正交表，从大量的数据中挑选适量的、有代表性的点，从而合理的安排测试
功能图法	用功能图形象地表示程序的功能说明，并机械地生成功能图的测试用例
场景法	用事件触发来控制流程的软件，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。用例场景用来描述流经用例的路径，从用例开始到结束遍历这条路径上所有的基本流和备选流。

5.   缺陷管理6.3  总则

软件的缺陷是软件开发过程中的重要属性，它提供了许多信息。测试过程中需要记录缺陷，并跟踪缺陷纠正过程。同时需要充分利用缺陷提供的信息，建立组织过程能力基线，实现量化过程管理，并可以此为基础，通过缺陷预防实现过程的持续性优化。

6.4  缺陷管理目标

a)        确保每个被发现的缺陷都能够被解决；这里解决的意思不一定是被修正，也可能是其他处理方式（例如，在下一个版本中修正或是不修正），总之，对每个被发现的BUG的处理方式必须能够在开发组织中达到一致；

b)        收集缺陷数据并根据缺陷趋势曲线识别测试过程的阶段；决定测试过程是否结束有很多种方式，通过缺陷趋势曲线来确定测试过程是否结束是常用并且较为有效的一种方式；

c)        收集缺陷数据并在其上进行数据分析，作为组织的过程财富。

6.1  缺陷级别定义

严重等级	说明
致命	系统崩溃、数据丢失、数据损坏
严重	操作性错误、错误结果、遗漏功能
一般	小问题、个别错别字、UI布局、罕见故障
建议	不影响使用的瑕疵或更好的实现

Gertie

6.2  缺陷状态定义

缺陷状态	说明
新建（New）	测试中新报告的软件问题
打开（Open）	问题确认并分配给相关开发人员处理
修正（Fixed）	开发人员完成修正，等待测试人员回归验证
拒绝（Declined）	不是软件问题，不修改
延期（Deferred）	下一个版本修复，当前版本不修改
关闭（Closed）	非问题，或已修复并回归验证通过的问题
重新打开（ReOpen）	验证修复的缺陷，验证结果未修复
挂起（Suspend）	经评审，缺陷暂时不修复

6.3  缺陷管理流程

（图）

注：

1）  为保证错误处理的正确性，测试人员提交问题之后，测试负责人需要确认是真正的问题还是误操作，是否为重复问题，以及问题描述的准确度，是否可复现；

2）  每个问题的每一步处理都要保留处理信息，包括处理人，时间，处理方法，处理意见，问题状态等；

3）  开发人员拒绝或延期处理的问题、不可修复的问题，应由开发人员和测试人员沟通后共同决定，必要时需要测试负责人、项目负责人一起决议；

4）  要加强测试人员和开发人员之间的交流，对于描述不够详尽的问题，开发人员可要求测试人员补充详细的测试步骤、测试方法和测试现象。

Gertie

公司有策略不让上传，我把文字贴上来了，大家看一下。
下一步打算把已有模板优化，然后缺的模板补齐。
之后写一下测试流程、测试方法、测试类型白皮书，就是把现在写的开展计划中的内容给详细描述下。

测试管理工具和缺陷管理工具已经部署了，用的TestLink和Mantis。
等流程方法什么的都搞完把使用说明也写一下。

找时间给主要的相干人做培训，然后找个项目做试点，用现在的流程和工具来试试。
如果什么都挺好，就提招人申请。

不知道这样是否可行？大家都来说说？

weimin520

做哪方面的测试

Gertie

weimin520 发表于 2017-7-31 22:28
做哪方面的测试

物联网、大数据相关。

archonwang

楼主辛苦。

这个事情要看公司资源。测试工作的核心内容和交付件是哪些，从这些东西上入手。看目前你这边情况应该是测试发展的蛮荒时代，有很大的空间，但是如果过度透支也会带来很严重的负面问题。建议循序渐进来做。

如果你的测试团队从0开始，先招人吧。安必须的坑和在你能力范围内觉得很优秀的人，前期的团队建设建议是这样来做。不要一上来就找没啥经验的同志，要不然累死自己不说，说不定还要拖累别人，耽误自己也耽误别人。

估算你这边的团队规模，50多人的研发，建议是6~8人的测试团队，后期根据业务再进行扩张，第一批招进来的同志会极大地影响团队的发展路线，切记！

让测试飞起来

这个可以看看，

hellinangel

这个是测试团队已经组建完毕之后的测试部工作规划及规范要求吧，和组建测试团队没啥关系啊。
建测试团队，要考虑的是这个测试团队是为了支撑什么业务，完成什么工作，工作范围，需要多少的人力配置，需要什么样的人，技术能力水平层级，工具使用情况，团队组织架构，什么时间完成团队组建等等的

kxm718

学习一下！

神软forever

衷心感谢楼主的辛苦！

xjw123456

学到了很多，谢谢楼主的分享！！！

amz_dx

说不定那天用得着

Gertie

hellinangel 发表于 2017-8-18 11:20
这个是测试团队已经组建完毕之后的测试部工作规划及规范要求吧，和组建测试团队没啥关系啊。
建测试团队， ...

对的，这块我也有整理，稍后发上来

Gertie

支撑业务不知道是否可能会涉密，不太好说。
基于现有业务我划分了技术责任田和行业责任田，分别如下：

技术责任田	责任田目标	田主
App测试责任田	1.承接产品线、本部和研究院项目的App测试工作   2.App测试方法总结   3.App最新测试方法预研及App测试技术货架：测试规范/测试方案/测试用例/缺陷库……   4.定期进行App测试方法分享
自动化责任田	1.对现有成熟产品进行自动化测试构建   2.自动化测试框架的搭建以及自动化测试能力建设   3.最新自动化测试技术预研   4.自动化测试技术货架：测试规范/测试脚本/测试方案/测试用例/缺陷库/性能优化方案……   5.定期进行自动化测试方法分享
兼容性测试责任田	1.承接产品线、本部和研究院项目的App测试工作   2.兼容性测试框架的搭建以及兼容性测试能力建设   3.最新兼容性测试技术预研及测试技术货架   4.定期进行自动化测试方法分享
性能责任田	1.承接产品线、本部和研究院项目的性能测试   2.性能测试框架的搭建以及性能测试能力建设   3.最新性能测试技术预研   4.性能测试技术货架：测试规范/测试指导书/测试方案/测试用例/缺陷库/性能优化方案……
安全责任田	1.对产品线、本部和研究院项目进行安全测试   2.安全测试   3.最新性能测试技术预研   4.性能测试技术货架：测试规范/测试指导书/测试方案/测试用例/缺陷库/性能优化方案……
用户体验责任田	1.对产品线B2C项目进行用户体验测试   2.研究用户体验测试方法并实施   3.优化用户体验方法并持续改进   4.用户体验测试技术货架   5.定期进行用户体验测试分享
算法测试责任田	1.主要针对大数据研究院的算法进行测试   2.算法测试新技术预研与技术货架建立   3.定期进行算法测试技术分享

行业责任田	责任田目标	田主
智能图像	1.智能图像领域（深度学习算法）评价标准与测试方法   2.智能图像领域先进技术及测试技术货架
数字艺术	1.数字艺术背景知识及艺术作品知识图谱   2.数字艺术领域测试技术   3.当前数字艺术领域测试方案/用例知识货架
智能车联	1.智能车联（ADAS/HUD/智能后视镜）行业背景知识   2.ADAS仿真测试   3.4G/GPS/蓝牙仿真测试
商超零售	1.商超零售领域（智能购物车/智能货架/电子标签）背景知识   2.商超零售领域测试技术
金融零售	1.金融零售领域背景知识   2.金融零售领域测试技术
商显系统	1.商显系统领域背景知识   2.商显系统领域测试技术
流程改进与质量控制	1.质量管理   2.测试流程改进（测试准入准出原则）   3.敏捷测试

Gertie

jameswang1018 发表于 2017-8-29 11:06
要做的事确实很多，先抓重点：

1）和领导明确短期和长期的目标

感谢jameswang1018，目前已定义三个方向的测试人员：前端、性能及算法测试。已经有3人到岗，加我是4个人。
招聘比我想象中困难，HR给出很多“中肯”的建议，比如资深人员人数太多成本增加、女生比例多，年龄偏大、性格不合适等等。砍掉了好几个技术上比较强的小伙伴。
随着人数的增加，测试与项目的对应也更加匹配，一切良性循环中。
测试流程也在持续改进中，我整理下发上来。