软件测试——工作业务流程

软件测试的工作流程

一、作为测试人员需要学习并了解业务，分析需求点

为什么测试人员需要参加需求分析就是进行测试需求分析的目的是什么/p>

把用户需求转化为功能需求：1）对测试范围进行度量 2）对处理分支进行度量 3）对需求业务的场景进行度量 4）明确其功能对应的输入、处理和输出 5）把隐式需求转变为明确
明确测试活动的五个要素：测试需求是什么、决定怎么测试、明确测试时间、确定测试人员、确定测试环境：测试中需要的技能、工具以及相应的背景知识、测试过程中可能遇到的风险等等。测试需求需要做到尽可能的详细明确，以避免测试遗漏和误解。

怎么进行测试需求分析/p>

场景分析
1）考虑场景的调用者：考虑每一个场景提供的服务是供哪些外部模块或者系统调用的，找出所有的调用者。调用前提，约束都要考虑。每一个调用都可以考虑成一个大的业务流程（一般和外部有交互的业务出错率比较大，需要重点关注）
2）考虑系统内部各个场景之间的：形成内部业务流程，需要分析每个场景之间的约束关系，执行条件，组织出各种业务流程图
挖掘隐形需求
这需要测试工程师的经验积累：1）常用的或者规定的业务流程 2）各个业务流程分支的遍历 3）明确规定不可使用的业务流程 4）没有明确规定但是应该不可使用的业务流程 5）其他异常或者不符合规定的操作

二、测试用例设计

如何进行测试用例的设计
编写测试用例之前，我们需要对项目的需求有清晰的了解，对要测试什么，按照什么顺序测试，覆盖哪些需求做到心中有数，作为测试用例的编写者不仅要了解常见的测试用例编写方法，同时需要了解被测软件的设计、功能规格说明、用户试用场景以及程序/模块的结构。
步骤
1）测试需求分析：从项目部拿到软件的需求规格说明书后，开始对项目的需求进行分析，通过自己的分析、理解，整理成为测试需求，清楚分析出被测对象具有哪些功能。明确测试用例中的测试集用例与需求的关系，即一个或多个测试用例集对应一个测试需求。
2）业务流程分析：分析完需求后，明确每一个功能的业务处理流程，不同的功能点作为业务的组合，以及项目的隐式需求。如遇到复杂的测试用例设计前，先画出软件的业务流程，从业务流程上，应得到以下信息：
A. 主流程是什么br> B. 条件备选流程是什么br> C. 数据流向是什么br> D. 关键的判断条件是什么br> 3）测试用例设计
完成以上两步则可以进行测试用例设计，功能测试用例，应尽量考虑边界、异常、性能的情况，以便发现更多的隐藏问题，设计测试用例的常见方法：等价类、边界值、因果图、判定表、状态迁移、正交实验、场景法、错误推断（注意：编写测试用例时，我们尽可能取的不应该是有效等价类而应该是无效等价类）
4）编写完成之后自我检查以及部门内部评审：
A. 测试用例本身的描述是否清晰，语言准确；是否存在二义性；
B. 测试用例内容是否完整，是否清晰的包含输入和预期输出的结果；测试步骤是否清晰；
C. 测试用例中使用的测试数据是否恰当、准确；
D. 测试用例是否具有指导性，是否能灵活的指导软件测试工程师通过测试用例发现更多缺陷，而不是限制他们的思维；
E. 是否考虑到测试用例执行的效率。对于不断重复执行的步骤，是否保证了验证点相同；或者测试用例的设计是否存在冗余性等。这些都可能导致测试用例执行效率低下；
F. 画出软件需求跟踪矩阵，验证测试用例是否完全覆盖了需求，验证测试用例的覆盖性；
G. 测试用例是否完全遵守了软件需求的规定。这一点其实有一些难做到，考虑到时间/成本的关系，应该视具体情况而定。
5）测试用例更新完善
测试用例编写完成之后要不断完善，如遇需求更改或功能新增时，测试用例必须配套修改更新，同时在测试过程中发现设计测试用例时考虑不周，需要对测试用例进行修改完善；在软件交付使用后客户反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成，也需要对测试用例进行完善。

三、测试用例执行过程

首先搭建测试环境，准备好测试数据，进行预测，预测通过之后，按照测试用例进入正式测试，有效的测试执行可以将测试用例发挥最大的价值。因此，测试用例规范执行有助于更好的发现代码中存在的缺陷，好的测试执行应该包括如下内容：

