svn help ci

页面检查
合理布局
1、界面布局有序，简洁，符合用户使用习惯 
2、界面元素是否在水平或者垂直方向对齐 
3、界面元素的尺寸是否合理 
4、行列间距是否保持一致 
5、是否恰当地利用窗体和控件的空白，以及分割线条 
6、窗口切换、移动、改变大小时，界面显示是否正常 
7、刷新后界面是否正常显示 
8、不同分辨率页面布局显示是否合理，整齐，分辨率一般为1024*768 > 1280*1024 >800*600
 
弹出窗口
1、弹出的窗口应垂直居中对齐 
2、对于弹出窗口界面内容较多，须提供自动全屏功能 
3、弹出窗口时应禁用主界面，保证用户使用的焦点 
4、活动窗体是否能够被反显加亮
 
页面正确性
1、界面元素是否有错别字，或者措词含糊、逻辑混乱 
2、当用户选中了页面中的一个复选框，之后回退一个页面，再前进一个页面，复选框是否还处于选中状态 
3、导航显示正确 
4、title显示正确 
5、页面显示无乱码 
6、需要必填的控件，有必填提醒，如 * 
7、适时禁用功能按钮（如权限控制时无权限操作时按钮灰掉或不显示；无法输入的输入框disable掉） 
8、页面无js错 
9、鼠标无规则点击时是否会产生无法预料的结果 
10、鼠标有多个形状时是否能够被窗体识别（如漏斗状时窗体不接受输入）

这个面试题碰到过很多次， 再次总结下来。

　　具体需求： 有一个登陆页面， 上面有2个textbox, 一个提交按钮。 请针对这个页面设计30个以上的test case.

　　此题的考察目的： 面试者是否熟悉各种测试方法，是否有丰富的Web测试经验， 是否了解Web开发，以及设计Test case的能力

　　这个题目还是相当有难度的， 一般的人很难把这个题目回答好。

　　阅读目录

　　功能测试(Function test)

　　1.输入正确的用户名和密码，点击提交按钮，验证是否能正确登录。

　　2.输入错误的用户名或者密码, 验证登录会失败，并且提示相应的错误信息。

　　3.登录成功后能否能否跳转到正确的页面

　　4.用户名和密码，如果太短或者太长，应该怎么处理

　　5.用户名和密码，中有特殊字符，和其他非英文的情况

　　6.记住用户名的功能

　　7.登陆失败后，不能记录密码的功能

　　8.用户名和密码前后有空格的处理

　　9.密码是否以星号显示

　　界面测试(UI Test)

　　1.布局是否合理，2个testbox 和一个按钮是否对齐

　　2.testbox和按钮的长度，高度是否复合要求

　　性能测试(performance test)

　　1.打开登录页面，需要几秒

　　2.输入正确的用户名和密码后，登录成功跳转到新页面，不超过5秒

　　安全性测试(Security test)

　　1.登录成功后生成的Cookie，是否是httponly (否则容易被脚本盗取)

　　2.用户名和密码是否通过加密的方式，发送给Web服务器

　　3.用户名和密码的验证，应该是用服务器端验证， 而不能单单是在客户端用javascript验证

　　4.用户名和密码的输入框，应该屏蔽SQL 注入攻击

　　5.用户名和密码的的输入框，应该禁止输入脚本 （防止XSS攻击）

　　6.错误登陆的次数限制（防止暴力破解）

　　可用性测试(Usability Test)

　　1. 是否可以全用键盘操作，是否有快捷键

　　2.输入用户名，密码后按回车，是否可以登陆

　　兼容性测试（Compatibility Test）

　　1.主流的浏览器下能否显示正常已经功能正常（IE,6,7,8,9, Firefox, Chrome, Safari,等）

　　2.不同的平台是否能正常工作，比如Windows, Mac

　　3.移动设备上是否正常工作，比如Iphone, Andriod

　　4.不同的分辨率

　　软件辅助性测试 （Accessibility test）

　　软件辅助功能测试是指测试软件是否向残疾用户提供足够的辅助功能

　　1. 高对比度下能否显示正常 （视力不好的人使用）

【译者注】：

原作者是Qingsong Yao，他的Linkedin在这里 http://www.linkedin.com/in/qingsongyao，里面有着详细的介绍。

这里简短摘抄翻译几句：

MS SQL Server Group — 资深测试员 — 7年

MS SQL Azure — 资深测试员 — 目前所在项目

原文发布时间：2012.12.14

原博文地址：blogs.msdn.com/b/qingsongyao/archive/2012/12/14/tester-s-career-series.aspx

注意，此文非常长，中文版都有18000多字。请各位在阅读时，放松，保持耐心，带着思考，为自己下个5年谋划谋划。

思想的启发，至少是黑暗中、迷糊中的一丝灯光。你的职业生涯只能是你自己做主、你自己规划，旁人只能是讲讲自己的经验，给出建议，你能学到什么和做些什么改变，只能靠你的水平。

在此，我十分感谢Qingsong这篇博文（的确让我有了更多的认识和思考），以及对翻译的指点和修订。

【正文如下】：

我已经从事测试工作超过7年，从测试员(SDET)成长为高级测试员(SDET II)，最近再从高级测试员成长为资深测试员(senior tester)。在我作为专业测试员的职业生涯中，我曾疑虑过我是否应该转行去做开发，我是否能在其他公司找到另一份测试工作，我们的软件测试员是否有更好的职业前景，以及我们（微软）拥有的测试员是否过多。在这系列博文中，我将给大家分享下我的一些想法，讨论如何才能成为资深测试员，并有一个更好的职业发展。这篇文章是写给我们的测试员和测试经理。我希望我的文章能帮助你深入思考测试和测试员的职业生涯，并希望你有一个更好的职业生涯。本文分为两部分，在第一部分中，我描述了测试员的四条进阶之路；在第二部分中，是我给我们测试员的一些建议。你可以在 这里 下载这篇文章的Word版本。

注：本文是我之前系列博文的总结，并只是我个人的看法。

目录

第一部分 - 成为资深软件测试员的四条进阶之路 2

成为一个专业的QA 2

成为一个测试架构师 5

成为一个领域专家 5

成为一个工具开发人员 8

转行或继续 9

结论 12

第二部分 - 我的一些建议 13

激情和动力 13

开放的思想和广泛的兴趣 14

提升影响力(Making Big Impact) 15

编码，编码，编码 16

花时间去思考 17

了解产品 18

用不同方式做事 19

给测试经理的建议 19

结论 21

第一部分 - 成为资深软件测试员的四条进阶之路

在这篇文章中，我认为我们的软件测试员有四条潜在的进阶道路。它们是： 1）成为专业的QA。知道如何使用不同类型的测试工具开展网络测试，性能测试，负载测试和压力测试；  2）成为领域专家。可以像最终用户一样来使用你正在测试的产品；  3）成为测试架构师。可以领导整个团队和整个公司的测试以及质量保证； 4）成为工具和框架的开发人员。可以开发出世界一流的测试工具； 我还将讨论工程师的其他进价道路，比如转行去开发人员或PM，改变你的工作领域。

成为一个专业的QA

在本节中，我想讨论成为资深软件测试员的第一条进阶道路，是成为一个专业的软件测试员。在许多公司里，我们称软件测试员为QA（质量保证），QA这种角色在微软成立软件测试员(SDET)这种角色之前，便存在了很长的时间。你可能想知道的质量保证和软件测试员(SDET)的区别是什么。我们的测试员是质量保证吗？

让我引用这里的QA定义来开始我们的讨论：

QA 代表质量保证，它是一个框架，以确保在符合规定要求下进行开发和制造产品，例如药品，农药和医疗器械。

这是一个需要个人成长 ，实现和持续改进的质量体系 ，不，这不仅是另一份工作。事实上，这是一个跟其他工作都不一样的工作。

作为一个专业QA意味着你会得到一个真正的机会，去影响工作实践和提高质量的标准。这个职位，能够提供多种个人的、职业的发展选择，在不同的项目、过程和地方里扮演不同角色。这是一个真正负责任的职业，同时也要求个人的真正能力。

你可以从上面的定义看到，QA是一个专业的职位，如牙医，教师一样，它需要自己的技能。在我担任软件测试员的整个职业生涯中，我关注了许多专业QA的博客。比如James Bach ， James Whittaker ， Elisabeth Hendrickson ， Cem Kaner 和许多微软内部测试架构师。他们教会我什么是软件测试，为什么我们需要测试，以及我们如何做测试。那么，他们之间有什么共同的地方吗？他们都是世界上的最好QA。他们都有非常深厚的测试知识，如基于模型的测试(Model Based Testing)，探索式测试(Exploratory Testing)，生产环境测试(Testing in Production)，基于情景的测试(Scenario Based Testing)。他们乐于分享，活跃在社交网络之中，常常把他们想法分享给我们广大的软件测试员。这非常棒，让我们可以看到现在有许多很好的测试技术和技术日新月异的变化。

