逆流成河在那个电视剧:软件测试基础总结

1.  软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果。
　  用例编号： 测试用例的编号有一定的规则，比如系统测试用例的编号这样定义规则：PROJECT1-ST-001 ，命名规则是项目名称＋测试阶段类型（系统测试阶段）＋编号。定义测试用例编号，便于查找测试用例，便于测试用例的跟踪。
　
　　测试标题： 对测试用例的描述，测试用例标题应该清楚表达测试用例的用途。比如 “ 测试用户登录时输入错误密码时，软件的响应情况 ” .重要级别： 定义测试用例的优先级别，可以笼统的分为“ 高 ” 和 “ 低” 两个级别。一般来说，如果软件需求的优先级为 “ 高 ” ，那么针对该需求的测试用例优先级也为 “ 高 ” ；反之亦然，测试输入： 提供测试执行中的各种输入条件。根据需求中的输入条件，确定测试用例的输入。测试用例的输入对软件需求当中的输入有很大的依赖性，如果软件需求中没有很好的定义需求的输入，那么测试用例设计中会遇到很大的障碍。
　
　　操作步骤： 提供测试执行过程的步骤。对于复杂的测试用例，测试用例的输入需要分为几个步骤完成，这部分内容在操作步骤中详细列出。
　
　　预期结果： 提供测试执行的预期结果，预期结果应该根据软件需求中的输出得出。如果在实际测试过程中，得到的实际测试结果与预期结果不符，那么测试不通过；反之则测试通过。
　
　　

2.  软件生命周期(SDLC)的六个阶段

软件危机的出现主要表现在：a. 由于缺乏大型软件开发经验和软件开发数据积累，开发工作计划很难制定；b. 开发早期需求分析不够明确，造成开发后期矛盾集中暴露；c. 不遵循开发规范，开发文档不完整，软件难以维护；d. 缺乏严密有效的软件质量检测手段，交付给用户的软件质量差。

软件危机的后果：a. 软件质量不高，很难稳定；b. 软件项目延期，进度无法控制； c. 成本增加，无法控制预算。

软件危机的根源：a. 根据摩尔定律，硬件发展很快，相应对软件系统的期望越来越高； b. 软件系统复杂性提高，需多人合作；c. 软件开发是人的智力活动，无法用已有的产业工程方法来组织管理。

软件生命周期(SDLC，软件生存周期)是软件的产生直到报废的生命周期，周期内有问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、验收与运行、维护升级到废弃等阶段，这种按时间分程的思想方法是软件工程中的一种思想原则，即按部就班、逐步推进，每个阶段都要有定义、工作、审查、形成文档以供交流或备查，以提高软件的质量。但随着新的面向对象的设计方法和技术的成熟，软件生命周期设计方法的指导意义正在逐步减少。

1、问题的定义及规划
      此阶段是软件开发方与需求方共同讨论，主要确定软件的开发目标及其可行性。

2、需求分析
      在确定软件开发可行的情况下，对软件需要实现的各个功能进行详细分析。需求分析阶段是一个很重要的阶段，这一阶段做得好，将为整个软件开发项目的成功打下良好的基础。"唯一不变的是变化本身。"，同样需求也是在整个软件开发过程中不断变化和深入的，因此我们必须制定需求变更计划来应付这种变化，以保护整个项目的顺利进行。

3、软件设计
     此阶段主要根据需求分析的结果，对整个软件系统进行设计，如系统框架设计，数据库设计等等。软件设计一般分为总体设计和详细设计。好的软件设计将为软件程序编写打下良好的基础。

4、程序编码
      此阶段是将软件设计的结果转换成计算机可运行的程序代码。在程序编码中必须要制定统一，符合标准的编写规范。以保证程序的可读性，易维护性，提高程序的运行效率。

