编写好的黑盒测试用例实例

znj8888

我刚进入手机测试领域，现主要从事电话，通话记录，STK，以及WAP浏览器方面的用例设计，如有这方面资料请发到我邮箱znj8888@163.com,或告诉我有哪些参考书上可以找到关于这方面资料！谢谢！急用！急急急！

jennie98

greenhourse所说：（4）我们单位设计测试用例的编号是一个基本的功能项是×，当它的子项时用×.×（×代表数字）如1
1．1．        并且容错输入单独标识出来。这样是不是会清晰些呢？并且我们给用户的测试用例只有正确的输入，这样也便于给用户时的测试用例的整理。

请问：测试用例要提供给客户吗？

另请教各位：如“UI界面大小是否与界面设计一致”等，是否都必须写进测试用例？
在测试时想着测试这些方面，可以吗？一定要写下来吗？

snake

每个单位的测试用例的编号是为了方便自己的使用，不用统一，自己觉得好用够用就可以了。
我们所说的测试用例是不尽相同的，我们公司做alpha测试的测试用例是不给用户的，用户做BETA测试的测试用例不是我们提供的。
UI测试的用例还是最好写的，因为界面数目繁多的大型软件是需要测试用例规范的，这样方便测试的进行。

ysyysy

我也是一名新手,刚刚上班。我想知道一份完整的测试用例大概包括哪几个部分啊?还有,测试用例书写时有什么要注意的吗?

lyh668

白箱测试 参见 结构测试
保真度 对于测试系统来说，它是指硬件、软件和网络环境模仿终端用户及其活动的准确程度。
报告工具 可以在给定某些有关日志产生的信息的情况下，将报告日志加工成报表和图表的特定测试工具。
报告日志 由低级测试工具产生的原始测试结果，它是在不同程度上“人类可读的”文档。例如，它可能是包含测试条件pass/fail结果、屏幕快照，以及诊断结果等内容的文本文件。
被测试的系统 被测试的产品或系统的总称，通常由多个明显的部分组成，简写为“SUT”。错误地理解被测试的系统范围可能会造成测试逃逸。
测试范围 1。测试系统覆盖被测试的系统结构（代码或组件）的程度。其度量方法通常用被涉及的结构元素（如代码行或功能点）占元素总数的百分比来表示。2。测试系统覆盖被测试的系统结构（操作、活动、功能及其他用途）的程度。这种程度（在质量方面）是通过顾客在整体基础上可能利用的用途来度量的。对于这两种情况，彻底的测试对于好的测试都是十分必要的。
测试方案 以串行方式、并行方式或其他一些组合顺序执行的一系列步骤、子步骤及其他操作，它将创建用来评估测试方案的理想的测试条件。
测试方案库 一组相互独立、可重复使用的测试方案。
测试工具 在执行测试方案以建立或破坏测试环境、创建测试条件、衡量测试结果过程中使用的具有普通意义的硬件、软件或硬件/软件系统。测试工具与测试方案本身是分离的。
测试阶段 确定特定质量风险级别的与众不同的测试子项目。测试阶段通常会重叠。
测试平台 运行测试的硬件。测试平台对于被测试的系统并不是必要的，尤其是在测试软件时。
测试人员错误 由测试人员在使用测试系统时造成的错误；人为的错误。测试人员错误可能导致类型I或类型II错误，也可能只是一些令人气愤的错误。
测试失败 测试系统的失败。测试失败可能会导致类型I或类型II错误，也可能只是产生一些令人不快的负面影响，而不会对测试结果的正确性有任何影响。
测试收益 测试方案或测试套件发现错误的能力。例如，收益较高的测试套件可能会导致大量严重的错误报告，而收益较低的测试套件可能会导致较少的微不足道的错误报告。
测试逃逸  在测试过程中被适当捕获但实际并不是错误的现场报告的错误。该术语也可以指进入下一个测试阶段的错误，虽然它应该在前面的阶段被发现。在测试阶段被发现、但因为项目管理决定而没有得到解决的现场报告的错误不是测试逃逸。只是通过与众不同的复杂硬件配置或模糊操作发现的错误也不被认为是测试逃逸。
测试套件 执行一组测试方案的框架；组织测试方案的方式。在测试套中，可以组合测试方案以创建独特的测试条件。
测试条件 由执行测试方案中的一些步骤、子步骤或操作的组合而创建的系统状态或环境。该术语有时也被用来指步骤、子辰骤或操作本身。
测试系统 一种集成的、可维护的测试环境和报告系统，其主要目的是查找、再现、隔离、描述及管理被测试的软件或硬件中的错误。
测试循环 对于该阶段的组成部分的一个指定的测试阶段，计划部分或全部执行的所有测试套件。一个测试阶段至少属于通过所有指定测试套件的一个（通常是多个）循环。测试循环通常与被测试的系统（如软件或主板）版本有关。通常，在测试阶段过程中将出现新的版本，并触发另一个测试循环。
产品测试 参见 集成测试
串测试 软件开发过程中的一个测试阶段，查找典型用法脚本和可操作或控制流“串”中的

