对于测试人员来说，对软件能否实现预期的功能是测试的重点。除了功能测试之外，根据用户或者客户的需求，在有的产品或者项目中，可能还会有性能测试、安全测试等。尽管有很多不同的测试内容，但总结出来可以归纳为两种类型：
　　一种是可以依据具体指标验证的测试，例如功能测试，某个功能有没有实现，功能是否正确实现，我们都可以有一个明确的依据进行参考确认，再比如性能测试，在指定的环境、指定的条件，系统是否达到了指定的性能指标，都有量化的数据可以验证。这种可以依据具体指标验证的功能，无论是对于开发人员去实现，或者是对于测试人员进行验证，都是可以做到具体化，便于开发，也便于测试。
　　还有一种测试类型，就是不便于通过量化的指标进行测试。如颜色、样式、按钮的大小和位置。比如颜色的设置，客户对某个界面的颜色要求是红色的，开发人员根据自己的理解可能设计为深红色，而测试人员在测试的时候根据自己的经验觉得浅红色更适合。这样测试和开发在对颜色的认识和理解上不一致，就可能都没法说服对方，没法达成一致的共识，增加沟通的时间，降低项目的研发效率。
　　以上关于功能和界面方面的测试都只是我们测试中一小部分的内容，还有其它方面的内容只是可能我们还没有接触到。玩过微信摇一摇的朋友都知道，我们在进入摇一摇界面摇动手机的时候，会收到到一个来福枪的声音。我想，在最初开发摇一摇功能的时候，肯定也不是来福枪的音效，肯定也是在很多种声音中经过筛选并通过使用验证后才最终确定下来的。那么，对于类似这样的音效，是否需要测试呢？如果需要测试，作为测试人员，又该拿什么标准来测试吗？仍然以微信摇一摇功能为例，摇一摇的界面很简单，没有文字说明告诉用户这个功能的作用是什么，也没提醒用户怎么去使用，但是，作为一个初次打开该功能的用户，看到摇一摇的图片都会下意识的去摇动一下。而这样的设计的初衷，都是力求简单。假设我们也在微信项目组，在微信刚开始研发的阶段，其中关于摇一摇功能的要求，有一项要求是界面简单，易于学习和操作。而这个需求肯定是没法进行量化的，不同的人有不同的理解，那作为测试人员，怎么去对这个需求进行测试是一个需要考虑的问题。
　　之前有看过一篇报道，是关于深圳一座摩天大楼被发现使用了海沙（搅拌和混凝土所用的沙，是来自海边且未经过处理的海沙，而非一般常用的河沙，海沙盐分含量高，容易对钢筋产生腐蚀，进而影响到建筑物的使用寿命），后来是被相关部门勒令整改，并对当时使用海沙的部分做了技术处理。后来的处理结果怎么样，没去关注，关注的是摩天大楼作为一个硬件工程，建设过程中如果有了缺陷，怎么去修复，对于这样影响到工程质量的缺陷，又该怎么样去预防。摩天大楼不像软件产品，出现了缺陷对有问题的代码做重新编写就能够解决问题，考虑到时间成本和费用成本，对摩天大楼推到重建的可能性很小，除非有很重大的问题。
　　摩天大楼等硬件工程的建设和软件产品的研发，虽然过程都不一样，但都有一个共通的东西，那就是质量的保证。怎么样将硬件产品的质量控制方法借鉴到软件工程的质量控制，是一个值得学习的过程。平时注意观察的话，可以发现生活中有很多场景需要测试工作的介入，或者用到测试思维。

　　51Testing又有好消息告诉小伙伴了！51Testing软件测试网作品系列重磅推出全新丛书《软件测试工程师面试秘籍》

　　此次我们邀请到知名互联网企业测试专家李江（G.li），整理并撰写软件测试工程师的面试技巧，通过应聘流程介绍、常见的测试知识梳理、面试技巧分享，用轻松、愉快、亲切的语言，为广大应聘测试岗位的读者搭建了一条通向成功求职的光明大道。

　　本书适用范围广，专业实用性强，尤其作者整理了十几家公司的笔试、面试样题及答案，让读者预先演练，知己知彼，方能有备无患！

　　有小伙伴戏称：“此书在手，打遍天下HR”

　　全书共4章。

　　第一章：知己知彼，百战不殆。简单讲述了应聘的整体流程，并对简历、合同细节进行详细的说明。

　　第二章：磨刀霍霍，有备无患。针对计算机基础知识进行总结归纳，并结合近两年笔试、面试题讲解分析。

