软件测试基础

1、软件测试基础测试人员技能要求业务知识（项目涉及的领域知识的分析和理解能力）设计知识（产品设计和架构的分析和理解能力）测试知识（各种测试手段和测试工具的应用）用户知识（用户模型的分析和理解能力）快速学习能力1 软件工程与软件测试 什么是软件工程 随着工程学科的发展，人们对计算机软件的认识逐渐深入。软件工程的范围不仅仅局限在程序编写，而是扩展到了整个软件生命周期。如软件基本概念的形成、需求分析、设计、实现、测试、安装部署、运行维护，直到软件被更新和替换新的版本。 软件工程还包括很多技术性的管理工作，例如过程管理、产品管理、资源管理和质量管理，在这些方面也逐渐的建立起了标准或规范。软件测试与软件工程

2、息息相关，软件测试是软件工程不可或缺的一部分。1.1 软件的生命周期如果把软件看成是有生命的事物，那么软件的生命周期可以分为6个阶段，各种软件工程思想、软件开发模式都是基于这6个基本阶段来设计的。软件工程贯穿软件生命周期的各个阶段。软件生命周期图计 划需求分析设 计编 码测 试运行维护1.2 软件工程的目的软件工程的目的是提高软件质量和生产效率，最终实现软件的工业化生产。采用软件工程模型的目的是为了确保项目成功，并且每次都成功。而每一个项目的成败，是由成本，进度，质量三者共同决定的。成功项目“铁三角”成本进度质量无论是哪一种软件工程模型，都必须充分考虑这3个方面，并且要考虑如何协调这3个方面，

3、使其搭配达到最佳平衡点。（1）软件成本主要考虑项目的开销，包括人员成本、工具成本、 设备成本、错误成本等。某些软件还需要考虑市场营销成本。（2）进度主要是通过时间上的控制。如何在规定时间范围内完成一个另客户满意的软件产品，是每个项目的首要挑战。（3）质量主要考虑软件对客户需求的满足程度。一个低质量的软件，即使生产成本很低，进度控制良好，客户也很难接受。因此，质量是软件产品的生命线。而软件测试作为质量保证的重要方法和手段，如何在一个软件工程模型中的适当位置出现，是每一个应用软件工程模型阻止要仔细考虑的问题。1.3 软件开发模式软件工程中软件开发模型用来描述和表示一个复杂的开发过程。 1.瀑布模型

4、瀑布模型的每一个阶段都只执行一次。适应范围：项目规模小，需求稳定优 点：简单，高效缺 点：测试介入晚，上游工作未完成时下游人员闲置，应变能力差测试范围：软件功能测试介入点：编码完成后 2.螺旋模型适应范围：与人的生命财产相关行业优 点：安全性和抗风险能力强缺 点：成本高测试范围：单元测试：代码、集成测试：接口、正式测试：功能、鉴定测试：异常测试介入点：单元测试：代码编写过程中、集成测试：模块编写过程中、正式测试：编码完成后 3.RUP流程适应范围：大型的复杂的的项目优 点：降低了软件研发的复杂度、每个阶段完成后都会发布半成品 可以提早应对变更、只能变更本阶段新增的功能，有效地控制了变更范围缺

5、点：缺乏专业的软件架构师测试范围：当前阶段完成的功能加上以前所有阶段完成的功能测试介入点：每个阶段编码完成后 4.IPD流程适应范围：大型的软硬集成厂商优 点：提高决策了的准确性缺 点：管理成本较高测试范围：软件测试+硬件测试测试介入点：产品研发完成后 5.双V模型适应范围：大型的项目、大型的公司、质量要求较高的项目优 点：测试更充分、测试与开发同时进行、测试介入早缺 点：测试成本高、开发变更后会影响测试变更、对开发成熟度 要求较高测试范围：ST-功能、IT-接口、UT-数据结构测试介入点：SRS-ST、HLD-IT、LLD-UT2 软件质量与软件测试质量就是产品或工作的优劣程度，换句话说，质

