以前一个人的时候很自由，加班后回家也没有什么负担和责任，现在结婚了就不一样了，以后有小孩就更难了。LG的工作需要经常出差，以后家里的事情基本上是我打点。现在的工作比较忙，晚上经常加班到9-10点，周末也是经常要加班。有时候还会将工作情绪带到生活中，为此LG不止一次的埋怨过我。

   公司有个女同胞，刚休完产假回公司，领导曾让她担任测试负责人，但被她委婉的拒绝了。为了家庭她舍去了好的升迁机会。有个朋友刚怀孕2个月就流产了，主要原因还是工作太劳累，她是搞软件开发的，已经干了3年多了，平时压力太大，流产后她就辞职转行了，之前她是个事业心很强的女人，挣的比她LG还多，上次和她通话，竟然从她口里说出挣钱是男人的事情，真的有点让我不可思议。我也是一个比较有事业心的人，不知道以后是否也能做到家庭重于工作？也曾想过换个行业，找个轻松点的，能准点下班，周末不需要加班的工作，但我不知道除了IT行业我还能干什么？即使找到了这样的工作我是否会甘心？内心一直都在纠结，家庭和事业很难平衡。

    静下心来想，家庭肯定要重于事业，有小孩后家庭教育很重要。不希望因为自己的时间精力有限而让小孩走上不健康的道路。所以现在初步的想法是：提高工作效率，尽量不加班，除非迫不得以，周末也尽量少加，多增加和家人相处的时间，在家里最好不想工作的事情。

  

  由于测试组长有事，请假一个月，所以我有幸体会了一次测试组长的工作，感慨颇多，简单总结了，具体如下：

1、  任务比较多时，需要根据优先级来安排任务，哪个最着急先完成哪个，且最好是记录下来排个顺序。因为有些任务是电话、开会上口头说的，有些是零散的邮件说明的，如果时间一长估计就忘了。这个我也就遇到过，当时项目经理隔三差五的给发个邮件说要完成哪些任务，我基本上都是来了任务就分配下去，未弄明白优先级，导致后来忙的团团转，一会儿要这个报告，一会儿要那个报告，结果呢要不是没完成，要不是就完成的质量不行。

2、  任务的细节最好搞清楚。比如要专项测试时问清楚测试版本，测试时是否需要抓相应的log,对结果反馈有没有特殊要求，如果在测试期间有新版了是否需要更换新版本测试，之前旧版本测试过的是否需呀用新版本再次验证….

3、  对任务完成的进度、bug数等相关信息要很熟悉，并能随时说出来。这个我也做的不好，记得开周会的时候被项目经理问及系统测试完成的进度如何，在规定时间是否可以完成，现在bug是否多不多，集中在哪些模块….，我当时脑袋都蒙了，不知道需要了解这些信息。当时我就说任务差不多能够完成，发现的bug都已提交到bug库了，如果想了解的话可以上那里查看。项目经理听了没说什么，我觉得自己做的很差。开完会后我就赶紧挨个问组内成员是否可以在预期的时间内完成任务。有了这一次的教训，在下次的例会上我就先做了相关方面的工作，任务分配下去了，过一段时间邮件或电话询问进度，然后也时不时的上库中查看Bug。

4、  测试人力方面有困难要及时找测试经理。当时也是测试时又来了个很着急的任务，人力实在有限，这个任务又不能延后，我都不知道怎么办，只是跟项目经理说人力有限，要完成的话很难。项目经理还比较好，知道我是临时的，所以她直接找到测试经理说明任务，一番沟通后又支援了一人，这样任务就能完成了。不知道为啥我自己就没想到找测试经理，当时的想法就是自己加班来完成，但那段时间我都连续家加了好几次班了。

5、  了解组内成员的能力。当时测试时人力有限，有3个人被临时支援测试。分任务前我先电话了解这个人之前测试的模块，也通过他们的领导了解到这几个人的测试水平，然后再分任务时可以有的放矢，将重要的模块分给能力强的，对于走case慢但发现Bug能力强的可以将任务少分点，让有时间做自由测试，以发现更多的bug.这方面我还是做的可以的。

6、  适时鼓励、赞美组内成员。前段时间是比较关键的时候，任务多、重，过几个星期就要出货了，所以周末难免要加班，平时晚上也要加班，同事都有怨气了，这几个人都是临时支援的，普遍有种只是完成任务，给我的感觉就是没有那种很尽力的感觉。我也能理解，所以当人发现比较好的bug时我都会发邮件赞美一番，或者是他们的工作习惯很不错时也会适时的赞美一下，组内有个新人很久都没发现bug，在这期间突然发现了几个bug，而且个别Bug也不错，为此我也特别发邮件鼓励了一番，没想到后来发现bug的数量有所增加。我不知道是否和我的鼓励有关，但进步了总该是好事。如果能细心认真的观察组内的成员，相信多多少少有一些闪光点是值得我去学习的。

 

目前的体会就这些了，毕竟经历的时间有限，相信如果在这个职位上工作的时间更长的话会有更多的体会，希望大家拍砖，谢谢。

在整个测试过程中，人是最重要的因素之一。不管是多好的过程，还是多好的方法，最终都需要由人来执行和完成。好的过程就像是一条高速公路，而人就是在这条高速公路上的车，好车配合好路才能够保证行驶的速度和安全。

　　测试经理在日常工作中的一个重要任务就是保持对测试团队成员的激励。一谈到激励，可能很多人下意识就会想到金钱，例如：给员工奖金，或者加工资。实际上，物质奖励只是激励方式的一种，但这并不是唯一的和最有效的方式。每个员工都有自己的梦想和目标，希望能够获得更多自主的空间，希望自己的才能得到施展，希望得到认可，希望自己的工作富有激情，因此，测试经理除了提供物质上的激励以外，更应该为员工提供一个施展他们才能的舞台，激发员工内在的自我激励和自我实现。而且每个员工的需求不一样，激励的方式也各不相同。例如：公开表扬对有的员工有明显的激励作用，但对于性格内向的员工，效果可能会大大打折；提供弹性的工作时间也是对员工的一种激励。下面介绍一些常见的激励方式。

