统将给出正确的示信息；
前置条件：存在正确的用户名和密码；
登录页面正常装载；
用例设计：
一.界面测试测试用例        用例目的：该用例用来测试在登录界面用户能否正常登录；

若出现错误的信息系统将给出正确的示信息；
前置条件：存在正确的用户名和密码；
登录页面正常装载；
用例设计：
一.界面测试
界面正常装载后，检视页面是否符合规范       

1．页面title是否正确；
2．页面的默认焦点是否控制在用户名输入框中；
3．TAB键能否控制；
4．未登录状态下，页面的其他按钮（非登陆/取消按钮）不可选或选择无效

5. 取消按键不可用；

二.登录测试
输入正确的用户名和正确的密码
用户名：mm
密 码：mm
鼠标点击登录        正常登陆，转入对应的系统页面

用户名：mm
密 码：mm
直接回车键（Enter）进行登陆        正常登陆，转入对应的系统页面

输入正确的用户名和正确的密码，但未区分大小写
用户名：Mm
密码：Mm
区分大小写，显示出错信息，不能正常登陆

输入正确的用户名和错误的密码
用户名：mm
密  码：dw54f

出现密码错误的提示并清空输入框
用户名：mm
密  码：￥§￡（即在密码中输入特殊符号）
提示密码中存在特殊符号或者在输入特殊符号时系统自动消除/不能输入

输入错误的用户名和正确的密码
用户名：jiew11
密  码：mm
出现用户名不存在或错误的提示并清空输入框
用户名：jie￥§（在用户名中输入特殊符号）
密  码：mm       

提示用户名中存在特殊符号或者在输入特殊符号时系统自动消除/不能输入

输入错误的用户名和错误的密码
用户名：jiew11
密  码：dw54f
出现用户名不存在或密码错误的提示并清空输入框

不输入用户名和密码/或均为空格，直接点击登录       

用户名：
密  码：       

出现“请输入用户名、密码”的提示框

只输入用户名，密码为空/或为空格       

用户名：mm
密  码：       

出现“请输入密码”提示框
用户名为空/或为空格，只输入密码       

用户名：
密  码：mm        出现“请输入用户名”提示框

三.异常测试
输入用户名或密码；点击取消；       

用户名：jiew11
密  码：dw54f

清空输入框

四.备注说明
1.在登录WEB页面也可以进行变态性的测试，比如不停的点击登录按扭，或多个人同时登录（可用loadrunner进行压力模拟）
2．现在的一般登录页面都会有验证码，同样的可以和上面类似的设计测试用例，但是由于在安全性上影响不大，故不在详说。（验证码测试用例举例：大小写，空值，错误输入等等）
3．登录的安全性测试：
a) 是否可以不登陆而直接浏览某个页面等。
b) Web应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内（例如15分钟）没有点击任何页面，是否需要重新登陆才能正常使用。
c) 为了保证Web应用系统的安全性，日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪，以防止被黑客截取。
d)  当使用了安全套接字时，还要测试加密是否正确，检查信息的完整性。
e)  服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。所以，还要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。
f)  有的在线登录系统会有“找回密码”，这样我们在测试是就一定要注意找回密码的条件（找回密码条件安全级应等同于或高于密码安全级）和此时的网络安全性。
4． 登录在易用性上要求也是较高的，以次我们也可以参照用户的观点以及安全性上考虑给出一个标准：
a)  界面的美观程度
b)  按扭的设置和排列
c)  输入提示的人性化考虑
d)  错误提示的准确性
e)  验证码的清晰度和复杂程度
进一步的信息        关于自动化测试工具在登录性能测试上的缺陷及解决办法
现在越来越多的网站为了安全性或是防止Spam的侵害，采用了验证码的校验技术。简单地说，验证码就是在进行登录或是内容提交的时候，页面上会随机出现一个人工可识别，但机器不可识别的验证字符串（一般是采用背景、扭曲等方式产生的图片），要求登录或是提交内容时同时输入这个验证码。
验证码可以有效防止对口令的刺探和所谓的网络推广软件带来的大量的Spam内容，目前已经被许多Internet或是Intranet应用接受为标准的实现方式。但对性能测试来说，这种验证码又带来了很大的问题。
最突出的问题是，性能测试工具本身是自动化工具，由于这种验证码采用的是“防止自动化工具尝试”的方法，因此，在录制了脚本之后会发现，很难对脚本进行调整，以使其适应验证码验证的需要。对这个问题，我个人的看法是，基本上可以考虑从三个途径来解决该问题：
1、第一种方法，也是最容易想到的，在被测系统中暂时屏蔽验证功能，也就是说，临时修改应用，无论用户输入的是什么验证码，都认为是正确的。这种方法最容易实现，对测试结果也不会有太大的影响（当然，这种方式去掉了“验证验证码”这个环节，不过这个环节本来就很难成为系统性能瓶颈）。但这种方法有一个致命的问题：如果被测系统是一个实际已上线的系统，屏蔽验证功能会对已经在运行的业务造成非常大的安全性的风险，因此，对于已上线的系统来说，用这种方式就不合适了；
2、第二种方法，在第一种方法的基础上稍微进行一些改进。第一种方法带来了很大的安全性问题，那么我们可以考虑，不取消验证，但在其中留一个后门，我们设定一个所谓的“万能验证码”，只要用户输入这个“万能验证码”，我们就验证通过，否则，还是按照原先的验证方式进行验证。这种方式仍然存在安全性的问题，但由于我们可以通过管理手段将“万能验证码”控制在一个小的范围内，而且只在性能测试期间保留这个小小的后门，相对第一种方法来说，在安全性方面已经有较大的改进了；
3、如果安全性对应用来说真的是至关重要的，不容许有一丝一毫的闪失，那我们还可以用更进一步的方法来处理这个问题。一般的性能测试工具（loadrunner等）都能够调用外部的组件接口，因此，可以考虑获得“验证码验证”部分的实现，写一个验证码获取的代码，在测试脚本中进行调用即可。
在我看来，第二种方法用得比较多，对未上线系统系统的内部性能测试，有时候也用第一种方法。但要提醒的是，如果针对的是已上线系统，无论用哪种方法，测试完成后，都必须立刻将应用恢复，并对系统进行一次安全审计，以免在测试期间被他人入侵。第三种方法用得比较少，而且具体上还依赖于验证组件是否能提供这样的接口，以及获取验证码开发的难度。

1．页面title是否正确；
2．页面的默认焦点是否控制在用户名输入框中；
3．TAB键能否控制；
4．未登录状态下，页面的其他按钮（非登陆/取消按钮）不可选或选择无效

5. 取消按键不可用；

二.登录测试
输入正确的用户名和正确的密码
用户名：mm
密 码：mm
鼠标点击登录        正常登陆，转入对应的系统页面

用户名：mm
密 码：mm
直接回车键（Enter）进行登陆        正常登陆，转入对应的系统页面

输入正确的用户名和正确的密码，但未区分大小写
用户名：Mm
密码：Mm
区分大小写，显示出错信息，不能正常登陆

输入正确的用户名和错误的密码
用户名：mm
密  码：dw54f

出现密码错误的提示并清空输入框
用户名：mm
密  码：￥§￡（即在密码中输入特殊符号）
提示密码中存在特殊符号或者在输入特殊符号时系统自动消除/不能输入

输入错误的用户名和正确的密码
用户名：jiew11
密  码：mm
出现用户名不存在或错误的提示并清空输入框
用户名：jie￥§（在用户名中输入特殊符号）
密  码：mm       

提示用户名中存在特殊符号或者在输入特殊符号时系统自动消除/不能输入

输入错误的用户名和错误的密码
用户名：jiew11
密  码：dw54f
出现用户名不存在或密码错误的提示并清空输入框

不输入用户名和密码/或均为空格，直接点击登录       

用户名：
密  码：       

出现“请输入用户名、密码”的提示框

只输入用户名，密码为空/或为空格       

用户名：mm
密  码：       

出现“请输入密码”提示框
用户名为空/或为空格，只输入密码       

用户名：
密  码：mm        出现“请输入用户名”提示框

三.异常测试
输入用户名或密码；点击取消；       

用户名：jiew11
密  码：dw54f

清空输入框

四.备注说明
1.在登录WEB页面也可以进行变态性的测试，比如不停的点击登录按扭，或多个人同时登录（可用loadrunner进行压力模拟）
2．现在的一般登录页面都会有验证码，同样的可以和上面类似的设计测试用例，但是由于在安全性上影响不大，故不在详说。（验证码测试用例举例：大小写，空值，错误输入等等）
3．登录的安全性测试：
a) 是否可以不登陆而直接浏览某个页面等。
b) Web应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内（例如15分钟）没有点击任何页面，是否需要重新登陆才能正常使用。
c) 为了保证Web应用系统的安全性，日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪，以防止被黑客截取。
d)  当使用了安全套接字时，还要测试加密是否正确，检查信息的完整性。
e)  服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。所以，还要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。
f)  有的在线登录系统会有“找回密码”，这样我们在测试是就一定要注意找回密码的条件（找回密码条件安全级应等同于或高于密码安全级）和此时的网络安全性。
4． 登录在易用性上要求也是较高的，以次我们也可以参照用户的观点以及安全性上考虑给出一个标准：
a)  界面的美观程度
b)  按扭的设置和排列
c)  输入提示的人性化考虑
d)  错误提示的准确性
e)  验证码的清晰度和复杂程度
进一步的信息        关于自动化测试工具在登录性能测试上的缺陷及解决办法
现在越来越多的网站为了安全性或是防止Spam的侵害，采用了验证码的校验技术。简单地说，验证码就是在进行登录或是内容提交的时候，页面上会随机出现一个人工可识别，但机器不可识别的验证字符串（一般是采用背景、扭曲等方式产生的图片），要求登录或是提交内容时同时输入这个验证码。
验证码可以有效防止对口令的刺探和所谓的网络推广软件带来的大量的Spam内容，目前已经被许多Internet或是Intranet应用接受为标准的实现方式。但对性能测试来说，这种验证码又带来了很大的问题。
最突出的问题是，性能测试工具本身是自动化工具，由于这种验证码采用的是“防止自动化工具尝试”的方法，因此，在录制了脚本之后会发现，很难对脚本进行调整，以使其适应验证码验证的需要。对这个问题，我个人的看法是，基本上可以考虑从三个途径来解决该问题：
1、第一种方法，也是最容易想到的，在被测系统中暂时屏蔽验证功能，也就是说，临时修改应用，无论用户输入的是什么验证码，都认为是正确的。这种方法最容易实现，对测试结果也不会有太大的影响（当然，这种方式去掉了“验证验证码”这个环节，不过这个环节本来就很难成为系统性能瓶颈）。但这种方法有一个致命的问题：如果被测系统是一个实际已上线的系统，屏蔽验证功能会对已经在运行的业务造成非常大的安全性的风险，因此，对于已上线的系统来说，用这种方式就不合适了；
2、第二种方法，在第一种方法的基础上稍微进行一些改进。第一种方法带来了很大的安全性问题，那么我们可以考虑，不取消验证，但在其中留一个后门，我们设定一个所谓的“万能验证码”，只要用户输入这个“万能验证码”，我们就验证通过，否则，还是按照原先的验证方式进行验证。这种方式仍然存在安全性的问题，但由于我们可以通过管理手段将“万能验证码”控制在一个小的范围内，而且只在性能测试期间保留这个小小的后门，相对第一种方法来说，在安全性方面已经有较大的改进了；
3、如果安全性对应用来说真的是至关重要的，不容许有一丝一毫的闪失，那我们还可以用更进一步的方法来处理这个问题。一般的性能测试工具（loadrunner等）都能够调用外部的组件接口，因此，可以考虑获得“验证码验证”部分的实现，写一个验证码获取的代码，在测试脚本中进行调用即可。
在我看来，第二种方法用得比较多，对未上线系统系统的内部性能测试，有时候也用第一种方法。但要提醒的是，如果针对的是已上线系统，无论用哪种方法，测试完成后，都必须立刻将应用恢复，并对系统进行一次安全审计，以免在测试期间被他人入侵。第三种方法用得比较少，而且具体上还依赖于验证组件是否能提供这样的接口，以及获取验证码开发的难度。

