测试理论整理

黑白盒测试的区别？

⿊盒测试：通过测试来检测每个功能是否符合需求，不考虑
程序内部的逻辑结构
⽩盒测试也称结构测试或逻辑驱动测试，必须知道软件内部
⼯作过程，通过测试来检测软件内部是否按照需求、设计正
常运⾏

1. 软件测试方法：白盒测试、黑盒测试、灰盒测试、静态测试、动态测试

2. 白盒测试：是一种测试用例设计方法，在这里盒子指的是被测试的软件，白盒，顾名思义即盒子是可视的，你可以清楚盒子内部的东西以及里面是如何运作的，因此白盒测试需要你对系统内部的结构和工作原理有一个清楚的了解，并且基于这个知识来设计你的用例。

白盒测试技术一般可被分为静态分析和动态分析两类技术。

静态分析主要有：控制流分析技术、数据流分析技术、信息流分析技术。

动态分析主要有：逻辑覆盖率测试(分支测试、路径测试等)，程序插装等。

白盒测试优点：迫使测试人员去仔细的思考软件的实现；可以检测代码中的每条分支和路径；揭示隐藏在代码中的错误；对代码的测试比较彻底；最优化。

白盒测试缺点：昂贵；无法检测代码中遗漏的路径和数据敏感性错误；不验证规格的正确性。

3. 黑盒测试又叫功能测试，这是因为在黑盒测试中主要关注被测软件的功能实现，而不是内部逻辑。在黑盒测试中，被测对象的内部结构，运作情况对测试人员是不可见的，测试人员对被测产品的验证主要是根据其规格，验证其与规格的一致性。

在绝大多数没有用户参与的黑盒测试中，最常见的测试有：功能性测试、容量测试、安全性测试、负载测试、恢复性测试、标杆测试、稳定性测试、可靠性测试等。

4. 灰盒测试：白盒测试和黑盒测试往往不是决然分开的，一般在白盒测试中交叉使用黑盒测试的方法，在黑盒测试中交叉使用白盒测试的方法。灰盒测试就是这类界于白盒测试和黑盒测试之间的测试。

最常见的灰盒测试是集成测试。

5. 静态测试：是一种不通过执行程序而进行测试的技术。它的关键功能是检查软件的表示和描述是否一致，没有冲突或者没有歧义。

6. 动态测试：包含了程序在受控的环境下使用特定的期望结果进行正式的运行。它显示了一个系统在检查状态下是正确还是不正确。

单元测试属于白盒测试范畴；集成测试属于灰盒测试范畴；系统测试属于黑盒测试范畴。

二. 单元测试

1. 概念：单元测试(Unit Testing)是对软件基本组成单元进行的测试，如函数或是一个类的方法。这里的单元，就是软件设计的最小单位。

单元测试的两个步骤：人工静态检查法与动态执行跟踪法。

人工静态检查是测试的第一步，这个阶段工作主要是保证代码算法的逻辑正确性（尽量通过人工检查发现代码的逻辑错误）、清晰性、规范性、一致性、算法高效性，并尽可能的发现程序中没有发现的错误。

第二步是通过设计测试用例，执行待测程序来跟踪比较实际结果与预期结果来发现错误。

2. 人工检查：

(1)、检查算法的逻辑正确性：确定所编写的代码算法、数据结构定义（如：队列、堆栈等）是否实现了模块或方法所要求的功能。

(2)、模块接口的正确性检查：确定形式参数个数、数据类型、顺序是否正确；确定返回值类型及返回值的正确性。

(3)、输入参数有没有作正确性检查：如果没有作正确性检查，确定该参数是否的确无需做参数正确性检查，否则请添加上参数的正确性检查。

(4)、调用其他方法接口的正确性：检查实参类型正确与否、传入的参数值正确与否、个数正确与否，特别是具有多态的方法。返回值正确与否，有没有误解返回值所表示的意思。最好对每个被调用的方法的返回值用显示代码作正确性检查，如果被调用方法出现异常或错误程序应该给予反馈，并添加适当的出错处理代码。

(5)、出错处理：模块代码要求能预见出错的条件，并设置适当的出错处理，以便一旦程序出错时，能对出错程序重做安排，保证其逻辑的正确性，这种出错处理应当是模块功能的一部分。若出现下列情况之一，则表明模块的错误处理功能包含有错误或缺陷：出错的描述难以理解；出错的描述不足以对错误定位，不足以确定出错的原因；显示的错误信息与实际的错误原因不符；对错误条件的处理不正确；在对错误进行处理之前，错误条件已经引起系统的干预等。

