合格的测试计划是怎样诞生的?

TestBird官方技术博客 发布于 2016/09/07 10:49
阅读 114
收藏 1


 

不论是刚毕业的Tester还是测试老鸟,是否想过“测试计划”怎么写?以前写的测试计划“合格”吗?我想很多人无法给出答案。

做测试计划通常是一件非常复杂的事情,一个理想的测试计划要完成“投资回报分析”和“风险分析”,在软件开发的众多因素中寻求一个最优解:

· 实现投入: 实现“可测试性”和某些场景的自动化测试,需要花费大量的时间,还会增加软件复杂度。会增加短期内的研发投入。

· 维护投入: 不论是自动化测试还是手工测试,都会不同程度地增加长期投入。

· 财务投入: 有些测试可能会需要资金投入。

· 回报: 测试能够减少软件bug,并在不同程度上提升生产力。在软件研发过程中,越早发现问题,带来的收益越大。

· 风险: 无法预测什么时候会碰到出问题的场景,而一旦出问题,带来的后果也无法预测:可能只是对用户体验有少许影响,也可能是一场灾难。

要有效的平衡以上因素,需要评估项目的具体情况:如何实现的?资源是否可用?团队是什么意见?尽管许多项目能够做到“低投入,高回报”的高覆盖率单元测试,但是他们也需要衡量“larger tests”和更复杂的场景。关键性的项目必须尽可能的降低风险,为了覆盖所有的测试层级,可能会做出一个高投入的测试决策。

本文将围绕“如何找到项目中的平衡点”展开。因为模板往往不具备通用性,而且很容易“过时”,所以在这里并不会提供测试计划模板。内容聚焦于做测试计划的过程中“如何选择最优的内容”。

 

测试计划 vs. 测试策略

开始之前,先澄清一下两种定义测试计划的方式:

· 单个测试计划: 一些项目拥有单个“测试计划”,描述与项目相关的所有实现与测试。

· 单个测试策略+多个测试计划: 一些项目拥有单个“测试策略”和许多小的“测试计划”文档。测试策略覆盖所有的测试路径与目标,测试计划覆盖特定的特性或者项目更新。

或许两种“测试计划”并没有孰优孰劣之分,请针对具体的项目具体选择。一般来说,稳定的项目选择“单个测试计划”更好,变化频繁的项目更加适合“固定测试策略”+“不固定增加的测试计划”。

 

内容选择

做测试计划最好的方式是罗列出所有需要解答的问题。无论是否会对项目产生影响,我们都要全面的进行收集所有重要问题。浏览一下收集的问题列表,筛选出所有影响项目的问题。在回答这些问题的过程中,就可以理出测试计划的内容,然后以团队可接受的方式编写一份测试计划(需要综合考虑上文中提到的几个因素来衡量计划的内容)。

 

前提

· 需要测试计划吗? 如果没有项目设计文档或者还不清楚项目长什么样,那么不要急着去写测试计划。

· 可测试性是否被纳入了项目设计? 在项目开始大规模开发之前,必须为所有的场景设计可测试性,最好能够支持自动化测试。项目设计文档和测试计划中都需要对可测试性提出要求。

· 需要持续更新测试计划吗? 如果要持续更新,请不要在计划中描述太多的细节,否则将难以维护。

· 工作成果是否与其他团队有重叠? 如果有重叠,如何避免重复工作?

风险

· 是否有明显的项目风险,如何减少风险? 例如:

会伤害人或动物

影响用户数据的安全性和完整性

侵犯用户隐私

影响公司系统安全

导致硬件或财产损失

存在法律或诚信问题

泄露机密或者敏感信息

导致数据丢失

导致收入减少

存在无法覆盖的场景

需要满足性能要求

误导用户

影响其他项目

被其他项目影响

影响公司对外形象

降低生产力

· 项目有哪些技术缺陷? 例如:

已知特性或者组件容易被入侵,健壮性查,或者急需重构

项目依赖的组件或者平台频繁导致问题

用户有可能会对系统造成破坏

以往问题的趋势如何

覆盖率

· 项目长什么样? 是一个只有一个方法的简单library,还是有复杂用户场景的软件系统?描述被测系统的设计和架构,分析可能出问题的地方。

· 支持什么平台? 建议列举出支持的操作系统,硬件,设备等。描述一下不同平台上测试的表现。

· 有什么特性? 建议将所有特性列出概要清单,描述一下哪些特性要进行测试。

· 哪些内容不会被测试? 没有一种测试会覆盖所有可能性。最好提前想好哪些用例不会进行测试。例如:”低风险低优先级用例“,”复杂功能低优先级用例“,”被其他团队测试过的功能“,”没有准备好的特性“等等,都属于低风险功能,而不会进行测试。

· 单元测试(small)、集成测试(medium)、系统测试(large)分别应该覆盖那些功能? 尽可能多地做“smaller tests”,少部分的用例使用“larger tests”。描述一下不同种类测试用例分别在哪种规模的测试中进行,并提供理论依据。

· 哪些用例要手工执行,哪些用例要自动化? 如果自动化具备可行性并且实现代价不高,通常是最好的选择。许多项目能将所有测试都自动化。然而,有些项目选择手工测试也有充分的理由。描述一下什么样的测试用例要进行手工测试,并提供理论依据。

