没有严密的测试和验证就开发不出高质量的产品--产品中试管理(从样品到量产)
相对于开发工作来说，测试往往被认为是“后卫”的工作，一旦“球门”失守，“后卫”往往是第一个受到责骂的：为什么没有抵挡住对方的进攻，为什么没有守卫 好“球门”?而“守卫”往往很委屈，被视为无技术含金量的活。测试工作也如同如此，“测试工作没前途”、“测试就是打杂的”、“真后悔当初没有找个开发工 作”等等抱怨不时在耳边响起。同时公司对测试工作的定位不正确，认识和重视不够，往往导致对测试工作的认识存在很多误区，这些误区直接影响了后续测试工作 效果。例如测试能无穷无尽吗?测试的一个事实:彻底的测试实际上是不可操作的!根据80/20原则：在一般情况下，在分析、设计、实验阶段的评审和测试工作能够发现和避免80%的缺陷，而系统的测试能够找出其余缺陷中的80%。最后约5%的缺陷只有在用户大范围、长时间的使用才会暴露出来。因此测试只能保证尽可能多地发现错误，却不能保证发现所有的错误。
测试和开发为何对问题的严重程度分歧过大。常常见到被测试人员认为致命严重的问题，在开发人员眼里是不慌不忙的事情或者双方之间老是对问题的严重程度和解决进度节奏没有达成共识，互相打架。
开 发人员和测试人员在职业特质上存在天然的差异，即开发人员总是以为自己输出的成果是不可挑剔的，天然地认为自己是站在客户立场上从全局思考设计和开发 的，同时开发人员具有一股冲劲，不断地使项目往前跑的冲劲。而测试人员一般是有完美主义倾向的，“爱挑剔”，有“揪着细节不放过”的习惯。因此两者一碰 面，难免争执不休。
没有产品测试和验证就开发不出高质量的产品
产 品测试和验证是围绕业务目标，统筹开展的一系列差错预防和审查工作。但是从研发管理发展的历程，尤其是软件开发管理的历程来看，更多的精力和重点放在需 求、设计和开发上，测试和验证工作曾经一度没有被视为一项重要的工作。后来出现大量的产品质量不稳定和事故，研发管理者和相关研究机构逐渐重视起测试和验 证保证体系建设，例如国际质量管理标准ISO 9000体系和能力成熟度模型集成CMMI体系的建立。因此，产品测试和验证工作需要进行严格细密的构建，下面主要从产品测试和验证的全流程、测试和验证项目管理总体过程、测试和验证的分类、测试和验证的阶段性要求等方面进行介绍。
测试和验证的重要原则
在统筹安排测试工作之前，开发团队必需理解测试的一些基本原则，以便从思想上、策略上对测试和验证工作有正确的认识。基于这些原则，有助于保持各项产品测试和验证工作的协调统一，并明确测试和验证的重点，达到事半功倍的效果。一般来说，常见的重要测试原则如下(见图5-5)：
图5-5 测试的重要原则
n 客户化测试。针对客户最容易遇到的缺陷机会点进行测试,以便改进测试的有效性。因为在产品中可能会存在许多缺陷，但客户遇到的缺陷只占很小比例。IBM曾经统计数据表明客户所看到的57%以上的故障是由占总数2%以下的缺陷引起的，所以客户化测试是重中之重。客户化测试要求不断聚焦于客户，甚至通过构建、模拟再现客户使用场景来提前测试，将问题杜绝在产品设计阶段。例如某厨电企业针对高层建筑中房间里用的吸油烟机在什么情况下能够达到最好的吸排效果课题进行了场景模拟。通过10层、20层、30层楼这样的公共排风管道的负压模拟装备，验证了如果吸油烟机装在有30层高的公共管道这样的住户中，处在一层、二层、三层这么大的吸压的情况下，能否把厨房的油烟吸出去。
n 见好就收。测试不能无穷无尽地开展下去，完全测试基本不可能，应制定合理的策略，需要权衡投入产出比，测试和验证工作既不要不充分也不要过分。不充分和过分都是一种不负责任的表现。
n 尽早测试。“尽可能早的开始测试，不要等产品构建完成了再进行测试”。对系统的验证不仅仅在系统已经完全构建后进行，早在概念阶段即可针对选定的构建模块(如外购模块、共用模块等)开始进行工程评估，以确定它们的稳定性，以及是否可以用来搭建新产品。在整个系统开发过程中，对模块应在系统构建之前充分验证。纠正早期发现缺陷的代价要远小于整个系统构建完成后发现缺陷再纠正的代价。例如如果在部署之后又发现软件问题再进行修复，这通常要多花100到1000倍的成本。要防患于未然.在特定时间达到既定目标，在整个项目生命周期内不断对质量进行检验和管理必不可少。
n 功能独立。在设计时尽可能保持功能的独立性，减少模块间的耦合。在进行模块划分时，每个模块合入较少的新模块(或修改的模块)以支持该模块的功能。
n 渐增构建。逐步增加功能，以渐增的方式进行构建和测试。每个模块必须在稳定后才进行后续模块的集成和测试。在稳定的基础上增加和验证一小部分功能子集，对问题的定位能够限定在一定的范围，减少问题定位所需要的时间。但是“不要对相同的被测对象做相同的测试两遍”，应提前做好准备进行系统回归测试，包括前面所做测试所导致的所有修补、更改，这样将保证产品质量已达到成熟状态(见图5-6)。
图5-6 渐增构建基本思想示意图
n 变更受控。在整个产品开发周期的任何时间点，市场人员发现要满足客户需求需要增加新的需求。开发测试组织将对这些需求进行风险评估，确定对原来配置的测试是否足够或者需要进行追加测试。由开发团队根据成本、时间和风险因素的分析来最终决定是否进行追加测试，并通过严格执行相关流程和配置管理来加以管理。
案例 F公司的可靠性增长试验测试平台建设
可靠性增长试验是在产品的研制生产过程中，为达到产品某阶段可靠性要求而采取的一种试验方法，是暴露问题、定位、改进、再试验的循环过程，用来提高产品的可靠性水平，最后直到问题可以承受的水平(见图5-3，其中MTBF为Mean Time Between Failure的缩写，指平均无故障时间)。可靠性增长试验相比一般的可靠性增长模式来说，在产品量产之前，可以更有效地激发出产品的潜在故障，并得以提前找出原因，给出解决方案。该公司由于新产品经常出现批量性质量问题，从2008年开始探索设计阶段的可靠性测试方法，并于2010年与可靠性咨询公司合作，研究产品的设计和可靠性实验方法(故障激发与改进)，其目标是将寻找符合产品的可靠性试验方案和方法，并将其嵌入到研发流程中，固化下来。
图5-3 快速可靠性增长模式
该公司可靠性试验测试平台建设的主要过程如下：
n 数据分析和挖掘。针对两款型号的产品本身质量可靠性问题的市场数据进行收集、整理、统计和分析，并初步确定故障/缺陷的原因。
n FMEA分析。学习DFMEA(Design Failure Mode Effects Analysis的缩写，指设计失效模式与影响分析)和PFMEA方法(Process Failure Mode and Effects Analysis的缩写，指制程失效模式与影响分析)，并建立、完善和应用产品故障模式库，将FMEA、DOE(Design Of Experiments的缩写，指试验设计)和试验等可靠性方法的结合使用(见图5-4)。
图5-4 FMEA、可靠性试验和DOE
n 可靠性增长试验。系统学习可靠性增长试验知识，引入相应试验设备和建立与外部试验机构的合作关系，分析、设计故障激发试验方案，记录试验中参数数据，并进行试验确认和改进，最终移交和实施符合企业产品的可靠性增长试验标准规范。
通过可靠性增长平台的的建设，针对主要故障模式采取有效的改进措施，使源于产品本身质量可靠性问题的市场年返修率大幅降低达40%以上;另外通过QFD、FMEA、DOE、过程控制、供应商可靠性管理等方法的运用，改善产品质量管理效果，改进措施成功率要求达到90%;让研发设计人员初步树立了可靠性设计、试验的理念，建立了适合的可靠性实验方法;最后提出在研发流程各个阶段应当进行的可靠性试验项目的建议(尤其是试验参数和方案等关键内容)，并固化到流程中。

标签：研发管理IPD讲师 流程管理培训师 培训 课程 流程管理 项目管理 研发管理 谢宁