正如你看到的，成为一个专业的QA，重要的因素不是编码的技能，而是测试的技能。另一方面，软件测试员(SDET)可算是一种专攻的测试用例自动化的软件工程师。换句话说，SDE们（软件开发工程师 - Software Development Engineer）为实现产品而编写代码，而测试员（这里实际指SDET 软件测试开发工程师 - Software Development Engineer in Test）们为自动化测试而编写代码。编码技能，是我们的测试员应有的最重要的技能之一（如果你的代码能力不够强，我预计，微软将不会聘你为测试员）。

然而，作为一个软件测试员并不妨碍你成为一个专业的QA，反而你还有很多成功的机会。在我们的日常工作​​中，我们有很多机会去学习新的测试方法并可在我们的项目中进行实践再掌握它们。能够深刻得理解测试方法，并能够在你的测试策略中使用它们，对测试项目成功来说是非常重要的。

那么，如何才能胜任一个专业的QA？你必须做到：

• 知道并使用不同的测试方法，比如基于模型的测试，探索式测试，用户界面​​测试(UI Testing)；
• 在一些领域有深入的测试知识，比如性能测试，网页(web)，手机应用测试，安全性测试（或一个安全专家）；
• 熟悉一些测试工具，比如JUnit，NUnit，MSTest，Selenium或商业QA工具，如HP负载测试工具(HP Load Running)，或VSTS负载测试工具；

让我解释一下，成为一个专业的QA，我们为什么需要第二个和第三个技能。当一个公司想雇用一个QA，他们通常都有一个明确的期望，他们想雇用一个什么样子的QA。由于不同领域的测试方法可能有着显着不同，因此QA趋于更专业，一些QA擅长安全测试，而另一些QA具有网页设计经验。公司想要招聘一些在某些领域内有经验的人，那才能够解决他们的迫切需要。例如，当正在开发一个网站时，我们可能会想雇用一些熟知性能测试、网站基础设施的人，以帮助测试网站的可扩展性。如果你能熟知流行的网络测试工具，那将是你的一大优势。例如，如果你知道Selenium，最流行的Web UI测试工具之一，它会给你在就业市场上的增加你的竞争力。在大公司里工作，比如微软，它同时会带有优势和劣势。就优势而言，你将有机会做不同类型的测试，并培养你相应技能。另一方面，你可能会使用内部测试工具（不公开性质的那些工具）。你也可能只是测试系统里的一小部分（也就是说，你可能对你负责的那块进行了非常深入功能测试），但很少有机会测试整个系统。如果你在一些领域有深厚的功底，如安全领域，或性能领域，你会在未来有更好的职业生涯。

成为一个专业QA的另一个关键技能，不是测试的技能，而是其他的技能。想象一下你希望加入一家规模较小的公司或初创的公司，只有测试技能，可能无法确保你能应聘上这份工作。但是，如果你能够做些其他工作，如自动化编译版本，搭建Web服务器，创建部署脚本。你将有更大的机会被录用（因为你可能不是全部时间都在做测试，所以，如果你能在同一时间做很多不同的事情，那你将是一个非常不错的候选人）。

为什么我们应该立志做一个专业的QA，而为什么不干脆永远做一个软件测试员？做一个优秀的软件测试员，是同时需要编码技能和测试技能。然而，我们需要在未来选择一个领域来深入，要么编码要么测试。这真的取决于你是否对软件测试有激情，和是否把它作为一种事业。如果你喜欢测试本身，成为一个专业的QA是一条很适合的职业发展道路。此外，同时拥有编码技能和测试技能将是你去应聘其他公司的QA职位时的亮点之一。另一方面，我也看到很多软件测试员对今天的工作并不满意，而且我认为根本原因是，他们有着工程师的根(engineering root)，并不喜欢测试。如果你真的喜欢编码，转行到开发或做更多的测试自动化，测试类库的开发可能是你的方向。在过去，我们曾经有两个独立的角色：SDET，STE（软件测试工程师），一个专注于自动化，另一个专注于测试，和许多公司一样，他们也有类似的角色，如亚马逊，谷歌。我认为这有一定道理。

我们可能会从上面的定义中注意到的一件事，质量保证是许多行业都有的职位，不仅仅在计算机软件行业。例如，在汽车行业，QA是负责审查我们的汽车是否符合质量要求(meets the quality bar)。不幸的是，在软件行业的QA还不够成熟。今天，几乎没有哪个学院设立软件测试专业或者设置一个软件质量保证的学位。我们中的许多人选择软件测试员作为我们的职业，因为我们被雇用来担任测试员，并不是我们喜欢做测试。我们看到了很多关于测试员（SDET）在公司内外职业发展的博文和文章，我们还将在不久的将来持续看到这种情况。只是因为测试作为一个专业的职业还不够成熟，我可以预言，这里面很快就会发生很大的变化（例如，在必应(Bing)团队中，我们做了一种改革， 没有单独的测试员， 所有人都是软件开发工程师， 每个人都负责自己的程序的质量时，我们采用在生产环境测试(Testing in Production)，把测试员的角色调整到更广的服务监测和运营领域中）。

成为一个测试架构师

在本节中，我想讨论我们如何能够成长成一个测试架构师。在这里，测试架构师不是一个头衔(title)，而是一个角色(role)。例如，如果你在很多测试工具 / 框架上都做出了突出的贡献，你可能有一个测试架构师的头衔，你也可能不是一个测试架构师。同样，一些软件测试员在他们的公司中扮演测试架构师的角色，但他们没有一个测试架构师的头衔。

测试架构师的角色意味着什么呢？在这里，我列出了测试架构师应该着眼的几个重要领域：

• 定义一个功能的整体测试策略，比如，如何测试一个浏览器，如何测试一个云数据库等；
• 某个测试领域的专家，如安全性测试，性能测试，云测试；
• 在团队中引入或发明新的测试方法，如探索性测试，众包测试(crowd sourcing testing)；
• 根据具体情况指导和培养团队；
• 思考测试的未来和测试员的职业发展的未来，并为未来做好准备；
• 参与测试相关的活动，如测试访谈，会议，博客；

怎样才能成为一个测试架构师呢？首先，它不是一个简单的事情，你需要先成为一个专业的软件测试员。作为专业的软件测试员，你会在你的日常工作​​，提高上述的能力，再成长为一个测试架构师。另外，许多架构师都在不同的公司、团队中接触过了不同的项目，所以都是非常有经验。参与到不同类型的项目之中，你总是能得到一些新的想法。最后，你必须有一种能力，即在任何项目中能迅速地适应变化(adopting change)，并做出贡献。这个技能对测试架构师来说非常重要。

今天有一些测试架构师为其他公司提供咨询服务。他们通常有广泛的知识，敏捷开发，项目管理，沟通技巧和风险管理，并帮助拯救许多几乎失败的项目(help to survive many nearly failed projects)。他们是最好的专业软件测试员，并在相关领域中获得了尊重。

成为一个领域专家

今天，我想说我们软件测试员的职业生涯中最重要的一条路，就是成为一个领域的专家。我们必须认识到，我们当中许多人最终是不会成为测试工具的开发人员或测试架构师。他们将成为专业的QA，一个领域专家或只是转行到一个新的岗位。就个人而言，我更喜欢你考虑在领域专家这个方向努力。

领域专家是谁？

让我来回答这个问题。假设你测试特定的软件测试五年，那你有资格成为一个领域专家吗？答案是不一定，取决于领域专家的定义。

举例来说，我已经测试了SQL Server六年。我很熟悉数据类型，排序规则(collation)，并能编写基本的SQL查询语句。“领域专家”在这种情况下，应该能够设计数据库应用程序或者管理数据库。为什么我这么来定义领域专家，因为它是搞数据库的人在其他公司找工作时一个基本要求（一个数据库开发人员或一个DBA）。我能胜任领域专家吗？我并不这么认为，因为我只知道SQL Server的一小部分。而我对这些都没有经验，比如，设计一个数据库架构(database schema)，开发一个使用的数据库的应用程序或者管理大量的SQL Server实例。所以我很难找到一个数据库开发人员的工作或一个DBA的工作。

