测试用例设计如何提高测试覆盖率.docVIP

测试用例设?计_如何提?高测试覆盖?率 一、测试用例的?切面设计 　　所谓测试切?面设计，其实就是测?试用例大项?的划分。测试用例划?分的经典方?法是瀑布模?型，也就是从上?到下，逐渐细分，大模块包括?小模块，小模块包括?更小的模块?。但仅仅如此?是不够的，我们还要从?更多的角度?切入系统，从不同的角?度把系统切?分成一块一?块的，来进行测试?，从而确保测?试大项的完?整性。 　　1、功能点切面? 　　这是最常见?的切面，通常我们认?为页面上的?一个按钮就?是一个功能?点。然后我们可?以根据功能?的复杂程度?，按每个功能?;或一个功能?点分多页;或多个功能?点合成一页?来进行用例?的撰写。 　　2、特定切面 　　除此以外，还有一种特?定切面的划?分方法，也是用例撰?写时经常会?用到的。所谓的特定?切面，就是忽略掉?表面上的功?能点，而关注测试?对象的某一?个面。比如我们的?内部管理系?统提供了销?售录入导入?、注册录入导?入等功能，从菜单划分?上对应了七?八个功能点?。但这些功能?处理后台有?个共同的处?理项就是授?权记录的生?成，这时我们就?可以把“授权记录生?成”单独拿出来?做一个测试?项，而在其它测?试项中涉及?这一部分的?用例就不必?再一一撰写?。此外象一些?界面共通的?操作用例单?独写成一页?，也是一种特?定切面。所以如果说?将用例按功?能点划分是?一种纵向划?分法，那么特定切?面就是从横?向的角度分?析所得到的?切面。在普通功能?点划分上再?根据实际情?况设计特定?切面，可以使我们?的用例阅读?性、理解性、操作性更强?。 　　3、隐含切面 　　这类用例是?最容易被忽?略的。它往往不是?明显的某个?功能项，可能是功能?项后台的隐?含处理，也可能是多?个功能项之?间的关联处?理，甚至可能是?在某种特定?情形下的处?理。这都需要测?试人员通过?对软件的学?习了解，来进行挖掘?。 　　(1)、后台功能 　　常见的如一?些定时自动?启动的服务?;以及某种特?定情况下自?动执行的操?作等。它们在界面?上往往是不?体现的，但许多在需?求设计中还?是会提到，也有一些比?较细小的功?能可能会被?忽略，就需要测试?人员根据对?项目的了解?程度来进行?挖掘。所以说一个?熟悉项目的?和一个不熟?悉的测试人?员，写出来的用?例就完全是?两个层次的?。 (2)、完整业务流?程的测试 　　我们都知道?测试用例的?设计是从点?、线、面三个层次?去考虑的。完整的一个?功能项是线?，其中的某个?按钮是点，多个相关功?能结合成完?整业务流就?是面。从实际来看?这类用例往?往被我们忽?略。 　　事实上目前?公司的软件?本来都是业?务型应用软?件，将各种功能?从业务流中?切割出来单?独写用例，肯定也会有?涉及到整体?流程的情况?。若不加以区?分，将细节与全?局搅在一起?，不仅思路混?乱，也容易考虑?不周。因此在系统?测试阶段，建议用例设?计要有分有?合，针对具体功?能的就只围?着这个功能?转：而在业务流?程测试项中?，再完全从整?体的业务流?角度出发去?考虑用例，这样不仅不?容易产生疏?漏，用例阅读与?执行也更清?楚。 　　(3)、某种特定情?况下的系统?运行 　　这类用例的?设计往往与?系统实际业?务情况密不?可分。比如财务软?件，通常需要在?月尾一天、月头一天、年尾一天、年头一天，对所有相关?功能中的日?期处理进行?测试;又比如WI?N 2000环?境开发测试?的系统，要测试在9?8、XP、2003等?操作系统下?是否能运行?自如;再有如存在?大量动态图?片视频等的?网页，在普通网速?下的展现速?度等等。总之就是要?尽可能从实?际应用的角?度出发考虑?，来进行测试?补充。 　　(4)、其它相关系?统 　　 即指在当前?项目中直接?使用的其它?成果，包括公司自?有的系统模?块、组件、函数;以及购买或?免费得到的?一些功能组?件。对这些内容?需要预先与?开发组长等?讨论清楚，是否需要测?试。若时间紧张?或其它原因?决定不测的?，应在测试计?划中说明。若需要测试?的，则具体可根?据实际情况?来设计，可以是通过?系统某个功?能的测试来?涉及，此时就不需?要单独划分?测试项;若相对比较?独立的，也可以通过?单独的测试?项来对其专?门进行测试?。 　　(5)、除功能测试?外的其它测?试类型 　　包括可靠性?、安全性、恢复性、配置安装测?试等等，这些测试类?型都是一个?单独的测试?项。 　　所谓好的开?始是成功的?一半，保证测试项?划分的完整?、合理、正确，会直接影响?到本次测试?的成效。通常建议该?阶段工作要?花1-2天的时间?来考虑，并要在测试?过程中随着?对软件的深?入了解，不断进行调?整补充。可千万不要?认为把分析?设计中的功?能模型图搬?搬过来就可?以了