6、量就是衡量产品的或工作的好坏。这是通俗的讲法。下面是ISO关于质量的定义：“一个实体的所有特性，基于这些特性可以满足明显或隐含的需求。而质量就是基于这些特性满足需求的程度。”2.1 质量的三个层次显性需求 隐性需求 用户实际需求内部质量 外部质量 使用质量中间产品文档 软件成品2.2 软件质量模型ISO 9126软件质量模型是评价软件质量的国际标准，由6个特性和27个子特性组成。外部和内部质量功能性可靠性易用性效率维护性可移植性适合性准确性互操作性保密安全性成熟性容错性易恢复性易理解性易学性易操作性时间特性资源利用易分析性易改变性易测试性稳定性适应性易安装性易替换性共存行2.3 SQA与软件测

7、试CMM第一个级别的改进方向重（CMM二级）就提出要“开展软件质量保证（SQA）活动”，可见SQA在软件能力改进方面的重要性。SQA阻止的好坏在一定程度上决定了SQA活动被执行的好坏情况。IBM公司的经验指出：“在超过8年的时间内，SQA发挥了至关重要的作用，并使得产品质量得到不断提高。越来越多的项目经理也感觉到由SQA的介入，不管是产品质量还是成本节约都得到较大改善。”软件质量由组织、流程和技术三方面决定。SQA从流程方面保证软件质量，测试从从技术方面保证软件质量。只进行SQA活动或只进行测试活动不一定能产生好的软件质量。软件质量 组织（人员） 技术（测试） 流程（SQA）3 软件测试的目的

8、与原则软件测试的目的可以从验证和确认两个方面进行理解。验证（Verification）：是指在软件生命周期的各个阶段，用下一个阶段的产品来检查是否满足上一个阶段的规格定义。需求设计编码测试确认（Validation）：是指在软件生命周期的各个阶段，检查每个阶段结束时的工作成果是否满足软件生命周期的出气需求文档中定义的各项规格和要求。需求设计编码测试验证和确认是两种不同的如啊你按测试方式，测试人员应该综合利用两种方式进行测试。4 软件测试的过程管理软件测试的各个阶段按照尽早测试的原则，测试人员应该在需求阶段就介入，并贯穿软件开发的全过程。就测试过程本身而言，应该包括以下几个阶段：测试需求的分析和

9、确定；测试计划测试设计测试执行测试记录和缺陷跟踪回归测试测试总结和报告4.1 测试需求数据表明，56%的缺陷来源于错误的需求。而这其中50%是由于需求文档编写有问题、不明确、不清晰、不正确导致的。可以通过检查需求文档来检查需求，也可以通过编写测试用例来检查需求。还可以通过用户调查来测试需求。下图为需求规格说明书联查列表的一个例子序号序号 检检 查查 项项 检查结果检查结果 说说 明明1是否覆盖了用户提供的所有需求项是 否 NA2用词是否清晰，语义是否存在有歧义的地方是 否 NA3是否清楚的描述了软件系统需要做什么及不做什么是 否 NA4是否描述了软件使用的目标环境，包括软硬件环境是 否 NA5

10、是否对需求项进行了合理的编号是 否 NA6需求项是否前后一致、彼此不冲突是 否 NA7是否清楚的说明了系统的每个输入、输出格式，以及输入输出之间对应关系是 否 NA8是否清晰描述了软件系统性能要求是 否 NA9需求的优先级是否合理分配是 否 NA10是否描述了各种约束条件是 否 NA4.2 测试计划计划是关于如何做某样事情的思考。也可以把测试当成一场战争，一场对所有软件Bug展开的歼灭战。对于这样一场战争，要考虑如何制定一个可行的计划。项目的成败由四大因素决定，如下图所示。项目成功的四大要素时间成本范围质量时间：由项目计划覆盖成本：由合同覆盖范围：由需求文档覆盖质量：由QA计划或测试计划覆盖测