正如你可以从上面的例子中看到，“领域专家”是的的确确取决于上下文。如果你在Windows团队中工作，“领域专家”就应该知道安装 / 配置 / 管理Windows或者能够编写基于Windows的软件。如果你在Visual Studio团队中，“领域专家”就应该知道如何使用Visual Studio和.NET编程。如果你在Windows Azure和SQL Azure中，你就应该知道如何通过使用所有可用Windows Azure的技术来构建一个可伸缩的应用程序。从这个意义上说，领域专家，需要你有一个全面理解，而不只是在某一小块里非常深入而已。他同时还关注于最终用户是如何得使用我们正在测试的软件或服务。

我们为何要成为一个领域专家？

有一天，你可能会考虑离开目前的职位，你可能选择加入另一个团队或另一个公司。你可能会问自己的一个问题是，从我过去作为一个软件测试员的经验中，学到些什么样的技能，或者我能胜任什么样的职位。不幸的是，今天我们很多的软件测试员只对他们的所负责部分有着深刻的理解，但他们缺乏测试产品应有全面的视野。其中一个原因是，今天我们的测试员过于注重功能性测试，我相信这是我们不太注重用户的使用场景或者我们的最终用户是怎么在使用我们产品。这也是我即使测试了SQL Server六年，我依然没有资格担任一个数据库开发人员或一个DBA的主要原因。

你可能会问，为什么我们应该考虑成为一个领域专家，或另一种问法，为什么不就永远待在测试角色上。原因是，它会为你的未来打开一个非常宽广的门，让你有一个更好的职业。领域专家的需求将远高于专业的QA，另外补偿金(compensation)也将更高，尤其是当你成为一个解决方案提供者时。

对微软的软件测试员，更是如此。我们公司有大量的优秀产品，有非常多的客户。对熟悉微软产品，并知道如何打造端到端解决方案的领域专家或专业人士都有着很高的需求。你越了解微软产品，你的职业发展越好。

给软件测试员的建议

现在，我想给我们的软件测试员提供一些建议。首先，问问自己，你三年后想成为什么样子的人，要成为一个领域专家，或者想成为一个专业软件测试员。这个问题，我建议你尽早地思考和作出决定。

然后，如果你想成为一个领域专家，你需要有一个成长计划。这里有一些可以帮助到你的步骤：

1）选择一个你想专注的领域。我们在微软实在是太幸运了，我们有这么多伟大的产品，因此我们有许多领域可以专注。近年来，IT技术的变化日新月异，我们应该谨慎选择那些IT趋势的领域。在这里，我想有几个你可能有兴趣知道的领域：

• NoSQL和BigData是数据库管理领域的热点。市场对熟悉NoSQL（例如Hadoop，MongoDB等）的人有着巨大需求。
• Windows Azure是微软的云计算平台。完全理解的这个系统和知道怎么构建可扩展的系统，将是你的职业发展中的一大优势。
• Windows Phone和Windows 8是我们下一代的操作系统。能为这些平台构建应用程序，能让你轻松地找到一个开发人员工作。
• 企业客户希望整合社交网络，office，移动和必应（Bing）搜索以提供更大的生产力。熟悉Office 365，微软其他的产品能够可以让你成为一个解决方案的提供者。

2）在你的工作中培养你的技能。一旦你有对你想熟悉什么样的领域有一个想法后，你需要培养的相应技能。如果你目前的工作领域不是你的兴趣所在，考虑转到其他团队。此外，做一些副项目(side project)，参与车库项目(Garage projects)中做些基层创新始终是一个不错的方式来提高你的技能。作为一个微软的员工，你有着很多优秀的资源可以利用，我强烈建议你发掘，总结你的知识。我强烈建议你​​设定了一个目标，并持续不断地提高你的技能。这是你的事业，你应该认真地投入时间来对待。请看我的其他博文，你可以从中找到另一些提高自己的建议。

给主管和经理(Lead and Manager)的建议

亲爱的主管和经理，我希望你能认识到并非你所有的员工，在最后都能成为一个专业的软件测试员。我们应该帮助我们的成员，增长他们的领域知识，并给他们一个更好的职业。有一天，当你的员工决定转行或离开公司时，他们会感谢你提供的机会，以帮助他们学到自己的知识，并感谢微软提供了一个让他们能成长的平台。

有时，建立一个健康、快乐的团队，比完成的任务更为重要。微软拥有的优秀员工正是我们宝贵的财富。作为主管和经理，我们应致力于让我们的员工感到开心，并有一个更好的职业发展。鼓励人们学习新东西，让员工能在某些领域里投入自己的时间，始终是一个培养员工的不错的方式。你也将认识到，如果这样做，你的员工也会引入一些新东西到他们的日常工作​​中。拥有领域知识和了解顾客如何使用产品，一直对测试都有很大益处，这将是软件测试的趋势。

成为一个工具开发人员

今天，许多我们的软件测试员编写了测试类库和测试框架，协助测试自动化和测试运行自动化。在整个公司里我们有很多的测试框架，测试运行系统。编写测试工具是一项重要的技能，它可以帮助我们的软件测试员增加他们的编码能力。如今，很多软件测试员开发测试框架和测试类库。他们和其他开发人员一样写一些代码。测试工具开发人员和软件测试员之间的一个很大区别是，编码技能是开发人员最重要的技能，而对软件测试员来说最重要是测试技能。

我们的工具开发人员面临的一个挑战是，你应该与使用你所创建的类库的其他人紧密合作，并确保你的确提高了工作效率。请记住，编写工具不是你的目标，让其他人更敏捷才是你的目标。

我能给想要成为工具开发人员的软件测试员一个建议是，你可以大体上看看，编写一个测试工具跟编写的其他软件是一样的，所以如果你有良好的编码能力，你可以在很多团队中有着潜力无穷的成长，所以不要限制自己去寻找一个软件测试员工作或只编写测试类的工具。

另一种观点认为，测试工具开发人员和编译器开发人员，UI开发人员或数据库开发人员一样，他们只是在不同的领域具有专业知识的开发人员。这是我之所以把本节的标题写成“成为工具开发人员”，而不是“成为测试工具开发人员”。

它带来了另一个有趣的观点，就是我们的测试员(SDET)角色实际是专业软件测试员和测试工具的开发人员的混合体。我们希望大家通过编码（开发的角色）来做更多的测试自动化（测试的角色）。但是，在某些情况下，我们发现在这两个领域，我们都不太擅长。它可能潜在地限制我们的软件测试员长期的职业规划。

转行或继续

我曾打算写一些建议，关于你是否​​应该留在你目前的职位或转行到另一个其他团队、其他公司的职位。在写下我的想法之前，我想我可以给你一些关于这个主题的参考。

第一篇文章是一个10年前Interface上发表的一篇文章，标题是“职业生涯？什么职业生涯？”。文章首先说，“你的职业生涯发展是你的责任。”和“你管理着自己的职业生涯。”然后说你，你的经理和微软怎样一起合作，帮助你的成长。这篇文章提供了一系列的问题让你进行思考并回答。根据你的答案，并提供些很好的建议，无论现在是否应该做出改变。我最喜欢它的一部分是，它有很多的探索式(probing)、开放式(open-ended)的问题。例如：

回顾……

• 你最享受的是做什么？是什么驱使你投入时间来干得这么漂亮？(What was it about those times that made them so good)
• 有时你会特别不喜欢你的工作吗？为什么？
• 去年里你感到最骄傲的成就是什么？
• 在你开始你的职业生涯后，你的抱负或长期目标有所改变吗？何时？为何？你现在将如何​​描述你的长期目标？
• 你的价值观是什么（一个主要标准，判断你是如何做事的）？你目前的工作和你的部门（微软）是否符合你的价值观？
• 你的经理是如何做你的教练？还有谁是你兴趣的好教练？

展望……

• 你真正擅长什么？从你的职业生涯中，你最想收获是什么？
• 当你展望你的职业生涯时，是否有些事情你特别想避免吗？为什么你想避免它们？
• 你认为在未来十年中你的职业生涯将会出现什么？
• 你需要什么样的技能或经验来为你下下个工作准备？对于十年的计划，你需要什么样的技能或经验？
• 你的经理（或微软）可以做些什么来帮助你实现你的目标？你需要从他们身上得到什么，才能使你获得成功？
• 当你展望你的职业生涯时，有什么是你特别期待的事情吗？理由是什么？
• 你认为你的下一个工作将是什么？下一个工作之后，你认为你的再下一个工作又将是什么？

回顾，你会被引导着去思考过去的工作经验。展望，你会被引导着去思考你想成为什么样子。思考这些问题，会真正帮助你整理职业生涯的思路。

然后，第二篇文章是在讨论这个问题，即“是改变的时候了吗？” 。文章列出了职业发展的八大选择模式：广泛(Enrichment)，偏向(Lateral)，垂直(Vertical)，跨职能(Cross-functional)，重新调整(Realignment)，探索(Exploratory)，执行(Peform)，和其他的追求(Other Pursuits)。这篇文章讨论了，你是如何在做决策，比如什么时候应该作出改变、什么时候又不是一个合适的改变时间和如何做好你的功课，再做出一个合适的改变。它也列举了很多别人的例子。例如：

