软件测试作业指导书

基础篇    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  能力成熟度模型  Capability Maturity Model for Software

3．软件测试

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

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

1．在UT(Unit Test)阶段，测试的目的是为了尽可能多地找出错误，那么UT阶段测试就应该直接针对软件比较复杂的部分或是以前出错比较多的位置。在此阶段，可以引用Grenford J. Myers在《The Art of Software Testing》一书中的观点：

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

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

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

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

   这种观点可以提醒人们测试要以查找错误为中心，而不是为了演示软件的正确功能。但是仅凭字面意思理解这一观点可能会产生误导，认为发现错误是软件测试的唯一目的，查找不出错误的测试就是没有价值的，事实并非如此。

首先，测试并不仅仅是为了要找出错误。通过分析错误产生的原因和错误的分布特征，可以帮助项目管理者发现当前所采用的软件过程的缺陷，以便改进。同时，这种分析也能帮助我们设计出有针对性地检测方法，改善测试的有效性。

其次，没有发现错误的测试也是有价值的，完整的测试是评定测试质量的一种方法。详细而严谨的可靠性增长模型可以证明这一点。

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

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

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

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

用户：通过测试来暴露错误

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

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

测试从狭义上说，就是：凭借测试用例Test Case→运行程序→发现错误的过程。

005．软件测试中的原则

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

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

●输入量太大

●输出结果太多

●软件实现途径太多

●软件说明书没有客观标准。从不同的角度看，软件缺陷的标准不同。

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

正因为完全测试程序是不可能的，那么在测试的过程中必定会对某些你认为是重复的或者没必要的或者为了节省时间，而将其提出，如果决定不去测试所有的情况，这就是选择了风险。既然不可能做完全测试，那么这种风险就是无法避免的了。软件测试员要学会的一个主要原则就是如何把无边无际的可能减少到可以控制的范围，以及如何针对风险制定做出明智抉择，去粗存精。

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

软件测试工作与防疫员的工作极为相似，可以报告已发现的软件缺陷，却无法报告潜伏的软件缺陷。你可以进行测试，查找并报告软件缺陷，但是不能保证软件缺陷全部找到。唯一的方法是继续测试，可能还会找到一些。

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

通常，软件测试员在没有找到软件缺陷之前拼命地琢磨。找到一个之后，就会接二连三地找到更多。其中的原因是：

●程序员怠倦。和我们大家一样，程序员也要休假。编写一天代码还不错，第二天就会烦躁不安了。一个软件缺陷很可能是泄露附近有更多软件缺陷的信号。

●程序员往往犯同样的错误。每个人都有偏好。一个程序员总是反复犯下自己容易犯的错误。

●某些软件缺陷实际上是大灾难的征兆。软件的设计或者体系常常会出现基础问题。软件测试员可能会发现某些软件缺陷开始似乎毫无关联的，但是最后才知道它们是由一个极其严重的原因造成的。

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

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

在测试过程中你会发现经过几个回合的测试之后，该发现的软件缺陷都被发现了，在测试下去也不会有新的发现了。这时，软件测试员，需要采用其他新的方法，对程序的不同部分进行测试，以找出更多软件缺陷。

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

这要求软件测试员能过进行良好的判断，搞清楚在什么情况下不能追求完美。项目小组需要对每一个软件缺陷进行取舍，根据风险决定哪些需要修复，哪些不要。

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

●没有足够的时间。在任何一个项目中，通常是软件功能较多，而代码编写人员和软件测试人员较少，而且在项目进度中没有为编制和测试留出足够的空间。常常会在不可更改的交付期限内，必须按时完成软件。

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

●修复的风险太大。修复一个软件缺陷可能导致其他软件缺陷出现；在紧迫的产品发布进度压力之外，修改软件将冒很大的风险。不去理睬未知软件缺陷，以避免出现未知新缺陷的做法也许是安全之道。

●不值得修复。不常出现的软件缺陷和在不常用功能中出现的软件缺陷可以放过；可以躲过和用户有办法预防或避免的软件缺陷通常不用修复。这些都要归结为商业风险决策。

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

测试是无穷近的，而测试的时间又是有限的，所以我们要尽早地开始测试，尽快地找出软件缺陷，以便降低修复成本。在几个回合的测试以后，没有再检测出BUG，不能说程序没有错误，只能说还没有找到错误，没有人能够找出程序中所有的错误，没有任何软件产品是完美无错的，我们能做的只是不断地进行测试。

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

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

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

“自负”是影响程序质量的原因之一，程序员测试的目的是证明程序的无错，基于这种心理，程序员是很难测试自己程序中的BUG的。另一方面，程序员在理解式样的时候难免会有偏差，如果测试自己的程序是很难找出这些偏差的。

10. 正确和错误的测试

    软件测试员测试的目的是要找出软件潜在的错误和缺陷，这里的错误和缺陷不仅指软件本身的错误，还要检测软件对错误的处理能力，所以我们在测试的时候既要准备正确的数据也要准备错误的数据，一般来说测试错误的CASE比正确的CASE要多很多。

11. 群集现象

    在测试的过程中，会发现某些画面BUG特别多，某些功能会出现BUG群集的现象，所以要重视这些群集现象，并且及时的采取对策。

12. 杜绝随意性

软件测试时一定要有测试依据的，测试人员不能按照自己的想法凭空想象来评判对错。

软件测试员是客户的眼睛，是第一次看到软件的人，代表客户说话，应力求完美。但力求完美的同时，最好能全面地客观评价，做到合情合理。

006．如何成为一个好的软件测试员

现在，大多数公司把软件测试视为技术工程专业工作。他们意识到在项目组中培训软件测试员，并在开发过程中早期投入工作可以制造出质量更优的软件。

下面是大多数软件测试员应具备的素质：

●沟通能力。一名理想的测试者必须能够同测试涉及到的所有人进行沟通，具有与技术（开发者）和非技术人员（客户，管理人员）的交流能力。既要可以和用户谈得来，又能同开发人员说得上话，不幸的是这两类人没有共同语言。和用户谈话的重点必须放在系统可以正确地处理什么和不可以处理什么上。而和开发者谈相同的信息时，就必须将这些活重新组织以另一种方式表达出来，测试小组的成员必须能够同等地同用户和开发者沟通。

