软件产品测试知识整理

软件测试工程师须知： 良好的沟通和表达能力 具有怀疑与破坏的精神 扎实的软件测试基础知识 缜密的业务逻辑分析能力 处在用户的角度进行换位思考 足够的耐心、细心、信心、责任心 积极乐观向上的心态和团队协作能力 要有严谨、敢于承担责任、稳重的做事风格 善于自我总结、自我督促和不断学习的能力

软件产品测试知识整理

APP测试

APP测试的时候，建议让开发打好包APK和IPA安装包，测试人员自己安装应用，进行测试。

1.安装和卸载

●应用是否可以在IOS不同系统版本或android不同系统版本上安装（有的系统版本过低，应用不能适配）

●软件安装后是否可以正常运行，安装后的文件夹及文件是否可以写到指定的目录里。

●安装过程中是否可以取消

●安装空间不足时是否有相应提示

●如果应用需要通过网络验证之类的安装，需要测试一下断网情况下是否有相应提示

●是否可以删除应用（可通过桌面删除，也可以通过软件卸载安装。曾发现在IOS手相上有个应用安装时未完全安装，终止安装后，未完成安装的应用图标一直显示在手机上，并且无法成功删除）

●测试卸载后文件是否全部删除所有的安装文件夹

●卸载过程中出现死机，断电，重启等意外的情况，待环境恢复后是否可以正确卸载

●卸载是否支持取消功能，单击取消后软件卸载情况是否正常

2.运行

●APP安装完成后，是否可以正常打开软件

●APP运行时，是否有加载图示

●APP的速度是可以让人接受，切换是否流畅

●用户登录状态太久，sessionId会过期，会出现“虽然是登录状态，系统会提示用户没有登录。

3.登录

●登录用户名和密码错误时，界面有提示信息

●用户主动退出登录后，下次启动APP时，应该进入登录界面

●对于支持自动登录的APP，数据交换时 ，是否能自动登录成功且数据库操作无误

●密码更改后，登录时是否做到了有效数据的校验

●对于未登录时一些页面的操作，是否做了控制

●切换账号登录，检验登录的信息是否做到及时更新

●对于多个端都进行操作时，确保数据库操作无误，且每个端可以及时看到数据的更新

●对于一些软件，支持一个账号只允许登录一台机器，这时，需要检查账号登录多个手机时，是否将原用户剔除，且能够给出提示信息

● APP切换到后台时，再次切换到前台的测试，如登录时，有电话打进来

●对于IOS与android不同设备登录同一个账号时，对个人信息等数据进行操作后，确保数据数库操作无误，且IOS与android设备看到的数据都是最新的。

4.离线

离线是应用程序在本地的客户端会缓存一部分数据以功程序下次调用

●对于一些程序，需要在登录进来后，这时没有网络的情况下可以浏览本地数据

●对于无网络时，刷新获取新数据时，不能获取数据且能给出友好提示

●切换到后台，再次切换到前台时，可以正常查看

●离线后又连上网，这时对数据有更新时，需要从服务器端获取新数据来更新客户端数据，且要更新本地缓存信息

●对于一些界面的数据不提供离线查看，需要给出相应提示且界面更新后无任何数据

●确认在无网情况下可以浏览本地数据

●确认退出APP再开启APP时能正常浏览

●确认切换到后台再切回APP应用时可以正常浏览

●锁屏后再解锁回到应用前台可以正常浏览

●服务端的数据有更新时有离线的提示

5.数据更新

●确认有数据更新后，哪些地方需要手动刷新，哪些地方需自动刷新。

●确认从后台切换回前台时，哪些页面需要进行数据更新

●根据需求和逻辑，确认哪些数据是从服务端请求实时响应，哪些是缓存到本地的数据。

6.消息推送开关设置

●默认开关应该是全打开状态

●设置开关可以自由打开关闭

●设置开关打开状态下，消息推送是否可正常接收（应用启用中和应用关闭时都应该可以收到）

●确认后台未打开APP客户端时，手机消息栏可以接收到消息提醒。且点击可查看。点击后消息栏中消失

●确认APP客户端启动时，可以收到消息提醒，且点击可查看。客户端运行时，消息不会进消息栏。

●设置开关关闭时，客户端接收不到消息推送。

7.软件更新

●当客户端有新版本时，有更新提示

●软件更新一定要测，确保android软件更新可以正确更新新版本，且安装运行正确。

●确保IOS软件更新会有限制，只有上了商店且有版本更新时才会测试，但是如果真有问题，再发现问题不点晚，可以让开发先在测试机上模拟一个地址进行测试。

●用户取消版本更新时，老版本可以正常使用，但是下次启动应用时，仍出现更新提示

●当有新版本时，不删除客户端的情况下，直接更新检查是否能正常更新，且更新后客户端的功能是否最新版本（正常来讲不用强制删除本地客户端可以正常更新）

