白盒测试体系-用例维护篇
开发一个软件产品通常会发布多个版本，随着软件版本及功能的逐渐增多和变更，测试用例也越来越多，维护成本也随之升高，因此有效地维护测试用例是白盒测试中至关重要的一环。本文将从以下5点对白盒测试中用例维护进行分享：
- 为什么要做用例维护
- 哪些项目需要用例维护
- 什么情况下需要进行用例维护
- 怎样进行用例维护
- 用例维护的意义
1
●
为什么要做用例维护
●
对于白盒测试而言，进行用例维护的核心目标就是提升测试用例的可复用性，节省人力成本，提升工作效率。
2
●
哪些项目需要用例维护
●
【需要长期维护的项目】
项目需要长期维护，版本在不断地更新迭代，对应的测试用例也要长期维护。
【服务于多个项目的用例】
测试用例不止服务于一个项目，而是因其可拓展性服务于多个项目的情形下，也需要进行用例维护。
3
●
什么情况下需要进行用例维护
●
已有功能优化升级后，现有的用例只满足于该功能变更之前的覆盖情况，对于该功能更新后的内容要进行测试用例补充，不支持的功能要进行用例修改或者删除，包括但不限于以下情形：
- 软件需求变更（增加，修改，删除）；
- 现有测试用例设计不全面或者不够准确；
- 用例评审后或者随机测试时发现的新缺陷，需对现有用例进行修改；
- 软件发布后，线上用户反馈了新的缺陷。
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
●
用例维护的意义
●
测试用例的维护是一个长期的过程，也是一个不断改进和完善的过程，测试用例伴随着整个项目的生命周期，因此只要项目还在维护和变化，测试用例就应当被妥善维护。
●