下载文档原格式
基本路径法设计测试用例的步骤
一、画出程序控制流图。
这就像是给程序画个地图呢。
把程序里的各种语句啊、判断啊、循环啥的，都用图的形式表示出来。
比如说，那些顺序执行的语句就用直线连起来，遇到判断就像走到了岔路口，不同的选择就分开画，循环就像是在绕圈圈。
这一步可重要啦，就像是给后面的探索打基础呢。
二、计算圈复杂度。
这个圈复杂度呀，就像是给这个控制流图的复杂程度打个分。
有个公式可以算呢，一般是边的数量减去节点的数量再加2。
这个分数能让咱知道这个程序结构大概有多复杂，复杂的程序可能就需要更多的测试用例去覆盖各种情况哦。
三、确定独立路径。
这时候就像在地图上找不同的路线啦。
独立路径就是那些从程序入口到出口的不同走法，而且这些走法不能相互包含。
比如说，一条路是直接走到底，另一条路可能是在某个判断处走了不同的分支，这都是不同的独立路径呢。
四、设计测试用例。
最后就根据确定的独立路径来设计测试用例啦。
对于每条独立路径，要想办法让程序按照这个路径走一遍。
这就需要考虑输入的数据啦，什么样的输入能让程序走这条路径呢？要让输入的数据合理又能达到测试的目的。
就像是给程序出不同的考题，看它能不能正确应对。
基本路径法设计测试用例虽然听起来有点复杂，但是按照这些步骤一步一步来，也不是那么难啦。
就像是搭积木，一块一块搭好，最后就能完成一个很棒的测试用例设计啦。
宝子，你要是还有啥不明白的，随时来问我哈。
单元测试单元测试是以程序设计说明书为指导，测试模块范围内的重要控制路径，以揭露错误。
当程序编好以后，将它录制在媒体上，或者直接由终端键盘输入到机中进行调试。
测试的相对复杂性和所发现的错误受到单元测试所限定的范围的限制。
它在执行的过程中紧密的依照程序框架对模块进行测试（调试），测试包含入口和出口的参数，输入和输出信息，错误处理信息，部分边界数值测试。
需要在6个方面对所测模块进行检查。
1．模块接口测试模块接口测试是单元测试的基础，当模块通过外部设备进行输入／输出操作时，只有在数据能正确流入、流出模块的前提下，模块才能完成他的功能。
模块接口测试应考虑下列因素：★调用其他模块时所给的输入参数与模块的形式参数在个数、属性、顺序上是否匹配；★调用其他模块时所给实际参数的个数是否与被调模块的形参个数相同；★调用其他模块时所给实际参数的属性是否与被调模块的形参属性匹配；★调用预定义函数时所用参数的个数、属性和次序是否正确；★输入的实际参数与形式参数的个数是否相同；★输入的实际参数与形式参数的属性是否匹配；★输入的实际参数与形式参数的量纲是否一致；★是否修改了只做输入用的形式参数；★是否存在与当前入口点无关的参数引用；★是否修改了只读型参数；★对全程变量的定义各模块是否一致；★是否把某些约束作为参数传递。
★输出给标准函数的参数在个数、属性、顺序上是否正确；★限制是否通过形式参数来传送；★文件属性是否正确；★OPEN/CLOSE语句是否正确；★格式说明与输入输出语句是否匹配；★缓冲区大小与记录长度是否匹配；★文件使用前是否已经打开；★是否处理了输入/输出错误；★输出信息中是否有文字性错误；★在结束文件处理时是否关闭了文件。
2．局部数据结构测试局部数据结构是为了保证临时存储在模块内的数据在程序执行过程中完整、正确的基础。
模块的局部数据结构往往是错误的根源，力求发现最常见的几类错误：★不合适或不相容的类型说明；★变量无初值；★变量初始化或省缺值有错；★不正确的变量名（拼错或不正确地截断）；★出现上溢、下溢和地址异常。
白盒测试之基本路径测试法白盒测试的测试方法有代码检查法、静态结构分析法、静态质量度量法、逻辑覆盖法、基本路径测试法、域测试、符号测试、Z路径覆盖、程序变异。
其中运用最为广泛的是基本路径测试法。
基本路径测试法是在程序控制流图的基础上，通过分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例的方法。
设计出的测试用例要保证在测试中程序的每个可执行语句至少执行一次。
在程序控制流图的基础上，通过分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例。
包括以下4个步骤和一个工具方法：1. 程序的控制流图：描述程序控制流的一种图示方法。
2. 程序圈复杂度：McCabe复杂性度量。
从程序的环路复杂性可导出程序基本路径集合中的独立路径条数，这是确定程序中每个可执行语句至少执行一次所必须的测试用例数目的上界。
3. 导出测试用例：根据圈复杂度和程序结构设计用例数据输入和预期结果。
4. 准备测试用例：确保基本路径集中的每一条路径的执行。
工具方法：图形矩阵。
是在基本路径测试中起辅助作用的软件工具，利用它可以实现自动地确定一个基本路径集。
程序的控制流图：描述程序控制流的一种图示方法。
圆圈称为控制流图的一个结点，表示一个或多个无分支的语句或源程序语句流图只有二种图形符号：图中的每一个圆称为流图的结点，代表一条或多条语句。
流图中的箭头称为边或连接，代表控制流任何过程设计都要被翻译成控制流图。
如何根据程序流程图画出控制流程图?在将程序流程图简化成控制流图时，应注意：●在选择或多分支结构中，分支的汇聚处应有一个汇聚结点。
●边和结点圈定的区域叫做区域，当对区域计数时，图形外的区域也应记为一个区域。
如下页图所示独立路径：至少沿一条新的边移动的路径基本路径测试法的步骤：第一步：画出控制流图流程图用来描述程序控制结构。
可将流程图映射到一个相应的流图(假设流程图的菱形决定框中不包含复合条件)。
在流图中，每一个圆，称为流图的结点，代表一个或多个语句。
如何编写测试⽤例如何编写测试⽤例⽤例的五个构成元素：1. ⽤例标题2. 前置条件3. 测试步骤4. 期望结果5. 后置条件下⾯从这五个元素的⾓度，去剖析如何编写测试⽤例⽤例标题⽤例标题就是测试点名称。
⽤例标题是⽤来说明这个⽤例的测试⽬的的，好的⽤例标题是别⼈看完你这个⽤例标题后就知道你这个⽤例是测什么的。
但并不是标题越详细越好。
既然是标题，就要⾔简意赅，能多简洁就多简洁，但简洁的同时⼜要能体现你的测试⽬的。
⽤例的标题最好不要超过30个字，太长会让⼈看起来很累也很不专业。
⼀般可以遵循这样的公式：主体(可省略) + 动词 + 名词 + 结果(可省略)(即谁做了什么有什么影响)，但很多时候是动词 + 名词的形式。
要注意：我们写的每⼀个案例对应的就是要测试的⼀个点。
其实每个点都是⽤户的⼀种操作⾏为。
前置条件⽤例的前置条件就是在测这个⽤例之前你要先准备的环境和数据。
同时，我们需要将前置条件和测试步骤区分开来，但怎么区分呢，是不是还是⽐较模糊？我们从⽤例标题⼊⼿，我们的⽤例标题是动作+名词嘛，那我们的测试重点是动作，那产⽣这个动作之前的所需的所有环境和数据都算是前置条件，产⽣这个动作和这个动作带来的后果都算是测试步骤。
这样是不是就⽐较清晰了。
前置条件只是说明测试这个⽤例需要准备的环境和数据，故前置条件不⽤像步骤那样写得那么详细，但也不能太过于简洁，不能有歧义。
测试步骤测试步骤是⼀个⽤例的精髓，⽤例标题体现测试的⽬的，⽤例步骤就是如何来测从⽽达到测试的⽬的。
即然是步骤那就是⼀步⼀步的操作过程，但这个操作过程并不是写得越详细越好。
我们的步骤是来体现我们的测试⽬的的，即要怎样做什么操作，这个操作后要如何检查产⽣的结果。
这个操作可能是⼀步，也可能是⼏步，也可能是来回循环。
不管是什么操作都是告诉别⼈如何去做，如何去检查。
但步骤不能写得过于详细，如【登录控制台，打开xx页⾯，点击xx按钮】这种就没必要写上去，因为这种既是浪费时间也会给⽤例的维护带来成本。
李龙：软件测试的测试阶段总结：需求阶段、设计编码阶段、测试阶段、用户测试阶段软测试的测试阶段总结软测试人员的职责软测试人员在测试的过程中要肩负着如下职责：★测试人员要了解项目需求内容，从用户角度提出自己的测试看法；★测试人员要编写合理的测试计划，并与项目整体计划有机地整合在一起；★测试人员要编写覆盖率高的测试用例；★测试人员要认真仔细地实施测试工作，并提交测试报告供项目组参考；★测试人员要进行缺陷跟踪与分析。
软测试实际是由确认、验证、测试三个方面组成：?确认：是评估将要开发的软产品是否是正确无误、可行和有价值的。
?验证：是检测软开发的每个阶段、每个步骤的结果是否正确无误，是否与软开发各阶段的要求或期望的结果相一致。
验证意味着确保软是否正确无误的实现软的需求，开发过程是否沿着正确的方向进行。
?测试：通常是经过单元测试、集成测试、系统测试等过程。
软测试分需求阶段、设计编码阶段、测试阶段、用户测试阶段。
1.需求阶段需求阶段要求：★测试人员了解项目需求，包括项目需求规格说明、功能结构及模块划分等；★测试人员了解项目需求变更；★测试人员会同项目主管根据软需求，制定和确定测试进度时，必须要有开发人员和相关的测试部门人员共同参与。
在制定测试进度时，必须考虑到合理地配置测试资源（测试设备、测试所要用到的技术文档资料、测试人员和对测试人员进行的必要培训）；★为了使所制定的测试进度正常有效，必须对其所制定的测试进度加以量化。
要制定测试的各个阶段的测试进度。
有特殊情况时还必须制定特定系统的测试进度。
如文管理系统、资料库内容功能测试等。
★所制定的测试进度中，必须含有修改问题和复查的时间。
2．设计编码阶段★测试人员制定测试大纲、测试设计、测试用例；★对每一个测试需求，确定其需要的测试用例；★对每一个测试用例，确定其输入及预期结果；★确定测试用例的测试环境配置、需要的驱动界面或稳定性；★为测试用例准备输入数据；★编写测试用例文档；★对测试用例进行同行评审；★项目开发组对完成的功能模块进行单元测试，测试人员参与单元测试过程；单元测试完成，产生单元测试报告；★所有单元测试及相应的修改完成后，项目开发组组织进行确认测试和系统集成测试，测试人员参与集成测试过程；集成测试完成后，产生集成测试报告。
测试用例编写方法测试用例的编写是软件测试的基础，它的完整性与合理性影响着软件测试的质量，本文结合实际和专业知识，介绍测试用例的编写方法，帮助读者更好地掌握软件测试流程。
1.试用例编写前期准备在测试用例的编写前，最重要的就是要做好充分的准备，这样才能使测试用例的编写更加高效，更能反映出测试的要点。
在准备的过程中，需要收集测试用例所需的信息，包括测试范围、测试标准、测试环境以及实施测试所需要的工具。
除此之外，还需要根据需求文件和测试计划，设计出需要测试的具体功能；测试用例的编写前期还需要确定测试类型和测试方法，让测试有正确的定位和走向。
2.试用例的编写在完成准备工作之后，就可以正式开始测试用例的编写了。
测试用例的编写要按照一定的格式和流程，要根据项目的需求文件和测试计划来编写，并要多考虑用户的实际使用情况，以及一些特殊条件下的功能测试，以满足用户的实际需求。
测试用例的编写一般包括以下几个部分：1）测试用例编号：根据测试用例的具体功能，编写对应测试用例的编号；2）测试用例描述：简要描述本测试用例的具体功能和目的；3）测试用例步骤：详细描述测试用例的执行步骤；4）测试用例输入：通过简要描述测试用例的具体输入；5）测试用例期望结果：明确描述本测试用例的期望结果；6）测试用例实际结果：描述本测试用例的实际结果，以便于进行性能检查。
3.试用例的审核在测试用例的编写完成之后，需要进行一定的审核，以确保测试用例的完整性和正确性。
审核的过程一般包括准确性审查、质量审查以及时效性审查。
在审查的过程中，可以通过面对面的沟通、回答查询问题的方式，检查测试用例是否记录完整，以及测试结果是否与期望结果一致；还可以通过进行特殊的测试环境和特殊场景的测试，检查是否存在遗漏的测试步骤以及遗漏或不清楚的步骤说明。
审核完毕后，会制作出审核报告，把审核过程中发现的问题进行汇总，以作为审核结果和测试负责人之间的交流和对策。
总之，测试用例是软件测试的重要工具，编写测试用例的过程要考虑到软件测试的目标以及测试人员的能力，要全面的考量测试的关键点和重点，不仅要充分准备测试的资料，更要注重测试用例的完整性和可执行性，以及审核的质量，以保证测试的成功。
基本路径测试用例是指对于一个程序模块，通过使用路径分析技术，确定所有可能的路径，并为每个路径设计测试用例。
基本路径测试用例是一种白盒测试方法，它关注程序的内部逻辑结构而不是外部行为。
确定基本路径测试用例的步骤如下：
1. 画出程序的控制流图：控制流图是一个有向图，其中每个节点表示程序的一个基本语句或条件判断，每个边表示一个控制转移。
2. 计算程序的基本路径数：基本路径数是程序中所有可能路径的总数。
可以通过计算程序的控制流图中节点的数量来得到基本路径数。
3. 生成测试用例：对于每个基本路径，设计一个测试用例，确保该路径在程序运行时被执行到。
在设计基本路径测试用例时，需要考虑以下因素：
1. 输入数据：为每个测试用例选择合适的输入数据，以确保测试用例能够覆盖程序的所有分支和条件。
2. 程序状态：考虑程序在执行测试用例之前的状态，以确保测试用例能够正确地执行。
3. 边界条件：考虑程序的边界条件，以确保测试用例能够覆盖所
有可能的输入和输出情况。
4. 异常情况：考虑程序的异常情况，例如输入非法数据或程序出现错误时的处理方式，以确保测试用例能够覆盖这些情况。
总之，基本路径测试用例是一种有效的白盒测试方法，它可以帮助开发人员发现程序中的潜在问题并提高程序的可靠性。
基本路径测试方法
基本路径测试方法是一种白盒测试技术，用于测试软件系统中的所有可能路径。
它是一种结构化的测试方法，基于程序的控制流图，通过遍历系统中的所有可能路径来验证系统的正确性和稳定性。
基本路径测试方法的主要步骤如下：
1. 识别控制流图：首先，需要将软件系统的源代码转换为控制流图。
控制流图是一个图形化表示程序控制流程的图，由控制流程节点和控制流程边组成。
2. 确定基本路径：在控制流图中，基本路径是从程序的入口节点到出口节点的一条路径。
基本路径测试的目标是遍历系统中的所有基本路径。
3. 计算基本路径的数量：基本路径的数量是基于控制流图中的节点和边的数量计算得出的。
它代表了系统中的所有可能路径。
4. 设计测试用例：根据基本路径的数量，设计测试用例来覆盖系统中的所有基本路径。
每个测试用例应该包含一个输入和一个预期输出，以验证系统在不同路径下的行为。
5. 执行测试用例：按照设计的测试用例，逐个执行测试用例。
记录测试结果并与预期输出进行比较，以确定系统是否按照预期工作。
6. 分析测试结果：分析测试结果，查找系统中的错误和缺陷。
如果测试结果与预期输出不一致，说明系统在某些路径下出现了错
误。
7. 修复错误和重复测试：对发现的错误进行修复，并重新执行测试用例。
重复测试过程，直到系统在所有基本路径上都能按照预期工作。
通过基本路径测试方法，可以全面地测试系统中的各种情况和路径，从而提高软件的质量和稳定性。
它可以帮助开发人员找出隐藏的错误和缺陷，并及时修复，确保系统的正确性和可靠性。
测试用例编写方法编写测试用例是软件测试过程中非常重要的一环，可以帮助我们发现软件中的缺陷，并确保软件系统的质量。
下面是一些常用的方法和步骤，可帮助您进行测试用例的编写。
1.理解需求：首先，您需要充分理解软件的功能和需求。
这可以通过与开发团队、产品经理或者其他相关人员的讨论来实现。
一个清晰的需求文档或者规范书也是非常有帮助的。
您需要明确软件的预期功能、输入和输出、边界条件及限制等等。
2.识别测试场景：测试场景是指软件系统的各种使用情况和操作路径。
您需要根据不同的用户角色、典型使用情况、异常情况等来识别不同的测试场景。
例如，对于一个电子商务网站，测试场景可以包括用户注册、登录、商品、添加商品到购物车、付款等等。
3.确定测试数据：根据每个测试场景的需求，您需要确定相应的测试数据。
这些数据应该包括正常情况下的有效数据，以及错误和异常情况下的无效数据。
例如，对于用户登录测试场景，您需要包括正确的用户名和密码，以及错误的用户名和密码。
4.编写测试用例：根据确定的测试场景和测试数据，您可以开始编写测试用例。
一个测试用例应该包含测试步骤、输入数据、预期结果和实际结果。
测试步骤应该是简洁明了的，以便测试人员能够按照步骤来执行测试。
输入数据应该是与测试场景相关的有效数据或者无效数据。
预期结果应该是开发人员或用户预期软件在特定输入下的输出结果。
实际结果是在执行测试用例后得到的软件的实际输出结果。
5.确定测试覆盖率：测试覆盖率是指测试用例执行到的代码的比例。
您可以使用测试覆盖率工具来确定测试覆盖率。
测试覆盖率是评估您的测试用例是否涵盖了软件的全部功能。
例如，代码覆盖率指标可以帮助您了解测试用例执行到了多少代码行。
6.执行测试用例：测试用例编写完毕后，您需要将其交给测试团队执行测试。
测试人员应该按照测试用例的步骤和输入数据来执行测试，并记录每个测试用例的实际结果。
如果测试结果与预期结果不一致，测试人员应该将问题报告给开发团队。
编写单元测试用例的方法
一、单元测试的概念
单元通俗的说就是指一个实现简单功能的函数。
单元测试就是只用一组特定的输入(测试用例)测试函数是否功能正常，并且返回了正确的输出。
测试的覆盖种类
1.语句覆盖：语句覆盖就是设计若干个测试用例，运行被测试程序，使得每一条可执行语句至少执行一次。
2.判定覆盖（也叫分支覆盖）：设计若干个测试用例，运行所测程序，使程序中每个判断的取真分支和取假分支至少执行一次。
3.条件覆盖：设计足够的测试用例，运行所测程序，使程序中每个判断的每个条件的每个可能取值至少执行一次。
4.判定——条件覆盖：设计足够的测试用例，运行所测程序，使程序中每个判断的每个条件的每个可能取值至少执行一次，并且每个可能的判断结果也至少执行一次。
5.条件组合测试：设计足够的测试用例，运行所测程序，使程序中每个判断的所有条件取值组合至少执行一次。
6.路径测试：设计足够的测试用例，运行所测程序，要覆盖程序中所有可能的路径。
用例的设计方案主要的有下面几种：条件测试，基本路径测试，循环测试。
通过上面的方法可以实现测试用例对程序的逻辑覆盖，和路径覆盖。
二、开始测试前的准备
在开始测试时，要先声明一下，无论你设计多少测试用例，无论你的测试方案多么完美，都不可能完全100%的发现所有BUG，我们所需要做的是用最少的资源，做最多测试检查，寻找一个平衡点保证程序的正确性。
穷举测试是不可能的。
所以现在进行单元测试我选用的是现在一般用的比较多的基本路径测试法。
三、开始测试
基本路径测试法：设计出的测试用例要保证每一个基本独立路径至少要执行一次。
函数说明：
当i_flag=0；返回i_count+100
当i_flag=1；返回i_count *10
否则返回i_count *20
输入参数：int i_count
int i_flag
输出参数：int i_return
代码：
1 int Test(int i_count, int i_flag)
2 {
3 int i_temp = 0;
4 while (i_count>0)
5 {
6 if (0 == i_flag)
7 {
8 i_temp = i_count + 100;
9 break;
10 }
11 else
12 {
13 if (1 == i_flag)
14 {
15 i_temp = i_temp + 10;
16 }
17 else
18 {
19 i_temp = i_temp + 20;
20 }
21 }
22 i_count--;
23 }
24 return i_temp;
25 }
画出程序控制流程图
事例程序流程图：
圈中的数字代表的是语句的行号，也许有人问为什么选4,6,13作为结点，第2行，第3行为什么不是结点，因为选择结点是有规律的。
让我们看程序中；第2行，第3行是按顺序执行下来的。
直到第4行才出现了循环操作。
而2，3行没有什么判断，选择等分支操作，所以我们把2，3，4全部合并成一个结点。
其他的也是照这个规则合并，然后就有了上面的流程图。
2.计算圈复杂度
有了图以后我们要知道到底我们有写多少个测试用例，才能满足基本路径测试。
这里有有了一个新概念——圈复杂度
圈复杂度是一种为程序逻辑复杂性提供定量测试的软件度量。
将该度量用于计算程序的基本独立路径数目。
为确保所有语句至少执行一次的测试数量的上界。
公式圈复杂度V（G）=E-N+2，E是流图中边的数量，N是流图中结点的数量。
公式圈复杂度V（G）=P+1 ，P是流图G中判定结点的数量。
通俗的说，圈复杂度就是判断单元是不是复杂，是不是好测试的标准。
一般来说如果圈复杂度大于20就表示这个单元的可测试性不好，太复杂（也许有人觉得无所谓，但是如果你们公司实行了CMMI5的话，对这个是有规定的）。
从图中我们可以看到，
V（G）=10条边-8结点+2=4
V（G）=3个判定结点+1=4
上图的圈复杂图是4。
这个结果对我们来说有什么意义呢？它表示我们只要最多4个测试用例就可以达到基本路径覆盖。
3.导出程序基本路径。
现在我们知道了起码要写4个测试用例，但是怎么设计这4个测试用例？
导出程序基本路径，根据程序基本路径设计测试用例子。
程序基本路径：基本独立路径就是从程序的开始结点到结束可以选择任何的路径遍历，
但是每条路径至少应该包含一条已定义路径不曾用到的边。
让我们看上面的流程图：从结点4到24有几条路径呢？
1 B（4，24）
2 C，E，J（4，6，8，24）
3 C，D，F，H，A，B（4，6，13，15，22，4，24）
4 C，D，G，I，A，B（4，6，13，19，22，4，24）
还有吗？？
5 C，D，C，I，A，C，E，J（4，6，13，19，22，4，6，8，24）算吗？
不算，为什么？因为上面的4条路径已经包括了所有的边。
第5条路径已经不包含没有用过的边了。
所有的路径都遍历过了。
好了，现在我们有了4条基本独立路径根据独立路径我们可以设计测试用例。
1 B（4，24）
输入数据：i_flag=0，或者是i_flag<0的某一个值。
预期结果：i_temp=0.
2 C，E，J（4，6，8，24）
输入数据：i_count =1; i_flag=0
预期结果：i_temp=101.
3 C，D，F，H，A，B（4，6，13，15，22，4，24）
输入数据：i_count =1; i_flag=1
预期结果：i_temp=10.
4 C，D，G，I，A，B（4，6，13，19，22，4，24）
输入数据：i_count =1; i_flag=2
预期结果：i_temp=20.
这里的输入数据是有路径和程序推论出来的。
而要注意的是预期结果是从函数说明中导出，不能根据程序结构中导出。
为什么这么说？
让我们看程序中的第3行。
int i_temp=0; 假如开发人员一不小心写错了，变成了int i_temp=1; 根据程序导出的预期结果就会是一个错误的值，但是单元测试不出来问题，那单元测试就失去了意义。
有人也许会问这么简单的函数就有4个测试用例，如果还复杂一些的怎么办？上面的测试用例还可以简化吗？答案是可以。
我们来看路径1 B（4，24）和4 C，D，G，I，A，B（4，6，13，19，22，4，24），路径1是路径4的真子集，所以1是可以不必要的。
上图的圈复杂度是4。
这个结果对我们来说有什么意义呢？它表示我们只要最多4个测试用例就可以达到基本路径覆盖。
所以说圈复杂度表示的是最多的测试用例个数，不是一定要4个测试用例才可以。
不过有一点要申明的是测试用例越简化代表你的测试越少，这样程序的安全性就越低了。
四、完成测试
接下来根据测试用例使用工具测试NUNIT，VS2005都可以。
接下来根据测试结果编写测试报告，测试人，时间，结果，用例，是否通过，格式网上一大把，每个公司的格式也不一样就不说了。