8.异常测试

●没有内存空间时，APP能否正确响应

●APP运行中手机断电

●APP运行中断开网络

●反复操作某个功能，不断点击，刷新时，是否会闪退

●APP运行时拔打或接听电话

●APP运行时发送信息、收取邮件等

●多个APP运行时

●不断切换前台和后台，是否影响应用正常功能

●APP运行时，启动相机功能

９.网络环境

●测试２G、３Ｇ，４Ｇ，wifi 网络下应用运应的速度

●内网测试时，选择到外网操作是否有异常处理

●网络不好时 ， 提交数据是否一直处理提交中，是否会有延迟，数据交换失败是否会有提醒

●有网到无网再到有网环境时，数据是否可以自动恢复，正常加载

10.其它

●接口测试。让开发提供一份接口文档，一定要将接口测试通。在接口测试阶段，将缺少接口，接口不完善的缺陷挖掘出来。这个需要准备充分的后台数据。

●导航测试。在运行APP时，不管在哪个接点，导航是否直观，精准，页面切换是否正确。

●图片测试。图片，按钮是否自适应。

●内容测试。要进行超长字符，空字符校验且校验是否有错别字

●功能测试。功能是否实现。

●易用性测试。所开发的功能，是否让用户容易接受，是否符合大众的操作习惯。

●适配性测试。应用在不同设备，不同系统上是否适配。

●UI测试。应用的设计是否够美观。

Web测试

常用的Web测试工具

性能测试工具--LoadRunner

介绍

LoadRunner,是一种系统性能负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner能够对整个企业架构进行测试同时也是一款收费的工具。

功能模块

a）VuGenLoadGenerator（虚拟用户生成器）用于捕获最终用户业务流程和创建自动性能测试脚本（也称为虚拟用户脚本）；

b）Controller（控制器）用于组织、驱动、管理和监控负载测试；

c）Analysis（分析器）有助于您查看、分析和比较性能结果。

性能测试工具--JMeter

介绍

ApacheJMeter是Apache组织开发的基于Java的压力测试工具。用于对软件做压力测试的同时也是一款免费的测试工具。

作用

JMeter能够对应用程序做功能/回归测试，通过创建带有断言的脚本来验证你的程序返回了你期望的结果。

JMeter可以用于对静态和动态的资源（文件、Servlet、Perl脚本、Java对象、数据库和查询、FTP服务器等等）的性能进行测试。它可以用于对服务器，网络或对象模拟繁重的负载来测试他们的强度或分析不同压力类型下的整体性能。你可以使用它做性能的图形分析或在大并发负载测试你的服务器/脚本/对象。

自动化测试工具--Selenium（需要编程基础）

介绍

Selenium是测试WEB的免费，开源自动化工具，功能强大。它可以在几乎用任何一种编程语言进行构建，包括JAVA，C#，PERL，PHP，Python和Ruby。它可以测试的浏览器有IE，Firefox，Chome等。

家族成员

a）Selenium IDE；

b）Selenium RC；

c）Selenium CORE；

d）Selenium GRID；

自动化测试工具--QTP

介绍

QTP是Quick Test Professional的简称，是一种收费的自动测试工具。现已被惠普收购，正式名字为HP Quick Test Professionalsoftware。

五个步骤

使用QTP的目的是想用它来执行重复的手工测试，主要是用于回归测试和测试同一软件的新版本。因此你在测试前要考虑好如何对应用程序进行测试，例如要测试哪些功能、操作步骤、输入数据和期望的输出数据等。 QTP进行功能测试的测试流程 ：[制定测试计划]——>[创建测试脚本]——>[增强测试脚本功能]——>[运行测试]——>[分析测试结果] 大致五个步骤

a）制定计划

自动测试的测试计划是根据被测项目的具体需求，以及所使用的测试工具而制定的，完全用于指导测试全工程。QTP是一个功能测试工具，主要帮助测试人员完成软件的功能测试，与其他测试工具一样，QTP不能完全取代测试人员的手工操作，但是在某个功能点上，使用QTP的确能够帮助测试人员做很多工作。在测试计划阶段，首先要做的就是分析被测应用的特点，决定应该对哪些功能点进行测试，可以考虑细化到具体页面或者具体控件。对于一个普通的应用程序来说，QTP应用在某些界面变化不大的回归测试中是非常有效的。

b）创建脚本

当测试人员浏览站点或在应用程序上操作的时候，QTP的自动录制机制能够将测试人员的每一个操作步骤及被操作的对象记录下来，自动生成测试脚本语句。与其他自动测试工具录制脚本有所不同的是，QTP除了以VBScript脚本语言的方式生成脚本语句以外，还将被操作的对象及相应的动作按照层次和顺序保存在一个基于表格的关键字视图中。比如，当测试人员单击一个链接，然后选择一个CheckBox或者提交一个表单，这样的操作流程都会被记录在关键字视图中。

