测试用例的设计

① 设计测试用例

如果想设计测试用例的话，特别简单，而且非常方便，这也非常的正常，而且特别的好。

② 测试用例设计的基本原则是什么

测试用例设计的最基本要求：覆盖住所要测试的功能。这是再基本不过的要求了，但别看只是版简单的一句话，要权能够达到切实覆盖全面，需要对被测试产品功能的全面了解、明确测试范围（特别是要明确哪些是不需要测试的）、具备基本的测试技术（如：等价类划分等）等。那么满足了上述这条要求是不是设计出来的测试用例就是好的测试用例了呢？答案：在理论上是，但在实际工程中还远远不是。之所以理论和实际会有这样的差别，是因为在理论上不要考虑的东东，而在实际工程中是不得不考虑的
-
成本。这里的成本包括：测试计划成本、测试执行成本、自动化测试用例、测试自动化成本，测试分析成本，以及测试实现技术局限、测试环境的bug、人为因素和不可预测的随机因素等引入的附加成本等。
此文出自:中国it实验室

③ 什么是测试用例如何设计测试用例

一个测试用例描述了针对某个目标对程序进行测试所采用的一组实际输入、程序执行条件、测试步骤和预期的输出，以核实某个程序或其中的特定路径是否满足特定需求。由于程序输入的范围会非常大，因此会导致一个软件可选的测试用例数目巨大（甚至是无穷的）。这时，需要恰当地设计和选择测试用例集，以在限定的资源和时间内，尽可能地暴露软件中的错误。因此，测试用例集的设计通常被认为是测试中最重要、也是最困难的方面。由于实际测试中使用的测试用例集的输入范围只是程序输入的子集，因此即使软件通过了测试，也无法保证程序一定是正确的。这说明测试本身是不完全的，不能证明程序无错。人们认为，软件测试活动从未间断，只是在软件交付用户使用后，将由用户扮演测试角色而已。
对每个测试用例都需要给出具体描述，表1给出了一个测试用例模版示例。
表1
测试用例模版用例标识：对该测试用例赋予一个唯一标识用例开发者：谁编写的本用例
用例开发日期：编写用例的日期测试项：描述将被测试的具体特征、代码模块等对象测试输入：测试时为程序提供的输入数据前提条件：执行测试时系统应处于的状态或要满足的条件等环境要求：执行测试所需的软硬件环境、测试工具、人员等测试步骤：(1)……；（例如，点击“文件”菜单中的“新建”菜单项）
(2)……；（例如，在“test
case”目录下选择“test5.dat”文件）……预期输出：希望程序运行得到的结果
用例之间的依赖性：该测试用例依赖或受影响的其它测试用例
当测试用例数量多时，文档化的工作量就比较大。这时，模版内容在实际测试中可以根据需要进行简化，例如把各个测试用例所共有的内容单独列出来（如环境要求），并把所有测试用例用一张表格描述出来。

④ 测试用例的设计方法有哪些

黑盒测试用例设计方法包括等价类划分法、边界值分析法、错误推测法、因内果图法、判定表容驱动法、正交试验设计法、功能图法、场景图法等。
白盒子测试方法：（强度由低到高）语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖。
测试人员经常用到的有等价类，边界值，场景法，因果图法。
具体方法的使用可以网络下，这里就不啰嗦了。

⑤ 测试用例的设计思路有哪些

通常来来讲，测试工程师会源从以下四个方面考虑来设计测试用例：
1.覆盖需求，既依据需求文档或原型来设计功能模块级测试用例；
2.相关业务，既着眼于业务的相关性来设计测试用例如：订单模块与支付模块等；
3.特殊角度，既从一些异常处理、极端情况等来设计用例，如苹果手机在极寒天气下的死机问题；
4.补充完善，基于一些内外部经验或行业规范来设计用例，如金融行业的合规性测试用例等。
测试用例的设计思路，每一条思路的详解去黑马程序员的论坛去看！文字看不懂也有课程，自己去官网找，或者对话框问问。哥们在黑马学出来的，但是我说的这些都是免费的。都是我哥们在我当初找工作的时候推荐我看的。

⑥ 单元测试的测试用例设计主要依据是详细设计说明吗