5、软件测试
      在软件设计完成后要经过严密的测试，以发现软件在整个设计过程中存在的问题并加以纠正。整个测试过程分单元测试、集成测试以及系统测试三个阶段进行。测试的方法主要有白盒测试和黑盒测试两种。在测试过程中需要建立详细的测试计划并严格按照测试计划进行测试，以减少测试的随意性。

6、运行维护
      软件维护是软件生命周期中持续时间最长的阶段。在软件开发完成并投入使用后，由于多方面的原因，软件不能继续适应用户的要求。要延续软件的使用寿命，就必须对软件进行维护。软件的维护包括纠错性维护和改进性维护两个方面。

2、软件生命周期模型

　　任何软件都是从最模糊的概念开始的：为某个公司设计办公的流程处理；设计一种商务信函打印系统并投放市场。这个概念是不清晰的，但却是最高层的业务需求的原型。这个概念都会伴随着一个目的，例如在一个"银行押汇系统" 的目的是提高工作的效率。这个目的将会成为系统的核心思想，系统成败的评判标准。99年政府部门上了大量的OA系统，学过一点Lotus Notes的人都发了财（IBM更不用说了），但是更普遍的情况是，许多的政府部门原有的处理模式并没有变化，反而又加上了自动化处理的一套流程。提高工作效率的初衷却导致了完全不同的结果。这样的软件究竟是不是成功的呢？

　　从概念提出的那一刻开始，软件产品就进入了软件生命周期。在经历需求、分析、设计、实现、部署后，软件将被使用并进入维护阶段，直到最后由于缺少维护费用而逐渐消亡。这样的一个过程，称为"生命周期模型"（Life Cycle Model）。

　　典型的几种生命周期模型包括瀑布模型、快速原型模型、迭代模型。瀑布模型（WaterfallModel）首先由Royce提出。该模型由于酷似瀑布闻名。在该模型中，首先确定需求，并接受客户和SQA小组的验证。然后拟定规格说明，同样通过验证后，进入计划阶段…可以看出，瀑布模型中至关重要的一点是只有当一个阶段的文档已经编制好并获得SQA小组的认可才可以进入下一个阶段。这样，瀑布模型通过强制性的要求提供规约文档来确保每个阶段都能很好的完成任务。但是实际上往往难以办到，因为整个的模型几乎都是以文档驱动的，这对于非专业的用户来说是难以阅读和理解的。想象一下，你去买衣服的时候，售货员给你出示的是一本厚厚的服装规格说明，你会有什么样的感触。虽然瀑布模型有很多很好的思想可以借鉴，但是在过程能力上有天生的缺陷。

迭代式模型

　　迭代式模型是RUP推荐的周期模型，也是我们在这个系列文章讨论的基础。在RUP中，迭代被定义为：迭代包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必需的所有其它外围元素。所以，在某种程度上，开发迭代是一次完整地经过所有工作流程的过程：（至少包括）需求工作流程、分析设计工作流程、实施工作流程和测试工作流程。实质上，它类似小型的瀑布式项目。RUP认为，所有的阶段（需求及其它）都可以细分为迭代。每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。迭代的思想如上图所示。

　　迭代和瀑布的最大的差别就在于风险的暴露时间上。"任何项目都会涉及到一定的风险。如果能在生命周期中尽早确保避免了风险，那么您的计划自然会更趋精确。有许多风险直到已准备集成系统时才被发现。不管开发团队经验如何，都绝不可能预知所有的风险。"（RUP）二者的区别如下图所示：

　　由于瀑布模型的特点（文档是主体），很多的问题在最后才会暴露出来，为了解决这些问题的风险是巨大的。"在迭代式生命周期中，您需要根据主要风险列表选择要在迭代中开发的新的增量内容。每次迭代完成时都会生成一个经过测试的可执行文件，这样就可以核实是否已经降低了目标风险。"（RUP）