如果你不满意你的工作，不管是因为你不喜欢你现在工作的类型，还是因为你共事的人的价值观或者公司文化跟你不对路，做出改变也许能帮你走出这种状态，但你得先做下功课！Lou Nee Gerard如是说：“跳槽换工作不是一个避难所。做出的改变应该是积极的，应该因为你真正想要去做些什么，而不是去摆脱你不喜欢的事情。”，他曾从行政职务转行到PM。

当你有一个明确的目标，并你已决定是否投入额外的努力时，这可能需要一个新的挑战(challenge)，你应该时刻关注这些潜在机会能不能满足你的目标，并时刻准备采取行动。例如：

跟你的经理聊聊。根据不同的情况，这可能是一个非常宝贵的步骤或一个你不想采取的步骤。你的经理可能是你最好的支持者并支持你的改变。如果你开始提你想要做的事情和你现在的工作不一样，虽然有些经理可能会感觉受到了威胁，一个优秀的经理会认识到对微软来说，你的成长是一件好事，并尝试与你一起向你的目标努力。

有时候你和你的经理很可能不是很合拍。这种事难免。如果你不能跟你的经理聊，你可能需要选择另一位导师，来帮助你做决策。

安排非正式的访谈。现在有不少谈论工作的非正式谈话，比如他们做了什么，他们是如何到达这种水平，什么样的技能才是重要的。你不需要你的经理像针对正式的访谈一样进行审核批准，就能组织安排这样非正式的访谈。这样的访谈实际上有利于微软这个整体：你将了解到更多适合你的职业发展方向和更多微软提供的机会。

如果你的目标是成长(growth)…… 考虑寻找一个比较成熟的团队并且负责人有着良好的记录。在一个运作良好的团队中工作，你可以学到很多东西，包括何时创新以及如何创新，何时交付和如何交付，以及优秀的团队过程。

如果你的目标是提升(advancement)…… 考虑一个具有部门的战略价值的初创团队。这些团队开始都比较小，成长非常快。他们可以为你提供快速提升、回报明显的机会。初创团队的风险与机会并存，新团队有更大的升迁机会，但也有较高的风险，其中许多团队是从来没有交付出任何东西，并且他们可能需要在人员不足的情况较长的工作时间。

看看微软之外。 从我们公司之外的人得到一些建议。设计师和MSTE易用性培训经理 Scott Berkun 说到“真正的职业发展是远比微软大的。你在这里看到的差异和对比，可以帮助你做出更明智的决策；在某些情况下，我们更比其他高科技公司，分层和分级得更多，并在另一些情况下，我们更加开放和灵活。”如果不从外部的角度来看，你会看不清楚在微软你所拥有的优势。

当你到了一个新的职位时，你想要踏出为未来规划的或者丰富你职业生涯的一步。Barbara Wilson，MSTE领导培训经理，提出了三个试金石，来判断你是不是在踏出正确的一步：

最后的这份工作。 如果你有一个以上的选择（待在原来地方可能是其中之一），这个试金石才会有效。假设，微软的工作是你最后的这份工作，在你正在考虑的几个选择中，哪些选择将会对你在几年之后想要做的有所帮助？

例如，如果你希望看到自己进入培训的角色，然后你可以在真正技术相关的和参与到培训他人的两个工作之间做一个选择的话，后者的职位可能是一个更合适的选择。

我会感到兴奋吗？ 问你自己四个问题：我对这个产品或服务会有激情？我能接触到客户吗？我对此职位或团队的问题处理解决感兴趣吗？这个团队的文化和管理理念是否适合我的风格？

合适吗？问问自己的职位，它能会为你提供些什么，然后再问问自己，你能为你的团队带来什么。如果这两个答案似乎是互补的(complimentary)，它可能是一个很好适合你的职位。

当你完成所有的自我评估和功课后，Brechner建议再做一个测验来判断此举是否正确：“带着你的勇气。”改变有时是非常困难的，即使你已预想过的相关情况。如果你觉得这一个改变，将教会你一些新东西，并且在改变时你感觉还行，那么很可能它就是一个很正确的改变。

结论

这是第一部分的结尾。除了这四条职业进阶之路，我们还有其他的道路。例如，我们可以成长为测试主管(Lead)，测试经理，PM和开发，甚至我们可以找到一个不是计算机领域的职业。作为软件测试员，你对系统有宽广视角，你考虑客户比考虑代码更多，你努力思考为什么我们要开发这个功能，我怎么能确保这个功能就是我们的客户所需要的。你从测试中学到这些技能，可以在你争取未来的职业时给与一些帮助。在接下来的一部分里，我将讨论，我们的软件测试员成长为更优秀的工程师的几个方面。

第二部分 - 我的一些建议

在这部分的文章中，我将专注于提供建议，以此帮助你的职业生涯发展。的确改变可能需要一段时间，有一天，你将成为一个资深员工。不断学习，不断思考和壮大自己的兴趣是你的职业成功的关键。我希望本文可以帮助你思考和开始积累你的力量。以我自己为例，我曾只专注于我的项目，只用很少的时间来思考。有一天，我无意中访问了www.infoq.com ，和听到了“被夸大的测试(Testing is Overrated)” 的会谈。阅读后，我把我的想法分享给我的同事们，并认识到，在我工作之外还有这么多出色的信息。我开始阅读这些文章，并借阅测试​​书籍。培养这样的学习和思考的习惯会花费时间，但一旦你有了这样的能力，你会发现，你可以成长得非常迅速。

激情和动力

有时，人们每天都做类似的事情就会觉得乏味。他们开始失去激情，感觉自己的职业生涯发展变得缓慢。我们应该如何处理这种情况？我可以给你一些建议。

• 考虑离开自己的舒适区域。

一旦你在一个地方里待了很长一段时间，你就有了一个舒适区域，它让你觉得你的工作失去挑战，你的技能不在提高。因此，是时候来改变了。你既可以换到其他公司也可以换到其他不熟悉项目。请大家认真考虑这个问题，因为这对你的职业生涯有重要影响。在未来的博文中，我将详细讨论改变或不改变。在一般情况下，我认为改变是应该的，你应该常常对此进行思考。我看到过很多例子，换到其他团队，并获取到更好的职业生涯。另外，还要考虑到换到其他团队，会给你提供机会，去学习新的、最终将有利于你的技能。

• 考虑做一些某些副项目(side project)。

我的第二个建议是，考虑做一些副项目。在过去的几年里，我发现，大家在他们的空闲时间里或主要任务责任外打造的项目往往比资助项目有更大的影响(the side projects which people build during their free time or out of main responsibility tend to have much larger impact that the funded project.)。作为一个专业的工程师，我们应该自我激励，自我组织。如果我所做的事情正是我的兴趣所在，我将会对它充满激情，并会为它做出持续努力。

• 拓展你的兴趣点。

我的第三个建议是，试试其他领域的兴趣。例如，当我觉得日常工作很枯燥时，我经常去公司内部微博，了解今天微软内部发生了些什么事。我喜欢阅读 www.infoq.com 的文章，了解公司外部又发生了些什么事。我喜欢阅读谷歌测试博客了解他们正在做些什么。你可以选择一个你特别有兴趣的领域，然后保持这个卓越的习惯，每天都学习些新东西。

最后，我有一些建议给我们的经理：宏观管理而不是微观管理；给大家一些做其他事情的自由；鼓励大家去尝试不同的机会。我知道我们的承诺，我们的任务必须要完成。然而，让大家愉快和受到激励比交付一个功能更为重要。一个快乐的团队能提供更好的产品，我们都不希望总是压力山大。

开放的思想和广泛的兴趣

一旦你在一个地方里待了很长一段时间，在你所在领域你获得了非常深厚的领域知识和测试方法。在这种情况下，我们往往是安于我们现在所做的，并有时还会避免改变。然而，作为一个专业的软件测试员，我们应该始终更宽更广地思考，思考有我们可以采用些什么新技术，思考你所在领域的未来测试技术。在一般情况下，一个优秀的软件测试员应该思考的比我们目前已有的东西更远，并有一些应对更改的计划。

为什么呢？究其原因是技术变化太快，如果我们不提前考虑，提前做好准备，有一天，当变化发生时，你会发现，你得仓促地面对这么多的挑战。例如，我总在浏览 www.infoq.com 和 www.dbms2.com ，以此提高我的技能。当我们的团队决定用列存储来实现数据仓库时，我已经知道我们为什么应该这样做的，这个领域中最热门的技术是什么。

