在家不上网 所以写起来比较慢

上次写到测试用例 以及在测试的过程中对测试用例的使用情况。关于测试用例基本上就这么多，中间有些环节可能记得不太清楚了 以后想起来再补充。

还有就是重新用户发现的问题，像转换问题会附有相应的文件还比较好重现，这种问题算是我们在制作测试数据时没有考虑到的问题，遇到这样的问题，我们通常要把用户发来的附件作为特殊的测试数据写入测试用例中。

还有些用户问题如：葡萄牙用户发来的问题，先要找到葡萄牙语的操作系统，装葡萄牙语的软件，如果装换的是word文档还要转葡萄牙语的office或英文office，基本上符合用户的环境以后，按照用户邮件中的步骤一步一步的操作，有时会重现不了问题，遇到重现不了的情况只能把可能影响的模块告诉开发人员，让他们自己去找问题。

在用例基本完善了以后我们开始学习使用qtp自动化测试工具，因为买了qtp mercury送了一套winrunner的sn，我们把这两个测试工具，结合起来使用。最初的自动化测试是针对PDF driver的也就是pdf转换器，因为每次测试需要测试的测试数据太多了，所以希望能使用工具，减少工作量。先用qtp录制脚本，录制两份不同的脚本，一份是公司的driver录制的脚本，一份是adobe driver录制的脚本，然后用winrunner比较两个driver转换的文档，与adobe不同的就是有问题，由于开始自动比较结果存在一些问题，还是会手动比较来进行确认，有些文档adobe的转换结果也不对，这个时候我们只能查阅pdf referrence 来证实结果的正确与错误。

基本上在第一家公司做的事情大概就是这么多，一年以后我就离开了这家公司来到现在公司，在现在的公司一直工作到现在，有3年多时间了。

我到现在的公司时，公司之前没有专门做测试的，也没有测试文档，测试流程，一切都是空白。开始的时候我只是按照以前的测试方法，先熟悉公司的产品（物流信息平台），对每个版本进行测试。然后将问题写到excel中发给开发人员，当时我自己制作了一个excel文档用于记录测试中发现的bug（因为没有bug系统），文档的格式大概就是（编号、操作步骤、问题、时间、测试人、开发人、备注）。这是一家刚起步的做物流信息的公司，随着我对公司产品的了解一步一步加深，对公司的了解也更多，开始我们的产品仅限于一个物流信息平台和一个门户网站、以及后台管理等等。慢慢的公司的产品也在增多手机物流平台、手机定位系统、车辆管理系统、运输管理系统等等。

在对公司的产品熟悉以后我开始按照以前学习到的知识，先开始写测试需求（没有开发需求）、测试用例、建立测试流程、引入bug管理系统（jira）、配置管理（svn）等等。开始就我一个人做测试，因为产品少还能忙的过来，后台产品越来越多，一个人很难忙过来，我的头让我招2个人帮我一起测试，我招了2个小姑娘帮。

07年的软件评测师考试报名又开始了，最近很多测试朋友也很关注，并对软件评测考试充满了好奇，论坛上也有一些讨论和交流。由于本人去年幸运的通过了软件评测师考试，因此将一些心得分享给大家，同时欢迎参加过考试的朋友也来谈谈经。

　　一些说明

　　计算机技术与软件专业资格(水平)考试分为初级、中级、高级，其中软件评测师属于中级。软件考试每年有两次，但评测师只有上半年才有。通过了这个考试,相当于中级职称。软测的考试年龄只有两岁，2005年5月第一次进入考试范围，可以说它是新生的充满活力的生命，成长空间很大。很多测试人员都不知道有这个水平考试的存在。据说前两年考试通过率都比较低，10%不到。

　　软件评测师考试意义

　　现在考证是个趋势，但说实在的，软考证书个人现在不觉得有什么实际用处，可能大多数软件公司并不会因为你获得了软件评测师资格或是中级职称就升工资(少数公司福利好的可能会有)，也许在找工作的时候会有点帮助吧。

　　倒是备考过程中的学习意义比较大，毕竟很多基础的知识的记忆都不是很牢固，回过头去巩固学习别有一番体会，也会触发更多工作方法的灵感。即使通不过自己的知识也增长了!

　　另外，如果能通过自己努力，在10%通过率下顺利通过，也是很有成就感的啊 ，咔咔。

　　备考经验

　　备考的复习资料主要有考试大纲、指定教材软件评测师教程、以及一些试题及答案分析。我觉得评测师教程不错，条理很清晰，阅读起来比较容易理解，我现在还一直作为手册来用。个人建议在考试前至少两个月就要开始复习备考了并做好学习计划，因为一开始还是比较难以进入良好的学习状态，同时需要复习的内容也很多很细需要一定的时间去理解消化，如果备考时间不足临时抱佛脚就不太好了。当然个人情况不一如果你原来基础就很好那也不需要。另外一些章节后面的习题也要做一下并弄懂解答原理，因为有一些考试试题就是类似的。

　　把考前的心态调整好比较重要。不要理解为去应付考试，这样很消极对备考不好，我们可理解为平时难得有机会这么系统的去学习，借助考试的机会好好的复习一把。这样的会就比较容易找到动力了。同时最好不要有侥幸心理。

　　考试分上午题和下午题。上午题主要是考基础理论，考的范围很广很细，这要求备考时准备充分一下，考试内容大部分都来自教程;下午题考实战的，需要理论加实际工作经验了，但大部分还是书本上有的。比如去年考的安装测试要点、单元测试路径、圈复杂度计算、性能测试等。

　　我的体会是只要备考充分加上一些工作经验还是比较好过的，也有人说去年的试题比较简单，不知道是不是。

　　软件评测师和测试工程师的区别

　　从字面理解上，评测就是测试+评价，以测为主，测完后再加上评价。个人理解，软件评测师只是一个考试的名称、资格的名称，而对应到实际工作中，仍然是测试工程师。并且，好像国外也没有评测师这一叫法?中国特色?

　　获取证书之后

　　通过了考试获取证书之后必须每3年到教育办公室(名字记不清了)进行登记，登记时需要出示继续教育证明。意思是通过考试之后每n(n>=1)年还要参加继续教育才行。这个比较麻烦。另外软件评测师只是中级职称，之后我们就要继续向高级职称的考试(信息系统项目管理师、系统分析师、系统架构设计师)挑战了，呵呵

07年的软件评测师考试报名又开始了，最近很多测试朋友也很关注，并对软件评测考试充满了好奇，论坛上也有一些讨论和交流。由于本人去年幸运的通过了软件评测师考试，因此将一些心得分享给大家，同时欢迎参加过考试的朋友也来谈谈经。

一些说明
计算机技术与软件专业资格（水平）考试分为初级、中级、高级，其中软件评测师属于中级。软件考试每年有两次，但评测师只有上半年才有。通过了这个考试,相当于中级职称。软测的考试年龄只有两岁，2005年5月第一次进入考试范围，可以说它是新生的充满活力的生命，成长空间很大。很多测试人员都不知道有这个水平考试的存在。据说前两年考试通过率都比较低，10％不到。

软件评测师考试意义
现在考证是个趋势，但说实在的，软考证书个人现在不觉得有什么实际用处，可能大多数软件公司并不会因为你获得了软件评测师资格或是中级职称就升工资（少数公司福利好的可能会有），也许在找工作的时候会有点帮助吧。
倒是备考过程中的学习意义比较大，毕竟很多基础的知识的记忆都不是很牢固，回过头去巩固学习别有一番体会，也会触发更多工作方法的灵感。即使通不过自己的知识也增长了!
另外，如果能通过自己努力，在10％通过率下顺利通过，也是很有成就感的啊 ，咔咔。

备考经验
备考的复习资料主要有考试大纲、指定教材软件评测师教程、以及一些试题及答案分析。我觉得评测师教程不错，条理很清晰，阅读起来比较容易理解，我现在还一直作为手册来用。个人建议在考试前至少两个月就要开始复习备考了并做好学习计划，因为一开始还是比较难以进入良好的学习状态，同时需要复习的内容也很多很细需要一定的时间去理解消化，如果备考时间不足临时抱佛脚就不太好了。当然个人情况不一如果你原来基础就很好那也不需要。另外一些章节后面的习题也要做一下并弄懂解答原理，因为有一些考试试题就是类似的。
把考前的心态调整好比较重要。不要理解为去应付考试，这样很消极对备考不好，我们可理解为平时难得有机会这么系统的去学习，借助考试的机会好好的复习一把。这样的会就比较容易找到动力了。同时最好不要有侥幸心理。
考试分上午题和下午题。上午题主要是考基础理论，考的范围很广很细，这要求备考时准备充分一下，考试内容大部分都来自教程；下午题考实战的，需要理论加实际工作经验了，但大部分还是书本上有的。比如去年考的安装测试要点、单元测试路径、圈复杂度计算、性能测试等。
我的体会是只要备考充分加上一些工作经验还是比较好过的，也有人说去年的试题比较简单，不知道是不是。

软件评测师和测试工程师的区别
从字面理解上，评测就是测试＋评价，以测为主，测完后再加上评价。个人理解，软件评测师只是一个考试的名称、资格的名称，而对应到实际工作中，仍然是测试工程师。并且，好像国外也没有评测师这一叫法？中国特色？

获取证书之后
通过了考试获取证书之后必须每3年到教育办公室（名字记不清了）进行登记，登记时需要出示继续教育证明。意思是通过考试之后每n（n>=1）年还要参加继续教育才行。这个比较麻烦。另外软件评测师只是中级职称，之后我们就要继续向高级职称的考试（信息系统项目管理师、系统分析师、系统架构设计师）挑战了，呵呵。

最后祝大家顺利通过考试，到时来这里给我报个喜，^_^！

QTP9.2TP9.2下载地址http://esd.mercury.com/akdlm/trial/qtp/qtp92.zip

WINRUNNER7.6:WR7.6下载地址http://lib.verycd.com/2005/03/16/0000042388.html

WINRUNNER8.0: WR8.0下载地址http://lib.verycd.com/2005/09/18/0000065515.html

LOADRUNNER8.0:hug: R8.0下载地址http://esd.mercury.com/akdlm/trial/lr/LR8DownLoad.exe

LOADRUNNER9.0:hug: R9.0下载地址http://esd.mercury.com/akdlm/trial/lr/LR9Download.exe

TD8.0::hug: TD8.0下载地址http://lib.verycd.com/2006/03/19/0000095046.html

我的QTP的学习方法及总结—参数化（三）

                              季风

关于QTP中的参数化

方法一、DataTable方法

这是QTP提供的一种方法，也是最容易实现参数化的一种方式。QTP针对DataTable对象提供了很多方法，可以对DataTable进行灵活的操作。DataTable分为Global和Local两种，Global所有的Action都可以用，而Local就是只能Action自己用。

通过DataTable做参数化最直接的方法就是在Keyword View视图下通过选项进行，这样即方便又减少出错的几率。单击要参数化项目的value列，选择出现的箭头弹出Value Configuration Option对话框，在这里可以很方便的进行参数化。

Parameters选择数据来源类型。DataTable是从数据表中取值，Environment是从环境变量中取值，Random Number是选择随机值。下拉列表选择DataTable后，选择所要使用的数据表Global还是local，最后选择name，参数取自哪列，点击确定后即可完成参数化过程。

Dialog("Login").WinEdit("Agent Name:").Set DataTable("UserName", dtGlobalSheet)

这是最简单最直接的方式。用这种方式需要注意，在File---Seting---Run需要做相应设置，否则运行结果很容易出错，使实际取到的参数值和预期的不一样或是循环不正确的错误。最好的方式是通过写语句来控制迭代过程中的取值。在脚本开发过程中，这种方式是最常用的。类似如下代码：

