测试用例的设计-提高测试覆盖率.docx

测试用例的设计-提高测试覆盖率.docx

ID:59149679

大小:25.40 KB

页数:10页

时间:2020-09-11

测试用例的设计-提高测试覆盖率.docx_第1页
测试用例的设计-提高测试覆盖率.docx_第2页
测试用例的设计-提高测试覆盖率.docx_第3页
测试用例的设计-提高测试覆盖率.docx_第4页
测试用例的设计-提高测试覆盖率.docx_第5页
资源描述:

《测试用例的设计-提高测试覆盖率.docx》由会员上传分享,免费在线阅读,更多相关内容在教育资源-天天文库

1、说到测试用例的设计,我想每个有过测试经历的测试工程师都会认为很简单,不就是:按需求或概要设计,得到软件功能划分图,然后据此按每个功能,采用等价类划分、临界值、因果图等方法来设计用例就行了。但事实上撇开测试数据的设计不谈,仅就测试项来说,我们发现,对同一个项目,有经验的测试人员,在写用例或测试时总会有更多的测试考虑点,从而发现更多的问题;而有些测试人员测试用例的撰写却只有那么三板斧,表面看好象已经把页面所有信息的测试都考虑到了,实际上却还是遗漏了大量测试覆盖点,导致其测试出来的程序总是比较脆弱。究其原因,我

2、觉得还是测试用例的撰写水平不到位,更确切地说是测试用例的覆盖度太低。说实话我认为系统测试用例真正做到100%覆盖是很难的。难道说按设计中的功能划分,每个功能都写到了这个用例就覆盖完整了?错,这还远远不够。因为我们知道还有大量的内部处理、转换、业务逻辑、相互影响的关系等都是需求或设计中所不会点明的。而这些一方面需要靠测试人员对项目本身的了解,另一方面要靠测试人员的经验,来一一找到这些隐藏点并予以测试,才能真正地保证我们的测试覆盖度。所以本文抛开具体的测试数据设计方法,主要从测试覆盖度的角度来介绍用例设计时,

3、如何才能考虑地更周全,如何才能将隐藏的测试项一一找出,从而使我们的测试更全面更完整。想法虽然美好,可是毕竟每个测试的项目都是各不相同,针对不同项目我们的经验也会告诉给我们不同的想法,这些想法通常很感性,很难用严密的逻辑理论来把它升华。因此本文的内容仍是很简陋且不成熟,只是希望能以本文为砖,引起大家的思考,一起来补充完善,以使我们的测试用例设计水平不断提高。正文一、测试用例的切面设计1、功能点切面2、特定切面3、隐含切面(1)、后台功能(2)、完整业务流程的测试(3)、某种特定情况下的系统运行(4)、其它相

4、关系统(5)、除功能测试外的其它测试类型二、详细用例的设计1、功能切面表面用例设计(1)、具体功能测试(2)、组合操作的测试(3)、GUI界面的测试(4)、数据初始化情况测试(5)、业务需求实现是否正确2、功能切面隐含测试项用例设计:(1)、数据完整性的测试(2)、后台的特殊处理(3)、功能业务之间的关联与转换(4)、从设计实现发掘测试点(5)、并发操作时的测试3、特定切面用例设计4、隐含切面用例设计(1)、无界面的后台功能(2)、与业务流相关的测试(3)、其它测试类型三、测试数据的设计 一、测试用例的切

5、面设计所谓测试切面设计,其实就是测试用例大项的划分。测试用例划分的经典方法是瀑布模型,也就是从上到下,逐渐细分,大模块包括小模块,小模块包括更小的模块。但仅仅如此是不够的,我们还要从更多的角度切入系统,从不同的角度把系统切分成一块一块的,来进行测试,从而确保测试大项的完整性。1、功能点切面这是最常见的切面,通常我们认为页面上的一个按钮就是一个功能点。然后我们可以根据功能的复杂程度,按每个功能;或一个功能点分多页;或多个功能点合成一页来进行用例的撰写。2、特定切面除此以外,还有一种特定切面的划分方法,也是用

6、例撰写时经常会用到的。所谓的特定切面,就是忽略掉表面上的功能点,而关注测试对象的某一个面。比如我们的内部管理系统提供了销售录入导入、注册录入导入等功能,从菜单划分上对应了七八个功能点。但这些功能处理后台有个共同的处理项就是授权记录的生成,这时我们就可以把“授权记录生成”单独拿出来做一个测试项,而在其它测试项中涉及这一部分的用例就不必再一一撰写。此外象一些界面共通的操作用例单独写成一页,也是一种特定切面。所以如果说将用例按功能点划分是一种纵向划分法,那么特定切面就是从横向的角度分析所得到的切面。在普通功能点

7、划分上再根据实际情况设计特定切面,可以使我们的用例阅读性、理解性、操作性更强。3、隐含切面这类用例是最容易被忽略的。它往往不是明显的某个功能项,可能是功能项后台的隐含处理,也可能是多个功能项之间的关联处理,甚至可能是在某种特定情形下的处理。这都需要测试人员通过对软件的学习了解,来进行挖掘。(1)、后台功能常见的如一些定时自动启动的服务;以及某种特定情况下自动执行的操作等。它们在界面上往往是不体现的,但许多在需求设计中还是会提到,也有一些比较细小的功能可能会被忽略,就需要测试人员根据对项目的了解程度来进行挖

8、掘。所以说一个熟悉项目的和一个不熟悉的测试人员,写出来的用例就完全是两个层次的。 (2)、完整业务流程的测试我们都知道测试用例的设计是从点、线、面三个层次去考虑的。完整的一个功能项是线,其中的某个按钮是点,多个相关功能结合成完整业务流就是面。从实际来看这类用例往往被我们忽略。事实上目前公司的软件本来都是业务型应用软件,将各种功能从业务流中切割出来单独写用例,肯定也会有涉及到整体流程的情况。若不加以区分,将细节与全局搅在一起,不

当前文档最多预览五页,下载文档查看全文

此文档下载收益归作者所有

当前文档最多预览五页,下载文档查看全文
温馨提示:
1. 部分包含数学公式或PPT动画的文件,查看预览时可能会显示错乱或异常,文件下载后无此问题,请放心下载。
2. 本文档由用户上传,版权归属用户,天天文库负责整理代发布。如果您对本文档版权有争议请及时联系客服。
3. 下载前请仔细阅读文档内容,确认文档内容符合您的需求后进行下载,若出现内容与标题不符可向本站投诉处理。
4. 下载文档时可能由于网络波动等原因无法下载或下载错误,付费完成后未能成功下载的用户请联系客服处理。