• 空间首页
• 空间管理
• 51Testing软件测试网
• 站点论坛
• 添加我的日志

我的最新日志

• 北京上班后的感受

  2008-4-15

      经过前段时间的奋斗，工作终于搞定了，今天也是上班后的第2天了。新的环境，新的同事，一切都要重新开始，一切都需要自己重新去开始，心理上多少还有点不太适应，慢慢来吧，我想一切都会好起来的。

      不过过段时间要对目前的软件系统进行性能测试，先前没怎么搞过这，有点压力呀，现在在奋力的学习中。。。

  查看(34) 评论(0)

• 新的开始，新的挑战

  2008-3-18

      最近由于个人原因不得不离开已经奋斗了8年的西安，离开现在的公司了，离开自己熟悉的环境，心情是异常的乱、矛盾，之前就没怎么写过日志，现在补上就算是对自己前面的一个总结吧。

      回想起自己的工作历程，也是充满了坎坷的。04年毕业为了找工作真是费了很大的劲哦，但是接下来就很顺利了，基本上都是一次搞定，尤其是现在这个单位，1小时拿到offer，工作中上下领导也很是照顾我，所以当初张口说辞职，老是过不去心理上的坎，但是反过来想想，假如自己有一天不能胜任现在的工作了，公司肯定会毫不留情的换人，所以心理上的压力也就慢慢的减轻了许多。关于测试呢，我从最初的开发转到后来的测试，从最初的软件测试员到现在的高级软件测试工程师，一路走的也倒是很顺利。刚进门的时候倒是觉得很是简单，可是慢慢的往后走，就越发觉自己的知识很是欠缺，在测试行业也打拼了将近快3年的时候了，自己的测试水平也在慢慢的成长，可是离高水平的阶段还相差很远，还需继续努力啊！

      矛盾的另一方面就是，北京对我来说是一个全新的环境，虽然那里有我很的朋友，可是工作了这几年下来，自己的那种闯劲好像退化了似的，自己也知道去北京了发展的机会肯定会比现在大的多，可是竞争的压力也会大很多，对自己去了后的前景不能很有把握的掌控，不过为了自己以后能有个更好的发展方向，还是打起精神来，振作起来，勇敢的面对即将到来的挑战，我坚信自己一定是胜利者中的一员的。。。。08年我会有个好的开始的，加油！

   

  查看(30) 评论(0)

• 改变人生的32句励志名言

  2007-9-26

  1.大多数人想要改造这个世界，但却罕有人想改造自己。

  2、积极的人在每一次忧患中都看到一个机会， 而消极的人则在每个机会都看到某种忧患。

  3、莫找借口失败，只找理由成功。(不为失败找理由，要为成功找方法)

  4、伟人之所以伟大，是因为他与别人共处逆境时，别人失去了信心，他却下决心实现自己的目标。

  5、世上没有绝望的处境，只有对处境绝望的人。

  6、当你感到悲哀痛苦时，最好是去学些什么东西。学习会使你永远立于不败之地。

  7、世界上那些最容易的事情中，拖延时间最不费力。

  8、人之所以能，是相信能。

  9、一个有信念者所开发出的力量，大于99个只有兴趣者。

  10、每一发奋努力的背后，必有加倍的赏赐。

  11、人生伟业的建立 ，不在能知，乃在能行。

  12、任何的限制，都是从自己的内心开始的。

  13、含泪播种的人一定能含笑收获。

  14、欲望以提升热忱，毅力以磨平高山。

  15、一个能从别人的观念来看事情，能了解别人心灵活动的人永远不必为自己的前途担心。

  16、一个人最大的破产是绝望，最大的资产是希望。

  17、不要等待机会，而要创造机会。

  18、如果寒暄只是打个招呼就了事的话，那与猴子的呼叫声有什么不同呢？ 事实上，正确的寒暄必须在短短一句话中明显地表露出你对他的关怀。

  19、昨晚多几分钟的准备，今天少几小时的麻烦。

  20、做对的事情比把事情做对重要。

  21、人格的完善是本，财富的确立是末。

  22、没有一种不通过蔑视、忍受和奋斗就可以征服的命运。

  23、行动是治愈恐惧的良药，而犹豫、拖延将不断滋养恐惧。

  24、没有天生的信心，只有不断培养的信心。

  25、只有一条路不能选择——那就是放弃的路；只有一条路不能拒绝——那就是成长的路。

  26、人性最可怜的就是：我们总是梦想着天边的一座奇妙的玫瑰园，而不去欣赏今天就开在我们窗口的玫瑰。

  27、征服畏惧、建立自信的最快最确实的方法，就是去做你害怕的事，直到你获得成功的经

  验。

  28、失败是什么？没有什么，只是更走近成功一步；成功是什么？就是走过了所有通向失败的路，只剩下一条路，那就是成功的路。

  29、让我们将事前的忧虑，换为事前的思考和计划吧！

  30、再长的路，一步步也能走完，再短的路，不迈开双脚也无法到达。

  31、任何业绩的质变都来自于量变的积累。

  32、成功不是将来才有的，而是从决定去做的那一刻起，持续累积而成。

   

  转载自：http://www.51testing.com/?29251/action_viewspace_itemid_17224.html

  查看(40) 评论(0)

