关于测试用例，我们有太多的疑惑了，测试用例的依据？好的测试用例评估....等等。我们依据需求分析，依据开发文档，依据系统设计文档，甚至依据UI写测试用例，我们就真的足够了？不够，真的不够。需求在变，开发文档跟着变，设计文档也在改动，UI也在做变化，那我们的测试用例应该怎么写？

　　个人认为，一个好的、有效的测试用例，应该具备以下几个特征：

　　1、覆盖全面。测试的每个路径都涉及到，功能测试、界面测试、有性能要求的做性能测试、有安全要求的做安全测试（网络安全、通信安全...）等。

　　2、测试用例的后期维护时间短。测试用例写出来，不可能一成不变，根据系统的优化，测试用例都应该做相应的修改。针对需要修改的测试用例，我们修改了测试用例的哪些部分？测试前提、测试过程、测试数据、测试结果？如果四个方面都需要做修改，要么就是该功能完全变了，要么就是测试用例写的不够好。在系统做优化的时候，一般只需要修改测试数据就可以。

　　3、对内的测试用例与对外的测试用例不一样。某些行业，测试用例需要随着系统一起交付用户使用。对内的测试用例，应该以寻求BUG为主，我们可以把过程写的流畅简单些，但是测试数据一定要充分；对外的测试用例，应该以指导用户参与测试为主，所以过程需要比对内的测试用例详细，但是测试数据可以减少。因为用户主要是想知道，这个系统是否可以使用，他不是真的为了给你找BUG。

　　4、同一个产品的不同项目，许多的测试用例可以公用的。所以，针对不同的项目编写测试用例，有许多我们拿以前的测试用例直接黏贴过来用，减少了许多写测试用例的时间。

　　针对以上几个特征，编写测试用例前，我们应该做哪些工作？我一般会花一些时间去看看需求文档、设计文档、开发文档；有机会就去找市场部的人交谈，在他们抽烟的时候，冒一根不够，就再冒一根，慢慢的问我想知道的问题；最好也和研发部的开发人员了解下情况，这个系统他们怎么看的，打算怎么做，有必要可以说说你的观点。

　　当这些前提你都做了，你完全可以写测试用例了，当然边写还是要边沟通，也许有新的发现呢？如果边写测试用例的时间不够，你没有太多的时间去做这么多的铺垫工作，也没有关系，你可以先把一些通用的测试用例写出来：登陆、增加数据、修改数据、查询数据等，然后把业务要求比较强的测试用例放在最后编写，这样我们既没有浪费时间，也可以按时交测试用例。

　　测试用例写出来，维护怎么办？测试用例的维护，写过测试用例的朋友都知道，大家都去嘟囔修改测试用例很无聊，首先它没有太多的技术含量（这个大家都不喜欢，好多人也认为测试没有技术含量），第二这个过程很繁琐和枯燥。如果想维护简单，在编写测试用例的时候你就应该考虑到这点。各项描述应该怎么写，通俗易懂而且是通用的是首选。举例：

　　方法一：

　　测试前提：系统服务运行正常、，具有xiaoming这个用户，密码为999999

　　测试过程：

　　1、访问系统登录页面http://localhost:8089/index.jsp

　　2、输入用户名：xiaoming

　　输入密码：999999

　　3、点击“登录”

　　测试数据：

　　　　用户名密码举例：

　　　　系统用户：xiaoming，密码999999；xiaohong，密码666666

　　　　用户名与密码不匹配：xiaoming，密码666666；xiaohong，密码999999

　　　　非系统用户：xiaowang，密码999999；xiaobai，密码666666

　　　　非法参数：#￥%，密码HH*&56；yong12%……，密码**……（