1.软件测试用例的模版

写好一个软件的测试用例的建议有：

1、测试用例名称，也叫测试用例标题，一定要写得简洁、明了，需要用概括的语言描述该用例的出发点和关注点，使得测试人员第一眼看到测试用例名称就能够明白测试用例的目的。用例名称中一般要求不能存在假设性的语句，并且原则上每个用例的名称不能重复。

2、预置条件要明确，包括测试环境、测试数据、测试场景。因为许多BUG只有在特定的环境、特定的场景下才可以重现。没有正确的前提条件，就无法进行后面的测试步骤或无法得到预期的结果。

3、测试步骤描述要简单、清晰，并且要清楚每一个步骤的描述，比如：第一步，输入用户姓名；第二步，输入登录密码；第三步，用户点击登录。步骤写的明确时就利于提高用例的可操作性。

4、用例的预期结果要完整而且清晰，并且要将各个输出的结果写出来，包括：返回值的内容、数据库相关字段的记录、界面的响应结果、输出结果的规则符合度、日志的检查和对其它业务影响的检查。

5、测试用例级别要划分清楚，这样在测试执行时有主次之分。

6、测试用例的划分也要单一，一个测试用例只检查功能点的一种情况。一个用例检查的情况太多，会导致用例的目的不明确。而且这样组织用例，有利于需求覆盖率的统计。一个功能点我们测试了哪些情况，以及哪些功能点我们在重点测试，一目了然。

2.软件测试,谁能给我一个测试项目的例子,大概的说明一下,呵呵

很简单，也很经典的微软 一次性水杯测试

功能度：用水杯装水看漏不漏；水能不能被喝到

安全性：杯子有没有毒或细菌，检查水杯被破坏后，是否会造成使用者伤害

可靠性：杯子从不同高度落下的损坏程度

可移植性：杯子再不同的地方、温度等环境下是否都可以正常使用

兼容性：杯子是否能够容纳果汁、白水、酒精、汽油等

易用性：杯子是否烫手、是否有防滑措施、是否方便饮用

错误测试：装载高密度固体

破坏测试：检查水杯最大抗挤压和拉扯承受力

用户文档：使用手册是否对杯子的用法、限制、使用条件等有详细描述

疲劳测试：将杯子盛上水（案例一）放24小时检查泄漏时间和情况；盛上汽油（案例二）放24小时检查泄漏时间和情况等

压力测试：用根针并在针上面不断加重量，看压强多大时会穿透

跌落测试： 杯子加包装（有填充物），在多高的情况摔下不破损

等等

3.软件测试用例的模版

写好一个软件的测试用例的建议有：1、测试用例名称，也叫测试用例标题，一定要写得简洁、明了，需要用概括的语言描述该用例的出发点和关注点，使得测试人员第一眼看到测试用例名称就能够明白测试用例的目的。

用例名称中一般要求不能存在假设性的语句，并且原则上每个用例的名称不能重复。2、预置条件要明确，包括测试环境、测试数据、测试场景。

因为许多BUG只有在特定的环境、特定的场景下才可以重现。没有正确的前提条件，就无法进行后面的测试步骤或无法得到预期的结果。

3、测试步骤描述要简单、清晰，并且要清楚每一个步骤的描述，比如：第一步，输入用户姓名；第二步，输入登录密码；第三步，用户点击登录。步骤写的明确时就利于提高用例的可操作性。

4、用例的预期结果要完整而且清晰，并且要将各个输出的结果写出来，包括：返回值的内容、数据库相关字段的记录、界面的响应结果、输出结果的规则符合度、日志的检查和对其它业务影响的检查。5、测试用例级别要划分清楚，这样在测试执行时有主次之分。

6、测试用例的划分也要单一，一个测试用例只检查功能点的一种情况。一个用例检查的情况太多，会导致用例的目的不明确。

而且这样组织用例，有利于需求覆盖率的统计。一个功能点我们测试了哪些情况，以及哪些功能点我们在重点测试，一目了然。

4.如何设计一个完整的测试用例

测试用例的设计一般从分析需求设计说明书开始，了解开发人员设计这个项目的思路、设计的要求、实现的功能等（最好有use case，这样看起来更清晰）。

软件测试的W模型，就要求测试与开发同步，在开发设计需求设计说明书的时候就开始测试流程，一般情况下，讨论需求设计的时候需要测试主管或者组员的参与，了解这个项目设计的总体情况。事实上，测试用例的编写一般是在需求设计说明书定下来之后才真正的开始的。

因为测试用例的内容要以需求设计说明书为依据，设计说明书上没体现的功能，不需要在测试用例中体现。编写测试用例（这里指功能测试用例的编写），首先要做的就是设计测试用例的模板。

每个公司都有适合自己公司用例编写的模板，各有各的特点。测试用例的格式包括，测试用例摘要、测试用例需求编号（一个需求设计说明书可以分好几个用例编写）、编写用例的日期、编写人员、编写日期、前置条件、准备数据等等。

格式没有固定的要求，可以根据自己测试用例设计的思路，对测试用例的格式作相应的改变。下面以一个登陆窗口为例，说说我设计登陆界面的思路和方法。

我把这个测试用例分为三层结构，表单测试、逻辑判断、业务流程。第一层，表单测试为最底层（最基础的）。

这部分的测试用例是对登陆窗口这个界面的输入框、按钮功能、界面等最基本功能的测试。一般来说登陆用户名和登陆用户密码是输入框的形式体现，那么，我们需要的是针对这两个输入框进行功能的测试。

