软件测试作业指导书.doc

软件测试作业指导书.doc

《软件测试作业指导书.doc》由会员分享，可在线阅读，更多相关《软件测试作业指导书.doc（37页珍藏版）》请在冰豆网上搜索。

润和软件测试作业指导书

测试作业指导书

基础篇 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．软件未达到产品说明书表明的功能

计算器的产品说明书可能声称它能够准确无误的进行加、减、乘、除运算。

如果按下加号（+）键，结果什么反应也没有，根据该条规则，这就是个软件缺陷。

假如得到错误的答案，根据规则，同样是软件缺陷

2．软件出现了产品说明书指明不会出现的错误

产品说明书可能声称计算机永远不会崩溃、锁死或者停止反应。

假如狂敲键盘会使计算器停止接受输入，根据本条规则，这是一个软件缺陷

3．软件功能超出产品说明书指明范围

假如我们发现除了加减乘除之外计算器还可以求品方根，而这一功能哪儿都没提。

干劲十足的程序员加入这项功能可能因为觉得这是一项创举，根据本条规则，这是软件缺陷。

4．软件未达到产品说明书虽未指出但应达到的目标

这条规则可能让人感觉有些矛盾和奇怪，但是这样是为了抓住产品说明书上遗漏之处。

在测试计算器时，会发现电池没电会导致计算机不正确。

没有人会考虑应如何应付这种情况，使计算机反应正常，而盲目以为电池永远充足了电。

测试要持续进行到电池完全没电，是少要看到电力不足的迹象。

产品说明书指出电力不足无法正确计算，但未指出会怎样，根据本条规则，这是软件缺陷。

5．软件测试人员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。

本条规则是全面的。

软件测试人员是第1个真正使用软件的人。

如果发现某些地方不对劲，无论什么原因，都要认定为软件缺陷。

对于计算器来说，可能觉得按键太小；也许等号（=）键的位置放得不好按；也许显示屏在亮光下很难以看清，根据本条规则，这些都是缺陷。

注意：

每一个使用过一些软件的人都会对如何改进有一些要求和意见。

要编写令所有用户都喜欢的软件是不可能的。

作为软件测试人员，在运用第5条测试规则时应记住这一点。

最好能全面地客观评价，做到合情合理。

002．影响软件质量的原因

影响软件质量的原因很多，具体地说，主要有以下几点：

1．用户原因

需求不清；二义性

2．产品说明书

没有产品说明书；说明书不够全面、经常更改

3．设计方案

与产品说明书是一样的，片面、易变

4．交流不够、交流上有误解或者根本不进行交流

在应用应该做什么或不应该做什么的细节（应用的需求）不清晰的情况下进行开发

5．软件复杂性

图形用户界面（GUI），客户/服务器结构，分布式应用，数据通信，超大型关系型数据库以及庞大的系统规模，使得软件及系统的复杂性呈指数增长，没有现代化开发经验的人很难理解它。

6．程序设计错误

跟所有的人一样，程序员也会出错

7．时间压力

软件项目的日程表很难做到准确，很多时候需要预计和猜测。

当最终期限迫近和关键时刻到来之际，错误也就跟着来了。

8．自负

自负的人更喜欢说：

“没问题”；“这件事很容易”；“几个小时我就能拿出来”，太多不切

实际的“没问题”结果只能是引入错误。

9．代码文档贫乏

贫乏或者差劲的文档使得代码维护和修改变的异常艰辛，其结果是带来许多错误。

事实

上，在许多机构并不鼓励其程序员为代码编写文档，也不鼓励程序员将代码写得清晰和

容易理解，相反他们认为少写文档可以更快的进行编码，无法理解的代码更易于工作的

保密（“写的艰难必定读的痛苦”）

10.软件开发工具

可视化工具，类库，编译器，脚本工具，等等，他们常常会将自身的错误带到应用软件中。

就像我们所知道的，没有良好的工程化作为基础，使用面向对象的技术只会使项目变得更复杂。

003．提高软件质量的方法

1．软件工程化

2．CMM能力成熟度模型CapabilityMaturityModelforSoftware

3．软件测试

004．软件测试的目标与定义

软件测试的目的决定了如何去组织测试，在项目的不同阶段，测试的目的也不相同。

1．在UT（UnitTest）阶段，测试的目的是为了尽可能多地找出错误，那么UT阶段测试就应该直接针对软件比较复杂的部分或是以前出错比较多的位置。

在此阶段，可以引用GrenfordJ.Myers在《TheArtofSoftwareTesting》一书中的观点：

Ø软件测试是为了发现错误而执行程序的过程；

Ø测试是为了证明程序有错，而不是证明程序无错误。

Ø好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案；

Ø成功的测试是发现了至今为止尚未发现的错误的测试。

这种观点可以提醒人们测试要以查找错误为中心，而不是为了演示软件的正确功能。

但是仅凭字面意思理解这一观点可能会产生误导，认为发现错误是软件测试的唯一目的，查找不出错误的测试就是没有价值的，事实并非如此。

首先，测试并不仅仅是为了要找出错误。

通过分析错误产生的原因和错误的分布特征，可以帮助项目管理者发现当前所采用的软件过程的缺陷，以便改进。

同时，这种分析也能帮助我们设计出有针对性地检测方法，改善测试的有效性。

其次，没有发现错误的测试也是有价值的，完整的测试是评定测试质量的一种方法。

详细而严谨的可靠性增长模型可以证明这一点。

