频繁迭代变更，测试人员大量时间消耗在反复设计测试用例上，疲于奔命无暇顾及产品质量本身，如何才能节省时间高效率的设计测试用例？如何保持测试用例的长久有效和新鲜？笔者把多年的工作学习中总结的道道分享给大家。同时，在笔者另一篇文章《敏捷化设计测试用例的十条建议》中，给出了设计测试用例的具体优化方法，需要的朋友也可以一起讨论。
先啰嗦几句什么是保持“测试用例新鲜”？保持“测试用例新鲜”是指测试人员在设计测试用例时，为了能够尽量长久地保证测试用例是有效的、可用的，从而采用的一些设计方法，简而言之就是为了让测试用例保持长久有效性。刚刚百度搜了下好像还没有人提过“测试用例新鲜”这个概念，算是首创了吧。
举一个栗子，有一天领导突然把你叫过去，安排测试一个老的产品，因为该产品增加了新需求，想必测试同学都面临过相似场景。接下来当然是撸起袖子开工了。第一件事是做测试设计！对的，没看错！有人会说为什么测试也要做设计，直接照着PRD（产品需求文档）写测试用例不就行了。我们要反问，难道写用例之前不需要了解需求吗？不但要了解需求还要深入项目背景、行业背景进行调研！还要对项目可行性、项目风险、人力和时间成本进行思考。
测试用例不是空想得来，必须来源于真实的产品需求，否则就是无效的测试用例，测试用例应该是密切跟随需求（项目），针对需求（项目）进展的不同阶段，有不同的策略。
比如在产品需求阶段，测试要参加需求评审，重点项目可能会有多次评审，测试在评审时需要评估项目有哪些风险，理解项目完整故事和背景，从而明确项目内容和边界。不了解这些内容，设计测试用例时就没办法从全局角度出发，导致用例的适用范围偏窄。就好似盲人摸象，摸到象腿的会说大象又粗又直长得应该像个柱子，实在是太搞笑了。
需求通过后，一般就会进入产品设计阶段（研发阶段）。此时开发团队会开始设计技术方案，此时测试用例也应同步推进了。有公司的做法是等技术评审后再开始测试用例评审，可以借鉴一些技术设计的内容。关于这个先后顺序仁者见仁智者见智吧，但我更推荐测试应该先于技术架构，类似于TDD的思路，测试先行，驱动开发，毕竟测试算半个产品经理。最早版本的测试用例在设计的时候，应该是高独立性的，有各自的纬度可以单独维护增删改查等等。
最后产品进入维护阶段，一个项目上线以后，主线特征（main line features）已经逐渐稳定，但是仍然会持续有迭代优化，针对这些优化需求，不建议新开用例库（test cases list），比较推荐的做法是在原有用例库上进行增删改。此时用例独立性的好处就能体现出来了，对原有测试用例的删改也体现了测试用例的进化性，即伴随项目的迭代，测试用例也持续进化和持续优化。具体还有哪些测试用例的优化设计方法，请移步到笔者的另一篇文章《敏捷化设计测试用例的十条建议》。
做项目惯例是先讲投资回报率（ROI），所以文章最后我们也讨论下都有哪些收益。
- 用例库仍然保持了原有的一套用例集合，维持了统一性和权威性，owner没有发生变化也就不会产生二义性。
- 维护成本没有额外增加，譬如用例增加了若干，那么维护的成本也是处于预期中和可接受的范围，维护成本的增长属于线性增长。
- 由于项目的每个迭代都会有变化，帮助项目fix持续的迭代演进，帮助新人理解整体需求，因此节约了人力成本。
- 降低测试设计时间，帮助降低了开发测试工期比例，能够节约部分时间成本。
为了解决测试用例设计难以保持长久有效，而重复设计又耗时的问题，本文提出了以上观点作为抛砖引玉，请不吝表达您的观点。
源自公众号 三国测