软件测试之测试用例、测试点写法以及需求分析【百科全说】

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

一.如何写测试用例

01

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

测试的生命周期：测试计划 --- 测试方案设计 --- 测试开发 --- 测试执行 --- 测试评估，对测试结果的分析和报告。测试用例的编写与执行属于测试开发环节。
03

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

测试用例的作用：检验软件是否满足客户的需求；体现一个测试人员的工作量；展现测试的设计思路，可以通过阅读别人的测试用例学习测试用例的设计方法和思路。
05

测试用例一般包含：编号、用例名称、测试背景、前置条件、优先级、重要级、测试数据、测试步骤、预期结果、实际结果、备注。但可以根据实际需要增加、删除、修改部分项，比如：增加分类、子分类等。
06

这里需要注意，编号并不简单的是1、2、3、4这样子，而是可以通过下划线将一些测试用例的信息包含进去，比如：TV_YUYIN_0001，代表着这条测试用例时测试电视语音相关的；用例名称是用例的名字，这个可以不写；测试背景是说明该测试用例的背景，是测试什么项目、什么内容的，也可以不写，有时候测试背景通过测试编号、测试文件的名字、标题等就可以表达出来；前置条件是测试之前应该满足什么条件才可以进行测试，一般要写，如果没有前置条件写无就可以；优先级和重要级看似差不多，其实关系不大，优先级高并不意味着重要级高；测试数据是指输入的数据；测试步骤是必须的，可以根据实际情况写测试步骤，可以写的粗糙，也可以写的很详细，比如第一步是什么，第二步是什么等；预期结果对应着测试步骤，如果测试步骤写的很详细，那么预期结果也要详细，比如测试步骤有5步，预期结果有2个，别人怎么知道这个结果是哪一步产生的？最好在编号上实现预期结果和操作步骤的统一；实际结果就是在测试过程中的实际情况，如果一样就写通过、OK等就可以了，如果不一样，需要写明实际结果是什么。有时候，我们可以在实际结果中写OK、false，然后将实际结果写在备注里，也没有问题。
07

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

二.需求分析

01

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

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

业务需求 --- 首先看一下搜狗百科上的概念表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。使用前景和范围（vision and scope）文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求（project charter 或 market requirement）文档。行业都有自己的领域系统（行业所处的大环境，包括行业习惯、背景等），而根据行业的领域系统及领导、客户等的方向及目标。
04

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

功能需求 --- 搜狗百科上的概念规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求有时也被称作行为需求（behavīoral requirement）。功能需求是去解决业务需求、用户需求的具体的解决方案，也就是我们通常说的需求说明书。对用户需求做具体的分析、提出实施方法（需求说明书通常是由软件开发方编写比如产品经理，使得用户和软件开发方都对软件的初始规定有一个共同的理解，是整个开发的基础）。同时，开发方需要对需求说明书进行评估，比如这个需求能不能做，耗费的成本是不是小于带来的收益，还有风险评估等。
06

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

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