IPD产品开发体系的产品测试标准制定：我们的实践与思考
说到产品测试，很多人第一反应可能是"不就是点点看能不能用吗"。我刚开始接触IPD体系的时候也是这么想的，觉得测试嘛，找几个工程师对着需求文档检查一遍，差不多就行。但真正深入了解之后才发现，这种想法实在太浅了。产品测试标准制定这件事，远比想象中复杂，也重要得多。今天我想把我们在薄云这些年做IPD产品测试标准的一些经验和思考分享出来，尽量用大白话讲清楚，不搞那些玄之又玄的概念。
一、我们是怎么理解IPD体系中的测试定位的
在讲测试标准之前，得先说清楚测试在IPD体系里到底处于什么位置。IPD，Integrated Product Development，也就是集成产品开发，说白了就是一套怎么把产品做出来的方法论。这套方法论把产品开发分成了好几个阶段，每个阶段都有该干的事，测试就是其中非常关键的一环。
我记得第一次参加IPD评审会议的时候，听到一个说法：测试不是开发的"附属品"，而是独立的质量保障活动。这个观点让我印象深刻。在传统的开发模式里，测试往往是开发做完了，找两个人来"找找bug"，属于救火队员的角色。但在IPD体系下，测试是从需求阶段就要介入的，不是等产品做完了再去测，而是在整个开发过程中都在进行。
为什么这么安排？因为缺陷发现得越晚，修复成本就越高。这个道理可能大家都听过，但具体高到什么程度呢？根据我们的统计数据，如果在需求阶段发现一个问题，修复成本可能是1；到了设计阶段，这个数字可能变成5到10倍；要是等到产品发布了才发现问题，那修复成本可能是几十倍甚至上百倍。所以测试左移，把问题在早期就抓出来，这才是测试在IPD体系里的真正价值。
二、产品测试标准到底包含哪些内容
接下来聊聊测试标准本身。这可能是大家最关心的问题：一个完整的产品测试标准应该包含什么？说实话，我们也是在实践中一步步摸索出来的，最初的几版标准现在看来简直惨不忍睹，不是缺这就是少那。
经过几年的迭代，现在我们的测试标准主要包含以下几个核心部分：
- 测试范围与边界：首先得说清楚测什么、不测什么。很多团队在制定测试标准的时候容易犯的一个错误就是贪大求全，什么都想测，结果什么都测不深。明确边界很重要，知道什么不在测试范围内，才能把有限的资源集中在关键点上。
- 测试方法与策略：不同的测试目标需要不同的测试方法。功能测试、性能测试、兼容性测试、安全测试，每一种都有其特定的测试思路和工具。测试标准里要把这些方法明确下来，让执行的人知道该用什么方法去测。
- 测试通过准则：这是最容易扯皮的地方。什么情况下算测试通过？有没有明确的量化指标？测试标准里必须把这些问题回答清楚。我们现在的做法是针对每一类测试都制定具体的判定标准，比如功能测试要求所有用例100%通过，性能测试要求响应时间在某个阈值以内。
- 测试环境要求：测试环境对测试结果的影响太大了。同一个产品，在不同的硬件环境、网络环境下测出来的结果可能天差地别。测试标准里要明确规定测试环境的配置，包括硬件、软件、网络、数据等方面。
- 缺陷管理流程：发现了问题怎么办？缺陷怎么分级、怎么分配、怎么验证修复、怎么关闭？这些流程都要在测试标准里说清楚。
2.1 测试类型的选择与优先级
在具体制定测试标准的时候，测试类型的选择是一个需要认真考虑的问题。并不是所有的产品都需要同样类型的测试。一个企业级软件产品和一个面向普通消费者的App，测试的重点肯定不一样。
以我们的经验，测试类型的选择应该基于产品特性和风险评估。首先要做风险分析，识别出产品中哪些功能是核心功能、哪些是新功能、哪些可能有安全隐患，然后把测试资源向这些高风险区域倾斜。
比如某个功能虽然用得不多，但如果它出错了会导致数据丢失，那这个功能的测试优先级就应该是最高的。相反，一个使用频率很低、出了问题影响也不大的功能，可能就不需要投入太多测试资源。
2.2 测试用例设计的基本原则
测试用例是测试工作的基本单元，测试标准里必须包含用例设计的指导原则。我们在这方面的教训特别多，早期很多测试用例就是简单地照搬需求文档，根本起不到发现问题的作用。
好的测试用例应该具备几个特点：
- 有明确的测试目的：每个用例都是为了验证某个具体的点，而不是漫无目的地"试试看"
- 有清晰的预期结果：测试执行前就要知道什么样的结果是对的，这样才能判断测试是否通过
- 有一定的独立性：用例之间尽量不要有依赖关系，这样执行的时候可以灵活组合
- 有可重复性：同样的条件下执行，结果应该是稳定的
除了这些基本的原则，我们还特别强调测试用例的"可测性"。有些需求描述得太模糊，根本没法转化为测试用例。遇到这种情况，我们的做法是要求需求方先把需求写清楚了再开始测试，而不是将就着来。
三、我们制定测试标准的一个大致流程
说完测试标准的内容，再来说说我们是怎么制定这个标准的。这个过程其实挺有意思的，最开始我们觉得制定标准嘛，找几个专家关起门来讨论几天就能搞定。结果发现完全不是那么回事，闭门造车造出来的标准，到了执行层面根本推不动。
现在的做法是多轮评审、逐步完善。第一步是起草，我们会有专门的测试标准负责人先出一个初稿，这个初稿主要是框架性的东西，先把结构定下来。然后是评审阶段，这个阶段会拉上开发、产品、测试、运维等各个相关方一起讨论，听取各方的意见。
评审过程经常会有一些意想不到的争论。比如有一次讨论性能测试的标准，开发说应该用生产环境的数据，产品说要用极端情况的数据，运维说两种环境都要考虑。最后大家讨论了很久，才达成了一个各方都能接受的方案。这样的争论是必要的，因为只有经过充分讨论的标准，执行起来阻力才会小。
标准定稿之后，我们会先在小范围试行，看看实际操作中有没有什么问题。有问题就修订，没问题再全面推广。这个试行—反馈—修订的循环我们会重复好几轮，确保标准是真正可落地的。
四、在薄云的实践中的几个关键经验
说了这么多理论层面的东西，我想分享几个在薄云实际做测试标准的过程中积累的具体经验，这些经验可能更具有参考价值。
4.1 测试标准要与产品生命周期相匹配
不同阶段的产品，测试标准应该有不同的侧重点。全新产品和迭代产品的测试策略是完全不同的。全新产品需要更全面的测试，因为不知道哪里会出问题；迭代产品则可以更多依赖回归测试，把有限的测试资源集中在变更部分。
我们把产品按阶段分成四种类型：全新产品、重大升级产品、常规迭代产品、补丁产品。每种类型都有对应的测试标准模板，测试负责人只需要根据产品实际情况做适当的调整就行，不需要每次都从零开始制定测试标准。
4.2 自动化测试与手工测试的平衡
这是一个经常被问到的问题：测试标准里要不要包含自动化的内容？我们的观点是，测试标准本身是方法论层面的东西，不应该限定用自动化还是手工，但我们会明确哪些场景适合自动化、哪些场景必须手工。
适合自动化的场景通常有几个特点：用例稳定、重复执行多、脚本开发成本低。适合手工的场景则是：探索性测试、用户体验测试、一次性验证等。测试标准里我们会给出判断的原则，让各团队根据自己的实际情况来决定。
在薄云，我们有一个专门的测试自动化平台，团队可以把自己维护的自动化脚本提交到这个平台上。大家互相分享、互相复用，这也避免了每个团队都重复造轮子。
4.3 测试数据的准备与管理
测试数据这个问题，看似不起眼，其实是个大坑。我们曾经有个项目，测试做了两个月，最后发现用的测试数据都是过期的，和实际情况完全不符，测试结果根本不可信。
从那以后，我们在测试标准里专门加了一章关于测试数据管理的内容。包括测试数据的来源、生成方法、版本管理、更新周期、保密要求等，都有明确的规定。对于一些敏感数据，还会要求做脱敏处理。
五、测试标准执行的几个常见问题和解决办法
标准制定出来了，执行过程中还是会遇到各种问题。这里我想聊几个我们遇到过的典型问题以及解决办法。
第一个问题是执行不到位。测试标准写得再好，下面执行的人不按标准来也没用。解决这个问题，我们采用的是"检查点+审计"的方式。在关键的里程碑设置检查点，审核测试工作是否符合标准要求。不定期地还会进行抽查，看看实际执行情况怎么样。
第二个问题是标准与实际脱节。技术发展很快，测试标准很容易就过时了。我们的做法是每年至少对测试标准进行一次全面评审，根据技术和业务的发展做必要的更新。平时也会收集执行中的反馈，发现问题及时修订。
第三个问题是各团队理解不一致。同样一条标准，不同团队可能有不同的理解，执行出来结果就不一样。为了解决这个问题，我们会组织标准解读的培训，让各团队对标准有一致的理解。还会建立答疑机制，有问题随时沟通。
六、一些实操性的建议
聊了这么多，最后我想给正在做或者打算做测试标准制定工作的朋友几条实操性的建议。
首先，别追求一步到位。测试标准是一个持续完善的过程，不可能一开始就做得尽善尽美。先有个可以用的版本，然后在实践中不断优化就行。我们现在的测试标准已经迭代了七八个版本，每次都有改进。
其次，一定要让执行方参与标准的制定。如果标准都是制定者自己想当然写出来的，执行的时候肯定会遇到各种阻力。测试要参与，开发要参与，甚至产品经理也应该参与进来，多方博弈才能出好标准。
第三，保持标准的可读性。标准是写给人看的，不是写给机器看的。如果一个标准写得像天书一样，谁也看不懂，那这个标准就失去了意义。我们现在的标准都是用大白话写的，尽量避免专业术语，即使有术语也会给出解释。
第四，建立反馈机制。标准实施过程中一定会遇到各种问题，必须有一个渠道让执行的人反馈。反馈的问题要及时处理，处理结果要通知到相关人员，这样大家才有动力继续提反馈。
第五，与公司整体流程相融合。测试标准不是孤立的，它应该和需求管理、开发流程、发布管理等相关流程衔接起来。如果一个标准定出来和公司其他流程格格不入，那执行起来会很别扭。
七、尾声
写着写着就聊了这么多。关于IPD产品开发体系中产品测试标准的制定，还有很多话题可以展开，但篇幅有限，今天就聊到这里吧。
回头来看，测试标准这件事，说到底就是想把"测试做好"这件事给规范化、系统化。没有标准的时候，测试质量完全取决于测试人员的能力和态度；有了一个好标准，即使团队成员水平参差不齐，也能保证一个基本的测试质量。
当然，标准也不是万能的。它是一个起点，而不是终点。真正的测试质量，还是来自于团队的专业能力和对质量的敬畏心。标准能帮我们做到80分，剩下的20分需要靠人来实现。
希望在薄云的这些实践经验，能给正在做这件事的朋友们一点参考。如果有什么问题或者不同的看法，欢迎一起交流探讨。