c）增强脚本

录制脚本只是为了实现创建或者设计脚本的第一步，基本的脚本录制完毕后，测试人员可以根据需要增加一些扩展功能，QTP允许测试人员通过在脚本中增加或更改测试步骤来修正或自定义测试流程，如增加多种类型的检查点功能，既可以让QTP检查一下在程序的某个特定位置或对话框中是否出现了需要的文字，还可以检查一个链接是否返回了正确的URL地址等，还可以通过参数化功能，使用多组不同的数据驱动整个测试过程。

d）运行测试

QTP从脚本的第一行开始执行语句，运行过程中会对设置的检查点进行验证，用实际数据代替参数值，并给出相应的输出结构信息。测试过程中测试人员还可以调试自己的脚本，直到脚本完全符合要求。

e）分析测试

运行结束后系统会自动生成一份详细完整的测试结果报告。

Web测试方法

Web测试概述

基于Web的系统测试与传统的软件测试既有相同之处，也有不同的地方，对软件测试提出了新的挑战。基于Web的系统测试不但需要检查和验证是否按照设计的要求运行，而且还要评价系统在不同用户的浏览器端的显示是否合适。重要的是，还要从最终用户的角度进行安全性和可用性测试。

主要从功能、性能、可用性、客户端兼容性、安全性等方面了解基于Web的系统测试方法。

Web测试特点

一般软件的发布周期以月或年计算，而Web应用的发布周期以天计算甚至以小时计算。Web测试人员必须处理更短的发布周期，测试人员和测试管理人员面临着从测试传统的C/S结构和框架环境到测试快速改变的Web应用系统的转变。

Web测试的常用的检查点

1.页面连接检查每一个连接是否都有对应的页面，并且页面之间切换正确。

2.相关性检查删除/增加一项是否会对其他项产生影响，如果产生影响，这些影响是否都正确。

3.检查按钮的功能是否正确如update,cancel,delete,save等功能是否正确。

4.字符串长度检查输入超过需求说明的字符串长度的内容，看系统是否检查字符串长度，会不会出错。

5.字符类型检查在应该输入指定类型的内容的地方输入其他类型的内容（如在应该输入整形的地方输入其他字符类型），看系统是否检查字符类型，是否报错。

6.标点符号检查输入内容包括各种标点符号，特别是空格，各种引号，回车键，看系统是否处理正确。

7.中文字符处理在可以输入中文的系统输入中文（简体或繁体），看是否会出现乱码或出错。

8.检查带出信息的完整性在查看信息和update信息时，查看所填写的信息是否全部带出，带出信息和添加的是否一致。

9.信息重复检查在一些需要命名，且名字应该唯一的信息输入重复的名字或id,看系统有没有处理，是否报错，重名包括是否区分大小写，以及在输入内容的前后输入空格，系统是否作出正确处理。

10.检查删除功能在一些可以一次删除多个信息的地方，不选择任何信息，按‘delete’,看系统如何处理，是否报错，然后选择一个或多个信息，进行删除，看是否做正确处理。

11.检查添加和修改的一致，检查添加和修改信息的要求是否一致，例如添加要求必添的项，修改也应该必填，添加规定的整形的项，修改也必须为整形。

12.检查修改重名，修改时把不能重名的项改为已存在的内容看是否会处理，同时，也要注意，会不会报和自己重名的错。

13.重复提交表单一条已经成功提交的记录，back后再提交，看系统会如何处理。

14.检查多次使用back键的情况在有back的地方，back,回到原来的页面，再back，重复几次，看是否会报错。

15.search检查在有search功能的地方输入系统存在和不存在的内容，看search结果是否正确，如果可以输入多个search条件，可以同时添加合理和不合理的条件，看系统处理是否正确。

16.输入信息位置注意在光标停留的地方输入信息时，光标和所输入信息是否会跳到别的地方。

17.上传和下载文件检查上传和下载文件的功能是否实现，上传是否能打开。对上传文件的格式有什么规定，系统是否有解释信息，并检查系统是否能够做到。

18.必填项检查应该填写的项没有填写的时候系统是否都做了处理，对必填项是否提示信息，如在必填项前面加*。

19.快捷键检查检查是否支持常用快捷，如Ctrl+C,Ctrl+V,BackSpace等，对一些不允许的的输入信息的字段，如选人，选日期对快捷方式是否做了限制。

20.回车检查在输入结束后直接按回车键，看系统如何处理，是否会报错。

登录功能的测试方法

1.快捷键的使用是否正常;

2.TAB键的使用是否正确；

3.上线左右键是否正确；

4.界面如果支持ESC键看是否正常工作；

5.ENTER键的使用是否正确切换时是否正常；

6.布局美感，界面的布局是否腐恶人的审美标准，具体因人而异；

