测试管理之路 —— 如何优化测试计划以提高测试覆盖率

Posted 2023-03-31 Austin_zhai

 

😏作者简介：博主是一位测试管理者，同时也是一名对外企业兼职讲师。
📡主页地址：🌎【Austin_zhai】🌏
🙆目的与景愿：旨在于能帮助更多的测试行业人员提升软硬技能，分享行业相关最新信息。
💎声明：博主日常工作较为繁忙，文章会不定期更新，各类行业或职场问题欢迎大家私信，有空必回。

 
 

阅读目录

• 1. 目的
• 2. 测试计划
• • 2.1 何为测试计划
  • 2.2 测试计划的具体组成元素
  • • 2.2.1 测试范围
    • 2.2.2 测试策略
    • 2.2.3 测试方法
    • 2.2.4 测试资源
    • 2.2.5 测试时间
    • 2.2.6 测试质量标准
  • 2.3 如何优化测试计划
  • • 2.3.1 确定的测试覆盖范围
    • 2.3.2 详细的测试策略
    • 2.3.3 良好的测试用例编写
    • 2.3.4 明确的阶段时间节点
    • 2.3.5 定时的测试计划更新
    • • 2.3.5.1 确定更新频率
      • 2.3.5.2 确定更新内容
      • 2.3.5.3 确定更新方式
      • 2.3.5.4 跟踪更新进度
• 3. 总结

1. 目的

  这阵子一直在忙测试项目的事情，正巧在一次项目阶段评审的会议上，团队里的一个测试组长描述的工作内容让我来了兴趣。他的原话是这样的：“在这次的XXX测试项目中，目前阶段的输出物已完成80%，其中XXX的测试计划基本可以保证现有的业务线功能覆盖率95%以上。”也许到了这里，会有很多的测试执行同学表示听不懂，测试计划与测试覆盖率有什么关系？测试计划不就是安排与分配相关测试资源与时间的一个文档吗？

  其实不然，测试计划其实是软件测试活动中一个至关重要的核心组成部分，相信很多担任过测试管理职位的同学都会有和博主一样的感受与见解。那么今天就趁着机会，让我们来一起讨论如何通过优化测试计划来提高测试活动执行中的测试覆盖率。

 
 

2. 测试计划

2.1 何为测试计划

  测试计划 —— 描述了要进行的测试活动的范围、方法、资源和进度的文档；是对整个信息系统应用软件组装测试和确认测试。它确定测试项、被测特性、测试任务、谁执行任务、各种可能的风险。以上的这段就是百度上对于测试计划的解释。其实对于广大测试管理岗的同学来说，测试计划有点类似于一份指导书，一般里面包含了测试的范围、测试策略、测试方法、测试资源、人员分配、测试时间表和测试质量标准等方面的内容，而且简单点来说，测试计划也不是由一个人写完或决定就OK的事情，它需要自身与外部团队的关系人员达成统一的认知后才能发挥效力。一份项目团队都认同的测试计划，才可以有效的让测试工作内容具有全面性、有效性和可管理性。也能帮助测试团队在测试活动中明确目标，制定测试策略和方法，规划测试资源和时间，监控测试进度和质量，以确保测试工作按计划顺利进行。

 
 

2.2 测试计划的具体组成元素

  通常来说一份符合日常测试活动要求的测试计划报告，需要由测试范围、测试策略、测试方法、测试资源、测试时间、测试质量标准几个内容元素组成，当然这个也需要根据各自公司对于测试团队的要求不同而会有些许的调整，但却不会影响这些基本内容框架的组成。

 

2.2.1 测试范围

  顾名思义，测试范围一般是指被测对象的覆盖范围，包括测试的软件版本、功能、非功能、特性等等方面。明确的测试范围可以有效的对测试活动边界进行界定，防止在测试后期出现执行活动变得冗长且无法收敛的现象发生。

 

2.2.2 测试策略

  测试策略就是我们在测试过程中为了达成测试目标所采用的各种测试方法和场景设计。一般来说测试策略不是一成不变的，不可能因为是同一个被测对象，仅仅因为迭代版本不同，就无脑的使用同一个测试策略。这里没有实践过的同学可能会觉得上述这些比较理论，我们就来举个例子详细说明一下测试策略。

  比如你的公司里有一个web类产品，那么对于作为测试管理岗的你来说，首先你需要确定本次测试活动针对整个被测对象要进行哪些类型的测试，接口测试、功能测试、自动化测试、性能测试，根据实际的时间周期与测试目标来进行有效选择；其次，对于测试内容进行测试方法的细分，用黑盒？白盒？灰盒？然后进行详细的描述，黑盒针对程序的外部功能，白盒针对内部代码逻辑，亦或者两方结合使用灰盒？再接着，确定使用哪些测试技术栈或工具来执行，手工来应付新出功能与复杂逻辑业务场景，selenium自动化框架来进行重复且稳定的往期功能与主业务线；其次，决定测试的覆盖功能范围，哪些模块使用手工，哪些模块使用自动化，哪些模块需要业务流串联；决定完这些之后就可以根据以上的这些来设计与分配测试环境，具体需要哪些硬件，OS版本，网络环境、中间件，客户端等等；当然Bug的生命周期管理也是必不可少的，使用什么工具来进行管理缺陷；最后相关的干系人员，角色分配与具体职责。

 