这时，我们只要考虑这个输入框的功能，而不需要考虑业务方面的内容。这样，我们考虑就是这个输入框的长度限制是多少？能否输入特殊字符？能否输入全角字符？当然，登陆窗口还有其他按钮，例如登陆按钮、退出按钮、界面设计等，这一层的测试用例只对他们最简单的功能的测试。

我觉得这一层的测试用例对新开发项目很重要，也必须执行，因为这些是最基本的功能保证，当项目进入维护阶段后，如果没有修改就不需要执行这部分的测试了或者说把这层的用例优先级置为最低，时间不充足的情况就不用去执行。第二层，逻辑判断层。

根据需求的设计，各功能之间的简单逻辑联系。以登陆窗口为例，账号登录，账号和密码必须对应才能登录，否则登录失败。

根据这一点，我们就可以从这个要求设计这一层测试用例。例如，账号和密码不一致时；账号为空时；密码为空时；账号密码对应时等等情况。

输入这些情况时，程序是作怎么样的逻辑控制的？控制是否正确？是否有相应的提示信息？我觉得，这一层的用例时最常规的一层，平时使用这个软件用经常碰到的一些情况，在常规测试或修改这部分的功能之后，这一部分的测试用例也必须执行。第三层，业务流程层。

这部分不关心软件的本身的基本功能，而是关心这个软件的业务有没有实现，不同的需求就有不同的业务需求。以登陆窗口为例，就可能有不同的需求，可能用户要求停用的账号能够登录系统（可能要求登录后不允许进行其他操作），也可能用户直接要求停用的用户账号不准登录系统。

根据不同的业务需求，就有不同的业务流程。这样这层的测试用例，我们就只要考虑业务需求，仍然以登录窗口为例，我们就只要考虑删除的用户能否登录？停用的用户能否登录？超级用户是如何登录的？普通用户是何种方式登录的？简单的说，这层的用例只描述业务流程，不关心具体这个业务是怎么实现的，执行这部分用例时，不要考虑哪个输入框控制了多少长度，能否输入空格等其他功能，因为这部分的测试需要基于上面两层的测试用例都已经测试通过了，所以在项目维护阶段或者说时间很紧迫的阶段，我们只需要执行这部分的用例，保证业务能够通畅的完成。

其实个人觉得在执行这部分用例时，对包含了对基本功能的测试，一些明显的问题应该能被发现，虽然严格来说测试覆盖率很低，但是基本能达到要求。这三层的组合起来才是一个完整的测试用例。

这是我个人对测试用例设计的一个思路和方法。真正设计这个测试用例的时候，可能会使用到黑盒测试用例的方法，例如等价类划分、边界值分析、错误猜测法（主要是个人经验）、正交分解等方法针对具体情况设计测试用例。

分层测试用例的思路主要来自对自动测试实现的考虑。因为我觉得，如果需要实现自动化测试就必须对测试用例进行细分，划分得越细就越有利于自动化的实现。

以上三层的划分也并不是很全面，需要在实践中不断完善，例如可以增加对数据库的部分功能的数据校验的分析。总之，测试用例写的细致、全面、步骤清晰，那么无论是用手工测试的方法还是用自动化测试的方法实现，只要能完整的跑完整个测试用例，就达到了测试的目标了。

5.如何编写出漂亮的测试用例

测试用例是测试设计的一个产出物，它直接体现测试设计的思想，一份漂亮的测试用例不仅仅是设计思路的优，更是便于流转和执行，具有可读性、传递性。

首先，一份漂亮的测试用例-需有一个用例模板 模板的作用：将测试用例的结构形式固定化、标准化，对编写者启引导作用，保证一份测试用例数据完整。 两份模板差别在于 机顶盒1和机顶盒2，因在IPTV行业，是通过机顶盒展示给用户的，而当前机顶盒厂商多，需要进行兼容性测试，将需要测试的机顶盒直接标记在用例中，执行哪款盒子，就直接在哪款盒子上写结果即可。

同一个功能在多个机顶盒上是否OK 一目了然。 哪款盒子测试用例通过率/失败率也非常清晰。

如你测试的是网站可将机顶盒改成 IE11 Chrome 等。 其次，测试用例具有目标、可读、简洁。

测试用例的目标、可读、简洁是从各个属性所填的内容散发出来的。 1、用例编号 用例编号就是测试用例文档中一个代号，需全局唯一，我们可以通过代号快速找到测试用例。

用例编号的书写，建议是项目名_模块名_001，我们可以通过编号快速知道一个项目有多少用例，项目中一个模块有多少用例。 2、用例标题 目的：概述测试用例的主要内容，明确用例意图 在做用例评审时，通过浏览一个模块的用例标题，能快速判断有没有遗漏功能；通过浏览一个功能用例标题，能快速判断出有没有遗漏正常或异常case。

一个测试用例的好坏，一半体现在测试用例标题上。 一个好用例的标题，书写方式有三种： 一：一句完整的话（不超过30个汉字） 二：功能简报形式 例：电影详情页-返回 例：栏目-发布 例：电影-添加 三：按条件/状态 例：发起转码-无源媒体文件 例：发起转码-有源媒体文件 例：鉴权-已订购产品已过期 例：鉴权-已订购产品未过期 例：鉴权-未订购产品 3、预置条件 预置条件-测试用例能执行的前提条件。

可以是到达某一状态，也可以是一些配置。 书写要求：一个简洁的结果。

用户已成功登陆 自动审核的开关已关 不需要写是怎么登陆的/如何将开关关掉的。