测试执行中评估测试执行时间不足，需要及时上风险。满足质量优先，进度其次原则。
测试用例按优先级顺序执行，通常是基本、详细和异常顺序执行。
未执行用例、标志为删除或者无效的用例，需注明原因。
执行过程中有疑问的测试用例（场景、操作步骤、检查点等）需找测试设计人员澄清。
测试执行需要对用例描述的检查点逐一检查，避免遗漏。
重视不易重现的缺陷场景，可能是一个bug。
执行过程中发现有前期设计遗漏用例需要补充到用例文档并执行验证。
建议测试人员交叉执行重复测试用例，用例执行对相同测试人员有免疫性。避免可能的缺陷一直遗漏。
如果需要，建议保留测试结果，结果可视。也便于不同版本间的测试结果对比。
已确认问题需及时按照问题提单要求（规范和缺陷定级）提单。
跟踪问题单修复情况并回归验证问题单。
每轮次测试结束，find一下是否有core文件产生。（核心文件（core file），也称为核心转存（core dump），是操作系统在进程收到某些信而终止运行时，将此时进程地址空间的内容以及有关进程状态的其他信息写出的一个磁盘文件。这种信息往往用于调试）
测试结束，将最终测试用例文档上传到归档目录，实现用例重现。
以上是针对一般的软件测试流程，如果是自动化测试的话，应该还有根据测试用例进行脚本编写，运行脚本等。
在测试用例执行过程中，包含了：功能测试阶段、缺陷跟踪阶段（bug tracking）、回归测试阶段、系统测试阶段、验收测试阶段等（系统已满足测试条件（开发完成），按照已经评审过的测试用例依次执行，执行过程中及时记录问题，将问题及时提交到QC（Quality Control）上，要跟踪缺陷。等开发修复后进行回归测试，确认修复后关闭缺陷，如果说该问题要更新而生产上未进行验证，就把缺陷状态改为生产未验证。对有异议的缺陷经甲方、开发和测试三方进行沟通讨论，由甲方最终确定处理方式。在测试过程中也会碰到对需求有异议，会反馈给经理，由经理与甲方沟通来对该需求提出一些可行性建议，最终还是由甲方来确定具体根据各个公司的业务流程而不一样）。

三、已达准出要求的根据测试情况写测试告，对整个测试过程和版本的质量做一个评估

测试告是指把测试的过程和结果写成文档，对发现的问题和缺陷进行分析，为纠正软件存在的质量问题提供依据，同时为软件验收和交付打下基础。测试告是测试阶段最后的文档产出物。优秀的测试经理或测试人员应该具备良好的文档编写能力，一份详细的测试告包含足够的信息，包括产品质量和测试过程的评价，测试告基于测试中的数据采集以及对最终的测试结果分析。

测试告的内容可以总结为以下目录：

首页
引言（目的，背景，缩略语，参考文献）
测试概要（测试方法，范围，测试环境，工具）
测试结果与缺陷分析（功能，性能）
测试结论与建议（项目概况，测试时间，测试情况，结论性能汇总）
附录（缺陷统计）

至此并不算最后的完结工作，软件测试还包含了线上功能检查、当前版本问题反馈以及改进建议等。这样才算是软件测试最终结束，软件测试是贯穿于整个软件生命周期的。

用例设计方法

生成测试用例
1）为每个等价类设置一个不同的编。
2）编写新的测试用例，尽可能多地覆盖那些尚未被覆盖地有效等价类，直到所有的有效等价类都被测试用例所覆盖（包含进去）。
3）编写新的测试用例，覆盖一个且仅一个尚未被覆盖的无效等价类，直到所有的无效等价类都被测试用例所覆盖。（用单个测试用例覆盖无效等价类，是因为某些特定的输入错误检查可能会屏蔽或取代其他输入错误检查。）
尽管等价划分方法要比随机选取测试用例优越得多，但它仍然存在不足。例如，这种方法忽略掉了某些特定类型的高效测试用例。边界值分析与因果图可以弥补其中的很多不足。

