软件测试杂录

比较杂，有空再整理一下

Junit笔记

框架，是结构的复用

Stub是用来代替外部系统的

Web测试

1、jetty是用作代替web服务器（如tomcat）的stub，用作集成、系统测试的。

它为基于jsp（和servlet）提供运行环境。开发人员可以将Jetty容器实例化成一个对象，可以迅速为一些独立运行（stand-alone）的Java应用提供网络和web连接。

2、selenium是操作web界面的功能测试，相当于winrunner。httpUnit也有类似功能

数据库测试

1、对业务逻辑的单元测试。讲业务逻辑代码部分与数据库访问代码部分隔离开来。就是用mock来模拟数据库访问代码。

2、对数据库访问的单元测试。目的是验证你是否正确使用了持久化API（如JDBC）用mockobject来进行模拟

3、 数据库集成单元测试。这类测试检验数据库的功能：连接、查询、存储过程、触发、约束以及引用完整性。为了让代码在相同环境中测试，这些测试必须在容器内部运行。Cactus提供了一种容器内测试解决方法，DbUnit（相当于stub，用xml代替可能会变化的实际数据源）提供了一种以测试数据预载数据库的方法。

Servlet测试：

Catus:在J2ee容器内对组件（如servlet）进行集成（单元）测试

所以容器内单元测试也叫集成单元测试

也可以用mockobject进行单元测试（即容器外测试）。关键：为servlet提供httpServletRequest对象

容器外方法的缺点：

1、无法测试容器与组件、及组件间的交互，部署

2、需要了解组件被调用的api

3、不确定会在目标容器中正常运行

用Catus可进行集成单元测试。可测容器内各组件的交互。是一个可以用junit驱动的tomcat容器。可以在jetty内运行cactus。（容器：组件是在容器内执行的一段代码。容器则是为存放在内的主件提供有用的服务（比如生命周期、安全、事务等）的器皿。

Cactus框架把容器对象（此处是httpServletRequest和HttpSession对象）提供给测试，这样就使得编写单元测试可以更简单更快速

关于 testmaker要安装 firefox3.0标准版 和testgen4web 1.0扩展。在浏览器上进行记录，生成测试代理脚本。一开始是testmaker的格式的脚本。可以转为jpython。脚本可分为触发脚本和记录或检验性脚本（这就需要firefox的扩展支持了）

关于 .net 测试自动化书中的web测试

介绍了两种方式

1、采用JavaScript的方式有局限性，那就是被测系统与测试平台依赖太强了，（用javaScript写的）测试平台必须先知道被测系统的dom结构

2、 这种方式是通过调用ie的接口实现的，与testmaker类似

杂：

Selenuim是功能测试

Jetty是集成或系统测试。Jetty可由在运行时启动，可由junit驱动。

Junit框架主要是做单元测试，也可以做集成（组件）、系统、功能测试，但是做这些测试时，是利用junit框架来进行 驱动、管理、分类的。可以把不同的测试工具放在这个框架上进行驱动，如功能测试工具selenuim、abbot等。

Jetty、catus可以看成是stub，是环境。做集成测试时，如果不用jetty，就会对环境依赖，不能通过框架驱动web服务器了。

Stub技术是把代码和环境隔离起来（如jetty、dbunit）而进行集成（单元）测试。类级的细粒度隔离就用mock。隔离是很重要的测试手段。不要把商业逻辑写入mock，它是一个傻对象。

集成测试需要stub（环境）

单元测试需要mock（其他类）

做功能测试时，不用jetty，而是用selenium驱动外部的web浏览器和服务器来进行测试。

（泽众的autorunner跟selenium相似，通过录制生成java脚本）

Stub和mock是有关策略的内容。Stub算是集成测试，mock算是单元测试

Stub方法里面需要实现逻辑，因为对Stub的调用者需要依赖stub模块或函数的返回值，正因为此，搭建stub跟mock比起来，是比较耗费精力的

Jmeter

可用定时器进行延时。测试性能的目的是，是否如预期的吞吐量

可先用jmeter进行批量请求，再用jprofile监测

持续集成笔记（持续测试）

集成测试（组件测试）与系统测试的不同之处在于，集成测试并不总是执行那些期望公开的api

例如，系统测试可能通过web页面执行，而集成测试通过业务层（servlet）执行

系统测试与功能测试的区别：功能测试是按照更像客户使用系统的方式来测试的（selenuim）

应对测试进行分类，先执行较快的测试。如单元测试可以在每次签入ci服务器的时候执行，集成测试在签入之前在本机执行，系统测试在晚上ci服务器上执行。

当发现缺陷时，应该隔离由问题代码，并为它写（单元）测试

让集成测试可重复：数据库的依赖性问题可以用xDbunit这样的数据库填充框架，把数据映射到xml文件中。

将测试用例限制为一个断言。

