LoadRunner穿越防火墙测试

posted @ 2014-08-18 10:10 顺其自然EVO 阅读(459) | 评论 (0) | 编辑 收藏

用JIRA来跟进和管理项目进度

　　新增需求列表：

　　让迭代master和测试负责人头疼的不能及时知道需求变更的情况在这里可以得到缓解

　　首先说一下，我们可以从模板上得到神马：

　　1、 迭代/项目的需求数量、需求列表、开发进度；

　　2、 迭代/项目的测试任务、测试进度、测试任务列表；

　　3、 缺陷数量、缺陷解决情况、缺陷列表；

　　4、 需求变更情况

　　5、 模板中的内容（列表、统计图等所有信息），会根据项目情况实时自动更新的，不用作任何设置或变动（前提是开发和测试人员及时更新jira上的任务状态~~这个不为过吧，本来就应该做到的~）

　　6、 导出报表（对出项目报告和测试周报等报告灰常方便，这个主要用于master、测试负责人、项目负责人、SQA）。

　　然后说一下可以改良目前的哪些状况：

　　1、 一个项目/迭代，只需要一个人（测试负责人或者master？）做一次配置更新，造福全项目/迭代的其他人；

　　2、 项目/迭代里的任何人何以在任何时候了解到当前项目/迭代的开发和测试进度以及缺陷情况；

　　3、 Master和测试负责人以及项目负责人、SQA可以及时账务需求变更情况，来更好的控制迭代/项目风险

　　4、 导出报表，不用手动统计需求情况和测试任务等条目，节省大量时间

　　5、 模板的通用性，可配置性

　　1）前面说了，这是一个模板，每起一个新的迭代或项目，只要更新一下过滤条件，另存为一下就OK了，一个新的迭代/项目进度dashboard就出来了

　　2）如果还想得到项目其他的一些信息，新建一个过滤器，保存在这个dashboard即可。

　　以上说的就是就是如何利用jira进行项目管理，目前已经用于各个项目和迭代中，而且起到了很好的作用，至于如何用jira建立这样一个dashboard这里就不废话给出了，因为会用jira的人看了这篇文章几分钟就可以把这样一个项目或者迭代的dashboard建立好了~

posted @ 2014-08-18 09:43 顺其自然EVO 阅读(9773) | 评论 (0) | 编辑 收藏

怎么的技能可以让软件测试工程师获得高薪？

posted @ 2014-08-18 09:41 顺其自然EVO 阅读(168) | 评论 (0) | 编辑 收藏

Web服务请求异步化测试

<Set name="ThreadPool"> <!-- Default queued blocking threadpool --> <New class="org.eclipse.jetty.util.thread.QueuedThreadPool"> <Set name="minThreads">10</Set> <Set name="maxThreads">500</Set> </Set> <Call name="addConnector"> <Arg> <New class="org.eclipse.jetty.server.nio.SelectChannelConnector"> <Set name="host"><SystemProperty name="jetty.host" /></Set> <Set name="port"><SystemProperty name="jetty.port" default="6060"/></Set> <Set name="maxIdleTime">300000</Set> <Set name="Acceptors">2</Set> <Set name="statsOn">false</Set> <Set name="confidentialPort">8443</Set> <Set name="lowResourcesConnections">20000</Set> <Set name="lowResourcesMaxIdleTime">5000</Set> </New> </Arg> </Call>

附注：

　　Asyn表示异步模式，syn表示同步。Asyn中还分成resume和complete两种方式，后续在介绍技术背景的时候详细描述。

　　对于服务端的load不是每一个测试都做了记录，选取了最全面的1500并发用户做了测试。

　　最大服务请求处理数是通过应用自身实现，具体代码可以参考后面的代码附件。

　　测试结果如下：

　　场景1：500 并发用户场景下，后端服务一次请求消耗3秒钟

　　这个场景测试的目的是比较在线程池资源足够的时候，异步和同步的差别。（也就是TOP服务器所有的资源处于正常服务，前台请求没有因为前段连接被消耗完，导致服务质量降低）

