如何肯定个人测试用例覆盖全面－测试面试题

 

测试用例的设计－提升测试覆盖率

前言

说到测试用例的设计，我想每一个有过测试经历的测试工程师都会认为很简单，不就是：按需求或概要设计，获得软件功能划分图，而后据此按每一个功能，采用等价类划分、临界值、因果图等方法来设计用例就好了。

但事实上撇开测试数据的设计不谈，仅就测试项来讲，咱们发现，对同一个项目，有经验的测试人员，在写用例或测试时总会有更多的测试考虑点，从而发现更多的问题；而有些测试人员测试用例的撰写却只有那么三板斧，表面看好象已经把页面全部信息的测试都考虑到了，实际上却仍是遗漏了大量测试覆盖点，致使其测试出来的程序老是比较脆弱。

究其缘由，我以为仍是测试用例的撰写水平不到位，更确切地说是测试用例的覆盖度过低。说实话我认为系统测试用例真正作到100％覆盖是很难的。难道说按设计中的功能划分，每一个功能都写到了这个用例就覆盖完整了？错，这还远远不够。由于咱们知道还有大量的内部处理、转换、业务逻辑、相互影响的关系等都是需求或设计中所不会点明的。而这些一方面须要靠测试人员对项目自己的了解，另外一方面要靠测试人员的经验，来一一找到这些隐藏点并予以测试，才能真正地保证咱们的测试覆盖度。

因此本文抛开具体的测试数据设计方法，主要从测试覆盖度的角度来介绍用例设计时，如何才能考虑地更周全，如何才能将隐藏的测试项一一找出，从而使咱们的测试更全面更完整。

想法虽然美好，但是毕竟每一个测试的项目都是各不相同，针对不一样项目咱们的经验也会告诉给咱们不一样的想法，这些想法一般很感性，很难用严密的逻辑理论来把它升华。所以本文的内容还是很简陋且不成熟，只是但愿能以本文为砖，引发你们的思考，一块儿来补充完善，以使咱们的测试用例设计水平不断提升。

正文

1、测试用例的切面设计

1、功能点切面

2、特定切面

3、隐含切面

（1）、后台功能

（2）、完整业务流程的测试

（3）、某种特定状况下的系统运行 

（4）、其它相关系统

（5）、除功能测试外的其它测试类型

2、详细用例的设计

1、功能切面表面用例设计

（1）、具体功能测试

（2）、组合操做的测试

（3）、GUI界面的测试

（4）、数据初始化状况测试

（5）、业务需求实现是否正确

2、功能切面隐含测试项用例设计：

（1）、数据完整性的测试

（2）、后台的特殊处理

（3）、功能业务之间的关联与转换

（4）、从设计实现发掘测试点

（5）、并发操做时的测试

3、特定切面用例设计

4、隐含切面用例设计

（1）、无界面的后台功能

（2）、与业务流相关的测试

（3）、其它测试类型

3、测试数据的设计

1、测试用例的切面设计

所谓测试切面设计，其实就是测试用例大项的划分。测试用例划分的经典方法是瀑布模型，也就是从上到下，逐渐细分，大模块包括小模块，小模块包括更小的模块。但仅仅如此是不够的，咱们还要从更多的角度切入系统，从不一样的角度把系统切分红一块一块的，来进行测试，从而确保测试大项的完整性。

1、功能点切面

这是最多见的切面，一般咱们认为页面上的一个按钮就是一个功能点。而后咱们能够根据功能的复杂程度，按每一个功能；或一个功能点分多页；或多个功能点合成一页来进行用例的撰写。

2、特定切面