代码的可靠性取决于测试的覆盖率，测试的价值取决于它的执行频率。

关于各类测试的讨论：

白盒测试黑盒测试指测试的方式

根据不同的测试阶段，测试可以分为单元测试、集成测试、系统测试和验收测试。

单元测试的粒度最小，一般由开发小组采用白盒方式来测试，主要测试单元是否符合“设计”。

单元测试是开发者编写一小段代码，用于检验被测代码的一个功能是否正确；执行单元测试是为了证明这段代码的行为和我们期望的一致。

集成测试界于单元测试和系统测试之间，起到“桥梁作用”，一般由开发小组采用白盒加黑盒的方式来测试，既验证“设计”，又验证“需求”。

系统测试的粒度最大，一般由独立测试小组采用黑盒方式来测试，主要测试系统是否符合“需求规格说明书”。

验收测试与系统测试相似，主要区别是测试人员不同，验收测试由用户执行。

黑盒测试不考虑程序内部结构和逻辑结构，主要是用来测试系统的功能是否满足需求规格说明书。一般会有一个输入值，一个输入值，和期望值做比较。白盒测试主要应用在单元测试阶段，主要是对代码级的测试，针对程序内部逻辑结构，测试手段有：语句覆盖、判定覆盖、条件覆盖、路径覆盖、条件组合覆盖

回归测试等只能算作一种日常的操作或过程，它是由几种测试构成的

不赞成 Junit in action 里的 集成单元测试的说法，应该理解为 用junit框架驱动的 集成测试。

上面讨论中，用junit框架驱动的单元、集成、系统测试，都是白盒测试。是开发者视角

而 功能测试，则是黑盒测试。是客户视角的

Test maker 笔记

使用jython并入Junit

Junit的特点：容易的使用现有的测试。编写新的测试会消耗时间和精力。单元测试框架必须容易地在新测试中重用已有的单元测试

单元测试仅仅是编译器操作的一部分。编译器检测源代码的错误，单元测试然后运行查找错误和纠正操作的编译代码

Testmaker可以使用junit

其实就是在jython中引入junit

Fromjunit.textuiimporttestRunner

然后jython使用junit的类和方法，如 runTest

笔记本上的记录

进行单元测试时，值得测试的地方：Right-Bicep

Right——需检查结果是否正确的地方

B——需要测试边界条件的地方

I——能用反向关联检查的地方（如通过执行查询语句来看数据库插入语句是否正确）

C——可用其他手段交叉检查的地方

E——可强制错误条件发生来检查的地方

（涉及其他类似可用mock来触发。如果某操作需要某种前置条件、后置条件，则故意不满足，需要一定顺序时就把顺序搞乱。故意产生文件不存在的情况。）

P——需要满足性能需求的地方

好测试的品质：A-TRIP

自动化（Automatic）

彻底的(Through)

可重复(Repeatable)

独立的(Independent)一次只测试一个

专业的(Professianl)

Tdd的步骤：

1、用代码写一个规格说明，要符合单元测试的形式

2、测试失败

3、编写代码，实现这个规格说明

4、测试通过

5、 重构，保证系统有一个优化的，干净的代码基线（保证无重复代码，代码富表现力、清晰体现程序员意图）

系统测试：针对整个产品的全面测试，既包含各模块的验证性测试（验证前两个阶段测试的正确性）和功能性（产品提交个用户的功能）测试，又包括对整个产品的健壮性、安全性、可维护性及各种性能参数的测试

系统测试是验证系统与设计说明书是否一致（功能、非功能）

验收测试是验证系统与需求是否一致

一.软件缺陷的正式定义：

符合下边5个规则的才能叫做软件缺陷。

1.软件未达到产品说明书标明的功能。

2.软件出现了产品说明书指明不会出现的错误。

3.软件功能超出产品说明书指明范围。

4.软件未达到产品说明书虽未指出但应达到的目标。

5.软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。

二.软件缺陷的产生原因：

导致软件缺陷最大的原因是产品说明书；第二大来源是设计方案；三是代码；四是某些软件缺陷产生的条件被错误地认定。

三.软件缺陷的修复费用：

随时间增长，修复软件缺陷的费用是呈几何数级增长的，随时间推移，数十倍增长。

那些自动生成测试代码的软件做的工作基本就是路径覆盖。针对某个方法，用可视化进行数据输入，然后自动生成代码来进行驱动。（visual unit）

关于冒烟测试，应该是微软首先提出来的一个概念，和微软一直提倡的每日build有很密切的联系。具体说，冒烟测试就是在每日build建立后，对系统的基本功能进行简单的测试。这种测试强调功能的覆盖率，而不对功能的正确性进行验证。从这一点看和所谓的“接受性（验收）测试（AcceptanceTest）”非常相似。不同之处就在于他们执行的频率和被测的版本不同。