-
Web服务器——nginx
2012-06-20 11:03:00
这两天又一次搭建了下nginx集群服务器,感慨些许,之所以说是又一次,是因为去年的时候在测试服务器上搭建过一次,当时得出的结论是,很简单,很easy就搞定了。这两天再研究的时候,却发现上传接触到的只是皮毛而已。于是在晚上找了份资料,回家也翻了下前段时间买的一本书,发现有点意思:
1、它是个什么东东?
俄国佬(名字不用管他了)开发的一款可以替代apache的高性能web服务器,支持高并发(50000),而CPU,内存等系统资源占用比较少,运行非常稳定。非常小,只有几百kb。国内很多知名门户都用它做web服务器或反向代理服务器。
2、安装(基于liunxOS)
tar zxvf ***.tar.gz
cd ***
./configure
make
make install
以前都是通过上面的命令,以最简单的方法安装一个软件,这次发现:./configure后面有很多编译选项,可以指定不同配置文件安装到不同路径;指定不同用户,组;开启/禁用某些配置,模式等。
3、nginx配置
编辑配置文件:nginx.conf ,下面列出目前用到的一些配置,其他的还在研究中
1).下面这张图是根据自己理解画的,可能不完整或者有不足。
2).打开配置文件:vim nginx.conf,配置如下
#nginx 用户组
user nobody;
#启动的nginx 进程数
worker_processes 1;
#nginx日志
error_log logs/error.log;
error_log logs/error.log notice;
error_log logs/error.log info;
events {
use epoll;# epoll 是Linux 下性能最好的event模式
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
#日志格式
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'"$status" $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
sendfile on;
keepalive_timeout 65;
upstream bap {
server 127.0.0.1:8082weight=20; #还有其他参数,暂时先不说明
server 127.0.0.1:8081 weight=10;
}
server {
listen 8088;
server_name 192.168.90.181:8088;
charset utf-8;
#access_log logs/host.access.log main;
location ~ ^/NginxStatus/ {
stub_status on; #Nginx 状态监控配置
access_log off;
}
#location1 / {
# root html;
# index index.html index.htm;
location / {
proxy_pass http://bap/;
proxy_set_header X-Real-IP $remote_addr;
client_max_body_size 100m;
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
}
:q
3).配置好后,启动:
/usr/local/nginx/sbin/nginx
4).测试验证:
在浏览器中输入,192.168.90.181:8088 ok,环境启动好了(预先在服务器上安装了两个BAP的环境),登录,正常。停掉其中任一台BAP环境,继续操作,没有问题。
4、动静态页面分离
1).静态页面处理
通过正则表达式,我们可让 Nginx 识别出各种静态文件,例如 images 路径下的所有请求可以写为:location ~ ^/images/ {
root /opt/webapp/images;
}而下面的配置则定义了几种文件类型的请求处理方式。
location ~ \.(htm|html|gif|jpg|jpeg|png|bmp|ico|css|js|txt)$ {
root /opt/webapp;
expires 24h;
}对于例如图片、静态 HTML 文件、js 脚本文件和 css 样式文件等,我们希望 Nginx 直接处理并返回给浏览器,这样可以大大的加快网页浏览时的速度。因此对于这类文件我们需要通过 root 指令来指定文件的存放路径,同时因为这类文件并不常修改,通过 expires 指令来控制其在浏览器的缓存,以减少不必要的请求 。
2).动态页面处理location / {
proxy_pass http://localhost:8080;
proxy_set_header X-Real-IP $remote_addr;
}
上面的配置(最简单的),通过proxy_pass 指令传送给后端的服务器(virgo)来处理动态请求。
5、负载均衡
# ip_hash
upstream bap {
server 127.0.0.1:8082 weight=20; #还有其他参数,暂时先不说明
server 127.0.0.1:8081 weight=10;
}Weight --权重
ip_hash--用ip_hash无法实现负载均衡,而且后端服务器设置的权重将不起作用。那么ip_hash作用是什么呢?加上ip_hash可以保证一台客户端发送到请求始终被分配到同一后端服务器上。避免session失效。
6、监控
配置
下面信息可以做到nginx的后台监控
location ~ ^/NginxStatus/ {
stub_status on; #Nginx 状态监控配置
access_log off;
}
监控到的内容包括:
l 当前nginx正处理的活动连接数
l 处理总数,成功多少,失败多少
l nginx 读取到客户端的 Header 信息数
l nginx 返回给客户端的 Header 信息7、缓存(需要在网上下载依赖包,比较麻烦,还没有搞)
8、其他深入研究,留待研究后再交流
PS:发现word上画的图在这里都显示不出来,只好去掉了;样式真难搞,土了点 -
测试申请提交操作手册
2011-12-21 13:46:56
测试申请提交手册
一、现 状
针对目前测试申请提交过程中存在:
Ø 装包错误率高达90%以上;
Ø 文件遗漏,错误问题时有发生;
Ø 提交周期比较长;
Ø 驳回频繁;
Ø 总体质量不高。
等若干问题,经过跟部分开发人员,项目经理和开发经理讨论,确定由测试这边制订一份《测试申请提交手册》。
二、目 标
通过本操作手册的完善和补充,达到:
Ø 降低测试装包错误率,努力控制在0%;
Ø 避免文件,存储过程等遗漏;
Ø 变更及时通知;
Ø 提高工作效率和补丁包总体质量。
三、方 案
1、checklist约束
基于之前checklist基础,持续完善checklist检查项内容,下面是最新修改的完善的内容:
===============================================================
--开发人员确认--
检查要求 | 检查结果
-----------------------------------------------------------------------------------------------------------------------------
1、必须在装包环境通过装包验证 | ??
2、必填项、唯一性等检测没问题 | ??
3、字符长度、类型、名称符合设计,并与数据库表一致 | ??
4、页面查看源文件不报错 | ?? 5、删除、启用、停用时提示是否正确 | ??
6、所有的显示列表、PT页面必须提供导出 | ??
7、物品、客户、供应商、人员、部门选择必须提供助记码| ??
9、数字、日期、电话、邮箱等符合约定格式 | ??10、特殊的操作和配置等是否在测试申请中注明 | ??
11、...... | ??
-----------------------------------------------------------------------------------------------------------------------------
--项目负责人/设计师确认--
检查要求 | 检查结果 1、功能、业务流程符合设计,无报错 | ??
2、数据回填等控制点是否完整 | ??
3、数据表字段是否符合设计 | ?? 4、提示信息是否准确 | ?? 5、打包是否符合规范 | ??-----------------------------------------------------------------------------------------------------------------------------
--UI设计师确认--
检查要求 | 检查结果===============================================================
2、常见错误总结
目前归纳记录下的装包错误也就是以下几种,通过记录平日常见错误,以避免类似的错误再犯。
错误1:文件、存储过程漏打入包中
解决:a、装包环境装包 b、自己或者设计师检查确认 c、装包后功能验证 d、...
错误2:存储过程带前缀:比如,solu201."Base_StatHotorder"
解决:a、自己或者设计师检查确认 b、平日养成习惯 c、.....
错误3:装包不成功
解决:a、一般是资源文件,result,存储过程安装不成功,通过查看数据库和菜单可以确认
错误4:装包乱码
解决:a、反复编码转换即可 b、找有经验的人,比如:king.bug,DT等 c、....
错误5:patch.xml文件写错
解决:a、参照已测试通过的patch文件 b、通过装包确认.
错误6:所有文件不是一次提交上来的,可能第一次装包没有问题,后续做了修改,导致出现问题
解决:a、尽量做到一次提交,避免提交后做大量修改或变更 b、最后的内容也要通过装包确认. C、....
错误7:环境因素,环境,数据不一致不同造成的
解决:a、装包尽量在接近正式环境下验证 b、如果有该因素,最好在测试申请中提出来. C、....
错误8:同一个包,包含多个人的内容
解决:a、推选包负责人 b、借鉴XGSCRUM小组的做法(目前他们做的很好). C、....
3、建议和要求
1、目前部分审批流程只是走一个形式,建议相关审批人员起到检查和督促作用。
Ps:关于测试申请走流程,希望开发人员发表自己的看法
2、前期没有任何参与或了解的情况下接到测试申请。这样的测试申请测试组按规定是可以拒测
3、提交测试时附属文档必须都是最新的
4、每次文件,内容变更在bugfree中标注
5、驳回的测试申请请重新走严格审批流程
6、及时完善checklist内容
7、为了便于查找和补充完善既定的规范标准、手册,建议建立专门svn目录(比如,《测试申请提交手册》,《bug解决处理手册》,《日常问题解决大全》等),所有新员工必须当作必修内容学习
8、对新入职员工做集中培训
-
测试用例模板与规范
2010-07-08 11:49:39
写了一份测试用例模板与使用规范
-
软件测试中十大负面测试用例
2010-06-04 11:30:55
负面测试(Negative testing)是相对于正面测试(Positive testing)而言的。它们也是测试设计时的两个非常重要的划分。简单点说,正面测试就是测试系统是否完成了它应该完成的工作;而负面测试就是测试系统是否不执行它不应该完成的操作。形象一点,正面测试就象一个毕恭毕敬的小学生,老师叫我做什么,我就做什么;而负面测试就象一个调皮捣蛋的孩子,你叫我这样做,我偏不这样做,而且和你对着干。开发人员也是最讨厌修改此类bug的。
正面测试主要根据需求,功能说明书,设计文档等相关参考文档来执行测试,而负面测试则主要根据错误猜测,逆向思维来测试系统,一定程序上的的依赖测试人员的经验积累。
执行负面测试时,不单单要测试系统是否处理了用户的异常操作,还要检查系统对于这些异常操作是否给予了正确的错误提示。它是系统对用户进行继续正确操作的指引。
简言之负面测试的三部曲就是:
1、检查程序中的屏幕或页面是否给出了清晰且充分的提示或约束;
2、测试系统是否处理了用户的异常操作;
3、检查系统的错误提示是否清晰且充分。
以下是Steve Miller的《Top 10 Negative Test Cases》,概括性的提到了一些做负面测试时经常需要注意的测试。
负面测试用例被设计于用软件未意欲被使用的方式测试软件,它也应该是测试工作的一部分。以下就是在设计测试工作量时你应该考虑的十大负面测试用例。
1、植入的单引号。大多数基于SQL的数据库系统在用户存储包含一个单引号的信息时会出现问题,例如John's car。每一个可以接受文字数字型数据条目的屏幕都要试试输入包含一个或多个单引号的文本。
【补充】其实不只是单引号,基本上测试人员应该测试所有的特殊字符和空/空格(单纯的空格和文本前后的空格)。单引号,逗号,/,<,>(对于web的应用程序)都是很容易引发错误的。在开发早期测试组就可以建议开发组写一个通用的函数来处理这些特殊字符,然后在处理用户的输入时套用这个函数就可以避免此类错误了。
2、必需输入的数据条目。功能说明书上应该清楚的指出屏幕上必须输入数据条目的字段。测试屏幕上每一个被说明为必须输入的字段以保证它强制要求你在字段中输入数据。
【补充】对于强制输入的字段,在屏幕上最好有些标识以说明其为必须输入的字段。一般在字段前或后用红色的*号表示。测试时必须要检查有标识的字段是否和功能说明书或其他参考文档一致,错误信息提示是否正确,强制输入的字段是否真的必须输入。
3、字段类型测试。功能说明书上应该清楚的指出要求特定数据输入要求(日期字段,数字字段,电话号码,邮编等等)的字段。测试屏幕上每一个被指出有特定类型的字段以保证你输入了基于字段类型的符合正确格式的数据(数字型字段应该不允许字符或特殊字符,日期型的字段应该允许输入一个正确的日期等等)
【补充】其实这里还有一个字段格式和字段内容的测试。有些字段对输入的格式有要求,这些字段的格式一般在屏幕上也有相应的提示。所以在测试时需要测试提示的格式是否合理(和功能说明书或其他参考文档相一致)以及系统是否正确识别输入的格式。有些字段对字段的内容有限制,如常见的用户名,不能包含特殊字符,首字不能未数字等要求。所以在测试时需要测试提示的格式是否合理(和功能说明书或其他参考文档相一致)还有不符合内容要求的数据输入时系统是否正确的处理。
4、字段长度测试。功能说明书上应该清楚的指出可以在字段中输入的字符数(例如,first name必须是50个或更少的字符)。写测试用例以保证你只可以输入特定的字符数。防止用户输入比允许范围更多的字符比因用户已输入过多的字符而给出的错误信息更加的文雅些。
【补充】一般对于限制长度的字段,现在开发大多采用限制输入的方法(设置字段的长度)来处理。所以测试时需要测试限制的长度是否合理(和功能说明书或其他参考文档相一致),对于没有限制长度的字段,要测试无穷输入时是否出错,有问题报bug时建议开发人员根据需要限制长度。
5、数字型的边界测试。对于数字型的字段,测试上下边界是非常重要的。例如,如果你正在计算某个账户的利息时,你永远不会输入一个负的利息数给应该赢取利息的账户。因此,你应该尝试用负数测试。同样,如果功能说明书上要求字段在某一个特定的范围(如从10~50),你就应该尝试输入9或51,它应该给出一个得体的信息表示失败。
6、数字的约束测试。大多数数据库系统和编程语言允许数字条目被识别为整数或长整数。通常,整数的范围是从-32,767~32,767,长整数的范围从-2,147,483,648~2,147,483,647。对于那些没有特定边界限制的数字数据条目,用这些限制测试以确保不会出现数字的溢出错误。
【补充】小数型的数字字段同样也需要格外的测试。一般对于未指出数字类型的字段,尝试输入负整数,负小数,0,正整数,正小数进行测试。
不管是哪种数据库系统,对于数字一般都有多种数字类型。所以测试人员一定要测试的全面。
7、日期边界测试。对于日期型的字段,测试上下边界是很重要的。例如,如果你正在检查一个出生日期的字段,很大可能出生日期不能早于150年前。同样,出生日期应该不是将来的某一天。
【补充】一般来说,每种数据库系统的日期都有个范围,如SQL Server最小日期是1753年1月1日,所以如果是输入型的日期字段同样也应该测试早于1753的日期。
8、日期的有效性。对于日期字段,确保不允许无效的日期是很重要的(04/31/2007是一个无效的日期)。测试用例也应该检查闰年(每个第4年和第400年是一个闰年)。
9、web会话测试。很多的web应用程序依赖浏览器的会话来追踪已登录的用户,应用程序的设置等等。应用程序的大多数屏幕不被设计为没有首次登录就可以被运行。应用程序应该确保在打开应用程序的某一页面之前会话里有一个有效的登录。
10、性能的改变。当发布产品的最新版本时,应该有一套运行于识别屏幕(列出信息的屏幕,add/update/delete数据的屏幕等等)速度的性能测试。测试包里应该包括比较先前版本和现有版本性能统计值的测试用例。这个可以帮助识别那些可以证明是随着对现有版本的代码变更而引起的潜在的性能问题。
【补充】从第一条到第八条是我们在测试字段时常常需要做的测试,一般的测试人员都不陌生。第九条在测试web应用程序中会作为检查应用程序的安全性而做的一项测试。而第十条估计很多公司都不会将它考虑到测试的范畴中,一般最多也就是在测试用例中添加校验某一个操作是否在系统允许的响应时间里,很少去做这样的比较,除了一些有针对性的性能测试。
我的栏目
标题搜索
我的存档
数据统计
- 访问量: 241786
- 日志数: 103
- 书签数: 1
- 建立时间: 2008-09-25
- 更新时间: 2016-06-01