为了培养这样的技能，我们需要的是开放和广泛。我们需要知道公司内部发生了什么事，社区里又发生了什么事。我们应该很开放地聆听和学习别人的想法。我强烈的主张，我们的资深测试员应与其他团队成员保持密切联系，尤其是微软里其他团队，并培养一种学习技术并能迅速吸收的能力。有一天，你会觉得学习的投入将为你的工作带来巨大的回报。

我可以给你一个例子，我如何做到这一点。就我而言，我订阅了微软内部和外部的大量非常活跃的博客，接收别人的更新。我也参加了会谈和培训，来提高自己。讲座范围可以非常广泛，如云计算中的系统工程方法(service engineering)，基于场景的工程方法(scenario focus engineer)，即以用户需求为导向的系统开发，等等。通过参加这样的培训，你将收获更广的技术知识。另外，你能知道公司内部发生了什么事。在过去的一年，我就参加了两个$99外训，然后我引入ATDD和个人看板(Personal Kanban)到我们的团队之中。SQL团队中许多成员所使用的技术和ATDD，其实早已被微软内部的很多团队使用过。你可以看到开放和广泛的价值，它能帮助你成长为一个资深测试员。

提升影响力(Making Big Impact)

今天，我想谈的另一个话题是作为一个资深测试员，需提升影响力。衡量一个人的成就的重要途径之一就是你对团队，对项目，对客户有多大的影响。我有三个方面提升影响力的建议。

• 帮助他人的成长

我们需要意识到，无论你是多么聪明，只靠你自己，你是不可能成功的。你帮助他人成长越多，你越可能会成功。作为一名资深测试员，我总是很喜欢看到初级测试员提高他们的技能，发展他们的职业，我也将提供建议和指导他们，帮助他们成长。就我的心里而言，我认为帮助别人是最重要的事情，我们应该每一天都帮助别人。有很多方法可以帮助他人成长，帮助他们做项目，回答论坛里问题，指导新成员，教他们如何编码和如何测试。对一个团队来说，建立这样的文化氛围是极其重要的，因为大家会感到其他人的温暖，并鼓励分享和学习。最后，我们一个团队一起都能成长起来。

• 影响他人

一旦你变得越来越资深，你已经掌握了非常深厚的技术知识，大量的项目经验。你得到别人更多的尊重，成为某一领域内的大牛(GOTO person)。换句话说，你有能力影响他人。如果我们看看，架构师，技术潮人(Techiques Follows)，大牛的工程师(Distinct Engineers)，他们的观点和思想能影响了很多人，类似这样的能力是他们独一无二的资产。

你认为我们能够像大牛一样影响其他人吗？我想是可以的。每个人都有一个你擅长的领域。你应该用你的专业知识来帮助人们作出决定，并提供宝贵的建议。例如，对于每一个我参与过的或我学习到的项目，我都对它有些独特的看法，我试图理解为什么我们应该开发这样的项目，我会更多思考为什么我们不使用另一种方式来构建它，我常常把我的想法分享给项目里的所有人然后我们一起再作出决定。我写了大量的博客，分享我的想法，并希望影响更多的人。

• 更多的跨团队协作

以我自己为例，在最近几年，我引入ATDD(验收测试驱动开发 - Acceptance Test-Driven Development)到我们的团队，并把它介绍给很多微软内部的其他团队，如Bing，Lync团队。我也参加不同类型的会议和研讨会，了解其他团队是在如何做测试。每当我看到有人做我所熟悉的项目，我也问他们是否需要帮助。

总之，当你努力提升你的影响力时，你的经验同样也会积累越来越多，你不断成长为一个资深测试员。

编码，编码，编码

今天，我想讨论一个最重要的技能，我们的软件测试员应该在自己的职业生涯中所掌握，这就是编码。

• 为什么编码这么重要？

因为你是软件测试员(SDET)，软件测试开发工程师(Software Development Engineer in Test)，你是软件工程师。作为一个软件工程师，编码就是每一天你应该做的任务，这是你应该掌握的技能。你可能会问是否编写测试用例没有编码更重要。这里的原因是，编写测试用例可以帮助提高产品的质量，但有时它并没有促进你的职业生涯发展。我可以举我的一个例子。当我刚参加到SQL Server团队之中，我们编写以T-SQL脚本为基础的测试，我很少有机会写编码。因此，我的编码技巧并没有提高。幸运的是，SQL Server的测试团队转移到以编程的方式编写测试，今天，我们的软件测试员的编码时间增加了不少。这是相当不错。当然，有时我们花费太多的时间在编写代码和类库上，而花费较少的时间来写真正的测试用例。这是另一个很大的话题，在这里我就不打算讨论了。

由于今天我们当中大部分人在编写自动化测试，这意味着我们有很大的机会来提高我们的编码技能吗？答案是不一定。今天我们的测试员做了太多的任务：我们编写测试库，我们验证测试结果，验收产品，我们配置机器和安装新版本进行测试，我们修正我们脆弱的测试，我们创建和关闭缺陷。有时我们花费大量的时间在下载和编译源代码。我们也有其他的任务，如会议，项目跟踪 / 缺陷报告。上述所有任务将需要花费我们每天中的大量时间，而时间提醒着我们，做实实在在编码真得很少，我们的技能提高也非常小。我记得有一天，我曾对我们的测试经理提到过我的梦想——我可以花50％的时间在编码上，他很惊讶，他认为这个数字理应还要大很多。然而，现实是这个数字理应小得多。

所以，我们该怎么处理这种情况呢？我们应该尽力尝试，改善我们的工程系统，以减少不必要的时间开销，让系统能够安装配置环境，安装测试版本，运行测试，创建 / 关闭的缺陷和退出测试。所有这些应该是自动化的。我们应给自己承诺每天尽可能多得编码。由于你的工作性质，如果你不能做到这一点，你应该考虑换到其他工作。

小结，请记住编码是一个重要的技能，你应该去提高它。

花时间去思考

在最近几天，我试图去理解，我们应该如何去教导和学生如何去学习。我的Ph.D研究经验和最近戴尔·卡耐基培训，为我提供一些想法：

• 教给他人或分享经验给他人最佳的办法是让他们思考。在你的谈话中不管他们思考了什么，他们至少学到些东西。一个好的实践是鼓励他们说话，与你互动。
• 思考自身有时可能并不够，我们可能需要实践和应用我们的思考到我们的工作中。

就研究论文而言，我们的论文大部分沿用了经典的格式，它必须有简介，相关的研究，实验结果和结论。没有实验结果的论文几乎是不可能被发布的。另一方面，论文的本质观点，似乎是不知为何地被隐藏起来或不是那么容易得找出来。我认为这是做研究里一个的问题。

当我们想要向人们做演示展现点东西时，或者我们想要写点东西教给别人时，同样也有上面的问题。首先，你会花很多时间在研究我应该思考些什么。之后，你头脑中就有些想法了，你会渴望通过写些东西与他人分享，这是一个很棒的方式来概括你的想法。

最后，我相信资深测试员的价值，是他可以给团队带来的观点 / 技能，而不是他在过去的工作经验。对我们的软件测试员来说，能够努力思考问题，并找出解决方案是一个重要的技能，我希望我们的资深员工应有的最最重要的技能就是思考 ，一个优秀的领导必须首先是一个出色的思考者。

了解产品

我相信作为一个资深软件测试员，我们应该充分了解我们正在测试的产品。知道产品的方向 / 未来是创建更好的测试的第一步。换句话说，如果我们不理解为什么我们应该构建这个产品和我们将构建怎样的产品，那么我们将不能编写出优秀的测试。

我们应该更多地参与项目 / 产品的规划，并影响产品的的策略（不仅是测试策略）。请注意，这是我们可以提高产品质量的重要途径之一。如果我们可以发现设计时的缺陷，我们可以节省下很多的时间和金钱，而且甚至比发现大量功能上的缺陷要有价值得多。有趣的是，我相信一个优秀的产品设计和一个正确的方向，会带来更少功能缺陷。过去我参与了大量的改进，我发现，如果是精心设计的功能，我们在实现功能的过程中将看到更少的产品问题 / 缺陷 / 后顾之忧。无论如何，如果该功能没有得到很好的设计，我们不应该去实现这个功能，否则你在执行的功能时会看到很多问题。

参与产品的设计，也可以帮助我们提高管理 / 构建项目的技能。并提高我们的技术技能，对测试架构师和领域专家的职业道路都是至关重要的。