●技术能力。就总体言，开发人员对那些不懂技术的人持一种轻视的态度。一旦测试小组的某个成员作出了一个错误的断定，那么他们的可信度就会立刻被传扬了出去。一个测试者必须既明白被测软件系统的概念又要会使用工程中的那些工具。要做到这一点需要有几年以上的编程经验，前期的开发经验可以帮助对软件开发过程有较深入的理解，从开发人员的角度正确的评价测试者，简化自动测试工具编程的学习曲线。

●自信心。开发者指责测试者出了错是常有的事，测试者必须对自己的观点有足够的自信心。如果容许别人对自己指东指西，就不能完成什么更多的事情了。因为开发和测试的立场不同，面对问题的时候测试人员要有自信坚持自己的观点，而不能轻信开发人员的说法。

●外交能力。当你告诉某人他出了错时，就必须使用一些外交方法。机智老练和外交手法有助于维护与开发人员的协作关系，测试者在告诉开发者他的软件有错误时，也同样需要一定的外交手腕。如果采取的方法过于强硬，对测试者来说，在以后和开发部门的合作方面就相当于“赢了战争却输了战役”。

●幽默感。在遇到狡辩的情况下，一个幽默的批评将是很有帮助的。

●很强的记忆力。一个理想的测试者应该有能力将以前曾经遇到过的类似的错误从记忆深处挖掘出来，这一能力在测试过程中的价值是无法衡量的。因为许多新出现的问题和我们已经发现的问题相差无几。

●耐心。一些质量保证工作需要难以置信的耐心。有时你需要花费惊人的时间去分离、识别和分派一个错误。这个工作是那些坐不住的人无法完成的。

●怀疑精神。可以预料，开发者会尽他们最大的努力将所有的错误解释过去。测式者必须听每个人的说明，但他必须保持怀疑直到他自己看过以后。

●自我督促。干测试工作很容易使你变得懒散。只有那些具有自我督促能力的人才能够使自己每天正常地工作。

●洞察力。一个好的测试工程师具有“测试是为了破坏”的观点，捕获用户观点的能力，强烈的质量追求，对细节的关注能力。应用的高风险区的判断能力以便将有限的测试针对重点环节。

●不懈努力。软件测试员总是不停尝试。他们可能会碰到瞬间即逝或者难以重建的软件缺陷。他们不会心存侥幸，而是尽一切可能去寻找。

●创造性。测试显而易见的事实，那不是软件测试员。他们的工作是相处富有创意甚至超常的手段来寻找软件缺陷。

●追求完美。他们力求完美，但是知道某些无法企及时，不去苛求，而是尽力接近目标。

●判断准确。软件测试员要决定测试内容、测试时间，以及看到的问题是否算作真正的缺陷。

●说服力。软件测试员找出的软件缺陷有是被人认为不重要，不用修复。测试员要善于表达观点，表明软件缺陷为何必须修复，并通过实际演示力陈观点。

    软件测试员的一个基本素质是打破砂锅问到底。他们喜欢找出那些深藏不露的系统冲突。他们乐于处理最复杂的问题。他们外表上热衷于来回奔忙，追求尽善尽美。

软件测试员的任务是检查和批评同事的工作，挑毛病，公布发现的问题。这样难免与项目组中的其他人员会产生摩擦，下面是保持小组成员和睦的建议：

●早点找出软件缺陷。这是软件测试员的当然任务，但是不容易做到。在三个月之前而不是在产品即将发布前夕找出严重的软件缺陷，会产生更小的影响，更容易让人接受。

●控制情绪。诚然，软件测试员真心喜爱自己的工作，当发现严重的软件缺陷时乐不自胜。但是，如果兴冲冲地闯进程序员同事的房间告诉他程序中存在不可救药的软件缺陷，他不会高兴的。

不要总是报告坏消息。假如意外发现某些代码没有软件缺陷，就大声宣扬。花一些时间找程序员聊聊天。如果总是报告坏消息，别人就会惟恐避之不及。

007．软件测试的阶段划分

1．单体测试

单元测试的对象是软件设计的最小单位——模块。单元测试的依据是详细设描述，单元测试应对模块内所有重要的控制路径设计测试用例，以便发现模块内部的错误。单元测试时,系统内多个模块可以并行地进行测试。在这个测试阶段所发现的往往是编码和详细设计的错误。

2．结合测试

也可以称作“集成测试”，是组装软件的系统测试技术，按设计要求把通过单元测试的各个模块组装在一起之后，进行综合测试以便发现与接口有关的各种错误。

3．系统测试

系统测试应该由若干个不同测试组成，目的是充分运行系统，验证系统各部件是否都能正常工作并完成所赋予的任务。

系统测试主要有以下的几种类型 ：

●恢复测试 ：主要检查系统的容错能力 。

●安全测试 ：检查系统对非法侵入的防范能力。

●强度测试 ：检查程序对异常情况的抵抗能力。

●性能测试 ：检查测试数据在超负荷环境中运行，程序是否能够承担。

4．回归测试

确定软件修改和变更后仍然满足所有软件要求。回归测试是有选择地重复已有的确认测试，而不开发新的测试。回归测试需要针对修改或者变更的程序进行验证，并且对该程序修正或者变更相关的功能点进行验证。回归测试不是一个的测试阶段，是贯穿在所有测试阶段中反复进行的过程。

008．测试用例的设计方法

测试用例是为特定的目的而设计的一组测试输入、执行条件和预期的结果。简单的说，测试用例就是设计一个场景，使软件程序在这种场景下，必须能够正常运行并且达到程序所涉及的执行结果。

测试用例的设计方法与测试的基本方法有类似之处，测试用例是对软件测试的设计，然后基于测试用例来进行软件测试的实施。

01．测试用例的特征：

1．最有可能抓住错误的

2．不是重复的、多余的

3．一组相似测试用例中最有效的

4．既不是太简单，也不是太复杂

02．测试用例的设计原则

1．测试用例的代表性：能够代表并覆盖各种合理的和不合理的、合法的和非法的、边界的和越界的以及极限的输入数据、操作和环境等。

2．测试结果的可判断性：即测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果。

