软件测试文档入门

不知不觉，做测试有一年多两年了，今天比较有空，把以前入职的经历经验与大家分享，欢迎DIS!

 

目前在实际生产中，测试多数还是处于辅助位置，伴随着开发的进度开展工作的。下面对测试工作的展开做一下简单介绍

1、阅读业务需求说明书，熟悉测试对象

       在测试分工前，每个人都要对测试对象的整体有所了解，以便测试关联性的保证和多角度测试的实现。当然，对于测试分工后的具体负责模块要有更加细致深入的了解，做到专业胜任。通常在阅读测试需求的时候会做功能点的梳理、拆分和测试需求的初步编写，这些都有助于对测试对象的理解。注意专业术语、概念的积累掌握，通过咨询客户方专业业务人员和自查资料、小组讨论等方式，完成测试执行工作的前期系统准备工作。

2、测试相关文档的处理

       与软件测试相关的工作文档主要包括测试计划、测试方案、测试案例以及测试过程跟踪和测试报告。其中测试案例和测试过程跟踪即缺陷报告单是测试执行人员的工作重点文档，而测试计划和测试方案、测试报告主要由测试项目负责人员进行编辑，但是测试人员要为其提供编辑材料，如测试计划、测试方案制定过程中的个人工作进度评估，测试资源需求提出和优化建议已经最终文档的评审等，并且在此过程中熟悉文档内容，对整体项目进度有所把控，并且积累文档经验，争取有需要的时候，可以自己胜任各项文档的编辑。

       在此，首先对工作中接触最多也最基础的测试案例、测试缺陷报告的具体样式和注意事项做如下说明。

 

（1）测试案例

        编写测试案例的方法主要有等价类、边界值、错误推测、因果图、判定表、正交实验、场景法等。通常测试案例的设计是多种方法结合的产物，在测试案例中体现的是方法组合后的最优化。测试案例设计的目的是指导测试工作的进行，保证测试的规范化、可重复化和易于管理。测试案例的格式多样，但是包含的主要要素大体相同。以本公司项目中使用的案例模板为例进行具体讲解。

       通常测试案例包含的要素有案例编号、案例名称、测试模块（即主题路径）、测试负责人、测试案例概述、测试优先级、测试步骤及详细描述、测试预期结果等部分组成。由于测试案例往往需要结合不同的测试管理工具来使用所以测试案例模版中的项目可能会有个别差异。例如，我公司使用QC进行测试项目的管理，测试案例编号会自动生成，故此未在测试案例中体现。

 

①测试案例名称

 如图所示，一般会按照子系统_子模块_测试要点_编号的格式来编写，举例来说，比如：存款（子系统）_通知存款_7天通知存款取款_01,可以根据不同的测试模块进行梯度的适当调整，但要保持案例格式的整体一致性。

②测试主题路径

 例子中的主题路径是结合QC而言的。文档导入excel时需要依据严格的路径，并为此生成QC中的结构树。注意路径输入中的“/”方向，否则会导入失败。具体的注意事项会在介绍QC的使用时详细描述

③测试负责人

如实填写该测试案例的执行人，通常是案例设计者。否则测试案例的设计者和执行者都要标识，确保发生问题时能够定位测试问题原因

④测试要点概述

以精简、准确的语言描述测试案例所要进行的测试的内容。通常格式是验证XXX即验证某种承接测试案例名称的情景、功能等。比如本例中的案例名称指出测试通知存款取款，则测试要点可以为 验证到期7天通知存款取款交易正常。通常一个小的功能点需要一组案例来测试，一组案例中的一系列个体分别验证不同情景。一般是一个正常交易情景配合多个异常情景的处理，采用正反案例的模式确保测试案例对测试功能点的覆盖。

     

⑤ 测试步骤描述

