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