11、试计划通常作为关于质量的重要文档呈现给管理层。测试计划的内部作用和外部作用。内部作用有3个：作为测试计划的结果，让相关人员和开发人员来评审；存储计划执行细节，让测试人员来进行同行评审存储计划进度表、测试环境等更多信息。测试计划的外部作用是给客户一个信心，通过向客户交代有关测试过程、人员的技术、资源、使用的工具等信息。 测试计划是对测试过程的整体设计软件测试计划是对测试过程的一个整体设计，通过收集项目和产品相关信息，对测试范围、测试风险进行分析，对测试用例、工作量、资源和时间等进行估算，对测试采取的策略、方法、环境、资源、进度等作出合理的安排。因此测试计划的要点包含以下内容。确定测试范围（根据质

12、量模型的6大特性来确定测试范围）制定测试策略（测试优先级别，采用测试的方法（黑盒、白盒、灰盒；手动测试、自动化测试），测试用例的设计方法（等价类划分法、边界值分析法、流程图法、因果图法、错误猜测法），测试工具等）测试资源安排（软件资源，硬件资源，人力资源，测试工具）进度安排风险及对策4.3 基于需求的测试用例设计基于需求的用例场景来设计测试用例是最直接有效的方法，因为它直接覆盖了需求，而需求是软件的根本，验证对需求的覆盖是软件测试的根本目的。测试用例的评价质量因素包括测试用例对需求的覆盖完整性、测试用例的有效性、测试用例描述的清晰程度、测试用例的可维护性等。4.4 测试的执行需求的分析和检查、

13、测试的计划、测试用例的准备。都是为了执行测试准备的。测试执行阶段是测试人员的主要活动阶段，是测试人员工作量的主要集中阶段，同事也是测试人员智慧体现的阶段、测试人员找到工作乐趣的一个重要过程。测试环境的搭建测试环境测试机器操作系统测试数据网络环境测试机器4.5 测试的记录和跟踪测试的执行只能有两个结果：测试通过和测试不通过。测试不通过的话，测试人员就应该把发现的错误及时记录下来，报告给开发人员作出相应修改。Bug记录是测试人员工作的具体表现形式，是测试人员与开发人员沟通的基础。因此如何录入一个高质量的Bug是每一位二是人员都要考虑的问题。Bug也是有生命的，它从开发人员手中诞生，到被测试人员发现

14、，再到交给开发人员修改。当然Bug也有复活的时候，所以Bug的缺陷跟踪很重要。 如何录入一个合格的Bug那么如何录入一个大家认为好的，尤其是开发人员认为好的Bug呢？撰写缺陷报告的一个基本原则是客观的陈述所有相关的事实。一个合格的Bug报告应该包括完整的内容，如下图。合格的缺陷报告发现问题的版本预期行为的描述问题出现的环境（如操作系统环境、软件配置环境，有时候还需要包括系统资源的情况，因为有些错误只有在资源不足时才出现）错误行为的描述问题重现步骤缺陷的严重程度缺陷的类型 如何跟踪一个Bug的生命周期测试人员应该跟踪Bug的整个生命周期，从Open到Closed的所有状态。New：新发现的Bug

15、，未经评审决定是否指派给开发人员进行修改。Open：确认是Bug，并且认为需要进行修改，指派给相应的开发人员。Fixed：开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。Rejected：如果认为不是Bug，则拒绝修改。Delay：如果认为暂时不需要修改或暂时不能改，则延后修改。Closed：修改状态的Bug经测试人员的回归测试验证通过，则关闭Bug。Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员从新修改。4.6 测试总结和报告测试人员的工作通常不能像开发人员那样直接体现出来，被大家直观的看到。开发人员做的是建设性的工作，开发了哪些功能，写了几行代码，设计了几个类，都能直观的看到，最重要的是软件能很鲜活的演示开发人员的工作。但是测试人员相对隐蔽一点，测试人员做的事破坏性的工作，并且没有很多可以直观的体现测试人员的贡献的东西。测试报告是一个展示自己工作的机会。缺陷列表太细太多