根据测试对象的不同，测试步骤描述也不同。通常在步骤描述中标明测试是怎么样进行的，在哪里进行，输入什么要素以及输入内容的注意事项等。测试步骤描述是测试案例的重点，好的描述清晰简洁，可重用性高，能够帮助定位问题，解决问题。在测试步骤描述中按照测试案例的执行顺序写出测试执行的具体过程，并在反用例的测试步骤描述中对异常输入的验证带入。需要对测试对象测试案例具有良好的整体理解，结合自身经验来保证测试进行的完备。一般的验证性测试如简单的查询，文件的正常导入等，可以不进行太细致的步骤描述，案例执行者结合操作界面就能较好地完成测试，但是，专门针对各种输入数据的验证就需要在测试案例步骤描述中详细说明输入数据，必要时要添加数据使用备注

⑥测试预期结果

预期结果是对测试案例执行后的测试表现的预测，是评定测试是否通过的重要依据。测试预期一定要明确、唯一，使用用语也要通俗易懂。测试案例和测试需求的关联性强，并且相互过度。测试需求设计得越详细，测试需求的工作量加大，但是利于测试案例的编写，甚至直接转化为测试案例。具体操作掌控的尺度要结合实际需要

（2）测试缺陷报告单

记录测试案例执行过程中及相关测试过程中发现的问题，结合测试平台工具进行测试问题的统计分析和产品质量评估等。测试缺陷报告记录单的样式也是多样的

 

测试缺陷报告单中通常包含的要素有缺陷ID、摘要介绍、问题描述、主题、缺陷类型、缺陷严重程度、提出人、处理人、提出时间、解决时间、以及缺陷的最终状态等。其中问题描述是缺陷记录的重点，比较能表明测试缺陷记录的质量

①缺陷ID

由结合的测试管理工具，如QC一类的软件在导入是形成，或者按照一定规则自定义，通常可以用测试缺陷产生位置（即测试案例中描述的主题位置）字母缩写+数字序号的方式表示，如CKJY01，即存款交易第一个缺陷

② 摘要

简要描述缺陷问题，对对缺陷做初步的定义

③问题描述

缺陷问题描述是测试缺陷报告单中的重点，最能体现缺陷提交的质量。

在缺陷描述中要注明缺陷产生的操作背景，即在进行怎样的特定操作时出现的该缺陷问题，接下来就要将缺陷重现。具体的输入步骤，输入内容，操作方式等都要条理清晰的列出，然后写明预期结果（参照案例）和实际结果，使缺陷通俗易懂。力所能及的话最好再写明缺陷产生的原因预测，便于开发人员定位解决问题

④缺陷主题

缺陷主题用来标记缺陷产生的位置，便于缺陷分类。一般要与案例表述一致

⑤提出人、处理人、提出时间、解决时间

这些是用于统计、跟踪缺陷解决状态的重要标尺，按照实际情况填写即可

⑥缺陷类型

产生的缺陷所属类型，一般包括功能问题、性能问题的大类及数据、通讯、界面、易用性等具体分类。按照实际情况依据标准分析判定

⑦缺陷级别

判定缺陷严重程度，是缺陷解决优先级的重要判定依据之一。通常按照问题严重性由高到低的顺序降序排列，即一级缺陷为最高（有时也表示为A级）缺陷。简单地，可以将缺陷定义为四级

 

（1、致命错误：由于程序所引起的死机，非法退出，死循环，数据库死锁，因错误操作导致的程序中断，功能错误，与数据库连接错误，数据通讯错误等；

2、严重错误：程序错误，程序接口错误，数据库的表、业务规则、缺省值未加完全约束条件等；

3、告警错误：操作界面错误，打印内容、格式错误，简单为输入限制未放在前台控制，删除操作未有提示，数据库表中有过多的空字段等；

4、建议性错误：界面不规范，辅助说明描述不清楚，输入输出不规范，长操作未给用户提示，提示窗口文字未使用行业术语等）

结合工作经验和适当讨论，合理定义缺陷级别

⑧缺陷状态

通常地，缺陷状态包括新建、打开、已修复、已关闭、拒绝、重新打开、延迟等各种情景，依据项目实际适当定义。缺陷的最终状态为关闭，但是特殊情况下延迟等状态也可以作为一定阶段的最终状态

测试缺陷截图

测试案例截图