软件测试作业指导书.docVIP

测试作业指导书 基础篇 5 001．什么是软件缺陷（bug） 5 002．影响软件质量的原因 5 003．提高软件质量的方法 6 004．软件测试的目标与定义 6 005．软件测试中的原则 7 006．如何成为一个好的软件测试员 9 007．软件测试的阶段划分 11 008．测试用例的设计方法 12 01．测试用例的特征： 12 02．测试用例的设计原则 12 03．等价类划分方法 12 04．边界值分析方法 14 05．因果图方法 17 06．判定表驱动分析方法 19 07．功能图分析方法 23 08．场景设计方法 24 09．测试用例设计综合策略 24 10．测试用例的设计步骤 25 009．软件测试的基本方式 25 01．黑盒测试 25 02．白盒测试 25 03．静态测试 25 04．动态测试 25 010．软件测试的基本方法 25 01．过测试和失败测试 25 02．等价类划分 26 03．数据测试 26 04．状态测试 26 05．其他黑盒测试方法 28 实践篇 30 001．测试流程图 30 002．测试准备 31 003．如何做好式样理解 31 004．关于测试用例的设计 31 005．测试数据的准备 32 006．测试的实施 33 007．测试过程中的变更管理 34 008．如何填写QA票和bug票 34 009．文档管理工具(cvs)的使用 35 010．bug管理工具（QAMS）的使用 35  基础篇 001．什么是软件缺陷（bug） 软件未达到产品说明书表明的功能 计算器的产品说明书可能声称它能够准确无误的进行加、减、乘、除运算。如果按下加号（+）键，结果什么反应也没有，根据该条规则，这就是个软件缺陷。假如得到错误的答案，根据规则，同样是软件缺陷 软件出现了产品说明书指明不会出现的错误 产品说明书可能声称计算机永远不会崩溃、锁死或者停止反应。假如狂敲键盘会使计算器停止接受输入，根据本条规则，这是一个软件缺陷 软件功能超出产品说明书指明范围 假如我们发现除了加减乘除之外计算器还可以求品方根，而这一功能哪儿都没提。干劲十足的程序员加入这项功能可能因为觉得这是一项创举，根据本条规则，这是软件缺陷。 软件未达到产品说明书虽未指出但应达到的目标 这条规则可能让人感觉有些矛盾和奇怪，但是这样是为了抓住产品说明书上遗漏之处。在测试计算器时，会发现电池没电会导致计算机不正确。没有人会考虑应如何应付这种情况，使计算机反应正常，而盲目以为电池永远充足了电。测试要持续进行到电池完全没电，是少要看到电力不足的迹象。产品说明书指出电力不足无法正确计算，但未指出会怎样，根据本条规则，这是软件缺陷。 软件测试人员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。 本条规则是全面的。软件测试人员是第1个真正使用软件的人。如果发现某些地方不对劲，无论什么原因，都要认定为软件缺陷。对于计算器来说，可能觉得按键太小；也许等号（=）键的位置放得不好按；也许显示屏在亮光下很难以看清，根据本条规则，这些都是缺陷。 注意：每一个使用过一些软件的人都会对如何改进有一些要求和意见。要编写令所有用户都喜欢的软件是不可能的。作为软件测试人员，在运用第5条测试规则时应记住这一点。最好能全面地客观评价，做到合情合理。 002．影响软件质量的原因 影响软件质量的原因很多，具体地说，主要有以下几点： 用户原因 需求不清；二义性 产品说明书 没有产品说明书；说明书不够全面、经常更改 设计方案 与产品说明书是一样的，片面、易变 交流不够、交流上有误解或者根本不进行交流 在应用应该做什么或不应该做什么的细节（应用的需求）不清晰的情况下进行开发 软件复杂性 图形用户界面（GUI），客户/服务器结构，分布式应用，数据通信，超大型关系型数据库以及庞大的系统规模，使得软件及系统的复杂性呈指数增长，没有现代化开发经验的人很难理解它。 程序设计错误 跟所有的人一样，程序员也会出错 时间压力 软件项目的日程表很难做到准确，很多时候需要预计和猜测。当最终期限迫近和关键时刻到来之际，错误也就跟着来了。 自负 自负的人更喜欢说：“没问题”；“这件事很容易”；“几个小时我就能拿出来”，太多不切 实际的“没问题”结果只能是引入错误。 代码文档贫乏 贫乏或者差劲的文档使得代码维护和修改变的异常艰辛，其结果是带来许多错误。事实 上，在许多机构并不鼓励其程序员为代码编写文档，也不鼓励程序员将代码写得清晰和 容易理解，相反他们认为少写文档可以更快的进行编码，无法理解的代码更易于工作的 保密（“写的艰难必定读的痛苦”） 10.软件开发工具 可视化工具，类库，编译器，脚本工具，等等，他们常常会将自身的错误带到应用软件中。就像我们所知