作为一个测试团队，基本的职责是：测试产品，发现缺陷，报告结果，使每个版本的测试水准稳步提升。这些价值是作为一个测试所必须具备的，发挥这些价值能够让测试获得研发团队的基本信任。
这类价值分为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 找对症结建立测试用例基线
在建立测试用例基线工作的前期，我建议和服务代表、市场代表、研发经理做充分的沟通。最好进行思路上的转变：测试的角度由设计验证转变为需求验证、应用场景验证；首先考虑的是业务问题的解决而不是自动化的方法。
3.2 正常使用中部分出错
3.2.2 解决问题的思路
【一般处理原则】
产品在使用过程中小毛病不断，一方面会降低用户的满意度；另一方面也会让产品研发不得不投入大量的精力去处理缺陷。如果这类问题经常发生，测试需要把拦截缺陷作为比较优先的任务。
由于解决这类问题需要一个经验和成果积累的过程，所以周期比较长。
【解决方法】
1）扩展基本用例集，使之包含安装、升级、应用场景、性能的部分用例；2）形成测试设计要素集，完善测试设计方法。
“测试分析”是画出业务流程，以及各种分支、异常处理过程；“测试设计”是使用深度优先或广度优先策略，实现对图的边、语句、逻辑或路径等的覆盖。大部分情况下，测试没有发现产品的缺陷，并不是“覆盖”的方法不全面，而是在图上根本就没有画出这部分内容。
因此，在测试设计中需要重视“被测试对象分析”：针对需要测试的特性、业务流程、功能（即被测试对象），选择合适的模型表达处理过程、状态跳转、异常处理、逻辑约束、数据结构等，以这些模型为基础进行测试设计，才真正能更有效地拦截缺陷。而在解决方法中提到的两点正是帮助完善“被测试对象分析”的方法。
总之，测试设计方法很重要，但是测试工程师更容易忽略被测试对象分析。
此外，没有正规测试设计过程的探索式测试似乎能够更快地发现缺陷，如果仔细理解常用的探索方法，可以看出这种测试很重视“被测试对象分析”和“攻击”，即通过各种探索方法找到软件各种可能的用法（被测试对象分析），以及通过各种探索方法试探如何让软件出错（可靠性和安全性攻击）。
3.2.3 扩展测试类型
产品中，常见的测试类型包含功能、性能、可靠性、安全性、可服务性、资料；其他测试类型则由产品根据自己的情况选择或者定义。
测试类型一般认为是和ISO 9126软件质量模型一致，但是在实际工作中，测试类型和质量模型并不完全一致，我们产品常用的测试类型有：
功能测试。产品的新、老功能与需求是否一致，各种分支处理是否正确。
性能测试。系统的性能指标，超负载处理能力，长时间稳定性。
一致性测试。产品是否满足相关的标准、规范和法规的要求。
兼容性测试。产品对不同的操作系统、数据库、第三方插件、外部接口、组网环境、硬件平台的兼容性。
可靠性测试。系统从各种已知故障中恢复的过程、影响和难易程度。冗余备份、过载控制等可靠性机制在各种已知场景下是否可靠。
安全性测试。组网设计、访问控制、权限管理、数据保护等安全机制是否能够有效防止安全攻击，并能维持正常运行和保护敏感数据。
可服务性测试。安装升级的过程、影响和难易程度。配置、维护、故障处理等能力是否满足日常维护需要。
资料测试。产品的配套资料能否正确指导安装、升级、配置、维护、故障处理等操作。
体验测试。在仿真、镜像或客户环境中，模拟客户的真实业务场景，对学习成本、操作路径、操作时间、信息呈现方式、界面布局等进行的体验。
互操作测试（IOT）。与不同的第三方设备、不同主流终端设备能否正确地互操作。
实验局测试。新产品或新版本在正式大范围商用前，先在个别客户的真实业务环境下使用一段时间，使缺陷可以更充分暴露，降低大范围应用后的质量风险。
镜像测试。在镜像环境上进行的测试，产品在特定环境下使用，使其所存在的问题能够提前暴露。镜像测试主要强调测试环境的镜像，测试内容可以是功能、体验、可靠性、可服务性等测试类型。这里的镜像是将产品的真实应用环境复制到实验室，环境的复制包含设备、网络、数据、业务、第三方系统等全部环境要素。严格意义上说，是将客户的环境按1∶1的比例在实验室复制，但这样做成本太高，所以更常见的是缩小比例复制，采用与客户环境同系列、但配置较低的设备搭建测试环境。
3.2.4 测试设计要素清单
测试设计要素清单是影响特性表现的各种常规因素。这是根据特性测试的经验总结出来的测试设计辅助工具，这个清单和测试设计方法一起，帮助测试工程师更全面地分析被测试对象。
测试设计要素清单完全是由每个产品经理自行建设，一般测试设计要考虑的要素和产品的数据模型密切相关，因此通常建议产品测试和设计团队共同参与。
3.2.5 客户问题RCA分析
在问题发生后，首先通过访谈和资料分析收集尽可能完整的问题信息和数据。然后通过头脑风暴、鱼骨图、因果图、5why等分析方法确定直接原因（问题发生时事物的状态、进行的操作，比如服务工程师误操作）、根本原因（导致问题必然发生的最本质原因，比如操作没有分级权限控制）、间接原因（导致问题发生的其他影响原因，比如操作员是新手）。最后针对分析出来的各个原因制订对应的改进措施，并在措施实施后进行结果的核实和成果的推广。
第一次追问why，得到直接原因，措施可以拦截这个缺陷，但同类缺陷无法拦截，治标不治本。
第二次追问why，得到间接原因，措施可以拦截这个缺陷，也可以拦截同类缺陷，但缺乏可实施性，隔靴搔痒。
第三次追问why，找到根本原因，措施可以拦截这类缺陷，改进彻底且可持续
3.2.6 提升能力的目的是解决问题
3.2.7 预则立不预则废—重视网上问题分析
问题要改进，很多时候是需要市场代表、系统工程师、测试工程师合作的。
推荐的做法是：持续搜集和分析在客户验收、应用中发现的问题，对问题至少分析到软件设计和测试设计的改进方法，周期性地进行统计。这样，当某类问题比较突出的时候，可以把包括问题、解决方法、需要的协助（这个很重要）、改进后的效果等信息完整、及时地拿出来。
一般开始统计之前确定的分类维度是特性、缺陷严重级别等，这样分类并不利于问题的聚焦和解决措施的制订，建议早期分析积累一定的信息后，采用亲和图法（一种质量分析的方法）逐步形成具有产品特点的分类统计的维度。
测试团队既要重视测试设计，也要重视客户问题的分析，这是测试最重要的两个手段，无论是个人能力提升，还是团队技术积累都要用到。