2．SI测试阶段的目的是为了给最终用户提供具有一定可信度的质量评价，那么测试就应该直接针对在实际应用中会经常用到的商业假设。

在这一阶段不仅要验证UT测试的结果，检测出软件本身的缺陷，更重要的是要站在用

户的角度找出我们在软件开发过程中的不合理的地方，最终的目的是让用户满意。

对于软件产品的不同角色来说，他们的测试目的也是不同的。

用户：

通过测试来暴露错误

开发者：

通过测试来证明自己开发的产品不存在错误

测试人员：

找出软件缺陷，尽可能早一些，并确保其得以修复

测试从狭义上说，就是：

凭借测试用例TestCase→运行程序→发现错误的过程。

005．软件测试中的原则

1．完全测试程序是不可能的

在软件测试的过程中，想要进行完全测试，找出所有软件缺陷，并使软件臻于完美，实际上这是不可能的，即使最简单的程序也不行，主要有如下4个原因：

l输入量太大

l输出结果太多

l软件实现途径太多

l软件说明书没有客观标准。

从不同的角度看，软件缺陷的标准不同。

2．软件测试是有风险的行为

正因为完全测试程序是不可能的，那么在测试的过程中必定会对某些你认为是重复的或者没必要的或者为了节省时间，而将其提出，如果决定不去测试所有的情况，这就是选择了风险。

既然不可能做完全测试，那么这种风险就是无法避免的了。

软件测试员要学会的一个主要原则就是如何把无边无际的可能减少到可以控制的范围，以及如何针对风险制定做出明智抉择，去粗存精。

3．测试无法显示潜伏的软件缺陷

软件测试工作与防疫员的工作极为相似，可以报告已发现的软件缺陷，却无法报告潜伏的软件缺陷。

你可以进行测试，查找并报告软件缺陷，但是不能保证软件缺陷全部找到。

唯一的方法是继续测试，可能还会找到一些。

4．找到的软件缺陷越多，就说明软件缺陷越多

通常，软件测试员在没有找到软件缺陷之前拼命地琢磨。

找到一个之后，就会接二连三地找到更多。

其中的原因是：

l程序员怠倦。

和我们大家一样，程序员也要休假。

编写一天代码还不错，第二天就会烦躁不安了。

一个软件缺陷很可能是泄露附近有更多软件缺陷的信号。

l程序员往往犯同样的错误。

每个人都有偏好。

一个程序员总是反复犯下自己容易犯的错误。

l某些软件缺陷实际上是大灾难的征兆。

软件的设计或者体系常常会出现基础问题。

软件测试员可能会发现某些软件缺陷开始似乎毫无关联的，但是最后才知道它们是由一个极其严重的原因造成的。

但是，如果无论如何也找不出软件缺陷，那么也有可能是软件经过精心编制，确实存在极少软件缺陷

5．反复使用相同的测试会使软件具有抵抗力

在测试过程中你会发现经过几个回合的测试之后，该发现的软件缺陷都被发现了，在测试下去也不会有新的发现了。

这时，软件测试员，需要采用其他新的方法，对程序的不同部分进行测试，以找出更多软件缺陷。

6．并非所有的软件缺陷都能修复

这要求软件测试员能过进行良好的判断，搞清楚在什么情况下不能追求完美。

项目小组需要对每一个软件缺陷进行取舍，根据风险决定哪些需要修复，哪些不要。

不需要修复软件缺陷的主要原因有：

l没有足够的时间。

在任何一个项目中，通常是软件功能较多，而代码编写人员和软件测试人员较少，而且在项目进度中没有为编制和测试留出足够的空间。

常常会在不可更改的交付期限内，必须按时完成软件。

l不算真正的软件缺陷。

在某些特殊场合，错误理解、测试错误或者说明书变更会把软件缺陷当作附加功能来对待。

l修复的风险太大。

修复一个软件缺陷可能导致其他软件缺陷出现；在紧迫的产品发布进度压力之外，修改软件将冒很大的风险。

不去理睬未知软件缺陷，以避免出现未知新缺陷的做法也许是安全之道。

l不值得修复。

不常出现的软件缺陷和在不常用功能中出现的软件缺陷可以放过；可以躲过和用户有办法预防或避免的软件缺陷通常不用修复。

这些都要归结为商业风险决策。

7．要尽早、不断地进行测试

测试是无穷近的，而测试的时间又是有限的，所以我们要尽早地开始测试，尽快地找出软件缺陷，以便降低修复成本。

在几个回合的测试以后，没有再检测出BUG，不能说程序没有错误，只能说还没有找到错误，没有人能够找出程序中所有的错误，没有任何软件产品是完美无错的，我们能做的只是不断地进行测试。

8．测试用例可以帮助我们有效地进行测试

“好的测试用例是极可能发现迄今为止尚未发现的错误的测试用例”，可见测试用例对在软件测试中占有很重要的地位，它可以弥补软件测试员在测试时的遗漏、偏差以及经验上的不足，给我们的测试提供依据。

同时测试用例也是作为向用户提供的质量保证的重要依据之一。

9．程序员应避免测试自己的程序

“自负”是影响程序质量的原因之一，程序员测试的目的是证明程序的无错，基于这种心理，程序员是很难测试自己程序中的BUG的。

另一方面，程序员在理解式样的时候难免会有偏差，如果测试自己的程序是很难找出这些偏差的。

10.正确和错误的测试

软