(6)、保证表达式、SQL语句的正确性：检查所编写的SQL语句的语法、逻辑的正确性。对表达式应该保证不含二义性，对于容易产生歧义的表达式或运算符优先级（如：<、=、 >、 &&、||、 、 --等）可以采用扩号“（）”运算符避免二义性，这样一方面能够保证代码的正确可靠，同时也能够提高代码的可读性。

(7)、检查常量或全局变量使用的正确性：确定所使用的常量或全局变量的取值和数值、数据类型；保证常量每次引用同它的取值、数值和类型的一致性。

(8)、表示符定义的规范一致性：保证变量命名能够见名知意，并且简洁但不宜过长或过短、规范、容易记忆、最好能够拼读。并尽量保证用相同的表示符代表相同功能，不要将不同的功能用相同的表示符表示；更不要用相同的表示符代表不同的功能意义。

(9)、程序风格的一致性、规范性：代码必须能保证符合企业规范，保证所有成员的代码风格一致、规范、工整。例如对数组做循环，不要一会儿采用下标变量从下到上的方式（如:for(i=0;i ;i<10)），一会儿又采用从上到下的方式(如:for(i=10;i–;i>0))；应该尽量采用统一的方式，或则统一从下到上，或则统一从上到下。建议采用for循环和While循环，不要采用do{}while循环等。

(10)、检查程序中使用到的神秘数字是否采用了表示符定义：神秘的数字包括各种常数、数组的大小、字符位置、变换因子以及程序中出现的其他以文字形式写出的数值。在程序源代码里，一个具有原本形式的数对其本身的重要性或作用没提供任何指示性信息，它们也导致程序难以理解和修改。对于这类神秘数字必须采用相应的标量来表示；如果该数字在整个系统中都可能使用到务必将它定义为全局常量；如果该神秘数字在一个类中使用可将其定义为类的属性（Attribute）,如果该神秘数字只在一个方法中出现务必将其定义为局部变量或常量。

(11)、检查代码是否可以优化、算法效率是否最高：如：SQL语句是否可以优化，是否可以用1条SQL语句代替程序中的多条SQL语句的功能，循环是否必要，循环中的语句是否可以抽出到循环之外等。

(12)、检查您的程序是否清晰简洁容易理解：注意：冗长的程序并不一定不是清晰的。

(13)、检查方法内部注释是否完整：是否清晰简洁；是否正确的反映了代码的功能，错误的注释比没有注释更糟；是否做了多余的注释；对于简单的一看就懂的代码没有必要注释。

(14)、检查注释文档是否完整：对包、类、属性、方法功能、参数、返回值的注释是否正确且容易理解；是否会落了或多了某个参数的注释，参数类型是否正确，参数的限定值是否正确。特别是对于形式参数与返回值中关于神秘数值的注释，如：类型参数 应该指出 1.代表什么，2.代表什么，3.代表什么等。对于返回结果集(Result Set)的注释，应该注释结果集中包含那些字段及字段类型、字段顺序等。

3. 动态执行跟踪：动态执行测试通常分为黑盒测试与白盒测试。对于单元测试来说主要应该采用白盒测试法对每个模块的内部作跟踪检查测试。对于单元白盒测试，应该对程序模块进行如下检查：(1)、对模块内所有独立的执行路径至少测试一次；(2)、对所有的逻辑判定，取“真”与“假”的两种情况都至少执行一次；(3)、在循环的边界和运行界限内执行循环体；(4)、测试内部数据的有效性等等。

4. 单元测试的目的：在于发现各模块内部可能存在的各种错误，主要是基于白盒测试。

单元测试的目的主要有3方面：验证单元代码和详细设计文档的一致性；跟踪详细设计文档中设计的实现，发现详细设计文档中存在的错误；发现在编码过程中引入的错误。

5. 单元的常见错误：(1)、单元接口；(2)、局部数据结构；(3)、独立路径；(4)、出错处理；(5)、边界条件。

6. 单元测试策略：有三种，独立的单元测试策略，自顶向下的单元测试策略和自底向上的单元测试策略。