Web Page Fundamentals(网页基本原理)-网页包含的元素还是网页的一些特征，相对于传统的光盘媒质，网页元素有其特别的元素和不同。很多网页都有但是不局限于以下的基本元素：

1.大小各异色彩缤纷N多不同字体的文字。

2.图像和相片

3.文字和图像超链接

4.广告

5.下拉菜单

6.可以添加文字的表单

还有就是一些高级的动态功能：

1.可以让用户随意改变显示位置的功能(自定义布局- Customizable layout)

2.用户可以选择其感兴趣的新闻(自定义内容- Customizable content)

3.动态下拉菜单

4.动态替换的文字

5.根据分辨率而变化的动态布局和可选内容

6.对不同浏览器，不同的版本，不同的硬件和软件平台的兼容

7.许多增强可用性的隐藏的格式，标签和内嵌信息

黑盒测试在Web测试中的应用

文字- (Text)：

1.对网页的测试有时候很想是对文本的测试，需要根据用户的水平，相关术语，内容，还有拼写错误，还有一个就是要看看那些信息是否已经是过时的。在这里要注意的是，不要依靠拼写检查器，因为他不能检查图片的文字还有表带等……

2.对于一些特别有用的信息，例如Email，地址，邮编，电话等……需要加倍留意。最与每个网页的标题也要认真细看。

3.还有一个很容易被忽略的地方就是ALT信息，就是我们把鼠标移动到一个图标上的弹出提示。

4.还有就是用不同的分辨率看看文字有没有变化。因为这里有可能出现一种问题就是，可能一段文字在特定的分辨率下显示是好的，换个分辨率就变得支离破碎了。

超链接- (Hyperlinks)

1.看是否那些超链接都是正确的。会不会一个“注册”的超链接，最后就链接到了退出页面了。

2.如果是一个在线发EMAIL的窗口，那么就写个EMAIL看他能不能发信出去并且收信人是收到的。

3.注意检查，防止出现孤立的页面(orphan pages)。有可能这个页面没有出口或者没有入口或者两者都没有。

图像- (Graphics)

1.看图像有没有被正常的load出来

2.如果图像和文字是弄到一起的，注意看那些在图像周围的文字有没有很好的换行，有没有文字被那个图像遮住了。

表单- (Forms)

1.看表单的布局有没有问题，是不是有些文本框没有跟说明的文字对齐

2.文本框能否正确输入内容，例如一个要填入邮编号码的文本框里面看能否输入数字

3.看看是不是所有字段都是必填的。如果有某些是必填的话，看看他们是否真的有效

其他杂项- (Miscellaneous)

1.如果有计数器，那么需要对之进行测试

2.如果是有搜索功能，要把这个站内搜索和搜索引擎的搜索分辨清楚

灰盒测试(Gray-Box Testing)在Web测试中的应用

灰盒测试就是用黑盒的方法，就是不管里面是怎么弄的，反正我只看功能，然后有结合白盒测试的技术，站在一个比较高的角度看这个软件是如何运作的。书中说一个网页比较适合灰盒测试，因为HTML本身不是一种编程语言，只是一种标记语言，比较容易理解。一般来说灰盒测试会在集成测试的执行过程中用到，多数由程序员来执行啦~

白盒测试在网页在Web测试中的应用

现在这个年头，已经没有人用静态网页了，有也是通过一些编程语言来动态生成的吧。白盒测试主要对以下进行测试：

1.动态内容- (Dynamic Content)

2.基于数据库内容的页面- (Database-Driven Web Pages)

3.程序生成的页面- (Programmatically Created Web Pages)

4.服务器性能和负载- (Server Performance and Loading)

5.安全性- (Security)

配置测试和兼容性测试- (Configuration and Compatibility Testing)

配置测试是一个检查你的软件在不同软硬件平台上以及不同的配置下能否正常工作的过程

兼容性测试是一个检查你的软件跟其他软件能否和平共处的过程

一些需要注意的东西：

1.硬件平台- (Hardware Platform)

2.浏览器软件及其版本- (Browser Software and Version)

3.浏览器插件- (Browser Plug-Ins)

4.浏览器选项- (Browser Options)

5.分辨率和色深- (Video Resolution and Color Depth)

6.文字大小- (Text Size)

7.网速- (Modem Speeds)

可用性测试在Web测试中的应用

可用性测试估计是提的比较多的吧。我记得以前看过一本书叫《Don't let me think》。里面就是讲述了一些提高可用性的方法还有设计原则之类的。《软件测试》这本书提到了10个最容易犯错点：

1.Gratuitous Use of Bleeding-Edge Technology-滥用先进技术，其实做IT这个大家都知道技术更新的很快，但是一般商用的软件都不会选择最新版本或者最前沿的技术，就好像JAVA都出到1.6了但是很多开发团队还是在用1.4。稳定压倒一切啊。

2.Scrolling Text, Marquees, and Constantly Running Animations-不要搞的整个页面动来动去的，因为用户看的是内容，看的是内容是否有价值，而不是花里胡哨的飘来飘去的文字。

3.Long Scrolling Pages-一个页面拉啊拉~拉半天都不到底。

4.Non-Standard Link Colors-前面都说过了，标准是要去跟的，不要随便改动，就好像一般链接是蓝色的那么就蓝色吧，特别大的标题做成红色是合理的，什么不好的事情做成黑的也是合理的，但是如果出现绿色di……那么就好像有点不合理哦。

5.Outdated Information-过时的内容，这个有可能出现在邮件地址，电话号码的地方。

6.Overly Long Download Times-过长的下载时间，一般用户的忍耐性都是有限，而且现在SB电信搞什么包月改为240小时，时间就是金钱啊。估计没人喜欢看着浏览器的进度栏干瞪眼。

7.Lack of Navigation Support-缺乏导航支持。有些页面有进没有出，或者不能方便的返回上层页面。

8.Orphan Pages-孤立的页面。没法进，万一不幸进了还没法出。

9.Complex Website Addresses (URLs)-这个要看当时注册了个啥域名了。。。

10.Using Frames-框架的确受人鄙视，不过不知道为什么哦，Rational ClearQuest就用的Frame。

前阶段为公司内刊发表了一篇小文，谈了下软件测试的内容，今天也共享到我的微博上，感兴趣的同学可以看一下：

本次很荣幸的由我来写一篇稿子。

在做软件测试工程师的这几年，收获了不少，对软件测试这一职业的理解也随着工作经验有这更加深入的了解，在这里写一篇关于“软件测试”的小文，发表一下我个人的一些拙见，供大家探讨学习之用。

软件测试

什么是软件测试？其实现在很多人对软件测试这一职业不是很了解，不知到底什么是软件测试。

关于软件测试的定义有很多种，我个人觉的比较符合的是：“使用人工或者自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别”。由于现在软件发展的十分迅速，软件的复杂度也越来越高，所以软件测试现在也变的原来越重要，软件测试贯穿于整个软件生命周期，软件测试并不局限于程序测试，它还包括对相关的需求、文档的测试，也包括一些多样化的回归测试、压力测试、性能测试等。

关于软件测试理论知识在很多书中都有详细的描写，这里就不摘抄了。但是根据我的经验，想要做好软件测试，深入了解软件测试的理论知识是必不可少的，很多很多实际遇到的问题，都是由于对软件测试的理论知识的不了解造成的。

测试心理

做好一名软件测试人员，调整好心理是必须的。

（1）“创造者”与“破坏者”

在心理上，软件开发和测试最大的区别在于前者是“创造者”而后者是“破坏者”。

对于“创造者”而言，在心理上是不会对自己“创造”出来的产品进行破坏，就像每个人都会很爱惜自己的手工作品。而对于“破坏者”，心理上应该是属于乐于看到自己测试的系统“崩塌”的场面，就像拿着别人的手工作品摔砸扔来证明那个手工不行一样。

又如在实际应用中，开发人员会说：“这个功能我测过好几遍了，没有问题了”，但测试软件却还是能在这个功能里挑出很多的问题，原因在于，开发人员测试时，心理上的关注点放在了“证明这个功能点可行”上，往往会无意识的绕过一些可能会引起问题的操作；而测试人员的关注点放在了“使这个功能点不行”上，会尝试各种可能造成问题的操作。所以“破坏者”需要利用你所有可知的测试策略与方法，对软件进行不同程度的“破坏”，检查各种状况下，软件的处理方式与系统的能力。

（2）“第三方视角”&“好奇心”

以第三方的眼光看软件产品是测试人员与开发人员在进行测试时最大的区别。除了“第三方的视角”，测试人员在心理上还要时常保持“好奇心”，随着测试的深入，测试人员应不满足于现有的测试成果，“好奇心”会让我想知道每次点击操作背后系统正在做些什么，驱使我去找程序员问个究竟或者看他们的代码是怎么写的，看看能否进一步优化系统；“好奇心”会让我想弄清楚究竟多少用户同时操作，系统就会崩溃，能否应付系统上线后的正常使用；“好奇心”会驱使我在想用户如果来使用软件的时候会如何操作，会遇到什么样的问题，会不会觉得繁琐。有了“好奇心”，才能让系统在上线前就做了更加完备的测试。

（3）“兴趣”

“兴趣”也是关键，做过软件测试工作的人知道，软件测试有时候是一个很繁琐枯燥的工作。比如测试一个表单填写提交的功能，需要使用不同数据进行填写并提交，所以非常有可能出现的情况是，这一星期，每天8小时的工作就是坐在电脑前，不停的做着“填写表单并提交”这样的简单机械时劳动，这时，“兴趣”是能让我摆脱枯燥的方法。兴趣是最好的老师，如果对测试工作真正感兴趣的，就会不断地研究测试相关的理论知识、技能技巧、工具等。就如上面说的“提交表单”测试，你可以把它当成一种挑战，目标是搞垮它，这时，就可以尝试各种各样测试方法：尝试不同的填写数字、在填数字的地方写英文、在写英文的地方写中文、将必填处留空提交、在填写框中复制上一篇10W字的文章、上传附件处上传各式各样的格式文件、上传50MB以上的图片文件、使用QTP反复快速操作、使用QTP Object对象方法篡改页面控件属性提交、使用Loadrunner模拟大量用户同时提交、提交的时候拔掉网线、用Sniffer或HttpWatch抓包进行观察等等，有太多的方法可以尝试，再使出浑身解数后，发现不知不觉中，已对表单的各种场景进行了模拟测试，提交了大量表单，时间也觉得一个星期都不够了呢。用一个比喻来说的话，如James A. Whittaker的《How to Break Software》说的，“像小时候我们拿上一个小玩具，可能就是一个陀螺，甚至是一个拖把，我们也会玩上半天也不会感到厌烦。我们会变着花样来玩它，我们扮演各种角色，把它当成道具，玩得不亦乐乎。现在的测试工作是什么，测试的对象有时候就是个玩具，只不过有些看起来过于严肃而已。如果我们能把软件当成玩具来玩，那么我们可能不会那么快就认为测试已经可以停止了。因为还有那么多有趣的玩法还没尝试。如果实在是玩腻了，还大可以把玩具狠狠地甩在地上，用脚踩几下，看它有什么反应。这也是一种测试方法！你是在进行破坏性测试！把你的小脚踏车一边又一边地从斜坡上冲下来，每次装上不同重量的东西，看装上哪一种东西会最快。哈哈，原来你是在做压力测试！”

PS：经常有初入软件测试的人发邮件给我问，说做软件测试是如此的枯燥无味，而且很难在一个软件中找到更多的BUG了，或是开始抱怨回归测试的无聊时，我都会告诉他，你还没找到软件测试的“兴趣”。非常有幸的，我发现了“它”，它让我工作到现在仍能在软件测试中找到无限的乐趣与挑战，也是它，迫使我学习更多的知识。

测试方法

测试的方法太多了，不是我一篇小文能够全部概括的，在这里，我就说一些最基础的测试方法。

如测试一个登录界面。有用户名和密码框，确定和重置按钮。用户名和密码长度要求为6-12位。

（1）冒烟测试