2.2.3 测试方法

  这里的测试方法就比较的宽泛了，一般是指我们在测试活动中所使用的不同测试类型、技术、工具等。就像之前测试策略的例子中提到的，针对每一次的测试活动正确使用不同的测试方法就可以帮助我们发现更多的潜在的问题和缺陷，并有效低成本的改进软件质量。

 

2.2.4 测试资源

  测试资源指的就是我们在整个测试执行过程中所需要用到的测试工具、测试设备、测试环境、测试数据等等。其实大家对于这块还是比较有实感的，毕竟面对的都是一些真实的硬件设备或看得到的软件载体。那么对于测试管理岗的同学来说，有效合理的分配测试资源也是间接的提升测试活动的效率和质量。反之就好比让你的团队测试一款APP产品，由于测试资源有限且分配不当，团队成员只能在某几台设备上进行测试，事前又没有确定好市场主流机型和操作系统版本，这意味着测试同学无法测试大部分的操作系统版本和设备组合，也无法进行充分的测试。这可能会导致团队无法发现一些潜在的缺陷，而且更绝望的是这些缺陷可能会在不同的操作系统版本和设备上出现。关键这还不算完，这些遗留或未被发现的缺陷会以线上问题的形式重新出现在测试团队的面前，而且还会以极高的后期成本来对其进行修复与确认。

 

2.2.5 测试时间

  这里的测试时间一般是指整个测试活动的所需时间周期，包括测试计划的编写在内，一直到产品上线测试活动终止。一说到时间，大多的测试同学都会叹一口气，吐槽公司或项目组给的测试时间不够，测试时间的长短也恰恰决定了一个版本的测试范围和深度。就和天平一样，质量与时间之间往往很难得到相对的平等。

  但是这里还是要谈谈时间的长短对被测对象的质量有着如何的影响。测试时间给的过短，那么不单单是测试执行环节，整个测试活动的每一个环节的质量都会被压缩，最明显的就是会导致测试同学可能无法覆盖所有的测试场景和测试用例，一些潜在的问题未被发现。因此，在这样的时间周期内要合理安排测试时间，根据重要性和优先级确定测试范围和测试用例，以确保测试工作的高效和充分就变为了无稽之谈。

  那么测试时间给的很长就好了吗，这样的命题当然也是不对的，过长的测试时间别的不说，光测试成本就会大大的增加，测试成本是什么？最直接的体现就是项目组全体人员的精力，测试人员天天无止境的测试，开发跟进，项目安排调拨等等。另一个就是无法覆盖所有的使用场景，测试人员是无法进行穷尽测试的，这个大家都知道。那么过长的测试时间无非就是在一些已知的测试场景中进行低效重复测试，最多再加之一点场景与经验的探索性测试，这样的局面就会让测试的效率与活动价值大大的降低。

 

2.2.6 测试质量标准

  测试质量标准也应该是大家耳熟能详的词汇，它一般用来代表测试活动中应该达到的标准或要求。简单来说就是衡量本次测试活动是否成功的一组数据标准。我们日常会用到的质量标准有测试覆盖率、缺陷密度、可靠性、性能、安全性等。这些标准需要结合每一次的用户需求、测试活动需求、团队技术力等进行综合考虑。这一部分可能比较的抽象，后期有机会的话会单独出一期来详细讲讲测试质量标准的拟定方法与参考技巧。

 
 

2.3 如何优化测试计划

  介绍了半天，终于回到了我们今天的主题。其实对于一份比较合理的测试计划来说，我们可以从以下几个方面去进行优化。

 

2.3.1 确定的测试覆盖范围

  我们在测试活动开始的前期就需要先确定测试覆盖的范围，这里大家不要简单的认为凭借过去对于自家产品的认知来进行覆盖范围是一个良策。我们既然要提高测试覆盖率的话就必须将“确定”这个动作尽量的做到完美。首先，对于本次被测对象的需求自身或团队是否有一个准确的分析，这里的分析与需求评审时不同，我们需要分析的是测试需求，而非原生需求，需求功能需要我们测什么？所有提到的被测功能是否定义明确？其次，我们需要提前做个风险评估，通过评估系统中的风险，大致确定测试的重点和方向；如果有条件的话可以对以往的被测对象历史数据做一个大概的分析， 确定之前在缺陷管理系统中记录的缺陷集中出现的模块与重点历史版本，这样也可以帮助我们来更好的确定测试覆盖范围。

 