单元测试所对应的是详细设计环节，也就是说，单元测试的测试用例是和详细设计一起出现的，在研发人员做详细设计的时候，相应的测试人员也就把测试用例写了出来（来自网络）

⑦ 测试用例设计的基本格式

软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果，下面逐一介绍。 如果我看得远，那是因为我站在巨人的肩上 －－牛顿。
一般来说，每个软件公司的项目可以分为固定的几大类。可以按业务类型划分，比如 ERP 软件、产品数据管理软件、通信软件、地理信息系统软件等等；可以按软件结构来划分，比如 B/S 架构的软件、 C/S 架构的软件、嵌入式软件等等。参考同类别软件的测试用例，会有很大的借鉴意义。如果，公司中有同类别的软件系统，千万别忘记把相关的测试用例拿来参考。如果，系统非常接近，甚至经过对测试用例简单修改就可以应用到当前被测试的软件。 “ 拿来主义 ” 可以极大的开阔测试用例设计思路，也可以节省大量的测试用例设计时间。 测试用例设计完毕后，接下来的工作是测试执行，测试执行中应该注意以下几个问题：
搭建软件测试环境，执行测试用例
测试用例执行过程中，搭建测试环境是第一步。一般来说，软件产品提交测试后，开发人员应该提交一份产品安装指导书，在指导书中详细指明软件产品运行的软硬件环境，比如要求操作系统系统是 Windows 2000 pack4 版本，数据库是 Sql Server 2000 等等，此外，应该给出被测试软件产品的详细安装指导书，包括安装的操作步骤、相关配置文件的配置方法等等。对于复杂的软件产品，尤其是软件项目，如果没有安装指导书作为参考，在搭建测试环境过程中会遇到种种问题。
如果开发人员拒绝提供相关的安装指导书，搭建测试中遇到问题的时候，测试人员可以要求开发人员协助，这时候，一定要把开发人员解决问题的方法记录下来，避免同样的问题再次请教开发人员，这样会招致开发人员的反感，也降低了开发人员对测试人员的认可程度。 测试环境搭建之后，根据定义的测试用例执行顺序，逐个执行测试用例。在测试执行中需要注意以下几个问题：
全方位的观察测试用例执行结果： 测试执行过程中，当测试的实际输出结果与测试用例中的预期输出结果一致的时候，是否可以认为测试用例执行成功了？答案是否定的，即便实际测试结果与测试的预期结果一致，也要查看软件产品的操作日志、系统运行日志和系统资源使用情况，来判断测试用例是否执行成功了。全方位观察软件产品的输出可以发现很多隐蔽的问题。以前，我在测试嵌入式系统软件的时候，执行某测试用例后，测试用例的实际输出与预期输出完全一致，不过在查询 CPU 占用率地时候，发现 CPU 占用率高达 90 %，后来经过分析，软件运行的时候启动了若干个 1ms 的定时器，大量的消耗的 CPU 资源，后来通过把定时器调整到 10ms ， CPU 的占用率降为 7 %。如果观察点单一，这个严重消耗资源的问题就无从发现了。
加强测试过程记录： 测试执行过程中，一定要加强测试过程记录。如果测试执行步骤与测试用例中描述的有差异，一定要记录下来，作为日后更新测试用例的依据；如果软件产品提供了日志功能，比如有软件运行日志、用户操作日志，一定在每个测试用例执行后记录相关的日志文件，作为测试过程记录，一旦日后发现问题，开发人员可以通过这些测试记录方便的定位问题。而不用测试人员重新搭建测试环境，为开发人员重现问题。
及时确认发现的问题： 测试执行过程中，如果确认发现了软件的缺陷，那么可以毫不犹豫的提交问题报告单。如果发现了可疑问题，又无法定位是否为软件缺陷，那么一定要保留现场，然后知会相关开发人员到现场定位问题。如果开发人员在短时间内可以确认是否为软件缺陷，测试人员给予配合；如果开发人员定位问题需要花费很长的时间，测试人员千万不要因此耽误自己宝贵的测试执行时间，可以让开发人员记录重现问题的测试环境配置，然后，回到自己的开发环境上重现问题，继续定位问题。
与开发人员良好的沟通： 测试执行过程中，当你提交了问题报告单，可能被开发人员无情驳回，拒绝修改。这时候，只能对开发人员晓之以理，做到有理、有据，有说服力。首先，要定义软件缺陷的标准原则，这个原则应该是开发人员和测试人员都认可的，如果没有共同认可的原则，那么开发人员与测试人员对问题的争执就不可避免了。此外，测试人员打算说服开发人员之前，考虑是否能够先说服自己，在保证可以说服自己的前提下，再开始与开发人员交流。 测试执行过程中，应该注意及时更新测试用例。往往在测试执行过程中，才发现遗漏了一些测试用例，这时候应该及时的补充；往往也会发现有些测试用例在具体的执行过程中根本无法操作，这时候应该删除这部分用例；也会发现若干个冗余的测试用例完全可以由某一个测试用例替代，那么删除冗余的测试用例。
总之，测试执行的过程中及时地更新测试用例是很好的习惯。不要打算在测试执行结束后，统一更新测试用例，如果这样，往往会遗漏很多本应该更新的测试用例。

