2018年11月13日

1.代码颜色调整，根据自己的喜好选择对应的颜色，设置如下：

2018年11月8日开始搭建测试环境（Python+jdk+eclipse+PyDev)；

2018.10.19解决PC端安装fiddler证书不成功的问题，通过下面链接解决；

其实这篇博文是写出来想给大家分享一下测试工程师的职业发展的，显然是老话题了，因此我假设本文的目标读者为：
1. 想进入软件测试领域，还不太清楚实际的软件测试长什么样的童鞋。
2. 刚上走上测试这条路不久，接触过一些实际项目了，但还没“拧”上道的童鞋。
3. 做了一段时间测试，也明白了软件测试是怎么回事，想继续从事测试行业，但是对前途感觉很茫然的童鞋。
4. 做了一段时间测试，感觉测试不是自己所想要的职业，仍然想在IT行业发展，但想转行的童鞋。
如果您不属于这其中的某一类人，或许这篇小文并不适合您，请不要浪费你的时间了，谢谢。

职业发展是个老生常谈的问题，但一直都是一个很火的话题。随便翻翻，各个关于软件测试的坛子里，都不乏探讨软件测试工程师职业发展的帖子，为什么我还要多写这么一篇呢？好吧，先来说说这篇博文的缘起：在我将近八年的职业软件测试生涯中，遇到过不少刚刚进入测试领域的新人，也有不少做过三四年或者五六年的“老鸟”，不管做得好的还是不好的，我觉得都可以用两个字来形容大多数人的状态：“忙”与“茫”。前一个忙可能适合于大部分刚踏入测试领域的新人，他们兴趣勃勃，对一切新鲜事物都充满着好奇，总想学习更多的技术，参与更多的测试，好早点积累起属于自己的测试经验。后一个“茫”，可能更适合做了几年测试的所谓“老鸟”，他们经历了一些项目，也积累了不少的经验，不管是否领悟了测试的“真谛”，他们中的大部分人都已经习惯了目前的工作状态，成了熟练工种。或许在纠结着究竟以后的路该怎么走，究竟是学技术还是做管理？学技术的话，什么样的技术学了才会让自己在这个领域更具竞争力？做管理的话，自己具备做管理的特质吗？又或许自己根本不适合做测试？甚至于不适合做IT？可转行的话，隐藏着巨大的机会成本，风险确实很大，用什么样的职业来转行才更靠谱呢？“菜鸟”也终究有成为“老鸟“的那一天，所以这些问题是我们每个人都会遇到的，有句话说得非常好：二十岁的迷茫将导致三十岁的恐慌，而接下来面对的是四十岁的无奈。不管你现在多少岁，如果你现在还没有定下自己的目标，可能看到这句话都会有这样的感觉，迷茫、恐慌和无奈，每个词都不是什么褒义词，没人想把它们放在自己的身上。正因为有这样一些问题，这么多的无奈，才有了这篇文章。我想通过这篇文章，和大家分享一下我这么多年工作之中对测试职业生涯发展的思考，更重要的是，我同时还会给大家提供一些以后不做测试之后该如何华丽”转行“的意见供大家参考，”三十六“变究竟应该怎么变，我想这也是我这篇文章的价值所在。

本文准备分两大部分来讲不同方向的职业生涯发展之路。第一部分当然就留给那些想继续留在测试行业发展的童鞋们，讲讲如果你想在测试行业继续奋斗下去的话，为了你的“钱途”，你应该往哪方面发展。第二部分应该算是其他文章讲得较少的内容，那就是如果你干了一段时间觉得你不愿意再从事测试行业，想从一些相关的职业转行离开测试领域，那么请着重看这部分。

一、测试行业的职业发展之路
其实这部分是几乎所有关于测试的职业发展文章都会探讨的部分，相信各位看官都已经耳熟能详了。不过为了照顾本文的完整性，也便于大家比较，我也将我的经验和观点分享给大家，以作参考。如果有童鞋有更好的观点，欢迎分享和探讨。