了解产品，可以帮助团队成员讲同一种语言，更顺畅地交流。假设有一天，你想加入另一家公司做云计算，当你和你的面试官谈论时，他们可能会问你很多关于云计算的问题。如果我们只知道在服务中如何测试单个组件，你会发现你是缺乏知识 / 思考的，这将影响你未来的职业生涯。然而，如果你知道并思考过IASS，PASS，亚马逊AWS等云计算技术，我敢打赌，你将有更大的机会得到这个职位。对于一家初创公司来说，有一个除测试以外的技能是至关重要的。这始终是一条金科玉律。

最后，我想分享下Erwin Engelsma的观点：

“测试能够提高顾客的满意度，前提是你真的知道客户认为什么是真正重要的，并测试了相关的内容。在你的客户几乎不感兴趣的领域，做出很大的改进，虽然是一个值得称道的努力，但是这不会改变他们对产品好坏的看法！”

- 改进测试时的关键问题 —— Erwin Engelsma。

用不同的方式做事

有一天，我的经理问我：“Qingsong，当你还在高级测试员级别时，为什么你可以得到出众的评价结果​​”。在高级测试员的阶段，我还没有很丰富的测试知识，对团队的影响也不大。所以，我也想知道是什么让我有这么一个出色的评价结果，答案就是在用不同方式做事情。

这个问题的一种思考方式是，你如何把你与其他人区分开来。我发现当我被分配了一些任务时，我会额外地做一些我应该做的事情，这使我跟他人不一样，更主要的原因，我提升了影响力，也发展我的职业。这里有一些在过去我曾做过的事情的例子：

• 当我们计划在SQL Server中增加对日期和时间(Date and Time)的支持时，我花了很多时间来研究日期 / 时间和时区在Windows，Linux，.NET和Win32 API上的支持情况。我曾积极参与到项目的规划和设计中。这就让当我们测试功能时，我就有了一个更好的地位。另外，我在该功能的测试过程中承担了更多的责任，包括构建管理，测试运行管理，在线文档审查，并帮助他人编写测试用例。这些增加了我的知识，还帮我产生了更大的影响。
• 当我们在SQL Server 2008中实现了稀疏列(Sparse Column)功能之后，在功能提交后我并没有停止思考我们的功能。我曾积极地在内部寻找能够使用我们这个功能的地方。最后，我发现我们团队的VSTS系统可以使用这个功能，所以我和支持团队一起工作，把这个功能部署到系统中去。这样一来，我帮忙提高了团队的业务能力，同时也更好地了解到功能的用户场景。结果就是，我看到这个功能还缺少的一些更细功能。

最后，我希望你能体会用不同方式做事的意义。如果你有这样的能力，将会帮助你的职业生涯很多。

给测试经理的建议

今天，我希望写一篇关于招聘软件测试员的博文。主要读者是我们的招聘经理。这篇博文不是关于如何面试人或决定雇不雇用一个人，我认为这些是具体过程。而我的主要议题将关注为什么，即为什么我们需要聘请一个或多个测试员。

我不是一个测试经理，当需要更多的人时，我不知道我们的经理给人力资源那边说的原因是什么。也许先让我列一些可能的原因：

1）我们开始一个新的项目或功能，我们需要建立一个新的开发和测试团队。

2）我们有一个新的测试主管(test lead)，主管应至少管理5～8人。

3）我们在做项目时，测试资源短缺。

4）我们的副总裁给测试经理一些名额，如果我们不填上这些名额，就会被“浪费掉”。

我们真的缺乏测试资源吗？

我总是听人说他们的项目缺乏测试资源。但是，我们真的缺乏测试员？不一定，根本不是。微软内部没有测试资源缺乏的问题，而是资源分配问题。今天，我们的测试通常属于一个组件(component)团队，由一个测试主管带领。他深刻理解他的领域并且测试也做得相当不错，以便发展他的职业生涯。人们往往认为，每一个部门都需要一个单独的测试团队人们往往认为，测试是一个专业的工作，需要深入的了解测试。我们可以以另一个角度来看这个问题。今天，现代的测试框架，如NUnit，XUnit，MSTest和Selenium，编写自动化测试起来是非常容易，做测试并不是真的需要太多的测试知识，尤其是对于白盒测试来说（我相信由开发人员来写白盒测试并尽早地跑起来，那么白盒测试的效果将比黑盒测试大得多）。

我看到不少的情况是，我们的资深软件测试员对他们负责的组件有着丰富的领域知识，对于这样的组件，深刻理解是必要的。测试查询优化器(query optimizer)就是一个例子。不过，我认为最好的测试员应该把他的知识和测试理念应用到测试类库，让每个人都可以使用它，使得这样的组件测试变得更加容易。在SQL Server中，TestQP和QREL是很好的例子，这两个工具就内嵌了查询优化器和关系数据库的知识。你将你的知识转化为代码后，我觉得你能随意移植到其他团队，我们是没有必要去限制，因为他在这个领域中有着最丰富的知识。

扩大我们的团队并不意味着我们的业务扩大？

有时，一个团队从5人扩大到20人甚至更多时，人们感到自豪。然而，这并不意味着，我们的业务扩展了四倍。不应该用人数来衡量经理或团队成功与否。

你想增加新的测试员来提高团队的工作效率？

这可不一定。有时，它是成立的，我们的测试员在项目上非常繁忙，我们有一种感觉，添加一个或多个的测试员可以帮助我们，真的吗？如果原因是我们想招人，那完成这个项目之后又该怎么办？我们永久地保留他们。

下面是一些我给我们招聘经理的建议，如果他想雇用一个新的测试员时：

1）需要一个测试员时，尝试探索不同的方法来解决这个问题，并把雇用一个新的测试员作为最后的备选解决办法。

2）如果在项目上我们需要更多的测试员，我们可以从其他的团队调用些测试员吗？

3）如果我们有太多要做的事情，我们能标清优先级，并放弃部分低优先级的任务吗？

4）考虑培养一个技术主管，而不是培养一个人事管理主管。我们倾向于培养非常优秀的技术人员成为主管，让他管理更多的人。然而，今天我们的主管，在人事管理和其他的东西上花了太多的时间，他们只是没有时间思考，没有时间去提高他们的技术方面技能。所以，请考虑把我们的主管视为技术主管，这样一来，管理多少并不重要，重要的是能影响帮助到团队的人。

5）请务必花时间去改善我们的文化，我们的过程和方法。优秀工程是更高生产力的关键。减少我们的技术负债，投入时间去创新。

6）考虑采用一些指标来衡量测试员或测试的效率，因此，我们可以用更好的方式来作出决定。

测试新人的职业生涯怎么样？

这是一个很大的话题，这里我不会说得太多。一种看法是，我们都希望我们的员工能够快速成长，在未来有一个更好的职业。我们都希望我们的测试员可以很轻松地在其他公司找到测试工作，如果他们决定去追求公司以外的机会。然而，今天许多公司的开发人员与测试员比例相对偏低，并且他们相信他们的产品质量不算坏。我希望有人能在就业市场和测试员的水平上做一些研究，我们可以用更多的事实来分析这个问题。

结论

这是“成长为资深软件测试员”系列博文的结尾。我希望从我的博客中，你可以学到一些有用的信息，并帮助你决定​​你的职业道路。近年来，计算机技术的变化日新月异。云计算，社交网络，移动都是热点领域。技术的变更同样也需要不同类型的测试技术。我会开始写另一个系列博文——“对测试的未来和软件测试员的职业的未来”。在接下来的段落中，我将列出一些的最新文章，以此回答软件测试的未来是什么，服务领域测试(testing in the service area)的未来是什么，以及对软件测试员的职业生涯有何影响。

“测试的未来”的相关参考文章：

• 在谷歌2011年的测试自动化会议上，谷歌工程和创新倡导者的主管(Director of Engineering and Innovation Agitator at Google)——Alberto Savoia负责开幕式主题演讲。他认为，我们曾熟知的软件测试已死 - 或至少是垂死的。我与几位同事看了这个视频两遍，大家都觉得这是很警醒的谈话，让我们更严肃地深思测试和事业。我强烈推荐每个测试相关的人去看看这个视频。主题中提到，初创公司对“我们正在做正确的事情吗？”比“我们正在正确地做事吗？”更感兴趣。也就是说，这里的质量真的不是我的软件或者服务是否有缺陷，而是我的想法是不是吸引顾客的最佳想法。这对我们的软件测试员有一定的影响，因为我们太专注于
  “我们正在正确地做事吗？”，并可能导致我们很难在初创公司找到工作。