独立的测试策略：不考虑每个模块与其他模块之间的关系，为每个模块设计桩模块和驱动模块。每个模块进行独立的单元测试。

自顶向下的测试策略：先对最顶层的单元进行测试，把顶层所调用的单元做成桩模块。其次对第二层进行测试，使用上面已测试的单元做驱动模块。如此类推直到测试完所有模块。

自底向上测试：先对模块调用层次图上最低层的模块进行单元测试，模拟调用该模块的模块做驱动模块。然后再对上面一层做单元测试，用下面已被测试过的模块做桩模块。依次类推，直到测试完所有模块。

7. 单元测试过程：计划(测什么)、设计(测试方案、策略)、实现(写测试用例、代码)、执行(测试报告)四个阶段。

8. 单元测试的原则：(1)、对全新的代码或修改过的代码进行单元测试；(2)、单元测试根据单元测试计划和方案进行，排除测试的随意性；(3)、必须保证单元测试计划、单元测试方案、单元测试用例等经过评审；(4)、当测试用例的测试结果与预期结果不一致时，单元测试的执行人员需如实记录实际的测试结果；(5)、只有当测试计划中的结束标准达到时，单元测试才能结束；(6)、对被测试单元需达到的一定的代码覆盖率要求。

三. 测试用例

1. 简介：测试用例(Test Case)是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。也指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。

不同类别的软件，测试用例是不同的。

2. 概述：测试用例构成了设计和制定测试过程的基础。测试的“深度”与测试用例的数量成比例。由于每个测试用例反映不同的场景、条件或经由产品的事件流，因而，随着测试用例数量的增加，你对产品质量和测试流程也就越有信心。

判断测试是否完全的一个主要评测方法是基于需求的覆盖，而这又是以确定、实施和/或执行的测试用例的数量为依据的。

测试工作量与测试用例的数量成比例。最佳方案是为每个测试需求至少编制两个测试用例。一个测试用例用于证明该需求已经满足，通常称作正面测试用例。另一个测试用例反映某个无法接受、反常或意外的条件或数据，用于论证只有在所需条件下才能够满足该需求，这个测试用例称作负面测试用例。

3. 设计方法：

(1)、白盒技术：白盒测试是结构测试，所以被测对象基本上是源程序，以程序的内部逻辑为基础设计测试用例。

白盒测试的测试用例设计：一般采用逻辑覆盖法和基本路径法进行设计。

逻辑覆盖是以程序内部的逻辑结构为基础的测试用例设计技术，这一方法要求测试人员对程序的逻辑结构有清楚的了解。逻辑覆盖可分为：语句覆盖、判定覆盖、条件覆盖、判定-条件覆盖、条件组合覆盖与路径覆盖。

语句覆盖：在测试时，首先设计若干个测试用例，然后运行被测程序，使程序中的每个可执行语句至少执行一次。

判定覆盖法：在测试时，首先设计若干个测试用例，然后运行被测程序，使得程序中的每个判断的取真分支和取假分支至少经历一次，即判断的真假值均曾被满足。

条件覆盖法：在测试时，首先设计若干个测试用例，然后运行被测程序，要使每个判断中每个条件的可能取值至少满足一次。

判定条件覆盖法：在测试时，首先设计若干个测试用例，然后运行被测程序，使得判断中每个条件的所有可能至少出现一次，并且每个判断本身的判定结果至少出现一次。

路径覆盖法：在测试时，首先设计若干个测试用例，然后运行被测程序，要求覆盖程序中所有可能的路径。

基本路径覆盖法：是在程序控制流图的基础上，通过分析控制结构的环路复杂性，导出基本可执行路径集合，设计测试用例的方法。该方法把覆盖的路径数压缩到一定限度内，程序中的循环体最多只执行一次。设计出的测试用例要保证在测试中，程序的每一个可执行语句至少执行一次。

循环路径测试：基本路径覆盖法将循环限制在最多一次，这样虽然大大降低了需要覆盖的路径的条数，但对循环的测试却不充分了，因此还需要对循环路径进行测试。循环路径测试包含，简单循环的测试和嵌套循环的测试。

每一种覆盖方法都有其优缺点。通常在设计测试用例时应该根据代码模块的复杂度，选择覆盖方法。一般的代码的复杂度与测试用例设计的复杂度成正比。因此，设计人员必须做到模块或方法功能的单一性、高内聚性，使得方法或函数代码尽可能的简单；这样将可大大提高测试用例设计的容易度，提高测试用例的覆盖程度。