　　快速原型（RapidPrototype）模型是我喜欢采用的另一种模型。快速原型模型在功能上等价于产品的一个子集。注意，这里说的是功能上。瀑布模型的缺点就在于不够直观，快速原型法就解决了这个问题。一般来说，根据客户的需要在很短的时间内解决用户最迫切需要，完成一个可以演示的产品。这个产品只是实现部分的功能（最重要的）。它最重要的目的是为了确定用户的真正需求。在我的经验中，这种方法非常的有效，原先对计算机没有丝毫概念的用户在你的原型面前往往口若悬河，有些观点让你都觉得非常的吃惊。在得到用户的需求之后，原型将被抛弃。因为原型开发的速度很快，设计方面是几乎没有考虑的，如果保留原型的话，在随后的开发中会为此付出极大的代价。至于保留原型方面，也是有一种叫做增量模型是这么做的，但这种模型并不为大家所接受，不在我们的讨论之内。

　　上述的模型中都有自己独特的思想，其实现在的软件组织中很少说标准的采用那一种模型的。模型和实用还是有很大的区别的。

软件生命周期模型的发展实际上是体现了软件工程理论的发展。在最早的时候，软件的生命周期处于无序、混乱的情况。一些人为了能够控制软件的开发过程，就把软件开发严格的区分为多个不同的阶段，并在阶段间加上严格的审查。这就是瀑布模型产生的起因。瀑布模型体现了人们对软件过程的一个希望：严格控制、确保质量。可惜的是，现实往往是残酷的。瀑布模型根本达不到这个过高的要求，因为软件的过程往往难于预测。反而导致了其它的负面影响，例如大量的文档、繁琐的审批。因此人们就开始尝试着用其它的方法来改进或替代瀑布方法。例如把过程细分来增加过程的可预测性。

补充：软件开发过程中的相关技术

3.软件测试概念

广义概念：指软件生存周期中所有的检查、评审和确认工作，其中包括了对分析、设计阶段，以及完成开发后维护阶段的各类文档、代码的审查和确认

狭义概念：识别软件缺陷的过程，即实际结果与预期结果的不一致

4.软件测试目的

ü  测试的目的就是发现软件中的各种缺陷

ü  测试只能证明软件存在缺陷，不能证明软件不存在缺陷

ü  测试可以使软件中缺陷降低到一定程度，而不是彻底消灭

ü  以较少的用例、时间和人力找出软件中的各种错误和缺陷，以确保软件的质量

软件测试的三层次：1.发现缺陷 2.尽早的发现缺陷3.帮助开发软件尽早的发现缺陷。（体现了测试人员的价值）

5．软件测试原则

ü  Good-enough: 一种权衡投入/产出比的原则

ü  保证测试的覆盖程度，但穷举测试是不可能的

ü  所有的测试都应追溯到用户需求

ü  越早测试越好，测试过程与开发过程应是相结合的

ü  测试的规模由小而大，从单元测试到系统测试

ü  为了尽可能地发现错误，应该由独立的第三方来测试

ü  不能为了便于测试擅自修改程序

ü  既应该测试软件该做什么也应该测试软件不该做什么

 测试结束的原则：

ü  基于测试阶段的原则：

ü  基于测试用例的原则：

ü  基于缺陷收敛趋势的原则

ü  基于缺陷修复率的原则

ü  基于覆盖率的原则

ü  基于项目计划的原则

ü  基于缺陷度量的原则

ü  基于行业经验的原则 

6．软件测试的的重点

ü  测试用例的设计

–  测试用例的设计是整个软件测试工作的核心

–  测试用例反映对被测对象的质量要求，决定对测试对象的质量评估

ü  测试工作的管理

–  尤其是对包含多个子系统的大型软件系统，其测试工作涉及大量人力和物力，有效的测试工作管理是保证有效测试工作的必要前提

ü  测试环境的建立

–  测试环境应该与实际测试环境一致

7．软件测试的几种常用模型

W模型由Evolutif公司提出，相对于V模型，W模型增加了软件各开发阶段中应同步进行的验证和确认活动。W模型由两个V字型模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。

