（1） 常规的测试用例：
  对于一个功能一个页面，每个数据项输入或选中典型的取值，生成一个用例
  对于一个功能多个页面，多个页面一起生成一个用例
  对于多个功能一个页面，每个功能生成一个用例
  每个功能操作需覆盖，如删除,对话框点击确定、取消分别生成2个用例
  输入框测试，在允许范围内尽可能覆盖多的字符类别，如中文、英文、数字等
  对于每个功能点，必须通过一组（一个或多个）用例满足其业务覆盖：对于某条记录的每个状态，对于能进行的每个操作，都生成一个用例（即对业务功能流程中的每个角色，每个功能操作，生成一个用例）
（2）初始化的测试用例：
进入功能页面后，某些控件会初始化填入数据，生成一个用例确保所有的初始数据正确
（3） 边界的测试用例
对于每个数据项，生成一个边界用例（含最大、最小两个边界值）
  字符串数据以字符串长度为计量单位
  布尔值数据的所有取值都需测试
  多个复选框一组时，需测同时都被选中及都不被选中
  下拉菜单、列表框、单选按钮组为最大、最小的2个取值
（4） 空值的测试用例：
对于每个必填数据项，都生成一个用例（不提供空值的除外，比如无空值的下拉框、有缺省值的单选按钮组），则预期结果提示该数

据项为空
（5） 格式错误的测试用例：
对于输入框数据项，都生成一个用例，预期结果提示该数据项格式错误
  日期输入框
  数字输入框
  字符串输入框：Email、邮编、用户名等带格式要求的
（6）溢出的测试用例：
对于输入框数据项，都生成一个取值范围外的测试用例，预期结果提示该数据项超出范围

  日期输入框
  范围的日期输入框，需添加上边界日期小于下边界日期的用例
  数字输入框（如‘金额’一般为正整数，填入一个负数）
  字符串输入框：超出规定长度的字符串
（7） 关联的测试用例：
对于相互关联的两个或多个数据项，生成一个用例，确保当一个数据项改变时，其它数据项的变化正确
（8） 唯一值的测试用例：
某些业务的数据字段要求是唯一的，生成一或两个用例（新建、编辑），使得输入数据与原有数据在该字段重复，预期结果为页面返回该数据已存在的提示
（9） 权限不足的测试用例：
对于功能模块，生成一个用例，以没有权限的用户身份访问，预期结果为提示权限不足
（10） 角色权限的测试用例：
业务功能流程涉及一到多个角色，对于每个角色，都生成一个用例，预期结果为用户以这个角色登陆时，他仅能执行权限允许的操作

对于软件，开发者往往只注意到其功能和性能，而忽略了用户手册。其实用户手册也是衡量软件好坏的一个重要标准。好的用户手册可以帮助用户快速入门，是用户正确、充分使用软件的前提。对于开发者来说，好的用户手册可以减少培训和售后服务的费用。所以在测试中，不能忽略用户手册的重要性，应从以下多个方面考察用户手册的质量。

    用户手册的完整性

    重点考察用户手册内容的全面性与完整性，从总体上把握用户手册的质量。这一项看似简单，但在实际测试中我们发现，很多开发商还是无法做到这一基本标准。很多软件由于开

发过于仓卒，在付诸使用时，用户手册中缺少关于某些模块的说明，让用户使用起来比较困难。在测试工程师的眼里，优秀的用户手册内容应该是包括软件的所有功能模块。

    用户手册的描述与软件实际功能的一致性

    考察用户手册与软件实际功能的一致程度。当确认用户手册基本完整后，我们还要注意用户手册与实际功能描述是否一致。这种问题往往是由用户手册跟不上软件版本的更新速度造成的。对用户来说，容易造成对描述不一致的功能的误解和疑惑，进而影响用户对软件的使用。优秀的用户手册应该根据软件的升级而及时更新，手册描述应该与软件实际功能保持一致。

只有正确、迅速、准确地处理这些错误，才能消除软件错误，保证要发布的软件符合需求设计的目标。在实际软件测试过程中，对于每个Bug都要经过测试、确认、修复、验证等的管理过程，这是软件测试的重要环节。

　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、测试管理者需要是技术专家吗？

　　测试管理者在测试项目中的主要任务是制定测试策略，管理测试计划的落实情况，并且还要为测试项目的进行创造良好的执行环境。同时还要调动员工的创造性，对员工的工作作出评估。这些工作不一定要求测试管理者达到专家的水平。但是在实际工作中，由于测试人员的短缺，测试管理者常常做为测试员来执行具体的测试任务。尤其在规模较小的测试团队，测试管理者的日常工作通常以具体的测试执行工作为主，这个时候更需要测试管理者有较好的背景知识。总体说来，技术方面的背景知识对测试管理者是十分有益的。例如：分配工作任务、做进度预算，以及一些具体的执行工作，都需要一定的背景知识。当然，做为一个测试管理者，没有必要精通所有的技术，那也是办不到的。测试管理者做到正确的帮助员工最好地完成工作，并且提供最好的完成工作的环境就可以了。

这个问题出题很新颖，着重是考察公司的测试Leader应对突发事件的能力？

　　以前我们公司招测试Leader的面试题目中也有类似的一个题目？我面试了很多人，回答都不是很理想，都只能够回答上几句话，并且都有“需求不明确”等同感，只是工作中太忙缺少总结，给出一个常见的很熟悉的问题，马上作答不知道如何说起。

　　下面是我的一些看法，恳请各位同行批评指正：

　　1.根据客户的功能点整理测试需求追朔表：

　　一般的客户都要把要开发软件的功能点写成一个表格交给市场部，让市场部门转交研发部。所以客户的功能点是编写测试用例一个最最重要的依据。

　　2.根据开发人员的Software Specification List整理我们的功能测试点：

