|
|
smoke testing
概念上面已经有人讲了，我来讲讲实际情况
一般来说冒烟测试就是实际中的build测试，不一定需要测试用例组成，但是整个一个测试计划来划定最初的覆盖是需要的。以后可以不断往里面添加，这个不能算回归测试，但是考虑到是增长性的，也可以认为有回归的性质。
这个测试一般QA负责写，builder负责执行，builder可以是QA,开发，或者是技术支持，各公司不同了，只有通过这个测试的版本才可以交到QA部门来系统测试。
更广义一些的话，交付QA后，如果执行下基本的package testing（一般也是有个计划，顺序执行各种操作，看看是不是都能完成）,那也可以算做冒烟测试。
我还是举实际例子：
这次用个购物网站好了，night build完成，开始冒烟测试，这个测试可以是很低级别的测试，比如
对于数据库直接的测试，简历数据库，批量增加，删除，查询，增加用户，销毁数据库；
对于服务的测试，服务启动，服务的各种功能；
对于ejb的测试，各个接口的测试；
安装脚本的测试，各个环境变量是否设置正确，系统路径是否设置正确；
。。。。。。。
这个smoke testing要经可能覆盖的广，确保这些底层功能完全无误。就好比管子里装满烟，烟不冒出来说明管子不漏，然后我们再说别的，就这个意思。
然后我后面提到的那个package testing,好比下面这个流程：
QA拿到通过build测试的版本，开始安装，然后按照测试计划执行一遍，比如打开localhost:8080/index.htm,点击注册，观察是否符合计划，然后点击。。。。。
这两个测试都比较适合自动化测试的，冒烟测试的量非常大，而且每个build都要经过的，一个晚上上万次（这个次指单个操作）的量也不算很大，常常会涉及到专门编程来测试。package testing，一般只做主要版本，不需要每个版本做了，可以手工，也可以用shell script,或者简单的脚本语言来做。 |
|
/1 
关于我们
发表于 2007-1-10 13:30:42