1. 技术方向
就技术方向的职业发展之路，我非常赞同之前看过的测试大牛sincky的一篇文章里说的，如果你打定主意就想往测试技术方向去发展，做一个技术型的牛人，那摆在你面前的就只有三条路：1. 自动化测试工程/架构师 2. 性能测试工程师 3. 行业性测试专家。你几乎没有其他选择，甭管你的领导怎么忽悠你，做手动测试大量需要劳动力也好，自动化测试现在还没有大规模发展起来也罢，如果你只会手动测试，并且你所测试的软件也没有什么特别值得深究的方面的话，那么可以告诉你你的测试生涯钱途堪忧，说白了也就是没有什么核心竞争力，哪天boss们想砍人了，那你就是第一个。有些童鞋可能会说了，这个不对吧，看咱项目里不是还是80%以上的人都是做手动的嘛，为什么你却说自动化/性能测试才更具有核心竞争力呢？先说自动化吧，确实，就目前中国测试业的现状来看，80%以上的IT公司里面80%以上的测试人员都在做着黑盒的手工测试，这个假象确实麻痹了一些人，使得大家以为既然大部分人都在做着手工测试，那我也不需要去学习自动化或者性能测试了。就算很多已经实施了自动化测试的公司，也在痛苦地摸索着如何提高自动化测试的效率，如何能够真正提高系统的性能。但不管现状如何，很多公司也必须重视自动化测试，原因有二：1. 商业上的需要。很多公司，特别是测试外包公司，销售们在推销自己公司的团队和产品的时候，测试的自动化程度都是一个重要的指标，这年头说测试不说自动化都显得自己“out”了，所以自动化测试能不香吗？2. 项目需要。很多管理职位的人，如果不是做测试技术出身，都会非常迷信自动化测试的神力，把自动化测试当成测试的银弹，战无不用，用无不胜，所以相对来说，会比较重视自动化测试的人。对于性能测试和行业测试专家来说，那就是物以稀为贵了。真正能做好性能测试，并能够通过性能测试结果分析出性能瓶颈，提出性能改进方案的人，寥寥无几。行业测试专家也一样，比如电信、医疗、ERP测试，能够精通业务，真正能够利用对业务的了解改进测试效率，也是数都能数出来的，你说他们的钱途用得着担心吗？呵呵。

好了，接下来再来说说这三个职位各需要什么样的具体技能吧（可能不是很全，欢迎各位看官补充）。

1.1 自动化测试工程师/架构师

基本能力要求：
--熟悉自动化测试的理论及常用框架
--熟练使用常见的自动化测试工具并能够根据项目实际需要选择合适的工具或者开发相应的工具
--熟悉项目软件架构及层次结构，能够利用自动化测试工具或自定义的框架提高自动化测试的覆盖率和复用率
--熟悉脚本类及一到两种常用的编译型编程语言，网络协议及linux平台

1.2 性能测试工程师

基本能力要求：
--熟悉性能测试过程模型和过程
--熟悉各种常见的应用协议
--熟悉性能测试工具的原理及使用
--能够根据实际项目配置测试环境，选择合适的性能测试工具或开发性能测试工具
--能够通过对被测系统的分析，对性能测试场景进行分析和选取
--执行性能测试并根据结果分析性能瓶颈，提出性能提升改进的建议

1.3 行业测试专家

基本能力要求：
--精通某个业务性较强的行业的业务流程及关键技能，如医疗，通信，ERP等特征较明显的行业。（如果你是测一般的网站或者是手机系统之类的话，还是省省吧，这个不是这里指的行业专家）
--能够根据对本行业业务的了解和对软件测试的了解，对组织内的软件测试流程和方法做出优化，提高测试效率，节省测试成本