7.输入框功能：输入合法的用户名和密码可以成功进入，输入合法的用户名和不合法的密码不可以进入，并给出合理的提示，输入不合法的用户名和正确的密码不可以进入，并给出合理的提示，输入不合法的用户名和不正确的密码不可以进入，并给出合理的提示，不合法的用户名有：不正确的用户名，使用了字符大于用户名的限制，正常用户名不允许的特殊字符，空的用户名。系统（操作系统和应用系统）的保留字符，不合法的密码有：空密码（除有特殊规定），错误的密码，字符大于密码的限制正常密码不允许的特殊字符，系统（操作系统和应用系统）的保留字符。

8.界面的链接：对于界面有链接的界面，要测试界面上所有的链接都正常或者给出合理的提示；

9.补充输入框是否支持复制，粘贴和移动；

10.密码框的显示不要是具体的字符，要是一些密码的字符，验证用户名前面有空格是否可以进入，一般情况可以。验证用户名是否区分大小写，（有的软件是区分大小写），验证必填项为空，是否允许进入。验证登录的次数是否有限制。从安全角度考虑，有些安全级别高的软件会考虑这方面的限制。

用户及权限管理功能常规测试方法

1.赋予一个人员相应的权限后，在界面上看此人员是否具有此权限，并以此人员身份登录，验证权限设置是否正确（能否超出所给的权限）；

2.删除或修改已经登录系统并正在进行操作的人员的权限，程序能否正确处理；

3.重新注册系统变更登录身份后再登录，看程序是否能正确执行，具有的权限是否正确；

4.在有工作组或角色管理的情况下，删除包含用户的工作组或角色，程序能否正确处理；

5.不同权限用户登录通一个系统，权限范围是否正确；

6.覆盖系统所有权限设定；

7.能否添加信息为空的用户（其中包括空用户名及空口令、空用户名非空口令、非空用户名及空口令）；

8.能否添加长用户名及长口令，如果允许，新用户能否正确登录；

9.系统是否允许删除系统管理员这一特殊用户或修改系统管理员口令，删除或修改后系统的实际情况；

10.登录用户能否修改自己的权限；

11.添加用户（有标识或编号）：标识相同，用户名不同；标识相同，用户名相同；标识不同，用户名相同；标识不同，用户名不同；

12.登录用户能否修改自己的权限；

13.修改用户的信息（包括权限，口令，基本信息等），对其他模块的影响；

14.修改用户的信息：修改后的用户信息和已经存在的用户信息相同；修改后的用户信息和已经存在的用户信息相同；修改后的用户信息和已经存在的用户信息不同；

15.不给用户授权，是否允许登录；

16.改某些设置时，是否会影响具有上级权限及相同权限人员的设置；

17.系统管理员修改了某些数据，以其他人员身份登录时数据是否会改变；

18.用户能否同时属于多个组，各个组的权限能否交叉；删除后重新添加的用户是否具有以前的权限；更改用户各项属性（包括权限）看对权限是否有影响。

搜索功能测试点

1.页面检查

2.默认条件搜索

3.修改可选条件搜索

4.修改输入条件搜索

5.修改区间条件搜索

6.组合可选，输入条件搜索

7.操作后检查搜索条件及查询结果

8.错误、空记录搜索

输入框的测试要点

1.验证输入与输出的是否信息一致；

2.输入框之前的标题是否正确；

3.对特殊字符的处理，尤其是输入信息需要发送到数据库的，特殊字符包括’（单引号），”（双引号），【】中括号，（）小括号，{}大括号，；分号，大于小于号。。。。。

4.对输入框输入超过限制的字符的处理，一般非特殊的没有做出限制的在255byte左右；

5.输入框本身的大小，长度；

6.不同内码的字符的输入；

7.对空格、TAB字符的处理机制；

8.字符本身显示的颜色；

9.密码输入窗口转换成星号或其他符号；

10.密码输入框对其中的信息进行加密，防止采用破解星号的方法破解；

11.按下CTRL和ALT键对输入框的影响；

12.对于新增、修改、注册时用的输入框，有限制的，应该输入时做出提示，指出不允许的或者标出允许的；

13.对于有约束条件要求的输入框应当在条件满足输入框的状态发送相应的改变，比如选了湖南就应该列出湖南下面的市，或者选了某些条件后，一些输入框会关闭或转为只读状态；

14.输入类型：根据前面的栏位标题判断该输入框应该输入那些内容算是合理的。例如：是否允许输入数字或字母，不允许输入其他字符等；

15.输入长度：数据库字段有长度定义，当输入过长时，提交数据是否会出错；

16.输入状态：当处于某种状态下，输入框是否处于可写或非可写状态。例如：系统自动给与的编号等栏位作为唯一标识，当再次处于编辑状态下，输入框栏位应处于不可写状态，如果可写对其编辑的话，可能会造成数据重复引起冲突；

