软件测试之测试设计阶段

测试设计阶段

当我们在做测试设计的时候，开发正在编写代码，研发软件，测试设计阶段我们主要做的事情都是写文档。我们会把后面要做的事情，都整理出来，写到文档里面去。
在实际的工作中，测试计划、测试策略、测试方案是可以直接写到一个文档里面去的，也就是说，这三个文档可以都写到测试计划说明书这个文档中。当然也可以拆开单独的写，具体是单独写，还是写到一起这个要看公司的要求和规定。

测试计划

所谓计划这个东西，大家应该都非常的熟悉。计划就是对某个事情，他的时间、地点、任务等相关内容安排。所以测试计划就是对软件测试这个活动，进行具体的安排。
测试计划全程称为测试计划说明书。这个文档一般来说是测试组长或者测试经理负责编写的。但是如果让你来负责编写也不是说不行，所以我们也是需要掌握测试计划的编写。

名词解释：里程碑是我们在项目中经常会遇到的一个词，所谓里程碑其实就是指的具体的项目节点，一个项目我们会拆分成很多不同的里程碑，随着时间的推进，我们就需要按顺序逐个达到里程碑要求完成的项目的内容。

 

测试方案

测试方案是我们对测试计划的一个补充。在测试方案里面，我们会详细的描述对于这个软件具体的测试的内容，比如功能、兼容性、易用性、安全、性能等等内容应该采用什么具体的测试方式进行。
不过核心的内容就是上述部分，但是如果你想要把文档写的专业，漂亮还是需要借助5W1H来进行编写补充、测试计划和测试方案他们里面内容有一些本身就是重复，所以你不要觉得在测试计划里面写过了，在方案中就不写了。
方案中还需要包括对测试过程的管理方案。也就是对具体的测试流程啊、发版流程等等进行规定。

测试策略

测试策略也是对测试计划的一个补充。
在测试策略中我们重点的内容是去约定我们哪些内容是需要测试的，哪些内容是不需要测试，哪些测试内容需要先做，哪些需要后做，对这些点进行约定，并且描述原因。
并且在测试策略中，我们需要完成对风险的分析，然后把分析的结论也写到文档中。

名词解释：我们在做任何一个事情之前，我们都可以先思考，会不会有什么事情或者情况会影响我们去做这个事情，然后就针对这个事情，去准备对应的解决方案，那么在实际执行的过程中，如果我们真的遇到影响我们执行的事情，那么我们就有现成的方案拿来使用，就不至于尬住了。在考虑风险的时候，是不需要考虑不可抗拒的风险的。
测试过程中场景的风险：

• 需求风险
  和需求有关的风险，比如需求变更，你都测试了一半，产品经理过来告诉你，之前做的都不算，全部重做。增加需求，本来之前这个功能的效果只有123个点，现在突然加了456个点。需求理解不正确、需求遗漏。
• 时间风险
  比如在估算工作所需要的时间的时候，估算的不准确，太短了。导致了工作无法按时完成。所以在估算工作时间的时候，要尽可能的多的估算一些，给自己流程缓冲的时间。
• 人员风险
  比如，同事离职了，请假了，导致了人手不够。对于这种情况，提前准备1个备用人员。前期参与到工作中，后期如果不缺人，那就不用他，缺人就用他顶上。
• 技术风险
  要求的测试工作，因为技术能力的原因无法完成。
  比如，公司安排你做性能测试，但是你不会。所以我们在安排工作之前，需要提前做好技术摸底，了解每个人的情况。

测试用例

测试用例的编写是属于每个测试人员都需要掌握的技能。非常的重要。
测试用例其实就是我们做软件测试的时候一个具体的指导书，我们怎么去做测试，需要输入数据、操作的步骤都会在测试用例里面写的清清楚楚，也就说，就算你不懂软件测试怎么做，只要你有测试用例，你就可以做软件测试。
测试用例不是谁编写谁就执行的，正常情况，应该是A编写用例，给B拿去执行。这样子的可以让每个的价值最大化，比如A对业务相当的精通，所以让A专门负责写用例，是对项目最好的方式，而执行，随便找个人就可以做了。
但是很多公司流程管理不规范，测试用例很可能是自己写了自己执行，也有可能根本就不要求写用例。
一般功能测试、接口测试都是要写测试用例的，其他的测试内容，比如兼容性、易用性之类的，直接在测试方案里面就写了，不会具体的测试的步骤。对于性能测试，会写专门的性能测试方案，所以也不需要写测试用例。