　　一般来说，开发人员实现一个功能都要把该功能分成几个子模块来实现，所以Software Specification List也是我们参考的另一个比较重要的依据。

　　3.开展项目跨部门讨论会：

　　可以抽出时间，叫市场部的项目负责人、产品经理、项目经理、软件开发经理和软件开发人员，分别讲讲他们对整个产品的认识和设计模式，对每个功能点的理解和认识，理顺思路，达成共识，测试人员负责记录，测试Leader负责整理汇总，形成测试的部分参考文档。

　　4.测试人员整理用例需求疑问递交项目组和客户代表回复：

　　测试人员根据项目讨论会后的理解，测试过程中可能碰到的问题（如：边界值、输入数据类型等等）和需求不明确的问题，整理用例需求疑问，让相关的模块负责人在“用例需求疑问”表格中回复，并给出详细解释和说明。

　　5.项目内部用例评审：

　　测试人员根据对项目的理解，编写测试用例要点，测试组内部评审修改后，可以召集项目组的成员，帮助Review一下，然后进行修改。经过多次修改和评审以后，测试用例要点可能会更加全面一些。

　　6.邮件和客户代表确认部分争议问题：

　　测试人员与开发人员、项目组成员，在需求问题上讨论有时候观点不一致，各说各有理，这种情况下最好把争议问题写成邮件，发给客户让客户来拍板，确定那种需求合理，到底如何做？抄送项目组的全体成员，方便大家都了解客户的意见。最后编写测试用例的时候，以客户的邮件内容为准。

　　7.项目Demo和部分已开发系统：

　　大部分的系统，由于没有需求，为了避免项目风险，开发方一般都要做成Demo，不断让客户确认后签字，不断展现新开发的功能，以达到吸引客户的目的。如果项目中有Demo，Demo也是参考标准。如果什么都没有，那已经开发的部分功能模块，要去随时让用户了解了解，并提出部分修改意见，也可以为我们熟悉系统提供部分依据。

　　8.参考同行业和竞争对手的类似产品：

　　假如说是做一个网上书店类似的网站，我们编写测试用例的时候，可以看看“当当网”，“China—pub”等等类似成熟相关的网站。很容易发现本公司产品的问题，无意识给产品添加了竞争力。对于竞争对手的了解一定不能够少。

　　9.交叉模块的测试，最容易被人忽略：

　　一般的产品，功能部分的交叉，即是说在A模块中设置了参数，在B模块和C模块中体现该参数的实际运用。比较难的如我们现在测试的“银行系统”中的交叉模块，还可能牵涉到不同的用户，3个以上的模块之间的调用。即是有了需求也很少写，同时也是需求编写的一个薄弱环节。这样的测试用例编写问题，一般初级测试工程师很难考虑全。对于有这种交叉功能的模块，必须要求项目组中的精兵强将，画出相关的调用关系图，表明调用关系，方便后面编写测试用例。

　　10.可以使用电话、MSN、Skype等网络聊天工具咨询部分需求：

　　我们做的产品，大多数的客户都在国外，测试经理也可以用这些网络聊天工具和客户确认部分需求疑问。不过要要事先越好时间，并注意异地的“时差”。

　　我以前的团队中主要使用这些方法，如果大家有什么好的方法，请大家补充，完善！！

 

原出处及链接：http://www.51testing.com/html/200810/n95728.html

产品经理的英文称谓是Product Manager，
项目经理的英文称谓是Project Manager，两者的缩写都是PM。

自从1927年美国P＆G（宝洁）公司出现第一名产品经理（Product Manager）以来，
产品管理（Product Management）制度逐渐在越来越多的行业得到应用和推广。

产品经理（Product Manager），又称品牌经理（Brand Manager）。
一般来说，产品经理是负责并保证高质量的软件产品按时完成和发布的专职管理人员。
他的任务包括倾听用户需求；负责产品功能的定义、规划和设计；
做各种复杂决策，保证开发队伍顺利开展工作及跟踪程序错误等等。
总之，产品经理全权负责产品的最终完成。
另外，产品经理还要认真搜集用户的新需求、竞争产品的资料以及研究产品的发展趋势等。

有一句话说的很精辟：

　　产品经理——靠想。产品经理是做正确的事，其所领导的产品是否符合市场的需求，是否能给公司带来利润的。

　　项目经理——靠做。项目经理是把事情做正确，把事情作得完美，在时间，成本和资源约束的条件下完成目标。

　　从管理的角度讲,项目经理是纵向的,而产品经理是横向的。

　　例如我们姑且理解项目经理是一个开发部门的项目经理,那么他一定是对某个产品进行开发的管理,负责开发的进度,开发过程中的协调,供应链等有关开发方面的问题,他最大的目标是时间第一,立项目标达成第一.并不会很尊重产品本身的市场需求以及业务逻辑的问题.

　　在一个公司中类似这样纵向管理的部门都是一个个职能部门,例如市场部,主要负责推广,销售部主要负责销售等,而产品经理是横向管理的,也就是说他将负责某个产品或者某个产品线从商业计划\市场竞争\开发需求\推广方案\渠道策略\物流等各个方面.当然产品经理不一定是决策人,每个公司对产品经理的权限限制也不同,但是产品经理一个产品线从头到尾的重要参与人.想做好产品经理需要很多方面的才华和技能,他也是一个公司中最适合培养复合型人才潜力的职位。

　　一个产品经理可能没有权利,但是一个产品经理要善于运用同事关系,客户关系去协调去促进事情的发展,一个项目是属于项目经理开发的,他有开发目标达成的责任.而这个项目也是属于产品经理的,他有对商业计划负责的责任.因此作为产品经理就意味着的和本产品有关的事,不论是开发\生产\推广\销售\成本\物流\渠道都是你的问题!

　　如果希望做一个复合人才就选择产品经理,如果希望做一个专注人才就选择项目经理。

