关于测试策略,测试方针,测试计划,测试方案的理解

一.什么是测试策略

 简单来说就是,测什么,怎么测。

一般可以归纳为6个问题

  1)测试的对象和范围是什么?

  2)测试的目标是什么?

  3)测试的深度到哪里,广度又到哪里?

  4)测试的重点有什么?难点又有什么?

  5)如何安排测试活动

  6)如何评价,评审测试是否有效?

二.什么是测试方针

  测试方针可以理解为测试活动中的一些通用的要求,原则。

  如:1)产品的缺陷修复率要达到90%以上才能发布。

    2)开发提交版本前,必须要先自测,比产出测试报告。

    3)对发布的版本,无论代码修改了多少,都要对基本功能进行回归测试。

    4)产品升级后,发型原有功能丢失或失效的,这类缺陷都定义为严重。

三.什么是测试计划

  可以这样理解:通过测试策略确定的测试活动,而这些测试活动都在测试计划中被拆分为一个个任务。并且每个任务都确定工期,执行的先后顺序和责任人。

  如图所示

  测试策略        测试计划               测试资源

                              测试计划实例

任务名称       责任人             任务起止时间   优先级

测试任务1

           张三                              2018/8/5至2018/8/7        高

测试任务2

           李四                              2018/8/8至2018/8/10        中

测试任务3

           王五                              2018/8/11至2018/8/13        低

四.什么是测试方案

  测试方案主要是解决功能特性在测试执行方面的问题。

  要注意,测试策略要解决的是软件测试中的六大问题(一.测试策略中有说到),而这里测试方案则是解决对功能特性如何进行测试,以及如何安排这种测试的执行。

  具体包括:

    1)对功能特性的需求,场景,设计进行分析,提取出测试点

    2)对测试点选择合适的测试设计方法(如,等价类设计法,边界值设计法,场景流法,错误探测法,如何选择测试数据)

    3)是否需要进行性能测试或自动化测试,若有,则进行相关的设计,如提取性能需求,部署环境等等。

    4)测试执行时需要按照怎么的顺序来执行这些用例。

  举例如下:



1.测试方案模板(以一个功能特性为单位):

  1.xxx特性的场景

    a)用户场景描述:

       描述用户会如何使用这个功能特性。

    b)测试场景描述:

       描述测试时会怎么模拟用户的使用,模拟和实际差别在哪里,是否会有风险。等等。

  2.xxx特性设计分析:

    a)产品实现中的关键业务流程。

    b)重要的算法(或实现技术)的分析

    c)其他需要主要的内容分析。

   3.xxx特性测试分析:

    a)测试类型分析

    b)功能交换分析。

  4.xxx特性测试设计:

    对测试点选择合适的测试设计方法,并得出测试用例

    为测试用例划分优先级

  5.xxx特性测试执行:

    那些用例需要进行手工测试。

    那些用例需要进行自动化测试。

    那些用例需要进行性能测试。

    测试用例是否需要考虑执行的顺序。

    是否还有些地方可以进行探索测试。



2.测试方案需要遵循的测试策略

  例如,该测试方案中的某些特性 需要遵循 测试策略中的测试深度和广度的要求。

特性  测试优先级(测试重点)  测试说明(测试深度和广度)
特性A  高
1.需要进行全面,深入的功能测试

2.需要考虑各种测试类型,尤其是可靠性方面的测试

特性B  低  只需要进行基本功能验证测试即可

  软件测试与产品的六大特性

产品  可靠性  可靠性测试  异常值测试
       故障植入测试
       稳定性测试
       恢复测试
       
        功能性    功能测试  运行正确值输入
       运行边界值输入
       等价类测试法
       场景测试
       
   效率  性能测试  压力测试
       负载测试
       对指定的性能指标进行测试
       
   可维护性  可维护性测试  检查产品是否可维护
       升级测试,更新测试
       下载链接测试,是否下载到最新版本
       
   兼容性  兼容性测试
平台测试

(检查产品是否能在各个平台运行,如app测试中,能运行在什么类型的手机)

       操作系统适应性测试,检查产品能运行在什么操作系统上
       
   易用性  易用性测试  产品是否提供教程
       产品中的功能控件是否简洁易用,不复杂
     
产品中的下拉弹出窗口最多三层,如txt记事本,里面有一个【文件】按钮,点击

后会弹出第一层下拉窗口,然后在点击其中的【另存为】就会弹出第二层窗口,选

择地址,点击保存后就存储成功。整个操作最多展开了两层。

对于特性A,因为要进行全面测试,那我们需要覆盖六大特性中的所有内容

  对于特性B,因为只需要基本功能验证,所以我们可以选择功能测试中的内容。

原文地址:https://www.cnblogs.com/chenwjia/p/10125495.html

时间: 2024-07-31 21:41:22

关于测试策略,测试方针,测试计划,测试方案的理解的相关文章

Monkey测试策略教程-android,Monkey测试【转】

Monkey的测试策略,Monkey测试2 一. 分类 Monkey测试针对不同的对象和不同的目的采用不同的测试方案,首先测试的对象.目的及类型如下: 测试的类型分为:应用程序的稳定性测试和压力测试 测试对象分为:单一apk和apk集合 测试的目的分为:解决问题的测试(忽略异常的测试)和验收测试(不忽略异常的测试) 二. 应用程序的稳定性测试: 1. 针对单个apk (1) 不忽略异常 在进行单个apk的验收测试时,则使用单一apk且不忽略异常的命令执行. 例如:monkey -p com.an