测试用例的内容

一般测试用例都是以一个表格的形式来体现出来的。不同的公司甚至不同的测试人员写的用例的内容可能都是不一样的。所以测试用例具体怎么去写是没有一个固定的答案，所以这里我们会列出测试用例相对比较核心重要的内容。其他的内容大家是可以根据实际的情况去做裁剪的。

• 用例的编号
  编码其实没什么可讲，随便怎么写都可以，重点是编号是唯一的，不能重负，每个编号都需要对应唯一的一条用例。比如：100，200，DL001，DL002
• 用例的名称
  名称就是我们给用例取的名字，但是我们要求名称需要言简意赅，一看到这个用例的名称，我们就可以准确的知道这个用例是干嘛用的。
• 前置条件
  我们在执行这个用例之前，我们的软件需要达成的一个条件。比如，现在我们需要测试修改课程信息的功能，那么前置条件就应该是列表中已存在课程数据。
• 优先级
  优先级是给测试人员自己看的，当我们在执行用例的时候，有的时候时间不是很充裕，那么我们就只能执行部分的用例，这种情况下，我们就会优先执行优先级高的用例。一般优先级的写法，高中低、ABCD、1234都是可以的。而优先级的制定，是一个很主观的过程，你觉得应该先测试，就可以把优先级调高。
• 重要级
  重要级说的这个测试用例所测试的功能的重要级、一般越核心的功能，对应的用例的重要级就会越高。
• 测试数据
  我们根据等价类、边界值给我们这个用例所设计的数据。测试数据可以存在很多组，也可以没有。测试数据的描述需要准确，1就是1，2就是2，尽量的避免使用描述性的语句。
• 测试步骤
  执行测试用例的具体的步骤，第一步干嘛，第二步干嘛。。。
  比如：新增课程这个功能。
  1、打开网站登录后台
  2、点击教务管理，进入课程列表界面
  3、点击新增按钮
  4、输入测试数据
  5、点击保存
• 预期结果
  预期结果一定要写的详细。千万千万不要只写一个成功、失败就完事。
  比如，新增课程这个用例，预期结果就是，新增课程成功，并且在列表中出现新增的课程，在报名的功能的课程下拉框中也出现对应的课程等等，也就是说，我们要把这个功能所影响到的所有的地方都描述到。
• 实际结果
  实际结果在编写用例的时候，是不填的，空着的。
  要等到，我们正式的执行用例的时候，再把实际结果填进去。

测试设计的方法

• 场景法
  又叫做用户场景法，我们站在用户的角度去想象，用户在操作某个功能的时候，有些什么操作情况，这些情况我们就叫做场景。所以场景法，就是我们把用户可以操作的全部场景全部给列出来。场景可以分为正向场景，也就是会导致这个功能操作成功的场景。逆向场景，也就是会导致这个功能无法操作成功的场景。注意：不是所有的功能都有逆向场景。
  使用场景法的前提是你已经对这个功能的需求了如指掌了。如果你对需求不熟悉、或者你不知道一些需求，那么你设计的场景肯定要么不正确，要么就会有遗漏。
  对于逆向场景的设计的时候，我们要使用控制变量法，一个逆向场景只允许有一个错误的点。这样才方便我们在后续的测试中去判断是不是这个错误导致的问题。
  比如：
  我们以新增一个用户为例进行介绍。
  新增用户的需求：

1. 名称要求必填，并且不能大于25个字符，不允许输入除大小写、数字、_以外的内容。
2. 介绍要求必填，并且不能大于300个字，内容没有限制。
3. 类型要求必填，并且以下拉框的形式出来。
4. 图片要求必填，并且只允许上传小于2M的jpg和png格式的图片。