　　项目经理与产品经理另一个重要区别是授权的范围不同：

　　项目经理一般是被授权的合同履约的负责人：

　　项目合同是规定承、发包双方责、权、利具有法律约束力的契约文件，是处理双方关系的主要依据，也是市场经济条件下规范双方行为的准则。

　　项目经理是公司在合同项目上的全权委托代理人，代表公司处理执行合同中的一切重大事宜，包括合同的实施、变更调整、违约处罚等，对执行合同负主要责任。
当然，根据企业的不同，老板能否给予项目经理相应的授权是另一回事。

　　产品经理的授权是保证流通链的畅通：

　　产品经理保证其所负责的产品，从上游创意、研发开始，至采购、生产，到下游渠道、通路，直至终端用户的整个流通链的畅通，因此要求产品经理既要有产品知识，也要有市场意识，还要具备协调能力，例如：财务、售后、物流……

　　但是，产品经理并无对外签订合同的授权。

在实际的项目质量管理中，质量管理总是围绕着质量保证(QualityAssurance)过程和质量控制(QualityControl)过程两方面。这两个过程相互作用，在实际应用中还可能会发生交叉。正如引言所述，关于软件的质量，很难下一个非常明确的定义。本文主要针对软件工程中的质量管理来进行讨论。

　　做软件“大餐”的工序

　　软件质量保证（SoftwareQualityAssurance，以下简称SQA）的目的是验证在软件开发过程中是否遵循了合适的过程和标准。软件质量保证过程一般包含以下几项活动：
  首先是建立SQA组；其次是选择和确定SQA活动，即选择SQA组所要进行的质量保证活动，这些SQA活动将作为SQA计划的输入；然后是制定和维护SQA 计划，这个计划明确了SQA活动与整个软件开发生命周期中各个阶段的关系；还有执行SQA计划、对相关人员进行培训、选择与整个软件工程环境相适应的质量保证工具；最后是不断完善质量保证过程活动中存在的不足，改进项目的质量保证过程。

　　独立的SQA组是衡量软件开发活动优劣与否的尺度之一。SQA 组的这一独立性，使其享有一项关键权利——“越级上报”。当SQA组发现产品质量出现危机时，它有权向项目组的上级机构直接报告这一危机。这无疑对项目组起到相当的“威慑”作用，也可以看成是促使项目组重视软件开发质量的一种激励。这一形式使许多问题在组内得以解决，提高了软件开发的质量和效率。
  选择和确定SQA活动这一过程的目的是策划在整个项目开发过程中所需要进行的质量保证活动。质量保证活动应与整个项目的开发计划和配置管理计划相一致。一般把该活动分为以下五类：

　　1）评审软件产品、工具与设施

　　软件产品常被称为“无形”的产品。评审时难度更大。在此要注意的一点是：在评审时不能只对最终的软件代码进行评审，还要对软件开发计划、标准、过程、软件需求、软件设计、数据库、手册以及测试信息等进行评审。评估软件工具主要是为了保证项目组采用合适的技术和工具。评估项目设施的目的是保证项目组有充足设备和资源进行软件开发工作。这也为规划今后软件项目的设备购置、资源扩充、资源共享等提供依据。

　　2）SQA活动审查的软件开发过程

　　SQA 活动审查的软件开发过程主要有：软件产品的评审过程、项目的计划和跟踪过程、软件需求分析过程、软件设计过程、软件实现和单元测试过程、集成和系统测试过程、项目交付过程、子承包商控制过程、配置管理过程。特别要强调的是，为保证软件质量，应赋予SQA阻止交付某些不符合项目需求和标准产品的权利。

　　3）参与技术和管理评审

　　参与技术和管理评审的目的是为了保证此类评审满足项目要求，便于监督问题的解决。

　　4）做SQA报告

　　SQA活动的一个重要内容就是报告对软件产品或软件过程评估的结果，并提出改进建议。SQA应将其评估的结果文档化

　　5）做SQA度量

　　SQA度量是记录花费在SQA活动上时间、人力等数据。通过大量数据的积累、分析，可以使企业领导对质量管理的重要性有定量的认识，利于质量管理活动的进一步开展。

　　要说明的是，并不是每个项目的质量保证过程都必须包含上述这些活动或仅限于这些活动，要根据项目的具体情况来定。

　　SQA 计划中必须明确定义在软件开发的各个阶段是如何进行质量保证活动的。它通常包含以下内容：质量目标；定义每个开发阶段的开始和结束边界；详细策划要进行的质量保证活动；明确质量活动的职责；SQA组的职责和权限；SQA组的资源需求，包括人员、工具和设施；定义由SQA组执行的评估；定义由SQA组负责组织的评审；SQA组进行评审和检查时所参见的项目标准和过程；需由SQA组产生的文档。

　　选择合适的SQA工具并不是试图通过选择SQA工具来保证软件产品的质量，而是用以支持SQA的活动。选定SQA工具时，首先需要明确质量保证目标。根据目标制定选择SQA工具的需求并文档化，包括对平台、操作系统以及SQA工具与软件工程平台接口的要求等。

　　如何使白壁“无瑕”

　　按工序去做也不一定能得到一盘完美的“大餐”，因为火侯等因素实在很难掌握。万一掌握不好怎么办？软件质量控制主要就是发现和消除软件产品的缺陷。对于高质量的软件来讲，最终产品应该尽可能达到零缺陷。而软件开发是一个以人为中心的活动，所以出现缺陷是不可避免的。因此，要想交付一个高质量的软件，消除缺陷的活动就变得很重要。缺陷消除是通过“评审”和“测试”这类质量控制活动来实现的。