For i=0  to  DataTable.GetCurrentRow

Dialog("Login").WinEdit("Agent Name:").Set DataTable("UserName", dtGlobalSheet)

DataTable.SetNextRow

Next

DataTable提供了很多相关的方法和属性，具体参考帮助文档。帮助目录下的Utility.chm文档中有关于DataTable对象的详细介绍。

方法二、环境变量实现参数化

Environment 对象提供对环境变量的访问。环境变量的来源有两种方式：内部环境变量和用户定义的环境变量，其中后者支持从外部导入，格式为XML文件。用环境变量做参数化有一定的局限性，因为环境变量对数据的操作没有方法一灵活，所以环境变量用的最多还是数据的共享。在此暂作为一种方式来学习，灵活运用就好。

首先说内部环境变量。它是QTP默认定义的一组变量，包括一些系统信息、项目信息等。目前用到最多的是TestDir，利用这个可以实现一个相对目录的目的。具体应用，在做一个数据驱动的脚本时，将数据文件放到脚本文件夹中，然后利用Environment("TestDir")+DataName导入数据文件。这样可以很方便的移植，而不需要考虑将数据文件放到具体目录下。

用户定义的环境变量，需要自己定义变量名和值。定义好后就可以用这些变量去参数化脚本中的常量。

Dialog("Login").WinEdit("Agent Name:").Set Environment("test1")

这样做参数时，每个参数值都需要指定，而且不能批量的生成。所以它有一定的应用场景：当一个Test中的不同Action需要同样一个参数，用环境变量去参数化常量是很好的一种方式；其次就是不同的Test需要用到同样的参数时，用环境变量可以很好的解决这个问题。

方法三、外部数据源实现参数化

利用外部数据驱动脚本的运行，这是经常用到的方法，这样可以很方便的组织测试数据。相对前两种方法，这种方式数据的读取、控制稍有些麻烦。下面以常见的几种方式进行说明。（以下代码并不复杂，没做注释）

1.       数据文件以Excel组织

用Excel组织测试数据是最常用的了。此种驱动可以采用两种方式，将数据Import到DataTab中或是利用com来操纵Excel文件。下面给出这两种方式的示例代码。（输入flight用户名和密码）

方式一、导入到DataTable中

       '获得数据文件路径，并将数据文件导入到DataTable运行表中

       DataStr= Environment("TestDir")&"\data.xls"

       DataTable.AddSheet("TestData")

       DataTable.ImportSheet DataStr,"Sheet1","TestData"

       '输入用户名和密码

       For i=1 to DataTable.GetSheet("TestData").GetRowCount

              DataTable.SetCurrentRow i

              UserName=DataTable.Value("UserName","TestData")

              PassWord=DataTable.Value("PassWord","TestData")

              Dialog("Login").WinEdit("Agent Name:").Set UserName

              Dialog("Login").WinEdit("Password:").SetSecure PassWord

       Next

方式二、利用com操纵Excel

       DataStr= Environment("TestDir")&"\data.xls"

       Set ExlObj=CreateObject("Excel.Application")

       ExlObj.Visible = True

       ExlObj.DisplayAlerts = FALSE

       Set book=ExlObj.Workbooks.Open(DataStr)

       Set sheet=book.Worksheets("Sheet1")

       For i=2 to sheet.usedrange.rows.count

              UserName=ExlObj.WorkSheets("Sheet1").Cells(i,1)

              PassWord=ExlObj.WorkSheets("Sheet1").Cells(i,2)

              Dialog("Login").WinEdit("Agent Name:").Set UserName

              Dialog("Login").WinEdit("Password:").SetSecure PassWord

       Next

       ExlObj.Quit

       Set ExlObj = nothing

 

2.       数据文件以txt组织

不多说，直接附上代码。

Const ForReading=1

TFilePath= Environment("TestDir")&"\data.txt"

Set Fso3 = CreateObject("Scripting.FileSystemObject")

Set DataFile= Fso3.OpenTextFile(TFilePath,ForReading,False)

DataFile.SkipLine

Do while DataFile.AtEndOfLine<>true

       ReadString = DataFile.ReadLine

       DataStr=split(ReadString,",")

       Dialog("Login").WinEdit("Agent Name:").Set DataStr(0)

       Dialog("Login").WinEdit("Password:").SetSecure DataStr(1)

loop

DataFile.close

Set  Fso3=Nothing

3.       数据文件以数据库组织

下面代码是用Access做的，其他类型数据库类似。不多说继续贴出代码。

strDB="Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\Documents and Settings\zilingold\桌面\Testdata.mdb;Persist Security Info=False"

strTableName="data"

Set Conn=createobject("adodb.connection")

Set Rst=createobject("adodb.recordset")

Conn.open strDB

Rst.open "select * from "+strTableName,Conn,2,2

Dim strTest(1)

Rst.MoveFirst

Do while not Rst.eof

       strTest(0)=trim(cstr(Rst.fields(0)))

       strTest(1)=trim(cstr(Rst.fields(1)))

       Dialog("Login").WinEdit("Agent Name:").Set strTest(0)

       Dialog("Login").WinEdit("Password:").SetSecure strTest(1)

       Rst.MoveNext

Loop

Rst.close

Set Conn=nothing

4.       数据文件以XML组织

XML也是会经常用到的一种方式。继续贴代码。

Dim xmlDoc 'As DOMDocument 需要引用xml对象

set xmldoc=CreateObject("microsoft.xmldom")

xmldoc.load(Environment("TestDir")&"\testdata.xml")

Set  Root=xmldoc.documentElement

For i = 0 To Root.childNodes.Length-1

              Set TestCases = Root.childNodes.Item(i)

                     For j = 0 To TestCases.childNodes.Length-1

                            Set TestCase = TestCases.childNodes.Item(j)

                                   If cstr(TestCase.nodeName)="UserName" Then

                                          Dialog("Login").WinEdit("Agent Name:").Set TestCase.text       

                                   end if

                                   If cstr(TestCase.nodeName)="PassWord" Then

                                          Dialog("Login").WinEdit("Password:").SetSecure TestCase.text                                                                End If                         

                     Next

       Next

Set root=nothing

Set xml=nothing

 

以上是对各种方式进行简单介绍，作为一个引子。各种方法在使用过程中会有需要注意的以及出现的问题，需要在脚本开发过程中慢慢积累。

转自:

http://www.51testing.com/html/200902/n106827.html

　　如果你是测试员或是高级测试员，有志转向管理发展，那么需要加强以下内容，至少要做到几点：

　　1. 测试计划的编写（要结合测试的项目，能以此来控制和确定测试所需人员，设备及时间来管理测试时间）

　　2. 要熟悉BUG跟踪工具及软件测试流程（如: TD， Bugzilla， CQ等）

　　3. 要熟悉配置管理工具（如:TestCenter ，CVS， VSS等）

　　4. 要熟悉自动化工具（例如:WinRunner， QTP， Robot， RFT， Automation等，能结合录制完的脚本编写代码）

　　5. 要熟悉压力及性能测试工具（例如: AutoRunner，LoadRunner， webload， silkperformance等，能结合相关数据，分析出性能瓶颈）

　　6. 要熟悉或精通一门语言 （例如: Java， C++）

　　7. 要熟悉数据库（例如: Oracle， DB2， SQLServer， MySQL）

　　8. 要熟悉主流操作系统 （例如: HP Unix， IBM AIX， Sun Solaris， Red Hat Linux， SuSE Linux， Windows）

　　9. 能用英文流利的和老外交流以及往来Email

　　10. 语言表达能力强，表达问题清晰明了

　　11. 沟通能力强，能和上级/开发经理很好的达成测试相关/BUG事宜

　　12. 学习技术的能力要强，能快速上手一个新的技术

　　13. 乐于与人交流

一只苹果，两种人生

最近再一次拾起了Ubuntu，为了更好的玩儿转Linux，专门到网上搜到的这些常用的终端命令，根据命令使用类别的不同分为了9个大类，都在下面一一列举了出来，个人觉得还是很有用的，在以后的时间里，小弟会随时更新自己对于Ubuntu的使用心得一.

　　文件目录类

　　1.建立目录：mkdir 目录名

　　2.删除空目录：rmdir 目录名

　　3.无条件删除子目录： rm -rf 目录名

　　4.改变当前目录：cd 目录名 (进入用户home目录：cd ~;进入上一级目录：cd -)

　　5.查看自己所在目录：pwd

　　6.查看当前目录大小：du

　　7.显示目录文件列表：ls -l (-a：增加显示隐含目录)

　　8.浏览文件：more 文件名.txt;less 文件名.txt

　　9.复制文件： cp 源文件 目标文件 (-r：包含目录)

　　10.查找文件：(1)find (2)locate 命令名