• 如何避免遗漏bug

  2007-9-07

           bug遗漏，我想这个是很多公司很多人头痛的一个问题。众所周知，bug是不可能被完全消灭的，当然也就意味着在发布前不能被全部找出来。于是乎当项目发布后，或多或少都会出现bug遗漏的现象，即使发布初期没有发现，随着时间的流逝，一些隐藏的bug也会慢慢浮现出来。那么对于遗漏的bug，我们该怎么去做？

          古时云：亡羊补牢，为时未晚也。对于遗漏的bug，我们应该去透彻的分析它产生的原因，然后吸取教训，防止再次出现。这样遗漏bug的数量就会越来越少，趋于0。那么怎样的分析才是透彻的呢？我发表一下自己的观点。

          根据我的经验，总结下来有以下几点，首先从根源上说，需求的问题。需求是一切的根本，我们所做的一切都是在需求的基础上进行的，那么需求会不会有问题？当然有啦，否则要需求评审干嘛，每次需求评审，或多或少都能发现一些需求的问题，在还没有开始编码之前就把需求的bug找出来，这个是最理想的状态。显然这个不现实，但是能多发现一个不合理的地方，那就能减少很多风险。因此需求关要把好。当然要求测试人员在需求评审时就要找出需求的bug，这个是要求比较高的，需要对业务的熟悉以及对相似产品的认识。需求关把好了，那么就算踏出了成功的第一步。

          其次，要尽早与开发人员进行测试设计评审，统一对需求的认识（开发测试人员都可能存在对需求的认识不正确）。越早进行，越能够避免出现因为对需求的认识不同而导致出现的问题（最可怕的是因此产生的隐性bug），这样也能减少后期很多不必要的资源浪费。

          接下来，就是用例设计了，这方面体现了一个测试人员的真实地能力。考虑的面要广，包括:使用不同的测试方案，不同的测试数据的类型（要齐全），正常流与异常流等来覆盖所有的需求。

          然后就开始执行测试，要全面地执行测试用例，并且在测试过程中不断的添加遗漏的用例。在时间允许下，尽可能的执行。

          回归阶段，除了要回归前面发现的bug，还要重视回归那些bug相关的模块，这个教训是很多的，所以千万不能忽视。一个小小的小小的参数变动可能引起一个比较远的功能点的大bug，继而引发遗漏。所以这个是需要开发人员与测试人员去识别的。开发人员熟知代码，知道改动的地方会被哪些模块调用或者会引起哪些变化，因此开发人员需要通知测试人员测试关注点以及加强自测。在开发人员与测试人员无间隔的合作下，这种bug的遗漏会减少很多。

          发布前期，应该在保证所有的bug都fixed的前提下，把所有用例都回归一下，以免遗漏。

          最后终于发布了，发布好就可去FB了，^o^。不要在开心的情况下放松神经，所谓行百里，半九十，不能倒在最后的冲刺关头。细心细心再细心。只要一步步走下来，那么就可以把遗漏的bug数量减到最低。

          当然最好做自动化脚本，方便以后的回归。这就是我想说的，大家有意见可以跟着，共同进步。

  查看(55) 评论(0)

