白盒测试体系-用例维护篇

2020/05/12 17:00
阅读数 575
AI总结

开发一个软件产品通常会发布多个版本,随着软件版本及功能的逐渐增多和变更,测试用例也越来越多,维护成本也随之升高,因此有效地维护测试用例是白盒测试中至关重要的一环。本文将从以下5点对白盒测试中用例维护进行分享:

  • 为什么要做用例维护

  • 哪些项目需要用例维护

  • 什么情况下需要进行用例维护

  • 怎样进行用例维护

  • 用例维护的意义



1


为什么要做维护

对于白盒测试而言,进行用例维护的核心目标就是提升测试用例的可复用性,节省人力成本,提升工作效率



2


哪些项目需要例维护
【需要长期维护的项目】

项目需要长期维护,版本在不断地更新迭代,对应的测试用例也要长期维护。


【服务于多个项目的用例】

测试用例不止服务于一个项目,而是因其可拓展性服务于多个项目的情形下,也需要进行用例维护。



3


什么情况下需要进行用例维护

已有功能优化升级后,现有的用例只满足于该功能变更之前的覆盖情况,对于该功能更新后的内容要进行测试用例补充,不支持的功能要进行用例修改或者删除,包括但不限于以下情形:


  1. 软件需求变更(增加,修改,删除);

  2. 现有测试用例设计不全面或者不够准确;

  3. 用例评审后或者随机测试时发现的新缺陷,需对现有用例进行修改;

  4. 软件发布后,线上用户反馈了新的缺陷。




4


怎样进行用例维护

【概述】


测试用例不断的变更和维护,使之与产品功能、特性的变化保持一致,对于服务于一个或多个项目的测试用例的维护,我们将其按照实际情况划分为以下四个阶段:

【第一阶段 零散测试用例的维护】


对于单一独立的功能,对该功能的各个测试点设计的用例进行执行和验证,此阶段没有进行固定的系统化的维护和整理。

【第二阶段 结构清晰的系统化测试用例维护】


维护的测试用例成一定量级和体系之后,需要按照模块来进行维护,各个大的模块下又会包含若干小的模块,以输入法内核模块举例:


【第三阶段 逻辑与数据分离的测试用例维护】


项目中经常会出现因为版本的更新而导致用例失败的情况,例如输入法词库更新导致的原有词条不存在、云输入下发结果发生变化等。

这时我们的做法是测试用例的逻辑与数据相分离,通过构造测试文件,mock等方法,使得即便发生上述情况的变化,用例依然生效,降低维护成本。


例:通过加载测试词库来验证内核联想黑名单逻辑:

TEST_F(CNewLegendBlackList, test){       load('Dict/usrdict_womenshi.bin);    initIME();    ASSERT_TRUE(Find(u"women", u"我们", u"是");    load_legend_blacklist("BlackListDict/womenshi_bl.bin");    initIME();    ASSERT_FALSE(Find(u"women", u"我们", u"是");}


【第四阶段 建立公共测试用例库】


对于同一类的测试用例,最终希望其可以有效复用在多个项目中,通过制定规范的协议或使用人工智能的方法,使得测试用例可以服务于更多的项目,成为公共用例库。



对于协议的制定,可以通过将测试用例json化,使得用例不仅能够应用于内核,更希望其能应用于安卓,iOS,PC等平台,最终服务于多个项目。




5


用例维护的意义







测试用例的维护是一个长期的过程,也是一个不断改进和完善的过程,测试用例伴随着整个项目的生命周期,因此只要项目还在维护和变化,测试用例就应当被妥善维护。



欢迎关注白盒测试体系系列其他文章:

白盒测试体系—开篇

白盒测试体系—框架搭建篇



本文分享自微信公众号 - 搜狗测试(SogouQA)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
0 评论
0 收藏
0
分享
AI总结
返回顶部
顶部