很高兴有这样一个机会与大家分享软件测试核心内容"测试用例设计技巧"，很多测试界的朋友写了很多年测试用例，但是从来不认可编写测试用例的作用与价值，我们为什么要编写测试用例，又如何编写有含量能够发现高优先级的bug？或者我干脆不编写用例照样能够将产品有效测试完成，并且发现产品上线之后也没见出现什么大的问题。
基于以上种种情况，是每个测试人员都曾考虑过的问题，Kitty老师跟大家谈谈编写测试用例的作用与价值，主要从以下几点来与大家讲解。
1.什么是测试用例？
为什么很多同学不愿意编写测试用例？因为编写测试用例很枯燥繁琐更消耗时间，而且如果自己所在的项目组产品或者项目时间比较紧急，根本没有太多时间来顾及编写测试用例，或者在有些同学看来，编写测试用例根本没有价值，每次程序迭代版本更新太过频繁，基本上不会按照测试用例的条数一条条来执行覆盖测试，甚至很多同学做了很多年测试，都不知道什么是测试用例，接下来我们首先了解学习一下测试用例的基本概念。
测试用例定底指：为某个特殊功能模块目标而编制的一组具有代表性的测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求的能力。
通俗的理解为"测试执行过程中使用的案例。帮助测试人员有序的执行测试工作"，让测试工作更标准规范化。
2.编写测试用例的目的？
将软件测试的行为转化为可管理的模式，同时测试用例也是将测试工作具体量化的工作方法之一。
那我们为什么要编写测试用例呢？写测试用例和不写测试用例有什么区别？编写测试用例的价值如何体现？接下来与大家详细分享。
首先编写测试用例的目的是为了保证软件产品的质量能够满足用户的潜在需求的能力。
大家都知道软件是由一个很大的软件工程组成的，从这个工程的立项到结项需要经历这些过程，依次是：用户市场需求调研、需求分析说明书、数据库设计说明书、概要设计说明书、详细设计说明书、编码这是整个软件开发过程的相关活动。
接下来就会触发软件测试过程活动，依次是单元测试、集成测试、系统测试、验收测试。根据V模型的构建过程，大家都知道这些过程活动是由不同的成员来完成相关工作，在不同的阶段会不会出现问题?那是必然会有问题，那作为一名测试人员，又如何保证软件产品的质量呢？
我们可以通过编写测试用例来覆盖开发过程的每一个需求模块的功能点，跟进每个需求点的代码实现过程，从而更好的保证软件产品的质量。
难道有了测试用例质量就一定好吗？不一定，为什么呢？这要看你编写测试用例的能力与技巧方法是否用对了。
但是，如果你不编写测试用例我可以肯定的告诉你，产品的质量肯定是没有保证的，为什么呢？
因为你自己不去编写用例，不去细细分析理解产品的业务需求，甚至那些模块你已经测试好了，有没有问题你可能心中都没底，又或者领导让你编写一个测试计划来评估本次产品测试的时间，你可能仅仅凭敲脑袋来定数。
这其实就是对测试工作的一种敷衍，不写测试用例在你执行测试的过程中如果你对整个系统的核心业务流程和逻辑过程都非常清晰前期影响并不大，但是随本次短期不写测试用例，到产品模块增加到一定的程序，质量自己都无法保证，甚至在编写测试报告的时候让你填写本次迭代的测试用例总数据，失败用例与成功用例都仅仅是猜想没有依据的写上去，这是对本职工作缺乏素养的一种表现，这样的测试工作做起来很是劳神费心。
3.如何编写测试用例？基于项目实践详解。
测试分为：黑盒测试与白盒测试，一般黑盒测试是基于功能的一种测试，白盒测试是基于代码层面的一种测试。但是他们编写测试用例的方法都是使用：等价类、边界值、因果图、错误推测法、场景分析法、正交分解法等等常用方法，今天咱们主要基于等价类与边界值来与大家详解讲解，这两种方法在测试工作中也是非常常见的。
什么是等价类？等价类分为：有效的等价类与无效的等价类两种。
等价类是指非彼即此，有效的等价类指：符合用户的需求、合理的、可执行的。
无效等价类将与有效等价类概念相反。
接下来我们将以案例实践与大家详细讲解。
假设给你一个用户登录的功能点"用户名的长度由6-10位数字组成"，密码长度为8-12位数字。
如何划分等价类区间？
有效等价类：用户名长度在6-10，为数字，6、7、9、10。
无效等价类：用户名长度小于6位，大于10位，非数字的字符：字母、中文、英文、空格、特殊字符，5、11。
边界值方法：作为等价类方法的一种补充。
咱们还是基于登录功能点来与讲解，划分边界值的点为：5、6、7，9，10，11，为什么要这样来划分，大家通过这个案例想必都能猜想出等价类方法与边界值方法的差异性，如果仅仅使用边界值方法对于非数字的相关功能无法覆盖全面，如果结合等价类方法就能更全面的覆盖以上内容，一般来说边界值主要针对数值范围的边界数据进行测试的一种方法，并会对特殊字符进行合理的覆盖。
4.用例维护
修改了某些功能之后，用例的执行和结果发生了变化。需要对用例的内容进行更新。为什么用例编写完成还要进行维护？如果仅仅只编写用例不对用例进行维护这等同于没有用例。
产品在不断的迭代，每次迭代都会有新增功能点需要加上用例，有减少模块需要将用户删除，或者在执行测试的过程中发现有未考虑到的相关功能用例都需要及时进行添加，让我们的用例与产品需求相一致，这样的用例才能产生价值，才能真正为我们所用，达到完整覆盖用户需求的目的，从而更好的保证软件产品质量，帮助我们升值加薪，迎娶白富美，从而达到人生巅峰。
综上所述，今天主要花一点时间与大家分享编写测试用例的作用与价值，希望通过本次课程能够帮助大家提升对测试用例的认知感，也能更好的在项目或者产品中发挥自己编写测试用例的价值，更好的为产品或者项目服务，开发出更优质的产品，帮助企业提升品牌信誉度。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