• “众包”是最近非常热门的话题。你能想象一家拥有数以十万计的软件测试员的公司吗，它可以帮助其他公司在极短的时间内完成测试。这些兼职软件测试员的薪水和他们找到的缺陷挂钩。他们在不同的地方用不同的语言在不同的设备上运行测试。不同于我们的内部测试，他们像真正的客户般的运行测试。 uTes​​t.com就是这么一个公司，该公司在这个领域相当抢眼，它将会对测试服务和测试移动应用的方式上有着极大影响。在内部，我们有几个团队，包括Bing，Lync，都在积极利用众包来测试他们的功能。对我们的测试员意味着是什么？仍是未知数。
• 由James Whittaker ， Jason Arbon和Jeff Carollo编写的“ 谷歌怎样进行软件测试 ”，很详细地回答封面的上问题。能在迷雾下看到像谷歌这么一个大型技术公司如何处理软件测试的复杂性，是很具知识性和趣味性。一个有趣的现象是，在此书的出版之前，三位作者都离开谷歌，一位回到微软担任开发主管，和另外两个则加入了uTest.com。下面是 一次访谈 的片断：

InfoQ：在本书中，你提出了，“不要雇用太多的测试员”，并且在未来里测试工程师的作用在下降。你对此有何回应，公司认为需要更多的角色，以此划分开发人员和质量保证之间的界线？

为什么你要这样的界线吗？谷歌已经证明编写代码和保证代码优秀的界线是模糊的，其结果就是代码被开发更快，并且潜在缺陷更少。雇用太多的测试员是为开发人员创建了一个依靠，对产品来说这就是有害的。当人们过于纠结自己的角色，会使我懊恼。“我是一个测试员”是一种不健康的心态。“我是一名开发人员”同样也是不健康的心态。当人们停止过多关注自己的角色，开始专注于他们的产品，这才是奇迹发生之时。这时候，每个人都专注于尽一切力量来打造他们能打造的最好的产品。

InfoQ：对当前那些考虑加入测试相关角色的测试分析师(test analysts)或新毕业生，你能提供最好的建议是什么？可以满足这个角色不断变化的技能。

对待测试如同开发一般。获取一个CS学位，并擅长CS。证书和行业培训只会教你简单的东西。学习难的东西，并掌握它。软件测试员只做简单的事情，在很长的时间里仍然会被视为二等公民。不想被这样对待吧？那就获取一等的技能。

• Bing团队的融合工程(Combined Engineering)设想，对服务测试和软件测试员的职业生涯都是非常有趣的。在融合工程，软件开发工程师（SDE）们和软件测试开发工程师（SDET）们合并为一个“工程师”的角色，我们为交付服务而优化，而不是为软件而优化。换句话说，许多测试成为开发者，真正的开发人员只写代码，而不是测试。我认为这可能是服务团队的未来发展方向，今天的测试员可以更专注于监测，基础设施和工具，他们和开发人员是一样的。
• 我们的生产环境测试(Testing in Production)专家——Seth Eliot，认为TestOps是我们的测试的未来发展道路之一。你可以到这个链接看看相关信息。我认为生产环境测试能真正改变我们如何做测试以及测试员的职业的未来。这是TestOps访谈的一个小段：

我认为测试领域的一个重要的变化将是我已经谈到过围绕测试服务和生产环境测试。我把它称为TestOps。

测试员需要摆脱定式思维观念，编写测试 - 运行测试 - 评估结果。我们要使用大量数据（一般是指服务）作为产品的质量信号，而不是用日常运行的测试结果作为质量信号。这包括系统数据，如CPU，API请求，系统响应时间，以及（妥善匿名处理的）用户数据。此外，还包括在生产环境中持续运行时交易发出的数据。这些依然是测试用例，你可以得到持续的可用性和性能状况，而不是只获得每天的失败 / 通过的状态。这是一种技术，但它也必定会改变我们的软件工程。角色的分类与归类(role and specialization versus generalization)的问题，答案是应满足每个团队的具体需要。数据科学家做为工程团队的一部分，就是TestOps方法的一个令人兴奋的结果。

其他与我们的职业生涯的相关文章：

• 谷歌怎样进行软件测试 系列
• 软件测试对比：亚马逊和微软
• 编码QA播客：再次回到开发人员和测试员角色
• 编码QA播客：新的所有者和类似开发的测试
• 编码QA播客：团队结构
• 博文：测试得不到尊重

在成功运行Wireshark之后，我们就可以进入下一步，更进一步了解这个强大的工具。

下面是一张地址为192.168.1.2的计算机正在访问“openmaniak.com”网站时的截图。

1. MENUS（菜单）

3. DISPLAY FILTER（显示过滤器）

4. PACKET LIST PANE（封包列表）

7. MISCELLANOUS（杂项）

正如您在Wireshark教程第一部分看到的一样，安装、运行Wireshark并开始分析网络是非常简单的。

使用Wireshark时最常见的问题，是当您使用默认设置时，会得到大量冗余信息，以至于很难找到自己需要的部分。
过犹不及。

这就是为什么过滤器会如此重要。它们可以帮助我们在庞杂的结果中迅速找到我们需要的信息。

1. 捕捉过滤器 2. 显示过滤器

1. 捕捉过滤器

捕捉过滤器的语法与其它使用Lipcap（Linux）或者Winpcap（Windows）库开发的软件一样，比如著名的TCPdump。捕捉过滤器必须在开始捕捉前设置完毕，这一点跟显示过滤器是不同的。

设置捕捉过滤器的步骤是：
- 选择 capture -> options。
- 填写"capture filter"栏或者点击"capture filter"按钮为您的过滤器起一个名字并保存，以便在今后的捕捉中继续使用这个过滤器。
- 点击开始（Start）进行捕捉。

例子：

注意事项：

当使用关键字作为值时，需使用反斜杠“\”。
"ether proto \ip" (与关键字"ip"相同).
这样写将会以IP协议作为目标。

"ip proto \icmp" (与关键字"icmp"相同).
这样写将会以ping工具常用的icmp作为目标。

可以在"ip"或"ether"后面使用"multicast"及"broadcast"关键字。
当您想排除广播请求时，"no broadcast"就会非常有用。

查看 TCPdump的主页以获得更详细的捕捉过滤器语法说明。
在Wiki Wireshark website上可以找到更多捕捉过滤器的例子。

2. 显示过滤器：

通常经过捕捉过滤器过滤后的数据还是很复杂。此时您可以使用显示过滤器进行更加细致的查找。
它的功能比捕捉过滤器更为强大，而且在您想修改过滤器条件时，并不需要重新捕捉一次。

例子：

	表达式正确
	表达式错误

　　实际工作中遇到的事情不是每一件事都能够在很短的时间内完成的,对于那些需要时间的事情我们就要分配适当的时间处理,时间分配的不均匀就会出现有些事情消耗的时间长一些,有些事情消耗的短一些,但我们自己清楚.LR 同样也为我们提供了这样的功能,使我们可以了解大部分的事务响应时间是多少?以确定这个系统我们还要付出多少的代价来提高它.

　　Transaction Response Time(Distribution)-事务响应时间(分布)

　　显示在方案中执行事务所用时间的分布.如果定义了可以接受的最小和最大事务性能时间,可以通过此图确定服务器性能是否在可接受范围内.

　　很明显大多数事务的响应时间在60-140S.在我测试过的项目中多数客户所能接受的最大响应时间也要在20S 左右.140S 的时间!很少有人会去花这么多的时间去等待页面的出现吧!

　　通过观察以上的数据表.我们不难看到此系统在这种环境下并不理想.世间事有果就有因,那么是什么原因导致得系统性能这样差呢?让我们一步一步的分析.

　　系统性能不好的原因多方面,我们先从应用程序看.有的时候我不得不承认LR 的功能真的很强大,这也是我喜欢它的原因.先看一张页面细分图.

　　一个应用程序是由很多个组件组成的,整个系统性能不好那我们就把它彻底的剖析一下.图片中显示了整个测试过程中涉及到的所有web 页.web page breakdown中显示的是每个页面的下载时间.点选左下角web page breakdown 展开,可以看到每个页中包括的css 样式表,js 脚本,jsp 页面等所有的属性.

　　在select page to breakdown 中选择页面.

　　见图.

　　在 Select Page To Breakdown 中选择http://192.168.0.135:8888/usertasks 后,在下方看到属于它的两个组件,第一行中Connection 和First Buffer 占据了整个的时间,那么它的消耗时间点就在这里,我们解决问题就要从这里下手.

　　也有可能你的程序中client 的时间最长.或者其他的,这些就要根据你自己的测试结果来分析了.下面我们来看一下CPU,内存.硬盘的瓶颈分析方法:

　　首先我们要监视CPU,内存.硬盘的资源情况.得到以下的参数提供分析的依据.
       %processor time(processor_total):器消耗的处理器时间数量.如果服务器专用于sql server 可接受的最大上限是80% -85 %.也就是常见的CPU 使用率.

