五一假期刚刚结束，大家都度过了疫情以来难得的休闲假期，但因大风天气频发，部分高铁线路出现线路悬挂异物，导致部分火车晚点运行，进而引起北京西站出现了大量旅客滞留的情况，引发了大家的关注。对于火车晚点，大家都能理解，但对于北京西站的处理方式和应急做法，民众就不见得理解了，大风刮飞地膜的事件不容易出，但相应的应急措施也需要预先想好。通过这个事件，联想起我们软件测试行业，哪些过程和活动是咱们需要提前想好应急措施的呢。

　　那么就跟着我来一起梳理梳理，那些可以提前想到的“地膜”事件，以及我们能够想到的应急措施，防止出现软件测试领域的“旅客滞留”现象。

　　拿一个传统的瀑布模型的信息系统来说，软件系统的生命周期分为需求分析、概要设计、详细设计、编码、测试及运行维护阶段。软件的测试工作是否只在测试阶段呢，并不是。现在都提倡软件测试的提早介入，那为什么要提早介入，多早算早呢，笔者认为从需求分析开始就可以介入了。下面就从软件生命周期各个阶段开始梳理。

　　（一）需求分析阶段

　　这个阶段的主要工作是确定软件的功能性需求和非功能性需求，包括系统的功能、性能、安全、数据和界面展现要求，该阶段形成软件需求规格说明书。测试人员在本阶段可以针对需求文档来进行文档检查。一是需求可读性，了解业务人员想要实现一个什么功能，这个功能是否合理，现有系统是否有类似功能；二是需求完整性，检查需求中是否详细描述业务规则，业务之间是否有闭环流程，有没有遗留在流程外的功能；三是需求详尽程度，检查系统的非功能需求是否有详尽描述，是否包含了诸如性能要求、安全需求等非功能需求。这些需求不妨碍系统的功能实现，但功能的好坏直接影响系统的易用性、安全性等。通过对需求文档的完整审视，我们可以大概了解该系统的目标用户和客户需求，系统的解决方案及业务价值。而我们在需求阶段将这些潜在问题梳理清楚，能够最大限度地减少项目返工的成本，大幅提高项目的成功率。

　　那么这个阶段潜在的“地膜”有哪些？又该如何应对呢？我们将其进行了如下梳理，形成《表1：需求阶段的风险事件分析及应对措施》。

表1：需求阶段的风险事件分析及应对措施

　　（二）概要设计、详细设计阶段

　　这个阶段，开发人员要把需求分析阶段确定的功能需求转换成需要的软件体系结构，体系结构中每个模块对应一些功能需求，明确软件由哪些模块组成，模块的层次接口和调用关系。还要确定系统的数据结构和数据库结构，该阶段形成概要设计说明书。详细设计阶段任务是将概要设计阶段的每个模块完成的功能进行具体描述，表示为精确的结构化的过程描述，对模块的控制结构，先做什么，后做什么，条件判定，重复处理等进行表示和描述，形成详细设计说明书。

　　在这个阶段，测试人员一般开始进行测试计划和方案的编写，在方案编写阶段，我们需要对需求进行整体考虑，同时考虑测试时的一些特殊情况，梳理关联系统，查看必要的关注点是否已覆盖到，有以下几点需要特别注意，我们挑选部分事件进行重点阐述，详见《表2：设计阶段的风险事件及应对措施》。

表2：设计阶段的风险事件及应对措施

　　（三）编码阶段

　　该阶段就是需求具体实现的过程了，在这个过程中，开发人员需要按照编码规范对程序代码进行检查，我们测试人员在这个阶段，就可以使用一些工具对程序进行另一种检查了，比如我们可以利用jacoco工具，来查看程序的覆盖度情况，通过自研的接口校验工具，检查接口对反向案例有没有很好的校验。我们还可以使用自动化工具，对界面进行自动化案例的设计。在这个阶段，需要开发人员配合完成代码插桩，实现代码覆盖率的检测；配合完成报文格式的编写以及报文的获取，并实现自研接口工具的反向检测；配合完成界面要素的定制，实现自动化脚本的快速生成。总之，编码阶段，开发人员需要提前排雷，尽量避免将问题遗留到测试阶段。

　　（四）测试阶段

　　进入测试阶段，即进入了测试人员的主战场，在这个阶段，我们需要关注的项就太多了，功能测试，性能测试，接口测试，自动化测试，安全测试（技术安全、业务安全），外联第三方测试，兼容性测试等等。测试人员需要关注的需求包括功能需求和非功能需求，还要再次关注关联系统测试需求。针对每个类别的测试，测试人员前期已进行了梳理，形成了测试关注要点，对于这些可能的“地膜”，测试人员根据经验已经一一列出，后续也会不断更新。这里重点选取一些流程管理方面可能会出现的“地膜”事件，如未按照流程进行操作，轻则是考核失分，重则是形成合规风险事件。

　　1、评审流程：

　　工作量评审→方案评审→案例评审→准入。

　　2、测试数据申请流程：

　　按照数据的脱敏程度，分级申请。比如全部脱敏数据，只要组长级别的审批通过即可，部分脱敏的要上升一个层级，未脱敏的数据需要上升到老总级别审批，同时需要向相关安全部门报备，用完后及时清理。

　　以上测试数据，均需要在项目结项后一个月内清理。

　　3、环境申请及登记流程：

　　有常备测试环境的一定要在项目开展过程中使用常备环境，并进行登记。

　　无常备测试环境的需要在相关系统中提先进行申请。

　　同时还要确保测试环境中无敏感信息留存。

　　4、案例设计：

　　需要充分考虑反向案例的情况，同时实现自动化测试的案例，还需要在案例中增加自动化的案例编号。

　　5、测试过程管理相关：

　　①　在测试过程管理系统中建立完整的测试套件，包括冒烟测试套件，功能测试套件，业务安全测试套件。

　　②　测试缺陷需要从测试案例发起，所有的案例均需在测试准出前执行完毕。

　　6、测试度量指标：测试度量

　　测试案例导入及时率：测试准入通过后7日内导入；

　　测试案例执行率：目标值100%；

　　致命、严重级别缺陷占比，反向案例占比，平均每百测试案例缺陷发现数，测试执行通过率，测试自动化率等等。这些指标都需要关注并按要求完成。

　　（五） 运行维护阶段

　　项目顺利投产，进入运维阶段，测试执行工作暂时告一段落，但测试工作并没有结束，我们还需要跟踪投产情况，同时关注系统上线后的运行情况。对于新建系统，需要收集系统的运行数据，以便后续的优化项目。我们可以根据运行情况来评估回归测试的方式，也可以对后续优化性能测试策略、测试目标、测试场景等提供参考和支持。

　　通过上述对软件测试过程的简要梳理，相信大家对于测试过程中如何排雷和应急有了一定的认识，软件测试是为信息系统排雷的，那谁来为软件测试的工作排雷呢，就需要我们大家积极思考，将类似的“地膜”事件一一找出，让排雷工作不含雷。

作者：金宝珠   

来源：51Testing软件测试网原创