对测试用例的一些想法（欢迎大家多提建议）
关于测试用例，我们有太多的疑惑了，测试用例的依据？好的测试用例评估....等等。我们依据需求分析，依据开发文档，依据系统设计文档，甚至依据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%……，密码**……（
测试结果：使用正确的用户名与密码，可以登录系统；使用错误的用户名和密码，不能登录系统
结果分析：
方法二：
测试前提：系统服务运行正常、具有系统用户数据
测试过程：
1. 访问系统登录页面
2. 输入用户名和密码
3. 提交数据
测试数据：
用户名密码举例：【假设xiaoming，密码999999为系统用户】
说明：用户名只能为数字、字母、下划线‘_’，首字不能为下划线
密码不能为空格
正确格式的用户名：xiaoming、xiao123、xiao_123、123_xiao等
错误格式的用户名：xiao%、123_xiao+空格、！@等
密码的输入参照用户名的输入规则
测试结果：系统用户能够登录系统并具有对应的权限、非系统用户不能登录系统
结果分析：
参照以上两个测试用例，我们就能很明显的分辨出用例的优劣。第一个测试用例我们至少需要准备xiaoming这一个测试数据、登录界面如果增加了需要输入验证码，我们就要重新修改测试过程，测试数据我们也要做很多修改（就拿用户名可以输入数字、字母、下划线来说，正确的组合就有2*3*3=18种），测试结果，我们登录系统为了做什么？没有权限怎么办？我们应该具有哪些权限？第一个用例就没有做说明，可以说，测试结果的说明是不全面的。
第二个测试用例，如果系统增加了需要输入验证码，我们在测试过程的第二步，只需要说明输入用户名、密码、验证码，测试数据我们不需要做变化，在结果分析里，增加说明：用户名、密码、验证码正确，准入，否则拒绝。
第二个测试用例，有个不足，就是测试数据不全面。我在编写测试用例时，针对这个测试用例，我有个测试数据的附件。【附件分为两部分，手工测试以及自动化测试，手工测试我会有个详细的数据说明，并不是把所有的数据组合都列出来，而是详细的说明组合的方式方法，一共有多少种（包含边界值法以及特殊值等）；自动化测试的数据说明简单很多，写一个正则表达式搞定】。
按照第二个测试用例，我们的工作就不再是苦力了，而是智慧的苦力。我们不再是点点点，慢慢的我们知道哪些是主要关注的，哪些是次要关注的，我们应该怎么去设计数据等等。慢慢的，我们学会了思考，我们也真的进步了。
欢迎大家多提意见，我们一起进步。 楼主说的好详细 ，值得学习下~~ 应该让很多要测试用例的人来看看 测试用例说实话是个蛮头疼的活，而且有时候写不全或者不写的 说的很好，顶一个。 顶楼主一个 新人对楼主的测试数据的附件很感兴趣
好记性不如烂笔头 说的很好，顶一个。 学会思考
页:
[1]
