21测试用例编写指南Word文档下载推荐.docx

21测试用例编写指南Word文档下载推荐.docx

《21测试用例编写指南Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《21测试用例编写指南Word文档下载推荐.docx（5页珍藏版）》请在冰豆网上搜索。

审批：

变更记录

日期

版本

变更说明

作者

创建

1概述

软件测试是为了发觉错误而执行程序的进程，或说，软件测试是依照软件开发各时期的规格说明和程序的内部结构而精心设计一批测试用例（即输入数据及其预期的输出结果），并利用这些测试用例去运行程序，以发觉程序错误的进程。

1.1目的

测试是程序的执行进程，目的在于发觉错误；

一个好的测试用例在于能发觉至今未发觉的错误；

设计测试用例的目的确实是想以最少的时刻和人力，系统地找出软件中潜在的各类错误和缺点。

1.2范围

该文档适用于软件统一开发进程中的编写测试用例的指导活动。

1.3术语概念

用户：

是指将利用软件系统的人，而不必然是软件的最终购买者等。

2内容组成

第一，测试用例应有简单的功能描述和业务逻辑描述，以便执行用例的人能专门快的了解此模块的功能需求；

第二，测试用例最重要的组成部份确实是要有测试输入数据、执行的动作和与之对应的预期输出结果这三部份组成。

测试之前应当依照测试的要求选择测试用例，用来查验程序员编制的程序，因此不但需要测试的输入数据，而且需要针对这些输入数据的预期输出结果。

3测试数据要求

在设计测试用例时，应当包括合理的输入条件和不合理的输入条件。

合理的输入条件是指能验证程序正确的输入条件，不合理的输入条件是指异样的，临界的，可能引发问题异变的输入条件。

软件系统处置非法命令的能力必需在测试时受到查验。

用不合理的输入条件测试程序时，往往比用合理的输入条件进行测试能发觉更多的错误。

不论如何测试，都不可能把所有可能的输入数据都拿来进行所谓的穷举测试，因此咱们要将测试数据分类，在设计测试用例时就要考虑各类数据的输入输出情形。

3.1正常数据

这是一类常见的也是最直观的输入数据。

不管是程序员仍是测试人员，在测试一个系统时最先考虑的确实是这种数据。

往往这种数据在测试进程中很少犯错，确实是因为程序员在程序开发进程中常常拿这种数据做为测试数据进行调试。

在设计测试用例时，这种数据往往被人们轻忽，但它应做为一类不可缺少的数据在用例中表现出来。

例如，在的输入框中输入的正常数据是100027，而当输入abcdefg、100这些就属于非正常的数据。

3.2反常规数据

这种数据在设计测试用例时往往被人们轻忽，因为它是最不常见、最不可能的输入方式。

因为在日常生活中可不能用到，因此工程师在开发程序时很少有人去想输入这种数据时输出的结果会是怎么样的。

而测试员用这种数据测试程序时，会发觉很多的错误。

因此设计测试用例时应考虑这种数据的输出结果。

例如，在日期的输入框中正常的输入格式为、2000-1-1等；

咱们都明白每一个月最多有31天，当输入确实是反常规数据。

3.3边界数据

人们从长期的测试工作体会得知，大量的错误是发生在输入或输出范围的边界上，而不是在输入范围的内部。

因此在设计测试用例时应针对各类边界情形充分考虑，能够查出更多的错误。

利用边界值分析方式设计测试用例，第一应确信边界情形。

通常输入等价类与输出等价类的边界，确实是应着重测试的边界情形。

应被选取正好等于，方才大于，或方才小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。

边界值分析方式是最有效的黑盒测试方式，但当边界情形很复杂的时候，要找出适当的测试用例还需针对问题的输入域、输出域边界，耐心细致地逐个考虑。

例如，在做三角形计算时，要输入三角形的三个边长：

A、B和C。

咱们应注意到这三个数值应当知足A＞0、B＞0、C＞0、A＋B＞C、A＋C＞B、B＋C＞A，才能组成三角形。

但如果是把六个不等式中的任何一个大于号“＞”错写成大于等于号“≥”，那就不能组成三角形。

问题恰出此刻容易被疏忽的边界周围。

那个地址所说的边界是指，相当于输入等价类和输出等价类而言，稍高于其边界值及稍低于其边界值的一些特定情形。

3.4模块接口数据

检测模块间功能实现正确与否，就要在测试用例中设计一组模块之间的接口数据。

为此，对模块接口，包括参数表、挪用子模块的参数、全程数据、文件输入／输出操作都必需检查，要有相应的输入数据和预期的输出结果。

3.5体会数据