3．测试结果的可再现性：即对同样的测试用例，系统的执行结果应当是相同的。

03．等价类划分方法

1.定义

是把所有可能的输入数据,即程序的输入域划分成若干部分（子集）,然后从每一个子集中选取少数具有代表性的数据作为测试用例。该方法是一种重要的,常用的黑盒测试用例设计方法。

2.划分等价类：

等价类是指某个输入域的子集合。在该子集合中,各个输入数据对于揭露程序中的错误都是等效的，并合理地假定：测试某等价类的代表值就等于对这一类其它值的测试，因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件就可以用少量代表性的测试数据取得较好的测试结果。等价类划分可有两种不同的情况：有效等价类和无效等价类。

1)有效等价类

    是指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。

  2)无效等价类

    与有效等价类的定义恰巧相反。无效等价类指对程序的规格说明是不合理的或无意义的输入数据所构成的集合。对于具体的问题，无效等价类至少应有一个，也可能有多个。

  设计测试用例时,要同时考虑这两种等价类。因为软件不仅要能接收合理的数据,也要能经受意外的考验，这样的测试才能确保软件具有更高的可靠性。

3.划分等价类的标准：

1)完备测试、避免冗余;

2)划分等价类重要的是：集合的划分，划分为互不相交的一组子集，而子集的并是整个集合;

3)并是整个集合：完备性;

4)子集互不相交：保证一种形式的无冗余性;

5)同一类中标识（选择）一个测试用例，同一等价类中，往往处理相同，相同处理映射到"相同的执行路径"。

4.划分等价类的方法

6)在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类。如：输入值是学生成绩，范围是0～100；

7)在输入条件规定了输入值的集合或者规定了"必须如何"的条件的情况下,可确立一个有效等价类和一个无效等价类；

8)在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类。

9)在规定了输入数据的一组值（假定n个）,并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类。

例：输入条件说明学历可为:专科、本科、硕士、博士四种之一，则分别取这四种这四个值作为四个有效等价类，另外把四种学历之外的任何学历作为无效等价类。

10)在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）；

11)在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类。

5.设计测试用例

  在确立了等价类后,可建立等价类表,列出所有划分出的等价类输入条件：有效等价类、无效等价类，然后从划分出的等价类中按以下三个原则设计测试用例：

1)为每一个等价类规定一个唯一的编号；

2)设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖地有效等价类,重复这一步，直到所有的有效等价类都被覆盖为止；

  3)设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步，直到所有的无效等价类都被覆盖为止。

04．边界值分析方法

边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。 

1．与等价划分的区别

  1)边界值分析不是从某等价类中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件。

  2)边界值分析不仅考虑输入条件，还要考虑输出空间产生的测试情况。

2．边界值分析方法的考虑：

长期的测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。

使用边界值分析方法设计测试用例，首先应确定边界情况。通常输入和输出等价类的边界，就是应着重测试的边界情况。应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。

3．常见的边界值

1)对16-bit 的整数而言 32767 和 -32768 是边界

2)屏幕上光标在最左上、最右下位置

3)报表的第一行和最后一行

4)数组元素的第一个和最后一个

5)循环的第 0 次、第 1 次和倒数第 2 次、最后一次

4．边界值分析

1)边界值分析使用与等价类划分法相同的划分，只是边界值分析假定错误更多地存在于划分的边界上，因此在等价类的边界上以及两侧的情况设计测试用例。

2)等价类划分：

    I.可以考虑作出如下划分：

a、输入 (i)<0 和 (ii)>=0

b、输出 (a)>=0 和 (b) Error

II.测试用例有两个：

a、输入4，输出2。对应于 (ii) 和 (a) 。

c、输入-10，输出0和错误提示。对应于 (i) 和 (b) 。

3)边界值分析：

    划分(ii)的边界为0和最大正实数；划分(i)的边界为最小负实数和0。由此得到以下测试用例：

a、输入 {最小负实数}

    b、输入 {绝对值很小的负数}

    c、输入 0

    d、输入 {绝对值很小的正数}

    e、输入 {最大正实数}

4)通常情况下，软件测试所包含的边界检验有几种类型：数字、字符、位置、重量、大小、速度、方位、尺寸、空间等。

5)相应地，以上类型的边界值应该在：最大/最小、首位/末位、上/下、最快/最慢、最高/最低、  最短/最长、 空/满等情况下。

6)利用边界值作为测试数据

在多数情况下，边界值条件是基于应用程序的功能设计而需要考虑的因素，可以从软件的规格说明或常识中得到，也是最终用户可以很容易发现问题的。然而，在测试用例设计过程中，某些边界值条件是不需要呈现给用户的，或者说用户是很难注意到的，但同时确实属于检验范畴内的边界条件，称为内部边界值条件或子边界值条件。

    内部边界值条件主要有下面几种：

a)数值的边界值检验：计算机是基于二进制进行工作的，因此，软件的任何数值运算都有一定的范围。

5.基于边界值分析方法选择测试用例的原则

1)如果输入条件规定了值的范围,则应取刚达到这个范围的边界的值,以及刚刚超越这个范围边界的值作为测试输入数据。

例如，如果程序的规格说明中规定："重量在10公斤至50公斤范围内的邮件，其邮费计算公式为……"。作为测试用例，我们应取10及50，还应取10.01,49.99,9.99及50.01等。

2)如果输入条件规定了值的个数,则用最大个数,最小个数,比最小个数少一,比最大个数多一的数作为测试数据。

比如，一个输入文件应包括1~255个记录，则测试用例可取1和255，还应取0及256等。

3)将规则1）和2）应用于输出条件，即设计测试用例使输出值达到边界值及其左右的值。

例如，某程序的规格说明要求计算出"每月保险金扣除额为0至1165.25元"，其测试用例可取0.00及1165.24、还可取一0.01及1165．26等。

再如一程序属于情报检索系统，要求每次"最少显示1条、最多显示4条情报摘要"，这时我们应考虑的测试用例包括1和4，还应包括0和5等。

4)如果程序的规格说明给出的输入域或输出域是有序集合,则应选取集合的第一个元素和最后一个元素作为测试用例。

5)如果程序中使用了一个内部数据结构,则应当选择这个内部数据结构的边界上的值作为测试用例。

