http连接对于测试同学来说， 不论做功能、性能或是安全，都是非常重要的， 他过滤了前台的因素，让测试同学直接能对后台进行交互。

　　以上是http连接的重要性，基本等于废话，下面是正题。

　　客户端安全测试，同样需要拿到http的请求包，由于客户端的前段限制绕过比较麻烦，那么在做安全测试的过程中，直接拿到http的请求包显得更外重要。

　　有如下方法可以拿到请求的http包：

　　1、在不配置代理的情况下，对Android客户端（模拟器）的数据我们可以使用wireshark或者etherpeek等网络层抓包软件抓取，模拟器本身的数据交互是通过电脑主机的网卡进行的，所以我们通过抓包软件抓取主机网卡的数据包，经过过滤，便可得到模拟器客户端中的数据包，类似这样：

　　访问之后，通过wireshark过滤http请求，便可找到我们刚刚发送的请求。

　　当然，这是种比较麻烦的方法，不过可以更确切的看到网络包发送的内容。

　　另一种办法是对模拟器配置代理，让所有请求包可以通过外部主机的七层抓包软件，例如fiddler ，burpsuite等所捕获到，配置代理需要先做一次设置：类似这样：

　　进 入“设置”选项之后，按照图示设置

　　这里proxy 设置为10.0.2.2是android模拟器对外部主机地址的硬编码，端口设为8888是外部主机fiddler 的监听地址，当然，如果是burpsuite 可以设置为8080。

　　那么这样的话 ，我们就能通过fiddler抓取模拟器中的数据包了， 这样对测试来讲，可以用web端的应用层工具对客户端的http数据进行处理，方便的可就多了。

　测试人员参与代码检视的收益：

　　a）测试人员可以在早期就能够熟知系统，提前发现代码中的BUG；

　　b）提高测试工程师阅读代码和写代码能力；

　　c）测试工程师的经验积累后，可以避免一些很常见，很普通低级的错误；

　　d）测试取得话语权，促进开发与测试的更多平等沟通；

　　e）对于开发新员工的代码，收益会加倍（新员工容易犯业务上的低级错误）。

　　第零步：（比如新参与某系统的测试）

　　a）学习业务知识；

　　b）学习系统整体架构；

　　c）开发同学讲解设计架构、代码结构；

　　d）熟悉使用系统，找到阅读代码下手点：从日志、业务入口、SqlMap等；

　　e）从流程或者数据流阅读下去，然后一步步深入到代码中。

　　第一步：（code review准备）

　　a）当需求已经确定，测试同学需要参与方案的讨论；

　　b）开发开始编写代码，测试进行测试用例设计；

　　c）当开发某个类或者功能或者方法已经基本稳定，让开发串讲实现方式（避免出现实现方式不合理）；

　　d）测试同学可以开始review开发的代码，同时补充或者去重复测试用例（story或者sdv测试用例）。

　　第二步：（code review进行）

　　a）对代码的规范进行检视；

　　b）对代码的可测试性进行检视；

　　c）从业务场景的角度去review代码，如果实现存在的问题，那基本上可以发现；

　　d）对于发现的问题，建议分时段给开发，否则会打乱开发的写代码节奏；

　　e）如果你还不懂设计、不懂架构，那么可以从是否浪费CPU、是否浪费内存的角度看代码。

　　第三步：（code review后）

　　a）转测试后，应该不出现实现方案不合理的情况；

　　b）有结果统计，这个迭代review的记录数，可以横向比较；

　　c）迭代总结，开发与测试一起进行经验教训分享。

　首先，恭祝51testing生日快乐，感谢您一直是所有软件测试人员成长的摇篮和精神支柱！

　　从刚刚接触软件测试工作，到现在已经有十年之久。

　　十年前，毕业后就进入了一家软件公司，经理分配的任务就是测试软件，发现有错的地方就告诉他。这是我对软件测试工作的第一印象，就是看系统是否报错，各个功能按钮是否能够正确响应。

