case1

测试用例^[1]（Test Case）目前没有统一的定义。比较常用的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。

不同类别的软件，测试用例是不同的。不同于诸如系统、工具、控制、游戏软件，管理软件的用户需求更加不统一，变化更大、更快。

一、测试用例是软件测试的核心

软件测试的重要性是毋庸置疑的。但如何以最少的人力、资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质，则是软件公司探索和追求的目标。每个软件产品或软件开发项目都需要有一套优秀的测试方案和测试方法。

用例编号、测试项描述、操作步骤、输入、预期结果、实际结果、测试结果、缺陷编号、回归测试结果、最终测试结果、测试人、测试时间、备注

什么是软件测试用例?

软件测试用例就是指导你对软件执行操作，帮助你证明软件功能或发现软件缺陷的一种说明。
1. 编写测试用例最终目的是发现更多软件中的bug。
2. 测试用例是测试人员进行测试操作的依据，它定义了测试的前提，测试环境，测试步骤，测试预期结果等要素，测试人员主要根据它来进行测试。

他的形式一般是这样的

假设一下吧。现在要求你测试一下百度知道的提交回答功能。

用例编号：提交问题001（编号通常会根据功能或模块编写）
测试目的：验证当用户回答完问题后，可以正常提交答案。（多数是会写需求规格的说明，总之要让人看明白你这条用例是想测什么）
测试标题：这个有时候就包含了测试目的，目的是可以不写的，但测试用例标题是必须的。
重要级别：像提交回答这条用例，多数会被列为最高级别用例，因为是最基本的功能。往往越是基本的，级别越高。原因在于，如果基本功能都有缺陷，那根本不用测别的功能，版本直接打回。
预制条件：1、百度知道运转正常。2、用户已登陆。3、进入了自己想要回答的问题页面。（也就是你做这条测试前必须要有的前提条件）
操作步骤：1、将光标点入“我来帮他解答”下的输入栏。
          2、输入想提交的答案
          3、点击提交回答
          4、验证提交后答案是否能显示到当前问题下
          （输入数据多数时候是合并到操作步骤中的，比如这条里的输入数据就是“答案”）
预期结果：1点击提交回答后，页面提示回答成功。2再次查看该问题时,刚刚的答案可以正确显示……

其中所有的标题 为软件测试用例需要包含属性。冒号后面是对这一条用例的具体描述。

软件测试的测试用例怎么写？

比如一个网页的登录窗口，有要输入用户名，密码等等。这样的一个网页怎么写测试用例

● 测试用例编号
  ◇规则：编号具有唯一性、易识别性，由数字和字符组合成的字符串
  ◇约定：
  系统测试用例：产品编号-ST-系统测试项名-系统测试子项名-XXX
  集成测试用例：产品编号-IT-集成测试项名-集成测试子项名-XXX
  单元测试用例：产品编号-UT-单元测试项名-单元测试子项名-XXX
  ● 测试项目
  ◇规则：当前测试用例所属测试大类、被测需求、被测模块、被测单元等
  ◇约定：
  系统测试用例测试项目：软件需求项 如：测试手机在没有SIM卡的情况下，可以拨打紧急电话
  集成测试用例测试项目：集成后的模块名或接口名 如：测试模块A提供的文件接口
  单元测试用例测试项目：被测试的函数名 如：测试函数int ReadFile(char *pszFileName)
  ● 测试标题
  规则：测试用例的概括简单的描述用例的出发点、关注点，原则上不能重复。
  ● 重要级别
  规则
  高：保证系统基本功能、核心业务、重要特性、实际使用频率高的测试用例；
  中：重要程度介于高和低之间的测试用例；
  低：实际使用频率不高、对系统业务功能影响不大的模块或功能的测试用例。
  ● 预置条件
  规则：执行当前测试用例需要的前提条件，是后续步骤的先决条件
  ● 输入
  规则：用例执行过程中需要加工的外部信息，输入、文件、数据库等
  ● 操作步骤
  规则：执行当前测试用例需要经过的操作步骤，保证操作步骤的完整性。
  ● 预期输出
  规则：当前测试用例的预期输出结果，包括返回值的内容、界面的响应结果、输出结果的规则符合度等

当测试用例编写完成，并通过审核后，就进入到软件测试最主要的阶段，就是执行测试用例，进行软件测试。不过在执行测试是有几个地方需要注意：
　　1、仔细检查软件测试环境是否搭建成功。执行测试前要按照测试用例中描述的测试环境去搭建，因为测试用例中的执行都是建立在这个测试环境之上的，如果测试环境的不一致，会影响测试用例的执行，和测试目的的证明。
 