6)分析规格说明,找出其它可能的边界条件。

●错误推测法

基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法。

1．错误推测方法的基本思想：

列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例。

1) 例如, 输入数据和输出数据为0的情况；输入表格为空格或输入表格只有一行。 这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例。

2)例如，前面例子中成绩报告的程序，采用错误推测法还可补充设计一些测试用例：

I.程序是否把空格作为回答

II.在回答记录中混有标准答案记录

III. 除了标题记录外，还有一些的记录最后一个字符即不是2也不是3

IV.有两个学生的学号相同

V.试题数是负数。

3)  再如，测试一个对线性表（比如数组）进行排序的程序，可推测列出以下几项需要特别测试的情况：

I.输入的线性表为空表；

II.表中只含有一个元素；

III.   输入表中所有元素已排好序；

IV.    输入表已按逆序排好；

V.     输入表中部分或全部元素相同

05．因果图方法

是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。

1．因果图法产生的背景：

等价类划分法和边界值分析方法都是着重考虑输入条件，但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。这样虽然各种输入条件可能出错的情况已经测试到了，但多个输入条件组合起来可能出错的情况却被忽视了。

如果在测试时必须考虑输入条件的各种组合，则可能的组合数目将是天文数字，因此必须考虑采用一种适合于描述多种条件的组合、相应产生多个动作的形式来进行测试用例的设计，这就需要利用因果图（逻辑模型）。

2．因果图介绍

1) 4种符号分别表示了规格说明中向4种因果关系。

2) 因果图中使用了简单的逻辑符号，以直线联接左右结点。左结点表示输入状态（或称原因），右结点表示输出状态（或称结果）。

3) Ci表示原因，通常置于图的左部；ei表示结果，通常在图的右部。Ci和ei均可取值0或1，0表示某状态不出现，1表示某状态出现。

3．因果图概念

1)    关系

①恒等：若ci是1，则ei也是1；否则ei为0。

②非：若ci是1，则ei是0；否则ei是1。

③或：若c1或c2或c3是1，则ei是1；否则ei为0。“或”可有任意个输入。

④与：若c1和c2都是1，则ei为1；否则ei为0。“与”也可有任意个输入。

2)    约束

输入状态相互之间还可能存在某些依赖关系，称为约束。例如, 某些输入条件本身不可能同时出现。输出状态之间也往往存在约束。在因果图中,用特定的符号标明这些约束。

A.输入条件的约束有以下4类：

① E约束（异）：a和b中至多有一个可能为1，即a和b不能同时为1。

② I约束（或）：a、b和c中至少有一个必须是1，即 a、b 和c不能同时为0。

③ O约束（唯一）；a和b必须有一个，且仅有1个为1。

④ R约束（要求）：a是1时，b必须是1，即不可能a是1时b是0。

B.输出条件约束类型

输出条件的约束只有M约束（强制）：若结果a是1，则结果b强制为0。

4. 采用因果图法设计测试用例的步骤：

1)分析软件规格说明描述中, 那些是原因(即输入条件或输入条件的等价类),那些是结果(即输出条件), 并给每个原因和结果赋予一个标识符。

2)分析软件规格说明描述中的语义，找出原因与结果之间, 原因与原因之间对应的关系，根据这些关系,画出因果图。

3)由于语法或环境, 有些原因与原因之间,原因与结果之间的组合情况不可能出现，为表明这些特殊情况, 在因果图上用一些记号表明约束或条件。

4)把因果图转换为判定表。

5)把判定表的每一列拿出来作为依据,设计测试用例。

06．判定表驱动分析方法

判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。

1．判定表的优点

能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。因此，利用判定表能够设计出完整的测试用例集合。

在一些数据处理问题当中，某些操作的实施依赖于多个逻辑条件的组合，即：针对不同逻辑条件的组合值，分别执行不同的操作。判定表很适合于处理这类问题。

2.“阅读指南”判定表

1)条件桩（Condition Stub）：列出了问题得所有条件。通常认为列出的条件的次序无关紧要。

2)动作桩（Action Stub）：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。

3)条件项（Condition Entry）：列出针对它左列条件的取值。在所有可能情况下的真假值。

4)动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作。

4.规则及规则合并

1)规则：任何一个条件组合的特定取值及其相应要执行的操作称为规则。在判定表中贯穿条件项和动作项的一列就是一条规则。显然,判定表中列出多少组条件取值,也就有多少条规则,既条件项和动作项有多少列。

2)化简：就是规则合并有两条或多条规则具有相同的动作，并且其条件项之间存在着极为相似的关系。

5.规则及规则合并举例

1)如下图左端，两规则动作项一样，条件项类似，在1、2条件项分别取Y、N时，无论条件3取何值，都执行同一操作。即要执行的动作与条件3无关。于是可合并。“－”表示与取值无关。

2)与上类似，下图中，无关条件项“－”可包含其他条件项取值，具有相同动作的规则可合并。

3)化简后的读书指南判定表

1)确定规则的个数.假如有n个条件。每个条件有两个取值（0,1）,故有2n种规则。

2)列出所有的条件桩和动作桩。

3)填入条件项。

4)填入动作项。等到初始判定表。

5)简化.合并相似规则（相同动作）。

07．功能图分析方法

一个程序的功能说明通常由动态说明和静态说明组成.动态说明描述了输入数据的次序或转移的次序.静态说明描述了输入条件与输出条件之间的对应关系.对于较复杂的程序,由于存在大量的组合情况,因此,仅用静态说明组成的规格说明对于测试来说往往是不够的.必须用动态说明来补充功能说明.功能图方法是用功能图FD形式化地表示程序的功能说明,并机械地生成功能图的测试用例. 功能图模型由状态迁移图和逻辑功能模型构成.状态迁移图用于表示输入数据序列以及相应的输出数据.在状态迁移图中,由输入数据和当前状态决定输出数据和后续状态.逻辑功能模型用于表示在状态中输入条件和输出条件之间的对应关系.逻辑功能模型只适合于描述静态说明,输出数据仅由输入数据决定.测试用例则是由测试中经过的一系列状态和在每个状态中必须依靠输入/输出数据满足的一对条件组成.功能图方法其实是是一种黑盒白盒混合用例设计方法。