　　缺陷在软件开发的任何阶段都可能会被引入。项目质量管理过程包含了许多可以识别缺陷、消除缺陷的过程。“识别缺陷”和“消除缺陷”本来是两个不同的过程，但在这里为了简便统一用“消除”来代表它们。潜在的缺陷越大，用来消除它所花的费用越高。因此成熟的软件开发过程在每一个可能会引入潜在缺陷的阶段完成之后都会开展质量控制活动。这些为了消除缺陷的活动包括：需求评审、设计评审、代码走查、单元测试、集成测试、系统测试以及验收测试等。

　　质量控制的任务就是策划可行的质量管理活动，然后正确地执行和控制这些活动以保证绝大多数的缺陷可以在开发过程中被发现。

　　正如前面提到的，在进行评审和测试时可检测到缺陷。评审是面向人的过程，测试是运行软件（或部分软件）以便发现缺陷。在一个项目里，评审和测试活动是预先策划好的（计划书中确定执行哪些质量控制活动和何时执行这些活动）。在执行过程中，根据已定义好的过程来执行这些活动。通过执行这些活动来识别缺陷，然后消除这些缺陷。例如，系统测试过程一般包括制定测试计划，测试计划中应列出在测试执行过程中所有的测试用例，评审测试计划，并且最终执行测试计划。

可惜是，对与国内大多公司目前还只是希望~

 

由于测试行业很好的发展前景，人员需求量也很大，最关键的是进入的技术门槛要求也不高，所以现在有越来越多的人选择从事软件测试这一行业，也有许多从事开发或技术相关行业，但是有些郁闷得很难再提升的人也转行投向测试。但是我想说的是，不知道大家有没有想过测试的“繁荣盛事”过去之后，我们是否已经准备好了充足的“过冬”所需的“食物”？

有不少的人也包括以前的我都是属于“一步族”（意为做事情属于走一步，看一步，没有什么长远打算），从毕业刚开始工作时，根本就搞不清楚到底什么样的工作是最适合自己的，只是希望能尽快找个工作，“有碗饭吃”是当时最大也是最迫切的愿望。当“温饱问题”解决后，接下来就是考虑如何“改善生活”吃得好些？就开始通过“跳槽”这样的方式来试图“提高工资”，但是大家也都知道，这样的方法绝对不可频繁使用，两三年用上那么一次半次频率已经不低了，因为没有一家公司喜欢这些“跳族”（靠跳槽来提高薪水不是长久之计）。可是无论是谁，都不想甘于平庸，碌碌无为或是只挣一份微薄的薪水。每个人都想生活得更好一些，而从事“IT”的技术人员尤其如此，外面的人看着我们这些每天来去匆匆、西装革履、进出高级写字楼的“IT白领”们，都有说不出的羡慕和激动，但是我们自己比谁都清楚在这些“光鲜夺目”的背后，压力和危机随时存在。最大的压力和危机有两类：

1、30岁之前，思考最多的是—我怎么能拿到“高薪”？(而且不要封顶，最好像绩优股一样，“疯涨”不停歇)

2、30岁之后或即将到来时，思考最多的是—我还能在这“呆”多久？（当薪水已经没有太多涨幅空间后，就希望能拿着差不多的薪水，在公司“养老”了。但是也许昨天还熟悉的办公室，说不定哪天就会接到人力或老板的通知，让我们“走路”了）

一个是薪水，一个是稳定!始终是做技术，尤其是对于瞬息万变的做“IT”技术的人而言，是最难说出口，也是我们心中的“最痛” 。不管你是否承认，也无论你技术如何，更无论你曾经为公司做过什么？你都会面临年龄、技术和生活这三座大山！

当“30岁”慢慢临近时，不管你是否承认，你都会感觉压力和危机越来越大了！如果您已经是某个知名大公司的中高级骨干或核心人物了，那么还是要恭喜您，起码您失业的危机可能性基本已经非常小了。无论如何，大公司对人才还是愿意“养”的，但是您千万不能掉以轻心，因为您的后面有无数的“后起之秀”正对您的位置“虎视眈眈”呢，您一定不能放松学习和提高，否则还是很有可能被“替换”的，除非您真的是“无可替代”！就像我们往届的奥运会冠军那样，您的压力绝对要大于那些还没有成为冠军的新秀。

无论如何，已经成为“冠军”或曾经是“冠军”的人，还是有很多选择余地的，只要他们肯屈尊，还是要有比我们常人更多的机会去选择。最需要关注的是那些即将30或已经30的“IT人才”，我们也许是因为时机，或者是可选择的余地太小，使得我们在“IT”届虽然打拼了很久，但是还是一个无人知晓、郁郁寡欢的、等待被人挖掘的无名“矿藏”！我们从20多岁大学毕业开始，拼搏了10几年光景，得到的还是无法让自己能够买房、买车的微薄的薪水，想换大公司吧，最好是外企。但是光看看那些长的吓人的英文职位介绍，就足以让你连简历都羞于投放！最后只能一咬牙，交个3万5万的去“街”上学英语。好不容易花了一两年的时间，修成了“正果”，去投了份简历，面试官问的第一个问题却是：“您年纪已经不小了，您对您以后的发展空间和职业规划是如何设想的？”，真是哪壶不开提哪壶！

如果您现在属于或即将属于我说的这两类人，我给您推荐一个对于“软件测试人才”而言一个不是“天堂”的“天堂”，说它不是“天堂”，是因为您也必须全力付出，最重要的是不断学习，所以它不是您可以什么都不做就可以有收获的地方。说它是“天堂”，是因为这可是一个帮您度过30岁以后的“漫漫寒冬”最好的场所。您可以在其中无忧无虑的钻研您的技术，可以成为某个领域的技术专家，但是却再也没有时间、成本的约束，您可以尽其所能得把技术做到最“精细”！只要“客户”喜欢您、认可您，绝对不会收到“解聘”通知，只要您愿意，可以一直做到您退休。而且每月的薪水您可以自己掌握，多干就多拿，如果累了，想休假，也没有问题！您可能会说，哪有这么好的地方，那您先看看您是否符合以下条件，如果满足，您可不要错失机会：