所谓体会确实是猜想法，利用这种方式进行测试时输入的数据确实是体会数据。

猜想能够说是一种凭直觉的特定进程，很难走出标准的执行步骤，它专门大方面还依托于测试员的体会程度，利用这种数据测试的系统往往会有专门好的成效。

一样，咱们可不能单单采纳一种技术，而是多种技术相结合的方式，比如，咱们会设计一些功能分解作为线索，在结合边值分析和等价类划分，还可加一些随机测试和一些利用猜想而取得的用例。

4测试活动要求

在测试进程中，穷举所有的途径或将系统中遍历的所有流程走完这是不可能的，但充分覆盖程序逻辑，并确保软件的所有条件是有可能的。

为了节省时刻和资源，提高测试效率，就必需要从数量极大的可用测试用例中精心地设计一些测试流，对模块中大体执行途径和重要的执行途径进行测试。

使得采纳这些流程能够达到最正确的测试成效，能够高效率地把隐藏的错误揭露出来。

设计这些测试流程要保证在测试中，程序的每一个可执行语句至少要执行一次，能够遵循以下这些覆盖准那么：

（1）语句覆盖：

语句覆盖确实是设计假设干个测试用例，运行被测程序，使得每一可执行语句至少执行一次。

这种覆盖又称为点覆盖，它使得程序中每一个可执行语句都取得执行，但它是最弱的逻辑覆盖，成效有限，必需与其它方式交互利用。

（2）判定覆盖：

判定覆盖确实是设计假设干个测试用例，运行被测程序，使得程序中每一个判定的取真分支和取假分支至少经历一次。

判定覆盖又称为分支覆盖。

判定覆盖只比语句覆盖稍强一些，但实际成效说明，只是判定覆盖，还不能保证必然能查出在判定的条件中存在的错误。

因此，还需要更强的逻辑覆盖准那么去查验判定内部条件。

（3）条件覆盖：

条件覆盖确实是设计假设干个测试用例，运行被测程序，使得程序中每一个判定的每一个条件的可能取值至少执行一次。

条件覆盖深切到判定中的每一个条件，但可能不能知足判定覆盖的要求。

（4）判定－条件覆盖：

判定－条件覆盖确实是设计足够的测试用例，使得判定中每一个条件的所有可能取值至少执行一次，同时每一个判定本身的所有可能判定结果至少执行一次。

换言之，即是要求各个判定的所有可能的条件取值组合至少执行一次。

（5）多重条件覆盖：

多重条件覆盖确实是设计足够的测试用例，运行被测程序，使得每一个判定的所有可能的条件取值组合至少执行一次。

这是一种相当强的覆盖准那么，能够有效地检查各类可能的条件取值的组合是不是正确。

它不但可覆盖所有条件的可能取值的组合，还可覆盖所有判定的可取分支，但可能有的途径会遗漏掉，测试还不完全。

例如，购销存软件的存货核算暂估功能。

在设计此测试用例中，考虑产品功能的数量不宜过量，应以自己实际情形而定，但在考虑功能的利用条件时，应当尽可能的充分。

（1）每一种暂估方式一个测试案例

（2）充分考虑存货的所有属性（非受托、受托、有无辅计量等）

（3）充分考虑时刻因素（期初、上期、本期、以后、结转下年等）

（4）充分考虑采购的结算情形（部份、外币、税率、折扣、费用等）

（5）充分考虑单据情形（蓝字、红字等）

5白盒测试

白盒测试把测试对象看做一个打开的盒子，许诺测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑途径进行测试。

通过在不同点检查程序的状态，确信实际的状态是不是与预期的状态一致。

白盒测试对测试人员的代码查看能力要求很高，本公司多采纳黑盒测试。

6压力及性能测试

性能测试确实是系统对响应时刻、事务处置速度和其他与时刻相关的需求进行评测和评估。

性能测试的目标是核实性能需求是不是都已知足。

实施和执行性能测试的目的是将测试对象的性能行为看成条件（例如工作量或硬件配置）的一种函数来进行评测和微调，从而找出因资源不足或资源争用而致使的错误。

若是内存或磁盘空间不足，测试对象就可能会表现出一些在正常条件下并非明显的缺点。

而其他缺点那么可能由于争用共享资源（如数据库锁或网络带宽）而造成的。

压力测试实际也是一种性能测试。

在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，和持续正常运行的能力。

压力测试的目标是确信并确保系统在超出最大预期工作量的情形下仍能正常运行。

另外，压力测试还要评估性能特点，例如，响应时刻、事务处置速度和其他与时刻相关的方面。

压力测试还可用于确信测试对象能够处置的最大工作量。