　　W模型强调：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等同样要测试，也就是说，测试与开发是同步进行的。W模型有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需求的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，这将显着减少总体测试时间，加快项目进度。

但W模型也存在局限性。在W模型中，需求、设计、编码等活动被视为串行的，同时，测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。这样就无法支持迭代的开发模型。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临着困惑。

X模型是由Marick提出的，他的目标是弥补V模型的一些缺陷，例如：交接、经常性的集成等问题。

     X模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试，此后将进行频繁的交接，通过集成最终合成为可执行的程序。右上半部分，这些可执行程序还需要进行测试。已通过集成测试的成品可以进行封版并提交给用户，也可以作为更大规模和范围内集成的一部分。多根并行的曲线表示变更可以在各个部分发生。

     X模型还定位了探索性测试（右下方）。这是不进行事先计划的特殊类型的测试，诸如“我这么测一下结果会怎么样？”，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。

      但V模型的一个强项是它明确的需求角色的确认，而X模型没有这么做，这大概是X模型的一个不足之处。 而且由于X模型从没有被文档化，其内容一开始需要从V模型的相关内容中进行推断，因为它还没有完全从文字上成为V模型的全面扩展。

V模型 ：“V”的左端表示传统的瀑布开发模型，而“V”右端表明相应的测试阶段。在V模型中，每一个开发阶段和一个相应的测试阶段相连。当工作进行到某个特定的开发阶段时，就要执行相应测试阶段的计划和一些基本的设计工作。

8．黑盒测试

ü 什么是黑盒测试

– 又称功能测试或数据驱动测试，是针对软件的功能需求/实现进行测试，通过测试来检测每个功能是否符合需求，不考虑程序内部的逻辑结构

ü  黑盒测试方法

–  功能划分

–  等价类划分

–  边界值分析

–  因果图

–  错误推测等

9．什么是白盒测试

–  白盒测试也称结构测试或逻辑驱动测试，必须知道软件内部工作过程，通过测试来检测软件内部是否按照需求、设计正常运行

–  白盒测试的主要方法

–  对应于程序的一些主要结构：语句、分支、逻辑路径、变量；白盒测试的主要方法是：

–  语句覆盖方法

–  分支覆盖方法

–  逻辑覆盖方法

10.什么是动态测试

动态测试需要在开发/测试环境或实际运行环境中运行软件，并使用测试用例去查找软件缺陷；动态测试包括功能确认与接口测试、覆盖率分析、性能分析、内存分析等 

11.什么是静态测试

静态测试不实际运行软件，主要是对软件的编程格式、结构等方面进行评估.静态测试包括代码检查、程序结构分析、代码质量度量等。它可以由人工进行，也可以借助软件工具自动进行

12.手工测试和自动测试

a.手工测试缺点在于测试工作量大，重复多，回归测试难以实现

b.自动测试利用软件测试工具自动实现全部或部分测试工作：管理、设计、执行和报告；节省大量的测试开销，并能够完成一些手工测试无法实现的测试

ü  手工完成测试的全部过程无法保证测试的科学性与严密性:

–       修改的缺陷越多，回归测试越困难

–       没有人能向决策层提供精确的数据以度量当前的工作进度及工作效率

–       反复测试带来的倦怠情绪及其它人为因素使得测试标准前后不一

–       测试花费的时间越长，测试的严格性也就越低

ü  自动测试将测试人员从反复、烦杂的测试执行中解放出来，用更多的时间进行测试设计和结果分析

ü  软件测试不可能完全自动化

ü  不能完成所有手工测试任务

ü  无创造性且灵活性差，不能改进测试的有效性

ü  过程中可能会遇到许多意想不到的问题，特别是当软件不稳定时

ü  测试脚本的维护高

13. 测试流程

ü  单元测试

ü  集成测试

ü  系统测试

ü  用户验收测试

ü  回归测试

14.单元测试

ü  完成对最小的软件设计单元—模块的验证工作

ü  目标是确保模块被正确地编码