一、符合以下一种条件：
1、 熟悉软件开发测试流程，能编写测试计划、设计测试方案、测试用例，有测试管理工作经验优先；
2、 掌握C/C++或JAVA，掌握SQL Server、Oracle、Mysql中任意一种数据库，有两年以上开发工作经验，掌握Unix或Linux操作系统管理，能够搭建常用的服务；了解软件测试基本概念
3、 掌握自动化测试理论，熟练使用Robot、QTP、LoadRunner之一种，并有相关自动化测试工作经验一年以上；熟悉计算机软硬件知识，熟悉网络基础知识及TCP/IP协议，熟悉Windows或Unix/Linux操作系统的配置和管理,能够搭建常用的服务；了解J2EE或.net架构
二、本科及以上学历；
三、身体状况：健康
四、素质要求：沟通能力，细心，耐心；思考问题思路清楚，口头表达能力强
五、有培训经验者优先

如果您觉得您符合以上条件，请将您的简历发按照您希望去的城市发到以下邮箱：

上海51testing ：songfeng@51testing.com

北京51testing: shangli@51testing.com

深圳51testing: pcl@51testing.com

1、好好规划自己的路，不要跟着感觉走！根据个人的理想决策安排，绝大部分人并不指望成为什么院士或教授，而是希望活得滋润一些，爽一些。那么，就需要慎重安排自己的轨迹。从哪个行业入手，逐渐对该行业深入了解，不要频繁跳槽，特别是不要为了一点工资而转移阵地，从长远看，这点钱根本不算什么，当你对一个行业有那么几年的体会，以后钱根本不是问题。频繁地动荡不是上策，最后你对哪个行业都没有摸透，永远是新手！

2、可以做技术，切不可沉湎于技术。千万不可一门心思钻研技术！给自己很大压力，如果你的心思全部放在这上面，那么注定你将成为孔乙己一类的人物！适可而止为之，因为技术只不过是你今后前途的支柱之一，而且还不是最大的支柱，除非你只愿意到老还是个工程师！

3、不要去做技术高手，只去做综合素质高手！在企业里混，我们时常瞧不起某人，说他“什么都不懂，凭啥拿那么多钱，凭啥升官！”这是普遍的典型的工程师的迂腐之言。8051很牛吗？人家能上去必然有他的本事，而且是你没有的本事。你想想，老板搞经营那么多年，难道见识不如你这个新兵？人家或许善于管理，善于领会老板意图，善于部门协调等等。因此务必培养自己多方面的能力，包括管理，亲和力，察言观色能力，攻关能力等，要成为综合素质的高手，则前途无量，否则只能躲在角落看示波器！技术以外的技能才是更重要的本事！！从古到今，美国日本，一律如此！

4、多交社会三教九流的朋友！不要只和工程师交往，认为有共同语言，其实更重要的是和其他类人物交往，如果你希望有朝一日当老板或高层管理，那么你整日面对的就是这些人。了解他们的经历，思维习惯，爱好，学习他们处理问题的模式，了解社会各个角落的现象和问题，这是以后发展的巨大的本钱，没有这些以后就会笨手笨脚，跌跌撞撞，遇到重重困难，交不少学费，成功的概率大大降低！

5、知识涉猎不一定专，但一定要广！多看看其他方面的书，金融，财会，进出口，税务，法律等等，为以后做一些积累，以后的用处会更大！会少交许多学费！！

6、抓住时机向技术管理或市场销售方面的转变！要想有前途就不能一直搞开发，适当时候要转变为管理或销售，前途会更大，以前搞技术也没有白搞，以后还用得着。搞管理可以培养自己的领导能力，搞销售可以培养自己的市场概念和思维，同时为自己以后发展积累庞大的人脉！应该说这才是前途的真正支柱！！！

7、逐渐克服自己的心里弱点和性格缺陷！多疑，敏感，天真（贬义，并不可爱），犹豫不决，胆怯，多虑，脸皮太薄，心不够黑，教条式思维。。。这些工程师普遍存在的性格弱点必须改变！很难吗？只在床上想一想当然不可能，去帮朋友守一个月地摊，包准有效果，去实践，而不要只想！不克服这些缺点，一切不可能，甚至连项目经理都当不好--尽管你可能技术不错！

8、工作的同时要为以后做准备！建立自己的工作环境！及早为自己配置一个工作环境，装备电脑，示波器（可以买个二手的），仿真器，编程器等，业余可以接点活，一方面接触市场，培养市场感觉，同时也积累资金，更重要的是准备自己的产品，咱搞技术的没有钱，只有技术，技术的代表不是学历和证书，而是产品，拿出象样的产品，就可技术转让或与人合作搞企业！先把东西准备好，等待机会，否则，有了机会也抓不住！

9、要学会善于推销自己！不仅要能干，还要能说，能写，善于利用一切机会推销自己，树立自己的品牌形象，很必要！要创造条件让别人了解自己，不然老板怎么知道你能干？外面的投资人怎么相信你？提早把自己推销出去，机会自然会来找你！搞个个人主页是个好注意！！特别是培养自己在行业的名气，有了名气，高薪机会自不在话下，更重要的是有合作的机会...　

10、该出手时便出手！永远不可能有100%把握！！！条件差不多就要大胆去干，去闯出自己的事业，不要犹豫，不要彷徨，干了不一定成功，但至少为下一次冲击积累了经验，不干永远没出息，而且要干成必然要经历失败。不经历风雨，怎么见彩虹，没有人能随随便便成功！

 

原文及出处：http://www.51testing.com/?161787/action_viewspace_itemid_95211.html

