前言
测试是无穷无尽的，100%测试不可能的。众所周知，随着技术日新月异的发展，当前软件系统越来越庞大，越来越复杂。一个软件系统可能由各种各样中组件组成，这些组件可能分布在系统的各个地方，在系统中所处的地位也可能是有所不同的。与此同时，当前互联网好多公司的核心业务代码比较老旧，缺乏相关文档与架构去了解学习，即使核心业务代码有问题只要不影响核心业务，也不会做相关变动。开发在基于这样的系统，在后续不断的迭代，丢失文档化可能越来越严重，这就可能造成相关的系统架构设计及业务，可能只在相关人员的脑子中情况。一旦相关人员从当前岗位离职，那这些系统的可测试性就很差、测试难度及风险就很大。
对于系统庞大、可测试差的系统，要如何进行测试分析呢？面对这样的系统如何着手分析呢？
被测系统特点
每个被测项目都是独一无二的。因此基于同一流程去进行测试，虽然可能完成相关测试，但是测试效果、测试人员、测试开发人员的体验肯定是不一样的，因此基于项目的独特性，应该重新调整测试流程，改善流程来整合项目资源。
新开发系统
-
如果流程规范，会在开发相关阶段遗留对应文档，如产品规格书面书、系统详细设计、系统概要设计等，这些文档对于项目维护及后续介入人员了解项目是有很大的好处的。
-
如果缺乏过程文档，当相关人员了解产品业务、设计与实现，这也能帮助后续人员学习。但这种会有一种风险，一旦人员流失严重，该系统就会成为一个“雷区”。
基于上述两个原因，新开发系统会有以下特点：
-
文档完备，便于后期维护、后续人员介入学习了解系统。
-
人员完备，文档有一定缺失，这种情况会有老带新，学习效率高，但会出现人员流失风险，不利于团队知识积累。但不影响当前人员对系统分析。
-
早期介入人员流失严重、文档缺失，这种情况测试学习成本高、风险比较大，系统不易维护。
历史遗留的老系统
历史遗留的老系统，这种老系统一般会有以下特点：
- 定期维护，产品相关资料齐全。
- 年久失修，文档缺失或者文档描述和系统实现脱离严重。
在历史遗留的系统上重新开发
在历史遗留的系统上重新开发会有以下特点：
- 重新梳理老系统设计实现并规范开发阶段，对关键流程文档化。
- 重新梳理老系统设计实现但在相关人员脑子里不留存，后续开发实现也不文档化，延用老系统恶习。
测试点先发散后收敛
本文主要以以下两个场景来阐述如何发散测试点：
- 关键文档定期维护，项目知识保留完整
- 关键文档缺失或者年久失修，项目知识遗失严重。
上述两种场景对测试人员最大的影响就是：学习系统的难易程度及时效性。对系统的理解的深浅，会造成一些关键测试点的遗漏。为了确保全面的分析被测系统，所以测试人员在熟练掌握了产品业务之后，还需要学习了解被测系统的架构及技术实现。所谓“知己知彼百战百胜”，只有足够了解系统之后，测试点才更全更对、更有针对性，测出的问题才更有专业性。
基于对业务、系统的深层次了解之后，会发散出很多测试点。这些测试点可能包括安全测试、兼容性测试、性能测试、功能测试、易用性测试、UI测试等方面，这些测试点会很全面、也很多。关于测试点的发散，常用的发散方法有：等价类、边界值、错误推测、同类别功能类比、基于经验推测等方法。关于如何发散测试点，这里没法展开，因为不同人的测试思维是不一样的、每个人思维都是独特的，俗话说“众人拾柴火焰高”，所以整个团队在一起进行头脑风暴，效果是最好的，单个人会产生一定的思维壁垒，产生思维盲区，导致测试点的遗漏。因此测试点发散最好是整个项目全员参与，一起发现产品业务、系统设计、测试设计等各方面的缺陷。
由测试人员整合项目其他成员的测试点，汇总成一个大而全的测试点，安排相关方一起评审该测试点。评审该测试点的主要目的是：
- 确保测试点的全面性有无遗漏。
- 基于项目发布周期，确定本次发布周期要进行测试点，与相关方达成共识，实现风险均摊。
- 确定本期测试点之后，哪些测试点要划入下一期。
这个评审的主要功能是把发散的测试点进行收敛，收敛一般基于以下准则：
- 测试点影响大小。如果不测试该点，会产生什么影响，这些影响有多大，产生这种影响如何规避？
- 测试点优先级。不同的发布周期呢，对系统在不同周期内，测试侧重点不同，会删减不必要的测试点？
- 被测组件在系统架构中的地位。测试组件对系统架构的整体影响，会影响测试资源的倾斜及资源分配情况。如果被测组件影响整个系统，该组件的测试点会被要求全部执行。
总结
测试点先发散后收敛，这个好处主要是“全面撒网、重点捕鱼、风险均摊、测试高效”。测试点先发散是为了确保思考的全面性，通过不同人员不同视角来获取对测试系统的不同方面的关注点，收集这些关注点，构化系统热点图。测试点收敛是为了针对性测试，针对系统测试热点，选取核心测试点，进行测试精准打击，缩小测试范围、重点突击容易出问题的功能，与相关人员就选取测试点，达成一致意见，风险均摊。
