发布新日志

  • QA是如何体现价值的（测试人生系列之四）

    2012-08-01 16:02:07

    作为一个软件测试人员，如何才能体验出自己的价值呢？

    首先，我们要明白什么叫做软件测试人员的价值。

    从经济学来讲，价值，是凝结在商品中的无差别的人类劳动。从测试人员来说，我们可以狭义的理解，价值就是我们凝结在在软件产品中的测试活动。所以，软件测试人员的价值，可以直接由产品的质量体现。

    而反映出一个软件测试人员的价值，就是你给产品的质量带来了多少正向的收益。

    从统计学角度，一个软件测试人员的价值可以由如下统计数据反映：开发测试用例的数量，执行测试用例的数量，发现缺陷的数量等等。

    从逻辑学角度，可以由以下作为参考：负责功能区域的优先级，测试用例的结构性，缺陷的深度和广度等等。

    从行为学角度，可以参考：任务优先级的安排，测试用例执行的顺序，缺陷跟踪的过程等等。

    从社会学角度，可以参考：对用户真实需求的贴合度，用户体验的反馈，与其他角色的交流效率等等。


    总之，一个软件测试人员的价值体现是由多个因素构成的。所以，如果想做一个高价值的测试人员，不光光是从技术角度等等方面单纯的考虑。一个好的技术人员，只是作为一个高价值的测试人员的必要条件，不是充分条件。所以对于很多单纯的想通过掌握很多测试工具来体现自己价值的从业人员来说，这是一个美丽的陷阱。

    所谓德智体美劳全面发展，如何让人把你认可为一个高价值的测试人员呢？

    个人认为主要是从如下三个方面体现：

    第一，个人能力。个人的能力包括了你的技术力，经验力，创新力，交流力等等，作为必要的条件存在。

    如何衡量你的个人能力呢？说实话，很难有个简单有效的方法。但是，有些公认的方法都可以实现。比如说，测试用例的质量，组织，结构和逻辑都很好。发现的缺陷都是直达源头。总之，个人能力好，就是大家对你的工作很放心，拥有很高的信任感。

    第二，团队能力。不怕老虎一样的敌人，就怕猪一样的队友。可是，作为团队的成员，如果你只是不停抱怨你身边的队友如何拖后腿，那么你缺乏最起码的团队精神。作为一个优秀的团队成员，你的作用不仅仅是完成自己的工作，而且要和全体成员一起达到团队成就。让每个团队中的人，能够发挥出自己的长处，避免自己的短处，鼓励激励。这不是一个团队领导自己能完成的任务，靠的是团队中的每一个人。你要做的是，让你的团队能力把你的团队推向更好。

    第三，管理能力。有句老俗话，中国人个个都是龙，凑一起就是虫。不过，这很少是因为你缺乏团队能力。而是缺乏管理能力。管理，有个人的自我管理，有任务的效率管理，有团队的执行管理等等。每个人都处于自我管理和参与团队管理和监督管理中，这样的团队，才是个有核心的团队，你才是个高价值的成员。

    其实，还有另外一种说法：

    第一，你对自己的认成度。第二，你对对团的认成度。第三，你对产品的认成度。


    综合来讲，我们作为从业人员，拿工资，干活，就是参与了价值的创造，剩余价值的剥夺和交换过程。对老板来说，你能创造比别人多的剩余价值，就是高价值的。 可是，对于每个人来说，追求自己高价值的认同，不仅仅是为了物质利益，也同时是满足自己的精神追求。

    如果你连最起码的精神追求都没有，那就谈不上什么精神愉悦感，更谈不上什么人生理想，纯粹是机械的为了生存而生存着。那你何必还去追寻如何作为一个有价值的测试人员呢。你已经抛弃了自己，不需要别人再来否定你了。

    查看(615) 评论(1) 收藏 分享 管理

  • 如何衡量一个QA（测试人生系列之三）

    2012-07-26 15:02:49

    最近在做performance review，很多人都只是简单的针对分数去争辩，都不在意为什么要做这个performance
    review了。

    实际上，在列出的指标中，能很好说明衡量一个QA的标准：

    Adaptability and Change Management Skills

    这一条，做一个合格的测试人员，就是能够接受频繁的任务转换。每个测试人员都是在不停的切换于不同的任务中。正常的，就是能够正常切换自己分配的任务。良好的测试人员，就是不光能够合理的切换，而且能加入自己的经验进行更高效率的切换。优秀的测试人员，不但能够更有效率的切换，还会对切换的需求进行分析，了解切换的原始目的，从而能够对切换的指令进行有效的回馈。

    Attendance and Punctuality

    一般来说，能够按时的参加各种会议，讨论和活动就是ok的。好一点的，会提前了解一下内容。更好点的，会不但了解内容，还会思考自己参加的意义，并提出自己的意见。

    Communication and Cooperation 

    能够交流和协作，这是必须的。能够作为发起人进行主动交流和协作，就是良好的。能够进行主动的进行高质量的交流和协作，并对整个过程进行掌控，就是优秀的。

    Initiative & Motivation

    能够主动去做一些份外的事，就是正常的。能够主动的去做，并且能够带来更有益的改进，就是良好的。主动做的事，能够带动team整体进行，就是优秀的。 

    Job Knowledge

    能够对自己工作的内容完全掌握，就是正常的。能够对整个项目熟悉，是良好的。能够主动的运用知识对项目进行有益的补充，就是优秀的。

    Judgment and Decision Making 

    能够对自己的工作内容进行合理的决定，就是正常的。能够对自己的决定给整个team带来的影响进行评估和管理，就是良好的。能够对自己的决定给整个项目带来的影响进行评估和管理，就是优秀的。

    Organization and Planning Skills 

    能够对自己的任务进行管理和计划，就是正常的。能够根据项目情况调整自己的管理和计划，就是良好的。能够根据自己的管理和计划对项目带来有益的补充，就是优秀的。

    Problem Solving Skills and Results Orientation 

    能够解决问题，就是正常的。能够够解决问题，并进行问题跟踪，分析和反馈就是良好的。能够解决问题，并引入风险管理，就是优秀的。 

    Quality

    能够保证工作的质量，就是正常的。能够提高team的质量，就是良好的。能够改善项目的整体质量，就是优秀的。 

    Reliability and Accountability

    能够被信任，就是正常的。能够被期望，就是良好的。能够被盼望，就是优秀的。

    Team-work and Inter-personal Skills 

    不做team的短板，就是正常的。帮助team的短板，就是良好的。team没有短板，就是优秀的。

    Technical Skills 

    项目的技术熟悉，就是正常的。能成功引入外部技术，是良好的。能够推动技术的潮流，就是优秀的。

    Information and Behavior.  

    提供最够的信息让外部识别，是正常的。拥有公司内部的知名度，是良好的。业界著名，就是优秀的。

    English Ability

    能够满足需要，就是正常的。能够去争论，就是良好的。能够去开讲论谈，就是优秀的。

    Goal and Objective Setting 

    能够制定个人目标，就是正常的。能够制定team共同目标，就是良好的。被所有人当作目标来追赶，就是优秀的。

    Leadership 

    能够当好leader，就是正常的。能够培养新的leader就是良好的。能够被人当作标杆，就是优秀的。

    Staff Development 

    管好项目的人，就是正常的。能够打成一片，就是良好的。能够被人信赖，就是优秀的。

    Responsibility

    做到职任所在，就是正常的。能够培养出有职业精神的团队，就是良好的。能够培养出有灵魂的团队，就是优秀的。

    查看(693) 评论(2) 收藏 分享 管理

  • 我们为什么用bugzilla

    2012-07-19 21:10:01

    bugzilla作为测试人员最常见的测试工具，被所有人熟悉和使用着。

    可是，bugzilla究竟给我们带来了些什么呢？

    第一，bugzilla给了测试人员话语权。我们通过它，作为一个平等互利的角色向开发人员，官方的，正式的发出我们的成果宣言：一个bug。

    第二，bugzilla给了测试人员平等权。测试人员不再是开发人员的帮手，大家是从不同的视图来看待一个产品的质量。 bugzilla是作为开发人员和测试人员交流的平台。 同时，这个交流平台也连接了项目管理，过程管理，需求人员，设计人员，销售人员，技术支持人员，和最终客户，是大家能有一个平台去交换各自的想法。

    第三，bugzilla使得测试人员能使用一个标准化的对象去进行信息内容的沟通。

    第四，bugzilla使得测试人员能够更加迅速的了解产品的当前质量状态，从而调整各种计划和工作。

    第五，bugzilla使得测试人员能够积极的参与到产品的管理过程中，对整个产品的管理提供更多的技术细节和过程参数。


    对于如何使用bugzilla进行项目管理，我们不妨举几个例子：

    例子一：我们在测试过程中，经常会遇到这种现象，就是一个模块会突然爆发出很多bug来。难道bug就真的那么多吗，其实很多时候，是因为开发人员在修改一个bug时，引起其他已经修复的bug被reopen或者导致更多的新bug。

    我们如果有一个机制，去监控 最近3天内，新加的bug的原因。那么，这种问题就能够作为一个风险进入我们的风险管理过程。如果有相应的风险管理，那么就执行。如果没有，就需要加入。并且，根据实际情况，我们来判断，还有多少潜藏的bug会以这种方式出现。


    例子二，我们在做测试计划的时候，很难说我们的测试各个阶段都能够很详细的制定出内容来。比如回归测试，到底哪些东西要做回归测试呢，什么样的频度，什么样的深度？

    我们可以在功能测试结束前的2周，就对现有的bug进行分析，依据bug的在各个模块的分布数量，优先级的加权等，来确定哪些需要重点进行回归，那些可以忽略。从而对各个模块的功能测试用例进行筛检，从而得到回归测试需要执行的规模和频度。

    例子三，当一个产品被release之后，或者一个sprint结束之后，我们也可以对bug进行分析，通过bugzilla自带的很多图表，我们能够对上个阶段的产品质量有一个很直接的可视化分析，然后写出QA角度的分析报告来，提供给管理层和开发团队作为参考，从而在下一个阶段中能够更好的提高质量和效率。甚至，可以以QA的视角，去管理下个阶段的开发过程和质量保证过程。

    总之，bugzilla不是仅仅作为我们QA跟开发交流的工具，还可以作为测试驱动开发的工具，可以作为产品质量衡量的工具。

    查看(1729) 评论(1) 收藏 分享 管理

  • Road to Revolution （测试人生之二）

    2012-07-19 20:40:12

    最近开QA Forum，发现大家越来越急切的想通过学习一种自动化工具来摆脱所谓的低级测试人员的帽子，从而能找一份更好的工作。

    我不禁想起前段时间跟朋友讨论的什么是企业文化。

    企业文化，就是你为什么想进入这个公司，你想在这个公司获得什么，你想在离开这个公司的时候有什么变化。为什么大家都想进入500强，张口闭口他们的企业文化好，无非就是高薪，高福利，工作压力小，适合养老。 呵呵。

    对一个发展中的中小企业，尤其是一个处于瓶颈期的企业，其实更需要企业文化来拯救自己。企业文化，其实就是一个企业的独特魅力，也是这个企业赖以生存的核心竞争力。

    一个没有文化的企业，压根就没有什么凝聚力，更谈不上什么团队。大家都是在混吃等死，完全看不到自己个人的职业方向，要么就是赶紧学点什么高精尖的技术，跳槽走人，要么就是得过且过，那天面到一个合适的就撤。

    一个有文化的企业，就是流氓会武术，谁也挡不住，再念几句经，皇帝也保护。

    但是，企业很难去形成自己的文化，为什么呢？缺乏改革的动力，没有想法，没有信心去改变，高层混吃等死的想法，比下边干活的人想的还多。反正公司倒了，我再换个公司去当高管。

    如此下去，就是典型的2年之内从10个人的小公司到500人的中型公司，然后大家就开始吃老本，3，5年内被打回原形。

    企业之道，就在于你需要跟随市场的需要不断进化。诺基亚如此，当年的通用也是如此。当高管们桎梏了企业的发展，我们就需要一场revolution。


    而测试人员来说，他的职业之路，其实就是一条revolution之路。 测试的最高境界，就是你从客户的角度来使用一个产品，也就是现在吵闹最多的用户体验决定产品质量。而用户的体验，就是随着时代不断变化中，你如果想在这条路上走的更好，不要去顾及太多的技术，去迎合那些软件开发公司的短期需求，你需要的是站在一个不断被新的应用调高胃口的客户的角度去考虑你的测试方向。更新更好更廉价，就是最好的产品。 所以一个好的测试人员，只需要去掌握趋势，不需要去深入到过多的技术细节，我们要无招胜有招，把所有的招数都忘记了，测试必然大成。

    查看(740) 评论(0) 收藏 分享 管理

  • 我们是谁？（测试人生系列之一）

    2012-07-10 21:40:51

    前几天跟朋友聊天，说你们测试人员现在不好混吧，技术含量低，人员过剩。呵呵，表面上敷衍过去，回来沉思，想到我们测试到底是什么一个状态呢。

    Who am I？

    一般来说，软件行业的测试人员主要是进行一些保障产品质量的活动。有的地方叫tester，和coder相对应。有的地方叫QE，意思是质量工程师（Quality Engineer）。 有的叫QA。 这个QA一般有两种说法，一个是Quality Assure， 意识是质量保障工程师。不但包含对软件产品质量的保障这层意思，很多公司还有专门的QA这个职位，用来对产品质量过程进行控制，例如CMMI体系，就有专门的人去审核测试团队在对某个产品进行质量保障的时候，其采用的流程，方法等等是否符合标准。 有的公司称QA为Quality Analyst，意为质量分析工程师。其实我个人更喜欢这个称呼，更加小资一些，像个文艺青年值得干的活。

    总而言之，测试人员的具体工作就是保障软件的质量。一般面试的时候，我也喜欢问这个问题，很多人都能说到这层意思。但是对于一个文艺青年来说，这点似乎有点太庸俗化。我们更喜欢说，我们是保障最终用户能够得到满足他们真实需求的软件。

    其实，很多开发人员看不起测试人员，就如同我们对中关村攒电脑的也自称自己是it人一样鄙视。实际上呢，测试和开发来说，都是软件工程中的一个角色而已。

    在软件工程这个词还没被发明前， 所谓的软件或者计算机行业，都是给数学专业大牛们打下手的。 我接触过最早的软件从业人员，任务就是帮助学校的老教授打孔，然后放到一个史前级别的科学计算器（也就是一般意义的电脑的前辈），去计算。 就是高级的计算器。

    后来，真正引导软件行业走向工程化的，应该是Nasa的功劳。每个入行的人应该都学过，当年为了保障火箭能顺利升空，很多计算结果都需要反复的验证。这个验证的过程，其实就是一个测试的过程。当软件开发变成了软件工程的时候，测试就作为开发的一分子存在于世了。

    那个时候，开发一个软件，很多时候都是为了自己的某个需求。所以，那个年代的开发，从实际意义来说充当了如下多个角色：用户，需求分析人员，设计人员，开发人员，测试人员，管理人员和维护人员。

    在中国的这个文化沙漠中，测试人员单独出现，也是由外企带来的。那个时候的测试人员，大部分时间就是玩自己公司的软件。然后，发现了问题，就写封邮件，说这个地方为什么是这样啊，我觉得不对劲啊。然后开发大拿们也许会斥责：不懂装懂，滚。也许会鄙视：这是我们的产品特性啊。 也许会悻悻然：哦，一个小问题，回头我改了就行了。

    当年2001年，找工作的时候，突然发现有公司招测试人员，就应聘了。基本上工作就是玩一个软件，熟悉了以后，就是每个版本从头到尾把自己能玩的玩一遍，看看有没有问题。所以，记忆尤甚的是当时很多bug都是一个大妈发现的，她连开机都不会，更别提装什么操作系统了。她的方式就是逮住一个页面，不停的点点点。

    哈哈，那个时候换煞有其事的参与了好多测试论坛的研讨会，很多著名的论坛都是那个时候各起山头的。 不过当时就觉得，大家其实都抱着我来学robot怎么用来的，其实没什么意思。感觉那个时候的测试人员，都是为了能有一个一技之长，好跳槽涨薪。 记得当时有个深圳的哥们说，他是测试人员，一个月12k，当时在北京一个月3k的我，只能恨之厌之不服之。哈哈。

    总之，行业在发展，后来就有很多像模像样的测试理论方法流程过程纷纷韶绕了一段。 那个时候，测试和开发，似乎成为了冤家对头。测试就是挑刺的，被开发鄙视，去恶心开发。 很多开发觉得，你丫就是个棒槌，根本用不到你们。 测试呢，普遍想法是，哥就喜欢干这个挑刺的活，舒坦，你丫牛逼，别搞这么多bug出来啊。所以，很多时候，开发人员终于如愿以偿的混上PM了，会对手下的测试人员极为苛刻。

    慢慢的，很多公司觉得把每个项目都搞几个QA有点得不偿失，就把人都集中起来，搞个测试经理，然后每个测试人员都参与多个产品的测试。貌似，有点独立权了，开始张口闭口我们测试部门怎么怎么样。 很多公司现在的模式还是如此。

    其实，测试人员如果只是单纯的会测试，确实局限性很大。 一个好的测试人员，哪怕最底层的，他至少对他要测试的部分了如指掌，知道跟那些模块的相互影响是什么。毕竟80%的bug都是出现在模块之间的交集地带。 而一个开发，更多的是对开发工具的熟悉，实现功能。他们注重的正向的测试，对于交叉测试很少能够全面的衡量。 所以，这就是一个好的底层测试人员的作用。

    对于一个3年以上的测试人员来说，其实他对一个产品的周期，要比很多开发人员熟悉的多。他更熟悉开发的计划，时间表等等。 能更好的从产品层次去组织和管理测试活动。

    对一个好的测试人员来说，测试经理不是最好的，其实他们更加适合当一个项目经理。一个产品开发过程，需要一个开发经理，一个测试经理和一个好的项目经理。这个项目经理，很多情况下都是高级开发经理担任的。其实这样有利有弊。 对于现在越来越清晰的测试驱动开发的模式，更需要一个高级测试经理来担任这个角色。

    因为一个好高级测试经理，不但是对产品开发周期，风险规避，人员安排更加熟悉。而且能够更加有效的组织测试活动。而且，高级测试经理往往已经能够胜任一个需求分析经理的职位。对测试管理，团队管理更加得心应手。原因就是：一个开发看到另一个开发的能力，往往是他的经验，就是他能不能解决一个复杂的开发问题。更多的是经验的积累。 而测试人员看开发人员，往往都是他的短处，谁更容易在什么地方出错等等。 而且，测试往往比开发更加熟悉一个产品的真实需求。而且，测试用例的设计，除了对已有知识经验的必需外，更加需要的是一个有很强的创新能力的人去设计。一个创新，一个积累，在中国这种纯粹靠密集劳动力拿项目的现实中，是多么的可贵，是多么的心痛，被那么多无量的开发经理直接忽略。

    所以测试人员，想做的更好，就是要把自己搞的既是BA，又是QA，process manager，而且还是最终用户。 这才是一个真正的测试人员需要自我。

    查看(1072) 评论(11) 收藏 分享 管理

  • 性能测试的研究（4）

    2012-02-03 14:47:51

    性能测试数据模型