　　1）满足员工的需求

　　作为团队核心的测试经理，必须针对部门内员工的不同特点“投其所好”，寻求能够激励他们的动力。每个人内心需要被激励的动机各不相同，因此，奖励杰出工作表现的方法也应因人而异。不同的人在不同时期的需求也是不一样的。员工主要的需求包括：

　　● 得到尊重和认可。

　　● 获得自我表现的机会。

　　● 在积极的团队氛围中工作。

　　● 获得一定的做决定的权力。

　　● 公平的竞争环境。

　　● 广阔的成长空间等。

　　要满足员工的需求，首先需要理解员工。这就要求测试经理在日常的工作和生活中能够多倾听、多观察，还应该注意员工的一些肢体语言或者异常的情绪波动等。测试经理可以通过以下途径获得员工的具体需求：积极倾听员工的呼声、换位思考、观察员工的情绪波动并做出积极的回应等。当员工的需求获得满足时，他们的工作效率会有很大的提高，员工的内在激励会起到重要的作用，团队会处于一个积极向上的氛围，员工的聪明才智和创造性才能够得到最大的发挥。

　　马斯洛需求层次理论（Maslow's hierarchy of needs），亦称“基本需求层次理论”，由美国心理学家亚伯拉罕·马斯洛提出。马斯洛是当代最伟大的心理学家之一，由于他的著作使人本心理学的观点更加丰富和清晰，所以被人们称为“人本心理学之父”。他的需求层次理论对团队激励有着很大的帮助。表1列出了根据马斯洛的需求层次理论得到的团队激励的实例。

表1  马斯诺的需求层次理论在团队激励中的实例

马斯诺需求层次	工作中的对应关系
自我实现的需要	参与挑战性的项目、创造性获得鼓励和支持、获得创新的机会
尊重的需要	获得尊重和认可、能够被委以重任
情感和归属的需要	友好的团队氛围、良好的客户关系
安全上的需要	工作的安全性、良好的工作环境
生理上的需要	基本的薪酬、工作空间、饮食

　　2）有效授权

　　测试经理在安排工作的时候，应该考虑让团队成员承担更多的责任并拥有更多的权利。授权并不一定是升职。测试经理在向其测试团队成员分配工作时，也要授予他们相应的权力，否则就不算授权。测试经理应该在合适的场合让所有的相关人员知道被授权者的权责，同时需要确保授权之后应该尽量减少干涉，要给被授权员工做相应决策的权力。

　　有效授权是一种很好的激励员工的方法。权力的下放同时也意味着责任的下放。员工在获得一定的决策权力的同时，也应该明白要全力以赴把事情做好，要对任务的结果负责。通过有效授权，员工的积极性和创造性能够被最大限度地调动起来，同时员工的责任感和主人翁精神会得到加强，对组织的认同感会不断提高。员工通过承担更多的责任，也获得提高自身各项技能的机会，从而获得更广阔的发展空间。但是在授权的过程中，测试经理也要注意确保授权的范围和员工的实际能力相匹配，尽量避免一开始就赋予给团队成员过多的授权和责任。在实际的授权过程中，测试经理可以以渐进的方式授予测试团队成员的权力，同时在必要的时候需要为员工提供相应的培训。

☆示例：有效授权

　　测试经理通常需要协调整个测试过程中的所有活动，包括测试计划和控制、测试分析和设计、测试实现和执行、评估测试出口准则和报告以及测试结束活动等。但是作为测试经理，并不需要对所有的测试活动亲力亲为，而是应该将测试活动进行划分，将测试过程中的一些活动下放到测试团队成员中去。在项目中可以采用“一事经理”的方式。所谓的“一事经理”，就是对某个独立的任务或活动具有决策权力的人。测试经理可以将测试活动中的测试环境管理、测试用例配置管理以及测试度量等任务的权力授予相应的测试人员，由其负责处理相关事宜，定期向测试经理汇报。

　　以测试度量为例，某个测试团队成员成为该任务的“一事经理”后，全权负责测试度量相关事宜，包括测试度量系统的设计、测试度量数据收集和测试度量数据分析等，而测试经理作为测试度量活动的一名成员而不是管理者参与到测试度量活动中。测试经理最终使用测试度量活动的分析结果作为其他活动的输入，例如：作为测试出口准则评估的输入。测试人员在“一事经理”这个方式下也得到了锻炼，自己的技能得到了增强，同时获得了整个团队的尊重和认可；测试经理也因此减少了日常的工作量，可以将更多的精力投入到其他测试管理活动中去。

　　3）有效沟通

　　沟通无时无地不在，测试经理每天要和各种不同角色的人以各种不同的方式进行沟通。有效地沟通能够节约测试经理的时间和工作量，同时也能帮助团队成员更好地完成任务。另外，有效地沟通还有助于构建一个开放的测试团队，最大限度地发挥团队的积极性。倾听是有效沟通的一个重要方面，尤其是对待团队成员的抱怨，测试经理更应该认真倾听，如果能做到认真倾听，大部分的抱怨都可以得到解决。很多时候，员工可能并没有期望问题得到解决，他们更看重的是测试经理或管理者的态度，通过认真的倾听，员工的问题即使没有得到解决，员工的不满意度也会得到很大的降低。此外，在沟通的过程中，测试经理要避免过于封闭而听不进员工的建议，或者只是进行有选择地倾听，例如：只听好的内容，对提及的问题视而不见，同时，测试经理必须对员工的意见及时进行反馈。

