1、从进度的角度对比华为和小米的测试
上图是小米UI的一周进度图。按照小米UI每周发布的进度，周四一天的内测。我按照华为的流程怎么套都套不出来。
疑惑点在于：
1、内测是指开发人员自测试，还是测试人员的测试？
2、如果是指开发人员自测试，那么测试人员在哪里测试？
3、如果是测试人员测试，那么开发人员的自测试呢？开发转测试的点在哪里？
华为背景的朋友一定会问：测试人员怎么可能用一天的时间完成测试？
也许有人说，小米的效率就是高。那么我们来看一下华为的测试流程，你就知道是否可以压缩到一天完成相关的测试。
首先说明一点，华为的软件部门，包括UI、或者网站的开发团队也是按照小步迭代进行开发的，在产品稳定后，新增需求会拆分成细小的版本，进行最短周期的开发测试。也可能华为的拆解需求的能力弱于小米，但是这里我们单纯谈测试流程。
测试是产品开发过程中必不少的环节,在华为的研发人员中,有近三分之一的人员是测试人员,华为的测试体系在国内算是起步较早,大概经历了这样几个阶段:
1) 青铜器时代: 手工作坊式测试
1996年研发测试团队成立
手工作坊方式的研发过程和测试
2) 铁器时代：IPD和CMM阶段
1998年华为与IBM合作，开始引进IPD流程
1999年左右引入CMM理念
产生IPD-CMMI流程
3) 火器时代：PTM阶段
2004年在IPD基础上开发PTM流程，自动化测试规模开展
2006~2007年左右PTM趋于完善
注：上图中各个TR点的含义如下：
SRS：需求分析文档；
HLD：概要设计文档；
LLD：详细设计文档；
1. UT
单元测试的对象是LLD中所划分定义的程序单元或模块，它也是单元测试用例设计中可测试的最大单元。该测试对象可能由一个或多个函数或者类组成，测试设计就是对测试对象进行测试用例设计。
UT的目的，是通过函数运行来检查模块代码对于LLD文档的顺从性，验证每个函数的输入输出响应，与它在详细设计文档中预先定义的是否一致。函数是产品开发实现的最基本单位，下一个实现单位是模块，从测试的角度看，希望UT完成后，每个函数都牢固可靠，下一步的IT测试将聚焦在函数之间配合能否实现分配需求，而不用担心函数本身的输入输出响应问题。
单元测试比较适合开发人员做。
2.IT
集成测试是指把若干个经过单元测试的单元组装到一起而进行的测试，集成测试应依据HLD，主要发现接口、依赖中的错误或不完善的地方。集成测试的对象为若干个单元测试对象的组合，至少为两个。
IT的目的，是根据模块设计对模块的分解，从已验证的函数开始，逐层向上集成，得到一个可运行的模块。
IT可以由开发人员做，也可以由测试人员做。
不难看出，UT是面向每一个单元的测试，IT是测试单元之间的接口，可以把UT/IT归为“单元级”测试。
3.ST
CMM定义的系统测试：系统测试是针对软件项目组所承担开发的软件系统进行的整体测试，将软件系统作为整体运行或实施明确定义的软件行为子集的测试。主要采用的测试方法是黑盒测试，即不管程序内部的实现逻辑，以检验输入输出信息是否符合规格说明书中有关需求规定的测试方法。可见ST的测试对象是规格说明书，更确切的说，是模块需求规格说明书，所以一般也称为MST。模块SRS文档给出了模块的输入输出的相应要求。MST后，每个模块是牢固可用的。
4.BBIT
BBIT为模块间接口测试，验证模块之间的接口能不能配合，有时和联调混在一起，其实目的并不相同。BBIT的目的，是根据系统设计对系统的分解，从已通过验证的模块开始，逐层向上集成，得到一个可运行的系统。而联调一般涉及软件、硬件或者不同产品间的配合测试。MST和BBIT可以归到“模块级” 的测试，一个验证模块，一个验证模块间的接口。
以上UT/IT/MST/BBIT一般由开发人员完成，系统基本可以运行起来了，测试人员可以开展SDV、SIT、SVT了。
5.SDV
SDV虽然属于测试人员开展的系统测试，但是有点偏灰盒测试，因为SDV验证各子系统的配合是否满足设计需求（DR），对内部的实现还是关注的，验证多个模块集成以后是否满足设计需求。
6.SIT
SIT也是验证设计需求是否得以满足，与SDV不同的是，SIT完全把系统当作一个黑盒来测试，不关心内部具体的实现。实际应用中，SDV和SIT 虽然都属于系统一级的测试，往往由不同项目组（子系统）的测试人员分别测试，他们只关注各自的子系统，所以还是把SDV和SIT归为“子系统级”的测试比较好。
7.SVT
SVT是验收测试，其测试对象是产品包需求OR。产品包需求给出了产品的范围，从产品可能的应用环境的角度刻画系统，SVT的目的就是确认（或验收）产品包需求给出的各种应用场景产品均能满足。
即使是网页开发项目，外包项目，终端的项目，华为的测试仍然会经历以下几个测试阶段：
SIV：System Integration Verify 系统集成验证
SDV：System design Verify 系统设计验证
SIT：System Integration Test 系统集成测试
SVT：System Verification Test 系统确认测试（系统模拟测试）
迭代结束后，在正式对外发布前，会将历次迭代实现的所有Story再做一次测试，测试 的主体在测试人员，包括功能、非功能，并要给出测试报告。这个活动就称为SIT或发布测试。
如果Story 测试、迭代SDV测试都自动化了，则本次测试主要是执行自动化用例、如前 面有测试不充分，则补充测试，以及详细性能测试。如果用例自动化程度不高，则本次测试会 刷选部分用来进行测试。测试结束后需要给出测试报告。
SIT测试重点： 所有迭代开发完成后，由迭代开发团队中的测试人员完成对全系统进行回归测试，达到TR4A的质量标准。遗留问题要满足TR5的DI（缺陷密度）目标。
4) 集团军时代：IPD-RD-I&V阶段
2008年左右开始推广敏捷，研发组织演变为PDU方式
引进迭代开发模式，形成IPD-RD-I&V流程
系统集成与验证流程：IPD-RD-I&V
(I&V：Integrationand Verification)
项目经理编写《项目计划》，开发人员产出《SRS》，这时测试组长就要根据SOW开始编写《测试计划》，其中包括人员，软件硬件资源，测试点，集成顺序，进度安排和风险识别等内容。 项目管理论坛
《测试计划》编写完成后需要进行评审，参与人员有项目经理，测试经理和系统工程师，测试组长需要根据评审意见修改《测试计划》，并上传到VSS上，由配置管理员管理。 项目管理者联盟
项目管理者联盟
待开发人员把《SRS》归纳好并打了基线，测试组长开始组织测试成员编写《测试方案》，测试方案要求根据《SRS》上的每个需求点设计出包括需求点简介，测试思路和详细测试方法三部分的方案。《测试方案》编写完成后也需要进行评审，评审人员包括项目经理，开发人员，测试经理，测试组长，测试成员和系统工程师，返回评审结果。测试组长组织测试成员修改测试方案，直到评审通过后才进入下个阶段――编写测试用例。
测试用例是根据《测试方案》来编写的，通过《测试方案》阶段，测试人员对整个系统需求有了详细的理解。这时开始编写用例才能保证用例的可执行和对需求的覆盖。测试用例需要包括测试项，用例级别，预置条件，操作步骤和预期结果。其中操作步骤和预期结果需要编写详细和明确。测试用例应该覆盖测试方案，而测试方案又覆盖了测试需求点，这样才能保证客户需求不遗漏。同样，测试用例也需要通过开发人员，测试人员，系统工程师的评审，测试组长也需要组织测试人员对测试用例进行修改，直到评审通过。
在我们编写测试用例的阶段，开发人员基本完成代码的编写，同时完成单元测试。转测试部后直接进行系统测试。测试部对刚转过来的测试版本进行预测试，如果软件未实现CheckList清单上的10％，测试部会把该版本打回。否则，软件转测试部进行系统测试。根据《测试计划》进度安排，测试组长进行多轮次的测试，每轮测试完成后测试组长需要编写测试报告，其中包括用例执行通过情况，缺陷分布情况，缺陷产生原因，测试中的风险等等，这时测试人员就修改增加测试用例。待到开发修改完bug并转来新的测试版本，测试部开始进行第二轮的系统测试，首先回归完问题单，再继续进行测试，编写第二轮的测试报告，如此循环下去，直到系统测试结束。在系统测试期间，测试人员还需要编写验收手册，验收用例和资料测试用例等。
修改问题单，直到满足规定的缺陷密度，才能够通过相关TR点。
如果验收发现的缺陷率在SOW规定的范围内，那么验收成功。如果超过规定的缺陷率，需要质量回溯。
2、不可思议的小米5%
雷军说：
首先华为工程师的平均收入应该是低于小米的，器件采购的成本也应该是低于小米的，制造的产线也应该是低于小米的，因为有自己的产线。
那么华为的成本花到哪里去了呢？
那么我们看华为的硬件测试过程，就知道成本出在哪里了。
第一、 全程测试参与的流程：
在项目开始的阶段，测试人员就开始参与需求分析，对产品的可测试性、测试方案等等因素进行评估。
第二、 多层级的测试与试验
对于电路的设计，会进行单元测试、整机测试、小批量试制、HALT试验、环境试验、EMC试验、热测试、进入生产环节之后会进行HASS试验。特殊的设备还会进行盐雾试验、硫化试验。整机结构还会进行：跌落试验、挤压、扭曲等等。
HALT（Highly accelerated life test）高加速寿命试验。HALT是一种发现缺陷的工序，它通过设置逐级递增的加严的环境应力，来加速暴露试验样品的缺陷和薄弱点，而后对暴露的缺陷和故障从设计、工艺和用料等诸方面进行分析和改进，从而达到提升可靠性的目的，最大的特点是设置高于样品设计运行限的环境应力，从而使暴露故障的时间大大短于正常可靠性应力条件下的所需时间。
环境试验是为了保证产品在规定的寿命期间，在预期的使用，运输或贮存的所有环境下，保持功能可靠性而进行的活动。是将产品暴露在自然的或人工的环境条件下经受其作用，以评价产品在实际使用，运输和贮存的环境条件下的性能，并分析研究环境因素的影响程度及其作用机理。
HASS应用于产品的生产阶段，以确保所有在HALT中找到的改进措施能够得已实施。HASS还能够确保不会由于生产工艺和元器件的改动而引入新的缺陷。
硬件工程师最怕HALT试验，因为会超越器件的限制范围去进行测试。但是为什么要这么做呢，其实是找到整个设备的最薄弱点，然后对最薄弱点进行改进。但是由于超出了器件的允许的工作范围，异常的情况特别多，原因也复杂。但是按照规范必须分析清楚，并给出优化措施。这是非常烧脑的意见事情，很多经典的问题都是HALT试验过程中产生的。
由于我本人非测试出生，有讲的不对的地方请专家指正。写这篇文章时，很多朋友抱怨小米手环使用不到一个月就坏了，想到雷军的5%，就写下这些。现在小米的供应链、质量、品牌都有所提升。特别是小硬件，通过生态的方式做的很成功。
联系客服