我们测试的时候，最先需要使用正确的账号登录一遍，这叫“冒烟测试”，“冒烟测试”的作用是判断一个功能模块的最基本功能是否实现，如果“冒烟测试”能通过，则继续进行深入的测试，如果不过，则不继续进行测试。

冒烟测试是测试的第一步，当发现软件连最基本的功能都无法实现的时候，应立即终止测试，交于开发处理问题，而不是继续测试，放慢了整体研发速度。

（2）边界值& 等价类

当“冒烟测试”过了，则可以进一步进行测试了。这里需要用到“边界值”和“等价类”的测试思想。何为“边界值”？边界值的概念是输入稍高于其边界值及稍低于其边界值的一种测试方法。往往会在边界值的地方发生错误或与需求文档要求的不符合。如例子中，假设限定用户名长度只能为6-12位，则我们需要分别对长度为5位、6位、7位、11位、12位、13位这6种长度进行测试，这就是“边界值”法。何为“等价类”？等价类是一种数学上的概念，在这里是将一个测试点划分为多种类的集合，如：还是长度只能为6-12位的问题，使用等价类的方法可以划分为三类：1是小于6位的情况，2是6-12位的情况，3是大于12位的情况。测试的时候，需要在这三类情况中各举出一套测试数据进行测试。这就是“等价类”。

从概念上来看，边界值和等价类的方法很好理解，这是软件测试中，最最基础的测试方法，但能真正活用于测试项目中的的确不多。从不少的来信中看到，其实还是有很多很多的测试人员不知道这两种测试方法，更不用说活用。但如电影中最厉害的大招往往是最基础的招式，小说中最厉害的人往往只是扫地僧，烹饪中最能看出能力的往往是炒蛋炒饭一样。看一个测试人员的基础和能力，看他写的测试用例就知道了。能活用与最简单的测试方法，才是最有效高效的测试。

（3）错误猜想

猜，这也是一种测试方法，这也是用的最多的一种测试方法。当然，不是胡猜，而是有依据的猜。往往经验丰富的测试人员能“猜”到更多有可能产生问题的情况，写出更加有效的测试用例。刚刚的登录例子，可以“猜”在能正常登陆的账号前或后加个空格，看看是否能正常登录；可以“猜”输入空的用户名和密码进行登录的情况；可以“猜”在登录框中粘贴进大于保存用户名变量类型的字符个数；可以“猜”在注册一些带有奇怪字符或是超出字库范围的文字后能否正常登录；可以“猜”登录瞬间关掉页面检查Sever上Session是否释放等等，能猜的内容很多很多，随着经验的增长和对系统越发的熟悉，会“猜”到更多测试方案。

（4）场景法

这也是在平时用的比较多的方法，定义不同的场景，进行有规律的测试。主要用于检查流程等，可使用在有较多分支流程中进行测试。

（5）失败测试

纯粹为了破坏而设计和执行的测试用例称为失败测试。可考察系统超出需求范围时的行为。

测试方法太多太多，这里就不一一阐述了，但是上面5种，是用的最基础也是用的最多的方法。

测试用例

测试用例的重要性不用多了，能规范化测试，记录所有可能出现的问题，随着对测试用例的扩充，能越来越达到完备的测试。关于测试用例，我想说的是两点，“预期结果”与“测试数据”。

（1）预期结果

测试用例中必须要写的中，最重要的一项是预期结果，我在指导一些网友写的测试用例的时候，发现这点很难有做的很好的。往往刚接触测试的人员会在预期结果一栏中写入诸如“登录正确”、“提交失败”等这样简单的预期结果。殊不知这样的写法和没写是差不多的，因为当另一个测试人员进行测试的时候，完全不知道“登录正确”时的表现形式，应写明页面上显示了些什么，那个角落会有什么样的显示，数据是否真正写到了数据库中而“提交失败”需写明失败提示到底是什么，是否有弹出框，是有错误图标等等的详细内容。

在预期结果中不要出现如“查看弹出框中内容是否有图片”这样的有两层意思的句子，即不要出现“是否”。因为这样的书写，在别人看来是“查看弹出框中内容是有图片”是预期结果还是“查看弹出框中内容没有图片”是预期结果，这个看来只有写这条测试用例的人自己知道了。

（2）测试数据

测试数据需要完整，如在某输入框中输入数据，需要写明需要输入的内容是什么，是“abcdefg”还是“1234567”，输入的账号也需要写明是什么账号，而不是写“输入正确的账号”，在别人测试过程中，是不知道什么才是正确的账号。如果这个账号不会变动（如管理员账号），则在测试数据中需写明“输入账号：admin，密码：123456”，如账号是常变动的（如用户账号），需在测试用例的前置条件中申明账号的可用性，如前置条件中写“系统存在账号为user123，密码为123456789的用户”，这时在测试数据中就可以写“试用账号user123，密码为123456789进行登录”。

总之，写测试用例的时候，注意仔细与严谨。时常检查自己写的测试用例别人是否也能看懂。小组中有多么测试人员的，需要时常对测试用例进行评审，从而保证测试用例的高质量。

BUG单

提交BUG也是一门功课，既要简单易读，又要能说明问题。所以需要在BUG单中写清楚复现的步骤，错误出现的频率，严重性和优先级，一个BUG单讲述一个问题，不可将多个问题写于同一篇BUG单中，BUG单中需注意语气，不得带有情绪，如果BUG存在争议，需要提供证据进行证明，如需求说明说，可以咨询需求人员，如果什么都没有可以参考行业软件规范。

我谈一下我在实际项目中遇到的一些问题，一次参加客户方关于提交BUG单规范的会议，发现了如下问题：

（1）客户方想只使用一个数值，来定义严重性和优先级。真是不应该的，严重性和优先级是两个不同的概念，严重性高的BUG不一定优先级就高，而严重性低的BUG很有可能优先级是最高的。如一个很少用的功能在一定的操作下会导致程序无响应，但是决定在下一个版本再进行修复，则它的严重性虽然是高，但是优先级确是低，而一个马上要投入使用的功能点中，页面上显示的标题不正确不影响使用，虽然严重性是低，但优先级确实高。像这样的情况使用一个数值便很难描述出BUG的严重情况和优先情况。

（2）客户方的部分测试人员认为一张表单上的3种不同类型的问题可以写在一个BUG单上。这也是不可以的，有时候虽然是一个页面上的，但有可能3个错误点是由3个不同的开发人员开发的。这时，让一个开发修改完成而两个开发未修改时，无法正确调整BUG单状态，导致测试进度收集也不完全，很难定位到还有多少问题需要修改。

（3）客户方将BUG的数量和测试人员的效益与开发员工的效益挂钩，这个在管理中也是万万不可以的。会导致大量BUG冗余；开发修改大量严重程度非常低的小BUG导致延缓整个项目的进度；很少有测试人员会花更多的时间去找难以发现的BUG；造成开发和测试之间如仇家等等的问题。

自动化

在进入公司后，客户方就交给了我一个非常艰巨的任务，要做现有系统的自动化测试平台。还好对QTP比较熟悉，到目前为止，已经写好BPM 1.0系统的自动化测试框架，和不少表单脚本，并将BPM 1.0的脚本经过修改后，复用至BPM 2.0版本。

如何进行自动化测试框架的搭建，我会在以后的文章中写明。

所以在这里，我说几点关于自动化测试的一些简单的知识和我的一些经验。很明显，自动化测试从字面上来理解，就是让电脑自动完成所需要的测试内容。如填写表单的测试，我可以预先将所要填写的内容写好，然后下班后，让电脑自动逐条进行填写，提交，记录测试的结果。看似很酷，但需要考虑的问题很多，最主要的是，需要有一定的编程基础，毕竟，脚本是要靠“写”的。在很多网友来信中发现，很多人对自动化的理解和自动化所能做的功能有一点偏差。主要有以下几点：

只要开发出强大的自动化测试脚本，就能将测试人员解放出来。其实不是的，很多的测试都是靠手工进行测试，自动化只是辅助。比如页面的排版是否好看，第一次测试时遇到的各种各样的问题，因为开发做了较大的改变等等一些问题时，自动化的执行就会失败。

对于需求会经常修改的系统如何进行自动化脚本的编写。对于这样需求会经常变动的系统，就不能开展自动化测试，还是老老实实的进行手工测试吧。

在软件测试理论知识还不是很牢固的情况下，不要进行自动化。对软件测试和自动化测试的错误理解会导致后期自动化进行十分的困难且根本没办法维护脚本。

在软件版本还没有稳定的情况下，不要进行自动化

领导不支持的情况下，不要进行自动化

系统中测试对象基本可以正常识别的情况下才进行自动化脚本的编写。

自动化测试一般的情况下是用来证明软件能正常运行，而不是用在证明软件这么操作一定会出错上。

记住，自动化测试最主要的是提高工作效率，正确的使用是，用1天开发一个脚本能用3个月的测试，而不是花3个月开发出一个很牛的脚本来测试1天，非常多初学者会范这个错误，我曾经也范过。

分析

学会分析数据也是软件测试中必要的一项。优秀的软件测试人员能通过各种数字，得到当前系统的各种信息。在性能测试中，分析数据显得尤为重要，一个做金融保险类系统性能测试的前辈和我说过，做性能测试，用使用Loadrunner，编写脚本设计场景，学的话几个月就能搞定，但是分析执行脚本后的数据，可能需要2-3年的工作经验，才能看到你想看到的信息。

说些简单常用的，通过分析BUG数据，就发现很多有用的信息。如：当系统刚刚开发完成，交给测试人员进行测试的时候，BUG数量一定是呈上升趋势，如果上升趋势不明显，一定是还没有做更完善的测试，说明需要投入更多的测试，随着测试的进行，BUG数量会成下降趋势，经过开发的几次调整，测试的几轮复测，BUG数量走势会在经过几次小波动后，趋于稳定，通过这些数字，就可以清楚的了解测试的进度，测试何时需要加强，何时可以退出，何时可以自动化的介入，何时可以开始进行性能测试压力测试等。

同样的BUG单的数据，通过BUG单上模块进行分类进行分析，会发现80%BUG会出现在20%的模块中，这也是经典的“二八原则”，对于拥有80%错误的20%模块，测试人员需要进行更多的测试，很有可能有更多的错误藏在这20%的模块中。这样可以划分出测试的轻重，从而能更加好的计划出测试投入的时间。

书写和演讲

测试人员平时会遇到很多需要书写文档的地方，如：测试计划文档、测试总结报告、测试用例、自动化测试用例、自动化测试报告、性能测试报告等，也需要开不少的会议，进行较多的报告演讲。这些也是一个测试人员不可缺少的素质。

我总结的经验就是：写报告要有理有据，图文并茂，提出一个点，需要给出足够的证据与分析过程来进行描述，而不是只写一个结论，要保证除测试人员外，开发、需求、架构人员也能从报告中，获取到相应的信息。至于演讲，尽量不要使用专有名词，简单明了，多做比喻，证据充足，由浅入深，才能让听的人接受你的观点，认同你的分析是正确的，能获得更多的帮助者与用户者，在日后的工作中，展开会更容易的多。

作为一名系统测试人员，还需要做到细心、耐心，多注意细节。平时也需要多做学习：系统的、网络的、软件的、硬件的、数据库的、语言的等等。总结也是必不可少的，把学到的、用到的知识，都记录下来，会对以后的工作带来非常多非常多的便利。

好了，也写了不少了，希望我写的东西，能对一些刚进入测试行业的、已进入测试行业的和一些像了解测试行业的一些开发一些帮助。

希望志同道合的朋友可以平时多交流，共同学习软件测试。

 欢迎志同道合之人一同学习。

QQ：370464196

Email：cydblack@163.com

陈永达

最近一直在更新和新增测试用例，对测试用例设计也有了更深的理解。以前写过关于测试用例设计方法方面的文章，这里就不介绍各个设计方法了。主要总结下测试用例设计思路及策略。