　　11.链接：(1)建立hard链接：ln 来源文件 链接文件(-d：创建目录链接）；(2)建立符号链接：ln -s 来源文件 链接文件

　　二.驱动挂载类

　　1.检查硬盘使用情况：df -T -h

　　2.检查磁盘分区：fdisk -l

　　3.挂载软硬光区：mount -t /dev/fdx|hdax /mnt/目录名

　　其中：：modos--FAT16;vfat--FAT32;ntfs--NTFS;光驱--iso9660

　　支持中文名：mount -o iocharset=x /dev/hdax /mnt/目录名(其中：x=cp936或

　　挂载光驱：mount -t auto /dev/cdrom /mnt/cdrom

　　挂载ISO文件：mount -t iso9660 -o loop xxx.iso /path

　　4.解除挂载：umount /mnt/目录名

　　解除所有挂载：umount -a

　　5.建立文件系统：mkfs -t /dev/hdxx。其中：ftype：ext2、ext3、swap等

　　三.程序安装类

　　1.RPM包安装：(1)安装 rpm -ivh somesoft.rpm

　　(2)反安装 rpm -e somefost.rpm

　　(3)查询 rpm -q somefost 或 rpm -qpi somefost.rpm(其中：p未安装;i包含的信息)

　　(4)查询安装后位置：rpm -ql somefost.rpm

　　(5)升级安装：rpm -Uvh somesoft.rpm

　　(6)强制安装：rpm -ivh --nodeps somesoft.rpm 或 rpm -ivh --nodeps --force somesoft.rpm

　　2.源代码包安装：

　　查阅README

　　基本用法 (1)配置：解压目录下 ./configure

　　(2)编译：解压目录下 make

　　(3)安装：解压目录下 make install

　　3.src.rpm的安装

　　需要用到rpmbuild命令加上--rebuild参数。如 rpmbuild --rebuild ***.src.rpm。然后在/usr/src/下找

　　3.FC3下iso程序安装：system-config-packages --isodir=iso所在目录

　　RH下iso程序安装：redhat-config-packages --isodir=iso所在目录

　　四.压缩解压类

　　1.tar.gz类：(1)解压：tar -xvzf 文件.tar.gz；(2)tar.gz解至tar：gzip -d 文件.tar.gz(2)压缩：gzip 待压缩文件

　　2.tar未压缩类：(1)解包：tar -xvf 文件.tar；(2)打包：tar -cvf 文件.tar 文件列表

　　3.zip类：(1)解压：unzip 文件.zip -d dir；(2)压缩：zip zipfile 待压缩文件列表

　　4.bz2类：(1)解压：bunzip2 文件.bz2或bzip2 -d 文件.bz2；(2)压缩：bzip2 待压缩文件

　　5.z类：(1)解压：uncompress 文件.z；(2)压缩：compress 文件

　　五.进程控制类

　　1.列出当前进程ID：ps -auxw

　　2.终止进程：(1)终止单一进程：kill 进程ID号

　　(2)终止该程序所有进程：Killall 程序名

　　(3)终止X-Window程序：xkill

　　3.查看资源占用情况：(1)top (2)free (3)dmesg

　　4.查看环境变量值：env

　　5.重启：(1)reboot (2)Ctrl Alt Del (3)init 6

　　6.关机：(1)shutdown -h now (2)halt (3)init 0

　　7.切换桌面：switchdesk gnome|KDE|...

六.程序运行类

　　1.查询命令：whereis 命令名

　　2.后台运行X-Window程序：程序名&

　　3.强行退出X-Window程序：Ctrl Alt Backspace

　　4.查看帮助：

　　(1)简明帮助：命令名 --help | less

　　(2)更多帮助：man 命令名

　　(3)info 命令名

　　(4)help 命令名

　　5.查看系统路径：echo $PATH

　　6.查看当前shell堆栈：echo $SHLVL

　　7.< / >：输入/输出重定向;|：管道左的输入是管道右输入

　　 六.用户帐号类

　　1.增加用户帐号：(1)用 户 名：adduser 用户帐号名

　　(2)设置密码： passwd 用户帐号名

　　2.删除用户帐号：userdel 用户帐号名

　　3.增加用户组：groupadd 用户组名

　　4.删除用户组：groupdel 用户组名

　　5.暂时终止用户帐号：passwd -l 用户帐号名

　　6.恢复被终止帐号：passwd -u 用户帐号名

　　7.权限设定

　　(1)chmod -a|u|g|o |-|=r|w|x 文件/目录名

　　其中：a--所有用户(all);u--本用户(user);g--用户组(group);o--其他用户(other users)

　　--增加权限;---删除权限;=--设置权限

　　文件：r--只读权限(read);w--写权限(write);x--执行权限(execute)

　　目录：r--允许列目录下文件和子目录;w--允许生成和删除目录下文件;x--允许访问该目录

　　(2)chmod xxx 文件/目录名

　　其中：execute=1;write=2;read=4

　　x取值：0--没有任何权限(常用);1--只能执行(不常见);2--只能写(不常见);3--只能写和执行(不常见);4--只读(常见);5--只读和执行(常见);6--读和写(常见);7--读.写和执行

　　 七.vi编辑类

　　1.进入后为命令模式：(1)插入i；(2)打开0；(3)修改c；(4)取代r；(5)替换s

　　2.经(1)后进入全屏幕编辑模式。

　　3.命令模式-->编辑模式(a/i)；编辑模式-->命令模式(Esc)；命令模式-->末行模式(：)。

　　4.：w/w newfile保存

　　5.：q/q!退出iv；：wq保存退出

　　 八.网络服务

　　1.显示网络接口参数：ifconfig

　　2.显示系统邮件：mail

　　3.启动/终止web服务：httpd -k start|stop|restart

　　4.查看网络状况：(1)联机状况：ping xxx.xxx.xxx.xxx；

　　(2)显示网络状况：netstat ，其中：options：-a==所有sockets；-l==包含网络设备；-n==数字IP；

　　-o==其他信息；-r==路由表；-t==只列TCP sockets；-u==只列UDP sockets；-w==只列raw sockets；

　　-x==只列Unix Domain sockets

　　 九.其他类

　　1.显示显卡3D信息：glxinfo和glxgears

 

    今天突然领悟到了这个道理。做IT的，永远要关注在技术上，而不是特定产品上。从薪金的角度来说，精通技术的人永远比精通某一种产品的人要高薪的多。因为产品是用技术开发出来的，关注了技术就关注了本质。
    从测试来说，我认为对于自动化测试和性能测试这两个领域，就很好的体现了技术与产品的关系。做自动化测试，学习到的是自动化框架、脚本语言的编写，（当然也有自动化测试工具，比如基于录制/回放技术等，但那些属于低级层面，不在讨论范围）。而性能测试，关注的是在一个复杂应用环境中遇到了性能问题时，如何去解决它。而解决的结果，通常是调优一些产品参数，使之适合当前的环境。而这个过程，你学习到的是特定产品的调优技巧。虽然它也有一定的通用性，但实际上，无论从技术含量上、还是应用领域上都不高、不广泛。我这里说的可能有些片面，但我想强调的是，如果你是搞测试的，并且你有选择的权利，建议你去选择学习自动化测试方向，在其中着重学习一些脚本编写技术。比如Windows下的批处理脚本，unix/linux下的shell语言，还有一些广泛在web开发中使用到的ruby，python, perl, jython等等。对这些脚本的精通，会使你身价狂增，想像一下在一个团队中，只有你能写出天书似的脚本，并且能够高效的完成测试任务，这样的人不拿高薪等什么呢？而且从学习周期的角度来说，脚本语言的编写也比性能调优学的快的多。你可以在1-2个月内熟练掌握某一种脚本语言的语法并且制作出属于自己的脚本，而想要在性能测试中具有丰富经验，没有1-2年是不可能的。在这个浮躁的社会，谁都希望学到的东西能够尽快的得到回报，我想，学习脚本语言，让你的工作高效化，这种自身带来的满足感和工资提升上带来的实际认知度，能让你得到最大的成就感。
    今年，对我来说，我就要开始对于脚本语言的学习了。我希望我能在批处理脚本、shell语言上做到精通。它将给我未来测试职业生涯的发展带来非常大的好处，我坚信这一点。
    我做了3年测试，今天，终于在无人点拨的深夜明白了这个道理，可惜我付出了三年。好在我还年轻，我还有些时间，不能再浪费时间了，学些无用的产品特定的知识，那些对我没有太大意义。
    做测试当然也能拿高薪，但前提是你不要想绕开编程，IT领域的核心就是编程，只要你还搞技术，你想做到senior，你就不可能脱离编程（除非你做管理）。如果你厌倦了java庞大而复杂的编程技术，对它望而生畏的话，试着去学习一些小巧但不失强大的脚本语言，你会觉得耳目一新。你的职业发展道路会更顺畅。

1、老师推荐过的书籍

《人月神话》 、《人件》 、《与熊共舞》、《你在为谁工作》。

2、实习时，经理向我推荐的好书，确实不错

1)：入门好书：《软件测试入门》红皮的，主要是以实例介绍测试大纲，测试大纲到测试用例，面向对象测试，web测试等。同类的还有《软件测试》这本书。

2):《实用软件测试指南》，本书和上面一本书完全不同，似乎有一种信马由缰的感觉，不怎么建议什么大纲，而是偏向于意识方面，特别上每一个知识点、每一中软件攻击方法，都拿一些知名软件来说明，比如window，word等。

3)：《面向对象的软件测试》主要针对的是面向对象的单元测试---类测试，书中自始至终贯穿了一个例子：Brickle游戏的例子（和弹砖块游戏相似的一个游戏），全书从测试视角来看问题，详细讨论了从用例分析到设计模型如何从测试视角看问题，然后分析了具体的类测试以及类的交互测试，后面还有分层机构的测试和系统测试，都是拿例子来分析，比较直观，不象那些全篇都是理论的拗口的书，这本书还是比较好的，推荐大家都看一下!

4):《软件开发的科学与艺术》，是曾经在微软工作过的几个人合写的，主要是讲讲他们在微软的经历和经验。里面就有讲到微软的测试是怎么做的经验之谈，里面还有一些测试计划，测试规范的规划文档，可以参考一下!

5)：《软件测试技术》

6）：软件自动化测试工具的一些书籍，好像没有较专门的，这些可以看看它们的电子书籍，这方面很多!偏向于自动化理论方面的有一些好书：比如 《软件测试自动化》

7）：《软件测试求生法则》：作者积累数十年软件开发和测试经验，揭示出软件测试面临的几大人际挑战，包括获得软件培训、与开发人员保持良好关系、争取管理人员的支持、与客户保持交流、满足不断变化的需求以及如何学会说不，并且通过具体的案例讲述了解决这些挑战的策略性方法。

还有一些：　　

《软件测试方法与技术概论》
《软件测试方法与应用》
《Software Testing》 Sams RonPatton(美) [机械工程出版社]
《实用软件测试指南》 [清华大学出版社]
《软件测试经验与教训》
《软件测试驱动开发》
《计算机软件测试技术》
《自动化测试的引入，管理与实施》 Elfriede Dustin [清华大学出版社] 推荐e文原版
《有效软件测试》 Elfriede Dustin [清华大学出版社] 新语译
《软件测试》 Paul.C.Jorgensen CRC [机械工程出版社]
《软件测试自动化》 Paniel J.Moslsy [机械工程出版社] 邓波译 中文翻译的不错。

附：若英语功底好的人，可以看原版，尽量不要看翻译版，有时候很多翻译版容易将一些关键点翻得有点偏差。

摘自《测试新手学习宝典》

软件测试面试题

01. 为什么要在一个团队中开展软件测试工作？
　　因为没有经过测试的软件很难在发布之前知道该软件的质量，就好比ISO质量认证一样，测试同样也需要质量的保证，这个时候就需要在团队中开展软件测试的工作。在测试的过程发现软件中存在的问题，及时让开发人员得知并修改问题，在即将发布时，从测试报告中得出软件的质量情况。

02. 您在以往的测试工作中都曾经具体从事过哪些工作？其中最擅长哪部分工作？
　　我曾经做过web测试，后台测试，客户端软件，其中包括功能测试，性能测试，用户体验测试。最擅长的是功能测试

03. 您所熟悉的软件测试类型都有哪些？请试着分别比较这些不同04. 的测试类型的区别与联系（如功能测试、性能测试……）
　　测试类型有：功能测试，性能测试，界面测试。
　　功能测试在测试工作中占的比例最大，功能测试也叫黑盒测试。是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时，需要测试软件产品的功能，不需测试软件产品的内部结构和处理过程。采用黑盒技术设计测试用例的方法有：等价类划分、边界值分析、错误推测、因果图和综合策略。
　　性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。
　　界面测试，界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。
　　区别在于，功能测试关注产品的所有功能上，要考虑到每个细节功能，每个可能存在的功能问题。性能测试主要关注于产品整体的多用户并发下的稳定性和健壮性。界面测试更关注于用户体验上，用户使用该产品的时候是否易用，是否易懂，是否规范（快捷键之类的），是否美观（能否吸引用户的注意力），是否安全（尽量在前台避免用户无意输入无效的数据，当然考虑到体验性，不能太粗鲁的弹出警告）？做某个性能测试的时候，首先它可能是个功能点，首先要保证它的功能是没问题的，然后再考虑该功能点的性能测试

04．您认为做好测试用例设计工作的关键是什么？
白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果
黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试，以最少的用例在合理的时间内发现最多的问题

05.     请试着比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系。

　　黑盒测试：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。
　　白盒测试：已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否以经过检查。

　　软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。黑盒测试主要是为了发现以下几类错误：
　　1、是否有不正确或遗漏的功能？
　　2、在接口上，输入是否能正确的接受？能否输出正确的结果？
　　3、是否有数据结构错误或外部信息（例如数据文件）访问错误？
　　4、性能上是否能够满足要求？
　　5、是否有初始化或终止性错误？

　　软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。白盒测试主要是想对程序模块进行如下检查：
　　1、对程序模块的所有独立的执行路径至少测试一遍。
　　2、对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍。
　　3、在循环的边界和运行的界限内执行循环体。
　　4、测试内部数据结构的有效性，等等。

　　单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。

　　单元测试是由程序员自己来完成，最终受益的也是程序员自己。可以这么说，程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试。执行单元测试，就是为了证明这段代码的行为和我们期望的一致。