边界值分析
经验证明，考虑了边界条件的测试用例与其他没有考虑边界条件的测试用例相比，具有更高的测试回率。所谓边界条件，是指输入和输出等价类中那些恰好处于边界、或超过边界、或在边界以下的状态。边界值分析方法和等价划分法存在两方面的不同：
1）与从等价类中挑选任意一个元素作为代表不同，边界值分析需要选择一个或多个元素，以便等价类的每一个边界都经过一次测试。
2）与仅仅关注输入条件（输入空间）不同，还需要考虑从结果空间（输出等价类）设计测试用例。
边界值分析考察正处于等价划分边界或在边界附近的状态。
能够提供部分帮助的通用指南：
1）如果输入条件规定了一个输入值范围，那么应针对范围的边界设计测试用例，针对刚刚越界的情况设计无效输入测试用例。
2）如果输入条件规定了输入值的数量，那么应针对最小数量输入值、最大数量输入值，以及比最小数量少一个、比最大数量多一个的情况设计测试用例。
3）对每个输出条件应用指南1。设计测试用例诱导其输出指南1的错误结果。
4）对每个输出条件应用指南2。
5）如果程序的输入或输出是一个有序序列（例如顺序的文件、线性列表或表格），则应特别注意该序列的第一个和最后一个元素。
6）此外，发挥聪明才智找出其他边界条件。

因果图
边界值分析和等价划分的一个弱点是未对输入条件的组合进行分析。因果图有助于用一个系统的方法选择出高效的测试用例集。它还有一个额外的好处，就是可以指出规格说明的不完整性和不明确之处。
因果图是一种形式语言，用自然语言描述的规格语言可以转换为因果图。因果图实际上是一种数字逻辑电路（一个组合的逻辑络），但没有使用标准的电子学符，而是使用了稍微简单点的符。
生产测试用例的过程如下：
1）将规格说明分解为可执行的片段。
2）确定规格说明中的因果关系。所谓“因”，是指一个明确的输入条件或输入条件的等价类。所谓“果”，是指一个输出条件或系统转换（输入对程序或系统状态的延续影响，举例来说，如果某个事务引起文件或数据库记录被修改，那么这种改变就是一个系统转换，而系统反馈的确认信息就是一个输出条件）。因果关系一旦确定下来，每个“因”和“果”都被赋予一个唯一的编。
3）分析规格说明的语义内容，并将其转换为连接因果关系的布尔图。就是所谓的因果图。
4）给图加上注解符，说明由于语法或环境的限制而不能联系起来的“因”和“果”。
5）通过仔细地跟踪图中地状态变化情况，将因果图转换成一个有限项的判定表。表中每一列代表一个测试用例。
6）将判定表中的列转换为测试用例。

错误猜测

错误猜测主要是一项依赖于直觉的非正规的过程，因此很难描述出这种方法的规程。其基本思想是列举可能犯的错误或错误易发生情况的清单，然后依据清单来编写测试用例。

测试策略总结

测试用例设计方法可以组合为一个整体的策略，一组合理的策略如下：

如果规格说明中包含输入条件组合的情况，应首先使用因果图分析法。
在任何情况下都应使用边界值分析方法。硬棘蛛，这是对输入和输出边界的分析。边界值分析可以产生一系列补充的测试条件，但是，也正如因果图分析中所说，多数乃至全部边界条件都可以被整合到因果图测试分析中。
应为输入和输出确定有效和无效等价类，在必要情况下对上面确认的测试用例进行补充。
使用错误猜测技术增加更多的测试用例。
针对上述测试用例集检查程序的逻辑结构。应使用判定覆盖、条件覆盖、判定/条件覆盖或多重条件覆盖准则（最后一个最为完整）。如果覆盖准则未能被前四个步骤中确定的测试用例所满足，并且满足准则也并非不可能（由于程序的性质限制，某些条件的组合也许是不可能实现的），那么增加足够数量的测试用例，以使覆盖准则得到满足。

按照开发阶段分类

构建大型程序测试的第一个步骤：模块测试

一、模块（单元）测试——详细设计阶段

模块测试（单元测试）是对程序中的单个子程序、子程序或过程进行测试的过程。目的是将模块的功能与定义模块的功能规格说明或接口规格说明进行比较，以此揭示模块与其规格说明存在着矛盾。

