这一章，我用一个实际的项目（一个直播APP）做为例子，来讲述如何做测试，如何写测试计划，如何设计测试用例。
1 背景介绍
上海地区某某创业公司，想做一款直播APP软件，假设这个APP的名字叫做佳佳直播APP，（如有雷同纯属巧合）， 直播APP是目前很火的手机娱乐应用，这种手机平台有很多的才艺美女，萌妹，综艺大咖，奇葩怪才，草根偶像。优秀主播放送精彩娱乐节目，和网友面对面即时互动。美女主播们给大家分享才艺。
小叶是一位本科毕业，有三年测试经验的工程师，刚加入了这个创业公司的项目组，她负责整个APP的测试。
2 团队介绍
小叶很快了解到整个团队只有8个人。 整个团队在最早的时候没有测试人员。小叶现在是整个团队唯一的测试人员。她感觉到责任重大，她需要负责整个APP的测试，包括前端，后台和接口，性能都需要测试。如果APP出现任何问题，都是她的责任。
整个团队的架构如下图所示。
整个APP的开发进度已经过半了， 已经有很多功能开发完成，可以移交给测试人员开始测试了。
3 如何做测试
小叶的测试经验很丰富，对要测试什么，按照什么顺序测试，覆盖哪些需求，哪些要重点测，哪些可以不测。都心中有数。 小叶的测试思路如下
1. 首先是需求分析。对照目前可以运行的APP，反复看需求说明书
2. 把自己当成用户，深入了解APP的使用场景
3. 制定一个简单的计划
4. 设计主流程的测试用例，测试主流程
5. 最后对功能模块进行详细的测试
6. 不断完善测试用例
3.1 需求分析
首先要对项目的需求有清晰的了解，测试人员需要吃透需求，甚至要比开发人员更了解需求。其实软件测试中最复杂的是需求分析了。 有些业务比如ERP，云计算的业务，可能要几年的时间才能学会。
小叶以前做过银行的项目，银行的业务非常复杂，各种复杂的业务流程，支付流程。小叶花了一两年才熟悉了银行的业务。而APP的业务都非常简单，APP都是给个人用的，基本上2个工作日，就能对业务有个大概的了解。
小叶从项目经理那边拿到需求规格说明书，开始对项目的需求进行分析。通过需求说明书， 可以了解APP的功能。
这款直播APP的功能大概是这样的。 首先APP支持Andriod和IOS两个平台， 所以这个需要做兼容性测试。 APP的用户分2种角色。 男生注册登录后， 充值可以获取到鲜花币， 1RMB=10个鲜花币。 女生用户一般都是主播。 主播可以开直播，分享才艺，吸引人来观看。男生用户，可以用鲜花币购买礼物赠送给主播。 主播得到礼物之后， 可以换成鲜花币，然后提现到银行卡中。直播APP平台再抽成来盈利。
这个APP的需求还是非常简单明了的。 为了更加深刻的了解需求，小叶反复的看规格说明书，对于规格说明书不懂的地方，小叶还会去找产品经理确认。
3.2 把自己当成用户
把自己当成用户，是了解需求最快的途径。而且对设计测试用例也很有帮助，可以了解用户的使用场景。
为了深入了解APP的使用场景，小叶还下载了一些同类的直播APP，玩了几天后。小叶对直播APP的需求有了非常清晰的了解。
3.3 测试计划
领导要小叶给一个大概的测试计划， 用来了解小叶的工作进度。 小叶本身是不太愿意想写测试计划的，但是领导要，没办法只能写个简单的。
测试计划，主要是对整个项目的一个测试计划。 包括有多少资源，测试的范围，要做什么类型的测试。 的这样一个文档。
很多公司测试计划有很规范的模板。 但是对于小团队来说，测试计划比较简单，
下面是小叶的测试计划，小叶的测试计划其实就是小叶的测试思路
第一周：熟悉需求文档，对已经开发好的模块，设计主流程的测试用例，进行功能测试。
第二周：对模块，比如登录注册，个人中心，直播排行，模块进行非常详细的功能测试
第三周：APP的一些专项测试，比如，APP压力测试（看APP会不会闪退），安装卸载测试，升级测试，弱网测试
第四周：APP后台接口的自动化测试。
第五周：APP的兼容性测试
3.4 主流程的测试用例
先设计几个主流程的测试用例。 明确每一个功能的业务处理流程，不同的功能点作业务的组合
小叶在禅道中，设计了一个主流程的测试用例，网址：http://123.206.13.15 用户名: qa_tank, 密码: tanktest1234
打开禅道，点击测试-》用例-》建用例
可以看出测试用例由5部分组成：1. 简明的标题，2. 详细的步骤，3. 正确的预期结果，4. 前置条件（可能没有），5 优先级 （可能没有）
优先级一般分为5个级别， 分别用0-4来表示， 数字越小表示越重要， 当项目比较大的时候，没有时间测试的时候。 可能只执行优先级高的测试用例
4 什么是测试用例 Test Case
测试用例目前没有经典定义，通常来讲，测试用例是为特定目标而开发的一组测试输入，执行条件和预期结果, 其目的是确定被测试的程序的某个特性是否正常的工作。
设计测试用例（Test case）是软件测试人员最复杂, 最繁琐的工作了，也是测试人员最有技术含量的刚工作， 需要动脑子的工作。 设计好后还需要管理，以及更新。
设计测试用例的能力，是软件测试人员，最核心的能力。 一般来说，测试人员需要花费一半的时间，在测试用例的设计上， 小部分时间花在测试用例的执行上。
一个不会设计测试用例的人，就测不出Bug，产品就会出问题。所以面试的时候， 面试官会问很多关于测试用例的设计。
4.1 设计Test case的流程
1. 测试人员根据项目经理写的需求分析说明书和开发人员写的详细设计 来设计测试用例
2. 设计测试用例完成后， 测试人员要组织一个“测试用例评审”的会议， 邀请项目经理，开发人员和其他测试人员 来评审测试用例， 来检验测试用例是否覆盖全面。
3. 测试人员根据测试用例评审会的结果，修改测试用例. 直到测试评审会说测试用例通过了.
4. 测试人员根据测试用例,来执行测试。
当然，在实际工作中。 如果时间紧张，可能不会给你设计测试用例的时间， 很可能是，边测试，边设计测试用例。
4.2 设计测试用例的作用
检验软件是否满足客户的需求， 通过需求和测试用例的对照， 如果测试用例通过了， 那么需求就通过了
测试用例，体现了一个测试人员的工作量， 计算测试需要花费的时间。
展现测试用例的设计思路， 测试用例提现了测试方法， 阅读学习别人的测试用例，总结别人的方法和思路， 对自己编写测试用例的水平有很大的帮助
理清思路，避免漏测， 如果思路没理清楚， 而去随机测试， 容易漏东西
提高测试效率， 有思路后，直接执行就可以了
跟进测试效率， 领导问我们测试进度的时候，就知道我们测试了多少， 还剩多少
告诉领导做过， 项目上线后如果出现了问题， 后期追查的时候， 有根有据。
跟进重复性工作， 有了用例后， 不会重复测试。
4.3 测试用例评审
在正规流程中，设计完测试用例后， 测试人员，需要组织一个测试用例评审会议，邀请开发人员，产品经理，以及一些其他的测试人员参加。目的是查漏补缺。要大家帮忙检查下测试用例是否考虑全。 通常，开发人员对需求非常了解，会在会议上提出很多补充的测试用例。
小叶所在的团队实在是太忙了。 开发人员每天都加班开发功能，根本不会参加测试人员的评审会议。小叶只好把测试用例，用邮件的形式发给整个团队。
5 功能模块的测试
测试完大的流程，现在小叶要对每一个功能模块，进行详细的测试了。拿注册模块做为例子，注册模块的需求说明书如下。
注册模块，可以说是整个APP中最简单的的一个模块， 大概需要2个小时的时间测试完。需求非常简单。 需要根据这个需求，来设计测试用例。如果没测试用例，那就是乱点了。
没有测试会漏测，还会没法跟踪进度。 没办法保证测试的质量。
功能模块的测试，需要测试得很细。我们需要设计很多详细的测试用例。
6 设计测试用例的方法
小叶熟悉各种测试用例的设计方法，测试用例设计方法大概如下：
6.1 错误推导法
错误推导法，就是要把软件搞垮。比如我们都知道手机号码都是数字。 我不填数字，填字母会怎么样？
按照错误推导法的思想，小叶设计如下的测试用例
手机号码是：136719784566（不是11位）
手机号码为： abcdb （不是数字），
手机号码是：我是汉字！@#%（不是数字）
6.2 边界值
边界的地方是程序员最容易出问题的地方， 所以要特别测试。 举个例子。用户名最少是6位， 那么程序员的代码应该是这么写的。 username>=6。很可能程序员一疏忽写成 username>6 了。
也就是在边界的地方我们需要测试 加一，和减一， 最小最大。 也要测。
注册模块，要求登录密码，是6到12位。 按照边界值的思想，小叶设计这些测试用例。
5位密码（N-1），6位密码（N），7位密码（N+1）
11位密码（N-1），12位密码（N）， 13位密码（N+1），
密码为空格（最小），密码为空（最小）， 300位的密码（最大）
6.3 等价类
等价类其实是一种偷懒的办法。 差不多情况的测试用例， 我们只要条一个测试就行了。 这样可以节约测试的时间。
7 测试用例的管理
测试用例的管理非常头疼，有的公司用禅道这样的管理， 有的公司用Excel如下图， 有的公司用思维导图，下一章，详细介绍如何用思维导图设计测试用例
用Excel管理测试用例
8 测试用例的更新和完善
测试用例编写完成之后需要不断完善，如遇需求更改或功能新增时，测试用例必须配套修改更新，
经常会发现很多Bug都不在测试用例里面，说明我们设计测试用例的时候，考虑不周。需要补充测试用例。
同时在测试过程中发现设计测试用例时考虑不周，需要对测试用例进行修改完善;在软件交付使用后客户反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成，也需要对测试用例进行完
总结
测试用例最难的地方，如何把测试用例写得全面
测试用例常见的问题
其实写测试用例并不难， 但是它仍然容易出现一些问题，
1. 含糊不清或者与内容不相符的标题
2. 过于简单的步骤， （让别人来执行的时候，步骤根本执行不了，不通）
3. 没有写明预期结果
4. 多个用例混在一个用例中
执行Test Case中，每一步都要注意实际结果是否与预期结果是一致的。
前提:
编写测试用例之前我们需要对项目的需求有清晰的了解，对要测试什么，按照什么顺序测试，覆盖哪些需求做到心中有数，作为测试用例的编写者不仅了解要有常见的测试用例编写方法，同时需要了解被测软件的设计、功能规格说明、用户试用场景以及程序/模块的结构。
步骤：
1、测试需求分析
从项目部拿到软件的需求规格说明书后，开始对项目的需求进行分析，通过自己的分析、理解，整理成为测试需求， 清楚分析出被测试对象具有哪些功能。 明确测试用例中的测试集用例与需求的关系，即一个或多个测试用例集对应一个测试需求。
2、业务流程分析
分析完需求后，明确每一个功能的业务处理流程，不同的功能点作业务的组合，以及项目的隐式需求。如遇复杂的测试用例设计前，先画出软件的业务流程。
从业务流程上，应得到以下信息：
A、 主流程是什么?
B、 条件备选流程是什么?
C、 数据流向是什么?
D、 关键的判断条件是什么?
3、测试用例设计
完成以上两步则可进行测试用例设计，功能测试用例，应尽量考虑边界、异常、性能的情况，以便发现更多的隐藏问题。
设计测试用例的常见方法
1）等价类
2）边界值
3）因果图
4) 判定表
5) 状态迁移
6) 正交实验
7) 场景法
8) 错误推断
注意：编写测试用例时，我们尽可能取的不应该是有效等价类而应该是无效等价类
4.编写完成后自我检查以及部门内部评审
5.测试用例更新完善