软件测试之测试用例、测试点写法以及需求分析

软件测试之测试用例、测试点写法以及需求分析

大家如果想成为软件测试的一名老司机，就必须掌握测试用例的写法。

软件由数据+程序+文档组成。我们软件测试工程师，就是给执行程序输入数据，得到输出结果，并判断输出结果是否符合需求规格的过程，而文档就是我们工作内容的可视化。而测试用例，就属于文档的一部分。

测试的生命周期：测试计划 --- 测试方案设计 --- 测试开发 --- 测试执行 --- 测试评估，对测试结果的分析和报告。

测试用例的编写与执行属于测试开发环节。

测试用例是测试工作的核心，是一组在测试时输入输出的标准，测试用例是软件需求的具体对照

测试用例的作用：

检验软件是否满足客户的需求；

体现一个测试人员的工作量；

展现测试的设计思路，可以通过阅读别人的测试用例学习测试用例的设计方法和思路。

测试用例一般包含：

编号、用例名称、测试背景、前置条件、优先级、重要级、测试数据、测试步骤、预期结果、实际结果、备注。

但可以根据实际需要增加、删除、修改部分项，比如：增加分类、子分类等。

这里需要注意，编号并不简单的是1、2、3、4这样子，而是可以通过下划线将一些测试用例的信息包含进去，比如：TV_YUYIN_0001，代表着这条测试用例时测试电视语音相关的；用例名称是用例的名字，这个可以不写；

测试背景是说明该测试用例的背景，是测试什么项目、什么内容的，也可以不写，有时候测试背景通过测试编号、测试文件的名字、标题等就可以表达出来；

前置条件是测试之前应该满足什么条件才可以进行测试，一般要写，如果没有前置条件写无就可以；

优先级和重要级看似差不多，其实关系不大，优先级高并不意味着重要级高；

测试数据是指输入的数据；

测试步骤是必须的，可以根据实际情况写测试步骤，可以写的粗糙，也可以写的很详细，比如第一步是什么，第二步是什么等；

预期结果对应着测试步骤，如果测试步骤写的很详细，那么预期结果也要详细，比如测试步骤有5步，预期结果有2个，别人怎么知道这个结果是哪一步产生的？最好在编号上实现预期结果和操作步骤的统一；

实际结果就是在测试过程中的实际情况，如果一样就写通过、OK等就可以了，如果不一样，需要写明实际结果是什么。有时候，我们可以在实际结果中写OK、false，然后将实际结果写在备注里，也没有问题。

测试用例的编写流程：

需求分析、提取测试点、编写测试用例、测试用例的评审

需求就是客户需要的东西和客户对其的要求。如果这款产品的用户就是直接面向大众的，那么就需要自己去分析大众用户需要的是什么，怎样的功能才能让用户喜欢用。

一般需求分为业务需求、用户需求、功能需求。

业务需求 --- 首先看一下百度上的概念

表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。使用前景和范围（vision and scope）文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求（project charter 或 market requirement）文档。

行业都有自己的领域系统（行业所处的大环境，包括行业习惯、背景等），而根据行业的领域系统及领导、客户等的方向及目标。

用户需求 --- 百度上的概念

描述的是用户的目标，或用户要求系统必须能完成的任务。

这个范围很广，比如软件的界面是否好看、功能使用是否便捷等都属于用户需求。用户需求可以认为是对业务需求的一个具体目标。比如业务需求提出了这个系统具有语音功能，那么用户需求可能就包含了语音具备的功能，比如可以喊“刘德华的电影”去搜索电影等。

功能需求 --- 百度上的概念

规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求有时也被称作行为需求（behavīoral requirement）。

功能需求是去解决业务需求、用户需求的具体的解决方案，也就是我们通常说的需求说明书。对用户需求做具体的分析、提出实施方法（需求说明书通常是由软件开发方编写比如产品经理，使得用户和软件开发方都对软件的初始规定有一个共同的理解，是整个开发的基础）。同时，开发方需要对需求说明书进行评估，比如这个需求能不能做，耗费的成本是不是小于带来的收益，还有风险评估等。

如果没有需求怎么办？直接给你一个软件直接测试怎么搞？我们可以参考市面上同类型的产品；

如果需求模糊怎么办？这个小编就经常遇到，产品经理提出来的需求往往只有几句话概括，这时候我们可以整理好已有的需求，把不明白的地方提出来，和相关的负责人确认，又或者参考同类型的产品实现的情况。也可以拿到产品后，进行探索性测试，去探索相关的功能需求，边测试边学习，验证看是否满足了业务，实在不明确的再进行确认，但这样会有风险，如果你和开发理解的一样，但恰巧你们都理解错了，那么可能做出来的东西就不是产品经理需要的东西了。

测试点是通过需求分析后对得出的需要测试的具体内容

将测试点总结完毕，就可以根据测试点快速的写测试用例，并可以很好的覆盖需求

评审就是对测试用例进行检查，包括同行评审、小组评审、部门评审、三方评审等

同行评审就是测试和测试之间的评审；

小组评审组织一个测试小组进行评审；

部门评审是整个部门进行评审；

三方评审是开发、测试、产品或者用户都会参与进行评审

评审不是一次性的，每次评审完进行测试用例的修改，再评审修改，直到测试用例通过。

原始方式是通过excel表格进行管理，虽然原始但是方便。只不过对于需求进行变更的项目来说，改起来比较痛苦

也可以采用一些项目管理工具，比如禅道，对测试用例及BUG系统进行统一管理，比较的方便