（功能图方法中,要用到逻辑覆盖和路径测试的概念和方法,其属白盒测试方法中 的内容.逻辑覆盖是以程序内部的逻辑结构为基础的测试用例设计方法.该方法要求测试人员对程序的逻辑结构有清楚的了解.由于覆盖测试的目标不同,逻辑覆盖可分为:语句覆盖,判定覆盖,判定-条件覆盖,条件组合覆盖及路径覆盖.下面我们指的逻辑覆盖和路径是功能或系统水平上的,以区别与白盒测试中的程序内部的.）

1.功能图

功能图由状态迁移图和布尔函数组成.状态迁移图用状态和迁移来描述.一个状态指出数据输入的位置（或时间）,而迁移则指明状态的改变.同时要依靠判定表或因果图表示的逻辑功能. 

2.测试用例生成方法

将节点代替状态,用弧线代替迁移,则状态迁移图就可转化成一个程序的控制流程图形式.问题就转化为程序的路径测试问题（如白盒测试）问题了.

3.测试用例生成规则

为了把状态迁移（测试路径）的测试用例与逻辑模型（局部测试用例）的测试用例组合起来,从功能图生成实用的测试用例,须定义下面的规则.在一个结构化的状态迁移（SST）中,定义三种形式的循环:顺序,选择和重复.但分辨一个状态迁移中的所有循环是有困难的.

4.从功能图生成测试用例的过程

1)生成局部测试用例:在每个状态中,从因果图生成局部测试用例.局部测试用例由原因值（输入数据）组合与对应的结果值（输出数据或状态）构成。

2)测试路径生成:利用上面的规则（三种）生成从初始状态到最后状态的测试路径。

3)测试用例合成:合成测试路径与功能图中每个状态中的局部测试用例.结果是初始状态到最后状态的一个状态序列,以及每个状态中输入数据与对应输出数据的组合。

08．场景设计方法

现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可以引入到软件测试中，可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时使测试用例更容易理解和执行。

基本流和备选流：如下图所示，图中经过用例的每条路径都用基本流和备选流来表示，直黑线表示基本流，是经过用例的最简单的路径。备选流用不同的色彩表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中（如备选流1和3）；也可能起源于另一个备选流（如备选流2），或者终止用例而不再重新加入到某个流（如备选流2和4）。

09．测试用例设计综合策略

1)在任何情况下都必须使用边界值分析方法，经验表明用这种方法设计出测试用例发现程序错误的能力最强。

2)必要时用等价类划分方法补充一些测试用例。

3)用错误推测法再追加一些测试用例。

4)对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度，如果没有达到要求的覆盖标准，应当再补充足够的测试用例。

5)如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法。

10．测试用例的设计步骤

1)构造根据设计书得出的基本功能测试用例；

2)边界值测试用例；

3)状态转换测试用例；

4)错误猜测测试用例；

5)异常测试用例；

009．软件测试的基本方式

01．黑盒测试

只需要知道软件要做什么即可——而无法看到盒子中是如何运作的。只要进行一些输入，就能得到某种输出结果。不用知道软件如何运行，为什么会这样，只要知道程序做什么。

02．白盒测试

用访问程序员的代码，并通过检查代码来协助测试——可以看到盒子里面。测试员根据代码检查结果判断多大的数字可能出错，并据此调整测试程序。要注意的是，进行白盒测试要冒一些风险。因为要调整测试程序以适应代码操作，所以很容易形成偏见而无法进行客观测试。

03．静态测试

是指测试不运行的部分——只是检查和审阅。

04．动态测试

是指通常意义上的测试——运行和使用软件。

010．软件测试的基本方法

01．通过测试和失败测试

软件测试有两个基本方法，通过测试和失败测试。我们一般的测试用例的内容也就是由通过测试和失败测试两部分组成的。通过测试就是我们所说的正常的CASE，确认软件至少能做什么，而不会考验其能力。软件测试员不把软件当回事，只运用最简单最直观的测试用例。在设计和执行测试案例时，总是首先进行通过测试。在做破坏性试验之前首先要确保软件基本功能是否已经实现了。失败测试就是所谓的异常CASE,在确信软件在普通情况下正确运行之后，就可以采取各种手段通过搞垮软件来找出缺陷。设计和执行破坏软件的测试用例。常见的测试用例就是设法迫使软件出现错误提示信息。虽然与通过测试看起来差不多，但是它是蓄意攻击软件的薄弱环节。

02．等价类划分

选择测试按例是软件测试员最重要的任务。选择测试案例的方法是等价分配，有时称为等价划分。等价分配是指分步骤地把过多（无限）的测试用例减小到同样有效的小范围的过程。寻找等价区间时，想办法把软件的相似输入、输出、操作分成组。这些组就是等价区间。等价分配的目标是把可能的测试用例组合缩减到仍然足以测试软件的控制范围。因为选择了不完全测试，就要冒一定的风险，所以必须仔细选择分类。

03．数据测试

软件由数据（包括键盘输入、鼠标单击、磁盘文件、打印输出等等）和程序（可执行的流程、转换、逻辑和运算）两个最基本的要素组成。对软件进行数据测试，就是在检查用户输入的信息、返回结果以及中间计算结果是否正确。主要根据下列原则来进行等价分配，以合理减少测试案例：边界条件、空值和无效数据。

●边界条件测试

边界条件是指软件计划的操作界限所在的边缘条件。程序在处理大量中间数值时都是对的，但是可能在边界处出现错误。数据类型：数值、字符、位置、数量、速度、地址、尺寸等，都会包含确定的边界。

应考虑的特征：第一个/最后一个、开始/完成、空/满、最慢/最快、相邻/最远、最小值/最大值、超过/在内、最短/最长、最早/最迟、最高/最低。

这些都是可能出现的边界条件。根据边界来选择等价分配中包含的数据。然而，仅仅测试边界线上的数据点往往不够充分。提出边界条件时，一定要测试临近边界的合法数据，即测试最后一个可能合法的数据，以及刚超过边界的非法数据。

●默认值测试（默认、空白、空值、零值和无）

