企业级软件测试阶段 - 单元测试,SIT, UAT
在企业级软件的测试过程中,经常会划分为三个阶段——单元测试,SIT和UAT,如果开发人员足够,通常还会在SIT之前引入代码审查机制(Code Review)来保证软件符合客户需求且流程正确。
SIT(System Integration Testing)系统集成测试,也叫做集成测试,是软件测试的一个术语,在其中单独的软件模块被合并和作为一个组测试。它在单元测试以后和在系统测试之前。集成测试在已经被单元测试检验后进行作为它的输入模式,组织它们在更大的集合,和递送,作为它的输出,集成系统为系统测试做准备。集成测试的目的是校验功能、性能和可靠性要求,配置在主设计项目中。
UAT(User Acceptance Testing)用户验收测试,通常是由最终软件的用户(通常这些用户不了解软件的具体逻辑,而对业务逻辑却相当熟悉)进行的测试,因此是面向最终用户的测试,结束之后通常就可以发布生产环境了。
区别与联系:
从时间上看,UAT要在SIT后面,UAT测试要在系统测试完成后才开始。
从测试人员看,SIT由公司的测试员来测试,而UAT一般是由用户来测试。它们两个之间的专注点是不一样的.UAT主要是从用户层面这些去考虑和着手测试,而SIT主要是系统的各个模块的集成测试.这在整个软件过程理论的基础知识中相当重要的.理论上讲SIT是由专业的测试人员去完成,UAT是由用户去做的. 做UAT测试的人一定是要对业务很精通的,并且是具有代表性的用户,关注的东西就是业务流程是否通畅是否符合业务的需要.以需求分析文档为重要参考,还有一些用户的操作习惯等等一系列的东西.
本文转自ITPUB博客tolywang的博客,原文链接:企业级软件测试阶段 - 单元测试,SIT, UAT,如需转载请自行联系原博主。
UAT测试后上线出现问题的引起的思考
最近公司有一个外部项目上线了,虽然我没有参与这个项目,仅仅只是作为一个旁观者,但是关于用户的UAT测试的问题,不得表达下我的看法,
在上线之前进行了近一个月的UAT测试,测试完成后进入了正式上线阶段。但是在正式上线后还是出现了几个让人感觉不可思议的问题。
首先是居然出现大面积的用户电脑安装系统不成功的问题,安装成功后又出现了由于SSO的登录不成功的问题。关于这2个问题,我觉得不应该是
在后期还会出现的问题,首先应该在需求确认和可行性分析阶段就应该验证的问题了。即使前期都没有发现,也应该在UAT给暴露出来,但是居然在上线后才暴露出来。不得不令人深思这其中的原因。
原因不外乎下面几个:
1.项目团队前期并没有将用户的环境纳入考虑范围,或者没有应对过这种问题。
2.设计系统时没有进行全面而认真的分析,将问题想象的过于简单了,结果导致上线后用SSO登录其中的几个系统都出现了问题。
3.单元测试,集成测试,UAT测试时都没有将这2个问题真正纳入测试项。
4.项目团队的每个人都很忙,都在疲于应付各自任务,根本没有时间去思考这些看上去微不足到却极为致命的问题。
5.此外项目的沟通,需求确认及需求调研也存在问题,没有考虑周全可能出现意外,盲目乐观,而且没有任何紧急预案,也没有给自己留下一个过渡的缓冲。
综合考虑以上问题,虽然这个项目自己没有参与,但是觉得小结下还是有必要的,自己以后做项目也要引以为戒。
最新内容请见作者的GitHub页:http://qaseven.github.io/
谈谈软件测试领域
功能测试-自动化测试-性能测试-测试管理 测试发展前景,测试的薪资水平,
大公司与小公司的区别
测试的职位级别工作如何划分
工作任务如何分配
用户体验测试
易用性测试
专项测试
网站b/s,web、移动app、客户端c/s
业务UAT测试
。。。
软件开发过程中常用的环境解释DEV FAT UAT PRO
1.DEVDevelopment environment开发环境,用于开发者调试使用2.FATFeature Acceptance Test environment功能验收测试环境,用于软件测试者测试使用3.UATUser Acceptance Test environment用户验收测试环境,用于生产环境下的软件测试者测试使用4.PROProduction environment生产环境
docker安装后导致的网络问题
问题描述:在uat环境中某台机子上安装了docker后,发现公司的办公网络到这条uat的机子就ping不通了,测试环境的网络也ping不通uat了。相关环境:本地ip:172.17..,windows系统测试ip:172.17..,ubuntu16系统uat的ip:10.3..、10.4..,ubuntu16系统复盘问题过程:1.搭建jenkins时,因测试环境不能ssh到uat和生产,故选择在uat搭建jenkins。2.使用docker搭建jenkins完毕后,并未发现明显异常,但是发现办公网络到uat这台装了docker的网络突然不通了。3.猜测肯定与docker安装有关,开始检查docker安装所使用的命令,操作命令中未发现任何会对其他硬件和配置有变更的地方,只更新了软件源。4.此时有些迷茫,不清楚为啥网络就有了故障,笔者对网络不甚了解。5.碰巧部门群里,服务器的管理人员发了一个场景的docker安装产生的网络异常问题的场景,对号入住后发现与自己症状很是相似。决定照这个去网上搜了解决方案。6.找到问题原因:docker安装后默认有个docker0网卡,该网卡的ip是:172.17.0.1,该ip正好与公司本部的IP地址有冲突,然后就导致了本部的ip与docker所在网络的通信出现了问题。ping与telnet都会不通了。7.问题产生的原因一直都知道方向:docker产生的网络问题。不过直到服务器管理人员发出来才真正意识到问题的所在。解决办法:1.删除现在的网卡sudo systemctl stop docker # 关闭docker
sudo ip link set dev docker0 down # 关闭docker0网卡
sudo brctl delbr docker0 # 删除docker0网卡
sudo iptables -t nat -F POSTROUTING # 清空路由后的地址转换规则执行“brctl delbr”该命令时,可能会提示命令未找到,请参照如下:sudo yum install bridge-utils # Centos系统网桥安装
sudo apt-get install bridge-utils # Ubuntu系统网桥安装2.重新创建docker0网卡sudo brctl addbr docker0 # 创建网卡
sudo ip addr add 10.250.8.8/24 dev docker0 # 为docker0网卡声明新的ip
sudo ip link set dev docker0 up # 启动docker0网卡3.修改docker配置文件daemon.json可能不存在,该文件并不是必须的。所以若是不存在,则需要我们自己创建。sudo vim /etc/docker/daemon.json # 编辑docker配置文件打开该文件后,在后面追加刚刚第二步 配置的ip即可,如下所示{
"bip": "10.250.8.8/24"
}4.重启docker即可sudo systemctl daemon-reload # 重载docker的配置文件
sudo systemctl restart docker # 重启docker服务
ORA-07445&ORA-00108错误案例
由于需要ORACLE的UAT测试环境,克隆了虚拟机后,修改IP地址后,启动实例遇到了ORA-07445 &ORA-00108错误.
案例环境:
SQL> select * from v$version;
BANNER
----------------------------------------------------------------
Oracle Database 10g Release 10.2.0.4.0 - 64bit Production
PL/SQL Release 10.2.0.4.0 - Production
CORE 10.2.0.4.0 Production
TNS for Linux: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production
告警日志文件alert里面出现如下错误信息:
Thu Jun 11 13:45:51 2015
Errors in file /u01/app/oracle/admin/epps/bdump/epps_ora_5109.trc:
ORA-07445: exception encountered: core dump [kslgetl()+120] [SIGSEGV] [Address not mapped to object] [0x000000208] [] []
ORA-00108: failed to set up dispatcher to accept connection asynchronously
Thu Jun 11 13:45:54 2015
found dead dispatcher 'D000', pid = (16, 4)
Thu Jun 11 13:45:54 2015
dispatcher 'D000' encountered error getting listening address
Thu Jun 11 13:45:54 2015
Errors in file /u01/app/oracle/admin/epps/bdump/epps_ora_5113.trc:
ORA-07445: exception encountered: core dump [kslgetl()+120] [SIGSEGV] [Address not mapped to object] [0x000000208] [] []
ORA-00108: failed to set up dispatcher to accept connection asynchronously
Thu Jun 11 13:45:57 2015
found dead dispatcher 'D000', pid = (16, 5)
Thu Jun 11 13:45:58 2015
dispatcher 'D000' encountered error getting listening address
Thu Jun 11 13:45:58 2015
Errors in file /u01/app/oracle/admin/epps/bdump/epps_ora_5115.trc:
ORA-07445: exception encountered: core dump [kslgetl()+120] [SIGSEGV] [Address not mapped to object] [0x000000208] [] []
ORA-00108: failed to set up dispatcher to accept connection asynchronously
Thu Jun 11 13:46:00 2015
found dead dispatcher 'D000', pid = (16, 6)
Thu Jun 11 13:46:01 2015
dispatcher 'D000' encountered error getting listening address
Thu Jun 11 13:46:01 2015
Errors in file /u01/app/oracle/admin/epps/bdump/epps_ora_5117.trc:
ORA-07445: exception encountered: core dump [kslgetl()+120] [SIGSEGV] [Address not mapped to object] [0x000000208] [] []
ORA-00108: failed to set up dispatcher to accept connection asynchronously
[oracle@getlnx01uat ~]$ more /u01/app/oracle/admin/epps/bdump/epps_ora_5109.trc
/u01/app/oracle/admin/epps/bdump/epps_ora_5109.trc
Oracle Database 10g Release 10.2.0.4.0 - 64bit Production
ORACLE_HOME = /u01/app/oracle/product/10.2.0/db_1
System name: Linux
Node name: getlnx01uat.esquel.com
Release: 2.6.32-200.13.1.el5uek
Version: #1 SMP Wed Jul 27 21:02:33 EDT 2011
Machine: x86_64
Instance name: epps
Redo thread mounted by this instance: 1
Oracle process number: 16
Unix process pid: 5109, image: oracle@getlnx01uat.esquel.com (D000)
Warning: keltnfy call to ldmInit failed with error 46
*** 2015-06-11 13:45:51.950
network error encountered getting listening address:
NS Primary Error: TNS-12533: TNS:illegal ADDRESS parameters
NS Secondary Error: TNS-12560: TNS:protocol adapter error
NT Generic Error: TNS-00503: Illegal ADDRESS parameters
OPIRIP: Uncaught error 108. Error stack:
ORA-00108: failed to set up dispatcher to accept connection asynchronously
Exception signal: 11 (SIGSEGV), code: 1 (Address not mapped to object), addr: 0x208, PC: [0x75f178, kslgetl()+120]
*** 2015-06-11 13:45:51.954
ksedmp: internal or fatal error
ORA-07445: exception encountered: core dump [kslgetl()+120] [SIGSEGV] [Address not mapped to object] [0x000000208] [] []
ORA-00108: failed to set up dispatcher to accept connection asynchronously
Current SQL information unavailable - no session.
............................................
解决方法:
在ORA-07445[kslgetl()+120]/ORA-00108错误解决这篇文章了解到可能是主机名不能被正常访问导致,于是从下面验证后,发现是自己不小心编辑/etc/hosts
[oracle@getlnx01uat ~]$ hostname
getlnx01uat.esquel.com
[oracle@getlnx01uat ~]$ ping getlnx01uat.esquel.com
PING getlnx01uat.esquel.com (192.168.xxx.xxx) 56(84) bytes of data.
64 bytes from getlnx01uat.esquel.com (192.168.xxx.xxx): icmp_seq=1 ttl=64 time=0.032 ms
64 bytes from getlnx01uat.esquel.com (192.168.xxx.xxx): icmp_seq=2 ttl=64 time=0.039 ms
64 bytes from getlnx01uat.esquel.com (192.168.xxx.xxx): icmp_seq=3 ttl=64 time=0.049 ms
^C
--- getlnx01uat.esquel.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 0.032/0.040/0.049/0.007 ms
[oracle@getlnx01uat ~]$
[oracle@getlnx01uat bdump]$ ls -l /etc/hosts
-rw-r--r-- 1 root root 260 Jun 11 13:52 /etc/hosts
[oracle@getlnx01uat bdump]$ hostname
getlnx01uat.esquel.com
[oracle@getlnx01uat bdump]$ ping getlnx01uat.esquel.com
ping: unknown host getlnx01uat.esquel.com
[oracle@getlnx01uat bdump]$ more /etc/hosts
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1 localhost.localdomain localhost
xxxx getlnx01uat.com getlnx01uat
如上所示,hostname为getlnx01uat.com,这个可能是我编辑/etc/hosts时,不小心误删除了一些hostname一些字符。编辑修改hostname后,重启数据库问题解决
[root@getlnx01uat ~]# more /etc/hosts
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1 localhost.localdomain localhost
xxx.xxx.xxx.xxx getlnx01uat.esquel.com getlnx01uat
持续集成
关于持续集成的基本方案
一、基本组建
1、maven jar包管理工具
2、svn 代码管理
3、eclipse 开发工具
4、junit4 单元测试工具
5、dbunit 数据库测试框架
6、jenkins 构建工具
7、tomcat web服务器
二、集成与发布
1、单元测试
要求每一行代码都必须要经过测试,单元测试、接口测试
2、版本控制
定义规范的版本控制策略,严格控制每次版本的输出,并记录更新log
2、自动化构建
在每次提交新代码时,自动触发自动化构建,运行所有的测试代码,并在测试报告通过的前提下,完成UAT环境的部署
3、一键发布
在UAT环境完成测试之后,测试通过的前提下,通过一键发布命令,完成生产环境的发布
本文转自一米一阳光博客园博客,原文链接: http://www.cnblogs.com/candle806/p/3785349.html ,如需转载请自行联系原作者
持续集成
关于持续集成的基本方案
一、基本组建
1、maven jar包管理工具
2、svn 代码管理
3、eclipse 开发工具
4、junit4 单元测试工具
5、dbunit 数据库测试框架
6、jenkins 构建工具
7、tomcat web服务器
二、集成与发布
1、单元测试
要求每一行代码都必须要经过测试,单元测试、接口测试
2、版本控制
定义规范的版本控制策略,严格控制每次版本的输出,并记录更新log
2、自动化构建
在每次提交新代码时,自动触发自动化构建,运行所有的测试代码,并在测试报告通过的前提下,完成UAT环境的部署
3、一键发布
在UAT环境完成测试之后,测试通过的前提下,通过一键发布命令,完成生产环境的发布
本文转自一米一阳光博客园博客,原文链接: http://www.cnblogs.com/candle806/p/3785349.html ,如需转载请自行联系原作者
一次不该出现的bug
部门好久没有出过事件了,ps:事件可以简单的理解为bug,事件分为5个类别,其中严重的是1级,灾难性的。但是这次是天灾,避免不了。
首先说说我们发布程序的过程,首先程序员发布到测试环境,测试人员测试通过,然后发布到uat,业务人员接着测,这个地方其实是很薄弱的,uat环境缺失很多数据,有的地方根本没有办法测,最后测试人员点通过,项目经理上生产,这个时候也不是直接上生产的,项目经理会告诉发布人员这个站点可以发布了,发布人员会从集群里面拉出一台机器做堡垒,把最新开发的代码发布到堡垒机上测试,堡垒测试还是测试人员来测的,只不过这个时候访问的是真实生产环境的数据,用的账号也是真实生产环境的账号。当然这个地方只是冒烟测试,不会测的很细致,因为在测试环境会测很长时间,虽然是黑盒但是会测的很细致,所以在生产环境上只是走一走常规流程。
整个过程是没有什么问题的,但是在某些情况下就不行了。offline预定站点访问量相对较少,注意只是相对。只有两台机器,如果拉一台出来做堡垒机,那客户所有的访问都会瞬间涌入到另外一台机器上,这个时候会暴漏出一个问题,504 gateway time-out,不用我解释你们可能已经清楚什么问题。
拉出来的这台堡垒机只有那几个测试人员在上面访问,绝对不会报这个错误,但是剩下的那台生产机就不一样了啊,相当于两个人的担子现在一个人来挑,于是它就罢工了,一直报504,堡垒测试的时间超过1小时,意味着这1个小时它完全趴下了,客户报修一个接着一个,完了,一个一级事件出现了。
你可能会疑问,测试人员如何在堡垒机上测试,如何保证自己测到的是最新的代码,答案是host,测试人员在自己host上指定堡垒机的IP地址,这样访问到的站点会映射到堡垒机上。
开发的技术很重要,测试很重要,流程也同等重要,一个大的站点不可能发布了,直接拷贝到生产环境就了事了,测试工具,发布工具,日志都是缺一不可的。但是不管怎么说问题还是会不断地出现。
作者:Tyler Ning
出处:http://www.cnblogs.com/tylerdonet/
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,如有问题,可以通过以下邮箱地址williamningdong@gmail.com
联系我,非常感谢。
测试流程--测试发版规范
一,目的 为了保证系统稳定性,对软件项目的上线过程进行规范,确保项目符合产品需求。对于已经开发完毕的系统,需要正式部署到生产环境前必须严格按照以下流程规范实施。规范发版的流程,指定发版的相关输出,相关信息的收集,并通知相关业务方了解发版信息。防止或减少因发版造成的系统抖动对业务产生的影 响,并有利于追溯发版过程,方便后续优化迭代。二,测试1.测试部署到UAT目的:测试根据开发提供的部署文档模拟配置生产环境,能提前发现开发遗漏配置等相关问题,提前暴露在UAT环境。整个系统开发完毕后,首先要模拟配置生产环境,并将系统部署至UAT环境进行测试,开发负责人发部署说明邮件,由测试部署到UAT,(如部份功能需在生产环境验证的,则需要在晚上等时间确保客户不使用或最少使用系统的时间段上线,并确保进行紧急的冒烟测试),测试部署到UAT环境后通知产品经理发布发版计划通知。2.发版计划通知目的:主要是同步发版计划,让各端根据发版规划提前做出相应的调整。部署到UAT环境后,由产品经理通过TAPD发送发版规划内容邮件通知到相关干系人,具体流程请看“二大类-发版规划”规范。3.业务方体验测试 注:此项由产品经理自行确认是否需要业务方进入体验性测试目的:业务方提前参与项目试用有助于提前熟悉相关功能以及能尽早的发现需求功能不是预期想要的。在UAT环境测试通过后,由产品经理邮件通知业务方进入UAT环境进行体验性测试(邮件附带需求、BUG的定义以及BUG的级别定义说明)。4.业务方体验提出的问题由测试同学评审并分类业务方提出的问题,修复需解决的BUG。三,上线流程3.1 项目迭代1,发版规划迭代版本确认后,由产品经理通过TAPD自带的项目报告功能(模板由项目委员会统一制定),发版规划需发送给此项目相关干系人(相关运营人员、产品、开发、项目总监、QA)内容包括:项目名称、迭代版本、计划上线时间、影响时长、新增/更新功能、影响范围报告模块使用方法:项目 --- 报表 --- 项目报告 --- 创建项目报告 --- 选择“发版规划模板”报告示例:2,发版前通知执行阶段:迭代版本进入到UAT环境, 经产品经理确认无误后,需至少提前1小时发布通知邮件。执行人:由产品经理通过TAPD自带的项目报告功能(模板由项目委员会统一制定)。接收人:发版规划需发送给此项目相关干系人(相关运营人员、产品、开发、项目总监、QA)。报告模块使用方法:项目 --- 报表 --- 项目报告 --- 创建项目报告 --- 选择“发版前通知模板”。3,发版结果通知发布上线后,由测试在线上进行验收,验收通过后告知产品经理,由产品经理发布发版结果通知,无论发布成功与失败在发布后30分钟内均需发布结果通知。报告模块使用方法:项目 --- 报表 --- 项目报告 --- 创建项目报告 --- 选择“发版结果通知 模板”。4,变更通知当发版计划影响发布时间节点时,建议至少提前1小时发布变更通知邮件,由产品经理收集相关信息并发布通知。报告模块使用方法:项目 --- 报表 --- 项目报告 --- 创建项目报告 --- 选择“发版变更通知 模板”3.2 紧急发版处理 当产生线上bug或紧急需求时,可不经过上述发版流程,直接解决或实现后,由开发或技术负责人直接做发布通知即可。若是线上BUG请按故障紧急处理规范执行,详见“线上产品故障处理规范”的“紧急措施”章节。报告模块使用方法:项目 --- 报表 --- 项目报告 --- 创建项目报告 --- 选择“发版结果通知模板”。四,发版后归纳总结项目迭代版本发布上线一周内,以下各项由组负责人或产品经理检查并组织项目的复盘工作,归纳项目文件,总结相关经验。1.巡检测试用例由各端负责巡检的测试同学编写并集成到jenkins对线上定时巡检。(注:编写巡检用例可由组内自由安排)2.业务功能重要场景梳理,由产品经理梳理业务的重要等级并更新到以下链接文档中。3.心跳检测,新上服务各端提供固定的接口,由运维负责加入到心跳检测。- - - 9.23日更新:当前上了K8S后未复现服务假死的情况,经运维确认,先观查一个月(10月底)如未复现,后续可不用添加心跳检测