　　%User time(processor_total)::表示耗费CPU的数据库操作，如排序，执行aggregate functions等。如果该值很高，可考虑增加索引，尽量使用简单的表联接，水平分割大表格等方法来降低该值。

　　%DPC time(processor_total)::越低越好。在多处理器系统中，如果这个值大于50%并且Processor:% Processor Time非常高，加入一个网卡可能会提高性能，提供的网络已经不饱和。

　　%Disk time(physicaldisk_total):指所选磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比。如果三个计数器都比较大，那么硬盘不是瓶颈。如果只有%Disk Time比较大，另外两个都比较适中，硬盘可能会是瓶颈。在记录该计数器之前，请在Windows 2000 的命令行窗口中运行diskperf -yD。若数值持续超过80%，则可能是内存泄漏。

　　Availiable bytes(memory):用物理内存数. 如果Available Mbytes的值很小(4 MB 或更小)，则说明计算机上总的内存可能不足，或某程序没有释放内存。

　　Context switch/sec(system): (实例化inetinfo 和dllhost 进程) 如果你决定要增加线程字节池的大小，你应该监视这三个计数器(包括上面的一个)。增加线程数可能会增加上下文切换次数，这样性能不会上升反而会下降。如果十个实例的上下文切换值非常高，就应该减小线程字节池的大小。

　　%Disk reads/sec(physicaldisk_total):每秒读硬盘字节数.

　　%Disk write/sec(physicaldisk_total):每秒写硬盘字节数.

　　Page faults/sec:进程产生的页故障与系统产生的相比较，以判断这个进程对系统页故障产生的影响。

　　Pages per second:每秒钟检索的页数。该数字应少于每秒一页Working set:理线程最近使用的内存页，反映了每一个进程使用的内存页的数量。如果服务器有足够的空闲内存，页就会被留在工作集中，当自由内存少于一个特定的阈值时，页就会被清除出工作集。

　　Avg.disk queue length:读取和写入请求(为所选磁盘在实例间隔中列队的)的平均数。该值应不超过磁盘数的1.5~2 倍。要提高性能，可增加磁盘。注意：一个Raid Disk实际有多个磁盘。

　　Average disk read/write queue length: 指读取(写入)请求(列队)的平均数Disk reads/(writes)/s:理磁盘上每秒钟磁盘读、写的次数。两者相加，应小于磁盘设备最大容量。

　　Average disk sec/read:以秒计算的在此盘上读取数据的所需平均时间。Average disk sec/transfer:指以秒计算的在此盘上写入数据的所需平均时间。

　　Bytes total/sec:为发送和接收字节的速率，包括帧字符在内。判断网络连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽比较Page read/sec:每秒发出的物理数据库页读取数。这一统计信息显示的是在所有数据库间的物理页读取总数。由于物理 I/O 的开销大，可以通过使用更大的数据高速缓存、智能索引、更高效的查询或者改变数据库设计等方法，使开销减到最小。

　　Page write/sec:(写的页/秒)每秒执行的物理数据库写的页数。

　　如果系统由于应用程序代码效率低下或者系统结构设计有缺陷而导致大量的上下文切换(context switches/sec显示的上下文切换次数太高)那么就会占用大量的系统资源,如果系统的吞吐量降低并且CPU的使用率很高,并且此现象发生时切换水平在15000以上,那么意味着上下文切换次数过高.

　　从图的整体看.context switches/sec变化不大,throughout曲线的斜率较高,并且此时的contextswitches/sec已经超过了15000.程序还是需要进一步优化.

　　2. 判断CPU瓶颈

　　如果processor queue length显示的队列长度保持不变(>=2)个并且处理器的利用率%Processortime超过90%,那么很可能存在处理器瓶颈.如果发现processor queue length显示的队列长度超过2,而处理器的利用率却一直很低,或许更应该去解决处理器阻塞问题,这里处理器一般不是瓶颈.

　　%processor time平均值大于95,processor queue length大于2.可以确定CPU瓶颈.此时的CPU已经不能满足程序需要.急需扩展.

　　3. 判断内存泄露问题

　　内存问题主要检查应用程序是否存在内存泄漏,如果发生了内存泄漏,process\private bytes计数器和process\working set 计数器的值往往会升高,同时avaiable bytes的值会降低.内存泄漏应该通过一个长时间的,用来研究分析所有内存都耗尽时,应用程序反应情况的测试来检验.

　　图中可以看到该程序并不存在内存泄露的问题.内存泄露问题经常出现在服务长时间运转的时候,由于部分程序对内存没有释放,而将内存慢慢耗尽.也是提醒大家对系统稳定性测试的关注.

　　附件:

　　CPU信息：

　　Processor\ % Processor Time 获得处理器使用情况。

　　也可以选择监视 Processor\ % User Time 和 % Privileged Time 以获得详细信息。

　　Server Work Queues\ Queue Length 计数器会显示出处理器瓶颈。队列长度持续大于 4 则表示可能出现处理器拥塞。

　　System\ Processor Queue Length 用于瓶颈检测通过使用 Process\ % Processor Time 和 Process\ Working Set

　　Process\ % Processor Time过程的所有线程在每个处理器上的处理器时间总和。

　　硬盘信息：

　　Physical Disk\ % Disk Time

　　Physical Disk\ Avg.Disk Queue Length

　　例如，包括 Page Reads/sec 和 % Disk Time 及 Avg.Disk Queue Length。如果页面读取操作速率很低，同时 % Disk Time 和 Avg.Disk Queue Length的值很高，则可能有磁盘瓶径。但是，如果队列长度增加的同时页面读取速率并未降低，则内存不足。

　　Physical Disk\ % Disk Time

　　Physical Disk\ Avg.Disk Queue Length

　　例如，包括 Page Reads/sec 和 % Disk Time 及 Avg.Disk Queue Length。如果页面读取操作速率很低，同时 % Disk Time 和 Avg.Disk Queue Length的值很高，则可能有磁盘瓶径。但是，如果队列长度增加的同时页面读取速率并未降低，则内存不足。

　　请观察 Processor\ Interrupts/sec 计数器的值，该计数器测量来自输入/输出 (I/O) 设备的服务请求的速度。如果此计数器的值明显增加，而系统活动没有相应增加，则表明存在硬件问题。

　　Physical Disk\ Disk Reads/sec and Disk Writes/sec

　　Physical Disk\ Current Disk Queue Length

　　Physical Disk\ % Disk Time

　　LogicalDisk\ % Free Space

　　测试磁盘性能时，将性能数据记录到另一个磁盘或计算机，以便这些数据不会干扰您正在测试的磁盘。

　　可能需要观察的附加计数器包括 Physical Disk\ Avg.Disk sec/Transfer 、Avg.DiskBytes/Transfer，和Disk Bytes/sec。

　　Avg.Disk sec/Transfer 计数器反映磁盘完成请求所用的时间。较高的值表明磁盘控制器由于失败而不断重试该磁盘。这些故障会增加平均磁盘传送时间。对于大多数磁盘，较高的磁盘平均传送时间是大于 0.3 秒。

　　也可以查看 Avg.Disk Bytes/Transfer 的值。值大于 20 KB 表示该磁盘驱动器通常运行良好;如果应用程序正在访问磁盘，则会产生较低的值。例如，随机访问磁盘的应用程序会增加平均 Disk sec/Transfer 时间，因为随机传送需要增加搜索时间。

　　Disk Bytes/sec 提供磁盘系统的吞吐率。

　　决定工作负载的平衡要平衡网络服务器上的负载，需要了解服务器磁盘驱动器的繁忙程度。使用 Physical Disk\ %Disk Time 计数器，该计数器显示驱动器活动时间的百分比。如果 % Disk Time 较高(超过90%)，请检查 Physical Disk\ Current Disk Queue Length 计数器以查看正在等待磁盘访问的系统请求数量。等待 I/O 请求的数量应当保持在不大于组成物理磁盘的主轴数的 1.5 到2倍。

　　尽管廉价磁盘冗余阵列 (RAID) 设备通常有多个主轴，大多数磁盘有一个主轴。硬件 RAID设备在“系统监视器”中显示为一个物理磁盘;通过软件创建的 RAID 设备显示为多个驱动器(实例)。可以监视每个物理驱动器(而不是 RAID)的 Physical Disk 计数器，也可以使用 _Total 实例来监视所有计算机驱动器的数据。

　　使用 Current Disk Queue Length 和 % Disk Time 计数器来检测磁盘子系统的瓶颈。如果Current Disk Queue Length 和 % Disk Time 的值始终较高，可以考虑升级磁盘驱动器或将某些文件移动到其他磁盘或服务器。