测试知识库Word下载.docx

测试知识库Word下载.docx

《测试知识库Word下载.docx》由会员分享，可在线阅读，更多相关《测试知识库Word下载.docx（27页珍藏版）》请在冰豆网上搜索。

　　测试概念的范畴

　　广义上讲，测试是指软件产品生存周期内所有的检查、评审和确认活动。

如：

设计评审、系统测试。

　　狭义上讲，测试是对软件产品质量的检验和评价。

它一方面检查软件产品质量中存在的质量问题，同时对产品质量进行客观的评价。

　　测试的目的

　　简单地说，就是替用户受过，测试的最终目的是确保最终交给用户的产品的功能符合用户的需求，把尽可能多的问题在产品交给用户之前发现并改正。

　　具体地讲，测试一般要达到下列目标：

（1）确保产品完成了它所承诺或公布的功能，并且所有用户可以访问到的功能都有明确的书面说明------在某种意义上与ISO9001是同一种思想。

　　产品缺少明确的书面文档，是厂商一种短期行为的表现，也是一种不负责任的表现。

所谓短期行为，是指缺少明确的书面文档既不利于产品最后的顺利交付，容易与用户发生矛盾，影响厂商的声誉和将来与用户的合作关系;

同时也不利于产品的后期维护，也使厂商支出超额的用户培训和技术支持费用。

从长期利益看，这是很不划算的。

　　当然，书面文档的编写和维护工作对于使用快速原型法（RAD）开发的项目是最为重要的、最为困难，也是最容易被忽略的。

　　最后，书面文档的不健全甚至不正确，也是测试工作中遇到的最大和最头痛的问题，它的直接后果是测试效率低下、测试目标不明确、测试范围不充分，从而导致最终测试的作用不能充分发挥、测试效果不理想。

（2）确保产品满足性能和效率的要求。

使用起来系统运行效率低（性能低）、或用户界面不友好、用户操作不方便（效率低）的产品不能说是一个有竞争力的产品。

　　用户最关心的不是你的技术有多先进、功能有多强大，而是他能从这些技术、这些功能中得到多少好处。

也就是说，用户关心的是他能从中取出多少，而不是你已经放进去多少。

　　（3）确保产品是健壮的和适应用户环境的。

健壮性即稳定性，是产品质量的基本要求，尤其对于一个用于事务关键或时间关键的工作环境中。

　　另外就是不能假设用户的环境（某些项目可能除外）。

　　测试的原则---GoodEnough

　　对于相对复杂的产品或系统来说，zero-bug是一种理想，good-enough是我们的原则。

　　Good-enough原则就是一种权衡投入/产出比的原则：

不充分的测试是不负责任的;

过分的测试是一种资源的浪费，同样也是一种不负责任的表现。

我们的操作困难在于：

如何界定什么样的测试是不充分的，什么样的测试是过分的。

目前状况唯一可用的答案是：

制定最低测试通过标准和测试内容，然后具体问题具体分析。

3如何配置软件测试环境

配置测试环境是测试实施的一个重要阶段，测试环境适合与否会严重影响测试结果的真实性和正确性。

测试环境包括硬件环境和软件环境，硬件环境指测试必需的服务器、客户端、网络连接设备，以及打印机/扫描仪等辅助硬件设备所构成的环境;

软件环境指被测软件运行时的操作系统、数据库及其他应用软件构成的环境。

在实际测试中，软件环境又可分为主测试环境和辅测试环境。

主测试环境是测试软件功能、安全可靠性、性能、易用性等大多数指标的主要环境。

一般来说，配置主测试环境可遵循下列原则：

　　1.符合软件运行的最低要求。

测试环境首先要保证能支撑软件正常运行。

　　2.选用比较普及的操作系统和软件平台。

例如，一个软件若声称支持“Windows9X/ME/NTWorkstation/2000professional”和“MSOffice97/2000/XP”，一般我们会采用如“Windows2000professional+MSOffice2000”的流行环境。

　　3.营造相对简单、独立的测试环境。