基本路径测试法是在程序控制流图的基础上，通过分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例的方法。设计出的测试用例要保证在测试中程序的每个可执行语句至少执行一次。基本路径测试法包括以下5个方面：(1)、程序的控制流图：描述程序控制流的一种图示方法；(2)、程序环境复杂性：McCabe复杂性度量；从程序的环路复杂性可导出程序基本路径集合中的独立路径条数，这是确定程序中每个可执行语句至少执行依次所必须的测试用例数目的上界；(3)、导出测试用例；(4)、准备测试用例，确保基本路径集中的每一条路径的执行；(5)、图形矩阵：是在基本路径测试中起辅助作用的软件工具，利用它可以实现自动地确定一个基本路径集。

另外，对于测试用例的选择除了满足所选择的覆盖程度（或覆盖标准）外还需要尽可能的采用边界值分析法、错误推测法等常用地设计方法。采用边界值分析法设计合理的输入条件与不合理的输入条件；条件边界测试用例应该包括输入参数的边界与条件边界（if,while，for，switch ,SQL Where子句等）。错误推测法，列举出程序中所有可能的错误和容易发生错误的特殊情况，根据它们选择测试用例；在编码、单元测试阶段可以发现很多常见的错误和疑似错误，对于这些错误应该作重点测试，并设计相应的测试用例。

(2)、黑盒技术：等价划分类、边界值分析、错误推测、因果图、综合策略

4. 测试类设计：一个模块或一个方法（Method）并不是一个独立的程序，在考虑测试它时要同时考虑它和外界的联系，用些辅助模块去模拟与所测模块相联系的其他模块。这些辅助模块分为两种：

(1)、驱动模块（driver）：相当于所测模块的主程序。它接收测试数据，把这些数据传送给所测模块，最后再输出实际测试结果；

(2)、桩模块（stub）:用于代替所测模块调用的子模块。桩模块可以做少量的数据操作，不需要把子模块所有功能都带进来，但不容许什么事情也不做。

打桩：一般在做单元或集成测试时，如果某个程序单元的某条语句，需要调用的一个外部函数还没有设计、编码、调试完成的话，可以只让它简单地返回几个支持测试用例的值就可以了，这种状态的外部函数一般就叫做“打桩”。

所测模块与它相关的驱动模块及桩模块共同构成了一个“测试环境”。

驱动模块和桩模块的编写会给测试带来额外的开销。因为它们在软件交付时并不作为产品的一部分一同交付，而且它们的编写需要一定的工作量。特别是桩模块，不能只简单地给出“曾经进入”的信息。为了能够正确的测试软件，桩模块可能需要模拟实际子模块的功能，这样桩模块的建立就不是很轻松了。

编写桩模块是困难费时的，其实也是完全可以避免编写桩模块的；只需在项目进度管理时将实际桩模块的代码编写工作安排在被测模块前编写即可。而且这样可以提高测试工作的效率，提高实际桩模块的测试频率从而更有效的保证产品的质量。但是，为了保证能够向上一层级提供稳定可靠的实际桩模块，为后续模块测试打下良好的基础，驱动模块还是必不可少的。

对于每一个包或子系统我们可以根据所编写的测试用例来编写一个测试模块类来做驱动模块，用于测试包中所有的待测试模块。而最好不要在每个类中用一个测试函数的方法，来测试跟踪类中所有的方法。这样的好处在于：(1)、能够同时测试包中所有的方法或模块，也可以方便的测试跟踪指定的模块或方法；(2)、能够联合使用所有测试用例对同一段代码执行测试，发现问题；(3)、便以回归测试，当某个模块作了修改之后，只要执行测试类就可以执行所有被测的模块或方法。这样不但能够方便得检查、跟踪所修改的代码，而且能够检查出修改对包内相关模块或方法所造成的影响，使修改引进的错误得以及时发现；(4)、复用测试方法，使测试单元保持持久性，并可以用既有的测试来编写相关测试；(5)、将测试代码与产品代码分开，使代码更清晰、简洁；提高测试代码与被测代码的可维护性。