好的软件会处理这种情况，常用的方法：一是将输入内容默认为合法边界内的最小值，或者合法区间内某个合理值；二是返回错误提示信息。这些值在软件中通常需要进行特殊处理。因此应当建立单独的等价区间。在这种默认下，如果用户输入0或－1作为非法值，就可以执行不同的软件处理过程。

●破坏测试（非法、错误、不正确和垃圾数据）

数据测试的这一类型是失败测试的对象。这类测试没有实际规则，只是设法破坏软件。不按软件的要求行事，发挥创造力吧！

04．状态测试

状态测试是通过不同的状态验证程序的逻辑流程。软件测试员必须测试软件的状态及其转换。软件状态是指软件当前所处的情况或者模式。软件通过代码进入某一个流程分支，触发一些数据位，设置某些变量，读取某些变量，从而转入一个新的状态。

同数据测试一样，状态测试运用等价分配技术选择状态和分支。因为选择不完全测试，所以要承担一定的风险，但是通过合理选择减少危险。

●建立状态转移图 

使用：方框和箭头；圆圈（泡泡）和箭头。

应包含的项目：

      － 软件可能进入的每一种状态。

             如果不能断定是否，先认为是；以后一旦发现不是，随时剔除。

      － 从一种状态转入另一种状态所需的输入和条件。

             状态变化和存在的原因，就是我们要寻找的对象。

      － 进入或退出某种状态时的设置条件及输出结果。

             包括显示的菜单和按钮、设置的标志位、产生的打印输出、执行的运算等等。

        由于是黑盒测试，因而只需从用户的角度建立状态图即可。

●减少要测试的状态及转换的数量

测试每一种路线的组合，走遍所有分支是不可能的事情。大量的可能性也需要减少到可以操作的测试案例集合。方法有以下5种：

      － 每种状态至少访问一次。

             无论用什么方法，每种状态都必须测试。

      － 测试看起来最常见最普遍的状态转换

      － 测试状态之间最不常用的分支。

             这些分支是最容易被产品设计者和程序员忽视的。

      － 测试所有错误状态机器返回值。

             错误是否得到正确的处理、错误提示信息是否正确、修复错误时是否正确恢复软件等

      － 测试随机状态转换。

●进行具体的测试——定义测试案例

测试状态及其转换包括检查所有的状态变量——与进入和退出状态相关的静态条件、信息、值、功能等等。如：窗口外观、窗口尺寸定义（固定/上次使用时的尺寸）、显示的菜单、默认设定值、文档的名称等。状态无论是否可见，都必须进行状态确定。状态变量也许不可见，但是很重要，一个常见的例子时文档涂改标志（以此判断退出时是否询问保存）。

●失败状态测试

状态测试的失败测试的案例，主要是竞争条件、重复、压迫和重负。

1.  竞争条件和时序错乱

设计多任务操作系统不是很难，设计充分利用多任务能力的软件才是艰巨的任务。在真正的多任务环境中软件设计绝对不能想当然，必须处理随时被中断的情况，能够与其他任何软件在系统中同时运行，并且共享内存、磁盘、通信设备以及其他硬件资源。

这样的结果，就是导致竞争条件问题；软件未预料到的中断发生，时序就会发生错乱。

竞争条件测试难以设计，最好是首先仔细查看状态转换图中的每一个状态，以找出哪些外部影响会中断该状态。考虑要使用数据如果没有准备好，或者在用到时发生了变化，状态会怎样。数条弧线或者直线同时相连的情形如何。

        以下是要面临竞争条件的典型情形：

            － 两个不同的程序同时保存或打开同一个文档。

            － 共享同一台打印机、通信端口或者其他外围设备。

            － 当软件处于读取或者修改状态时按键或者单击鼠标。

            － 同时关闭或者启动软件的多个实例。

            － 同时使用不同的程序方位一个共同数据库。

2.重复、压迫和重负        

这三个测试的目标是处理那些连程序员都没有想到的恶劣条件下产生的问题的能力。

         － 重复测试

         重复测试是不断执行同样的操作。最简单的是不停地启动和关闭程序，或者反复读写数据或者选择同一个操作。这种测试的主要目的是看内存是否不足。如果内存被分配进行某项操作，但操作完成时没有完全释放，就会产生一个常见的软件问题。

        － 压迫测试

         压迫测试是使软件在不够理想的条件下运行——内存小、磁盘空间少、CPU速度慢、调制解调器速率低等等。观察软件对外部资源的要求和依赖程度。压迫测试就是将支持降到最低限度，目的在于尽可能的软件的必要条件。

        － 重负测试

        重负测试和压迫测试相反。压迫测试是尽量软件，而重负测试是尽量提供条件任其发挥。让软件处理尽可能大的数据文件。最大限度的发掘软件的能力，让它不堪重负。比如：软件对打印机或通信端口进行操作，就把能连的都连上；服务器可以处理几千个模拟连接，就按他说的做。

        不要忘了，时间也是一种重负测试。

        重复、压迫和重负测试应联合使用，同时进行。

        需要注意的是：

        一，项目管理员和小组程序员可能不完全接受软件测试员这样打破软件的做法。但是软件测试员的任务就是确保软件在这样恶劣的条件下正常工作，否则就报告软件缺陷。如何以最佳方式报告软件缺陷，使其得到严肃对待和修复，也是一门学问。

        二，无数次重复和上千次的连接对于手工操作是不可能的。因而需要借助自动化测试工具来实现。

05．其他黑盒测试方法

1.像无经验的用户那样做

        输入意想不到的数据；中途变卦而退回去执行其他操作；单击不应该单击的东西……

2.在已经找到软件缺陷的地方再找找

      原因有二：一是软件缺陷的集中性。如果发现在不同的特性中找出了大量上边界条件软件缺陷，那么就应该对所有特性着重上边界条件。对某个存在的缺陷，应当投入一些案例来保证这个问题不是普遍存在的。二是程序员往往倾向于只修改报告出来的软件缺陷，不多也不少。比如报告启动－终止－再启动255次导致冲突，程序员可能只修复了这个问题。重新测试时，一定要重新执行同样的测试256次以上。

3.凭借经验、直觉和预感

        记录哪些技术有效，哪些不行。尝试不同的途径。如果认为有可疑之处，就要仔细探究。按照预感行事，直至证实这是错误为止。