　　可以看到，在TPS和Response Time上两者基本上没有太大差别，TPS就等于500/3=167左右（3秒一个请求，因此用这种简单算式可以算出），响应时间也较为正常。当时我发现在每秒吞吐量上有些差别，后来单个测试case跑了一下，发现是返回的http header比较大，应该是在做异步化时重入等作的一些标识（后面其他容器的异步化也是一样）。

　　最大处理请求数都在服务端后台看到是500，等同于最大的并发用户数。

　　场景2：1000 并发用户场景下，后端服务一次请求消耗3秒钟

　　场景2就在资源不足的情况下，比较异步服务请求与同步请求处理能力。（例如由于后端某些服务比较慢，导致前段的服务器能够承载的请求数目超过了线程数）

　　这个场景的结果可以看到TPS在异步模式下与并发用户数呈现同步增长，就好比配置了1000个线程作为线程池一样，同样在后端打出的最大请求数上也证明了这一点，因此前段线程池的服务能力在异步的情况下充分复用（当然这里使用的异步服务处理使用的是NIO而不是BIO的Connector）。同样在吞吐量上依然是增加的，由于异步附加的内容。

　　场景3：1500 并发用户场景下，后端服务一次请求消耗3秒钟

　　场景三比对了现有TOP的部署模式（Apache + modjk + Jboss）和Jetty7的同步模式，两种异步模式，Tomcat同步模式，Tomcat的servlet3.0异步模式的处理情况。根据测试可以得到的信息如下：

　　1.              现有部署方式在后端服务处理耗时较大的情况下，处理能力不如Jetty7和Tomcat6，同时出错率很高。

　　2.              Jetty7的同步处理测试结果和Tomcat6的同步处理测试结果很类似，但是load方面jetty7更好。

　　3.              异步处理方面Jetty7的两种方式基本上差别不大（后续还需要深入源码看看对于数据缓存资源复用的状况），Tomcat7的异步处理成功率有些问题（错误多半是在获取response回写的时候，response已经被提前释放，看来Tomcat7还是需要一些时间来考验），load上来说tomcat结果比较好。

　　4.              异步请求在提高处理能力的情况下，对于资源消耗也较大（线程切换较为频繁），不过还是在承受范围。

　　三个场景组合比较：

　　最后将三个场景合并起来做一个简单的比较，得到信息如下：

　　1.       随着并发用户的增加，本身异步处理也会有衰减，同时对于性能消耗（线程切换）也会不断增长。

　　2.       异步化在消息头上会增加一些数据，会增加回写的带宽消耗（不过量不大），一个请求增加了100byte左右的消息数据。

　　测试总结：

　　1.       Web请求异步化在TOP很合适。

　　重复两个条件：

　　a.       处理耗时大多消耗在于对后端或者外部服务资源的请求上。

　　b.       后端或者外部资源在更多的流量下不会成为瓶颈。

　　2.       Web请求异步化在Jetty6到7上已经经历了2年多的成长（Google App Engine , Yahoo Hadoop），稳定性和效率较好。（同时很多优化可以通过扩展自行定制，jetty的可扩展性很好）Tomcat7在servlet3上处于刚发布阶段，还有待继续完善。（Servlet3的另一种模式尚未执行成功，直接导致jvm退出）

　　后续需要继续跟进的：

　　1.       对于大数据量请求的容器间性能对比。（图片上传或者大数据量的Post请求）

　　2.       容器安全性。（是否容易被攻击）

　　3.       代码迁移成本。

posted @ 2014-08-18 09:39 顺其自然EVO 阅读(482) | 评论 (0) | 编辑 收藏

Android单元测试方法与步骤

　点击下一步，选择要测试的方法：

　　点击完成。

　　将新产生的单元测试的类放入test/项目包名下。

　　在单元测试方法中添加实现：