除了操作系统，测试机上只安装软件运行和测试必需的软件，以免不相关的软件影响测试实施。

　　4.无毒的环境。

利用有效的正版杀毒软件检测软件环境，保证测试环境中没有病毒。

　　辅测试环境常常用来满足不同的测试需求或特殊测试项目：

　　兼容性测试：

在满足软件运行要求的范围内，可选择一些典型的操作系统和常用应用软件对其安装卸载和主要功能进行验证。

　　模拟真实环境测试：

有些软件，特别是面向大众的商品化软件，在测试时常常需要考察在真实环境中的表现。

如测试杀毒软件的扫描速度时，硬盘上布置的不同类型文件的比例要尽量接近真实环境，这样测试出来的数据才有实际意义。

　　横向对比测试：

利用辅测试环境“克隆”出完全一致的测试环境，从而保证各个被测软件平等对比。

4软件测试实践之测试环境的规划与管理[1]

测试环境是指为了完成软件测试工作所必需的计算机硬件、软件、网络设备、历史数据的总称。

毫无疑问，稳定和可控的测试环境，可以使测试人员花费较少的时间就完成测试用例的执行，也无需为测试用例、测试过程的维护花费额外的时间，并且可以保证每一个被提交的缺陷都可以在任何时候被准确的重现。

　　简单的说，经过良好规划和管理的测试环境，可以尽可能的减少环境的变动对测试工作的不利影响，并可以对测试工作的效率和质量的提高产生积极的作用。

　　一、规划测试环境——让环境为你服务

　　对于“金山词霸”这样的软件，大多数测试工作都可以在一台单独的电脑上完成，而对于一套电信系统，为了执行测试用例，你可能会需要搭建一个由多台计算机以及其他网络设备组成，采用集群和负载均衡技术，并且接驳到Internet的计算机网络。

　　不同的行业应用，不同的质量目标，都可能会影响到测试环境的规划。

但从测试工作自身的要求来看，一条应当遵守的原则就是“尽可能的还原软件在用户那里最终实际运行的环境”——虽然在很多时候这是不现实的。

^_^

　　通常来说，我们所需要搭建的环境，主要是用于被测应用的系统测试——单元测试和集成测试由开发人员在开发环境中进行，而验收测试则在用户的最终应用环境中进行，因此都可以暂不考虑。

　　为了确定测试环境的组成，我们需要明确以下问题：

　　1.所需要的计算机的数量，以及对每台计算机的硬件配置要求，包括CPU的速度、内存和硬盘的容量、网卡所支持的速度、打印机的型号等;

　　2.部署被测应用的服务器所必需的操作系统、数据库管理系统、中间件、WEB服务器以及其他必需组件的名称、版本，以及所要用到的相关补丁的版本;

　　3.用来保存各种测试工作中生成的文档和数据的服务器所必需的操作系统、数据库管理系统、中间件、WEB服务器以及其他必需组件的名称、版本，以及所要用到的相关补丁的版本;

　　4.用来执行测试工作的计算机所必需的操作系统、数据库管理系统、中间件、WEB服务器以及其他必需组件的名称、版本，以及所要用到的相关补丁的版本;

　　5.是否需要专门的计算机用于被测应用的服务器环境和测试管理服务器的环境的备份;

　　6.测试中所需要使用的网络环境。

例如，如果测试结果同接入Internet的线路的稳定性有关，那么应该考虑为测试环境租用单独的线路;

如果测试结果与局域网内的网络速度有关，那么应该保证计算机的网卡、网线以及用到的集线器、交换机都不会成为瓶颈;

　　7.执行测试工作所需要使用的文档编写工具、测试管理系统、性能测试工具、缺陷跟踪管理系统等软件的名称、版本、License数量，以及所要用到的相关补丁的版本。

对于性能测试工具，则还应当特别关注所选择的工具是否支持被测应用所使用的协议;

　　8.为了执行测试用例，所需要初始化的各项数据，例如登陆被测应用所需的用户名和访问权限，或其他基础资料、业务资料;

