软件测试52讲 读书笔记 如何做好测试计划

作者: 小菠萝测试笔记
测试基础

测试计划的好处

  • 知道确切的测试范围，采取怎么样的测试策略
  • 预估具体的工作量和测试资源，每个人分工明确，不容易出现重复测试的情况
  • 测试进度是可控的，实时知道目前测试完成情况
  • 可以提前识别潜在风险，当需求发生变化时，们需要做出响应

测试计划

测试范围

包含：被测对象，主要的测试内容

确定测试范围一般在测试需求分析完成后进行，所以确定测试范围的过程在一定程度上也是对测试需求分析的进一步检验，有助于在早期阶段发现潜在的测试遗漏；

由于测试时间和成本有限，必须进行针对性的测试，因此测试范围中要明确 测什么 和 不测什么 。

测试策略

测试策略就是要明确 先测什么后测什么 和 如何来测 ，明确测试的重点，以及各项测试的先后顺序； 比如：对 用户登录模块 来讲，“用户无法正常登录"和"用户无法重置密码"这两个潜在问题重要性并不高，所以应该按优先级来先测"用户正常登录”

测试策略还要说明，采用什么样的 测试类型 和 测试方法 ，不仅要给出为什么要选用这个测试类型，还要详细说明具体的实施方法。 第一：功能测试

  • 对于功能测试，应该根据测试需求分析的思维导图来设计测试用例
  • 另外，还要评估被测软件的可测性，如果有可测性的问题，需要提前考虑切实可行的变通方案，要求开发人员提供可测性的接口 第二：兼容性测试
  • Web 测试需要确定覆盖的浏览器类型和版本，移动设备测试需要确定覆盖的设备类型和具体 iOS/Android 的版本
  • 兼容性测试的实施，往往是在功能测试的后期，也就是说需要等功能基本都稳定了，才会开始兼容性测试
  • 当前端引入新的前端框架或者组件库时，往往会在前期做兼容性评估，确保不会引入后期无法解决的兼容性问题 第三：性能测试

前期，明确性能需求（ 并发用户数 、 响应时间 、 事务吞吐量 ），结合被测系统的特点，设计性能测试场景并确定性能测试框架 比如：

  • 是直接在API级别发起压力测试，还是必须模拟终端用户行为进行基于协议的压力测试；
  • 是基于模块进行压力测试，还是发起全链路压测

如果性能是背景数据敏感的场景，还需要确定背景数据量级与分布，并决定产生背景数据的技术方案，比如是通过 API 并发调用来产生测试数据，还是直接在数据库上做批量 insert 和 update 操作，或者是两种方式的结合。

最后，无论采用哪种方式，都需要明确待开发的单用户脚本的数量，以便后续能够顺利组装压测测试场景。 关于性能测试的实施 ，首先，需要根据你想要解决的问题，确定性能测试的类型，然后，根据具体的性能测下类型开展测试。 性能测试实施相关

  1. 性能测试的实施，往往先要根据业务场景来决定需要开发哪些单用户脚本，脚本的开发会涉及到很多性能测试脚本特有的概念，比如思考时间、集合点、动态关联等等。
  2. 脚本开发完成后，你还要以脚本为单位组织测试场景（Scenario），场景定义简单来说就是百分之多少的用户在做登录、百分之多少的用户在做查询、每个用户的操作步骤之间需要等待多少时间、并发用户的增速是 5 秒一个，还是 5 秒 2 个等等。
  3. 最后，才是具体的测试场景执行。和自动化功能测试不同，性能测试执行完成后性能测试报告的解读，是整个测试过程中最关键的点。 还有很多测试类型 比如：接口测试、集成测试、安全测试、容量验证、安装测试、故障恢复测试

测试资源

包含：测试人员和测试环境

测试资源需要明确 谁来测 和 在哪里测

测试进度

主要描述：各类测试的开始时间，所需工作量，预计完成时间，并以此为依据来建议最终产品的上线发布时间

在传统瀑布模型中：测试进度完全依赖于开发完成并递交测试版本的时间。如果开发提交测试版本发生了延误，那么在不裁剪测试需求的情况下，产品整体的上线时间就同样会延期。

然而在敏捷模式中：测试活动贯穿于整个开发过程，很多测试工作会和开发工作同步进行，比如采用行为驱动开发（Behavior-Driven Development）模式，这样测试进度就不会完全依赖于开发递交可测试版本的时间。

行为驱动开发：就是平时们经常说的 BDD，指的是可以通过自然语言书写非程序员可读的测试用例

测试风险预估

对于需求变更，如增加需求、删减需求、修改需求，一定要重新进行测试需求分析，确定变更后的测试范围和资源评估，并与项目经理和产品经理及时沟通因此引起的测试进度变化 测试过程中，可能会发生以下情况

  1. 测试工作量评估不准确
  2. 需要增加额外的测试类型
  3. 修复某些严重缺陷，导致需要全量回归
  4. 送测延期
  5. 人员变动