　　展开test/cn.ycmoon.test.activity下单元测试类，选择要测试的方法，点右键，选择Run As->Android JUnit Test，就会打开单元测试结果界面。

　　右该方法无错误，则结果会显示绿色状态条：

posted @ 2014-08-18 09:34 顺其自然EVO 阅读(424) | 评论 (0) | 编辑 收藏

Web应用软件功能测试

posted @ 2014-08-18 09:32 顺其自然EVO 阅读(163) | 评论 (0) | 编辑 收藏

Win7下的内置FTP组件的设置详解

　在局域网中共享文件，FTP是比较方便的方案之一。Win7内部集成了FTP，只是设置起来颇费一番功夫。着文以记之。

　　一、安装FTP组件

　　　　由于Win7默认没有安装FTP组件。故FTP的设置第一步就是安装FTP组件

　　　　点击：控制面板—》程序和功能—》打开或关闭Windows功能。勾选“FTP服务器”及“FTP服务”“FTP扩展性”，点击“确定”，安装FTP组件。如下图所示

　　二、添加FTP站点

　　　　点击：控制面板—》管理工具。选中“Internet信息服务(IIS)管理器”，如图

　　　　双击“Internet信息服务(IIS)管理器”。弹出管理器界面，如下图所示：

　　　　单击选中“网站”，并且在其上右击，选择“添加FTP站点”，出现“站点信息”界面，如下所示：

　　　　给FTP取名（本例是：zhu），以及设置FTP站点的物理路径（本例是：c:\ftp），点击“下一步”，出现“绑定和SSL设置”界面，如下图所示

　　　　IP设置为本机的IP地址，端口用FTP默认的21，SSL勾选“无”。点击“下一步”，出现“身份验证和授权信息”界面，如下图所示：

　　　　如果只是想设置简单的FTP，则“身份验证”和“授权”都勾选“匿名”，并且给匿名设置相应的权限。本例中，还要给FTP配置帐号，以及帐号的权限，故“身份验证”勾选“基本”，“授权”勾选“未选定”，点击“完成”，完成FTP站点的设置。

　　三、设置FTP帐号以及权限

　　　　由于Win7下的FTP帐号是Windows用户帐号。所以，先得添加两个用户帐号，一个是View，可以浏览、下载FTP内容；一个是Admin，完全控制FTP。

　　　　点击：控制面板—》管理工具—》计算机管理。在计算机管理的界面的左侧，点击：系统工具—》本地用户和组—》用户，右侧显示所有用户。如下图所示：

　　　　在“用户”上右击，出现“新用户”，如下所示：

　　　　在用户名中输入View，设置好密码，去掉勾选“用户下次登陆时须更改密码”，勾选“用户不能更改密码”和“密码永不过期”。点击“创建”，完成用户View的创建。同样的步骤，创建Admin用户。由于Windows默认将用户添加到Users组，你可以将刚才的两个用户从Users组中删除。方法是在“计算机管理”中点击“组”，在右侧的列表中找到Users，双击之，出现如下界面，点中用户View，点“删除”，点中用户Admin，点“删除”。将两个用户从Users组中删除。

　　　　接下来，在FTP站点中，给View和Admin添加权限。

　　　　点击：控制面板—》管理工具—》Internet信息服务(IIS)管理器。点中刚才新建的FTP站点。点中“FTP授权规则”。如下图所示：

　　　　点击右侧的“编辑权限”，对FTP站点文件夹添加用户权限。在弹出的窗口中，点击“安全”标签。，如下图所示：

　　　　点“编辑”，出现权限的窗口，如下：

　　　　点“添加”，在“输入对象名称来选择”中输入View，点“确定”，添加View用户。如下所示：

　　　　添加的View用户，默认是只有读取、列出的权限。在依法添加Admin用户，给Admin用户添加完全控制的权限。如下所示：

　　　　再回到“Internet信息服务(IIS)管理器”窗口，双击刚才选中的“FTP授权规则”，在FTP站点中对View和Admin授权。如下所示：