2. 管理方向
谈完了技术，当然就该谈谈被无数人所追崇的管理职位了。当然了，能管别人，发号施令，谁不喜欢呢？古人云：学而优则仕，就是这个道理。可职业发展这个金字塔上，能最终站上管理职位的那个塔尖的人又有多少呢？管理职位虽然看似很爽，很诱人，但绝不是每个人都适合做这个岗位的。也不是说你做了若干年的技术，成了技术大牛，你就一定能去管项目管人，毕竟管理主要是跟人打交道的活，你虽然能把电
脑弄得服服帖帖，但不一定你去管人的时候，人就会服你，所以其实谈到做管理，最关键的就不是技术了，用两个比较时髦的词来说，关键就是“沟通”和“协调”，你得会跟客户去做沟通，你得会跟其他人去做协调，这是做管理的先决条件。如果你觉得自己不善言谈，不想时时面对众人，那兄弟你还是跳过这一节，继续看看其他部分吧。

那么就从做管理来说又可以有什么样的职位选择呢？撇开高层管理什么CXO的不谈，就一般的管理而言，可以选择的管理职位有两类：

2.1 项目经理

基本能力要求：
--较高的沟通和协调能力。一方面你要能把客户哄好了，另一方面你得牢牢取得团队的支持，你要没点沟通能力和协调能力，能行吗？
--熟悉项目管理的相关知识，如果能够取得PMP证书(项目管理师认证)是最好的，因为那至少可以证明你从理论上非常专业地学习了项目管理的基本概念，熟悉了项目管理的五大过程组及九大知识领域(详细内容请参考相关PMP书籍)，有一定的项目管理经验，理论上是没问题的了。
--技术方面呢，不需要你太精通技术，但作为IT行业的项目经理，我一直都认为没有任何的技术背景其实是很难胜任这个行业的管理职位的，因为技术性确实太强，人家谈论实现的时候，你啥都听不懂，是不是挺尴尬的？关键是你还得做出决策。如果打个比喻来说明究竟项目经理需要掌握技术到什么程度的话，可以用两个词：一平方公里和一米。你的知识面必须得有一平方公里宽，但这些知识的深度只有一米。什么都知道一点，什么都不精，或许对做技术的人来说不是什么好事，但如果你是做管理的，那恭喜你，兄弟，继续干吧。

2.2 测试经理

基本能力要求：
--参照项目经理的第一条，必须滴~~
--你不需要有特别多项目管理理论基础及经验，但你必须精通软件测试的方方面面，从流程、方法、工具、框架、组织等等，你都必须了解，并最好有实际的项目经验，能够随时指导测试团队的工作，对团队里面的问题提出一定的参考意见和解决方案，对团队的测试流程和方法做出改进。

二、从测试行业转行的选择
好了，看了上面的那些测试行业本身的职业发展选择，有的童鞋可能会感觉不蛋定了，压力山大了，哎呀，本人天生就是编程白痴，书看了不少，什么语言之类的人家说起来或者看着书上感觉都会，可自己一坐到电脑面前打开IDE就茫然，思路全无，硬是敲不进一行代码，我怎么可能做自动化？我怎么发展？我从事的测试就是测测手机上的游戏，我怎么做行业测试专家？说沟通和协调吧，我自己都是宅男宅女，选择性话痨，最烦跟不熟的人(客户)多说一句话，我怎么沟通？怎么做管理？得，如果您是属于这类人，其实说实话，软件测试这个职位可能并不是您的菜，您可能还需要重新考虑一下更适合你的职位。当然我们都知道，转行的机会成本是相当高的，本来做了三五年软件测试，突然让你去做医生或者建筑师，那估计谁心里都没底，除非您就是一天才。综合比较来看，比较保险的办法应该是继续从事IT行业，但不做软件测试，转到比较相关的行业，再看看自己是否适合，这样做的机会成本会低很多，风险相对较小。那么什么样的职业选择是和软件测试相关的呢？它们又应该具备什么样的技术技能呢？接下来本人会为大家一一道来。当然，这些意见都是根据我自己的一些浅薄的经验，无奈当初楼主在一些小公司被劈成几半用的时候，除了测试外，几乎软件工程里面该有的一些主要职位都做过了，如需求分析，开发，售前，售后等等，所以才会有这些结论出来，下面的内容关于能力方面的要求是最基本的，欢迎大家补充，个人见识有限，这里权当抛砖引玉了，呵呵。