　　沟通的方式有很多，例如：面对面交流、Email、电话、文档评审等。测试经理应该根据实际需要选择合适的交流方式，例如：简短的信息传递，可以通过电话的方式很快解决；对于复杂方案的讨论，需要安排专门的会议；有些事情可以先通过Email的方式传递基础信息，给员工一个准备的时间，然后通过面谈的方式做最后的沟通。以下的建议将有利于改进沟通的效果：

　　● 多听少说。

　　● 使用简单、容易理解的语句。

　　● 注意使用合适的肢体语言。

　　● 不明白的要及时提出问题。

　　● 要经常沟通以及沟通要保持热情。

　　☆示例：有效沟通

　　测试经理和测试团队成员之间如果能够建立有效的沟通渠道，团队成员和测试经理之间能够有效地交换意见，将有助于测试团队成员的激励。但是在实际的测试过程中，测试团队成员很少主动找测试经理反馈意见。尤其是以技术为主的测试团队中，测试团队成员相对比较“内向”，交流不够主动。这种情况下，测试经理可以定制一个团队沟通交流计划，团队成员每个月都有一次和测试经理单独面谈的机会。测试经理会轮流和每个测试团队成员进行面对面地交流，给员工一个反馈意见的机会。这些面谈都是在一对一的情况下进行的，团队成员不会有太多的顾虑；同时面谈的时间都是提前计划好的，如果有需要反馈的问题或建议，员工在沟通之前可以做好充分的准备。测试经理在这种方式下要把面谈的气氛调节为一种非正式的交流，可以交谈任何内容，从工作到生活。

　　4）提供学习和培训的机会

　　现代社会，科学技术迅猛发展，信息和知识急剧增加，知识更新周期缩短，创新频率加快，各种技术方法层出不穷。如果员工不积极学习，就很难跟上时代发展的步伐，甚至会被社会淘汰。因此，每个员工自身都有危机感和紧迫感，从而自身都有学习和培训方面的需求和需要。这种情况下，为员工提供良好的学习和培训的机会，显然能够激励员工创造更大的价值。通过提供学习和培训的机会，不仅员工自身的能力得到增强，对组织的认同感提高，整个团队的能力也会得到提升，从而能够更加有效地完成相关任务，并承担更大的责任。

学习和培训的方式有很多，可以在团队内部组织交流和学习、相互进行培训，也可以聘请外部专家进行培训；可以通过E-learning的方式，也可以通过课堂教学的方式。要开展学习和培训，必须将员工的兴趣和工作需要结合起来。在开展培训之前，首先收集员工的培训需求，然后结合项目或者团队的目标，从而在个人目标和团队目标之间实现共赢。学习或培训后，需要及时收集员工的反馈，不断改进培训的效率和有效性。

　　☆示例：提供学习和培训的机会

　　“岗位轮换”是一种很好的学习方式。当测试团队成员在自己的岗位上工作了一段时间以后，相关技能已经熟练掌握，这个时候都希望能够有机会再增加一些其他方面的技能。这种情况下，可以在测试团队内部进行岗位轮换，给每个员工一个学习新知识的机会。在iBAS R1.0项目中，随着测试执行的不断进行，被测试对象中发现的问题越来越少，测试人员已经开始“审美疲劳”，觉得很难再发现新的问题。这个时候，在测试团队中进行岗位轮换，原来执行IGMP系统测试的人员开始测试DHCP功能，其他人也相应地进行轮换。通过这种方式，测试人员可以掌握原来不具备的知识，增加了对整个被测试系统的了解；同时由于相互轮换，起到了一个评审的作用，测试人员对新分配任务的功能可从自己的角度重新思考，可以对原来的测试用例进行修改或补充，这样也有利于发现更多的缺陷，提高被测试对象的质量。

　　5）尊重和认可

　　每个人都希望得到别人或团队的尊重和认可。尊重和认可能够使员工对自己更加自信、对工作更加热爱，能够鼓励员工提高工作效率。给员工的认可也要及时而有效，当员工工作表现很出色时，测试经理应该立即给予称赞，让员工感受到自己受到上司的赞赏和认可。测试经理可以通过各种不同的方式认可员工的工作表现，例如：口头赞赏、书面赞美、对员工一对一的赞赏、公开的表扬等，从而不断鼓舞员工士气。对于测试人员而言，当测试人员的建议被开发人员或项目团队采用、测试人员能够在项目早期介入项目开发活动、为测试团队分配足够的资源等，这些都是对测试人员的尊重和认可，可以激励测试人员更好地工作。

　　☆示例：尊重和认可

　　“每周之星”是一种表扬员工的方式，通过这种方式可以使员工感受到被组织的认可，从而获得满足感和成就感。测试经理每周发掘团队中表现出色的员工进行表扬，是尊重和认可的重要表现形式。员工的出色表现可以是各种各样的，例如：需求评审过程中发现了很多问题、测试设计过程中有效地引入了测试自动化、为客户制定了良好的解决方案等。测试团队每周肯定都会有一些特别的事情发生，因此，总归可以发掘成为“每周之星”的员工。即使是测试团队处于项目的前期学习阶段，也有很多员工的行为是值得表扬的，例如：对及时总结或者分享学习成果的员工进行表扬。“每周之星”这样的形式不仅对员工的工作进行了认可和表扬，而且能够激励其他员工不断地努力。

　　6）物质奖励

　　上面介绍的几种激励方式更多地偏重于精神上的鼓励。实际上，除了精神激励外，物质奖励也是必不可少的，它也是日常工作中经常使用的一种方式。薪水不仅能保证员工生存，同时能者多得的薪酬机制也能有效地起到激励效果。物质奖励的多少依赖于员工能为公司带来的价值，例如：对于为公司创造出高利润、开发出赢利新项目的核心人才，通过加薪激励是必不可少的。在使用物质奖励方式的时候，一个重要的考虑因素是公平。如果某个员工的贡献突出，那么可以对这个员工进行单独的奖励。假如突出的是团队共同努力的结果，那么需要对整个团队进行奖励。同时物质奖励要有充足的理由，确保只有表现优秀的员工或者团队才能够获得物质奖励。