在大家懵懵懂懂之中，踏入测试大军的那一刻起，想来都曾经看过或者说都曾经被问过：身为一个测试人员，需要具备什么素质？测试员的责任是什么？

　　在从事了一两年的测试工作之后，很多人在坚守着自己当初对这个行业许下的诺言。也有些人，终日混在开发人员堆里的（这个几率很大），渐渐的就如被火烫伤过的猫一样，收回了自己的利牙和尖爪，他们和开发人员一起，“各管一片”，只是应对着某一个小小的问题。在测试中，即使发现了别的问题，也会因为这个问题跟这次测试的主要目的不同而“ 视而不见”。。

　　这样的测试到底对不对？自己以前的思维到底对不对？

　　我近来常常在思索这个问题。

　　一个成规模的测试团队，却因为其中有偶尔的几个有过编程经验，可以帮助开发人员去Fix Issue的人而得益。这是怎样一个团队？一个测试人员，不从如何提高自己的测试水平出发去努力，而是努力的如何去跟开发人员搞好关系（我不是说不重要），如何去游说周边的人，开发人员修改一个问题或者发布一个版本的辛苦。。这是怎样的一个团队？

　　我无语。。

　　无论如何难解。我还是坚定地认为，测试人员应该首先看清自己的责任。应该明白什么叫做测试的机会和测试的成本。应该懂得如何在发现Issue的第一时间来报告和促使解决这个问题。

　　这些都是最基本的知识，确实在现实生活中，尤其在这样的开发和测试团队中最难做到的。。

　　我相信，终有一刻，终有一日，坚守的会开发结果。放弃原则的，夹缝中的人，会无处藏身。。

　　记住测试人员的责任：站在客户的角度，尽早的找出bug,并且促使其修复。

　　 好的测试工程师应具备的素质

　　人是测试工作中最有价值也是最重要的资源，没有一个合格的、积极的测试小组，测试就不可能实现。然而，在软件开发产业中有一种非常普遍习惯，那就是让那些经验最少的新手、没有效率的开发者或不适合干其他工作的人去做测试工作。这绝对是一种目光短浅的行为，对一个系统进行有效的测试所需要的技能绝对不比进行软件开发需要的少，事实上，测试者将获得极其广泛的经验，他们将遇到许多开发者不可能遇到的问题。

　　1.沟通能力。

　　一名理想的测试者必须能够同测试涉及到的所有人进行沟通，具有与技术（开发者）和非技术人员（客户，管理人员）的交流能力。既要可以和用户谈得来，又能同开发人员说得上话，不幸的是这两类人没有共同语言。和用户谈话的重点必须放在系统可以正确地处理什么和不可以处理什么上。而和开发者谈相同的信息时，就必须将这些活重新组织以另一种方式表达出来，测试小组的成员必须能够同等地同用户和开发者沟通。

　　2.移情能力。

　　和系统开发有关的所有人员都处在一种既关心又担心的状态之中。用户担心将来使用一个不符合自己要求的系统，开发者则担心由于系统要求不正确而使他不得不重新开发整个系统，管理部门则担心这个系统突然崩溃而使它的声誉受损。测试者必须和每一类人打交道，因此需要测试小组的成员对他们每个人都具有足够的理解和同情，具备了这种能力可以将测试人员与相关人员之间的冲突和对抗减少到最低程度。

　　3.技术能力。

　　就总体言，开发人员对那些不懂技术的人持一种轻视的态度。一旦测试小组的某个成员作出了一个错误的断定，那么他们的可信度就会立刻被传扬了出去。一个测试者必须既明白被测软件系统的概念又要会使用工程中的那些工具。要做到这一点需要有几年以上的编程经验，前期的开发经验可以帮助对软件开发过程有较深入的理解，从开发人员的角度正确的评价测试者，简化自动测试工具编程的学习曲线。

　　4.自信心。

　　开发者指责测试者出了错是常有的事，测试者必须对自己的观点有足够的自信心。如果容许别人对自己指东指西，就不能完成什么更多的事情了。

　　5.外交能力。

　　当你告诉某人他出了错时，就必须使用一些外交方法。机智老练和外交手法有助于维护与开发人员的协作关系，测试者在告诉开发者他的软件有错误时，也同样需要一定的外交手腕。如果采取的方法过于强硬，对测试者来说，在以后和开发部门的合作方面就相当于“赢了战争却输了战役”。

　　6.幽默感。

　　在遇到狡辩的情况下，一个幽默的批评将是很有帮助的。

　　7.很强的记忆力。

　　一个理想的测试者应该有能力将以前曾经遇到过的类似的错误从记忆深处挖掘出来，这一能力在测试过程中的价值是无法衡量的。因为许多新出现的问题和我们已经发现的问题相差无几。

　　8.耐心。

　　一些质量保证工作需要难以置信的耐心。有时你需要花费惊人的时间去分离、识别和分派一个错误。这个工作是那些坐不住的人无法完成的。

　　9.怀疑精神。

　　可以预料，开发者会尽他们最大的努力将所有的错误解释过去。测式者必须听每个人的说明，但他必须保持怀疑直到他自己看过以后。

　　10.自我督促。

　　干测试工作很容易使你变得懒散。只有那些具有自我督促能力的人才能够使自己每天正常地工作。

　　11.洞察力。

　　一个好的测试工程师具有“测试是为了破坏”的观点，捕获用户观点的能力，强烈的质量追求，对细节的关注能力。应用的高风险区的判断能力以便将有限的测试针对重点环节。

   游戏测试工程师:通过不间断的测试劳动，保证游戏产品的质量。

　　以用户角度评定游戏产品的质量及游戏品质包括两点：

　　1.以用户角度评定的游戏性——及可玩性

　　2.以用户角度评定的游戏的稳定性——及bug的多少

　　游戏测试工程师的职责：