1. SQA
说到SQA，其实很多公司现在都已经跟软件测试是一个概念了，测试人员既做QA又做QC的情况非常普遍，只有一些规模较大，流程确实非常正规的公司还保留有专门的SQA的职位，这里只是权当做个参考和选择之一。或许有不少童鞋会对QA和QC的区别心存疑惑，甚至有不少人根本不知道这是两个不同的职业，那么他们有什么区别呢？我这里随便解释下。如果用一个比喻来形容QA和QC的关系的话，我觉得用法官和警察的关系来形容是比较贴切的。法院的法官制定法律，但他们不亲自去抓罪犯，而警察呢，则依据法院制定的法律去判断某人是否违法，是否是应该被抓捕的罪犯，并亲自去把他们抓住。QA就如同法官，他们制定了一系列的流程，工作的输入输出，哪些文档，如何审计测试的效率，如果改进测试流程，都是他们在掌握。而QC，就是测试人员，他们则在QA的流程下，运用各种测试的方法去抓bug，尽量减少产品的缺陷，保证产品的质量。所以SQA的工作比较适合不太喜欢亲自去找bug，但喜欢从比较high level的角度去看待问题的人，说白了就是动手能力不太强，但确实对测试还比较感兴趣，对各种质量理论感兴趣的人。

基本能力要求：
--熟悉常见的质量控制体系及软件项目成熟度模型等，如CMM/CMMI，6 sigma，ISO9000，RUP等等

2. 售前工程师
为什么说测试工程师同样也适合转售前呢？因为测试工程师其实是最了解产品需求和产品功能的那个人，甚至他比模块化的开发人员还了解公司的系统或者产品。在清楚系统的功能的前提下，很容易就能够针对各种客户的需求提出相应的解决方案，再加上如果您有较好的文字功底或者是沟通技巧，那其实售前工程师是一个相当好的转行的方向。当然，这个职位也特别适合那些想做销售但又上了测试这条船的童鞋，这可是一个很好的跳板啊，呵呵。

基本能力要求：
--熟悉产品的使用及实施，能够根据客户的需求提出相应的解决方案
--较好的沟通和表达能力
--较强的文字功底和报告功底

3. 用户体验师
用户体验师或许还不是一个很火的职业，但根据当前和以后的软件业的趋势，火是必然的了。因为用户使用产品，除了功能外，越来越重视的是用户体验，功能谁都有，那当然是谁的好用就用谁的了，比如最近热得烫手的苹果产品就是最好的例子。当然用户注重用户体验了，那当然各大软件公司就必须得重视了，自然用户体验师就应运而生。其实很多大公司早已有专门的用户体验师的职位，比如苹果，乔布斯就可以说是苹果的首席用户体验师，同样国内的如百度，腾讯等大公司也都有，而且腾讯的马总也是首席体验师，任何新产品他都会亲自使用并提出改进意见，由此重要性可见一斑。那么如何又扯到跟测试这个职业相关了呢？大家想想，平时我们在做诸如易用性测试，界面UI测试等等，遇到用户体验不好的，或者给用户操作带来阻碍的东东是不是也应该算是bug呢？所以我们也可以说是对用户体验有足够的了解了，只是对用户体验师这个职位来说，还不是很专业罢了。那么要成为专业的用户体验师，我们又应该具备什么样的能力呢？

基本能力要求：
--具备较丰富的UI设计经验和较强的设计能力，并且对用户体验较为敏感。
--具备人机交互工程学，人体力学等专业知识，并且具备一定的用户体验测试经验。

