如何写好测试用例的设计心得_测试用例_领测软件测试网
如何写好测试用例的设计心得
发表于：来源：未知作者：waybook点击数：
如何写好测试用例的设计心得,入行软件测试行业2年，从事过自动化的测试和手工的功能测试。两年来一直没有总结过自己的工作。每当一听人问起一个简单的问题，如何编写好的测试用例? 如此简单的问题一问，仔细一想，思绪凌乱无章。这就是没有好好思考过
　　入行软件行业2年，从事过的和手工的。两年来一直没有总结过自己的工作。每当一听人问起一个简单的问题，如何编写好的?
　　如此简单的问题一问，仔细一想，思绪凌乱无章。这就是没有好好思考过的原因。
　　今天在总结下自己的看法，如何编写：
　　1、了解软件的原始(测试目的)
　　在编写一个软件或者模块的测试用例时候，一定要明白这个功能的原始，也就是软件的使用者(客户)的。理解原始需求后，编写的测试用例才更有目的性。
　　2、熟悉软件的功能需求(测试点)
　　这个功能需求是指软件的细化需求点，这个一般在需求文档里面都会体现。这里要做的是把需求稳定的&粗略&的需求，细化成一个个小需求点。
　　熟悉功能需求后，要知道软件是怎么使用的，这也才能覆盖到各种操作。
　　总之，测试用例一定要全部覆盖所以的需求点，这是最基本的一点。
　　3、熟悉软件的实现原理(测试点)
　　在理解原始需求和软件的功能需求后，软件有什么功能，如何使用就基本上都知道啦。这时候在根据需求编写测试用例，基本上都能覆盖的比较全面。
　　在此基础上，熟悉软件的实现原理，理解软件的内部处理。
　　(1)熟悉原理的过程是进一步深入熟悉软件的过程。如果单单是从需求点上面覆盖案例，测试用例只能覆盖&表面&的一层。一些内部的处理流程也许没有覆盖到，
　　而这些没有覆盖到的代码很可能就是一个风险点。
　　(2)熟悉模块原理后，还有一点就是易于分析软件模块的关联性。一个大型的软件，都是一些小模块的组合而成。软件越是大型，耦合就越大。&互相影响&就会越多，
　　设计用例单单是从模块本身考虑的话，很可能就会对其他模块造成风险。
　　4、用户场景和网上问题(测试点)
　　从用户的使用场景考虑，这些在一些设备比较重要。比如软件后期在一些真实的使用环境中使用。
　　还要就是从一些网上问题总结出来的，那些地方容易出错。在设计案例的时候需要考虑进去
　　5、测试用例的框架
　　我觉得一个测试用例的框架体现了一个在设计测试用例的整体思路。框架也是从大到小划分下来，可以是：
　　UI界面，功能，容错，兼容，等几大类，每个大类在根据软件的逻辑等进行划分成小类，最后细分到测试点。
　　6、测试步骤(测试技巧方法)
　　前面4点都是从测试点的角度考虑，测试用例在完成测试点外，下来就是测试步骤和测试结果啦。
　　测试用例可以写的很详细，也可以写的比较简单。看公司的要求，有些公司要去测试步骤很细很细，包括测试结果和测试步骤一一对应。
　　我个人不太认同这种做法，测试用例最重要的我认为是测试点。只要理解了测试目的后，下来的就是测试人员的执行工作啦。如果对一些非常娴熟的测试人员，他们一般
　　看测试用例的标题就是知道你测试目的了，具体的操作就是根据他们的进行测试。如果测试步骤写的很详细的话，一会很耗时间。你要考虑到文字语音的描述，以及一些前置步骤的操作，这也会导致案例有时候像个文章，而且过于详细的会限制执行人员的思维。
　　要求测试步骤写的很详细的公司，一般是怕执行人员的执行力不到位，导致没有理解案例的目的，导致漏测。一般出现在新员工对软件系统的不熟悉。
　　7、测试用例的一些思路
　　在设计案例中，我用的最多的是边界值，等价类，正常和异常的测试。下面是我想到的几个方面：(结合一些网上文章的观点)
　　一)从单个模块或者单个功能点考虑
　　(1)UI界面(易用性，提示信息，整体布局，色彩，中英文标点错别字)
　　(2)数据的多样性
　　有效数据
　　合法的无效数据(边界值)
　　非法和异常数据
　　各种数据的组合
　　(3)操作多样性
　　添加删除编辑查询
　　多用户的操作
　　(4)容量测试
　　(5)用户权限(使用权限)
　　(6)升级安装卸载(平滑升级)
　　(7)日志相关(包括调试日志)
　　(8)软件功能的逻辑划分
　　功能上划分未能覆盖的代码逻辑，可以添加灰盒用例;
　　(9)关联的功能
　　设计关联的测试的用例
　　(10)可靠性，容错性
　　(11)(浏览器，系统)
　　(12)性
　　(13)性能(这里的性能是指，单个模块或者子系统的性能)
　　测试用例首先要能覆盖所有功能需求点，然后搞懂软件处理逻辑，可以找一起看测试用例，把没有覆盖到的代码流程相应的补充用例。用例覆盖到这2点基本不会出现基本功能的问题。
　　在此基础上，可以进行一些可靠性，容错性，等用例的设计，测试下软件的稳定性。
原文转自：
评论列表（网友评论仅供网友表达个人看法，并不表明本站同意其观点或证实其描述）怎么编写测试用例（只提供一种思路）
关于用例，我们有太多的疑惑了，测试用例的依据？好的测试用例评估....等等。我们依据需求分析，依据开发文档，依据系统设计文档，甚至依据UI写测试用例，我们就真的足够了？不够，真的不够。需求在变，开发文档跟着变，设计文档也在改动，UI也在做变化，那我们的测试用例应该怎么写？
个人认为，一个好的、有效的测试用例，应该具备以下几个特征：
1．&&覆盖全面。测试的每个路径都涉及到，、界面测试、有性能要求的做、有安全要求的做（网络安全、通信安全..）等。
2．测试用例的后期维护时间短。测试用例写出来，不可能一成不变，根据系统的优化，测试用例都应该做相应的修改。针对需要修改的测试用例，我们修改了测试用例的哪些部分？测试前提、测试过程、测试数据、测试结果？如果四个方面都需要做修改，要么就是该功能完全变了，要么就是测试用例写的不够好。在系统做优化的时候，一般只需要修改测试数据就可以
3．对内的测试用例与对外的测试用例不一样。某些行业，测试用例需要随着系统一起交付用户使用。对内的测试用例，应该以寻求BUG为主，我们可以把过程写的流畅简单些，但是测试数据一定要充分；对外的测试用例，应该以指导用户参与测试为主，所以过程需要比对内的测试用例详细，但是测试数据可以减少。因为用户主要是想知道，这个系统是否可以使用，他不是真的为了给你找BUG。
4．同一个产品的不同项目，许多的测试用例可以公用的。所以，针对不同的项目编写测试用例，有许多我们拿以前的测试用例直接黏贴过来用，减少了许多写测试用例的时间。
针对以上几个特征，编写测试用例前，我们应该做哪些？我一般会花一些时间去看看需求文档、设计文档、开发文档；有机会就去找市场部的人交谈，在他们抽烟的时候，冒一根不够，就再冒一根，慢慢的问我想知道的问题；最好也和研发部的开发人员了解下情况，这个系统他们怎么看的，打算怎么做，有必要可以说说你的观点。
当这些前提你都做了，你完全可以写测试用例了，当然边写还是要边沟通，也许有新的发现呢？如果边写测试用例的时间不够，你没有太多的时间去做这么多的铺垫工作，也没有关系，你可以先把一些通用的测试用例写出来：登陆、增加数据、修改数据、查询数据等，然后把业务要求比较强的测试用例放在最后编写，这样我们既没有浪费时间，也可以按时交测试用例。
测试用例写出来，维护怎么办？测试用例的维护，写过测试用例的朋友都知道，大家都去嘟囔修改测试用例很无聊，首先它没有太多的技术含量（这个大家都不喜欢，好多人也认为测试没有技术含量），第二这个过程很繁琐和枯燥。如果想维护简单，在编写测试用例的时候你就应该考虑到这点。各项描述应该怎么写，通俗易懂而且是通用的是首选。举例：
测试前提：系统服务运行正常、，具有xiaoming这个用户，密码为999999
测试过程：
1.&&&&&&访问系统登录页面
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种），测试结果，我们登录系统为了做什么？没有权限怎么办？我们应该具有哪些权限？第一个用例就没有做说明，可以说，测试结果的说明是不全面的。
第二个测试用例，如果系统增加了需要输入验证码，我们在测试过程的第二步，只需要说明输入用户名、密码、验证码，测试数据我们不需要做变化，在结果分析里，增加说明：用户名、密码、验证码正确，准入，否则拒绝。
第二个测试用例，有个不足，就是测试数据不全面。我在编写测试用例时，针对这个测试用例，我有个测试数据的附件。【附件分为两部分，手工测试以及，手工测试我会有个详细的数据说明，并不是把所有的数据组合都列出来，而是详细的说明组合的方式方法，一共有多少种（包含边界值法以及特殊值等）；自动化测试的数据说明简单很多，写一个正则表达式搞定】。
按照第二个测试用例，我们的工作就不再是苦力了，而是智慧的苦力。我们不再是点点点，慢慢的我们知道哪些是主要关注的，哪些是次要关注的，我们应该怎么去设计数据等等。慢慢的，我们学会了思考，我们也真的进步了。
欢迎大家多提意见，我们一起进步。
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。请教功能测试用例怎么写???
本回答由提问者推荐
var sogou_ad_id=731547;
var sogou_ad_height=160;
var sogou_ad_width=690;您所在的位置： &
如何编写性能测试用例（1）
如何编写性能测试用例（1）
于涌/王磊/曹向志/高楼/于跃
人民邮电出版社
《精通软件性能测试与LoadRunner最佳实战》第7章LoadRunner常见问题解答，本章结合笔者工作经验、学员以及网上论坛经常提出的问题，总结了关于工具设置、工具使用、结果分析等问题的解决方案，旨在起到举一反三的作用，指导读者实际应用于工作当中。本节为大家介绍如何编写性能测试用例。
7.58& 如何编写性能测试用例（1）
1．问题提出
如何编写性能测试用例，性能测试结果如何命名？
2．问题解答
有很多刚刚做性能测试工作的同志，非常期望能够有一份性能测试用例设计模板可以参考，这里我给大家提供一份性能测试用例模板和结果命名等规范供大家参考。
表7-18中内容是本次性能测试中的命名规则及规范，性能测试实施严格按照该规范执行。
表7-18&性能测试命名规范表
【责任编辑： TEL：（010）】&&&&&&
关于&&&&的更多文章
本书在介绍软件性能测试概念的基础上，结合对实际测试案例的剖析
本书描述了黑客用默默无闻的行动为数字世界照亮了一条道路的故事。
作为虚拟化领域的后起之秀，微软最新发布的Windows Se
随着Unity 3D的迅猛发展，该游戏引擎通过不断优化与改
本书从核心实现和企业应用两个方面，由浅入深、由易到
本书是目前所能找到的最实用、最全面的Linux指南和参考手册，也是唯一一本提供以下全部内容的书籍：
更好更实用的示例覆盖了实
51CTO旗下网站}