软件测试测试用例范文如何设计一个完整的测试用例

高分求软件测试的测试计划与测试用例,(详情如下)

Boffice软件系统测试计划 Windows计算器的测试计划 修订历史记录 版本 日期 添加/修改/删除 修订者 说明 2009-5-5 张XX 目录 1.简介 1. 1目的 Windows计算器的测试计划文档有助于实现以下目标： 1.确定现有项目的信息和应测试的软件构件 2.列出推荐的测试需求 3．推荐可采用的测试策略，并对这些策略加以说明 4.确定所需的资源，并对测试的工作量进行估计 5.对整个测试工作的工作量进行估计 6.对测试活动的进程进行有计划的实施 7.列出测试项目的可交付元素 1. 2背景 项目名称：计算器 任务提出者： 开发者： 用 户：个人 项目背景：windows自带软件???????? 1. 3范围 测试的各个阶段： 测试设计：根据软件行业标准,制定测试计划、测试方案，包括收集测试方法、测试用例及可能的测试工具等。

系统测试：主要针对功能、界面、安装、版本验证进行测试，对经常使用的模块进行重点测试。

2.测试参考文档和测试提交文档 2.1. 测试参考文档 无 2.2. 将要用到文档 测试时间表、人员安排、测试总体计划、测试方案、测试分析报告、测试用例模版、测试报告单模版、测试用例通过情况统计表、各个模块的测试用例。

2.3. 测试提交文档 测试报告、测试记录、测试总结、工作日志。

2.4. 测试项目里程碑 里程碑任务 工作量 开始日期 结束日期 制订测试计划 X人/1.0天 设计测试用例 X人/0.5天 系统测试 X人/0.5天 测试总结 X人/0.5天 2.5. 各测试阶段资源要求及时间安排 人员 设备 时间安排 测试计划 5台计算机 测试设计 5台计算机 系统测试 5台计算机 测试总结 5台计算机 2.6. 问题优先级描述 严重程度： Blocker 阻碍开发和/或测试工作 Critical 死机，数据丢失，内存溢出 Major 较大的功能缺陷 Normal 普通的功能缺陷 Minor 较轻的功能缺陷 Trivial 产品外观的问题或不影响使用的小毛病 Enhancement 建议或意见 优先级： 描述 响应时间 P1 用户使用频率高 督促开发发现问题后立即修改 P2 Minor轻微的缺陷 督促1-2个工作日修改 P3 Normal用户经常使用的功能 发布之前 P4 Trivial用户很少使用的功能 可以在发布后修改的问题 2.7. 备注 3.术语和定义 4.测试策略 4. 1．功能测试 测试目标： 系统提供的功能正常实现 方法： 测试开始阶段主要针对的功能实现进行测试。

重要的功能应投入更多的精力进行测试，并及时小结 开始标准： 各个模块集成一起，即可开始 需考虑的特殊事项： 注意其中一些重要功能与实际效果相关，并不是简单的功能实现 4.2．界面测试： 测试目标 程序界面符合相关的规范 方法 按照规定逐项检查，包括菜单项，按钮，提示信息检查提示信息中的文字和标点符号，图标等 完成标准 程序界面与相关规定的要求统一 需考虑的特殊事项 注意启动画面和安装程序的版权信息注意版本信息 4.4.兼容性测试（资源不足，无法测试） 测试目标： 测试软件在当前微软系列操作系统中的运行情况，以及和同类文字处理软件的兼容性问题 方法： 1，在Microsoft Windows 98, ME, NT(Service Pack 6 之上), 2000 及 XP中安装软件并能够正常运行， 2，测试软件与同类软件word97, word2000, word2003，WPS之间的兼容性问题。

3，与其它相关软件web浏览器，绘图程序等进行兼容性测试。

完成标准： 能够在微软系列操作系统中正常安装并且运行，可以识别和处理其它厂商同类软件生成的文件，同时产生的文件可以被其它厂商同类软件所正确识别和处理，对于其它相关软件如web浏览器，绘图软件等可以兼容运行。

需考虑的特殊事项： 无

软件测试用例的设计

我做软件测试4年了，我说几点，供参考 1.测试用例的作用就是方便回归测试以及不同人员的交叉测试，由于每个人的角度不同，所以在设计测试用例的时候，如果时间充足，需要尽可能多的让更多的人看到并修改这份测试用例，使用例的覆盖度达到最高，否则，用例是没有意义的 2.用例需要及时维护和更新，根据需求和实际产品经常要更新用例。

3.编写的时候无非是 六个值原则 “正常值 异常值 “0”值 空值 默认值 边界值” ，把握好这六个值来设计用例。

楼主说到的 功能间的内聚比较高的情况，在设计测试用例时，关联到其他功能的数据可以在操作过程中直接给出取值范围 比如 装备模块 盔甲需要40-60等级的战士才能穿 设计用例的时候直接写出范围就可以

关于软件测试的测试用例应该学习哪些内容？

首先记好测试用例的八大编写必备要素：模块、版本、时间、编号、流程、输入数据、预期结果、实际输出 编写测试用例时能够运用到的方法有 黑盒：等价类划分法、场景分析法、边界值法、错误推测法、因果图法。