对于性能测试，还应当特别考虑执行测试场景前应当满足的历史数据量。

当然，还有另外一个非常关键的问题：

在测试过程中受到影响的数据如何恢复?

　　明确了上面的问题后，明确哪些条件是可以满足的，哪些是需要其他部门协助调配、采购或者支援的。

建议在搭建测试环境之前，把上面的问题做成一张CheckList，并为每一项指定一个责任人，完成一项就填写一项，最终形成的文档则作为测试环境的配置说明文档使用。

当然，如果时间或其他条件允许，应当做好应急预案，尽量保证在环境失效时不会对正常工作产生太大的影响。

二、管理测试环境——把变化掌握在手中

　　测试环境搭建好以后不太可能永远不发生变化，至少被测应用的每次版本发布都会对测试环境产生或多或少的影响。

而应对变化之道，不是禁止变化，而是“把变化掌握在手中”。

下面的这些建议可以帮助你尽可能摆脱环境变化所带来的不利影响。

　　1.设置专门的测试环境管理员角色

　　每个测试项目或测试小组都应当配备一名专门的测试环境管理员，其职责包括：

　　测试环境的搭建。

包括操作系统、数据库、中间件、WEB服务器等必须软件的安装，配置，并做好各项安装、配置手册的编写;

　　记录组成测试环境的各台机器的硬件配置、IP地址、端口配置、机器的具体用途，以及当前网络环境的情况;

　　完成被测应用的部署，并做好发布文档的编写;

　　测试环境各项变更的执行及记录;

　　测试环境的备份及恢复;

　　操作系统、数据库、中间件、WEB服务器以及被测应用中所需的各用户名、密码以及权限的管理;

　　当测试组内多名成员需要占用服务器并且相互之间存在冲突时（例如在执行性能测试时，在同一时刻应当只有一个场景在运行），负责对服务器时间进行分配和管理。

　　2.明确测试环境管理所需的各种文档

　　一般来说，下面的几个文档是必需的，当然你也可以根据需要增加新的文档。

　　组成测试环境的各台计算机上各项软件的安装配置手册，记录各项软件的名称、版本、安装过程、相关参数的配置方法等，并记录好历次软件环境的变更情况;

　　组成测试环境的各台机器的硬件环境文档，记录各台机器的硬件配置（CPU/内存/硬盘/网卡）、IP地址、具体用途以及历次的变更情况;

　　被测应用的发布手册，记录被测应用的发布/安装方法，包括数据库表的创建、数据的导入、应用层的安装等。

另外，还需要记录历次被测应用的发布情况，对版本差异进行描述;

　　测试环境的备份和恢复方法手册，并记录每次备份的时间、备份人、备份原因（与上次备份相比发生的变化）以及所形成的备份文件的文件名和获取方式;

　　用户权限管理文档，记录访问操作系统、数据库、中间件、WEB服务器以及被测应用时所需的各种用户名、密码以及各用户的权限，并对每次变更进行记录。

　　3.测试环境访问权限的管理

　　应当为每个访问测试环境的测试人员和开发人员设置单独的用户名，并根据不同的工作需要设置不同的访问权限，以避免误操作对测试环境产生不利的影响。

下面的要求可以作为建立“测试环境访问权限管理规范”的基础。

访问操作系统、数据库、中间件、WEB服务器以及被测应用等所需的各种用户名、密码、权限，由测试环境管理员统一管理;

　　测试环境管理员拥有全部的权限;

　　除对被测应用的访问权限外，一般不授予开发人员对测试环境其他部分的访问权限。

如的确有必要（例如查看系统日志），则只授予只读权限;

　　除测试环境管理员外，其他测试组成员不授予删除权限;

　　用户及权限的各项维护、变更，需要记录到相应的“用户权限管理文档”中。

　　4.测试环境的变更管理

　　对测试环境的变更应当形成一个标准的流程，并保证每次变更都是可追溯的和可控的。