　　两年后，由于公司经营不善，我被公司裁员。其理由是：技术总监认为没有必要设置软件测试工程师的岗位。因此，竞岗时，我无岗可竟。

　　恰巧，当时中国软件评测中心跟省科技厅联合培训，于是，我就第一次真正认识到什么是软件测试。同时，也知道了51testing和测试时代这些软件测试交流的专业平台。

　　之后，我就入职另一家软件公司。当时，入职的职务是测试员，但公司的测试基本上和我第一次接触软件测试工作时的水平差不多。于是，我就从最基础的缺陷管理、测试用例、测试流程、测试规范、测试标准等等，一步步的将公司的测试规范建立起来，而我也因此成为了公司的测试部门经理。从测试员到测试部门经理，在这短短的八个月的时间里，可以说我取得的每一次进步，掌握的每一种知识，均来源于51testing和QQ群。可以说，如果没有这些交流平台，就不可能有系统化学习的机会。

　　为了挑战质量要求更高的项目，我离开了家乡，加入了现在的团队。这是一支由150多名技术人员组成的团队，其中，测试人员有20人。我入职的职务是测试组长，两周后任质量经理，八个月后任测试总监。从各种测试标准的制定到测试规范的建立，再到测试体系的建立；从团队战略发展方向到团队梯队建设再到测试知识库的筹建；从技术培训到团队成员职业规划；三年来 ，我和这支团队一起成长。

　　从业近十年，参与的项目十余个，其中千万级以上的项目三个。项目涉及MIS、HIS、GIS、OA、三维应用、BI、SOA、应用系统集成等诸多方向，其测试类型包括：功能测试、性能测试、接口测试。

　　说了这么多，大家一定以为我写跑题了，其实不然。之所以描述自己的成长经历，是想告诉大家我的体会来源于我的经历。

　　无论是在各种测试论坛上，各个测试QQ群中，还是在招聘时的应聘人员。我经常会遇到这种问题，相信大多数同行们也都遇到过。

　　1、做功能测试有前途么？
　　2、做黑盒测试有前途么？
　　3、我现在只能做功能测试，但我今后一定要做自动化测试、性能测试！
　　4、你们公司上自动化了么？
　　5、我会QTP、LR。

　　广大测试同行在投简历时，也一定常见这种职位要求：要求熟练掌握LR、QTP、QC、TD、Bugzilla等工具之一。

　　咱们先说说后面这种情况。一个公司在选择测试人员时，竟然将这些测试工具作为选人标准之一。我想问这样招聘的公司几个问题：

　　1、贵公司的产品适合上自动化么？
　　2、贵公司的管理水平达到上自动化的要求了么？
　　3、LR能完全支撑贵公司产品的性能测试么？
　　4、贵公司一年能有多少项目需要做性能测试？
　　5、缺陷管理工具每个公司用的都不太一样，其缺陷管理流程是需要结合公司管理流程的，这种工具即便人家不会或没用过此类工具，你就不能培训么？很难么？

　　除非公司是在招聘对口的技术人才，否则，我只能认为这家公司的测试水平真的不咋的。甚至于写招聘要求的人，压根就不懂测试。

　　咱们再来说说关于同行们对功能测试的误解。好多人都认为功能测试门槛低，没技术含量，好像提起来做功能测试就低人一等似得。如果你有这种意识，我只能说：兄弟，多干几年吧。我承认功能测试的入门门槛是低，但我不认为功能测试没技术含量。我甚至认为一个能把功能测试做好的测试人员，才是一个合格的质量负责人！

　　大家先别拍我，让我们来谈一下什么是软件测试。既然大家都是同行，相信大家都认同：“通过测试手段，在用户使用前，发现缺陷。”以及“软件中不可能没有缺陷。”这两句话。不错，测试是不能被穷举的，因此，我们也不可能发现软件中所有的缺陷。因此，我们是不是能够换句话说：“软件测试是通过一系列的测试手段，证明软件具备一定的质量。”

　　如果你认同这一观点，那么我们再来谈谈功能测试的范围。