白盒：逻辑法、条件判断法、语句覆盖法

2016软件测试笔试题中怎么写测试用例

我以前做过公司的软件测试面试，理解不深，希望对你有帮助吧。

常见的有这么几种面试问题类型： 1、理论基础，也就是问你一些测试理论和测试方法的基本概念，如黑白盒测试都是怎么回事，测试用例的设计方法都有哪些，软件测试中遵循的一些原则等等 2、测试经验，是否有进行软件测试的经验，从事过哪些类型的测试，是否进行过自动化测试，自动化测试中用到的工具和平台是什么，是否有测试脚本编写的能力，写过什么测试脚本，用的脚本语言是什么 3、逻辑严密，一般会举例让你进行测试用例设计，例如圆珠笔、纸杯，或者一些你肯定用过的软件比如、微信的某一个功能，这部分要注意思路要清晰，要测试哪几个方面，每个方面按照什么分类规则去设计你的用例，争取做到条理清晰且覆盖度高 面试的时候不要紧张，就像和朋友聊天一样反而更容易获得好感，祝你成功啦~~

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

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

软件测试的W模型，就要求测试与开发同步，在开发设计需求设计说明书的时候就开始测试流程，一般情况下，讨论需求设计的时候需要测试主管或者组员的参与，了解这个项目设计的总体情况。

事实上，测试用例的编写一般是在需求设计说明书定下来之后才真正的开始的。

因为测试用例的内容要以需求设计说明书为依据，设计说明书上没体现的功能，不需要在测试用例中体现。

编写测试用例（这里指功能测试用例的编写），首先要做的就是设计测试用例的模板。

每个公司都有适合自己公司用例编写的模板，各有各的特点。

测试用例的格式包括，测试用例摘要、测试用例需求编号（一个需求设计说明书可以分好几个用例编写）、编写用例的日期、编写人员、编写日期、前置条件、准备数据等等。

格式没有固定的要求，可以根据自己测试用例设计的思路，对测试用例的格式作相应的改变。

下面以一个登陆窗口为例，说说我设计登陆界面的思路和方法。

我把这个测试用例分为三层结构，表单测试、逻辑判断、业务流程。

第一层，表单测试为最底层（最基础的）。

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

软件测试的W模型，就要求测试与开发同步，在开发设计需求设计说明书的时候就开始测试流程，一般情况下，讨论需求设计的时候需要测试主管或者组员的参与，了解这个项目设计的总体情况。

事实上，测试用例的编写一般是在需求设计说明书定下来之后才真正的开始的。

因为测试用例的内容要以需求设计说明书为依据，设计说明书上没体现的功能，不需要在测试用例中体现。

编写测试用例（这里指功能测试用例的编写），首先要做的就是设计测试用例的模板。

每个公司都有适合自己公司用例编写的模板，各有各的特点。

测试用例的格式包括，测试用例摘要、测试用例需求编号（一个需求设计说明书可以分好几个用例编写）、编写用例的日期、编写人员、编写日期、前置条件、准备数据等等。

格式没有固定的要求，可以根据自己测试用例设计的思路，对测试用例的格式作相应的改变。

下面以一个登陆窗口为例，说说我设计登陆界面的思路和方法。

我把这个测试用例分为三层结构，表单测试、逻辑判断、业务流程。

第一层，表单测试为最底层（最基础的）。

这部分的测试用例是对登陆窗口这个界面的输入框、按钮功能、界面等最基本功能的测试。

一般来说登陆用户名和登陆用户密码是输入框的形式体现，那么，我们需要的是针对这两个输入框进行功能的测试。

这时，我们只要考虑这个输入框的功能，而不需要考虑业务方面的内容。

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

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

第二层，逻辑判断层。

根据需求的设计，各功能之间的简单逻辑联系。

以登陆窗口为例，账号登录，账号和密码必须对应才能登录，否则登录失败。

根据这一点，我们就可以从这个要求设计这一层测试用例。

例如，账号和密码不一致时；账号为空时；密码为空时；账号密码对应时等等情况。

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

第三层，业务流程层。

这部分不关心软件的本身的基本功能，而是关心这个软件的业务有没有实现，不同的需求就有不同的业务需求。

以登陆窗口为例，就可能有不同的需求，可能用户要求停用的账号能够登录系统（可能要求登录后不允许进行其他操作），也可能用户直接要求停用的用户账号不准登录系统。

根据不同的业务需求，就有不同的业务流程。

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

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

这三层的组合起来才是一个完整的测试用例。

这是我个人对测试用例设计的一个思路和方法。

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

分层测试用例的思路主要来自对自动测试实现的考虑。

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

以上三层的划分也并不是很全面，需要在实践中不断完善，例如可以增加对数据库的部分功能的数据校验的分析。

总之，测试用例写的细致、全面、步骤清晰，那么无论是用手工测试的方法还是用自动化测试的方法实现，只要能完整的跑完整个测试用例，就达到了测试的目标了。