　　　　点击右侧的“添加允许规则”，在弹出的窗口中，勾选“指定的用户”，输入View，在下方的“权限”中，勾选“读取”。如下所示：

　　　　点“确定”，给FTP站点添加View用户，相应的权限是读取。再给FTP站点添加Admin用户，相应的权限是读取和写入。

　　　　至此，FTP的站点设置就完成了。站点文件夹是c:\ftp，View用户有读取（浏览和下载）的权限，Admin用户有读取和写入（上传和删除）的权限。当然，还可以根据实际的情况添加用户及相应的权限，也可以将用户添加进组，再给组设置权限。还可以添加匿名用户等等，不一而足了。

　　　　然而，事情远远没有结束。如果，你急于做测试的话。会发现，在本机上测试正常，但是用别的机器测试FTP的话，会发现连接不上。问题出在Win7下的防火墙。如果你把防火墙关掉，你会发现FTP恢复了正常，但你也不能因为要用FTP，就把Win7的防火墙关掉。要想在Win7开着防火墙的时候还要正常使用，还必须得在防火墙中进行一番设置

　　四、Win7的防火墙设置

　　　　点击：控制面板—》Windows防火墙。点击左侧的“允许程序或功能通过Windows防火墙”，选中“FTP服务器”，将后面的两个框都勾选，如下所示：

　　　　这是网上绝大多数介绍的防火墙设置。然而还不够，你做测试的话会发现，还是连接不上。还必须在防火墙中进一步做设置。

　　　　点击下方的“允许运行另一程序”，在弹出窗口里，点“浏览”，找到C:\Windows\System32\inetsrv\inetinfo.exe，点添加，也就是上图中的Internet Infomation Services。将后面的两个框也都选中。因为在Win7下，FTP是IIS的一个组件，因此也必须在防火墙中将IIS设置为允许。而IIS又不在默认的列表中，因此得手动添加。

　　　　遗憾的是，这样设置，FTP还是不能正常使用。由于FTP用的是21端口，因此在防火墙中还得添加出站和入站的端口规则。

　　　　在Windows防火墙窗口里，点击左侧的“高级设置”，弹出高级安全防火墙窗口，点击左侧的“入站规则”，如下图所示：

　　　　点击右侧的“新建规则”，出现向导界面，勾选“端口”，如图：

　　　　点击“下一步”，勾选TCP（FTP用的是TCP协议），再勾选特定本地端口，输入21（FTP用的是21端口）如图所示：

　　　　点击“下一步”，勾选“允许连接”，如图：

　　　　点击“下一步”，默认的都选上，如图：

　　　　点击“下一步”，在名称里输入名字，本例中是21，如图

　　　　点击“完成”，完成入站规则的设置，在用同样的方法，完成出站规则的设置，同样是21端口。

　　　　至此，在Win7的防火墙就已经设置好了。现在测试基本上就正常了。

　　不过，还有个小问题：

　　在用IE浏览FTP的时候，虽然可以登录，但是没法显示FTP内容。这个是IE的设置问题。在Internet选项中，将“使用被动FTP（用于防火墙和DSL调制解调器的兼容性）”勾掉就解决了不能浏览的问题。如下图所示：

　　后序。总体来说，Win7的内置FTP设置比一些第三方的FTP软件设置要繁琐一些。但是在某些场合下，还只能用Win7的内置FTP。以上的内容都是网上搜集来的，加上本人的亲测。如果谁在FTP设置上还有什么问题，欢迎交流。

posted @ 2014-08-15 16:18 顺其自然EVO 阅读(186) | 评论 (0) | 编辑 收藏

缺陷上报统一模板及缺陷管理流程

posted @ 2014-08-15 09:56 顺其自然EVO 阅读(213) | 评论 (0) | 编辑 收藏

ASA防火墙基本配置管理

posted @ 2014-08-15 09:55 顺其自然EVO 阅读(374) | 评论 (0) | 编辑 收藏