测试用例设计可以从两个思路入手：按功能点和按业务流。这两则的主要区别是一个是从单个功能点考虑进行测试用例设计，一个是从把各个功能点串联起来形成业务流方面考虑进行测试用例设计。当我们要对一个模块进行测试用例设计时，要首先分析该测试模块的特点及业务，确定是按功能设计测试用例好点，还是按业务流设计测试用例好点，还是一个为主，一个为辅？从功能点进行测试用例设计容易把各个模块独立出来，减小了各模块之间相互的影响，各模块之间的交互可能考虑的较少，但是我们提交给用户的是整个产品，各模块之间必然有数据交互，所以只从功能方面考虑是不足的，需要业务流做补充。我惯用的测试思路是先以功能点设计为主，就是以单个功能点作为设计切入点，覆盖到测试模块各个独立的单个功能点，然后用业务流进行补充，把各个功能点串起来。这样的好处是能够尽可能的覆盖测试模块的各个点及各个功能点之间的交互，借用一个前辈的话：“把每条业务流程比作竖线，功能线比作横线，那么功能点就是横线和竖线的节点，这样整个用例就是一张大网，我们可以随时向网中添加横线或竖线，使得覆盖率不断增加，“漏网之鱼”越来越小。”但是这种策略比较耗时。这里要考虑测试用例颗粒度问题，相信只要设计过测试用例的人员都考虑过这个问题，也是设计测试用例前必须要确定的问题，个人感觉测试用例的颗粒度取决于时间和可重用性。时间比较好理解，可重用性最好的例子就是多个build的项目。

其实关于按功能点或业务流进行测试用例的设计，我感觉是人为的划分，有时候想想一个流程走下来肯定完成的是一个功能，那这是不是从功能点考虑的体现呢？验证一个功能时，也应该是一系列操作，走多个业务，那这是不是业务流的体现呢？所以个人感觉设计测试用例时，非要说你是从业务流考虑的还是从功能点考虑的没有意义，有意义的就是设计出高水准的测试用例，而不是从语义上争得的死去活来（工作中遇到过），要有自己的设计思路。

最近设计测试用例发现使用思维导图是个不错的方法（强烈推荐使用），用思维导图罗列出测试点（从需求中提取），寻找思路及策略，编写测试用例，不断完善细化测试用例，扩大测试用例的覆盖面。

最近跟测试同行讨论，设计测试用例时经常遇到学习的测试用例设计方法应用不到实际的测试用例中。我也遇到过这个问题，现在测试用例设计中也存在这个问题，我们知道测试用例设计方法的目的就是减少测试用例，使测试活动处在可控的范围之内，但是这是有风险的，好多领导为了避免风险就要求我们尽可能的用穷尽的方法设计测试用例以及执行测试用例，遇到这种情况也没有办法，听领导的呗，但是有时你也会发现使用穷尽的笨方法可以发现使用减少测试用例的方法发现不了的问题以及相关的注意点，感觉这个对新员工特别有帮助，能够全面详细的了解一个产品。有时候想想要是我是领导，时间允许的情况下，我也会要求自己的组员尽可能的详细的测试产品，呵呵。当然也有些模块或者产品的确不需要使用测试用例设计方法，只需要考虑特殊场景即可。个人认为不应该让这些方法理论什么的束缚住自己的思维，不要为了使用而使用，也应该考虑测试模块特点，实际测试环境，时间等等。

Ps：今天看了下阅读器，发现订阅同行的博客有了不少更新，好久没有查看了，批评下自己，要多看看前辈的文章，扩展知识面，不给自己找借口。

最近一直在思考以下两个问题：

1.       每个项目每个Build测试执行过程中如何把握测试主线？

2.       哪些属于测试模块的主要功能？对于测试人员有哪些途径去积累判断测试模块的主要功能？

对于第一个问题，看起来很简单，但是执行起来不容易，有时即使对于有经验的测试人员也很容易在测试过程忽略掉每一轮测试的重点，陷入一个小模块进行详细测试，而忽略了对这轮测试总体测试侧重点的把握。所谓测试主线就是该轮测试我们的测试重点，如冒烟测试我们主要看测试模块主要功能在正常情况下能不能实现，影不影响项目进入系统测试；本地化测试时，当主要功能较稳定时，我们关注的更多的是字符，乱码，拼写，提示信息，标点等等是否已本地化；测试后期我们更多的是验证bug，而不是进行详细的系统测试。实际测试中，我经常看到同事对每轮的测试主线把握的不是太好，如我们公司对每个项目每轮测试都要进行冒烟测试，在冒烟测试问题反馈中，经常看到上报的有些小的控件问题，如按钮没有完全展示出来，输入框对特殊字符及快捷键没有做处理等，这些确实是问题，但是这不是我们进行冒烟测试的初衷；一个项目的最后一个Build有时会看到同事会提好多建议，提建议固然很好，但是我们应该清楚，最后一个Build测试重点一般主要放在验证上轮Bug上，对于建议应该在前几个Build来提，而不是最后一轮，因为最后一轮意味着项目要投向市场，面临着市场压力，即使提了建议，开发人员为了保持主要功能的稳定性及降低风险，一般也不会修改这些建议的。

那么我们如何知道每轮测试的侧重点？拿我们公司来说，每轮测试都会有更新文档和本轮测试重点描述的相关文档；如果没有这方面的文档，这时候就可以去询问测试项目负责人或测试执行负责人。当我们知道该轮测试重点后，结合测试时间，大致划分下每个时间段测试哪些模块，具体执行中牢记本来测试重点，从负责的整个测试模块来把握测试主线，尽量避免被一个小模块拖累了整个项目的测试进度。

关于第二个问题：哪些属于测试模块的主要功能？我的理解是这里的主要功能是由用户的使用频率和这个功能失效对用户的影响共同决定的，举个简单例子，我们经常提到的UI测试，一般UI的关注点在于美观性，控件类等问题，如进入tab页后信息的展示，这个对功能的使用没有影响（功能已经实现），但是用户进行相关操作时直接就可以看到这些信息如何的展示，用户看到和使用到的频率很高，如果信息的展示不是很好，就会直接影响用户对我们产品的使用信心。决定主要功能的是用户，所以对于测试人员有哪些途径去积累判断测试模块的主要功能也是从如何了解用户习惯展开的，总结了以下途径：

1、               直接与用户接触了解用户使用习惯，了解用户主要关注哪些模块，这些模块这些点就是我们所说的主要功能。（对于我们公司很少有这种机会）

2、               关于1是个很理想的状态，但是大多数情况下，我们测试人员是很少有机会接触到用户的。这个时候可以间隔性的请技术支持或者销售人员给我们介绍用户主要关注哪些模块及哪些问题的出现会使用户非常恼火以及现场问题收集等等，技术支持和销售人员对于用户的了解一般会比我们测试人员多。（这个途径也像老大建议过，但是一直没有做起来，导致现在对现场问题及用户习惯处在模模糊糊的状态）

3、               看需求，这里的需求有产品需求说明书和用户需求说明书，通过需求说明书我们就可以知道用户的需求，优先级等，这些也是我们判断是否是主要功能的依据。

4、               经验，这个主要就看我们对测试模块的熟悉程度。大家可能有这个经验，就是一个模块测试久了，对这个模块的总体把握，哪些相对重要在心里会有大致的区分，这个就要求我们在测试执行过程中，其他时间多了解我们的测试项目，哪些是主线，哪些是次线。（这种途径个人感觉存在一定风险，有时只是自我感觉是不是主要功能，实际上是不是-----）

5、               向以前测试该模块的测试人员学习，询问；向小组领导请教，一般测试领导对模块主要功能的把握比较准

6、               看产品使用说明书，当我们刚接手一个新模块时，还没有对该模块形成所谓的经验，这时候我们可以看看使用说明书，了解该模块，使用说明书一般是技术支持人员来写（我们公司如此，其它公司不太清楚），写的角度也可能是从用户角度出发，对我们对一个模块主要功能的判断有一定的启示意义。

一年回顾：

去年7月4号入职到现在已经有一年零2个月了，一直想写下一年工作回顾及总结，但是每次打开文档时总是以各种理由推后，一来是想写的太多但是又不知从哪里写起，二来是总想把自己的一年工作经历写的真实好看一点，以至于推到现在才写这个总结及回顾，昨天一个大学玩的比较好的同学跟我讲起了他的创业，我也趁今天好好回顾总结下过去的一年，想到哪就写到哪吧。

本人是自动化专业，踏入测试这个行业还得从大学计算机四级说起，大学有大量的空闲时间，于是就问学长考什么证有用，也为毕业找个好工作做准备，学长告诉我测试是个新兴的职位，考软件测试工程师对以后进入这个领域很有帮助，于是就报考了计算机四级（软件测试工程师），最后也顺利拿到证书；正是因为考这个证对软件测试有了基本的认识，但是这些认识只是理论知识的了解，实际的测试技能几乎为0。大四开始找工作，因为大三去一家公司当技术员实习生，对本专业的行业实在不敢兴趣（主要还是不喜欢进车间听大型机器的声音，呵呵呵），在干净的办公室对着电脑工作一直是我所向往的，也自认比其他应届生对测试领域多了解一些，就有意无意的投软件测试这个职位，。找工作很顺利（得意一下），拿到的offer也很多，有格力，华为，美的，科大讯飞，京东方，最后经过多方面考虑去了科大讯飞。在科大讯飞实习一个月，让我学到了很多，更关键的是认识了现在的女朋友，呵呵呵。科大讯飞的测试有点像敏捷测试流程，主要进行集成测试，测接口，使用各种脚本语言，给我印象最深刻的是在实习期间，我们部门老大跟我讲：我们公司的自动化程度已经达到100%，当时不是太明白，现在想起来感觉有点吹嘘，更有点扯。因为这个公司是个快速发展中的公司（公司总测试人员有150人左右，测试人员规模还是很大的），所以对新人来说进步很快，这个快主要是我根据我与女朋友比较得出的，我们两个都是去年毕业的，现在她能熟练掌握性能测试，功能自动化测试以及对整个测试项目的把控，现在她自己也带了几个小弟，独立负责一个产品线的测试。想想刚刚毕业一年就可以负责一个产品线的测试，在我现在的公司里几乎是不可能的。听女朋友讲天天加班，导致离职率很高。后来因为找到了工资更高的公司，于是就跳到现在的公司。

在现在的公司主要负责平台系统测试，B/S和C/S架构的都测，但是主要以web测试为主，包括系统测试，稳定性测试，性能测试。刚来公司负责的第一件事情就是测试环境维护，首先是装系统，大学都是用系统集成盘来装，像驱动什么的都不要自己动手去下，但是测试需要一个纯净的操作系统，要用纯净的系统盘装好系统，然后根据PC机主板及网卡，显卡，声卡，芯片组等去下载相应的驱动安装，这些听起来很简单也很容易，但是要是同时管理40台左右的PC机就不那么简单了，于是去学习系统备份，恢复，封装，再把备份的镜像做个备份中心集中起来管理；为防止病毒感染影响测试及杀毒软件与测试项目的兼容性问题，采用共享及U盘禁用方法解决，测试中跑出问题学习判断是不是环境引起的（有些PC机很老了），如果是机器的问题判断是什么问题引起的：虚拟内存不足，配置不够，内存条有问题，显卡坏了等等。因为长期进行测试环境搭建，也掌握了哪些测试机适合进行哪方面的测试，测试环境搭建需要注意哪些问题，什么样的测试需要什么样的环境等，现在组内所有项目测试环境基本上都是我搭建的，对于测试过程中遇到的环境问题现在自己也基本能搞定，最近重新学习操作系统相关知识，希望对操作系统有更深入的认识。

一年来看过的书也有20来本吧，学习的东西很泛，但是都不是很深入，这个可能跟大学没有掌握相关知识有关，学习了计算机网络，操作系统，数据库，HTML以及测试中需要的一些知识技能：需求评审， 需求分析，需求提取，测试分析，测试用例设计以及测试执行，缺陷跟踪，对探索式测试，安全测试，稳定性测试，性能测试，自动化测试也了解一些；这些知识的学习基本上都是自己工作之余自学的，实际工作中学到的业务知识很多，但是要是讲到纯技术方面的不是很多。一年的工作经历让我对测试和工作认识很多，测试被认为是没有技术含量的工作，这个有没有技术含量不是别人定义的，是我们自己定义的，如我经常鼓励自己的话就是：我们发现bug，开发人员修改bug，开发人员可以用不同的方法修改bug，我们也可以用不同的方法发现bug，天天点点鼠标，只要你能点出bug，点出别人不能发现的bug，你就是一个好的tester；软件中不是没有bug，只是我们还没有找到发现bug 的方法。一年来对测试项目各个阶段的把握和掌握很有自己的心得，如需求提取方法，测试点分析，测试用例设计以及具体执行过程中注意的问题，bug上报注意事项等等，也许好多人会说这些是一个测试人员最基本的要求，但是并不是每个人都会对自己的测试方法进行改进，测试过程进行优化。

