测试用例,模版

转载:https://blog.csdn.net/a823080387/article/details/55100730

 

该范例已经包含一个测试用例的模板。

项目/软件	技术出口合同网络申领系统 （企业端）	程序版本	1.0.25
功能模块名	Login	编制人	xxx
用例编号-	TC-TEP_Login_1	编制时间	2002.10.12
相关的用例	无
功能特性	用户身份验证
测试目的	验证是否输入合法的信息，容许合法登录，阻止非法登录
预置条件	无	特殊规程说明	如数据库访问权限
参考信息	需求说明中关于“登录”的说明
测试数据	用户名=yiyh 密码=1
操做步骤	操做描述	数 据	指望结果	实际结果	实际结果	测试状态（P/F）
1	输入用户名称，按“登录”按钮。	用户名=yiyh，密码为空	显示警告信息“请输入用户名和密码！”
2	输入密码，按“登录”按钮。	用户名为空，密码=1	显示警告信息“请输入用户名和密码！”
3	输入用户名和密码，按“登录”按钮。	用户名=yiyh，密码=2	显示警告信息“请输入用户名和密码！”
4	输入用户名和密码，按“登录”按钮。	用户名=xxx，密码=1	显示警告信息“请输入用户名和密码！”
5	输入用户名和密码，按“登录”按钮。	用户名=xxx，密码=2	显示警告信息“请输入用户名和密码！”
6	输入用户名和密码，按“登录”按钮。	用户名=空，密码=空	显示警告信息“请输入用户名和密码！”
7	输入用户名和密码，按“登录”按钮。	用户名=yiyh，密码=1	进入系统页面。
8	输入用户名和密码，按“登录”按钮。	用户名=Admin，密码=admin	进入系统维护页面。
9	输入用户名和密码，按“登录”按钮。	用户名=yiyh'',密码=1	显示警告信息“请输入用户名和密码！”
10	输入用户名和密码，按“登录”按钮。	用户名=yiyh，密码=1''	显示警告信息“请输入用户名和密码！”
11	输入用户名和密码，按“重置”按钮。	用户名=yiyh，密码=1	清空输入信息
测试人员		开发人员			项目负责人

三、测试用例设计的误区

一、能发现到目前为止没有发现的缺陷的用例是好的用例：

首先要申明，其实这句话是十分有道理的，但我发现不少人都曲解了这句话的原意，一心要设计出发现“难于发现的缺陷”而陷入盲目的片面中去，忘记了测试的目的所在，这是十分可怕的。我倾向于将测试用例看成一个集合来认识，对它的评价也只能对测试用例的集合来进行，测试自己是一种“V&V”的活动，测试须要保证如下两点：

l 程序作了它应该作的事情 

l 程序没有作它不应作的事情

所以，做为测试实施依据的测试用例，必需要能完整覆盖测试需求，而不该该针对单个的测试用例去评判好坏。

 

二、测试用例应该详细记录全部的操做信息，使一个没有接触过系统的人员也能进行测试；

不知道国内有没有公司真正作到这点，或者说，不知道有国内没有公司可以将每一个测试用例都写得如此详细。在个人测试经历中，对测试用例描述的详细和复杂程度也曾有过不少的彷徨。写得太简单吧，除了本身没人可以执行，写得太详细吧，消耗在测试用例维护（别忘了，测试用例是动态的，一旦测试环境、需求、设计、实现发生了变化，测试用例都须要相应发生变化）上的时间实在是太惊人，在目前国内大部分软件公司的测试资源都不足的状况下，恐怕很难实现。但我恰恰就能遇到一些这样的老总或者是项目负责人，甚至是测试工程师自己，全然不顾实际的资源状况，必定要写出“没有接触过系统的人员也能进行测试”的用例。