　　狭义的功能测试：这点点，那点点，看看能不能正确打开页面、程序会不会崩溃、功能是不是能够正确实现等等。这也就是大家之所以认为功能测试没技术含量的根本原因。因为这种测试也得叫它功能测试。

　　广义的功能测试：各种业务逻辑是否已正确实现？各种业务约束是否正确实现？各类特殊的数据是否能够正确处理？软件的容错机制如何？数据的完整性、唯一性、正确性是否已经通过测试？系统及数据的安全性是否已通过测试？软件的易用性是否满足用户的需要？等等等等。功能测试所包含的范围实在是太大。

　　我没有贬低其他测试专业的意思，但有几点是需要说明的。随着各行各业对信息化建设的需求日益提高，其软件的规模和复杂度正在翻倍的提高。而功能测试的难度也随软件的复杂度逐日提高。而相对来说，白盒测试依旧关注的是单个函数的代码逻辑以及异常的处理；自动化测试仅仅提高的是测试执行效率，测试质量依然是要靠功能测试用例来保障；性能测试其实关注的是业务发生的场景和如何生成负载和收集监控指标，其变化就是需要监控的对象更多，影响因素更为复杂。

　　面对规模庞大，业务逻辑愈来愈复杂的系统，保障其软件质量，就需要广大功能测试人员具备更强的逻辑分析、设计能力；掌握更多的业务知识及技术。同时，由于当前国内绝大多数企业对测试工作的认知程度不足，大多数测试工作都是在时间紧、任务重的条件下完成的。那么，在有限的条件下，如何能够提高软件产品的质量，即：如何证明软件具备了一定的质量。将是所有软件质量负责人首先考虑的问题。

　　在这种前提下，我认为，一个好的功能测试工程师应具备丰富的行业知识（专家级），极强的逻辑分析能力，精于业务架构、测试架构、数据库、测试用例的设计。公司的产品质量，取决于测试负责人的组织能力及团队成员的技术能力，因此，功能测试工程师在测试团队中不可或缺。

　　无论是白盒测试、自动化测试、性能测试，都是不同的测试手段，但功能测试却是产品质量的根本保障！ 请广大正在从事功能测试的同行们，正视自己的工作，认真对待，不要气馁或轻视自己的工作。将自己手头上的事做好，人生的每一段经历都将是你的财富！

　　在企业内网的开发环境方面，文件服务器是一个非常重要的环节。其中，Samba服务器由于其权限控制的高度灵活性，最初学习时确实会让大家感到很迷惑，但我们可以先搭建一些简单的案例来掌握其语法。本节主要是介绍Linux下的高级权限suid、sgid、sticky三种权限的特点。

　　很多人都很奇怪，为什么我们需要学习这三种权限呢？因为在实际工作中我们发现，如果不了解这些特殊权限会让我们对Linux权限的理解（尤其是加上Samba权限后）尤为困难，所以我们必须要学习并了解它们。下面试图用浅显的讲解，让大家能充分理解这三种权限的作用。理解了它们，再理解Samba的权限控制就更容易了。

　　注意　Samba的权限由两方面构成：

　　一是目录本身的权限；二是Samba的配置权限。最终权限的定义是两者的最小交集。

　　我们接着来理解这3种权限：

　　1）一个文件都有一个所有者，表示该文件是谁创建的。

　　2）如果同时该文件还有一个组编号，则表示该文件所属的组一般为文件所有者所属的组。

　　3）如果是一个可执行文件，那么在执行时，一般该文件只拥有调用该文件的用户所具有的权限。

　　权限标志通过以下3个“位”来定义。

　　setuid：设置使文件在执行阶段具有文件所有者的权限。比如/usr/bin/passwd，如果是一般用户执行该文件，则在执行过程中，用户通过该文件可以获得root权限，从而可以更改用户的密码。

　　setgid：该权限只对目录有效。目录被设置该权限后，任何用户在此目录下创建的文件都具有和该目录所属的组相同的组。