设计性能测试数据模型是一个设计数据负载分布配置文件的建模过程，也是对一个真实的用户的环境进行模拟的过程。每个配置文件一般包含了如下属性：
•	关键场景
•	并发用户数
•	请求率
•	请求模式

对于请求模式和请求率，一般是根据真实的用户环境和用户习惯进行预测。如果已经有实际的应用环境，那么分析服务器日志文件是一个更加精确的方法。通用的方法如下述各条：

那些是关键的场景？

通过分析那些会对程序性能产生影响的场景，并结合用户需求来衡量那些是关键场景。也就是说，经历程序的核心模块的那些场景

预期的最大在线用户数和并发用户数是多少？

预期的最大现在用户数一般就是预期设计的程序最大运行能力所能承受的用户数。而活跃用户数一般是分布在程序的不同场景中。而并发用户数，是指一个单一的场景所能允许的极限用户数。一般来说并发用户数占在线用户数的比例不超过五分之一。同过分析已部署的实际用户环境的服务器日志，很容易得出这些数值。

普通用户一般会执行的场景路线图是什么？

从用户角度分析，正常的用户在使用程序时都有什么样的习惯也是很重要的。通过分析用户的习惯，从而知道用户体验的关键场景在什么地方。从而有针对性的测试。例如，一个电子商务网站的最常用的场景路线图是：
•	打开主页
•	登录
•	浏览商品目录
•	选定商品加入购物车
•	提供付费，送货地址等信息。
•	提交订单