　　☆示例：物质奖励

　　物质奖励的方式既可以是单次奖金的形式，也可以是加薪的方式。在平时的激励过程中，测试经理应该综合应用这两种形式。每个季度可以对个人或团队进行一次评比，对表现突出的优秀个人或者优秀团队进行单次的奖金激励。每年对团队成员进行综合考核，根据团队成员的年度表现，对不同贡献的员工进行不同程度的物质奖励，可以是年度的加薪，也可以是年度加薪和单次的年终奖相结合的方式。

　　上面介绍了几种常见的激励方式，其实，激励的方式还有很多，例如：建立良好的团队氛围、鼓励大家注意身体健康、重视工作和生活的平衡等。在日常管理过程中，测试经理应该灵活应用各种激励方式。

　　激励测试人员的方式有很多，同时也有很多方式会打击测试人员的积极性，造成消极的影响，例如：测试人员在一个几乎看不到结束期限的项目上工作；测试人员致力于保证产品的质量，并且投入了额外的时间和精力，但是由于一些外部因素影响，输出的产品仍旧没有满足计划中设定的目标；尽管测试人员尽了最大的努力，但还是没有及时完成测试任务；如果测试人员的贡献没有被理解和衡量，不管最终结果是否成功，对测试人员而言都很可能造成消极的影响。

本文转自：http://www.51testing.com/html/02/n-226402-3.html

   提取测试需求是软件测试活动中的基础工作，是测试活动展开的前提条件。

        在项目实施前在做整个系统的测试方案中工作量评估时，如果是基于系统功能点的方法，则已经对系统中的功能点、性能点等进行分析统计，可以直接在该分析结果的基础上进行细化和完善。

    外包项目测试活动中确定用户需求范围是最重要也最困难的工作之一。往往在项目实施前无法准确界定测试范围，原因很多，主要有以下几个方面：

1、系统用户需求不详细，从而无法确定测试范围；

2、用户需求中简单的描述，可能包括很多研发工作，也需要测试，容易别忽略；

3、行业经验不足，对其中的业务不熟悉，造成对业务功能不能确定；

    在测试过程中，带来测试范围变化的原因，主要包括：

1、在研发过程中客户较大的改变原来的需求，扩展原来的需求；

2、研发公司改变客户的需求，带来测试范围的变化；

    综合以上的原因，主要来自于三个方面：

1、客户的需求前期描述不清，后期的增加、修改变化；

2、研发公司对需求的变更；

3、我们自己团队行业业务、项目经验的不足；

  对于第1点，可以约定测试用户需求的基线版本，对于研发过程中需求变更超过一定范围，重新评估增加的工作量。

  对于第2点，可以同第1点一样，同客户在前期约定好。

  对于第3点，则是需要一个过程，业务和项目经验积累需要一个过程。

        要确定测试需求，相当于确定了测试范围，则能比较准确的确定工作量。如何分析测试需求呢？

        首先、分析用户提供的所有文档，在业务分析师的帮助下，根据业务分解系统功能，由粗到细，逐渐细化需求，这其中需要客户、研发团队的协助，把不清晰、不明确、不具有可测试性的需求转化明确的、具有可测性的需求。根据测试需求对应的集成测试、系统功能测试和性能测试活动不同，其测试需求也不同，例如，对于产品集成测试，则测试需求细化到测试集成的每个模块接口、子系统接口即可。对于功能测试则时一个具体的功能实现，该功能可能时一个典型业务中的一个操作，也可能是整个典型业务。如果是一个典型业务的一个操作功能，则最好把整个典型业务的测试需求串接在一起，形成一个典型业务的测试需求链（具有相关的测试需求形成的一个序列）。

        其次、把测试需求尽量使用测试管理工具进行管理，便于测试需求的统计、变更，以及与测试用例形成关联。

        测试需求在客户评审通过后，要形成基线，以后用户需求变更后，要进行测试需求的变更，且保持测试需求与用户需求的版本一致



    这篇文章觉得写的不错，所以转载一下。对于需求最近也深有体会啊。公司刚接收了一个新项目，客户的需求也比较简单，只说要有什么功能，一句话就没了。因为这个功能虽然是A模块的，但它牵涉到调用B模块，在A和B模块的交接处客户未做说明。于是开发想当然的做了，功能是做好了，也满足了需求，但对于用户来说是很不方便的，我们测试人员为此就提了bug.可以说这个测试还是很不错的，能够站在用户的角度考虑。

  ----------------------------------------------------------------------

需求一般分为显式需求和隐式需求两种

一、显式需求提取参照需求说明书：
1、逐个罗列出功能点，功能描述
2、考虑交叉功能点
3、画出业务流程图

二、对于隐式需求
1、针对行业知识，向客户（提需求的人）和项目组内熟悉产品的人请教。切记，“闻道有先后，术业有专攻”，在这方面很多人需要习惯并且擅长向他人学习，你就要问的他都烦。
2、针对用户实际需求，要问清楚他想解决的问题和以后的期望值，做到“未雨绸缪”，想客户之所想。期望值虽然暂时达不到，但一定会为你了解产品有非常大的帮助。
3、软件实际需求，在了解用户需求的基础上，向技术人员请教，了解当前产品所能达到的目标。