转:google测试分享-分层测试

原文: http://blog.sina.com.cn/s/blog_6cf812be0102vctg.html 上一次分享了google测试分享-SET和TE,有一些自动化测试的细节没有说清楚,那这次会把google的分层自动化测试描述的更详细. 为了让这些blog分享更有逻辑性,我打算分几个专题来分享google测试相关的测试理念. google测试分享-SET和TE google测试分享-分层测试 google测试分享-GTA google测试分享-测试经理 google测试分享-问题和挑

学习使用Jmeter做压力测试(一)--压力测试基本概念

一.性能测试的概念 性能测试是通过自动化的测试工具模拟多种正常峰值及异常负载条件来对系统的各项性能指标进行测试.负载测试和压力测试都属于性能测试,两者可以结合进行. 通过负载测试,确定在各种工作负载下系统的性能,目标是当负载逐渐增加时,测试系统各项性能指标的变化情况.压力测试时通过确定一个系统的瓶颈或者不能接受的 性能点,来获取系统能提供的最大服务级别的测试.性能测试主要包括负载测试.强度测试.容量测试. 二.性能测试的指标 web服务器: Avg Rps: 平均每秒的响应次数 = 总请求数 /

测试负责人和测试工程师在日常工作有什么不同

作为负责人,要考虑的事情比较多,要从大局观.整体项目周期上看待问题.而测试工程师平时只要做好分配的任务就行,不需要考虑太多事情.以下是从项目各个阶段来描述作为测试负责人应该要做的工作. 一.需求阶段 要参与需求评审,了解以后要做的项目,做到心里有数 熟悉需求,并组织测试人员分析需求,把需求疑问整理文档,与产品人员讨论. 二.开发阶段 了解开发进度,主动与项目经理沟通,询问近期要提测的项目,做好测试准备工作. 如果提测有并行且人力有限的情况下,划分好优先级和重要性,根据优先级.重要性由高到低开始,

需求分析与测试计划、方案

需求分析 参与人员:软件项目组所有成员,包括产品经理,开发经理,测试经理,系统工程师/架构师,开发工程师/程序员,美术工程师,测试工程师,项目经理,QA(质量监督人员),配置管理员. 测试需求的特征: 1.测试需求项必须是可核实的; 2.指明满足需求的正常的前置条件,同时也要指明不满足需求时的出错条件; 3.测试需求不涉及具体的数据. 需求分析评审: 1.※完整性:每项需求都必须将所要实现的功能描述清楚 2.※正确性:每项需求都必须准确地陈述其要开发的功能 3.可行性:每项需求都能通过设计测试用

【测试基础】测试产出的文档“们”

测试计划方案文档 通常情况下,测试计划和测试方案可合为一个文档 文档说明: 包含文档目的和读者对象 文档目的:编写文档的目的.文档时用到的约定和文档的编排方式 读者对象:包括部门经理/高级经理.项目经理.项目组.测试人员.配置管理员及其他相关人员 术语与参考: 包含参考资料与术语解释 参考资料:填写本文档时使用的参考资料,如详细设计文档.开发文档等 术语解释:解释测试人员使用的专业术语,如集成测试.冒烟测试的含义等 测试计划概述: 包含测试系统概述.测试目标.测试方法.测试里程碑.测试系统发布及

程序员自己写测试,还要测试人员做什么?

在向开发人员介绍单元测试或TDD等工程实践时,往往可以听到这样的疑问.比如: 自己写的程序,自己无法从另一个角度测出问题.写bug的时间都不够了,哪有时间来写测试?开发来写测试了,测试干什么?除了核心代码,没有什么值得测试的.-- 一个例子首先我们看一个例子. 全项目唯一的测试 不止一次,我在各种项目中看到这样的测试,往往这也是整个工程中唯一一个测试.可以看出,开发者认为编写是有必要的.所以按照"标准"的做法建立了测试目录,引入JUnit依赖.并且利用它在开发的初期来验证某些技术疑问,

入门级----黑盒测试、白盒测试、手工测试、自动化测试、探索性测试、单元测试、性能测试、数据库性能、压力测试、安全性测试、SQL注入、缓冲区溢出、环境测试

黑盒测试 黑盒测试把产品软件当成是一个黑箱子,只有出口和入口,测试过程中只要知道往黑盒中输入什么东西,知道黑盒会出来什么结果就可以了,不需要了解黑箱子里面是如果做的. 即测试人员不用费神去理解软件里面的具体构成和原理,只要像用户一样看待产品就可以了. 例如银行转账功能,不需要知道转账的具体实现代码是怎样工作的,只需要把自己想象成各种类型的用户,模拟多种转账情况看系统是否能正常转账即可. 但是仅仅像用户一样去测试又是不够的.如果只做黑盒测试,必然是存在一定的风险的. 例如某个安全性较高的软件系统,

alpha测试和beta测试的区别是什么?

Beta测试是用户公司组织各方面的典型终端用户在日常工作中实际使用beta版本,并要求用户报告异常情况,提出批评意见. 区别:两者的主要区别是测试的场所不同.Alpha测试是指把用户请到开发方的场所来测试,beta测试是指在一个或多个用户的场所进行的测试.         Alpha测试的环境是受开发方控制的,用户的数量相对比较少,时间比较集中.而beta测试的环境是不受开发方控制的,谁也不知道用户如何折磨软件,用户数量相对比较多,时间不集中.一般地,alpha测试先于beta测试执行.通用的软