如何制定用户配置文件?

用户配置文件是为了区分不同类型的用户。每个配置文件里都包含了一种特定用户类型，以及该类型用户的特定操作组。例如，可以设计一个用户配置文件，使用该用户配置文件的用户都是属于某个特定权限组，唯一操作是浏览目录。利用这种方式就可以把各个场景的用户进行组织。

例如：
•	浏览配置文件（给只浏览的用户群使用）
•	搜索配置文件（给直接搜索的用户群使用）
•	订单配置文件（给需要完成订单的用户群使用）


每一个用户配置文件中，单一用户的操作分布是？

我们可以根据用户需求分心或者实际的用户体验（利用服务器的日志文件分析得出）来判断每个单一用户的操作分布是什么。例如对于电子商务网站来说，一个实际的订单配置文件中的用户体验如下：


    

对于无法从日志文件中得出分布的时候，我们可以根据用户需求分析和通常的市场分析报告来获取。例如，通过需求和市场报告我们获知，每个人在购买产品时，通常会浏览该类产品总目录一次，需要搜索指同类产品两次以做比较后进行购买。并且用户购买产品时绝大多数不少于三件产品。那么 我们的配置文件就如：


    

每个请求之间的平均思考时间是多少？

思考时间是指用户在两个连续的请求之间的等待时间。在次期间，用户一般在浏览上一个请求返回的信息。例如，该产品的详细信息，图片啊等等。