综上，把所有需求功能点罗列在一张表格里，找对应人员确认，查缺补漏

  偶然看到这篇文章《面对用户反馈的缺陷：我们能做些什么》http://www.51testing.com/html/75/n-221875.html，不禁让我想起了之前的公司。这家公司对测试还是蛮重视的，当然压力也是很大的。每个版本上发现的问题都需要对比上个版本，看是否为漏测的，所以每每发现了严重问题都比较害怕，所以每次的专项测试都希望尽量多测点，为的是少漏测，经常不要求加班的但我也会稍微晚点下班，为此那时候工作特负责，也特充实。这个还不算什么，特别是用户反馈来的bug，我们都要按模块进行归类，然后分析，看是否是测试漏测的，如果是的话需要写报告分析，为啥漏测，以后如何避免，然后再把它在用例中更新。

  现在换了新工作，压力没之前那么大了，对这些漏测的及用户反馈的Bug头都没对测试施压。想想这些我就觉得有点失落，在这样宽松的环境下测试的技术、水平如何提高？反正我不能这样，虽然头没要求，但我自己私下里还是得总结，反省，给自己点压力吧。

 

 

信产部CTA测试，英文全称：China Type Approval，即入网测试，只有通过了这一测试，才能获得信产部颁发的终端入网证。（相当一部分是在北京信息产业部电信研究所进行测试）

总体分为：室内测试和外场测试。

具体见：http://hi.baidu.com/dragoniye2008/blog/item/a4b7196cfcb5c7f6431694d3.html

  在新公司工作已经有3个月了，也快转正了，在此期间经历了几个同事的离职，有干了1年的也有干了好几年的。不禁会想自己的选择是否正确，再加上同经验的同事找的工作工资都比我高不少，但能力还不如我，这些因素造成了我浮躁的心理，所以在这段时间我没有很投入的去工作。我想或许转正时可以再跟领导谈谈工资的事情，但不知道该如何说出口。这阶段刚好有几个项目，一个项目是android的，而且需要提英文bug，自己一直在坚持学英语，加上有半年多的android手机测试经验，所以我特别想加入这个项目，但结果往往事与愿违，我被分到了其他项目组。为这事我又郁闷了一段时间，想想是否需要主动跟头说说，但又想自己刚转正不太好。总之有很多让我郁闷的事情、郁闷的地方，让我觉得在这个公司学不到什么东西。我总是在抱怨着抱怨那，但上周的一件事让我清醒了很多。

 之前我一直都在测A模块，对其他模块只是一个了解的程度，很少测。没想到在这个新项目组，另一个头分给我的模块却是我从未测过的，可以说是现在比较先进的模块吧，而且任务很急，加上那个case写的很专业，让我看不懂，或许因为我一点都不了解吧，再加上也没有一些环境搭配的说明书，之前只有几个同事测过，但大家都比较忙，很难有时间去教你。哎，这只能怪自己了，自己完全可以在不忙的时候，或者是自己晚上加个班啥的去了解，去问同事。总是说没地方可以学习的，这个就很好的啊。这个就是教训，在今后的工作中要不断学些，摆正心态，如果你想学的话在哪都可以的，也不要抱怨工资，如果你有能力的话还怕这个....

   公司交付软件时需要经过一系列的客户验收测试，在此次验收测试中客户发现了不少的问题。仔细看看其中的部分问题是不难的，步骤也不复杂，都是一些很普通的问题。我们总是说要站在客户的角度上去测试，但又有几个人能做到呢？其中客户发现的一个问题让我觉得自己真的是没站在客户角度的。

   问题大概是这样的：主界面上有一些快捷菜单，移动上下方向键可以在快捷菜单和时间widgets之间高亮，移动左右方向键可以在快捷菜单之间高亮，每高亮到一个菜单的话会有相应的动画或颜色显示。但现在这个动画或颜色不明显，有时候让人不知道当前高亮在哪个上面。这个问题其实在我测试中遇到好几次了，当时心理确实闪过一丝疑问，这个确实不明显，但我没有提单，为什么呢？公司其实在可用性方面做的还是很差的，没有相关的UI，或需求的话是不会改的。再加上之前的那个项目我提过几个和这类似的bug，都被reject，不是被开发reject而是被QA，她们认为现在是后期，只要不出现重启，某个模块不能用像这样的问题的话，才让提交。弄的我心里不舒服，有时候像这类问题我基本上也是睁一只眼闭一只眼。现在想想这种想法真的是不好的，像这次验收测试，客户提了不少这样的问题，导致重出版本，周末还得加班，还是苦了自己。如果不是被客户发现了而是直接投放到市场上，被最终用户投诉，那后果更严重。

   既然踏入了测试，就要把测试做好，也许有时候自己辛苦提交的bug被reject，让自己觉得很委屈，但有什么办法呢？自己提了总比被客户提要强。

   这几天在测试时发现一个小bug，大概现象是这样的：

  在进行操作时拔掉耳机后此操作被终止但未回到Idle界面，且这个操作功能正常，从这个现象来说也不是大问题，只是一个很小的问题，有时候对于这样的问题我都不会去提单的，但没想到这个操作对其他应用产生了影响， 某个应用启动不了。这可是个大问题啊。

  所以在测试时遇到小问题时不要轻易放过，可以再试试其他应用，或许会产生大问题，模块之间是相互影响的，谁知道会对哪个模块产生影响？

不论是刚接触测试的同学还是做测试已经有一段时间的同学，都会在一个问题上有类似的困惑：我们测试用例的粒度是粗点好，还是细点好。尤其是在时间紧张，人力有限，需要别人执行，后续需要维护的情况下，抉择更加艰难。本届黑灯舞会就这个问题展开了激烈的辩论。并获得了具有一定指导意义的结果。

　　正方观点认为：测试用例的粒度应该细点，主要体现测试细节

　　反方观点认为：测试用例的料度应该粗点，主要体现测试思想

　　论辩先由正方一辩马雯佳同学发言：“我方认为, 测试用例的粒度应该细点，主要体现测试细节。原因有（1）测试用例的编写就像是织网，而BUG就像是鱼，网织得越密，捕捉到的BUG就越多（2）测试思想的学习并不是一蹴而就的。对一个新人来说，这种学习是一个渐近的过程，具体到每个项目，更需要用更精细的用例来保证测试的覆盖率（3）设计详细的用例便于执行，便于新人理解，便于知识传承。”虽然做为一个新人，雯佳略显青涩，但言辞却很犀利。