　　集成测试（也叫组装测试，联合测试）是单元测试的逻辑扩展。它的最简单的形式是：两个已经测试过的单元组合成一个组件，并且测试它们之间的接口。从这一层意义上讲，组件是指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合成程序的更大部分。方法是测试片段的组合，并最终扩展进程，将您的模块与其他组的模块一起测试。最后，将构成进程的所有模块一起测试。

　　系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。（常见的联调测试）

　　系统测试的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。

　　验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。
验收测试是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能如同用户所合理期待的那样。

06. 测试计划工作的目的是什么？测试计划工作的内容都包括什么？其中哪些是最重要的？
　　软件测试计划是指导测试过程的纲领性文件，包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。
测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。所以其中最重要的是测试测试策略和测试方法（最好是能先评审）

07. 您认为做好测试计划工作的关键是什么？
　　1. 明确测试的目标，增强测试计划的实用性
　　编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷，因此软件测试计划的价值取决于它对帮助管理测试项目，并且找出软件潜在的缺陷。因此，软件测试计划中的测试范围必须高度覆盖功能需求，测试方法必须切实可行，测试工具并且具有较高的实用性，便于使用，生成的测试结果直观、准确
　　2．坚持“5W”规则，明确内容与过程
　　“5W”规则指的是“What（做什么）”、“Why（为什么做）”、“When（何时做）”、“Where（在哪里）”、“How（如何做）”。利用“5W”规则创建软件测试计划，可以帮助测试团队理解测试的目的（Why），明确测试的范围和内容（What），确定测试的开始和结束日期（When），指出测试的方法和工具（How），给出测试文档和软件的存放位置（Where）。
　　3．采用评审和更新机制，保证测试计划满足实际需求
测试计划写作完成后，如果没有经过评审，直接发送给测试团队，测试计划内容的可能不准确或遗漏测试内容，或者软件需求变更引起测试范围的增减，而测试计划的内容没有及时更新，误导测试执行人员。
　　4. 分别创建测试计划与测试详细规格、测试用例
　　应把详细的测试技术指标包含到独立创建的测试详细规格文档，把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。

08. 您所熟悉的测试用例设计方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。
　　1．等价类划分
　　划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.

　　2．边界值分析法
　　边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.
　　使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.

3．错误推测法
　　基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.
　　错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.

4．因果图方法
　　前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）. 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.

09. 请以您以往的实际工作为例，10. 详细的描述一次测试用例设计的完整的过程。
　　就说最近的这次网站功能的测试吧
　　首先：得到相关文档（需求文档和设计文档），理解需求和设计设计思想后，想好测试策略（测试计划简单点就OK了），考虑到测试环境，测试用例，测试时间等问题。
　　第二步：设计测试用例，测试策略是：把网站部分的功能点测试完，然后在进行系统测试（另外个模块呢有另一个测试人员负责，可以进行联调测试），网站模块的测试基本是功能测试和界面测试（用户并发的可能性很小，所以不考虑）：这次的网站的输入数据呢是使用数据库中的某张表记录，如果表中某一数据记录中新加进来的（还没有被处理的，有个标志位），网站启动后会立刻去刷那张表，得到多条数据，然后在进行处理。处理过程中，会经历3个步骤，网站才算完成了它的任务。有3个步骤呢，就可以分别对　　这3个步骤进行测试用例的设计,尽量覆盖到各种输入情况（包括数据库中的数据，用户的输入等），得出了差不多50个用例。界面测试，也就是用户看的到的地方，包括发送的邮件和用户填写资料的页面展示。
　　第三步：搭建测试环境（为什么这个时候考虑测试环境呢？因为我对网站环境已经很熟了，只有有机器能空于下来做该功能测试就可以做了），因为网站本身的环境搭建和其他的系统有点不同，它需要的测试环境比较麻烦，需要web服务器（Apache,tomcat），不过这次需求呢，网站部分只用到了tomcat，所以只要有tomcat即可
　　第四步：执行测试

11. 您以往是否曾经从事过性能测试工作？如果有，12. 请尽可能的详细描述您以往的性能测试工作的完整过程。
　　是的，曾经做过网站方面的性能测试，虽然做的时间并不久（2个月吧），当时呢，是有位网站性能测试经验非常丰富的前辈带着我一起做。
性能测试类型包括负载测试，强度测试，容量测试等
　　负载测试：负载测试是一种性能测试指数据在超负荷环境中运行，程序是否能够承担。
　　强度测试： 强度测试是一种性能测试，他在系统资源特别低的情况下软件系统运行情况
　　容量测试：确定系统可处理同时在线的最大用户数  
　　在网站流量逐渐加大的情况下，开始考虑做性能测试了，首先要写好性能测试计划，根据运营数据得出流量最大的页面（如果是第一次的话，一般是首页，下载页，个人帐户页流量最大，而且以某种百分比），

　　Web服务器指标指标：
　　* Avg Rps: 平均每秒钟响应次数＝总请求时间 / 秒数；
　　* Successful Rounds：成功的请求；
　　* Failed Rounds ：失败的请求；
　　* Successful Hits ：成功的点击次数；
　　* Failed Hits ：失败的点击次数；
　　* Hits Per Second ：每秒点击次数；
　　* Successful Hits Per Second ：每秒成功的点击次数；
　　* Failed Hits Per Second ：每秒失败的点击次数；
　　* Attempted Connections ：尝试链接数；　　

13. 您在从事性能测试工作时，14. 是否使用过一些测试工具？如果有，15. 请试述该工具的工作原理，16. 并以一个具体的工作中的例子描述该工具是如何在实际工作中应用的。

17. 您认为性能测试工作的目的是什么？做好性能测试工作的关键是什么？

18. 在您以往的工作中，19. 一条软件缺陷（或者叫Bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（Bug）记录？

20. 您以往所从事的软件测试工作中，21. 是否使用了一些工具来进行软件缺陷（Bug）的管理？如果有，22. 请结合该工具描述软件缺陷（Bug）跟踪管理的流程。

23. 您认为在测试人员同24. 开发人员的沟通过程中，25. 如何提高沟通的效率和改善沟通的效果？维持测试人员同26. 开发团队中其他成员良好的人际关系的关键是什么？

27. 在您以往的测试工作中，28. 最让您感到不29. 满意或者不30. 堪回首的事情是什么？您是如何来对待这些事情的？

31. 在即将完成这次笔试前，32. 您是否愿意谈一些自己在以往的学习和工作中获得的工作经验和心得体会？（可以包括软件测试、过程改进、软件开发或者与此无关的其他方面）

33.        你对测试最大的兴趣在哪里？为什么？
　　最大的兴趣就是测试有难度，有挑战性！做测试越久越能感觉到做好测试有多难。曾经在无忧测试网上看到一篇文章，是关于如何做好一名测试工程师。一共罗列了11，12点，有部分是和人的性格有关，有部分需要后天的努力。但除了性格有关的1，2点我没有把握，其他点我都很有信心做好它。
　　刚开始进入测试行业时，对测试的认识是从无忧测试网上了解到的一些资料，当时是冲着做测试需要很多技能才能做的好，虽然入门容易，但做好很难，比开发更难，虽然当时我很想做开发（学校专业课我基本上不缺席，因为我喜欢我的专业），但看到测试比开发更难更有挑战性，想做好测试的意志就更坚定了。
　　不到一年半的测试工作中，当时的感动和热情没有减退一点（即使环境问题以及自身经验，技术的不足，做测试的你一定也能理解）。
　　我觉得做测试整个过程中有2点让我觉得很有难度（对我来说，有难度的东西我就非常感兴趣），第一是测试用例的设计，因为测试的精华就在测试用例的设计上了，要在版本出来之前，把用例写好，用什么测试方法写？（也就是测试计划或测试策略），如果你刚测试一个新任务时，你得花一定的时间去消化业务需求和技术基础，业务需求很好理解（多和产品经理和开发人员沟通就能达到目的），而技术基础可就没那么简单了，这需要你自觉的学习能力，比如说网站吧，最基本的技术知识你要知道网站内部是怎么运作的的，后台是怎么响应用户请求的？测试环境如何搭建？这些都需要最早的学好。至少在开始测试之前能做好基本的准备，可能会遇到什么难题？需求细节是不是没有确定好？这些问题都能在设计用例的时候发现。
　　第二是发现BUG的时候了，这应该是测试人员最基本的任务了，一般按测试用例开始测试就能发现大部分的bug，还有一部分bug需要测试的过程中更了解所测版本的情况获得更多信息，补充测试用例，测试出bug。还有如何发现bug？这就需要在测试用例有效的情况下，通过细心和耐心去发现bug了，每个用例都有可能发现bug，每个地方都有可能出错，所以测试过程中思维要清晰（测试过程数据流及结果都得看仔细了，bug都在里面发现的）。如何描述bug也很有讲究，bug在什么情况下会产生，如果条件变化一点点，就不会有这个bug，以哪些最少的操作步骤就能重现这个bug，这个bug产生的规律是什么？如果你够厉害的话，可以帮开发人员初步定位问题。

34. 你的测试职业发展是什么？
　　测试经验越多，测试能力越高。所以我的职业发展是需要时间累积的，一步步向着高级测试工程师奔去。而且我也有初步的职业规划，前3年累积测试经验，按如何做好测试工程师的11，12点要求自己，不断的更新自己改正自己，做好测试任务。

35. 你自认为测试的优势在哪里？
　　优势在于我对测试坚定不移的信心和热情，虽然经验还不够，但测试需要的基本技能我有信心在工作中得以发挥。

36. 你以前工作时的测试流程是什么？
　　公司对测试流程没有规定如何做，但每个测试人员都有自己的一套测试流程。我说下我1年来不断改正（自己总结，吸取同行的方法）后的流程吧。需求评审（有开发人员，产品经理，测试人员，项目经理）－>需求确定(出一份确定的需求文档)－>开发设计文档（开发人员在开始写代码前就能输出设计文档）－>想好测试策略，写出测试用例－>发给开发人员和测试经理看看（非正式的评审用例）－>接到测试版本－>执行测试用例（中间可能会补充用例）－>提交bug（有些bug需要开发人员的确定（严重级别的，或突然发现的在测试用例范围之外的，难以重现的），有些可以直接录制进TD）－>开发人员修改（可以在测试过程中快速的修改）－>回归测试（可能又会发现新问题，再按流程开始跑）。

37. 当开发人员说不38. 是BUG时，39. 你如何应付？
　　开发人员说不是bug，有2种情况，一是需求没有确定，所以我可以这么做，这个时候可以找来产品经理进行确认，需不需要改动，3方商量确定好后再看要不要改。二是这种情况不可能发生，所以不需要修改，这个时候，我可以先尽可能的说出是BUG的依据是什么？如果被用户发现或出了问题，会有什么不良结果？程序员可能会给你很多理由，你可以对他的解释进行反驳。如果还是不行，那我可以给这个问题提出来,跟开发经理和测试经理进行确认,如果要修改就改,如果不要修改就不改。其实有些真的不是bug，我也只是建议的方式写进TD中，如果开发人员不修改也没有大问题。如果确定是bug的话，一定要坚持自己的立场，让问题得到最后的确认。

23．你为什么想离开目前的职务？
　　因为公司运作情况并不理想，公司需要调整部门体系，公司考虑到缩减部门人员，所以大批量的裁员（有6，7个），这是我的第一份工作，对公司也有较深的感情，因为在这里我找到了职业理想（就是测试），所以公司需要精简人员，我自愿退出。虽然很舍不得，但我将会有新的发挥能力的舞台。

24：你对我们公司了解有多少？

25：你找工作时，最重要的考虑因素为何？
　　工作的性质和内容是否能让我发挥所长，并不断成长。

26：为什么我们应该录取你？
　　您可以由我过去的工作表现所呈现的客观数据，明显地看出我全力以赴的工作态度。