• VSTS For Testers读书笔记(26)

  2007-8-06

  一、顺序测试

  ²顺序测试包含要以特定顺序运行的其他测试

  ²顺序测试可包含除负载测试之外的任何测试类型。但是，如果远程运行顺序测试或从命令行运行顺序测试，则对于此测试运行，将临时从该顺序测试中移除其中包含的所有手动测试，并显示一个警告对话框。

   

  可以将同一个测试多次添加到相同的顺序测试中。进行了多次添加后，测试将按照列出的顺序多次运行（它在顺序列表中出现了多少次就运行多少次）。

  选中“失败后继续”表示无论是否有测试失败，顺序测试都将运行。不选中“失败后继续”表示在首次发生测试失败后，顺序测试将停止运行。

  查看(76) 评论(0)

• VSTS For Testers读书笔记(25)

  2007-8-06

  一、概述

  ²可以使用一般测试来包装旧式测试和其他外部程序。在执行了此操作后，测试引擎将一般测试视为任何其他测试类型

  ²使用一般测试来包装可从命令行运行并返回 Pass 或 Fail 值的现有测试、程序或第三方工具

  ²一般测试是 Team Edition for Testers 的一种简单形式的扩展；它们允许您运行除预定义测试类型（包括 Web 测试、负载测试、单元测试、手动测试和顺序测试）以外的其他测试，如以前的测试和自定义测试。

  ²传递命令行参数

  可以向一般测试所包装的程序传递命令行参数

  ²部署其他文件

  如果一般测试在运行时需要其他支持文件，可以在运行测试之前先部署这些文件

  ²使用摘要结果文件

  该机制可使您的测试报告具体、详细的测试结果

  远程运行一般测试时，如果使用摘要结果文件，将无法立即查看结果。对于一般测试，必须先运行完测试运行中的所有测试，才能查看测试结果，即使一般测试本身早已完成也是如此。

  二、创建一般测试

  ²在“指定要包装为一般测试的现有程序(测试、测试工具或测试适配器)”下指示要包装为一般测试的测试、程序或第三方工具的路径和文件名

  ²在“传递给一般测试的命令行参数”下键入一个或多个要传递的参数。请用空格分隔多个参数

  ²在“要与一般测试一起部署的其他文件”下指定测试正确运行所必需的所有文件

  ²在“工作目录”下指定可执行文件运行时作为要工作目录使用的目录

  ²指定结果文件的名称

  ²测试将返回 0 或其他数字。测试引擎将 0 解释为“已通过”，其他数字则解释为“已失败”。

   

  EvenOddDemo下载

  命令行参数

  ²对于简单的可以使用单一参数

   

  ²多个参数使用空格分隔

  

  环境变量

  在下面区域中使用环境变量来显示路径

  ²目标执行

  ²命令行参数

  ²摘要结果文件位置

  ²部署项  

  ²可以使用任何系统定制或自定义的环境变量，比如SystemDrive,ProgramFiles和UserProfile。

  ²特别有用的变量是ComSpec。ComSpec是CMD命令的全名，可以使用ComSpec来运行例如.Bat后缀的命令提示脚本

  ²环境变量不区分大小写

  ²默认情况下，未定义的环境变量扩展成空字符串，例如，如果你在一般测试中指定%MyExecutableDir%MyExecutable.exe ，但MyExecutableDir 没有定义，测试引擎认为这个字符串为 MyExecutable.exe ，并且试图在部署目录中运行它。前提是MyExecutable.exe已经部署

  ²你可以使用一个环境变量来控制测试引擎运行测试的文件夹。例如，如果你设置MyExecutableDir 目录为E:\builds\drop\...\Bin\，那测试引擎试图在这个位置运行文件，这个对于不能移动的测试很有用，这个非常适合测试存放在源代码管理中

  

  三、收集代码覆盖率

  与手动测试一样，通过LoadTest Config配置中选择代码覆盖配置，见手动测试

  四、创建和使用摘要结果文件

  ²通过使用摘要结果文件，一般测试可以生成特定的详细测试结果

  ²摘要结果文件是 XML 文件，符合特定的 XML 架构

  ²步骤

  Ø使用XSD工具，目的是要使用选择的语言使 xsd 实用工具输出一个包含特定参数和属性的类

   

  Ø编辑要包装为一般测试的程序，使用 xsd 生成的类向一般测试的类中添加参数和属性

  Ø创建一般测试本身来包装现有程序，在一般测试中的“结果设置”之下单击“摘要结果文件”，并指定要放置摘要结果文件的文件夹的路径。

  

  结果文件示例

  ²<?xml version="1.0" encoding="utf-8" ?>

  ²<SummaryResult>

  ² <TestName>ParentTest</TestName>

  ² <TestResult>Passed</TestResult>

  ² <InnerTests>

  ² <InnerTest>

  ² <TestName>InnerTest1</TestName>

  ² <TestResult>Passed</TestResult>

  ² <ErrorMessage>Everything is fine.</ErrorMessage>

  ²<DetailedResultsFile>D:\Documents and Settings\Results.txt</DetailedResultsFile>

  ² </InnerTest>

  ² <InnerTest>

  ² <TestName>InnerTest2</TestName>

  ² <TestResult>Failed</TestResult>

  ² <ErrorMessage>Something went wrong.</ErrorMessage>

  ² <DetailedResultsFile>D:\Documents and Settings\Results.txt</DetailedResultsFile>

  ² </InnerTest>

  ² </InnerTests>

  ²</SummaryResult>

  五、运行一般测试

  ²测试视图，选择一般测试

  ²测试管理器，选择一般测试

  ²测试结果

  当一般测试包装的可执行程序返回值 0 时，表示测试通过，如果返回任何其他值，则表示测试失败。

  

  

  查看(53) 评论(0)