4. 需求分析工程师
其实做过测试的童鞋都应该知道，在项目里面，除了客户之外，可能就是测试团队对项目需求是最了解的了。大家可以说天天都在和需求打着交道，因为需求就是我们做一些测试的依据。随着很多公司开始应用敏捷模式来进行软件开始，可能传统意义上的需求分析工程师的数量正在减少，取而代之的是测试人员在团队中担当了需求分析和功能建模的角色。但不要担心，还是有很多公司对需求分析有专门的需求的，当然，你如果是有需求分析师证书的话，那就更好了。

基本能力要求：
--了解软件项目需求分析过程，具备需求建模能力及系统用例分析及设计能力，能够使用uml建模语言建模。
--较强的沟通，交流及理解能力，要善于引导客户说出真正的需求或者理解客户真正的需求。

5. 开发工程师
这个就不说了，这个职位适合于对编码确实感兴趣的童鞋，可以考虑从测试转开发，尽管现实中一般都是开发转测试，你懂的，呵呵。

基本能力要求：
--代码编写能力较强，愿意做一个码农或者苦逼的程序猿

6. 售后及技术支持
相信每一个测试工程师测完被测系统后，你都敢拍着胸脯说，OK，我现在对这个系统的功能是最熟悉的了，哪里最容易出问题，哪里该注意什么，可能对于你来说都不在话下，甚至你还可以写出你负责测试那个模块的用户手册。没错，这就足以说明你已经胜任售后及技术工程师的角色了，如果你确实不愿意再去做测试，不妨也考虑一下这个职位。

基本能力要求：
--非常熟悉产品的各项功能及使用，并具备较强的解决问题的能力
--较强的沟通和理解能力。要跟客户打交道的岗位，必须滴的哈。。。

7. 软件测试培训及咨询
其实这个职位是比较适合资格较老的测试工程师，他们已经对软件测试烂熟于心，技术能力较强，并且可以灵活变通，了解各种测试工具及方法，升职无望或者不想再从事具体的测试工作，可以考虑这个方向，并且从现在的待遇来看，培训及咨询行业的行情还是很不错的哟，呵呵。

基本能力要求：
--精通软件测试理论及具备一定的项目实践经验，熟悉各种主流工具、流程及方法等。
--较强的沟通、表达及引导能力。这条其实非常重要，你想想，在众人面前，你讲不出来，怯场，那什么都完了。
--能够根据企业或学员的具体情况给出理想的解决方案或培训方案。

好了，我能想到的就这么多了。显然题目比较夸张了，这里给出大家的职业发展选择远远没有“三十六行”那么多，但我想应该能够给到大家一些新的idea，至少我很少看到有人写到关于非软件测试行业本身应该有哪些比较“靠谱”的职业选择的。其实早就想把这篇文章写出来，现在终于如愿了。不管怎么说，我都希望各位看官能够在看完本文后，不管你仍然选择奋战在测试战线上也好，还是准备转行也好，都能够对自己将来的职业发展有一点点的想法和方向，那么我觉得你就没有浪费这么三五分钟看完本文，我就没有浪费那么三五个小时完成本文，呵呵。当然，我也希望借由这篇短文，大家可以谈谈自己心目中理想的职业发展方向，毕竟我们都不是高帅富，有个好的职业生涯发展是每个人都希望的事。

转载

测试人员尽早参与项目，是软件测试中的一个基本原则。但是，在测试实践中，测试人员的尽早参与常常是为了学习，例如：理解了测试对象之后进行测试用例的设计，而将尽早发现其中的问题和缺陷的目的放在了较低的优先级。这实际上很大程度上违背了评审的初衷。

　　下面通过笔者实际经历的一个案例，阐述这样的一个观点：测试人员参与评审，其最主要的目的是尽早发现其中的问题和缺陷；当然学习也是一个目的，但是学习的目的是为了更好的理解和设计测试用例，而设计的测试用例，其主要的目的是更加有效的发现测试对象中的缺陷，以提高产品质量。而在测试执行过程中发现和修复缺陷的效率会比评审低的多，而成本将高的多，该方面的信息，可以参考博客中的另一篇文章“用数据说话：评审如何降低成本、提升质量和帮助过程改进”。