5. 跟踪调试：跟踪调试不但是深入测试代码的最佳方法，而且也是程序调试发现错误根源的有利工具。测试类设计完成后，最好能借助代码排错工具来跟踪调试待测代码段以深入的检查代码的逻辑错误。现有的代码开发工具（如:JBuilder）一般都集成了这类排错工具。排错工具一般由执行控制程序、执行状态查询程序、跟踪程序组成。执行控制程序包括断点定义、断点撤销、单步执行、断点执行、条件执行等功能。执行状态查询程序包括寄存器、堆栈状态、变量、代码等与程序相关的各种状态信息的查询。跟踪程序用以跟踪程序执行过程中所经历的事件序列（如：分支、子程序调用等）。程序员可通过对程序执行过程中各种状态的判别进行程序错误的识别、定位及改正。

对于模块的单元跟踪调试最好能够做到：每次修改被测模块后，都将所有测试用例跟踪执行一遍以排除所有可能出现或引进的错误。在时间有限的情况下也必须调用驱动模块对所有的测试用例执行一次，并对出现错误或异常的测试用例跟踪执行一次，以发现问题的根源。

排错过程往往是一个艰苦的过程，特别是那种算法复杂、调用子模块较多的模块，对于错误的定位来说并不是件容易的事情。尽管排错不是一门好学的技术（有时人们更愿意称之为艺术），但还是有若干行之有效的方法和策略，下面介绍几种排错时应该采用的方法策略：(1)、断点设置，设置断点对源程序实行断点跟踪将能够大大提高排错的效率。通常断点的设置除了根据经验与错误信息来设置外，还应重点考虑以下几种类行的语句：A、函数调用语句。子函数的调用语句是测试的重点，一方面由于在调用子函数时可能引起接口引用错误，另一方面可能是子函数本身的错误；B、判定转移/循环语句。判定语句常常会由于边界值与比较优先级等问题引起错误或失效而作出错误的转移。因此，对于判定转移/循环语句也是一个重要的测试点；C、SQL语句。对于数据库的应用程序来说，SQL语句常常会在模块中占比较重要的业务逻辑，而且比较复杂。因此，它也属于比较容易出现错误的语句；D、复杂算法段。出错的概率常与算法的复杂度成正比。所以越复杂的算法越需要作重点跟踪，如递归、回朔等算法。(2)、可疑变量查看，在跟踪执行状态下当程序停止在某条语句时可查看变量的当前值和对象的当前属性。通过对比这些变量当前值与预期值可以轻松的定位程序问题根源；(3)、SQL语句执行检查，在跟踪执行或运行状态下将疑似错误的SQL语句打印出来，重新在数据库SQL查询分析器（如：Oracle SQL Plus）中跟踪执行可以较高效的检查纠正SQL语句错误；(4)、注意群集现象，经验表明测试后程序中残存的错误数目与该程序中已发现的错误数目或检错率成正比。根据这个规律，应当对错误群集的程序段进行重点测试，以提高测试投资的效益。如果发现某一代码段似乎比其他程序模块更多的错误倾向时，则应当花费较多的时间和代价测试这个程序模块。

6. 测试用例设计的基本原则：(1)、一个好的测试用例在于能够发现至今没有发现的错误；(2)、测试用例应由测试输入数据和与之对应的预期输出结果这两部分组成；(3)、在测试用例设计时，应当包含合理的输入条件和不合理的输入条件。

7. 测试用例的具体做法：

(1)、测试用例文档：编写测试用例文档应有文档模板，须符合内部的规范要求。

(2)、测试用例的设置：按功能设置用例、按路径设置用例、按功能、路径混合模式设置用例；

(3)、设计测试用例：测试用例可以分为基本事件、备选事件和异常事件。

四. 白盒测试

1. 白盒测试一般包括以下几项：

(1)、目的：保证程序创建的类与接口的完整与正确，以及程序模块单独正常运行。保证局部模块功能完备性，运行正确性与稳定性。
(2)、测试项：所要测试的类。
(3)、测试依据：A、需求规格说明书、用例描述清单；B、设计文档；C、编码规范；D、开发命名标准。
(4)、通过的准则：创建的类、接口、方法、属性应与《设计文档》保持一致；程序的各种命名、注释、代码行的格式等应符合《程序开发命名标准》和《编码规范》；程序模块能独立稳定运行。
(5)、测试环境配置：A、测试工具；B、软件环境。

2.测试步骤：

(1)、配置好测试环境；

