测试培训资料

软件测试培训资料 1 前言： 软件测试是一种特殊的软件系统的设计和实现，即执行另一个以发现错误（或缺陷）为目标的软件系统。测试就是 分析 定性数据统计分析pdf销售业绩分析模板建筑结构震害分析销售进度分析表京东商城竞争战略分析 被测系统，判定怎样可能是错误的，同时，测试设计也是为测试的自动化提供了需求。 软件测试的核心工作就是通过规范性的测试手段按软件可能遇到的应用场合全面充分地对软件进行测试，软件测试能够充分地发现软件中的缺陷和问题，确定软件当前的技术状态，提高软件的质量，使软件项目和软件产品满足用户需求。 软件测试作为软件开发的重要一环，它的作业应该和软件开发的其它过程并行进行。这是因为： · 现在的c/s或b/s 系统都是图形用户界面，是通过事件驱动而实现的操作，即软件系统针对发生的事件执行相应的代码，如果测试时因系统庞大复杂，测试准备工作做的不充分，测试人员难以组织科学全面的测试用例，从而使测试成本大大提高，并严重影响测试的全面性和有效性； · c/s或b/s 结构系统的应用程序的用户图形界面中导航是灵活的，而有的系统因设计不足或不重视使得导航极其复杂，操作流程曲折，且几乎每个软件项目在测试阶段还没有操作说明书，使得测试过程难以顺利进行； · 由于受到项目进度的限制，测试时间紧迫，测试工作往往不彻底，因而将大量的缺陷留给了最终用户，这样影响公司的形象和利益。 所以，测试 计划 项目进度计划表范例计划下载计划下载计划下载课程教学计划下载 应该早在需求分析时就开始制定，其它相关工作，如测试大纲的编制、测试数据的生成、测试工具的选择和开发也应当在测试阶段前进行。充分的准备可以有效地克服测试的盲目性，缩短测试周期，提高测试效率，并且对开发中可能遇到的问题有启示的作用。 测试的准备工作主要是对用户需求的理解、消化、归纳和总结，积累同类或同行业的需求经验，并参照经验，根据预期的结果，设计测试用例，积累测试数据，对被测软件进行量化评估。 2 测试能完成什么 软件测试的首要任务是发现错误。发现错误也许要花很大代价的，或者不可能用其它的验证和确认技术去发现错误。第二个目的是对于给定的测试集，说明被测系统是符合规约所描述的需求。 测试不是用好的软件 工程 路基工程安全技术交底工程项目施工成本控制工程量增项单年度零星工程技术标正投影法基本原理 方法来防止故障的替代品。相反，它应当关注测试的有效性的范围是什么，并且能用已知最好的软件工程实践加以补充和完善。它不是为了防止或辨认所有类型的错误而选择的技术。例如，测试难以辨认遗漏的需求，但它能发现可能引起系统崩溃的交互动作和特殊情况。试图“测试一个系统的质量”是没有意义的。测试不应该是防止错误的第一步，也不应该是作为最后的有害废物的过滤器。 测试活动与软件过程协调一致的好与坏，都对测试的有效性有很重要的影响。如果测试的开发是在一个项目时进行的，那么测试是非常有效的。及早的考虑可测试性，及早进行测试设计，和尽可能早的实现测试，提供了有力的预防错误的方法。由于这些过程迫使我们更仔细的考虑需求和规约的实现，其结果可能改进应用设计。 总之，从软件产品的角度考虑，有效的测试对于生产可靠的、安全的和成功的系统是必须的。 下图列出了对什么样的错误类型，应在那些阶段进行测试和检验。 错误类型 产生的原因 测试和修改的合适阶段 需求确认 单元测试 测试阶段 系统的可用性 不良的用户接口设计 √ 遗漏的功能 引发错误 √ 规范遗漏 √ √ 功能错误等 引发错误 √ √ 规范遗漏 √ √ √ 副作用和无法预测的不得当的交互特征 引发错误 √ √ 规范遗漏 √ √ 编程错误 √ √ 配置 / 集成错误 √ 性能不完整、实时控制失败、同步死锁、解锁等 引发错误 √ √ 规范遗漏 √ √ √ 不合适的目标 √ √ √ 无效的算法 √ √ √ 无效的编程 √ √ 不可行问题 √ √ 编程错误 √ √ 配置 / 集成错误 √ 不正确的错误 规范遗漏 √ √ 编程错误 √ √ 配置 / 集成错误 √ √ 异常终止 编程错误 √ √ 配置 / 集成错误 √ 其中：√表示有用，阴影部分表示典型的非常有效 3 软件测试的基本内容 3.1 安装与测试环境 测试环境要求：根据被测系统的需求选用专用的测试环境，或结合具体系统情况搭建测试环境，使其尽量逼近真实的系统运行环境。 3.2 单元测试：（采用白盒测试方法）单元测试的主要内容是： 系统代码走查 界面、输出报表检查 功能测试 容错测试 测试过程中静态测试的分类 静态测试可以分为代码审查、代码走查和静态分析： 1、代码审查的测试内容包括：检查代码和设计的一致性；检查代码对标准的遵循、可读性；检查代码的逻辑表达的正确性；检查代码结构的合理性。代码审查以代码审查组的方式，使用读程序和利用代码审查单的方法进行 2、代码走查是由被指定作为测试员的小组成员提供若干测试实例（程序的输入数据和期望的输出结果），让参加会议的成员充当计算机，在会议上对每个测试实例用头脑来执行程序，也就是用测试实例沿程序逻辑走一遍，并由 测试人员讲述程序执行过程，在纸上或黑板上监视程序状态（变量的值） 3、静态分析一般需使用软件工具进行。通常包括控制流分析、数据流分析、接口分析、表达式分析。如logiscope,testbed都是比较好用的静态分析工具。 3.2.1 代码检查 · 程序单位的首部应有代码说明和修改备注，内容包括编写或更改代码的人员、时间、程序的功能及调用关系等； · 变量、过程、函数等应符合软件项目组规定的统一命名规则； · 代码中不同的功能部分应有清楚的注释，较复杂的代码段落也应有注释，一般的要求是代码注释的量是代码的1/3； · 如果是修改，在修改的代码处应有修改注释，注释说明修改的人员、时间及内容。 3.2.2 界面及输出报 表格 关于规范使用各类表格的通知入职表格免费下载关于主播时间做一个表格详细英语字母大小写表格下载简历表格模板下载 式检查 · 用户界面、输出报表的格式以及代码的命名应符合统一的规则； · 用户界面、输出报表的字段位置、长度、类型应与设计文档的要求一致。界面、报表的风格一致、协调。 3.2.3 功能测试 · 如果有多个界面，多个界面之间切换正确； · 每一个界面的功能键、触发键、按钮、菜单、选择项功能正确； · 检查数据项的关联与限制功能是否正确； · 找出设计文档中要求的未被包含在上述几项测试中的功能，逐项测试，检查是否达到设计文档要求的功能。 3.2.4 功能测试的正确性判断 · 有增、删、改、刷新等功能的系统，增、删、改、刷新等操作的结果正确，测试时应手工打开数据库表，以检查写/删除的效果； · 有查询或报表操作时，检查在各种选择项的合理组合下，所产生的结果，对照数据库中的数据是否正确；对不符合条件的，应有相应的提示及相应的保护措施。 · 对照设计文档的要求，测试系统所有的功能是否正确。 3.2.5 容错测试 · 非法键容错测试： 在不同的界面，不同的字段处输入非法键或其它空白处任意点击，被测试系统应有非法键容错能力； · 异常数据容错测试： 在不同的界面，不同的字段输入异常数据（如：数据类型不同、非法日期等），被测试系统应有异常数据容错能力；（如：相应信息提示等） · 系统负作用检查： 退出被测试系统后应恢复到进入前的系统状态，不应影响其它系统的正确运行； · 残留文件检查： 退出系统后在本地机和服务器的有关目录或TEMP目录下不应留下任何无用的文件。否则，影响系统运行的性能。 3.3 集成测试： （采用黑盒测试方法）其主要测试内容 流程测试 SQL测试 3.3.1 流程测试（也叫接口测试，包括模块之间、子系统之间、小组之间等） 根据系统的需求说明书：以实体（即具体业务处理）为对象，主要按业务的需求测试其输入、处理、输出是否满足需求，验证每个业务既符合实际工作的需要，又验证业务的处理过程是正确的，输出的结果是正确的，这里测试的内容比较多，测试大纲的内容主要体现的是该阶段的内容，测试用例主要用在该阶段。 3.3.2 SQL测试 每一个c/s系统都使用SQL来访问数据库，其中有利也有弊，SQL语句使用户用很少的几条简单语句访问和操纵大量数据。一个单独的查询语句可以选择、揉和、编组、和总结一个数据库中上百万行的数据。它使开发者可以快速和相对容易地开发，把数据返回并显示在窗口和报表中的语句。一个语句也可以修改一个、大量或一个数据表中全部的数据行。如果定义了触发器或依赖关系，一个更新语句有可能影响数据库中许多其他表。这是它的优势。 但是、所有这些潜在力量可能会付出不被理解或确认的代价。使用SQL语言访问关系数据库时有产生大型错误的可能性。写的不好或未被很好测试的语句很可能使一个查询产生错误的结果。没有被充分测试的SQL语句也可能对系统的性能产生巨大的负面影响。一个写的不好的SQL语句可能在效率上低很多很多。 3.4 确认测试：其主要测试内容是 系统性的功能测试 性能测试 多用户测试 负载测试 配置测试 安装测试 安全性测试 长时间测试 容量测试 恢复测试 2.4.1 功能测试 再次抽查性的验证被测系统的各个功能点是否正确，流程是否正确 2.4.2 性能测试 包括以下几点： · 界面操作效率测试：逐项测试每一项操作，特别是增、删、改、刷新等功能、翻页、滚屏等操作，测试每项操作的响应时间是否符合设计要求或用户要求； · 报表输出及查询效率测试：分别选择最小范围（非空）的数据及最大范围（根据实际情况定）的数据，测试产生结果的响应时间是否符合设计要求或用户要求； · 数据库压力测试；当被测数据库具有几万、几十万条数据时，分别操作增、删、改、刷新、翻页等功能，测试每项操作的响应时间是否符合设计要求或用户要求； · 评价系统效率是否合理。 2.4.3 并发测试 · 随机并发测试：在两个或以上的客户端同时多次进入和退出被测试系统，测试系统是否正确无误； · 共享并发测试：在两个或以上的客户端同时调用被测试系统做同样的工作，测试系统是否正确无误； · 同步并发测试：就系统中使用到的同步机构，有针对性地组织数据进行测试，如：有关同步的命令包括对数据库表、文件的共享，互斥操作，文件系统或记录的加锁、解锁，对公共数据区域的操作等。 如： 以下均用同一用户名USER：AAAAAA，PASSWORD：aaaaaa登录进行测试。 1．同时登录到同一邮箱； 2．同时给用户AAAAAA发一个邮件，邮件各不相同； 3．同时添加地址，地址各不相同； 4．同时添加签名，签名各不相同； 5．同时添加过滤规则，过滤规则各不相同； 6．同时定时发信，所定时间不同； 7．同时添加POP3服务器，服务器名相同； 8．同时更改密码，密码不同； 2.4.4 多用户测试 就是大批量用户对被测系统进行使用。 如： 1．以不同用户名登录，每人向用户AAAAAA发送20封邮件（越多越好，可以随变拷一编文章发出去）； 2．每人在AAAAAA信箱中添加20 个地址； 3．每人在AAAAAA信箱中添加20 个过滤规则； 4．每人在AAAAAA信箱中添加20 个签名； 2.4.6 兼容测试 本测试的目的主要是验证被测系统在各种运行环境中将原来系统的数据移植过来后，是否能照常运行，又叫跨平台测试。 2.4.7 安装测试 本测试主要检测系统的可移植性和可用性。在系统产品化后，将产品移植到另外的机器上，检查是否能正常运行。 2.4.8 恢复测试 本测试主要目的是检查系统的可恢复性。在系统运行过程中，突然断电。然后重新启动，查看系统是否能正常运行。 测试结果：断电对系统的性能并不产生影响，但是由于在往服务器写东西的时候断电，对硬盘影响较大，硬盘需恢复后系统才能运行。 2.4.9 安全性测试 本测试主要包括系统级和应用级的安全性测试，应用级的测试主要是被测系统的安全登陆测试。系统级测试的主要内容是各种licenses的测试，其中包含防止黑客攻击的测试，这种测试的手段是用一个黑客软件来攻击系统，检查系统是否能防范于未然。 如： 黑客对邮件系统一般有三种攻击方式： 1． TCP/IP网络进行攻击。这些攻击包括序列号欺骗，路由攻击，源地址欺骗和授权欺骗。 2． 在服务器预置Internet trojan horse，来获取管理员帐号。 3． 通过EMAIL炸弹来攻击邮件系统。 对第一种情况，可以用IGMP(一个指定IP的攻击工具),SSS(一个相当优秀的服务器漏洞扫描工具)进行测试。 对第二种情况，可以使用了BO V120进行测试。 对第三种情况，可以使用Anonymai ，KaBomb!3（两个较成熟的EMAIL炸弹），攻击成功。这种情况下的攻击只会对用户的邮件产生不良影响，对系统无影响，而且这种主动性攻击目前尚无一个十分周全的解决办法。 4 软件的测试方法 4 .1 设计测试用例 4 .1.1 设计测试用例的原则 · 测试用例的代表性：能够代表各种合理和不合理的、合法的和非法的、边界和越界的,以及极限的输入数据、操作和环境设置等； · 测试结果的可判定性：即测试执行结果的正确性是可判定的或可评估的； · 测试结果的可再现性：即对同样的测试用例，系统的执行结果应当是相同的。 4.1.2 测试用例的组成 测试用例应该由以下两部分组成 1） 输入数据 2） 处理（如计算、合并等） 3） 预期的输出结果 这就是说，在执行系统之前应该对期望的输出有很明确的描述，这样，测试后就可将系统的输出同它仔细对照检查。否则，如果不是先确定输出，就可能把似乎是正确而实际是错误的结果当成是正确的结果。 4.1.3 设计测试用例应注意的事项 · 不仅要选用合理的输入数据作为测试用例（即肯定测试用例），还应选用不合理的输入数据作为测试用例（即否定测试用例）。许多人往往只注意前者而忽略了后者。为了提高系统的健壮性，输入数据不合理的各种情况是应该认真检查的（在开发过程中，正常业务处理的代码量只占有效代码量的10%，而例外处理的代码量要占有效代码量的90%），所以测试工作量也是如此，即肯定测试用例占总用例的10%，否定测试用例占总用例的90%）。 · 除了检查系统是否做了它应该做的工作之外，还应检查系统是否做了它不应该做的事情。 · 应该长期保留所有的测试用例，直至这个系统被废弃不用为止。这是因为：设计测试用例是很费人工的，如果将用过的测试用例丢弃了，以后一旦需要再测试这个系统（例如因为系统内部作了某些修改）就需要再花很多人工，人们往往懒得再次认真地设计测试用例，因而“再测试”很少像初次测试那样“彻底”。如果系统的修改使得前面已测试过的部分产生了错误，“再测试”往往就不能发现这些错误。 4.1.4 设计测试用例（测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。） 4.1.4.1 白盒法 白盒法是以系统内部的逻辑为基础设计测试用例，所以又称为逻辑覆盖法。白盒法考虑的是测试用例对系统内部的覆盖程度，最彻底的白盒法是覆盖系统中的每条路径，但是由于系统中一般含有循环，所以路径的数目极大，要执行每条路径是不可能的，所以只能希望覆盖的程度尽可能高些。我们可以从以下几点考虑： （1）语句覆盖 “语句覆盖”是一个很弱的测试覆盖，它的含义是：选择足够的测试用例，使代码中每个有效语句（即注释语句除外）至少都能被执行一次。顺序语句覆盖率是100% 。 （2）分支覆盖 比“语句覆盖”稍强的测试覆盖是“分支覆盖”。这个标准是执行足够的测试用例，使代码中每个分支至少都获得一次“真”值和“假”值，或者说使得代码中的每个分支至少都通过一次。分支覆盖率是80% 。 （3）循环覆盖 “循环覆盖”的含义是：执行足够的测试用例，使得循环中的每个条件都得到验证。循环语句覆盖率是80% 。 4.1.4.2 黑盒法 设计测试用例的另一种方法是黑盒法。与白盒法不同，黑盒法不关心系统内部的逻辑，而只是根据系统的功能说明、预期结果、数据流程或业务流程等来设计测试用例。黑盒法测试的依据是需求说明书或功能说明书。我们常常采用的方法是： A、划分等价类 这一步是：先从系统的需求规格说明中找出所有的输入条件，然后为每个输入条件划分两个或多个等价类，此时可以使用下表： 输入条件 合理等价类(合理输入数据) 不合理等价类(非法输入数据) · 划分等价类在很大程度上是试探性的，下面几点可供参考： ① 如果某个输入条件说明了输入的范围（如“数据值”是从1到999），则可划分一个合理等价类（大于等于1而小于等于999的数）和两个不合理等价类（小于1的数，以及大于999的数）。 ② 如果某个输入条件说明了输入数据的个数（如每个学生可以选修1至3门课程），则可划分一个合理等价类（选修1-3门课程）和两个不合理等价类（没选修课程，以及超过3门课程）。 ③ 如果一个输入条件说明了一个“必须成立”的情况（如 标识 采样口标识规范化 下载危险废物标识 下载医疗器械外包装标识图下载科目一标识图大全免费下载产品包装标识下载 符的第一个字符必须是字母），则可以划分一个合理等价类（第一字符是字母），和一个不合理等价类（第一字符不是字母）。 ④ 如果某个输入条件说明了输入数据的一组可能的值，而且认为系统是用不同的方式处理每一种值的（如职称的输入值可以是助教、讲师、副教授和教授4种），则可为每一种值划分一个合理等价类（如助教、讲师、副教授和教授4种），并划分一个不合理等价类（上述4钟职称之外的等价类）。 · 设计测试用例 . 设计测试用例，使它包括尽可能多的、尚未被包括的合理等价类；重复做这一步，直至这些测试用例包括所有的合理等价类。 . 设计测试用例，使它包括一个（而且仅仅一个）尚未被包括的不合理等价类；重复做这一步，直至测试用例已包括所有的不合理等价类。 必须注意的是，这一步应使每个例子仅包括一个不合理等价类。这样做的原因是：系统中的某些错误检测往往会抑制其它错误检测，例如某个系统的功能说明中指出：输入数据是书的“类型”（它可以是“精装”、“平装”和“线装”）和书的“数量”（其允许值是1-999），如果某个测试用例中，书的“类型”是“活页”，书的“数量”是0，他包括了两个不合理的条件（“类型”和“数量”都不合理），系统在发现“类型”不合理之后，可能不会再去检查“数量”是否合理，因此这一部分系统实际上并没有测试到。 这里采用等价类划分法具个例子： 1. 对一个输入1-100数字的输入提交功能设计测试用例 划分等价类：其测试用例为 a. 输入数字为空； b. 输入数字为0； c. 输入数字为-1； d. 输入数字为101； e. 输入数字为1-100中间的任何数； f. 输入数字为小数；7.输入为字母； g. 输入为控制字符。 2. 免费电子邮件系统： a) 新用户注册页面 数据项取值 USER NAME：长度为 3-19 ；以字母开头;非空 姓名：非空 密码：非空 确认密码：值和密码值相同 出生年份：年——四位数字；月——1-12；日——1-31； 其余项：不要求 等价类的划分 数据项 有效等价类 无效等价类 USER NAME （1）长 3-9 ；（2）以字母开头; (1)长度<3；（2）非字母开头（3）长度>19 名 （3）非空 （4）为空 码 （5）为空 认密码 （6）值和密码值不同 生年份 （6）月—1-12；（7）日—1-31 （4）非空 余项 （8）都填（9）都不填 （5）值和密码值相同 b).忘记密码部分 数据项取值 ： 登录用户名：已存在的用户名 用户的回答：和注册值相同 密码：>=5 确认密码：值和密码值相同 等价类的划分 数据项 有效等价类 无效等价类 登录用户名 1)已存在 (1)不存在 用户的回答 （2）和注册值相同 （2）和注册值不同 密码 （3）>=5 （3）<5 密码确认 (4)值和密码值相同 (4)和密码值不同 B、 边界值分析法 “边界情况”是指输入等价类或输出等价类边界上的情况。 边界值分析法与等价分类法的差别在于： ① 边界值分析法不是从一个等价类中任选一个例子作代表，而是选一个或几个例子，使得该等价类的边界情况成为测试的主要目标。 ② 边界值分析不仅注意输入条件，它还根据输出的情况（即按输出等价类）设计测试用例。 运用边界值分析法，需要有一定的创造性，以下几点供使用时参考： ① 如果某个输入条件说明了值范围，则可选择一些恰好取到边界的例子，另外，再编写一些代表非法输入数据的例子，它们的值恰好越过边界。 ② 如果一个输入条件指出了输入数据的个数，则为最小个数、最大个数、比最小个数少1、比最大个数多1、分别设计例子。 ③ 为每个输出条件使用上面第①点。 ④为每个输出条件使用上面第②点。 ⑤ 如果系统的输入和输出是有序集合（如顺序文件、线性表等），则应特别注意集合的第一个或最后一个元素。 C、因果图法 D、错误推测法 人们也可以通过经验或直觉推测系统中可能存在的各种错误，从而有真对性地编写检查这些错误的例子，这就是错误推测法。错误推测法没有确定的步骤，很大程度上是凭经验进行的。 4.1.5 确定和描述测试方法 测试方法是对如何实施测试的说明（陈述）。它应该说明或指出测试对象、测试时采取的主要操作以及如何核实结果等。说明应该为读者提供足够的信息以便他们能够理解测试的对象（尽管尚不了解测试深度），如应有以下四步陈述： · 对于每一个用例，确定并执行测试用例，包括有效和无效的输入数据。 · 对于每一个用例都将设计和开发测试流程，也就是说：测试具体过程的描述。 · 利用某一段时间来实施测试过程。 · 如：测试账号管理模块，通过模拟客户账号管理来实现，测试过程包括添加、修改和删除账号以及客户。 · 比如，登录系统模块，可以这样简单的做需求： 1，检查用户名 2，检查密码 至于更加详细的测试用例简略列举如下： 1，正确的操作 1，1 正确的系统可以接受的用户名 1，2 正确的系统可以接受的密码 2，不正确的操作 2，1 登录用户名的检查 2，1，1 检查非法字符 2，1，2 检查长度 2，1... 2，2 登录用户的密码检查 2，2，1 检查密码显示为星号 2，2，2 检查长度 4.1.6 确定测试标准 测试标准是关于测试的客观说明，它指明那些用于确定/识别测试完成时间的值和被测试应用程序质量。测试标准可能包括一系列说明或对其他文档（比如方法指南或测试标准等）的引用。测试标准应确定： · 测试对象（具体测试目标） · 评测方法 · 评估评测方法所采用的标准 测试标准示例： 对于每一高优先级用例： · 所有计划好的测试用例和测试过程已被执行。 · 所有确定的缺陷已被解决。 · 所有计划好的测试用例和测试过程已被重新执行并且没有发现新的缺陷。 在上例中，“对于每一高优先级用例”说明测试对象。“所有计划好的测试用例和测试过程已被执行”说明评测的方法。评估标准包含在最后两个陈述“所有确定的缺陷已被解决”和“所有计划好的测试用例和测试过程已被重新执行并且没有发现新的缺陷”之中。 4.1.7 确定测试的特殊事项说明 应列出所有关于测试或者依赖关系的特殊事项，如下所示： · 测试数据库将由操作资源恢复。 · 测试（性能）必须在办公结束后开始（不受日常的正常操作影响）并且在凌晨 5:00 以前结束。 5 软件测试的基本过程 一个规范化的软件测试过程必须包括下述基本的测试活动： · 拟订软件测试计划 · 编制软件测试大纲 · 设计和生成测试用例（系统和数据） · 测试全过程的管理：(如：组织测试小组、确定测试版本)。 · 实施测试 · 生成测试报告 · 整理测试文档：测试资料的收集，归档。 每一轮测试前应该修改测试大纲，测试用例和测试版本。最后形成一套测试文档。一个商品化的软件往往需要经过多轮测试周期才能通过。 6 测试文档 测试文档应该包括： · 测试计划 · 测试大纲 · 测试用例 · 测试报告 · 问题（bug）表 7 测试工具 一些受软件开发人员欢迎的软件测试工具为软件测试提供了强有力的支持。目前，我们已有美国Rational公司的著名套装软件TeamTest：TeamTest直接支持对客户/服务器应用软件的测试。它是一套测试工具包，其中包括了Loadtest、Testmanager、Testfactry、Robot等产品。它的一个重要特点是可以自动录制/回放系统的测试过程,从而实现了对测试进行"复查"的自动化。 由于测试是一个需要反复进行的过程,常常要数十次甚至数百次地重复。因此,这一特性大大地提高了软件"再测试"和"回归测试"的自动化程度,把测试人员从繁杂的、重复性的手工测试中解脱出来,从而显著地提高软件测试效率，其中。 · Robot具有自动录放功能，并提供了一系列的辅助支持功能，比如： 自动记录和分析比较测试的执行结果。不论是简单的正文方式的输出结果,还是任意的图表、声音、动画、图形用户界面(GUI)中的任一构件,都可以根据测试人员的指定被自动记录在测试结果库中,并可对两次测试的结果自动地进行比较,指出其差异部分。此项功能无疑对"自动查找错误"很有帮助。 调节和设定事件的发生时间和速度。 基本的测试库管理功能。 · Testmanager 支持软件测试人员进行以下工作: 制定测试计划和测试大纲,并将这些文档按照自然的树状结构分层地管理起来,并据此控制和驱动整个测试过程。 不仅能够自动记录各类测试结果,而且对其进行修改,从而使得测试人员可以在系统运行结果尚有许多错误的情况下,通过对所记录下的结果做适当修正来获得理想的"期望结果" ,为测试结果的自动比较奠定基础。 测试问题报告的记录与管理。 · Purify是专门用于检测系统中种种内存使用错误的软件工具。几乎所有使用过Purify可以自动识别出二十多种内存使用错误,包括 未初始化的局部变量 未申请的内存 使用已释放的内存 数组越界 内存丢失 文件描述问题 栈溢出问题 栈结构边界错误等 · loadtest主要支持多用户测试。 软件测试－《软件开发的科学和艺术》节选 撰文/陈宏刚 《软件开发的科学与艺术》是电子工业出版社联袂微软公司华人专家于近期推出的一本优秀之作。书中凝聚了微软司多位专家多年研究与工作的宝贵经验，并通过对许务成功或失败案例的中肯剖析，为读者展现了软件开发的思想与程，值得软件人员好好阅读和领悟! 一、微软的测试人员 微软的软件测试人员分为两类:测试工具软件开发工程师（Software Development Engineer in Test,简称SDE/T)和软件测试工程师(Software Test Engineer，简称STE)。 测试工具软件开发工程师:负责写测试工具代码，并利用测试工具对软件进行测试；或者开发测试工具为软件测试工程师服务。产品开发后的性能测试(Performance Test)、提交测试(Check-in Test)等过程，都有可能要用到SDE/T开发的测试工具。由于SDE/T和SDE的工作都是写代码，具有相通的地方，所以两者之间互相转换的情况比较多。但需 意的是，两者写出来的代码用途是不一样的，SDE写的是产品的代码，而SDE/T写的代码只用于测试产品。 软件测试工程师:负责理解产品的功能要求，然后对其进行测试，检查软件有没有错误(Bug)，决定软件是否具有稳定性(Robustness)，并写出相应的测试规范和测试案例。 除此之外，在一个软件产品的研发和销售过程中，还会需要负责给产品打补丁(Service Pack)的快速修正工程师比（Quick Fix Engineer)，通常曲SDE来担任，通过电话方式向用户提供售后技术支持的支持工程师(Support Engineer)，销售和市场(Sales and Marketing)人员，研究员和研究工程师(Researchers & Research SDE)。 在进行产品开发的时候，主要是由前面三类人员(项目经理、开发人员及测试人员)组成产品开发团队来进行的。 在微软内部，软件测试人员与软件开发人员的比率一般为1.5-2.5左右，这可能远远超出了大家对测试人员的理解，但微软软件开发的实践过程已经证明了这种人员结构的合理性。下图中显示了上述两个产品的微软软件开发人员的一般配置图。 下面以微软Exchange2O0O和Windows2000为例介绍一下微软产品团队的人员结构(这里只分析三类主要的人员，即项日经理、开发人员及测试人员)，如下表所示。 Exchange 2000 Windows 2000 项目经理 25人 约250人 开发人员 140人 约1700人 测试人员 350人 约3200人 测试人员/开发人员 2.5 1.9 二、测试时应考虑的几个问题 (1) 测试最重要的一件事就是要考虑到所有的出错可能性。同时，还要做一些不是按常规做的、非常奇怪的事。 说起来可能不太好听，测试的过程就像黑客(Hacker)的攻击过程那样。可以这么说，像黑客这样的人是最好的软件安全测试员。他们专门找软件的漏洞，从而破坏这个软件，这样就可以修复这些漏洞保证软件的性能。如果找不到这种漏洞，那就说明该软件质量己经很好了。 (2) 除了漏洞之外，测试还应该考虑性能(Performance)问题，也就是一定要保证软件运行得很好，非常快，没有内存泄漏，不会出现那种越来越慢的情况。 我们可以在不关机的情况下，与其他软件一起持续运行一个多月，看看是否会出现越来越慢的情况(当然必须保证其他软件是没有问题的)。我们在做IE的时候，就是让它72小时连续不停地打开不同的网页，处理几万个不同的网页，而且速度不能减慢。有许多软件，当只有一两个人用的时候，可能感觉不到什么问题，而当几百个用户一起用的时候，有的网站就出现各种各样的异常，这就是测试工作还比较欠缺的原故。 (3) 另外，测试还要考虑软件的兼容性(Compatibility)。 一般来说，一个软件是由许多小软件构成的，如果其中一个小软件与它的前一版本不兼容，那么这个软件就会出现错误。这种错误需要通过测试来发现和解决。 许多人认为写代码的人一定能找出错误来。其实开发人员在写代码的时候，如果有错误，他可以意识到了，可是写出来的错误，他不一定能想得到。我自己也编过程序，在编程序的时候很自信，觉得不会有错，可事实上，即使是我编的小程序也有错误，但要自己找出来，却要费很大劲。因为我一直认为自己不应该出错，但常常错误就出现在我认为最有把握的地方。我是学数学的，是一个很细心的人，可是--样还是会出错，但要找出自己的错误却要花费很长的时间。后来我写的代码让我的师弟帮我看，结果他很快就找到许多问题，可是我自己花一个月时间可能都找不到。所以，开发人员和测试人员完全不一样，开发人员确实可以找到一些Bug，但是有更多的Bug是他意识不到的。 在一般的开发团队中，并不需要测试人员定位Bug的具体位置，所以，对测试人员的要求并不高。只要你愿意学，测试工作是非常容易做的。但是，我当年所在的IE团队(IE 4.0)就不同，因为当时正在与另一个公司的产品竞争，所以微软就要求尽量找到一 流的开发人员和一流的测试人员，尽快开发出新产品，打败对手。所以，当时对我们测试人员的要求非常严格，不仅要找出Bug，而且要定位引起此Bug的代码行。然后将这些信息交给开发人员，后者就可以很快更正，省去了他们找错误出处的时间。因此，当时IE的开发速度非常快，一年之内就发布了一个新版本，而且几乎役有任何大Bug，大大超越了竞争对手。 二、关于Bug Bug的定义很广泛，在软件使用过程中所出现的任何一个可疑问题，或者导致软件不能符合设计要求或满足消费者需要的问题部是Bug，即使这个Bug在实践中是可行的。 有时候，Bug并不是程序错误。例如，软件没有按照一般用户的使用习惯来运行，此时也可以把这个问题看成是该软件的一个Bug。 通常，对Bug的跟踪过程如图所示。 首先，测试人员根据测试结果来报告他发现的所有Bug。通常，这项工作还需要用户的参与。微软在正式发布一个软件之前，经常要依次发布Alpha测试版、Beta测试版让用户试用，以便用户能够反馈出相关Bug的信息。但是，现在随着微软测试队伍的扩大及测试水平的提高，越来越多的 Bug都是我们内部的测试人员自己发现的，很少出现外部用户所反馈的Bug没有被测试人员发现的情况。 然后，开发经理根据这些Bug的危害性对它们进行排序，确定Bug的优先级，并安排给相关的开发工程师。 接着，开发人员根据Bug的轻重缓急依次修复各个Bug。 最后，测试人员再对开发人员已经修复的Bug进行验证，确认Bug是否已经被彻底更正。 微软开发一个产品经常会遇到几十万条Bug。随着测试人员越来越多，测试工作也越来越完善。但是，如何快速有效地追踪并修复Bug，仍然是摆在软件测试人员面前的一个主要困难。测试产品和追踪Bug时最重要的是问题的定义，要清楚需要解决什么样问题，确定Bug的主次关系，挑选出最主要的问题，并先解决它们。例如，有些Bug可能会导致死机或程序崩溃，这时就要先修复它们，而另一些Bug可能对软件的运行影响不大，或者出现的机会很少，就可以考虑以后再修复。 可以说，没有任何一个产品没有Bug，也永远不可能找井修复所有的Bug。在修复了旧的Bug的同时，往往又会生新的Bug。 这个过程就类似于数学中的“极限”的定义，尽管我们知道某个极限值为0，但是它永远也不可能达到0。这也就产品的Bug永远也修复不完的原因。因此，我们在修复 Bug时要注意，一定要记住用户最需要的是什么，然后优先尽力修复那些影响用户使用的Bug;而对于大部分对用户影很少、甚至根本不影响的Bug，则可以推迟修复，甚至不修复。 在查找并修复Bug的过程中，测试人员和开发人员经常会发生争执。例如，当开发人员宣布某一个Bug已经被Fixed时，测试人员往往还不放心，又重新对该Bug进行检查;当开发人员宣布某一个Bug是Duplicated时，细心的测试人员也要验证该Bug是否和另外一个Bug相重复，如果另外一个 Bug己经被修复了，但这个Bug还存在，就会让开发人员重新修复该Bug;对于是否需要Postponed一个Bug，测试人员和开发人员也常常争论不休，测试人员认为这个Bug需要修复，而开发人员则认为修复这个Bug不值得，这时候就需要项目经理来决定，因为测试人员要从用户的角度来看待 Bug，开发人员则要考虑到开发期限和付出的代价，而项目经理要同时考虑到这两种情况。 只有项目经理经过权衡之后才能确定是否要推迟修复该 Bug；在By design情况下，通常是争论最多的时候。这时候也需要三方都坐下来谈，其结果一般有三种:坚持原来的设计、修改原来的设计并增加特性、或者取消该设计。对Not repro和Won't fix情况也是这样，需要测试人员、开发人员和项目经理进行协商，直到三方达成共识。 四、软件测试方法和辅助工具 有了Bug类型的定义以后，如何去找出这些Bug呢？这就需要采用好的测试方法。以下介绍几种常用的钦件测试方法。 有多种方式对软件测试方法进行分类。例如，从代码和用户使用的角度可以将软件测试方法分为如下几种。 (1) 覆盖性测试 (Coverage Testing) 覆盖性测试是从代码的特性角度(即内部)出发的测试方法，包括以下方式。 ① 单元测试 (Unit Test): 按照代码的单元组成逐个进行测试。 ② 功能测试 (Function Test)或特性测试(Feature Test): 按照软件的功能或特性逐个进行测试。例如，在 Exchange中，发送邮件和接收邮件就是两个不同的功能或特性，在测试时就分别对它们进行检查，看是否工作正常。 ③ 提交测试 (Check-in Test): 在开发人员对代码做了任何修改，或者修复了某个Bug时，需要重新Check-in代码 (即将修改后的代码放大到整个大的系统中)。这时，开发人员往往也要进行测试，看代码是否工作正常。为了保险起见，开发人员往往要找测试人员帮着一起进行测试(我们把这种情况称做Buddy Test)。测试人员和开发人员之间搞好关系是非常重要的，稍后我会专门讲述这一点。 ④ 基本验证测试 (Build Verification Test，简称BVT): 对完成的代码进行编译和连接，产生一个构造，以检查程序的主要功能是否会像预期一样进行工作。这是最简单而又最省时的一种测试方法。每产生一个新的构造时都要进行测试。如果连BVT部通不过，表明问题很严重，开发人员需要尽快修复出现的问题，测试人员也就不用浪费时间做其他测试了。 ⑤ 回归测试 (Regression Test): 过一段时间以后，再回过头来对以前修复过的Bug重新进行测试，看该Bug是否会重新出现。 (2) 使用测试(Usage Testing) 使用测试是从用户的角度(即外部)出发的测试方法。它也包括许多类型。 ① 配置测试 (Configuration Test): 从用户的使用出发进行多方面的测试。例如，保证软件不仅能够在Windows 9X下运行，也能够在Windows ME下运行，还能够在Windows NT/200O/XP下运行;或者软件不仅能够在配置高的计算机上运行，也能够在配置很低的计算机上正确地运行。总之，要考虑到用户的多种情况，用多种配置对软件进行测试。 ② 兼容性侧试 (Compatibility Test): 主要考虑兼容性问题，比如同一个产品的不同版本(如Office 2O00和Office XP)之间的兼容问题，不同厂家的同一个产品(如IE和Netscape)之间的兼容问题，不同类型软件(如IE和Office)之间的兼容问题等。最难测试的往往就是软件的兼容性问题，往往要投人巨大的人力和物力。一些厂商开发出来的产品在兼容性上做得很不好，就是因为没有足够的人力和物力进行测试。 我在做SQL Server的XML测试的时候，为了解决XML的兼容性问题，用了6个测试人员和100台计算机进行测试。正因如此，微软产品的兼容性都非常好。而不像市场上的一些产品，安装以后就导致计算机上的许多其他软件无法使用，或者出现各种各样的问题，这样不仅伤害了其他软件，也伤害了用户。 ③ 强力测试 (StressTest): 在各种极限情况下对产品进行测试 (如很多人同时使用该软件，或者反复运行该软件)，以检查产品的长期稳定性。例如，我们在开发1E 4.0的时候，由于当时有一个非常强的竞争对手，因此我们必须保证1E4.0要做得非常好。当时，为了测试IE4.0的长期稳定性，我们专门设计了一套自动测试程序，它一分钟可以下载上千个页面。我们使用这个测试程序对IE4.0进行了连续72小时的测试，也没有出现任何问题，如内存泄漏、程序崩溃等。 本项测试可以帮助找到一些大型的问题，如死机、崩损、内存泄漏等，因为有些存在内存泄漏问题的程序，在运行一两次时可能不会出现问题，但是如果运行了成千上万次，内存泄漏得越来越多，就会导致系统崩滑。 ④ 性能测试 (Performance Test): 本项测试是保证程序具有良好的性能。如果别人的产品只需5秒钟就能得出结果，而你的产品需要10秒钟才能得出结果，就说明你的产品性能不好。如果在测试过程中发现性能问题，修复起来是非常艰难的，因为这常常意味着程序的算法不好，结构不好，或者设计有问题。因此在产品开发的开始阶段，就要考虑到软件的性能问题。 ⑤ 文档和帮助文件测试 (Documentation and help file Test): 因为用户通常是通过文档和帮助文件来学习使用产品的，如果文档和帮助文件存在错误，就可能会导致用户无法正常使用产品。这项工作通常在产品即将Ship(即准备包装发布)时进行，以避免在修复Bug的过程中需要反复修改文档，或者忘记修改文档，导致文档与产品的特性不相符。 ⑥ Alpha和Beta测试 (Alpha and Beta Test): 在正式发布产品之前往往要先发布一些测试版，让用户能够反馈出相关信息，或者找到存在的Bug，以便在正式版中得到解决。 还有一种分类方法将测试方法分为如下几种。 (1) 白盒测试 (White Box Testing) 又叫做玻璃盒测试(Glass Box Testing)。在软件编码阶段，开发人员根据自己对代码的理解和接触所进行的软件测试叫做白盒测试。这一阶段测试以软件开发人员为主，有时候SDE/T也会辅助开发人员进行测试。 (2) 黑盒测试 (Black Box Testing) 黑盒测试的内容主要有以下几个方面。 ① 接受性测试 (Acceptance Testing)：类似于BVT测试。 ② Alpha/Beta测试 (Alpha/Beta Testing): 在此过程中，产品特征不断地修改。当发现Bug后，在开发人员修改的同时，项目经理也会对产品计划做出相应的调整，产品计划不是一成不变的 ③ 菜单/帮助测试 (Menu/Help Testing)：大家千万不要以为这一项测试不值得进行。其实，在软件产品开发的最后阶段，文档里发现的问题往往是最多的。因为在软件测试过程中，开发人员会修复侧试人员发现的Bug，而且可能会对软件的有些功能进行修改，同时项目经理也会根据情况调整软件的特性，因而在软件开发和测试的过程中，所有的功能都不是固定不变的，都会进行调整。所以，一般来说，直到软件Ship时才编写软件的帮助文档，这样才能保证帮助文件的内容与软件功能相符，我在做帮助文件测试的时候，总是假装什么都不懂，就按照帮助文件提供的步骤去做，看看该文件是否正确。在实际测试中，我经常能发现帮助文件中的Bug。 ④ 发行测试 （Release Testing）：在正式发行前，产品要经过非常仔细的测试。除了专门的测试人员外，还需要几千个甚至几十万其他用户与合作者通过亲自使用来对产品进行测试，然后将错误信息反馈给我们。到了发行测试这一步，如果出现非改不可的Bug，就必须推迟软件的发行，有的时候一推就是几个月，期间需要重新对软件产品进行全面的测试，耗费大量的时间和人力物力。 ⑤ 回归测试 （Regression Testing）：回归测试的目的就是保证以前已经修复的Bug在软件Ship以前不会再出现。实际上，许多Bug都是在回归测试时发现的，在此阶段，我们首先要检查以前找到的Bug是否已经更正了。值得注意的是，已经更正的Bug也可能有回来了，有的Bug经过修改之后可能又产生了新的Bug。所以，回归测试可保证已更正的Bug不再重现，不产生新的Bug。 ⑥ RTM测试（Release To Manufacture Testing）：为产品真正的Ship做好准备所进行的测试。事实上，在这一测试阶段，对每一个Bug都需要经过很高职务的人同意才能更正。因为这时候修改软件非常容易产生其他的错误，所以只有那种非修复不可的Bug才会被允许进行修改。如果在发行阶段软件还有许多严重的Bug的话，恐怕就不能按时发布了。记得有一次一个微软核心产品刚刚完成，准备Ship时，我对其进行RTM测试时就发现一个Bug：只要用该产品打印中文就会导致程序错误。这是一个很严重的Bug，浴室开发人员马上修复了该Bug，重新Ship该产品。 功能及系统测试（Function ＆ System Testing）：这一点是最重要的，他包括了非常多的内容。 · 规范验证 (Specification Verification） · 正确性 (Correctness） · 可用性 (Usability） · 边界条件 (Boundary Condition） · 性能 (Performance) · 强力测试 (Stress) · 错误恢复 (Error Recovery) · 安全性 (Security) · 兼容性 (Compatibility) · 软件配置 (Configuration) · 软件安装 (Installation) 另外一种分类方法就比较好理解了，主要将软件测试方法分为如下几种。 ⑴ 手工测试 （Manual Testing）：即依靠人力来查找Bug。 ⑵ 自动测试 （Automation Testing） 即编写一些测试工具，让他们自动运行来查找Bug。 自动测试的优点是能够很快、很广泛地查找Bug，缺点是它们只能检查一些最主要的问题，如崩溃、死机，但是却无法发现一些一般的日常错误，这些错误通过人眼很容易找到，但机器却往往找不到。另外，在自动测试中编写测试工作量也很大，因此在实际测试中通常是手工测试和自动测试相结合，而且手工测试往往是主要的，占了1/2－2/3，而自动测试只占1/3－1/2。在不同的开发队伍中，这个比例会有所不同，但总体趋势是这样的。 有了好的测试方法，还需要有高效好用的辅助工具，做软件测试通常需要以下一些基本工具。 · 计算机 · 优秀的办公处理软件（如字处理软件和表单软件，用于编写测试计划和规范） · 视频设备 · 秒表（角色程序运算时间，测试产品性能） · 错误跟踪系统（微软内部使用的是RAID，用来自动跟踪Bug） · 自动测试工具（产生Automation脚本） · 软件分析工具 · 好的操作系统（如Windows NT/2000，其中有很多有用的工具，如文件比较器、文件查看器、文件转换器、内存监视器等） · 多样化平台 � EMBED Excel.Chart.8 \s ��� � EMBED MSPhotoEd.3 ��� 根据微软的经验，每修复三到四个Bug一般就会产生一个新的Bug。 在微软公司，Bug经过开发人员解决后，再回到软件测试人员手中时，会被分为以下几种类型。 Fixed:表示Bug己经被修复或更正了。 Duplicated: 表示测试人员所找到的某个Bug已经被别人找出来了。这种情况是很难避免的。一是因为同时有许多测试人员在进行测试，这样就很有可能有多个测试人员先后发现同一个Bug；二是因为同一个Bug在不同的进入计况下所表现的现象也不一样，尽管表面上看起来是不同的Bug，但实际上可能是相同的。因此在报告一个Bug之前一般都要搜索该Bug是否巳经存在。 Postponed: 表明这个Bug不是很重要，在当前阶段不用进行更正了；或者更正这个Bug风险大大，Bug本身又不会造成大的影响。 By design: 测试人员认为是Bug，不符合逻辑，也不符合用户的需求，但开发人员则认为是按照项目经理的设计做的。 Not repro: 以前出现的某个Bug自动消失了，可能是在处理其他Bug的时候把这个Bug一并修复掉了。 Won't fix: 这个Bug是一个错误，还没有重要到非要更正不可的地步，完全可以忽略不计。 强力测试时间要求:根据微软的实践经验，如来一个软件产品