好的产品经理，差的产品经理

　　Ben Horowitz这篇不朽的杰作诞生于1996年，但时间的久远丝毫不影响其对当前的警示作用。那时，作为Netscape产品管理部门经理的Ben，没有假大空地介绍产品经理的角色和责任，而是很直观地对比了一个好的产品经理和差的产品经理。

　　好的产品经理，差的产品经理

　　——Ben Horowitz

　　好的产品经理了解市场、产品、产品线和剧烈的（市场）竞争，并基于自身强大的知识基础和自信进行角色扮演和职责履行。好的产品经理是产品的CEO。好的产品经理能全力履行职责并以产品的成功进行衡量。他们对正确的产品、正确的时机以及所有相关细节负有责任。好的产品经理了解公司、收入基本、竞争等种种情况的相关信息，他们负责制定并毫无托词地执行一个成功的计划。

　　差的产品经理有众多借口。比如，资金不足、技术经理很白痴、微软拥有10倍的工程师致力于开发同样的产品、我超负荷了、我得不到直接充分的指导。Barksdale不会制造这些借口，同样产品CEO也不会。

　　好的产品经理不会被需要共事交付正确产品、履行正确时间的其他各类组织占用全部时间。他们不会耗掉所有产品团队的时间、不会制定管理各种职能、不会成为产品队的一部分；相反，他们管理产品团队。技术团队不会将好的产品经理当成营销资源。好的产品经理是技术经理的营销同行。好的产品经理清晰地定义目标、做什么（需求），并管理交付什么。而差的产品经理在指出“怎么做”的时候自我感觉最棒。好的产品经理能以书面方式清晰地沟通工作上的事，即便在口头形式上也能做到清晰沟通。好的产品经理不会随便给出指示。但是，好的产品经理会非正式性地（不刻板）收集信息。

　　好的产品经理会制作可参考的附加材料、常见问题解答、简报、白皮书。差的产品经理抱怨他们整天回复销售团队的问题，以至于头晕脑胀。好的产品经理期望严重的产品缺陷，并建立真实可靠的解决方案。而差的产品经理整日跟踪消除缺陷。好的产品经理对于重要问题（强竞争力的绝招、结实的架构抉择、艰难的产品决策、市场攻击或收益）进行书面记录。而差的产品经理口头陈述观点并悲叹类似问题不要在发生。一旦差的产品经理失败了，他们则指出自己已经预测到会失败。

　　好的产品经理使团队关注收益和客户层面。而差的产品经理则让团队聚焦微软正构建的功能数。好的产品经理定义可暴力执行的好产品。差的产品经理则定义这样的“好产品”：不能执行或无法让技术人员构建他们想要的行为（比如，解决最大难度的问题）。

　　好的产品经理会考虑：在发布计划中向市场交付高价值的东西，并在发布之后获取市场份额、取得收益目标。而差的产品经理对于交付价值、匹敌的竞争性功能、定价和普遍性之间的区别，却混淆不清。好的产品经理分解问题，而差的产品经理将所有问题捆绑为一个大难题。

　　好的产品经理考虑想让媒体书写的故事。而差的产品经理跟媒体一同思考覆盖每个功能、考虑在真实技术上确保（描述）准确。好的产品经理咨询媒体问题，而差的产品经理回答媒体的任何问题。好的产品经理假定媒体和分析师是聪明的。差的产品经理则假定媒体和分析人员是外行人——（认为他们不理解“推动”和“拟推动”的区别）。

　　好的产品经理在“‘明确’对比‘解释浅显问题’”方面犯错。而差的产品经理则从不解释显而易见的问题。好的产品经理定义他们的工作和成功，而差的产品经理经常需要被告知做什么。

　　好的产品经理每周及时发送他们的现状报告，因为他们遵守纪律。而差的产品经理忘记及时发送，因为他们不重视纪律。

posted @ 2014-08-15 09:54 顺其自然EVO 阅读(153) | 评论 (0) | 编辑 收藏