正向场景：
- 输入正确的信息新增成功。
- 点击取消关闭新增的弹窗成功。
- 点击X关闭新增的弹窗成功。
逆向场景：
- 输入错误的名称新增失败
1.名称为空，
2.名称太短、
3.名称太长，
4.名称含有非法字符
- 输入错误的介绍新增失败
1.介绍为空
2.介绍的内容太长
3.介绍的内容太短
- 输入错误的类型新增失败
1.类型为空
- 输入错误的封面新增失败
1.图片为空
2.图片太大
3.图片不是jpg\png

以签到功能进行介绍
正向场景：
1.上课前签到，签到成功，显示正常。
2. 上课后签到，签到成功，显示迟到。
逆向场景：
1.课程结束后签到，无法签到。
2. 已签到的情况下签到，无法签到。
3. 在没有课程的情况下签到，无法签到。

• 边界值
  边界值的作用是用来帮助我们快速的找出合适的等价类数据。
  以新增课程的时候输入的课程名称这个数据为例。
  需求上要求了他的输入范围是1-25个字符。
  所以，左边界就是输入1个字符，右边界就是输入25个字符。我们利用边界值就可以去设计出合适的等价类的数据。
  一般正向等价类就是左边界和左边界+1，右边界和右边界-1，以及一个典型的中间值。
  一般无效等价类就是左边界-1，右边界+1.
  所以通过边界值的设计。
  • 有效等价类
    1、2、25、24、13
  • 无效等价类
    0，26
• 等价类
  等价类其实就是表示的是具有代表性的数据。找出一些具有代表性的数据，去覆盖所有情况的数据的输入情况。其中等价类又分为了有效等价类，无效等价类两种。
  • 有效等价类
    能够代表符合要求的数据。
  • 无效等价类
    能够代表不符合要求的数据。
• 因果图
• 判定表
• 路径覆盖法
• 错误推断法 。
  。。

测试常识

• 软件测试是无穷无尽的。因为测试数据的情况无穷无尽的。

评审

评审是我们在工作中非常常见的一个活动。
产品、开发、测试、项目中的任何一个角色都是可以组织对自己的工作内容进行评审的。
所谓评审就是让其他人来检查你的工作有没有问题。
比如我们常见的评审活动，就有 需求评审、用例评审、代码走查等等。
评审根据规模的不同，又可以分为同行评审、小组评审、部门评审、项目评审、第三方评审等等。
评审活动根据采用的形式不同，又可以分为邮件评审、钉钉评审等等。

5W1H/六合分析法

我们经常会写文档时候使用到六合分析法这个东西。
六合分析法一般我们就叫做5W1H，不管是在我们测试的工作中还是其他的工作中，都是可以用上的一个技能。
六合分析法既是一种创造技法、也是一种分析方法。
在这里我们主要使用的是他的创造技法的这方面。我们可以利用六合分析法的方法去编写我们的文档。
如果我们要用六合分析法使用到编写测试计划上面。

• What
  what在这里指的就是我们要做什么事情，也就是对我们的测试活动，对我们测试的软件等信息进行介绍，让别人能够知道我们是要做什么事情。
• Who
  who指的参与的人员，哪些人会参与到这个项目中，每个人负责的工作又是什么，具体的责任人又是谁。
• when when
  指的时间的安排，我们的项目在什么时间节点，需要完成什么事情。
  when就是对里程碑进行规定。
• where
  where正常情况指的是地点，但是在我们测试计划中，指的就不是地点了。在这里，哪里指的是我们的测试环境。所以我们就需要在where这个点里面，描述清楚测试环境的组成，和搭建的过程和步骤。
• Why
  why指的是原因，为什么我们要做测试啊，为什么要对某块功能进行测试，为什么要对某个内容进行测试，为什么要这么进行测试？
• how how如何进行这个活动，那所谓how
  就是约定测试具体如何进行。

流程图

我们测试人员画业务流程图，重点是要突出这个他的流程，所以流程图画的标准或者不标准是不重要，当然你画的更好看，肯定是更好的。

• 圆形
  表示是开始和结束
• 矩形
  过程和步骤
• 菱形
  判断和分支