写写个人测试心得,以及与志同道合者交流的空间
测试20100623
上一篇 /
下一篇 2010-06-23 14:26:29
/ 个人分类:个人测试
测试用例编写的一点点个人心得
有一段时间没有写点东西了,主要是工作中的事情多,加上自己也想多看看书,这一晃时间就几个月过了。这一次我想说的内容关于“黑盒测试的测试用例的编写”,事先声明,如有雷同,纯属巧合。这些就算是我这两年来在自己的测试道路上积累的一些关于编写测试用例的经验吧,希望与大家分享和交流。
一、
测试用例的介绍
言归正传,测试用例——英文:test case(我个人一般习惯简写为TestCase),依据http://en.wikipedia.org 提供的解释,测试用例是由软件测试人员在软件工作环境下,设计一系列的条件和变量用于判断一个应用程序和软件是否正确的工作(A test case in software engineering is a set of conditions or
variables under which a tester will determine whether an application or software
system is working correctly or not)。详情可点击网址:http://en.wikipedia.org/wiki/Test_case
了解详细的叙述。
二、
TestCase执行过程
先穿插一个关于测试用例和Bug的管理的简单操作图:
三、 TestCase内容
以个人经验,认为一条测试用例(根据网上了解的和从书上学习到的)基本包含以下内容:
【表1】
编号(ID) | 标记TestCase |
测试的主模块(function) | TestCase针对的功能所归属的主模块 |
测试的子模块(sub-function) | TestCase针对的功能所归属的子模块 |
操作步骤(Action) | 操作行为 |
测试数据(Data) | 提供测试过程中的数据(包括文件) |
测试结果(Result) |
描述操作行为和现象 |
参考(Reference) |
依据的需求说明 |
测试人员(Tester) |
谁进行的测试 |
测试时间(Time) |
什么时候完成的测试 |
备注 |
说明测试过程中的一些不可预料事件 |
当然,这些只是我在进行当前的软件(应用软件)测试涉及的内容来考虑的测试用例,可能与其他人员设计的TestCase有不同,毕竟,对于TestCase没有统一的规范,只要能够将某一小功能的所有操作覆盖,并能够发现Bug和保证功能的正确实现就是好的测试用例。
我这里只是简单的描述了编写TestCase的过程,具体在编写过程中, 需要个人根据具体的情况而定,而且,TestCase并不是一蹴而就,需要不断的修订,我一般采用PDCA方法(Plan--Do--Check--Action,详细内容可自行搜索)进行修订。
其实,我所写的内容只是一个引子,对于每个人而言,测试没有什么通用的方法,具体的还需要个人更细心,更有耐心,一点一点的在测试过程中积累经验,不断学习。
相关阅读:
- 基于数据驱动的软件自动化测试框架 (fishy, 2010-6-01)
- 组合测试用例生成技术 (fishy, 2010-6-07)
- 基于模型检测的软件测试技术 (fishy, 2010-6-08)
- 关于测试用例理念的个人想法 (yangzy707, 2010-6-10)
- 关于测试用例理念的一些想法 (fishy, 2010-6-11)
- 从测试用例看测试的问题及变化(转) (8596991, 2010-6-12)
- 基于状态转换的测试 (fishy, 2010-6-13)
- 测试用例的价值 (fishy, 2010-6-17)
- 一致性测试中的时间约束及测试用例生成算法 (fishy, 2010-6-23)
- 测试20100623-2 (carlli213, 2010-6-23)
收藏
举报
TAG:
测试用例