白盒测试用例设计过程（精选5篇）
白盒测试用例设计过程 篇1
测试用例设计步骤
设计测试案例的时候，需要有清晰的测试思路，对要测试什么，按照什么顺序测试，覆盖哪些需求做到心中有数。测试用例编写者不仅要掌握软件测试的技术和流程，而且要对被测软件的设计、功能规格说明、用户试用场景以及程序/模块的结构都有比较透彻的理解。测试用例设计一般包括以下几个步骤：
1、测试需求分析
从软件需求文档中，找出待测试软件/模块的需求，通过自己的分析、理解，整理成为测试需求，清楚被测试对象具有哪些功能。测试需求的特点是：包含软件需求，具有可测试性。测试需求应该在软件需求基础上进行归纳、分类或细分，方便测试用例设计。测试用例中的测试集与测试需求的关系是多对一的关系，即一个或多个测试用例集对应一个测试需求。
2、业务流程分析
软件测试，不单纯是基于功能的黑盒测试，还需要对软件的内部处理逻辑进行测试。为了不遗漏测试点，需要清楚的了解软件产品的业务流程。建议在做复杂的测试用例设计前，先画出软件的业务流程。如果设计文档中已经有业务流程设计，可以从测试角度对现有流程进行补充。如果无法从设计中得到业务流程，测试工程师应通过阅读设计文档，与开发人员交流，最终画出业务流程图。业务流程图可以帮助理解软件的处理逻辑和数据流向，从而指导测试用例的设计。
从业务流程上，应得到以下信息：
A、主流程是什么
B、条件备选流程是什么
C、数据流向是什么
D、关键的判断条件是什么
3、测试用例设计
完成了测试需求分析和软件流程分析后，开始着手设计测试用例。测试用例设计的类型包括功能测试，边界测试，异常测试，性能测试，压力测试等。在用例设计中，除了功能测试用例外，应尽量考虑边界、异常、性能的情况，以便发现更多的隐藏问题。
黑盒测试的测试用例设计方法有：等价类划分、边界值划分、因果图分析和错误猜测，白盒测试的测试用例设计方法有：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、多重条件覆盖。在这里主要讨论黑盒测试。在设计测试用例的时候可以使用软件测试用例设计方法，结合前面的需求分析和软件流程分析进行设计：
功能测试：测试某个功能是否满足需求的定义，功能是否正确，完备。
适合的技术：由业务需求和设计说明导出的功能测试、等价类划分
边界测试：对某个功能的边界情况进行测试。
适合的技术：边界值划分
异常测试：对某些功能来说，其边界情况无法简单的了解或某些操作不完全是正确的但又是
可能发生的，类似这样的情况需要书写相关的异常测试。
适合的技术：由业务需求和设计说明导出的特殊业务流程、错误猜测法、边界值
分析、内部边界值测试。
性能测试：检查系统是否满足在需求中所规定达到的性能，性能主要包括了解程序的内外部
性能因素。内部性能因素包括测试环境的配置，系统资源使用状况；外部因素包
括响应时间，吞吐量等。
适合的技术：业务需求和设计说明导出的测试
压力测试：压力测试又称强度测试，主要是检查系统运行环境在极限情况下软件运行的能力，比如说给一个相当大的负荷或网络流量给应用软件兼容测试：测试软件产品在不
同的平台，不同的工具，相同工具的不同版本下功能的兼容性。
4、测试用例评审
测试用例设计完成后，为了确认测试过程和方法是否正确，是否有遗漏的测试点，需要进行测试用例的评审。
测试用例评审一般是由测试leader安排，参加的人员包括：测试用例设计者、测试leader、项目经理、开发工程师、其它相关开发测试工程师。测试用例评审完毕，测试工程师根据评审结果，对测试用例进行修改，并记录修改日志。
5、测试用例更新完善
测试用例编写完成之后需要不断完善，软件产品新增功能或更新需求后，测试用例必须配套修改更新；在测试过程中发现设计测试用例时考虑不周，需要对测试用例进行修改完善；在软件交付使用后客户反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成，也需要对测试用例进行完善。一般小的修改完善可在原测试用例文档上修改，但文档要有更改记录。软件的版本升级更新，测试用例一般也应随之编制升级更新版本。测试用例是“活”的，在软件的生命周期中不断更新与完善。
白盒测试用例设计过程 篇2
继电保护及自动装置是电力系统的重要组成部分。对保证电力系统的安全经济运行,防止事故发生和扩大起到关键性的决定作用。由于电力系统的特殊性,电气故障的发生是不可避免的。一旦发生局部电网和设备事故而得不到有效控制,就会造成对电网稳定的破坏和大面积停电事故。现代化大电网对继电保护的依赖性更强,对其动作正确率的要求更高,也造成了对继电保护装置的测试要求越来越高。
各大继电保护的厂家对保护装置的测试也非常重视,基本上采用的都是黑盒测试的方法,通过测试人员和工程人员采用商用测试仪进行加量进行闭环的保护功能测试,这种测试方式虽然能检查出一部分系统的漏洞,但是远远达不到对于可靠性要求极高的继电保护装置的测试要求。并且数字化的测试依赖于外部的数字化测试仪[1]。这种测试方法的不足体系在以下几点:
1)无法进行软件平台的各模块代码覆盖率测试。
2)无法进行系统的自动回归测试。
3)无法进行自动测试用例管理,测试质量由测试人员的专业素质决定,而不是由各测试和开发人员的测试积累组成。
4)无法规范地进行测试报告记录,不能详细记录研发人员关心的测试量信息。
5)商用测试仪不能与保护装置进行交互。
鉴于传统测试的上述问题,设计了一种满足研发人员、生成人员以及工程人员使用的统一测试体系,该测试体系包括上位机、测试仪和被测装置,覆盖了研发阶段和单板测试阶段以及整机测试各阶段。
最近两年,也有一些装置厂家[2,3,4]也通过自主研发开发一套适合自身产品的自动测试系统,但是目前这些测试也集中在保护功能的闭合测试上,没有考虑装置中平台部分的功能隐蔽性,一般功能测试很难系统地对其进行逻辑测试。本文将重点介绍自动测试系统中的白盒测试实现方法。
1 系统结构
保护装置的软硬件体系结构图如图1所示。
测试主机的功能分成两个部分,离线功能包括完成测试用例的编写、测试用例的管理、测试用例程序编译等离线功能。在线功能包括测试用例下载,测试参数下载,测试命令发送和测试报告生成等。
平台系统软件包含下面模块:任务调度、系统监视、对时、异常处理、调试及下载模块。平台管理通信模块包括:MANAGER管理、事件录波、IEC103模块、IEC61850模块;LCD模块;PRINT模块。平台装置的板卡通常由三大部分组成:管理CPU板、计算处理CPU/DSP板和I/O板。
测试主机通过以太网采用内部通信的协议与调试代理插件相连,调试代理驻留在PPC插件上,内部通信协议具有下载文件、调试变量、修改变量等功能。整个测试过程的上位机与装置的交互都是以该协议为基础。
自动测试系统和平台设计同时进行,完成对平台的软件模块和通信管理模块的自动测试,并将测试结果直观地反映到测试终端。
2 白盒测试架构
白盒测试时需要保护装置运行一个测试支撑系统,白盒测试包括测试装置中所有智能插件上的程序,尤其是平台系统软件程序,这部分程序在整组的功能测试实验(黑盒测试)中不是测试重点,所以需要通过周密的白盒测试来覆盖测试路径。测试支撑系统运行在Manager插件上。
目标板上的测试支撑模块包括测试用例运行管理、PC通信管理、测试运行信息采集及管理、系统信息处理、信息上送等模块。测试用例运行管理是运行在目标板上与PC机同步执行同一测试用例的管理程序;PC通信管理是与PC机通信,接收PC下发的参数信息,下载的程序信息、启停测试用例命令和测试数据上送等功能;测试运行信息采集及管理是指采集某一个测试用例执行后的一些变量数据信息,组织成特定的数据报文;系统信息处理是目标板上的其他应用模块,当这一测试用例运行时其他应用模块的数据信息采集(例如SOE事件测试用例会收集103模块的报文信息);信息上送是通过组织报文发送到PC机,由PC机进行结果比对。
运行在Manager插件上的测试用例的测试流程如图2所示。
第一步:PC测试主机下载ppc测试用例可执行程序out到目标板上。
第二步:PC测试主机发送启动测试命令到测试代理。
第三步:测试代理装载测试用例程序。
第四步:PC测试主机启动主机上运行的相应测试dll。
第五步:目标板上测试用例测试过程中,与PC机上对应的比对dll进行参数以及测试结果交换。
第六步:PC机对结果进行比对,形成测试报告。
运行在其他智能IO上的测试用例框架结构如图3所示。
测试用例运行在从板上时,测试用例目标文件首先下载到Manager系统中,重新上电后加载到从板中运行。MANAGER负责与从板系统的信息交互。
平台模块在设计时,设计了测试代理程序的接口,确保测试代理程序可以通过该接口进行功能测试和性能评估。该代理程序通过平台的测试接口,实现对平台代码的测试,并通过网络通信将测试结果上送给测试终端。同时通过网络接收测试终端的测试用例,并根据给定的测试用例进行相关测试。
运行在装置中的每个模块在设计初期即考虑了测试方案,通过自动测试系统可确保测试的代码覆率达到90%以上。有效的压力测试可以发现并解决平台的隐藏问题,为平台的可靠性及稳定性提供了保证。
3 测试框架实现
测试系统上位机的主要功能有:测试用例管理,测试用例的执行流程、测试结果比对和测试报告生成四个模块。
3.1 测试用例管理
测试用例管理包括:1)对测试时所需要的源代码的管理,需要链接的库和obj文件的管理;2)生成hex文件;3)界面模板tpl文件;4)测试用例tpl文件的管理。
保护装置的测试打桩程序以源程序的形式保存在上位机中,当用户选择某个测试用例时,需要编译对应的c文件和链接相应的库,生成obj文件,一组测试用例生成一个.out或者一个hex执行文件下载到目标板中。考虑到目标系统的空间大小,一次全测试过程可以生成多个hex文件,在测试过程中分别下载。
下位机上执行的每一种类型的测试用例需要在上位机中配置一个解析该测试用例的比对程序,比对程序以dll的形式驻留在上位机中,当上位机启动下位机某一个测试用例的同时,需要装载相对应的比对dll。该比对dll负责与下位机测试用例进行交互,得到测试结果返回给上位机测试报告模块,统一形成测试报告。
一个hex文件中包含了多个测试用例,测试用例的启动是通过上位机来启动的,上位机告诉下位机现在执行某个测试用例,这样保证了上位机测试比对程序与下位机测试用例的一致性。当用例配置完成后,根据所配置的测试用例和测试用例的执行顺序生成测试用例入口源程序,并链接测试函数和系统库函数,生成hex文件。
例如:在***.tpl文件中,配置了测量量、CAN网、和事件3个测试点,测量并配置了刷新测试项和置值测试项,且3个测试点均在DSP板上运行。生成的init.c源代码为
该测试用例入口函数由上位机生成,上位机通过内部调试协议修改下位机变量testcase来控制测试用例的启动,通过修改参数变量的值,来传递函数的参数。当生成源码后,需要在makefile中添加链接init.o、以及各测试函数所在的.o文件,生成一个hex文件。
界面模板的tpl管理是指为了实现参数配置,界面风格是通过用户根据测试项自定义的,本测试框架程序提供了一套可视化界面配置前端程序提供给用户配置自定义的参数界面,配置后生成tpl文件,由测试工具解析显示相应的界面。
3.2 测试流程管理
流程控制功能包括以下两个方面。
1)流程控制的配置
执行顺序表示测试项的顺序执行顺序。
异常控制表示该测试项如果不正确执行,是继续执行、退出执行或者跳转执行。
表示该测试项测试前是否具有初始化操作、测试完成后是否需要复位操作、断开连接并重建连接操作,是否具有重新下载程序等操作。这些流程控制的配置信息在配置完成后都是以模板配置的形式保存在PC上位机中。
2)流程的自动控制
配置完测试用例的执行顺序后,系统根据配置信息,进行自动执行。
3.3 测试结果的比对
测试结果的回送通过两种方式:通过通信端口报文回送到PC机进行回读判断,通过PC机读取变量的形式读测试结果。
测试结果比对由测试用例对应的dll完成,将测试结果的详细信息送到测试报告模块。
3.4 测试报告生成
在测试过程中,对于每个测试项会有一个简单的结论,在测试完成后,生成一个详细的测试报告。测试报告中的详细信息,需要在测试比较模块主动向测试报告的数据结构输入,生成测试用例时,按照一定的格式,生成测试报告。
测试报告格式如表1所示。
4 CAN网测试举例
上文大篇幅地阐述了白盒测试的实现方法,如何通过白盒测试体系架构来实现测试覆盖率,进行各种边缘测试、压力测试以及负荷测试等具体功能及性能测试则依赖于测试用例的编写以及实现上。
下面以CAN网测试为例,进行网络压力测试、CPU负荷测试、疲劳测试及持久性测试。测试平台的基本架构如图4所示。
CAN1驱动模块测试的单次测试过程为
1)PC机通过调试变量下装参数/控制命令到PPC板和GOOSE板;
2)PPC板或GOOSE板读取到控制命令后,启动[CAN1测试程序];
3)在[CAN1测试程序]的执行过程中,PPC板或GOOSE板向CAN1网发、收数据;
4)PPC或GOOSE板将[CAN1测试程序]的执行结果通过调试变量返回到PC机;
5)PC机利用返回的调试变量值验证测试结果。
在测试用例中对CAN网收发程序的语句进行静态分析,对条件判断等逻辑分支进行测试覆盖,在一次测试用例中发送双方发送各种异常/正确报文,使测试能够覆盖CAN网模块的所有语句。
连续进行多次CAN网测试,从每秒1 000帧连续发送10 s到每秒10 000帧连续发送10 s进行递增,对每次测试过程中,通过装置中变量来记录测试的信息,然后将这些测试过程信息上送到PC机,由PC机得出CAN网的稳定性能时负荷值等重要参数。
5 结论
在ARP保护装置系统中设计了一整体测试系统,不仅包括白盒测试来测试系统程序或者应用程序,还包括整机测试和整屏系统。整机和整屏系统是闭环的功能测试系统,但都融于本文介绍的这套测试体系框架之内。这套测试系统为装置的出厂测试、现场测试提供了很大的便利。
参考文献
[1]何刚,胡宝,陈强林,等.OMICRON测试仪在数字化保护装置测试中的应用[J].电力系统保护与控制,2010,38(12):132-134.HE Gang,HU Bao,CHEN Qiang-lin,et al.OMI CRON tester in digital protection device test[J].Power System Protection and Control,2010,38(12):132-134.
[2]赖擎,华建卫,吕云,等.通用继电保护自动测试系统软件的研究[J].电力系统保护与控制,2010,38(3):90-94.LAI Qing,HUA Jian-wei,LüYun,et al.Research on general relay protection auto-test system software[J].Power System Protection and Control,2010,38(3):90-94.
[3]应站煌,胡建斌,赵瑞东,等.继电保护装置自动测试系统研究和设计[J].电力系统保护与控制,2010,38(17):142-146.YING Zhan-huang,HU Jian-bin,ZHAO Rui-dong,et al.Research and design of relay protection equipment automated test system[J].Power System Protection and Control,2010,38(17):142-146.
小议软件测试用例的设计论文 篇3
白盒测试方法的主要作用有：
（1）至少测试一次程序子模块的所有独立执行路径；
（2）针对所有可能的逻辑判定，至少一次取“真”或“假”两种情况；（3）在运行界限内和循环边界处执行循环体；
（4）测试程序内部的数据结构的有效性。在实际的数据测试中，如果程序具有多种循环嵌套的情况，不同的执行路径数目可能是天文数字，例如一个有5条路径的嵌套20次循环的小程序，包含不同执行路径条数为520次方，如果每一条路径测试1ms，全年无休时要测试完所有路径需要约3170年的时间。因此，我们必须采用一些替代办法，典型的方法是有选择的执行程序中某些最有代表性的通路。白盒测试的主要技术有：
1根据程序内部的逻辑结构设计测试用例的技术—逻辑覆盖
（1）语句覆盖，选择足够多的测试数据以使被测程序中每条语句都至少执行一次。语句覆盖不考虑对程序的逻辑覆盖，它主要关心表达式的结果，却对每个条件取不同值的情况不做测试。因此，语句覆盖是比较弱的逻辑覆盖标准。在图论中和语句覆盖对应的是点覆盖。
（2）判定覆盖，又叫分支覆盖，它首先满足语句覆盖的条件，同时对每个判定的每种可能的结果都至少执行一次，即对每个分支都至少执行一次每个判定，判定覆盖对程序的逻辑覆盖程度也不高。在图论中和判定覆盖相对应的是边覆盖。
（3）条件覆盖，指的是不仅每个语句至少执行一次，而且使判定表达式中的每个条件都取到各种可能的结果，条件覆盖中可能不包含判定覆盖。
（4）判定/条件覆盖，指选取足够多的测试数据，使得判定表达式中的每个条件都取到各种可能的值，每个判定表达式也取到各种可能的结果。
（5）条件组合覆盖，要求选择足够多的测试数据，使得每个判定表达式中条件的各种可能组合都至少出现一次。条件组合覆盖是逻辑覆盖标准中最强的。
（6）路径覆盖，指的是选取足够多的测试数据，使程序的每条可能路径都至少执行一次。测试用例设计举例1：如下图1所示程序段流程，实现语句覆盖需要设计的测试数据有：X=0，Y=3和X=-1，Y=2；实现条件覆盖至少采用的测试数据有：X=0，Y=3和X=3，Y=1；实现判定覆盖至少应用的测试数据有X=0，Y=3，X=1，Y=2和X=-1，Y=2。
2测试程序的控制结构，主要包括条件测试，循环测试和基本路径测试。
其中基本路径测试是由TomMcCabe提出的一种白盒测试技术，这种技术在设计测试用例时需要首先计算程序的环形复杂度，并用该复杂度为指南定义执行路径的基本集合。在实际测试中，仅靠基本路径测试还不能满足要求，还需要结合条件测试技术来检查程序模块中包含的逻辑条件，还有循环测试来专门测试循环结构的有效性。
黑盒测试技术中的测试用例设计方法研究
黑盒测试主要用来测试软件的功能特点，通过黑盒测试可以发现：（1）是否有遗漏了的功能或者不正确的功能；（2）能否有正确的接收输入和正确的输出结果，这主要针对接口而言；（3）是否有外部信息访问错误或数据结构错误，同时，软件运行时能否满足性能上的要求；（4）软件在初始化或者退出时有无错误等；使用黑盒测试同样不可能将所有可能的输入条件和输出条件用于测试，因为测试用例的组合是天文数字。例如一个程序有两个输入量和一个输出量，在32位计算机上运行，若X，Y取整数，按穷举测试时需要232×232=264组，如果一组数据需要1ms，全年无休，需要5亿年的时间。显然，我们必须设计合理的方案来减少测试用例的数量。目前黑盒测试的主要测试用例设计技术有：
1等价类划分
等价类划分是把程序的输入域划分成若干个数据类，据此导出测试用例，因为对于同一类中的数据而言其作用是相同的[3]。等价类划分可以分为有效等价类和无效等价类。有效等价类是指符合程序功能要求的数据类，该类中包含的都是有意义的数据；而无效等价类指不能满足程序正确运行或者预期结果的数据类的集合。我们在设计测试用例时，要同时考虑有效等价类和无效等价类的设计方案。等价类的划分有自己的原则。在具体使用等价类划分设计测试用例时有两个步骤：（1）设计一个新的测试方案以尽可能多地覆盖尚未被覆盖的有效等价类，重复这一步骤直到所有有效等价类都被覆盖为止；（2）设计一个新的测试方案，使它覆盖一个而且只覆盖一个尚未被覆盖的无效等价类，重复这一步骤直到所有无效等价类都被覆盖为止。
2边界值分析
使用边界值分析方法来设计测试用例时需要开发者具有一定的经验和创造性，通常根据划分的输入等价类和输出等价类的边界来确定边界值的结果，即选取刚刚等于、刚刚小于和刚刚大于边界值的测试数据，而不是选择等价类内部的数据作为测试用例。
3错误推测法
错误推测法主要依靠直觉和经验，需要有一定开发大型软件工程的经验，其基本思想是通过列举出程序中可能有的错误和容易发生错误的特殊情况，并根据这些情况来选择测试方案。
小结
测试用例 篇4
测试用例(Test Case)目前没有经典的定义，比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。
不同类别的软件，测试用例是不同的。不同于诸如系统、工具、控制、游戏软件，管理软件的用户需求更加不统一，变化更大、更快。笔者主要从事企业管理软件的`测试。因此我们的做法是把测试数据和测试脚本从测试用例中划分出来。测试用例更趋于是针对软件产品的功能、业务规则和业务处理所设计的测试方案。对软件的每个特定功能或运行操作路径的测试构成了一个个测试用例。
编制测试用例的具体做法，
1、测试用例文档
编写测试用例文档应有文档模板，须符合内部的规范要求。测试用例文档将受制于测试用例管理软件的约束。
软件产品或软件开发项目的测试用例一般以该产品的软件模块或子系统为单位，形成一个测试用例文档，但并不是绝对的。
测试用例文档由简介和测试用例两部分组成。简介部分编制了测试目的、测试范围、定义术语、参考文档、概述等。测试用例部分逐一列示各测试用例。每个具体测试用例都将包括下列详细信息：用例编号、用例名称、测试等级、入口准则、验证步骤、期望结果(含判断标准)、出口准则、注释等。以上内容涵盖了测试用例的基本元素：测试索引，测试环境，测试输入，测试操作，预期结果，评价标准。
2、测试用例的设置
我们早期的测试用例是按功能设置用例。后来引进了路径分析法，按路径设置用例。目前演变为按功能、路径混合模式设置用例。
编辑测试用例方法感言 篇5
编辑测试用例方法感言、一个测试用例要写到什么程度才比较好?、刚开始做测试的时候，你是怎么学习写测试用例的？、你对黑盒测试用例的编写的体会是什么？有什么好的版本或者标准吗？
对于测试用例，而我目前正在思考的问题是：怎么写出对公司有价值的测试用例，对公司来说，怎么测试才是最有价值的测试？
一个测试用例要写到什么程度才比较好？
这个问题，没有定语，没有说是在什么样的一个情况下，因此我这里只能就我工作中碰到的情况说说了。说起来
比较长阿，大家要有常要考虑这个项目的周期和测试资源。我所在的公司，通常项目开发时间都很短到个月，然而测试通常都是在开发即将结束的时候才真正介入。测试就是个人负责。因此时间和人力资源对测试来说是完成测试工作的一个风险。为此在这种情况下，我都是先熟悉系统的业务，把握重点业务和功能后，参考需求，把测试需求、测试计划和测试大纲给制定好。由于时间关系，测试用例都是先写重点的业务，也就是集成测试的测试用例。另外测试用例是根据测试大纲来的。通常都是先挑最重要的测试项和风险大的业务功能编写测试用例。
由于测试用例是本人执行，所以测试用例可以写的简单些，但是一定要开发人员能够看明白。可惜我所在的公司，都没有人来看我的测试用例。测试用例对我来说是用来提示我不要忘记了要测试哪些项。一些很有价值的bug通常不是在写测试用例的时候发现的，而是在
测试软件的过程中，我在家睡觉前的思考和回家的路上思考出来的。这就是手动测试的魅力，有些软件的缺陷是在你使用软件的一瞬间和思考的一刹那突然发现的。所以要我回答测试用例要写到什么程度才比较好，我觉的只要你所写的测试用例在你的公司能够顺利的执行，不影响你的测试执行工作就可以了。因为测试用例写的太详细，你要花费时间和人力成本，这样出来的测试用例是最好的也是最贵的，一旦需求变更，也需要修改，这时你会发现这种详细的测试用例是最不挣钱的。测试用例写的太粗，别人看不懂，不能执行，那你要花费你的时间去解释，这就加大了测试的工作量。这也不是好的方法。
第二个问题，刚开始做测试的时候，你是怎么学习写测试用例的？
我之所以选择测试这个工作是因为：我毕业后，在第一家公司做技术支持，产品的问题很多，导致技术支持工作很辛苦、很累。为了让用户买到的产
品的质量是好的，我选择了做测试，到了现在的公司。我刚做测试的时候，对测试一无所知，什么测试流程阿、文档阿都不知道，公司的测试和管理也不规范。对测试，大家都认为不就是拿个鼠标点来点去，谁都可以来做。为此，我经常上网查测试的资料，看看自己到底适合不适合做测试，测试到底是什么样的一个职业，怎么去规划自己的个人发展。其实要做好测试，真是不容易。不喜欢，真是不能做这个职业。http://
现在想想自己刚开始写测试用例的时候，真是好笑。就像小孩子学习写字一样。先是在网上狂搜索了一把测试用例的模板，综合了几个，就形成了。我之所以不用公司原有的测试用例模板，是因为太不适用了。还好，公司没有严格要求必须要那个模板，只要适用就行。模板找好了，可是写就费劲了。对于刚做测试的新人，看似简单的一个填表工作，要写好真是不简单。一开始写的比较不自然，有些生搬硬套，而且
还很慢。没有办法，那时候没有人指导我，全靠自己自学和领悟，所以那段日子很苦阿！多写几次后，就知道和领悟了，测试用例要根据测试大纲来写，测试大纲要根据测试计划来写。测试大纲更多的是把握住测试项的方向，而测试用例是指导怎么去执行测试。还好，我有编程的经验，所以对我熟悉软件帮了一个很大的忙。熟悉了软件的业务才能去写测试用例，才能更好的去测试。这也是我一点一点的领悟出来的。说了这么多，不知道这样的回答是否是回答了这个问题。
你对黑盒测试用例的编写的体会是什么？有什么好的版本或者标准吗？
我的体会：、测试用例要根据测试大纲来编写、测试用例也要分测试项进行归类，这样比较好分析和阅读。如：业务流程测试、安装测试、功能测试、用户友好性测试、兼容性测试、性能测试、安全性测试等等。、编写测试用例要考虑各种情况，精力主要集中在软件的主要业务流程和风险高的地方。能分出测试优先级别就最好了。、熟悉系统，对编写测试用例很有帮助。、即使对测试很熟悉了，在时间非常紧的时候，编写测试用例还是很有必要和好处的。