　　sticky：该位可以理解为防删除位。一个文件是否可以被某用户删除，主要取决于该文件所属的组是否对该用户具有写权限。如果没有写权限，则这个目录下的所有文件都不能被删除，同时也不能添加新的文件。如果希望用户能够添加文件但同时又不删除文件，则可以对文件使用sticky bit位。设置该位后，就算用户对目录具有写权限也不能删除该文件。

　　下面介绍一下三种权限的特点。

　　（1）sticky的特点

　　sticky只能应用在目录上，并且是应用在其他人的目录上。

　　只有root和文件的拥有者才能删除该文件。

　　小写s表示能执行，大写S表示不能执行。

　　它的其他特点大家可以参考/tmp目录。

　　（2）setuid的特点

　　setuid只能应用在二进制文件中。

　　当一个文件应用了setuid，那么任何人在执行该命令的时候就能临时拥有该文件拥有人的权限。

　　setuid只能应用在文件的拥有者上。

　　小写s表示能执行，大写表示S不能执行。

　　它的其他特点大家可以参考/usr/bin/passwd目录。

　如果您很容易使 shell 提示行变得色彩绚烂且带有更多信息，为什么还要坚持用烦人的标准提示行呢？在这篇技巧中，Daniel Robbins 将说明如何获得符合您的意愿的 shell 提示行，并会说明如何动态更新 xterm 的标题栏。

　　作为 Linux/UNIX 人，我们有很长的时间是在 shell 中工作，并且在许多情况下，下面这一行就是始终盯着我们的那个提示行：

　　bash-2.04$

　　如果您恰巧是超级用户 (root)，您就有权使用下面这个美丽的标示“身份”的提示行版本：

　　bash-2.04#

　　这些提示行并不是十分漂亮。这也就难怪几种 Linux 版本对默认提示行进行了升级，在其中增加了颜色和更多的信息。但是，即便您恰好有一个本身带有很好的彩色提示行的新式版本，它也不可能是完美无缺的。您或许希望在提示行中增加或更改几种颜色，或者增加(或删除)一些信息。从头开始设计属于您自己的彩色的、经过装饰的提示行并不难。

　　提示行基础

　　在 bash 下，可以通过更改 PS1 环境变量的值来设置提示行，如下所示：

　　$ export PS1="> " >

　　更改会立即生效，通过将 "export" 定义放在您的 ~/.bashrc 文件中可将这种更改固定下来。只要您愿意，PS1 可以包含任意数量的纯文本：

　　$ export PS1="This is my super prompt > " This is my super prompt >

　　尽管这很有趣，但在提示行中包含大量静态文本并不是特别有用。大多数定制的提示行包含诸如用户名、工作目录或主机名之类的信息。这些花絮信息可以帮助您在 shell 世界中遨游。例如，下面的提示行将显示您的用户名和主机名：

　　$ export PS1="\u@\H > "drobbins@freebox>

　　这个提示行对于那些以多个不同名称的帐户登录多台机器的人尤为有用，因为它可以提醒您：您目前在哪台机器上操作，拥有什么权限。

　　在上面的示例中，我们使用了专用的用反斜杠转义的字符序列，藉此通知 bash 将用户名和主机名插入提示行中，当这些转义字符序列出现在 PS1 变量中时，bash 就会用特定的值替换它们。我们使用了序列 "\u"（表示用户名）和 "\H"（表示主机名的第一部分）。下面是 bash 可识别的全部专用序列的完整列表（您可以在 bash man page 的 "PROMPTING" 部分找到这个列表）：

　　序列说明

　　\aASCII 响铃字符(也可以键入 \007)

　　\d"Wed Sep 06" 格式的日期

　　\eASCII 转义字符(也可以键入 \033)

　　\h主机名的第一部分(如 "mybox")

　　\H主机的全称(如 "mybox.mydomain.com")

　　\j在此 shell 中通过按 ^Z 挂起的进程数

　　\l此 shell 的终端设备名(如 "ttyp4")

　　\n换行符

　　\r回车符

　　\sshell 的名称(如 "bash")

　　\t24 小时制时间(如 "23:01:01")

　　\T12 小时制时间(如 "11:01:01")