除此之外，还有一种特定切面的划分方法，也是用例撰写时常常会用到的。所谓的特定切面，就是忽略掉表面上的功能点，而关注测试对象的某一个面。好比咱们的内部管理系统提供了销售录入导入、注册录入导入等功能，从菜单划分上对应了七八个功能点。但这些功能处理后台有个共同的处理项就是受权记录的生成，这时咱们就能够把“受权记录生成”单独拿出来作一个测试项，而在其它测试项中涉及这一部分的用例就没必要再一一撰写。此外象一些界面共通的操做用例单独写成一页，也是一种特定切面。因此若是说将用例按功能点划分是一种纵向划分法，那么特定切面就是从横向的角度分析所获得的切面。在普通功能点划分上再根据实际状况设计特定切面，可使咱们的用例阅读性、理解性、操做性更强。

3、隐含切面

这类用例是最容易被忽略的。它每每不是明显的某个功能项，多是功能项后台的隐含处理，也多是多个功能项之间的关联处理，甚至多是在某种特定情形下的处理。这都须要测试人员经过对软件的学习了解，来进行挖掘。

（1）、后台功能

常见的如一些定时自动启动的服务；以及某种特定状况下自动执行的操做等。它们在界面上每每是不体现的，但许多在需求设计中仍是会提到，也有一些比较细小的功能可能会被忽略，就须要测试人员根据对项目的了解程度来进行挖掘。因此说一个熟悉项目的和一个不熟悉的测试人员，写出来的用例就彻底是两个层次的。

 

（2）、完整业务流程的测试

咱们都知道测试用例的设计是从点、线、面三个层次去考虑的。完整的一个功能项是线，其中的某个按钮是点，多个相关功能结合成完整业务流就是面。从实际来看这类用例每每被咱们忽略。

事实上目前公司的软件原本都是业务型应用软件，将各类功能从业务流中切割出来单独写用例，确定也会有涉及到总体流程的状况。若不加以区分，将细节与全局搅在一块儿，不只思路混乱，也容易考虑不周。所以在系统测试阶段，建议用例设计要有分有合，针对具体功能的就只围着这个功能转：而在业务流程测试项中，再彻底从总体的业务流角度出发去考虑用例，这样不只不容易产生疏漏，用例阅读与执行也更清楚。

（3）、某种特定状况下的系统运行

这类用例的设计每每与系统实际业务状况密不可分。好比财务软件，一般须要在月尾一天、月头一天、年尾一天、年头一天，对全部相关功能中的日期处理进行测试；又好比WIN 2000环境开发测试的系统，要测试在98、XP、2003等操做系统下是否能运行自如；再有如存在大量动态图片视频等的网页，在普通网速下的展示速度等等。总之就是要尽量从实际应用的角度出发考虑，来进行测试补充。

（4）、其它相关系统

即指在当前项目中直接使用的其它成果，包括公司自有的系统模块、组件、函数；以及购买或免费获得的一些功能组件。对这些内容须要预先与开发组长等讨论清楚，是否须要测试。若时间紧张或其它缘由决定不测的，应在测试计划中说明。若须要测试的，则具体可根据实际状况来设计，能够是经过系统某个功能的测试来涉及，此时就不须要单独划分测试项；若相对比较独立的，也能够经过单独的测试项来对其专门进行测试。

（5）、除功能测试外的其它测试类型

包括可靠性、安全性、恢复性、配置安装测试等等，这些测试类型都是一个单独的测试项。

所谓好的开始是成功的一半，保证测试项划分的完整、合理、正确，会直接影响到本次测试的成效。一般建议该阶段工做要花1-2天的时间来考虑，并要在测试过程当中随着对软件的深刻了解，不断进行调整补充。可千万不要认为把分析设计中的功能模型图搬搬过来就能够了。

2、详细用例的设计

划分好了测试项，接着就是针对各个测试项，考虑具体的测试用例了。根据测试项的特色，测试用例的设计角度也有所不一样。下面咱们就来看看一般的功能点测试用例，该从哪些角度出发来进行设计：

1、功能切面表面用例设计

（1）、具体功能测试