⑧ 软件测试用例的几种设计方法

一、等价类划分
等价类划分主要适用于单个输入条件，输入为数值型的情况，如果输入规定了输入区间，可划分出一个有效等价类，两个无效等价类;如果输入只规定了输入范围，可划分出一个有效等价类，一个无效等价类。
二、边界值
边界值方法也是适用于单个输入条件的情况，输入类型可以数值、字符等，要测试的边界包括上点、下点、离点。
三、错误推测法
错误推测法主要是测试设计人员的测试经验相关,测试经验不同,设计出来的测试用例也区别很大。
四、因果图法
因果图方法考虑输入的组合，特别适用于多个输入条件相关有关联又相互约束的情况。
设计步骤：
1)罗列出输入与输出;
2)根据输入与输出画出因果图;
3)标出约束跟限制;
4)把因果图转化成判定表;
5)根据判定表的每一列设计测试用例。
五、判定表驱动法
判定表适合于解决多个逻辑条件的组合。将各种逻辑的组合罗列出来，避免遗漏。不能表达重复的操作。
判定表包括条件桩、条件项、动作桩、动作项。
条件桩：列出所有条件，次序无关;
条件项：列出所对应条件的所有可能情况下的取值;
动作桩：列出可能采取的操作，次序无关;
动作项：列出条件项各种取值情况下采取的操作。
设计步骤：
1)确定规则个数，条件及各条件取值的组合;
2)列出条件桩、动作桩;
3)列出条件项;
4)列出动作项;
5)初始化判定表;
6)规则简化、合并。

⑨ 测试用例设计的基本原则是什么

1、测试用例的代表性：能够代表并覆盖各种合理的和不合理、合法的回和非法的、边界的和越界答的、以及极限的输入数据、操作和环境设置等。
2、测试结果的可判定性：即测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果。
3、测试结果的可再现性：即对同样的测试用例，系统的执行结果应当是相同的。

不管是从个人角度还是从公司角度，根据我这几年的经验我觉得case的设计应该符合以下几点：
1、一个case一个功能点：每个case都要有个测点，找准一个测点则可，不能同时覆盖很多功能点，否则执行起来牵连太大；
2、case的易读：从执行者的角度去写case，最好不要有太多的术语在里面，如果要有最好指明具体位置；
3、case的执行粒度：粒度越小越好；
4、步骤清晰：一个case多个步骤，可一个重点，步骤指名人们怎么去操作，expect则指明这样操作之后应该看到什么结果---最好不要用正确，正常，错误之类的含糊主观的字眼。
5、总体设计：先正常，后异常，这样可以确保正常情况下功能能够走通。
总之：对于一个新来的tester，给他个case和我们的软件，他就能顺利取执行case.

⑩ 如何选择测试用例设计方法

设计方法如何选择
p当遇到需要输入数据时，首先进行等价类和边界值版，这是减权
少工作量和提高测试效率最有效方法
p用错误推测法再追加一些测试用例
p对照程序逻辑，如果存在组合，用判定表设计用例
p对于业务流清晰的功能，利用场景法贯穿整个测试案例过程，
再针对不同节点综合使用其他测试方法
p 测试用例的设计方法不是单独存在的
p 在实际测试中，往往是综合使用各种方法才能有效提高测试
效率和测试覆盖度。