　　1.最初期，验证策划案的合理性——为了玩家的可玩性、平衡性、风险性

　　2.开发前期测试工作的准备——协助策划进行策划案的细化，进行测试分析讨论会、测试用例设计，测试用例研讨等 （目前许多国内公司没有做到这一点）

　　3.开发过程中，协助程序人员进行模块调试（目前许多国内公司没有做到这一点）

　　4.开发后期，单服环境的搭建（有的公司并不需要测试来搭建），资源整理和核对

　　5.以上工作完成，进入游戏执行测试阶段，本阶段分为三种：

　　1）功能验证：

　　-验证游戏功能是否与策划案相符

　　-从正向和反向对功能进行重复的测试已达到最终论证功能的正确性

　　-bug的整理和上报

　　2）测试推动开发：

　　-执行测试完成后，测试报告报告测试结果

　　-bug的回归和修改时间点控制，需要测试人员不断的与策划或者程序人员进行沟通以期在预期时间内将功能正常发布

　　3）功能验收：

　　-功能发布前的最终确认，资源核对以及功能发布单的签字等

　　以上为游戏测试工程师的一些工作

　　而用户体验工程师：有些偏向于产品化相关的工作内容，主要针对游戏性，及游戏功能测试中的易用性方面的测试。现在很多公司都已经把用户体验提到了日程上，用户的喜好关系到游戏的生存与否，一款受广大玩家喜爱的用户，或者是游戏功能上有吸引力，或者是游戏上手性好，易于理解或者操作，总之就想通用软件的测试一样。用户就是上帝，用户的任何习惯都值得我们讨论和分析。

出处及链接：http://www.51testing.com/?action_viewnews_itemid_87995.html

1、测试项目：删除

　　测试方法：对已拨/已接/未接/拒接中的电话记录进行单条删除和全部删除操作，当电话记录达到最大容量时，手机自动删除最老的记录，并且保存最近的电话记录。

　　判断标准: 手动删除操作能够实现，而且当电话记录达到最大容量时，能够自动删除最老的记录，并且保存最近的电话记录。

　　2、测试项目：保存

　　测试方法：对已拨/已接/未接/拒接中的电话记录进行保存操作?

　　判断标准: 电话记录保存操作能够实现。

　　3、测试项目：呼叫

　　测试方法: 对已拨/已接/未接/拒接中的电话记录进行呼叫操作?

　　判断标准: 电话记录呼叫操作能够实现。

　　4、测试项目：发信息

　　测试方法: 对已拨/已接/未接/拒接中的电话记录进行发信息操作。

　　判断标准: 对电话记录能够实现发信息操作。。

　　5、测试项目：存储空间确认

　　测试方法: 正确显示存储空间总量，并且区分已用空间、未用空间。

　　判断标准: 能够正确显示存储空间容量。

　　6、测试项目：通话计费

　　测试方法: 在网络的支持下，是否能查询最近一次通话和总通话的通话话费；必须可以对通话话费进行清零重计费操作

　　判断标准: 在网络的支持下，可以实现通话费用的查询及清零重计费操作

　　7、测试项目：通话计时

　　测试方法: 查看手机是否能保留上次通话时间、所有呼入通话时间、所有呼出通话时间、和全部通话时间?

　　判断标准: 必须能够保留各类通话时间。通话过程中必须正确显示通话所持续的时间。

 

出处及链接：http://www.51testing.com/?action_viewnews_itemid_87741.html

等价类划分法:是把所有可能的输入数据，即程序的输入域划分成若干部分（子集），然后从每一个子集中选取少数具有代表性的数据作为测试用例。该方法是一种重要的，常用的黑盒测试用例设计方法。

　　划分出的等价类中按以下三个原则设计测试用例:

　　①为每一个等价类规定一个唯一的编号。

　　②设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖地有效等价类，重复这一步。直到所有的有效等价类都被覆盖为止。

　　③设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步。直到所有的无效等价类都被覆盖为止。

　　一般来说，等价类划分法对我们功能测试是最有帮助，同时也是最实用的测试方法，结合边界类测试法就可以设计很多好的case，我的经验是在设计case的时候，针对某一个feature功能是否正常，可以尝试先开启与这个feature相关的feature，因为它们可能统一调用了某一个模块，或者相关数据在传送时会一起被传出去，而这些都有可能引起bug，开启后，可以设置相关feature的边界值，尝试一些边界边缘的值，等设置好后再来跑feature的case，在这种环境相对来说不单纯的环境下来跑case，发现的bug可能并不只是单个feature的问题，而且出现了问题后，再确认bug的过程中，把环境细化，让bug凸现出来。 所以说我们在考虑设计case的时候，可以多考虑用等价类划分法和边界值分析法来确认多个precondition以及多个step来设计成功的case 和失败的case，而这对找bug是很有帮助的。

　　一句话: 测试是为了失败而测。

　1. 不登录系统，直接输入登录后的页面的url是否可以访问

　　2. 不登录系统，直接输入下载文件的url是否可以下载，如输入http://url/download?name=file是否可以下载文件file

　　3. 退出登录后按后退按钮能否访问之前的页面

　　4. ID/密码验证方式中能否使用简单密码。如密码标准为6位以上，字母和数字混合，不能包含ID，连续的字母或数字不能超过n位

　　5. 重要信息（如密码，身份证号码，信用卡号等）在输入或查询时是否用明文显示；在浏览器地址栏里输入命令javascrīpt:alert(doucument.cookie)时是否有重要信息；在html源码中能否看到重要信息

　　6. 手动更改URL中的参数值能否访问没有权限访问的页面。如普通用户对应的url中的参数为l=e，高级用户对应的url中的参数为l=s，以普通用户的身份登录系统后将url中的参数e改为s来访问本没有权限访问的页面

　　7. url里不可修改的参数是否可以被修改