2.3.2 详细的测试策略

  测试策略的细则在2.2.2中已经介绍的很详细了，那么我们在编写测试策略的时候就需要尽量的细化里面的细节。在细化的过程中你可以将之前讨论环节中很多模糊的事项进行具体安排，写的越细，在执行阶段的执行难度越小，但也不能矫枉过正，因为一旦方向错了，返工的工作量可能会让你绝望。

 

2.3.3 良好的测试用例编写

  因为之前已经用两篇文章阐述了如何写好测试用例，这里就不在展开细说了。这里有人会问编写测试用例和测试计划有什么关系？其实大家可以这么理解，测试计划不是一次性的测试指导书，它在对应的整个测试活动中一直都是在优化和修改的，就比如你在测试活动的前期阶段编写完测试计划后，如果测试计划一直到测试收尾阶段还是一次都没有修改过，那就只能说明这个计划只是废纸一张，计划是随着整个测试活动周期进行随时调整的，伴随着每个阶段进行不断修正的一个过程。那么转回头我们再说良好的测试用例编写其实也是在测试活动的前期为测试计划与测试覆盖率打下了一个坚实的基础，质量差的测试用例不仅存在着测试质量的隐患，还会拉大测试计划原定的安排轨迹，导致后期测试人员因执行用例质量较差而出现返工、信任丧失、情绪波动等各类成本损失的出现。

 

2.3.4 明确的阶段时间节点

  既然是测试计划，又怎么能少了时间节点呢？测试管理者在确定测试节点的时候一般都是进行反推，反推deadline的时间直至测试活动开始的时间，根据之前几步已经确认的条件来进行测试环节分割，再将每个环节的所拥有的时间进行详细分配。其实除此之外，我们还可以从活动中的多个方面来进行时间分配。第一，开发的中日程，比如从开发开始介入到某个功能完成的那一天测试其实就可以开始介入进行对应测试活动，但在此之前的时间是否可以完成需求熟悉与用例设计就需要管理者给到比较合理的准备时间；第二，环节的执行交替，例如需求分析、测试计划制定、测试用例编写、测试执行和缺陷跟踪等，这些我们常见的环节其实不一定需要头尾相连，有序合理的互相穿插也是很有必要的，特别是团队工作的场合，大可不必等待所有人都进入下一个阶段才整体开始对应工作；第三，与团队成员的协商，制定测试计划从来都不是管理者一个人的事情，在前期制定之初就可以在团队会议上进行头脑风暴，多多听取团队成员合理的意见，这样的测试计划想必也是大家乐意见到的计划。

 

2.3.5 定时的测试计划更新

  这块是诸多影响测试覆盖率中比较考验管理者的工作内容之一。如果想做好测试计划更新，博主建议尝试优化以下这些内容：

2.3.5.1 确定更新频率

  一般通过被测对象项目的时间周期长度来定，高速迭代的就更新的频繁一点；定制化项目或比较稳定的项目可以适当的减缓更新频率，但请切记，第一，不要随时修改，这个是测试团队整体的指导书；第二，知会至所有干系人，不要怕麻烦，这样做会帮你省掉很多麻烦。

2.3.5.2 确定更新内容

  和第一条里的内容呼应，在更新测试计划时，需要确定更新的内容。通常情况下，更新内容可能包括测试计划中的测试目标、测试范围、测试策略、测试用例等。需要根据实际情况进行判断，确定需要更新的内容。

2.3.5.3 确定更新方式

  在项目前期就确定好更新方式并知会到所有干系人，无论是邮件还是企微亦或是自研软件都是可以的，但切忌私下单发或者抄送遗漏，避免测试活动中出现纰漏而导致信息不一致的情况出现。

2.3.5.4 跟踪更新进度

  如果是第三方的测试团队就无所谓了，但如果是自家的测试团队，最好指派一个人来担任计划更新的跟踪人员，来确保每次的更新进度准确无误。

 
 

3. 总结

  光说不练假把式，我们就将上面的一些元素进行整合，给大家示范一下简单的测试计划应该如何写。（注：这里只是将元素进行简单整合，并无真实项目结合，借鉴即可，切勿无脑抄。）

测试计划：XXX产品项目测试计划 （APP端）

1. 测试范围
   本次测试覆盖范围主要包括登录登出、发布个人内容、评论、私信等功能模块，对各项功能进行详细的测试，包括功能输入输出及各种数据边缘情况的测试，确保产品能够稳定运行。
    
    