ü  使用过程设计描述作为指南，对重要的控制路径进行测试以发现模块内的错误

ü  通常情况下是面向白盒的

ü  对代码风格和规则、程序设计和结构、业务逻辑等进行静态测试，及早地发现和解决不易显现的错误

ü  单元测试的内容

–       接口测试

–       内部数据结构

–       全局数据结构

–       边界

–       语句覆盖，错误路径

15.集成测试

ü  通过测试发现与模块接口有关的问题

ü  目标是把通过了单元测试的模块拿来，构造一个在设计中所描述的程序结构

ü  应当避免一次性的集成（除非软件规模很小），而采用增量集成

集成测试主要内容

ü  API

ü  API/参数组合

16．系统测试

ü  根据软件需求规范的要求进行系统测试，确认系统满足需求的要求

ü  系统测试人员相当于用户代言人

ü  在需求分析阶段要确定软件的可测性，保证有效完成系统测试工作

ü  系统测试主要内容

ü  所有功能需求得到满足

ü  所有性能需求得到满足

ü  其它需求（例如安全性、容错性、兼容性等）得到满足

17.用户验收/确认测试

ü  Alpha测试

–       是由用户在开发者的场所来进行的，Alpha测试是在一个受控的环境中进行的

ü  Beta测试

–       由软件的最终用户在一个或多个用户场所来进行的，开发者通常不在现场，用户记录测试中遇到的问题并报告给开发者

18．压力测试VS性能测试
  性能测试的目的不是去找bugs,而是排除系统的瓶颈，以及为以后的回归测试建立一个基准。而性能测试的操作，实际上就是一个非常小心受控的测量分析过程。在理想的情况下，被测软件在这个时候已经是足够稳定了

性能测试是为了检查系统的反映，运行速度等性能指标，他的前提是要求在一定负载下，如检查一个网站在100人同时在线的情况下的性能指标，每个用户是否都还可以正常的完成操作等。
概括就是：在不同负载下（负载一定）时，通过一些系统参数（如反应时间等）检查系统的运行情况；

压力测试是为了发现系统能支持的最大负载，他的前提是要求系统性能处在可以接受的范围内，比如经常规定的叶面3秒钟内响应；概括就是：在性能可以接受的前提下，测试系统可以支持的最大负载。

举例说明：针对一个网站进行测试，模拟10到50个用户就是在进行常规性能测试，用户增加到1000乃至上万就变成了压力/负载测试。如果同时对系统进行大量的数据查询操作，就包含了强度测试。

19. 主流测试工具的测试流程

1.自动化测试工具

======loadrunner========
1　制定负载测试计划
(分析应用程序， 确定测试目标，计划怎样执行LoadRunner）
2　开发测试脚本
（录制基本的用户脚本，完善测试脚本）
3　创建运行场景
（选择场景类型为Manual Scenario，选择场景类型，理解各种类型，场景的类型转化）
4　运行测试
5　监视场景
（MEMORY 相关，PROCESSOR相关，网络吞量以及带宽，磁盘相关，WEB应用程序 ，IIS5.0，SQL SERVER，NETWORK DELAY等)
6　分析测试结果
(分析实时监视图表,分析事务的响应时间,分解页面,确定WEBSERVER的问题,其它有用的功能)
=========quicktestpro========
1　准备录制
打开你要对其进行测试的应用程序，并检查QuickTest中的各项设置是否适合当前的要求。
2　进行录制
打开QuickTest的录制功能，按测试用例中的描述，操作被测试应用程序。
3　编辑测试脚本
通过加入检测点、参数化测试，以及添加分支、循环等控制语句，来增强测试脚本的功能，使将来的回归测试真正能够自动化。
4　调试脚本
调试脚本，检查脚本是否存在错误。
5　在回归测试中运行测试
在对应用程序的回归测试中，通过QuickTest回放对应用程序的操作，检验软件正确性，实现测试的自动化进行。
6　分析结果，报告问题
查看QuickTest记录的运行结果，记录问题，报告测试结果。