　　2、注意测试用例中的前提条件和特殊规程说明。因为有些测试软件是有顺序性的，那么它的测试用例就会有一些执行前提或特殊说明。比如要测试某个软件的登陆功能，那么测试前必须创建用户，并为用户分配一定的权限等。如果前提条件和特殊说明没有注意，会导致测试用例的无法执行。
 
　　3、测试用例要执行全部执行，每条用例至少执行一遍。因为编写测试用例时，它考虑了测试覆盖率的问题，每条测试用例都对应一个功能点，如果少执行一条，就会有一个功能点没有测试到。我们执行测试前要认为待测试软件的每条功能点都是未实现的，每个功能点我们都要测试一遍，才能保证待测试软件能正确满足用户需求。
 
　　4、执行测试用例时，要详细记录软件系统的实际输入输出，仔细对比实际输入和测试用例中的期望输入是否一致。如果不一致，要从多个角度多测试几次，尽量详细的定位软件出错的位置和原因，并测试出因为这个错误会不会导致更严重的错误出现，最后把详细的输入和实际的输出，以及对问题的描述写到测试报告中。在一个项目组中，项目的开发时间是有限的，如果我们测试时能把问题描述的详细一些，那么开发人员就会很容易的重现这个问题，也就能更快的解决问题，节省项目时间。
 
　　5、不要放过任何偶然想象。我们在测试时，有时会发现某条用例执行时，软件会出错，但是当再次执行时这个错误就不再重现。这种情况，一般大家就会认为是偶然现象，就会忽略过去。其实，这种错误才是隐藏最深的，最难发现的错误。我们要遇到这种情况时，要仔细分析这种情况，不要放过任何小的细节，多测试几次，要准确的找出问题的原因。我以前遇到过这样的情况，当刚打开这个软件，执行某项操作时，软件抛出了一个异常，然后我再次执行同样的操作时，这个异常确消失了，软件功能正常。后来我又多次执行这项功能的相关操作，问题依然没有重新，最后当我意外关闭这个软件后重新打开时，问题才重现了出来，后来查出因为其中的一个变量没有赋初始值造成的。
 
　　以上部分就是执行测试时需要注意的地方，最后再说一下测试开始和结束的条件，按照下面的条件执行软件测试。
 
　　测试开始标准：
 
　　1、测试计划评审通过
 
　　2、测试用例已编写完成，并已通过评审；
 
　　3、存在已提交的可测试的系统；
 
　　4、测试环境已搭建完毕。
 
　　测试退出标准：
 
　　1、测试用例全部通过；
 
　　2、存在的问题已得到合理的处理。
 
　　测试停止标准：
 
　　1、近半数以上测试用例无法执行；
 
　　2、测试环境与要求不符。
 
　　3、开发中需求频繁变动

测试用例的八大要素：
1、用例编号：
    测试用例编号是由字母和数字组合而成的，用例的编号应该具有唯一性，易识别性，比如可以采用统一的约定，产品编号_ST_系统测试项名_系统测试子项名_编号。这样看到编号就可以知道是做的什么测试，测试的对象是什么，也方便维护。
2、测试项目：
    你现在这个测试用例所测的项目名，可以是测试用例所属的大类，被测需求，被测的模块，或者是被测的单元。例如：计算器加法功能
3、测试标题：
    测试标题是对测试用例的简单描述。用概括的语言描述该测试用例的测试点。每个测试用例的标题不能够重复，因为每个测试用例的测试点事不一样的。例如：手机在没有SIM卡的情况下，拨打119.
4、重要级别：
    重要级别分为高中低三等：
    高：保证系统基本功能、重要特性、实际使用频率比较高的用例；
    中：重要程度介于高和低之间的测试用例；
    低：实际使用频率不高，对系统业务功能影响不大的模块或功能的测试用例。
    注：一般情况下，重要级别为高的测试用例，一个测试子项里有且仅有一个，大多数都是重要级别为中的测试用例。因为一般我们会进行一个系统测试预测试项，如果重要级别为高的太多，则就失去了预测试的实际意义。
5、预置条件：
    就是执行当前测试用例的前提描述，如果不满足这些条件，则无法进行测试
6、测试输入：
    测试用例执行时，需要输入的外部信息。例如：某一个文件，数据记录等
7、操作步骤：
    执行当前测试用例所要经过的操作步骤，需要给出每一步操作的详细描述，测试人员根据测试用例操作步骤，完成测试用例的执行
8、预期输出：
    当前测试用例的预期输出结果，用来与实际结果比较，如果相同则该测试用例通过，否则该测试用例失败。