2. 测试策略
   2.1 测试环境：搭建适合APP测试的环境，包括模拟不同的网络环境和设备环境。
   (如果没有后续的测试环境或测试场景设计文档，可以在这里进行详细描述，反之则简洁带过即可)
    
   2.2 测试用例设计：对各个功能模块进行详细的用例设计，确保每个功能点都被覆盖。鉴于私信在v.xx版本测试中Bug出现率与线上逃逸率较高，针对此模块将加大用例设计量并在后期增加探索性测试环节。其余回归与往期功能的手工测试将根据用例库中v.xx版本的测试用例来复用执行，新功能相关测试用例进行手动编写并在测试活动结束后进行用例库归档。C端用户相关Happy Path业务流使用UI自动化测试进行功能覆盖。
    
   2.3 测试手段：结合手工测试和自动化测试，优化测试资源的利用效率。手工测试用例相关设计策略参看2.2，因自研自动化平台维护中，自动化测试分别使用jenkins+docker+selenium+pytest+allure进行UI自动化、使用jenkins+docker+requests+pytest+allure来进行接口自动化。
    
   2.4 缺陷管理：缺陷全生命周期管理使用TAPD进行及时收集、记录、追踪和管理，确保缺陷得到及时解决。缺陷相关严重程度与跟踪期限规则已知会全部项目干系人。
    
   2.5 测试评估：后续根据测试结果对测试策略进行评估，及时进行调整。调整频率与更新内容与测试计划保持一致。
    
    
3. 测试资源
   本次测试人员7人，其中5人进行手工测试，2人进行自动化测试。测试环境包括模拟器和真实设备，安卓机型：xxx 数量：xxx 涉及机型：xxx OS版本：xxxx ，（鸿蒙与苹果同理编写）按照测试策略的要求搭建，确保测试资源的充足。
   (同测试环境，没有详细相关测试文档的，在这里仔细描述所用的机型型号、操作系统版本、网络环境配置，有后端性能测试的，将服务器硬件与软件配置也写清楚)
    
    
4. 测试时间安排
   本次项目周期为14天，测试周期为7天。测试人员将在第7天进行TEST环境提测，准入达标后进行全面测试执行并在第8天进行前期测试评估，以及在第10天进行UAT环境提测，期间缺陷修复和确认均在各自对应环境进行。第14天进行最终测试评估和复盘总结。
   (此处下方附上具体的时间安排表，需要分开编写独立的时间表或使用管理工具填写工时的可以不在这里提现。)
    
    
5. 测试质量标准
   5.1 功能测试：对每个功能模块进行全面测试，确保功能的正确性、稳定性和可用性。具体功能覆盖标准参看《xxxAPP功能模块黑盒测试覆盖达标记录表》
   (这里不必按照上述的一定要弄个记录出来，每个公司习惯不同，有记录功能模块覆盖达标的指标即可)
    
   5.2 兼容性测试：针对不同的设备和操作系统版本进行测试，确保本次产品在测试范围内所提及的所有功能在各种情况下都能够正常运行。
    
   5.3 稳定性测试：检测产品在硬件持续高负载情况下的表现，确保产品可以稳定、可靠地运行，并且能够满足《xxx产品需求说明书》中所涉及的APP端各类用户与产品需求。
    
   本测试计划的编写将会遵循以上的所有原则和标准，确保本次测试的全面性和高效性。

 

  好了，以上就是一个十分简单的测试计划模板了，当然里面的很多数据与标准是缺失的，这里还需要大家去根据各自公司的产品业务或测试要求去进行添加与润色。当然这篇文章中提到的优化测试计划的方法只是冰山一角，作为测试的我们还需要不断学习、总结、优化自己的测试经验，不断探索更好的方法来提高测试覆盖率，在项目中实现自己的岗位价值。祝愿每一位测试人都能够在不断努力中成长，让我们共同努力，为更美好的未来而奋斗！

如何提高接口自动化测试的有效性覆盖和案例有效性

敏捷项目管理和 DevOps 已经蔚然成风，然而让很多开发团队、测试团队以及团队管理者头疼的是：缺少有效的自动化测试手段，缺少对自动化测试质量的信心，让持续集成（CI）和持续部署（CD）流于形式。根据以往敏捷项目和 DevOps 实施过程积累的经验，我们把 CI/CD 过程中的自动化测试分为三层，它们是单元测试、接口测试和自动化验收测试（主要是业务场景验收）。

本 Chat 我们主要讨论如何提高接口自动化测试的测试质量，主要内容如下：

1. 如何选择接口测试的测试范围和评估测试范围对测试质量的影响
2. 如何设计高质量的接口测试案例
3. 如何形成团队/部门的接口实施流程和测试规范
4. 敏捷项目或 DevOps 中的接口测试的反馈流程与测试结果质量指标分析

GitChat:如何提高接口自动化测试的有效性覆盖和案例有效性

专业免费的  企业敏捷与DevOps技术与工具交流群

 

专业免费  企业敏捷与DevOps技术与工具公众号