不管在传统软件公司还是互联网公司，测试用例的设计和编写一直是测试人员一个非常重要的基本工作。很多从事互联网测试工作的朋友都会问道这么一个问题：“测试用例到底该如何去设计？为什么我设计出来的测试用例总有遗漏？”这里需要说明一点的就是设计出来的用例有遗漏是很正常的现象，我们写测试用例的目的就是让产品尽可能得接近没有缺陷，但是距离客户完美的期望还是有一定距离的，毕竟每个客户心中都有自己的评判标准。

然而在大多数互联网公司，基本都走敏捷，讲究小步快跑，快速试错，基本上产品迭代非常频繁，这给测试留下的执行测试的时间就极短，更别说写用例的时间，所以就只能简化测试用例。

言归正传还是认真的说一下测试用例相关的知识

一、什么是测试用例

测试用例就是一组由前提条件、输入、执行条件、预期结果等组成，以完成对某个特定需求或者目标测试的数据，体现测试方案、方法、技术和策略的文档。测试编写用例一般按照流程是在需求评审结束，项目立项后。

二、测试文档的结构

一般情况下，测试文档主要分两个部分。即：非功能性测试需求、功能性测试需求。所谓非功能性测试，主要指APP运行时在各种环境下是否能正常运行，而功能性测试是指每个具体功能是否按要求运行。

三、具体编写时应该思考的问题

在编写测试用例之前，你需要踩得坑还是很多的。因为你面对的时一个”活生生"的商业产品，既然是一个产品，作为测试你就需要考虑以下几点：第一， 产品有什么特点？第二， 产品所在的系统结构？第三， 产品本身的系统架构？第四， 用户最关心产品的功能是什么？但是，这几点通常按照需求文档写完所有测试点后，还是不能满足任务需求，因为一个产品的功能可能会在不同的场景下使用，那么这就需要测试会根据应用的场景设计若干条场景测试用例。场景测试用例的优点是可以将孤立的功能点串联起来，达到全链路的测试，完善测试用例覆盖率，提高测试效果。

作为测试人员一般要记住场景用例设计的原则：1一个业务场景只存在一个基本流。2、基本流只有一个起点和一个重点。3.基本流是主流，备选流是直流。4备选流可以起始于基本流，亦可以始于其他的备选流。

其实到最后用例写多了，你就会发现很多功能模块是类似的，例如查询功能，校验文明本框，时间控件校验等等，那么在编写用例的时候就可以提取成一个公共方法，供各个地方调用。同样编写测试用例时，你也可以提取类似的测试用例，形成一个公共用例库，供相同的功能模块引用。

最后，用例评审也是非常必须的，当你坐上一辆由经验老道或者业务熟悉的老司机主掌方向盘的车，你就会发现那简直是飞一般的感觉，他们可以在用例评审上快速的帮忙指出用例的遗漏点，有助于你迅速的打开思路。当人别光顾着坐车，遇到不懂的或者不确定的问题及时记录下来。结束后及时找相关人员确认，避免猜测。

感谢阅读，我是漫读，时刻专注设计界的那点事，专注干货分享！感谢阅读、点赞与评论，欢迎关注向我提问！@漫读时间

软件测试流程指的就是测试计划、测试设计、测试执行、测试总结这几个阶段。但如果面试中有人问你：你们公司的测试流程是什么时。你要回答：在项目启动后，从系统需求分析阶段，测试人员就介入项目着手测试需求分析，编写测试计划、设计测试方案和测试用例；然后搭建测试环境，准备测试数据；当系统通过集成测试后，测试团队首先进行版本验证测试，然后进行多轮迭代系统测试；一般经过三代迭代测试后，95%的用例通过测试，没有明显致命和严重的bug就结束系统测试；最后由测试负责人进行测试评估总结。

我们说的最多的是软件测试流程，很少有人提起测试规程。

软件测试流程指的就是测试计划、测试设计、测试执行、测试总结这几个阶段。但如果面试中有人问你：你们公司的测试流程是什么时。你要回答：在项目启动后，从系统需求分析阶段，测试人员就介入项目着手测试需求分析，编写测试计划、设计测试方案和测试用例；然后搭建测试环境，准备测试数据；当系统通过集成测试后，测试团队首先进行版本验证测试，然后进行多轮迭代系统测试；一般经过三代迭代测试后，95%的用例通过测试，没有明显致命和严重的bug就结束系统测试；最后由测试负责人进行测试评估总结。

测试规程指的是测试各个流程的相关规范。具体指出测试团队如何工作，如何与相关项目成员协调。

设计测试用例要考虑哪些？这个详细的不便多说，如果是面试时面试官问这问题，可以这样回答：

要考虑测试方法、测试类型。我们拿到一个项目首先要分模块，然后进行分层设计，把模块按页面用例、功能用例、业务逻辑用倒、数据流向用例进行编写，在每个测试点中把具体的测试方法和测试类型考虑进去进行设计。一般时间允许的情况下你可举个例子进行说明。