17.如果是会进行数据库操作的输入框，还可以考虑输入SQL钟的一些特殊符号如单引号等，有时会有意想不到的错误出现；

18.输入类型输入长度是否允许复制粘贴为空的情况，空格的考虑，半角全角测试对于密码输入框要考虑显示的内容是**，输入错误时的提示信息及提示信息是否准确；

19.可以先了解你要测试的输入框在软件系统的某个功能中所扮演的角色，然后了解其具体的输入条件，再将输入条件按照有效等价类，无效等价类，边界值等方法进行测试用例的设计。

20.关键字有大小写混合的情况；

21.关键字中是否含有一个或多个空格的情况，包括前空格，中间空格，（多个关键字），和后空格；

22.关键字中是否支持通配符的情况（视功能而定）；

23.关键字的长度分别为9,10,11个字符时的情况；

24.关键字是valid，但是没有匹配搜索结果的情况；

25.输入html的标签会出现哪些问题？输入&it:html&gt；会出现什么问题？

26.安全测试方面：给出一些特别的关键字，比如or 1=1，这样的关键字如果不被处理就直接用到数据库查询中去，后果可想而知。

WEB兼容性测试

1.软件兼容性测试概述：兼容性测试是指待测试项目在特定的硬件平台上，在不同的网络等环境中能正常的运行的测试。

2.兼容测试的目的：让待测试项目在不同的操作系统平台上正常运行。

3.Web兼容性测试的主要类型：Web兼容性测试主要针对不同的操作系统平台，浏览器，以及分辨率进行的测试。

1）操作系统兼容性测试

2）浏览器兼容性测试

3）分辨率兼容性测试

WEB安全性测试与性能测试

1.Web安全性测试（根据需要进行拓展）

1）Web安全性测试-SQL注入

2）Web安全性测试-跨站点脚本漏洞

3）Web安全性测试-测试XSS漏洞

2.Web性能测试

1）并发用户

并发用户数大家都知道我们的性能测试就通过工具模拟多用户对系统进行操作，对系统造成压力，来验证系统的性能（不太标准的解释）。好多人也简单的把性能测试当成并发测试。那么这个“多用户”和“同时”两个因素缺一不可。只多用户不同时，很难对系统构成压力；没有多个用户，同时的概念也就自然不存在了。

并发的两种情况：

一种是严格意义上的并发，即所有的用户在同一时刻做同一件事或操作，这种操作一般指做同一类型的业务。比如，所有用户同一时刻做并发登陆，同一时刻做表单提交。

另外一种并发是广义范围的并发，这种并发与前一种并发的区别是，尽管多个用户对系统发出了请求或者进行了操作，但是这些请求或都操作可以是相同的，也可以是不同的。比如，在同一时刻有用户在登录，有用户在提交表单。

从服务器的角度来看并发：

前面的两种解释都是从用户业务的角度来解释并发的，因为我们平时所做的性能测试也是从用户端对业务层的操作来进行并发测试的。

如果考虑整个系统运行过程中服务器所承受的压力是这样的：在该系统的运行过程中，把整个运行过程划分为离散的时间点，在每个点上，都有一个“同时向服务端发送请求的客户数”，这个就是所谓的服务器所承受的最大并发访问数。

2）吞吐量

指在一次性能测试过程中网络上传输的数据量的总和。

对于交互式应用来说，吞吐量指标反映的是服务器承受的压力，在容量规划的测试中，吞吐量是一个重点关注的指标，因为它能够说明系统级别的负载能力，另外，在性能调优过程中，吞吐量指标也有重要的价值。如一个大型工厂，他们的生产效率与生产速度很快，一天生产10W吨的货物，结果工厂的运输能力不行，就两辆小型三轮车一天拉2吨的货物，比喻有些夸张，但我想说明的是这个运输能力是整个系统的瓶颈。

提示，用吞吐量来衡量一个系统的输出能力是极其不准确的，用个最简单的例子说明，一个水龙头开一天一夜，流出10吨水；10个水龙头开1秒钟，流出0.1吨水。当然是一个水龙头的吞吐量大。你能说1个水龙头的出水能力是10个水龙头的强？所以，我们要加单位时间，看谁1秒钟的出水量大。这就是吞吐率。

3）吞吐率

单位时间内网络上传输的数据量，也可以指单位时间内处理客户请求数量。它是衡量网络性能的重要指标，通常情况下，吞吐率用“字节数/秒”来衡量，当然，你可以用“请求数/秒”和“页面数/秒”来衡量。其实，不管是一个请求还是一个页面，它的本质都是在网络上传输的数据，那么来表示数据的单位就是字节数。

不过以不同的方式表达的吞吐量可以说明不同层次的问题。例如，以字节数/秒方式表示的吞吐量主要受网络基础设置、服务器架构、应用服务器制约；以请求数/秒方式表示的吞吐量主要受应用服务器和应用代码的制约。

