新人要学习的东西很多，先学什么后学什么?该如何分配?这是新人指南知识沉淀中整理出来的，大家可参考下：业务、技能、工具、流程……很多培训，它们之间哪个是我该首先掌握的?

    1、业务方面

    你所在业务线的业务知识，肯定是重点。每位新人来后，都会被分配到不同的组，不同的组其业务重点也不相同。建议新人可以在测试环境下实际操作下。

    把握当前工作的重点：虽然你处于某一条业务线，每条业务线的业务知识也是很多的，要和tl沟通，明确自己以后的工作重点。先从当前工作的重点开始，一点带面，逐渐掌握业务

    2、技能

    不同的新人技能要求也不一样。淘宝网将其分为多种测试类型：功能测试、性能测试、自动化测试、接口测试、安全性测试。

    每位新人要根据自己“入职时主管对你的定位”+“目前的优势”+“自己打算将来的发展方向”选择不同的技能提高。

    因为市面上的技能何其多，要塑造自己的优势。

    3、工具

    工具方面总体来说，跟技能是相同的。

    另外还要考虑公司需要的工具，以后要推广的工具。现在淘宝网已用ruby取代了QTP的自动化测试。

    4、流程

    查看流程规范。最重要的2个流程，就是“项目测试流程”和“日常测试流程”。

    我觉得还有比较重要的是注意发布流程的相关约定，比如周二或周四发布要在什么时间确保提交测试、什么时间预发布测试。

    对于新人，在项目中实践，通过执行别人写的用例，可以很快的体会测试的思想，掌握一些测试的基本方法。但自己编写TC，从UC提取TC，确实还需要一定时间的锻炼。

    记得刚开始的时候，从头到尾的看完UC，很多规则，脑袋看得晕乎乎的，TC的也是像抓图似的，抓了这块忘了那块。经过一段时间的练习，我逐渐掌握了较为系统的测试用例的编写方法，现把自己的一点体会总结下：

    1、在测试之前，要熟读prd和UC，深入的挖掘UC，对于新增的业务，如果对之前的老业务不了解，那么一定要找出相应的资料了解下其中的规则。可以参照 自己所在产品线业务的mm图，熟悉整个业务框架。对于自己不明确的地方，UC上没有指出来的，记录下来，以便在UC评审的时候提出，及时的得到解答。

    2、根据UC编写TC。多参照QC里写的好的用例，对照着UC，会收获很多。目前各产品线也在总结一些公用控件的测试用例，为以后的测试形成规范和指导。

    3、还需要理论结合实践。测试用例的设计方法如：等价类划分、边界值分析、因果图法、判定表法等，结合相应的实例来学习会比较快的理解。

    4、BUG的经验总结，每周周会我们社区组成员都会分享这周发现的经典bug，并记录在cf上，彼此共同进步，感觉很好。也可以多看看站点上整理的经典bug，开拓自己发现bug的思路。

    刚进入这个行业，一切还不熟悉，但身边这么多热心的有经验的人，主动与他们交流，向他们请教自己心中的疑惑，自己平时多做总结，你会在不知不觉中提高自己的测试技术。

　　1      简介：
Bugzilla是Mozilla公司向我们提供的一个开源的免费缺陷跟踪工具。作为一个产品缺陷的记录及跟踪工具，它能够为你建立一个完善的Bug跟 踪体系，包括报告Bug、查询Bug记录并产生报表、处理解决、管理员系统初始化和设置四部分。并具有如下特点：
●       基于Web方式，安装简单、运行方便快捷、管理安全。
●      有利于缺陷的清楚传达。本系统使用数据库进行管理，提供全面 详尽的报告输入项，产生标准化的Bug报告。提供大量的分析选项和强大的查询匹配能力，能根据各种条件组合进行Bug统计。当错误在它的生命周期中变化 时，开发人员、测试人 员、及管理人员将及时获得动态的变化信息，允许你获取历史纪录，并在检查错误的状态时参考这一记录。
●      系统灵活，强大的可配置能力。Bugzilla工具可以对软件产品设定不同的模块，并针对不同的模块设定开发人员 和测试人员；这样可以实现提交报告时自动发给指定的责任人；并可设定不同的小组。设定不同的用户对Bug记录的操作权限不同，可进行有效的控制管理。允许 设定不同的严重程度和优先级，可以在错误的生命期中管理错误，从最初的报告到最后的解决，都有详细的记录，确保了错误不会被忽略，同时，可以让开发人员将 注意力集中在优先级和严重程度高的错误上。
●       自动发送Email通知相关人员。根据设定的不同责任人，自动发送最新的动态信息，有效的帮助测试人员和开发人员进行沟通。
2      Bugzilla操作流程：

2.1   用户登录及设置流程：

●      打开浏览器，输入Bugzilla服务器地址：http://server/bugzilla/
●      进入主页面后，点击【新建帐号】，进入注册页面。
●      在注册页面中输入E-Mail地址和用户代号，然后，点击【Create Account】，随后，你将收到一封包含初始密码的E-Mail。
●      在收到E-Mail之后，点击【登录】，在帐号栏输入注册时使用的E-Mail地址，在密码栏输入邮件里通知的初始密码，然后，点击【Login】。
●      如忘记密码，在登陆页面中输入注册用户名，点击【Submit Request】,根据收到的邮件进行重新设置密码。
●      如果成功登录后，点击【Edit属性】->【帐号设置】，进行密码修改。
●      点击【Edit属性】->【邮件设置】，进行邮件通知设置。
●      点击【Edit属性】->【权限】，进行权限查询。
2.2   Bug的处理流程概述：
●      测试人员或开发人员发现bug后，判断属于哪个模块的问题，填写bug报告后，通过Email通知项目组长或直接通知开发者。
●      项目组长根据具体情况，重新reassigned分配给bug所属的开发者。
●      开发者收到E-Mail信息后，判断是否为自己的修改范围。
A.      若不是，重新reassigned分配给项目组长或应该分配的开发者；
B.      若是，进行处理，resolved并给出解决方法。（可创建补丁附件及补充说明）；
●       测试人员查询开发者已修改的bug，进行重新测试。（可创建test case附件）
A.      经验证无误后，修改状态为VERIFIED。待整个产品发布后，修改为CLOSED。
B.      还有问题，REOPENED，状态重新变为“New"，并发邮件通知。
●       如果这个BUG一周内一直没被处理过。Bugzilla就会一直用E-Mail骚扰它的属主，直到采取行动为止。

软件测试步骤

• 测试过程按4个步骤进行，即单元测试、集成测试、确认测试和系统测试及发版测试。

• 开始是单元测试，集中对用源代码实现的每一个程序单元进行测试，检查各个程序模块是否正确地实现了规定的功能。