下面的几项要点并不是一个完整的流程，但是可以帮助你实现这个目标。

　　测试环境的变更申请由开发人员或测试人员提出书面申请，由测试环境管理员负责执行。

测试环境管理员不应接受非正式的变更申请（例如口头申请）;

　　对测试环境的任何变更均应记入相应的文档;

　　同每次变更相关的变更申请文档、软件、脚本等均应保留原始备份，作为配置项进行管理;

　　对于被测应用的发布，开发人员应将整个系统（包括数据库、应用层、客户端等）打包为可直接发布的格式，由测试环境管理员负责实施。

测试环境管理员不接受不完整的版本发布申请;

　　对测试环境做出的变更，应该可以通过一个明确的方法返回到之前的状态。

　　5.测试环境的备份和恢复

　　对于测试人员来说，测试环境必须是可恢复的，否则将导致原有的测试用例无法执行，或者发现的缺陷无法重现，最终使测试人员已经完成的工作失去价值。

因此，应当在测试环境（特别是软件环境）发生重大变动（例如安装操作系统、中间件或数据库，为操作系统、中间件或数据库打补丁等对系统产生重大影响并难以通过卸载恢复）时进行完整的备份，例如使用Ghost对硬盘或某个分区进行镜像备份。

并由测试环境管理员在相应的“备份记录”文档中记录每次备份的时间、备份人以及备份原因（与上次备份相比发生的变化），以便于在需要时将系统重新恢复到安全可用的状态。

　　另外，每次发布新的被测应用版本时，应当做好当前版本的数据库备份。

而在执行测试用例或性能测试场景之前，也应当做好数据备份或准备数据恢复方案，例如通过运行SQL脚本来将数据恢复到测试执行之前的状态，以便于重复的使用原有的数据，减少因数据准备和维护而占用的工作量，并保证测试用例的有效性和缺陷记录的可重现。

5软件测试中如何进行增加、编辑、删除和密码修改测试用例

软件测试中如何进行增加、编辑、删除和密码修改测试用例

增加、编辑、删除等功能，几乎每个系统都会用到，针对这几个方面，写如下测试用例

一：

增加

1：

在添加页面，输入要添加的数据项均合理，检查数据库以及列表页是否添加了相应的数据

2：

在添加页面，留出一个必填项为空，检查是否会提示

3：

按照边界值等价类设计测试用例原则设计其他输入项测试用例

4：

不符合要求的地方要有错误提示

5：

是否支持table键

6：

按enter是否能保存

7：

若提示保存，也要查看数据库里是否多了一条数据

二、删除

1、删除一个数据库中存在的数据，然后查看数据库以及列表也中是否删除

2、删除一个数据库中并不存在的数据，看是否有错误提示，并且数据库中没有数据被删除

3、输入一个格式错误的数据，看是否有错误提示，并且数据库中没有数据被删除

4、输入正确数据前加空格，看是否能正确删除数据

5、不输入任何字符

6、是否支持table键

7、是否支持enter键

三、编辑

对编辑列表页中的每个编辑项进行修改，点击保存，查看是否编辑成功

依次对每个编辑项进行修改，点击保存，查看是否编辑成功

对于必填项，我们可以修改为空、全角/半角空格，点击保存时，查看是否编辑成功

现在很多编辑项目中有很多图片预览的功能，如果对于没有上传的图片，查看编辑页面时，是否显示默认图片。

如果上传了图片，是否显示上传的图片。

（因为实际工作中，很多客户很介意这个节目图片显示红叉）

在编辑的时候，也要注意添加时，每个编辑项的长度校验，有些时候，添加时有长度限制，而编辑的时候却没有

在编辑的时候，查看界面的字段是否同添加时字段显示一致，以及冒号是否也一致（无论是中文冒号或者是英文冒号，但是必须要一致）

四、密码修改

实际当中，根据具体情况具体分析，实际测试中可能只用到几条而已，例如：

银行卡密码的修改，就不用考虑英文和非法字符，更不用考虑tap之类的快捷键