(2)、编写测试用例；

(3)、静态测试、走查代码；

(4)、动态测试；

(5)、确定问题属性：分为四类，错误、缺陷、失效、故障。

错误是指计算值、观测值、测量值之间，或条件与真值之间，不符合规定的或理论上的正确值或条件。

缺陷是指与期望值或特征值的偏差。

故障是指功能部件不能执行所要求的功能。故障可能由错误、缺陷或失效引起。

失效是指功能部件执行其功能的能力丧失，系统或系统部件丧失了在规定限度内执行所要求功能的能力。

(6)、确定问题类别；

(7)、填写测试报告。

3. 白盒测试和单元测试的区别：(1)、测试目的：一个是测试程序的整体逻辑，另一个是测试程序中一个独立的模块；(2)、通常的执行人员不一样：白盒一般由专门的白盒测试人员完成，单元测试一般由程序员自己完成。

测试方式不同

黑盒测试：功能测试，是通过测试来检测每个功能是否能正常使用
白盒测试：俗称：结构测试\透明盒测试\逻辑驱动测试\基于代码的测试

测试目的不同

黑盒测试：把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构盒特性的情况下，在程序接口进行测试，只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息
白盒测试：通过检查软件内部的逻辑结构，对软件种的逻辑路径进行覆盖测试。在程序不同地方设立监测点，检查程序的状态，以确定实际运行状态与预期状态是否一致。

测试原则不同

黑盒测试：以用户角度，从输入数据与输出数据的对应关系出发进行测试的。很明显，如果外部特性本身设计有问题或规格说明的规定有误，用黑盒测试方法是发现不了的。
白盒测试：一个模块种的所有独立路径至少被测一次。所有逻辑值均需测试true和false两种情况

手工与自动化的优缺点？

• ⼿⼯测试
传统的测试⽅法，由测试⼈员⼿⼯编写测试⽤例
缺点在于测试⼯作量⼤，重复多，回归测试难以实现

• ⾃动化测试
利⽤软件测试⼯具或代码⾃动实现全部或部分测试⼯作：管
理、设计、执⾏和报告
⾃动测试节省⼤量的测试开销，并能够完成⼀些⼿⼯测试⽆
法实现的测试

自动化测试的优缺点

优点：

• 自动化测试可帮助你找到比人工测试人员更多的错误。
• 由于测试过程的大部分是自动化的，因此你可以快速高效地进行测试。
• 可以记录自动化过程。这使你可以重用和执行相同类型的测试操作。
• 自动化测试是使用软件工具进行的，因此与人工测试中的人员不同，它不会疲劳和疲劳。
• 它可以快速，准确地提供测试结果，因此可以轻松提高生产率。 自动化测试支持各种应用。
• 由于自动化测试工具，你永远都不会忘记检查最小的单元，因此可以增加测试范围。

缺点：

1. 没有人为因素，就很难深入了解UI的视觉方面，例如颜色，字体，大小，对比度或按钮大小。
2. 运行自动化测试的工具可能很昂贵，这可能会增加测试项目的成本。
3. 自动化测试工具还不是万无一失的。每个自动化工具都有其局限性，从而缩小了自动化范围。
4. 调试测试脚本是自动化测试中的另一个主要问题。测试维护成本很高。

手工测试的优缺点

优点：

• 获得快速准确的视觉反馈。
• 由于您无需花费预算购买自动化工具和流程，因此成本较低。
• 人的判断力和直觉总是有益于手工要素。
• 在测试较小的更改时，自动化测试将需要编码，这可能很耗时。虽然您可以即时进行手动测试。

缺点：

• 不太可靠的测试方法，因为它是由人工执行的。因此，它总是容易出现错误和错误。
• 无法记录手动测试过程，因此无法重复使用手动测试。
• 在这种测试方法中，某些任务很难手动执行，这可能需要软件测试阶段的额外时间。

查询软件测试策略的各质量特性的定义

1、软件质量的定义

软件质量是软件特性的综合，指软件满足规定或潜在用户需求的能力，其主要从内部质量、外部质量、使用质量和过程质量这四个方面来衡量。

2、软件质量模型

测度与度量：在软件质量中用于测量的一种量化的标度和方法即为测度，而名词的度量即用来指测量的结果。

1. McCail质量模型

这是由McCall和他的同事在早期提出的软件质量模型，指出了影响软件质量因素的分类，其主要集中在以下三个方面：