思考时间完全依赖于数据的复杂性。比如，登录页面的思考时间就远远小于浏览产品信息的思考时间。一般来说，思考时间都是取的所有请求的思考时间的平均值。这个时间一般都可以从通常的读速或者日志文件中获得。

用户配置的文件是如何组织的？

一般来说用户配置文件的组织结构，都是在一个给定的时间点，各个用户群体的分布来决定的。例如：


    

如何判断每个测试用例需要的执行时间？

测试的持续时间取决于设计的场景，数据和使用模式。以下是会经常考虑的：

用户的规模。对于一个电子商务网站来说，场景很简单，数据压力也不大，所以主要是考虑用户的使用模式。这样在考虑持续时间时，只需要做一个2-4小时即可。对于电信收费系统来说，就需要至少持续48个小时。

用户的行为。对于一个电子商务网站来说，压力最大的时候是在特定的假日期间会产生大量的订单。所以，对具体的瓶颈模块，需要更长时间的测试。比如银行付款模块，就需要能有足够大的能力来承受瞬间的强大压力，并要在最大承受能力下持续7X24小时来测试。

特殊的需求。对于一些特殊的客户需求，我们需要执行相应的测试时间。例如，电信收费系统会在每月底不断的接受强大的数据压力。为了模拟这种测试，我们就需要有个模拟的环境。例如，有一套单独的系统，独立运行中，每次压力只持续10分钟即可

    -fo


    查看(1040) 评论(0) 收藏 分享 管理

  • 性能测试的研究（3）

    2012-02-02 14:54:42

    压力测试

压力测试是使用高于系统承受能力的数据压力对程序进行测试。其手段是快速消耗资源从而使得程序在“零”资源情况下运转。例如，超负载的用户登录数，大量消耗处理器和内存，剥夺了其他模块获得资源的机会，使得这些模块处于“暂停”状态。

压力测试的目的是为了在高负荷条件下挖掘那些潜在的程序问题。

常见的问题有：
•	同步问题
•	资源竞争
•	内存泄漏
•	网络拥塞导致的数据丢失

和负载测试不同，压力测试是有明确针对性的测试。具有明确的性能指标，明确的测试场景，明确的数据量。负载测试往往是单一的场景测试，而压力测试往往是多个场景的复合测试。负载测试往往没有特殊的先决条件，而压力测试都是在特殊的指定测试环境下进行的。负载测试一般都是用来发现一个问题，而压力测试往往是用来复现一个问题。负载测试一般都是针对业务逻辑进行测试，而压力测试可以是一个简单的对象，例如一个指定的存储过程。

进入文档

执行压力测试的进入文档一般有如下几个：
•	程序的特性（特殊的场景）
•	潜在的问题（隐含的场景）
•	需要的压力数据的特性
•	瓶颈峰值（由负载测试得到的阀值）

步骤

进行压力测试需要的六步流程如下所示：


    

流程包含的步骤如下：
1.	选择测试场景。根据要测试的缺陷，选择相关的测试场景。
2.	设计测试数据。依照测试场景，和由负载测试获得的阀值，来设计所需的测试数据。
3.	指定性能指标。针对测试的缺陷，来指定在压力测试中要监察的性能指标。
4.	创建测试用例。基于测试场景，数据集和缺陷来创建针对性的测试用例。
5.	执行测试用例。在特定的测试环境中执行测试用例。
6.	分析测试结果。 对得到的结果进行分析。

步骤一 选择测试场景

进行压力测试要确定多个测试方案。每个方案都依赖于一个单一的测试场景。一般来说，只有一对一的场景测试，才能更好的发现潜在的性能问题。如下是常用选择场景的原则：
•	选择那些对整体性能有影响的场景。
•	选择那些最有可能影响性能的操作。例如，频繁的锁定操作，同步操作，长事务操作和那些磁盘密集型操作。
•	基于负载测试的结果。通过负载测试，可以探知一些系统的瓶颈。而一般围绕这些瓶颈进行压力测试是一个很好的选择。通过对瓶颈进行更大的压力测试，从而使得程序部分功能阻塞，从而揭显出那些隐藏的问题。

对一个电子商务应用来说，典型压力测试如下：
•	订单处理场景中，程序需要实时的更新产品的库存。所以，会出现数据库数据同步和假死锁的可能。
•	用户在搜索的场景中，使用了一个会返回大量值的关键词。这种搜索会占用大量的内存而使得利用率降至极低。并且很大程度上是一次无效的搜索，浪费了资源。

步骤二 设计测试数据

用于压力测试的数据负载量，首先必须超过阀值。然后，不断调整负载来观察程序的行为。

其中一个设计理念就是对负载测试的反向设计。负载测试是要保证所有影响程序性能的性能指标是处于正常运行的状态下。所以压力测试只要破坏其中任意一个性能指标就可以压垮程序。通过不断的压垮程序的压力数据集，你也可以获得对抗这种潜在的高峰压力的方法。

负载测试的持续时间一般都是有个明确的值。而压力测试的持续时间测很难判断，不但会跟测试环境相关，也跟具体的场景有关。所以，不断的更换测试环境的配置是很有必要的补充，而在负载测试中，测试环境都是要求稳定的一致。

步骤三 指定性能指标

在压力测试前，要明确每个场景存在的隐患所可能涉及到的性能指标。这些性能指标一般都是预设的性能要求或者是根据明确的用户需求推导出来的潜在需求。一般来说，这些性能指标都是和负载测试的指标相同。可以共用同一种方法来获得。例如，在代码中加入的计时器，就可以被二者共享。但是，压力测试的性能指标获得都要比负载测试的过程复杂。

例如，在提交订单这个场景中，最主要的性能指标是资源竞争。除了负载测试需要关心的基本信息，需要获得一些额外的信息：


    

步骤四 创建测试用例

基于以上步骤，创建所需要的压力测试用例。例如一个提交订单的测试用例如下：

触发条件：
•	十万个模拟用户
•	每秒随机两次操作
•	用户异步触发
•	持续两天

性能参数（期望值）：
•	死锁（无硬死锁）
•	接受请求数（不小于25次/秒）
•	驳回请求数（不高于50次/秒）
•	死锁率（不高于35%）
•	解除死锁率（长度不超过100个/秒）

步骤五 执行测试

可以使用手工或者自动化工具对测试用例进行执行。一般执行的时间可以分为两种：
第一种，固定时间。例如，每个模块完成集成测试后，开始执行功能测试前。
第二种，固定阶段。例如，在功能测试完成后进行。

步骤六 分析测试结果

通过分析测试结果，与负载测试的数据进行对比，从而发现那些隐藏的瓶颈的成因。为了更好的修复问题，还需要做如下的额外工作：
•	重新审读设计文档
•	重新审核源代码
•	修改架构并测试来验证结论

    查看(980) 评论(1) 收藏 分享 管理

  • 性能测试的研究（2）

    2012-02-01 16:14:49

    负载测试流程

使用负载测试来研究系统在通常数据压力下和峰值数据压力下的行为。一般是采用逐级增加数据量的方法来研究。从一个初始化环境的数据量逐级增加直到性能阀值数据量，一般是倍增的原则。例如，你设定了CPU的最高阀值是75%。那么逐级增加数据量，直到CPU的占用率接近75%。通过负载测试，你能够识别系统的瓶颈和程序的最大稳定负载能力。