一直以来都想把新学习到的知识运用到实际测试中，向领导建议整个组的测试流程改进，现场问题收集，测试用例的更新简化（公司的测试用例设计几乎用的都是穷尽的方法），增加数据库测试等等，但是一直没有做起来，有时候明明知道这样做能够更好的进行测试，更有实际意义，也更有效率但是就是不做，真不理解。

最近也一直在反思自己一年的表现，感觉一年来进步是进步了，但是技术的提升没有想象的那么快，有时候真的很急。但是想想技术本来就是一个积累的过程，不可能一蹴而就，需要自己坚持积累，坚持学习，不断总结，调整好自己的心态，工作中要学习的还很多，需要自己用心去发现问题，去学习优秀员工良好的测试心态，为人处事的心态，慢慢的把自己沉淀下来，去除测试小生的鲁莽向心态沉稳的测试大牛迈进。

一年总结：

优点：

1、    经常逛测试论坛和QQ测试交流群，跟同行交流，了解测试领域新技术

2、    每天保持阅读书籍的习惯，学习新的技术，引入到实际测试中

3、    善于总结，反思自己的测试方法及建立适合自己的测试方法

4、    能够按照设定目标坚持学习、

不足：

1、    心态还不是太成熟，需要提高，不要把什么事情都写在脸上，不要什么话都说

2、    与老员工的交流不够，没有充分利用什么资源学习测试技巧

3、    学习的东西泛而不深，需要深入某一方面学习

需要牢记：

1、    不在其位不谋其政

2、    说话张弛有度

3、    学习的东西为现在所用，不要为跳槽做准备

4、    不被嘲笑的梦想是不值得追逐的，加油

感觉这篇文章不错，针对发现的一个问题是不是bug时的一些解决方法，值得学习，就以原创形式转载，请大家见谅，也谢谢作者Tester Chen分享。

随着软件行业的快速发展，以及客户、市场的高要求，软件本身的复杂度、要求不断提高。这一现象也直接导致以前只有大中型公司才配备的测试人员，现在在越来越来越多的小型公司也开始出现。
小公司测试人员的出现，一方面是为了适应产业的发展需求；另一方面也是为了提升产品质量、加强公司的竞争力，保证公司不被市场所淘汰。但这样一来也就直接增加了公司的管理、人力及资金成本（测试人员的薪水虽然相对比开发人员低，但也是一个不小的数字）；最后因为小公司制度及管理的欠缺，暴露出很多问题，往往直接或间接的导致开发、和测试的不和谐，这也是我们今天讨论的话题。

这个是缺陷！这个不是缺陷！
对于是不是缺陷这个话题往往被很多人很厌恶，大家都厌恶谈论这个话题，因为谈及他往往令人不愉快，但很多的时候他却在我们身边真实发生。
测试人员认为某个情况是缺陷，但开发人员认为这个不是缺陷，而争论具体的情形在需求中也没有明确的描述，公说公有理，婆说婆有理，说不清了！如果只是开发、测试对于工作上理解的差异还好，但往往争执由此开始，矛盾也就由此产生，不和谐的气氛由此埋下种子。

出现上述的情况的原因有几种：
①公司在没有对原始需求进行评审、整理、并书面化形成文档（需求也是需要测试的，这点很重要）
②公司完全没有需求这一档子事，完全在没有需求的情况下进行开发、测试（走一步看一步的情况）
③开发、测试对需求的理解存在差异（开发、测试没有良好的沟通）
④需求本身的定义存在二义性（与①相关，没有对需求进行测试）
⑤个人的性格与情绪

问题出现了，如何解决？
不管是开发人员还是测试人员：
①思想要保持统一的认知，我们所做的都是为了公司，为了我们的产品，任何的争论都不存在任何的个人感情与感情色彩
②出现问题时，都要先从自身找原因，很多时候往往是因为我们自己的简单思维而导致，所以，当你在工作中对某个事情存在疑问时，多问自己几个为什么，再向他人请教，或回复他人
③我们讨论的只是问题，不直接关系到个人的工作能力与工作作风，人非圣贤，有错就改，并不失面子

当无法确认是否为缺陷时，测试人员：
①发现无法确认的缺陷时，如果有其他的测试人员可以征求其他测试人员的意见（同行评审，同行评审往往能发现80%的问题），如果彼此都认为此应该是缺陷时，可以找到相应的开发人员进行讨论。如果开发人员同意你们的意见，则可以提交缺陷，着手修复（如涉及比较重大的业务逻辑时应该要向上级汇报，申请确认）
②如果开发（甚至多位开发人员）对缺陷不认可时，我们可以向测试组长（或测试总监）请教，请求对缺陷进行确认，如果领导和开发人员都认为此不是缺陷，并且无修复的必要时，我们可以保留我们的意见，同时记录下此缺陷（到后期如果有时间再进行评审）
③如果测试组长（或测试总监）也认为此是缺陷，但在无论如何解释的情况下开发人员仍不认可时，我们可以由测试组长（测试总监）与开发项目经理（技术经理）进行交涉、确认，最终确认缺陷情况
④如果有必要，我们可以邀请开发、测试、需求（如果有）、产品（如果有），甚至技术总监（CTO）进行开会（需求或缺陷）评审
⑤最后，也是最重要的一条，不管是开发，还是测试，都不要越级汇报

另外，有部分许多公司把缺陷作为开发人员和测试的员的业绩指标，在某些大公司这些确实是在施行、也是可行的，但在中小型公司或管理达不到CMMI4或5的情形时，我个人不赞同那样的作法。因为你不是他，你就做不到他……
而你那样做产生的直接结果就是让开发和测试从此不和谐，彼此勾心斗角，何必呢？！

最后，要相信办法总是比问题多，每一个问题都有至少一个解决办法！

原文链接：http://www.cnblogs.com/hncjp1989/archive/2012/04/14/2447533.html

搭建良好的测试环境是执行测试用例的前提，也是完成测试任务顺利完成的保证。测试环境大体可分为硬件环境和软件环境，硬件环境包括测试必须的PC机，服务器，设备，网线，分配器等硬件设备；软件环境包括数据库，操作系统，被测试软件，共存软件等；特殊条件下还要考虑网络环境，比如网络带宽，IP地址设置等。

搭建测试环境前后要注意以下几点：

1> 搭建测试环境前，确定测试目的

即是功能测试，稳定性测试，还是性能测试，测试目的不同，搭建测试环境时应注意的点也不同。比如要进行功能测试，那么我们就不需要大量的数据，需要覆盖率高，测试数据要求尽量真实，这对硬件环境配置的好坏要求不是太苛刻，为提高覆盖率，就要配置不同的硬件环境。如要进行性能测试，就需要大量的数据，测试数据应尽可能的达到符合实际的数据分配，这时可能需要大量的设备来给测试对象施加压力，要提前准备大量设备。

2> 测试环境时尽可能的模拟真实环境。

这个要求对测试人员要求很高，因为很多测试人员没有去过用户使用现场，要完全模拟用户使用环境根本不可能。这时我们就应该通过技术支持人员，销售人员了解，尽可能的模拟用户使用环境，选用合适的操作系统和软件平台，了解符合测试软件运行的最低要求及用户使用的硬件配置，了解用户常用的软件，避免所有配置所有操作系统下都要进行测试，没有侧重点，浪费时间。这样一方面，可以在测试执行过程中发生软件产品与其他协同工作产品之间的兼容性，避免软件发布给用户之后才发现的问题；另一方面也可以用来检验产品是不是用户真正需要的。多说情况下，测试环境都是真空环境，完全纯净的平台，测试时，没有问题，一旦拿到现场，与其它软件并存，硬件配置等原因，问题多多，这个就是搭建测试环境时没有考虑用户的使用环境。

3>确保无毒环境

我测试过几个项目都是因为搭建的测试环境感染病毒，导致测试软件经常出现莫名的崩溃，运行不起来等现象，导致测试中断。这是杀毒是必要的，但是杀毒的时间也应掌握好，具体可按照下列步骤：选择PC机-à安装操作系统—>安装杀毒软件杀毒—>安装驱动程序及用户常用软件及浏览器à杀毒à安装测试软件—>杀毒，安装测试软件后杀毒，要注意如果我们不是使用正版杀毒软件，很可能我们安装的测试软件的一些文件被当做可疑文件或者病毒被清除，导致测试软件直接不可用。要确保杀毒软件正版，如果不是正版，建议在安装测试软件前，卸载掉杀毒软件。测试过程中，要注意U盘的使用以及测试环境与外网的控制。每次使用U盘前，要在其它机器上先杀毒；当测试环境与外网联通时，不建议使用共享方式互访测试机。当小范围PC机与外界隔离起来做测试环境时，可以禁掉可移动存储设备的使用，只允许一台PC使用，这台PC机上安装杀毒软件，进行资料传送时，先拷贝到这台机器上杀毒，然后以共享的方式进行资料的传送。经过这些措施可以很好的防止病毒感染测试环境，确保无毒环境。

4>营造独立的测试环境

测试过程中要确保我们的测试环境独立，避免测试环境被占用，影响测试进度及测试结果，比如设备连网后，是不是其他测试组也在共用，这样就可能影响我们的测试结果。有时开发人员为确定问题会使用我们的测试环境，这样会打乱我们的测试活动，更严重的是影响测试进度。为避免这种情况，测试人员在提交缺陷单时，提供详细的复现步骤以及尽可能多的信息。让开发人员根据缺陷单，在开发环境中复现和定位问题。

5>构建可复用的测试环境

  当我们刚搭建好测试环境，安装测试软件之前及测试过程中，对操作系统及测试环境进行备份是必要的，这样一来可以为我们下轮测试时直接恢复测试环境，避免重新搭建测试环境花费时间，二来在当测试环境遭到破坏时，可以恢复测试环境，避免测试数据丢失，重现问题。构建可“复用”的测试环境，往往要用到如ghost、Drive Image等磁盘备份工具软件;这些工具软件，主要实现对磁盘文件的备份和还原功能;在应用这些工具软件之前，我们首先要做好以下几件十分必要的准备工作：

A．确保所使用的磁盘备份工具软件本身的质量可靠性，建议使用正版软件;

B．利用有效的正版杀毒软件检测要备份的磁盘，保证测试环境中没有病毒

C. 对于在测试过程中备份时，为减少镜像文件的体积，要删除掉Temp文件夹下的所有文件，要删除掉Win386.swp文件或_RESTORE文件夹，这样C盘就不至于过分膨胀，选择采用压缩方式进行镜像文件的创建，可使要备份的数据量大大减小;

D. 最后，再进行一次彻底的磁盘碎片整理，将C盘调整到最优状态。

对于刚安装的操作系统，驱动程序等安装完成之后，测试程序安装之前，也要进行备份工作，这样可以防止不同项目交叉进行时，当使用相同操作系统时，直接恢复即可。

完成了这些准备工作，我们就可以用备份工具逐个逐个的来创建各种组合类型的软件测试环境的磁盘镜像文件了。对已经创建好的各种镜像文件，要将它们设成系统、隐含、只读属性，这样一方面可以防止意外删除、感染病毒;另一方面可以避免在对磁盘进行碎片整理时，频繁移动镜像文件的位置，从而可节约整理磁盘的时间;同时还要记录好每个镜像文件的适用范围，所备份的文件的信息等内容。

上一篇介绍局部探索式测试主要是帮助测试人员在执行测试用例时或者无测试用例时动态进行各式各样的局部决定，面对的是测试对象的一个测试点或者小的测试模块。这篇主要介绍全局探索式测试法，主要关于测试人员在全局方面所必须做出的各种决定，做出全局目标，用于指导以后的测试过程。

