资讯专栏INFORMATION COLUMN

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

Jrain / 1158人阅读

摘要:要有效的平衡以上因素,需要评估项目的具体情况如何实现的资源是否可用团队是什么意见尽管许多项目能够做到低投入,高回报的高覆盖率单元测试,但是他们也需要衡量和更复杂的场景。内容选择做测试计划最好的方式是罗列出所有需要解答的问题。

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

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

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

维护投入:不论是自动化测试还是手工测试,都会不同程度地增加长期投入。 财务投入: 有些测试可能会需要资金投入。

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

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

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

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

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

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

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

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

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

前提

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

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

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

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

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

会伤害人或动物

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

侵犯用户隐私

影响公司系统安全

导致硬件或财产损失

存在法律或诚信问题

泄露机密或者敏感信息

导致数据丢失

导致收入减少

存在无法覆盖的场景

需要满足性能要求

误导用户

影响其他项目

被其他项目影响

影响公司对外形象

降低生产力

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

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

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

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

以往问题的趋势如何

覆盖率

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

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

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

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

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

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

是否覆盖了所有测试类型? 例如:可达性,功能 模糊(测试,国际化和本地化 性能,加载,压力和耐久性,隐私安全性,冒烟,稳定性,易用性

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

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

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

什么样的测试应该在团队之外进行? 例如:”吃狗粮“,外部的众包测试,公开的”alpha/beta“版本(如何在正式发布前测试),可信的外部Tester

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

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

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

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

工具和基础建设

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

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

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

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

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

执行过程

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

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

如何上报和监控构建和测试的结果?是否有一个团队负责监控持续集成?”large
tests“可能要求专业技术人员来进行监控。是否有一个dashboard来查看测试接结果和项目的健康度?如何发送告警邮件,以及告警邮件会通知哪些人?监控测试的同事只是简单地以口头传达的方式通知团队吗?

发布过程中如何进行测试?是不是只会使用”待发布版本“,或者发布的程序严格依赖于持续测试的结果?如果系统组件和依赖要被独立发布,是否在每一个发布类型上都进行了测试?发布决策者是否会因为”阻塞发布”的bug而停止发布?“阻塞发布”是否有统一的标准?首次发布的时候,如何监控进度并组织测试?

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

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

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

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

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

使用

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

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

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

是否有通用的产品健康度或者质量目标?如何进行评估? 例如:
发布节奏,用户发现的bug数量,在“release testing”中发现的bug数量,超时未解决的bug数量,代码覆盖率,手工测试的投入,创建新测试的难度

本文系TestBird测试工程师编译整理。想了解更多开发测试相关信息,请访问 TestBird。
原文地址:
http://googletesting.blogspot...

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/13169.html

相关文章

  • 零基础入门前端修炼之道

    摘要:面对这些较高的要求,前端在开发环节中的作用也变得越来越重要因而近几年来前端工程师备受青睐一般水平的前端工程师平均年薪可达万元资深前端工程师年薪高达万元。这种用户体验的细节问题是否处理妥当是判断一名前端工程师是否优秀的因素。 本文是为了给那些想要了解前端开发是什么,或者刚刚打算开始学习前端的朋友们准备,希望可以帮助准备入行的你;showImg(https://segmentfault.c...

    JiaXinYi 评论0 收藏0
  • 简介:CII最佳实践徽章 - CNCF毕业标准要求之一

    摘要:已经实现并维护了核心基础结构计划的最佳实践徽章。年中国开源峰会提案征集现已开放在中国开源峰会上,与会者将共同合作及共享信息,了解最新和最有趣的开源技术,包括容器云技术网络微服务等并获得如何在开源社区中导向和引领的信息。 从沙箱或孵化状态毕业,或者作为一个新项目加入作为一个毕业项目,项目必须符合孵化阶段标准以及: 有来自至少两个机构的提交者。 已经实现并维护了核心基础结构计划(CII)...

    jzman 评论0 收藏0
  • 开发进阶篇:书写高效SQL语句

    摘要:基于此,帮助更多的开发人员解决引起的数据库问题是高效语句编写课程的初衷。适用人群需要解决引起的数据库问题,从而完成从低阶到高阶的跃迁的开发人员。 调查显示,SQL是目前第二大编程语言,自诞生以来40多年一直发挥着重要的作用,有50%的开发者都在使用SQL。虽然使用非常广泛,但是SQL的质量水平却并不令人满意。 根据经验,80%的数据库问题是由于SQL引起的,而80%的SQL问题来自于2...

    daydream 评论0 收藏0
  • 开发进阶篇:书写高效SQL语句

    摘要:基于此,帮助更多的开发人员解决引起的数据库问题是高效语句编写课程的初衷。适用人群需要解决引起的数据库问题,从而完成从低阶到高阶的跃迁的开发人员。 调查显示,SQL是目前第二大编程语言,自诞生以来40多年一直发挥着重要的作用,有50%的开发者都在使用SQL。虽然使用非常广泛,但是SQL的质量水平却并不令人满意。 根据经验,80%的数据库问题是由于SQL引起的,而80%的SQL问题来自于2...

    wangdai 评论0 收藏0
  • 开发进阶篇:书写高效SQL语句

    摘要:基于此,帮助更多的开发人员解决引起的数据库问题是高效语句编写课程的初衷。适用人群需要解决引起的数据库问题,从而完成从低阶到高阶的跃迁的开发人员。 调查显示,SQL是目前第二大编程语言,自诞生以来40多年一直发挥着重要的作用,有50%的开发者都在使用SQL。虽然使用非常广泛,但是SQL的质量水平却并不令人满意。 根据经验,80%的数据库问题是由于SQL引起的,而80%的SQL问题来自于2...

    Magicer 评论0 收藏0

发表评论

0条评论

最新活动
阅读需要支付1元查看
<