-
软件测试管理艺术
2013-02-16 16:24:38
概述：什么是测试管理的艺术？在物联网、云技术、移动互联网的兴起发展，三网合一成为大趋势的未来，测试管理艺术又将何去何从呢？本文旨在与对测试管理感兴趣的同仁进行探讨。名家名言
艺术不是你所看到的东西，而是你让别人看到的东西。
——埃德加 德加（Edgar Hilaire Germain de Gas）
什么是测试管理的艺术？
一提到艺术我们马上就会想到绘画、雕塑、戏剧、建筑、舞蹈、诗歌等等，但在这里我们要讨论的，是关于测试管理的艺术。首先我们来看，什么是测试？ISTQB为测试做了如下定义：
测试是一个过程，它包括了软件生命周期的所有活动，有静态的也有动态的。它涉及到计划、准备和对软件及其相关工作产品的评估，目的是
● 判定软件或软件的工作产品是否满足特定需求；
● 证明它们是否符合目标；
● 发现缺陷。
但是什么时候做测试？是在产品将要完成的时候来做还是从产品需求定义的时候就开始做？实际经验又告诉我们，如果在产品将要完成的时候再做测试那么就太晚了，预防缺陷远比发现缺陷耗费的费用和时间少的多。所以，测试的目的应该是：
● 预防缺陷；
● 提供与产品质量相关的信息和信心；
● 发现缺陷。
什么是管理？
管：为了达成某一目的，行使一定的权力，组织分配人员执行任务。
理：在目标实现的过程中，控制过程，使其条理化、有序进行。
测试管理（manage）就是制定计划、执行计划、检查和改进过程从而达到测试目的的一切方法和活动。制定计划（或规定、规范、标准、法规等）是设计达到目标的路径，将整体的大目标分成一个个阶段性的小目标，确定实现阶段性目标所需要采取的战略措施，部署相应的人力、物力、规定走向目标时应该遵循的规范、标准、法规和过程等；执行就是按照计划去做，即实施；检查就是将执行的过程或结果与计划进行对比，总结出经验，找出差距；改进首先是推广通过检查总结出的经验，将经验转变为长效机制或新的规定；再次是针对检查发现的问题进行纠正，制定纠正、预防措施，以持续改进。
测试管理的艺术就是创造管理方法和技巧，创造性的运用管理方法和技巧实现测试的目的。它应该是基于实践的，与时俱进的，同时也是感性的，反映人类内心的情感和诉求，反映对理想的追求。因为只有这样的艺术才会有生命力。
回顾国际上的管理学艺术之路，我们可以看到管理学经历了两大阶段：
第一阶段：从行为科学到战略管理
从个体行为到组织行为（1956—1965）
从组织中的人到人的组织（1966—1975）
从过程管理到战略管理（1976—1985）
第二阶段：从组织变革到知识管理
从职能组织到变革组织（1986—1995）
从组织管理到知识管理（1996—2005）
回顾软件测试的目的演变，我们可以看到如下的脉络：
以调试为主（从有软件开始-1956）
证明程序是正确的（1957–1978）
证明程序中有错误（1979–1982）
评估产品能力（1983–1987）
预防缺陷（1988–1992）
预防缺陷，发现缺陷，评估质量（1992– ）
管理理念方法和技巧都是以目标为导向的。当我们的目标发生了变化的时候，管理的艺术也随之得到了发展。我们可以清楚的看到管理艺术随着测试目的的变化而变化，在有一个时间上一一对应（或者略带滞后）的关系。
比如在测试目的从“调试”转换到“证明程序是正确的”时，也是管理艺术从个体行为到组织行为转变的过程。再比如，当测试的目的从“证明程序中有错误”改变为“评估产品能力”时，管理艺术也经历了从过程管理到战略管理的转换。
随着物联网、云技术、移动互联网的兴起和发展，测试管理也受到了空前未有的挑战，因为测试对象的开发规模，组织形式，应用范围以及对人类生活的影响都产生了前所未有的革命。如何创造管理方法和技巧，创造性地运用管理方法和技巧来适应这场革命成为我们必须面对的课题。
笔者以为，未来的测试组织和测试过程应该体现：效率 Performance，安全 Security，随时可取 Availability，灵活收放 Scalability的特性。
未来的测试管理应该是
● 多种软件生命周期的组合 – V模型和敏捷开发敏捷测试的一体化；
● 多种测试组织形式的组合 – 内包、外包、研发测试人员角色互换，独立测试团队，第三方测试多种测试组织形式的一体化；
● 多种文化交融，超越地域分布，集目标管理、知识管理、人才管理、信息化管理为一体。
只有这样，我们才能与时俱进，适应新的形势发展，创造出新的测试管理艺术。
让我们听从内心的直觉，听从内心对美的呼唤和追求，一起去探索寻求21世纪新的测试管理艺术，并将这些艺术表现出来。因为正如法国古典印象主义画家埃德加.德加（Edgar Hilaire Germain de Gas）所说的：
“艺术不是你所看到的东西，而是你让别人看到的东西。”
-
软件测试管理摘抄
2013-02-16 16:20:40
软件测试管理常见问题及其回答
1、测试负责人要进行严格的测试进度跟踪吗？
很多时候，由于人力资源的不足，测试项目负责人都是在执行测试，这样就使整个项目缺乏控制，一些问题（例如：有些成员的缺陷质量不够合格；开发人员修改不及时，系统某些功能发生严重问题导致部分功能无法测试。）得不到解决，耽误了进度。所以测试负责任必须全程监控项目，尽可能多的掌握信息。通常，测试负责人需要完成下面这些内容的管理工作：
测试用例执行情况；
每个测试员提交的缺陷情况；
测试中是否发生突发问题。
2、 测试也有版本控制吗？
这里的版本主要是指测试对象的版本控制，也就是指对开发部提交的产品进行版本控制。在开发小组版本管理不规范的情况下，测试小组进行版本控制十分重要，要保证测试对象是可以控制的。建议开发和测试双方进行明确的约定，可以各自指定专门的测试版本负责人，制定提交原则，对提交情况进行详细的记录，这样基本避免了版本失控导致的测试失误或无效。
3、如何处理测试人员的流动问题？
人员流动不仅仅是测试部门，这是IT行业的普遍现象。从管理者角度，主管需要多多和团队内成员进行沟通，建立一个融洽的团队环境，及时掌握情况，可以早些进行相应的调整。但是只有企业建立好的用人制度，给员工提高广阔的发展空间和好的培训学习机会，才能从根本上解决这一问题。
加强项目管理，强化文档管理并保证文档的有效性，可以大大减少由于人员流失带来的损失。同时，测试部门要建立培训机制，使新到员工接受直接或者间接的培训，快速适应工作。
4、为什么开发人员经常抱怨测试工程师提交的缺陷质量太差？
我们经常听开发人员说：“这不是缺陷！”，“这个缺陷没有，因为我的系统上运行正常！”。测试工程师本身就是做质量工作的，提交的成果本身就应该质量高些，为什么还会有这种现象？
提交的缺陷引起争议是一种正常的现象，例如测试人员描述不清楚就会引起争议。减少甚至避免这种现象的方法是交叉测试，交叉测试是提高测试质量的一个有效手段，当然交叉测试会增加一定的测试成本投入。在测试任务完成后，测试工程师之间互相验证彼此提交的缺陷，就会避免了缺陷描述不清、因运行环境而产生的缺陷等一系列问题，从而大大降低了回归测试以及交流的成本，因而这种投入也是值得的，实际开发人员在单元测试阶段也会进行交叉测试，来提高开发质量。
另外，测试人员一定要按照规范描述测试中发现的缺陷，一个缺陷至少描述清楚概要描述、详细描述、重现步骤三方面的内容，缺陷管理参考第八章的内容。
5、“让那些新手来做测试，反正他们也不会什么”正确吗？
在实际项目开发中，我们常常看到有些单位忽视测试团队存在的意义，当要实施测试时，往往临时找几个程序员充当测试人员。也有些单位尽管认识到了组建测试团队的重要性，但在具体落实的时候往往安排一些毫无开发经验的行业新手去做测试工作，这常常导致测试效率低下，测试人员对测试工作索然无味。
根据笔者的经验，测试团队应首先聘请一名资深的测试领域专家，他应具有极为丰富的同类项目软件测试经验，对软件开发过程中常见的缺陷或错误了然于胸;此外，他还具有较好的亲和力和人格魅力。其次，项目测试团队还具有很多具备一技之长的成员，如对某些自动化测试工具运用娴熟或能轻而易举地编写自动化测试脚本等。
另外，测试团队还应聘请一些兼职成员，如验证测试实施过程中，同行评审是最常使用的一种形式，这些同行专家就属于兼职测试团队成员的范畴。至于测试团队里里的测试新手，这部分人可以安排去从事交付验证或黑盒测试之类的
6、测试同化现象是什么？
同化现象是指随着时间的推移，开发人员会逐渐影响测试人员的思维和对缺陷的判断能力，尤其是针对同一产品，同一组开发人员和同一组测试人员共同配合了很长时间，很多本来是缺陷的问题，由于测试人员对软件“习惯成自然”的使用，会不被当成缺陷，尤其是在开发人员的解释和说服下。同化现象发生可能意味着“恶性循环”的开始：测试人员会帮着开发人员解释一个个缺陷的合理性，一轮有一轮的测试都不会发现问题。
招聘新的人员，不同的测试项目组轮换去测试不同的产品，就可以避免。同时建议产品可以发布测试版，更多的人对其进行测试，就可以发现更多的问题。
7、测试工程师如何避免定位效应？
社会心理学家曾作过一个试验：在召集会议时先让人们自由选择位子，之后到室外休息片刻再进入室内入座，如此五至六次，发现大多数人都选择他们第一次坐过的位子。这种现象称为定位效应，说明人们习惯上凡是自己认定的，人们大都不想轻易改变它。
定位效应在开发人员和测试人员身上都有体现。例如开发工程师针对某一自己写的功能，经常进行代码移植，这种复制的“功能”，由于上一次经过调试，在新的地方往往不会认真调试，这些代码往往会带来共享变量冲突等许多种类型的缺陷。
定位效应体现在测试人员身上就是测试过的功能不再进行认真测试：在回归测试时，之前由于进行过认真的测试，往往会认为某些功能是可靠，只要验证一些以前发现的缺陷是否修改完成就可以了。这种现象在反复多次回归时表现的更加突出，因为回归测试中很多功能都会进行多次反复测试。众所周知，开发人员在修改缺陷时往往会引入新的缺陷，测试人员的疏于防范就会把这些缺陷带到用户这里。
解决这种问题的方案一般有两个：
(1)完整的执行测试用例：这种方法投入较大，但是在开发产品时最好在最后一次回归测试时测试的执行一次全部的测试用例。
(2)交叉测试：测试人员交叉测试，就可以很大程度的避免定位效应。测试工程师在回归测试时互相交换任务，反复测试某一功能的机会大大减少，从而也就不会“主观的”人员某些功能没有缺陷。
通常上面的两个方法都是结合使用的，既要进行交叉测试，又要全面执行测试用例，测试覆盖面要尽可能的广泛。
8、测试人员忽然辞职怎么办？
目前IT行业人员流动较大已经成为一种不争的事实，员工的辞职大多数都会给组织带来一定的影响，而这种影响基本是不可能避免的。在测试领域，员工忽然辞职也会带来很大的负面影响，尤其测试队伍规模较小时。面对这种情况，我们所能做的，就是如何最大限度的降低这种影响。
根据作者的经验，主要有两种方法：第一种是在测试人员内部建立一个良好的学习环境，大家互相学习，这样某些特有技术不会被某一个人所掌握，而互相学习和提高自身，也是大多数成员愿意做的；第二种就是在组织中进行知识管理，把技术作为知识沉淀下来，这样新的员工在接手工作时容易上手，通过学习快速适应环境。
此外，日常还要注意工作规范化，例如形成尽可能多的文档，都可以降低员工离职带来的损失。
9、测试人员工作发生问题测试经理应该如何做？
测试人员工作发生问题是测试经理经常要面对的问题，作为测试部门的领导，首先要做的是指出测试人员所犯的错误，使其尽快改正错误。
唯一不能做的就是盯着下属的错误不放。总盯着下属的失误，是一个领导者的最大失误。英国行为学家波特说：当遭受许多批评时，下级往往只记住开头的一些，其余就不听了，因为他们忙于思索论据来反驳开头的批评。身为测试经理要根据测试人员的心理来进行指导，最大限度的调动每个人员的积极性来参加工作。
10、不深入到具体测试工作时，测试经理如何考核员工？
这种现象在测试规模较大的组织中很常见。测试经理应该尽可能的安排每周与每个成员在不被打扰的环境下进行谈话，这样可以尽早发现和解决很多问题。
最为一个测试经理，主要工作之一就是定期的评定组织做了些什么并且是怎样做的。同时还要为员工做一个报告——关于充分了解测试人员正在做什么和怎样做的报告，以此来给测试人员做做工作成绩考核。这份报告要了解到每个人的动态。
测试经理和每个员工重点是谈谈目前的工作，例如大家在工作中的问题或意见；是否需要帮助等。许多管理者经常抱怨没有时间在一周会见每一个员工来谈他们的工作。但是根据作者的经验，如果不能安排时间和员工进行每周的谈话，员工会来打扰测试经理的工作，因为员工很多问题还要要来找测试经理商议。
同时对待员工要用他们能接受的方式，而不是我们自己可以接受的方式。“己之不予，勿施于人”，这条黄金法则可能会对许多生活中的纯粹的社交因素有效，但是并不是总对工作有用。有效率的管理者知道应该逐渐了解每一个员工需要怎样的对待方式。
总之，只有尽可能多的和员工接触，才能更精确的进行考核。
11、测试经理如何面对加班问题？
大多数情况下，作者是不主张加班的。当员工每周工作超过40个小时的时候，他们开始在工作的时候关心自己的事。他们花钱，会给很久没有联系的人打电话，因为员工们一直都在工作。员工不能在太疲劳的状态下完成工作，这是因为他们在工作时不能关心自己，这种情况下通常效率很低。
测试管理工作的重要任务之一就是要创造一个环境，让员工在工作时间内完成工作，同时还要鼓励他们每周不要超过40小时，甚至可以基于他们在40个小时能够完成的工作量给他们酬劳。通常情况下这样做能够提升创造力，从而会逐渐提高效率。
测试工作本身的一个突出特点就是不断重复枯燥、冗长的测试，如果在疲劳状态下，很有可能精力不集中，略过一些重要的测试环节。而且有的时候测试需要编写测试驱动程序，这种情况更需要较好的状态来工作。
12、测试管理者如何面对自己的错误？
每个人都会犯错。我们可能会因为忘记开会而使客户发怒，承认自己犯错是一件尴尬的事情，尤其是管理人员认为对自己负责的项目小组承认犯错可能会失去尊严。如果我们不是经常犯错，承认错误的时候其实能够赢得尊敬。例如我们忘记一次会议，然后为此向同事或者客户道歉，其他的人会理解我们的。
不管做了什么，不要否认或故意忽略自己的失误。故意忽略不会让错误消失，这只会让错误成长为怪物。
13、为什么计划定期的培训?
测试工作和开发工作一样，不但要面对日新月异的新技术，还要学习相关系统的领域知识。只有在不断的学习中，才能做好工作，跟上行业的发展。如果测试管理者没有基于不断的变化而培训员工，就会给组织带来一定的损失。日常培训可以是关于特定项目或者是技术，通常采用下面几种方法：
（1）测试部门内自由交流方式的培训。这种培训的交流比较随意，可以在周五的例会上进行交流，也可以大家一起坐在茶馆里进行交流。方法可以采用“头脑风暴法”，让每个组员讨论一个特定的领域，这种交流方法特别对同时要做很多不同项目的小组比较有益处。当每个人做不同的项目，这会有助于每个人了解你小组所有的工程。
（2）跨部门的互相学习。测试工作需要很多领域以及技术知识，这些知识单靠自学是远远不够的。和其它部门的同事进行交流是一个相当好的办法，大家在工作中可以在技术等各个方面互相得到提高。
（3）外部培训。外部培训尽管投入较高，但也是值得的。这些专家一般在自己的领域非常精通，可以快速提高整个测试团队的水平。也可以通过测试小组介绍一些朋友来进行培训，这种方式可以降低成本。
培训是构造学习型组织的基本条件，也是提高员工水平的重要方法。经常的定期培训，可以增强组织凝聚力，使员工更加愿意长期留在组织中发展。做为测试负责人，定期的进行培训是十分必要的。
14、时间上不允许进行全部测试，测试负责人应该如何做？
这个问题也许十分可笑，可是现实中我们的测试经理们却不得不面对这个问题。这里的全部测试不是指对软件进行遍历测试，而是指测试负责人制定的测试计划包含的全部测试内容。
通常，不管是开发产品还是做具体的项目，都会发生耽误进度的情况。一旦整体进度不能向后延迟，项目相关人员习惯上的做法就是缩减测试时间。尤其在功能还没有开发完成的情况下，这种现象更为突出。
担负着质量重任的测试经理，如何来解决这个问题呢？比较好的做法是按照下面的步骤逐步来完成和改进工作：
（1）按照测试任务的轻重缓急，尽最大努力完成测试任务。在时间不足的情况下，我们应该对测试任务按照优先级来划分，重要紧急的任务先完成。这个时候的测试任务是一种辅助性工作，其目的就是尽最大努力来提高质量。因此，面对这种情况，测试负责人要做的就是带领测试小组充分利用所有资源来保证质量。
（2）在实际工作中和开发人员共同配合，逐步改进工作。只有整个团队的软件开发能力提高了，才能从根源上解决问题。因此，测试负责人要带领团队和开发小组共同寻找适合自己的开发模式，从而使项目规划的更加合理，进而按照预定计划来开展测试工作。
总之，在任何情况下，测试负责人都不应该抱怨。只有积极的面对问题，才能更好的解决问题。
15、公司不重视测试，测试负责人如何开展测试工作？
目前国内的软件公司不重视测试仍然是一种普遍现象。尽管很多公司在意识上已经开始重视测试，但是在具体工作中，往往由于追赶进度、节省资源等方面原因而忽略测试工作。在这种情况下，测试负责人仍要对软件质量负主要责任。在这种环境下，测试负责人应该如何开展工作呢？
首先，要主动去配合开发人员完成工作。尤其是不能抱怨环境，在任何情况下抱怨是不能解决问题的，只能加重矛盾的激化。在此基础上，逐渐显出测试工作的重要性，然后再逐步健全测试体系。
其次，用实际行动来证明测试工作的重要性。只有测试工作的业绩逐步表现出来，人们才会真正的注意到测试的重要性。因此，测试负责人从点滴开始做起，才能逐步做好测试工作。
要想做好软件，把开发的软件产品形成商品，测试工作必须和开发一样重视。否则，质量不好的产品，很快会被市场淘汰的。现代的软件规模越来越大，测试工作也会越来越重要，因此测试负责人只要坚持做好工作，可发挥作用的空间会越来越大。
最后要说的是，如果真的是在一个没有希望的团队里，测试负责人可以考虑辞职。辞职也是一个不错的选择，到新的环境去发挥自己的能力，要比长时间的怀着“郁闷”的心情去工作好的多。
16、测试管理者需要是技术专家吗？
测试管理者在测试项目中的主要任务是制定测试策略，管理测试计划的落实情况，并且还要为测试项目的进行创造良好的执行环境。同时还要调动员工的创造性，对员工的工作作出评估。这些工作不一定要求测试管理者达到专家的水平。
但是在实际工作中，由于测试人员的短缺，测试管理者常常做为测试员来执行具体的测试任务。尤其在规模较小的测试团队，测试管理者的日常工作通常以具体的测试执行工作为主，这个时候更需要测试管理者有较好的背景知识。
总体说来，技术方面的背景知识对测试管理者是十分有益的。例如：分配工作任务、做进度预算，以及一些具体的执行工作，都需要一定的背景知识。当然，做为一个测试管理者，没有必要精通所有的技术，那也是办不到的。测试管理者做到正确的帮助员工最好地完成工作，并且提供最好的完成工作的环境就可以了。 -
Heuristic Test Strategy Model
2011-11-03 15:25:46
从今天起开始翻译一些英文的测试类技术文章，帮助自己的英语水平，也稍微学点东西。
今天看的是James Bach写的Heuristic Test Strategy Model。 不一定有时间全部看完，能看多少是多少吧。
Heuristic Test Strategy Model
Heuristic Test Strategy Model是一套提供设计测试策略的模型。这套模型可以指导测试人员介入测试时需要考虑到哪些方面。
项目环境：在项目过程中然我们更好工作的资源、约束和其他被测产品产品中强制条件，确保我们使用的资源都是有效。
产品组成：你即将要测试的所有事项，软件是由很多个组件看不见的组合在一起的，你需要仔细的检查你即将测试的每一个组件。
质量基准是指一个测试人员评判一个产品是否有问题的一个标准或者是一个标准值。这个指标是多维的，通常是隐藏的或者自相矛盾的。
测试技巧是在测试前的一些策略，所有的技巧是建立在各种项目环境分析，产品原理分析，质量基准之上的。
品质认知度是测试的结果。你永远也不知道产品实际的质量，但是通过各种对用应用程序的测试，你能够了解到产品大致的情况是怎么样的。
一些普遍的测试技巧
有很多有趣的测试技巧，以下包括了就个常用的测试技巧
未完成。。待续。。
-
测试总结及分析报告模板
2010-07-09 10:48:05
目 录
-
测试结果分析
2010-06-22 16:14:34
测试过程质量度量应该包括
1. 缺陷度量或者缺陷分布度量(包括分布统计和密度)
2. 测试用例的深度、质量、覆盖率和有效性
3. 测试执行的效率和质量(例如执行率、通过率等)
4. 缺陷报告的质量
5. 测试覆盖率(测试整体的质量)
6. 测试环境的稳定性或者有效性
测试用例的度量
A. 测试用例的深度、质量和有效性
测试用例深度(TEST Case Depth TCD): 每千行代码(KLOC)的测试用例数or每个功能点/对象点的测试用例数
测试用例的效率: 每100或者1000个测试用例所发现的缺陷数来衡量
测试用例质量(Test Case Quality, TCQ)=测试用例发现的缺陷数量/总的缺陷数量
-
转:杯子的测试
2010-05-20 10:55:27
测试项目：杯子
需求测试：查看杯子使用说明书，是否有遗漏。
界面测试：查看杯子外观，是否变形；
功能性：用水杯装水看漏不漏；水能不能被喝到；
安全性：杯子有没有毒或细菌；
可靠性：杯子从不同高度落下的损坏程度；
可移植性：杯子再不同的地方、温度等环境下是否都可以正常使用
可维护性：把杯子捏变形，然后看是否又能恢复
兼容性：杯子是否能够容纳果汁、白水、酒精、汽油等
易用性：杯子是否烫手、是否有防滑措施、是否方便饮用
用户文档：使用手册是否对杯子的用法、限制、使用条件等有详细描述
疲劳测试：将杯子盛上水（案例一）放24小时检查泄漏时间和情况；盛上汽油（案例二）放24小时检查泄漏时间和情况等
压力测试：用根针穿杯子，并在针上面不断加重量，看压强多大时会穿透
跌落测试：杯子加包装(有填充物),在多高的情况摔下不破损
震动测试：杯子加包装(有填充物),六面震动,检查产品是否能应对恶劣的铁路\公路\航空运输
测试数据：测试数据具体编写此处略（最讨厌写测试数据了）。其中应用到：场景法、等价类划分法、因果图法、错误推测法、边界值法等方法
期望输出：该期望输出需查阅国标、行标以及使用用户的需求
说明书测试：检查说明书书写准确性 -
测试计划
2010-05-18 16:33:20
1. 引言
1.1 编写目的
说明编写这份文档的目的，指出预期的读者。
1.2 限制条件
本测试计划受限于产品开发人员提交测试的内容和时间的事实。根据开发人员提交模块的实际情况，本计划会做出相应的修改。
1.3 定义与缩写
定本文档中用到的专业术语和外文缩写的原词句。
1.4 参考资料
列出编写本文档时参考的文件、资料、技术标准以及他们的作者、标题、编号、发布日期和出版单位，说明能够得到这些文件资料的来源。对于每个测试项，如果存在测试计划、测试设计说明、测试规程说明、测试项传递报告、测试日志和测试事件报告等文件，则可以引用它们。
2. 测试项
2.1 系统概述
归纳所要求测试的软件项和软件功能，可以包括产品/系统名称，版本/修订级别，系统目标、背景、范围。
2.2 主要业务流程
描述软件测试中主要的业务流程，便于设计测试流程。
2.3 测试项定义
描述呗测试的对象要进行的测试类型、测试项，并指出在测试开始之前对逻辑或者物理变换的要求。
3. 被测试项的特性
指明所有要被测试的软件特性及其组合，指明每个特性或者特性组合有关的测试设计说明。
4. 不被测试项的特性
指出不被测试所有特性和特性的有意义的组合及其理由。
5. 测试目标
描述项目的测试目标、项目过程和特定质量保证目标。在此只能定义与测试相关的目标。给出测试项的通过准则。
6. 测试设计
6.1 测试方法
描述测试的总体方法，规定测试指定特定功能组所需的主要活动、技术和工具。应详尽的描述方法，以便列出主要的测试任务，并估计执行各项任务所需的时间。规定所希望的最低程度的测试完备性，指明用于判断测试完备性的技术（如检查哪些语句至少执行过一次）。指出对测试的主要限制，例如对测试项的可用性、测试资源的可用性和测试截止期限等。
6.2 测试项通过准则
规定各测试项通过测试的标准。
说明用来判断测试工作是否能通过的评价尺度，如合理的输出结果的类型、测试输出结果与预期输出之间的容许偏离范围、允许中断或停机的最大次数。
6.3 测试资源
列出本项测试所需的软/硬件资料，包括测试脚本、必要的桩模块和驱动模块、附属媒体等。
7. 暂停标准和再启动要求
规定用于暂停全部和部分与本计划有关的测试项的测试活动的标准。规定当测试再启动时必须重复的测试活动。
8. 应提供的测试文件
列出测试过程中应提交的所有文件。
9. 测试任务和测试进度
9.1 测试任务
指明执行测试所需的任务集合，指出任务间的一切依赖关系和所需的一切特殊技能。
如：测试计划、测试设计、测试用例、测试执行以及测试总结之间的依赖关系。
9.2 测试进度
包括在软件项目进度中规定的测试里程碑以及所有测试项的提交时间。定义所需的新的测试里程碑，估计完成每项测试任务所需的时间，为每项测试任务和测试里程碑规定进度，对每项测试资源规定使用期限。
10. 物理资源
10.1 环境要求
规定测试环境所必备的和所希望有的性质。包括硬件、通信和系统软件的物理特性，使用方式以及任何其他支撑测试所需的软件或设备，以及其他测试要求（如打印机或场地等）。
指出测试组目前还不能得到的所需的资源。
软件包括操作系统、通信软件、保密安全、测试工具、必备的前期文档等。
10.2 测试工具
指出所需的测试工具
11. 职责
指出负责管理、设计、准备、执行、监督、检查和仲裁的小组、这些小组可以包括开发人员、测试人员、操作员、用户代表、数据管理员和质量保证人员。
12. 人员和培训要求
指明测试人员应有的水平以及为掌握必要技能可供选择的培训。
引用资料或者直接说明需要为软件使用者提供培训的计划。规定培训的内容、受训的人员以及从事培训的工作人员。
13. 风险和应急
预计测试过程中的风险，规定对各种风险的应急措施，例如，延期提交的测试项可能需要加班来赶上规定进度。本章节不应重复在其他文档中描述的风险，除非与测试相关的方面还未处理。
-
UAT用户可接受度测试之个人总结
2010-05-06 17:05:57
首先, 谈到UAT测试就不得不谈验收测试了,而验收测试分为两种即 Alpha和Beta测试,以下是对于这两种测试的摘抄:
大型通用软件，在正式发布前，通常需要执行Alpha和Beta测试，目的是从实际终端用户的使用角度，对软件的功能和性能进行测试，以发现可能只有最终用户才能发现的错误。
Alpha测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由程序员或测试员完成。Alpha测试发现的错误，可以在测试现场立刻反馈给开发人员，由开发人员及时分析和处理。目的是评价软件产品的功能、可使用性、可靠性、性能和支持。尤其注重产品的界面和特色。Alpha测试可以从软件产品编码结束之后开始，或在模块（子系统）测试完成后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。有关的手册（草稿）等应该在Alpha测试前准备好。
Beta测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。因而，Beta测试是在开发者无法控制的环境下进行的软件现场应用。在Beta测试中，由用户记下遇到的所有问题，包括真实的以及主管认定的，定期向开发者报告，开发者在综合用户的报告后，做出修改，最后将软件产品交付给全体用户使用。Beta测试着重于产品的支持性，包括文档、客户培训和支持产品的生产能力。只有当Alpha测试达到一定的可靠程度后，才能开始Beta测试。由于Beta测试的主要目标是测试可支持性，所以Beta测试应该尽可能由主持产品发行的人员来管理。
由于Alpha和Beta测试的组织难度大，测试费用高，测试的随机性强、测试周期跨度较长，测试质量和测试效率难于保证，所以，很多专业软件可能不再进行Beta测试。随着测试技术的提高，以及专业测试服务机构的大量涌现，很多软件的Beta测试外包给这些专业测试机构进行测试。根据以上可以理解为Alpha测试时在有开发人员参与的情况下进行测试,根据以上的理解是不管是Alpha测试还是Beta测试都是不能由测试人员和开发人员来完成的.这一点方面我有一些不同的见解,也问过资深的一些专家,Alpha测试是可以由测试人员来完成的.而Beta测试不可以.另外一篇摘抄的文件如下关于两者的区别和共同点.
一、共同点：
两者的目的都是从实际终端用户的使用角度，对软件的功能和性能进行测试，以发现可能只有最终用户才能发现的错误。
二、区别：
A alpha测试是一个用户在开发环境下进行的测试，beta测试是一个或多个用户在实际环境下进行的测试
B alpha测试是公司内部的用户在模拟实际操作环境下的受控测试。beta测试是在开发者无法控制的环境下进行的软件现场应用。
C alpha测试发现的错误可以现场立及反馈给开发人员，及是分析和处理。beta测试中，用户记下所有的问题，定期向开发者报告，开发者在综合用户的报告后，做出修改，最后将软件产品交付给全体用户使用。
D alpha测试达到一定程序后，才能开始beta测试。
E beta测试的主要目标是测试可支持性。
所以根据以上说明,Alpha测试是可以在公司的模拟环境下,有开发人员参与修改的环境下由测试人员或者资深的业务人员进行测试的.而beta测试是由最终实际环境下,开发人员无法控制的环境下进行测试,而使用者可能是最终用户也可能是资深的业务人员.
回到之前的那个问题,UAT测试,根据以上的资料几乎就可以看出,UAT测试包括了beta测试,几乎beta测试也涵盖了UAT测试,这个测试主要的优缺点为
Beta 测试由最终用户实施，通常开发（或其他非最终用户）组织对其的管理很少或不进行管理。Beta 测试是所有验收测试策略中最主观的。
这种测试形式的优点是：
· 测试由最终用户实施。
· 大量的潜在测试资源。
· 提高客户对参与人员的满意程度。
· 与正式或非正式验收测试相比，可以发现更多由于主观原因造成的缺陷。
缺点包括：
· 未对所有功能和/或特性进行测试
· 测试流程难以评测
· 最终用户可能沿用系统工作的方式，并可能没有发现或没有报告缺陷。
· 最终用户可能专注于比较新系统与遗留系统，而不是专注于查找缺陷。
· 用于验收测试的资源不受项目的控制，并且可能受到压缩。
· 可接受性标准是未知的。
· 您需要更多辅助性资源来管理 Beta 测试员验收测试过程
1. 软件需求分析：了解软件功能和性能要求、软硬件环境要求等，并特别要了解软件的质量要求和验收要求。2. 编制《验收测试计划》和《项目验收准则》：根据软件需求和验收要求编制测试计划，制定需测试的测试项，制定测试策略及验收通过准则，并经过客户参与的计划评审。
3. 测试设计和测试用例设计：根据《验收测试计划》和《项目验收准则》编制测试用例，并经过评审。4. 测试环境搭建：建立测试的硬件环境、软件环境等。（可在委托客户提供的环境中进行测试）5. 测试实施：测试并记录测试结果。
6. 测试结果分析：根据验收通过准则分析测试结果，作出验收是否通过及测试评价。
7. 测试报告：根据测试结果编制缺陷报告和验收测试报告，并提交给客户。但是以上所有的测试都必须经过足够的内部测试,才能够执行UAT测试, 执行测试之前需要准备的文档有
●主要的开发类文档：《需求分析说明书》、《概要设计说明书》、《详细设计说明书》、《数据库设计说明书》、《测试计划》、《测试报告》、《程序维护手册》、《程序员开发手册》、《用户操作手册》、《项目总结报告》。
●主要的管理类文档：《项目计划书》、《质量控制计划》、《配置管理计划》、《用户培训计划》、《质量总结报告》、《评审报告》、《会议记录》、《开发进度月报》。就这些文档来说是可以根据一些具体的情况而裁剪掉一些文档的, 但是就测试部门必须提交给客户的文档应该是要包括一下内容的(某些文档可以复用测试阶段的计划和用例,但是需要修改个别地方,以及对特殊方面进行说明,比如业务的逻辑性,业务的特殊性,以及实际环境包括数据的差异性.)
1. 验收测试计划
2. 验收测试用例(可以视情况省略)
3. 验收测试缺陷报告模板(此模板与内部模板不同,可以对在内部一个缺陷一个报告的模板上给予简化,甚至是只是给予一个报告模板描述所有的缺陷以及改进建议)
4. 系统安装手册(如果有安装部署方面的测试,大多是C/S架构程序)
5. 系统操作指南
6. 软件验收标准(软件验收和通过标准也可以放置到验收测试计划中说明)
根据验收测试以后会有一些后期的跟踪,如果客户或者资深业务人员没有提出任何的缺陷建议,那么本程序版本已经可以放置到产品库,作为Release版本正式提交给客户了;那么如果提出了相关的改进建议的话,测试人员就要对这些改进进行跟踪以及再次的测试了.
4. 其他摘抄
UAT测试步骤及重点
什么是UAT测试
UAT，(user acceptance Test),用户接受度测试 即验收测试
以下是它的一些一般步骤；仅供参考
一步:用户培训手册准备（就是针对要进行UAT测试的对象，及要进行培训的用户，准备一些培训资料：一般是测试对象使用/功能手册及要培训的用户的个人资料等等：就跟教师上课进行备课差不多）
二步：测试脚本发放（如果你公司采用自动化测试，那么每一个功能或一个模块等都有对应的测试脚本，可以把这些测试脚本分发给特定的人员；如果采用手工测试，就要把详细描述一个功能或模块的文档分给相关人员（当然自动化测试也要分发））
三步：用户补充业务测试场景和测试数据（就是：请有代表性的一些最终用户根据实际应用环境及一些常用处理的数据，来给一些补充与建议，越贴近实际应用越好）
四步：顾问补充测试步骤（你可以请项目专家，测试经理，或专门的测试，开发等顾问对测试步骤进行补充）
五步：培训资料及测试脚本文档的确定与最终输出(一般到此，各种资料都基本确定，这时可以将它们进行打印，或形成特别的电子文档）
六步：测试策略的制定（如嵌入测试策略等，http://www.51testing.com/cgi-bin ... 2%CA%D4%B2%DF%C2%D4）
七步：测试用户的确定（大体上从培训人员中选取，因为不是每个接受培训的人员都能有资格去测试的，这里你可以通过一些考核来实现人员的筛选等等）
八步：由专门的测试组织机构确定测试地点，并发出通知
九步：测试网络环境的搭建和保障（包括网络，系统，硬软件，包括一些case工具等）
十步：组织进行测试
十一步：评审分析提交的问题（这就进入了一般bug处理过程，形成了一个循环）
UAT测试的重点,我想主要体现在以下几个方面
一是：培训的资料表述要准确全面，易懂等（这是理论基础）
二是：人员选择，要典型有代表性（用户基础）
三是：测试流程步骤（要周密）
四是：测试策略制定（确定一个适合测试对象及测试人员的测试策略）
五是：问题的表达与处理(因为测试者不是专业开发测试人员，对于问题的表达可能不能到位，或根本就不是那种问题，这就存在如何复现与转化问题等）
UAT测试与SIT测试
SIT是集成测试
UAT是验收测试
从时间上看，UAT要在SIT后面，UAT测试要在系统测试完成后才开始。
从测试人员看，SIT由公司的测试员来测试，而UAT一般是由用户来测试(或者有本行业背景的人员执行)。恩恩..以上就是个人今天的总结了,如果有其他的与本文档不符合的会陆续更新.呵呵.
-
关于性能测试的 I/0指标
2010-05-05 16:22:53
下面是一些衡量I/O 闲忙程度的经用指标：
磁盘利用率(disk utilization) ；磁盘队列长度(disk queue length) ；
磁头/逻辑卷的读/写速率(read/write rates per spindle/logical volume) ；
原始I/O(raw I/O)：主要用于数据库应用；
交换队列的长度(swap queue length) ；
缓存命中率(buffer cache hit ratio) ；
网络文件系统和无盘工作站速率(NFS and diskless rates(server)) ；
I/O 资源成为系统性能的瓶颈的征兆：
当I/O 成为瓶颈时，会出现下面这些典型的症状：
过高的磁盘利用率(high disk utilization)
太长的磁盘等待队列(large disk queue length)
等待磁盘I/O 的时间所占的百分率太高(large percentage of time waiting for disk I/O)
太高的物理I/O 速率:large physical I/O rate(not sufficient in itself)
过低的缓存命中率(low buffer cache hit ratio(not sufficient in itself))
太长的运行进程队列，但CPU 却空闲(large run queue with idle CPU) -
读书笔记之灰盒测试汇总
2010-05-05 16:11:51
今天突然想了解一下灰盒测试,于是去发掘了一些文章汇总了一下
“灰盒测试，确实是介于白盒测试与黑盒测试之间的，可以这样理解，灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒的方法。
灰盒测试结合了白盒测试和黑盒测试的要素。它考虑了用户端、特定的系统知识和操作环境。它在系统组件的协同性环境中评价应用软件的设计。
灰盒测试由方法和工具组成，这些方法和工具取材于应用程序的内部知识和与之交互的环境，能够用于黑盒测试以增强测试效率、错误发现和错误分析的效率。
灰盒测试涉及输入和输出，但使用关于代码和程序操作等通常在测试人员视野之外的信息设计测试。”
灰盒测试我的理解，灰盒测试是运用工具及开发知识，寻找软件黑盒的测试点。 灰盒测试属于黑盒测试的一部分，也是对一个黑箱子进行测试，只是灰盒测试点增加黑盒测试路径，也是黑盒测试人员的更高的境界。
灰盒测试是要运用一些开发知识的，大家都认为要去学习开发知识。网上很多论坛也有人说做测试之前，最好要有一、二年的开发经验就比较好。做为黑盒测试人员，如果会当然好，但是大部分黑盒测试人员是没有开发经验，这里我谈谈黑盒测试人员学习什么，怎么去学习。
1、多看、多分析、多总结缺陷
测试人员应该多去看别人的发现的缺陷，特别是一个模块后，你测试完成后，别人再测试，心里一定要多问他为什么可以发现这些缺陷，你没有发现。多分析缺陷发生的原因，是由于开发人员业务不是很了解，还是在设计的问题，还是开发人员态度的问题。可以分类汇总发现的缺陷，也可以总结开发人员常犯的缺陷。
2、和开发做朋友，充分交流。
当发现一个缺陷时，我们应该了解缺陷发现的原因及一些原理。这些缺陷发现的原因只有开发人员很清楚，需要他跟你讲解。只有多和开发人员交流，你对缺陷发现的原因慢慢了解，你的水平才会得到提升。
在界面上你看不到的一些字段，往往是造成一些非常难发现的缺陷，因为这些字段是用来做控制作用。也可以利用数据库知识进行SQL注入。
4、学习工具
可以利用一些工具，方便我们去了解开发相关的知识，比如：Charles能够让我们查看所有网络和机器之间的HTTP流量情况。包括请求、响应、HTTP头信息(包含cookies和缓存)等。
在测试领域众所周知存在黑盒测试和白盒测试，黑盒测试更多是在集成测试阶段进行只关注应用是否符合需求，而不关心代码设计的结构，方式，方法。而白盒测试是针对黑盒测试提出的，前提是知道软件产品内部工作过程。通过测试来检测软件产品内部动作是否按照规格说明书的规定正常进行，通常是在单元测试阶段进行。那么做了这两种测试是否覆盖了软件测试的全部内容，即是否就能保证产品的质量呢。其实是不一定的，或者说如果靠这两种方法来覆盖，投入的代价是比较大的。譬如目前很火的OPEN API的测试，譬如对具备软件平台性质产品的测试。因为通过黑盒手工测试是很难完成的，而白盒测试是在单元测试进行的，显然对产品的测试带来很大的局限性，它也无法测试到产品在集成过程中带来的问题。那么灰盒测试就有它出现的必然性，这就是所谓存在就是合理的。
灰盒测试的特性：
1. 灰盒测试通常是在集成测试前期进行的。灰盒测试通常在程序员做完白盒测试之后（有些书上认为白盒测试是由测试人员进行的，我觉得纯属理想主义），在功能测试人员进行大规模集成测试之前进行的。
2. 灰盒测试是需要了解代码工程的实现的
3. 灰盒测试是通过类似白盒测试的方法进行的，也就是说和白盒测试的方法是相同的，是通过编写代码，调用函数或者封装好的接口进行的。
4. 灰盒测试是由测试人员进行测试的。
灰盒测试和白盒测试的区别
1. 测试的时段不同，白盒测试在单元测试阶段进行，灰盒测试在集成测试前期进行
2. 测试的关注对象不同，白盒测试更关注内部实现是否按照规格说明书进行，灰盒测试除了需要关注白盒测试关注的内容还更多从业务层面去考虑问题，考虑更多的组合测试业务场景。
3. 范围不同，白盒测试更关注单个代码段，函数的正确性，灰盒测试的对象已经基本能完成一个完整的业务功能。
4. 灰盒测试的代码比较独立，不像白盒测试基本上和程序代码需要做到一一对应。
灰盒测试和白盒测试的相同点
1. 目的相同
2. 方法相同，都是需要通过代码来实现
3. 对测试人员素质要求相同
灰盒测试和黑盒测试的不同点
1. 测试的方法不同。
2. 对测试人员要求不同。灰盒测试要求比较强的编程能力。
3. 测试范围不同，关注的对象不同，黑盒测试是覆盖产品范围最广的测试，是灰盒测试无法取代的。但是灰盒测试是可以被黑盒替代的，只是代价比较大，需要很多的测试用例。
灰盒测试和黑盒测试的相同点
1. 目的相同
2. 测试所处的时间段相近。
黑盒测试、白盒测试和灰盒测试的基本概念
1.黑盒测试
黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。
黑盒测试方法主要有等价类划分、边值分析、因—果图、错误推测等，主要用于软件确认测试。“黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。2.白盒测试
白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。
“白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。“白盒”法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。贯穿程序的独立路径数是天文数字。但即使每条路径都测试了仍然可能有错误。第一，穷举路径测试决不能查出程序违反了设计规范，即程序本身是个错误的程序。第二，穷举路径测试不可能查出程序中因遗漏路径而出错。第三，穷举路径测试可能发现不了一些与数据相关的错误。3.灰盒测试
灰盒测试，确实是介于二者之间的，可以这样理解，灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒的方法。
灰盒测试结合了白盒测试盒黑盒测试的要素.它考虑了用户端、特定的系统知识和操作环境。它在系统组件的协同性环境中评价应用软件的设计。
灰盒测试由方法和工具组成，这些方法和工具取材于应用程序的内部知识盒与之交互的环境，能够用于黑盒测试以增强测试效率、错误发现和错误分析的效率。
灰盒测试涉及输入和输出，但使用关于代码和程序操作等通常在测试人员视野之外的信息设计测试。 -
读书笔记之测试计划
2010-05-05 15:23:27
无论做什么工作，都是计划先行，然后按照所制定的计划去执行、跟踪和控制。软件测试也一样，先要制定测试计划，是做好整个测试工作的前提。所以在进行实际测试之前，应制定良好的、切实可行的、有效的测试计划。软件测试计划的目标是提供一个测试框架，不断收集产品特性信息，对测试的不确定性（测试范围、测试风险等）进行分析，将不确定性的内容慢慢转化为确定性的内容，该过程最终使得我们对测试的范围、用例数量、工作量、资源和时间等进行合理的估算，从而对测试策略、方法、人力、日程等做出决定或安排。
1．测试计划的要点
测试规划与软件开发活动同步进行，在需求分析时，就开始测试策划，确定测试需求、目标、资源等。测试计划可以按不同的测试阶段（集成测试、系统测试等）来组织，也可以为每个测试任务或目标(安全性、性能、可靠性等测试) 进行考虑。
测试计划主要集中在测试目标、质量标准、测试策略、测试范围、测试用例设计方法、所需资源和日程安排等，其关键是制定有效的测试策略，界定清楚地测试范围，识别出测试中所存在的各种风险并找出风险回避、监控和管理的方法，针对不同的测试目标或阶段确定测试方法，对测试工作量及所需的资源、时间进行合理的估算。所有这些，都是为了两个根本目的：测试的质量和效率。
2．制定测试策略
制定测试策略主要分析测试的目标和质量指标、确定测试的对象和依据，测试的重点和所采用的方法，包括在规定的时间内哪些测试内容要完成，软件产品的特性或质量在哪些方面得到确认。测试策略可以分为：
- 基于测试技术的测试策略，根据软件系统的技术构成和层次结构，着重考虑如何分层测试、选择哪些测试工具、如何将白盒测试和黑盒测试有机地结合起来等。
- 基于测试方案的综合测试策略，根据测试的目标和范围，着重考虑如何更好地满足测试需求、如何让功能测试、适用性测试和兼容性测试等进行有机结合、如何充分利用测试资源、如何更有效地完成回归测试等。
- 全面细致地了解产品的项目信息：应用领域、测试范围、市场需求、产品特点、主要功能和技术架构；
- 基于模块、功能、系统、版本、性能、配置和安装等各个因素对产品质量的影响，客观地、全面地展开测试计划；
- 根据软件单元在系统结构的重要性差异和一旦发生故障将给客户造成的损失大小，来确定软件测试的等级、重点和先后次序；
- 需要在测试用例数和测试覆盖率上进行权衡而获得一个平衡点，以便能使用尽可能少的有效测试用例去发现尽可能多的程序错误。测试不足意味着让用户承担隐藏错误带来的危险；同时反过来看，过度测试则又会浪费许多宝贵的资源或耽误软件产品的发布时间。
3．确定测试范围
测试主要依据 “产品设计规格说明书”、代码所发生的变化及其影响的区域，来确定哪些功能和特性要测试，哪些功能和特性不需要测试。在确定测试范围时，主要考虑的因素有：
- 优先级最高的需求功能
- 新增加的功能和编码改动较大的已有功能
- 容易出现问题的部分功能
- 过去测试不够充分的地方
- 经常被用户使用的功能和配置（占20%）
4．所需资源和日程安排
为了合理、准确地安排日程，对测试工作量要进行正确的估计。除了对工作量的估计之外，还要正确评估参与该项目人员的培训时间、适应过程和工作能力等。由于涉及到不同的项目、不同的测试人员、不同的前期介入方式，要对每人每天能够完成的平均测试用例数目做出一个准确的估计确实很困难，但是可以根据以前一些项目测试的经验或历史积累下来的数据进行判断推理，并适当增加10%-20%的余量，估算结果就比较准确了。
在估算的基础上，进行有效的、合理的资源安排。在不同的测试阶段人力资源的需求是不一样的，所以人力资源的计划要有一定的灵活性和动态性，形成有机的动态平衡，保证测试的进度和资源的使用的效率。
5．编制测试计划的技巧
要做好测试计划，测试设计人员要仔细阅读有关资料，包括用户需求规格说明书、设计文档等，全面熟悉系统，并建议注意以下方面：
- 让所有合适的相关人员参与测试项目的计划制定，特别是在测试计划早期；
- 测试所需的时间、人力及其它资源的预估，尽量做到客观、准确、留有余地；
- 测试项目的输入、输出和质量标准，应与各方达成一致；
- 建立变化处理的流程规则，识别出在整个测试阶段中哪些是内在的、不可避免的变化因素，加以控制。
6．测试项目计划的评审
测试项目的计划不可能一气呵成，而是要经过计划初期、起草、讨论、审查等不同阶段，才能将测试计划制定好。测试计划的评审是完成测试计划关键的一个环节，包括测试组织内部的自我评审、讨论和修改，然后交到评审会进行正式的评审，直至测试计划得到审批。
测试计划的正式评审，项目中的每个人（产品经理、项目经理、开发工程师等）都应当参与。计划的审查是必不可少的，每一个参与者都可能根据其经验及专长提出问题或建议，弥补在测试范围、工作量、风险等各方面的不足，进一步完善测试计划。 -
VM server服务器环境搭建
2010-04-30 10:18:49
1. 到VMware的官方网站上注册并且下载vmware server,地址为: http://downloads.vmware.com/cn/d/details/server202/dCpiZCVqdGJkZXQl
如下图为windows下的VMware server 版本,只要注册了就会将序列号相关信息发送到邮箱内,我这边获取了一个.
VMware Server for Windows
A0JDM-FU8A1-VA41J-431T1
VMware Server for Linux
AA044-FR88J-UCK73-4CHLN
2. 安装该版本,按照安装的顺序配置.
3. 安装完成后可以远程登陆到该服务器并且配置相关选项(),远程地址为https://serverip:8333
输入服务器的用户名和密码进行验证
4. 进入配置界面,如下图
首先是要新增一个Datastore,按照他的提示配置即可,
Datastore配置好以后就可以根据需要建立虚拟服务器,如下图所示,可以配置多台
同时还可以查看相关事件信息
同时,只要在本机安装一个插件,就可以远程控制多台虚拟服务器
-
JIRA3.12.2安装配置及破解
2010-04-30 09:58:10
JIRA 3.12.2下载:
http://www.atlassian.com/software/jira/JIRADownloadCenter.jspaA. 安装atlassian-jira-enterprise-3.12.2-windows-installer.exe到相应位置,
B. 打开http://SERVERIP:8080
配置应用程序名以及备份,索引路径等,填写License Key为,可以用到2019年:
MQQNsBebGETgjRTVCovUkfgmi2Kt0MuD5hZjgZoWaT87xu>2KRE5W2GZuOvrZzAkz<WgmqonxWMorMqQRmOmnORXTomOPrQPNnOPQOWxUvXvostUUnrpvtsmmmtrnoUUnooqqmmmmtrnoUUA9I1步骤二:
配置管理员的用户名密码,邮箱地址,如admin/admin
步骤三:
配置邮件服务器,这一步骤也可以忽略,在管理页面也可以进行配置
进入页面,可以看到JIRA信息,如图,表示破解成功
使用管理员账户进入administratoràUser&GroupàGroup Browseràadd group,如test
administratoràUser&GroupàGroup Browseràuser BrowseràCreate New User,如test
修改User test到Group test
SchemesàPermission SchemesàAdd Permission Schemes,如test
Global SettingàGlobal Permissions,将JIRA user和Browse Users的权限赋予Test组
步骤七
SchemesàNotification Schemes,新增和修改邮件通知权限
步骤八
新建一个ProjectàProjects,选择刚刚新建的邮件通知方案和权限方案
其他,如邮件通知等都可以在左侧导航栏中配置.
-
初次配置jira与svn服务器端总结
2008-10-31 11:43:57
1. 介绍：
JIRA是一个优秀的问题(or bugs, task, improvement, new feature )跟踪及管理软件。 它由Atlassian开发，采用J2EE技术。它正被广泛的开源软件组织，以及全球著名的软件公司使用，它堪称是J2EE的Bugzilla。JIRA具有良好的扩展性，在和版本控制工具集成方面，JIRA内置了与CVS集成的配置；还可以通过插件与ClearCase、Subversion（SVN）、Perforce进行集成。
2. 安装环境：
winXP SP2
4. 安装步骤
A. 安装jdk1.5并配置环境变量
java_home C:\Program Files\Java\jdk1.5.0_14
class_path .;%JAVA_HOME%\lib\tools.jar;%JAVA_HOME%\lib\dt.jar
path path %SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;C:\Program Files\Java\jdk1.5.0_14\bin;
B. 安装JIRA standalone发布包
现在最新的是atlassian-jira-enterprise-3.13-windows-installer.exe
可以去http://www.atlassian.com下载，安装一路NEXT。完成后在web浏览器中访问http://localhost:8080，然后根据页面上的JIRA的配置向导，经过三个配置步骤就完成了：第一步配置JIRA系统的属性；第二步配置JIRA系统管理员的信息；第三步配置JIRA系统的邮件通知参数。（jira的序列号有搜索过很多，但是都不可以用，最后无奈只好点了试用30天）
C.
安装Subversion 安装 VisualSVN-Server-1.6.1.msi，可以去
http://www.visualsvn.com/server/changes/下载，按照提示安装即可。这是一个非常简单好用的SVN server端口，安装非常方便。在运行——cmd——输入这个命令svn mkdir svn://localhost/monkey，以检验Subversion的服务启用是否正常
D.
安装TortoiseSV
直接运行TortoiseSVN-1.4.0.7501-win32-svn-1.4.0.msi按照提示安装即可，不过最后完成后会提示是否重启，其实重启只是使svn工作拷贝在windows中的特殊样式生效，与所有的实际功能无关，这里为了立刻看到好的效果，还是重新启动机器。
可以导入项目的根目录，我们导入的是e:\test1，右键->TortoiseSVN->Import...
URL of repository输入如“https://remote2:8443/svn/qateam/”，okF
（1） 安装JIRA Subversion Plugin
解压缩atlassian-jira-subversion-plugin-0.10.1.zip文件，将atlassian-jira-subversion-plugin-0.10.1\lib目录中的三个jar文件atlassian-jira-subversion-plugin-0.10.1.jar、ganymed.jar、javasvn-1.0.5.jar拷贝到JIRA的\atlassian-jira\WEB-INF\lib目录中；编辑atlassian-jira-subversion-plugin-0.10.1目录下的subversion-jira-plugin.properties文件，添加用户和对应的密码，svn.root=https://remote2:8443/svn/qateam拷贝该文件到\atlassian-jira\WEB-INF\classes目录中。
启动svnserve，重启JIRA，启动过程中会自动创建indexs\plugins\atlassian-subversion-revisions\目录，用于保存subversion的索引。在浏览器中访问http://localhost:8080，就可以在JIRA系统中看到Subversion plugin 了。如下图：
比较忙。。。未完待续
-
关于subversion--菜鸟日记
2008-09-26 09:57:33
什么是 Subversion?
Svn是一个开源的版本控制系统Subversion的简称。Subversion 管理着随时间改变的数据。 这些数据放置在一个中央资料档案库 (repository) 中。 这个档案库很像一个普通的文件服务器，不过它会记住每一次文件的变动。 这样你就可以把档案恢复到旧的版本，或是浏览文件的变动历史。 许多人会把版本控制系統想像成某种“时光机器”。版本控制是管理数据变更的一种技术。对于程序员来说，它已经成为不可或缺的工具，因为他们经常修改软件代码，产生部分的变更，然后第二天再取消所有的变更。想象有一群程序员同时工作的情况你就能理解，为什么需要一个良好的系统来管理可能出现的混乱。
怎么样才可以使用Svn进行程序开发？
你需要有一个SVN客户端，当然在Windows下和Linux下甚至Mac下你都能找到相应的合适的软件。在大多数人的开发环境Windows下，我们推荐使用TortoiseSvn。
另外更重要的，你还需要一台支持SVN服务的服务器。你可能习惯了在公司的内网使用SVN，但如果你经常于游走于各种不同的办公环境，比如公司、家里、客户处，用着很多台不同的电脑，那么你将需要一台外网的服务器。
Svn Hosting Service，专业SVN源代码托管服务，面向全中国的程序员，正是为了解决这个需求而生。
需要清楚掌握你的.NET项目？
有时候，最简单的解决方案就是最有效的解决方案。很多项目都要忍受使用电子数据表的麻烦，在这个数据表上列着应用程序的所有错误，而这在不断地由测试人员和开发人员更新，以确保没有留下什么可以被攻破的漏洞。尽管这看起来可能像是追踪错误和解决问题的最简单方法，但是使用Excel进行跟踪还存在一些问题，其中包括如何确定电子数据表的格式，多个用户需要同时更新文件，通过QQ或者MSN以及局域网之间传来传去。还有后期对错误的统计、人员工作量的估算等等
SvnHost提供的Bug跟踪管理平台提供专业但是简单易用的一个平台。项目管理员增加好项目人员后，每个项目成员即可"add new bug"、“查看Bug列表”，可以根据优先级排序、Bug状态排序等等排序方式，可打印Bug列表、Bug详细信息，可以导出到Excel等等先进的项目开发思想，等待你一一来体验！如下图：
-
读书笔记——svn
2008-09-26 09:30:11
SVN简介 （转）51Testing软件测试网r o!iy5m;j.P(e^0{a
SVN站在更高层次上对现在的安全产品，从系统和控制的角度进行了"有机"和"无隙"的整合。
Z(G+k B,v194265 SVN是一个安全虚拟网络系统，它将系统整体的信息安全功能均衡合理地分布在不同的子系统中，51Testing软件测试网)f/Z$doZ w J&h q6i
使各子系统的功能得到最大限度的发挥，子系统之间互相补充，系统整体性能大于各子系统功能之和，用均衡互补的原则解决了"木桶原理"的问题。
s N&zTA1m-nv'_M C194265 SVN能在跨接Internet, Intranet, Extranet间的网络所有端点实现全面的安全，而且还能提供基于企业策略的信息管理机制以充分有效地利用有限的带宽。SVN可以满足各种企业VPN的要求，通过为公司内部网络、远程和移动用户、分支机构和合作伙伴提供基于Internet的安全连接。所以，我们可以将SVN看成是VPN、防火墙、基于企业策略的信息管理软件集成在一起的Internet安全的综合解决方案。在这样一个网络系统中，所有互联网服务器端和客户端都是安全的，并有一个信息管理机制以不断地通过这个外部网络环境动态地分析及满足客户的特定带宽需求。SVN提供了目前基于网络实现的eBusiness 应用的安全服务，它包含：51Testing软件测试网:z-z&` _8[ g g
对多种应用进行全面的安全认证；
DW*M@1mhQk!x194265 支持多种认证及PKI
Z$} E4~;tP194265 功能强大并对用户透明的通讯加密；
4wdB:}Au!v7|194265 面向用户的集中安全策略管理；
M A'~ EoN Coy194265 统一跨接Internet、Intranet、Extranet的通讯。51Testing软件测试网[;S:ma [&h.o-W"m"W
完整的SVN体系结构应包括以下部分：51Testing软件测试网.x{"b4g%m%E EX*f
带有防火墙的VPN网关，它是一个将防火墙和VPN技术紧密结合的网关产品；51Testing软件测试网 q\/[6O yJX^
SVN安全远程客户端软件包，一个功能强大的VPN客户端软件，支持台式机用户、远程用户和移动用户，具有集中化管理的个人防火墙功能和VPN用户的安全认证功能；
u h/[AqG194265 SVN证书管理模块，一个用于SVN的完整PKI解决方案，它将完善的CA和LDAP目录服务器技术集成在一起；
~-h.D9S9v/aT K194265 SVN硬件加密卡，可以通过硬件技术实现功能强大的各种算法以提高VPN的速度和性能；51Testing软件测试网7[5r-Q6OE0[K
SVN智能带宽管理模块，一个基于企业策略的带宽管理解决方案，可以智能地管理有限的带宽资源，以确保用于企业重要应用的VPN性能可靠；
+Pe Z4cLr|194265 SVN冗余管理模块，通过冗余网关集群和防火墙VPN内的SVN冗余模块，对执行重要任务的VPN和防火墙应用在出现故障时实现无缝切换。51Testing软件测试网 a`%T_@!]9X#f|
自动地址转换模块，一个自动管理IP地址和命名的解决方案，通过提供IP地址服务的跟踪和集中化管理，确保可靠地控制地址分配和提高TCP/IP管理效率；
x1U FI;K*k2z${194265 SVN安全服务器软件包，专门保护单个应用服务器安全的VPN网关软件，它可以保护进行敏感操作的服务器免受攻击和未授权的访问，使客户端建立与服务器间的安全认证和支持交换加密数据的连接；
Y iS,TZ(N194265 SVN安全客户端软件包，它将基于状态检测的防火墙和基于IPSec的VPN客户端软件集成在客户端机器上，通过提供集中管理的个人防火墙和对所有企业VPN用户的安全认证，增强客户端机器的安全性。它与 SVN安全远程客户端软件功能相比，增强了客户端的安全功能，如访问控制和安全初始化控制等。
\j D IA.|19426551Testing软件测试网d_:J GB\l8T -
读书笔记二——08-09-14
2008-09-14 21:02:23
1. JIRA介绍
JIRA是集项目计划、任务分配、需求管理、错误跟踪于一体的商业软件。JIRA创建的问题类型包括New Feature、Bug、Task和Improvement四种，还可以自己定义，所以它也一是过程管理系统。Jira融合了项目管理、任务管理和缺陷管理，许多著名的开源项目都采用了JIRA。JIRA 是目前比较流行的基于Java架构的管理系统，由于Atlassian公司对很多开源项目实行免费提供缺陷跟踪服务，因此在开源领域，其认知度比其他的产品要高得多，而且易用性也好一些。同时，开源则是其另一特色，在用户购买其软件的同时，也就将源代码也购置进来，方便做二次开发。正因为其开放性，价格上自然也相当不菲，对于中小型的软件企业做项目管理，则又要另寻出路。
功能列表：
1. 问题追踪和管理（问题类型包括New Feature-新功能、Bug-缺陷、Task-任务、Improvement-改进 四种），可自定义；
2. 问题跟进情况的分析报告；
3. 项目类别管理功能；
4. 组件/模块负责人功能；
5. 项目email地址功能；
6. 无限制的工作流；
7．子任务功能；
8．邮件通知功能；
9．CVS、SVN以及LDAP的集成功能；2. TD介绍
TestDirector 是业界第一个基于Web的测试管理系统，它可以在您公司组织内进行全球范围内测试的协调。通过在一个整体的应用系统中提供并且集成了测试需求管理、测试计划和用例管理、测试日程控制、测试执行和缺陷跟踪等功能，TestDirector 极大地加速测试过程。
功能列表：
1．域及工程管理；
2．用户管理；
3．工程进行定制(属性和列表、用户、用户组、版本、工作流、邮件通知等)；
4．测试需求管理；
5．测试计划和用例管理；
6．测试日程控制；
7．测试执行和缺陷追踪。
8．强大的统计分析功能。三、JIRA的优缺点
1. JIRA的优点
用它管理项目，跟踪任务、bug，通过JIRA的邮件通知功能进行协作通知，在实际工作中使工作效率提高很多，效果非常不错！安全性、可扩展性方面发挥到了极致！
JIRA不仅仅是一个缺陷跟踪系统，通过Jira，可以整合客户、开发人员、测试人员，各人各司其职，信息很快得到交流和反馈，让大家感到软件开发在顺利快速的进行，朝意想的目标迈进。IDEA下的Jira插件，主要为开发人员服务，实时将信息反馈给开发人员，开发人员同时迅速地将修复的结果信息反馈到跟踪系统中，最后通过持续集成，软件迅速地完成了更新，这些方便便捷的操作会极大地鼓舞软件开发中的各方人员，甚至包括客户，及时响应，相信是每一个客户都会欣赏的。
跟同类软件产品TestTracker、ClearQuest、TestDirector相比，JIRA的性价比最好！因为TestTracker、ClearQuest、TestDirector等这几类软件都是根据用户数来定价的，而JIRA软件不限制用户数！不限制创建项目数和Issue的数量！一年内免费更新版本！2. JIRA的缺点
对于测试需求、测试用例等都没有提供直接的方式进行管理。四、TD的优缺点
1. TD的优点
TestDirector能消除组织机构间、地域间的障碍。它能让测试人员、开放人员或其它的IT人员通过一个中央数据仓库，在不同位置就能互通测试信息。TestDirector将测试过程流水作业—从测试需求管理，到测试计划，测试日程安排，测试执行以至到出错后的跟踪—仅在一个基于浏览器的应用中便可完成。
强大的统计分析功能：测试过程的最后一步是分析测试结果，确定应用程序是否已布属成功或需要再次的测试。TestDirector常规化的图表和报告和在测试的任一环节帮助您对数据信息进行分析。TestDirector还以标准的HTML或Word形式提供一种生成和发送正式测试报告的一种简单方式。测试分析数据还可简便地输入到一种工业标准化的报告工具，如Excel，ReportSmith， Crystal Reports，和其它类型的第三方工具。
2. TD的缺点
由于其早期版本不能灵活的对项目管理流程进行配置，又由于其昂贵的价格，因此目前应用的企业也不是很多。 -
读书笔记一——08-09-14
2008-09-14 20:57:08
测试需求分析的信息来源不止是业务需求，我们公司的规范做法：全部新业务：
。画出业务流程
。提取基本正向流程、分支流程及反向流程
。提取流程穿过的业务画面，填写全部的界面参数及系统内置参数（其他画面输入）
。填写每个画面的必输项
。提取业务规则
。从常用规则库提取适用规则
。使用业务原语描述测试模板
。计算参数表适配模板得出用例优化压缩空间
。根据风险原则选取
老业务回归：
查出配置管理系统本次变更的程序模块、库表、值域选择等的变化
计算变更影响分析
提取需要复测的功能列表
提取影响这些功能列表的业务流程
提取测试用例模板
修正模板（如果界面修改）
修正参数（如果值域修改）
修正规则参数（与业务规则修改相关）
-
08-09-02读书笔记四
2008-09-02 23:15:08
VBscrīpt:处理文件（创建、写入、读取、删除）
2007-06-22 14:57:02 / 个人分类：QTP
1.创建文件
_;qr%m"^_194265 创建空文本文件（有时被叫做“文本流”）有三种方法。第一种方法是用 CreateTextFile 方法。下面的示例示范了如何用 CreateTextFile 方法创建文本文件：
[VBscrīpt]
{CBG0rxL194265Dim fso, f151Testing软件测试网%dFex0x ~:bEf&}
Set fso = CreateObject("scrīpting.FileSystemObject")
kc"Cv C$G8^ w194265Set f1 = fso.CreateTextFile("c:\testfile.txt", True)创建文本文件的第二种方法是，使用 FileSystemObject 对象的 OpenTextFile 方法，并设置 ForWriting 标志。
[VBscrīpt]51Testing软件测试网 nfO~+]7]$H7Z BP
Dim fso, ts
"P4lT do%n T194265Const ForWriting = 2
8xrk f S0h s^194265Set fso = CreateObject("scrīpting. FileSystemObject")
o,U6@3x8y#rf194265Set ts = fso.OpenTextFile("c:\test.txt", ForWriting, True)创建文本文件的第三种方法是，使用 OpenAsTextStream 方法，并设置 ForWriting 标志。要使用这种方法，使用下面的代码：
[VBscrīpt]51Testing软件测试网v~8}5h2wH
Dim fso, f1, ts
Z f Yb L3j6@194265Const ForWriting = 2
(^MAu0C9tm/by194265Set fso = CreateObject("scrīpting.FileSystemObject")51Testing软件测试网 |(J;Rc8i F#c!h
fso.CreateTextFile ("c:\test1.txt")
1tf H eVs194265Set f1 = fso.GetFile("c:\test1.txt")51Testing软件测试网|s%[6R(\
Set ts = f1.OpenAsTextStream(ForWriting, True)
u8bla AdA O;wQ194265
Ddt.Nj1942652.写入数据
o(@+o g~FS:]8af194265 一旦创建了文本文件，使用下面的三个步骤向文件添加数据：打开文本文件。
写入数据。
关闭文件。
要打开现有的文件，则使用 FileSystemObject 对象的 OpenTextFile 方法或 File 对象的 OpenAsTextStream 方法。
要写数据到打开的文本文件，则根据下表所述任务使用 TextStream 对象的 Write、WriteLine 或 WriteBlankLines 方法。
任务 方法 向打开的文本文件写数据，不用后续一个新行字符。 Write 向打开的文本文件写数据，后续一个新行字符。 WriteLine 向打开的文本文件写一个或多个空白行。 WriteBlankLines 要关闭一个打开的文件，则使用 TextStream 对象的 Close 方法。
注意 新行字符包含一个或几个字符（取决于操作系统），以把光标移动到下一行的开始位置（回车/换行）。注意某些字符串末尾可能已经有这个非打印字符了。
下面的例子示范了如何打开文件，和同时使用三种写方法来向文件添加数据，然后关闭文件：
[VBscrīpt] 51Testing软件测试网{ z} r"Z1n(kR
Sub CreateFile() 51Testing软件测试网\+a!] vW la a
Dim fso, tf 51Testing软件测试网3~` pO([5RH i
Set fso = CreateObject("scrīpting.FileSystemObject") 51Testing软件测试网7P_4Zu&\1@2vH!F
Set tf = fso.CreateTextFile("c:\testfile.txt", True) ' 写一行，并带有一个新行字符。 tf.WriteLine("Testing 1, 2, 3.") ' 向文件写三个新行字符。
(Ny,? [-ktp194265tf.WriteBlankLines(3) ' 写一行。 51Testing软件测试网^f/{)_6V m9|*`
tf.Write ("This is a test.") 51Testing软件测试网Q W)hiPO E
tf.Close 51Testing软件测试网 tj vg'X4|-J
End Sub51Testing软件测试网4f2c0|h)fX!a G
51Testing软件测试网 `u'x jf"h,f
3.读取数据
'`X.?/GF cV0w1Uu194265 要从文本文件读取数据，则使用 TextStream 对象的 Read、ReadLine 或 ReadAll 方法。下表描述了不同的任务应使用哪种方法。任务 方法 从文件读取指定数量的字符。 Read 读取一整行（一直到但不包括新行字符）。 ReadLine 读取文本文件的整个内容。 ReadAll 如果使用 Read 或 ReadLine 方法，并且想跳过数据的特殊部分，则使用 Skip 或 SkipLine 方法。read 方法的结果文本存在一个字符串中，该字符串可以显示在一个控件中，也可以用字符串函数（如 Left、Right 和 Mid）来分析，连接等等。
下面的例子示范了如何打开文件，和如何写数据到文件中并从文件读取数据：
[VBscrīpt]51Testing软件测试网jW~5`%lk T9L
Sub ReadFiles51Testing软件测试网%hl:M@1| K
Dim fso, f1, ts, s51Testing软件测试网w%hpD bN*|
Const ForReading = 1
;J.v5w.? v&]194265 Set fso = CreateObject("scrīpting.FileSystemObject")
$[kb CJ8dc{!g E194265 Set f1 = fso.CreateTextFile("c:\testfile.txt", True)51Testing软件测试网 n'_G5b.n$v fD kbQ
' 写入一行。
5?&N.{ b9u.q{#w194265 Response.Write "Writing file <br>"
n B_ J%Z6a+|194265 f1.WriteLine "Hello World"
I Yr J-o194265 f1.WriteBlankLines(1)
}?&U^2lk$yWJ194265 f1.Close51Testing软件测试网3@D&CYZd C
' 读取文件内容。51Testing软件测试网@ XF Z w2A J9a
Response.Write "Reading file <br>"51Testing软件测试网Y p [ r`;F
Set ts = fso.OpenTextFile("c:\testfile.txt", ForReading)51Testing软件测试网:w$D pv/QdbM GQ5F
s = ts.ReadLine
7L+pc9bg#| jM Q v194265 Response.Write "File contents = '" & s & "'"51Testing软件测试网1XE3N5agF
ts.Close51Testing软件测试网t H l/J(D
End Sub
]7F5`!x M+D194265
f)fq9k8E1942654.移动、复制、删除
l(cKILj"d%b k194265 FSO 对象模型各有两种方法移动、复制和删除文件，如下表所述。任务 方法 移动文件 File.Move 或 FileSystemObject.MoveFile 复制文件 File.Copy 或 FileSystemObject.CopyFile 删除文件 File.Delete 或 FileSystemObject.DeleteFile 下面示例在驱动器 C 的根目录中创建一个文本文件，向其中写一些信息，然后把它移动到 \tmp 目录中，并在 \temp 中做一个备份，最后把它们从两个目录中删掉。
要运行下面的示例，需要先在驱动器 C 的根目录中创建 \tmp 和 \temp 目录：
[VBscrīpt] Sub ManipFiles Dim fso, f1, f2, s 51Testing软件测试网\Dh*Pn+\!{+n{e
Set fso = CreateObject("scrīpting.FileSystemObject") 51Testing软件测试网jv8m n@g7K
Set f1 = fso.CreateTextFile("c:\testfile.txt", True) 51Testing软件测试网d'NDI;r3Zk
Response.Write "Writing file <br>" ' 写入一行。
9{#p nZ9G O4i w NP194265f1.Write ("This is a test.") ' 关闭写入到的文件。
iqf#d'sm y194265f1.Close Response.Write "Moving file to c:\tmp <br>" ' 获取到 C:\ 根目录中文件的句柄。 Set f2 = fso.GetFile("c:\testfile.txt") ' 将文件移到 \tmp 目录。51Testing软件测试网!qf']4g ~_/K
f2.Move ("c:\tmp\testfile.txt")
q }Th"U194265Response.Write "Copying file to c:\temp <br>" ' 将文件复制到 \temp。
E'SE'~8y.Wa194265f2.Copy ("c:\temp\testfile.txt")
7`V9JA N'pQ7u194265Response.Write "Deleting files <br>" ' 获得文件当前位置的句柄。
)TU ? ~I.l"{194265Set f2 = fso.GetFile("c:\tmp\testfile.txt") Set f3 = fso.GetFile("c:\temp\testfile.txt") ' 删除文件。
je4i3or5jPK194265f2.Delete f3.Delete
-D _9D N!uv194265Response.Write "All done!"
R$a!~AI194265End Sub -
08-09-02读书笔记三
2008-09-02 22:59:13
由于性能测试与功能测试有很大的区别，所以讨论出的结果可能与预先的设想有一定的区别。性能测试的目的：
为了验证系统是否达到用户提出的性能指标，同时发现系统中存在的性能瓶颈，起到优化系统的目的。
性能测试指标的来源：
用户对各项指标提出的明确需求；如果用户没有提出性能指标则根据用户需求、测试设计人员的经验来设计各项测试指标。（需求+经验）
主要的性能指标：
服务器的各项指标（CPU、内存占用率等）、后台数据库的各项指标、网络流量、响应时间。
BUG观点：
1、性能测试就象人在无风情况下跑步（正常情况下的性能指标）；
2、压力测试就象人在微风中跑步（在正常的基础上加大多少百分比压力的性能指标）；
3、负载测试就象人在强风中跑步（不断加压，直到系统崩溃）。
HTTP观点：
1、 负载测试是正常情况下持续的加压；
2、 压力测试是直接加压达到一个极限值。
大家统一的观点：
性能测试、压力测试、负载测试密不可分，可统称为性能测试。
性能测试要点：
1、 性能测试是在功能测试完成之后进行。
2、 性能测试计划、方案一般与测试用例统一在一个文档里。
3、 测试环境应尽量与用户环境保持一致。
4、 性能测试一般使用测试工具和测试人员编制测试脚本来完成，性能测试的环境应单独运行尽量避免与其他软件同时使用。
5、 性能测试的重点在于前期数据的设计与后期数据的分析。
6、性能测试的用例主要涉及到整个系统架构的问题，所以测试用例一旦生成，改动一般不大，所以做性能测试的重复使用率一般比较高。（说明：当系统中出现的某个功能点需要修改，它一般只会影响到功能测试的设计用例，而对于性能测试，很少影响到性能测试的设计用例。但是如果某个功能有较大的修改，性能测试也应该进行重新测试。）
标题搜索
我的存档
数据统计
- 访问量: 32991
- 日志数: 38
- 图片数: 1
- 建立时间: 2008-07-28
- 更新时间: 2013-02-16