　　第三章：临阵磨枪，不快也光。阐述测试相关知识，包括测试理论、测试设计实践、测试自动化、性能测试、测试管理、测试职业规划。这部分还提供了十几家公司的笔试、面试样题及答案，附属了一线测试工程师及面试官的参考答案。

　　第四章：面面俱到，脱颖而出。列出了经验丰富的面试者们总结的面试注意事项、面试技巧、英文面试等，并给出100多个英文面试题库。

　　是不是很心动呢？是不是特别想要呢？现在这本书已经上市啦，可以直接在当当网上搜索《软件测试工程师面试秘籍》购买。

　　买之前可以先看看独家连载哦！连载地址：http://www.51testing.com/html/16/category-catid-216.html

　　职业发展现在已成为众多测试小伙伴头疼的问题，整天瞎忙活，却没有目标。不知该向什么方向发展，不知还应该学些什么，不知道除了自己现在的公司以外，其他公司的测试都是怎么做的，对跳槽也毫无把握。其实51Testing每年都会进行软件测试行业现状大调查，统计身处软件测试领域各个层次、各个相关岗位的测试同仁的工作情况，薪资情况，公司的测试团队发展情况，工具使用情况等等，并对所有调查数据进行统计分析，帮助大家更了解自己的工作、了解整个行业的发展，帮助测试人员更好的认识和定位自我，规划职业发展。
　　目前该调查已进行了8年，每年都会吸引上万人参加，统计出的报告质量非常高，真实的反映出这一年软件测试的发展现状，除广受测试从业人员的欢迎外，对公司管理层拟定测试团队发展计划、公司测试人才招聘也非常有指导作用。每份报告都被下载超过数万次，反响强烈。
　　2014软件测试现状调查活动正在火热进行中，问卷的设计在2013年的基础上做了进一步的修改和完善，力求使本次调查活动更专业、严谨、客观、实用，打造中国软件测试领域最具广泛性、权威性和实用性的产业调查。
　　欢迎广大软件测试从业人员前来参与，与51Testing携手，共同为提升软件测试从业人员整体价值，提高软件测试领域发展水平尽一份力量。
　　参与形式：http://vote.51testing.com

一个人从大学毕业，即开始发生从学生时代向职业人士的过渡，这种过渡走的好，可以实现梦想，体现个人价值；如果走的不好，则会误入歧途，纵有凌云壮志、万丈豪情，难免一生郁郁不得志！

有人说，毕业后有幸进入软件测试，就已经是迈向成功的第一步了。的确，近几年，软件测试作为新兴行业，正处于蓬勃发展的时期，也是IT人才需求榜上的热门职位之一，很多年轻人认为这是职场黄金地，都对此趋之若鹜。门槛低，上手快，无性别歧视，让众多青年男女顺利的迈出职场第一步。但是工作几年后，迷茫不知所措的声音陆续出现了。

在51Testing论坛职业发展版块中，很多小伙伴询问诸如“怎么走下去我的测试路”、“软件测试5年，有点迷茫”等等，也有很多人自发的进行一些薪资调查、工作情况调查等，最终的目的，还是想知道到底该如何规划自己的职业生涯。

纵观当今社会各行各业，对于个人的职业发展方向，从宏观上都可以划分为四个群体，即：

"低管理、低技能"-----普通工作者

"高管理、低技能"-----管理路线

"低管理、高技能"-----技术路线

"高管理、高技能"-----全面路线

软件测试职业发展方向，大体上与上述的通用职业发展路线相吻合，也可以分为管理路线、技术路线、管理+技术路线；只是针对该行业本身，有其特殊性和细致性。软件测试毕竟在国内还不算很成熟，走管理路线，面临的就是在公司测试流程优化、团队管理上，无借鉴案例。走技术路线，各公司的测试重点都不同，技术繁杂，使用的工具各不相同，流程不统一，不知如何学起。走管理+技术路线，却不知道目前行业对于这种高级人才的需求度以及薪资待遇如何，成长慢风险高。而且很多普通工程师深陷于机械重复的基础工作，对于其他公司其他同仁的情况，只能通过日常社交了解，到底走哪条路，自己到底现在处于什么水平，无法评估，因此对于职业规划更是无据可依。

51Testing每年都会进行软件测试行业现状大调查，统计身处软件测试领域各个层次、各个相关岗位的测试同仁的工作情况，薪资情况，公司的测试团队发展情况，工具使用情况等等，并对所有调查数据进行统计分析。查看分析结果，可以了解去年整个行业的发展情况，同行的技术水平，各公司测试团队的发展趋势。只有深入了解整个测试大环境，才能更加清晰的认知自己的工作，选择不只是自己感兴趣，而且是空间更大的职业发展之路。