我们知道探索式测试的目标是：

1》  找出缺陷

2》  强迫软件展现其能力

3》  证明软件实现了哪些功能

Whittaker又把全局探索式测试叫做漫游测试，把我们测试对象，比喻成我们将要旅游

的一个城市。根据我们要访问城市各区域的目的，把城市各区域有分为：商业区，历史区，娱乐区，旅游区，旅馆区和破旧区。相应的把我们的测试对象，根据各模块的功能及特性，分为：商业区测试类型，历史区测试类型，娱乐区测试类型，旅游区测试类型，旅馆区测试类型和破旧区测试类型。

商业区测试类型：

对于测试来讲，商业区就是软件的启动及关闭代码之间，并包含用户所要使用的软件特性和功能，侧重于测试对象的主要功能及特性。

主要测试方法有：

1》               指南针测试法：主要要求测试人员通过阅读用户手册，场景及产品需求进行相关的测试

2》               卖点测试法：对那些能够吸引用户的特性进行测试，至于哪些特性能够吸引用户，可以向销售人员咨询，或者拜访客户。

3》               地标测试法：主要是寻找测试点，明确测试项，这里的测试点就是地标

4》               极限测试法

5》               快递测试法：要求测试人员专注于数据，即数据从输入到输出展现给客户或页面过程中，数据执行的流程。了解一个测试输入项输入后，经过哪些流程后展现给用户的，这些流程能否正确执行。

6》               深夜测试法：当我们不对测试对象操作时，测试对象能否会自动完成各种维护任务，将数据归档，自动记录发生的异常情况等

7》               遍历测试法：通过选定一个目标 ，然后使用可以发现的最短路径来访问目标包含的所有对象。测试中不要求追求细节，只是检查哪些明显的东西。

历史区测试类型：

指遗留的代码，或者在前几个版本就已经存在的软件特性，也指那些用于修复已知缺陷的代码，侧重于老的功能和缺陷修复代码。

1》  恶邻测试法：对bug扎堆的地方进行遍历测试法及详细测试。

2》  上一版测试法：检查那些在新版本中无法再运行的测试用例，以确保产品没有遗漏必需的功能。

3》  博物馆测试法：重视老的可执行文件和那些遗留代码。

娱乐区测试类型：

在测试那些辅助特性。

1》               配角测试法：测试中调节自己的测试注意力，使测试细化，具体，确保配角得到应有的重视。

2》               深巷测试法：测试最不可能被用到或是那些最不吸引用户的特性。

3》               通宵测试法：这个方法很容易和深夜测试法混淆，但是测试侧重点不同，深夜测试法是测试测试对象的自动处理能力；而通宵测试法是测试软件的长时间运行后，各功能模块是否正常，有点像稳定性测试。

旅游区测试类型：

快速访问测试对象的各种功能。有点像遍历测试法

1》               收藏家测试法：收集执行一个测试点后的所有输出。确保能观察到软件生成的任何一个输出。

2》               长路径测试法：确定测试目标，在到达目的地之前尽量多地在应用程序中穿行。把埋在应用程序最深处的界面作为测试目标。

3》               超模测试法：GUI测试

4》               测一送一测试法：测试同一个应用程序多个拷贝的情况。测试程序同时处理多个功能要求时，是否正常，各功能之间同时处理时，是否会相互影响。

5》               苏格兰酒吧测试法：花一些时间参与用户之间的讨论，了解测试对象所处行业信息，深入理解测试对象。

旅馆区测试类型：

测试那些经常被忽略和测试计划中较少描述的次要及辅助功能。

1》  取消测试法：启动相关操作，然后停止它。查看测试对象的处理机制及反应。

如：esc键，取消键，回退键，shift+F4，关闭按键或者彻底关闭程序（从任务管理器中杀进程），重复同一个操作。

2》  懒汉测试法：做尽量少的实际工作，让程序自行处理空字段及运行所有默认值。这个有点像深夜测试法。

破旧区测试类型：

对于这个区域的测试模块，就是输入恶意数据，破坏软件，修改配置文件等。

1》  做一个破坏者，测试各种异常情况

2》  反叛测试法：输入最不可能的数据，或者已知的恶意输入

又分为：逆向测试法，歹徒测试法，错序测试法

3》  强迫症测试法：重复测试

终于介绍完了全局探索式测试法，测试中运用这种方法，可以使我们的测试更有趣，更有针对性，指导性。确定测试对象那个对象用那个测试法，将测试对象功能与测试技术方法结合起来，达到匹配平衡。特别是针对升级版本项目，要给予持续关注，刚开始时，运用各种测试法，然后跟踪，找出各模块哪个测试法最有效，可以以发现的bug数来衡量测试法的有效度，这样在接下来的版本测试中，可以更有效更有针对性的去执行测试方法，提高测试质量和效率，再辅以其他测试法提高测试覆盖率。这需要测试人员的用心观察，总结，经验很重要。

什么是探索式测试？

简单的说就是: 测试人员根据应用程序所提供的信息自由发挥，不受限制，不受任何约束的探索程序的各种功能。主要强调测试人员个人自由和责任的测试方法。

探索式测试的缺点是：测试人员可能在测试过程中没有重点，有些模块可能会重复测试，而有些会遗漏掉。

这时必要的指导方法显得尤为重要，在指导方法的引导下，我们测试人员在测试过程中应时刻明确到底要测什么，实现什么功能。

也就是说探索式测试是强化用户使用场景，测试过程多种多样，各种途径，各种方法，但是测试的目标要明确，测试程序的什么功能。

探索式测试的指导方法主要有局部探索式测试法和全局探索式测试法，这里主要介绍局部探索式测试法。

局部探索式测试法是辅助测试人员在测试执行测试中即时做出决定，注重测试中如何做抉择，应注意的测试细节等。

局部探索式测试法在测试过程中应用应注意事项：

1.   用户输入

      细节注意点：

1>   开发人员喜欢编写正常功能代码，不喜欢编写错误处理代码。测试过程中应关注在错误输入发生时，应用程序的处理机制。

2>   仔细阅读每一条错误提示信息，使用提示信息来引导测试深入

3>  对于输入筛选器，检查是否实现了正常的功能，是否可以绕过屏蔽器等

4>  对于空泛的通用错误提示信息，要反复测试相关模块，继续使用刚才引发异常的输入数据或者小修改，查看程序运行状况

5> 合法输入和非法输入，常规输入和非常规输入，一般字符和特殊字符

 注：所有和ctrl，alt，esc等按键组合的字符都算特殊字符；每一个操作系统，编程语言，浏览器和运行时环境都会有一些特定的保留词，他们具有特殊的含义，对于测试输入框，应键入这些保留词。如widows下就有一些保留的设备名称：LPT1，COM1，AUX等。

6> 默认输入和用户输入   可以进行默认值得删除，留下一个空白字段，查看程序处理机制

7> 学会使用输出指导输入

2.代码路径

3.用户数据

     细节注意点： 1> 测试中药在很短的时间内，模拟产生实际使用时的大量数据

                       2> 尽量逼真的模拟用户数据的相互关系和结构

                      3>注意“用户隐私”的问题

4.运行环境