进入文档

进入文档一般包含如下：
•	由性能架构决定的性能目标
•	程序的特性（测试用例）
•	工作数据流的特性
•	每个程序特性的性能指标
•	测试计划


测试步骤
如下表中描述了进行负载测试的流程：
  

    


负载测试流程包含了如下步骤：
1.	设定主要测试场景。从程序所包含的所有应用场景中，挑选出那些对性能影响最大的场景作为需要测试的场景。
2.	设计测试数据。根据设定好的测试场景设计相应的测试数据。
3.	审定性能指标。对每个需要测试的场景，设定具体要检测的性能指标。
4.	创建测试用例。针对每个测试场景，设计具体的测试用例，用于获得需要的性能指标。
5.	执行测试。使用设计好的测试数据执行测试用例，并搜集设定的性能指标的具体数据。
6.	分析测试结果。根据具体的性能指标的数据分析结果，对程序性能进行评估。


步骤一 设定主要测试场景

万始之初是挑选关键的测试场景。一般一条业务路径中，包含了多个场景。而关键场景，就是对你的测试目标有着直接影响的场景。一般来说关键场景就是经常被使用的场景或者是需要使用大量资源来执行的场景。

例如，对一个购物网站来说，常见的关键场景如下：
•	登录网站
•	浏览产品目录
•	搜索特定产品
•	购物车
•	信用卡验证
•	订单提交

步骤二设计测试数据

根据挑选出来的测试场景，需要有针对性的设计所需的测试数据。一般来说测试数据应该考虑到如下几个因素：
•	用户数。需要明确在线用户数和活跃用户数的需求。
•	请求频率。需要明确在单位时间内可能发生的请求数。
•	请求的模式。同样的用户集合在不同的模式下使用程序会带来不同的数据流。所以要明确用户会以何种模式来使用程序。

一般来说，我们采用数据模型的方法来创建测试数据集。 在创建了数据模型后，根据用户分布配置文件，来使用测试数据进行逐渐加压测试。在加压过程中，记录程序的行为，直到获得足够典型的性能目标数据，即可将当前的数据量作为一个数据集标准。然后逐渐加压，直到获得程序的阀值，然后就可以在数据模型中明确标识。这样，就可以勾勒出来一个明确的数据级别分布图。


步骤三审定性能指标

拥有明确的性能指标，才能在测试中获得有效的测试数据。通过这些指标，你才知道在哪里能找到用来对程序的性能进行评估的对象。只有通过这些指标，才能识别出真正的瓶颈。

而且，通过不断迭代的测试方式，你可以在任何一轮测试前根据上次的结果来修改下一轮测试需要关注的性能指标。例如在上轮测试中发现某个未监控的服务进程实际上是真正的资源消耗源头。那么在下轮测试中，就可以根据这个服务进程修改测试方法，数据和要关注的性能指标来跟踪。

如下所列的指标类型，都是用于评估程序性能的常用类型：
•	网络类指标。这类指标一般提供了网络健康指数。例如交换机，路由器和网关等的状态。
•	系统类指标。这类指标一般用于了解服务器的资源利用率情况。例如处理器，内存，磁盘的输入/输出和网络端口的输入输出状态。
•	平台类指标。这类指标一般用于监察程序相关软件的性能情况。例如，使用的公用语言运行库和私有语言运行库的性能情况。
•	程序类指标。这类指标一般使用在程序中添加获得额外的代码来获得的。例如，在登录程序中，添加一个计时器，来获得用户登录的消耗时间。
•	服务类指标。这类指标一般用于衡量整个程序的数据吞吐量和服务延迟时间。一般都会跟一些特定的业务场景相结合。例如下表所列：


    

在审定好性能指标后，我们需要给每个指标设定一个我们期望的基准线。这个基准线可能有多条，分别对应于不同的数据量。通过分析这些基准值和实际值，能够更加清晰的得出在不同的负载水平下的性能。举例如下：


    


步骤四 创建测试用例

基于步骤二设定的数据模型和步骤三设定的性能指标来制定测试用例。

例如：在数据集A的测试场景中，使用测试用例1，2，3对多个性能指标进行检测。

    数据模型的数据集A为：
    

    
 
    
  
  
    场景
    
      		
  
  
    占总用户的比例
    
      		
  
  
    用户数
    
      		
 
    
 
    
  
  
    浏览目录
    
      		
  
  
    50%
    
      		
  
  
    250
    
      		
 
    
 
    
  
  
    搜索产品
    
      		
  
  
    30%
    
      		
  
  
    150
    
      		
 
    
 
    
  
  
    提交订单
    
      		
  
  
    20%
    
      		
  
  
    100
    
      		
 
    
 
    
  
  
    总计
    
      		
  
  
    100%
    
      		
  
  
    500
    
      		
 
    

    
审定性能指标和预设值为：
•	单位时间浏览目录数（100/秒）
•	单位时间成功提交订单数（10/秒）
•	返回查询结果平均时耗（2.5秒）
•	处理器占用率（不大于50%）
•	内存占用量（不大于320MB）

测试用例为：
•	测试用例1：每秒发送200个浏览请求。检测性能指标：单位时间浏览目录数，处理器占用率，内存占用量。
•	测试用例2：每秒发送100个查询请求。检测性能指标：返回查询结果时耗，处理器占用率，内存占用量。
•	测试用例3：每秒发送20个订单提交请求。检测性能指标：单位时间成功提交订单数，处理器占用率，内存占用量。


步骤五 执行测试

可以使用手工或者自动化工具对测试用例进行执行。一般执行的周期可以分为两种：
•	第一种，固定周期。例如，每周对测试用例执行一次。
•	第二种，固定版本数。例如，每十个版本执行一次测试用例。

步骤六 分析测试结果

根据测试获得的数据和预设值进行比较，就可以对程序的性能有一个明确的评价结果。从而明确了性能调优的目标。同时，这些数据也能帮助你得出产品的瓶颈和潜在的固有缺陷和风险。以及获得如何进行扩容的方式和方法。同时，连续的测试结果报告，有助于控制产品的性能指标，从而降低开发成本。根据测试结果，还可以帮助用户在使用程序是如何部署更加优化的运行环境。

输出文档

通过负载测试获得的常用输出文档如下：
•	更新的测试计划文档
•	在不同的负载水平下，程序的行为描述文档
•	程序的最大稳定负载能力描述文档
•	潜在的瓶颈，固有缺陷和风险的描述文档
•	推荐的部署和配置文档

    查看(935) 评论(0) 收藏 分享 管理

  • 性能测试的研究（1）

    2012-01-31 18:38:21

     简述

性能测试用于确定应用程序在指定的输入输出条件下的响应状况。一般要使用多个独立的性能测试场景/测试用例来覆盖所有的可能性。测试时，尽可能使测试环境贴近真实环境。通过研究应用程序的模拟负载下的行为，来确定其性能指标是否满足设计目标。

性能测试是用于研究应用程序在预期数据量和最高峰值数据量下运行状态的测试方法。以便确认程序在不断增加的数据量下的具备的处理能力。如下的三种性能测试方法都可以殊途同归的实现以上的目标：

•	负载测试。使用负载测试来研究基于不同可接受的数据集合下的产品的行为。 可以很明确的获知产品是否达到了设计要求。一般通过监控响应时间，数据吞吐率，资源使用率来进行测试。而且通过这种测试可以探知应用程序在什么样的数据峰值下达到崩溃点。