操作特性(产品运行)
承受可改变的能力(产品修订)
新环境适应的能力(产品变迁)
具体的模型图如下(来源<软件评测师教程>)：

2. Boehm质量模型

Boehm及其同事提出了如下的分层的软件质量模型，除了包含用户期望与需求之外，还提出了McCall模型中没有的硬件特性。

Boehm模型始于软件的整体效用，从从系统交付后涉及不同类型用户的考虑；用户分为三种，分别为初识用户、将软件移植到其他环境下使用的用户、维护系统的程序员。这三种用户都希望整个系统是可靠的。Boehm模型反映了对软件质量的理解，即软件做了用户要它做的，有效地使用系统资源、易于用户学习和使用、易于测试和维护。

3. ISO9126质量模型

ISO9126软件质量模型是一个分层的质量模型，有6个影响质量的特性，模型中说明了质量特性及其子特性的关系。
• 测试⽤例的良好设计
• 测试⽤例的设计是整个软件测试⼯作的核⼼
• 测试⽤例反映对被测对象的质量要求，决定对测试对象的质量评估
• 测试⼯作的管理
• 尤其是对包含多个⼦系统的⼤型软件系统，其测试⼯作涉及⼤量⼈
⼒和物⼒，有效的测试⼯作管理是保证有效测试⼯作的必要前提
• 测试环境的建⽴
• 测试环境应该与实际测试环境⼀致

标准的软件质量模型分为三个层次，第一层是6个影响软件质量的主要因素(即下面的质量的特性)，在标准中称为质量特性，而每个特性又可以通过第二层的若干个子特性来进行测量，而第二层的每个子特性在测量时又要定义并实施若干个度量。
此模型的出发点是使软件满足用户明确或潜在的需求，这六个特性最大可能的涵盖了其他早期质量模型中的所有因素，并且彼此交叉最小。

3、软件质量的特性

软件的质量特性主要有六个大的特性，其中每个特性中又有一些子特性，分别如下所述。

1. 功能性

定义：软件在指定条件下使用时，满足用户明确或隐含需求的能力。
子特性：

适合性：软件为指定的任务和用户目标提供一组合适功能的能力
互操作性：软件与一个或更多的规定系统进行交互的能力。
安全性：软件保护信息和数据的能力，以使未授权的人员或系统不能阅读或修改这些信息和数据，而不拒绝受权
依从性：软件遵循与各种特性相关的标准、约定或法规以及类似规定的能力。这些标准要考虑国际标准。
准确性

2. 可靠性

定义：软件在指定条件下使用时，维护规定的性能级别的能力。
子特性：

成熟性：软件为避免由软件中错误而导致失效的能力。
容错性：在软件出现故障或者违反指定接口的情况下，软件维持规定的性能级别的能力。
易恢复性：在失效发生的情况下，软件重建规定的性能级别并恢复受直接影响的数据的能力。

3. 易用性

子特性：

易理解性：软件使用户能理解软件是否合适，以及如何能将软件用于特定的任务和使用环境的能力。
易学性：软件使用户能操作和控制它的能力。
易操作性：软件使用户能操作和控制它的能力。

4. 效率

定义：在规定条件下，相对于所用资源的数量，软件可提供适当性能的能力。
子特性：

时间特性：在规定条件下，软件执行其功能时，提供适当的响应和处理时间以及吞吐率的能力，即完成用户
资源利用性：在规定条件下，软件执行其功能时，使用合适的资源数量和类别的能力。

5. 可维护性

易分析性
易更改性
稳定性
易测试性

6. 可移植性

适应性
易安装性
一致性
易替换性

软件开发的生命周期有哪些环节？

软件开发生命周期
软件开发生命周期定义：
软件从定义到消亡所经历的过程。

软件开发生命周期一共包含五个阶段：

分析阶段：
软件开发首先需要进行需求调研和分析完善的需求是软件开发项目成败的重要因素， 提炼所收集的用户需求，建立完整的分析模型

设计阶段：
软件设计可以分为两个阶段概要设计和详细设计。

概要设计：给出软件模块结构，用软件结构图表示

详细设计的首要任务是设计模块的程序流程，算法和数据结构

实现阶段：
软件编码是指把软件设计转换成计算机可以接受的程序

