当测试用例编写完成，并通过审核后，就进入到软件测试最主要的阶段，就是执行测试用例，进行软件测试。不过在执行测试是有几个地方需要注意：
1、仔细检查软件测试环境是否搭建成功与稳定，因为测试用例中的执行都是建立在这个测试环境之上的，如果测试环境的不一致，会影响测试用例的执行，和测试目的的证明。
2、注意测试用例中的前提条件和特殊规程说明。因为有些测试软件是有顺序性的，那么它的测试用例就会有一些执行前提或特殊说明。比如要测试某个软件的登陆功能，那么测试前必须创建用户，并为用户分配一定的权限等。如果前提条件和特殊说明没有注意，会导致测试用例的无法执行。
阅读全文…
loadrunner场景设置的方法：
1.逐步增加用户数，分多次去运行场景。比如：第一次运行50并发，第二次运行100并发……
2.针对同一个脚本设置多个组，使用组策略(点击Edit Schedule按钮，选择Schedule by Group)，第一个组为初始用户数，如100，第二个组以50或100递增。每个用户场景都持续稳定地运行一段时间，这样可以把几种用户场景下的测试在一次场景的运行过程中就一次性执行完毕，而且还有一个好处是可以把多个用户场景下的性能结果都整合到同一个结果中，也方便对比、分析。
按组计划一般可用于比较复杂的业务流程中。比如，我们要实现用户注册系统，然后发贴，而论坛管理员认为这些帖子是非法的，需要将这些帖子删除。此时，我们就需要用到按组计划了。
按组计划的优点是可以设置在同一场景中不同脚本执行的先后顺序，可以组合处复杂的业务逻辑。
在Schedule by Group中方式，比按场景计划多了”Start Time”选项卡，Start Time中脚本有三种执行方式：
第一个：在场景开始时启动；
第二个：场景开始运行一段时间后开始，这种方式需要指定具体的开始时间；
第三个：在某些特定虚拟用户组运行完成后开始，这种方式适用于具有耦合关系的虚拟用户组。
通过后两种方式可以体现处不同组之间执行的先后关系。
至于Ramp Up, Duration, Ramp Down的功能与 Schedule by scenario一样。
按用户组计划的方式更加灵活，能够创建实际应用中那些有约束的场景。如果一组用户执行后产生的数据记录是另外一组用户的输入，那么就学要按照”用户组”的方式配置场景。
可以通过选右边Graph中的不同场景的线来选择对象，也可只显示一个线条，再对各个场景关系进行设置！
注：Schedule by scenario是所有用户遵从场景的整体安排。
昨天安装和破解Loadrunner11后发现会有License失效的情况，具体现象：启动loadrunner，选择“CONFUGURATION—>loadrunner license”会发现license信息框内为空白。
在“开始”菜单找到Loadrunner的一个应用程序后，点右键-选择“属性”-兼容性，兼容模式中将“以兼容模式运行这个程序”前面的对勾选中，下拉选项选择：windows XP（Service Pack 3），特权等级中将“以管理员运行此程序”前面的对勾选中，然后“确定”，再次启动Loadrunner应用程序即可。
界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的*作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。目前界面的设计引起软件设计人员的重视的程度还远远不够，直到最近网页制作的兴起，才受到专家的青睐。而且设计良好的界面由于需要具有艺术美的天赋而遭拒绝。
目前流行的界面风格有三种方式：多窗体、单窗体以及资源管理器风格，无论那种风格，以下规则是应该被重视的。
阅读全文…
检查清单（Checklist）可以帮测试人员节省时间，因为很多有效的方法并不需要每个测试人员重新发现，前人已经有了充分的总结，并做了大量的有效性验证，其次，检查清单可以帮助测试人员避免遗漏，人的记忆是有局限的，难免会有遗漏的地方，通过检查清单检查可以有效的防止遗漏。最近，IBM工程师***总结了Web软件测试中数据输入的检查清单，对Web测试人员提供了很好的参考。
主要从表格输入、数据验证、数据一致性、日期输入、数字输入、数字字符输入等方面归纳了Web测试中需要检查的要点。
阅读全文…
负载测试是一种性能测试，指数据在超负荷环境中运行，程序是否能够承担。通过逐步增加系统负载，确定在满足性能指标的情况下，系统所能承受的最大负载量。
很久没有做接手项目性能方面的测试，感觉陌生了许多，由于这次一个简单的web页面的压力测试，突然觉得知识的积累不够深刻，不能学着学着就丢了，如何积累成为自己的才是最重要的，凡是最后忘记的了那只能说明还是认识和学习不深刻。性能测试一直都是测试行业的一个难点，更是重点，可能我们都想做好它，但是不见得都有信心做好它，性能测试是一个带着诸多非常不确定因素进行的，因为没有标准答案，只能靠综合技术能力来分析，当然经验是最重要的，所以就需要不断去探索、积累，甚至于周围的同事进行讨论，吸取多方的经验。
关于性能，我想大多数人对这个三个概念都很模糊，感觉都差不多。网上相关的说明确实很多，不过看完之后很容易忘记，而且真正做项目测试的时候还是分不清楚，这就是所谓不确定性。所以我想通过动手记录的方式来加深印象，至少还是需要深入理解才行。性能测试、压力测试和负载测试是我们最常接触的测试，关于这三种测试先来看看一个有趣的故事，可以帮助我们直观地去理解，故事描述得很形象，具体如下：
有一个农夫决定买一匹骡子，他认为这个骡子至少 得能扛动3袋大米，他才会决定买这匹骡子(这相当于用户提出的性能需求)。结果他来到农贸集市上，试了好几头骡子，都不合适，最后终于有一头骡子能够比较轻松的扛动这3袋大米，而且还潇洒的走了几步(这相当于于性能测试通过)。 然后农夫高高兴兴地牵着这头骡子回家，而且给它扛了4袋大米(相当于让系统超负荷运行)，因为他跑了太远才买到了这匹不可多得的骡子，他想看看它到底能有多强，所以农夫决定， 让这匹骡子就扛着这四袋大米走回家试试看，这匹骡子真的很厉害，刚开始的时候还一颠一跑的，可是后来实在路太远了，骡子越驮越费劲(在超负荷情况下检验系 统能正常运行多久，这相当于压力测试)，快到家的时候，已经是走两步歇一步了。终于到家了， 农夫非常自豪地叫出自己的老婆，说：”老婆子，快来看看，看我买到了一头多么厉害的骡子啊!”,老婆来后，农夫把他和骡子在一路上的经历都告诉了老太 婆，谁知这个老太婆却说：”你真蠢，这么大老远的路，也不让骡子驮着你，竟然和这头傻骡子一样走回来!”,农夫听了，觉得非常后悔，说：”那好吧，既然在 路上它没有驮我，那就让它现在补上，也算是对我的补偿。”,骡子还没有反应过来，就看那老农夫一个箭步，跳到了骡子背上(这相当于容量测试的极限点)，可怜的骡子，无论如何也不会想到，这狠心的农夫竟然在它走了这么久之后，不但没有帮 它卸掉身上的重担，更没有给它喝口水，竟然变本加厉的跳到了它那本已弯曲的背上。可怜的骡子啊，就这么一命呜乎了!就看见那个骡子、农夫和4袋麦子一起轰然倒地。(相当于已经到了系统的最大拐点，造成了系统瘫痪，无法使用，容量测试结束)。
阅读全文…
分享一下公司新项目的测试阶段流程，希望对各位同学有所帮助，让每个项目的测试阶段顺利愉快的度过，抛砖引玉。一般会分为一下几个阶段：
在项目提交测试前，项目会有之前测试需求时间预估，例如一周、两周。在项目组通过了策划、程序等所有人员的自测通过后（包括游戏主逻辑模块、游戏基本玩法操作、策划案需求检测、UI显示等），提交给测试人员进行冒烟测试。此测试阶段中，会向策划询问一些需求设计，需程序配合修改数值搭建测试环境、询问实现方式等。
冒烟测试需达到的标准应为项目本周期需实现的项目标准相统一。冒烟测试会对游戏在基本的主体玩法、分支逻辑、系统模块、交互上进行检验。有多数走不通或者游戏模块发现并未完成责视为不通过冒烟测试。游戏主体玩法符合需求，基本逻辑走通，系统模块完整可正常交互后将进行游戏的全功能测试。
阅读全文…
什么是软件性能测试？
一般来说，性能是一种指标，表明软件系统或构件对其及时性要求的符合程度：其次，性能是软件产品的一种特性，可以用时间来衡量。性能的及时性用响应时间来衡量。
响应时间是指应用系统从发出请求开始到客户端接收到所有数据所消耗的时间。
并发用户数指同一时刻与服务器进行数据交互的所有用户数量。
吞吐量是指单位时间内服务器处理客户请求的数量。
吞吐率是指单位时间内从服务器返回的字节数，也可以指单位时间内服务器处理客户提交的请求数。它是衡量网络性能的一个重要指标。
TPS表示服务器每秒处理的事物数，他是衡量系统处理能力的重要指标。
点击率是指每秒钟用户向服务器提交的HTTP数量。
小布老师视频:
测试工具概述，兼LoadRunner介绍 -1-4
http://www.boobooke.com/v/bbk1046
http://www.boobooke.com/v/bbk1046.zip
http://www.boobooke.com/v/bbk1047
http://www.boobooke.com/v/bbk1047.zip
http://www.boobooke.com/v/bbk1048
http://www.boobooke.com/v/bbk1048.zip
http://www.boobooke.com/v/bbk1055
http://www.boobooke.com/v/bbk1055.zip
也许我们想要寻找像伯牙与子期的那种高山流水般知音境界还有些遥远，但是就像文学创作者期待读者的共鸣那样，其实测试人员也一样需要找到类似这样的“共鸣”。
以我自己的亲身经历为例，话说前些日子在参与一个项目的测试过程中，我提的一条“bug”被开发人员置为了“invalid”，投身测试工作近3年，提出的bug无效可是头一次，于是仔细看了开发人员的评注，他说uc中没有明确该项需求，于是我兴师动众的拖着开发一起找来PD进行理论，可是万万没有想到PD认可了开发，他认为目前系统的实现可以满足他对产品的要求，而当时的我虽然强烈的表达了自己的意见，但是无奈孤掌难鸣，这个无效bug就这么留在了项目的缺陷库中。
阅读全文…
最新评论