•	压力测试。压力测试用于评估应用程序在数据量过载后的行为。目的是在高负荷状态下，挖掘更多的系统隐藏的内在问题。例如数据同步，资源竞争和内存泄漏这些常见的问题。通过压力测试，我们可以探知应用程序的内在缺陷，以及其会带来的风险。

•	能力测试。能力测试和负载测试相辅相成。通过其能够获知应用程序的预设的失败阀值点。这个阀值点是通过研究负载测试在各个数据量的程序行为获得的，即在崩溃点前最后一个能够维持程序稳定运行的数据量为预设的失败阀值点。通过能力测试，可以制定扩容计划。通过扩容计划，我们可以稳定的提高用户集和数据集。例如，如果想将用户集和数据集提高一倍，那么根据现有的资源。（例如处理器个数，内存容量，硬盘空间，网络带宽等等）我们就可以知道最小的扩容资源需求值。

性能测试的目标

性能测试的最大目的是来比照应用程序的实际性能和预期性能。同时还有一些其他的目的：
•	确认系统中存在的瓶颈和成因。
•	调整和优化平台的硬件配置和软件配置来达到性能最大化。
•	验证程序在压力下运行的可靠性。

只通过一种性能测试的方法是不可能获得所有的性能指标的。但是了解这些性能指标，对你进行性能测试会有很大的帮助：
•	响应时间。
•	吞吐率。
•	最大并发用户数。
•	资源利用率。
•	不同数据量对应的系统行为。
•	程序崩溃点。崩溃点一般是指程序停止响应，返回典型的503错误时的数据量值。
•	程序崩溃的原因和崩溃后的行为。
•	程序的固有缺陷。
•	负载的主要成因。例如，是用户数的增加导致负载量翻倍，还是某个操作导致数据流翻倍。

性能测试的指标

绝大多数的性能测试依赖于一组预定好的，文档化的和达成共识的性能目标。明确的目标可以提高性能测试的效率。通过测量程序的真实数据和目标进行对比从而判断程序性能的优劣。
当然你也可用通过探索的方式对产品进行性能测试来了解程序的真实情况而无需任何明确的目标。这些测试的结果也可以作为对产品性能评价的指标。

性能指标一般包含如下：
•	响应时间/延迟时间。
•	数据吞吐率。
•	资源利用率。
•	工作负载。

响应时间/延迟时间

响应时间是指发出请求后到得到相应所需的时间量。在服务器端和客户端都可以测量相应时间：

服务器端获得响应时间。这个时间段是指服务器从获得请求到完成的执行时间段。不包含客户端到服务器端的传输时间段，因为其含有网络传输消耗的时间。

客户端获得响应时间。这个时间段包含了加入请求队列的时间段，服务器处理的时间段和来回传输的网络消耗时间段。在多种测试方法中，最常用的两种方法是：TTFB，第一个字节到达客户端为终点。TTLB，最后一个字节到达客户端为终点。而且一般来说，测试时还要使用不同的网络带宽来测试从而得到更加真实的数据。

通过测试时间延迟，从而可以判断是否存在对客户端的请求响应度过低的性能问题。

数据吞吐率

数据吞吐率是指单位时间内可以被程序响应的请求数。不同的用户数和用户活动类型会产生较大的差异。例如下载的数据吞吐率就要比浏览页面的低。通常，数据吞吐率是以每秒可以响应的请求数来记录。

资源利用率

资源利用率用于确认在服务器和网络资源方面需要的资源成本。主要的资源为：
•	处理器
•	内存
•	硬盘输入/输出
•	网络输入/输出
通过性能测试，可以明确每一个流程和步骤需要的资源情况。通过优化资源利用率，降低成本。

工作负载

对于一个程序，活跃用户和并发用户往往有着巨大的差别。一般来说在活跃用户中，一般只有10%-20%的并发用户存在。