实践篇

001．测试流程图

002．测试准备

我们把测试人员进入项目到正式开始测试之前的这段时间作为测试的准备阶段。在测试的准备阶段中测试人员主要完成以下几件事情：

●了解系统全体概要、相关背景、运行环境、专业术语等等。

●切实的了解自己的工作范围。做哪些工作，需要达到什么要求，有什么成果物等等。

●认真掌握测试方案中提出的测试方法、各项指标等等。

●测试培训：针对项目的需要对测试工具、测试方法等进行必要的培训。

●搭建测试所需要的相关环境。

003．如何做好式样理解

式样是测试的依据，是判断程序是否正确的标准，所以测试人员对式样的把握直接影响到测试的效果。式样理解要做到以下两点：

●式样理解包含所有的业务功能，功能没有遗漏。

●所有的业务功能都能够正确的理解。

式样理解的内容：

●熟悉式样书的目录结构。

●熟悉设计书的内容，了解所要知道的内容在那个文档里面进行描述的。

●了解项目的背景，主要模块划分，项目的专用术语。

●通过html理解画面的主要业务以及画面的表征。

●熟悉ER图，理解项目的数据结构关系。

●理解项目的共通业务功能。

●理解各功能的详细业务。包括：迁移关系，数据的传递，画面项目定义，action处理等。

在式样理解过程中碰到疑问应及时地向设计人员确认，直到问题得到解决并且与设计人员的理解一致为止。

在测试开始之前，测试经理会安排测试人员的式样理解review，一般采用测试人员复述业务功能，并且能够描述主要的验证点，测试经理对于重点或者复杂的业务功能以提问的方式进行，以确保测试人员是否真正的理解了式样。

004．关于测试用例的设计

在测试实施之前，在式样理解的基础上，测试人员需要进行测试用例的设计。设计测试用例之前，测试人员要深入理解测试方案，有哪些keypoint。

结合测试的测试用例一般是由设计人员进行设计形成结合测试式样书，单体测试是否需要制作测试用例需要跟客户确认，如果客户同意使用详细设计书作为测试用例不再单独制作单体测试的测试用例的话，测试人员虽然不需要做成文档形式的测试用例，但必须对式样书上的功能要点设计测试用例，已达到所有业务功能都得到正确的验证。测试用例必须包含以下的内容：

测试观点：你要测试什么？

输入条件：应包括有效的和期望的输入情况，也要包括无效的和不期望的输入情况。

预想结果：在特定的输入条件下应该会出来什么样的结果，结果会是正常的结果，也会是异常的结果。结果一定是预想结果，在测试之前要先知道我需要得到什么样的结果，否则就失去了测试的意义了。

测试用例的设计要求：

●必须包含所有的功能点，不能有遗漏。

●针对每个功能，测试用例应该反映该功能正常和异常两种情况。在一般情况下，对于测试的每个需求来说，至少有一个正常测试用例和多个异常测试用例一次来检查在异常情况下系统能否正常处理，或者用户进行了错误操作时，是否给出了相关的提示。

●测试用例必须有效，避免设计无效的测试用例。

●测试用例必须唯一，避免测试用例的重复浪费。

测试用例的review点：

●用例是否完整？是否每一个需求都有其对应的测试用例来验证？

●测试用例的顺序是否合理，是否产生唯一的测试目标行为？

●是否每个测试用例都阐述了预期结果？

●是否每个测试用例（或每组相关的测试用例）都确定了初始的测试目标状态和测试数据状态？

●测试用例是否包含了所有单一的边界？

●测试用例是否包含了所有的业务数据流？

●是否所有的测试用例名称、ID都符合命名规定？

●测试数据是否多样性？等等

在正确理解式样的基础上，利用发散思维，灵活运用测试用例设计的方法，那么你的测试的品质是完全能够得到保证的。

005．测试数据的准备

测试过程需要通过数据来验证软件的正确性，数据的质量直接会影响到测试的品质，避免重复的、无效的数据是保证测试效率的关键。测试数据的准备一般分为两个阶段：

1．Master数据的准备

每个系统都会有一些master数据，在测试准备阶段，测试经理会安排测试人员准备，以便开发人员进行调试，保证系统倒入业务数据后能够运转起来。

因为master数据是一些基本的常规数据，一般可以通过以下三种方式创建：

●客户提供master数据

●前系统倒入

●测试人员准备：如果没有以前系统地master数据或者客户暂时也不能够提供，测试组可以制作一些master数据，mater数据要求更加符合项目的实际情况，数据越真实越好。

Master数据需要由测试经理制定相关测试管理员进行备份，以便数据库变更时能够及时地会复或升级。

2．业务数据的准备

在单体测试阶段，无法从画面正常录入数据进行测试，需要测试人员手动制作数据进行功能验证。制作业务数据需要注意以下几点：

●保证测试数据的性：测试人员避免使用别人的数据，严禁删除修改别人的测试数据。

●保证数据的准确性：制作测试数据关系到测试的品质和测试的效率，制作测试数据时要

保证测试数据的正确性、有效性，避免重复和无效的数据。

●对于关键业务数据测试人员各自应做好备份，一般我们使用excel来备份测试数据，在数据库更新时能够及时得倒入，避免重复制作数据浪费时间。

●测试数据尽可能的真实、易懂。

业务数据设计的技巧：

●单体测试阶段，一般先造满足条件的一条数据，验证功能是否正确，然后修改这条数据，验证错误的情况是否有合理的处理方法。

●结合测试阶段，因为尽量避免手动造数据，要求各种情况的业务数据都要制作出来，以验证不同情况下的业务功能是否满足要求。

●测试数据制作要易识别，要能很容易从数据库中找出你做制作的数据，节省查找数据所花费的时间。

●测试数据要与测试的目的紧密地结合，比如测试排序的时候，测试数据也可以加入数字等，通过直观的表象验证功能，以提高测试的效率。

006．测试的实施

单体测试包含debug、SourceReview、白盒测试、黑盒测试几种方式，在项目中，debug和SourceReview一般由开发组来完成，的测试组以黑盒测试方法进行单体测试为多。

