第2部分--扫门前雪
作为一个测试团队，基本的职责是：
测试产品，发现缺陷，报告结果，使每个版本的测试水准稳步提升。这些价值是作为一个测试所必须具备的，发挥这些价值能够让测试获得研发团队的基本信任。
这类价值分为3部分：
1、
拦截缺陷，即对产品进行测试，尽可能把产品的缺陷拦截在研发阶段；
2、
提供数据，即提供产品的质量结论，并且给出支撑这些结论的数据；
3、测试
过程可控，提升测试团队和测试工程师的能力，使得产品测试的效率、质量、成本都处于可控状态；
“扫门前雪”，说明这些价值基本上是测试的
本职工作，价值的发挥是依靠测试自身或者以测试为主进行能力建设。当然，这并不是说测试必须将这些价值发挥到极致，测试工程师还需要权衡成本和效益，找到合适的“
度”。
第3章 拦截缺陷
拦截缺陷是测试最基本的价值，尽可能多地发现缺陷，尽可能在版本发布前发现并解决影响用户使用的缺陷，这是测试这个职业存在的基础。
为了说明问题的解决办法，这里按照缺陷的激活条件（产品中的错误在特定条件下被激活，导致产品出现故障，这个“特定条件”就是激活条件），把缺陷分为四类：
基本功能缺陷：用户进行正常业务的基本操作时，由于缺陷导致业务操作无法完成。这类缺陷对用户的影响最大，是研发最需要最优先解决的问题。
常规使用缺陷：用户大部分情况下能完成正常的业务操作，但在特定的条件下进行业务操作时，缺陷被激活导致操作无法完成，产品绝大部分的缺陷都属于这一类。想要减少这类缺陷，需要进一步按故障的影响范围和严重程度找到优先解决的重点。
受攻击暴露的缺陷：产品出现故障并非由于用户的业务操作，而是由于软硬件或网络环境发生异常、业务请求超出预期而造成过载、受到黑客攻击等。这类缺陷对用户的影响很大，但用户会基于成本来考虑解决的方式，不一定全部是通过增强软件能力来解决。
随机出现的缺陷：产品出现故障的条件不明确，如果故障的影响范围大、严重程度高、出现频次高，也会对缺陷进行专项分析。
3.1用户无法正常使用
3.1.1.问题案例
这类缺陷典型的有：
安装或升级过程中出错，新研发特性的基本功能有错，升级后原本正常使用的功能出错，产品在正常使用中数次崩溃，正常使用中有导致用户直接经济损失或信息泄露的错误。
3.1.2解决问题的思路
一般处理原则：如果这类错误经常反复发生，测试需要把拦截缺陷作为最优先的任务。
解决方法：这类缺陷的发现条件是，只要测试时覆盖了这个功能或特征，就能够发现缺陷。
推荐的解决思路是：
1、
建立基本的测试用例基线，基本用例集包含产品最常见的业务场景，覆盖绝大部分功能特性。
2、
尽可能实现100%自动化测试，在每次启动测试、产品发布之前都将基本测试用例全部测试一遍。
3、有时候出现问题还与
客户数据、环境和使用方法有关，那么基本用例基线的测试用例就需要包含客户的数据、环境、应用场景等信息，并按版本、客户进行管理。
无论是否有专业的测试团队，产品在发布之前一定是验证过基本功能的。缺陷没有被拦截，实际上大部分原因是：
新增的功能测试了，原有的老功能
没有全部测试；
原有的老功能测试了，但是
检查结果不完整；
新、老功能都测试了，但是测试用例和用户的
常用使用场景有出入；测试环境的基础数据、开关设置、终端类型、操作系统版本等和用户常用的使用数据有出入。
建立测试用例基线是确定了产品的常见使用场景，而自动化是固化成果，确保每次发布常规场景都能正常使用。
3.1.3建立测试用例基线
我们的产品都要求建立测试用例基线，用例基线包括
基本用例（基本用例集）、
常规用例（绝大部分正常和异常用例）、
生僻用例（非常规手段才能实施的测试）。
测试用例基线的建设标准包含
基本要求和附加要求两部分。基本要求主要关注测试用例基线的
完整性；附加要求主要关注测试用例基线是否
易于使用。
基本要求：
1、建立产品级测试用例基线，基线覆盖产品的
全部特性功能和所有质量属性。这是为了随时都能根据用例的测试结果得到
产品质量的整体试图。
2、测试用例基线中的用例集或用例，包含与产品特性、产品需求的
对应关系。这是为了在测试结束时，按特性或需求进行
测试结果分析。
3、测试用例基线包含基本用例集，基本用例
100%覆盖产品特性。要求每个产品特性都
至少有一个用例在基本用例集中。
4、测试用例基线的用例
不存在空用例、拷贝用例、自动化脚本和文本不一致等情况。这是
用例质量最基本的要求。
附加要求：
1、测试用例基线
覆盖产品的全部需求。
2、有针对测试用例基线的
更新、审核机制。
3、有管理用例基线的
工具，工具管理了用例及其执行过程和结果的全部的信息，并可以根据版本、客户、业务等条件方便地查询，并进行测试结果演变过程分析。
3.1.4测试用例基线要同步优化管理和质量
建立测试用例基线绝非简单地把现有的用例实现自动化并管理起来，很可能需要改善用例的质量，一方面需要根据
业务场景设计用例，另一方面在
预置条件、操作步骤、中间和最终结果检查方面需要更
严谨。
在我们的产品中，最开始部分产品出于自己的业务需要，建立基本测试用例集并实现自动化、形成基线，在每个版本中作为冒烟测试的基础用例使用，并随着产品版本的演进，同步进行维护和更新。由于这种做法很好地控制了基本功能的质量，后来逐步在产品间推广，把建立基本测试用例基线作为对全部产品的
基本能力要求。
3.1.5
找对症结建立测试用例基线
在建立测试用例基线工作的前期，建议和服务代表、市场代表、研发经理做
充分的沟通，
切忌盲目铺开或者孤立的看待每个问题。
沟通前，首先进行
缺陷分析，明确基本用例集需要包含哪些方面的测试用例，导致缺陷遗漏是因为缺少用例？还是操作方法不对或结果不完整？是否需要和具体的环境、客户数据、应用场景建立关联？根据这些信息估计用例数量、手工测试工作量和自动化工作量。
然后和市场代表或者研发经理
讨论策略，一种是先把用例集整理出来手工测试，再逐步实现自动化；一种是按缺陷出现的频率和业务影响排优先级，先把风险最大的部分整理用例集并实现自动化。后一种策略有更明显的商业成功导向。
发生这类问题的另一个原因是测试工程师对客户的业务流程、使用习惯、网络环境、产品部署不了解。因此，基本用例集中功能测试的环境、操作步骤、测试数据、结果检查项，都最好能够和客户或者市场代表进行确认。这样做的好处不仅是让用例更贴近用户的真实情况，还有利于测试工程师掌握客户的业务和要求的第一手信息。
总之，解决这一类问题，最好进行思路上的转变：测试的角度
由设计验证转变为需求验证、应用场景验证；首先考虑的是
业务问题的解决而不是自动化的方法。
3..2正常使用中部分出错
3.2.1问题案例
这类缺陷典型的有：
新版本在部分用户那里无法正确升级或使用，新特性在用户进行特别的操作或使用特定的数据时保护不足、出错或造成损失，系统在忙时处理能力不足或出错率高等。
3.2.2解决问题的思路
一般处理原则：产品在使用过程中小毛病不断，一方面会
降低用户的满意度；另一方面也会让产品研发不得不投入大量的
精力去处理缺陷。如果这类问题经常发生，测试需要把拦截缺陷作为
比较优先的任务。由于解决这类问题需要一个
经验和成果积累的过程，所以
周期比较长。
解决方法：这类缺陷的发现条件是，必须在
特定场景下测试，或者使用了
特定的数据，或者进行了
特定的操作，或者走了
特定的路径，总之，测试设计必须考虑到了这些情况。在遇到这类问题的时候，推荐的方法是：1、
扩展基本用例集，使之包含安装、升级、应用场景、性能的部分用例；2、
形成测试设计要素集，完善 测试设计方法。
判断采取什么手段进行改进，需要依据对客户问题的
分析，常用的分析方法是
根因分析法（RCA），通过对缺陷根本原因的分析，找到需要解决的问题，进而确定合适的解决问题的突破点。
为什么没有强调”使用经典的测试设计方法“？
产品有缺陷，肯定会想到改善测试设计，而改善测试设计首先又会想到使用经典的测试设计方法。进行根因分析后，
测试没有成功地拦截缺陷，问题并不是出在”测试设计“上，而是出在”测试分析“上。因此在测试设计中需要
重视”
被测试对象分析“：针对需要测试的特性、业务流程、功能，选择合适的模型表达处理过程、状态跳转、异常处理、逻辑约束、数据结构等，以这些
模型为基础进行测试设计，才真正能有效地拦截缺陷。而在解决方法中提到的两点正是帮助完善”被测试对象分析“的方法。
总之，测试设计方法很重要，但是测试工程师
更容易忽略被测试对象分析。
此外，
没有正规测试设计过程的探索式测试似乎能够
更快地发现缺陷，如果仔细理解常用的探索方法，可以看出这种测试很重视
”被测试对象分析“和”攻击“，即通过各种探索方法找到软件各种可能的用法（被测对象分析），以及通过各种探索方法试探如何让软件出错（可靠性和安全性攻击）。
3.2.3扩展测试类型
常用的测试类型有：
功能测试：新老特性满足需求；
性能测试：性能指标；
一致性测试：满足标准、规范和法律等；
兼容性测试：软硬件的匹配性；
可靠性测试：故障恢复；
安全性测试：安全机制；
可服务性测试：安装升级，配置、维护、故障处理等；
资料测试：配套资料；
体验测试：体验用户真实业务场景；
互操作性测试：第三方设备、不同终端的正确操作；
实验局测试：商用前，先在个别用户环境下使用；
镜像测试：镜像环境下测试，真实的环境复制到实验室；
这些都是常规测试内容，但几乎所有产品都测试的只有功能和性，其它类型的测试都会
根据产品的特点选择。
总的来说，功能、性能、一致性、可靠性、安全性测试在我们的产品中比较受重视。而
客户化测试（主要是体验测试、镜像测试、验收测试、Beat测试等有客户参与或者客户主导的测试）是近年来
逐渐被看重的测试内容。
3.2.4测试设计要素清单
测试设计要素清单是影响特性表现的各种
常规因素。这是根据特性测试的经验总结出来的测试设计
辅助工具，这个清单和测试设计方法一起，帮助测试工程师更全面地分析被测试对象。
测试设计要素清单并非一个新的测试设计方法，而是作为测试设计的
参考信息之一，与测试设计常用的流程图、状态图、逻辑、数据结构分析等方法
结合，目的是使得测试设计的时候不容易
遗漏对输入参数、处理分支的覆盖。
面对场景复杂，测试设计要素多，探索了一个行之有效的做法：
随机抽取一段时间的用户操作及其对应的数据，在版本发布之前在实验环境上进行回放，这样一来，现实存在的绝大多数部分数据组合和业务场景就被覆盖了。
实施这个思路需要产品做一些工作：
系统在处理完任何一个事物后，都需要留下足够详细的记录，测试用这个记录可以还原用户业务场景，形成一个包含预置条件、操作步骤、预期结果在内的完整用例。
3.2.5客户问题RCA分析
客户问题分析比较推荐的方法是
根本原因分析（RCA），这是一种回溯性失误分析方法，包括确定和分析问题原因，找出问题解决办法，并制定问题拦截和预防措施。
收集信息：确认问题、收集核实数据；
分析确定原因：直接原因（头脑风暴、鱼骨图、因果图、5why等分析方法）、根本原因、间接原因；
解决问题：预防措施、拦截措施；
结果评估：核实结果、推广应用；
根本原因分析是一个通用的方法，在不同领域应用时，需要结构化的具体方法，用于解决不同领域的具体问题。
测试进行客户问题的根本原因分析，主要是进行如下调查和追溯：
1、缺陷在项目的哪个
阶段被发现，缺陷的
触发条件、外在表现和业务
影响有哪些。通常触发条件不明的缺陷，不会进行根因分析。
2、缺陷的引入
阶段和引入的直接原因、间接原因、根本原因，如何避免引入这个缺陷？主要是为了找到问题改进的合伙人。
3、缺陷应该在哪个
阶段发现，测试遗漏的直接原因、间接原因、根本原因，如何才能发现？这是测试进行RCA分析的核心。
4、在分析原因、制定解决措施的时候，尽可能追问到
根因，并且针对
各层原因确定相应的解决措施。
在RCA分析中，测试遗漏的根因分析是最关键的环节。在我的经验中，RCA首先要注意：
追问到技术原因，避免把责任心之类的人为原因作为根因，很多时候需要追问3-5次才能找到真正原因。
3.2.6提升能力的目的是
解决问题
我们的很多产品，都是以这类缺陷的爆发作为测试团队、测试技术建设的契机，因为这时测试工作会比较容易获取所需的人力和设备资源。
我们应该形成一个问题
闭合的循环。
问题分析、解决方案设计、基础能力短板补齐、解决方案实施、问题闭环，形成一个环路。
3.2.7预则立不预则废--重视网上问题分析
即使是成熟的测试团队也可能会遇到这类问题。产品被用于新的客户时，由于客户内部组织、业务运营、发展历史、文化等环境不同，产品上线初期几乎都会出现这类问题。
推荐的做法是：
持续搜集和分析在客户验收、应用中发现的问题，对问题至少分析到软件设计和测试设计的改进方法，周期性地进行统计。这样，当某类问题比较突出的时候，可以把包括问题、解决方法、需要的协助、改进后的效果等信息完整、及时地拿出来。
一般开始统计之前确定的分类维度是特性、缺陷严重级别等，这样分类并不利于问题的聚焦和解决措施的制定，建议早期分析积累一定的信息后，采用
亲和图法（一种质量分析的方法）逐步形成具有产品特点的分类统计的维度。
测试团队既要重视测试设计，也要重视客户问题的分析，这是测试最重要的两个手段，无论是个人能力提升，还是团队技术积累都要用到。
3.3受攻击出错
3.3.1问题案例
这类问题典型的有：
被黑客攻击，网络风暴，对系统的人为误操作，对硬件设备的误操作，自然灾害导致停止服务等。
3.3.2解决问题的思路
一般处理原则：通常这类错误的解决思路是在产品中增加安全防护、备份恢复、过载控制、故障检测和恢复机制，而不是试图通过测试把这些缺陷都挖出来。
解决办法：根据网络上公布出来的
安全性漏洞和可靠性故障模式，加上产品的
已知缺陷，形成一个安全性漏洞和可靠性故障的
模式库，这个模式库既是产品进行可靠性和安全性机制设计的依据，也是测试人员开展攻击测试的依据。因此，模式库的建设通常是产品设计人员主导，测试工程师根据网上问题的分析进行补充，并且确定每种攻击的模拟的方法。
选择攻击方法时不能完全依赖客户问题分析，这样太被动。
网上公布的安全性漏洞和可靠性故障模式，是从大量的产品报告的缺陷中总结出来的，以这些为基础，可以用较小的代价达到比较全面的覆盖效果。
3.3.3建设故障模式库
故障模式库是可靠性测试的
依据，测试时逐一模拟库中的每一种故障模式对产品进行攻击，考验可靠性机制能否确保产品在这些攻击下保持正常的业务处理。
一个故障模式包含的内容有：
分类：如物理组网、硬件、业务流程、业务数据等；
故障模式：名称及其具体描述；
优先级：频率和范围确定优先级；
故障处理：约定故障处理的原则和预期效果；故障处理原则：进行根因告警；自动恢复；手工恢复；
故障模拟方法：方法、工具来模拟。
我们各个产品线都有安全性漏洞库和故障模式库的
基准库。
3.3.4DFX测试能力提升的线路
可靠性和安全性测试能力提升，走了两条完全不同的线路。
产品的可靠性及其测试能力，是在不断完善满足产品应用场景需求的过程中，同步成长起来的。
第1阶段：
特性测试。基本上是围绕设计进行的测试。
第2阶段：
故障注入。主要是台哦过过对网上问题的长期分析积累下来的故障模式库。
第3阶段：
可靠性指标测试。客户更关心恢复时间、业务影响等。在故障注入测试的基础上，对故障自动恢复率、业务恢复时长等可靠性指标进行采集和分析。
产品的可靠性的测试能力是通过一个
自然的过程生长起来的，因此，所需的方法、工具，包括如何融入研发流程，这些都是以产品的测试团队为主力完成的。
产品的安全性及其测试能力，则走了一条不同的路。安全性受到重视，是由于产品进入某些市场遇到了门槛，几乎是一夜之间就要求所有产品给出满足安全要求的计划表。因此，很多产品的安全性是以“
测试驱动开发”的方式建立的。
安全测试团队对产品的安全性测试包含两部分内容：
1、
特性测试。测试时，要逐一验证这些需求和设计的实现情况。这些内容由产品测试团队随版本开发进行测试。
2、
安全攻击。寻找漏洞进行安全攻击。由于产品测试团队没有足够的时间掌握安全攻击能力的测试，因此组建了一个跨产品的、专职的安全测试团队，完成安全漏洞库、安全攻击方法的能力建设，并进行产品的安全攻击及安全性评估工作。
把可靠性测试作为一个专门的门类进行发展，到形成可靠性指标，前后大约经历了5-6年的时间。随着技术的发展，产品的可靠性测试专家也获得了个人的发展。
安全性测试，至今第4个年头，仍然没有几个产品测试团队掌握了安全攻击方法和工具。
3.3.5重视行业信息的长期积累
测试人员可以在日常工作中关注业界的相关新闻、资讯、成熟的方法和工具，并注意产品相关问题的分析和积累。这样在专项问题研究分析时能够提供更多的信息，测试提供的信息如果丰富且有结构性，就能够给研发团队解决问题的信心。
一般搜集和整理这类信息，可以从3个角度进行：
看业界；看同行；看自己；
建议测试团队中，
固定一个经验相对丰富或思维相对活跃的人，对可靠性和安全性方面的技术做比较
长期的跟踪。
3.4随机出错
3.4.1问题案例
这类问题典型的有：
产品偶尔无规律地宕机；用户偶尔无规律地无法操作或操作出错；进行简单恢复后，不再必然出现的故障。
3.4.2解决问题的思路
一般处理原则：通常这类错误的解决思路，是提升代码质量，并为产品加上故障检测和自动恢复的能力（即检测到宕机或长时间无心跳就复位重启），而不是试图通过测试把这些缺陷都挖出来。
解决方法：发生这类问题的必然条件没有被找到，因而也无法根据问题分析找到测试流程或方法的薄弱点，也就无法进行有目的测试设计或改进测试执行方法。根据经验，通常是编码质量存在问题，第一选择是提升代码质量。
3.4.3利用工具提高错误检出率
当需要减少随机出错时，首选的方法就是代码静态测试。一般是利用工具进行静态检查，加上人工的代码审查。代码静态测试一般是以开发工程师为主体开展，测试参与的比较少。
也有一些产品在解决这个问题时采用的方法是：开发错误检测工具。应具备的功能有：
数据一致性；异常宕机core dump文件；告警；文件数目和大小；数据表大小；产品和系统异常日志；业务流程阻塞或挂起或未正常释放；系统资源异常波动；
常规测试中进行后台的、自动的宕机检测，很多产品都能够做到，但是回溯操作、现场快照则鲜有产品能够做到。
3.4.4通过测试解决这类问题不是好办法
无论如何，通过测试发现这类问题无异于大海捞针，发现了是运气，漏过了是必然，顺着研发经理给的绳子，测试很多生僻的用例绝不是什么好的方法。事实上，想发现这类问题，不仅系统测试是吃力不讨好，单元测试也不一定有效，代码的静态测试可能才是最经济的方法。
3.5分层构建缺陷拦截能力
找缺陷是公认的、测试最基本的职责。
| 问题分类 | 典型问题 | 方法 | 技术 |
| 用户无法正常使用 | 安装或升级过程中出错，新研发特性的基本功能有错，升级后原本正常使用的功能出错，产品在正常使用中数次崩溃，正常使用中有导致用户直接经济损失或信息泄露的错误 | 建立基本用例集 |
特性基本功能用例集
特性基本业务场景用例集
自动化测试
客户使用数据、环境、步骤的获取和基线化
|
| 正常使用中部分出错 | 新版本在部分用户那里无法正确升级或使用，新特性在用户进行特别的操作或使用特定的数据时保护不足、出错或造成损失，系统在忙时处理能力不足或出错率高等 | 增加测试类型，完善测试设计方法 |
测试类型、DFX测试
测试设计方法
测试设计要素清单
缺陷分析方法（RCA）
|
| 受攻击出错 | 被黑客攻击，网络风暴，对系统的人为误操作，对硬件设备的误操作，自然灾害导致停止服务等 | 安全性和可靠性测试 |
可靠性和安全性攻击测试
可靠性故障模式库
安全性漏洞模式库
|
| 随机出错 | 产品偶尔无规律地宕机；用户偶尔无规律地无法操作或操作出错；进行简单恢复后，不再必然出现的故障 | 代码质量提升 | 后台错误检测 |
测试基线库、基本用例集：目的是拦截基本功能错误；作用是基本业务能使用；
测试设计和DFX测试、提升覆盖度：目的是拦截正常使用的错误；作用是产品能正常使用；
攻击测试：作用是提升安全性、可靠性；
前两者是撒网
捞“鱼”，而后者是
钓“鱼”。捞鱼需要网织得密，覆盖够全；钓鱼则需要知道怎么才能让“鱼”上钩。一般来说，进行攻击测试需要更多的
分析工作，否则可能事倍功半。
3.6小结
解决“正常使用中部分出错”需要改进测试设计；解决受攻击出错需要增加DFX测试，这些都是通常认为测试工作中有
技术含量的部分。
我们的测试团队曾经做过实验，发现经过不到一个多月对产品和测试技术的学习，一个完全外行的新员工就可以发现产品70%-80%的已知缺陷，这些缺陷包括：
基本功能错误和大部分日常使用的错误。
遗漏较多的缺陷，一类是
应用场景不满足要求、各种
不一致的缺陷，因为新员工对产品特性掌握的不全面，没有办法根据可能的相互影响，进行同场景下各个功能的组合测试。一类是
特性对特殊或非常规数据处理的测试，因为新员工缺乏这方面的思维训练和经验。
容易遗漏的第一类问题，有很多都属于用户无法正常使用，因此这类问题
并非最容易解决的问题，相反，可能是测试解决起来
最困难的问题。因为实际项目中，这些缺陷主要通过需求验证、业务场景和应用场景验证来拦截，这些测试是基于需求的，但是大部分工程师最熟悉的是基于设计的验证。
需求验证、业务场景验证获取测试输入信息是比较困难的。