软件测试计划的制定通常是在需求分析以及测试需求分析完成后开始,并且是整个软件研发生命周期中的重要环节
如果没有测试计划,会带来哪些问题呢?
- 很难确切地知道具体的测试范围,以及应该采取的具体测试策略
- 很难预估具体的工作量和所需要的测试工程师数量,同时还会造成各个测试工程师的分工不明确,引发某些测试工作被重复执行而有些测试则被遗漏的问题
- 测试的整体进度完全不可控,甚至很难确切知道目前测试的完成情况,对于测试完成时间就更难预估准确的时间节点了
- 整个项目对潜在风险的抵抗能力很弱,很难应对需求的变更以及其他突发事件
一份好的测试计划要包括:测试范围、测试策略、测试资源、测试进度和测试风险预估,这五大方面,并且每一部分都要给出应对可能出现问题的解决办法
测试范围
测试范围描述的是被测对象以及主要的测试内容
测试范围的确定通常是在测试需求分析完成后进行,所以确定测试范围的过程在一定程度上也是对测试需求分析的进一步检验,这将有助于在早期阶段就发现潜在的测试遗漏
测试策略
根据轻重缓急排序,有限的资源优先重要的项目及功能点
测试策略还需要说明,采用什么样的测试类型和测试方法。 这里需要注意的是,不仅要给出为什么要选用这个测试类型,还要详细说明具体的实施方法
功能测试
对于功能测试,根据测试需求分析的思维导图来设计测试用例.
主线业务的功能测试由于经常需要执行回归测试,所以你需要考虑实施自动化测试,并且根据项目技术栈和测试团队成员的习惯与能力来选择合适的自动化测试框架.
应该先实现主干业务流程的测试自动化。 实际操作时,你通常需要先列出主要的功能测试点,并决定哪些测试点适合采用自动化测试,并且决定具体使用什么样的框架和技术。 对于需要手工测试的测试点,你要决定采用什么类型的测试用例设计方法,以及如何准备相关的测试数据
另外,你还要评估被测软件的可测试性,如果有可测试性的问题,需要提前考虑切实可行的变通方案,开发可测试性的接口
兼容性测试
兼容性测试的实施,往往是在功能测试的后期,也就是说需要等功能基本都稳定了,才会开始兼容性测试
当然也有特例,比如,对于前端引入了新的前端框架或者组件库,往往就会先在前期做兼容性评估,以确保不会引入后期无法解决的兼容性问题
性能测试
在明确了性能需求(并发用户数、响应时间、事务吞吐量等)的前提下,结合被测系统的特点,设计性能测试场景并确定性能测试框架
比如,是直接在API级别发起压力测试,还是必须模拟终端用户行为进行基于协议的压力测试。再比如,是基于模块进行压力测试,还是发起全链路压测。
如果性能是背景数据敏感的场景,还需要确定背景数据量级与分布,并决定产生背景数据的技术方案,比如是通过API并发调用来产生测试数据,还是直接在数据库上做批 量insert和update操作,或者是两种方式的结合。
最后,无论采用哪种方式,都需要明确待开发的单用户脚本的数量,以便后续能够顺利组装压测测试场景。
性能测试的实施,是一个比较复杂的问题。首先,需要根据你想要解决的问题,确定性能测试的类型;然后,根据具体的性能测试类型开展测试。
- 性能测试的实施,往往先要根据业务场景来决定需要开发哪些单用户脚本,脚本的开发会涉及到很多性能测试脚本特有的概念,比如思考时间、集合点、动态关联等等。
- 脚本开发完成后,你还要以脚本为单位组织测试场景(Scenario),场景定义简单来说就是百分之多少的用户在做登录、百分之多少的用户在做查询、每个用户的操作步骤之间
需要等待多少时间、并发用户的增速是5秒一个,还是5秒2个等等。 - 最后,才是具体的测试场景执行。和自动化功能测试不同,性能测试执行完成后性能测试报告的解读,是整个测试过程中最关键的点
测试资源
测试资源通常包括测试人员和测试环境,这两类资源都是有限的。
测试计划的目的就是,保证在有限资源下的产出最大化。所以,测试资源就是需要明确“谁来测”和“在哪里测”这两个问题。
测试人员是最重要的,直接关系到整个测试项目的成败和效率。测试人员的资源通常有两个维度:
- 测试工程师的数量
- 测试工程师的个人经验和能力
你会发现,测试工程师的经验和能力不足,很难通过测试人员的数量来弥补。相反地,测试工程师的经验和能力都非常强的情况下,测试人员的数量可以适当地减少。
通常在测试团队中,测试工程师既有资深,也会有初级,那么你就必须针对团队的实际情况去安排测试计划。比如,难度较大的工作,或者一些新工具、新方法的应用,又或者自动 化测试开发工作,通常由资深的测试工程师来承担;而那些相对机械性、难度较小的工作,则由初级工程师完成。
可见,你要想规划好测试资源,除了要了解项目本身外,还必须对测试团队的人员特点有清晰的把控。
相对于测试人员,测试环境就比较好理解了。不同的项目,可能会使用共享的测试环境,也可能使用专用的测试环境,甚至还会直接使用生产环境。
对于目前一些已经实现容 器化部署与发布的项目,测试环境就会变得更简单与轻量级
测试进度
测试进度主要描述各类测试的开始时间,所需工作量,预计完成时间,并以此为依据来建议最终产品的上线 发布时间
测试风险预估
很少有整个测试过程是完全按照原本测试计划执行的。通常需求变更、开发延期、发现重大缺陷和人员变动是引入项目测试风 险的主要原因
对于需求变更,比如增加需求、删减需求、修改需求等,一定要重新进行测试需求分析,确定变更后的测试范围和资源评估,并与项目经理和产品经理及时沟通因此引起的测试进度 变化
在制定测试计划时,你就要预估整个测试过程中可能存在的潜在风险,以及当这些风险发生时的应对策略
文章链接 https://fangzongzhou.github.io/2020/12/31/计算机/软件测试/测试计划/