测试用例设计
在为模块测试设计测试用例时，需要使用两种类型的信息：模块的规格说明和模块的源代码。规格说明一般都规定了模块的输入和输出参数以及模块的功能。
设计过程：
1）使用一种或多种白盒测试方法分析模块的逻辑结构；（多重条件覆盖准则要优于其他准测，任何逻辑覆盖准则尚不足以胜任作为生成模块测试用例的唯一手段，因此下一个步骤就是用一组黑盒测试用例来补充）
2）使用黑盒测试方法对照模块的规格说明以补充测试用例。
增量测试
在执行模块测试过程中，我们主要有两点考虑：1）如何设计一个有效的测试用例集；2）将模块组装成工作程序的方式。第二点很重要，因为它设计模块测试用例的编写形式、可能用到的测试工具类型、模块编码和测试的顺序、生成测试用例的成本以及调试（定位并修复检查出的错误）的成本等。组装方法有：非增量测试和增量测试，增量测试又分为自顶向下和自底向上的开发或测试过程。

非增量测试（崩溃测试）即先独立地测试每个模块，然后再将这些模块组装成完整的程序。
- 可以使我们发现认为因素的错误和问题；
- 可以将程序演示给最终用户看；
- 证明程序的整体设计是合理的；
- 起到精神上的鼓舞作用。
  然而，自顶向下策略还有一些严重的缺陷，例如我们假定当前的测试状态如5-10所示，下一步是用模块H取代桩模块H。
  这时，我们要做的是使用本章前面所述的方法为H设计一个测试用例集。但是请注意，这些测试用例采用的是向模块J的实际程序输入的形式。这带来了一些问题。
  首先，由于在模块J和模块H之间存在中间模块（即模块F、B、A和D），我们会发现无法将测试过模块H中所有预先确定的情况的测试用例提交到模块J中去。
  其次，由于H和程序中测试数据引入点之间存在着“距离”，即使存在着测试全部状态的可能性，要决定往模块J中输入什么样的数据来测试到H中的所有状态，通常也是一项困难的脑力劳动。
  最后，由于一个测试显示出来的输出可能来自于一个与被测模块相距甚远的模块，要将显示出来的输出与此模块的实际执行情况联系起来非常困难，甚至是不可能的。
  自顶向下的测试策略取决于其使用的方法，可能还存在两个更深层次的问题。人们会偶尔感觉到它可能与程序的设计阶段重叠。举例来说，如果我们正在设计如图5-8所示的程序，可能会觉得在最先的两个层次设计完成之后，在下面层次的设计进行的同时就可以对模块A至模块D进行编码和测试了。正如我们在其他地方所强调的那样，这往往不是明智之举。程序设计是一个迭代的过程，这意味着当我们在设计程序结构的较低层次时，可能会对较高层次进行合理的变更或改进。如果较高层次已经完成了编码和测试，那么这些理想的改进就会被摈弃，最终成为一个不明智的决策。
  在进行到下一个模块前未能穷举测试此模块。这来自于两个原因：一时由于将测试数据嵌入桩模块中存在困难，二是由于程序的较高层次通常会为较低层次提供资源。可能会将较高层次的某些测试延后，但是等到了那个较晚的时间点，很多人就会忘记较高层次未完成的测试内容。另外，因为较高层次常会提供资源给较低层次使用（例如打开文件），有时除非到了使用资源的较低层次模块测试完场之后，我们很难判断这些资源提供得是否正确（例如，文件是否以正确的属性打开）。

自底向上的测试
在大多数情况下，自底向上与自顶向下的策略是相对立的，自顶向下测试的优点成为自底向上测试的缺点，反之亦然。
自底向上的策略开始于程序中的终端模块。测试完这些模块之后，同样没有最佳的方法来挑选要进行增量测试的下一个模块。唯一正确的原则是，要成为合乎条件的下一个模块，该模块所有的从属模块（它调用的模块）都已经事先经过了测试。
执行测试
模块测试的其他部分如何实际进行测试。一系列操作的提示和指南：

使用自动化测试工具可以使测试过程中的枯燥劳动减至最小。举例来说，现在已有测试工具可以降低我们对驱动模块的需求。流程分析工具可以列举出程序中的路径，找到从未被执行的语句（“不可达”代码），以及找出变量在赋值前被使用的实例。
对预期输出进行定义时测试用例必不可少的部分。在执行测试时，应该查找程序的副作用（即模块执行了某些不该执行操作的情况）。一般情况下，这些情况都是很难发现的，但如果在测试用例执行完之后，检查那些不应有变动的模块输入，可能会发现一些错误实例。
因个人试图测试自己编写的程序所带来的心理学问题，也适用于模块测试。程序员不应测试自己编写的模块，而应交换模块进行测试，编写调用模块的程序员始终时测试被调用模块的最佳候选人。注意，这仅仅适用于测试，对模块的调用一般应当由编程人员本人进行。应避免随意丢弃测试用例，应将它们按某种格式记录下来，以便将来可以重新使用它们。如果发现某一部分模块存在大量错误，那么很有可能这些模块甚至包含着更多错误，这样的模块应该进行更进一步的测试，可能还需要进行额外的代码走查或检车。最后，记住模块测试的目的不是证明模块能够正确地运行，而是证明模块中存在着错误。