• VSTS For Testers读书笔记(23)

  2007-8-06

  九、参考文档

  —MSDN: 中文——http://msdn2.microsoft.com/zh-cn/library/ms182409(VS.80).aspx

  英文——http://msdn2.microsoft.com/en-us/library/ms182409(VS.80).aspx，推荐看英文的，因为中文的翻译不全，又是翻译机翻的

  —Troubleshooting Load Tests

  http://msdn2.microsoft.com/en-us/library/ms404661(VS.80).aspx

  —Bill Barnett's blog

  http://blogs.msdn.com/billbar/

  —Ed Glas's blog

  http://blogs.msdn.com/edglas/

  —Sean Lumley's Blog

  http://blogs.msdn.com/slumley/

  查看(58) 评论(0)

• VSTS For Testers读书笔记(22)

  2007-8-06

  八、监视与分析

  —监视器和分析器

  —关系图

  —表

  —错误与阈值

  —SQL跟踪

  —分析错误

  —创建插件

  监视器和分析器

  —监视器用来实时查看负载测试结果

  —分析器用于检查已经保存的所有负载测试结果

   

  —分析前提，设置了负载测试结果存储区

   

  嵌入的状态栏显示测试状态以及错误或阈值冲突的总数。

  使用“计数器”窗格中的树结构来快速查看各种性能计数器或各个计算机。

  —计数器

  显示已添加到负载测试中的性能计数器

  —关系图

  显示关系图上来自运行期间收集到的数据的绘制点

  —点

  “关系图”窗格的一部分。显示当前关系图中使用的数据。

  —摘要

  显示从运行中得来的摘要数据。

  —表

  显示一组包含运行数据的表，例如“错误”表和“阈值”表。在分析器中可以查看 SQL 跟踪数据。

  关系图

   

  图形化计数器的图例显示一些有用的数据列

  默认关系图（显示用户负载、吞吐量和响应时间）

  表
   

  —表选项:

  错误

  显示在运行期间创建的错误列表。

  页

  显示在运行中使用的页列表。

  请求

  显示在运行期间发送的所有 HTTP 请求。其中包括从属请求，如图像。

  测试

  显示负载测试中使用的测试列表。

  阈值

  显示运行期间超过的阈值的列表。

  事务

  显示运行中的事务列表。

  SQL 跟踪

  只有在使用 SQL 跟踪时，才可在运行后的分析器中看到该选项。

  代理

  只有在包含多个代理的 rig 上运行测试时，才可看到该选项。

  

  错误与阈值

  —错误和阈值计数在嵌入的状态栏上显示为链接。

  —单击其中一个链接便会激活相应的表：“错误”表或“阈值”表。

  计数器树显示了阈值冲突。如果当前的采样间隔内发生了阈值冲突，则除了节点名称外，您还会看到一个红色的符号或一个黄色的符号。在运行持续期间，这些符号将保留，但当不再超出阈值时，这些符号就会灰显。

  阈值网格显示了前 1,000 个阈值冲突，包括发生冲突的时间。

  可以找到一个超出阈值的计数器，并通过把符号拖动到关系图上的方式来绘制该计数器。

  警告：

  

  错误：

  

  阈值

  —在负载测试中显示阈值冲突时，可以在两种阈值规则中进行选择：

  Ø比较常数

  将性能计数器的值与一个常数值进行比较。

  Ø比较计数器

  将一个性能计数器的值与另一个性能计数器的值进行比较。

  可以设置一个“警告阈值”级别，当达到该警告级别时，负载测试监视器和分析器中便会出现一个指示此警告的黄色符号。

  可以设置一个“关键阈值”级别，当达到该警告级别时，负载测试监视器和分析器中便会出现一个指示此警告的红色符号。

  比较计数器属性设置：临界阈值和警告阈值

  

  新建比较常数

  

  新建比较计数器

  

  SQL跟踪

  —通过收集跟踪数据，可以识别出在所测试的 SQL 数据库中运行速度最慢的查询和存储过程。

  —单击“表”按钮。从“表”列表框中选择“SQL 跟踪”。

  —通常，“持续时间”列是第一个要检查的列。此列中收集的数据的单位为毫秒。

  —SQL 跟踪面板将列出运行速度最慢的 SQL 操作，并根据持续时间按照最慢的操作放在最上面的方式来排序。

   

  —此面板上可以显示的 SQL 跟踪输出中的数据列：

  Ø事件类

  Ø持续时间

  ØCPU

  Ø读取

  Ø写入

  Ø文本数据

  Ø开始时间

  Ø结束时间

  Ø主机名

  Ø应用程序名

  Ø登录名

  ØNT 用户名

   

  

  如果需要跟踪 SQL 事件而不是跟踪在这些列中标识出的数据，则必须使用与 Visual Studio Team Edition for Testers 分开提供的 SQL Profiler 工具设置自己的自定义 SQL 跟踪。

  

  分析错误

  —提供了两种查看错误的方式：关系图和表

  —Demo

  —Example：Could not find dependent counter needed to apply threshold rule

  —Example：The load test results database could not be opened.

  解决参考：

  http://msdn2.microsoft.com/en-us/vstudio/aa718685.aspx

  创建插件

  —负载测试提供了API，Microsoft.VisualStudio.TestTools.LoadTesting

  —可以使用API创建负载测试插件

  —Demo

  using System;

  using Microsoft.VisualStudio.TestTools.LoadTesting;

  using System.Net.Mail;

  using System.Windows.Forms;

  namespace DataDrivenUnitTest

  {

  public class MyLoadTestPlugin : ILoadTestPlugin

  {

  LoadTest myLoadTest;

  public void Initialize(LoadTest loadTest)

  {

  myLoadTest = loadTest;

  myLoadTest.LoadTestFinished += new

  EventHandler(myLoadTest_LoadTestFinished);

  }

  void myLoadTest_LoadTestFinished(object sender, EventArgs e)

  {

  try

  {

  // place custom code here

  MailAddress MyAddress = new

  MailAddress("someone@example.com");

  MailMessage MyMail = new MailMessage(MyAddress, MyAddress);

  MyMail.Subject = "Load Test Finished -- Admin Email";

  MyMail.Body = ((LoadTest)sender).Name + " has finished.";

  SmtpClient MySmtpClient = new

  SmtpClient("localhost");

  MySmtpClient.Send(MyMail);

  }

  catch (SmtpException ex)

  {

  MessageBox.Show(ex.InnerException.Message +

  ".\r\nMake sure you have a valid SMTP.");

  }

  }

  }

  }

  —有八种事件与负载测试相关联，且可在负载测试插件中进行处理，以使用负载测试运行自定义代码。以下是事件的列表，这些事件提供对负载测试运行的不同时间段的访问：

  ØLoadTestStarting

  ØLoadTestFinished

  ØLoadTestWarmupComplete

  ØTestStarting

  ØTestFinished

  ØThresholdExceeded

  ØHeartBeat

  ØLoadTestAborted

  Demo下载

  查看(75) 评论(0)