2014年即将过去，软件测试产业又经历了一年的洗刷，身为测试大军中的你，目前对职场环境是否满意？你的薪资处于什么水平？你们公司的测试团队又经历了哪些变化？你是不是在与这个行业同步上升？参加调查：http://vote.51testing.com，让你清晰职业定位，选择对你最适合的职场之路。

　　软件开发难，恐怕大家都觉得最难的是搞清楚需求；但是其实更难的是管理需求。今天在北京.NET俱乐部上又有人提出了这样的问题，主要的难点是他的开发团队是为了自己的领导们服务的，几个领导都有自己的想法，而且不停的在开发过程中提各种个样的问题；开发进度无法保证，开发的结果总是满足不了要求……

　　其实这样的问题大家都遇到过，而对于普通的开发人员来说我们往往不去关心，认为这是项目经理的事情，但是其实不然，这样的问题涉及软件开发的各个环节，就算你是出于最底层的开发人员，一样需要控制项目经理交给你的任务。其实这里最重需要把握的一点就是：把任务控制在你能控制的范围之内。总结一下，我的经验如下：

　　第一：无论你的客户是谁，我们永远需要一个中介来接受需求；你首先需要和客户有个协议，需要他们制定某一个人来提所有的需求，这个人不需要是很高职位的人，而且往往最好的选择是中层的技术管理人员；用户的所有需求必须通过这个人的认可，就算是对方老总提出的要求，如果没有这个人的认可我们也不执行。这点非常重要，可是替我们减少许多麻烦。

　　第二：无论是什么样的软件开发过程理论现在都承认一个问题，那就是软件开发需要迭代。而且我们一定要面对一个现实，就是软件开发的过程是在不断的变化中寻找平衡的过程，我们的需求永远不会结束，我们的软件永远都在被修改；修改不是坏事，但是我们必须要保证在一定的时候可以拿出成果。

　　所以，控制迭代的增量就是非常重要的。一般我们公司的做法是，以两周为一个周期最为一个Release，一旦这个Release开始以后，任何用户的新需求就都需要放到后面的Release；我们不会决绝客户的需求，但是我们必须管理我们可以承受的进度。这样做的最大好处在于，在两周的时间内，我们一定可以为客户提供一个更好的版本，这可能不是客户现在心目中的最终结果（因为很多新需求都在后面的Release中），但是我们至少完成了我们在两周前所承诺的结果，客户得到他们想要的东西（当然不是全部），我们也可以很明确的告诉客户，我们完成什么样的需求。

　　而且在这样一个迭代的过程中，我们会发现很多需求中的不完善之处，每两周的时间我们都可以针对开发方向作相应调整。最终的结果是保证了客户的满意度，同时也保证了产品的按期交付。

　　在这里，我们需要明确的区分修改bug的需求和新功能的需求，bug应该是那些对软件主要功能造成决定性影响的缺陷，这些东西无论是我们开发人员自己发现的还是客户反馈的，都必须在当前的Release处理完；而新需求则必须放到后面的Release中去。明确区分这两种不同需求对软件项目的成功起到决定性作用。

　　第三：我们需要学会管理客户。可能有人觉得我在胡扯，客户怎么可能被管理，他们是上帝啊？？！！其实上帝也是人，而且是通事理的人。我们对客户永远不应该是100%的服从，正确的方式是控制用户对开发进度的期望值，尽量使他们一致。当然有些时候我们需要更强硬一点点，比如我就经常很直接的告诉我的老板，这个需求属于新功能，必须放到后面的Release中去。

转自：51Testing软件测试网

一般来讲，测试用例设计的时候可以采用二维的方式归类：
　　横向：根据对用的FDD进行分类。
　　纵向：根据测试类型进行分类。
　　横向
　　横向的分类主要根据功能模块进行划分。根据产品的不同而有所不同，但是一般每一个测试用例，都能追溯到一个具体的功能需求。具有类似功能需求的测试用例会放在一起，形成一个功能模块的测试集。

　　纵向
　　纵向的分类主要根据测试的类型进行分类。主要有以下几种类型：

　　BAT(Build Acceptance Test)
　　这类测试用例属于最基本的测试用例。一般都不复杂，但都是非常重要的基本用例。BAT测试用例具有很高的稳定性。BAT的测试用例大概会占测试用例的总数的30%左右。BAT里面的测试用例，往往都是作为Regression测试用例的。BAT的测试用例用例一旦fail, 意味产品有重大缺陷，基本无法发布。对应的测试用例发现的问题，往往为P1的Bug。