elevenchen

看到朋友很久以前写的一个test case, 感觉不是很完美.
1. 设计表格最好用Excel, 便于查看与修改.
2. 测试表格中测试条款好像不是很全.For example: 测试ID最好写的详细点, 可以用AA_BB_001的形式表示, 其中AA, BB表示所要测试的项目.
3. 应该在测试表格中加入Name一项, 这样测试的时候会很方便查看.
4. 有必要的话需要加入测试等级:priority.
5. And so on

luckhj

也来学习学习

zj_yu

下下来看看

remela

UI设计应该是开发部提供的，不应该是测试人员提供的吧？我们公司这一块就是由开发部门来提供的！

pride

其实测试用力的便携式因人而异的，也是多变的，不同的公司要求不一样，而且不同的测试员编得用例也是有区别的。就算是同一个测试员在不同的时间编得用例也是不一样的。所以说现在就有了那么多的软件维护。我们现在做的职能是尽善尽美。因为不可能有绝对完全的测试！尽善尽美啊！

csm1014

常用的功能测试方法
    功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检
查产品是否达到用户要求的功能。常用的测试方法如下：
1.        页面链接检查：每一个链接是否都有对应的页面，并且页面之间切换正确。
2.        相关性检查：删除/增加一项会不会对其他项产生影响，如果产生影响，这
些影响是否都正确。
3.        检查按钮的功能是否正确：如update, cancel, delete, save等功能是否正确。
4.        字符串长度检查: 输入超出需求所说明的字符串长度的内容, 看系统是否
检查字符串长度,会不会出错.
5.        字符类型检查: 在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型),看系统是否检查字符类型,会否报错.
6.        标点符号检查: 输入内容包括各种标点符号,特别是空格,各种引号,回车键.看系统处理是否正确.
7.        中文字符处理: 在可以输入中文的系统输入中文,看会否出现乱码或出错.
8.        检查带出信息的完整性: 在查看信息和update信息时,查看所填写的信息是不是全部带出.,带出信息和添加的是否一致
9.        信息重复: 在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理.
10.        检查删除功能:在一些可以一次删除多个信息的地方,不选择任何信息,按”delete”,看系统如何处理,会否出错;然后选择一个和多个信息,进行删除,看是否正确处理.
11.        检查添加和修改是否一致: 检查添加和修改信息的要求是否一致,例如添加要求必填的项,修改也应该必填;添加规定为整型的项,修改也必须为整型.
12.        检查修改重名:修改时把不能重名的项改为已存在的内容,看会否处理,报错.同时,也要注意,会不会报和自己重名的错.
13.        重复提交表单：一条已经成功提交的纪录，back后再提交，看看系统是否做了处理。
14.        检查多次使用back键的情况: 在有back的地方,back,回到原来页面,再back,重复多次,看会否出错.
15.        search检查: 在有search功能的地方输入系统存在和不存在的内容,看search结果是否正确.如果可以输入多个search条件,可以同时添加合理和不合理的条件,看系统处理是否正确.
16.        输入信息位置: 注意在光标停留的地方输入信息时,光标和所输入的信息会否跳到别的地方.
17.        上传下载文件检查：上传下载文件的功能是否实现，上传文件是否能打开。对上传文件的格式有何规定，系统是否有解释信息，并检查系统是否能够做到。
18.        必填项检查：应该填写的项没有填写时系统是否都做了处理，对必填项是否有提示信息，如在必填项前加*
19.        快捷键检查：是否支持常用快捷键，如Ctrl+C Ctrl+V Backspace等，对一些不允许输入信息的字段，如选人，选日期对快捷方式是否也做了限制。
20.        回车键检查: 在输入结束后直接按回车键,看系统处理如何,会否报错.

junfei521

学习ing

冰河

学习了不少!!


嘻嘻~~~继续努力~~~~~~~~~~

[ 本帖最后由 冰河 于 2005-11-16 12:29 编辑 ]

青橘子

　　受益多多啊，这样的帖子我们才学的多啊！多谢了！

jtiger

UI测试还应该增加在不同分辨率下的一致性，如果设计不好，会导致在低分辨率下对话框、按钮、显示文字重叠或显示不完整的问题，甚至颜色都可能发生改变。

alexzhao

从昨天中午逛到现在，真的受益非浅，十分感谢论坛中的每一位成员。

renhaiyong

谢谢！受益匪浅 ！

boliping

测试用例的详细程度是由测试人员的经验和能力决定的。在国外做测试计划和测试用例的都是由高级测试人员进行的。而国内反正是能不能做都是一样，做成啥都是一样，所以经常出现很多测试人员什么都做的情况。

我觉得这种情况对新人来说是个好机会，乱世出英雄吗。

david909

高手大有人在,好极了

波波天地

还是这个实在，虽然还没看，不过斑竹又浪费了我一个技术点下载了。。
看完再来讨论。