测试用例思考

关于测试用例的思考

 

说到测试用例，我们大家都很有发言权，我们也有很多的困惑。关于如何编写测试用例，我还是从我曾经在博客上写的两篇文章开始说起：

两篇文章

第一篇：simple,还是simple，测试的本质

一直有人在问：为什么做测试？测试的目的是什么？

上网搜索这样的答案，一大堆，你都看不过来。有人说，测试的目的是寻找BUG；有人说，测试的目的是为了满足需求...但是我说，测试的目的：为了简单。

简单=设计简单+使用简单。做测试一年多了，虽然时间不长，但感悟颇多。在测试过程中，和百度、HP、微软的一些朋友聊天，但事实是，大家对测试，都在摸索阶段。

我们拿着国外的一套理论，在中国执行，我们同样沿袭着不成熟（软件测试在中国不成熟）的思考方式。那我们应该怎么去做测试？我们应该制定测试方案，也应该制定测试计划，还应该写测试用例，但为什么？我们为什么需要这些？这些，我的想法是，测试方案，是从技术上考虑，我们应该怎么测；测试计划，是从管理上去考虑，我们怎么管理测试过程。那测试用例呢？当然，一个个的case，就是为了最终的测试路径。那我们写测试用例的依据是什么？

关于测试用例，我们有太多的疑惑了，测试用例的依据？好的测试用例评估....等等。我们依据需求分析，依据开发文档，依据系统设计文档，甚至依据UI写测试用例，我们就真的足够了？不够，真的不够。需求在变，开发文档跟着变，设计文档也在改动，UI也在做变化，那我们的测试用例应该怎么写？(这个我会作为一个单独的话题拿出来写，今天先写测试的本质）

写一个测试用例，都有这么多的问题，那面对测试，我们的问题就更加多了。曾经看过一本书，书上说：你开了个商店，有人来买一个钉子，你就给他一个钉子。但是，他为什么需要钉子？因为他需要把画固定在墙上。这个时候，问题就来了，把画固定在墙上，有很多种方式。胶水、钉子、螺丝等等。所以，如果你只卖钉子，肯定满足不了用户的需求的，你应该从最根源的方向出发，然后才能挖掘更多的市场。这是从商人的角度上思考问题。

那我们做测试呢？你面对一个系统，你看到的是这个系统，还是我们面对的客户？我在每次测试的时候，我看到了系统，我也同样在考虑客户。我在想，客户为什么需要这个东西，她拿这个东西做什么？我们有没有更好的方式去解决这个问题。所以，每次做单元测试、集成测试、系统测试，我就会有不同的问题提出来，很多的建议（占据整个问题的30%），也发现了很多不如意的地方。

所以，当有人问我，你为什么要做测试。我说，测试，我喜欢，因为我面对的不只是软件，是活生生的使用者，是我们未来市场的客户。我希望他们拿到我测试过的东西，微笑着使用，这个就是我做测试的初衷也是我一直需要努力的方向。

面对客户，我们需要做什么？我们是计算机的人才，精通电脑，也精通软件，甚至有些东西我们使用到闭眼就知道怎么做，那我们的客户呢？他们知道什么？他们甚至不知道怎么装操作系统，打字也很慢，他真正需要什么东西，他也不太清楚。我们拿一个非常复杂的软件，去交付用户使用，后果会怎么样？他将付出很高的成本，我们也会派专业的人员疲于奔命。

所以，测试，最终的目的，就是用让系统最简单的满足需求。设计简单，无论谁都可以做，无论谁离开了，我们的系统依旧可以运行并且做优化；使用简单，用很短的时间，我们就可以熟练操作并且知道它为什么这么做。这个，才是测试的本质。

第二篇：怎么编写测试用例

关于测试用例，我们有太多的疑惑了，测试用例的依据？好的测试用例评估....等等。我们依据需求分析，依据开发文档，依据系统设计文档，甚至依据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为系统用户】

说明：用户名只能为数字、字母、下划线‘_’，首字不能为下划线，长度不能超过24个字符

 密码不能为空格，长度不能超过24个字符

正确格式的用户名：xiaoming、xiao123、xiao_123、123_xiao等

错误格式的用户名：xiao%、123_xiao+空格、！@等

密码的输入参照用户名的输入规则

测试结果：系统用户能够登录系统并具有对应的权限、非系统用户不能登录系统

结果分析：

 

参照以上两个测试用例，我们就能很明显的分辨出用例的优劣。第一个测试用例我们至少需要准备xiaoming这一个测试数据、登录界面如果增加了需要输入验证码，我们就要重新修改测试过程，测试数据我们也要做很多修改（就拿用户名可以输入数字、字母、下划线来说，正确的组合就有2*3*3=18种），测试结果，我们登录系统为了做什么？没有权限怎么办？我们应该具有哪些权限？第一个用例就没有做说明，可以说，测试结果的说明是不全面的。

第二个测试用例，如果系统增加了需要输入验证码，我们在测试过程的第二步，只需要说明输入用户名、密码、验证码，测试数据我们不需要做变化，在结果分析里，增加说明：用户名、密码、验证码正确，准入，否则拒绝。

第二个测试用例，有个不足，就是测试数据不全面。我在编写测试用例时，针对这个测试用例，我有个测试数据的附件。【附件分为两部分，手工测试以及自动化测试，手工测试我会有个详细的数据说明，并不是把所有的数据组合都列出来，而是详细的说明组合的方式方法，一共有多少种（包含边界值法以及特殊值等）；自动化测试的数据说明简单很多，写一个正则表达式搞定】。

按照第二个测试用例，我们的工作就不再是苦力了，我们不再是点点点，慢慢的我们知道哪些是主要关注的，哪些是次要关注的，我们应该怎么去设计数据等等。慢慢的，我们学会了思考，我们也真的进步了。

欢迎大家多提意见，我们一起进步。

一个测试用例

在整个测试生涯中，到现在，我的测试用例已经经过了几次变化。还是以用户登录系统功能测试为例：

第一种方式：

这个测试用例是我2008年刚进公司时，公司给我的测试用例模板，然后我也依葫芦画瓢写的：

测试编号	PRS-001	模块名称		正常登录系统
开发人员		版本号			设计日期		2008-10-26
用例作者	宁成文	测试日期			测试人员
前置条件	1. 安全服务器系统正常运行 2. 具有系统用户数据
测试步骤	1. 访问系统登录页面http://192.168.102.38:8089/caweb/login.jsp 2. 输入用户名：ningchengwen    输入密码：11111111（8 个1） 3. 点击“登录”按钮
预期结果	登录CA系统
测试说明
结论	□通过  □未通过		结论说明

 

测试编号	PRS-002	模块名称		非系统用户登录系统
开发人员		版本号			设计日期		2008-10-26
用例作者	宁成文	测试日期			测试人员
前置条件	1. 安全服务器系统正常运行 2. 具有系统用户数据
测试步骤	1. 访问系统登录页面http://192.168.102.38:8089/caweb/login.jsp 2. 输入用户名：xiaoming    输入密码：11111111（8 个1） 3. 点击“登录”按钮
预期结果	系统提示：用户名不存在，请重新输入
测试说明
结论	□通过  □未通过		结论说明

 

测试编号	PRS-003	模块名称		不输入用户名登录系统
开发人员		版本号			设计日期		2008-10-26
用例作者	宁成文	测试日期			测试人员
前置条件	1. 安全服务器系统正常运行 2. 具有系统用户数据
测试步骤	1. 访问系统登录页面http://192.168.102.38:8089/caweb/login.jsp 2. 输入用户名：空值    输入密码：11111111（8 个1） 3. 点击“登录”按钮
预期结果	系统提示：请输入用户名
测试说明
结论	□通过  □未通过		结论说明

 

测试编号	PRS-004	模块名称		不输入密码登录系统
开发人员		版本号			设计日期		2008-10-26
用例作者	宁成文	测试日期			测试人员
前置条件	1. 安全服务器系统正常运行 2. 具有系统用户数据
测试步骤	1. 访问系统登录页面http://192.168.102.38:8089/caweb/login.jsp 2. 输入用户名：ningchengwen    输入密码：空值 3. 点击“登录”按钮
预期结果	系统提示：请输入密码
测试说明
结论	□通过  □未通过		结论说明

 

测试编号	PRS-005	模块名称		不输入用户名密码登录系统
开发人员		版本号			设计日期		2008-10-26
用例作者	宁成文	测试日期			测试人员
前置条件	1. 安全服务器系统正常运行 2. 具有系统用户数据
测试步骤	1. 访问系统登录页面http://192.168.102.38:8089/caweb/login.jsp 2. 输入用户名：空值    输入密码：空值 3. 点击“登录”按钮
预期结果	系统提示：请输入用户名
测试说明	系统应该首先对用户名进行校验
结论	□通过  □未通过		结论说明

 

测试编号	PRS-006	模块名称		非法字符登录系统
开发人员		版本号			设计日期		2008-10-26
用例作者	宁成文	测试日期			测试人员
前置条件	1. 安全服务器系统正常运行 2. 具有系统用户数据
测试步骤	1. 访问系统登录页面http://192.168.102.38:8089/caweb/login.jsp 2. 输入用户名：ningchengwen￥、《》？等    输入密码：%…、111￥%等 3. 点击“登录”按钮
预期结果	系统提示：请输入正确的用户名
测试说明	系统应该首先对用户名进行校验
结论	□通过  □未通过		结论说明

 

测试编号	PRS-007	模块名称		边界值检测
开发人员		版本号			设计日期		2008-10-26
用例作者	宁成文	测试日期			测试人员
前置条件	1. 安全服务器系统正常运行 2. 具有系统用户数据
测试步骤	1. 访问系统登录页面http://192.168.102.38:8089/caweb/login.jsp 2. 输入用户名：ningchengwenningchengwen（24个字符）/ningchengwenningchengwen1(25个字符或者更多)【用户名不能超过24个字符】    输入密码：1111111111111111（16个1）/11111111111111111（17个1或者更多）【密码不能超过16个字符】 3. 点击“登录”按钮
预期结果	1. 用户名过长，系统提示：用户名不能超过24个字符或用户名不正确 2. 密码过长，系统提示：密码不能超过16个字符或密码不正确
测试说明	系统应该首先对用户名进行校验
结论	□通过  □未通过		结论说明

这一种方式，让我非常困惑，一个登录，就写这么多的测试用例，那一个系统下来，还不得上千个用例啊，我一天写100多个，需要写10天，真正执行起测试用例来，它能不能发现真正的问题？

第二种方式

测试编号	PRS-001	模块名称		系统用户登录
开发人员		版本号			设计日期		2009-1-15
用例作者	宁成文	测试日期			测试人员
用例描述	用户登录：系统用户，准入；非系统用户，拒绝
前置条件	1. 安全服务器系统正常运行 2. 具有系统用户数据
测试步骤	1. 访问系统登录页面 2. 输入用户名、密码 3. 提交数据
输入数据	用户名密码有如下输入情况：【说明：用户名只能为数字、字母、下划线‘_’，首字母只能为数字或者字母，长度不能超过24个字符；密码不能为空格，长度不超过16个字符】 正确格式的用户名：xiaoming、xiao123、xiao_123、123_xiao、超过规定长度的用户名等 错误格式的用户名：xiao%、123_xiao+空格、！@、超过长度的用户名等 密码的输入参照用户名的输入规则
预期结果	1. 正常访问系统登录页面，页面美观，可操作性强，功能与描述正确对应 2. 系统用户，准入系统；非系统用户，拒绝登录系统；错误数据，有正确提示指导用户进行下一步操作
测试说明	系统应首先检查用户名的正确性
结论	□通过  □未通过		结论说明

这种测试用例，思路比较清晰，目的也很明确，一个测试用例，验证了登录功能的可执行性、登录界面的美观要求、也验证了不同输入需要弹出的提示。一般的话，这个测试用例，就很足够了

我为什么用自动化测试？试想，数字、字母、下划线、首字母只能为数字或者字母，这种组合方式就有2*3*3=18种输入的方式，而且加上单独输入一个字符什么的，就有20多种输入方式了。一个登录功能，我们花费这么多的时间，似乎不太值得，但是QTP能帮我们解决这个问题。录制操作，加入检查点，参数化数据，调试，OK了，让它自己跑去吧。

这个测试用例，我基于功能策略也基于风险策略考虑的。每个系统，一般都会有登录功能，而且基本都一样。所以，这个用例，都可以通用，不用管提交数据按钮是“登录”、“提交”、“Submit”都没有关系，测试用例可以不变。

第三种方式

上一种测试用例使用了很长的时间，但个人感觉，他还是不能检查出真正的问题，而且，写测试用例太简单了吧，知道了功能，就能写测试用例，这么简单的东西，怎么让那么多人困惑？百思不得其解，查看了许多的资料，似乎明白了点，所以我想将测试用例写法再次修改了。

首先我们考虑一下用户登录的基本流：

基本流	本用例的开始是系统运行正常 1准备登录--用户输入用户名密码 2验证用户名--系统从用户名输入框读取用户名，并判断是否属于系统用户 3验证密码--系统从密码输入框读取密码，并判断是否为用户使用的密码 4授权--登录界面以账号信息作为一条数据发送系统，由系统启动验证过程并返回值为用户授权 用例结束时，用户已经登录系统并具有对应的权限

我们再考虑下用户登录的其他流：

备选流1：用户名密码无效

备选流2：用户已经登录

备选流3：用户没有权限

可选流1：断网

可选流2：系统宕机

…..

这个时候，用例就有以下的场景：

场景1—成功的登录	基本流
场景2—用户名密码无效	基本流	备选流1
场景3—用户已登录	基本流	备选流2
场景4—用户没有权限	基本流	备选流3

根据场景，我们设计测试用例：

测试编号	场景/条件	用户名密码	用户已登录	没有权限	预期结果
PRS01	成功登录	1	0	0	登录成功并具有权限
PRS02	用户名密码无效	0	0	0	提示信息并返回基本流
PRS03	用户已登录	1	1	1	提示信息并返回基本流
PRS04	用户无权限	1	0	1	提示信息并返回基本流

测试用例如果确认，就可以输入值进行测试。这个测试用例场景设计的优点是每一步的测试用例目的很明确，而且这个测试用例一旦设计好，考察的不仅仅是测试人员的测试水平，还有组织思维能力。不足的是，我们需要花很长的时间，去分解场景，而且需要一个团队去讨论，一般的项目，我们没有这么多的时间。所以，这种场景设计配合测试用例的写法，暂时作为产品级别的一种考虑。