在讨论这个问题以前，咱们能够先考虑一下测试的目的。测试的目的是尽量发现程序中存在的缺陷，测试活动自己也能够被看做是一个Project，也须要在给定的资源条件下尽量达成目标，根据我我的的经验，大部分的国内软件公司在测试方面配备的资源都是不足够的，所以咱们必须在测试计划阶段明确测试的目标，一切围绕测试的目标进行。

除了资源上的约束外，测试用例的详细程度也须要根据须要肯定。若是测试用例的执行者、测试用例设计者、测试活动相关人对系统了解都很深入，那测试用例就没有必要太详细了，文档的做用原本就在于沟通，只要能达到沟通的目的就OK。

在我担任测试经理的项目中，在测试计划阶段，通常给予测试设计30% - 40%左右的时间，测试设计工程师可以根据项目的须要自行肯定用例的详细程度，在测试用例的评审阶段由参与评审的相关人对其把关。

 

三、测试用例设计是一劳永逸的事情；

这句话摆在这里，我想没有一我的会承认，但在实际状况中，却常常能发现这种想法的影子。我曾经参与过一个项目，软件需求和设计已经变动了屡次，但测试用例却没有任何修改。致使的直接结果是新加入的测试工程师在执行测试用例时不知所措，间接的后果是测试用例成了废纸一堆，开发人员在屡次被无效的缺陷报告打扰后，对测试人员不屑一顾。

这个例子可能有些极端，但测试用例与需求和设计不一样步的状况在实际开发过程当中确是家常便饭的，测试用例文档是“活的”文档，这一点应该被测试工程师牢记。

 

四、测试用例不该该包含实际的数据；

测试用例是“一组输入、执行条件、预期结果”、毫无疑问地应该包括清晰的输入数据和预期输出，没有测试数据的用例最多只具备指导性的意义，不具备可执行性。固然，测试用例中包含输入数据会带来维护、与测试环境同步之类的问题，关于这一点，《Effective Software Test》一书中提供了详细的测试用例、测试数据的维护方法，能够参考。

 

五、测试用例中不须要明显的验证手段；

我见过不少测试工程师编写的测试用例中，“预期输出”仅描述为程序的可见行为，其实，“预期结果”的含义并不仅是程序的可见行为。例如，对一个定货系统，输入定货数据，点击“肯定”按钮后，系统提示“定货成功”，这样是否是一个完整的用例呢？是否是系统输出的“定货成功”就应该做为咱们惟一的验证手段呢？显然不是。定货是否成功还须要查看相应的数据记录是否更新，所以，在这样的一个用例中，还应该包含对测试结果的显式的验证手段：在数据库中执行查询语句进行查询，看查询结果是否与预期的一致。

四、测试用例在软件测试中的做用 

    一、指导测试的实施 

    测试用例主要适用于集成测试、系统测试和回归测试。在实施测试时测试用例做为测试的标准，测试人员必定要按照测试用例严格按用例项目和测试步骤逐一实施测试。并对测试状况记录在测试用例管理软件中，以便自动生成测试结果文档。 

    根据测试用例的测试等级，集成测试应测试那些用例，系统测试和回归测试又该测试那些用例，在设计测试用例时都已做明确规定，实施测试时测试人员不能随意做变更。 

    二、规划测试数据的准备 

在咱们的实践中测试数据是与测试用例分离的。按照测试用例配套准备一组或若干组测试原始数据，以及标准测试结果。尤为象测试报表之类数据集的正确性，按照测试用例规划准备测试数据是十分必须的。

除正常数据以外，还必须根据测试用例设计大量边缘数据和错误数据。 

    三、编写测试脚本的"设计规格说明书" 

    为提升测试效率，软件测试已大力发展自动测试。自动测试的中心任务是编写测试脚本。若是说软件工程中软件编程必须有设计规格说明书，那么测试脚本的设计规格说明书就是测试用例。 

    四、评估测试结果的度量基准 

    完成测试实施后须要对测试结果进行评估，而且编制测试报告。判断软件测试是否完成、衡量测试质量须要一些量化的结果。例：测试覆盖率是多少、测试合格率是多少、重要测试合格率是多少，等等。之前统计基准是软件模块或功能点，显得过于粗糙。采用测试用例做度量基准更加准确、有效。 

    五、分析缺陷的标准 

    经过收集缺陷，对比测试用例和缺陷数据库，分析确证是漏测仍是缺陷复现。漏测反映了测试用例的不完善，应当即补充相应测试用例，最终达到逐步完善软件质量。而已有相应测试用例，则反映实施测试或变动处理存在问题。

