好的测试用例是怎么写出来的?

　　测试用例(Test Case)是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求，是软件测试人员需要具备的基础能力。

　　好用例的标准

　　/是否可以发现Bug

　　设计测试用例的目的就是为了发现bug，如果bug都发现不了，怎么能称得上是一个好的测试用例呢?

　　/是否够高效

　　一个好的测试用例应该不止测试一个测试点，从而减少需要的用例总量。但也不能包含太多不想关的测试点，否则你这个用例就没法测试了，并且给开发的debug造成困难。

　　/是否够经济

　　这个测试用例执行起来是否容易，分析和debug是否要花太多代价，都是值得考虑的，毕竟咱也要站在组织的角度来看待测试这个事，公司是为了盈利而做这些事，而不是为了做测试而测试。

　　/是否有足够的扩展性

　　主要是考察测试用例在维护时是否要花费很大的代价。

　　测试用例的好处

　　/理清思路，避免遗漏

　　这里是我们认为最重要的一点，假如我们测试的项目大而复杂，我们可以把项目功能细分，根据每一个功能通过编写用例的方式来整理我们测试系统的思路，避免遗漏掉要测试的功能点。

　　/跟踪测试进展

　　通过编写测试用例，执行测试用例，我们可以很清楚的知道我们的测试进度。

　　/历史参考

　　在我们所做的项目中，也许会有很多功能是相同或相近的，我们对这类功能设计了测试用例，便于以后我们遇到类似功能的时候可以做参考依据。

　　/重复性

　　我们测试一个系统不是一个人测一遍就算测完的，需要多人反复的进行测试，那么我们就需要测试用例来规范和指导我们的测试行为。

　　测试用例方法

　　/等价类划分

　　在某个输入域的子集合，在该子集合中，各个输入数据对于揭露程序中的错误都是等价的。

　　假如有一个输入框要求输入1-10000个数，我们不可能用每一个数去试，我们输入5 和输入6去验证和揭露输入框的错误可以看做是等价的。

　　那么这个时候我们就可以随机的抽取一些数据来进行验证。如：10 、99、7777......

　　等价类分：有效等价类和无效等价类

　　输入框要求输入1-10000的数

　　有效等价类：可以输入1-10000之间的数来验证，如：2、5、99、8495......

　　无效等价类：可以输入1-10000之外的任意字符验证，如：20000、字母、下划线、特殊符号、空格、回车.....

　　/边界值

　　边界值是对等价类的补充，测试工作经验告诉我们，大量的错误是出在输入输出的边界价上。

　　我们还拿上面的例子，一个输入框要求输入1-10000之间的数。

　　我们要测它有没有超出这个范围，如：0、-1、-2、1000、10001.....等等，来判定是否超出了我们的范围。

　　/因果图

　　因果图方法最终生成的就是判定表，它适合于检查程序输入条件的各种组合情况。举个例子：原因：A=0，B=0，结果我就可以判定：A=B。

　　确切的说他是一种因果关系思想。它会无形中指导这我们的测试。

　　当然了，我们为了以免遗漏，可以把系统中的因果关系用图画出。不过系统大而复杂的话就是个体力活了。

　　/错误推测法

　　基于经验和直觉推测出系统可能存在的错误，从而有针对性的设计测试用例的方法。

　　/其它

　　设计测试用例的方法有很多，我们常用就上面几种，其它的方法还有：状态迁移图、流程分析法、正交验证法等等。

　　测试用例的格式与要素

　　一个测试用例应该包括：编号，标题，测试场景，测试步骤，预期结果。

　　当然还可加入一些它选项，如：优先级、测试阶段....

　　举例：

　　上面的格式取自《微软的软件测试之道》，仅供大家参考，一般项目管理系统自带的用例管理，有固定的格式，搜索、修改等功能，使用起来非常方便。

　　如：禅道项目管理、QC、bugfree 等等都带的有用例管理功能。

　　测试用例开始设计最优时间

　　当根据客户的需求整理出项目需求分析文档时，我们就可以根据需求文档来编写测试用例了。但是，一般我们(国内大多小公司)项目需求文档都非常“简陋”，所以，很难根据需求文档设计测试用例。

　　我们只有等到项目开发人员把项目开发出来，给我们系统文档、部署环境、数据库结构(如果系统牵涉到数据库的话)，我们根绝这些文档来设计测试用例。

　　什么情况下不适合写测试用例

　　/性价比低

　　如果一个功能我很快就测试完了，而且只需要测试一遍，但我们设计测试用例时却比较麻烦，花时间也长。

　　这个时候就没必要编写测试用例了。

　　/需求变动大且频繁

　　需求的功能变动非常频繁，而且变动很大，之前编写的测试用例根本没法使用，必须要重新编写，这个时候不建议自己做，

　　建议选择第三方测试机构帮忙，比如类似Testin的众包测试服务。

　　融入探索性测试思维

　　完全的执行测试用例时一件非常枯燥的事情，个人在执行测试用例时会做一些，其它的非常规性的操作，看系统是否会有相应的处理和提示。

　　我的一部分bug就是再这种非常规操作下发现的。

　　当然了真正的探索性测试需要对产品的深入了解，以及软件开发技术有一定的深度和宽度

　　成都软件测试培训哪家好，当然是成都达内培训，成都达内是一家专业的程序员培训机构，专注于网络营销课程，成都Linux培训，成都软件测试培训，成都php培训，成都java培训，成都安卓培训，成都会计实操培训，web前端开发，成都网络营销培训，成都it培训，成都编程培训，成都程序员培训等IT培训,专业的成都软件培训机构，专业师资授课，真实项目实战、零首付、低押金、名企就业，达内培训，成都软件测试培训学校www.cdtedu.com/pxkc/test/

(责任编辑：成都达内)