日历
| 日 | 一 | 二 | 三 | 四 | 五 | 六 |
---|
24 | 25 | 26 | 27 | 28 | 29 | 30 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 1 | 2 | 3 | 4 |
|
导航
留言簿(1)
随笔分类(31)
文章分类(4)
收藏夹(21)
搜索
积分与排名
最新随笔
最新评论
阅读排行榜
|
软件工程
|
软件开发领域,如需求分析, 编码, 测试 |
-
单元测试(转摘)
摘要: 单元测试(模块测试)是开发者编写的一小段代码,用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言,一个单元测试是用于判断某个特定条件(或者场景)下某个特定函数的行为。例如,你可能把一个很大的值放入一个有序list 中去,然后确认该值出现在list 的尾部。或者,你可能会从字符串中删除匹配某种模式的字符,然后确认字符串确实不再包含这些字符了。
单元测试是由程序员自己来完成,最终受益的也是程序员自己。可以这么说,程序员有责任编写功能代码,同时也就有责任为自己的代码编写单元测试。执行单元测试,就是为了证明这段代码的行为和我们期望的一致。
要进行充分的单元测试,应专门编写测试代码,并与产品代码隔离。个人认为,比较简单的办法是为产品工程建立对应的测试工程,为每个类建立对应的测试类,为每个函数(很简单的除外)建立测试函数。 阅读全文
-
测试用例设计
摘要: 测试用例就是测试数据及与之相关的功能的一个特定集合,它是为验证被测试程序(为测试程序路径或验证是否符合特定功能等方面的需求)而设计的。在单元测试过程中,测试用例的设计应与复审工作相结合,根据设计的测试用例选取不同的测试数据,将增加发现各类错误的可能性;另外,根据项目的具体情况确定测试用例项。如:测试用例编号、用例输入、用例预期输出、被测单元的版本号、实际输出等。单元测试用例的设计既可以使用白盒测试也可以使用黑盒测试,但以白盒测试为主,黑盒测试侧重于功能,白盒测试侧重于逻辑。
白盒测试进入的前提条件是测试人员已经对被测试对象有了一定的了解,基本上明确了被测试软件的逻辑结构。具体过程就是针对程序逻辑结构设计和加载测试用例,驱动程序执行,检查在不同点程序的状态,以确定实际的状态是否与预期的状态一致。
一般来说,为了度量测试的完整性,测试工作中通常要求达到一定的覆盖率要求。因为通过覆盖率的统计可以知道测试是否充分,对软件的哪个部分所做的测试不够,指导我们如何设计增加覆盖率的测试用例。这样就能够提高测试质量,尽量避免设计无效的用例。
在白盒测 阅读全文
|