软件测试入门手册.doc

软件测试入门手册前言本手册是针对想学习软件测试，却万法不得入门的朋友编写的，如若已有部分基础朋友，可以自行忽略。不管你是在校学生，还是已工作转行学习软件测试的，如果你是零基础，那么就请你静下心来，好好的看完这本手册，它能给你一些帮助。首先，你要思考一下，你为什么要学习软件测试？这个问题应该是见仁见智的，但最根本的应该都是为了找个好工作，能更好的生活。那么，如果你也是这样，那么从现在开始，就别浪费时间，好好的学习软件测试的基础吧。那么这个时候，很多朋友会说，我不知道怎么入手，很迷茫，也很着急，所以到处找资料，问前辈，然而网上找的资料往往不是我所急需的，所以很苦恼。现在，我在这里告诉大家，摆在你面前的虽然不是完全是你所想要的东西，但是应该能给你触动，让你对软件测试更有兴趣，从而能很好的进行学习，直至入职成功。最后，想告诉大家的是，如果你不是心血来潮的三分钟热度，那么有这么好的环境，你真的应该好好学习一下，不然真的就辜负了群主跟大家的一番心意了。目录（按住Ctrl键可以点击跟踪目录）1、什么是软件测试？32、软件测试的常见误区33、 软件测试的目的和原则73.1、软件测试的目的73.2、软件测试的原则84、软件测试的基本流程105、软件测试分为哪些方式？115.1、软件测试的分类115.2、各分类的介绍126、 怎么编写测试用例？156.1、测试用例的组成元素156.2、测试用例的设计技巧167、 测试的方法有哪些?177.1、测试方法简介177.2、测试方法详情178、 怎么提一个高质量的BUG？208.1、Bug的高质量208.2、BUG的提出211、什么是软件测试？软件测试的经典定义是： 在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。现在抛开那些所谓的定义，我们扪心自问一下，什么是软件测试？有人说，软件测试就是找Bug；有人说，软件测试是为了保证软件产品的质量；有人说，软件测试，呃.我不知道。那么，如果让我来定义软件测试的话，我会说软件测试就是想尽一切方法来提高软件产品质量的操作过程。那么，随着软件测试的发展，慢慢的大家总结了许多的方法和规律，然后大家再开发出各种测试的工具，直至今天软件测试的蓬勃发展。2、软件测试的常见误区 现在，我们来扫清大家对软件测试的一些常见的误区。2.1软件测试和插件开发是测试人员的事情，与程序员无关:开发和测试是相辅相成的过程，需要软件测试人员、程序员和系统分析师等保持密切的联系，需要更多的交流和协调，以便提高测试效率。另外，对于单元测试主要应该由程序员完成，必要时测试人员可以帮助设计测试样例。对于测试中发现的软件错误，很多需要程序员通过修改编码才能修复。程序员可以通过有目的的分析软件错误的类型。2.2软件测试很简单：如果你这么想，那么请别去做测试，如果你做了，你也做不长久。软件测试有其自身的测试理论、方法、与设计，有时也对软件测试人员的，测试设计能力、编程能力、沟通能力、协调能力、以及细致严谨的一个挑战。2.3测试就是为了找到BUG：很多人最初都是这样的看法，千万要小心。如果你只是为了找到BUG，那这项工作将变得枯燥无味。2.4测试人员和开发人员从来都是死对头：我以前发起过一个倡议：我们讨论的时候不要用他们(开发人员)和我们(测试人员)，而是统一用咱们(开发人员和测试人员本来就是一起的)。如果测试人员能与开发人员成为朋友，你会发现，生活是多么美好，在我所在的企业中，测试人员和开发人员关系非常融洽，互相尊重，对大家的工作能力和技术表示肯定。2.5自动化测试太难：有的人一进公司就想做自动化，觉得它有难度，有挑战。我说你如果做不好手工测试，你同样做不好自动化，手工测试才是基础。而另外还有一部分人一说到自动化便望而生畏，认为这个东西太难了，不想碰(特别是很多女生，就有这个心理)。其实大可不必这样想，其实自动化测试的难点不在于其技术，而在于其实施，你如何有效地利用好手头已有的资源，开展自动化测试，将投入产出比最优化。2.6手工测试太没挑战：什么都不说了，能把它做好的人没几个，你认为手工测试没挑战吗？虽然每次版本我们都经过了细致的测试，但每次发布上线，我还记得大家紧张而又急迫的样子。2.7大量的重复性的工作很乏味：于是大家学得测试这份工作不好玩儿，特别一些男生，特别一些开发人员，从来都瞧不起做测试的，觉得这玩意儿太没劲。我想说的是，要掌握方法，要学会创新，任何东西都有它的特点，你如果总觉得成天在做重复性的工作，那么请静下心来想想，怎么能让它不重复(事情本身是死的，人是活的)，是否可以考虑自动化测试，是否可以通过脚本把重复工作给计算机来处理。2.8白盒测试是开发人员干的事：一个合格的测试人员必须掌握白盒测试，理解其中的原理。不管什么样的测试，都必须要有测试人员的思维才能做好，白盒测试有着其测试理论与技术，完全可以有专职的白盒测试人员进行，避免开发人员自己测试自己的程序。2.9女生适合做测试：在早些年，可能女生做测试的比例较多，但现在仔细分析。软件测试的要求相比早些年，随着软件测试中国内的快速发展，要求已经明显提升了很多，有较多的开发人员转入测试，并且，做自动化测试和性能测试的，目前男生比较多，在技术掌握方面，较多的技术往往在男生身上，女生未必适合做测试，女生在测试行业也面临男生的挑战，男生同样能把测试做好，且做得更加专业。2.10测试就是给开发擦屁股的：这句话，我真实地听人说过，一模一样的话语，就在前几周与一位开发培训师闲聊的过程中，他便是这么说的，我便开玩笑地说，某些开发人员的程序实在写得烂，必须纠正，测试人员永远要站在客户的角度来想问题，相反，是客户在驱动着软件的进展与成型。测试人员就应该扮演这样的角色，在大部分时候，要驱动开发人员完成软件的功能，驱动他们做改变。2.11我做开发可能不行，做测试吧：这个观点特别适应于应届毕业生，在以前面试的过程中，有一部分人就是觉得我代码写不好，所以入行做测试，还有一部分人稍微明白一点的，是觉得自己在开发方面没什么优势，主动给自己定位做测试工作。其实测试要掌握的技能远比开发多得多，至少面要广得多，要做一个好的测试人员，远比做一个开发人员难得多，如果不想测试行业成为骨干，只是打酱油，好吧，近几年内，你不会开发，暂时还不会失业。2.12功能性测试掩盖了可用性测试的必要:测试人员甚至我们的设计人员，开发人员都不太注重可用性(usability)方面的设计和测试。我们往往只在意功能性或者性能方面的测试，而忽略了用户体验，即使谈不上用户体验，哪怕是方便使用也行，这些方面往往从软件需求，设计一开始就没怎么考虑。到后来，用户使用的时候便是边用边骂娘，幸好，大部分互联网公司对用户体验这块非常重视。希望大家在进入软件测试这一行以前，能对测试有一个更深入的认识。3、 软件测试的目的和原则3.1、软件测试的目的 基于不同的立场，存在着两种完全不同的测试目的。从用户的角度出发，普遍希望通过软件测试暴露软件中隐藏的错误和缺陷，以考虑是否可以接受该产品。而从软件开发者的角度出发，则希望测试成为表明软件产品中不存在错误的过程，验证该软件已正确地实现了用户的要求，确立人们对软件质量的信心。因此，他们会选择那些导致程序失效概率小的测试用例，回避那些易于暴露程序错误的测试用例。同时，也不会着意去检测、排除程序中可能包含的副作用。显然，这样的测试对完善和提高软件质量毫无价值。因为在程序中往往存在着许多预料不到的问题，可能会被疏漏，许多隐藏的错误只有在特定的环境下才可能暴露出来。如果不把着眼点放在尽可能查找错误这样一个基础上，这些隐藏的错误和缺陷就查不出来，会遗留到运行阶段中去。如果站在用户的角度，替他们设想，就应当把测试活动的目标对准揭露程序中存在的错误。在选取测试用例时，考虑那些易于发现程序错误的数据。有鉴于此，Grenford JMyers就软件测试目的提出以下观点：（1）测试是程序的执行过程，目的在于发现错误；（2）一个好的测试用例在于能发现至今未发现的错误；（3）一个成功的测试是发现了至今未发现的错误的测试。测试的目标是想以最少的时间和人力找出软件中潜在的各种错误和缺陷。如果成功地实施了测试，就能够发现软件中的错误。测试的附带收获是，它能够证明软件的功能和性能与需求说明相符。此外，实施测试收集到的测试结果数据为可靠性分析提供了依据。3.2、软件测试的原则3.2.1软件测试应该从项目开始就进行（越早进行越好） 由于原始问题的复杂性，软件的复杂性和抽象性，软件开发各个阶段工作的多样性，以及参加开发各种层次人员之间工作的配合关系等因素，使得开发的每个环节都可能产生错误。所以不应把软件测试仅仅看作是软件开发的一个独立阶段，而应当把它贯穿到软件开发的各个阶段中。坚持在软件开发的各个阶段的技术评审，这样才能在开发过程中尽早发现和预防错误，把出现的错误克服在早期，杜绝某些隐患，提高软件质量。3.2.2测试用例应由输入数据和预期输出结果这两部分组成。 测试以前应当根据测试的要求，来选择在测试过程中使用的测试用例。测试用例主要用来检验程序员编制的程序，因此不但需要测试的输入数据，而且需要针对这些输入数据的预期输出结果。如果对测试输入数据没有给出预期的程序输出结果，那么就缺少了检验实测结果的基准，就有可能把一个似是而非的错误结果当成正确结果。3.2.3程序员应避免检查自己的程序（第三方原则）测试工作需要严格的作风，客观的态度和冷静的情绪。人们常由于各种原因具有一种不愿否定自己工作的心理，认为揭露自己程序中的问题总不是一件愉快的事。这一心理状态就成为测试自己程序的障碍。另外，程序员对软件规格说明理解错误而引入的错误则更难发现。如果由别人来测试程序员编写的程序，可能会更客观，更有效，并更容易取得成功。要注意的是，这点不能与程序的调试相混淆，调试由程序员自己来做可能更有效。3.2.4软件测试是证伪而不是证真 测试的目的是为了发现产品存在的错误，而不是为了验证产品功能是否真的达到要求。3.2.5充分注意测试中的群集现象（二八原则）测试时不要以为找到了几个错误问题就已解决，不需继续测试了。经验表明，测试后程序中残存的错误数目与该程序中已发现的错误数目或检错率成正比。根据这个规律，应当对错误群集的程序段进行重点测试，以提高测试投资的效益。在所测程序段中，若发现错误数目多，则残存错误数目也比较多。这种错误群集性现象，已为许多程序的测试实践所证实。3.2.6严格执行测试计划，排除测试的随意性。测试计划应包括：所测软件的功能，输入和输出，测试内容，各项测试的进度安排，资源要求，测试资料，测试工具，测试用例的选择，测试的控制方式和过程，系统组装方式，跟踪规程，调试规程，以及回归测试的规定等以及评价标准。对于测试计划，要明确规定，不要随意解释。3.2.7应当对每一个测试结果做全面检查。这是一条最明显的原则，但常常被忽视。有些错误的征兆在输出实测结果时已经明显地出现了，但是如果不仔细地全面地检查测试结果，就会使这些错误被遗漏掉。所以必须对预期的输出结果明确定义，对实测的结果仔细分析检查，抓住征候，暴露错误。3.2.8妥善保存测试过程中的各种文档测试过程中的文档有测试计划，测试用例，出错统计和最终分析报告。保存各文档很有必要，这样就能很清楚的查找到各阶段的问题和项目的保密性要求。4、软件测试的基本流程4.1需求分析阶段： 只要就是对业务的学习，分析需求点。4.2测试计划阶段： 测试组长就要根据项目需求开始编写测试计划，其中包括人员，软件硬件资源，测试点，集成顺序，进度安排和风险识别等内容。4.3测试设计阶段： 测试方案一般由对需求很熟的高资深的测试工程师设计，测试方案要求根据需求文档上的每个需求点设计出包括需求点简介，测试思路和详细测试方法三部分的方案。测试方案编写完成后也需要进行评审。4.4测试方案阶段： 主要是对测试用例和规程的设计。测试用例是根据测试方案来编写的，通过测试方案阶段，测试人员对整个系统需求有了详细的理解。这时开始编写用例才能保证用例的可执行和对需求的覆盖。测试用例需要包括测试项，用例级别，预置条件，操作步骤和预期结果。其中操作步骤和预期结果需要编写详细和明确。测试用例应该覆盖测试方案，而测试方案又覆盖了测试需求点，这样才能保证客户需求不遗漏。同样，测试用例也需要评审。4.5测试执行阶段： 执行测试用例，及时提交有质量的Bug和测试日报，测试报告等相关文档。5、软件测试分为哪些方式？5.1、软件测试的分类按阶段分：单元测试、集成测试、系统测试、验收测试按是否运行程序分：静态测试、动态测试按内部结构（是否查看代码）分：黑盒测试、灰盒测试、黑盒测试按性能分：功能测试、性能测试其他测试：回归测试、冒烟测试、随机测试、压力测试、负载测试、5.2、各分类的介绍5.2.1单元测试： 是指对软件中的最小可测试单元进行检查和验证。单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。5.2.2集成测试： 也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求（如根据结构图）组装成为子系统或系统，进行集成测试。实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。一些局部反映不出来的问题，在全局上很可能暴露出来。5.2.3系统测试： 是针对整个产品系统进行的测试，目的是验证系统是否满足了需求规格的定义，找出与需求规格不符或与之矛盾的地方，从而提出更加完善的方案。5.2.4验收测试： 在软件产品完成了单元测试、集成测试和系统测试之后，产品发布之前所进行的软件测试活动。它是技术测试的最后一个阶段，也称为交付测试。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。5.2.5静态测试： 是指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错。5.2.6动态测试： 是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率、正确性和健壮性等性能。这种方法由三部分组成：构造测试用例、执行程序、分析程序的输出结果。5.2.7黑盒测试： 黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。5.2.8灰盒测试： 灰盒测试，确实是介于二者之间的，可以这样理解，灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒的方法。5.2.9白盒测试： 白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。5.2.10功能测试： 就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。5.2.11性能测试： 过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。5.2.12回归测试： 是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。5.2.13冒烟测试： 是对软件基本的功能进行测试，测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本的功能正常，保证软件系统能跑的起来,可以进行后续的正式测试工作，如果最基本的测试都有问题，就直接打回开发部了，所以正式交付测试的版本必须首先通过冒烟测试的考验。5.2.14随机测试： 要是根据测试者的经验对软件进行功能和性能抽查。5.2.15压力测试： 压力测试是模拟实际应用的软硬件环境及用户使用过程的系统负荷，长时间或超大负荷地运行测试软件，来测试被测系统的性能、可靠性、稳定性等。简单的说，压力测试就是检验持续抗压的能力。5.2.16负载测试： 通过测试系统在资源超负荷情况下的表现，以发现设计上的错误或验证系统的负载能力。简单的说，就是检验极限的承受力。6、 怎么编写测试用例？6.1、测试用例的组成元素 从软件测试的根本意义上来说，用例的主要组成元素就是输入条件和输出结果。就是说你输入什么样的条件，能达相对应的结果，那么就是对的，不然就是有问题的，即Bug。 从测试用例的表现形式上说，用例最主要的部分是：用例说明、预置条件、操作步骤、预期结果、实际结果；还有其他的部分：需求编号、用例编号、用例状态、测试人员等。6.2、测试用例的设计技巧 当自己接受到一个设计测试用例的任务时，如何对一个庞大的模块进行设计测试用例呢？这时候测试用例的划分就显的尤为重要。我总结的测试用例的划分有三种：1）按照功能划分2）按照路径（业务流程）划分3）按照功能和路径（业务流程）划分目前我用的方法是第三种。第一种按照功能划分，优点是最简捷，但其缺点是：对于复杂操作的程序模块，其各功能的实施是相互影响，紧密相关，环环相扣的。如果没有严密的逻辑分析，很容易产生遗漏。第二种纯粹按照路径划分也容易造成对功能点的遗漏。所以我基本都是大方向用功能块的划分来走，然后再结合上路径（业务流程）的划分方法。7、 测试的方法有哪些?7.1、测试方法简介7.1.1、常用方法：边界值法、等价类划分法、因果图法、状态迁移图法、错误推测法7.1.2、其他方法对比法、判定表法、正交法、7.2、测试方法详情7.2.1等价类划分等价类划分主要适用于单个输入条件，输入为数值型的情况，如果输入规定了输入区间，可划分出一个有效等价类，两个无效等价类;如果输入只规定了输入范围，可划分出一个有效等价类，一个无效等价类。7.2.2边界值边界值方法也是适用于单个输入条件的情况，输入类型可以数值、字符等，要测试的边界包括上点、下点、离点。7.2.3错误推测法错误推测法主要是测试设计人员的测试经验相关,测试经验不同,设计出来的测试用例也区别很大。7.2.4因果图法因果图方法考虑输入的组合，特别适用于多个输入条件相关有关联又相互约束的情况。设计步骤：1)罗列出输入与输出;2)根据输入与输出画出因果图;3)标出约束跟限制;4)把因果图转化成判定表;5)根据判定表的每一列设计测试用例。7.2.5判定表驱动法判定表适合于解决多个逻辑条件的组合。将各种逻辑的组合罗列出来，避免遗漏。不能表达重复的操作。判定表包括条件桩、条件项、动作桩、动作项。条件桩：列出所有条件，次序无关;条件项：列出所对应条件的所有可能情况下的取值;动作桩：列出可能采取的操作，次序无关;动作项：列出条件项各种取值情况下采取的操作。设计步骤：1)确定规则个数，条件及各条件取值的组合;2)列出条件桩、动作桩;3)列出条件项;4)列出动作项;5)初始化判定表;6)规则简化、合并。7.2.6状态迁移图法 状态迁移图法主要关注在测试状态转移的正确性上面。对于一个有限状态机，通过测试验证其在给定的条件内是否能够产生需要的状态变化，有没有不可达的状态和非法的状态，可能不可能产生非法的状态转移等。通过构造能导致状态迁移的事件，来测试状态之间的转换。状态迁移图的步骤：1）画出状态迁移图；2）列出状态事件表；3）得到状态转换树；4）推出测试路径；5）根据测试路径编写测试用例。简单的举个例子，比如淘宝大家应该都很熟悉，那么从你选择好商品加入购物车，那么就是待支付状态；你进入购物车支付之后，就是待发货状态；卖家发货之后，就是待收获状态。8、 怎么提一个高质量的BUG？8.1、Bug的高质量8.1.1唯一性：一个bug说明一个问题，如果有能力的话，一个bug说明一类问题，这一类问题一定要能判断出是一条代码错误