软件测试作业指导书

软件测试作业指导书测试作业指导书基础篇3001什么是软件缺陷（BUG）3002影响软件质量的原因3003提高软件质量的方法4004软件测试的目标与定义4005软件测试中的原则5006如何成为一个好的软件测试员7007软件测试的阶段划分9008测试用例的设计方法901测试用例的特征902测试用例的设计原则903等价类划分方法1004边界值分析方法1105因果图方法1506判定表驱动分析方法1607功能图分析方法2008场景设计方法2109测试用例设计综合策略2110测试用例的设计步骤22009软件测试的基本方式2201黑盒测试2202白盒测试2203静态测试2204动态测试22010软件测试的基本方法2201过测试和失败测试2202等价类划分2203数据测试2304状态测试2305其他黑盒测试方法25实践篇26001测试流程图26002测试准备27003如何做好式样理解27004关于测试用例的设计27005测试数据的准备28006测试的实施29007测试过程中的变更管理30008如何填写QA票和BUG票30009文档管理工具CVS的使用30010BUG管理工具（QAMS）的使用30基础篇001什么是软件缺陷（BUG）1软件未达到产品说明书表明的功能计算器的产品说明书可能声称它能够准确无误的进行加、减、乘、除运算。如果按下加号（）键，结果什么反应也没有，根据该条规则，这就是个软件缺陷。假如得到错误的答案，根据规则，同样是软件缺陷2软件出现了产品说明书指明不会出现的错误产品说明书可能声称计算机永远不会崩溃、锁死或者停止反应。假如狂敲键盘会使计算器停止接受输入，根据本条规则，这是一个软件缺陷3软件功能超出产品说明书指明范围假如我们发现除了加减乘除之外计算器还可以求品方根，而这一功能哪儿都没提。干劲十足的程序员加入这项功能可能因为觉得这是一项创举，根据本条规则，这是软件缺陷。4软件未达到产品说明书虽未指出但应达到的目标这条规则可能让人感觉有些矛盾和奇怪，但是这样是为了抓住产品说明书上遗漏之处。在测试计算器时，会发现电池没电会导致计算机不正确。没有人会考虑应如何应付这种情况，使计算机反应正常，而盲目以为电池永远充足了电。测试要持续进行到电池完全没电，是少要看到电力不足的迹象。产品说明书指出电力不足无法正确计算，但未指出会怎样，根据本条规则，这是软件缺陷。5软件测试人员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。本条规则是全面的。软件测试人员是第1个真正使用软件的人。如果发现某些地方不对劲，无论什么原因，都要认定为软件缺陷。对于计算器来说，可能觉得按键太小；也许等号（）键的位置放得不好按；也许显示屏在亮光下很难以看清，根据本条规则，这些都是缺陷。注意每一个使用过一些软件的人都会对如何改进有一些要求和意见。要编写令所有用户都喜欢的软件是不可能的。作为软件测试人员，在运用第5条测试规则时应记住这一点。最好能全面地客观评价，做到合情合理。002影响软件质量的原因影响软件质量的原因很多，具体地说，主要有以下几点1用户原因需求不清；二义性2产品说明书没有产品说明书；说明书不够全面、经常更改3设计方案与产品说明书是一样的，片面、易变4交流不够、交流上有误解或者根本不进行交流在应用应该做什么或不应该做什么的细节（应用的需求）不清晰的情况下进行开发5软件复杂性图形用户界面（GUI），客户/服务器结构，分布式应用，数据通信，超大型关系型数据库以及庞大的系统规模，使得软件及系统的复杂性呈指数增长，没有现代化开发经验的人很难理解它。6程序设计错误跟所有的人一样，程序员也会出错7时间压力软件项目的日程表很难做到准确，很多时候需要预计和猜测。当最终期限迫近和关键时刻到来之际，错误也就跟着来了。8自负自负的人更喜欢说“没问题”；“这件事很容易”；“几个小时我就能拿出来”，太多不切实际的“没问题”结果只能是引入错误。9代码文档贫乏贫乏或者差劲的文档使得代码维护和修改变的异常艰辛，其结果是带来许多错误。事实上，在许多机构并不鼓励其程序员为代码编写文档，也不鼓励程序员将代码写得清晰和容易理解，相反他们认为少写文档可以更快的进行编码，无法理解的代码更易于工作的保密（“写的艰难必定读的痛苦”）10软件开发工具可视化工具，类库，编译器，脚本工具，等等，他们常常会将自身的错误带到应用软件中。就像我们所知道的，没有良好的工程化作为基础，使用面向对象的技术只会使项目变得更复杂。003提高软件质量的方法1软件工程化2CMM能力成熟度模型CAPABILITYMATURITYMODELFORSOFTWARE3软件测试004软件测试的目标与定义软件测试的目的决定了如何去组织测试，在项目的不同阶段，测试的目的也不相同。1在UTUNITTEST阶段，测试的目的是为了尽可能多地找出错误，那么UT阶段测试就应该直接针对软件比较复杂的部分或是以前出错比较多的位置。在此阶段，可以引用GRENFORDJMYERS在THEARTOFSOFTWARETESTING一书中的观点软件测试是为了发现错误而执行程序的过程；测试是为了证明程序有错，而不是证明程序无错误。好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案；成功的测试是发现了至今为止尚未发现的错误的测试。这种观点可以提醒人们测试要以查找错误为中心，而不是为了演示软件的正确功能。但是仅凭字面意思理解这一观点可能会产生误导，认为发现错误是软件测试的唯一目的，查找不出错误的测试就是没有价值的，事实并非如此。首先，测试并不仅仅是为了要找出错误。通过分析错误产生的原因和错误的分布特征，可以帮助项目管理者发现当前所采用的软件过程的缺陷，以便改进。同时，这种分析也能帮助我们设计出有针对性地检测方法，改善测试的有效性。其次，没有发现错误的测试也是有价值的，完整的测试是评定测试质量的一种方法。详细而严谨的可靠性增长模型可以证明这一点。2SI测试阶段的目的是为了给最终用户提供具有一定可信度的质量评价，那么测试就应该直接针对在实际应用中会经常用到的商业假设。在这一阶段不仅要验证UT测试的结果，检测出软件本身的缺陷，更重要的是要站在用户的角度找出我们在软件开发过程中的不合理的地方，最终的目的是让用户满意。对于软件产品的不同角色来说，他们的测试目的也是不同的。用户通过测试来暴露错误开发者通过测试来证明自己开发的产品不存在错误测试人员找出软件缺陷，尽可能早一些，并确保其得以修复测试从狭义上说，就是凭借测试用例TESTCASE运行程序发现错误的过程。005软件测试中的原则1完全测试程序是不可能的在软件测试的过程中，想要进行完全测试，找出所有软件缺陷，并使软件臻于完美，实际上这是不可能的，即使最简单的程序也不行，主要有如下4个原因输入量太大输出结果太多软件实现途径太多软件说明书没有客观标准。从不同的角度看，软件缺陷的标准不同。2软件测试是有风险的行为正因为完全测试程序是不可能的，那么在测试的过程中必定会对某些你认为是重复的或者没必要的或者为了节省时间，而将其提出，如果决定不去测试所有的情况，这就是选择了风险。既然不可能做完全测试，那么这种风险就是无法避免的了。软件测试员要学会的一个主要原则就是如何把无边无际的可能减少到可以控制的范围，以及如何针对风险制定做出明智抉择，去粗存精。3测试无法显示潜伏的软件缺陷软件测试工作与防疫员的工作极为相似，可以报告已发现的软件缺陷，却无法报告潜伏的软件缺陷。你可以进行测试，查找并报告软件缺陷，但是不能保证软件缺陷全部找到。唯一的方法是继续测试，可能还会找到一些。4找到的软件缺陷越多，就说明软件缺陷越多通常，软件测试员在没有找到软件缺陷之前拼命地琢磨。找到一个之后，就会接二连三地找到更多。其中的原因是程序员怠倦。和我们大家一样，程序员也要休假。编写一天代码还不错，第二天就会烦躁不安了。一个软件缺陷很可能是泄露附近有更多软件缺陷的信号。程序员往往犯同样的错误。每个人都有偏好。一个程序员总是反复犯下自己容易犯的错误。某些软件缺陷实际上是大灾难的征兆。软件的设计或者体系常常会出现基础问题。软件测试员可能会发现某些软件缺陷开始似乎毫无关联的，但是最后才知道它们是由一个极其严重的原因造成的。但是，如果无论如何也找不出软件缺陷，那么也有可能是软件经过精心编制，确实存在极少软件缺陷5反复使用相同的测试会使软件具有抵抗力在测试过程中你会发现经过几个回合的测试之后，该发现的软件缺陷都被发现了，在测试下去也不会有新的发现了。这时，软件测试员，需要采用其他新的方法，对程序的不同部分进行测试，以找出更多软件缺陷。6并非所有的软件缺陷都能修复这要求软件测试员能过进行良好的判断，搞清楚在什么情况下不能追求完美。项目小组需要对每一个软件缺陷进行取舍，根据风险决定哪些需要修复，哪些不要。不需要修复软件缺陷的主要原因有没有足够的时间。在任何一个项目中，通常是软件功能较多，而代码编写人员和软件测试人员较少，而且在项目进度中没有为编制和测试留出足够的空间。常常会在不可更改的交付期限内，必须按时完成软件。不算真正的软件缺陷。在某些特殊场合，错误理解、测试错误或者说明书变更会把软件缺陷当作附加功能来对待。修复的风险太大。修复一个软件缺陷可能导致其他软件缺陷出现；在紧迫的产品发布进度压力之外，修改软件将冒很大的风险。不去理睬未知软件缺陷，以避免出现未知新缺陷的做法也许是安全之道。不值得修复。不常出现的软件缺陷和在不常用功能中出现的软件缺陷可以放过；可以躲过和用户有办法预防或避免的软件缺陷通常不用修复。这些都要归结为商业风险决策。7要尽早、不断地进行测试测试是无穷近的，而测试的时间又是有限的，所以我们要尽早地开始测试，尽快地找出软件缺陷，以便降低修复成本。在几个回合的测试以后，没有再检测出BUG，不能说程序没有错误，只能说还没有找到错误，没有人能够找出程序中所有的错误，没有任何软件产品是完美无错的，我们能做的只是不断地进行测试。8测试用例可以帮助我们有效地进行测试“好的测试用例是极可能发现迄今为止尚未发现的错误的测试用例”，可见测试用例对在软件测试中占有很重要的地位，它可以弥补软件测试员在测试时的遗漏、偏差以及经验上的不足，给我们的测试提供依据。同时测试用例也是作为向用户提供的质量保证的重要依据之一。9程序员应避免测试自己的程序“自负”是影响程序质量的原因之一，程序员测试的目的是证明程序的无错，基于这种心理，程序员是很难测试自己程序中的BUG的。另一方面，程序员在理解式样的时候难免会有偏差，如果测试自己的程序是很难找出这些偏差的。10正确和错误的测试软件测试员测试的目的是要找出软件潜在的错误和缺陷，这里的错误和缺陷不仅指软件本身的错误，还要检测软件对错误的处理能力，所以我们在测试的时候既要准备正确的数据也要准备错误的数据，一般来说测试错误的CASE比正确的CASE要多很多。11群集现象在测试的过程中，会发现某些画面BUG特别多，某些功能会出现BUG群集的现象，所以要重视这些群集现象，并且及时的采取对策。12杜绝随意性软件测试时一定要有测试依据的，测试人员不能按照自己的想法凭空想象来评判对错。软件测试员是客户的眼睛，是第一次看到软件的人，代表客户说话，应力求完美。但力求完美的同时，最好能全面地客观评价，做到合情合理。006如何成为一个好的软件测试员现在，大多数公司把软件测试视为技术工程专业工作。他们意识到在项目组中培训软件测试员，并在开发过程中早期投入工作可以制造出质量更优的软件。下面是大多数软件测试员应具备的素质沟通能力。一名理想的测试者必须能够同测试涉及到的所有人进行沟通，具有与技术（开发者）和非技术人员（客户，管理人员）的交流能力。既要可以和用户谈得来，又能同开发人员说得上话，不幸的是这两类人没有共同语言。和用户谈话的重点必须放在系统可以正确地处理什么和不可以处理什么上。而和开发者谈相同的信息时，就必须将这些活重新组织以另一种方式表达出来，测试小组的成员必须能够同等地同用户和开发者沟通。技术能力。就总体言，开发人员对那些不懂技术的人持一种轻视的态度。一旦测试小组的某个成员作出了一个错误0的断定，那么他们的可信度就会立刻被传扬了出去。一个测试者必须既明白被测软件系统的概念又要会使用工程中的那些工具。要做到这一点需要有几年以上的编程经验，前期的开发经验可以帮助对软件开发过程有较深入的理解，从开发人员的角度正确的评价测试者，简化自动测试工具编程的学习曲线。自信心。开发者指责测试者出了错是常有的事，测试者必须对自己的观点有足够的自信心。如果容许别人对自己指东指西，就不能完成什么更多的事情了。因为开发和测试的立场不同，面对问题的时候测试人员要有自信坚持自己的观点，而不能轻信开发人员的说法。外交能力。当你告诉某人他出了错时，就必须使用一些外交方法。机智老练和外交手法有助于维护与开发人员的协作关系，测试者在告诉开发者他的软件有错误时，也同样需要一定的外交手腕。如果采取的方法过于强硬，对测试者来说，在以后和开发部门的合作方面就相当于“赢了战争却输了战役”。幽默感。在遇到狡辩的情况下，一个幽默的批评将是很有帮助的。很强的记忆力。一个理想的测试者应该有能力将以前曾经遇到过的类似的错误从记忆深处挖掘出来，这一能力在测试过程中的价值是无法衡量的。因为许多新出现的问题和我们已经发现的问题相差无几。耐心。一些质量保证工作需要难以置信的耐心。有时你需要花费惊人的时间去分离、识别和分派一个错误。这个工作是那些坐不住的人无法完成的。怀疑精神。可以预料，开发者会尽他们最大的努力将所有的错误解释过去。测式者必须听每个人的说明，但他必须保持怀疑直到他自己看过以后。自我督促。干测试工作很容易使你变得懒散。只有那些具有自我督促能力的人才能够使自己每天正常地工作。洞察力。一个好的测试工程师具有“测试是为了破坏”的观点，捕获用户观点的能力，强烈的质量追求，对细节的关注能力。应用的高风险区的判断能力以便将有限的测试针对重点环节。不懈努力。软件测试员总是不停尝试。他们可能会碰到瞬间即逝或者难以重建的软件缺陷。他们不会心存侥幸，而是尽一切可能去寻找。创造性。测试显而易见的事实，那不是软件测试员。他们的工作是相处富有创意甚至超常的手段来寻找软件缺陷。追求完美。他们力求完美，但是知道某些无法企及时，不去苛求，而是尽力接近目标。判断准确。软件测试员要决定测试内容、测试时间，以及看到的问题是否算作真正的缺陷。说服力。软件测试员找出的软件缺陷有是被人认为不重要，不用修复。测试员要善于表达观点，表明软件缺陷为何必须修复，并通过实际演示力陈观点。软件测试员的一个基本素质是打破砂锅问到底。他们喜欢找出那些深藏不露的系统冲突。他们乐于处理最复杂的问题。他们外表上热衷于来回奔忙，追求尽善尽美。软件测试员的任务是检查和批评同事的工作，挑毛病，公布发现的问题。这样难免与项目组中的其他人员会产生摩擦，下面是保持小组成员和睦的建议早点找出软件缺陷。这是软件测试员的当然任务，但是不容易做到。在三个月之前而不是在产品即将发布前夕找出严重的软件缺陷，会产生更小的影响，更容易让人接受。控制情绪。诚然，软件测试员真心喜爱自己的工作，当发现严重的软件缺陷时乐不自胜。但是，如果兴冲冲地闯进程序员同事的房间告诉他程序中存在不可救药的软件缺陷，他不会高兴的。不要总是报告坏消息。假如意外发现某些代码没有软件缺陷，就大声宣扬。花一些时间找程序员聊聊天。如果总是报告坏消息，别人就会惟恐避之不及。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在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类。如输入值是学生成绩，范围是0100；机密第10页共377在输入条件规定了输入值的集合或者规定了”必须如何”的条件的情况下,可确立一个有效等价类和一个无效等价类；8在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类。9在规定了输入数据的一组值（假定N个）,并且程序要对每一个输入值分别处理的情况下,可确立N个有效等价类和一个无效等价类。例输入条件说明学历可为专科、本科、硕士、博士四种之一，则分别取这四种这四个值作为四个有效等价类，另外把四种学历之外的任何学历作为无效等价类。10在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）；11在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类。5设计测试用例在确立了等价类后,可建立等价类表,列出所有划分出的等价类输入条件有效等价类、无效等价类，然后从划分出的等价类中按以下三个原则设计测试用例1为每一个等价类规定一个唯一的编号；2设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖地有效等价类,重复这一步，直到所有的有效等价类都被覆盖为止；3设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步，直到所有的无效等价类都被覆盖为止。04边界值分析方法边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。1与等价划分的区别1边界值分析不是从某等价类中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件。2边界值分析不仅考虑输入条件，还要考虑输出空间产生的测试情况。2边界值分析方法的考虑长期的测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。使用边界值分析方法设计测试用例，首先应确定边界情况。通常输入和输出等价类的边界，就是应着重测试的边界情况。应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。3常见的边界值1对16BIT的整数而言32767和32768是边界2屏幕上光标在最左上、最右下位置3报表的第一行和最后一行4数组元素的第一个和最后一个5循环的第0次、第1次和倒数第2次、最后一次4边界值分析1边界值分析使用与等价类划分法相同的划分，只是边界值分析假定错误更多地存在于划分的边界上，因此在等价类的边界上以及两侧的情况设计测试用例。2等价类划分I可以考虑作出如下划分A、输入I0B、输出A0和BERRORII测试用例有两个A、输入4，输出2。对应于II和A。C、输入10，输出0和错误提示。对应于I和B。3边界值分析划分II的边界为0和最大正实数；划分I的边界为最小负实数和0。由此得到以下测试用例A、输入最小负实数B、输入绝对值很小的负数C、输入0D、输入绝对值很小的正数E、输入最大正实数4通常情况下，软件测试所包含的边界检验有几种类型数字、字符、位置、重量、大小、速度、方位、尺寸、空间等。5相应地，以上类型的边界值应该在最大/最小、首位/末位、上/下、最快/最慢、最高/最低、最短/最长、空/满等情况下。6利用边界值作为测试数据7内部边界值分析在多数情况下，边界值条件是基于应用程序的功能设计而需要考虑的因素，可以从软件的规格说明或常识中得到，也是最终用户可以很容易发现问题的。然而，在测试用例设计过程中，某些边界值条件是不需要呈现给用户的，或者说用户是很难注意到的，但同时确实属于检验范畴内的边界条件，称为内部边界值条件或子边界值条件。内部边界值条件主要有下面几种A数值的边界值检验计算机是基于二进制进行工作的，因此，软件的任何数值运算都有一定的范围限制。B字符的边界值检验在计算机软件中，字符也是很重要的表示元素，其中ASCII和UNICODE是常见的编码方式。下表中列出了一些常用字符对应的ASCII码值。C其它边界值检验5基于边界值分析方法选择测试用例的原则1如果输入条件规定了值的范围,则应取刚达到这个范围的边界的值,以及刚刚超越这个范围边界的值作为测试输入数据。例如，如果程序的规格说明中规定”重量在10公斤至50公斤范围内的邮件，其邮费计算公式为“。作为测试用例，我们应取10及50，还应取1001,4999,999及5001等。2如果输入条件规定了值的个数,则用最大个数,最小个数,比最小个数少一,比最大个数多一的数作为测试数据。比如，一个输入文件应包括1255个记录，则测试用例可取1和255，还应取0及256等。3将规则1）和2）应用于输出条件，即设计测试用例使输出值达到边界值及其左右的值。例如，某程序的规格说明要求计算出”每月保险金扣除额为0至116525元”，其测试用例可取000及116524、还可取一001及116526等。再如一程序属于情报检索系统，要求每次”最少显示1条、最多显示4条情报摘要”，这时我们应考虑的测试用例包括1和4，还应包括0和5等。4如果程序的规格说明给出的输入域或输出域是有序集合,则应选取集合的第一个元素和最后一个元素作为测试用例。5如果程序中使用了一个内部数据结构,则应当选择这个内部数据结构的边界上的值作为测试用例。6分析规格说明,找出其它可能的边界条件。错误推测法基于经验和直觉推测程序中所有可能存在的各种错误,从而有针对性的设计测试用例的方法。1错误推测方法的基本思想列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例。1例如,输入数据和输出数据为0的情况；输入表格为空格或输入表格只有一行。这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例。2例如，前面例子中成绩报告的程序，采用错误推测法还可补充设计一些测试用例IIIIIIIVV程序是否把空格作为回答在回答记录中混有标准答案记录除了标题记录外，还有一些的记录最后一个字符即不是2也不是3有两个学生的学号相同试题数是负数。3再如，测试一个对线性表（比如数组）进行排序的程序，可推测列出以下几项需要特别测试的情况III输入的线性表为空表；表中只含有一个元素；III输入表中所有元素已排好序；IV输入表已按逆序排好；V输入表中部分或全部元素相同05因果图方法是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。1因果图法产生的背景等价类划分法和边界值分析方法都是着重考虑输入条件，但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。这样虽然各种输入条件可能出错的情况已经测试到了，但多个输入条件组合起来可能出错的情况却被忽视了。如果在测试时必须考虑输入条件的各种组合，则可能的组合数目将是天文数字，因此必须考虑采用一种适合于描述多种条件的组合、相应产生多个动作的形式来进行测试用例的设计，这就需要利用因果图（逻辑模型）。2因果图介绍14种符号分别表示了规格说明中向4种因果关系。2因果图中使用了简单的逻辑符号，以直线联接左右结点。左结点表示输入状态（或称原因），右结点表示输出状态（或称结果）。3CI表示原因，通常置于图的左部；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“阅读指南”判定表3判定表通常由四个部分组成如下图所示。1条件桩（CONDITIONSTUB）列出了问题得所有条件。通常认为列出的条件的次序无关紧要。2动作桩（ACTIONSTUB）列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。3条件项（CONDITIONENTRY）列出针对它左列条件的取值。在所有可能情况下的真假值。4动作项（ACTIONENTRY）列出在条件项的各种取值情况下应该采取的动作。4规则及规则合并1规则任何一个条件组合的特定取值及其相应要执行的操作称为规则。在判定表中贯穿条件项和动作项的一列就是一条规则。显然,判定表中列出多少组条件取值,也就有多少条规则,既条件项和动作项有多少列。2化简就是规则合并有两条或多条规则具有相同的动作，并且其条件项之间存在着极为相似的关系。5规则及规则合并举例1如下图左端，两规则动作项一样，条件项类似，在1、2条件项分别取Y、N时，无论条件3取何值，都执行同一操作。即要执行的动作与条件3无关。于是可合并。“”表示与取值无关。2与上类似，下图中，无关条件项“”可包含其他条件项取值，具有相同动作的规则可合并。3化简后的读书指南判定表6判定表的建立步骤（根据软件规格说明）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如何做好式样理解式样是测试的依据，是判断程序是否正确的标准，所以测试人员对式样的把握直接影响到测试的效果。式样理解要做到以下两点式样理解包含所有的业务功能，功能没有遗漏。所有的业务功能都能够正确的理解。式样理解的内容熟悉式样书的目录结构。熟悉设