测试用例，简单来说，就是一个文档，描述输入、动作和期望的结果，作为一个半路转行的小白来说，刚开始，觉得测试用例有点多余，脑图画画思路，有个梗概即可，但是越来越多的坑告诉我，测试用例，必不可少，那么，大家可能会遇到以下几个问题：
1.测试用例繁杂，如何维护？
2.怎样高效利用测试用例来开展测试工作？
3.测试过程中涉及的范围如何定义？
接下来，就分享一下自己的方案
1.高效维护
刚开始，虽然是模块化，但是在一个sheet里，每次下拉几百行，定位太浪费时间，不知道你们的用例评审模式和我们的是否一样，我们的用例写完之后产品都要先过一遍，所以，每次都会被各种吐槽，所以，商量了一下
解决方案：分模块，一个模块一个sheet，新增功能或优化按大模块细分增加进去，最近的优化发给产品之前用颜色标注一下本次的修改，再发消息说明总的变动，用例用版本工具维护，第三方工具也可，我们是用SVN维护，可以找回历史版本
2.测试范围
之前，同事问我评审测试用例的意义何在，答：距离项目评审已经一段时间，可能会有遗忘，再碰一下，看测试和产品之间对于需求理解有没有偏差，查漏补缺。
再问，那为什么要叫开发一起呢，答：开发也可能会忘。。。
。。。。说完我自己都感觉搞笑
完了同事提出了正解：对于初级测试来说，我们对于一个功能可能影响的范围是按照主观来看的，但是实际上可能还影响了其他的模块，这个就要开发帮我们分析一下，他们在改代码的时候可能会动到哪一块，总而言之，两点
1>思维导图自己梳理功能，和产品达成一致
2>用例评审过细节，记录开发的问题点，联想可能涉及到的模块
3.必测项
刚开始接触这个概念，是基础用例，不过我感觉叫必测项更好理解，字面意思，就是不管上什么功能，你都要保证这部分功能不会受影响
八个字：由繁至简，由少到多
一开始，不太确定范围，可以把一些核心流程都测一遍，完了预估时间，多次之后，把一些不会变动且没问题的流程去掉，慢慢形成自己测试的一套必测项，然后，在这个过程中，可能会出现一些新的问题，慢慢增加，这个，是个不断优化的过程
4.总结
一件事情刚开始做的时候，可能会觉得很繁琐，但是框架搭起来之后，你会发现，以后的工作会方便很多，所以，磨刀不误砍柴工
最后，再说个小事吧
一开始，想把必测项以导图的形式来做的，然后再去找对应用例，但是，又被否了
你的思路，你知道，后来的小伙伴怎么办，这就是所谓的前人栽树，后人乘凉
所以，前人小伙伴们，加油吧