作为一个测试团队，基本的职责是：测试产品，发现缺陷，报告结果，使每个版本的测试水准稳步提升。这些价值是作为一个测试所必须具备的，发挥这些价值能够让测试获得研发团队的基本信任。
这类价值分为3部分：
1）拦截缺陷，即对产品进行测试，尽可能把产品的缺陷拦截在研发阶段。
2）提供数据，即提供产品的质量结论，并且给出支撑这些结论的数据。
3）测试过程可控，提升测试团队和测试工程师的能力，使得产品测试的效率、质量、成本都处于可控状态。
“扫门前雪”说明这些价值基本上是测试的本职工作，价值的发挥是依靠测试自身或者以测试为主进行能力建设。当然，这并不是说测试必须将这些价值发挥到极致，测试工程师们还需要权衡成本和收益，找到合适的“度”。
拦截缺陷是测试最基本的价值，尽可能多地发现缺陷，尽可能在版本发布前发现并解决影响用户使用的缺陷，这是测试这个职业存在的基础。
一个测试团队或者测试工程师，如果经常将基本功能缺陷漏出去，那是无论如何也得不到信任的。这也不是说只要产品到客户那里有遗留缺陷，测试活动就一定有问题，拦截缺陷的能力就一定需要改进。通常还是会视缺陷的影响程度而定。
为了方便说明问题的解决办法，这里按照缺陷的激活条件（产品中的错误在特定条件下被激活，导致产品出现故障，这个“特定条件”就是激活条件），把缺陷分为4类：
A 基本功能缺陷
用户进行正常业务的基本操作时，由于缺陷导致业务操作无法完成。这类缺陷对用户的影响最大，是研发需要最优先解决的问题。
B 常规使用缺陷
用户大部分情况下能完成正常的业务操作，但在特定的条件下进行业务操作时，缺陷被激活导致操作无法完成，产品绝大部分的缺陷都属于这一类。想要减少这类缺陷，需要进一步按故障的影响范围和严重程度找到优先解决的重点。
C 受攻击暴露的缺陷
产品出现故障并非由于用户的业务操作，而是由于软硬件或网络环境发生异常、业务请求量超出预期而造成过载、受到黑客攻击等。这类缺陷对用户的影响很大，但用户会基于成本来考虑解决的方式，不一定全部是通过增强软件能力来解决。
D 随机出现的缺陷
产品出现故障的条件不明确，如果故障的影响范围大、严重程度高、出现频次高，也会对缺陷进行专项分析。
3.1 用户无法正常使用
这类缺陷典型的有：安装或升级过程中出错，新研发特性的基本功能有错，升级后原本正常使用的功能出错，产品在正常使用中数次崩溃，正常使用中有导致用户直接经济损失或信息泄露的错误。
3.1.2 解决问题的思路
【一般处理原则】
产品安装或升级后，基本的功能出错或者完全不能使用，这对于测试的信誉是极大的伤害，如果这类错误经常反复发生，测试需要把拦截缺陷作为最优先的任务。
【解决方法】
这类缺陷的发现条件是：只要测试时覆盖到了这个功能或特性，就能够发现缺陷。因此，在遇到这类问题的时候，推荐的解决思路是：
1）建立基本测试用例基线（测试用例基线类似代码基线，是产品截止到某个版本时，产品全部测试用例及其测试结果的集合，这是产品下一个版本测试的基础，故称基线。基本测试用例基线是测试用例基线的一个子集），基本测试用例集包含产品最常见的业务场景，覆盖绝大部分功能特性。
2）尽可能实现100%自动化测试，在每次启动测试、产品发布之前都将基本测试用例全部测试一遍。
3）有时候出现问题还与客户数据、环境、使用方法有关，那么基本用例基线的测试用例就需要包含客户的数据、环境、应用场景等信息，并按版本、客户进行管理。
3.1.3 建立测试用例基线
我们的主要产品都要求建立测试用例基线，用例基线包含基本用例、常规用例、生僻用例。基本用例就是上一小节提到的基本用例集。常规用例包含绝大部分正常和异常用例，一般在老特性修改或者新特性对老特性影响较大时，会测试老特性的常规用例。生僻用例是一些使用非常规手段才能实施的测试，比如暴力攻击、断电、代码注入等，这些用例很少会重复测试，只有在可靠性、安全机制做架构升级时才会考虑重新测试。
测试用例基线的建设标准包含基本要求和附加要求2部分，基本要求主要关注测试用例基线的完整性；附加要求主要关注测试用例基线是否易于使用。
【基本要求】
1）建立产品级测试用例基线，基线覆盖产品的全部特性功能和所有质量属性（功能、性能、可靠性、安全性、可服务性、资料）。产品级的含义是，一个产品一个用例集基线，而不是一个版本一个用例基线，这是为了随时都能根据用例的测试结果得到产品质量的整体视图。
2）测试用例基线中的用例集或用例，包含与产品特性、产品需求的对应关系。这是为了在测试结束时，按特性或需求进行测试结果分析。
3）测试用例基线包含基本用例集，基本用例100%覆盖产品特性。这要求每个产品特性都至少有一个用例在基本用例集中。
4）测试用例基线的用例不存在空用例、拷贝用例、自动化脚本和文本不一致等情况。这是用例质量最基本的要求。
【附加要求】
1）测试用例基线覆盖产品的全部需求。
2）有针对测试用例基线的更新、审核机制。测试用例基线要做到和产品同步更新，每个版本根据特性变更情况刷新基线，保证基线不腐化。
3）有管理用例基线的工具，工具管理了用例及其执行过程和结果的全部的信息，并可以根据版本、客户、业务等条件方便地查询，并进行测试结果演变过程分析。
3.1.4 测试用例基线要同步优化管理和质量
在常用的、久经考验的软件中，也不乏“用户无法正常使用”的例子。
想要在测试的时候发现这个缺陷，必然需要有业务场景用例基线，这样在新版本验证的时候，才能够发现出现了特性丢失、有的业务场景已经不能实现的缺陷。建立测试用例基线绝非简单地把现有的用例实现自动化并管理起来，很可能需要改善用例的质量，一方面需要根据业务场景设计用例，另一方面在预置条件、操作步骤、中间和最终结果检查方面需要更严谨。
在各个产品进行这项能力建设的过程中，有些产品直接把特性测试时的基本功能验证用例拿来构造基本测试用例基线，使用后发现并不能拦截“用户无法正常使用”的缺陷，于是觉得基本测试用例基线“没有用”。但事实上并不是基本测试用例基线这种方法没有用，而是基线中的用例并没有覆盖用户的正常使用场景，或者覆盖了场景但是结果检查的内容不完整。
3.1.5 找对症结建立测试用例基线
在建立测试用例基线工作的前期，我建议和服务代表、市场代表、研发经理做充分的沟通。最好进行思路上的转变：测试的角度由设计验证转变为需求验证、应用场景验证；首先考虑的是业务问题的解决而不是自动化的方法。