1、请你自我介绍一下自己好吗？
回答提示：一般人回答这个问题过于平常，只说姓名、年龄、爱好、工作经验，这些在简历上都有。其实，企业最希望知道的是求职者能否胜任工作，包括：最强的技能、最深入研究的知识领域、个性中最积极的部分、做过的最成功的事，主要的成就等，这些都可以和学习无关，也可以和学习有关，但要突出积极的个性和做事的能力，说得合情合理企业才会相信。企业很重视一个人的礼貌，求职者要尊重考官，在回答每个问题之后都说一句“谢谢”，企业喜欢有礼貌的求职者。
2、你觉得你个性上最大的优点是什么？
回答提示：沉着冷静、条理清楚、立场坚定、顽强向上、乐于助人和关心他人、适应能力和幽默感、乐观和友爱。我在北大青鸟经过一到两年的培训及项目实战，加上实习工作，使我适合这份工作。
3、说说你最大的缺点？
回答提示：这个问题企业问的概率很大，通常不希望听到直接回答的缺点是什么等，如果求职者说自己小心眼、爱忌妒人、非常懒、脾气大、工作效率低，企业肯定不会录用你。绝对不要自作聪明地回答“我最大的缺点是过于追求完美”，有的人以为这样回答会显得自己比较出色，但事实上，他已经岌岌可危了。企业喜欢求职者从自己的优点说起，中间加一些小缺点，最后再把问题转回到优点上，突出优点的部分，企业喜欢聪明的求职者。
4、你对薪资的要求？
回答提示：如果你对薪酬的要求太低，那显然贬低自己的能力；如果你对薪酬的要求太高，那又会显得你分量过重，公司受用不起。一些雇主通常都事先对求聘的职位定下开支预算，因而他们第一次提出的价钱往往是他们所能给予的最高价钱，他们问你只不过想证实一下这笔钱是否足以引起你对该工作的兴趣。
回答样本一：我对工资没有硬性要求，我相信贵公司在处理我的问题上会友善合理。我注重的是找对工作机会，所以只要条件公平，我则不会计较太多。
回答样本二：我受过系统的软件编程的训练，不需要进行大量的培训，而且我本人也对编程特别感兴趣。因此，我希望公司能根据我的情况和市场标准的水平，给我合理的薪水。
回答样本三：如果你必须自己说出具体数目，请不要说一个宽泛的范围，那样你将只能得到最低限度的数字。最好给出一个具体的数字，这样表明你已经对当今的人才市场作了调查，知道像自己这样学历的雇员有什么样的价值。
5、你对加班的看法？
回答提示：实际上好多公司问这个问题，并不证明一定要加班，只是想测试你是否愿意为公司奉献。
回答样本：如果工作需要我会义不容辞加班，我现在单身，没有任何家庭负担，可以全身心的投入工作。但同时我也会提高工作效率，减少不必要的加班。
6、如果通过这次面试我们录用了你，但工作一段时间却发现你根本不适合这个职位，你怎么办？
回答提示：一段时间发现工作不适合我，有两种情况：①如果你确实热爱这个职业，那你就要不断学习，虚心向领导和同事学习业务知识和处事经验，了解这个职业的精神内涵和职业要求，力争减少差距；②你觉得这个职业可有可无，那还是趁早换个职业，去发现适合你的，你热爱的职业，那样你的发展前途也会大点，对单位和个人都有好处。
7、谈谈你对跳槽的看法？
回答提示：①正常的“跳槽”能促进人才合理流动，应该支持。②频繁的跳槽对单位和个人双方都不利，应该反对。
8、工作中难以和同事、上司相处，你该怎么办？
回答提示：①我会服从领导的指挥，配合同事的工作。②我会从自身找原因，仔细分析是不是自己工作做得不好让领导不满意，同事看不惯。还要看看是不是为人处世方面做得不好，如果是这样的话我会努力改正。③如果我找不到原因，我会找机会跟他们沟通，请他们指出我的不足，有问题就及时改正。④作为优秀的员工，应该时刻以大局为重，即使在一段时间内，领导和同事对我不理解，我也会做好本职工作，虚心向他们学习，我相信，他们会看见我在努力，总有一天会对我微笑的。
9、你对于我们公司了解多少？
回答提示：在去公司面试前上网查一下该公司主营业务。如回答：贵公司有意改变策略，加强与国外大厂的OEM合作，自有品牌的部分则透过海外经销商。
10、最能概括你自己的三个词是什么？
回答提示：我经常用的三个词是：适应能力强，有责任心和做事有始终，结合具体例子向主考官解释，
11、你的业余爱好是什么？
回答提示：找一些富于团体合作精神的，这里有一个真实的故事：有人被否决掉，因为他的爱好是深海潜水。主考官说：因为这是一项单人活动，我不敢肯定他能否适应团体工作。
12、作为被面试者给我打一下分？
回答提示：试着列出四个优点和一个非常非常非常小的缺点（可以抱怨一下设施，没有明确责任人的缺点是不会有人介意的）。
13、你为什么要离开原来的公司?
回答提示：①回答这个问题时一定要小心，就算在前一个工作受到再大的委屈，对公司有多少的怨言，都千万不要表现出来，尤其要避免对公司本身主管的批评，避免面试官的负面情绪及印象。建议此时最好的回答方式是将问题归咎在自己身上，例如觉得工作没有学习发展的空间，自己想在面试工作的相关产业中多加学习，或是前一份工作与自己的生涯规划不合等等，回答的答案最好是积极正面的。②我希望能获得一份更好的工作，如果机会来临，我会抓住。我觉得目前的工作，已经达到顶峰，即沒有升迁机会。
14、你欣赏哪种性格的人？
回答提示：诚实、不死板而且容易相处的人、有“实际行动”的人。
15、你通常如何对待别人的批评？
回答提示：①沈默是金，不必说什么，否则情况更糟，不过我会接受建设性的批评。②我会等大家冷靜下来再讨论。
16、怎样对待自己的失败？
回答提示：我们大家生来都不是十全十美的，我相信我有第二个机会改正我的错误。
17、你为什么愿意到我们公司来工作？
回答提示：对于这个问题，你要格外小心，如果你已经对该单位作了研究，你可以回答一些详细的原因，像“公司本身的高技术开发环境很吸引我。”、“我同公司出生在同样的时代，我希望能够进入一家与我共同成长的公司。”、“你们公司一直都稳定发展，在近几年来在市场上很有竞争力。”、“我认为贵公司能够给我提供一个与众不同的发展道路。”这都显示出你已经做了一些调查，也说明你对自己的未来有了较为具体的远景规划。
18、对这项工作，你有哪些可预见的困难？
回答提示：①不宜直接说出具体的困难，否则可能令对方怀疑应聘者不行。②可以尝试迂回战术，说出应聘者对困难所持有的态度——工作中出现一些困难是正常的，也是难免的，但是只要有坚忍不拔的毅力、良好的合作精神以及事前周密而充分的准备，任何困难都是可以克服。
19、如果录用了你，你将怎样开展工作？
回答提示： ①如果应聘者对于应聘的职位缺乏足够的了解，最好不要直接说出自己开展工作的具体办法。②可以尝试采用迂回战术来回答，如“首先听取领导的指示和要求，然后就有关情况进行了解和熟悉，接下来制定一份近期的工作计划并报领导批准，最后根据计划开展工作。”。
分析：这个问题的主要目的也是了解应聘者的工作能力和计划性、条理性，而且重点想要知道细节。如果向思路中所讲的迂回战术，面试官会认为回避问题，如果引导了几次仍然是回避的话，此人绝对不会录用了。
20、你希望与什么样的上级共事？
回答提示：①通过应聘者对上级的“希望”可以判断出应聘者对自我要求的意识，这既上一个陷阱，又是一次机会。②最好回避对上级具体的希望，多谈对自己的要求。③如“做为刚步入社会的新人，我应该多要求自己尽快熟悉环境、适应环境，而不应该对环境提出什么要求，只要能发挥我的专长就可以了。
分析：这个问题比较好的回答是，希望我的上级能够在工作中对我多指导，对我工作中的错误能够立即指出。总之，从上级指导这个方面谈，不会有大的纰漏。
21、与上级意见不一时，你将怎么办？
回答提示：①一般可以这样回答“我会给上级以必要的解释和提醒，在这种情况下，我会服从上级的意见。”②如果面试你的是总经理，而你所应聘的职位另有一位经理，且这位经理当时不在场，可以这样回答：“对于非原则性问题，我会服从上级的意见，对于涉及公司利益的重大问题，我希望能向更高层领导反映。”
分析：这个问题的标准答案是思路①，如果用②的回答，必死无疑。你没有摸清楚改公司的内部情况，先想打小报告，这样的人没有人敢要。
22、为什么选择我们公司？
回答提示：曾经在报章杂志看过关于贵公司的报道，与自己所追求的理念有志一同。而贵公司在业界的成绩也是有目共睹的，而且对员工的教育训练、升迁等也都很有制度。
分析：去面试前先做功课，了解一下该公司的背景，让对方觉得你真的很有心想得到这份工作，而不只是探探路。
23、谈谈如何适应办公室工作的新环境？
回答提示①办公室里每个人有各自的岗位与职责，不得擅离岗位。②根据领导指示和工作安排，制定工作计划，提前预备，并按计划完成。③多请示并及时汇报，遇到不明白的要虚心请教。④抓间隙时间，多学习，努力提高自己的政治素质和业务水平。
24、除了本公司外，还应聘了哪些公司？
回答提示：很奇怪，这是相当多公司会问的问题，其用意是要概略知道应徵者的求职志向，所以这并非绝对是负面答案，就算不便说出公司名称，也应回答“销售同种产品的公司”，如果应聘的其他公司是不同业界，容易让人产生无法信任的感觉。
25、你还有什么问题要问吗？
回答提示：企业的这个问题看上去可有可无，其实很关键，企业不喜欢说“没问题”的人，因为其很注重员工的个性和创新能力。企业不喜欢求职者问个人福利之类的问题，如果有人这样问：贵公司对新入公司的员工有没有什么培训项目，我可以参加吗？或者说贵公司的晋升机制是什么样的？企业将很欢迎，因为体现出你对学习的热情和对公司的忠诚度以及你的上进心。
26、如果你被录用，何时可以到职？
回答提示：大多数企业会关心就职时间，最好是回答“如果被录用的话，到职日可按公司规定上班”，但如果还未辞去上一个工作、上班时间又太近，似乎有些强人所难，因为交接至少要一个月的时间，应进一步说明原因，录取公司应该会通融的。

4.6 组合测试

最后需要进行组合测试。600x800 的分辨率在 MAC 机上可能不错，但是在 IBM 兼容机上却很难看。在 IBM 机器上使用 Netscape 能正常显示，但却无法使用 Lynx 来浏览。如果是内部使用的 web 站点，测试可能会轻松一些。如果公司指定使用某个类型的浏览器，那么只需在该浏览器上进行测试。如果所有的人都使用 T1 专线，可能不需要测试下载施加。(但需要注意的是，可能会有员工从家里拨号进入系统) 有些内部应用程序，开发部门可能在系统需求中声明不支持某些系统而只支持一些那些已设置的系统。但是，理想的情况是，系统能在所有机器上运行，这样就不会限制将来的发展和变动。

采取措施：根据实际情况，采取等价划分的方法，列出兼容性矩阵

5 安全测试

即使站点不接受信用卡支付，安全问题也是非常重要的。Web 站点收集的用户资料只能在公司内部使用。如果用户信息被黑客泄露，客户在进行交易时，就不会有安全感。

5.1 目录设置

Web 安全的第一步就是正确设置目录。每个目录下应该有 index.html 或 main.html 页面，这样就不会显示该目录下的所有内容。我服务的一个公司没有执行这条规则。我选中一幅图片，单击鼠标右键，找到该图片所在的路径"…com/objects/images"。然后在浏览器地址栏中手工输入该路径，发现该站点所有图片的列表。这可能没什么关系。我进入下一级目录 "…com/objects" ，点击 jackpot。在该目录下有很多资料，其中引起我注意的是已过期页面。该公司每个月都要更改产品价格，并且保存过期页面。我翻看了一下这些记录，就可以估计他们的边际利润以及他们为了争取一个合同还有多大的降价空间。如果某个客户在谈判之前查看了这些信息，他们在谈判桌上肯定处于上风。

5.2 SSL