• VSTS For Testers读书笔记(21)

  2007-8-06

  七、运行LoadTest

  —负载测试可从三个位置运行

  Ø“测试视图”窗口

  Ø“测试管理器”窗口

  Ø负载测试编辑器

  —从命令行运行负载测试

  mstest /testcontainer:LoadTest1.loadtest

  —使用代理运行负载测试

  通过远程控制器来运行代理机上的负载测试

  

  查看(58) 评论(0)

• VSTS For Testers读书笔记(20)

  2007-8-06

  六、创建和编辑LoadTest

  1、创建LoadTest

  新建一个负载测试是通过负载测试向导来完成的

  

  方案

  —负载测试包含一个或多个方案，用于对用户组与服务器应用程序交互的方式进行建模

  —单个方案由负载模式、测试组合、浏览器组合和网络组合组成

  —其中的每个设置均与“负载测试向导”中的一个页面对应

  —负载测试可包含 Web 测试和单元测试

  

  负载模式

  —负载模式指定在负载测试期间活动的虚拟用户数以及启动新用户的速率

  —每个负载模式在负载测试中都有不同的目标，必须确定如何实现特定方案的测试目标

  

  测试组合

  —“测试组合”用于指定虚拟用户运行负载测试方案中的给定测试的概率

  —测试均选自现有 Web 测试和单元测试

  

  浏览器组合

  —浏览器组合指定虚拟用户运行给定浏览器配置文件的概率

  —浏览器组合应反映特定方案的测试目标

  

  网络组合

  —“网络组合”指定虚拟用户运行指定网络配置文件的概率

  

  计数器集

  —计数器集是可用于在负载测试过程中进行监视的一组系统性能计数器

  —计数器集按不同技术划分，例如 ASP.NET 计数器集或 SQL 计数器集

  

  运行设置

  —“运行设置”是一组影响负载测试方案的属性

  —运行设置和计数器集类似，应用于负载测试中的所有方案，而非单个方案

  —运行设置可决定测试的长度、预热持续时间、报告错误的最大数量、采样速率、连接模型（仅适用于 Web 测试）、结果存储类型、验证级别和 SQL 跟踪

  

  最后完成一个LoadTest文件建立

  

  —每个设置都可以在其属性中进行修改值来编辑

  2、编辑LoadTest

  LoadTest文件属性：

  

  这里有个负载测试的插件设置，在后面会介绍到

  方案属性：

  

  某个具体计数器的属性：

  

  这个设置比较重要，在后面运行测试后，排除错误或警告往往需要这个设置

  运行设置属性：

  

  查看(66) 评论(0)

我的主题

• (急)loadrunner录制上传文件回放增加的数
• 关于破解版LR录制socket脚本不能跑场景的
• 测试结束，服务器端口不释放问题如何解决？
• 哪位去过北京迈思奇面试过，进来说说情况
• 请问：脚本运行出现-26612错误，该如何解
• 求助：LR不能生成脚本的问题，急！（已解
• 并发运行脚本时出错，请大侠们帮帮忙！
• 想去北京发展，请北京的测试同行进来评价
• 关于测试人员的发散思维和逆向思维
• 太文信息技术有限公司（新蛋）