但是从业务的角度看，吞吐率也可以用“业务数/小时或天”、“访问人数/小时或天”、“页面访问量/小时或天”来衡量。例如，在银行卡审批系统中，可以用“千件/小时”来衡量系统的业务处理能力。那么，从用户的角度，一个表单提交可以得到一次审批。又引出来一个概念---事务。

4）事务

就是用户某一步或几步操作的集合。不过，我们要保证它有一个完整意义。比如用户对某一个页面的一次请求，用户对某系统的一次登录，淘宝用户对商品的一次确认支付过程。这些我们都可以看作一个事务。那么如何衡量服务器对事务的处理能力。又引出一个概念----TPS。

5）TPS(Transaction Per second)

每秒钟系统能够处理事务或交易的数量，它是衡量系统处理能力的重要指标。

6）点击率（Hit Per Second）

点击率可以看做是TPS的一种特定情况。点击率更能体现用户端对服务器的压力。TPS更能体现服务器对客户请求的处理能力。

每秒钟用户向web服务器提交的HTTP请求数。这个指标是web 应用特有的一个指标；web应用是“请求-响应”模式，用户发一个申请，服务器就要处理一次，所以点击是web应用能够处理的交易的最小单位。如果把每次点击定义为一个交易，点击率和TPS就是一个概念。容易看出，点击率越大。对服务器的压力也越大，点击率只是一个性能参考指标，重要的是分析点击时产生的影响。

需要注意的是，这里的点击不是指鼠标的一次“单击”操作，因为一次“单击”操作中，客户端可能向服务器发现多个HTTP请求。

7）吞吐量指标的作用

1. 用户协助设计性能测试场景，以及衡量性能测试场景是否达到了预期的设计目标：在设计性能测试场景时，吞吐量可被用户协助设计性能测试场景，根据估算的吞吐量数据，可以对应到测试场景的事务发生频率，事务发生次数等；另外，在测试完成后，根据实际的吞吐量可以衡量测试是否达到了预期的目标。

2. 用于协助分析性能瓶颈：吞吐量的限制是性能瓶颈的一种重要表现形式，因此，有针对性地对吞吐量设计测试，可以协助尽快定位到性能冰晶所在位置。

WEB测试分类

1.链接测试

1）常见的链接测试工具：Xenu，Html Link Validator等

2.表单测试（即输入框）

1）数据添加功能测试

2）数据修改功能测试

3）数据删除功能测试

4）数据查询和统计测试

3.Cookies测试（查看和禁用cookies）

1）检查cookies是否能正常工作

2）是否按预定的时间进行保存

3）刷新对cookies有什么影响

4.导航测试

1）导航栏界面

5.图形测试

1）对象：图片，动画，边框，颜色，文字，背景，按钮

2）确保有明确用途，链接正确，表意清楚

3）验证所有页面字体风格是否一致

4）背景颜色应该与字体颜色和前景颜色相搭配

5）图片的大小和质量，一般采用IPG或GIF压缩。

6.内容测试

7.整体页面测试

软件测试框架基础

软件测试的目的

测试的目的是根据软件开发各阶段的规格说明和程序内部结构而精心设计一批测试用例，并利用这些测试用例去运行程序。在软件投入生产性运行之前，尽早，尽可能多的发现软件中的错误，是保障软件质量的关键步骤。

关键步骤

1）测试是为了发现程序的错误而执行的过程；

2）一个好的测试方案是极可能发现迄今为止未发现的错误的测试方案；

3）成功的测试是发现了至今为止未发现的错误的测试；

4）设计测试的目标是想以最少的时间和人力系统的找出软件中潜在的各种错误和缺陷，如果成功地实施了测试，就能够发现软件中的错误。测试的附带收获是，它能够证明软件的功能和性能与需求说明相符。此外，实施测试收集到的测试结果数据为可靠性分析提供了依据。

5）测试决不能证明程序是正确的，即使经过了最严格的测试之后，仍然可能还有没被发现的错误潜藏着程序中；

6）测试的目标是想以最少的时间和人力找出软件中潜在的各种错误和缺陷。

软件测试的原则

1）测试显示缺陷的存在

测试可以显示缺陷的存在，但不能证明系统不存在缺陷。测试可以减少软件中存在缺陷的可能性，但即使测试没有发现任何缺陷，也不能证明软件或系统是完全正确的，或者说是不存在缺陷的。

2） 穷尽测试是不可能的

穷尽测试是不可能的，当满足一定的测试出口准则时测试就应当终止。考虑到所有可能输入值和它们的组合，以及结合所有不同的测试前置条件，这是一个天文数字，我们没有可能进行穷尽测试。在实际测试过程中，测试人员无法执行“天文”数字的测试用例。所以说，每个测试都只是抽样测试。因此，必须根据测试的风险和优先级，控制测试工作量，在测试成本、收益和风险之间求得平衡。