　　案例中功能的简单描述：登陆某个系统，例如：某个网站，首先需要创建不同权限的用户。不同权限的用户，其对系统操作的内容是不一样的。本案例中，用户的权限UAP（User Access Privileges）分别定义为CONF、PROV、ADMIN、DEBUG和READ五种类型。

　　针对用户权限UAP的选择，系统的需求是这样描述的：创建的用户UID（User Identifier），可以为它们分配不同权限的UAP。但是，每个用户的权限UAP都至少包括READ权限，即每个用户都需要有READ权限。图1是用户权限UAP进行选择和删除的简单示意图。

图1 用户的UAP选择示意图

　　在开发人员实现该功能的过程中，包括图1的界面设计上，尽管测试人员都参与了评审，但是测试人员由于时间、资源和理念方面的原因，仅仅只是定位在功能的学习和理解上面。等开发人员将功能提交给测试人员之后，测试人员在测试过程中发现了下面的几个缺陷：

　　● 默认得UAP权限READ可以被删除，即在图1中，右边方框内的Read-only（READ）可以被移除；

　　● 假如在修改用户的属性时候，再选择一次Read-only（READ），那么修改之后的用户权限中会出现两个Read-only（READ）的条目，如图2上半部分所示；

　　● 假如在修改用户属性的时候，只选择了除Read-only（READ）之外的其他权限UAP，那么修改之后的用户权限没有了Read-only（READ），如图2所示的下半部分；

图2 用户的UAP缺陷示意图

根据系统需求中的描述，每个用户的权限都至少包括Read-only（READ），因此，上面的3个问题都应该确认为缺陷，测试人员分别都提交了缺陷报告。

　　在项目结束之后的总结会议上面，笔者就针对该功能的实现和GUI提出了自己的想法：假如在开发人员具体实现阶段，测试人员将评审的目的更多的放在发现缺陷上面，开发人员尽早修复其中的问题，那么该功能的实现可以更加简单高效，而测试人员后期的工作量也可以大大降低。笔者的建议包括：

　　● 根据需求的描述，Read-only（READ）应该作为每个用户UID必须具备的权限，因此将Read-only（READ）作为每个用户的默认值，不允许进行增加、修改和删除等动作；

　　● 根据上面的建议，在该功能的图形化，如图1所示中，将Read-only（READ）选项移除，因为改选项已经通过内部代码实现了，不需要操作人员进行选择。

　　假如测试人员在评审过程中发现了上述的问题，并根据上面的建议开发人员进行了修复，那么，在软件实现过程中，可以获得下面几个好处：

　　● Read-only（READ）作为每个用户的默认值，不允许增加、修改和删除，那么，在图1的示意图中直接删除Read-only（READ）选项，可以简化示意图；

　　● 按照上面的思路，代码中就可以省略针对Read-only（READ）异常处理，例如：在修改的时候，不需要判断用户是否重复选择了Read-only（READ）选项，或者没有选择Read-only（READ），直接可以节约开发人员的代码异常处理的工作量；

　　● 而对于测试人员，由于前期参与评审工作，发现了其中的一些缺陷，提高了代码的质量，可以减少后续的测试工作量；

　　假如测试人员、系统人员和开发人员在实现该功能之前，认真仔细的评审了具体的实现，那么，我相信上面碰到的问题就可以避免在系统测试过程中才被发现。另外，系统人员、开发人员和测试人员在针对该功能的评审过程中，除了可以避免将这些问题和缺陷引入到工作产品中之外；还可以帮助大家对功能的实现和期望结果有了更好的认识，并更加容易达成一致。这是不是可以更好的实现在整个团队内部的知识共享呢？

导读：使用集成化安全模式，OS安全性可以大大地简化管理工作，管理员不需要再同时管理两个独立的安全模型。这样还可以使连接字符串中不包含密码。SQL安全是数据库管理员最为重要的工作之一，下文中总结的注意事项希望大家在以后的工作中都能够足够重视。