27：请谈谈你个人的最大特色。
　　我的坚持度很高，事情没有做到一个令人满意的结果，绝不罢手。

28.白箱测试和黑箱测试是什么?什么是回归测试?

29。单元测试、集成测试、系统测试的侧重点是什么？

30。设计用例的方法、依据有那些？

31。一个测试工程师应具备那些素质和技能？

32.集成测试通常都有那些策略？

33.你用过的测试工具的主要功能、性能及其他？

34.一个缺陷测试报告的组成

35.基于WEB信息管理系统测试时应考虑的因素有哪些？

36.软件测试项目从什么时候开始，？为什么？

37.需求测试注意事项有哪些？

38.简述一下缺陷的生命周期

39.测试分析测试用例注意（事项）？
　　你在你所在的公司是怎么开展测试工作的？是如何组织的？
　　你认为理想的测试流程是什么样子？
　　你是怎样工作的？
　　软件测试活动的生命周期是什么？
　　请画出软件测试活动的流程图？
　　针对缺陷采取怎样管理措施？
　　什么是测试评估？测试评估的范围是什么？
　　如果能够执行完美的黑盒测试，还需要进行白盒测试吗？为什么？
　　测试结束的标准是什么？
　　软件验收测试除了alpha,beta测试以外,还有哪一种?
　　做测试多久了？
　　以前做过哪些项目？
　　你们以前测试的流程是怎样的？
　　<答：测试计划－测试用例设计－测试执行－测试分析报告>
　　用过哪些测试工具？
　　为什么选择测试这行？
　　<答：它是一个新兴的行业，有发展潜力，而且很锻炼人，需要掌握更多的技能，比做开发要更难>
　　为什么值得他们公司雇用？
　　如果我雇用你，你能给部门带来什么贡献？
　　如何从工作中看出你是个自动自觉的人
　　你的工作通常能在时限内完成吗.（我想问一下就是她问这个问题的动机是什么）
　　通常你对于别人批评你会有什么样的反应
　　如果明知这样做不对，你还会依主管的指过去做吗
　　如果你接到一个客户抱怨的电话，你确知无法解决他的问题，你会怎么处理
　　你觉得什么样的人最难相处
　　为什么值得他们公司雇用？
　　　　帮助公司提高软件质量和测试部门的技术水平
　　如果我雇用你，你能给部门带来什么贡献？
　　　　分享我的测试经验和测试技能，提高测试部门技术水平
　　如何从工作中看出你是个自动自觉的人
　　　        自动自觉范围太广
　       1. 工作成果
       　2. 工作质量 
　　你的工作通常能在时限内完成吗.（我想问一下就是她问这个问题的动机是什么）
　　　　在有足够的资源和合理的工作量的情况下，完全可以按时完成，并能比一般人做的更好
　　通常你对于别人批评你会有什么样的反应
　　　　有错即改，无措勉之

　　如果明知这样做不对，你还会依主管的指过去做吗
　　　　在公司内部下级是否有申诉渠道？

　　如果你接到一个客户抱怨的电话，你确知无法解决他的问题，你会怎么处理
　　　　为什么抱怨？是怎么样的问题？
　　　　如果是客服问题，提交客服部门解决
　　　　如果是质量问题，分析原因，下一版本改进
　　你觉得什么样的人最难相处
　　　　自以为是的人

　　什么叫单元测试？
　　　　请就软件测试人员应该具备什么样的基本素质说说你的看法。

　　请就如何在开发中进行软件质量控制说说你的看法
　　 简述软件测试的意义，以及软件测试的分类

1、功能测试，性能测试，界面测试，安全测试（可以简单点，比如只涉及到COOKIES里的内容），压力测试（商业性质的网站） 等等，B/S软件也要根据其具体功能采用不同的测试策略。
2、态度、责任心、自信、敏锐的观察力、良好的发散思维
3、先设计后开发模式，加强单元测试，加强代码走查，有一套完整的白盒测试方法。关键是加强开发人员的质量意识，增进程序员向工程师水平发展。
4、意义嘛，就自己想吧。软件测试的分类，这个很多人都按各种方法去分。无明确答案给你。

对测试的理解——基本的测试知识，对测试是否认可？ 75。
      3、谈一谈过去自己的工作——了解经历、提供进一步提问的素材，表达能力  
测试技能
测试设计的方法并举例说明——测试技术的使用
测试工具——熟悉程度，能否与当前工作匹配？
如何做计划？如何跟踪计划？——日常工作能力
如果开发人员提供的版本不满足测试的条件，如何做？——与开发人员协作的能力
熟悉unix系统、oracle数据库吗？——是否具备系统知识
做过开发吗？写过哪些代码？——开发技能
阅读英语文章，给出理解说明？——部分英语能力
文档的意义——是否善于思考？（最简单的概念，不同层次的理解）
假如进入我们公司，对我们哪些方面会有帮助？——讲讲自己的特长
随便找一件物品，让其测试——测试的实际操作能力
软件测试的方法有？
软件测试的过程？
有一个新的软件，假如你是测试工程师，该如何做？

软件测试分哪两种方法？分别适合什么情况？
2。一套完整的测试应该由哪些阶段组成？分别阐述一下各个阶段。
3。软件测试的类型有那些？分别比较这些不同的测试类型的区别与联系。
4。测试用例通常包括那些内容？着重阐述编制测试用例的具体做法
5。在分别测试winform的C/S结构与测试WEB结构的软件是，应该采取什么样的方法分别测试？他们存在什么样的区别与联系？
6。在测试winform的C/S结构软件时，发现这个软件的运行速度很慢，您会认为是什么原因？您会采取哪些方法去检查这个原因？
7。描述使用bugzilla缺陷管理工具对软件缺陷（BUG）跟踪的管理的流程
你在五年内的个人目标和职业目标分别是什么？
　　分析这个问题是用来了解你的计划能力的，通过这个问题，面试人同时还可以知道你的目标是否符合企业对你的安排。
　　错误回答我想在将来的某个时候考虑这个问题。如今企业的领导者更换频繁，我认为做太多的个人计划是荒谬可笑的，不是吗？
　　评论这种回答属于令人反感的一类。首先，当有人想了解你的目标时，"将来的某个时候"这种通俗说法并不奏效。其次，认为企业很脆弱，领导者更换频繁，这种说法毫无疑问会令人反感，而且也是不合理的。最后，认为做计划可笑，看不起这个问题，而且反问面试人，这些都注定了这样的求职者最终会失败。
　　正确回答从现在起的五年之内，我希望能够在一个很好的职位上待几年，而且最好有一次晋升，然后就期待着下一步。不管是向上提升，还是在企业内横向调动，对我个人来说，我希望找到一家企业——一家愿意做相互投入的企业——待上一段时间。
　　评论这个问题没有回答得过分具体（那样可能会产生漏洞），而且它表明你有雄心，并且思考过在企业中的成长方式。通过表达横向调动和向上提升的愿望，表明你是一个有灵活性的人。
　问题23　你怎样做出自己的职业选择？
　　分析 面试人提出这个问题是为了了解求职者的动机，看看他（她）应聘这份工作是否有什么历史渊源，是否有职业规划，是不是仅仅在漫无目的地申请很多工作。
　　错误回答 我一直都想在企业界工作。自孩提时代起，我就梦想自己至少也要成为大企业的副总裁。
　　评论 除了难以令人相信之外，这种回答还存在一个问题：它表明求职者会对副总裁以下的职位不感兴趣。
　　正确回答 在上大学四年级前的那个夏天，我决定集中精力在某一领域谋求发展。尽管我是学商业的，但是我不知道自己最终会从事哪一行业的工作。我花了一定的时间考虑自己的目标，想清楚了自己擅长做的事情以及想从工作中得到的东西，最后我得出了一个坚定的结论，那就是这个行业是最适合我的。
　　评论 这种回答表明，求职者认真地做过一些计划，缩小了自己的关注点，而且也认准了前进的方向。这种回答还表明，求职者理解个人职业规划的重要性，并且有能力做出认真的个人决策。
1. 你都用什么测试方法
2.怎么编写案例
3.怎么才能够全面的测试到每一个点
1. 你都用什么测试方法
针对不同的产品或者系统或者模块，有不同的测试方法。总体而言有白盒测试和黑盒测试。
2.怎么编写案例
案例的编写与测试阶段的定义有很大的关系。系统测试和unit测试的案例可能不同。总体而言测试案例根据系统的需求而定。
3.怎么才能够全面的测试到每一个点
测试的全面性主要需要在设计测试计划的时候考虑，从测试策略，产品需求等等多个角度考虑从而定义全部的测试点。
1、谈谈软件测试技术，以及如何提高
2、谈谈软件测试职业发展，以及个人的打算
3、谈谈软件测试在企业的地位，也可以结合软件生命周期来谈
有可能清晰的思路比确切的答案更重要
在这里，主要说下笔试和面试的问题，希望大家共同参考。
       1，一般公司里实际的软件测试流程是什么样的？你们公司又是怎样的？
       2，软件工程师要具有那些素质？
       3，你会哪些测试工具？怎么操作？
       4，你能不能说下你的3到5年的职业计划（规划）
       5，你觉得你来应聘有那些优势？
其余的还好说，但就第4个问题，我感到不好说哦！希望大家给个意见
第一关：首先要自我介绍，自己的性格怎么样，目前的工作经历积累了一些什么经验取得了些什么值得一说的成果。然后要说说对软件测试怎么看？还有对于软件测试有什么自己的想法。为什么会想到要做这行（因为我的简历上的工作经历没有关于测试方面的）。哦，还有期望薪资。
第二关：认为软件测试人员所要具备的基本素质，如果遇到问题会怎样处理，如果得不到研发人员的配合（就是研发说这个不是问题）你又会怎么处理？然后就是一些基本概念，比如软件测试的流程有哪些？如果我上任了，首先会怎么开始自己的工作计划。
（前两关通过了后面这个就好过多了）
第三关：像我介绍了一下公司的情况，告诉我主要针对什么内容的测试，会不会使用数据库。告诉我大概要做哪些内容，详细的可以上岗以后慢慢熟悉。
大概就这么多了，这对没有经过这一关的不知道有没有帮助，仅供参考吧
我觉得就像李波说的，关键是要给对方留下好印象:)

面试官最后会问你有什么问题要问吗。作为应聘者的你一般不要说没问题问，这会给面试官留下你不太重视这份工作的坏印象。所以如果你想得到这份工作的话应该抓住这最后的表现自己的机会：
你可以问：
1.           贵公司近期和远期的发展目标是什么？
2.           贵公司的主要竞争对手有哪些？
3.           贵公司有多少开发人员有多少测试人员？
4.           贵公司又进一步扩充测试人员的计划吗?
5.           如果我有幸能进入贵公司的话，我有怎么样的发展？
6.           测试人员的沟通能力很重要，贵公司有规范的沟通渠道吗？
7.           请介绍一下贵公司的福利情况。
8.           请问我什么时候能知道结果？

1、阅读需求文档，深入了解系统，磨刀不误砍柴工，不要还没弄清需求就开测了，（一个星期前，公司刚进一个新人，TD上查看了下他们发的BUG，发现好几个是需求不明确误发的）心想：原来是这个系统啊，项目实训的时候做过和这个类似的项目，于是就把实训的系统需求硬生生的搬到当前系统来，这样做的风险太大，因为每个系统的需求都不一样，不能生搬硬套，打个比方：假设要你制造一辆轿车，你以前制造过普桑，就把你制造普桑的技术拿去制造林肯，这样做显然不合适。熟悉系统（一般公司都会有系统熟悉情况考核）所以请一定要认真的阅读需求文档（有的公司叫产品定义）