3）测试的尽早介入

根据统计表明，在软件开发生命周期早期引入的错误占软件过程中出现所有错误（包括最终的缺陷）数量的50%～60%。此外，IBM的一份研究结果表明，缺陷存在放大趋势。如需求阶段的一个错误可能会导致N个设计错误，因此，越是测试后期，为修复缺陷所付出的代价就会越大。因此，软件测试人员要尽早地且不断地进行软件测试，以提高软件质量，降低软件开发成本。

4）缺陷的集群性

Pareto原则表明“80%的错误集中在20%的程序模块中”。实际经验也证明了这一点，通常情况下，大多数的缺陷只是存在测试对象的极小部分。缺陷并不是平均而是集群分布的。因此，如果在一个地方发现了很多缺陷，那么通常在这个模块中可以发现更多的缺陷。因此，测试过程中要充分注意错误集群现象，对发现错误较多的程序段或者软件模块，应进行反复的深入的测试。

5）杀虫剂悖论

杀虫剂用得多了，害虫就有免疫力，杀虫剂就发挥不了效力。在测试中，同样的测试用例被一遍一遍反复使用时，发现缺陷的能力就会越来越差。这种现象的主要原因在于测试人员没有及时更新测试用例，同时对测试用例及测试对象过于熟悉，形成思维定势。

为克服这种现象，测试用例需要经常的评审和修改，不断增加新的不同的测试用例来测试软件或系统的不同部分，保证测试用例永远是最新的，即包含着最后一次程序代码或说明文档的更新信息。这样软件中未被测试过的部分或者先前没有被使用过的输入组合就会重新执行，从而发现更多的缺陷。同时，作为专业的测试人员，要具有探索性思维和逆向思维，而不仅仅是做输出与期望结果的比较。

6）测试活动依赖于测试内容

项目测试相关的活动依赖于测试对象的内容。对于每个软件系统，比如测试策略、测试技术、测试工具、测试阶段以及测试出口准则等等的选择，都是不一样的。同时，测试活动必须与应用程序的运行环境和使用中可能存在的风险相关联。因此，没有两个系统可以以完全相同的方式进行测试。比如，对关注安全的电子商务系统进行测试，与一般的商业软件测试的重点是不一样的，它更多关注的是安全测试和性能测试。

7）没有失效不代表系统是可用的

系统的质量特征不仅仅是功能性要求，还包括了很多其他方面的要求比如稳定性、可用性、兼容性等等。假如系统无法使用，或者系统不能完成客户的需求和期望，那么，这个系统的研发是失败。同时在系统中发现和修改缺陷也是没有任何意义的。

在开发过程中用户的早期介入和接触原型系统就是为了避免这类问题的预防性措施。有时候，可能产品的测试结果非常完美，可最终的客户并不买帐。因为，这个开发角度完美的产品可能并不是客户真正想要的产品。

8）尽量避免测试的随意性

应该从软件工程的角度去理解软件测试，它是有组织、有计划、有步骤的活动。

软件测试的流程

开发模块完成

测试

OA录入BUG

开发人员修改

回归测试

测试没问题关闭任务

有问题就退回修改，重复之前的流程

1）软件测试V模型

2）软件测试的对象

软件是由文档，数据以及程序组成的，软件测试应该是对软件形成过程的文档，数据以及程序进行的测试，而不仅仅是对程序进行的测试。60%以上的软件错误并不是程序错误，而是分析和设计错误，因此，做好软件需求和设计阶段的测试工作是非常重要的，测试概念应该扩大化，提倡软件全生命周期测试的理念。

软件测试的方法

1.从是否运行软件上划分：

1）静态测试：

不运行程序，通过人工对程序和文档进行分析与检查；静态测试包括对软件的需求说明书，设计说明书，程序源代码等进行非运行的检查；（代码走读，审查，需求确认）

2）动态测试：

指通过人工或者使用工具运行程序进行检查、分析程序的执行状态和程序的外部表现；

动态测试分为：

白盒测试：

对程序内部结构的分析、监测来寻找问题；

黑盒测试：

对软件的外部表现来发现其缺陷和错误；

灰盒测试：

介于白盒测试与灰盒测试之间的测试

测试用例

1.测试用例概述

测试用例（Test Case）是将软件测试的行为活动做一个科学化的组织归纳，目的是能够将软件测试的行为转化成可管理的模式；同时测试用例也是将测试具体量化的方法之一；

测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求；

2.测试用例的作用

1）指导测试的实施

测试用例主要适用于集成测试、系统测试和回归测试。在实施测试时测试用例作为测试的标准，测试人员一定要按照测试用例严格按用例项目和测试步骤逐一实施测试。并对测试情况记录在测试用例管理软件中，以便自动生成测试结果文档。