测试阶段：
测试软件的各个组成模块，然后，在把各个模块集成起来，测试整个产品的功能和性能

维护阶段：
维护是指已经完成对软件的研制工作并交付使用后，对软件产品所进行的错误改正，适应环境变化和增强功能等软件工程修订

软件测试各阶段测试的重点是什么？

• 测试⽤例的良好设计
• 测试⽤例的设计是整个软件测试⼯作的核⼼
• 测试⽤例反映对被测对象的质量要求，决定对测试对象的质量评估
• 测试⼯作的管理
• 尤其是对包含多个⼦系统的⼤型软件系统，其测试⼯作涉及⼤量⼈
⼒和物⼒，有效的测试⼯作管理是保证有效测试⼯作的必要前提
• 测试环境的建⽴
• 测试环境应该与实际测试环境⼀致

（一）需求分析：

“需求分析”阶段：这个阶段主要是对业务的学习，包括：阅读需求，理解需求，分析需求点，参与需求评审会议，评审需求是否合理。

（二）制定测试计划：

这个阶段的主要任务就是通过参考“软件需求规格说明书”以及“项目总体计划”，来编写测试计划。

所编写的测试计划的内容包括：

① 测试范围（依据需求文档）

② 进度安排（时间进度、流程进度）

③ 人力、物力的分配

（人员有哪些、都有哪些业务点、以及相对应的资源，对于这些的分配）

④ 对于整体测试策略的制定

⑤ 对于风险评估与规避措施要有一个制定

（三）设计测试用例、编写测试用例

通过参考需求文档（原型图）、概要设计、详细设计等文档，来编写测试用例，用例编写完成之后会进行评审。

（四）实施测试（执行测试用例）

实施测试主要包括以下几个部分：

① 搭建相应的测试环境

② 执行冒烟测试（预测试）

③ 进行正式的测试

④ 回归测试

（五）bug的管理，提交缺陷报告

这个阶段主要是将执行测试过程中发现的bug提交到bug管理平台上，最后可能需要提交缺陷报告。

（六）生成测试总结和报告

在这个阶段需要给出测试报告，并确认是否可以上线。

课上知识点

引起软件缺陷的原因
• ⼈们本身容易犯错误、时间的压⼒、复杂的代码、复杂的系
统架构、技术的⾰新、或者系统之间的配合⼯作等。
• 失效也可能是由于环境条件引起的
• ⽬前引起缺陷最⼤的原因是需求不明确。

什么是软件测试
• ⼴义的概念
• 指软件⽣存周期中所有的检查、评审和确认⼯作，其中包
括了对分析、设计阶段，以及完成开发后维护阶段的各类
⽂档、代码的审查和确认
• 狭义概念
• 识别软件缺陷的过程，即实际结果与预期结果的不⼀致

• 软件测试通常包括验证(verification)和确认(validation)：
• 验证指保证软件正确的实现了某⼀特定功能的⼀系列活动
• 确认指的是保证软件的实现满⾜了⽤户需求的⼀系列活动

软件测试原则-⾎的教训
• Good-enough: ⼀种权衡投⼊/产出⽐的原则
• 保证测试的覆盖程度，但穷举测试是不可能的
• 所有的测试都应追溯到⽤户需求
• 越早测试越好，测试过程与开发过程应是相结合的
• 测试的规模由⼩⽽⼤，从单元测试到系统测试
• 为了尽可能地发现错误，应该由ᇿ⽴的第三⽅来测试
• 不能为了便于测试擅⾃修改程序
• 既应该测试软件该做什么也应该测试软件不该做什么

• Bug的80-20原则
• 在分析、设计、实现阶段的复审和测试⼯作能够发现和避免80%的Bug
• ⽽系统测试⼜能找出其余Bug中的80%
• 最后的5%的Bug可能只 有在⽤户的⼤范围、⻓时间使⽤后才会曝露出来




fiddler

通过阻断修改返回的json 注册请求你们名字邮箱—中断（rule-breakpoint—before requests）—修改请求—linda@qq.com—成功—中断响应(rule-breakpoint-after response)-修改响应换成—你们名字邮箱。

阻断请求 修改邮箱 重新发送请求

通过阻断评论的请求 修改后 重新发送 刷新后 看到评论的邮箱是修改后的 不是请求原网页的邮箱

通过AutoResponder 实现两个网址链接 在访问时实现映射