　　然后是反方一辩达海发言：“我方认为, 测试用例的粒度应该粗点，主要体现测试思想。（1）粗并不等于简单。测试用例的粒度粗点，是建立在我们对需求完全理解，对设计完全掌握的基础上的粗粒度。这样我们可以避免繁琐的流程，提高测试执行的效率，把握重点需求。测试粗粒度可以避免陷入机械性的测试。（2）粗粒度的测试设计可以使我们把重点关注于设计，可以让测试往前走，在时间，资源有限的情况下，更高效地进行测试，保证产品质量。

　　随后进入激烈的自由辩论环节。双方你来我往，引起大家的阵阵喝彩。

　　正方：“测试用例过粗，当拿着过粗的用例都执行不下去时，如何让新人在执行中得到提升？”

　　反方：“如果都按照师父的提供的测试用例去测试，是否可以达到技能提升。”

　　反方：“思想就像大脑，测试用例是骨骼。在时间有限，资源有限时，必须要有所取舍，抓住主干测试，所以我们会追求白盒覆盖率而不是路径覆盖率。测试技能的提高是测试思想的不断丰富，测试手段的不断完善，而不是用例越写越细”

　　正方：“在测试领域有8：2原则，80%的bug源于经常修改的20%代码，tc的数量提升有利于减少这种bug遗漏。并且，越精细的用例越便于定位BUG”

　　反方：“就是因为我们的用例过细，导致在时间，资源紧张的情况下，导致覆盖律低，没有发现尽可能多的BUG,相反，如果我们在测试设计的时候，放得粗，可以把主要精力放在测试思想上，这样就可以提高测试覆盖率，发现更多的BUG。测试用例的设计要先搭一个整体的框架，然后再逐步完善”

　　正方：“逐步完善的过程是不是用例越来越细？”

　　在激烈的辩论中，时间到了。大家意犹未尽。

　　评委进行了精彩的点评：

　　辩论会是一种很好的形式，可以活跃大家思维。正方一辩马雯佳思路清晰，在立论阶段提出了很多很好的论据。可惜在后面的论辩过程中并没有展开。从管理者角度来看，还是希望测试用例的粒度细点好。

　　测试用例的粒度取决于项目质量的要求，时间的要求，用户的要求。如果时间充足，就可以把用例写细一些，时间紧张，就写粗些。有个词叫测试艺术家。就是要我们掌握质量与效率之间的平衡。

　　我们的用例不管是细还是粗，它都是为了达到最终目的“保证产品质量”。测试用例写粗点还是细点，可以用一个例子来说明。当我们刚学车的时候，什么时候打方向盘，什么时候踩离合，什么时候踩油门。都需要教练一步步教，要一步步来，这些都很明确的。当开车有一段时间后，什么情况下要做什么动作都会很自然，一气呵成。当我们的新人在进行测试的时候，需要很明确地知道怎么做，这时候用例就得细些。当成为一个很熟练的测试工程师的时候，设计用例时就不必纠结于这些细节了。每个阶段不同，做事方式就不同，只要满足结果就好。

本文转自：http://www.51testing.com/html/28/n-218628.html

 外包到hw已有1年半之久了，在这期间让我感受到了大公司的风范，但就是累了点。对于测试，公司还是比较重视的，其中觉得有些地方还是很值得学习的。

 1、先说说bug的处理。这个走的还是基本的流程，相信大部分公司都有的，但却有个很独特的地方，CCB。即这个主要是针对一些有争议的bug，开发认为是非问题，或者是修改这个问题风险比较大，拒绝修改，此时可不是开发说了算，这时候就是CCB起作用了。CCB成员主要是各个部门的头组成了，其中还包括测试经理哦。当然到CCB裁决时此时也是项目的尾声了，CCB裁决的单会直接关闭。如果对于被裁掉的单有异议的话可以直接反馈给测试经理，或许还有回旋的余地哦。

 2、对于无规律问题的处理。这个还是强调找找规律，对于那些找不到规律但抓的Log对开发定位有帮助的话就可以直接提单，对于那些没有log或者Log无效的话，就将这个bug提到疑难问题中，这个有1个专门的excel来记录。然后在后期会定期分配人专门去复现。

 3、质量意识。他们有1个事故级别（1级、2级...），所谓的事故就是漏测，这个包括的范围很广，小到手机彩盒，大到手机功能。记得有1次我不小心将手机掉到地上，发现扬声器被损坏了，像这种情况下测试要提单的，这个在我以前的公司还是从来没遇到过的。会将以往项目事故写成文档，事故现象，事故的原因分析等，对于新人都要先培训这个知识的。

4、知识共享。测试组人比较多，手机模块多。对于骨干的话都是负责几个模块，然后再输出心得体会，供新人学些参考。还有培训也是，大家相互培训学习。

 当然也存在一些问题，比如项目比较混乱，这个主要是项目太多了，时间又紧迫，有些bug在这个手机上合入了，在另1个项目上又不合....，但是在中国的测试行业相信他还是领头羊的。

本文转自：http://www.51testing.com/?1592/action_viewspace_itemid_83107.html

 

今天看到51testing上有这个问题，觉得很值得探讨一下，就在此谈谈我的看法。
 
关于这个问题，我粗粗的搜索以下网上的关于这个问题的说法，大都是空空理论之谈，实际操作起来并不一定适合。
 
说到回归测试用例，先说什么是回归测试。顾名思义，回归测试就是修改完bug之后对程序的新的一轮测试，据微软的统计，按照他们的经验，一般开发人员解决3~4个bug会衍生出一个新的bug，这就是必须作回归测试的原因。简单的说，就是检测一下解决了bug之后有没有带进新的问题，以免把聋子给治成哑巴，就得不偿失了~~
 