根据需求分析设计，按页面提供的各个功能项，采用黑盒测试的各类方法，设计用例。好比页面提供了增、删、改、查功能，那么这四个功能是否正确实现就是我要验证的。这是最简单、最基本，同时也是必须的测试用例，一般咱们的编码人员自测也就是作到这个程度。

（2）、组合操做的测试

这是从上一角度扩展出来的，相对而言也是编码人员不会去测试的，因此须要测试人员多做考虑。

所谓组合操做测试，也就是选择某几个操做项，按必定的顺序进行操做，验证系统不会出现意外错误。固然要将全部功能项排列组合一遍来测试不只没必要要，也是不可能的。因此具体要将哪些功能项进行结合，要按怎样的步骤来操做，仍是须要测试人员根据实际状况来做设计（因此说在IT业人才就是一切呀，呵呵：）。

通常来讲咱们会考虑功能项之间的数据是否会存在关联，如有就须要考虑这种组合了。常见的如查询功能，须要将各条件逐一累加进行测试；增完的数据可否改，改完可否删，删完可否再增，这之间可否查询到正确结果；按钮的连续屡次点击会否出现异常；有严格先后顺序要求的几个操做，尝试颠倒顺序去操做，系统可否控制等等。

不只在某功能内部，扩展到有关联的多个功能项之间，一样有组合操做测试的存在。如申报完了能才反馈；如申报成功或失败后再尝试申报等。固然对于这类用例既能够写到某个功能切面中，也能够单独写到完整业务流程的切面中，这就取决于可能涉及用例的数量了，若关系比较复杂，固然是单独写比较好；若也就是三五个用例数，那就直接在某个功能的用例中补充好了。

 

（3）、GUI界面的测试

这类测试是测试人员的强项，具体测试项目如限长、非法输入等等，就没必要赘述了。要提醒的是在测试时，必定要从实际使用者的操做习惯出发。要知道界面原型所能肯定的也只是页面的摆放显示，而实际操做时的控制实现还是编码人员自行实现的，即便有编码指南，其所及范围也是十分有限。而许多编码人员在用户操做方便性上的考虑每每差强人意。因此测试人员就必需要把好这一关。

（4）、数据初始化状况测试

不应为空的数据是否有校验；该有默认值的数据默认值是否正确；引用其它功能生成的数据，是否会实时刷新；页面关闭或系统重启后，数据的初始化设置等都是这类用例。

（5）、业务需求实现是否正确

这类问题每每是因为咱们的需求说明欠详细，而编码人员的需求了解程度又较低形成。做为测试人员天然要对需求进行深入研究，来对软件实现进行把关。这里常见的一些关注点有：

      数据的长度、类型控制是否合理（好比控制纳税人识别号只能为数字，但实际业务中是会有字母出现的）；

      业务逻辑控制是否合理（好比某数据项不提供修改，但实际业务中该数据项常常会须要改动）；

      提供的实现方式是否合理（好比只在某一页面提供某数据的获取功能，但根据业务划分有些人员不能操做此页面，却必需要能看到该数据）；

      所作的数据控制是否合理（好比必须在A功能中新增数据，而后才能在B功能中操做，但实际业务中有可能会出现相反操做）；

      所作的数据控制是否完整（如受权的方式有普通按月、有买断、有按数量控制，那么当同一企业尝试同时存在以上几种受权方式时，系统是否能有必要的控制）；

      还有其它一些操做细节上的知足（如业务上须要批量操做的数据有否提供批量操做功能、导入失败的结果文件是否能修改后直接再导入等）。

对于不知足的需求，经开发组长、需求经理等确认不做修改的，就要做为软件的缺限或限制在测试报告中进行说明民。

2、功能切面隐含测试项用例设计：

（1）、数据完整性的测试

当某数据被其它功能引用；或当前功能要引用其它来源的数据，就会涉及到数据完整性的测试。最多见的如被引用的数据删除了，或关键字被修改了，引用的数据会否出错；两个途径进入的数据会否冲突或重复；此外还有由于相关的几个功能由不一样人员编码，从而致使彼此的控制不一致，如A功能进入的数据在可容许的极端状况下，到B功能中引用会否异常（最多见如用户名录入时容许长度10，但引用到某个单子填写时容许长度是8，此时就会异常了）。

