开发一个软件产品通常会发布多个版本，随着软件版本及功能的逐渐增多和变更，测试用例也越来越多，维护成本也随之升高，因此有效地维护测试用例是白盒测试中至关重要的一环。本文将从以下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.用例维护的意义
测试用例的维护是一个长期的过程，也是一个不断改进和完善的过程，测试用例伴随着整个项目的生命周期，因此只要项目还在维护和变化，测试用例就应当被妥善维护。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理
