测试用例的感想

        一直想写一篇关于测试用例的文章, 一直都没空坐下来好好的写. 刚好周末有空,  趁机写下来, 供以后做参考

       做测试的,免不了要写测试用例了. 而且, 这东西, 差不多也是每个人测试求职者会被提问的. 如何有效的组织测试用例呢?  也是值得深思的.

        刚开始做测试的时候, 大家推崇的是测试案例要写的尽可能的详细, 而且制定的标准是:让一个不会这个系统的人也知道这个用例的用意以及如何操作,并且知道正确与否. 于是大家的   案例写的都是:  标题(用例概要); 内容(详细内容, 一步一步的操作步骤, 用到的数据, 如何验证数据), 预期结果, 环境. 有时候,对于一个简单的模块, 不得不写好几个这样的测试用例 ,否则在评审的时候, 就有人开始叫嚣: 那样的情况你不测一下么?  所以一个需求下来, 案例的个数是满天飞. QA以及领导们倒是满意了, 哗啦啦的案例很是养眼, 而且显示出了工作量. 这样下去, 需求一个接一个, 案例集越来越多越来越多. 突然有一天, 新人来了, 想了解下系统, 丢一份这个么多的案例给他: 你看看这个, 写的很详细, 照着操作就好了.  我的神 . 那是有多么多的案例啊. 看的头昏眼花, 即使是熟悉这个系统的人也分不清那些是有用的, 哪些是没有用的. 敢问QA们, 你们去看过这里的内容么?有没有想过用例的复用度?单纯的以案例来写案例肯定不是一个明智的选择.

        那么我们需要怎么样的测试案例呢? 测试用例的目的仅仅就是为了让"让一个不会这个系统的人也知道这个用例的用意以及如何操作,并且知道正确与否"么?  用例的目的是为了发现缺陷 . 窃以为, 用例可以是记录测试点的文本存档, 可以是对系统知识的一个补充.  用例并不是写完了用完了就了事的. 指不定现在再测的需求, 后面某个时候会被用到, 或者会被其他的需求用到.  如果让用例更实用, 更能帮助寻找缺陷? 

        用知识库(wiki)的形式组织案例或许是一个很好的方法. 首先将系统进行整理, 按照模块或者业务形成wiki知识库框架. 后期的案例都以wiki的形式存档到wiki中. 案例主要侧重测试要点,并且这些要点以思维方式形成. 所谓的思维方式是指编写案例的思考方式, 比如这一类是在界面展示或者操作的时候注意的, 这一类是在数据处理的时候注意的, 这一类是在数据的存储时注意的,  这一类是按照业务流的形式需要注意的 等等~ . 只是把这些要点记录下来, 至于看到这个要点, 执行者如何去执行, 每个人都有每个人的方式, 也不必统一.  这样测试人员就可以从繁琐的案例编写中解放出来, 有时间去了解这个需求更多的内容, 形成测试要点, 并组织记录在wiki中.  在以后设计到这一块内容时, 可以通过搜索关键字来查询wiki中相关的内容, 获取对应的信息, 同时也可以看看之前的内容, 可以做参考,也可以做补充.