（2）、后台的特殊处理

是指某功能除了表面所见之外的程序处理。好比订单录入，表面所见的就是订单的保存，但后台还会有重复数据的判断、非法数据的处理、业务逻辑上冲突状况的处理以及其它种种根据需求设计所特有的处理。又好比备份功能，在备份前可能有数据的清空、备份目录的清空、备份目标是否存在的校验、备份文件重复时的处理等等。相似这些在分析设计中就未必会写全了，仍是要测试人员多花心思去思考挖掘。

（3）、功能业务之间的关联与转换

相关联的几个功能之间数据的传递，会否产生影响。好比新增录入的某种特殊字符，要查询时会引发查询SQL语句异常；又如某下载文件名中存在中文等字符，下载时因为编码问题致使乱码的出现；再有报表填写时到小数点后四位，生成报文时会不会被忽略成两位了等等。象这种问题，一般只能是在每一个功能设计用例时，尽可能保证用例中的数据能涉及到容许范围的各类状况，即充分运用等价类划分+边界值的方法设计出各类“稀奇古怪”的数据，并需验证这些数据从头流到尾，都仍是能保持其正确性，而不只仅是在当前功能中正确。

（4）、从设计实现发掘测试点

这个就是咱们测试中最难捉的BUG了，它每每是由编码人员本身在编码时创造出来的，连设计人员都不会知道。

好比内部管理系统中，正常的产品，其类别一般是2位数字；若是是模块，其类别就以产品代码来取代。这时如何来判断该产品是模块呢？最保险的固然是校验其产品类别字段的值可否在产品表中找到；也有比较简单的方法就是直接判断类别代码大于2位仍是小于等于2位。此时若能确切知道采用的是哪一种实现方法，就能够直接找到其漏洞所在。好比采用后一种方法，当产品类别长度变化时，明显系统会出错。那么即便确认该实现方式不改，测试人员也应将其做为限制写入测试报告，。让你们知道这个产品类别长度是不能随意变化的。

而让人郁闷的是，相似这样的实现，有太多的编码人员都是随性处理的，它们细而隐蔽，在系统数据正常状况下根本不会被发现；而在漫漫的软件使用道路中，因为需求变动等缘由对原有一些设计作维护变化，这种问题就会忽然暴发出来让人措不及防。因此要杜绝这类漏洞，除了测试人员要作土拨鼠，不停地对软件各功能的实现细节进行挖掘外，也要多给编码人员灌输完美实现的理念，多用复杂但抗压性高的代码，来替代简单但依赖性强的代码。

（5）、并发操做时的测试

即两个或多个用户同时操做同一功能时，会否引发数据的混乱。一般在C/S结构下，若是有同时操做的可能，是须要做此测试的；而在B/S结构下因为其特殊性，此问题一般难以解决。除非就是某用户一旦使用过某功能后，在必定时间内锁定不容许再用，但这也会带来实际应用中的不便，因此除非是特别核心的数据，通常咱们也不会去作此控制，固然对于可能出现的并发冲突也就做为系统的限制进行遗留了。

3、特定切面用例设计

所谓特定切面，其实就是从另外一个角度切割出来的用例面，因此具体的用例撰写方式其实与功能切面是一致的。

4、隐含切面用例设计

隐含切面分如下几种状况：

（1）、无界面的后台功能

对这类测试项，须要经过参数设置、代码调用等方式来实现测试，但具体的测试设计其实与普通功能测试并没有二致。这里要注意，由于测试时每每前台、后台是分开来分别进行的，而实际运行时二者极可能是交集的，因此测试时要多注意后台功能的执行与前台的一些功能执行会否产生冲突？好比后台有个文件搬运的服务，那有没有可能在前台文件生成过程当中，后台执行文件搬运了？如有可能就要注意会否出现问题了。