　　1） 花点时间去审计SQL登录密码的有效性以及密码安全性。

　　使用以下代码检查无效密码：

Use master Select name, Password from syslogins where password is null order by name

　　检查密码安全性的强弱有很多免费和付费工具，SQLPing2就是一个免费的工具，可以用来检查密码的有效性和安全性。

　　2）经常检查群组和角色成员身份

　　虽然SQL Server安全性模式有很多改进，但是它也同时增加了一层额外的权限，我们必须对此进行监督，确保每个成员的权限符合其成员身份。还有的情况就是用户在企业里的身份已经发生改变，但是SQL Server的权限结构还没有做出相应的调整。

　　3）保证SQL Server的物理安全性

　　把SQL Server锁在门后，如果你正在使用它，就把钥匙锁藏起来。因为坐在server前的人总有会钻空子的。

　　4）重写应用程序，使用能够更好地定义用户的存储程序和视图

　　这样做可以尽量减少提供直接访问表格权限的需要。程序开发员能够更好控制数据存取的情况。

　　5）启用记录所有用户登录事件

　　你可以通过以下代码完成这一点：

　　xp_instance_regwrite N'HKEY_LOCAL_MACHINE'， N'SOFTWARE\Microsoft\MSSQLServer\MSSQLServer'，N'AuditLevel'， REG_DWORD，3

　　6）检查master..Sp_password中是否含有trojan代码

　　把你的生成脚本与全新安装程序的过程默认脚本进行对比。把这些代码保存在方便查阅的地方。

7）检查master..Sp_helpstartup中是否含有trojan程序

　　确保这里没有后门程序。使用Sp_unmakestartup来清楚所有流氓程序。

　　8）除非绝对有必要的情况，否则禁用SQL Mail功能

　　开放这个功能无疑给黑客另一个传播木马、病毒或者给攻击服务器使其不能提供服务的途径。这个功能本身并没有任何害处，但是它能够被黑客所利用。

　　9）清除数据库里的访客用户，确保没有未授权用户滥用数据库

　　这个是默认设置，但是要警惕一些dbo在权限控制上出现松懈的情况。唯一的例外情况是当主数据库和tempdb数据库需要作为访客帐户登录时。

　　10）确保所有SQL Server数据和系统文件都安装在NTFS分区里

　　如果有人需要访问OS，确保需要有必要的权限设置，防止出现重大问题。

　　11）需要使用SQL Server服务时使用低权限的用户帐号，而不要使用LocalSystem或管理员帐号。

　　这个帐号应该设置为最小权限（最好是本地用户），而且应能够在出现漏洞的情况下抑制服务器受到攻击。注意如果使用Enterprise Manager或SQL Server Configuration Manager （SQL 2005）来做改动的话，文件、注册和用户权利的SCLs都会自动完成。

　　12）设置安全性强的密码来保证“sa”帐户的安全

　　适用于使用SQL Server和Windows安全模式的情况。尽可能使用Windows Only模式，这样你就不用担心有人会强制使用“sa”帐户。当然，就算做到这一步，最好还是设置一个安全性强的密码，因为难免不会出现有人改变系统模式的情况。

　　13）只选择企业必需的网络连接库

　　如果企业的SQL Server只是本地使用，为什么不禁用所有的网络连接库，只使用共享内存来访问SQL Server呢？只用'（local）'作为服务器名称。如果你的SQL Server需要连接其他服务器，使用TCP/IP netlib，然后决定是否需要SSL。

　　14）确保使用最新版的操作系统和SQL Server 服务包/热补丁

　　毫无疑问，这是安全事项里不可能会缺少这一项。只要在你的SQL Server里执行"select @@version"。