五、试用例编号规则

目的：好的测试用例编号，能够更好的去了解此项用例所针对的模块，也有助于记忆和新用例的增长。

规则：测试用例编号采用“版本+细类+编号”的形式。

备注：其中“版本”为设计此测试用例的软件版本。

“细类”为小模块中的汉字头一个字母，以最多5个字母为标准。

“编号”为BUG用例的编号，以4位为标准，依次递增。

例如：引导系统V2.01版本中，候车点设置，用例编号能够书写为：

          2.01_HCDSZ_0001

9、集成测试

      集成测试（也叫组装测试，联合测试）是单元测试的逻辑扩展。它的最简单的形式是：两个已经测试过的单元组合成一个组件，而且测试它们之间的接口。从这一层意义上讲，组件是指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合成程序的更大部分。方法是测试片断的组合，并最终扩展进程，将您的模块与其余组的模块一块儿测试。最后，将构成进程的全部模块一块儿测试。此外，若是程序由多个进程组成，应该成对测试它们，而不是同时测试全部进程。

      集成测试识别组合单元时出现的问题。经过使用要求在组合单元前测试每一个单元并确保每一个单元的生存能力的测试计划，能够知道在组合单元时所发现的任何错误极可能与单元之间的接口有关。这种方法将可能发生的状况数量减小到更简单的分析级别。

      集成测试是在单元测试的基础上，测试在将全部的软件单元按照概要设计规格说明的要求组装成模块、子系统或系统的过程当中各部分工做是否达到或实现相应技术指标及要求的活动。也就是说，在集成测试以前，单元测试应该已经完成，集成测试中所使用的对象应该是已经通过单元测试的软件单元。这一点很重要，由于若是不通过单元测试，那么集成测试的效果将会受到很大影响，而且会大幅增长软件单元代码纠错的代价。 

      集成测试是单元测试的逻辑扩展。在现实方案中，集成是指多个单元的聚合，许多单元组合成模块，而这些模块又聚合成程序的更大部分，如分系统或系统。集成测试采用的方法是测试软件单元的组合可否正常工做，以及与其余组的模块可否集成起来工做。最后，还要测试构成系统的全部模块组合可否正常工做。集成测试所持的主要标准是《软件概要设计规格说明》，任何不符合该说明的程序模块行为都应该加以记载并上报。 

      全部的软件项目都不能摆脱系统集成这个阶段。无论采用什么开发模式，具体的开发工做总得从一个一个的软件单元作起，软件单元只有通过集成才能造成一个有机的总体。具体的集成过程多是显性的也多是隐性的。只要有集成，老是会出现一些常见问题，工程实践中，几乎不存在软件单元组装过程当中不出任何问题的状况。从图1能够看出，集成测试须要花费的时间远远超过单元测试，直接从单元测试过渡到系统测试是极不稳当的作法。 

      集成测试的必要性还在于一些模块虽然可以单独地工做，但并不能保证链接起来也能正常工做。程序在某些局部反映不出来的问题，有可能在全局上会暴露出来，影响功能的实现。此外，在某些开发模式中，如迭代式开发，设计和实现是迭代进行的。在这种状况下，集成测试的意义还在于它能间接地验证概要设计是否具备可行性。 

      集成测试的目的是确保各单元组合在一块儿后可以按既定意图协做运行，并确保增量的行为正确。它所测试的内容包括单元间的接口以及集成后的功能。使用黑盒测试方法测试集成的功能。而且对之前的集成进行回归测试。