二、更高级别的测试

完成了对程序的模块测试之后，整个测试过程才刚刚开始，对于大型或负责的软件来说尤为如此。**当程序无法实现其最终用户要求的合理功能时，就发生了一个软件错误。**因此，要结束整个测试任务，还须进行其他形式的更深入的测试，我们将其称为“更高级别的”测试。
软件开发过程在很大程度上是沟通有关最终程序的信息，并将信息从一种形式转换到另一种形式。由于这个原因，绝大部分软件错误都可以归因于信息沟通和转换时发生的故障、差错和干扰。

集成测试往往不作为一个独立的测试步骤，而且在进行增量模块测试时，它时模块测试的隐藏部分。

2. 功能测试

**功能测试是一个试图发现程序与其外部规格说明之间存在不一致的过程。**外部规格说明是一份从最终用户的角度对程序行为的精确描述。
功能测试通常是一项黑盒操作。在进行功能测试时，需要对规格说明进行分析以获取测试用例集。等价类划分、边界值分析、因果图分析和错误猜测的方法尤其适合于功能测试。还有一些原则也特别适合于功能测试：跟踪那些暴露出错误数量最多的功能，这些功能很可能还包含着大多数尚未发现的错误。应记住对无效和未预想到的输入条件给予足够的重视。对预期结果的定义是测试用例的重要部分。最后，应始终牢记功能测试的目的是为了暴露程序的错误以及与规格说明不一致之处，而不是为了证明程序符合其外部规格说明。

3. 系统测试

系统测试最容易被错误理解，也是最困难的测试过程。系统测试的目的：将系统或程序与其初始目标进行比较。给定这个目标之后，隐含两方面的含义：
1）系统测试并不局限于系统。如果产品时一个程序，那么系统测试就是一个试图说明程序作为一个整体时如何不满足其目标的过程。
2）根据定义，如果产品没有一组书面的、可度量的目标，系统测试也就无法进行。
在寻找程序与其目标不一致的过程中，应重点注意那些在设计外部规格说明的过程中所犯的转换错误。
与功能测试不同，外部规格说明不能作为获得系统测试的基础，否则就破坏了系统测试的目标。另一方面，也不能利用目标文档本身来表示测试用例，因为根据定义，这些文档并不包含对程序外部接口的准确描述。
克服上述两个困难的方法是利用程序的用户文档或书面材料。通过分析目标文档来设计系统测试，分析用户文档来阐明测试用例。

3. 演绎法调试

演绎的过程是从一些普遍的理论或前提出发，使用排除和精炼的过程，达到一个结论（错误的位置）。

2. 测试的挑战

用户群体庞大且五花八门。站用户的能力参差不齐，使用的浏览器、操作系统和设备种类也不同，我们还应考虑到消费者访问站时的信道速率差别也很大。
业务环境。如果运行的是一个电子商务站，那么必须考虑到诸如计算税费、判断运输成本、结算往来账务以及跟踪用户资料等问题。
地点。用户可能位于其他国家，在这种情况下，涉及到处理国际化问题，如语言翻译、时差及货币兑换等问题。
测试环境。为了严格地测试应用系统，必须复制软件运行的环境，即使用与软件运行环境中相同的Web服务器、应用服务器和数据库服务器。为了得到最精确的测试结果，还需要建立相同的络环境，包括路由器、交换机和防火墙。
安全相。
测试浏览器的兼容性

3. 测试的策略

为基于因特的应用系统涉及测试策略，需要对组成应用系统的每一个硬件和软件组件都有深入的了解。规格说明文档对于成功测试一般的应用程序非常关键，这里也需要一份规格说明文档来描述Web站点的预期功能和性能。
按照因特应用系统的三层C/S程序进行分层测试：

表示层的测试
主要目的是发现应用程序的GUI或前端错误。下面列举了表示层测试中的三个主要内容：