• 集成测试把已测试过的模块组装起来，主要对与设计相关的软件体系结构的构造进行测试。
• 确认测试则是要检查已实现的软件是否满足了需求规格说明中确定了的各种需求，以及软件配置是否完全、正确。
• 系统测试把已经经过确认的软件纳入实际运行环境中，与其它系统成份组合在一起进行测试。
单元测试 (Unit Testing)
• 单元测试又称模块测试，是针对软件设计的最小单位 ─ 程序模块，进行正确性检验的测试工作。其目的在于发现各模块内部可能存在的各种差错。
• 单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。
1. 单元测试的内容
• 在单元测试时，测试者需要依据详细设计说明书和源程序清单，了解该模块的I/O条件和模块的逻辑结构，主要采用白盒测试的测试用例，辅之以黑盒测试 的测试用例，使之对任何合理的输入和不合理的输入，都能鉴别和响应。

(1) 模块接口测试
• 在单元测试的开始，应对通过被测模块的数据流进行测试。测试项目包括：
– 调用本模块的输入参数是否正确；
– 本模块调用子模块时输入给子模块的参数是否正确；
– 全局量的定义在各模块中是否一致；

•     在做内外存交换时要考虑：

– 文件属性是否正确；
–   OPEN与CLOSE语句是否正确；
– 缓冲区容量与记录长度是否匹配；
– 在进行读写操作之前是否打开了文件；
– 在结束文件处理时是否关闭了文件；
– 正文书写／输入错误，
–   I／O错误是否检查并做了处理。

(2) 局部数据结构测试
• 不正确或不一致的数据类型说明
• 使用尚未赋值或尚未初始化的变量
• 错误的初始值或错误的缺省值
• 变量名拼写错或书写错
• 不一致的数据类型
• 全局数据对模块的影响
(3) 路径测试
• 选择适当的测试用例，对模块中重要的执行路径进行测试。
• 应当设计测试用例查找由于错误的计算、不正确的比较或不正常的控制流而导致的错误。
• 对基本执行路径和循环进行测试可以发现大量的路径错误。
(4) 错误处理测试
• 出错的描述是否难以理解
• 出错的描述是否能够对错误定位
• 显示的错误与实际的错误是否相符
• 对错误条件的处理正确与否
• 在对错误进行处理之前，错误条件是否已经引起系统的干预等
(5) 边界测试
• 注意数据流、控制流中刚好等于、大于或小于确定的比较值时出错的可能性。对这些地方要仔细地选择测试用例，认真加以测试。
• 如果对模块运行时间有要求的话，还要专门进行关键路径测试，以确定最坏情况下和平均意义下影响模块运行时间的因素。

2. 单元测试的步骤
• 模块并不是一个独立的程序，在考虑测试模块时，同时要考虑它和外界的联系，用一些辅助模块去模拟与被测模块相联系的其它模块。
– 驱动模块 (driver)
– 桩模块 (stub) ── 存根模块