根据测试用例的测试等级，集成测试应测试那些用例，系统测试和回归测试又该测试那些用例，在设计测试用例时都已作明确规定，实施测试时测试人员不能随意作变动。

2）规划测试数据的准备

在我们的实践中测试数据是与测试用例分离的。按照测试用例配套准备一组或若干组测试原始数据，以及标准测试结果。尤其象测试报表之类数据集的正确性，按照测试用例规划准备测试数据是十分必须的。

除正常数据之外，还必须根据测试用例设计大量边缘数据和错误数据。

3）编写测试脚本的"设计规格说明书"

为提高测试效率，软件测试已大力发展自动测试。自动测试的中心任务是编写测试脚本。如果说软件工程中软件编程必须有设计规格说明书，那么测试脚本的设计规格说明书就是测试用例。

4）评估测试结果的度量基准

完成测试实施后需要对测试结果进行评估，并且编制测试报告。判断软件测试是否完成、衡量测试质量需要一些量化的结果。例：测试覆盖率是多少、测试合格率是多少、重要测试合格率是多少，等等。以前统计基准是软件模块或功能点，显得过于粗糙。采用测试用例作度量基准更加准确、有效。

5）分析缺陷的标准

通过收集缺陷，对比测试用例和缺陷数据库，分析确证是漏测还是缺陷复现。漏测反映了测试用例的不完善，应立即补充相应测试用例，最终达到逐步完善软件质量。而已有相应测试用例，则反映实施测试或变更处理存在问题。

3.测试用例的格式

参考测试用例设计模板（软件测试用例的基本要素包括测试用例编号、测试标题、重要级别，测试输入、操作步骤、预期结果。）

黑盒测试

1.黑盒测试用例的设计方法

1）等价类划分法

等价类是指某个输入域的子集合。在该子集合中,各个输入数据对于揭露程序中的错误都是等效的，并合理地假定：测试某等价类的代表值就等于对这一类其它值的测试，因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件就可以用少量代表性的测试数据取得较好的测试结果。等价类划分可有两种不同的情况：有效等价类和无效等价类。

a)有效等价类

是指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。

b)无效等价类

与有效等价类的定义恰巧相反。无效等价类指对程序的规格说明是不合理的或无意义的输入数据所构成的集合。对于具体的问题，无效等价类至少应有一个，也可能有多个。

设计测试用例时,要同时考虑这两种等价类。因为软件不仅要能接收合理的数据,也要能经受意外的考验，这样的测试才能确保软件具有更高的可靠性

2）边界值分析法

边界值方法也是适用于单个输入条件的情况，输入类型可以数值、字符等，要测试的边界包括上点、下点、离点。

3）因果图法

因果图方法考虑输入的组合，特别适用于多个输入条件相关有关联又相互约束的情况。

设计步骤：

a)罗列出输入与输出;

b)根据输入与输出画出因果图;

c)标出约束跟限制;

d)把因果图转化成判定表;

e)根据判定表的每一列设计测试用例。

4）流程分析法

又叫场景分析法，是编写测试用例时最常见的方法，我们在测试过程中将软件系统分析成多个路径，根据路径的不同组合来进行测试，在测试的过程中使得软件的各个分支都能得到测试。

5）状态迁移图法

状态迁移图法主要关注在测试状态转移的正确性上面。对于一个有限状态机，通过测试验证其在给定的条件内是否能够产生需要的状态变化，有没有不可达的状态和非法的状态，可能不可能产生非法的状态转移等。通过构造能导致状态迁移的事件，来测试状态之间的转换。

状态迁移图的步骤：

a）画出状态迁移图；

b）列出状态——事件表；

c）得到状态转换树；

d）推出测试路径；

e）根据测试路径编写测试用例。

6）判定表法

判定表适合于解决多个逻辑条件的组合。将各种逻辑的组合罗列出来，避免遗漏。不能表达重复的操作。

判定表包括条件桩、条件项、动作桩、动作项。

条件桩：列出所有条件，次序无关;

条件项：列出所对应条件的所有可能情况下的取值;

动作桩：列出可能采取的操作，次序无关;

动作项：列出条件项各种取值情况下采取的操作。

设计步骤：

a)确定规则个数，条件及各条件取值的组合;

b)列出条件桩、动作桩;

c)列出条件项;

d)列出动作项;

e)初始化判定表;

f)规则简化、合并。

7）错误推测法

8）场景法

现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可以引入到软件测试中，可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时使测试用例更容易理解和执行。

应用：

基本流和备选流：如下图所示，图中经过用例的每条路径都用基本流和备选流来表示，直黑线表示基本流，是经过用例的最简单的路径。备选流用不同的色彩表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中；也可能起源于另一个备选流（，或者终止用例而不再重新加入到某个流。