有时，需要根据需求具体分析了，例如：

连续出错多少次出现的提示，和一些软件修改密码要求一定时间内有一定的修改次数限制等。

1、旧密码、新密码、确认新密码都为空时，查看系统是否会有提示

2、不输入旧密码，直接改密码

3、输入错误的旧密码

4、不输入确认新密码

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

6、新密码中有空格

7、新密码为空

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

9、新密码为符号要求的最少字符

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

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

12、新密码为最多字符+1

13、新密码为最少字符-1

14、新密码为最少字符+1

15、新密码为非允许字符（例如：

密码要求是英文和数字组成，则要试汉字和符号等）

16、看是否支持tap和enter键等

17、密码是否可以复制、粘贴，是否以*之类的加密符号

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

19、新密码和旧密码一样能否修改成功

6软件测试用例编写的一点看法

对于测试用例的编写提一些个人的建议。

　　1、测试用例的划分也要单一，一个测试用例只检查功能点的一种情况。

一个用例检查的情况太多，会导致用例的目的不清晰，而且这样组织用例，有利于需求覆盖率的统计。

一个功能点我们

　　2、功能划分时，一定要简单、清晰，一个测试用例集就只需要检查一个功能模块。

如果包含的功能点太多，会让我们的测试用例比较混乱，降低了可读性。

测试了那些情况，以及哪些功能点我们在重点测试，一目了然。

　　3、测试用例要有一个简单的目的描述，有助于读者对测试用例的理解。

　　4、测试用例的步骤描述要简单、清晰，一步就是一步。

比如：

第一步，用户登陆;

第二步，用户点击“用户信息”;

第三步，用户修改姓名为“张&

三”;

第四步，用户点击保存。

这有利于提高用例的可操作性。

　　5、测试用例的数据要明确，特别是前提数据和要检查的数据。

比如，测试准备数据：

用户：

张三，李四，王二。

在排序后用例的预期结果为：

李四，王二，张三。

这样，用例在执行时

　　仅是自己的一点看法，供大家参考

7软件测试中一个ajax的经典测试用例

和大家分享一个ajax的经典测试用例，希望能帮助到大家

[1]写index.jsp文件

　<

%@pagecontentType="

text/html;

charset=gb2312"

%>

!

DOCTYPEHTMLPUBLIC"

-//W3C//DTDHTML4.01Transitional//EN"

>

html>

head>

<

title>

MyJSP'

index.jsp'

startingpage<

/title>

metahttp-equiv="

pragma"

content="

no-cache"

cache-control"

expires"

0"

description"

Thisismypage"

linkrel="

stylesheet"

type="

text/css"

href="

styles.css"

/head>

body>

scripttype="

text/javascript"

　varreq;

functionvalidate（）{

　varidField=document.getElementById（"

userid"

）;

　varurl="

servlet/ValidateServlet?

id="

+escape（idField.value）;

　if（window.XMLHttpRequest）{

　alert（"

　req=newXMLHttpRequest（）;

　}elseif（window.ActiveXObject）{

1"

　req=newActiveXObject（"

Microsoft.XMLHTTP"

　}

　if（req）{

　req.open（"

GET"

url,true）;

　req.onreadystatechange=callback;

　req.send（null）;

　functioncallback（）{

　if（req.readyState==4）{

　if（req.status==200）{

　parseMessage（）;

　//updatetheHTMLDOMbasedonwhetherornotmessageisvalid

　}else{

　alert（"

Notabletoretrievedescription"

+req.statusText）;

　functionparseMessage（）{

　varmessage=req.responseXML.getElementsByTagName（"

message"

）[0];

　varname=req.responseXML.getElementsByTagName（"

name"

　setMessage（message.firstChild.data,name.firstChild.data）;

　functionsetMessage（message,name）{

　varuserMessageElement=document.getElementById（"

userIdMessage"

　userMessageElement.innerHTML="

fontcolor="

red"

"

+message+"

you"

+name+"

/font>

;

/script>

divid="

/div>

inputty