2、熟悉测试用例，这是测试执行的一个导向，要想快速高效率的执行用例，必须在熟悉系统的同时，熟悉用例，熟悉每条用例覆盖的需求，这样执行起来才能事半功倍

3、一旦发现缺陷，应立刻提交。有几种情况：测试就像是一场优胜劣汰的战斗，你的动作慢了，成果就是别人的了。作为一个测试新人来讲，测试的第一步，可能是从执行用例开始，而成功的用例（项目刚开始时）可以发现很多系统中存在的问题，同一条case里的不同STEP就可能发现多个BUG，那么对于这样的情况，我们要做的是：发现就提交，不要等到所有STEP都执行完再提交。那样说不定已经被别人提交了。
特别说明：1）速度和效率同时考虑，尽量别发错BUG；2）公平竞争，还要考虑团队合作，在别人的测试模块发现BUG，建议告知对方提，与同事交流的时候，同事讲到的缺陷，而缺陷管理工具中没提，应该让对方提交上去
4、新版本发布：
       1）验证FIXED缺陷，如果验证通过了，把状态改为CLOSED（关闭的时候一定要加个备注，（比如：某月某日某版本验证通过。）对于开发修改了，但是与需求有出入的，且与测试经理确认可以这样修改时，备注建议这样写：某月某日某版本验证通过，修改为……），如果没通过改为OPEN（同样加个备注：某月某日某版本验证未通过），这里存在一个误区，有的人会把状态改为REOPEN，如果是公司要求的，那无可厚非，如果没有要求，建议改为OPEN，因为REOPEN是已经确认修改并且该BUG已经改为CLOSED状态后，才需要修改为REOPEN状态的。（有很多公司是不允许出现REOPEN状态的（针对开发），一旦出现，开发此模块的程序员绩效可能会被大打折扣，我现在所在的公司就是这样的）
       2）冒下烟确保主流程畅通，然后再进行功能测试，着重测试有修改的或者与所修改模块有调用关系的模块和发现BUG比较多的模块（公司发布版本会邮件通知修改的模块与修复的BUG），未改动的模块建议做个流程测试。特别说明：主流程走不通，应立刻MSN给项目负责人（组长或经理，如果有本项目MSN群，直接在群里讲就可以了）
5、如果版本未更新，
       1)建议着重进行业务逻辑方面测试，在电脑上以文档形式画出简单的业务逻辑图片，重点说明：一定 要尽量考虑所有的情  况，因为这样的BUG要么就没有，一旦有就是HIGH
       2)建议进行环境测试（当然要根据需求测试相应的环境）
       3)严格核对需求文档，防止需求遗漏

6、严格按照缺陷提交说明提交BUG，因为这有可能涉及BUG的统计问题，（一般公司的缺陷描述：系统名称_功能模块，缺陷描述，要具体问题具体对待）。优先级和严重程度不要夸大也不要降低，实事求是，因为这与开发和测试的绩效考评有挂钩，要是夸大缺陷，会影响开发的绩效考评，降低会影响自己的绩效考评，建议：系统级（影响流程）和跳黄页（报服务器错误的，这类缺陷有的是服务器配置错误导致）建议为高，功能实现建议为中，界面易用，或者不影响系统使用的其他问题建议为低，具体级别公司会有规定，如果没有规定，可以参考一下我的建议

7、测试没有空闲。项目在不同阶段，会有些时间很‘空闲’。建议：
       1）把测试管理工具中的缺陷全部分类导出，总结一下哪些模块容易产生哪些缺陷，重点看一下自己没发现或没有考虑到的缺陷，有多余时间可以看一下CLOSED_NBUG的缺陷，这类BUG一般都是需求不明确，需求变更而产生的，看一下这类缺陷，可以总结一下哪些需求容易产生误解，和出现了哪些新需求。
       2）把测试管理工具中的用例细细看几遍，学习别人的用例编写方法和思想，空闲时间可以自己试着编写，看自己编写的与别人编写的用例差距在哪，从而不断完善
       3）进入一些测试论坛，比如51testing，把自己的困惑和经验和大家一起分享，共同学习，共同进步！

 转自：http://www.51testing.com/?236994/action_viewspace_itemid_101535.html#xspace-itemform

做测试三年,你能拿到7000吗?

 

   新的一年到了，最近一直思考一个问题，在新的一年自己在软件测试职业发上有什么新的打算和计划呢？

   08年12月刚换了一份工作，待遇很不错的。我想能找到这样的工作肯定和自己平时的工作经验积累也有一定的关系的。我在数据库、中间件、操作系统、开发技能上都是做的很不错的，想找一份像样的工作还是很容易的。那么在新的一年，如何计划呢，若想让自己的薪水破万？

   我认为一个想拿高薪水的测试工程师，应该具体下列素质，也是我在新的一年里愿意去继续提高的地方：

 

1、测试技术测试理论

  作为一个测试人员，掌握基本的测试技术理论是必须的吧。看看测试理论的书，你也许一直在看，再去翻翻吧，常品常新。工作这么多年了，都快成专家了，不但要掌握精通测试技术理论，偶尔也要写写文章，分享一下心得，指导指导新人。

2、测试环境部署能力

  对项目组上可能用到的数据库、中间件及应用服务器、操作系统平台（一般是Unix Linux系统）的常用的、基本的操作必须要懂的。对DB2、Oracle、MSSQL Server、Informix等数据库，WebLogic、WebSphere、Jboss等中间件及应用服务器，Solaris、AIX、RedHat

等OS系统的安装配置部署要掌握，没必要掌握这么多产品，每种产品要掌握一种吧，比如DB2+WebSphere+AIX。如果以后想做好性能测试，这些产品的性能优化、性能监控也要掌握的。

3、开发技能、脚本编程能力

   大公司的笔试题一般会考到开发知识，Java、C语言的基本开发知识要掌握。作为一个测试人员，在工作中会常常用到shell、bat、jython 等脚本语言 ，特别是做自动化测试的时候。对这些脚本语言最好掌握一到两门。用好这些脚本会让你的工作更加轻松的。

4、设计模式、架构知识、单元测试模式学习

   软件架构师的头衔很耀眼吧？作为测试工程师，你又是无可救药的技术派，多学习一下软件设计架构的知识吧，你也许会成为一位测试架构师呢。想成为这样的人，三五年的开发设计经验、三五年的测试经验是很重要的。  

对于开发编码人员，编写程序代码是最天经地义的事情了，为了后期的可维护和可扩展，得到更简洁的减少重复的代码，重构，改善既有代码设计的重构是开发编码人员的另一项工作内容。重构的方向是设计模式，基于原来开发代码、重构代码的经验，直接选用合适的设计模式进行开发，能快速有效得到优美的代码。那么对于执行单元测试(白盒测试)的测试人员，他们为开发人员维护的程序代码编写单元测试代码，基于同样的原因，单元测试人员是否也应该考虑引入重构的概念，建立一套单元测试模式呢？对于使用特定设计模式开发的程序代码，也一定有相应的单元测试模式更有效率的保障程序代码的质量。

 

5、重视职业规划、认识一位HR

  有时候你能做到什么程度，在于你想没想做到那样的程度，职业规划是必要的！如果安全按照职业规划发展，人生是很枯燥无味的，我们可能随时会对职业发展方向进行调整，可是如果没有职业规划，我们基于什么进行调整呢？

  认识一位HR吧，他们的专业技能，他们掌握的资源是你需要的。  我的一位朋友在做这个，我们常交流职业发展的问题，感觉她说的不错。如果你对职业发展感到困惑，对现在的待遇不满意,还想来北京发展？你可以和HR聊聊测试职业规划。

 

    方法＋坚持＋机遇＝成功。

    一个好的计划是成功的一半。如何做一个行之有效的自学测试的方法，并坚持下去，是我这几日苦思冥想后想要立即付诸执行的计划之一。

    学习需要克服的障碍：几乎未写过代码；C语言在10年前自学过；数据库只对SQL有所熟悉；测试经验只鉴于手工简单测试，少之甚少。。。。。。

    学习时间：每天抽出4个小时学习软件测试。

    学习内容：

    第一阶段，继续翻开C语言书籍，回顾C语言，其实就等于重新学习。熟悉数据库ORACLE等。熟悉软件测试的一些基础概念及内容，书籍《测试新手学习宝典》、郑人杰《计算机软件技术》（鉴于以前在做项目管理期间，一直在读这本书，继续看完它）。

    第二阶段：熟悉各类测试工具的使用。（鉴于本人对工具的了解和掌握应该算比较容易）

    第三阶段：尝试编写测试小工具，为白盒测试做准备。  

    第四阶段：测试相关文档的编制等。这一工作偶以前都做过，对于文档的编写流程和规范、格式比较熟悉，这一阶段主要是将学习的内容融入到文档的编写过程中，这对于今后若有可能参与软件测试工作提供了标准化、专业化的基础。

    预期完成时间：2个月。

    难度颇大！希望各位过来的前辈们给予指正和提出建议，并能提出不足之处和其它需要克服的困难，小女子不胜感激。

    自勉之：鉴于平时还有其它学习计划，譬如英语翻译资格证考级，信息分析学习，为此，学习任务任重而道远，真的不想半途而废，顶住压力，勇往直前，路慢慢其修远兮，吾将上下而求索。

    加油ing！先喝杯咖啡，休息一下！然后投入战斗。  

    1.不要看到别人的回复第一句话就说：给个代码吧！你应该想想为什么。当你自己想出来再参考别人的提示，你就知道自己和别人思路的差异。

　　 2.初学者请不要看太多太多的书那会误人子弟的，先找本系统的学，很多人用了很久都是只对部分功能熟悉而已，不系统还是不够的。

　　 3.看帮助,不要因为很难而自己是初学者所以就不看；帮助永远是最好的参考手册，虽然帮助的文字有时候很难看懂，总觉得不够直观。

　　 4.不要被对象、属性、方法等词汇所迷惑；最根本的是先了解最基础知识。

　　 5.不要放过任何一个看上去很简单的小问题--他们往往并不那么简单，或者可以引伸出很多知识点；不会举一反三你就永远学不会。

　　 6.知道一点东西，并不能说明你会写脚本，脚本是需要经验积累的。

　　 7.学脚本并不难，JSP、ASP、PHP等等也不过如此--难的是长期坚持实践和不遗余力的博览群书。

　　 8.看再多的书是学不全脚本的，要多实践。

　　 9.把时髦的技术挂在嘴边，还不如把过时的技术记在心里。

　　 10.学习脚本最好的方法之一就是多练习。

　　 11.在任何时刻都不要认为自己手中的书已经足够了。

　　 12.看得懂的书，请仔细看；看不懂的书，请硬着头皮看。

　　 13.别指望看第一遍书就能记住和掌握什么——请看第二遍、第三遍；

　　 14.请把书上的例子亲手到电脑上实践，即使配套光盘中有源文件；

　　 15.把在书中看到的有意义的例子扩充；并将其切实的运用到自己的工作中。

　　 16.不要漏掉书中任何一个练习——请全部做完并记录下思路；

    17.当你用脚本到一半却发现自己用的方法很拙劣时，请不要马上停手；请尽快将余下的部分粗略的完成以保证这个代码的完整性，然后分析自己的错误并重新编写和工作。

　　 18.别心急，写脚本确实不容易；水平是在不断的实践中完善和发展的；

　　 19.每学到一个脚本难点的时候，尝试着对别人讲解这个知识点并让他理解----你能讲清楚才说明你真的理解了。

　　 20.记录下在和别人交流时发现的自己忽视或不理解的知识点。

　　 21.保存好你做过的所有的源文件----那是你最好的积累之一。