所以在性能测试中，要区别两者。在压力测试时，工作负载一般指的就是并发用户产生的数据量。

    查看(1051) 评论(0) 收藏 分享 管理

  • Test Case Design

    2012-01-11 11:01:05


    包含如下内容

    •Test Case Component
    •Test Case Object
    •Test Case Organization
    •Test Case Design Methodology
    •Test Case Design Process
    •Test Case Common Risk

    查看(588) 评论(0) 收藏 分享 管理

  • CS架构的性能测试

    2012-01-11 10:51:08

    简述了如何在CS架构下进行性能测试

    查看(869) 评论(0) 收藏 分享 管理

  • QA grows

    2012-01-10 15:52:34

    Our lives are guided by natural rhythms that are particular to each of us and cannot be altered by force of will alone
    (我们的生命是由对我们每个人来说都是非常特别的自然规律所引导的，而且不能被个人意愿所改变。)

    What a QA engineer does?
    （一个测试工程师要干些什么？）

    Write test plans from the requirements, specifications and test strategies.
    （根据测试需求，规格和策略书写测试计划。）
    Use versioning systems to code test scripts. 
    （使用版本控制系统开发测试用例。）
    Create and perform. test campaign whenever it is necessary to fit in the overall planning.
    （总体规划测试活动，创建和执行测试活动，并在必要时进行调整。）
    Use bug tracking database to report bugs. 
    （使用可长期维持的数据系统对问题报告进行报告和跟踪。）
    Analyses test results. 
    （分析测试结果。）
    Report results to the QA manager. 
    （向测试经理发送可依赖的测试结果报告。）
    Raise an alert when an important issue is likely to put in jeopardy the whole project. 
    （当某个严重问题将会对整个系统产生严重影响前，对整个项目组发起警告。）

    What makes a good QA Engineer?
    （怎样才能做一个好的测试工程师？）

    1. Broad understanding of the product
    （深入了解整个项目）

    To test efficiently a product, the QA engineer must know it well enough. This sounds obvious must unfortunately, this is often under-estimated. Knowing well the product includes also knowing how end-users expect it to work. Again this may sound obvious but remember that the biggest part in testing is black-box testing. The QA engineer must have a "customer-focus" vision.
    （为了更加有效率的测试一个产品，测试工程师必须对产品有很深刻的了解。听起来这是很明显的一个人人皆知的道理，但是大部分时间都无法达到。除了产品知识，终端用户的体验也同样重要。尽管这也是个人人皆知的道理，而且是黑盒测试的主要组成部分。测试工程师必须拥有“客户观点”的测试策略。）

    But a good QA engineer must also know how the product is designed because the more you know the product; the better you're able to test it. However, the QA engineer will have to analyses the design only after his black-box test plan is completed. Indeed, knowing the design can widely influence the test strategy. It is better to first write the test plan with a high-level vision, then getting more and more information to refine the testing.
    （同样，好的测试工程师也必须对产品的架构比较熟悉，这样会有助于你对产品测试的更加完善。当然，对产品设计架构的分析一般是在黑盒测试计划设计完成之后。而且对产品架构的熟悉，可以有助于增强你的测试策略。一般来说，测试计划的初始版本都是都是比较泛泛的。然后会根据细节一点点的丰富。）


    2. Effective communication
    （高效率的沟通）

    Communication is an extremely important skill for a QA engineer. Of course, meetings (stand-up etc.) and status reports are part of the communication but more importantly.
    （良好的沟通是测试工程师最重要的技能。其中通过会议和状态报告进行交流是胃肠重要的。）
     
    A QA engineer must be particularly efficient in the following tasks: 
    （一个好的测试工程师必须在如下任务中非常有效率：）

    1）Directly communicate with both Development and Product definition teams. 
    （同开发团队和设计团队的直接交流）

    2）Has capability to communicate with technical and non-technical people. 
    （同有技术背景和没有技术背景的人进行沟通）

    3）Having the diplomacy to say "no" when a bug is considered as not fixed.
    （在对一个未被修复的产品错误具有外交策略的说“不”。） 

    4）Having the diplomacy to communicate a bug that without "offending" to the developer.
    （在和开发人与讨论一个产品错误的时候具有“无冒犯”意味的外交策略）

    Developers may often feel offended when a bug is submitted. This is 100% natural. This is why the QA engineer must have the ability to "criticize without offending". 
    （开发人员经常在一个问题报告被提交后具有“被冒犯”的感觉。完全出自绝对的人性自然。所以需要测试工程师具有“对事不对人”的技巧。

    5）Do not rely on "bug tracking" database for communication! 
    （不要仅仅依赖问题报告跟踪库进行交流。 ）

    There is nothing better that a bug tracking system to create "misunderstanding" between Development and QA teams. 
    （再也没有别的方式能比问题报告跟踪库那样给开发和测试团队带来那么多的相互误解。）

    3. Creativity
    （创新性）

    Testing requires a lot of creativity. Bugs are often hidden and just performing the obvious positive tests will have only a few chances to actually find bugs. Hence, the QA engineer must use its creativity to figure out all the scenarios that are likely to detect a bug. In other words, the QA engineer must be able to "see beyond the obvious".
    （测试需要创新的能力。如果仅仅通过常规的正向测试，很难发现那些隐藏的问题。所以，测试工程师要用自己的创新能力去是设计更多的非常规场景来发现问题。简单的说，测试工程师要能够看到现象背后隐藏的真相。）


    4. Development knowledge
    （开发背景知识。）

    Quality Assurance requires knowledge about software development for two basic reasons: 
    （测试人员需要知道软件开发知识的原因一般有如下两个：）

    1） Development capabilities are required to eventually code automated tests 
    （自动化测试需要具有开发能力）

    2）If you know how to develop, you have better ideas on what is "dangerous" to code, so what to test more thoroughly 
    （如果你知道如何去开发产品，那么就更容易的知道哪里会有危险代码，从而更加有针对性的进行测试。）

    5. Driving for results
    （结果驱动）

    A good QA engineer never forgets that the ultimate goal is not only to find bugs but also have them fixed. Once a bug has been found and has been "acknowledged" by the development team, the QA engineer may be required to "convince" people to fix it.
    （一个好的测试工程师要记住测试的最终目的不是发现问题而是保障隐藏的问题被修复。一旦一个问题被发现和得到开发团队的确认，那么测试工程师就要保证有人完全修复这个问题。）


    6. Additionally
    （其他技巧）

    Getting a nice automation framework with smart tools does not bring anything if it does not find any bug at the end. 
    （引入一个漂亮的自动化测试框架和高科技的测试工具，并不意味着就能发现更多的软件缺陷。）

    Ask yourself if the automation is going to help to find more bugs and when.
    （如果自动化测试能够帮你发现更多的缺陷，那就要问问你自己为什么漏掉了。）

    Prioritize your testing tasks on the only important criteria.
    优化你的测试基于这些重要标准：
    How many bugs is this likely going to find? 
    （有多少问题可以被这种测试发现？）
    How major will be the found bugs? 
    （有多少严重的缺陷可以被这种测试发现？）

    Detecting thousands of cosmetic bugs is irrelevant/useless - and often easy - until all major/show-stopper bugs have been found。

    （发现上千的无关紧要的问题是没有任何意义的，而且这样一般是很容易的。只有所有的严重和阻塞性的问题被全部发现后，测试才有意义。

    查看(542) 评论(0) 收藏 分享 管理

  • How to automate your project

    2012-01-10 15:47:08

    Now, more and more requirements come from client that they want to make the testing to be automated, but how we start it? Here are some tips to share with you:

     

    Automation design process

    Analyze Automation Type

    Identify Automation Scope

    Case design methodology

    Case structure

    查看(355) 评论(0) 收藏 分享 管理

  • How to make a Test Plan

    2012-01-10 15:43:58

    What should be included in a test plan? In general, they are: goals, scopes, methods, schedules, resources, templates, standards, reports.

     

    The goals of a test plan are the reasons and results that you need to do a testing: 

    1.          Completion rate

    2.         Error-free rate

    3.        Time on Tasks

    4.         Subjective measures

    5.        Start/complete criteria

    6.        Approach

    7.          Output

     

    The scopes of a test plan are that you will test: 

    1.          Task list

    2.         Fail/pass scenarios

    3.        Test depth

    4.         Test width

    5.        Methods

    6.        Metrics

    7.          Acceptable/unacceptable issues

    8.        Trainings

    9.        Release documents

    10.     Reports

    11.       Priority and severity sets

    12.      Test methodology

    13.     Test tools

     

    The methods of a test plan are the ways to do test: 

    1.          Test case development methodology 

    2.         Manual testing methodology

    3.        Auto testing methodology

    4.         Process to review test case

    5.        Process to manage test case

    6.        Process to execute test case

    7.          Process to report bug

    8.        Process to fix bug

    9.        Process to verify bug

    10.     Process to generate reports

    11.       Process to generate documents

     

    The schedules of a test plan are the time sheets to set milestones and checkpoints:

    1.          When the design docs ready for test case development

    2.         When the test case ready for test case review

    3.        When the test environment ready for test

    4.         When the milestones get the deadline

    5.        When to start smoke testing

    6.        When to start functional testing

    7.          When to start regression testing

    8.        When to deploy a new build

    9.        When to verify bugs

    10.     When to GA build

    11.       When to close the testing               

     

    The resources of a test plan are what you can use to do the testing: 

    1.          What human resources that you need

    2.         What hardware resources that you need

    3.        What software resources that you need

     

     

    The templates of a test plan are used to generate each required documents in the testing: 

    1.          Design documents template

    2.         Test outline template

    3.        Test case template

    4.         Bug templates

    5.        Reports templates

    6.        Release templates

     

    The standards of a test plan are needed to follow in the testing: 

    1.          Test case development standards

    2.         Test case execution standards

    3.        Bug actions standard

    4.         Release standard

     

    The reports of a test plan are exaction trace of the testing:

    1.          Phase reports

    2.         Build reports

    3.        Daily reports

    4.         Weekly reports

    5.        Monthly reports

    6.        Release reports

    7.          Process reports

    8.        Management reports

    9.        Resources reports

    10.     Progress reports


    (Objectiva QA forum, Eddie Zhang)

    查看(681) 评论(0) 收藏 分享 管理

  • “Powerful” flags in Bugzilla

    2012-01-10 15:32:22

    Although Bugzilla has already provides powerful search and report function, we still want to get some special information from the Bugzilla. To get this, the additional flags sound powerful than we expected.

     

    Here are some examples to show these powerful flags:

    Example #1:

    We can search out all bugs that have been set to REOPEN status by search, but how to know which bug is reopened by code fixing failed?

     

    We set a flag named “FailedinQA”. So when the bug was reopened by a failed code fixing, we marked this flag to “+”. So, we can easily tell these actually failed bugs.

     

    Example #2:

    There are bugs were found after one round test case execution. We want to know all these bugs that still working on previous build.

     

    We set a flag named “Regressed”. When the bug is verified working on previous build, the flag was set to “+”. Set to “-“means this is a new feature bugs or it not working on previous build too. So, the “-“marked bugs are missed one. We should take more regression test on these areas.

     

    Example #3:

    There are some bugs need to log into release note. So, technic writer need a way to search out all bugs easily.

     

    We set a flag named “ReleaseNotesReq”. We marked all these bugs to “-” for the technic writer. The writer set to “+” means it has been updated into release notes.

     

    Example #4:

    Sometimes, the created bug is not create for a real issue, but created for an opening discussion. So, BA, Dev., and QA can work together on it for enter comments as logs.

     

    We set a flag named “InternalCommunication”. Set to “-“means it still opening. Set to “+” means is closed.


    (Objectiva QA Forum - Eddie Zhang) 

    查看(551) 评论(0) 收藏 分享 管理

  • 随遇而安(倚天屠龙记 主题曲)

    2007-08-08 11:50:57

    马锦涛版的倚天屠龙记 也许不是最好看的 但是主题歌是我看过的电视剧集里面最好听的

    随遇而安(倚天屠龙记 主题曲)
    作词:姚若龙下载
    作曲:小虫
    演唱: 黄沾

    人外有人山外有山
    不怕拼命怕平凡
    有得有失有欠有还
    老天不许人太贪
    挺起胸膛咬紧牙关
    生死容易低头难
    就算当不成英雄
    也要是一条好汉
    万般恩恩怨怨都看淡
    不够潇洒就不够勇敢
    苦来我吞酒来碗乾
    仰天一笑泪光寒
    滚滚啊红尘翻呀翻两翻
    天南地北随遇而安
    但求情深缘也深
    天涯知心长相伴

    查看(944) 评论(0) 收藏 分享 管理

  • 景黛音

    2007-08-08 11:20:03

    

    景黛音:
    　　1980年《上海滩》饰阿娣 (周润发 赵雅芝 吕良伟 汤镇业合演)
    　　1984年《鹿鼎记》饰建宁公主 (梁朝伟 刘德华 刘嘉玲合演)
    　　1984年《决战玄武门》饰李洛云 (苗侨伟 黄日华 翁美玲 汤镇业合演)
    　　1985年《陆小凤之凤舞九天》饰薛冰 (万梓良 黄允材合演)
    　　1985年《雪山飞狐》饰程灵素 (吕良伟 赵雅芝 曾华倩合演)

    呵呵 居然演过我最喜欢的程灵素!

     

    查看(722) 评论(0) 收藏 分享 管理

  • 什么叫做绝望

    2007-08-08 11:09:41

    昨天那么好的天 算的上北京一年中最适合堕落的一天了, 我居然没睡舒服了, 真是暴殓天物啊(居然google拼音没这个词)

    总体来说分为三个阶段:

    刚回家 发现同屋的猫跑到我的屋子里面大闹了一番 不过既没大小便 也没乱翻一气 就是把灯绳咬成了三节 让我怀疑他上辈子是不是做那个两条绳子计算半个小时之类的题给累死的 这辈子福来心至 老是要给大家证明一下

    只好把所有的床单 被子 枕套 衣服 都扔到洗衣机里面消毒去了

    然后打开了昨天下的陆小凤传奇, 发现薛冰挺好看. 呵呵 一大堆老面孔, 虽然不知道名字, 只是些 死跑龙套的. 演员表如下: 

       领衔主演：万梓良、陈秀珠、欧阳震华、景黛音、
                黄允材、刘江、李香琴、陈洁仪、吴君如 

    没注意谁是吴君如, 不过欧阳振华好年轻啊 也没那么胖 就是没现在那么好玩了 不容易啊 85年的片子 到了2000年人才红

    然后到点睡觉

    结果做了几个梦 只有一个记得很清楚:

    似乎俺成某个地方的老大, 但是不作恶的那种, 有一天不知道怎么回事 就杀了人了 就跑 路边拦了一个黑车 开车的是石头里面的黑狗 跑啊跑 居然跑到当初住过的地下室了

    结果被人认了出来 居然成了国安局的卧底神探了 乱起八糟的 呵呵

    印象最深的是当时被人认出来的时候那种绝望感, 整个人浑身沉巅巅的, 但是有觉得自己空无一物, 明明要晕过去 却神志非常清楚 想要瘫倒 发现原来这样也要花力气能控制整个自己才行

    整个人就跟悬在空中 浑身上下都压力十足 偏偏还感觉浑身不着力 在那一个 真是绝望了 一切一切都是空啊

    呵呵 醒来了 浑身也没啥不舒服的 就是觉得这个梦有点太真实了 绝对的绝望感觉啊 不错不错 算是很好的体验

     

    查看(452) 评论(0) 收藏 分享 管理

  • 夹起品格做人!

    2007-08-08 10:37:28

     
    转贴一下, 什么叫做品格呢?
     
    什么叫品格？品者，次第也；格者，标准也。品格就是有等次的标准，合乎等次的标准的东西，是够等级够资格的人和事。也就是说，品格就是有品味的人格。品味就是层次，品味就是不俗，品味就是高雅，所以讲品味就是具有高雅层次的、不平庸入俗的人格。
     
     呵呵, 由此看来, 所谓品格, 就是一个人具有了讲究品味的高雅的人格. 所谓雅, 要从风雅颂讲起:
     
    风。是不同地区的地方音乐。《风》诗是从周南、召南、邶、鄘、卫、王、郑、齐、魏、唐、秦、陈、桧、曹、豳等15个地区采集上来的土风歌谣。共160篇。大部分是民歌。
    雅。是周王朝直辖地区的音乐，即所谓正声雅乐。《雅》诗是宫廷宴享或朝会时的乐歌，按音乐的不同又分为《大雅》31篇，《小雅》74篇，共105篇。除《小雅》中有少量民歌外，大部分是贵族文人的作品。
    颂。是宗庙祭祀的舞曲歌辞，内容多是歌颂祖先的功业的。《颂》诗又分为《周颂》31篇，《鲁颂》4篇，《商颂》5篇，共40篇。全部是贵族文人的作品。从时间上看，《周颂》和《大雅》的大部分当产生在西周初期；《大雅》的小部分和《小雅》的大部分当产生在西周后期至东迁时；《国风》的大部分和《鲁颂》、《商颂》当产生于春秋时期。从思想性和艺术价值上看，三颂不如二雅，二雅不如十五国风
     
    由此可见 雅 最早是指的音乐 也就是说高雅 就是那些有地位有特权才有能力听的宫廷歌曲.
     
    呵呵 所以说品格就是所谓的贵族气质. 夹起了贵族气质做人, 说白了 就是做人不作派.
     
    呜呼挨宰, 这年头连贵族气质都没几个人能撑的起来, 何况品格啊. 所以书呆子们都自我麻痹, 万般皆下品,唯有读书高啊. 啥时候你成了个只会死要面子的书呆子了, 恭喜你, 你有品味了, 品格高尚了, 反正你也不在乎别人说什么, 呵呵.
     
    所以总结一句 品格, 就是yy到极点, 不要也罢!

    查看(649) 评论(0) 收藏 分享 管理

  • 上传的相关文档

    2007-08-06 13:51:54

    1. 如何在window平台安装bugzilla和testopia组件

    2. Testopia的中文用户手册,自己翻译的.

    3. 现用的测试用例的模板

    查看(577) 评论(0) 收藏 分享 管理

1829/10<12345678910>
Open Toolbar