单体测试的重点在于网罗性，是不是全部功能，全部的代码都经过了验证。单体测试的重点在于边界、异常、以及接口部分。结合测试主要是模仿需求设计测试用例验证功能的正确性。

在单体测试阶段，测试人员一般既是测试的设计者，也是测试的实施者，主要验证功能的正确性以及程序是否对错误情况作出了识别。单体测试是以数据库确认为重点，要确认数据操作是否正确，对数据库的确认有以下两个方面：

1）满足条件的情况下，是否触发了数据操作，并且操作正确

2）不满足条件的情况下，是否没有触发数据操作

在测试过程中，往往对上面的第二点会有遗漏，只关心了数据更新是否正确，而忽略了相反的情况。

在异常case的测试中，除了要check数据没有被操作过，画面上是否显示了相应的报错信息之外，还应该确认log输出是否正确，特别是在batch类型的测试中，会对log输出作出严格的要求。

测试人员在测试的过程中需要将式样问题和bug及时纪录下来，如果遇到式样有疑问的地方，请避免与开发人员交流，而应该直接填写QA票向设计人员确认，发现程序的错误应该及时地将bug登陆到bug管理系统中去，并且跟踪bug的对应情况，及时确认关闭。

在验证bug时需要进行回归测试，除了确认bug已经被正确修改之外，还需要确认相关功能的正确性，以免开发人员在对应bug或者式样变更过程中改出新的问题。

如果你具备测试人员应有的素质，加上对式样的正确理解，掌握测试的基本方法，那么bug会很难在你的眼皮下溜走。

007．测试过程中的变更管理

在测试启动之前，测试经理或者测试组应该密切关注开发过程，跟随开发进度计划的变更调整测试策略，测试之前的式样变更一般直需要变更测试用例。

测试启动的时候，测试人员一定要使用CCB制定版本的式样书或者测试用例，记录好式样书或测试用例的版本号，对此时版本上开发人员没有对应的式样变更做好相应的记录。在测试过程中，测试人员要密切注意式样变更的情况，将式样变更做好记录和管理（可以使用QAMS工具来管理式样变更），确认开发人员的对应情况。验证式样变更的时候，测试人员进行分析，式样变更的影响面，哪些画面哪些功能需要再验证，然后重新测试。

测试完成后的式样变更管理由测试经理安排由原来的测试人员各自负责还是安排专门的测试人员负责已经测试完了功能的式样变更的验证。

008．如何填写QA票和bug票

测试人员需要通过填写QA票和bug票分别向设计人员确认式样，向开发人员指明需要修改的地方。无论是QA票还是bug票都应该表达得简洁明了、通俗易懂。

在写QA票向设计人员确认式样问题的时候，要注意以下几个方面：

1）文档已经要说明清楚：你需要确认的式样问题在哪本设计书上。

2）提出的式样问题一定是经过自己考虑的，在提问的时候尽可能地提出自己的意见供设计人员参考。

3）如果没有得到满意的回复的情况下，应该再次提问知道问题解决为止。

4）如果问题比较紧急影响了你的测试进度需要设计人员尽快回复的话，也请提出你希望他回复的日期。

在写bug票的时候需要注意以下几个方面：

1）要讲错误的现象和正确的结果分别描述清楚。

2）某种特定条件下出现的bug，请写明操作手顺，以便开发人员在开发环境中能够再现。

3）正确的区分bug和式样变更，以减少与开发人员之间的矛盾。

4）识别bug的紧急度，如果影响测试正常进行的bug，需要设为紧急，会要求开发人员尽快对应。

009．文档管理工具(cvs)的使用

公司内部统一使用cvs来管理式样书，通过cvs来上传下载文档。Cvs的具体使用手册在

\\\\run-public\\Public\\UserGuide\\WinCVSUserGuide.doc

010．bug管理工具（QAMS）的使用

bug一般用专门的bug管理工具来进行管理，也有使用excel来管理的情况。

下面就使用QAMS提出质问票和BUG票的方法做一些简单的说明：

说明中采用的是内网登录，网址是：http://portal/QAMS/ITF0210_Init.do

或者http://portal/QAMS/

登录的网址是：https://www.it-forest.co.jp/QAMS/ITF0110_Init.do

1.登录http://portal/QAMS/ITF0210_Init.do

在ユーザー名一栏输入自己hoperun-domain的用户名，在パスワード一栏输入自己hoperun-domain的密码。（如图1、以“黄素英”为例）

（图1）

2.进入QAMS主菜单画面，选择プロジェクト的名称，然后在“ドキュメント一覧”里选择“課題·質問”或者“障害管理”。如是“課題·質問”则填写的是质问票，如是“障害管理”则将填写BUG票。（如图2）

（图2）

3.进入“課題·質問”画面以后，点击“新規追加” （如图3）。

（图3）

4.进入质问票追加画面以后，先在“表題”一栏填写质问票的标题名称，然后在“カテゴリ情報”栏里面选择“優先度”、“影響度”等项目。“添付資料”一栏为添加附件专用。

双击“起票”下方的内容的空白处，等待输入框的出现。（如图4）

（图4）

5.输入框出现后，在输入框内输入质问票的内容，然后点击“入力”按钮。（如图5）

“備考”栏跟上一步同样操作。

（图5）

6.选择“備考”栏下方的“Owner(アサイン先)”中的人名，质问票是开给谁的就选择谁的名字。然后点击“登録更新”按钮。（如图6）

（图6）

7.如果在第2步操作的时候进入的是“障害管理”，接下来的操作与3、4、5、6步基本相同。

只是在“起票”栏须填写“障害内容”和“予想結果”两项。（如图7）

（图7）

8.“カテゴリ情報”栏的“優先度”、“影響度”等，如不选择系统将默认选中第一个。

“備考”栏可以不填。

由于“Onで通知メールを送信します”前面的勾是默认选中的，所以系统会默认每一次QAMS的操作对方都会收到一封mail通知。

9.在问题一览画面已经对应完了的bug，验收这一栏会显示「検収待ち」,点击他会进入bug详细画面登陆确认结果

10.点击画面上部的菜单栏的「表示条件設定」link，会迁到表示条件设定画面，可以对你想要显示的项目、顺序、颜色等进行设置。