· 是否覆盖了所有测试类型? 例如:

可达性

功能

模糊(测试)

国际化和本地化

性能,加载,压力和耐久性

隐私

安全性

冒烟

稳定性

易用性

· 需要使用静态和/或动态分析工具吗? 无论是静态分析工具,还是动态分析工具都能够找到一些测试过程中很难找到的问题,所以建议使用分析工具。

· 测试过程中,系统组件和依赖之间是“stubbed”,”mocked”,”faked”,”staged”,还是正常使用? 每一项内容都会影响最终的测试覆盖率。

· 测试运行在哪个”构建“之上? 在”HEAD“,”stage“,还是”待发布“版本之上?如果是在”HEAD“上测试,怎么测试”cherry picks(只发布部分改动)“?怎么测试系统配置的改变?

· 什么样的测试应该在团队之外进行? 例如:

o ”吃狗粮“

外部的众包测试

公开的”alpha/beta“版本(如何在正式发布前测试)

可信的外部Tester

· 怎么测试数据迁移? 可能需要特殊的测试来对比迁移数据前后的结果。

· 是否需要关注向后兼容? 可能存在一个以前版本的客户端,或者有另外一个系统依赖于当前系统的协议、配置、特性或者行为。

· 是否需要测试”服务器/客户端/终端“的升级场景?是否需要测试软件所依赖的”库/平台/API“?

· 是否有代码行的覆盖率的目标?

工具和基础建设

· 是否需要新的测试框架? 如果需要,请描述或者在测试计划中增加设计链接。

· 是否需要新的测试实验室? 如果需要,请描述,或者在测试计划中增加设计连接。

· 如果当前项目为其他项目提供服务,是否要像用户提供测试工具? 建议提供”mocks“,”fakes“和/或可靠的stage服务器,方便用户进行集成测试。

· 对于end-to-end测试,如何管理测试基础设施、被测系统和其他的依赖? 如何部署?如何持续地进行”set-up/tear-down“?数据迁移怎么做?

· 是否需要工具来对系统进行debug或者测试错误? 可以使用现有的工具,也可能需要开发一款新的工具。

 

执行过程

· 是否要拿出一个测试时间表? 什么时间,会进行哪一项测试(或者提供测试结果)?是否一些测试的比其他测试更加重要?

· 如何持续不断的进行构建和测试? 大部分”small tests“会通过持续集成工具来运行,但是”large tests“可能需要不同的运行方式。

· 如何上报和监控构建和测试的结果?

是否有一个团队负责监控持续集成?

o ”large tests“可能要求专业技术人员来进行监控。

是否有一个dashboard来查看测试接结果和项目的健康度?

如何发送告警邮件,以及告警邮件会通知哪些人?

监控测试的同事只是简单地以口头传达的方式通知团队吗?

· 发布过程中如何进行测试?

是不是只会使用”待发布版本“,或者发布的程序严格依赖于持续测试的结果?

如果系统组件和依赖要被独立发布,是否在每一个发布类型上都进行了测试?

发布决策者是否会因为”阻塞发布”的bug而停止发布?“阻塞发布”是否有统一的标准?

首次发布的时候,如何监控进度并组织测试?

· 外部用户如何上报bug? 建议增加反馈连接或者其他类似的工具来收集上报的问题。

· 如何将bug分类? 建议使用标签和类型对bug进行分类管理。同时确保团队也要使用与此相同的bug上报模板。

· 应该被解决的bug未解决就要被close,是否有一种机制可以提交新的测试?

· 未提交的改动如何进行测试? 如果有人能做到,建议提供使用说明。

· 团队成员如何构建测试 /或 进行debug? 建议提供使用说明。

 

使用

· 测试计划的读者是谁? 虽然有些测试计划会被许多人读到,但是有些测试计划只会被很少一部分人读到。测试计划至少应该被所有的利益相关者(项目管理者,技术leader,产品管理者)review。写测试计划的时候为了确保读者能够理解,需要提供足够的背景材料,回答所有可能的疑问。同时,建议在测试计划中增加联系方式,方便读者能够获取更多的信息。

· 读者如何review测试用例? 手工测试用例可能会被放在一个测试用例管理工具中,可能会放在单独的文档中,也可能直接写在测试计划中。自动化测试建议提供对应的链接。

· 需求、特性和测试之间是否需要可追溯?

· 是否有通用的产品健康度或者质量目标?如何进行评估? 例如:

发布节奏

用户发现的bug数量

“release testing”中发现的bug数量

超时未解决的bug数量

代码覆盖率

手工测试的投入

创建新测试的难度

本文系TestBird测试工程师编译整理。想了解更多开发测试相关信息,请访问 TestBird

原文地址:

http://googletesting.blogspot.com/2016/06/the-inquiry-method-for-test-planning.html

加载中
0
kyzg2211
kyzg2211
项目可测试性要重视啊,栽过跟头踩过坑,一把辛酸一把泪!文中说的很全面了,测试计划真得全面才不会坑啊。。。。。
0
珊小猫
测试前一定要评估项目缺陷
返回顶部
顶部