锐客网

  1. 首页 > 睿知 > >

如何制定测试计划 测试计划

睿知生活知识

测试计划(如何制定测试计划)
软件项目通常有详细的项目计划 。
软件测试作为整个项目的重要组成部分，也应该进行详细的测试计划 。所谓运筹帷幄，决胜千里，强调的是提前谋划的重要性和必要性 。
在软件工程的早期实践中，软件测试计划的制定通常在需求分析和测试需求分析完成后开始，是整个软件开发生命周期中的重要环节 。然而，在敏捷开发模式下，你可能会有疑问，软件测试计划仍然那么重要吗？我的软件项目根本没有正式的测试计划 。没有什么大问题吗？
的确，对于很多非产品互联网公司来说，由于采用敏捷开发模式，确实很少做传统意义上的测试计划，但这并不意味着他们不再做测试计划 。
但是测试计划的形式已经不再是传统意义上的庞大而正式的测试计划文档，更多的是体现在每个冲刺阶段的计划环节，这样的短期测试计划可以根据项目情况非常快速实时的调整 。
所以测试计划还是存在的，只是取代了原来的一次性集中测试计划，变成了一个迭代的、持续的测试计划 。但是对于传统的软件公司，或者制作非互联网软件产品的公司，他们通常会有一个非常正式的软件测试计划 。
可见无论是前期最典型的瀑布式开发模式，还是现在的敏捷开发模式，测试计划的重要性都没有改变 。那么，你可能会问，测试计划的重要性是什么？在回答这个问题之前，我先跟大家说一下，如果没有测试计划会造成什么问题 。
没有测试计划会怎么样？如果没有测试计划，会带来什么问题？
1.很难确切知道具体的测试范围和应该采取的具体测试策略；
2.具体工作量和所需测试工程师数量难以估算，同时各测试工程师分工不明确，导致部分测试重复进行，部分测试遗漏的问题；
3.测试的整体进度完全失控，甚至很难确切知道当前测试的完成情况，更难以预测测试完成时间的确切时间节点 。4.整个项目抗潜在风险能力弱，难以应对需求变化等突发事件 。
从这些问题中，你可以推导出，一个好的测试计划应该包括测试范围、测试策略、测试资源、测试进度和测试风险估计五个方面，每个部分都要针对可能出现的问题给出解决方案 。
测试范围，顾名思义，描述了被测试的对象和主要的测试内容 。
比如对于用户登录模块，功能测试需要同时测试浏览器端和移动端，同时还要考虑与登录安全和并发性能相关的非功能性需求的测试 。
测试范围的确定通常是在测试需求分析完成之后进行的，因此确定测试范围的过程在一定程度上也是对测试需求分析的进一步测试，这将有助于在前期发现潜在的测试遗漏 。
同时，由于不可能进行穷举测试，测试时间和资源有限，所以必须做出一些取舍，进行有针对性的测试 。因此，需要在测试范围中定义“测量什么”和“不测量什么” 。
关于测试策略这个话题，简单来说，测试策略需要明确两个问题:“先测试什么”和“如何测试” 。
疾病有轻重缓急，检测也是 。重要的项目先测试，不重要的项目后测试 。测试策略将要求我们指定测试的关键点和每个测试的顺序 。
比如，就用户登录模块而言，“用户无法正常登录”和“用户无法重置密码”这两个潜在的问题一目了然，所以你应该先测试“用户正常登录”，再根据优先级测试“用户重置密码” 。
测试策略还需要说明采用什么样的测试类型和测试方法 。这里需要注意的是，不仅要给出为什么要选择这种测试类型的原因，还要详细说明具体的实现方法 。
首先，功能测试
对于功能测试，你应该根据测试需求分析的思维导图来设计测试用例 。
由于主线的功能测试往往需要回归测试，你需要考虑实现自动化测试，根据项目技术栈和测试团队成员的习惯和能力选择合适的自动化测试框架 。
这里需要注意的是，你通常应该先实现主干业务流程的测试自动化 。
在实践中，你通常需要先列出主要的功能测试点，决定哪些测试点适合自动化测试，决定使用什么样的框架和技术 。
对于需要手工测试的测试点，你要决定采用什么类型的测试用例设计方法，以及如何准备相关的测试数据 。此外，你必须评估被测试软件的可测试性 。如果存在可测性问题，需要提前考虑可行的变通方法，甚至要求开发者提供可测性接口 。
第二，兼容性测试 。
对于兼容性测试，Web测试需要确定覆盖的浏览器类型和版本，移动设备测试需要确定覆盖的设备类型和具体的iOS/Android版本 。
你可能会问，如何确定需要覆盖的移动设备类型以及iOS/Android的版本列表？其实这个问题并不难:如果是现有产品，通过大数据技术分析产品的历史数据，就可以得到前30%的移动设备和iOS/Android版本列表，所以兼容性测试只需要覆盖这部分 。如果是全新的产品，可以通过TalkingData之类的网站查看目前主流的移动设备，用大小分辨率、iOS/Android版本等信息确定测试范围 。
兼容性测试的实施往往是在功能测试的后期，也就是说，兼容性测试要等到功能基本稳定后才会开始 。
当然也有特例 。比如前端引入新的前端框架或组件库时，会在前期进行兼容性评估，确保不会引入后期无法解决的兼容性问题 。兼容性测试用例的选择通常来自已实现的自动化测试用例 。原因很简单，因为兼容性测试往往涵盖了最常用的业务场景，而这些最常用的业务场景通常是实现自动化测试的第一目标 。
因此，我们的GUI自动化框架需要能够支持同一套测试脚本在不同的浏览器中运行，而无需修改 。
三、性能测试
对于性能测试，需要在定义性能需求(并发用户数、响应时间、事务吞吐量等)的前提下，设计性能测试场景，确定性能测试框架 。)并结合被测系统的特点 。
例如，是否在API级别直接启动压力测试，或者是否模拟最终用户的行为来进行基于协议的压力测试 。再比如是基于模块进行压力测试还是发起全链路压力测试 。
如果表现的是后台数据敏感的场景，还需要确定后台数据的量级和分布，决定生成后台数据的技术方案，比如是通过API并发调用生成测试数据，还是直接对数据库进行批量插入和更新操作，或者两种方法的结合 。
最后，无论采用哪种方法，都需要指定要开发的单用户脚本数量，以便后期成功组装压力测试场景 。
性能测试的实现是一个复杂的问题 。首先，你需要根据你要解决的问题来确定性能测试的类型；然后根据具体的性能测试类型，进行测试 。
1.在性能测试的实现中，往往需要首先根据业务场景决定需要开发哪些单用户脚本 。脚本的开发会涉及到很多性能测试脚本特有的概念，比如思考时间、组装点、动态关联等等 。
2.脚本开发完成后，还需要按脚本单元组织测试场景 。场景的定义简单来说就是有百分之几的用户在登录，百分之几的用户在做查询，每个用户在操作步骤之间需要等待多长时间，并发用户的增长率是5秒一个还是5秒两个，等等 。
3.最后是具体的测试场景执行 。与自动化功能测试不同，性能测试完成后对性能测试报告的解释是整个测试过程中最关键的一点 。
如果你现在不知道我上面提到的一些概念也没关系 。我将在后续文章中为您详细解释它们 。
除了我给大家详细分析的最常用的功能测试、兼容性测试、性能测试之外，还有很多测试类型(例如，接口测试、集成测试、安全测试、容量验证、安装测试、故障恢复测试等 。).这些测试类型都有各自的应用场景和对应的独特测试方法，这里就不一一展开了 。如果你对这些考试类型有任何疑问，可以给我留言讨论 。
测试资源通常包括测试人员和测试环境，两者都是有限的 。测试的目的是确保用有限的资源获得最大的产出 。因此，测试资源需要明确“谁来测试”和“在哪里测试”这两个问题 。测试人员是最重要的，直接关系到整个测试项目的成败和效率 。测试人员的资源通常有两个维度:
第一，测试工程师的数量；第二，测试工程师的个人经验和能力 。
你会发现测试工程师的经验和能力不足，这几乎不是测试人员数量可以弥补的 。相反，当测试工程师的经验和能力非常强的时候，可以适当减少测试人员的数量 。
通常在一个测试团队中，既有高级测试工程师，也有初级测试工程师，所以你必须根据团队的实际情况来安排测试计划 。例如，困难的工作，或者一些新工具和方法的应用，或者自动化测试开发工作通常由高级测试工程师承担；那些相对机械、难度较低的工作都是初级工程师做的 。
由此可见，要想规划好测试资源，除了要了解项目本身，还必须明确控制测试团队的人员特征 。另外，我强烈建议你把具体任务明确落实到每个人，这样有助于建立明确的责任机制，避免以后可能出现的纠纷 。
与测试人员相比，测试环境更容易理解 。不同的项目可能使用一个共享的测试环境，一个专用的测试环境，或者甚至直接使用一个生产环境 。此外，对于一些已经在容器中部署和发布的项目，测试环境会变得更简单、更轻便 。这部分我会在后面的文章里给你详细解释 。
测试进度，在定义了测试范围、测试策略、测试资源之后，就要考虑具体的测试进度了 。
测试进度主要描述各项测试的开始时间、所需工作量和预计完成时间，并以此为基础建议最终产品的上线时间 。比如构建验收测试的工作量、冒烟测试的工作量、自动化脚本开发的工作量、缺陷修复的验证工作量、多轮回归测试的工作量、每轮回归测试的工作量等 。
在传统的瀑布模型中，测试进度完全取决于开发完成和提交测试版本的时间 。如果延迟了测试版本的开发和提交，在不削减测试需求的情况下，产品的整体上线时间也会延迟 。
但是在敏捷模式下，测试活动贯穿整个开发过程，大量的测试工作会与开发工作同时进行 。比如采用行为驱动的开发模式，这样测试进度就不会完全依赖于开发提交可测试版本的时间 。
行为驱动开发通常被称为BDD，即非程序员可读的测试用例可以用自然语言编写，基于自然语言的步骤描述可以通过StepDef与具体的业务操作关联起来 。最典型的框架被命名为“黄瓜” 。
风险估计，俗话说计划赶不上变化，测试也是如此 。整个测试过程很少有完全按照原测试计划进行的 。
通常，需求变更、开发延迟、发现重大缺陷和人员变动是引入项目测试风险的主要原因 。
对于需求变更，如增加需求、删除需求、修改需求等 。，需要重新分析测试需求，确定变化后的测试范围和资源评估，并及时与项目经理和产品经理沟通测试进度的变化 。测试经理/测试负责人千万不要有咬着牙的想法，否则对测试团队或产品本身都没有好处 。
另外，随着测试的发展，你可能会发现前期对测试工作量的估算不够准确，你也可能会发现需要增加更多类型的测试 。您可能还会发现，由于要修改的测试架构的严重缺陷，许多测试需要完全回归，可能会出现延迟提交测试版本进行开发，或者人员变更等各种情况 。
所以在制定测试计划时，你要预估整个测试过程中可能存在的潜在风险，以及这些风险发生时的应对策略 。那么，当你真的遇到类似的问题时，你就可以冷静而有条不紊地应对这些挑战 。
摘要
软件测试和软件项目一样，需要一个详细的测试计划 。虽然在敏捷开发模式下，软件测试不再局限于厚厚的正式的计划文档，但是测试计划的重要性丝毫没有改变 。
【如何制定测试计划 测试计划】一个成功的测试计划必须清晰地描述五个最重要的方面:测试范围、测试策略、测试资源、测试进度和测试风险估计 。测试范围需要明确“测什么”和“不测什么”；测试策略需要明确“先测试什么”和“如何测试”；测试资源需要明确“谁来测试”和“在哪里测试”；测试进度是需要指定各项测试的开始时间、所需工作量和预计完成时间；风险评估是需要知道如何有效应对各种潜在的变化 。

    推荐阅读


    上一篇：cdr图形如何画心 cdr绘制一箭穿心图形的具体操作

    下一篇：菠萝模型制作 ug创建菠萝模型的操作教程