所以，在制定测试计划时，就要预估整个测试过程中可能存在的潜在风险，以及风险发生时的应对策略。

原文创作：小菠萝测试笔记

原文链接：https://www.cnblogs.com/poloyy/p/12198900.html

文章列表

更多推荐

更多
  • Java测试驱动开发-十二、通过实现连续交付利用 TDD 案例研究可怕的赌博公司，探索代码库，释放程序，部署到生产环境，增加测试覆盖率，结论，可能的改进，实施持续集成，走向持续交付，詹金斯装置，自动化构建，第一次执行，下一步是什么？，这仅仅是开始，这不一定是结束， “没有什么比结果更能说
    Java开发者

    测试驱动 Java测试

  • Java测试驱动开发-一、为什么我应该关心测试驱动的开发？ 为什么是 TDD？，理解 TDD，红绿重构，速度是关键，这与测试无关，测试，黑盒测试，白盒试验，质量检查和质量保证之间的区别，更好的测试，嘲笑，可执行文件，无调试， 这本书是由开发人员为开发人员编写的。因此，大部分学习将通过代码进
    Java开发者

    测试驱动 Java测试

  • Java测试驱动开发-十一、把它们放在一起 简而言之，TDD，最佳做法，命名约定，过程，开发实践，工具， “如果你总是做你一直做的事，那么你将永远得到你一直得到的。”——阿尔伯特·爱因斯坦我们经历了大量的理论和更多的实践。整个旅程就像一列高速行驶的火车，我们几乎没有
    Java开发者

    测试驱动 Java测试

  • Java测试驱动开发-零、前言 这本书是给谁的，充分利用这本书，下载示例代码文件，下载彩色图像，使用的惯例， 测试驱动开发已经有一段时间了，很多人还没有采用它。这背后的原因是 TDD 很难掌握。尽管这个理论很容易掌握，但要真正精通它需要大量的实践。本书的作者多年
    Java开发者

    测试驱动 Java测试

  • Java测试驱动开发-四、单元测试—关注你做了什么，而不是已经做了什么 单元测试什么是单元测试？，为什么要进行单元测试？，代码重构，为什么不专门使用单元测试呢？，用 TDD 进行单元测试，TestNG，TestNG 与 JUnit 摘要，遥控船舶要求，遥控船舶的研制，项目设置，助手类，需求–起点和方向，规格
    Java开发者

    测试驱动 Java测试

  • Java测试驱动开发-五、设计—如果它不可测试，那么它就设计得不好 我们为什么要关心设计？，设计原则，你不会需要它的，不要重复你自己，保持简单和直接，奥卡姆剃刀，坚实的原则，连接 4，要求，测试 Connect 4 的最后一个实现，要求 1–游戏的棋盘，要求 2–介绍光盘，要求 3–球员轮换，要求 4–
    Java开发者

    测试驱动 Java测试

  • Java测试驱动开发-二、工具、框架和环境 吉特，虚拟机，Vagrant，Docker，构建工具，综合发展环境，创意演示项目，单元测试框架，朱尼特，TestNG，Hamcrest 和 AssertJ，汉克雷斯特，资产，代码覆盖工具，杰科科，模拟框架，Mockito，轻松的，模拟的
    Java开发者

    测试驱动 Java测试

  • Java测试驱动开发-六、模拟—删除外部依赖项 嘲笑，为什么嘲笑？，术语，模拟对象，Mockito，Tic Tac Toe v2 要求，开发 TicTacToe v2，要求 1–门店移动，规范–数据库名称，实施，规范–Mongo 集合的名称，实施，重构，规范–将项目添加到 Mongo
    Java开发者

    测试驱动 Java测试

  • Java测试驱动开发-九、重构遗留代码—使其再次年轻 遗留代码，遗留代码示例，识别遗留代码的其他方法，遗留代码更改算法，应用遗留代码更改算法，确定变化点，寻找测试点，打破依赖关系，写作测试，卡塔演习，卡塔遗产酒店，描述，技术意见，添加新功能，黑盒或峰值测试，初步调查，如何找到重构的候选对象
    Java开发者

    测试驱动 Java测试

  • Java测试驱动开发-八、BDD—与整个团队合作 不同规格，文档，编码员的文档，非编码人员的文档，行为驱动开发，叙述，情节，书店 BDD 故事，杰伯哈夫，JBehave 转轮，未决步骤，Selenium 和 Selenide，JBehave 步骤，最终验证， “我不是一个优秀的程
    Java开发者

    测试驱动 Java测试

    • 小菠萝测试笔记

    314
    文章数
    1066
    获赞数
    1024
    粉丝数
    测试基础

    近期文章

    更多
    文章目录

      热门标签

      更多

      推荐作者

      更多