• 如果一个模块要完成多种功能，可以将这个模块看成由几个小程序组成。必须对其中的每个小程序先进行单元测试要做的工作，对关键模块还要做性能测试。
• 对支持某些标准规程的程序，更要着手进行互联测试。有人把这种情况特别称为模块测试，以区别单元测试。
集成测试（Integrated Testing）
• 集成测试 (集成测试、联合测试）
• 通常，在单元测试的基础上，需要将所有模块按照设计要求组装成为系统。这时需要考虑的问题是：
– 在把各个模块连接起来的时侯，穿越模块接口的数据是否会丢失；
– 一个模块的功能是否会对另一个模块的功能产生不利的影响；

– 各个子功能组合起来，能否达到预期要求的父功能；
– 全局数据结构是否有问题；
– 单个模块的误差累积起来，是否会放大，从而达到不能接受的程度。
在单元测试的同时可进行集成测试，
发现并排除在模块连接中可能出现
的问题，最终构成要求的软件系统。

•    子系统的集成测试特别称为部件测试，它所做的工作是要找出集成后的子系统与系统需求规格说明之间的不一致。
• 通常，把模块集成成为系统的方式有两种
– 一次性集成方式
– 增殖式集成方式

1. 一次性集成方式(big bang)
• 它是一种非增殖式组装方式。也叫做整体拼装。
• 使用这种方式，首先对每个模块分别进行模块测试，然后再把所有模块组装在一起进行测试，最终得到要求的软件系统。

2. 增殖式集成方式
• 这种集成方式又称渐增式集成
• 首先对一个个模块进行模块测试，然后将这些模块逐步组装成较大的系统
• 在集成的过程中边连接边测试，以发现连接过程中产生的问题
• 通过增殖逐步组装成为要求的软件系统。

(1) 自顶向下的增殖方式
• 这种集成方式将模块按系统程序结构，沿控制层次自顶向下进行组装。
• 自顶向下的增殖方式在测试过程中较早地验证了主要的控制和判断点。
• 选用按深度方向组装的方式，可以首先实现和验证一个完整的软件功能。

(2) 自底向上的增殖方式
• 这种集成的方式是从程序模块结构的最底层的模块开始集成和测试。
• 因为模块是自底向上进行组装，对于一个给定层次的模块，它的子模块（包括子模块的所有下属模块）已经组装并测试完成，所以不再需要桩模块。在模块的 测试过程中需要从子模块得到的信息可以直接运行子模块得到。

•    自顶向下增殖的方式和自底向上增殖的方式各有优缺点。
• 一般来讲，一种方式的优点是另一种方式的缺点。
(3) 混合增殖式测试
• 衍变的自顶向下的增殖测试
– 首先对输入／输出模块和引入新算法模块进行测试;
– 再自底向上组装成为功能相当完整且相对独立的子系统;
– 然后由主模块开始自顶向下进行增殖测试。

• 自底向上-自顶向下的增殖测试
– 首先对含读操作的子系统自底向上直至根结点模块进行组装和测试;
– 然后对含写操作的子系统做自顶向下的组装与测试。
• 回归测试
– 这种方式采取自顶向下的方式测试被修改的模块及其子模块;
– 然后将这一部分视为子系统，再自底向上测试。
关键模块问题
• 在组装测试时，应当确定关键模块，对这些关键模块及早进行测试。
• 关键模块的特征：
① 满足某些软件需求；
② 在程序的模块结构中位于较高的层次（高层控制模块）；
③ 较复杂、较易发生错误；
④ 有明确定义的性能要求。

确认测试（Validation Testing）
• 确认测试又称有效性测试。任务是验证软件的功能和性能及其它特性是否与用户的要求一致。
• 对软件的功能和性能要求在软件需求规格说明书中已经明确规定。它包含的信息就是软件确认测试的基础。

1. 进行有效性测试（黑盒测试）
• 有效性测试是在模拟的环境 (可能就是开发的环境) 下，运用黑盒测试的方法，验证被测软件是否满足需求规格说明书列出的需求。
• 首先制定测试计划，规定要做测试的种类。还需要制定一组测试步骤，描述具体的测试用例。

• 通过实施预定的测试计划和测试步骤，确定
– 软件的特性是否与需求相符；
– 所有的文档都是正确且便于使用；
– 同时，对其它软件需求，例如可移植性、兼容性、出错自动恢复、可维护性等，也都要进行测试

• 在全部软件测试的测试用例运行完后，所有的测试结果可以分为两类：
– 测试结果与预期的结果相符。这说明软件的这部分功能或性能特征与需求规格说明书相符合，从而这部分程序被接受。
– 测试结果与预期的结果不符。这说明软件的这部分功能或性能特征与需求规格说明不一致，因此要为它提交一份问题报告。
2. 软件配置复查
软件配置复查的目的是保证

a 软件配置的所有成分都齐全；

b各方面的质量都符合要求；

c具有维护阶段所必需的细节；

d而且已经编排好分类的目录。

应当严格遵守用户手册和操作手册中规定的使用步骤，以便检查这些文档资料的完整性和正确性。

验收测试（Acceptance Testing）
• 在通过了系统的有效性测试及软件配置审查之后，就应开始系统的验收测试。
• 验收测试是以用户为主的测试。软件开发人员和QA（质量保证）人员也应参加。
• 由用户参加设计测试用例，使用生产中的实际数据进行测试。

• 在测试过程中，除了考虑软件的功能和性能外，还应对软件的可移植性、兼容性、可维护性、错误的恢复功能等进行确认。
• 确认测试应交付的文档有：
– 确认测试分析报告
– 最终的用户手册和操作手册
– 项目开发总结报告。

系统测试（System Testing）
• 系统测试，是将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其它系统元素结合在一起， 在实际运行环境下，对计算机系统进行一系列的组装测试和确认测试。
• 系统测试的目的在于通过与系统的需求定义作比较, 发现软件与系统的定义不符合或与之矛盾的地方。

α测试和β测试
• 在软件交付使用之后，用户将如何实际使用程序，对于开发者来说是无法预测的。
•    α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。

•     α测试的目的是评价软件产品的FLURPS（即功能、局域化、可使用性、可靠性、性能和支持）。尤其注重产品的界面和特色。
•     α测试可以从软件产品编码结束之时开始，或在模块（子系统）测试完成之后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。

•     β测试是由软件的多个用户在实际使用环境下进行的测试。这些用户返回有关错误信息给开发者。
• 测试时，开发者通常不在测试现场。因而，β测试是在开发者无法控制的环境下进行的软件现场应用。
• 在β测试中，由用户记下遇到的所有问题，包括真实的以及主观认定的，定期向开发者报告。

•    β测试主要衡量产品的FLURPS。着重于产品的支持性，包括文档、客户培训和支持产品生产能力。
• 只有当α测试达到一定的可靠程度时，才能开始β测试。它处在整个测试的最后阶段。同时，产品的所有手册文本也应该在此阶段完全定稿。
测试类型
• 软件测试是由一系列不同的测试组成。主要目的是对以计算机为基础的系统进行充分的测试。
功能测试
功能测试是在规定的一段时间内运行软件系统的所有功能，以验证这个软件系统有无严重错误。

强度测试

强度测试是要检查在系统运行环境不正常乃至发生故障的情况下，系统可以运行到何种程度的测试。例如：
– 把输入数据速率提高一个数量级，确定输入功能将如何响应。
– 设计需要占用最大存储量或其它资源的测试用例进行测试。

–   设计出在虚拟存储管理机制中引起“颠簸”的测试用例进行测试。
– 设计出会对磁盘常驻内存的数据过度访问的测试用例进行测试。
• 强度测试的一个变种就是敏感性测试。在程序有效数据界限内一个小范围内的一组数据可能引起极端的或不平稳的错误处理出现，或者导致极度的性能下降的 情况发生。此测试用以发现可能引起这种不稳定性或不正常处理的某些数据组合。

性能测试
• 性能测试是要检查系统是否满足在需求说明书中规定的性能。特别是对于实时系统或嵌入式系统。
• 性能测试常常需要与强度测试结合起来进行，并常常要求同时进行硬件和软件检测。
• 通常，对软件性能的检测表现在以下几个方面：响应时间、吞吐量、辅助存储区，例如缓冲区，工作区的大小等、处理精度，等等。

恢复测试
恢复测试是要证实在克服硬件故障(包括掉电、硬件或网络出错等)后，系统能否正常地继续进行工作，并不对系统造成任何损害。
• 为此，可采用各种人工干预的手段，模拟硬件故障，故意造成软件出错。并由此检查：
– 错误探测功能──系统能否发现硬件失效与故障；

– 能否切换或启动备用的硬件；
– 在故障发生时能否保护正在运行的作业和系统状态；
– 在系统恢复后能否从最后记录下来的无错误状态开始继续执行作业，等等。
– 掉电测试：其目的是测试软件系统在发生电源中断时能否保护当时的状态且不毁坏数据，然后在电源恢复时从保留的断点处重新进行操作。

配置测试

• 这类测试是要检查计算机系统内各个设备或各种资源之间的相互联结和功能分配中的错误。
• 它主要包括以下几种：
– 配置命令测试：验证全部配置命令的可操作性（有效性）；特别对最大配置和最小配置要进行测试。软件配置和硬件配置都要测试。

–   循环配置测试：证明对每个设备物理与逻辑的，逻辑与功能的每次循环置换配置都能正常工作。
– 修复测试：检查每种配置状态及哪个设备是坏的。并用自动的或手工的方式进行配置状态间的转换。

安全性测试
安全性测试是要检验在系统中已经存在的系统安全性、保密性措施是否发挥作用，有无漏洞。
• 力图破坏系统的保护机构以进入系统的主要方法有以下几种：
– 正面攻击或从侧面、背面攻击系统中易受损坏的那些部分；
– 以系统输入为突破口，利用输入的容错性进行正面攻击；

–   申请和占用过多的资源压垮系统，以破坏安全措施，从而进入系统；
– 故意使系统出错，利用系统恢复的过程，窃取用户口令及其它有用的信息；
– 通过浏览残留在计算机各种资源中的垃圾（无用信息），以获取如口令，安全码，译码关键字等信息；
– 浏览全局数据，期望从中找到进入系统的关键字；
– 浏览那些逻辑上不存在，但物理上还存在的各种记录和资料等。

可使用性测试

• 可使用性测试主要从使用的合理性和方便性等角度对软件系统进行检查，发现人为因素或使用上的问题。
• 要保证在足够详细的程度下，用户界面便于使用；对输入量可容错、响应时间和响应方式合理可行、输出信息有意义、正确并前后一致；出错信息能够引导用 户去解决问题；软件文档全面、正规、确切。

安装测试
安装测试的目的不是找软件错误，而是找安装错误。
• 在安装软件系统时，会有多种选择。
– 要分配和装入文件与程序库
– 布置适用的硬件配置
– 进行程序的联结。
• 而安装测试就是要找出在这些安装过程中出现的错误。

• 安装测试是在系统安装之后进行测试。它要检验：
– 用户选择的一套任选方案是否相容；
– 系统的每一部分是否都齐全；
– 所有文件是否都已产生并确有所需要的内容；
– 硬件的配置是否合理，等等。

容量测试

• 容量测试是要检验系统的能力最高能达到什么程度。例如，
– 对于编译程序，让它处理特别长的源程序；
– 对于操作系统，让它的作业队列“满员”；
– 对于信息检索系统，让它使用频率达到最大。
在使系统的全部资源达到“满负荷”的情形下，测试系统的承受能力。

文档测试

这种测试是检查用户文档(如用户手册)的清晰性和精确性。
• 用户文档中所使用的例子必须在测试中一一试过，确保叙述正确无误。

自动测试
• 认识自动测试
• 什么时候使用自动测试

　　在实际的单元测试过程中总会有一些错误的认识左右着我们，使之成为单元测试最大的障碍，在此将其一一分析如下：

　　它太浪费时间了，现在要赶进度，时间上根本不允许，或者随便做做应付领导。

　　我是一个很棒的程序员，我写的代码肯定是没有问题的。

　　做单元测试太烦了，直接集成，到时有问题在集成测试时肯定能发现的，实在不行在系统测试总该能发现吧。

　　它仅仅是证明这些代码做了什么。

　　对于以上错误认识的产生归根结底还是由于对单元测试的理解还是不够，没有真正认识到单元测试的重要性。

　　单元测试的重要性

　　单元测试是软件测试的基础，因此单元测试的效果会直接影响到软件的后期测试，最终在很大程度上影响到产品的质量。从如下几个方面就可以看出单元测试的重要性在何处。

　　时间方面：如果认真的做好了单元测试，在系统集成联调时非常顺利，因此会节约很多时间，反之那些由于因为时间原因不做单元测试或随便做做的则在集成时总会遇到那些本应该在单元测试就能发现的问题，而这种问题在集成时遇到往往很难让开发人员预料到，最后在苦苦寻觅中才发现这是个很低级的错误而在悔恨自己时已经浪费了很多时间，这种时间上的浪费一点都不值得，正所谓得不偿失。

　　测试效果：根据以往的测试经验来看，单元测试的效果是非常明显的，首先它是测试阶段的基础，做好了单元测试，在做后期的集成测试和系统测试时就很顺利。其次在单元测试过程中能发现一些很深层次的问题，同时还会发现一些很容易发现而在集成测试和系统测 试很难发现的问题。再次单元测试关注的范围也特殊，它不仅仅是证明这些代码做了什么，最重要的是代码是如何做的，是否做了它该做的事情而没有做不该做的事情。

　　测试成本：在单元测试时某些问题就很容易发现，如果在后期的测试中发现问题所花的成本将成倍数上升。比如在单元测试时发现1个问题需要1个小时，则在集成测试时发现该问题需要2个小时，在系统测试时发现则需要3个小时，同理还有定位问题和解决问题的 费用也是成倍数上升的，这就是我们要尽可能早的排除尽可能多的bug来减少后期成本的因素之一。

　　产品质量：单元测试的好与坏直接影响到产品的质量，可能就是由于代码中的某一个小错误就导致了整个产品的质量降低一个指标，或者导致更严重的后果，如果我们做好了单元测试这种情况是可以完全避免的。

　　综上所述，单元测试是构筑产品质量的基石，我们不要因为节约单元测试的时间不做单元测试或随便做而让我们在后期浪费太多的不值得的时间，我们也不愿意因为由于节约那些时间导致开发出来的整个产品失败或重来!

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

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

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

用户界面
使用 Web 浏览器作为应用程序的前台的一个原因就是它易于使用。用户知道如何浏览一个构建良好的网站。如果你注重这方面的测试，那么验证应用程序是否易于使用就非常重要了。很多人认为这是测试中最不重要的部分，但是如果你想通过网站赚钱，最好使你的网站使用起来更加方便。

使用说明
应该确认你的站点有使用说明。即使你认为你的网站很简单，也可能有人在某些方面需要征实一下。测试人员需要测试说明文档，验证说明是正确的。还可以根据说明进行操作，确认出现预期的结果。

站点地图和导航条
确认你测试的站点是否有地图。有些网络高手可以直接去自己要去的地方，而不必点击一大堆页面。另外新用户在网站中可能会迷失方向。站点地图和/或导航条可以引导用户进行浏览。需要验证站点地图是否正确。确认地图上的链接是否确实存。地图有没有包括站点上的所有链接。是否每个页面都有导航条? 导航条是否一致? 每个页面的链接是否正常? 导航条是否直观?

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

颜色/背景
由于 web 日益流行，很多人把它看作图形设计作品。不幸的是，有些开发人员对新的背景颜色更感兴趣，以至于忽略了这种背景颜色是否易于浏览。典型的站点是在紫色图片的背景上显示黄色的文本(如果你没有见过这样的站点，请浏览一下 GeoCities 或 AOL 上的个人主页，有不少这样的)。这种页面显得"非常高贵"，但是看起来很费劲。通常来说，使用少许或尽量不使用背景是个不错的选择。如果您想用背景，那么最好使用单色的，和导航条一起放在页面的左边。另外，图案和图片可能会转移用户的注意力。

图片
无论作为屏幕的聚焦点或作为指引的小图标，一张图片都胜过千言万语。有时，告诉用户一个东西的最好办法就是将它展示给用户。但是，带宽对客户端或服务器来说都是非常宝贵的，所以要注意节约使用内存。是否所有的图片对所在的页面都是有价值的，或者它们只是浪费带宽? 使用其它的文件格式(.GIF, .JPG) 是否能使图片的大小减小到 30k 以下? 通常来说，不要将大图片放在首页上，因为这样可能会使用户放弃下载首页。如果用户可以很快看到首页，他可能会浏览站点，否则可能放弃。

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

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

功能测试
Web 站点的功能是贵公司雇佣开发人员而不只是艺术家的原因。就是这一部分与服务器通讯并且最终完成任务。  

链接
链接是使用户从一个页面浏览到另一个页面的重要手段。对于每个链接，需要验证两件事情： 一是该链接将用户带到它所说明的地方，另外就是被链接页面是存在的。这句话听起来有些问题，但是有很多多站点的内部链接都是空的。这实在是无法忍受。

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

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

Cookies
很多用户喜欢甜食，但是开发人员喜欢 web cookie (小甜饼)。如果系统使用了cookie，测试人员需要对它们进行检测。如果在 cookies 中保存了注册信息，请确认该 cookie能够正常工作而且已对这些信息已经加密。如果使用 cookie 来统计次数，需要验证次数累计正确。  

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

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

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

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

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

兼容性测试
需要验证应用程序可以在用户使用的机器上运行。如果您用户是全球范围的，需要测试各种操作系统、浏览器、视频设置和 modem 速度。最后，还要尝试各种设置的组合。

操作系统
你的站点能否在 MAC 和IBM 兼容系统上浏览? 有些字体在某个系统上可能不存在，因此需要确认选择了备用字体。如果用户使用两种操作系统，请确认站点未使用只能在其中一种操作系统上运行的插件。

浏览器
站点能否使用 Netscape、Internet Explorer 或Lynx 进行浏览? 有些 HTML 命令或脚本只能在某些特定的浏览器上运行。请确认有图片的替代文字，因为可能会有用户使用文本浏览器。如果您使用 SSL 安全特性，则只需对 3.0 以上版本的浏览器进行验证，但是对于老版本的用户应该有相关的消息提示。

视频设置
页面版式在 640×400、600×800 或 1024×768 的分辨率模式下是否显示正常? 字体是否太小以至于无法浏览? 或者是太大? 文本和图片是否对齐?

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

打印机
用户可能会将网页打印下来。因此网也在设计的时候要考虑到打印问题，注意节约纸张和油墨。有不少用户喜欢阅读而不是盯着屏幕，因此需要验证网页打印是否正常。有时在屏幕上显示的图片和文本的对齐方式可能与打印出来的东西不一样。测试人员至少需要验证订单确认页面打印是正常的。

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

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

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

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

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

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

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

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

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

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

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

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

      测试用例写的太细化了，则适应不了系统的变更需求；写的太粗糙，则可操作性不强，太随意。如果文档中的对操作步骤描述的过于具体，像下面这样：

　　01.　　在“用户名”项中输入“user”；

　　02.　　在“密码”项中输入“password”；

　　03.　　点击“确定”按钮。

　　这样的描述方式表面看起来可操作性似乎是增强了，任何人拿到这个文档都可以充当测试人员，检查一下这个功能是否存在缺陷。但是我们不要忘记，在开发过程中，变更的存在是必然的。一旦需求、设计或者应用程序中的某些细节发生了变化，比如“用户名”变成了“操作员”，“密码”变成了“口令”，“确定”变成了“登录”，或者输入项所接受的数据类型发生了变化，那么同这部分内容相关的所有的测试用例都需要修改。否则，我们凭什么可以保证这些描述不同的测试用例说的是同一样东西？如果我们只有这么一个测试用例，也许一切都不是问题，但是对于一个业务复杂、功能完整的系统，如果按照这样的方法描述测试用例，最终要么产生大量的测试用例文档，要么产生过长的单个文档。无论是那一种，如果发生了类似于上面 说的变化，维护文档都将变成一次地狱式的体验。这也是为什么在网络上频频出现的这个问题，而且每次出现都会受到测试同行们的关注的原因。

　　那么这个问题应该任何解决呢？测试用例是不是把所有的流程写出来就可以了呢？如何在减少测试用例文档中包含过多琐碎的细节的同时保证测试用例的可操作性呢？又有什么方法可以提高我们维护测试用例文档的效率呢？笔者的建议是：关注“测试思想”而不是关注操作步骤。

       要理解这个问题，首先要弄明白测试用例的作用。就像用例一样，测试用例并不是用来描述具体的实现的，而是着重描述处理问题的思路——对于一项明确的测试内容进行测试的思路。作为测试用例的设计人员，如何理解基本流和备选流？如何深入分析并找到所有需要覆盖的路径和需要检查的特性？我们在测试用 例中应该用容易理解的自然语言清晰的来描述我们将要如何进行测试，而不是简单的把在应用程序上如何操作的烦琐的步骤记录下来。把测试用例设计当成填写具体 操作步骤的表格是人们对测试用例最大的误解。传统的测试用例文档编写有两种方式。一种是填写操作步骤列表：将在软件上进行的操作步骤一步一步详细的记录下 来，包括所有被操作的项目和相应的值。另一种是填写测试矩阵：将被操作项作为矩阵中的一个字段，而矩阵中的一条条记录，则是这些字段的值。网络上对于这两 种方式孰优孰劣的争论，将大家错误的引导向了两个极端：要么采用A，要么采用B。而大家却忽视了一点，对于工作方法的争论，本质上同工具的争论并不是一回 事（例如曾经的VC、BCB之挣）。如果不同的方法各有优势，我们完全可以通过变通的方法，把优势的部分组合在一起来使用。操作步骤列表的优势在于对基本 流和备选流进行分析后，它可以清晰的描述您的测试思路。而测试矩阵则更适合于用来存放测试数据，特别是那些需要人工赋予一个确定的值的特性。下面，我们来看一个例子，当然，这个例子同样是杜撰的。

需求名称：用户登录安全验证

需求描述：用户登录安全验证是为了保证所有登录到系统中的用户，都是由系统管理员预先在系统中设定的。使用系统中不存在的用户名，或者用户名输入正确，但密码输入错误情况，都无法 登录到系统中。当用户使用了不存在的用户名或错误的密码时，系统应分别给出适当的提示。如果用户连续三次无法使用正确的用户名和密码登录到系统，则系统应 给出适当的提示，并退出当前程序。如果用户使用正确的用户名和密码登录到系统，则退出界面，转到系统主界面。对于用户登录界面和程序主界面，请参考相应的 UI设计文档。

　　测试需求：

　　01.　检查能否使用正确的用户名和密码登录到系统；

　　02.　检查能否使用错误的用户名或密码登录到系统；

　　03.　检查使用错误的用户名和密码登录失败超过三次，是否会自动退出当前程序。

　　测试用例：

　　这个例子并不是按照RUP提供的标准模板编写的，它的目的只是要为大家展示，用前面所讲的方法，整理出来的测试需求和设计完成的测试用例到底是个什么样子。所以省略了很多细节，

        不过大家在实际编写测试用例文档的时候，可以根据自己的需要把相应的内容添加上去。同时，也可以在用 户名和密码两个字段中填写准备使用的具体数据。相信大家已经看到，在我们的例子中，测试需求同测试用例之间并非是一一对应的关系因为一条测试需求未必是明 确的对应到一个有效功能的（其实测试需求本身同软件需求和用例之间也未必是一一对应的）。而我们的测试用例所关注的，应该是一个有效功能。

　　不过不用担心，这种情况并不会增加管理测试需求和测试用例的成本，现在市面上提供的测试工具中已经有些是专门用来维护软件需求、测试需求同测试用例之间的关系的，并且它们提供的强大的视图功能还可以让您很容易的查看到测试用例对测试需求的覆盖情况。 对于例子中的测试用例文档，已经被分成了两个部分，一部分是描述了测试用例执行者所应遵循的操作过程，一部分则是在操作中需要使用到的测试数据。这样做的原因是在我们的实际工作中，尤其是在进行功能测试时，很多时候都是使用雷同的操作过程和不同的测试数据来进行的。而使用上面的方法，可以不用再对原本在多个用例中重复出现的操作过程再次描述，而可以把更多的精力放到测试数据的设计和准备上。这样作带来的副产品，就是提高了测试用例的可维护性。怎么？还有人对笔者的观点持怀疑态度？那好吧，那么我们来尝试着证明一下。

　　我们的邮递员要在5个城市内奔波，并且每个城市都有些邮件需要投递，他需要找到可以一次走遍5个城市的所有路线。这听起来似乎并不是太复杂，利用我们已有的数学知识，很容易就可以得到答案。但是对于我们要测试的内容，通常都会包含更多复杂的规则。例 如，我们有三个文本框，每个文本框每次都只能输入一个英文大写字母，允许输入的值只包括：A、B、C三个字母，当三个文本框输入不同的值的时候，我们不知道会发生什么，也不知道它们之间是否会互相影响，所以需要您来设计可以覆盖所有输入情况的测试用例来测试它。瞧，这很简单不是吗？如果我们希望每个测试用 例在执行时一旦出现缺陷都可以很快的找到导致缺陷的原因，那么最好的办法就是每个测试用例只包括一个同其他测试用例不同的输入值。那么可供我们输入的值都有哪些呢？嗯，对于每个文本框，都至少有A、B、C三种已经声明的不同的值，另外，我们还要考虑当文本框为空、输入空格、输入非英文字符以及输入A、B、 C之外的英文字符的情况。那么按照上面的方法，我们会有多少测试用例呢？答案是343个。这只是一个很简单的例子，我们工作中遇到的软件的业务规则和特性 决不会比这少的，那会有多少个测试用例呢？天知道。 不过至少有一点可以肯定，我们无法在原有业务规则发生变化时高效的、无差错的维护完343个测试用例。但是如果使用我们前面所描述的方法，对于操作过程的 改变，您只需要重新维护一次，而对测试数据的维护，也同样是非常简单的，而且并不会因为连续大量修改时出现的错误导致测试用例本身出现歧意。在将主要精力从“设计”操作步骤转移到设计测试数据之后，我们还将从这种方法中获得更大的益处——通过“逆向测试数据分析”来提高测试工作的整体效率。这种“逆向测 试数据分析”的方法，是假设软件中存在多个互相依赖的功能，而且这些功能中包含在“依赖链”最末端，并且不再被其他功能依赖的功能。在我们准备测试数据时，首先从这个“依赖链”最末端的功能开始，分析这个功能会对不同的输入产生哪些不同的结果。然后将所有的输入进行整理，分清哪些输入是来源于其前一个功能的输出。之后，对该功能的上一个功能进行同样的分析， 整理出所有的输入和输出，但是这个功能的输出至少应该包含“依赖链”最末端功能接收到的全部输入。继续按照这样的思路循环向上，直到到达“依赖链”开始端 的功能。不知道您在工作中有没有遇到这样的情况：在对那些“依赖链”上的功能进行测试时，一开始并没有严格的规范测试数据的使用，结果前一个功能测试时产 生的数据根本无法在下面的工作中被很好的利用起来，反而因为大量无效数据增加了后面功能的测试难度。最终不得不对每一个功能重新准备测试数据。大量的时 间，浪费在了这些重复而低效的劳动上？当然，如果希望可以进一步提高某个阶段测试工作的效率，还可以考虑应用“设计测试过程”的方法。这里所说的测试过 程，指的是我们在执行测试时所设定的执行测试用例的先后顺序。之所以这样作，是因为可以充分的利用不同功能之间的耦合性，尽量通过一次操作来检查尽量多的内容，从而降低已完成工作的无效性或低效性，最终提高某个阶段的整体工作效率。不过，这项工作同样要求操作者必须对被测的系统所涉及的所有业务以及这些业 务之间的关系都非常熟悉才行。如果您正被测试工作的低效问题所困扰，那么建议您尝试一下上面的方法，希望会对您的工作有所帮助。

测试生命周期

　　测试计划 → 测试设计 → 测试开发 → 测试执行 → 测试评估

　　测试计划就是定义一个测试项目的过程，以便能够正确的度量和控制测试。

第一部分：测试计划

测试计划的问题：

　　1、测试计划经常是等到开发周期后期才开始实行，使得没有时间有效的执行计划；

　　2、测试计划的组织者可能缺乏Client/Server测试经验；

　　3、测试的量度和复杂性可能太大，没有自动化工具，很难计划和控制。

测试策略：

　　测试策略描述测试工程的总体方法和目标。描述目前在进行哪一阶段的测试（单元测试、集成测试、系统测试）以及每个阶段内在进行的测试种类（功能测试、性能测试、压力测试等）。

　　测试策略包括

　　1、要使用的测试技术和工具；

　　2、测试完成标准；

　　3、影响资源分配的特殊考虑例如测试与外部接口或者模拟物理损坏、安全性威胁。

　　测试计划最关键的一步就是将软件分解成单元，写成测试需求。

　　测试需求有很多分类方法，最普通的一种就是按照商业功能分类。把软件分解成单元元件有几个好处：

　　1、测试需求是测试设计和开发测试用例的基础，分成单元可以更好地进行设计；

　　2、详细的测试需求是用来衡量测试覆盖率的重要指标；

　　3、测试需求包括各种测试实际和开发以及所需资源。

怎样估计测试工作量：

　　1、效率假设：即测试队伍的工作效率。对于功能测试，这主要依赖于应用的复杂度，窗口的个数，每个窗口中的动作数目。对容量测试，主要依赖于建立测试所需数据的工作量大小。

　　2、测试假设：为了验证一个测试需求所需测试动作数目。

　　3、应用的维数：应用的复杂度指标。例如要加入一个记录，测试需求的维数就是这个记录中域的数目。

　　4、所处测试周期的阶段：有些阶段主要工作都在设计，有些阶段主要是测试执行。

测试资源：

　　1、人力资源

　　测试项目经理

　　为测试项目提供总体方向。开发测试计划、征集并监督测试人员、申请系统资源、监视并汇报工作进程、测试评估、测试需求的分解。

　　测试工程师 —- 设计和开发

　　设计：对被测软件的详细了解、分解测试需求的技能、选择在C/S环境下用来验证测试需求的技术。

　　开发：熟悉SQA、VB、和脚本语言。

　　测试工程师 —- 执行

　　负责测试执行和记录结果。需要能够安装系统，网络知识，初始化数据库和其他初始条件。重要的是诊断能力。

　　测试系统管理者

　　每个测试项目必须指定一个专人负责管理SQA Suite。包括在服务器上安装存储库，安装打印机连接，执行备份，以及其他维护工作。管理者必须高度熟悉SQA，网络工作经验。

　　2、系统资源

　　安装SQA Suite的硬件和软件环境

　　数据库服务器

　　该服务器必须专用于 测试工作，能够重置某些初始值，包括系统日期和时间等。

写测试计划的步骤：

　　1、确定工程

　　收集下列信息

　　定义新的工程，Adminà New Project。

　　确定软件的结构，用Assetsà Software Structure选项定义软件结构。

　　2、定义测试策略

　　3、分解软件，写测试需求

　　分析各种信息

　　反复检查并理解各种信息，和用户交流，理解他们的要求。可以按照以下步骤执行：

　　1、确定软件提供的主要商业任务

　　2、对每个商业任务，确定完成该任务所要进行的交易。

　　3、确定从数据库信息引出的计算结果。

　　4、对于对时间有要求的交易，确定所要的时间和条件。这些条件包括数据库大小、机器配置、交易量、以及网络拥挤情况。

　　5、确定会产生重大意外的压力测试，包括：内存、硬盘空间、高的交易率

　　6、确定应用需要处理的数据量。

　　7、确定需要的软件和硬件配置。通常情况下，不可能对所有可能的配置都测试到，因此要选择最有可能产生问题的情况进行测试，包括：最低性能的硬件、几个有兼容性问题的软件并存、客户端机器通过最慢的LAN/WANF连接访问服务器。

　　8、确定其他与应用软件没有直接关系的商业交易。包括：

　　　　管理功能，如启动和推出程序
　　　　配置功能，如设置打印机
　　　　操作员的爱好，如字体、颜色
　　　　应用功能，如访问email或者显示时间和日期。

　　9、确定安装过程，包括定置从哪安装、定制安装、升级安装。

　　10、确定没有隐含在功能测试中的户界面要求。大多界面都在功能测试时被测试到。还有写没有测到，如：操作与显示的一致性，如使用快捷键等；界面遵从合理标准，如按钮大小，标签等。

　　把需求组织成层次图

　　4、估计测试工作量

　　∑(每个测试的时间*每个需求的测试的数目*测试需求的的数目)
　　（测试设计、开发、….）

　　5、确定资源

　　人力资源

　　系统资源

　　6、创建工程调度表

　　7、书写测试计划

　　1、介绍

　　　　目的
　　　　背景
　　　　测试范围
　　　　项目文件列表

　　2、测试需求

　　3、测试策略

　　　　测试类型

　　　　1、功能测试
　　　　2、用户界面测试
　　　　3、性能测试
　　　　4、压力测试
　　　　5、容量测试
　　　　6、配置测试
　　　　7、安装测试

　　　　工具

　　4、资源

　　　　人力资源
　　　　系统资源

　　5、调度

　　6、文档

　　　　软件元件
　　　　测试特性（Assets）
　　　　测试日记
　　　　缺陷报告

第二部分：测试设计

测试设计的问题

　　1、不做测试设计，测试过程也是胡乱建立的。

　　2、测试设计不详细，不是基于可量度的测试策略，例如测试计划覆盖一个集合或者测试需求的一个子集。

　　3、测试过程没有采用最好的技术来检验Windows C/S结构的测试需求

测试用例的选择规则

　　1、选择与测试需求的实质部分最相关的测试用例。

　　2、选择的测试用例应该不容易应用程序的改变的影响。

　　下面是选择测试用例的几点具体规则：

　　1、商业函数

　　商业函数一般与数据库有关，要测试数据库的变化，有几种方法：
　　1、如果数据库的的改变会反映在一个列表框中，那么就要选择验证列表框内容的测试用例。
　　2、还可以检查交易完成后的确认对话框。可以检查对话框的标题。图象比较也可以检查确认对话框，但图象比较容易受其他因素影响。
　　3、修改脚本，SQA Basic提供了强大的数据库支持。

　　2、域的验证

　　各种不同的域选择相应的测试用例。

　　3、用户界面测试

　　对象状态测试用例

　　4、性能标准

　　等待状态测试用例

　　5、压力下的操作

　　6、访问控制

　　Object state test case

　　7、配置测试

　　不能选择图象测试用例（也分辨率有关）和文件测试用例（与驱动器有关）

　　8、安装选项和验证

　　对象状态用例和窗口存在用例，文件存在用例。

书写测试设计的步骤

　　　　生成测试需求报告
　　　　　　　↓
　　　　　指定测试过程
　　　　　　　↓
　　　指定测试用例（可选）
　　　　　　　↓
　　　　回顾测试覆盖率

第三部分：测试开发

输入：被测软件、基于测试需求的测试设计

输出：测试过程和测试用例

目标：

　　1、创建可以重用的测试过程和测试用例
　　2、维护测试过程、测试用例与相关测试需求的一一对应。

测试开发的问题：

　　1、测试开发很乱，与测试需求或测试策略没有对应性
　　2、测试过程不可重复或不可重用
　　3、测试过程被作为一个编程任务来执行，导致脚本太长，不能满足软件移植性的要求。

错误处理

　　当测试过程发生错误时，有几种解决办法：

　　1、跳转到别的测试过程
　　2、调用一个能够清除错误的过程
　　3、退出过程，启动另一个
　　4、退出过程和应用程序，重新启动启动Windows，在失败的地方重新开始测试

测试开发的步骤

　　1、设立开发环境

　　　　SQA Suite
　　　　连接到SQA存储库
　　　　启动SQA Baisc或VB
　　　　被测软件
　　　　等等

　　2、录制和回放原型过程

　　原型过程指出所有未知窗口控制，使得他们都能象标准窗口那样动作或者没有特别的动作，把他们都划归为Generic类型。通过这个过程，SQA Robot就知道该怎样处理应用中的特殊控制。

　　1、把recording option 中的Define Unknown Object as Type Generic选项设置为off
　　2、使用的过程标识符要可以被覆盖，或者能被删掉。因为这只是个原型，用来教SQA Robot 录制的过程

　　3、录制测试过程和测试用例

　　1、录制模块测试过程和与测试需求最低层对应的测试用例；
　　2、录制初始化过程；
　　3、录制导航过程，把前面的过程串起来；

　　4、测试和调试测试过程

　　5、修改测试过程（可选）

　　6、建立外部数据集合

　　如果测试过程是用来循环一套输入和输出数据，就需要建立数据集合。

　　7、重复测试和调试测试过程，回到4

第四部分：测试执行

测试执行的问题

　　1、自动化测试没有有效的利用，使得手工测试太多。
　　2、测试结果的捕获没有系统性，而且没有查看或调查
　　3、缺陷报告必须用手工加入缺陷跟踪系统

错误分类

　　1、测试用例失败

　　　　正常错误

　　2、脚本命令失败

　　　　当测试过程不能不能执行录制过程中的某个功能时，回产生这种错误，如鼠标单击按钮或选择菜单项等。它也能指示是缺陷还是测试过程的设计问题。

　　3、致命错误

　　　　导致测试停止，这种情况最好重起Windows。

具体步骤：

　　1、建立测试系统
　　2、准备测试过程
　　3、运行初始化过程
　　4、执行测试
　　5、从终止的测试恢复
　　6、验证预期结果
　　7、调查突发结果
　　8、记录缺陷日记

第五部分：测试评估

测试评估的目标

　　1、量化测试进程
　　2、生成缺陷和测试覆盖率的总结报告

测试评估的问题

　　1、没有把测试覆盖率作为报告测试进程的根据，使得不知测试是否结束；
　　2、没有做缺陷评估，缺陷评估是量度软件可行性的重要指标；
　　3、不使用专门的软件工具进行数据输入任务和相应的评估活动，使得这些任务变得繁重累人。

测试覆盖率

　　评估测试完成多少的标准

缺陷评估

　　评估软件质量的重要指标，通常评估模型假设缺陷的发现是呈泊松分布的；严格的缺陷评估要考察在测试过程中发现缺陷的间隔时间长短。评估要估计软件当前的可靠性并预测随着测试的继续进行，软件可靠性会怎样提高。

　　SQA Suite 提供四种形式进行缺陷评估：

　　1、缺陷分布报告可以生成缺陷数量与缺陷属性的函数。如测试需求和状态。
　　2、缺陷趋势报告可以看出缺陷增长和减少的趋势；
　　3、缺陷年龄报告展示一个缺陷处于某种状态的时间长短
　　4、测试结果进度报告展示测试过程在被测应用的几个版本中的执行结果以及测试周期。

具体步骤

　　1、回顾测试日记

　　2、评估测试需求的覆盖率

　　3、分析缺陷

　　4、决定是否达到完成测试的标准，没有满足标准时

　　　　1、再测试
　　　　2、降低标准
　　　　3、确定软件的一个满足标准的子集，看是否可以发布。

　　本文介绍了基于B/S模式的软件缺陷跟踪管理系统的设计与实现。软件缺陷是在软件生命周期中不可避免的对象。缺陷跟踪管理是软件管理的重要组成。现有管理方法是将进入到系统中的问题,都认为是软件缺陷进行处理。但是实际情况却可能有虚假或重复的缺陷报告。不及时处理这些问题,它本身又可能形成新的缺陷。从软件系统考虑,应将软件缺陷跟踪管理纳入到项目管理信息系统之中,成为项目管理信息系统的一个子系统。对维护人员提交的缺陷报告认真鉴定、筛选、分类,进入不同的处理流程,以获得真正的缺陷跟踪数据。本文在分析讨论这些问题的基础上,提出新的软件缺 陷跟踪管理系统的总体结构。

　　软件缺陷跟踪管理系统在现代软件开发中已经占据了很重要的位置。每一个软件组织都知道必须妥善处理软件中的缺陷。这是关系到软件组织生存、发展的质量根本。可遗憾的是，并非所有的软件组织都知道如何有效地管理自己软件中的缺陷。CMM及CMMI都对软件缺陷跟踪给予了关注并做出了相关规定。本文的侧重点放在了讨论这个程序的需求分析、设计、实现及所用到的项目管理知识。借着实现这个简单的缺陷跟踪系统，探讨了个人软件开发过程当中遇到的各种问题，以及解决它们的方法，展示了个人软件开发的一般过程。

　　缺陷跟踪管理是测试工作的一个重要部分，测试的目的是为了尽早发现软件系统中的缺陷，因此，对缺陷进行跟踪管理，确保每个被发现的缺陷都能够及时得到处理是测试工作的一项重要内容。

　　1、 缺陷跟踪管理的目标

　　缺陷能够引起软件运行时产生的一种不希望或不可接受的外部行为结果，软件测试过程简单说就是围绕缺陷进行的，对缺陷的跟踪管理一般而言需要达到以下的目标：

　　确保每个被发现的缺陷都能够被解决；这里解决的意思不一定是被修正，也可能是其他处理方式（例如，在下一个版本中修正或是不修正），总之，对每个被发现的BUG的处理方式必须能够在开发组织中达到一致；

　　收集缺陷数据并根据缺陷趋势曲线识别测试过程的阶段；决定测试过程是否结束有很多种方式，通过缺陷趋势曲线来确定测试过程是否结束是常用并且较为有效的一种方式。

　　收集缺陷数据并在其上进行数据分析，作为组织的过程财富。

　　上述的第一条是最受到重视的一点，在谈到缺陷跟踪管理时，一般人都会马上想到这一条，然而对第二和第三条目标却很容易忽视。其实，在一个运行良好的组织中，缺陷数据的收集和分析是很重要的，从缺陷数据中可以得到很多与软件质量相关的数据。

　　2、 缺陷的描述

　　对缺陷的描述应该包含以下的内容： 可追踪信息

　　缺陷ID：唯一的缺陷ID，可以根据该ID追踪缺陷

　　缺陷基本信息

　　缺陷状态：缺陷的状态，分为“待分配”、“待修正”、“待验证”、“待评审”、“关闭”

　　缺陷标题：描述缺陷的标题

　　缺陷的严重程度：描述缺陷的严重程度，一般分为“致命”、“严重”、“一般”、“建议”四种

　　缺陷的紧急程度：描述缺陷的紧急程度，从1－4，1是优先级最高的等级，4是优先级最低的等级

　　缺陷提交人：缺陷提交人的名字（邮件地址）

　　缺陷提交时间：缺陷提交的时间

　　缺陷所属项目/模块：缺陷所属的项目和模块，最好能较精确的定位至模块

　　缺陷指定解决人：缺陷指定的解决人，在缺陷“提交”状态为空，在缺陷“分发”状态下由项目经理指定相关开发人员修改

　　缺陷指定解决时间：项目经理指定的开发人员修改此缺陷的deadline

　　缺陷处理人：最终处理缺陷的处理人

　　缺陷处理结果描述：对处理结果的描述，如果对代码进行了修改，要求在此处体现出修改

　　缺陷处理时间：缺陷处理的时间

　　缺陷验证人：对被处理缺陷验证的验证人

　　缺陷验证结果描述：对验证结果的描述（通过、不通过）

　　缺陷验证时间：对缺陷验证的时间

　　缺陷的详细描述：对缺陷的详细描述；之所以把这项单独列出来，是因为对缺陷描述的详细程度直接影响开发人员对缺陷的修改，描述应该尽可能详细

　　测试环境说明：对测试环境的描述

　　必要的附件：对于某些文字很难表达清楚的缺陷，使用图片等附件是必要的

　　除上述描述项外，从统计的角度出发，还可以添加上“缺陷引入阶段”、“缺陷修正工作量”等项目。

　　3、 缺陷管理的一般流程

　　缺陷管理的流程比较简单，图1是一个缺陷状态图。

　　流程中的角色：

　　1、 测试人员：进行测试的人员，缺陷的发起者；

　　2、 项目经理：对整个项目负责，对产品质量负责的人员；

　　3、 开发人员：执行开发任务的人员，完成实际的设计和编码工作；

　　4、 评审委员会：对缺陷进行最终确认，在项目成员对缺陷达不成一致意见时，行使仲裁权力。

　　缺陷的状态

　　1、 初始化：缺陷的初始状态；

　　2、 待分配：缺陷等待分配给相关开发人员处理；

　　3、 待修正：缺陷等待开发人员修正；

　　4、 待验证：开发人员已完成修正，等待测试人员验证；

　　5、 待评审：开发人员拒绝修改缺陷，需要评审委员会评审；

　　6、 关闭：缺陷已被处理完成。

　　4、 缺陷数据统计

　　如前所述，缺陷数据统计也是缺陷跟踪管理系统的目标。一般而言，生成的缺陷数据统计图表包括缺陷趋势图、缺陷分布图、缺陷及时处理情况统计表等。

　　5、 缺陷跟踪管理系统

　　目前已有的缺陷跟踪管理软件包括Compuware公司的TrackRecord软件（商业软 件）、Mozilla公司的Bugzilla软件（免费软件），以及国内的微创公司的BMS软件，这些软件在功能上各有特点，可以根据实际情况选用。当然， 也可以自己开发缺陷跟踪软件，例如基于Notes或是ClearQuese开发缺陷跟踪管理软件。我公司采用的是自己开发的基于Notes的缺陷跟踪系统，除了具有上述功能外，还能够通过Notes的邮件系统方便地向相关人员发送提醒信息（缺陷处理超时提醒、缺陷待处理提醒等）。

　　除此之外，作为一个缺陷跟踪管理系统，还必须注意权限分配的问题。缺陷记录作为软件开发过程中的 重要数据，不能轻易被删除；对于已经关闭的缺陷，也不能随意进行修改。因此，缺陷跟踪管理系统必须设置严格的管理权限，非相关人员不得进行相应操作，修改相应数据。在这一点上，通过Notes也很容易控制。