　　Core(Core Regression Test)
　　这类测试用例和BAT的测试用例很相似，代表核心功能，重要级别会比BAT要低些。测试用例会比较复杂，一般占整个总数的20%左右。一般Core集里面的测试用例fail, 对应的Bug也往往都是P1。Core和BAT比较难以划分，但是可以将不属于BAT和Func的测试用例划入到这个里面。

　　Func
　　这类测试用例往往是对BAT和Core的补充。BAT和Core执行的主要路径的测试用例，那么分支的测试用例往往都设计在Func里面，这类测试用例相对比较多和复杂，占整个测试用例的比例为50%左右。Func集里面测试用例fail, 对应的Bug往往为P2或者P3。

　　其他一般还会有，UI, Security, Performance, Localization等等。

　　大致结构和设计如下：
              BAT(30%)    Core(20%)   Func(50%)   UI   Security
Function
category

转自：51Testing软件测试网

　　我不清楚你的情况，但我很容易分心。我查看自己的邮箱，查看我的Facebook，查看我的Linkedin。我们生活在一个信息可以通过多种渠道推送给我们的世界。我认为这是件很棒的事—但这有时候会导致你效率低下。这里有4件事能够帮助你成为一个更高效率的测试者。
　　不要同时进行多项任务
　　你也许是世上最擅长同时进行多项任务的人。然而，这代表着你在每个任务上分配的就少了。在测试过程中需要相当的专心和注意力。这在进行多项任务时是相当不可能做到的事。
　　保持注意力需要大量的训练，在此，我有几个建议：
　　在固定时间查看与回复邮件。这代表着你会批量的处理邮件，而不是随时随地的处理。
　　有时候电话比邮件更有用。如果你需要写三封以上的邮件，那是时候可以拿起你的电话了。
　　把查看社交网络留到午餐时间——社交信息节食。你真的有那么喜欢关于猫的视频么？
　　致力于成为单任务的专家。你会发现，即使是一个CEO也会给你这个建议。
　　使用便利贴
　　在任意一天的开始，我记下了我需要完成的最重要的任务以确保我最大程度的完成执行测试任务。我将便签贴在我显示器的边缘，每天时不时的看看我的清单。我必须说我的生活中有很多乐趣，其中之一就是用笔在纸上划去一个任务的瞬间。
　　这个方法让你认识到你任务的重点。此外，它可以给你每天想要完成的个人目标。不要轻信我的话，动手试试吧！
　　书签
　　你是否曾有在WIKI上找不到东西的时候，例如test cards？你是搜索了10分钟呢？还是你不得不问问你一起工作的同事？把重要的网页保存为书签。这代表着你不用去记东西在哪儿。取而代之的，你浏览器上有条理的书签列表会让你便捷地访问所有内容，从测试工具到test cards到重要的链接.....
转自：51Testing软件测试网

　　数据库的存储引擎就是管理数据存储的东西，它完成下面的工作：
　　1）存储机制
　　2）索引方式
　　3）锁
　　4）等等
　　SQL语言：-----关系型数据库所使用的数据管理语言
　　1）数据定义语言（DDL）：DROP、CREATE、ALTER等对数据对象发生操作的语言。
　　2）数据操作语言（DML）：INSERT 、UPDATE、 DELETE，对数据本身发生更、删、改。
　　3）数据查询语言（DQL）：SELECT，专门用于查找数据。
　　4）数据控制语言（DCL）：GRANT/授权、REVOKE/收回授权、COMMIT/提交操作等等。
　　而非关系型数据库其操作语言就多种多样了。
　　数据库管理系统（DBMS）：管理和维护数据库所使用的软件，为管理数据的方式和方法提供载体和支持。包含：
　　1）用户管理
　　2）处理数据库连接
　　3）缓存
　　4）查询
　　5）日志
　　6）等等
　　用于不同程序设计语言连接盒管理数据库的接口：
　　1）ODBC
　　2）JDBC
　　3）PDO
　　4）ADO.NET等等类型的接口
转载自：51Testing软件测试网 http://www.51testing.com/html/57/n-866757.html