内容测试。包括整体审美、字体、色彩、拼写、内容准确性和默认值。
Web站点结构。包括无效的连接或图形。
用户环境。包括Web浏览器的版本和操作系统配置。（也被称为“浏览器兼容性测试”）常常是测试基于因特的应用系统中最具挑战性的部分。浏览器和操作系统的组合非常之多，我们不仅要测试每一个浏览器的配置，还要测试同一个浏览器的不同版本。如果浏览器系统高度依赖客户端的脚本处理，用户环境测试就变得更加复杂，每一个浏览器都有不同的脚本引擎或虚拟机在客户计算机上运行脚本和代码。如果使用了一下任何一项，就应特别关注浏览器的兼容性问题：ActiveX控件；JavaScript；VBScript；Java applets。通过制订定义完善的功能需求，可以客服大多数与浏览器兼容性测试相关的挑战。举例来说，在需求搜集阶段，市场部门可能会决定应用系统只需要运行于几个特定的浏览器就可以了，这个需求排除了大量的测试工作量，因为我们有了一个定义良好的目标平台以供测试。

业务层测试
业务层测试的重点是发现因特应用系统的业务逻辑错误。白盒、黑盒测试技术都可以使用到，我们需要制定测试计划和过程，用来发现系统性能需求、数据获取和事务处理中的错误。
对于内部开发的部件，可以深入程序逻辑结构中去，因此应该使用白盒测试，然而，黑盒测试技术应是业务层测试的主要方法。在对业务层进行系统测试时，需要模拟用户在购买某个产品或服务时执行的步骤。我们应该采用多种测试方法进行测试，无论采用什么方法，应用系统中始终存在着一些可以测试的特性，这些内容包括：

性能。测试的目的在于检查应用系统是否满足书面性能规格说明（通常定义为响应时间和吞吐率）。为了达到足够的性能水平，必须保证性能规格说明在需求收集阶段编写完成，如果没有书面的规格说明或目标，也就无从得知应用系统的性能是否可以接受。强度测试是一种常用的性能测试方法。开始进行强度测试之前，应确保支撑设施部件处于合适状态，如果做不到这一点，可能会得到错误的结果。
数据有效性。测试的目的在于发现从用户那里采集到的数据中的错误。
事务。测试的目的在于发现事务处理过程中的错误，其中可能包括信用卡处理、电子邮件验证以及消费税计算等。我们可以将事务测试视为对业务层进行的系统测试，自始自终测试业务层，尽量发现错误。再次强调，应具备书面的文档，详细定义事务的构成，除了测试内部的业务过程之外，还必须测试外部服务。

数据层测试
数据层测试主要是指对应用系统用于存储和获取信息的数据库管理系统的测试。数据测试的最大挑战之一是复制应用系统的运行环境。必须使用相同的硬件平台和软件版本来进行有效的测试，此外，一旦获得了资金和人力资源，就必须设计一个方法来使实际运行的环境与测试环境保持一致。与测试其他层一样，在测试数据层时应当在特定的方面查找错误：

响应时间。应量化数据操作语言（DML，包括结构化查询语言SQL中的INSERT、UPDATE和DELETE）、查询（SELECT）及事务的完成时间。在测试数据层的响应时间时，我们要确保单个的数据库操作能够快速完成，不至于阻塞其他操作。对数据层响应时间的测试充斥着挑战。测试环境必须与系统实际应用环境相一致，否则得到的结果就会无效。另外，必须彻底了解数据库系统，确保它安装正确、操作有效。
数据完整性。即在数据库表中发现不准确数据的过程，验证数据存储适当且正确。有很多因素会影响到数据库存储数据的方式，数据类型和长度可能导致数据截断或食去精确性；对于日期和时间字段，会出现时区问题；国际化和字符集同样会影响数据完整性；还应检查应用系统使用的检查/参考表的准确性，例如销售税、邮政编码及时区信息等。我们不仅要确保信息准确，还应保持其最新。
容错性和可恢复性。最大化平均故障间隔时间（MTBF），最小化平均故障恢复时间（MTTR）。最大化MTBF取决于数据库系统的容错级别，采用何种类型的测试取决于系统的结构。可恢复性测试的目标是设计出数据库无法恢复的场景出来，恢复计划开始于获得有效的备份，在进行可恢复性测试时，如果无法恢复数据库，那么需要修改备份策略。

软件测试实例

电商系统(用户)

看例题以及做题熟悉软件测试的方法。

声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！