一般的软件测试的流程是后期快速迭代的，bug在后期是快速收敛的，debug和测试的周期也是越来越短，频率是越来越高，譬如说第一轮测试需要花上10天跑用例，那么到后期就没那么长的时间，可能就是1~2天的测试时间，在后期有时候一天就有一个新的版本，这时候就要求测试人员能快速的进行一轮回归测试。
 
一般来说，覆盖越高，风险越低，但是效率就越差，反之亦然。所以如果时间允许的话，能把所有的用例都再跑一边是最好不过的，但是一般不会有那么多的时间，这就需要在效率和覆盖之间有一个适当的平衡，选择其中一部分测试用例用来作回归测试。
 
选择回归测试的时候，首先要确定的是，回归测试用例的比例，这个要根据时间情况了，100%是最好了，我个人一般这个比例在60%左右。然后要确定回归测试用例的优先级。根据我的经验，一般有如下必须回归的用例：
 
第一，新修改的功能，这个显然是重点
第二，新修改的功能的关联功能，就是有耦合的部分，这个一般最好咨询一下开发人员
 
第三，程序最有卖点或者说亮点的部分，这个地方一旦有问题，会使程序质量大打折扣
 
第四，程序中最致命的部分，譬如说安全隐患，数据泄露，加密注册，
 
第五，程序中比较脆弱的部分，这个要咨询开发人员，一般就是他们心中最没底的地方
 
第六，程序的主干功能
 
第七，如果以上做完，还有时间的话，最好把用例中级别比较高的用例再执行一遍。
 
OK ，以上是回归测试用例的选择优先级。
 
其实，即使这样做，还是有风险的。最根本的解决方法是自动化测试工具加上手工测试。具体就是常用的程序主干功能，主要功能，用自动化测试，保证每一个版本都能够执行一遍，其他修改频繁的小功能手工测试了。
说了这么多，好像比较乱，总结一下。
 
个人觉得解决这个回归测试的终极解决方案是：
 
a.作每日构建
 
b.基线功能自动化
 
c.编写用例时一定要分级（按照风险度，常用度，重要度）
 
d.手工执行回归测试用例（就是我上面说的7项）
 
好了，这是我对这个问题的解决方案，欢迎大家补充，讨论，拍砖~~~~~~~~

 

  V模型体现了测试设计分层和测试执行分层的概念，本文以作者自身的理解谈谈测试执行分层，不过从实际项目运作情况来看，真正做到测试执行分层的并不多，这里原因有很多种，暂且不论。

　　1. UT

　　单元测试的对象是LLD中所划分定义的程序单元或模块，它也是单元测试用例设计中可测试的最大单元。该测试对象可能由一个或多个函数或者类组成，测试设计就是对测试对象进行测试用例设计。

　　UT的目的，是通过函数运行来检查模块代码对于LLD文档的顺从性，验证每个函数的输入输出响应，与它在详细设计文档中预先定义的是否一致。函数是产品开发实现的最基本单位，下一个实现单位是模块，从测试的角度看，希望UT完成后，每个函数都牢固可靠，下一步的IT测试将聚焦在函数之间配合能否实现分配需求，而不用担心函数本身的输入输出响应问题。

　　单元测试比较适合开发人员做。

　　2. IT

　　集成测试是指把若干个经过单元测试的单元组装到一起而进行的测试，集成测试应依据HLD，主要发现接口、依赖中的错误或不完善的地方。集成测试的对象为若干个单元测试对象的组合，至少为两个。

　　IT的目的，是根据模块设计对模块的分解，从已验证的函数开始，逐层向上集成，得到一个可运行的模块。

　　IT可以由开发人员做，也可以由测试人员做。

　　不难看出，UT是面向每一个单元的测试，IT是测试单元之间的接口，可以把UT/IT归为“单元级”测试。

　　3. ST

　　CMM定义的系统测试：系统测试是针对软件项目组所承担开发的软件系统进行的整体测试，将软件系统作为整体运行或实施明确定义的软件行为子集的测试。主要采用的测试方法是黑盒测试，即不管程序内部的实现逻辑，以检验输入输出信息是否符合规格说明书中有关需求规定的测试方法。可见ST的测试对象是规格说明书，更确切的说，是模块需求规格说明书，所以一般也称为MST。模块SRS文档给出了模块的输入输出的相应要求。MST后，每个模块是牢固可用的。

　　4. BBIT

　　BBIT为模块间接口测试，验证模块之间的接口能不能配合，有时和联调混在一起，其实目的并不相同。BBIT的目的，是根据系统设计对系统的分解，从已通过验证的模块开始，逐层向上集成，得到一个可运行的系统。而联调一般涉及软件、硬件或者不同产品间的配合测试。MST和BBIT可以归到“模块级” 的测试，一个验证模块，一个验证模块间的接口。

　　以上UT/IT/MST/BBIT一般由开发人员完成，系统基本可以运行起来了，测试人员可以开展SDV、SIT、SVT了。

　　5. SDV

　　SDV虽然属于测试人员开展的系统测试，但是有点偏灰盒测试，因为SDV验证各子系统的配合是否满足设计需求（DR），对内部的实现还是关注的，验证多个模块集成以后是否满足设计需求。

　　6. SIT

　　SIT也是验证设计需求是否得以满足，与SDV不同的是，SIT完全把系统当作一个黑盒来测试，不关心内部具体的实现。实际应用中，SDV和SIT 虽然都属于系统一级的测试，往往由不同项目组（子系统）的测试人员分别测试，他们只关注各自的子系统，所以还是把SDV和SIT归为“子系统级”的测试比较好。

　　7. SVT

　　SVT是验收测试，其测试对象是产品包需求OR。产品包需求给出了产品的范围，从产品可能的应用环境的角度刻画系统，SVT的目的就是确认（或验收）产品包需求给出的各种应用场景产品均能满足。

　　产品包需求不考虑内部实现的差异，SVT也是从整个系统的角度考虑包需求的各种应用场景，属于“系统级”的测试。