　　 22.对于网络，还是希望大家能多利用一下，很多问题不是非要到论坛来问的，首先你要学会自己找答案，比如google、百度都是很好的搜索引擎，你只要输入关键字就能找到很多相关资料，别老是等待别人给你希望，看的出你平时一定也很懒！

　　 23.到一个论坛，你学会去看以前的帖子，不要什么都不看就发帖子问，也许你的问题早就有人问过了，你再问，别人已经不想再重复了，做为初学者，谁也不希望自己的帖子没人回的。

　　 24，虽然不是打击初学者，但是这句话还是要说：论坛论坛，就是大家讨论的地方，如果你总期望有高手总无偿指点你，除非他是你亲戚！！讨论者，起码是水平相当的才有讨论的说法，如果水平真差距太远了，连基本操作都需要别人给解答，谁还跟你讨论呢。
　　25、不要因为工作简单就不重视，简单的工作做好了能体现个人的态度，简单的工作做好之后才能够有效管理作简单工作的人。

　　26、少发牢骚，多提建设性意见，前者说不定哪天会被领导听见，也影响自己的心情；后者可能会得到领导重视，说不定哪天机会就来了，再说以解决问题的思路来看待问题，不断的思考就会不断进步，也有利于良好心态的形成

　　27、做好自己能够掌控的事情，对于自己无法影响的东西，少想、少说

　　28、吃亏就是占便宜

　　29、不要追求绝对公平，否则是自寻烦恼

　　 浮躁的人容易问：我到底该学什么；----别问，学就对了；

　　 浮躁的人容易问：Js有钱途吗；----建议你去抢银行；

　　 浮躁的人容易说：我要中文版！我英文不行！----不行？学呀！

　 　浮躁的人经常说：啊呀，今天放松一下，从明天开始我一定认真学!

　　 浮躁的人分两种：只观望而不学的人；只学而不坚持的人；

　　 浮躁的人永远不是一个高手。

摘自：《测试新手学习宝典》

由于国内软件测试行业目前的发展迅速、需求旺盛，在国内的软件测试职位晋升一般要比国外快，但因行业本身太年轻，大家对软件测试中软件测试职业的发展了解不够，从而导致许多有志在此发展的年轻人举步不前。所以下面介绍一下海外公司成熟的软件测试行业职位分布情况，我国一些在软件测试行业中处于前端的公司与之也相仿，这可以作为软件测试职业规划的参考，给新人一个导向。

第一阶段：(测试员)初级测试工程师
自身条件：初入行具备计算机专业学位或一些手工测试经验的个人。
具体工作：执行测试用例，记录bug，并回归测试，通过qtp等测试工具录制回归测试脚本，并执行回归测试脚本。
学习方向：开发测试脚本并且开始熟悉测试生存周期和测试技术。

第二阶段：(测试工程师)程序分析员
自身条件：有1~2年工作经验的测试工程师或程序员。具有初步的自动化测试能力，完善自动化测试脚本。
具体工作：设计和编写测试用例，编写自动测试脚本程序且担任测试编程初期的领导工作。
学习方向：拓展编程语言、操作系统、网络与数据库方面的技能 。

第三阶段：(高级测试工程师)程序分析员
自身条件：有3~4年经验的测试工程师或程序员。具有一定的行业业务知识，储备系统分析员的能力。
具体工作：帮助开发或维护测试或编程标准与过程，分析软件需求，获得测试需求。确定测试需求相应的测试方法，获得测试策略方案。参与同行的评审（软件需求，软件测试计划等），并为其它初级的测试工程师或程序员充当顾问。
学习方向:继续拓展编程语言、操作系统、网络与数据库方面的技能。

第四阶段：测试组负责人
自身条件：有4~6年经验的测试工程师或程序员。具有丰富的行业业务知识，具有系统分析员的能力，专长性能测试。
具体工作：负责管理1~3名测试工程师或程序员。集中于技能方面，担负一些进度安排和工作规模/成本估算职责。分析性能瓶颈的原因，为开发团队提供bug解决策略。
学习方向：性能测试，测试技能

第五阶段：（资深安全或性能测试工程师）测试/编程高级负责人
自身条件：有6~10年经验的测试工程师或程序员。
具体工作：负责管理8~10名技术人员。性能测试整体方案设计，软件系统性能问题定位和性能优化，内存优化及分析数据溢出等，分析系统的安全漏洞等。 负责进度安排、工作规模/成本估算、按进度表和预算目标交付产品。负责开发项目的技术方法。为一些用户提供支持与演示。
学习方向：开发一些特定领域的技术专长

第六阶段：测试/质量保证/开发（项目）、经理
自身条件：有10多年的工作经验。
具体工作：管理8名或更多的人员参加的1个或多个项目。负责这一领域（测试/质量保证/开发）内的整个开发生存周期业务。为一些用户提供交互和大量演示。负责项目成本、进度安排、计划和人员分工

第七阶段：（公司级质量总监）计划经理
自身条件：有15年以上开发与支持（测试/质量保证）活动方面的经验。
具体工作：管理从事若干项目的人员以及整个开发生存周期。负责把握项目方向与盈亏责任。

    转载  ：本文出自卧龙公子的51Testing软件测试博客：http://www.51testing.com/?161964

　　别小看了这个用户名密码这么简单的输入框。可测试的内容还是很多的，并且引发的问题也有很多种类。下面就说一说他的测试方法。

　　一．用户注册

　　只从用户名和密码角度写了几个要考虑的测试点，如果需求中明确规定了安全问题，Email，出生日期，地址，性别等等一系列的格式和字符要求，那就都要写用例测了~

　　以等价类划分和边界值法来分析

　　1.填写符合要求的数据注册: 用户名字和密码都为最大长度（边界值分析，取上点）

　　2.填写符合要求的数据注册 :用户名字和密码都为最小长度（边界值分析，取上点）

　　3.填写符合要求的数据注册:用户名字和密码都是非最大和最小长度的数据（边界值分析，取内点）

　　4.必填项分别为空注册 

　　5.用户名长度大于要求注册1位（边界值分析，取离点）

　　6.用户名长度小于要求注册1位（边界值分析，取离点）

　　7.密码长度大于要求注册1位（边界值分析，取离点）

　　8.密码长度小于要求注册1位（边界值分析，取离点）

　　9.用户名是不符合要求的字符注册（这个可以划分几个无效的等价类，一般写一两个就行了,如含有空格，#等，看需求是否允许吧~）

　　10.密码是不符合要求的字符注册（这个可以划分几个无效的等价类，一般写一两个就行了）

　　11.两次输入密码不一致(如果注册时候要输入两次密码，那么这个是必须的）

　　12.重新注册存在的用户

　　13.改变存在的用户的用户名和密码的大小写，来注册。（有的需求是区分大小写，有的不区分）

　　14.看是否支持tap和enter键等；密码是否可以复制粘贴；密码是否以* 之类的加秘符号显示

　　备注：边界值的上点、内点和离点大家应该都知道吧，呵呵，这里我就不细说了~~

　　二．修改密码

　　当然具体情况具体分析哈~不能一概而论~

　　实际测试中可能只用到其中几条而已，比如银行卡密码的修改，就不用考虑英文和非法字符，更不用考虑那些ＴＡＰ之类的快捷键．而有的需要根据需求具体分析了,比如连续出错多少次出现的提示，和一些软件修改密码要求一定时间内有一定的修改次数限制等等。

　　1.不输入旧密码，直接改密码

　　2.输入错误旧密码

　　3.不输入确认新密码

　　4.不输入新密码

　　5.新密码和确认新密码不一致

　　6.新密码中有空格

　　7.新密码为空

　　8.新密码为符合要求的最多字符

　　9.新密码为符合要求的最少字符

　　10.新密码为符合要求的非最多和最少字符

　　11.新密码为最多字符-1

　　12.新密码为最少字符+1

　　13.新密码为最多字符+1

　　14.新密码为最少字符-1

　　15.新密码为非允许字符（如有的密码要求必须是英文和数字组成，那么要试汉字和符号等）

　　16.看是否支持tap和enter键等；密码是否可以复制粘贴；密码是否以* 之类的加秘符号

　　17.看密码是否区分大小写，新密码中英文小写，确认密码中英文大写

　　18.新密码与旧密码一样能否修改成功

　　另外一些其他的想法如下：

　　1 要测试所有规约中约定可以输入的特殊字符，字母，和数字，要求都可以正常输入、显示正常和添加成功

　　2 关注规约中的各种限制，比如长度，大否支持大小写。

　　3 考虑各种特殊情况，比如添加同名用户，系统是否正确校验给出提示信息，管理员帐户是否可以删除，因为有些系统管理员拥有最大权限，一旦删除管理员帐户，就不能在前台添加，这给最终用户会带来很多麻烦。比较特殊的是，当用户名中包括了特殊字符，那么对这类用户名的添加同名，修改，删除，系统是否能够正确实现，我就遇到了一个系统，添加同名用户时，如果以前的用户名没有特殊字符，系统可以给出提示信息，如果以前的用户名包含特殊字符，就不校验在插入数据库的时候报错。后来查到原因了，原来是在java中拼SQL语句的时候，因为有"_"，所以就调用了一个方法在“_“，前面加了一个转义字符，后来发现不该调用这个方法。所以去掉就好了。所以对待输入框中的特殊字符要多关注。

　　4 数值上的长度 之类的，包括出错信息是否合理

　　5 特殊字符：比如. / ' " \ </html> 这些是否会造成系统崩溃

　　6 注入式bug：比如密码输入个or 1=1

　　7 登录后是否会用明文传递参数

　　8 访问控制（不知道这个算不算）：登录后保存里面的链接，关了浏览器直接复制链接看能不能访问

客户端兼容性测试 
  1、平台测试 
  市场上有很多不同的操作系统类型，最常见的有Windows、Unix、Macintosh、Linux等。Web应用系统

的最终用户究竟使用哪一种操作系统，取决于用户系统的配置。这样，就可能会发生兼容性问题，同一

个应用可能在某些操作系统下能正常运行，但在另外的操作系统下可能会运行失败。 
  因此，在Web系统发布之前，需要在各种操作系统下对Web系统进行兼容性测试。 
  2、浏览器测试 
  浏览器是Web客户端最核心的构件，来自不同厂商的浏览器对Java，、Javascrīpt、ActiveX、 plug

-ins或不同的HTML规格有不同的支持。例如，ActiveX是Microsoft的产品，是为Internet Explorer而设

计的，Javascrīpt是Netscape的产品，Java是Sun的产品等等。另外，框架和层次结构风格在不同的浏览

器中也有不同的显示，甚至根本不显示。不同的浏览器对安全性和Java的设置也不一样。 
  测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中，测试不同厂商、不同版本的浏

览器对某些构件和设置的适应性。 
  五、安全性测试 
  Web应用系统的安全性测试区域主要有： 
  （1）现在的Web应用系统基本采用先注册，后登陆的方式。因此，必须测试有效和无效的用户名和密

码，要注意到是否大小写敏感，可以试多少次的限制，是否可以不登陆而直接浏览某个页面等。 
  （2）Web应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内（例如15分钟）没有点击

任何页面，*是否需要重新登陆才能正常使

用。 
  （3）为了保证Web应用系统的安全性，日志文件是至关重要的。需要测试相关信息是否写进了日志文

件、是否可追踪。 
  （4）当使用了安全套接字时，还要测试加密是否正确，检查信息的完整性。 
  （5）服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。所以，还要测试没有经过授

权，就不能在服务器端放置和编辑脚本的问题。 
  六、总结 
  本文从功能、性能、可用性、客户端兼容性、安全性等方面讨论了基于Web的系统测试方法。 
  基于Web的系统测试与传统的软件测试既有相同之处，也有不同的地方，对软件测试提出了新的挑战

。基于Web的系统测试不但需要检查和验证是否按照设计的要求运行，而且还要评价系统在不同用户的浏

览器端的显示是否合适。重要的是，还要从最终用户的角度进行安全性和可用性测试。

规范性细则：1):常用菜单要有命令快捷方式。
2):完成相同或相近功能的菜单用横线隔开放在同一位置。
3):菜单前的图标能直观的代表要完成的操作。
4):菜单深度一般要求最多控制在三层以内。
5):工具栏要求可以根据用户的要求自己选择定制。
6):相同或相近功能的工具栏放在一起。
7):工具栏中的每一个按钮要有及时提示信息。
8):一条工具栏的长度最长不能超出屏幕宽度。
9): 工具栏的图标能直观的代表要完成的操作。
10):系统常用的工具栏设置默认放置位置。
11):工具栏太多时可以考虑使用工具厢。
12):工具厢要具有可增减性，由用户自己根据需求定制。
13):工具厢的默认总宽度不要超过屏幕宽度的1/5。
14): 状态条要能显示用户切实需要的信息，常用的有：
目前的操作、系统状态、用户位置、用户信息、提示信息、错误信息等，如果某一操作需要的时间较长，还应该显示进度条和进程提示。
15)：滚动条的长度要根据显示信息的长度或宽度能及时变换，以利于用户了解显示信息的位置和百分比。
16)：状态条的高度以放置五好字为宜，滚动条的宽度比状态条的略窄。
17)：菜单和工具条要有清楚的界限;菜单要求凸出显示，这样在移走工具条时仍有立体感。
18)：菜单和状态条中通常使用5号字体。工具条一般比菜单要宽，但不要宽的太多，否则看起来很不协调。
19):右键快捷菜单采用与菜单相同的准则。
3：帮助设施：
系统应该提供详尽而可靠的帮助文档，在用户使用产生迷惑时可以自己寻求解决方法。