　　8. 上传与服务器端语言（jsp、asp、php）一样扩展名的文件或exe等可执行文件后，确认在服务器端是否可直接运行

　　9. 注册用户时是否可以以'--,' or 1=1 --等做为用户名

　　10. 传送给服务器的参数（如查询关键字、url中的参数等）中包含特殊字符（','and 1=1 --,' and 1=0 --,'or 1=0 --）时是否可以正常处理

　　11. 执行新增操作时，在所有的输入框中输入脚本标签（<scrīpt>alert("")</scrīpt>）后能否保存

　　12. 在url中输入下面的地址是否可以下载：http://url/download.jsp?file=C:\windows\system32\drivers\etc\hosts,http://url/download.jsp?file=/etc/passwd

　　13. 是否对session的有效期进行处理

　　14. 错误信息中是否含有sql语句、sql错误信息以及web服务器的绝对路径等

　　15. ID/密码验证方式中，同一个账号在不同的机器上不能同时登录

　　16. ID/密码验证方式中，连续数次输入错误密码后该账户是否被锁定

　　17. 新增或修改重要信息（密码、身份证号码、信用卡号等）时是否有自动完成功能（在form标签中使用autocomplete=off来关闭自动完成功能

 

 

出处及链接：http://www.51testing.com/?21023

　　bug描述的标准有：

　　1、基本标准：需要让开发人员能根据描述理解这个bug。

　　2、最好能让开发人员能明确这个bug在哪可以找到（定位）、需要怎样修复。

 

　因此我对bug描述的建议就是：

　　1. 有条理的把每个小问题列出来，分123，不要怕条目多。

　　2. 描述问题时一定要把背景交代清楚，即在哪些操作后或者什么环境中会出现，不要忽视那些你看来可能不会引起问题的操作，越细致越好。

　　3. 善于使用截图和视频录制，这些可以更直观的说明bug的产生过程和结果。

   4.再现：尽量三次再现故障。如果问题是间断的，那么最好报告问题发生的概率；例如，每3次出现一次，每3次出现2次等；

   5.推广：确定系统其他部分是否可能出现这种错误，以及使用不同的数据是否可能出现这种问题，特别是那些存在严重影响的问题。

   6.使用清晰的语言，尤其要避免使用那些有多个不同或相反含义的词汇。

   7.中立：公正地表达自己的意思，对错误及其特征的事实进行描述，避免夸张或忽略的语句，引起过度的注意力或忽视。

   8.走察：在你提交测试报告或测试评估报告之前先自己读一遍，最好是另有一个有测试工程师或测试经理走察一遍。
 

        测试是用来保证软件开发过程的高效性，以及保证开发出来的软件产品的高质量和可用性的。软件开发本身就是一件非常困难的事情，这也决定了有效的测试决不是简单的依靠一些测试工具就可以进行的。在使用工具的同时，我们更要加强关于测试的培训、教育，使大家对于测试首先有一个正确的认识。只有这样，我们才能够更加有效、高效的使用工具，才能够使测试真正起到它应有的作用。

卸载测试
文件－－－－安装目录里的文件及文件夹（如：程序安装在几处的)
　　　　　　 非安装目录（向系统其它地方添加的文件及文件夹）
它们包括（exe,dll,配置文件等)
快捷方式－（桌面，菜单，任务栏，系统栏,控件面板，系统服务列表等）
复原方面－卸载后，系统能否恢复到软件安装前的状态（包含目录结构、动态库,注册表，系统配置文件,驱动程序,关联情况等）(专门的测试工具regsnap)
卸载方式－－程序自带卸载程序/系统的控件面板卸载/其它自动卸载工具（如:优化大师)
卸载状态－－程序在运行/暂停/终止等状态时的卸载
非正常卸载情况－卸载软件过程中，取消卸载进程，然后，观察软件能否继续正常使用
冲击卸载－－在卸载的过程中，中断电源，然后，启动计算机后，重新卸载软件，如果软件无法卸载，则重新安装软件，安装之后再重新卸载。
卸载环境－－不同的(操作系统，硬件环境，网络环境等)下进行卸载
卸载后,该系统是否对其他的应用程序造成不正常影响（如操作系统,应用软件等)

安装测试
一：基本目标
1.安装程序能正确运行
2.程序安装正确
3.程序安装后能正确运行
4.完善性安装后程序能正确运行
二：一些方面
0、安装手册给的所有步骤得到验证；
1、安装过程中所有缺省选项得到验证；
2、安装过程中典型选项得到验证；
3、测试各种不同的安装组合，并验证各种不同组合的正确性(包括参数组合，控件执行顺序组合，
产品安装组件组合，产品组件安装顺序组合(如b/s)等)
4、安装过程中异常配置或状态（非法和不合理配置）情况进行了测试(如：断电；数据库终止，网络终止等)
5、安装后是否能产生正确的目录结构和文件，文件属性正确；
6、安装后动态库是否正确；
6、安装后软件能否正确运行；
7、安装后没有生成多余的目录结构,文件，注册表信息，快捷方式等；
9、安装测试应该在所有的运行环境上进行验证(手册上指定如：操作系统，数据库，硬件环境，网络环境等)；
10、自动安装还是手工配置安装
11、至少要在一台笔记本上进行安装/卸载测试，因为有很多产品在笔记本中会出现问题，尤其是系统级的产品
13、安装,该系统是否对其他的应用程序造成不正常影响（如操作系统,应用软件等)


a 是否可以识别大部分的硬件；对串口硬盘的支持；常见的显卡/声卡的支持；
b 确认打包程序的特性，比如installshield,不同的打包发布程序所支持的系统都是不一样的，
　　一个软件应该只能在确认的适应的系统上安装
c.空间不足的情况，安装过程中如果像安装盘放入大量文件
d.卸载过程不得删除系统应该保留的用户数据