QTP与LR的区别:

QTP: 基于UI对象的功能测试

LR:  基于协议的性能测试

QTP 录制原理：消息机制，截获消息。录制的前提是能识别控件。

LU  录制原理：捕获数据包。录制的前提是能识别协议报文。

========winrunner========
1　启动时选择要加载的插件
2　进行一些设置（如录制模式等）
3　识别应用程序的GUI，即创建map(就是学习被测试软件的界面）
4　建立测试脚本（录制及编写）
5　对脚本除错及调试（保证能够运行完）
6　插入各种检查点（图片，文字，控件等）
7　在新版应用程序中执行测试脚本
8　分析结果，回报缺陷

2.测试管理工具

＝＝＝＝TestDirect============
安装好后，先进入站点管理
1　创建域及工程
2　添加用户
3　编辑licenses及本服务器
4　编辑数据库
－－TD
1　选择新建的工程进行定制(列表，用户，组，版本等)
2　在require中增加需求
3　把需求转化为plan
4 在testlab中由计划新建测试具体用例与执行

5　发现bug，在defect中提交bug
（每一部分都可以相对独立地使用）

3. 测试用例通常包括那些内容？着重阐述编制测试用例的具体做法不同结构的用例包括的不一样。（版本、编号、项目、设计人员、设计日期、输入、预期输出……）
　

＝＝＝＝bugzilla============  

为了正确跟踪每个软件错误的处理过程，通常将软件测试发现的每个错误作为一条条记录输入制定的错误跟踪管理系统。

  作为一个缺陷跟踪管理系统，需要正确设计每个错误的包含信息的字段内容和记录错误的处理信息的全部内容。字段内容可能包括测试软件名称，测试版本号，测试 人名称，测试事件，测试软件和硬件配置环境，发现软件错误的类型，错误的严重等级，详细步骤，必要的附图，测试注释。处理信息包括处理者姓名，处理时间，处理步骤，错误记录的当前状态。

  正确的数据库权限管理是错误跟踪管理系统的重要考虑要素，一般要保证对于添加的错误不能从数据库中删除。

软件错误的状态

  新信息(New)：测试中新报告的软件缺陷； 
  打开 (Open)：被确认并分配给相关开发人员处理； 
  修正(Fixed)：开发人员已完成修正，等待测试人员验证； 
  拒绝(Declined):拒绝修改缺陷； 
  延期(Deferred): 不在当前版本修复的错误，下一版修复 
  关闭(Closed)：错误已被修复； 

Bug 管理的一般流程

　　测试人员提交新的Bug入库，错误状态为New。

　　高级测试人员验证错误，如果确认是错误，分配给 相应的开发人员，设置状态为Open。如果不是错误，则拒绝，设置为Declined状态。

  开发人员查询状态为Open的Bug，如果不是错误，则置状态为Declined；如果是Bug则修复并置状态为Fixed。不能解决的Bug，要留下文 字说明及保持Bug为Open状态。

  对于不能解决和延期解决的Bug，不能由开发人员自己决定，一般要通过某种会议（评审会）通过才能认可。

  测试人员查询状态为Fixed的Bug，然后验证Bug是否已解决，如解决置Bug的状态为Closed，如没有解决置状态为Reopen。

软 件错误流程管理要点

  为了保证错误的正确性，需要有丰富测试经验的测试人员验证发现的错误是否是真正的错误，书写的测试步骤是否准确，可以重复。

  每次对错误的处理都要保留处理信息，包括处理姓名，时间，处理方法，处理意见，Bug状态。

  拒绝或延期错误不能由程序员单方面决定，应该由项目经理，测试经理和设计经理共同决定。

  错误修复后必须由报告错误的测试人员验证后，确认已经修复，才能关闭错误。

  加强测试人员与程序员的交流，对于某些不能重复的错误，可以请测试人员补充详细的测试步骤和方法，以及必要的测试用例。