（2）、与业务流相关的测试

这类测试用例的设计，就要从完整业务角度来设计数据了。从理论上来说，应该要将各个功能可能出现的各类数据排列组合到一块儿，按业务流程逐一进行测试。但实际上咱们不可能去作全覆盖。因此设计这类用例时，最好有一张草稿，将全部相关功能按业务流程逐一列示，而后再将每一个功能可能出现的特定数据一一标上，最后将图中最可能出现的、最可能出错的、最核心的数据取出来，分别组合成一个个完整的业务数据用例，来进行测试。这样就能够按清晰的思路，找出最实用、最有效的测试数据。

（3）、其它测试类型

这一类的测试一般都有其特定的方法。如要测可靠性就准备大量数据不停地执行；要测安全性就考虑数据的加密、数据的传输、数据的破坏；恢复性通常从网络、电源方面着手；配置安装则根据系统可支持的配置，搭建相应环境进行功能验证，此处的验证也要掌握技巧，即要多测试那些涉及到：数据库读写、磁盘文件读写、文件上传下载、文件加解密、数据统计、图表展示、打印等方面的功能。

 

3、测试数据的设计

每个测试思路最终都要转化成具体的数据才能来执行。关于测试数据设计的方法也不外乎那几种，就再也不赘述了。此处单就一些常常易犯的错误，提出一些注意点，做为用例数据设计时的参考：

1、尽可能避免可能出现歧义测试结果的数据：即你设计的数据必须能惟一正确地反映出你所但愿测试的结果。好比一组测试数据，有可能获得结果A或结果B，此时单用此数据来测试预期结果为A的用例，那明显就产生了歧义。

2、对于不便具体列示的数据，则必须详细描述其各项特性：有时咱们在设计用例时为节约时间，不必定要到具体的一个数值，这也是容许的，但前提是你必需要详细描述清楚你要测试的数据特性。好比数据库字段限长20，要测试超长数据时，能够描述为：尝试输入长度为21位的半角英文字符；尝试输入长度为19位的半角英文字符，而后切换到中文全角再输入一位全角字符等。千万不能写成：尝试输入超长字符，由于这只能是测试方案，做为方案是能够这样写，但到用例阶段，必需要是具体的、明确的、可操做的。

3、测试数据的设计必须有明确目的性：即测试数据是从测试方案衍生而来的。如上例测试方案是测超长字符输入控制，因此测试数据就要根据具体字段长度来录入超长数据，若是一味录入长15位、长16位的数据那就没意义了。好的测试数据是能够同时针对多个测试方案的，此时能够在用例边注明一下该数据的测试目的，由于随着时间推移，对着具体的数据你也许会忘了它究竟是测什么的，而这对你最后总结测试，查验测试覆盖率是很是不利的，因此随时记下你的思路想法吧，好记性不如烂笔头。

4、测试数据可省略描述：测试数据描述以能让人看懂为准则。因此写用例时当碰到连续几个用例，仅某几个关键数据值改动，其他均是同样的状况下，没必要每一个用例都要重复描述全部数据，能够在第一个用例描述完整以后，其他用例中仅列示不一样的数据，并标明其他数据同上第X个用例，便可。这样测试时仍能复原测试数据，且该用例的测试目的一眼就明，增长了用例的清晰性。

至些，我根据测试用例设计的顺序，从测试数据的切面设计（即测试项划分），到详细测试用例设计，再到测试数据设计三个层面，逐一介绍了如何来提升测试用例的覆盖度。由于具体项目中的具体状况太多，以上叙述的内容也只能是管窥蠡测。至于其中的疏漏错误之处应也不免，只但愿各位阅后能打开思路，从本身多年的测试经验中多总结、提炼出一些想法思路，进一步补充完善这个文档，使你们的测试用例设计能力都能进一步提高。