很多站点使用 SSL 进行安全传送。你知道你进入一个 SSL 站点是因为浏览器出现了警告消息，而且在地址栏中的 HTTP 变成 HTTPS。如果开发部门使用了SSL，测试人员需要确定是否有相应的替代页面(适用于3.0 以下版本的浏览器，这些浏览器不支持SSL。当用户进入或离开安全站点的时候，请确认有相应的提示信息。是否有连接时间限制？超过限制时间后出现什么情况？

5.3 登录

有些站点需要用户进行登录，以验证他们的身份。这样对用户是方便的，他们不需要每次都输入个人资料。你需要验证系统阻止非法的用户名/口令登录，而能够通过有效登录。用户登录是否有次数限制? 是否限制从某些 IP 地址登录? 如果允许登录失败的次数为3，你在第三次登录的时候输入正确的用户名和口令，能通过验证吗? 口令选择有规则限制吗?  是否可以不登陆而直接浏览某个页面？

Web应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内（例如15分钟）没有点击任何页面，是否需要重新登陆才能正常使用。

5.4 日志文件

在后台，要注意验证服务器日志工作正常。日志是否记所有的事务处理? 是否记录失败的注册企图? 是否记录被盗信用卡的使用? 是否在每次事务完成的时候都进行保存? 记录IP 地址吗? 记录用户名吗?

5.5 脚本语言

脚本语言是常见的安全隐患。每种语言的细节有所不同。有些脚本允许访问根目录。其他只允许访问邮件服务器，但是经验丰富的黑客可以将服务器用户名和口令发送给他们自己。找出站点使用了哪些脚本语言，并研究该语言的缺陷。还要需要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。最好的办法是订阅一个讨论站点使用的脚本语言安全性的新闻组。　

6 接口测试

在很多情况下，web 站点不是孤立。Web 站点可能会与外部服务器通讯，请求数据、验证数据或提交订单。

6.1服务器接口

第一个需要测试的接口是浏览器与服务器的接口。测试人员提交事务，然后查看服务器记录，并验证在浏览器上看到的正好是服务器上发生的。测试人员还可以查询数据库，确认事务数据已正确保存。

这种测试可以归到功能测试中的表单测试和数据校验测试中

6.2 外部接口

有些 web 系统有外部接口。例如，网上商店可能要实时验证信用卡数据以减少欺诈行为的发生。测试的时候，要使用 web 接口发送一些事务数据，分别对有效信用卡、无效信用卡和被盗信用卡进行验证。如果商店只使用 Visa 卡和 Mastercard 卡， 可以尝试使用 Discover 卡的数据。(简单的客户端脚本能够在提交事务之前对代码进行识别，例如 3 表示 American Express，4 表示 Visa，5 表示 Mastercard，6 代表Discover。)通常，测试人员需要确认软件能够处理外部服务器返回的所有可能的消息。  

这种情况在远程抄表中可能会体现到

6.3 错误处理

最容易被测试人员忽略的地方是接口错误处理。通常我们试图确认系统能够处理所有错误，但却无法预期系统所有可能的错误。尝试在处理过程中中断事务，看看会发生什么情况？订单是否完成？尝试中断用户到服务器的网络连接。尝试中断 web 服务器到信用卡验证服务器的连接。在这些情况下，系统能否正确处理这些错误？是否已对信用卡进行收费？如果用户自己中断事务处理，在订单已保存而用户没有返回网站确认的时候，需要由客户代表致电用户进行订单确认。

采取措施：在理解需求的基础上，充分发挥想象力，尽量比较全面的列出各种异常情况

7 结论

无论你在测试 internet、intranet 或者是 extranet 应用程序，web 测试相对于非 web 测试来说都是更具挑战性的工作。用户对 web 页面质量有很高的期望。在很多情况下，就像业务功能一样，页面用于维护和发展公共关系，所以第一印象非常重要。

本文将 web 测试分为 6 个部分：

• 功能测试
• 性能测试（包括负载/压力测试）
• 用户界面测试
• 兼容性测试
• 安全测试
• 接口测试

本文的目的是覆盖 web 测试的各个方面，未就某一主题进行深入说明。

1 功能测试

1.1 链接测试

链接是Web应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先，测试所有链接是否按指示的那样确实链接到了该链接的页面；其次，测试所链接的页面是否存在；最后，保证Web应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页面，只有知道正确的URL地址才能访问。

　　链接测试可以自动进行，现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成，也就是说，在整个Web应用系统的所有页面开发完成之后进行链接测试。

采取措施：采用自动检测网站链接的软件来进行。

推荐软件：

Xenu Link Sleuth 免费 绿色免安装软件

HTML Link Validator 共享（30天试用）

1.2 表单测试

当用户通过表单提交信息的时候，都希望表单能正常工作。

如果使用表单来进行在线注册，要确保提交按钮能正常工作，当注册完成后应返回注册成功的消息。如果使用表单收集配送信息，应确保程序能够正确处理这些数据，最后能让顾客能让客户收到包裹。要测试这些程序，需要验证服务器能正确保存这些数据，而且后台运行的程序能正确解释和使用这些信息。

当用户使用表单进行用户注册、登陆、信息提交等操作时，我们必须测试提交操作的完整性，以校验提交给服务器的信息的正确性。例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。如果使用了默认值，还要检验默认值的正确性。如果表单只能接受指定的某些值，则也要进行测试。例如：只能接受某些字符，测试时可以跳过这些字符，看系统是否会报错。

1.3 数据校验

如果系根据业务规则需要对用户输入进行校验，需要保证这些校验功能正常工作。例如，省份的字段可以用一个有效列表进行校验。在这种情况下，需要验证列表完整而且程序正确调用了该列表(例如在列表中添加一个测试值，确定系统能够接受这个测试值)。

在测试表单时，该项测试和表单测试可能会有一些重复。

1.2和1.3的采取措施：第一个完整的版本采用手动检查，同时形成WinRunner（QTP）脚本；回归测试以及升级版本主要靠WinRunner（QTP）自动回放测试。

1.4 cookies测试

Cookies通常用来存储用户信息和用户在某应用系统的操作，当一个用户使用Cookies访问了某一个应用系统时，Web服务器将发送关于用户的信息，把该信息以Cookies的形式存储在客户端计算机上，这可用来创建动态和自定义页面或者存储登陆等信息。

　　如果Web应用系统使用了Cookies，就必须检查Cookies是否能正常工作。测试的内容可包括Cookies是否起作用，是否按预定的时间进行保存，刷新对Cookies有什么影响等。如果在 cookies 中保存了注册信息，请确认该 cookie能够正常工作而且已对这些信息已经加密。如果使用 cookie 来统计次数，需要验证次数累计正确。

采取措施：

       1 采用黑盒测试：采用上面提到的方法进行测试

2 采用查看cookies的软件进行（初步的想法）

可以选择采用的软件

IECookiesView v1.50

Cookies Manager v1.1

1.5 数据库测试

在Web应用技术中，数据库起着重要的作用，数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在Web应用中，最常用的数据库类型是关系型数据库，可以使用SQL对信息进行处理。

在使用了数据库的Web应用系统中，一般情况下，可能发生两种错误，分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的，而输出错误主要是由于网络速度或程序设计问题等引起的，针对这两种情况，可分别进行测试。

采取措施：暂时没有更好的测试方法

       考虑结合到1.2和1.3的测试中

1.6 应用程序特定的功能需求

最重要的是，测试人员需要对应用程序特定的功能需求进行验证。尝试用户可能进行的所有操作：下订单、更改订单、取消订单、核对订单状态、在货物发送之前更改送货信息、在线支付等等。这是用户之所以使用网站的原因，一定要确认网站能像广告宣传的那样神奇。

采取措施：深刻理解需求说明文档

1.7 设计语言测试

Web设计语言版本的差异可以引起客户端或服务器端严重的问题，例如使用哪种版本的HTML等。当在分布式环境中开发时，开发人员都不在一起，这个问题就显得尤为重要。除了HTML的版本问题外，不同的脚本语言，例如Java、JavaScript、 ActiveX、VBScript或Perl等也要进行验证。

暂时没有方法测试，可以多参考一点讨论组内的更新信息

2 性能测试

2.1 连接速度测试

用户连接到Web应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。当下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长（例如超过5秒钟），用户就会因没有耐心等待而离开。

　　另外，有些页面有超时的限制，如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登陆了。而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。

2.2 负载测试

负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量，也可以是在线数据处理的数量。例如：Web应用系统能允许多少个用户同时在线？如果超过了这个数量，会出现什么现象？Web应用系统能否处理大量用户对同一个页面的请求？

2.3 压力测试

负载测试应该安排在Web系统发布以后，在实际的网络环境中进行测试。因为一个企业内部员工，特别是项目组人员总是有限的，而一个Web系统能同时处理的请求数量将远远超出这个限度，所以，只有放在Internet上，接受负载测试，其结果才是正确可信的。

　　进行压力测试是指实际破坏一个Web应用系统，测试系统的反映。压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么情况下会崩溃。黑客常常提供错误的数据负载，直到Web应用系统崩溃，接着当系统重新启动时获得存取权。

　　压力测试的区域包括表单、登陆和其他信息传输页面等。

负载/压力测试应该关注什么

测试需要验证系统能否在同一时间响应大量的用户，在用户传送大量数据的时候能否响应，系统能否长时间运行。可访问性对用户来说是极其重要的。如果用户得到“系统忙”的信息，他们可能放弃，并转向竞争对手。系统检测不仅要使用户能够正常访问站点，在很多情况下，可能会有黑客试图通过发送大量数据包来攻击服务器。出于安全的原因，测试人员应该知道当系统过载时，需要采取哪些措施，而不是简单地提升系统性能。

瞬间访问高峰
如果您的站点用于公布彩票的抽奖结果，最好使系统在中奖号码公布后的一段时间内能够响应上百万的请求。负载测试工具能够模拟 X 个用户同时访问测试站点。

每个用户传送大量数据
网上书店的多数用户可能只订购 1-5 书，但是大学书店可能会订购 5000 本有关心理学介绍的课本? 或者一个祖母为她的 50 个儿孙购买圣诞礼物(当然每个孩子都有自己的邮件地址) 系统能处理单个用户的大量数据吗?

长时间的使用
如果站点用于处理鲜花订单，那么至少希望它在母亲节前的一周内能持续运行。如果站点提供基于 web 的 email 服务，那么点最好能持续运行几个月，甚至几年。可能需要使用自动测试工具来完成这种类型的测试，因为很难通过手工完成这些测试。你可以想象组织100 个人同时点击某个站点。但是同时组织 100000 个人呢。通常，测试工具在第二次使用的时候，它创造的效益，就足以支付成本。而且，测试工具安装完成之后，再次使用的时候，只要点击几下。

采取措施：采用测试工具WAS、ACT协助进行测试

3 用户界面测试

3.1 导航测试

导航描述了用户在一个页面内操作的方式，在不同的用户接口控制之间，例如按钮、对话框、列表和窗口等；或在不同的连接页面之间。通过考虑下列问题，可以决定一个Web应用系统是否易于导航：导航是否直观？Web系统的主要部分是否可通过主页存取？Web系统是否需要站点地图、搜索引擎或其他的导航帮助？

　　在一个页面上放太多的信息往往起到与预期相反的效果。Web应用系统的用户趋向于目的驱动，很快地扫描一个Web应用系统，看是否有满足自己需要的信息，如果没有，就会很快地离开。很少有用户愿意花时间去熟悉Web应用系统的结构，因此，Web应用系统导航帮助要尽可能地准确。

　　导航的另一个重要方面是Web应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容，内容在什么地方。

　　Web应用系统的层次一旦决定，就要着手测试用户导航功能，让最终用户参与这种测试，效果将更加明显。

3.2 图形测试

在Web应用系统中，适当的图片和动画既能起到广告宣传的作用，又能起到美化页面的功能。一个Web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有：

　　（1）要确保图形有明确的用途，图片或动画不要胡乱地堆在一起，以免浪费传输时间。Web应用系统的图片尺寸要尽量地小，并且要能清楚地说明某件事情，一般都链接到某个具体的页面。

　　（2）验证所有页面字体的风格是否一致。

　　（3）背景颜色应该与字体颜色和前景颜色相搭配。

　　（4）图片的大小和质量也是一个很重要的因素，一般采用JPG或GIF压缩，最好能使图片的大小减小到 30k 以下

（5）最后，需要验证的是文字回绕是否正确。如果说明文字指向右边的图片，应该确保该图片出现在右边。不要因为使用图片而使窗口和段落排列古怪或者出现孤行。

通常来说，使用少许或尽量不使用背景是个不错的选择。如果您想用背景，那么最好使用单色的，和导航条一起放在页面的左边。另外，图案和图片可能会转移用户的注意力。

3.3内容测试

内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。

　　信息的正确性是指信息是可靠的还是误传的。例如，在商品价格列表中，错误的价格可能引起财政问题甚至导致法律纠纷；信息的准确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软件来进行，例如使用Microsoft Word的"拼音与语法检查"功能；信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口，也就是一般Web站点中的所谓"相关文章列表"。

对于开发人员来说，可能先有功能然后才对这个功能进行描述。大家坐在一起讨论一些新的功能，然后开始开发，在开发的时候，开发人员可能不注重文字表达，他们添加文字可能只是为了对齐页面。不幸的是，这样出来的产品可能产生严重的误解。因此测试人员和公关部门一起检查内容的文字表达是否恰当。否则，公司可能陷入麻烦之中，也可能引起法律方面的问题。测试人员应确保站点看起来更专业些。过分地使用粗体字、大字体和下划线可能会让用户感到不舒服。在进行用户可用性方面的测试时，最好先请图形设计专家对站点进行评估。你可能不希望看到一篇到处是黑体字的文章，所以相信您也希望自己的站点能更专业一些。 最后，需要确定是否列出了相关站点的链接。很多站点希望用户将邮件发到一个特定的地址，或者从某个站点下载浏览器。但是如果用户无法点击这些地址，他们可能会觉得很迷惑。

3.4 表格测试

需要验证表格是否设置正确。用户是否需要向右滚动页面才能看见产品的价格？把价格放在左边，而把产品细节放在右边是否更有效? 每一栏的宽度是否足够宽，表格里的文字是否都有折行？是否有因为某一格的内容太多，而将整行的内容拉长?

3.5 整体界面测试

整体界面是指整个Web应用系统的页面结构设计，是给用户的一个整体感。例如：当用户浏览Web应用系统时是否感到舒适，是否凭直觉就知道要找的信息在什么地方？整个Web应用系统的设计风格是否一致？

对整体界面的测试过程，其实是一个对最终用户进行调查的过程。一般Web应用系统采取在主页上做一个调查问卷的形式，来得到最终用户的反馈信息。

　　对所有的用户界面测试来说，都需要有外部人员（与Web应用系统开发没有联系或联系很少的人员）的参与，最好是最终用户的参与。

采取措施：手动测试，参与人员最好有外部人员

4 兼容性测试

4.1 平台测试

市场上有很多不同的操作系统类型，最常见的有Windows、Unix、Macintosh、Linux等。Web应用系统的最终用户究竟使用哪一种操作系统，取决于用户系统的配置。这样，就可能会发生兼容性问题，同一个应用可能在某些操作系统下能正常运行，但在另外的操作系统下可能会运行失败。

　　因此，在Web系统发布之前，需要在各种操作系统下对Web系统进行兼容性测试。

4.2 浏览器测试

浏览器是Web客户端最核心的构件，来自不同厂商的浏览器对Java，、JavaScript、 ActiveX、 plug-ins或不同的HTML规格有不同的支持。例如，ActiveX是Microsoft的产品，是为Internet Explorer而设计的，JavaScript是Netscape的产品，Java是Sun的产品等等。另外，框架和层次结构风格在不同的浏览器中也有不同的显示，甚至根本不显示。不同的浏览器对安全性和Java的设置也不一样。

　　测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中，测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。

4.3 分辨率测试

页面版式在 640x400、600x800 或 1024x768 的分辨率模式下是否显示正常? 字体是否太小以至于无法浏览? 或者是太大? 文本和图片是否对齐?

4.4 Modem/连接速率

是否有这种情况，用户使用 28.8 modem下载一个页面需要 10 分钟，但测试人员在测试的时候使用的是 T1 专线? 用户在下载文章或演示的时候，可能会等待比较长的时间，但却不会耐心等待首页的出现。最后，需要确认图片不会太大。

4.5 打印机

用户可能会将网页打印下来。因此网也在设计的时候要考虑到打印问题，注意节约纸张和油墨。有不少用户喜欢阅读而不是盯着屏幕，因此需要验证网页打印是否正常。有时在屏幕上显示的图片和