　　根据IEEE 828和CMM/CMMI，配置管理计划常常被认为是一份文档，确实的，对于一个大项目而言，往往需要制定项目自身的配置管理计划。
　　但不是所有的组织都是软件外包组织，不是每个项目针对的是不同的客户。
　　在非软件外包的高效软件开发组织中，推荐的配置管理计划应有三个层面。
　　首先是组织层面，一般，提供统一的配置管理服务，不会允许每个团队自己搭建配置管理服务器。所以对于组织级的配置管理服务要有所约定，约定的主要内容有：
　　如何建立项目文档目录？
　　如何建立产品级目录？
　　如何建立代码目录？
　　配置项如何命名？
　　配置库的备份和恢复如何进行？谁来进行？
　　什么情况下拉分支？什么情况下合并到主干？ 关于分支主干要提供多种模式，或者放开限制，让产品线或者项目组选择。
　　如何进行变更？ 一般应当在组织级进行定义和发布。如果放到项目层面，变更流程的制定太费功夫；当然有些大项目是有足够的预算和特殊情况需要专门定义项目级的变更。
　　对产品线和项目如何开展配置审计？
　　有什么推荐的配置管理实践？
　　组织级配置管理规程或者指南的更新频率在每年一次左右。
　　其次是产品线层面。对于特定产品线，已经存在大量的源代码和文档，那么结合实际，这个产品线在配置管理存储时有哪些约定？
　　比如对代码配置项和非配置项有所说明，不要假设每个团队新人都是代码配置管理达人，小心自以为是的新手加入一些自以为是的垃圾。虽然可以删除，但发现再删除，其本身就是成本。
　　比如哪些依赖项值得存储？
　　比如哪些区域是机密，权限另外管理
　　比如那些代码是核心代码，如果改动需要资深人员复核。
　　本产品线的主干和分支策略是什么？ 守护主干？还是先锋主干？无分支？还是单分支？还是多分支？
　　比如约定团队统一一致的工作环境：都把Java装在C:/java，把eclipse装在D:/eclipse
　　最后是项目层面。在有了上述组织级和产品线级的配置管理约定后，项目层面的配置管理计划中最关键的是需要明确人员、基线和项目特殊配置项。其中基线的安排必须与项目本身生命周期的选择相匹配，最重要而言，必须匹配于里程碑。
　　在这样的三层结构下，为项目高效计，不需要单独写项目的配置管理计划，只需把项目级的配置管理约定写入项目计划即可，一般的篇幅不超过1页。
原文链接：http://www.51testing.com/html/89/n-866189.html

　　公司在组建配置管理团队（主要是项目级的配置管理员）时，通常有两种选择。
　　1）兼职项目CM。即开发人员兼任项目CM。选择研发人员兼职的好处是项目CM了解项目进展和研发流程，能够与项目经理等一起合作，沟通无障碍。缺点是研发人员以开发任务为主，工作量大时可能难以兼顾配管工作，易导致配管工作延迟。这个方案的另外一个缺点是兼职配管的人员流动性大，项目内任务的调配，人员离职等都会造成配管更换的问题。从就职资格的角度来说。每位新任的配管都需要经过培训。这就加大了培训的难度。尽管，硬币的另一面是更多的开发人员接受了较为正式的配管培训。
　　2）专职项目配管。比如一条产品线设一个专职配管，负责该产品线下所有项目的配管工作。这种做法有利于配管人员的专业化发展，长期对公司来说也是有利的。但是这种模式的前提是公司的配置管理体系已经较为完善，对于项目配管的工作流程比较清楚，权责界定也较为明确。对于新加入的项目配管，企业能够很快通过培训让其上岗。确保公司的配管流程正常运转。
　　有人可能会问，第二种方案显然比第一种好，第一种方案还有存在必要吗？问题是现在很多企业在面临管理问题时，由于一些原因不能给足够的资金购买商业软件，也不会招聘正式的专职人员（这两点是企业配置管理三大误区中的两点）。背后的深层次根源还是对配管工作没有引起足够的重视。在领导还未能对配管引起足够重视的前提下，第一种方案就成了曲线救国的办法。至少解决了有无问题。慢慢的研发人员就会开始抱怨，任务重，事情杂。第二种方案也就顺理成章地成为领导自主自发的要求。
　　此外，配置管理团队（这里主要指组织级配置管理工程师）的定位和汇报机制也比较关键。由于该岗位与研发关系密切，最好是归属研发部门或项目管理部。向研发部经理或项目管理部的leader汇报。必须获得对配管工作的完全授权，避免出现研发部不认可、不配合的情况，甚至无法触及研发流程和数据的问题（听起来奇怪，但你见多了国内企业的乱象就会理解什么叫”见怪不怪”）。
原文链接：http://www.51testing.com/html/22/n-864522.html