江苏龙网

  1. 主页 > 生活百科 > >

如何制定测试计划 测试计划( 二 )


对于兼容性测试，Web测试需要确定覆盖的浏览器类型和版本，移动设备测试需要确定覆盖的设备类型和具体的iOS/Android版本 。
你可能会问，如何确定需要覆盖的移动设备类型以及iOS/Android的版本列表？其实这个问题并不难:如果是现有产品，通过大数据技术分析产品的历史数据，就可以得到前30%的移动设备和iOS/Android版本列表，所以兼容性测试只需要覆盖这部分 。如果是全新的产品，可以通过TalkingData之类的网站查看目前主流的移动设备，用大小分辨率、iOS/Android版本等信息确定测试范围 。
兼容性测试的实施往往是在功能测试的后期，也就是说，兼容性测试要等到功能基本稳定后才会开始 。
当然也有特例 。比如前端引入新的前端框架或组件库时，会在前期进行兼容性评估，确保不会引入后期无法解决的兼容性问题 。兼容性测试用例的选择通常来自已实现的自动化测试用例 。原因很简单，因为兼容性测试往往涵盖了最常用的业务场景，而这些最常用的业务场景通常是实现自动化测试的第一目标 。
因此，我们的GUI自动化框架需要能够支持同一套测试脚本在不同的浏览器中运行，而无需修改 。
三、性能测试
对于性能测试，需要在定义性能需求(并发用户数、响应时间、事务吞吐量等)的前提下，设计性能测试场景，确定性能测试框架 。)并结合被测系统的特点 。
例如，是否在API级别直接启动压力测试，或者是否模拟最终用户的行为来进行基于协议的压力测试 。再比如是基于模块进行压力测试还是发起全链路压力测试 。
如果表现的是后台数据敏感的场景，还需要确定后台数据的量级和分布，决定生成后台数据的技术方案，比如是通过API并发调用生成测试数据，还是直接对数据库进行批量插入和更新操作，或者两种方法的结合 。
最后，无论采用哪种方法，都需要指定要开发的单用户脚本数量，以便后期成功组装压力测试场景 。
性能测试的实现是一个复杂的问题 。首先，你需要根据你要解决的问题来确定性能测试的类型；然后根据具体的性能测试类型，进行测试 。
1.在性能测试的实现中，往往需要首先根据业务场景决定需要开发哪些单用户脚本 。脚本的开发会涉及到很多性能测试脚本特有的概念，比如思考时间、组装点、动态关联等等 。
2.脚本开发完成后，还需要按脚本单元组织测试场景 。场景的定义简单来说就是有百分之几的用户在登录，百分之几的用户在做查询，每个用户在操作步骤之间需要等待多长时间，并发用户的增长率是5秒一个还是5秒两个，等等 。
3.最后是具体的测试场景执行 。与自动化功能测试不同，性能测试完成后对性能测试报告的解释是整个测试过程中最关键的一点 。
如果你现在不知道我上面提到的一些概念也没关系 。我将在后续文章中为您详细解释它们 。
除了我给大家详细分析的最常用的功能测试、兼容性测试、性能测试之外，还有很多测试类型(例如，接口测试、集成测试、安全测试、容量验证、安装测试、故障恢复测试等 。).这些测试类型都有各自的应用场景和对应的独特测试方法，这里就不一一展开了 。如果你对这些考试类型有任何疑问，可以给我留言讨论 。
测试资源通常包括测试人员和测试环境，两者都是有限的 。测试的目的是确保用有限的资源获得最大的产出 。因此，测试资源需要明确“谁来测试”和“在哪里测试”这两个问题 。测试人员是最重要的，直接关系到整个测试项目的成败和效率 。测试人员的资源通常有两个维度:
第一，测试工程师的数量；第二，测试工程师的个人经验和能力 。
你会发现测试工程师的经验和能力不足，这几乎不是测试人员数量可以弥补的 。相反，当测试工程师的经验和能力非常强的时候，可以适当减少测试人员的数量 。
通常在一个测试团队中，既有高级测试工程师，也有初级测试工程师，所以你必须根据团队的实际情况来安排测试计划 。例如，困难的工作，或者一些新工具和方法的应用，或者自动化测试开发工作通常由高级测试工程师承担；那些相对机械、难度较低的工作都是初级工程师做的 。
由此可见，要想规划好测试资源，除了要了解项目本身，还必须明确控制测试团队的人员特征 。另外，我强烈建议你把具体任务明确落实到每个人，这样有助于建立明确的责任机制，避免以后可能出现的纠纷 。
与测试人员相比，测试环境更容易理解 。不同的项目可能使用一个共享的测试环境，一个专用的测试环境，或者甚至直接使用一个生产环境 。此外，对于一些已经在容器中部署和发布的项目，测试环境会变得更简单、更轻便 。这部分我会在后面的文章里给你详细解释 。


推荐阅读


上一篇：高考中的拉格朗日点之L1点和L2点 拉格朗日点

下一篇：叶卡捷琳娜二世对外战争胜率 叶卡捷琳娜二世