帮助设施细则：
1)：帮助文档中的性能介绍与说明要与系统性能配套一致。(我们的系统帮助文档都是系统的祖先时期的说明，让人困惑)。
2)：打包新系统时，对作了修改的地方在帮助文档中要做相应的修改。
3)：操作时要提供及时调用系统帮助的功能。常用F1。
4)：在界面上调用帮助时应该能够及时定位到与该操作相对的帮助位置。也就是说帮助要有即时针对性。
5)：最好提供目前流行的联机帮助格式或HTML帮助格式。
6)：用户可以用关键词在帮助索引中搜索所要的帮助，当然也应该提供帮助主题词。
7)：如果没有提供书面的帮助文档的话，最好有打印帮助的功能。
8 )：在帮助中应该提供我们的技术支持方式，一旦用户难以自己解决可以方便的寻求新的帮助方式。

4：合理性：
屏幕对角线相交的位置是用户直视的地方，正上方四分之一处为易吸引用户注意力的位置，在放置窗体时要注意利用这两个位置。

合理性细则：
1)：父窗体或主窗体的中心位置应该在对角线焦点附近。
2)：子窗体位置应该在主窗体的左上角或正中。
3)：多个子窗体弹出时应该依次向右下方偏移，以显示窗体出标题为宜。
4)：重要的命令按钮与使用较频繁的按钮要放在界面上注目的位置。
5)：错误使用容易引起界面退出或关闭的按钮不应该放在易点位置。横排开头或最后与竖排最后为易点位置。
6)：与正在进行的操作无关的按钮应该加以屏蔽(Windows中用灰色显示，没法使用该按钮)。
7)：对可能造成数据无法恢复的操作必须提供确认信息,给用户放弃选择的机会。
8)：非法的输入或操作应有足够的提示说明。
9): 对运行过程中出现问题而引起错误的地方要有提示，让用户明白错误出处，避免形成无限期的等待。
10):提示、警告、或错误说明应该清楚、明了、恰当。
5：美观与协调性：
界面应该大小适合美学观点，感觉协调舒适，能在有效的范围内吸引用户的注意力。

美观与协调性细则：
1): 长宽接近黄金点比例，切忌长宽比例失调、或宽度超过长度。
2): 布局要合理,不宜过于密集，也不能过于空旷，合理的利用空间。
3): 按钮大小基本相近，忌用太长的名称，免得占用过多的界面位置。
4): 按钮的大小要与界面的大小和空间要协调。
5): 避免空旷的界面上放置很大的按钮。
6)：放置完控件后界面不应有很大的空缺位置。
7): 字体的大小要与界面的大小比例协调, 通常使用的字体中宋体9-12较为美观，很少使用超过12号的字体。
8): 前景与背景色搭配合理协调，反差不宜太大，最好少用深色，如大红、大绿等。常用色考虑使用Windows界面色调。
9): 如果使用其他颜色，主色要柔和，具有亲和力与磁力，坚决杜绝刺目的颜色。
10): 大型系统常用的主色有"#E1E1E1"、"#EFEFEF"、"#C0C0C0"等。
11): 界面风格要保持一致，字的大小、颜色、字体要相同，除非是需要艺术处理或有特殊要求的地方。
12): 如果窗体支持最小化和最大化或放大时，窗体上的控件也要随着窗体而缩放；切忌只放大窗体而忽略控件的缩放。
13)：对于含有按钮的界面一般不应该支持缩放，即右上角只有关闭功能。
14): 通常父窗体支持缩放时，子窗体没有必要缩放。
15)：如果能给用户提供自定义界面风格则更好，由用户自己选择颜色、字体等。

6：菜单位置：
菜单是界面上最重要的元素，菜单位置按照按功能来组织。

菜单设测试细则：
1)：菜单通常采用“常用--主要--次要--工具--帮助”的位置排列，符合流行的Windows风格。
2):常用的有“文件”、“编辑”，“查看”等，几乎每个系统都有这些选项，当然要根据不同的系统有所取舍。
3):下拉菜单要根据菜单选项的含义进行分组，并切按照一定的规则进行排列，用横线隔开。
4): 一组菜单的使用有先后要求或有向导作用时，应该按先后次序排列。
5): 没有顺序要求的菜单项按使用频率和重要性排列，常用的放在开头， 不常用的靠后放置；重要的放在开头，次要的放在后边。
6): 如果菜单选项较多，应该采用加长菜单的长度而减少深度的原则排列。
7): 菜单深度一般要求最多控制在三层以内。
8): 对常用的菜单要有快捷命令方式，组合原则见8。
9):对与进行的操作无关的菜单要用屏蔽的方式加以处理，如果采用动态加载方式——即只有需要的菜单才显示——最好。
10)：菜单前的图标不宜太大，与字高保持一直最好。
11):主菜单的宽度要接近，字数不应多于四个，每个菜单的字数能相同最好。
12)：主菜单数目不应太多，最好为单排布置。
。7:独特性：
如果一味的遵循业界的界面标准，则会丧失自己的个性.在框架符合以上规范的情况下，设计具有自己独特风格的界面尤为重要。尤其在商业软件流通中有着很好的迁移默化的广告效用。

1):安装界面上应有单位介绍或产品介绍，并有自己的图标。
2):主界面，最好是大多数界面上要有公司图标。
3):登录界面上要有本产品的标志，同时包含公司图标。
4):帮助菜单的“关于”中应有版权和产品信息。
5):公司的系列产品要保持一直的界面风格，如背景色、字体、菜单排列方式、图标、安装过程、按钮用语等应该大体一致。

8：快捷方式的组合
在菜单及按钮中使用快捷键可以让喜欢使用键盘的用户操作得更快一些 在西文Windows及其应用软件中快捷键的使用大多是一致的。 
菜单中：
1):面向事务的组合有: 
Ctrl-D 删除 ；Ctrl-F 寻找 ；Ctrl –H替换；Ctrl-I 插入 ；Ctrl-N 新记录 ；Ctrl-S 保存 Ctrl-O 打开。
2)：列表: 
Ctrl-R ，Ctrl-G定位；Ctrl-Tab下一分页窗口或反序浏览同一页面控件；。
3):编辑:
Ctrl-A全选；Ctrl-C 拷贝；Ctrl-V 粘贴；Ctrl-X 剪切；Ctrl-Z撤消操作；Ctrl-Y恢复操作。
4)文件操作:
Ctrl-P 打印；Ctrl-W 关闭。
5):系统菜单
Alt-A文件；Alt-E编辑；Alt-T工具；Alt－W窗口；Alt－H帮助。
6):MS Windows保留键:
Ctrl-Esc 任务列表 ；Ctrl-F4 关闭窗口； Alt-F4 结束应用；Alt-Tab 下一应用 ；Enter 缺省按钮/确认操作 ；Esc 取消按钮/取消操作 ；Shift-F1 上下文相关帮助 。
按钮中：
可以根据系统需要而调节，以下只是常用的组合。
Alt-Y确定(是)；Alt-C取消；Alt-N 否；Alt-D删除；Alt-Q退出；Alt-A添加；Alt-E编辑；Alt-B浏览；Alt-R读；Alt-W写。
这些快捷键也可以作为开发中文应用软件的标准,但亦可使用汉语拼音的开头字母。 
9:安全性考虑：
在界面上通过下列方式来控制出错几率，会大大减少系统因用户人为的错误引起的破坏。开发者应当尽量周全地考虑到各种可能发生的问题,使出错的可能降至最小。如应用出现保护性错误而退出系统,这种错误最容易使用户对软件失去信心。因为这意味着用户要中断思路,并费时费力地重新登录,而且已进行的操作也会因没有存盘而全部丢失。


安全性细则：
1)：最重要的是排除可能会使应用非正常中止的错误。
2)：应当注意尽可能避免用户无意录入无效的数据。
3)：采用相关控件限制用户输入值的种类。
4)：当用户作出选择的可能性只有两个时,可以采用单选框。 
5)：当选择的可能再多一些时,可以采用复选框,每一种选择都是有效的,用户不可能输入任何一种无效的选择。
6)：当选项特别多时，可以采用列表框，下拉式列表框。
7)：在一个应用系统中,开发者应当避免用户作出未经授权或没有意义的操作。
8)：对可能引起致命错误或系统出错的输入字符或动作要加限制或屏蔽。
9):对可能发生严重后果的操作要有补救措施。通过补救措施用户可以回到原来的正确状态。
10):对一些特殊符号的输入、与系统使用的符号相冲突的字符等进行判断并阻止用户输入该字符。
11)：对错误操作最好支持可逆性处理，如取消系列操作。
12):在输入有效性字符之前应该阻止用户进行只有输入之后才可进行的操作。
13):对可能造成等待时间较长的操作应该提供取消功能。
14)：特殊字符常有；;’”><,｀‘：“［”｛、\|｝］+=)-(_*&&^%$#@!~,.。?/还有空格。
15)：与系统采用的保留字符冲突的要加以限制。
16)：在读入用户所输入的信息时，根据需要选择是否去掉前后空格。
17)：有些读入数据库的字段不支持中间有空格，但用户切实需要输入中间空格，这时要在程序中加以处理。

10:多窗口的应用与系统资源：
设计良好的软件不仅要有完备的功能，而且要尽可能的占用最底限度的资源。
1)： 在多窗口系统中，有些界面要求必须保持在最顶层，避免用户在打开多个窗口时，不停的切换甚至最小化其他窗口来显示该窗口。

2)：在主界面载入完毕后自动卸出内存，让出所占用的WINDOWS系统资源。
3)：关闭所有窗体，系统退出后要释放所占的所有系统资源 ，除非是需要后台运行的系统。
4)：尽量防止对系统的独占使用。