(声明：以下是转载的别人的帖子，但是别人也是转载的却未注明出处，所以我也找不到原文出处）

考官从办公室（面试 现场）随意选取一个简单物品，假定是一个喝水的带广告图案的花纸杯，让应聘人对它设计出尽可能多的测试 用例。

测试项目：杯子

需求测试：查看杯子使用说明书

界面测试：查看杯子外观

功能度：用水杯装水看漏不漏；水能不能被喝到

安全性：杯子有没有毒或者细菌

可靠性：杯子从不同高度落下的损坏程度

可移植性：杯子在不同的地方、温度等环境下是否都可以正常使用

兼容性：杯子是否能够容纳果汁、白水、酒精、汽油等

易用性：杯子是否烫手、是否有防滑措施、是否方便饮用

用户文档：使用手册是否对杯子的用法、限制、使用条件等有详细描述

疲劳测试：将杯子盛上水（案例一）放24 小时检查泄漏时间和情况；盛上汽油（案例二）放24 小时检查泄漏时间和情况等

压力测试：用根针并在上面不断加重量，看压强多大时会穿透

跌落测试：杯子加包装（有填充物），在多高的情况下摔下不破损

震动测试：杯子加包装（有填充物），六面震动，检查产品是否能应对恶劣的铁路\ 公路\ 航空运输

测试数据： 
其中应用到：场景法、等价类划分法、因果图法、错误推测法、边界值法等方法

期望输出： 
该期望输出需查阅国标、行标以及使用用户的需求

说明书测试：检查说明书书写准确性

PS:以下都是从网上搜罗来的，版权比较难注明，主要目的是分享及讨论。

如何测试一支铅笔？

1,功能测试 能不能称作一只笔 是否能书写..
2,性能测试 写起来是不是很流畅，压力测试 用多久能用完..可对比其他上市铅笔 有什么优点。
3,用户体验 找适当人群组织群众使用 并跟踪记录使用后反应出来的效果。
4,破坏测试 多大的力气可以折断啊...等等啊
5,安全测试 铅笔芯是不是有毒，笔的木质是不是在折断时 弄坏手之类的。
6,外观审视 一般审视 这种设计是不是耐看 颜色是不是用户可以接受。

如何测试一支黑色签字笔

答案一：1,功能测试(能不能完成一支笔的需求)
2,性能测试(压力测试,看用多久能用烂,把它绑在电动机上划纸盒)
3,用户体验(找尽量多的群众,搜集FeedBack)
4,破坏测试(看在几楼掉下会摔坏,记录高度和地面硬度,烧,看燃点是多少,煮,看煮完坏不坏...)
5,安全测试(潜入机场,把这个扔在飞机进气孔里,看能不能引起爆炸;让白鼠吃笔心,看是否中毒...) 

6,外观审视 一般审视 这种设计是不是耐看 颜色是不是用户可以接受。

（很多人都评价这个答案好，我觉得那个破坏性测试和安全测试有点太离谱了吧）

答案二：1，写写出不出水,是不是黑色,能写多长时间多少字,时间长了笔头会不会出问题(比如像圆珠笔一样漏油的问题)，在不同的纸上写出的效果是怎么样,会不会把纸划坏
2，笔杆是粗是细,抓在手上舒服不舒服,写时间长了会不会手长茧
3，扔地上再拿起来看看能不能再写,如果是圆的放桌上容不容易掉到地上,不带套长时间放在外面还能不能再写,
4，市场上容易不容易买到能装进这支笔的笔芯
5，放在特别冷和特别热的地方能不能写
6，笔杆是不是塑料的,和其它东西比如橡皮放在起会不会出问题(粘在一起)
7，能不能别在衣服上,别在衣服上时看上去是不是很帅
8，能不能被人容易地掰断,踩碎,掉地上被踩碎是很可能发生的
9，当垃圾扔掉以后会不会产生毒副作用,如果经常咬笔头会不会中毒,抓着它写手是不是会烂掉........

（这个比较全，但是有点乱，等我把软件测试学的比较专业的时候，回头再评价）

如何测试一支钢笔？