　　各个级别的测试描述完毕，回头再看看这个分层测试的模型图，不难发现以下几个特征：

　　1）基于系统架构的分解结构（系统－子系统－模块－单元），开发按照自顶向下的顺序逐层设计，测试按照自底向上的顺序逐层验证，这个分解结构在每一层或每一个阶段，将开发和测试过程统一起来。

　　2）在每一层，测试的对象是开发相应阶段设计的输出（包括需求和这个阶段的设计文档），测试的目的与开发相应阶段设计的思路是相辅相成的，所以决定每个阶段的测试如何开展、评价一个测试过程时，如果离开开发过程，只谈测试自身的话，是不系统、不全面的。

　　3）除了“系统级”的SVT测试以外，其他各层的测试均包含两个方面：一是对这个层每个构件的测试，有n个构件就要测试n次，二是这n个构件之间接口的测试。例如：nSDV（每个测试项目组的SDV是一个SDV）和SIT、nMST（每个开发项目组的MST是一个MST）和BBIT、nUT和IT。

 

转自:http://www.51testing.com/html/99/n-211399.html

在我测试工作的前5年，一直以为测试的目标和价值就是在黑盒测试活动中找bug，以找到bug越多越自豪。但当我随着商业意识的不断积累，跳出测试的视角，站在公司的角度看测试时，会发现测试的目标是商业成功，而不仅是找bug。商业成功的关键是什么？简单点说就是可以长期地稳定获得大量的客户并获得足够的利润。而要想长期稳定的得到客户的喜爱，就必须提供让用户满意的质量，这是测试找bug的初衷。可是商业成功要解决的“大量的客户”，“足够的利润”，如何由测试来保障呢？“大量的用户”的获得有时关键就是看谁的产品先推向市场，先占领市场。因此一个词“TTM——Time to Market”就是非常重要的，测试应该支撑项目在满足质量目标的条件下能及时地推向市场，而不是拖延产品的发布进度。“足够的利润”就要确保成本越低越好。减少研发人力：减少开发人力和测试人力；减少研发时间：减少开发修改bug的时间和减少测试活动时间；就能帮助产品减少成本，提高产品的利润。

项目成功的铁三角：质量，成本，进度。每一个关键因素都需要测试人员来做出贡献和支撑。如果仅仅只找bug，可能只支撑了质量，甚至有时也并未真正保障了客户想要的质量。那么测试如何支撑项目成功的成本和进度呢？这时需要的就不仅仅是自动化测试，虽然自动化测试能起到一定的效果。但更需要具有商业意识的测试领导者，站在公司的角度思考选择做正确的测试决策。

下面就以一个案例来证明测试如何更大地发挥其应有的商业价值：

如果一个项目有10个功能：3个功能支撑性能，3个功能支撑可靠性，2个功能支撑可用性，2个功能支撑基本功能。（客户最关心：可靠性，不太在意性能和可用性）

测试如何支撑项目获得更短的研发周期和更低的研发成本：

反面案例：

一个测试思考简单化的测试经理，可能要求10个测试人员进行10个功能的全面测试。1个测试人员的生产力为：1个功能需要10天测试完成，1天发现1个bug。10个测试人员用了10天时间完成了测试，并在每个功能发现了10个bug，一共100个bug。

1个开发人员的生产力为：1天修复1个bug。100个bug需要10个开发人员修改10天。

总结：重点功能50个bug，开发人力：100人天。测试人力：100人天，项目用时：20天。

正面案例：

一个真正了解客户需求，理解公司商业利益的测试经理做了如下决策：用10个测试人员，2个人一组重点测试可靠性的3个功能和2个基本功能，用时5天，每个功能发现10个bug，重点功能共发现50个bug。其余5个非重点功能的测试工作量可以减少一半，用时2.5天，每个功能发现5个bug，非重点功能共发现25个bug。开发人员10人，修改75个bug，用时7.5天。

总结：重点功能50个bug，开发人力：75人天，测试人力：75人天，项目用时：15天。

从以上数据可以看到，只需要测试经理或测试架构师多用一点时间来思考，以公司最终目标：“在保障满足客户需求质量的前提下成本更低，进度更快”为自己的工作目标。避免大而全的唯bug论，就可以发现在重点功能质量标准不下降的前提下，可以实现开发和测试都节省了25%的研发成本和25%的研发进度。

测试如何支撑项目获得更高质量的同时有更短的研发周期和更低的研发成本：

测试经理做了如下决策：用10个测试人员，2个人一组重点测试可靠性的3个功能和2个基本功能，每个功能发现15个bug，重点功能共发现75个bug，用时7.5天。其余5个功能的测试工作量可以减少为1/4，用时1.25天，每个功能发现2.5个bug，非重点功能共发现12.5个bug。开发人员10人，修改87.5个bug，用时8.75天。

总结：重点功能75个bug，开发人力：87.5人天，测试人力：87.5人天，项目用时：17.5天。

  从以上数据可以发现在同样的测试人力和开发人力情况下，最应该保障的重点功能发现了更多的bug，为原方案的150％，必须重点关注的地方的相对质量得到了提升，而研发成本下降为87.5%,研发进度减少了2.5％。

本文通过一个简单的案例故事，说明了测试的价值不仅是找bug，只要我们测试工作追求科学的思考，而不盲目的干活，那么我们测试执行活动也能在提高关键质量目标的同时，帮助公司降低研发成本，减少研发时间，全面真正支撑公司商业成功所必须的：更快的进度，更低的成本，更高的质量。

希望我们广大测试人员能从平时的测试工具研究使用和测试脚本开发过程中多抬头思考，选择正确的事来做，做到事半功倍。要相信测试人员能创造更大的商业价值，而不仅仅是bug。

注：本文转自http://www.51testing.com/?uid-293557-action-viewspace-itemid-172908