软件测试

写在最前面

1 课程目标

• 掌握基础的软件测试理论、测试方法和策略
• 掌握常用工具的使用方法
• 根据需求和设计文档，独立编写测试计划、测试方案、测试用例以及测试报告

2 主要内容

• 软件测试概论
• 软件测试基础知识
• 软件测试通用技术
• 软件测试流程
• 黑盒测试
• 白盒测试
• 性能测试
• 软件测试自动化
• 软件测试管理

3 课程安排

学时安排：72课时（理论36+实践36）
教材：清华大学出版社 《软件测试》(第2版) 周元哲 编著

4 课程资源

• 课程内容文档 gitee 课程地址
• 课程思维导图
• 测试相关文档模板
• 测试工具：禅道

5 期末成绩

考勤：选取5次，占比总成绩 30%，3次缺勤，考勤成绩取消
平时作业：14-15次，占比总成绩 30%
大作业：占比总成绩 40%

6 大作业

1. 人员：自由结组（6-8人，不得少于4人）
2. 测试对象：自选一款企业级开源软件，主题不限。例如：https://gitee.com/XiaFuXiangFei/lin-cms-vue
3. 内容：按照软件测试各个阶段，分角色完成测试工作，编写各环节文档，形成最终测试报告，最后一节课演示。

注意：

1. 同组不同分，按照每个人的工作量贡献计分，多劳多得。
2. 可以跨班级结组，但协调好时间，最后一节演示需要全组成员出席。
3. 演示成员有加分。

第1章 软件测试概论

1.1 软件

1.1.1 软件定义

软件是一系列按照特定顺序组织的计算机数据和指令的集合。
软件 ≠ 程序（代码）
软件包含如下内容：

1. 运行时，能够提供所要求功能和性能的指令或计算机程序集合。
2. 程序能够处理信息的数据结构。
3. 用于描述程序功能需求、程序如何操作和如何使用的文档。

1.1.2 文档

开发文档

开发文档是描述软件开发过程，包括软件需求、软件设计、软件测试和保证软件质量的一类文档，开发文档也包括软件的详细技术描述、程序逻辑、程序间相互关系、数据格式和存储等。

• 《可行性研究》
• 《项目任务书》
• 《需求规格说明书》
• 《概要设计》
• 《详细设计》
• 《代码规范说明书》
• 《数据字典》
• 《开发计划》

管理文档

从管理的角度规定涉及软件生存的信息：

1. 职责定义；
2. 开发过程的每个阶段的进度和进度变更的记录；
3. 软件变更情况的记录；
4. 相对于开发的判定记录。

• 《工作报告》
• 《工作日志》
• 《会议记录》
• 《里程碑报告》
• 《软件项目配置管理计划》
• 《实施方案》

产品文档

为使用和运行软件产品的任何人规定培训和参考信息，促进软件产品的市场流通或提高可接受性。使得那些未参加开发本软件的程序员也能维护它。

• 《产品手册》
• 《用户指南》
• 《培训手册》
• 《软件支持手册》

1.1.3 软件发展史

1. 程序设计阶段：个体化生产、专用软件、规模小、功能单一、开发者即使用者。（软件 = 程序）；
2. 程序系统阶段：多用户系统，人机交互技术，实时系统和数据库管理系统；
3. 软件工程阶段：以软件的产品化、系列化、工程化和标准化为特征的软件产业发展起来，软件开发有了可以遵循的软件工程化的设计准则、方法和标准；
4. 多层分布结构，面向服务架构。

1.1.4 软件项目

软件项目是一种特殊的项目，具有如下特点：

1. 知识密集型，技术含量高；
2. 涉及多个专业领域，多种技术综合应用；
3. 项目范围广和目标的灵活性高；
4. 风险大，收益大；
5. 客户化程度高；
6. 过程管理重要。

1.2 软件生命周期

1.2.1 需求定义

描述： 定义出本次任务都需要做什么，做成什么样子。

参与者： 产品经理、需求分析师、客户

1.2.2 可行性分析

描述： 由项目组相关成员去研究需求是否可行，能不能做出来。

参与者： 产品经理、架构师、项目经理、开发人员

1.2.3 需求分析

描述： 需求分析其实是在做需求细化，按照任务说明书中的任务内容和指标具体细化各个点，细化到每个输入框、每个按钮的样式，输入输出等各项值，统一整理编写成《需求说明书/需求规格说明书》。

参与者： 产品经理、架构师、项目经理、测试人员/质量管理员(很多公司把这个统称为QA)、开发人员

输出：《需求规格说明书》

1.2.4 评审

描述： 评审就是做审查，对这个阶段的工作进行审查，看是否偏离或者有遗漏（比如：设计和工厂的各个环节都有相关的审查，审查材料是否合格、设计是否符合规定、按照工人设计出的材料需求是否足够或者多余等等，这些审查都是评审）；评审一般由相应工作人员来参与。

参与者： 每个阶段的评审一般都是各职能部门内部审核，也可以申请其他相关人员审核，比如需求评审，一般是产品经理、项目经理、测试人员、开发人员一起评审；系统设计一般是项目经理、开发人员评审；测试策略评审一般是测试组内部评审。

1.2.5 设计

描述： 架构师根据需求确定产品或者项目的场景、特点，选择合适的框架、技术使项目实现最优化。在此基础上将系统进行概要设计，包括系统总体数据结构、数据库结构、模块结构以及它们之间的关系等。开发人员根据概要设计对具体模块进行详细设计，包括接口、参数等。此处设计会形成概要设计文档和详细设计文档。

参与者： 项目经理、架构师、开发人员、测试人员

1.2.6 编码

描述： 开发人员根据详细设计文档对系统进行模块化开发，在确定参数和接口的情况下，根据需求对模块内部进行方法级别的设计和编码以及自测，对产品功能进行一一实现。

参与者： 开发

1.2.7 提测

描述： 开发人员完成一个小迭代/小功能，且完成自测(开发编码完成后，一般都会自己检测下)，然后向测试部门发起提测，一般以邮件方式或者任务管理工具的任务流方式向测试部门通知xxx模块/功能可以测试。

参与者： 任务责任人（开发）、测试人员

1.2.8 测试

• 测试需求
• 测试计划
• 测试设计
• 测试执行
• 回归测试
• 测试评估

1.2.9 部署/发版

描述： 经过前面的各个阶段，产品已经可以出售或者面向大众了。配置管理人员进行封版、版本制作（针对产品来说）、部署上线（针对项目应用来说）。

参与人： 配置管理人员、测试人员

1.2.10 支持维护

描述： 支持维护类似于我们日常中的售后，主要是对已卖出的产品/已上线的项目进行日常维护。包括纠错性维护和改进性维护两个方面。

参与人： 支持维护人员/售后工程师

1.3 软件测试概述

1.3.1 软件测试定义

软件测试的经典定义是：在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。
IEEE（电气与电子工程师协会）：使用人工或自动手段来运行或测定某个软件系统的过程，其目的在于检测它是否满足规定的需求或弄清预期结果和实际结果的差别。

1.3.2 测试发展历程

1. 1957年之前－调试为主(Debugging Oriented)

软件规模小，复杂度低，开发人员承担需求分析、设计、开发、测试等所有工作，等同于调试。

2. 1957–1978－证明为主(Demonstration Oriented)

与调试区分开，这是软件测试史上一个重要的里程碑，主要目的是确认软件是满足需求的。

3. 1979–1982－破坏为主(Destruction Oriented)

1979年，《软件测试的艺术》 (The Art of Software Testing)第一版问世，这本书是测试界的经典之作。书中给出了软件测试的经典定义：

The process of executing a program with the intent of finding errors.
测试是为发现错误而执行程序的过程。

这个观点较之前证明为主的思路，是一个很大的进步。我们不仅要证明软件做了该做的事情，也要保证它没做不该做的事情，这会使测试更加全面，更容易发现问题。

4. 1983–1987－评估为主(Evaluation Oriented)

软件行业进入了大发展时期，软件趋向大型化、复杂化，质量越来越重要。软件测试的基础理论和实用技术开始形成。提出了在软件生命周期中使用分析、评审、测试来评估产品的理论。

5. 1988–至今－预防为主(Prevention Oriented)

尽量早地介入并发现这些明显的或隐藏的bug，发现得越早，修复起来的成本越低，产生的风险也越小。

1.3.3 测试与开发的关系

瀑布模型

这是一种经典模型,提供了软件开发的基本框架。

强调开发工作（计划、设计、开发、测试、维护等）各阶段之间的先后顺序，不可以并行操作。

瀑布模型认为，测试是指代码完成后，处于运行维护阶段之前。如果需求和设计上存在缺陷，就会造成大量返工，增加成本。

为了更早的发现问题，测试应延伸需求评审，设计审查活动中，软件生命周期的每个阶段都应包含测试。

优点：

1. 各阶段划分清晰；
2. 强调计划与需求分析；
3. 适合需求稳定的产品开发。

缺点：

1. 单一流程，不可逆；
2. 风险显露得晚，纠正机会少；
3. 测试只是其中一个阶段，缺乏全过程测试思想。
4. 客户往往很难清楚给出所有的需求，而改模型却要求如此。

V模型

强调测试和开发同等重要，对于开发阶段都有与之对应的测试阶段。

优点：

相对于瀑布模型，V模型测试能够尽早的进入到开发阶段。

缺点：

虽然测试尽早的进入到开发阶段，但是真正进行软件测试是在编码之后，这样忽视了测试对需求分析、系统设计的验证，时间效率上也大打折扣。

W模型(双V模型)

明确表示出了测试与开发的并行关系。

优点：

W 模型相对于 V 模型来说，测试更早的进入到开发阶段，与开发阶段是并行关系，更早的发现问题，能够及时解决问题，各个阶段分工明确，方便管理。

缺点：

W 模型是顺序性的、不可逆的，需求的变更和调整，依旧不方便。

螺旋模型

大型软件项目通常有很多不确定性和风险，如果采用瀑布式线性过程模型，失败风险很大，因此需要采取一种渐进式的演化过程模型。将产品分解成增量版本，每个版本单独测试。

螺旋模型是一种演化软件开发过程模型，它兼顾了快速原型的迭代的特征以及瀑布模型的系统化与严格监控。螺旋模型最大的特点在于引入了其他模型不具备的风险分析，使软件在无法排除重大风险时有机会停止，以减小损失。同时，在每个迭代阶段构建原型是螺旋模型用以减小风险的途径。螺旋模型更适合大型的昂贵的系统级的软件应用。

优点：

螺旋模型将风险分析扩展到各个阶段中，大幅度降低了软件开发的风险。

缺点：

螺旋模型的控制和管理较为复杂，可操作性不强，对项目管理人员的要求较高。

敏捷模型

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。专注于交付对客户有价值的软件（可以工作的)。

强调以人为核心，程序员团队和业务专家之间的紧密联系，频繁交付新的软件版本，紧凑的自我组织型团队，更注重软件开发中人的作用。

在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

《联盟敏捷宣言》

1. 最重要的是通过尽早和不断交付有价值的软件满足客户需要；
2. 我们欢迎需求的变化，即使在开发后期；敏捷过程能够驾驭变化，保持客户的竞争优势；
3. 经常交付可以工作的软件，从几星期到几个月，时间尺度越短越好；
4. 业务人员和开发者应该在整个项目过程中始终朝夕在一起工作；
5. 围绕斗志高昂的人进行软件开发，给开发者提供适宜的环境，满足他们的需要，并相信他们能够完成任务；
6. 在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈；
7. 可以工作的软件是进度的主要度量标准；
8. 敏捷过程提倡可持续开发；出资人、开发人员和用户应该总是维持不变的节奏；
9. 对卓越技术与良好设计的不断追求将有助于提高敏捷性；
10. 简单——尽可能减少工作量的艺术至关重要；
11. 最好的架构、需求和设计都源自自我组织的团队；
12. 每隔一定时间，团队都要总结如何更有效率，然后相应地调整自己的行为。

解读：

• 个体和互动高于流程和工具

  以人为本，没有比面对面交流更高效的沟通渠道了，基于互相信任的前提，敏捷提倡自治的全功能团队。

  在工作形式上，整个团队平时坐在一起工作，从物理空间上创造了更加便捷面对面的沟通机会。在团队职责上，团队内部具备完成软件交付的角色(能力)，团队所有人对软件的质量负责，开发过程由团队内部把控，业务价值团队内部快速流动，在任何环节都能及时获得反馈。同时，每个角色都更容易从全局视角去思考软件，避免了传统部门墙模式下的视角割裂和协作障碍。

• 工作的软件高于详尽的文档

  为客户交付可工作的软件是我们的核心目标，我们应该尽早交付可进行端到端测试的代码，该目标决定了我们不应该花过多精力在面面俱到的文档上，但这不代表我们要抵制任何文档。实践证明，轻量级的文档策略有助于团队高质量交付可工作的软件。

• 客户合作高于合同谈判

  主动拥抱变化，及时响应，持续交付。

• 响应变化高于遵循计划

  通过高效的协作，获取快速的反馈，从而尽早做出调整，减少浪费。

优点：

敏捷模型持续关注卓越的技术和良好的设计，定期适应变化的环境，即使是最新的需求变化也受到欢迎。

缺点：

敏捷模型缺乏对必要的设计和文件的重视，由于其项目周期很长，所以很难保证开发的人员不更换，而缺少文档就会造成在交接的过程中出现很大的困难。只有高级程序员才能在开发过程中做出所需的决策，因此，除非与经验丰富的资源相结合，否则对于新手程序员来说，他没有立足之地。

1.4 软件缺陷

1.4.1 缺陷定义

IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准的定义：从产品内部看，缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题；从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背。

符合下面4个条件之一就是缺陷：

1. 软件未达到规格说明书中规定的功能；
2. 软件出现了产品说明书中指明的不会出现的错误；
3. 软件功能超出了产品说明书中指明的范围；
4. 软件难于理解，不易使用，运行速度慢，或者最终用户认为软件使用效果不好。

1.4.2 产生原因

1. 软件本身复杂性，产生大量不确定因素；
2. 成本、时间限制，导致流程不够完善，文档缺失，缺乏严谨的评审；
3. 人员本身技能水平限制、责任心不够、交流沟通不顺畅；
4. 审查不全面或者没有复审。

1.4.3 缺陷来源

1.4.4 缺陷类型

1.4.5 缺陷级别

严重性： 表示软件缺陷的恶劣程度，当用户碰到该缺陷时影响的可能性和程度。

优先级： 表示修复缺陷的重要程度和紧迫程度。

严重性

优先级

严重性和优先级对于审查缺陷报告并决定哪些软件缺陷应该修复，以何种顺序修复的人员极为重要。如果一个程序员受命修复10个缺陷，他就应该先从严重性为1 、优先级为4这样的缺陷着手，而不是优先修复简单的，由简到难。

综合使用重要性等级和严重性双标准的优先顺序:

1.4.6 跟踪流程

最优化、最简单的生命周期是：（理想情况）

1. 测试员发现缺陷并记录缺陷报告；
2. 缺陷报告交给程序员，此时缺陷状态是打开（open state）；
3. 程序员修改缺陷，此时缺陷状态是解决（resolved state）；
4. 缺陷报告交还测试员；
5. 测试员确认已修复；
6. 测试员关闭缺陷报告，此时缺陷状态是关闭（closed state）。

一个缺陷很可能会被反复打开→关闭。在日常工作过程中，由于开发修订其他缺陷影响、需求变更等因素缺陷可能会被反复打开→关闭。

1.4.7 缺陷记录内容

1. bug编号：bug的唯一id，以方便尽快找到此bug；
2. bug标题：bug摘要，阐述bug大体内容；
3. bug类型：功能、用户界面、软件包、文档、性能或接口问题；
4. bug严重级别:作为缺陷是否修复以及缺陷修复优先级的决定性因素；
5. bug优先级：作为缺陷是否修复以及缺陷修复优先级的决定性因素；
6. bug产生的模块：记录bug所属模块，方便开发定位问题；
7. bug对应的版本：bug对应的软件版本，方便后续的统计归档以及开发定位问题；
8. bug描述：bug的产生环境、详细步骤、期望结果、实际结果；
9. bug发现者：谁上报的bug；
10. bug发现时间：可以自动生成；
11. 附件：包括但不仅限于截图、日志、录像、所用到的示例文件以及应用；同样是方便复现解决缺陷的。

以上是上报bug、创建bug必须要做的，在后续我们还会对bug进行修复、复测等工作，那么为了记录后续工作，bug还应该包含：

1. bug状态：开始、修复中、修复完成、提测、测试中、测试通过/失败、关闭等，后续bug周期中会讲到；
2. bug修订人：修改bug的开发人员；
3. bug修订说明：由bug修订人来写，说明bug产生原因，修改思路等；
4. bug复测人：通常是谁报的bug最后返回给谁测试，但是在某些情况下比如bug报告人任务积累太多/不在的情况下也会分给其他人，所以通常会记录bug复测责任人；
5. bug复测说明：由复测人员来写，说明复测过程，复测结果等；
6. bug备注：备注，以便记录一些额外信息。截图、视频、log。

1.4.8 缺陷预防

**差错：**人在理解和解决问题的思维和行为过程中出现的问题，沟通不当，理解错误；（产生根源）
**错误：**软件内部问题，设计错误、编码错误；（内部原因）
**失效：**软件系统运行时偏离了用户需求。（外部表现）

1.5 软件测试行业

1.5.1 行业现状

软件系统越来越复杂，一个软件不能够由单独的软件工程师单独编写，而是由团队进行配合，每个人可能只负责一个模块，对于全局没有过多的了解，这时如果运行软件就会容易产生很多的错误。在行业内将这些错误叫做BUG。并且每一个软件工程师都会有思维的死角，自己不容易发现自己编写出来的错误。所以这个时候就需要专门的软件测试工程师用专业的测试方式来检查软件。检查该软件是否符合客户要求的产品设计，是否能够符合大多数用户的使用习惯，如果发现异常状态及时进行处理。软件市场虽然远远没有达到饱和但是各种各样功能的软件也层出不穷竞争激烈，对软件开发的质量要求也是日益增高。

我国软件测试行业起步较晚，发展较慢，直到21世纪初期，我国才逐步开始重视软件测试行业。但近年来，软件行业的快速发展为软件测试行业的发展提供了良好的基础，随着我国软件测试行业的发展，行业内企业向规模化发展将获得规模效应，可以有效降低企业的单位成本;而软件测试技术的不断发展，也将淘汰那些技术实力较弱的企业，促使行业内企业向专业化方向发展。

在软件业较发达的国家，软件测试产业已形成规模，比较发达，软件测试不仅早已成为软件开发的一个重要组成部分，而且在整个软件开发的系统工程中占据着相当大的比重。在微软公司内部，软件测试人员与软件开发人员的比例一般为1.5∶1到2.5∶1左右，即一个开发人员背后，有至少两位测试人员在工作，以保证软件产品的质量。国外优秀的软件开发机构把40%的工作花在软件测试上，软件测试费用占软件开发总费用的30%至50%，对于一些要求高可靠性、高安全性的软件，测试费用甚至相当于整个软件项目开发所有费用的3至5倍。

从国内软件公司软件测试部门的独立性来看，多数软件企业没有专门的测试技术部门，软件测试程序也不太规范，多数企业也不懂测试，对测试的投入资金过少。大多数是在经过简单地测试之后，就认为没有问题了，就交于用户了，让用户去“测试”。于是，软件产品在没有经过严格测试的情况下就发布了。对国内消费类软件而言，经常出现一些已经推向市场的产品由于被发现有严重缺陷而导致大量退货的现象。定制的行业软件，常出现一再返工、无限期的修改和维护的现象。

当前国内软件测试行业主要存在以下问题：

1. 软件规模越来越大，功能越来越复杂，如何进行充分而有效的测试成为难题；
2. 面向对象的开发技术越来越普及，但是面向对象的测试技术却刚刚起步；
3. 对于分布式系统整体性能还难以进行很好的测试；
4. 对于实时系统缺乏有效的测试手段；
5. 随着安全问题的日益突出，信息系统的安全性如何进行有效的测试与评估，成为世界性的难题；
6. 测试的自动化程度不高，手工测试过多，自动化测试工具和手工测试人员也缺乏较好的结合；
7. 缺乏软件测试意识、对其重视不够；
8. 在软件开发基本完成后才进行测试，也缺乏软件测试的统一标准；
9. 高校从师资储备到专业设置再到人才培养的机制薄弱。

国内外软件测试差距：

1. 测试的理解认识；
2. 测试过程的管理；
3. 测试工具的使用；
4. 测试人员的培养。

1.5.2 未来趋势

1. 以软件为代表的计算机行业正在以一种井喷式的趋势发展；
2. 人才缺口大；
3. 女性员工受到青睐；
4. 未来发展空间大；
5. 外包为主。

1.5.3 软件测试职业发展

1. 技术方向
   • 敏捷测试专家
   • 高级测试开发专家
   • 专项测试专家
   • QA-Ops 专家
2. 管理方向
   • 测试组长
   • 测试经理
   • 项目测试负责人
   • 测试总监
3. 易转型方向
   • 项目经理
   • 产品经理

1.5.4 测试思维方式

1. 逆向思维方式
2. 组合思维方式
3. 全局思维方式
4. 两级思维方式
5. 比较思维方式
6. 发散思维方式

1.6 测试认识的误区

1. 使用了测试工具，就是进行了有效的测试；

有效的测试首先是指该软件具有可测试性。可测试性反映了软件质量的内在属性，是一个强内聚、弱耦合、接口明确的软件，它不会因为使用了某种测试工具，就证明被测试的软件具有可测试性。

2. 存在太多无法测试的东西；

在软件开发领域，确实存在一些看起来比另外一些东西难测试的东西，但是远非无法测试。在大多数情况下，发生这种情况还是由于被测试软件本身在设计时没有考虑到可测试性的问题。只不过这种不可测试性不是由于被测试软件内部的过紧耦合造成的，而是和外部某些很难测试的部分耦合过紧，从而表现出被测试软件本身很难测试的特征。这些很难测试的部分，比较常见的有图形界面、硬件、数据库等。

3. 软件开发完成后才进行测试；

软件测试是一个系列过程活动，包括软件测试需求分析、测试计划设计、测试用例设计、执行测试，软件测试贯穿软件项目的整个生命过程，每一个阶段都要进行不同目的和内容的测试活动，以保证各个阶段的正确性。软件测试的对象不仅仅包括软件代码，还包括软件需求文档和设计等各类文档。软件开发与软件测试是交互进行的，例如，单元编码需要单元测试，模块组合阶段需要集成测试。如果等到软件编码结束后才进行测试，测试的时间将会很短，测试的覆盖面将很不全面，测试的效果也将很差。更严重的是，如果发现了软件需求阶段或概要设计阶段的错误，要修复该类错误，将会耗费大量的时间和人力。

4. 软件发布后发现质量问题，是测试人员的问题；

这种错误的认识非常伤害软件测试人员的积极性。软件中的错误可能来自软件项目中的各个过程，软件测试只能确认软件存在错误，不能保证软件没有错误，因此从根本上讲，软件测试不可能发现全部错误。从软件开发的角度看，软件的高质量不是软件测试人员测出来的，是靠软件生命周期的各个过程中设计出来的。如果出现软件错误，不能简单地归结为某一个人的责任，有些错误可能是技术原因，也可能是混乱的管理所致。因此，应该分析软件项目的各个过程，从过程改进方面寻找产生错误的原因和改进的措施。

5. 软件测试很简单，就是点点点，是个人就能做；

随着软件工程学的发展和软件项目管理经验的提高，软件测试已经形成了一个独立的技术学科，演变成一个具有巨大市场需求的行业。软件测试技术不断更新和完善，新工具、新流程、新方法都在不断出现，因此，软件测试需要学习很多测试知识，更需要不断的实践和学习。

6. 软件测试没有前途，只有程序员才是软件高手；

随着市场对软件质量要求的不断提高，软件测试将变得越来越重要，对测试人员的要求也越来越高。测试人员不仅要懂得如何测试，还要懂得被测软件的业务知识和专业知识.而开发人员往往只需要对自己开发的模块了解比较深，对算法掌握的程度要求高一些，所以，软件测试和开发人员只是工作的侧重点不同，并不存在水平差异的问题。

7. 软件测试是测试人员的事情和程序员无关；

开发和测试是相辅相成的过程，需要测试人员、程序员和系统分析师等保持密切的联系，需要交流和协调，以便提高测试效率。另外，对于单元测试，主要应该由程序员完成，必要时测试人员可以帮助设计测试样例。对于测试中发现的软件错误，很多都需要程序员通过修改编码才能修复。程序员通过有目的地分析软件错误的类型、数量，找出产生错误的位置和原因，以避免同样的错误发生，积累编程经验，提高软件开发能力。

8. 项目进度吃紧时少做测试，时间多时多做测试；

这是在软件开发过程中不重视软件测试的常见表现，也是软件项目过程管理混乱的表现，必然会降低软件测试的质量。软件项目开发需要合理的项目进度计划，其中就包括测试计划，对项目实施过程中的任何问题，都要有风险分析和相应的对策，不要因为开发进度的延期而简单地缩短测试时间，压缩人力和资源。因为缩短测试时间使测试不完整，引入潜在风险，往往造成更大的软件缺陷。避免这种现象的最好办法是加强软件过程的计划和控制，包括软件测试计划、测试设计、测试执行、测试度量和测试控制。

9. 测试要进行穷尽测试；

测试最多只是采样。

10. 采样是随机抽取过程；

测试采样过程需要使用正确的测试用例设计方法来操作。

11. 测试和开发是对头；

开发和测试是合作伙伴的关系，在日常生活中要注意沟通技巧和方式，如意见不一致且不能说服对方的问题，上报给负责人去决定。

12. 测试少报bug开发就会高兴点，报告也会好看点；

遇到缺陷一定要上报，即使它不能稳定复现（当然测试要尽可能的再现缺陷，并且找出再现问题的具体步骤）。但是一定不要不负责任的乱报。

13. 自动化测试终会取代手工测试；

我们在选择用哪种方法的测试的时候，坚持“效率最高化，利益最大化”的原则来选择用最适合的方法。我们工作的目的是为了利益，而不是显得高端。

自动化测试的初衷是将测试从繁重的、重复的回归工作中解放出来，从而提高测试效率的。并不是为了取代手工测试的，当然以目前的情况来看也取代不了手工测试。另外自动化测试需要在前期投入大量的人力资源和时间，且维护成本很高，故不能盲目推崇测试自动化。

14. 规范化软件测试是增加项目成本；

大家常说“磨刀不误砍柴工”，但是真正用时又拿“能省则省”的理论来操作，殊不知此时省了相当于埋了颗雷。不仅要规范化软件测试，更要规范化整个软件过程,规避个人水平、责任心、经验的差距。

15. 测出bug越多测试越有效；

测试过程中bug的数量并不能说明测试的有效性，只能说明开发人员的技术水平高低。项目上线后/产品卖出后现场反馈回来的线上bug数量才能反应测试的有效性。

16. 软件测试工作只负责项目上线/产品发布之前的部分。

测试活动贯穿整个软件生命周期。

1.7 知识点总结

1. 软件定义与发展
2. 软件测试定义与发展
3. 软件生命周期
4. 软件测试模型
5. 缺陷定义、来源、产生原因和记录方法
6. 软件测试行业
7. 软件测试职业发展
8. 软件测试认识误区

第2章 软件测试基础知识

2.1 概述

1. 从软件测试的目的来理解

软件测试的目的是发现软件中的错误，是为了证明软件有错，而不是无错。是在软件投入运行前，对软件需求分析、设计和编码各个阶段产品的最终检查，是为了保证软件开发产品的正确性、完整性和一致性。

2. 从软件测试的性质来理解

在软件开发过程中，分析、设计和编码都是“建设性的”，唯有测试是“破坏性的”。

3. 从软件开发角度来理解

软件测试以检查产品的内容和功能特性为核心，是软件质量保证的关键步骤，也是成功实现软件开发目标的重要保障。

4. 从软件工程角度来理解

软件测试是软件工程的一部分，是软件工程过程中的重要阶段。

5. 从软件质量保证角度来理解

软件测试是软件质量保证的重要措施。

2.2 测试的目的和原则

2.2.1 测试的目的

1. 测试不仅仅是找出错误。通过分析错误产生的原因和错误的发展趋势，可以帮助项目管理者发现当前软件开发过程中的缺陷，以便即时改进；
2. 检测产品是否符合用户要求；
3. 没有发现错误的测试也是有价值的，完整的测试是评定软件质量的一种方法；
4. 提升用户体验。

2.2.2 测试的原则

1. 软件测试是证伪而非证实；
2. 尽早地、不断地进行测试；
3. 重视无效数据和非预期的测试；
4. 应当对每一个测试结果做全面的检查；
5. 测试现场保护和资料归档；
6. 程序员应避免检查自己的程序；
7. 充分注意测试中的集群现象；
8. 用例要定期评审，适时补充修改用例。

2.3 测试分类

2.3.1 按照测试阶段划分

1. 单元测试
2. 集成测试
3. 确认测试
4. 系统测试
5. 验收测试

软件测试阶段对照表:

2.3.2 按照执行状态划分

1. 静态测试
2. 动态测试

2.3.3 按照测试技术划分

1. 白盒测试
2. 黑盒测试
3. 灰盒测试

2.3.4 按照执行主体划分

1. α测试
2. β测试
3. 第三方测试

2.3.5 按照测试内容划分

1. 界面测试
2. 功能测试
3. 安全测试
4. 兼容性测试
5. 易用性测试
6. 性能测试

2.3.6 按照是否手工操作划分

1. 手工测试
2. 自动化测试

2.4 测试用例

2.4.1 简介

测试用例是指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。其内容包括：测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，最终形成文档。

简单的认为，测试用例是为某个特定目标而编制的一组测试输入、执行条件和预期结果，用于核实是否满足某个特定的软件需求。

选择测试用例是软件测试员最重要的一项任务，不正确的选择可能导致测试量过大或者过小，甚至测试目标不对。准确评估风险，把无穷尽的可能性减少到可以控制的范围是软件测试成功的诀窍。

2.4.2 测试用例的作用

1. 指导测试的实施；
2. 评估测试结果的度量基准；
3. 保证软件的可维护性和可复用性；
4. 分析缺陷的标准。

2.4.3 测试用例设计准则

1. 有效性
2. 经济性
3. 完备性
4. 可判定性
5. 可再现性

2.4.4 测试用例维护

术语：

1. 测试编号：测试用例的编号
2. 测试项：测试的功能点说明
3. 前置条件：该测试用例的前提条件，比如测试wangdachui／dachui12345（用户名／密码）账户是否能正确登录进去，那前提wangdachui／dachui12345一定是注册过的
4. 测试步骤：就是测试的所有操作步骤，最好是每一个步骤应该对应一个期望结果，最少也得一个测试用例对应一个期望结果
5. 期望结果：就是希望得到的结果（正确的结果）
6. 测试结果：实际测试的结果，可选项有：通过、不通过、暂时挂起／锁定（就是暂时不测试）
7. 对应的bug：当期望结果与实际结果不符时测试不通过，此时需要上报bug（记录缺陷），bug需要与测试用例对应
8. 测试执行人：实际由谁来执行测试用例；也有任务分配人的选项，就是测试用例分配给哪个测试员来测试
9. 备注：做一些备注或者测试的说明
10. 合法用户：就是已经注册过的用户
11. 非法用户：没有注册过；注册过但是用户名／密码不匹配的；本文特指未注册过的用户

测试用例维护一般分为以下几种情况：

1. 产品特性没变：漏测或者环境变更，这个时候版本没变，测试用例增加和修改均可；
2. 原有特性变化：功能变化，只能新增，不能修改，还要兼容老版本；
3. 原有功能取消：测试用例在新版本上置为“空”标志或者“无效状态”，对于先前版本有效；
4. 新增功能：新增用例，对应新版本标志。

测试用例组成：

1. 用例编号：产品名-测试阶段-测试项-XX功能模块缩写加数字
2. 版本：产品版本号
3. 功能模块：对应的功能模块（细分）
4. 测试标题(测试项)：测试点描述
5. 重要级别(优先级)：高、中、低
6. 预置条件：需要满足的前提条件
7. 测试数据：输入数据
8. 操作步骤：明确的给出操作步骤，执行人员可以根据步骤执行
9. 预期结果：根据预期输出对比实际结果，来判断测试对象是否符合需求(结果必须唯一)
10. 设计者：设计测试用例的人，前面8条都是设计者填入
11. 实际结果：实际测试的结果
12. 执行者：测试用例执行者
13. 备注：以上没包含的信息

2.4.5 测试用例设计误区

1. 测试用例设计等同于测试输入数据设计；
2. 测试用例设计越详细越好；
3. 追求测试用例设计“一步到位”；
4. 将多个测试条件混在一个用例中。

2.5 测试停止标准

2.5.1 软件测试停止总体标准

1. 测试超过了预定时间；
2. 执行了所有的测试用例，并没有发现故障；
3. 使用特定的测试用例设计方法作为判断测试停止的基础；
4. 给出测试停止的要求；
5. 根据经单位时间内查出故障的数量决定是否停止测试；
6. 软件系统经过了单元、集成、系统测试，分别达到停止标准。通过验收测试，得出验收测试结论；
7. 软件项目暂停以进行调整，测试应随之暂停，并备份暂停点数据。或者软件项目开发生命周期内出现重大估算、进度偏差，需暂停或终止时，测试应随之暂停或终止，并备份数据。

2.5.2 软件测试各阶段停止标准

单元测试停止标准

1. 单元测试用例已经通过评审；
2. 按照单元测试计划完成了所有规定单元测试；
3. 达到了测试计划中关于单元测试所规定的覆盖率要求；
4. 被测试的单元每千行代码必须发现至少3个错误；
5. 软件单元功能与设计一致；
6. 单元测试中发现的错误已经得到修改，各级缺陷修复率达到标准。

集成测试停止标准

1. 集成测试用例已经通过评审；
2. 按照集成测试计划和增量集成策略完成了整个系统的集成测试；
3. 达到了测试计划中关于集成测试所规定的覆盖率要求；
4. 被测试的集成工作版本每千行代码必须发现至少2个错误；
5. 集成工作版本满足设计定义的各项功能、性能要求；
6. 在集成测试中发现的错误已经得到修改，各级缺陷修复率达到标准。

系统测试停止标准

1. 系统测试用例已经通过评审；
2. 按照系统测试计划完成了系统测试；
3. 达到了测试计划中关于系统测试所规定的覆盖率要求；
4. 被测试的系统每千行代码必须发现至少1个错误；
5. 系统测试满足设计需求规格说明书要求；
6. 在系统测试中发现的错误已经得到修改，各级缺陷修复率达到标准。

2.6 知识点总结

1. 软件测试的目的和原则
2. 软件测试的分类（测试阶段、执行状态、测试技术、执行主体）
3. 测试用例设计和维护
4. 测试停止标准

第3章 黑盒测试

3.1 概述

黑盒测试也称功能测试，通过测试来检测每个功能是否都能正常使用。

着眼于程序外部结构，不考虑内部逻辑结构，通过测试检验每个功能是否能正常使用。在程序接口进行测试，只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当的接受输入数据而产生正确的输出信息。

黑盒测试从用户的角度出发，以输入数据与输出数据的对应关系进行测试，数据驱动。

黑盒测试注重测试软件的功能需求，主要试图发现下列几类错误：

1. 功能不正确或遗漏；
2. 界面错误；
3. 数据库访问错误；
4. 性能错误；
5. 初始化和终值错误。

从理论上讲，黑盒测试只有穷举输入测试，把所有可能的输入作为测试情况考虑，才能查出所有错误。但事实上，测试情况可能是无穷多的，完全测试是不可能的。

如何解决？

对测试行为加以分类：

1. 节约测试时间和资源。
2. 提高测试效率。
3. 重点突出，目的明确。

3.2 等价类划分

等价类是指某个输入域的子集合。在该子集合中，测试某等价类的代表值就等于对这类其他值的测试，对于揭露程序的错误是等效的。

要注意的是，在进行等价类划分的过程中，我们不仅要考虑有效等价类划分，也要考虑无效等价类划分。

有效等价类：是指输入完全符合程序规格说明的数据集合。利用有效等价类可以测试程序是否满足规格说明书规定的功能和性能。

无效等价类：和有效等价类相反，是指对程序的规格说明无意义、不合理的输入数据构成的集合。

3.2.1 划分原则

1. 在输入条件规定了取值范围的情况下，可以确立一个有效等价类（在取值范围之内）和两个无效等价类（小于取值范围和大于取值范围）；
2. 在输入条件规定了取回个数的情况下，可以确立一个有效等价类（在取值个数范围之内）和两个无效等价类（小于取值个数和大于取值个数）；
3. 在输入条件规定了输入值的集合的情况下，可以确立一个有效等价类和一个无效等价类；
4. 在输入条件规定了“必须如何”条件的情况下，可以确立一个有效等价类和一个无效等价类；
5. 在输入条件是一个布尔值的情况下，可以确立一个有效等价类和一个无效等价类；
6. 在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可以确立n个有效等价类和一个无效等价类；
7. 在规定了输入数据必须遵守规则的情况下，可以确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）；
8. 在确知已划分的等价类中各元素在程序处理中的方式不同的情况下，则应再将改等价类进一步划分为更小的等价类。

3.2.2 设计测试用例步骤

1. 形成等价类表，每一等价类规定一个唯一编号；
2. 设计测试用例，使其尽可能多的覆盖尚未覆盖的有效等价类；
3. 设计一个新的测试用例，使其只覆盖一个无效等价类，重复这一步直到所有无效等价类均被覆盖。

3.2.3 等价类举例

我们要测试学习成绩这一输入框（假设总成绩都是100），那么我们就可以如下图划分，有效的成绩是>=0且<=100的，无效的是<0和>100这两部分。

另外图中还有一个无效等价类没有表现出来--非数字字符（比如：英文字母、中文、特殊的符号等单一或者组合，如a、abc、你好、你abc、你=我、\你\a\等;以及他们分别与数字组合,比如：a123、321a、你123、12你、1你2、1\2、1=你等）。

那么根据上述分析，最终设计出来的测试用例如下：

1. 有效等价类1：0~100（包含0和100）之间的任意数，比如：19；
2. 无效等价类1：小于0的负数，比如：-1；
3. 无效等价类2：大于100的数，比如：121；
4. 无效等价类3：其他任意非数字字符，比如：a、你、\；
5. 无效等价类4：空字符。

等价类最终必须是分割到最小单位，只有这样才能保障测试覆盖全面。

非数字字符可以是包含英文字符、中文、特殊符号的字符串或者字符，所以其实它又可以分为三个无效等价类，分别是：

1. 无效等价类：包含英文字符的字符串，比如：a、a123、a=、b你a；
2. 无效等价类：包含中文的字符串，比如：你、你12、1你2、你=；
3. 无效等价类：包含特殊字符的字符串，比如：\ 。

eg. 变量命名

1. 英文字母开头；

    正确：int student_1 = 2;

    错误：int 1student = 2;

2. 只能包含字母、数字和下划线，不能包含空格、标点符号和类型说明符；

    正确：int studentAge = 18;

    错误：int age% = 18;
    错误：int student-age = 18;
    错误：int student age = 18;

3. 大小写敏感；

    int n = 1;
    int N = 10;
    // n和N是两个不同的变量

4. 不能是保留字（关键字）；

    错误：int static = 1;

由ANSI标准定义的C语言关键字共32个：auto、 double、 int、 struct、 break 、else、 long、 switch、case、 enum、 register 、typedef、 char 、extern 、return、 union 、const、 float 、short、 unsigned、 continue、 for、 signed 、void、default 、goto、 sizeof 、volatile、 do 、if 、while、 static。

5. 有效长度255个字符

等价类表：

编号：有效到无效顺序的排号

测试用例设计：

覆盖：等价表编号

3.3 边界值分析

边界值分析法是等价类划分法的补充。顾名思义，边界值分析法是对输入的边界值进行测试。从实践中我们可以发现，人们无论是在生活中还是在工作中往往会忽略边界值的条件，所以在输入或者输出的边界上会发生大量的错误。因此，在测试用例设计中，需要对输入的条件进行分析并且提取其中的边界值条件，通过对这些边界值的测试来查出更多的错误。

常见的边界值：

1. 文本框接受字符个数，比如用户名长度、密码长度等；
2. 报表的第1行和最后1行；
3. 数组元素的第1个和最后1个；
4. 循环的第1次、第2次和倒数第1次、最后1次。

3.3.1 设计原则

1. 如果输入条件规定了值的范围，则应取刚达到这个范围边界的值，以及刚刚超越这个范围边界的值作为测试输入数据；
2. 如果输入条件规定了值的个数，则用最大个数、最小个数、比最小个数少1、比最大个数多1的数作为测试数据；
3. 如果规格说明书给出的输入域或输出域是有序集合，则应选取集合的第1个元素和最后1个元素作为测试用例；
4. 如果程序中使用了内部数据结构，则应选择内部数据结构边界上的值作为测试用例；
5. 分析规格说明，找出其他可能的边界条件。

3.3.2 两类方法

1. 一般边界值分析 对于含有n个变量的程序，取值为min、min+、normal，max-、max，测试用例数目为4*N+1。

2. 健壮性边界值分析 健壮性边界值测试是边界值分析的一种扩展。变量除了取min、min+、normal、max-、max 5个边界值外，还要考虑略超过最大值(max+)以及略小于最小值(min-)的取值。因此，对于含有n个变量的程序，健壮性边界值分析产生6*n+1个测试用例。

3.3.3 应用举例

延伸上节的例子来说明：学生信息系统中有一个“考试成绩”的输入项，成绩的取值范围是0~100之间的整数，考试成绩及格的分数线是60，优秀的分数线是80。那么这个例子中的边界值数据是哪些呢?

选取的边界值数据应该包括：

-1、0、1、59、60、61、79、80、81、99、100、101

通常情况下，软件测试所包含的边界检验有以下几种类型：数字、字符、位置、质量、大小、速度、方位、尺寸、空间等，而相应地，这些类型的边界值应该在最大/最小，首位/末尾，上/下，最快/最慢，最高/最低，最短/最长，空/满等情况下。

3.3.4 局限性

如果被测程序是多个独立变量的函数，这些变量受物理量的限制，则较适合采用边界值分析。这里的关键是 “独立”的“物理量” 。例如，Date是3个变量(年、月、日)的函数，对其采用边界分析测试用例，就会发现测试用例是不充分的，例如，没强调2月和闰年。其存在问题是因为没有考虑月份、日期和年变量之间存在的依赖关系。由于边界值分析假设变量是完全独立的，因此边界值分析测试用例是对物理量的边界独立导出变量极值，不考虑函数的性质，也不考虑变量的语义含义。 边界值分析对布尔变量和逻辑变量没有多大意义。例如，布尔变量的极值是true和false，但是其余3个值不明确。

3.4 决策表

等价类划分法和边界值分析法只是孤立地考虑各个输入数据的测试效果，没有考虑输入数据的组合及其相互制约关系，而决策表考虑了多种条件的组合情况。决策表又称为判定表，分析多种逻辑条件(if-else、switch-case等)与执行之间的关系。

决策表由4部分组成：

1. 条件桩：列出了问题的所有条件，通常认为列出的条件次序无关紧要；
2. 动作桩：列出了问题规定可能采取的操作，这些操作的排列顺序没有约束；
3. 条件项：列出针对条件桩的取值，在所有可能情况下的真假值；
4. 动作项：列出在条件项的各种取值情况下应该采取的动作。

规则：任何条件组合的特定取值及其相应要执行的操作。在决策表中贯穿条件项和动作项的列就是规则。显然，决策表中列出多少条件取值，也就有多少规则，条件项和动作项就有多少列。

所有条件都是逻辑结果(即真/假、是/否、0/1)的决策表称为有限条件决策表。如果条件有多个值，则对应的决策表叫做扩展条目决策表。决策表设计测试用例，条件解释为输入，动作解释为输出。

决策表适合以下特征的应用程序：

1. if-then-else分支逻辑突出；
2. 输入变量之间存在逻辑关系；
3. 涉及输入变量子集的计算；
4. 输入和输出之间存在因果关系；
5. 很高的圈复杂度。

3.4.1 应用举例

决策表(判定表)设计测试用例的具体步骤如下：

1. 确定规则的个数。假如有n个条件，每个条件有两个取值(0，1)，故有2种规则；
2. 列出所有的条件桩和动作桩；
3. 填入条件项；
4. 填入动作项，得到初始判定表；
5. 简化，合并相似规则（相同动作）； 简化就是合并多条具有相同的动作的规则，并且其条件项之间存在极为相似的关系。

需求：输入三边值，判定是哪种三角形：非三角形、不等边三角形、等腰三角形、等边三角形

1. 绘制初始三角形判定决策表；
2. 优化1的产出；
3. 设计测试用例。

条件桩：

• abc能构成三角形
  • a+b>c
  • a+c>b
  • b+c>a
• a=b？
• a=c?
• b=c?

动作桩：

• 非三角形
• 不等边三角形
• 等腰三角形
• 等边三角形

决策表：

测试用例：

练习：
工资结算系统：

1. 工资分为年薪和月薪
2. 错误程度分为普通和严重
3. 年薪员工普通错误扣工资2%，严重扣4%
4. 月薪员工普通错误扣工资4%，严重扣8%

3.4.2 优点和缺点

决策表把复杂问题的各种可能情况一一列出，易于理解。但是，决策表不能表达重复执行动作的缺点。

使用判定表设计测试用例的条件如下：

1. 规格说明以判定表形式给出，或很容易转换成判定表；
2. 条件的排列顺序不会也不影响执行哪些操作；
3. 规则的排列顺序不会也不影响执行哪些操作；
4. 每当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则；
5. 如果某一规则得到满足要执行多个操作，这些操作的执行顺序无关紧要。

这5个必要条件使得操作的执行完全依赖于条件的组合。对于不满足条件的判定表，可增加其他的测试用例。

3.5 因果图

前面我们介绍的等价类划分法和边界值分析法都没有考虑到输入情况的组合。这样虽然各种输入条件可能出错的情况已经看到了，但是多个输入情况组合起来可能出错的情况却被忽视了。

地铁自动充值机充值

假设自动充值机每次只能投入面值50或者面值100的人民币，投入钱后会有充值50和充值100两个选项

等价类划分法和边界值分析法可能不会测试到投入面值50的人民币，然后点击充值100这种异常情况；因此，当程序的输入条件有多个的话，就需要用到因果图法来设计测试用例了。

因果图利用图解法分析输入的各种组合情况，适合描述多种输入条件的组合、相应产生多个动作的方法。因果图法最终生成的是判定表。

3.5.1 基本术语

1. 原因结果图： 原因——结果图使用了简单的逻辑符号，以直线连接左右结点，左结点表示输入状态(原因)，右结点表示输出状态(结果)。

• “恒等”：若原因出现，则结果出现；若原因不出现，则结果不出现。
• “非”：若原因出现，则结果不出现；若原因不出现，则结果出现。
• “或”：若几个原因中有一个出现，则结果出现；若几个原因都不出现，则结果不出现。
• “与”：若几个原因都出现，结果才出现；若其中有一个原因不出现，则结果不出现。

2. 约束图： 输入输出状态相互之间存在的某些依赖关系，称为约束。

• E(互斥)：原因不会同时成立，最多1个成立,可以都不成立。
• I(包含)：原因中至少一个成立，不能同时为0。
• O(唯一)：原因中有且只有一个成立。
• R(要求)：原因中a出现，b必须出现,a=1则b=1,a=0的话，b随便。QQ登录的例子a为自动登录，b是记住密码。
• M(屏蔽)：a为1时，b必须是0,a=1,则b=0，如果a=0，b随便。

3.5.2 设计因果图测试用例步骤

1. 分析软件规格说明，哪些是原因(即输入条件或输入条件的等价类)，哪些是结果(即输出条件)，给每个原因和结果赋予标识符；
2. 分析原因与结果之间、原因与原因之间对应的逻辑关系，用因果图表示；
3. 由于语法或环境限制，有些原因与原因之间、原因与结果之间的组合情况不可能出现，在因果图上用一些记号表明这些特殊情况的约束或限制条件，把因果图转换为判定表；
4. 从判定表的每一列产生出测试用例。

对于逻辑结构复杂软件，先用因果图进行图形分析，再用判定表进行统计，最后设计测试用例。当然，对于比较简单的测试对象，可以忽略因果图，直接使用决策表。

3.5.3 应用举例

需求：第一列字符必须是A或者B，第二列为数字，才允许进行文件修改。如果第一列字符不正确，输出提示L，第二列不是数字，输出提示M,采用因果图设计测试用例

原因：

1. 第一列是A
2. 第一列是B
3. 第二列是数字

结果：

1. 修改文件
2. 输出提示L
3. 输出提示M

因果图：

决策表：

测试用例：

公交一卡通自动充值系统需求：

1. 系统只接收50或100元纸币；
2. 每次操作只能放入一张；
3. 每次充值只能选择50或100；
4. 放入50纸币，选择充值50，提示充值成功，返回；
5. 放入50纸币，选择充值100，提示输入金额不足，退还50；
6. 放入100纸币，选择充值50，提示充值成功，找零50，返回；
7. 放入100纸币，选择充值100，提示充值成功，返回；
8. 放入其他面额纸币，选择充值金额，提示错误，退还纸币，返回；
9. 放入纸币后，不操作，提示超时，退还纸币，返回；
10. 不放纸币，选择充值，提示请放入，返回。

因果图：

决策表：

测试用例：

3.5.4 优点和缺点

优点：

1. 考虑多个输入之间的相互组合、相互制约的关系；
2. 指出需求规格说明书中存在的不完整性和二义性；
3. 帮助测试人员按照一定的步骤高效的开发测试用例。

缺点：

1. 作为输入条件的原因和输出结果之间的因果关系，很难从规格说明书得到；
2. 此方法得到的用例数量规模大。

3.6 场景法

通过尝尽该描述的业务流程（业务逻辑），设计用例来遍历场景（路径），验证系统功能的正确性。 场景法重点是测试流程，因此每个流程用一个用例验证即可，流程测试没问题不代表系统功能没问题，还需要单步进行测试，结合前面的方法。

流程图：

• 矩形：步骤
• 菱形：判断条件
• 箭头：流向

3.6.1 ATM取款流程图

3.6.2 ATM取款场景设计

3.6.3 测试用例

3.7 错误推测法

3.7.1 概念

错误推测法是利用经验和直觉推测出出错的可能类型，列举出程序中所有可能的错误和容易发生错误情况的清单，根据清单设计测试用例。所谓凭经验，是指人们对过去所作测试结果的分析，对所揭示缺陷的规律性直觉的推测来发现缺陷。

该方法强调的是对被测试软件的需求理解以及设计实现的细节把握，当然还有个人的能力。那么显而易见地，这个方法的缺点就是太过依赖个人能力，难以系统化。因此，这个方法一般是作为测试用例设计的补充，而不是单独用来设计测试用例。在回归测试中应用较多。

错误推测法一般采用如下技术：

1. 有关软件设计方法和实现技术；
2. 有关前期测试阶段结果的知识；
3. 测试类似或相关系统的经验，了解以前这些系统曾在哪些地方出现缺陷；
4. 典型的产生错误的知识，如：被零除错误。

3.7.2 优点和缺点

优点：

1. 不用设计等价类的测试用例，将多个等价类的测试合成一个随机测试，可以以较少代码实现测试代码的编写；
2. 当等价类设计不确切或不完全时，测试会产生遗漏，而使用错误推测法则是按照概率进行等价类覆盖。不论存在多少个等价类，只要随机数据个数足够，就能保证各个等价类被覆盖的概率足够高，能够有效弥补等价类分法设计不充分的缺陷；
3. 采用错误推测法进行测试，每次执行测试时，测试的样本数据可能都不相同，执行次数愈多，错误暴露的概率愈大。

缺点：

1. 错误推测法中的随机数据很难覆盖到边界值，无法保证测试的充分性；
2. 错误推测法进行自动化测试的难度较大。有些程序很难用程序来自动验证，这使得程序结果的验证工作难度变大；
3. 当等价类的范围较小，这些范围较小的等价类被覆盖的概率也是很小的，错误推测法难以测试到；
4. 随机测试不可以代替常规的功能或非功能测试，因为其随意性大，没有一套完整严格的方法且并非有章可循的测试技术。

3.7.3 常见错误

1. 页面规范相关部分（跟公司甚至项目需求有关系）

• 命名、注释、字体、颜色、缩进等
• 文本框长度/范围限制
• 支持的浏览器、操作系统、jdk等做兼容性测试

2. 常识性问题

• 密码用密文
• 手机号码是11位，且是特定三位数开头
• 文本框自动忽略前后空格
• 支持模糊查询

3. 常见的异常测试情况

• 输入框不输入任何内容（为空）或者输入空格的情况
• 输入框输入非法字符
• 用户注销后，是否仍然能操作；再登录是否能成功
• 断电重连后是否能继续使用且信息未丢失

4. 功能相关的常见异常问题

• C++软件的内存泄漏、内存分配
• web程序的session失效问题
• JavaScript字符转义

3.8 综合策略

黑盒测试方法有等价类划分、边界值分析、决策表、因果图、场景法、错误推测法等，每种测试方法都有其各自的特点和适用场合。
软件测试专家Myers给出了黑盒测试方法中各种测试方法的使用策略：

1. 在任何情况下都必须使用边界值分析方法。经验表明，用这种方法设计的测试用例发现程序错误的能力最强；
2. 必要时使用等价类划分方法补充一些测试用例；
3. 用错误推测法再追加一些测试用例；
4. 对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度，如果没有达到要求的覆盖标准，应当再补充足够的测试用例；
5. 如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法。

对于功能性测试技术，可以根据如下条件进行选择：

1. 如果变量是独立的，则可以用定义域测试和等价类测试；
2. 如果变量不是独立的，可采用决策表测试；
3. 如果为单缺陷假设，则可采用边界值分析和健壮性测试；
4. 如果为多缺陷假设，可采用最坏情况测试、健壮最坏情况测试和决策表测试；
5. 如果程序包含大量例外处理，可采用健壮性测试和决策表测试；
6. 如果变量引用的是逻辑量，可采用等价类测试用例和决策表测试。

3.9 知识点总结

1. 等价类划分
2. 边界值分析
3. 决策表
4. 因果图
5. 场景法
6. 错误推测法
7. 综合策略

第4章 白盒测试

4.1 概述

白盒测试是把测试对象看作打开的盒子，允许测试人员利用程序内部的逻辑结构及有关信息设计或选择测试用例，通过在不同点检查程序状态确定实际状态是否与预期的状态一致。白盒测试测试软件产品的内部结构和处理过程，而不测试软件产品的功能，用于纠正软件系统在描述、表示和规格上的错误，是进一步测试的前提。

白盒测试分为静态测试和动态测试。

静态白盒测试是在不执行的条件下有条理地仔细审查软件设计、体系结构和代码，从而找出软件缺陷的过程，有时也称为结构分析。

动态白盒测试也称结构化测试，通过查看并使用代码的内部结构设计和执行测试。

白盒测试发展史

1. 单步调试、半手工、没有统一规范的评判标准；
2. 脚本测试，可评估；
3. 规范记录、解决了重复测试的问题；
4. 测试过程融入软件的整个开发全过程，解决了持续测试问题。

4.2 静态测试

静态方法是指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错。

此类过程中应用数据较少，主要过程为通过软件的静态性测试（即人工推断或计算机辅助测试）测试程序中运算方式、算法的正确性，进而完成测试过程，此类测试的优点在于能够消耗较短时间、较少资源完成对软件、软件代码的测试，能够较为明显地发现此类代码中出现的错误。静态测试方法适用范围较大，尤其适用于较大型的软件测试。

静态测试有代码检查、静态结构分析。

• 代码检查 主要是检查代码的可读性、逻辑表达的正确性、结构的合理性等方面。一般在编译和动态测试之前执行，具有走查、审查或伙伴检查等方法

• 静态结构分析 测试者通过使用测试工具，分析程序代码数据结构等控制逻辑，生成函数调用关系图等，用于检查函数之间的调用关系是否符合要求，是否存在递归调用，函数的调用是否过深，是否存在孤立的函数，用于检测系统是否存在结构缺陷。

4.3 动态测试

动态测试方法是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率、正确性和健壮性等性能。主要目的为检测软件运行中出现的问题，较静态测试方式相比，其被称为动态的原因即为其测试方式主要依赖程序的运用，主要为检测软件中动态行为是否缺失、软件运行效果是否良好。

4.4 逻辑覆盖

逻辑测试，又称为控制流覆盖，是一种按照程序内部逻辑结构和编码结构设计测试用例的测试方法。目的是要测试程序中的语句，判定(控制流能够分解为不同路径的程序点)，条件(形成判定的原子谓词)等。根据覆盖的标准不同，分为语句覆盖、判定覆盖、条件覆盖、条件判定覆盖、修正条件判定覆盖、增强条件判定覆盖、条件组合覆盖和路径覆盖等标准。

4.4.1 语句覆盖

语句覆盖又称为线覆盖面或段覆盖面。其含义是指设计若干个测试用例，使被测试程序中的每一条可执行语句至少被执行1次。

只统计可执行的代码行，不包括：头文件、注释、空行。语句覆盖通常被称为“最弱的覆盖”，由于不考虑各个分支的组合，不能发现判断中逻辑运算符的错误。

测试用例越少越好。

语句覆盖率 = 被测试到的语句数量 / 可执行的语句总数 * 100%

语句覆盖测试方法仅仪针对程序逻辑中的显式语句，无法测试隐藏条件，例子中的第一个逻辑运算符And误写成or，测试用例a=2，b=2，c=4仍能达到语句覆盖的要求，但是并未发现程序中的误写错误。

4.4.2 判定覆盖

判定覆盖(Decision Coverage，DC)，又称为分支覆盖或所有边覆盖，测试控制结构中布示表达式分别为真和假(例如if语句和while语句)。布尔型表达式被认为是一个整你.取值为true或 false，而不考虑内部是否包含“逻辑与”或者“逻排或”等操作符。

判定覆盖的基本思想，是指设计的测试用例使程序中每个判定至少分别取“真”分支和取“假”分支各一次，即判断真假值均被满足。

作为语句覆盖的超集，判定覆盖比语句覆盖要多几乎一倍的测试路径，当然也就具有比语句覆盖更强的测试能力。同样，判定覆盖也具有和语句覆盖一样的简单性，无须细分每个判定就可以得到测试用例。但是，往往大部分的判定语句是由多个逻辑条件组合而成(如判定语句中包含and、or、case)，判定覆盖仅仅判断其整个最终结果，而忽略判定内部的每个条件的取值情况，因此必然会遗漏部分测试路径。

4.4.3 条件覆盖

条件覆盖(Condition Coverage,CC)是设计测试用例，使每个判断中每个条件的可能取值至少满足1次。

条件覆盖设计例4.2的测试用例，针对a>0 and b＞0判定条件表达式，a＞0取值为“真”，记为T1；a＞0取值为“假”，记为F1；b＞0取值“真”，记为T2；b＞0取值为“假”，记为F2；条件表达式a>1 or c＞1，a＞1取值为“真”，记为T3；a＞1取值为“假”，记为F3；c>1取值为“真”，记为T4；c＞1取值为“假”，记为F4，如下表所示：

条件覆盖只能保证每个条件有1次为真、1次为假，而不考虑所有的判定结果。上表中的测试用例a=2，b=-1和测试用例a=—1，b=2满足了条件覆盖的测试用例，保证了a>0 and b＞0两个条件的可能值(True 和False)至少满足1次。但是，由于测试用例的所有判定结果都是False，并没有满足判定覆盖。所以条件覆盖不一定包含判定覆盖。

4.4.4 条件判定覆盖

条件判定覆盖的含义是通过设计足够的测试用例，使得判断条件中的所有条件可能至少执行1次取值，同时所有判断的可能结果至少执行1次。因此，条件判定覆盖的测试用例满足如下条件:

1. 所有条件可能至少执行1次取值。
2. 所有判断的可能结果至少执行1次。

条件判定覆盖能同时满足判定、条件两种覆盖标准，是判定和条件覆盖设计方法的交集。表面上，条件判定覆盖测试了所有条件的取值，但事实并非如此，往往某些条件掩盖了另一些条件，并没有覆盖所有的True 和False取值的条件组合情况，会遗漏某些条件取值错误的情况，为彻底地检查所有条件的取值，需要分解判定语句中给出的复合条件表达式，形成由多个基本判定嵌套的流程图。这样就可以有效地检查所有的条件是否正确了。

4.4.5 修正条件/判定覆盖

修正条件/判定覆盖(Modified Condrtion/Decision Coverage，MC/DC)，修正条件判定覆盖是判定中每个条件的所有可能结果至少出现1次，每个判定本身的所有可能结果也至少出现1次，并且每个条件都显示能单独影响判定结果。

1. 语句覆盖
2. 条件判定覆盖
3. 独立影响:其他条件相同，单一条件改变，结果改变。消除判定中的某些条件被其他条件掩盖的问题。

(1,3)说明条件a独立影响测试结果,(1,2)说明条件b独立影响测试结果

(2,4)说明条件a独立影响测试结果,(3,4)说明条件b独立影响测试结果

修正条件/判定覆盖继承了语句覆盖准则、条件判定覆盖准则、多重条件覆盖等判定条件，同时加入了新的判定条件。

例如，A or B 误写为 A and B。因为 T and T = T or T，且F and F = F or F，两者所得到的判定结果相同，由此可说明，虽然使用了条件判定覆盖(C/DC)准则来测试语句，一些错误不能检测出来。但如果使用MC/DC方法，就可以发现这样的错误。

MC/DC具有如下优点:

1. 继承了多重条件覆盖的优点;
2. 线性增加了测试用例的数量;
3. 对操作数及非等式条件变化反应敏感;
4. 具有更高的目标码覆盖率。

4.4.6 条件组合覆盖

条件组合覆盖(Multiple Condtion Coverage,MCC)的基本思想是设计测试用例使得判断中每个条件的所有可能至少出现1次，并且每个判断本身的判定结果也至少出现1次，与条件覆盖的差别是条件组合覆盖不是简单地要求每个条件都出现“真”与“假”两种结果，而是要求这些结果的所有可能组合都至少出现1次。

条件组合覆盖是一种相当强的覆盖准则，可以有效地检查各种可能的条件取值组合是否正确。它不但可覆盖所有条件可能取值的组合，还可覆盖所有判断的可取分支，但仍可能会漏掉有的路径，测试还不完全。

条件组合覆盖的条件划分：

条件组合覆盖测试用例：

条件组合覆盖准则满足判定覆盖、条件覆盖和判定/条件覆盖准则，但线性地增加了测试用例的数量，却不能保证所有的路径被执行测试，仍有可能有部分路径被遗漏，测试还不够全面。

4.4.7 路径覆盖

相对于其他逻辑覆盖法，路径覆盖的覆盖率最大。但随着程序代码复杂度的增加，测试工作量将指数增长。例如：包含10个if语句的代码，有2^10 = 1024个路径要测试，如果增加一个if，就有2^11 = 2048个路径要测试。

4.5 路径分析

路径覆盖会存在如下的困难：

上图中包含的不同执行路径数达5的20次方条，假定对每一条路径进行测试需要1毫秒，一年工作365 × 24小时，要想把所有路径测试完，需3170年。

测试中做到完全的路径覆盖是无法实现的，为解决这一难题只得把覆盖的路径数压缩到一定限度内。

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

4.6 控制结构测试

4.6.1 条件测试

条件测试是检查程序模块中所包含逻辑条件的测试用例设计方法。

条件的错误类型如下:

1. 布尔操作符错误(遗漏布尔操作符，布尔操作符多余或布尔操作符不正确)；
2. 布尔变量错误；
3. 布尔括号错误；
4. 关系操作符错误；
5. 算术表达式错误。

分支测试可能是最简单的条件测试策略，对于复合条件C的真分支、假分支以及C中的每个简单条件，都需要至少执行一次。

域测试(Domain Testing)通过分析程序输入域的数据，从有理表达式中导出3个或4个测试进行测试。

4.6.2 循环测试

假设N是通过循环的最大次数

1. 零次循环：从循环入口直接跳到循环出口
2. 一次循环：只有一次通过循环，用于查找循环初始值方面的错误
3. 两次循环：两次通过循环，用于查找循环初始值方面的错误
4. m次循环：m次通过循环，其中m＜n，用于检查多次才暴露的错误
5. 比最大循环数少一次
6. 最大循环数
7. 比最大循环数多一次

4.6.3 Z路径覆盖

路径覆盖是路径覆盖的一个变体。不考虑循环的形式和复杂度，也不考虑实际执行循环体的次数是多少，只考虑通过循环体零次和一次这两种情况，零次循环是指跳过循环体，从循环体的入口直接到循环体的出口。通过一次循环体是指检查循环初始值，根据简化循环的思路，循环要么执行，要么跳过，这和判定分支的效果一样。这样就大大减少了循环的个数，将循环结构简化为选择结构。

4.7 数据流测试

4.7.1 变量定义/使用分析

变量定义和使用有如下三种缺陷:

1. 变量被定义，但从来没有使用
2. 使用的变量没定义
3. 变量在使用之前定义了两次

4.8 程序插桩

它是借助于往被测程序中插入操作来实现测试目的的方法，即向源程序中添加一些语句，实现对程序语句的执行、变量的变化等情况进行检查。

4.8.1 插桩位置

插桩位置主要解决的是在哪儿插的问题，为此将程序按“块”划分，探针主要插桩在其“路口”的位置，主要考虑以下5种位置：

1. 程序的开始，即程序块的第1个可执行语句之前；
2. for、do、do-while、do until 等循环语句开始、结束处；
3. if、else if、else及end if等条件语句各分支开始、结束处；
4. 函数、过程、子程序调用语句之后；
5. 程序的出口，return、call之后。

4.8.2 插桩策略

插桩策略主要解决的是如何在程序中植入探针的问题，包括植入的位置和方法。主要考虑块探针和分支探针。

1. 块探针设计策略：又称“顺序块”，它是若干个相连顺序语句的序列集合。在程序的执行过程中，它具有线性特征。若该线性块的第一条语句被执行，则整个线性块的语句都执行了。这样仅在线性块的开始或末尾处插入一个探针即可，避免了对每条语句都进行的冗余插装操作。
2. 分支探针策略：所有进行true或false判断的语句。它是统计分支覆盖率的探针测试点。

4.8.3 插桩过程

在被测试的源程序中植入探针函数的桩，即函数的声明。而插桩函数的原型在插桩函数库中定义。在目标文件连接成可执行文件时，则必须连入插桩函数库。探针函数是否被触发，就要依据插桩选择记录文件了，要求不同的覆盖率测试会激活不同的插桩函数。

4.9 测试方法综述

4.10 知识点总结

1. 白盒测试概念
2. 静态测试
3. 动态测试
4. 逻辑覆盖（语句覆盖、判定覆盖、条件覆盖、条件判定覆盖、修正条件/判定覆盖、条件组合覆盖、路径覆盖）

第5章 性能测试

5.1 基本概念

性能测试是通过测试工具模拟多种正常、峰值以及异常负载条件，对系统的各项性能指标进行测试。

软件性能是指在一定条件下系统行为表现是否符合需求规格的指标，如传输的最长时限、传输的错误率、计算的精度、响应的时限和恢复时限等。

性能测试的目的是发现软件系统中存在的性能瓶颈，优化软件运行效率。

性能测试主要包括以下几个方面：

1. 评估系统的能力
   评估系统的能力是指测试软件系统所得到的负荷数据和响应时间等数据，用于验证软件系统的稳定性和可靠性。

2. 识别体系中的弱点
   通过将软件系统受控的负荷增加到一个极端的水平，确定体系的瓶颈或薄弱的地方，并进行修复。

3. 系统调优
   长时间的运行系统将导致系统失败，揭示系统中隐含的问题或冲突，进行调整，优化系统性能。

5.1.1 响应时间

响应时间是指应用系统从请求发出开始到客户端接收到数据所消耗的时间，响应时间分解为网络传输时间、应用延迟时间、数据库延迟时间和呈现时间等。

5.1.2 并发用户数

多个用户对系统发出了请求或进行了操作，其请求或者操作可以是相同的，也可以是不同的，下面给出估算并发用户数的公式:

C = nL/T

C：是平均的并发用户数； n：是登录会话的数量； L：是登录会话的平均长度； T：指考察的时间段长度。

并发用户数峰值的计算方式：

C ̂≈ C+ 3√C

该公式是假设用户登录会话符合泊松分布而估算得到的。

eg.

一个软件系统每天大约有400个用户访问，用户在一天之内有8小时使用该系统，从登录到退出该系统的平均时间为4小时。
C=400×4/8=200
C ̂≈200+3×√200=242

课后思考： 我们课程一共有80/89位同学参会与，假设使用自己搭建的禅道系统完成一次作业需要90分钟（即每个用户登录会话时长90min），当天完成作业，可用于完成作业的时段为4小时。估算并发用户数和峰值，写明推倒过程。

5.1.3 吞吐量

吞吐量是指单位时间内成功在网络上传输数据量的总和，用请求数/秒或页面数/秒来衡量，吞吐量有如下两个作用:

1. 协助设计性能测试场景，以及衡量性能测试场景是否达到了预期设计目标，在设计性能测试场景时，根据吞吐量数据测试场景中的事务发生频率等。
2. 协助分析性能瓶颈。吞吐量是性能瓶颈的重要表现形式。因此，有针对性地测试吞吐量，可以尽快定位到性能瓶颈所在位置。

吞吐量和并发用户数之间存在一定的联系，计算公式如下所示：

F=(Nvu×R)/T

F：吞吐量；
Nvu：虚拟用户个数；
R：每个虚拟用户发出的请求数量；
T：性能测试所用的时间。

5.1.4 性能计数器

性能计数器是描述服务器或操作系统性能的一些数据指标，具有“监控和分析”作用。例如，Windows系统的内存数、进程数、系统缓存等都是常见的性能计数器。

5.1.5 资源利用率

资源利用率与性能计数器关系密切，是指系统中各种资源的使用状况，在通常的情况下，资源利用率需要结合响应时间变化曲线、系统负载曲线等各种指标进行综合分析。

资源利用率计算公式如下所示：
资源利用率 = 资源的实际使用 / 总的资源可用量

5.2 性能测试分类

5.2.1 负载测试

负载测试(Load Testing)是测试系统在资源超负荷情况下的表现，以发现设计上的错误或验证系统的负载能力，评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力，负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外，负载测试还要评估性能特征，例如，响应时间、事务处理速率和其他与时间相关方面的特征。

负载测试通过大量重复的行为、模拟不断增加的用户数量等方式观察不同负载下系统的响应时间和数据吞吐量、系统占用的资源(如CPU、内存)等，检验系统特性，发现系统可能存在的性能瓶颈、内存泄露等问题。

负载测试的加载方式通常有如下几种：

1. 一次加载 一次性加载某个数量的用户，在预定的时间段内持续运行。例如，早晨上班的时间。访问网站或登录网站的时间非常集中，基本属于扁平负载模式。

2. 递增加载 有规律地逐渐增加用户，每几秒增加一些新用户，交错上升。这种负载方式的测试容易发现性能的拐点，即性能瓶颈。

3. 高低突变加载 某个时间用户数量很大，突然降到很低，过一段时间又突然加到很高，反复几次。借助这种负载方式的测试容易发现资源释放、内存泄露等问题。

4. 随机加载方式 由随机算法自动生成某个数量范围内变化的、动态的负载，这种方式可能是和实际情况最为接近的一种负载方式。虽然不容易模拟系统运行出现的瞬时高峰期，但可以模拟系统长时间高位运行过程的状态。

5.2.2 压力测试

压力测试(Stress Test)也称强度测试，是在强负载(大数据量、大量并发用户等)下的测试，通过查看应用系统在峰值使用情况下的状态发现系统的某项功能隐患、系统是否具有良好的容错能力和可恢复能力。压力测试涉及时间因素，用来测试那些负载不定的，或交互式的，实时的以及过程控制等程序。压力测试分为高负载下的长时间(如24小时以上)的稳定性压力测试和极限负载情况下导致系统崩溃的破坏性压力测试。

压力测试也被看作是负载测试的一种特殊情况，即高负载下的负载测试，或者说压力测试采用负载测试技术。

5.2.3 可靠性测试

软件可靠性是软件质量的一个重要标志。IEEE将软件可靠性定义为系统在特定的环境下，在给定的时间内无故障地运行的概率，软件可靠性涉及软件的性能、功能性、可用性、可服务性、可安装性、可维护性等多方面特性，是对软件在设计、生产以及在它所预定环境中具有所需功能的置信度的一个度量。

可靠性测试一般伴随着强壮性测试，是评估软件在运行时的可靠性，通过测试确认平均无故障时间、故障发生前的平均工作时间或因故障而停机的时间在一年中应不超过多少时间。可靠性测试强调随机输入，并通过模拟系统实现，很难通过实际系统的运行来实现。

5.2.4 数据库测试

数据库测试一般包括数据库的完整测试和数据库容量测试。

1. 数据库完整测试 数据库完整测试是指测试关系型数据库中的数据是否完整，用于防止对数据库的意外破坏，提高了完整性检测的效率。

   数据库完整性原则如下所示:
   (1) 实体完整性
   实体完整性规定主码的任何属性都不能为空，通过主码的唯一性标识实体。
   (2) 参照完整性
   参照完整性是对关系间引用数据的一种限制，参照完整性通过外码来体现，外码必须等于对应的主码或者为空。
   (3) 用户自定义完整性
   例如，通过用户自定义完整性将员工的年龄限制在20～35岁之间，如果用户输入的年龄不在这个范围之内，就违反了“用户自定义完整性”的原则。

2. 数据库容量测试 数据库容量测试是指数据库是否能存储数据量的极限，还用于确定在给定时间内能够持续处理的最大负载。

5.2.5 安全性测试

安全性测试是测试系统在应付非授权的内部/外部访问、非法侵入或故意的损坏时的系统防护能力，检验系统是否有能力使可能存在的内/外部伤害或损害的风险限制在可接受的水平内，可靠性通常包括安全性，但是软件的可靠性不能完全取代软件的安全性，安全性还涉及数据加密、保密、存取权限等多个方面。

进行安全性测试时，需要设计一些试图突破系统安全保密措施的测试用例，检验系统是否有安全保密漏洞，验证系统的保护机制是否能够在实际中不受到非法侵入，安全性测试采用建立整体的威胁模型，测试盟出漏洞、信息泄露、错误处理、身份验证和授权错误等。

在安全测试过程中，测试者扮演攻击系统的角色，一般采用如下方法：

1. 尝试截取、破译、获取系统密码。
2. 让系统失效、瘫痪，将系统制服，使他人无法访问，自己非法进入。
3. 试图浏览保密的数据，检验系统是否有安全保密的漏洞。

5.2.6 兼容性测试

兼容性是指某个软件能够稳定地工作在某个操作系统/平台之中，就说这个软件对这个操作系统/平台是兼容的；其次，在多任务操作系统中，几个同时运行的软件之间如果能够稳定地工作，就认为这几个软件之间兼容性较好，否则就是兼容性不好；另外，就是软件数据的共享，几个软件之间无需复杂的转换，即可方便地共享相互之间的数据，也称为兼容。

软件兼容性测试要检查软件能否在不同组合的环境下正常运行，或者软件之间能否正常交互和共享信息。作为衡量软件好环的重要指标之一，软件兼容性用于保证软件在不同环境中都能按照用户期望的方式进行交互。

软件兼容性测试分为软件兼容性和数据兼容性，具体如下所示：

1. 软件兼容性 软件兼容性是指平台的兼容性、浏览器兼容性和应用软件之间的兼容性。其中，平台兼容性用于检查哪些功能依赖于系统的调用，这些调用是否是某个平台或版本所独有的，是否在不同平台上有差异，然后标识出来，进行兼容性测试。 由于许多软件在升级时会做出很多修改，需要检查使用方式是否和老版本兼容，这种操作性方面的兼容并非要求必须完全一样，而是让已经习惯了老版本操作的用户能很快适应新版本的变化。

2. 数据兼容性 数据兼容性主要是指数据能否共享等。如通信协议的软件 兼容情况审查版本升级后，对网络通信协议也进行了升级，就要检查和老版本的通信协议是否一致，需要标识出来进行兼容性测试。

5.2.7 可用性测试

可用性是系统正常运行的能力和程度，在一定程度上也是系统可靠性的表现，一般用如下公式表示：

可用性 = 平均正常工作时间 / (平均正常工作时间 + 平均修复时间)

影响可用性的因素有如下几方面：

1. 不充分的测试。
2. 更改管理问题。
3. 缺少在线监视和分析。
4. 操作错误。
5. 弱编码。
6. 与外部服务或应用程序的交互。
7. 不同的操作条件(使用级别更改、峰值重载)。
8. 异常事件(安全性失败、广播风暴）。
9. 硬件故障(硬盘、控制器、网络设备、服务器、电源、内存和CPU)。
10. 环境问题(电源、冷却、火、洪水、灰尘、自然灾害)。

提高可用性的办法：

1. 使用集群 集群包括至少将两个系统连接到一起，使两个服务器能够像一台机器那样工作。集群是高可用性的关键技术，因为它是在出现失败时，提供即时故障转移的应用程序服务。

2. 使用网络负载平衡 网络负载平衡通过检测某服务器失败后，自动将通信量重新分发给仍然运行的服务器。

3. 使用服务级别协议 定义期望的服务级别。可用性指标一般要求达到4个或5个“9”，例如，“该应用程序应每周运行7天，每天24小时，年可用性为99.99%”是指全年不能正常工作的时间仅仅只有52分钟，不足1个小时。

4. 提供实时的监视 连续监视操作工作负荷和失败数据，对于发现趋势和改善服务至关重要。

5. 使用数据备份

6. 检查所有安全计划 安全性是确保应用程序服务只对有资格的用户可用，还意味着保护应用程序使用的所有分布式组件和资源。

5.3 性能测试步骤

1. 制定目标和分析系统；
2. 选择测试度量的方法；
3. 采用相关技术和工具；
4. 制定评估标准；
5. 设计测试用例；
6. 运行测试用例；
7. 分析测试结果。

5.3.1 制定目标和分析系统

性能测试计划中的第一步都会制定目标和分析系统。只有明确目标和了解系统构成，才会澄清测试范围，知道在测试中要掌握什么样的技术，明确目标是指确定客户需求和期望、实际业务需求和系统需求。

5.3.2 选择测试度量的方法

经过第一步的制定目标和分析系统后，接下来进行软件度量，收集系统相关的数据。度量包括如下内容：

1. 制定规范；
2. 制定相关流程、角色、职责；
3. 制定改进策略；
4. 制定结果对比标准。

5.3.3 采用相关技术和工具

性能测试是通过测试工具模拟大量用户操作，对系统增加负载，所以必须熟练地掌握和运用测试工具，由于性能测试工具一般基于不同的软件系统架构实现，脚本语言也不同，只有经过工具评估才能选择符合现有软件架构的性能测试工具。确定测试工具后，需要组织测试人员学习测试工具，培调相关的测试技术。

5.3.4 制定评估标准

任何测试的目的是确保软件符合预先规定的目标和要求。通常性能测试有线性投射、分析模型、模仿和基准4种模型技术用于评估。

1. 线性投射 通过大量过去的、扩展的或者将来可能发生的数据组成散布图，利用这个图表不断和系统的当前状况进行对比。

2. 分析模型 通过预测响应时间，将工作量的数据和系统本质关联起来，进行分析模型。

3. 模仿 模仿实际用户的使用方法，反复测试系统。

4. 基准 定义测试作为标准，与后面进行的测试结果进行对比。

5.3.5 设计测试用例

设计测试用例的原则是受最小的影响，提供最多的测试信息。设计测试用例的目标一次尽可能包含多个测试要素，这些测试用例必须是测试工具可以实现的，不同的测试场景将测试不同的功能。

5.3.6 运行测试用例

通过性能测试工具运行测试用例，需要不同的测试环境以及不同的机器配置。

5.3.7 分析测试结果

运行测试用例后收集相关信息，进行数据统计分析，找到性能瓶颈。通过排除误差和其他因素，让测试结果体现真实情况。不同的体系结构，分析测试结果的方法也不同，B/S结构的系统通常会分析网络带宽、流量对用户操作响应的影响，而C/S结构可能更关心系统整体配置对用户操作的影响。

5.4 Web测试

基于Web的软件架构系统的测试与传统的软件测试不同，不但需要检查和验证网站是否按照设计的要求运行，还要测试网站是否适合不同用户的浏览器显示，并要从最终的使用用户的角度进行安全性和可用性的各项测试。

5.4.1 Web系统体系结构

1. 客户端表示层，一般就是Web浏览器，用于从位于Web服务器下载数据，到本地的浏览器中执行。
2. 应用服务器层，处理应用中的所有业务逻辑，包括对数据库的访问等工作，该层具有良好的可扩充性，可以随着应用的需要任意增加服务的数目。
3. 数据中心层，主要由数据库组成，用于存放数据。

5.4.2 用户界面测试

1. 导航测试
   导航描述了用户在不同的连接页面之间跳转的方式。导航测试需要考虑下列问题，从而决定一个Web应用系统是否易于导航。
   (1) 导航是否直观？
   (2) Web系统的主要部分是否可通过主页存取？
   (3) Web系统是否需要站点地图、搜索引擎或其他的导航帮助？
   (4) Web应用系统的页面结构、导航、菜单、连接的风格是否一致？
   (5) 确保用户凭直觉就知道Web应用系统里面是否还有内容，内容在什么地方

2. 图形测试
   在Web应用系统中，适当的图形不但能起到广告宣传的作用，而且具有美化页面的功能。一个Web应用系统的图形包括图片、动画、边框、颜色、字体、背景、按钮等。
   (1) 确保用于链接的图形都有明确的用途，能清楚地说明某件事情。
   (2) 验证所有页面字体的风格是否一致。
   (3) 背景颜色应该与字体颜色和前景颜色相搭配。
   (4) 图片的大小和质量也是一个很重要的因素，一般采用JPG或GIF格式压缩。

3. 内容测试
   内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。
   (1) 信息的正确性是指信息是可靠的还是误传的。例如，在商品价格列表中，错误的价格可能引起财务问题。
   (2) 信息的准确性是指是否有语法或拼写错误。例如，Word中的“拼音与语法检查”功能。
   (3) 信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口。例如，有些网站页面中的“相关文章列表”。

4. 整体界面测试
   整体界面是指整个Web应用系统页面结构的设计，它给用户的是一个整体感觉。例用户进行调查的过程，一般Web应用系统采取在主页上做一个调查问卷的形式来得到最终用户的反馈信息。

5.4.3 功能测试

功能测试作为黑盒测试的一个方面，用于检查实际软件的功能是否符合用户的需求。功能测试包括链接测试、表单测试、Cookies测试和数据库测试。

1. 链接测试
   链接是Web应用系统的一个主要特征，它是在页面之间切换和指导用户去一些未知地址页面的主要手段。链接测试可分为如下三个方面:
   (1) 测试所有链接是否按指示确实链接到了该链接的页面。
   (2) 测试所链接的页面是否存在。
   (3) 最后保证Web应用系统上没有孤立的页面。所谓孤立页面，是指没有链接指向该页面，只有知道正确的URL地址才能访问。

2. 表单测试
   当用户给Web应用系统管理员提交信息时，需要使用表单操作，如用户注册、登录、信息提交等，在这种情况下，必须测试提交操作的完整性，以校验提交给服务器的信息的正确性，例如，用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等，如果使用了默认值，则要检验默认值的正确性。表单测试需要验证服务器是否能正确保存这些数据，而且后台运行的程序能否正确解释和使用这些信息。

3. Cookies测试
   Cookies通常用来存储用户信息，是让网站服务器把少量数据储存到客户端的硬盘或内存，或者是从客户端的硬盘读取数据的一种技术。Cookies通常用来存储用户信息和用户在某些应用系统的操作，如用户ID、密码、浏览过的网页、停留的时间等信息。当用户下次再来到该网站时，网站通过读取Cookies得知用户的相关信息，从而做出相应的动作，如果Web应用系统使用了Cookies，就必须检查Cookies是否能正常工作。测试的内容可包括Cookies是否起作用，是否按预定的时间进行保存，以及刷新对Cookies有什么影响等。

4. 数据库测试
   关系型数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。一般情况下，数据库测试可能发生两种错误，数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确造成的，输出错误主要是由于网络速度或程序设计等问题引起的。

5.4.4 性能测试

1. 链接速度测试
   用户连接到Web应用系统的速度根据上网方式的变化而变化，或许是电话拨号，或许是宽带上网。下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长(例如超过5s)，用户就会因没有耐心等待而离开。另外，有些页面有超时的限制，如果响应速度太慢，用户可能还来不及浏览内容就需要重新登录了，而且，连接速度太慢还可能引起数据丢失，使用户得不到真实的页面。

2. 负载测试
   负载测试是模拟实际软件系统所承受的负载条件的系统负荷，通过不断加载(如逐渐增加模拟用户的数量)或其他加载方式来观察不同负载下系统的响应时间和数据吞吐量系统占用的资源(如CPU、内存)等，以检验系统的行为和特性，用于发现系统可能存在的性能瓶颈、内存泄露、不能实时同步等问题。例如，Web应用系统能允许多少个用户同时在线？如果超过了这个数量，会出现什么现象？Web应用系统是否能处理大量用户对同个页面的请求？

3. 压力测试
   压力测试是在强负载(大数据量，大量并非用户等)下的测试，检查应用系统在峰值使情况下的操作行为，从而有效地发现系统的某项功能隐患，系统是否具有良好的容错能和可恢复能力(如24小时以上)的稳定性压力测试和极限负载情况下导致系统崩溃的坏性压力测试。

5.4.5 兼容性测试

1. 平台兼容性测试
   市场上有很多操作系统，例如Windows、Unix、Macintosh、Linux等。Web应用系统的最终用户究竟使用哪一种操作系统，取决于用户系统的配置。这样就可能会发生兼容性问题。即，同一个应用在某些操作系统下能正常运行，但在另外一些操作系统下可能会运行失败。因此，在Web系统发布之前，需要在各种操作系统下对Web系统进行兼容性测试。

2. 浏览器兼容性测试
   浏览器是Web客户端的核心构件，来自不同厂商的浏览器对Java、JavaScript、ActiveX有不同的支持。例如，Active X是Microsoft的产品，是为IE而设计的。JavaScript是Netscape的产品，Java是Sun的产品等等。不同的浏览器对安全性的设置不一样。网页的框架和层次结构风格在不同的浏览器中也有不同的显示，甚至根本不显示。

3. 分辨率兼容性测试
   分辨率的测试是为了页面版在不同的分辨率模式下能正常显示，字体符合要求而进行的测试。现在常见的分辨率是1280×1024、1027×768、800×600。对于常见的分辨率，测试必须保证测试通过，对于其他分辨率，根据具体情况进行取舍。

4. 组合兼容性测试
   最后需要进行组合测试。理想的情况是，系统能在所有机器上运行，这样就不会限制将来的发展和变动。

5.4.6 安全性测试

安全性测试是检验在系统中已存在的安全性保密性措施是否发挥作用。一般情况下，网络软件的安全评估包括以下内容：

1. 检验和测试网络软件中涉及数据传输各部分的配置对安全的影响；
2. 会话跟踪是否足够；
3. 是否正确使用了加密技术；
4. 变量限制的设定；
5. 服务器端执行程序中的安全漏洞；
6. HTML源码中是否有敏感的信息或没有必须出现的信息。

Web应用系统的安全性测试区域主要如下所示:

1. 用户身份认证 Web应用系统基本采用先注册、后登录的方式。因此，必须测试有效和无效的用户名和密码，注意是否大小写敏感、次数的限制，是否不登录而直接浏览某个页面等。
   (1) 用户ID选定的复杂程度是否足够。
   (2) 拒绝登录是否可靠(用户经n次登录失败后会遭遇拒绝登录)。
   (3) 用户密码是否留在客户端处。
   (4) 登录出错提示是否正确。
   (5) 密码设定及管理的规定是否足够严格。

2. 用户授权
   (1) Cookie的使用是否正确。
   (2) 高速缓存数据的处理是否安全。
   (3) 跟踪逻辑是否合理。
   (4) 接管会话的发生率。

3. 信息外泄
   信息外泄主要是检查HTML源码中是否有信息外泄的情况(如改版的情况、说明、主机的内部信息等)。

4. 字段变量的控制
   (1) 是否去除了缓冲存储溢出(如检测过长URL引起的缓冲存储溢出)。
   (2) SQL语句变量植入的控制。
   (3) 是否严格控制在字段中嵌入系统指令。

5. 会话时间控制
   Web应用系统是否有超时的限制，也就是说，用户登录后在一定时间内(例如15min)没有单击任何页面，是否需要重新登录才能正常使用。
   (1) 是否允许“返回”(会话结束后)。
   (2) 是否允许单一会话(同一用户不能同时多次登录)。
   (3) 是否及时清除或处理失效用户的登录认证。
   (4) 空机超时控制。

6. 高速缓存控制
   为了保证Web应用系统的安全性，日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。
   (1) 不允许任何敏感资料存放在终端机。
   (2) 不允许任何可以重开会话的会话跟踪资料存储。

7. 服务器软件逻辑
   服务器端的脚本常常构成安全漏洞，要测试没有经过授权就不能在服务器端放置和编辑脚本的问题。
   (1) 网络软件执行环境。
   (2) 网络软件与数据库的连接。
   (3) 内部代理服务器的监测。
   (4) 应用过程界面，所有指令是否获得许可。

8. 用户端软件脆弱性检测

9. 用户端的各种设定

10. 错误处理
    (1) 出错提示是否含有敏感资料或消息。
    (2) 出错提示含有揭示数据库及中介软件的资料是否暴露所使用的软件。

11. 第三方软件的安全程度
    (1) 所有中介软件是否涉及已公布于众的安全漏洞。
    (2) 网络软件所使用的通信协议。
    (3) 软件的安全设定。

12. 网络软件的管理
    (1) 是否订立明确的管理条款、程序。
    (2) 进入管理网页的控制是否严密。
    (3) 远程登录管理的安全性。

13. 数据加密
    (1) 加密的力度是否够。
    (2) 用户密码的存储是否安全。
    (3) 密匙管理以及密匙撤销是否立即生效。

5.5 知识点总结

1. 性能测试基本概念（响应时间、并发数、吞吐量）
2. 负载测试
3. 压力测试
4. 可靠性测试
5. 数据库测试
6. 安全性测试
7. 兼容性测试
8. 可用性测试
9. 性能测试步骤
10. Web测试

第6章 软件测试流程

6.1 软件测试流程概述

软件测试流程与软件开发流程类似，也包括测试计划、测试设计、测试开发、测试执行和测试评估几个部分。

1. 测试计划： 根据用户需求报告中关于功能要求和性能指标的规格说明书，定义相应的测试需求告，使得随后所有测试工作都围绕着测试需求来进行。同时适当选择测试内容，合理安排测试人员、测试时间及测试资源等。
2. 测试设计： 测试设计是指将测试计划阶段制定的测试需求分解、细化为若干个可执行的测试过，并为每个测试过程选择适当的测试用例，保证测试结果的有效性。
3. 测试执行： 执行测试开发阶段建立的自动测试过程，并对所发现的缺陷进行跟踪管理。测试执行一般由单元测试、集成测试、系统测试、验收测试以及回归测试等步骤组成。
4. 测试评估： 根据缺陷跟踪报告，对软件的质量和开发团队的工作进度及效率进行评价。

6.2 测试需求

测试需求根据市场/产品需求定义、分析文档和相关技术文档，输出《可测试性需求说明书》和《测试规格》等报告。

软件需求： 需求是产品必须完成的功能以及必须具备的品质。它详细定义了信息流和界面，功能需求，设计要求和限制，测试准则和质量保证要求。

需求包括：功能性需求、非功能性需求和限制条件。比如：性能需求，质量标准，或者设计限制。

非功能性需求：界面、软件环境和硬件环境等。

主要工作：

1. 阅读需求文档（原型图），同时也是文档测试。
2. 需求评审
3. 测试需求分析
4. 提取功能点

参与者： 产品经理，架构师，项目经理，测试/质量管理员(很多公司把这个统称为QA)，开发

需求文档检查： 从需求的完整性、明确性、必要性、可测性、一致性、可修改性和优先级出发。

1. 测试需求说明书是否满足了用户提出的每一项要求，实现需求的完整性
2. 检查需求文档的用词、用语问题，实现需求的明确性
3. 检查需求规格说明书对需求覆盖是否正确，实现需求的必要性
4. 软件使用环境的描述是否清晰，实现文档的完整性
5. 需求编号是否正确，实现文档的可修改性
6. 需求是否相互矛盾，实现需求的一致性
7. 检查软件系统允许的输入和预期的输出，实现需求的可测试性
8. 软件系统的性能需求有没有得到清晰地描述，实现需求的完整性
9. 需求的关注重点和实现的先后顺序是否清晰地被描述出来，实现需求的优先级
10. 对软件系统的约束条件是否完整的进行描述，实现需求的可测试性

eg. 注册功能描述

eg. 登录功能描述

6.3 测试计划

测试计划以测试需求为基础，分析产品的总体测试策略，输出《产品总体测试策略》等报告。

参与者： 测试组长

测试计划规定测试任务、安排人员、预见风险，指导测试，实现测试的目标。

1. 周期和进度？
2. 资源配置？
3. 质量管理？
4. 测什么？
5. 什么时候开始？
6. 怎么测？
7. 什么时候结束？

6.3.1 测试计划要点

1. 测试范围 确定各阶段的测试范围、技术约束等，以及测试成功的标准和要达到的目标。

2. 测试策略 开发有效的测试模型，决定黑盒测试和白盒测试、人工测试和自动化测试的比重等。

3. 测试资源 确定测试所需要的时间和资源，对人员、硬件和软件等资源进行组织和分配。

4. 进度安排 分解项目工作结构，并采用时限图、甘特图等方法制定时间/资源表。

5. 风险及对策 测试可能存在的风险分析，对风险进行回避、监控、管理，采用变更管理和控制等。

6.3.2 步骤

1. 了解项目需求，明确测试对象 根据项目组提供的需求说明书、界面原型、开发计划等文档，了解项目需求，明确本次测试的任务。

2. 制定测试策略 测试的策略包括宏观的测试策略和微观的测试策略战术，为了设计出好的测试策略，需要了解软件的结构、功能分布、各模块对用户的重要程度等，从而决定测试的重点、优先次序、测试的覆盖方式等。设计测试用例时，应尽可能用最少的测试用例发现最多的缺陷，尽可能用精简的测试用例覆盖最广泛的状态空间，还要考虑哪些测试用例使用自动化的方式实现，哪些使用人工方式验证等。

3. 确定资源 确定测试所需的人力资源、硬件、软件、工具等资源。

4. 安排测试进度 测试的进度安排需要结合项目的开发计划、产品的整体计划进行考虑，还要考虑测试本身的各项活动进行安排。把测试用例的设计、测试环境的搭建、测试报告的编写等活动列入进度安排表。

5. 估计计划风险 一般可能碰到的风险是项目计划变更、测试资源不能及时到位等问题。制定测试计划时应根据项目的实际情况进行评估，并制定出合理、有效的应对策略，对于项目计划的变更，可以考虑建立更加流畅的沟通渠道，让测试人员能及时了解到变更的情况，以及变更的影响，从而可以做出相应的改变。

6.3.3 测试计划的5W1H

1. What - 对象 (1) 测什么?
   (2) 做什么类型的测试?
   (3) 被测软件的特点是什么？
   (4) 测试什么版本？

2. Why - 原因 (1) 为什么要做性能测试？ (2) 为什么测试重点是这个部分？

3. Who - 参与人 (1) 软件的最终用户是谁？ (2) 谁来设计测试用例？ (3) 谁来执行测试用例？ (4) 谁来评审？

4. When - 时间 (1) 什么时间开始测试？ (2) 什么时间结束测试？ (3) 什么时候提交缺陷报告？

5. Where - 地点 (1) 在哪里进行测试？ (2) 在什么环境下测试？

6. How - 方式 (1) 如何进行测试？ (2) 如何掌控风险？ (3) 如何控制进度？

6.4 测试设计

测试设计建立在测试计划书的基础上，根据测试大纲、测试内容及测试的通过准则，将测试需求转换成测试用例的过程，用于描述测试环境、测试执行的范围、层次和用户的使用场景以及测试输入和预期的测试输出等信息，输出《产品或者版本总体测试方案》等报告。

6.4.1 测试设计内容

1. 制定测试的技术方案，确认各个测试阶段采用的测试技术、测试环境和平台，以及选择什么样的测试工具。其中，系统测试中的安全性、可靠性、稳定性、有效性等是测试技术方案的内容重点。
2. 设计测试用例，根据产品需求分析、系统设计等规格说明书，在测试技术方案的基础上设计具体的测试用例。
3. 根据测试的目的和任务，以及测试用例的特性和属性(优先级、层次、模块等)设计测试用例，从而构成执行某个特定测试任务的测试用例集合（组），如基本测试用例组、专用测试用例组、性能测试用例组、其他测试用例组等。
4. 根据所选择的测试工具，将自动化测试的测试用例转换为测试脚本。
5. 根据所选择的测试平台以及测试用例所要求的特定环境，进行服务器、网络等测试环境的设计。

软件测试设计中，需要考虑如下要点。

1. 所设计的测试技术方案是否可行、是否有效、是否能达到预期的测试目标；
2. 所设计的测试用例是否完整、边界条件是否考虑、其覆盖率能达到的百分比；
3. 所设计的测试环境是否和用户的实际使用环境比较接近。

6.4.2 测试用例属性

设计测试用例主要根据测试用例的以下属性，并结合测试用例的编号、标题、描述(条件、步骤、期望结果)等进行测试用例管理。

1. 优先级 测试用例的优先级越高，被执行的时间越早、执行的频率越多。由最高优先级的测试用例组来构成基本验证测试，每次构建软件包时，都要被执行一遍。

2. 目标性 根据不同的目标设计测试用例。有的测试用例是为主要功能而设计，有的则为系统的负载而设计。

3. 所属范围 根据测试用例所属不同的组件或模块进行管理。

4. 关联性 测试用例一般和软件产品特性相联系，多数情况下验证某个产品的功能。

5. 阶段性 根据不同的测试阶段，如单元测试、集成测试、系统测试、验收测试等设计测试用例，便于得出该阶段的测试覆盖率。

6. 状态性 测试用例有不同的状态，只有被激活的测试用例才被运行。

7. 时效性 针对同样功能，可能所用的测试用例不同，是因为不同的产品版本在产品功能、特性等方面的要求不同。

8. 所有者 测试用例还包括由谁、在什么时间创建，又由谁、在什么时间修改等。

6.5 测试执行

6.5.1 单元测试

单元测试即为将整个软件分解为各个单元，随后对单元进行测试。此类测试策略的优点在于所需分析数据较少，且针对性较强，程序开发者于开发过程中可通过操作经验明确出现问题的大致区域，随后针对此类问题对相关单元展开分析，进行问题排查。但需注意的是，某些程序中无具体单元驱动程序，即单个单元无法有效驱动，易出现问题，若针对此类软件展开测试，需重点注意此类分解单元。

单元测试是对软件组成单元进行测试。其目的是检验软件基本组成单位的正确性。测试的对象是软件设计的最小单位：模块。

• 测试阶段：编码后
• 测试对象：最小模块（函数、类、模块）
• 测试人员：白盒测试工程师或开发工程师
• 测试依据：代码和注释+详细设计文档
• 测试方法：白盒测试
• 测试内容：模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试

单元测试针对模块进行测试,主要有以下5个任务：

• 模块接口：全局量定义一致性，调用参数
• 局部数据结构:数据的定义和使用
• 边界条件：循环边界和输入边界
• 执行路径：关键路径和重要路径
• 错误处理：非合理输入和系统错误

6.5.2 集成测试

集成测试与单元测试相反，原理为将部分需测试部分作为整体进行集成，随后针对此类集成部分进行测试。测试要求为此类被测试集成题应具有一定的结构，且属于非渐增方式集成。对于较大软件而言，集成测试方式较单元测试方式而言较为繁琐，多数大型软件的测试皆采取渐增方式进行测试。渐增测试方式为集成测试方式的衍生，其能够按照不同次序对软件进行测试，日常测试中，常将两类方式进行集成测试，随后按照次序展开选择。

集成测试也称联合测试、组装测试，将程序模块采用适当的集成策略组装起来，对系统的接口及集成后的功能进行正确性检测的测试工作。主要目的是检查软件单位之间的接口是否正确。

• 测试阶段：一般单元测试之后进行
• 测试对象：模块间的接口
• 测试人员：白盒测试工程师或开发工程师
• 测试依据：单元测试的模块+概要设计文档
• 测试方法：黑盒测试与白盒测试相结合
• 测试内容：模块之间数据传输、模块之间功能冲突、模块组装功能正确性、全局数据结构、单模块缺陷对系统的影响

集成测试的主要任务是解决以下5个问题：

1. 将各模块连接起来，检查模块相互调用时，数据经过接口是否丢失；
2. 将各个子功能组合起来，检查能否达到预期要求的各项功能；
3. 一个模块的功能是否会对另一个模块的功能产生不利的影响；
4. 全局数据结构是否有问题，会不会被异常修改；
5. 单个模块的误差积累起来，是否被放大，从而达到不可接受的程度。

集成测试主要测试软件的结构问题，因此测试建立在模块接口上，多为黑盒测试，适当辅以白盒测试，在集成测试过程中，尤其要注意关键模块测试，关键模块一般具有如下一个或多个特征：同时对应几条需求功能；具有高层控制功能；复杂且易出错；有特殊的性能要求。

集成测试的主要目的是验证组成软件系统各模块的接口和交互作用，分为非增量式集成和增量式集成等。

1. 非增量式测试方法 非增量式测试方法又名大棒集成方法，采用一步到位的方法来测试，将所有模块按程序结构图连接起来，当作整体进行测试。非增量式测试是集中一次进行测试，虽然可能发现很多错误，但为每个错误定位和纠正非常困难，并且在改正一个错误的同时又可能引入新的错误，从而更难断定出错的原因和位置。因此，非增量式集成测试只能适合在规模较小的应用系统中使用。

2. 增量式测试方法 增量式测试方法是指测试从一个模块开始，测试成功后，再添加一个模块进行测试，如此进行。增量式测试采用逐步集成和逐步测试的方法，其测试范围是逐步增大，从而易手错误的定位和纠正。因此，增量式集成测试比非增量式集成测试有比较明显的优越性。

增量式测试方法具有自顶向下、自底向上以及三明治集成测试方法。

增量式测试方法的比较：

1. 自顶向下测试是逐步求精，让测试者了解系统的框架，但需要提供驱动模块。由于驱动模块可能不能反映真实情祝，因此测试可能具有不充分性。
2. 自底向上测试采用驱动模块模拟了所有调用，但是需要等到只有最后一个模块加入才能知道整个系统的框架。
3. 三明治集成测试采用自顶向下、自底向上的结合方式，并采取持续集成策略，有助于尽早发现缺陷，提高工作效率。

6.5.3 系统测试

一般情况下，系统测试采用黑盒法来进行测试的，以此来检查该系统是否符合软件需求。本阶段的主要测试内容包括健壮性测试、性能测试、功能测试、安装或反安装测试、用户界面测试、压力测试、可靠性及安全性测试等。为了有效保证这一阶段测试的客观性，必须由独立的测试小组来进行相关的系统测试。另外，系统测试过程较为复杂，由于在系统测试阶段不断变更需求造成功能的删除或增加，从而使程序不断出现相应的更改，而程序在更改后可能会出现新的问题，或者原本没有问题的功能由于更改导致出现问题。所以，测试人员必须进行回归测试。

将软件系统看成是一个系统的测试。包括对功能、性能以及软件所运行的软硬件环境进行测试。时间大部分在系统测试执行阶段。

• 测试阶段：集成测试通过之后
• 测试对象：整个系统（软、硬件）
• 测试人员：黑盒测试工程师
• 测试依据：需求规格说明文档
• 测试方法：黑盒测试
• 测试内容：功能、界面、可靠性、易用性、性能、兼容性、安全性等

6.5.4 验收测试

验收测试是最后一个阶段的测试操作，在软件产品投入正式运行前的所要进行的测试工作。和系统测试相比而言，验收测试与之的区别就只是测试人员不同，验收测试则是由用户来执行这一操作的。验收测试的主要目标是为向用户展示所开发出来的软件符合预定的要求和有关标准，并验证软件实际工作的有效性和可靠性，确保用户能用该软件顺利完成既定的任务和功能。通过了验收测试，该产品就可进行发布。

但是，在实际交付给用户之后，开发人员是无法预测该软件用户在实际运用过程中是如何使用该程序的，所以从用户的角度出发，测试人员还应进行α测试或β测试这两种情形的测试。α测试是在软件开发环境下由用户进行的测试，或者模拟实际操作环境进而进行的测试。α测试主要是对软件产品的功能、局域化、界面、可使用性以及性能等等方面进行评价。而β测试是在实际环境中由多个用户对其进行测试，并将在测试过程中发现的错误有效反馈给软件开发者。所以在测试过程中用户必须定期将所遇到的问题反馈给开发者。

验收测试是部署软件之前的最后一个测试操作。它是技术测试的最后一个阶段，也称为交付测试。验收测试的目的是确保软件准备就绪，按照项目合同、任务书、双方约定的验收依据文档，向软件购买方展示该软件系统满足原始需求。

• 测试阶段：系统测试通过之后
• 测试对象：整个系统（包括软硬件）。
• 测试人员：主要是最终用户或者需求方。
• 测试依据：用户需求、验收标准
• 测试方法：黑盒测试
• 测试内容：同系统测试(功能...各类文档等)

6.5.5 α测试

软件交付使用之后，用户在使用过程中常常会发生各种问题，如操作使用方法的误解、异常的数据组合等。α测试和β测试用于发现可能只有最终用户才能发现的错误。

α测试是在开发环境或公司内部用户在模拟实际操作的环境下，由用户参与的测试，主要用于评价软件产品的功能、可靠性、性能等，特别是对于软件界面和易用性进行测试。

α测试不能由程序员或测试员完成。

6.5.6 β测试

只有当α测试达到一定的可靠程度时，才能开始β测试。与α测试不同，开发者通常不在测试现场，在β测试中，由用户记下遇到的所有缺陷，向开发者报告。测试着重于产品的支持性测试，包括文档、客户培训等。

α测试与β测试的区别：

1. 测试的场所不同：α测试是指把用户请到开发方的场所来测试，β测试是指在一个或多个用户的场所进行的测试。
2. 测试的环境不同：α测试的环境是受开发方控制的，用户的数量相对比较少，时间比较集中。β测试的环境是不受开发方控制的，用户数量相对比较多，时间不集中。
3. 测试的时间不同：α测试先于β测试执行。通用的软件产品需要较大规模的β测试，测试周期比较长。

当软件通过最后阶段的测试 - 验收测试或质量全面评估测试，从研发阶段来看，工程发布(Engineering Release，ER)将作为一个里程碑，随后将软件推向市场。进行α测试后，到达了有限可用(Limited Available，LA)里程碑(LA是指由于测试覆盖率不能达到100%，软件功能并不能全部使用)。LA之后所发现的缺陷，再通过β测试，到达全面可用(General Available，GA)里程碑，此时所有功能可以全部使用。

6.6 回归测试

微软测试表明，一般修复3～4个错误会产生一个新的错误，新代码的加入，除了本身含有错误外，还有可能对原有的代码带来影响。因此，软件一旦发生变化，必须重新设计测试用例，检测软件功能，确定修改达到预期目的。回归测试是一种验证已变更系统的完整性与正确性的测试技术，用于确保修改没有带来副作用。回归测试输出《产品或版本测试报告》等报告。

这里要注意的是我们bug修订后不只要重新测试这个bug，还要重新测试与这个功能点甚至是代码块相关的部分。

回归测试与一般测试有如下不同：

1. 测试用例来源 一般测试根据系统规格说明书和测试计划进行，测试用例都是新的。而回归测试可能是更改了的规格说明书、修改过的程序和需要更新的测试计划。

2. 测试范围 一般测试目标是检测整个程序的正确性，而回归测试目标是检测被修改的相关部分的正确性以及它与系统原有功能的整合。

3. 时间分配 一般测试所需时间通常是在软件开发之前预算，而回归测试所需的时间(尤其是修正性的回归测试)往往不包含在整个产品进度表中。

4. 开发信息 一般测试可以随时获取关于开发的知识和信息。而回归测试可能会在不同的地点和时间进行，需要保留开发信息，以保证回归测试的正确性。

5. 完成时间 由于回归测试只需测试程序的一部分，完成所需时间通常比一般测试少。

6. 执行频率 回归测试往往要多次进行，一旦系统经过修改就需要进行回归测试。

6.6.1 测试流程

1. 在测试策略制定阶段制定回归测试策略。
2. 确定回归测试版本。
3. 发布回归测试版本，按照回归测试策略执行回归测试。
4. 回归测试通过，关闭缺陷跟踪单。
5. 回归测试不通过，缺陷单返回到开发人员处，等待重新修改，再次作回归测试。

6.6.2 什么情况下需要回归测试

1. 开发修订了bug 影响较小，很容易获悉影响范围，以及回归测试用例的选择。

2. 版本发布 每次版本的发布或者更新，都必须保障原有功能的正确性以及新功能的正确性；因此回归测试的范围必须是全面的。

3. 新功能提测 新上线的功能，我们首先要保障新功能的正确性；另外保障它没有影响与其相关联的功能，即保障其相关功能的正确性。

修订bug和新功能可以只回归相关部分，版本发布需要回归整个产品。

6.6.3 测试用例设计方法

1. 选择全部测试用例 选择完全重复测试，是指将所有的测试用例全部再完全地执行一遍，以确认问题修改的正确性和修改后周边是否受到影响。缺点是由于要把用例全部执行一遍，因此会增加项目成本，也会影响项目进度，所以很难完全执行。

   优点： 这其实是最安全的方法，再测试全部用例具有最低的遗漏回归错误的风险，它几乎可以应用到任何情况下，且几乎不需要进行分析。
   缺点： 测试成本极其高昂
   策略： 定时执行全部回归（自动测试脚本）以及上线前执行。

2. 基于风险选择测试用例 根据缺陷的严重性来进行测试，基于一定的风险标准，从测试用例库中选择回归测试包。选择最重要、关键以及可疑的测试，略过那些次要的、例外的测试用例或功能相对非常稳定的模块。

3. 基于操作剖面选择测试用例 如果测试用例是基于软件操作面开发的，测试用例的分布情况将反映系统的实际使用情况。回归测试所使用的测试用例个数由测试预算确定，可以优先选择针对最重要或最频繁使用功能的测试用例，尽早发现对可靠性有最大影响的故障。

4. 覆盖修改法 针对发生错误的模块设计测试用例，只能验证本模块是否还存在缺陷，但不能保证周边与它有联系的模块不会因为这次改动而引发缺陷在修改范围内的测试，其效率最高，风险也最大，因为它无法保证这个修改是否影响了别的功能，该方法一般用于软件结构设计的耦合度较小的状态下使用。

5. 周边影响法 除了执行出错模块的用例之外，把周边和它有联系的模块的用例也执行一遍，保证回归测试的质量。

6. 指标达成法 根据一定的覆盖率指标选择回归测试。例如，规定修改范围内的测试是90%，其他范围内的测试阅值为60%，该方法一般是在相关功能影响范围难以界定时使用。

7. 再测试修改部分 通过相依性识别软件的修改情况，将回归测试局限于被改变的模块，只选择相应的测试用例来做回归测试，此策略风险最大，但成本也是最低。

   优点： 工作量小
   缺点： 这个方法对测试人员的要求还是很高的，需要测试人员不仅要熟悉业务，还要能看懂代码且了解代码结构。这么来看这个方法风险还是很高的。
   策略： 要求开发修订bug后在缺陷管理工具上直接标明影响范围，测试只做审核和实施。

6.7 测试评估

6.7.1 测试评估活动

1. 审查测试全过程 在测试跟踪的基础上对测试项目进行全过程、全方位的审视，检查测试计划、测试用例是否得到执行，检查测试是否有漏洞。

2. 对当前状态的审查 测试的审核包括软件缺陷和过程中没解决的各类问题。对产品目前存在的缺陷进行逐个分析，了解其对产品质量影响的程度，决定所有测试内容是否完成，测试的覆盖率是否达到要求以及产品质量是否达到标准，从而确定是否停止测试。

6.7.2 缺陷分析方法

1. 缺陷分布分析 缺陷分布分析是横向分析方法，针对一个或多个缺陷属性进行分布分析，生成缺陷数量与缺陷属性的函数。

缺陷分布分析涉及的因素如图:

2. 缺陷趋势分析 缺陷趋势分析用于描述一段时间内缺陷的动态变化情况。其中，收敛趋势图是其中常用的一种。它是指在一定周期内遗留缺陷的变化情况，用于反映项目的质量变化情况，作为产品发布的一个重要参考。

• 发现缺陷：测试人员在某一测试周期内新发现的缺陷总数。
• 修复缺陷：测试人员在某一测试周期内修复的缺陷总数。
• 遗留缺陷：在某一测试试用周期结束时刻未关闭的缺陷总数。

3. 注入矩阵分析 软件缺陷有“注入阶段”和“发现阶段”两个阶段，缺陷注入-发现矩阵如下表：

矩阵的每行表示该阶段或活动发现的各阶段产生的缺陷数；矩阵的每列表示该阶段或活动注入的缺陷泄漏到后续各环节的缺陷数。

表中的参数解释如下：
缺陷移除率=(本阶段发现的缺陷数/本阶段注入的缺陷数)×100%
如需求阶段一共注入了21个缺陷，需求评审时只发现了4个，设计过程中发现了13个，编码和单元测试阶段发现了2个，还有2个直到系统测试阶段才被发现。这样，需求阶段的缺陷移除率 4 / 21 * 100% = 19%。它反映的是该活动阶段的缺陷清除能力。

缺陷泄露率=(下游发现的本阶段缺陷数/本阶段注入的缺陷总数)×100%
"缺陷泄漏率"，即有多少本阶段注入的缺陷没有在本阶段发现而是被泄漏到后阶段环节才被发现。它反映的是本阶段质量控制措施落实的成效。

编码过程的缺陷大部分依赖系统测试发现。很显然，项目开发过程中的单元测试和集成测试活动开展不够深入。我们可以进一步分析这些系统测试出来的测试缺陷，是不是可以被更前端的评审/测试/设计讨论活动所替代。

需求阶段注入的缺陷绝大部分是在设计阶段发现的。这大概是目前国内公司大部分项目的现实，需求不稳定、不明确，很多东西需要在设计过程中才能明确下来。从分析结果也可以看出，在设计评审时，也需要重新审视需求规格说明书，必要时可利用需求追踪矩阵辅助发现上游需求的缺陷。

通过注入矩阵分析，可以看出软件开发各个环节的质量，找到最需要改进的环节，从而有针对性地制定改进措施。实际规划“缺陷注入一发现矩阵”时，可对缺陷的发现活动和注入阶段进行细分或粗分。

6.8 知识点总结

1. 测试需求
2. 测试计划
3. 测试设计
4. 测试执行（单元测试、集成测试、系统测试、验收测试、回归测试）
5. 测试评估（缺陷分布分析、缺陷趋势分析、注入矩阵分析）

第7章 软件测试自动化

7.1 自动化测试和手工测试

随着计算机日益广泛的应用，软件变得越来越庞大和复杂，软件测试的工作量也随之增大。自动化测试采用软件测试工具实现手工测试难以实现的功能，减轻了手工测试的工作量，减少了测试的执行时间，提高了测试效率。

自动化测试往往适合以下场合:

1. 软件需求变动不频繁 当软件需求变动过于频繁，势必多次更新测试用例以及测试脚本，而自动化测试适合于需求中相对稳定的模块。

2. 项目周期足够长 自动化测试需求的确定、自动化测试框架的设计、测试脚本的编写与调试需要相当长的时间来完成，因此需要项目周期足够长。

3. 测试脚本重复使用的情况 负载测试需要模拟大量并发用户，手工测试往往难以完成。

手工测试与自动化测试对比:

当然，自动化测试也有如下的局限性，不能取代手工测试。

1. 测试用例的设计：测试人员的经验和对错误的猜测能力是工具不可替代的；
2. 界面和用户体验测试：审美观和心理体验是不可替代的；
3. 正确性检查：对是否的判断、逻辑推理能力是工具不可替代的；
4. 手工测试比自动化测试发现的缺陷更多；
5. 不能用于测试周期很短的项目；
6. 不能保证100%的测试覆盖率；
7. 不能测试不稳定的软件；
8. 不能测试软件易用性。

7.2 自动化测试发展历程

自动化测试发展经历了机械方式实现人工重复操作、统计分析的自动测试、面向目标的自动测试技术和智能应用的自动测试技术等4个阶段。

1. 机械方式实现人工重复操作 自动化测试的最初研究主要集中在如何采用自动方法实现和替代人工测试中烦琐和机械重复的工作，将人工设计测试数据改变成自动生成测试数据的方法，对程序进行动态执行检测。此时的自动测试活动只是软件测试过程中出现的偶然行为，虽然在一定程度上可提高某些测试行为的效率，简化测试人员的工作，但对整体的测试过程并无太大的提高。

2. 统计分析的自动测试 该阶段有针对性地引入了不同的测试准则和测试策略，指导测试的自动化过程以及对测试的结果进行评估。

3. 面向目标的自动测试技术 面向目标的自动测试技术并不是机械和随机地发现错误的活动。由于各种高性能的算法，如进化计算和人工智能等领域被引入到自动测试技术中，因此测试具有很强的目的性。

4. 智能应用的自动测试技术 引入能力成熟度模型后，不同的自动测试等级成为测试能力的一个衡量依据。

7.3 测试成熟度模型

测试成熟度模型(Testing Maturity Model，TMM) 描述了测试的过程，分为初始级、定义级、集成级、管理和测量级和优化、预防缺陷和质量控制级五个等级。

7.3.1 初始级

TMM初始级软件测试过程的特点是测试过程无序，有时甚至是混乱的，几乎没有妥善定义的。在初始级中，软件测试与调试常常被混为一谈，软件开发过程中缺乏测试资源、工具以及训练有素的测试人员，初始级的软件测试过程没有定义成熟度目标。

7.3.2 定义级

TMM的定义级中，测试已具备基本的测试技术和方法，软件的测试与调试已经明确地区分开，这时，测试被定义为软件生命周期中的一个阶段，它紧随在编码阶段之后，由于测试计划往往在编码之后才制定，因此显然有悖于软件工程的要求。

TNM的定义级中需实现的3个成熟度目标：制定测试与调试目标，启动测试计划过程，制度化基本的测试技术和方法。

1. 制定测试与调试目标
   软件组织必须区分软件开发的测试过程与调试过程，识别各自的目标、任务和活动。正确区分这两个过程是提高软件组织测试能力的基础。与调试工作不同，测试工作是种有计划的活动，可以进行管理和控制。这种管理和控制活动需要制定相应的策略和政策，以确定和协调这两个过程。

   制定测试与调试目标包含以下5个子成熟度目标：
   (1) 分别形成测试组织和调试组织，并有经费支持。
   (2) 规划并记录测试目标。
   (3) 规划并记录调试目标。
   (4) 将测试和调试目标形成文档，并分发至项目涉及的所有管理人员和开发人员。
   (5) 将测试目标反映在测试计划中。

2. 启动测试计划过程
   测试计划作为过程可重复、可定义和可管理的基础，包括测试目的、风险分析、测试策略以及测试设计规格说明和测试用例，此外，测试计划还应说明如何分配测试资源，如何划分单元测试、集成测试、系统测试和验收测试。

   启动测试计划过程包含以下5个子目标：
   (1) 建立组织内的测试计划组织，并予以经费支持。
   (2) 建立组织内的测试计划政策框架，并予以管理上的支持。
   (3) 开发测试计划模板并分发至项目的管理者和开发者。
   (4) 建立一种机制，使用户需求成为测试计划的依据之一。
   (5) 评价、推荐和获得基本的计划工具，并从管理上支持工具的使用。

3. 制度化基本的测试技术和方法
   应用基本的测试技术和方法，并说明何时和怎样使用这些技术、方法和支持工具，基本的测试技术和方法的制度化有如下两个子目标：
   (1) 在组织范围内成立测试技术组，研究、评价和推荐基本的测试技术和测试方法，推荐支持这些技术与方法的基本工具。
   (2) 制定管理方针，以保证在全组织范围内一致使用所推荐的技术和方法。

7.3.3 集成级

在TMM的集成级中，测试不再是编码阶段之后的阶段，已被扩展成与软件生命周期融为一体的一组活动。测试活动遵循V字模型，测试人员在需求分析阶段便开始着手制定测试计划，根据用户需求建立测试目标和设计测试用例。软件测试组织提供测试技术培训，测试工具支持关键测试活动。

集成级要实现如下4个成熟度目标：建立软件测试组织，制定技术培训计划，软件生命周期测试，控制和监视测试过程。

1. 建立软件测试组织 测试组完成与测试有关的活动，包括制定测试计划，实施测试执行，记录测试结果，制定与测试有关的标准和测试度量，建立测试数据库、测试重用、测试跟踪以及测试评价等。

   建立软件测试组织要实现以下4个子目标:
   (1) 建立全组织范围内的测试组，并得到上级管理层的领导和各方面的支持，包括经费支持。
   (2) 定义测试组的作用和职责。
   (3) 由训练有素的人员组成测试组。
   (4) 建立与用户或客户的联系，收集他们对测试的需求和建议。

2. 制定技术培训计划
   为高效率地完成好测试工作，测试人员必须经过适当的培训。

   制定技术培训规划有以下3个子目标。
   (1) 制定组织的培训计划，并在管理上提供包括经费在内的支持。
   (2) 制定培训目标和具体的培训计划。
   (3) 成立培训组，配备相应的工具、设备和教材。

3. 软件生命周期测试 提高测试成熟度和改善软件产品质量都要求将测试工作与软件生命周期中的各个阶段联系起来。

   该目标有以下4个子目标：
   (1) 将测试阶段划分为子阶段，并与软件生命周期的各阶段相联系。
   (2) 基于已定义的测试子阶段，采用软件生命周期V字模型。
   (3) 制定与测试相关的工作产品的标准。
   (4) 建立测试人员与开发人员共同工作的机制。这种机制有利于促进将测试活动集成与软件生命周期中。

4. 控制和监视测试过程 软件组织采取如下措施，制定测试产品的标准，制定与测试相关的偶发事件的处理预案，确定测试里程碑，确定评估测试效率的度量，建立测试日志等。

   控制和监视测试过程有以下3个子目标： (1) 制定控制和监视测试过程的机制和政策。
   (2) 定义、记录并分配一组与测试过程相关的基本测量。
   (3) 开发、记录并文档化一组纠偏措施和偶发事件处理预案，以备实际测试严重偏离计划时使用。

在TMM的定义级，测试过程中引入计划能力，在TMM的集成级，测试过程引入控制和监视活动。两者均为测试过程提供了可见性，为测试过程持续进行提供保证。

7.3.4 管理和测量级

在TMM的管理和测量级中，测试活动包括软件生命周期中各个阶段的评审、审查和追查，使得测试活动涵盖软件验证和确认活动。因为测试是可以量化并度量的过程，根据管理和测量级要求，与软件测试相关的活动，如测试计划、测试设计和测试步骤，都要经过评审。为了测量测试过程，建立了测试数据库，用于收集和记录测试用例，记录缺陷并按缺陷的严重程度划分等级。此外，所建立的测试规程应能够支持软件组中对测试过程的控制和测量。

管理和测量级有3个要实现的成熟度目标：建立组织范围内的评审程序，建立测试过程的测量程序和软件质量评价。

1. 建立组织范围内的评审程序
   软件组织应在软件生命周期的各阶段实施评审，以便尽早有效地识别，分类和消除软件中的缺陷。

   建立评审程序有以下3个子目标:
   (1)管理层要制定评审政策，支持评审过程。
   (2)测试组和软件质量保证组要确定并文档化整个软件生命周期中的评审目标、评审计划、评审步骤以及评审记录机制。
   (3)评审项由上层组织指定。培训参加评审的人员，使他们理解和遵循机的评政策、评审步骤。

2. 建立测试过程的测量程序 测试过程的测量程序是评价测试过程质量，改进测试过程的基础，对监视过程至关重要。测量包括测试进展、测试费用、软件错误和缺陷数据以及产品测量等。

   测试测量程序有以下3个子目标：
   (1) 定义组织范围内的测试过程、测量政策和目标。
   (2) 制定测试过程测量计划，测量计划中应给出收集、分析和应用。
   (3) 应用测量结果制定测试过程改进计划。

3. 软件质量评价 软件质量评价内容包括定义可测量的软件质量属性，定义评价软件工作产品的质量目标等项工作。

   软件质量评价有2个子目标：
   (1) 管理层、测试组和软件质量保证组要制定与质量有关的政策、质量目标和软件产品质量属性。
   (2) 测试过程应是结构化、已测量和已评价的，以保证达到质量目标。

7.3.5 优化、预防缺陷和质量控制级

本级的测试过程是可重复、可定义、可管理的，因此软件组织优化调整和持续改进测试过程。测试过程的管理为持续改进产品质量和过程质量提供指导，并提供必要的基础设施。

优化、预防缺陷和质量控制级有以下3个要实现的成熟度目标：

1. 应用过程数据预防缺陷 此时的软件组织能够记录软件缺陷，分析缺陷模式，识别错误根源，制定防止缺陷再次发生的计划，提供跟踪这种活动的办法，并将这些活动贯穿于全组织的各个项目中。

   应用过程数据预防缺陷的成熟度子目标如下：
   (1) 成立缺陷预防组。
   (2) 识别和记录在软件生命周期各阶段引入的软件缺陷和消除的缺陷。
   (3) 建立缺陷原因分析机制，确定缺陷原因。
   (4) 管理、开发和测试人员互相配合制定缺陷预防计划，防止已识别的缺陷再次发生。缺陷预防计划要具有可跟踪性。

2. 采用统计采样技术测量组织的自信度，测量用户对组织的信赖度以及设定软件可靠性目标来推进测试过程
   支持统计质量控制的子目标如下:
   (1) 软件测试组和软件质量保证组建立软件产品的质量目标，如产品的缺陷密度、组织的自信度以及可信赖度等。
   (2) 测试管理者要将这些质量目标纳入测试计划中。
   (3) 培训测试组学习和使用统计学方法。
   (4) 收集用户需求，以建立使用模型。

3. 优化测试过程 优化测试过程在测试成熟度的最高级，以能够量化测试过程。这样就可以依据量化结果来调整测试过程，不断提高测试过程能力，并且软件组织具有支持这种能力持续增长的基础设施。基础设施包括政策、标准、培训、设备、工具以及组织结构等。

   优化测试过程包含如下内容：
   (1) 识别需要改进的测试活动。
   (2) 实施改进。
   (3) 跟踪改进进程。
   (4) 不断评估所采用的与测试相关的新工具和新方法。
   (5) 支持技术更新。

   测试过程优化所需子成熟度目标包括如下内容：
   (1) 建立测试过程改进组，监视测试过程并识别需要改进的部分。
   (2) 建立适当的机制，以评估改进测试过程能力和测试成熟度的新工具和新技术。
   (3) 持续评估测试过程的有效性，确定测试终止准则。

7.3.6 TMM 5个阶段总结

1. 测试和调试没有区别，除了支持调试外，测试没有其他目的。
2. 测试的目的是为了表明软件能够工作。
3. 测试的目的是为了表明软件能够正常工作。
4. 测试的目的不是要证明什么，而是为了把软件不能正常工作的预知风险降低到能够接受的程度。
5. 测试成为了自觉的约束，不用太多的测试投入便能产生低风险的软件。

7.4 自动化测试体系

7.4.1 自动化测试体系

自动化测试体系包括测试用例管理、分析报告、开发环境、运行环境和代码管理等。

开发环境包括开发语言、库程序、驱动程序和开发工具；测试用例管理包括测试用例的定义、设置、分类和组合运行；分析报告是指对于测试工具的运行和长期走势进行的报告；运行环境是指软件测试工具的安装配置；代码管理是指存储和编译。

7.4.2 自动化测试流程

自动化测试流程包括可行性分析、测试工具选型、设计测试框架、设计测试用例、开发测试脚本、使用测试脚本和维护测试资产等。

7.5 测试工具介绍

7.5.1 测试管理工具

测试管理工具一般具有如下功能：

1. 测试过程生成器
2. 测试用例管理
   (1) 提供用户界面，用于管理测试。
   (2) 对测试进行整理以方便使用和维护。
   (3) 启动并管理测试执行，运行用户选择的测试。
   (4) 提供与捕获/回放及覆盖分析工具的集成。
   (5) 提供自动化的测试报告和相关文档的编制。
3. 缺陷跟踪管理
   (1) 迅速提交和更新故障报告。
   (2) 具有选择地自动通知用户对故障状态的修改。
   (3) 具有对数据的安全访问。

常用工具：

1. TestDirector(大而全)
2. jira(简单好用)
3. 禅道(简单好用)
4. bugzilla(功能简单)
5. svn(代码和文档管理工具)
6. git，同svn，但是多分支管理比svn好
7. QTP(HP)

7.5.2 接口测试工具

1. Jmeter(开源)
2. postman
3. SoapUI

推荐使用 jmeter 和 postman

jmeter是一款100%纯Java编写的免费开源的工具，它主要用来做性能测试，相比loadrunner来说，它内存占用小，免费开源，轻巧方便、无需安装，越来越被大众所喜爱。

Postman是谷歌的一款接口测试插件，它使用简单，支持用例管理，支持get、post、文件上传、响应验证、变量管理、环境参数管理等功能，可以批量运行，并支持用例导出、导入。

7.5.3 性能测试工具

1. jmeter：基于java平台的性能开源测试工具，其实也很强大，而且比较好用。
2. ab(apache bench)：apache自带的压力测试工具。
3. loadrunner(HP)：是一种预测系统行为和性能的负载测试工具。
4. LoadUI：一款开源的压力测试工具，支持图形化。
5. Siege：一款开源的压力和指标测试工具。

zhangnadeMacBook-Pro:~ zoey$ ab -n 1000 -c 200 http://zentao.zrise.top/
This is ApacheBench, Version 2.3 <$Revision: 1879490 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking zentao.zrise.top (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests


Server Software:        nginx  #web服务器
Server Hostname:        zentao.zrise.top   #请求的URL主机名
Server Port:            80  #请求端口

Document Path:          /  #请求路径
Document Length:        141 bytes  #HTTP响应数据的正文长度

Concurrency Level:      200  #并发用户数，这是我们设置的参数之一
Time taken for tests:   11.284 seconds  #所有这些请求被处理完成所花费的总时间 单位秒
Complete requests:      1000  #总请求数量，这是我们设置的参数之一
Failed requests:        333  #表示失败的请求数量
   (Connect: 0, Receive: 0, Length: 333, Exceptions: 0)
Non-2xx responses:      333  #HTTP响应数据的头信息中含有2XX以外的状态码
Total transferred:      803921 bytes  #所有请求的响应数据长度总和。包括每个HTTP响应数据的头信息和正文数据的长度
HTML transferred:       143997 bytes #所有请求的响应数据中正文数据的总和，也就是减去了Total transferred中HTTP响应数据中的头信息的长度
Requests per second:    88.62 [#/sec] (mean)  #吞吐量，计算公式：Complete requests/Time taken for tests  总请求数/处理完成这些请求数所花费的时间
Time per request:       2256.800 [ms] (mean)   #用户平均请求等待时间，计算公式：Time token for tests/（Complete requests/Concurrency Level）。处理完成所有请求数所花费的时间/（总请求数/并发用户数）
Time per request:       11.284 [ms] (mean, across all concurrent requests)  #服务器平均请求等待时间，计算公式：Time taken for tests/Complete requests，正好是吞吐率的倒数。也可以这么统计：Time per request/Concurrency Level
Transfer rate:          69.57 [Kbytes/sec] received   #表示这些请求在单位时间内从服务器获取的数据长度，计算公式：Total trnasferred/ Time taken for tests，这个统计很好的说明服务器的处理能力达到极限时，其出口宽带的需求量。

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       37  365 509.4    144    3159
Processing:    37 1574 1144.0   2021    3346
Waiting:       37 1573 1143.7   2021    3346
Total:        124 1939 1258.4   2387    5874

Percentage of the requests served within a certain time (ms)
  50%   2387  #50%的请求在88ms内返回
  66%   2720
  75%   2834
  80%   2917
  90%   3303
  95%   3796
  98%   4765
  99%   4853
 100%   5874 (longest request)

7.5.4 白盒测试工具

目前的白盒测试工具主要支持C、Visual C++、Java、Visual J++等程序开发语言。白盒测试工具一般针对被测源程序进行测试，测试所发行的故障可以定位到代码级。

根据测试工具工作原理的不同，白盒测试工具分为静态分析工具和动态测试工具。

静态分析工具：

1. 代码覆盖率分析器和代码测量器
2. 一致性检查
3. 接口分析
4. 类型分析

动态测试工具：

1. 功能确认与接口测试
2. 性能与内存分析

常见工具：

1. jtest：java语言的单元测试框架
2. JUnit：验证java的工具
3. cppunit：跨平台的c++单元测试框架
4. gtest：跨平台的c++单元测试框架
5. PhpUnit：Php
6. BoundsChecker：C++,Delphi API和OLE错误检查、指针和泄露错误检查、内存错误检查
7. TrueTime：C++,Java,Visual Basic 代码运行效率检查、组件性能的分析

7.5.5 网络测试工具

1. Ixia：也是对网络设备进行性能和压力测试工的平台
2. firebug：抓包工具
3. Fiddler：抓包工具
4. wireshark：数据包抓取分析和回放测试工具
5. tc：网络丢包和试验模拟工具，非常好用
6. iperf：用来测试tcp和udp的网络质量
7. tcpping：工具工作在 TCP 层，通过发送伪造的 TCP SYN 包并侦听来自服务器或中间设备返回的 SYN/ACK 或 RST

7.5.6 Web安全测试工具

1. appscan：算是用的非常多的一款工具了，扫描后能够将绝大部分的漏洞找出来。
2. Netsparker Community Edition：可以检测SQL注入和跨页脚本事件,还能提供解决方案。
3. Websecurify：这是个简单易用的开源工具，此程序还有一些人插件支持，可以自动检测网页漏洞。运行后可生成多种格式的检测报告。
4. Wapiti：这是一个用Python编写的开源的工具，可以检测网页应用程序，探测网页中存在的注入点。
5. N-Stalker Free Version：可一次检测100个以上的页面，包括跨页脚本的检测。
6. skipfish：这是一个轻量级的安全测试工具，处理速度很快，每秒可处理2000个请求。
7. Scrawlr：HP的一款免费软件，可检测SQL注入漏洞。
8. Watcher：这个是Fiddler的插件，可在后台静默运行，可检测跨域提交等。
9. WebScarab：这个实际上是一个代理软件，有很多功能，可以检测XSS跨站脚本漏洞、SQL注入漏洞等。

7.6 如何选择测试工具

当前市场上的测试工具很多，每个测试工具在不同环境有各自的优点和缺点。如何选择最佳的测试工具，主要依赖于系统工程环境以及组织特定的其他需求和标准。因此，选择自动化测试工具应从以下几方面考虑：

1. 测试工具的集成能力。 确定测试工具与系统的构架、编程环境等兼容性。
2. 确定被测程序管理数据的方式。 了解被测试程序管理数据的方式，确定自动测试工具如何支持对数据的验证。
3. 确定测试类型。 了解工具的测试类型，不同测试类型的测试工具功能差距较大。
4. 确定项目进度。 测试工具是否影响测试进度。
5. 确定项目预算。 根据成本/效益分析，确定所投入的总成本与获益之间的关系。

7.7 Postman

7.7.1 优点

1、支持用例管理 2、支持get、post、文件上传、响应验证、变量管理、环境参数管理等功能 3、支持批量运行 4、支持用例导出、导入 5、支持云端保存用例【付费用户】

7.7.2 新建项目

直接点击左边栏上面的添加目录图标来新增一个根目录，这样就等于新建了一个项目，我们可以把一个项目或一个模块的用例都存放在这个目录之下，并且在根目录之下我们还可以在建立子目录来进行功能用例的细分。

7.7.3 新增用例

创建了项目目录后我们就可以新建用例了，具体是点击右侧区域的+号来新增一个空用例的模板，也可以通过复制一个已有用例来达到新建一个用例的目的。

7.7.4 添加请求信息

1. 选择一个请求方法，如：get或post
2. 填写请求的url，如：http://www.baidu.com
3. 如果是get则请求参数直接写在url后，用？连接
4. 如果是post则请求添加在body中
5. 点击“send”发送请求
6. 查看请求响应内容

7.7.5 post请求参数

post请求的主要的特点是把请求数据放在body中，而非url后。 如果需要发送带文件的请求时，就要改下请求格式了。

7.7.6 添加头信息

有些时候请求时还需要一些特定的头信息，直接点击Headers标签就可以进行请求头的信息设置。

7.7.7 预处理和结果检查

预处理主要是对一些环境变量之类的进行设置，相当于数据初始化。

响应处理就是对响应结果进行分析和验证，比如检查code是不是200，内容是不是等于具体某个值，是否包含特定的值等等。

因为预处理和结果检查都是使用js作为脚本语言，所以你还可以进行任意的js可以实现的场景，来辅助测试。

7.7.8 全局变量与环境变量

全局变量我们可以自己在预处理和结果处理2个脚本环境里进行赋值，在具体的测试数据里我们就可以直接使用，具体的使用方法是为：{{variable_key}}；比如在脚本中可以设置全局变量：

postman.setGlobalVariable("username", "tester");

那么在用例数据项里面我就可以这样使用，{{username}}，用来代表具体的tester值。

而环境变量的设置可使用与全局变量基本一样，只是环境变量我们还有另外一个入口可以进行设置，那就是环境配置管理中，我们可以预先建立若干和与环境相关的一套变量，根据实际的测试需求在执行前选择对应的环境变量模板，这样可以快速切换测试服务器与线上服务器之前的环境差异。比如：配置2套环境变量模板，一套url是测试环境，另一套为线上环境，根据测试对象不同我们选择不同的环境变量模板就行了，而不再需要修改测试数据中的url了。

7.7.9 导出用例为代码

如果编写好了用例之后可以通过点击“Code”来一键生成代码，并且还有好多语言和类库可以选择。

7.7.10 批量执行用例

这个功能由单独的runner来负责的，需要在另外的界面进行操作。选择待测试项目，选择“Run collection”,选择用例文件，选择数据，执行。

7.8 禅道

禅道是一款开源项目管理软件。它集产品管理、项目管理、质量管理、文档管理、组织管理和事务管理于一体，是一款专业的研发项目管理软件，完整覆盖了研发项目管理的核心流程。

禅道将产品、项目、测试这三者的概念明确分开，产品人员、开发团队、测试人员，这三者分立，互相配合，又互相制约，通过需求、任务、bug来进行交相互动，最终通过项目拿到合格的产品。

• 官网地址

• 课堂测试平台地址

  初始化用户名密码 用户名：学号 密码：Rjcs2021

• 使用教程

7.8.1 主要功能

1. 产品管理：包括产品、需求、计划、发布、路线图等功能。
2. 项目管理：包括项目、任务、团队、版本、燃尽图等功能。
3. 质量管理：包括bug、测试用例、测试任务、测试结果等功能。
4. 文档管理：包括产品文档库、项目文档库、自定义文档库等功能。
5. 事务管理：包括todo管理，我的任务、我的Bug、我的需求、我的项目等个人事务管理功能。
6. 组织管理：包括部门、用户、分组、权限等功能。
7. 统计功能：丰富的统计表。
8. 搜索功能：强大的搜索，帮助您找到相应的数据。
9. 扩展机制：几乎可以对禅道的任何地方进行扩展。
10. api机制：所见皆API，方便与其他系统集成。

7.8.2 环境搭建

开源版手册

1. web服务：Apache或Nginx
2. 数据库：Mysql（推荐5.5/5.6）
3. PHP：PHP7.0/7.1/7.2

7.8.3 基本流程

1. 产品经理创建产品
2. 产品经理在产品下创建需求
3. 项目经理创建项目
4. 项目经理确定项目要做的需求和任务
5. 项目经理分解任务，指派到研发人员。
6. 测试人员测试，提交bug。

7.8.4 创建产品

禅道的设计理念是围绕产品展开的，因此我们首先要做的就是创建一个产品。进入产品主页，在下拉菜单中，选择“添加产品”。或者先进入“所有产品”页面，点击右侧的“添加产品”。之后便可以添加产品的具体信息。

新增产品的时候，需要设置产品的名称、代码，几个负责人信息。

1. 产品名称和产品代号是必填项。其中产品代号可以理解为团队内部约定俗称的一个称呼，比如我们禅道的代号是zentao，需要是英文字母和数字的组合。
2. 产品线：该产品属于那一个产品线。比如禅道这个产品线，下面包含禅道专业版，禅道开源版，禅道企业版。
3. 产品负责人：负责整理需求，对需求进行解释负责，制定发布计划，验收需求。
4. 测试负责人：可以为某一个产品指定测试负责人，这样当创建bug，而不知道由谁进行处理的时候，该产品的测试负责人会成为默认的负责人。
5. 发布负责人：由这个角色负责创建发布。
6. 产品类型：默认是正常的类型，还可以选择多分支（适用于客户定制场景）和多平台（适用于跨平台应用开发，比如iOS，安卓，pc端等）的产品。
7. 访问控制：可以设置产品的访问权限，其中默认设置只要有产品视图的访问权限就可以访问。如果这个产品是私有产品，可以将其设置为私有项目，那么就只有项目团队成员才可以访问。或者还可以设置白名单，指定某些分组里面的用户可以访问该产品。

7.8.5 添加需求

产品经理可能都习惯了写需求设计文档，或者规格说明书，通过一个非常完整的word文档将某一个产品的需求都定义出来。但在禅道里面，提倡按照功能点的方式来写需求。简单来讲，就是将原来需求设计文档中的每一个功能点摘出来，录在禅道里面，作为一个个独立的功能点。如果按照scrum标准走的话，我们可以称之为 用户故事(user story)。所谓用户故事，就是来描述一件事情，作为什么用户，希望如何，这样做的目的或者价值何在，这样有用户角色，有行为，也有目的和价值所在，非常方便与团队成员进行沟通。

创建需求的步骤如下：

1. 使用产品经理角色登录系统。
2. 进入产品视图。
3. 点击二级导航的“ 需求”，在页面右侧，有提需求的按钮，并支持批量创建，点击新增需求的页面。

• 需求的标题是必填项。
• 所属计划和模块，可以暂时保留为空。
• 需求评审，我们选上不需要评审，这样新创建的需求状态就是激活的，否则只有指定人员进行评审通过后，才能转为激活状态。 只有激活状态的需求才能关联到项目中，进行开发。
• 需求可以设置抄送给字段，这样需求的变化都可以通过email的形式抄送给相关人员。
• 可以设置关键词，这样可以比较方便的通过关键词进行检索。

7.8.6 创建项目

导航的下拉菜单中直接点击“添加项目”或者在项目主页的项目总览区块中点击“添加项目”。在项目添加的页面中，设置项目名称、代号、起止时间、可用工作日、团队名称、和项目描述等字段。

7.8.7 设置团队

项目创建成功，然后可以选择设置团队。或者从项目视图中的团队菜单，也可以进行项目的团队管理。

1. 在维护项目团队的时候，需要选择都是哪些用户可以参与到这个项目中，同时需要设置这个用户在本项目中的角色。
2. 可用工作日和可用工时每天需要仔细设置，设置完毕之后，系统会自动计算这个项目总得可用工时。

7.8.8 关联产品

如果在创建项目的时候，已经关联过产品，可以忽略这个步骤。

1. 以项目经理身份登录。
2. 进入项目视图。
3. 点击“关联产品”按钮。然后点选该项目相关的产品即可。

7.8.9 关联需求

1. 在关联需求的时候，可以按照优先级进行排序。
2. 关联的需求状态必须是激活的（评审通过，不能是草稿）

7.8.10 分解任务

设置了团队之后，下一步操作就是创建任务。

1. 在创建任务的时候，指派给是从项目团队成员中读取。
2. 姓名列表中的首字母可以用来快速筛选用户。
3. 任务的优先级、预计工时（单位小时）都需要进行设置。
4. 如果需要设置任务必须在某一个时间点截止，可以设置截止日期。
5. 可以上传附件。

7.8.11 管理任务

对于项目团队的成员来讲，他要做的事情就是更新任务的进度和状态。

1. 任务的列表： 在任务的列表页面，可以看到系统中所有的任务列表，可以通过各种标签方便地进行筛选。点击某一个任务的名称进入详情页面。
2. 任务的详情页面： 在任务的详情页面可以看到任务的详细信息，包括历次的修改记录等信息。同时也给出了各种操作的按钮。
3. 开始任务： 开始某一个任务的时候，可以设置已经消耗的时间和预计剩余的时间。单位都是工时。
4. 更新任务工时： 点击操作栏里的“工时”按钮，通过更新工时消耗，来管理任务执行进度。
5. 完成任务： 完成任务的时候，需要设置下已经消耗的时间。
6. 关闭任务：任务完成之后，点击操作栏里的“关闭”按钮，将该任务关闭，这个任务就结束了。

7.8.12 测试用例管理

1. 用例编写
2. 用例导出评审
3. 用例修改
4. 用例执行
5. 对于用例执行结果是失败的，可以【转Bug】

7.8.13 缺陷管理

Bug处理流程：

1. bug的基本处理流程：测试提交bug => 开发确认bug => 开发解决bug => 测试验证bug => 测试关闭bug。
2. 如果bug验证没有通过，可以激活：测试提交bug => 开发确认bug => 开发解决bug => 测试验证bug => 测试激活bug => 开发解决bug => 测试验证 => 测试关闭。
3. 还有一个流程就是bug关闭之后，又发生了。测试提交bug => 开发确认bug => 开发解决bug => 测试验证bug => 测试关闭bug => 测试激活bug => 开发解决bug => 测试验证 => 测试关闭。

操作方法：

1. 研发人员负责模块对照表，用于指派开发修改。
2. 单独的bug，直接新建，填写描述。
3. 执行阶段bug，勾选测试步骤，点击【转bug】，可以自动填写步骤重现，适当补充截图说明。

7.9 知识点总结

1. 自动化测试对比手工测试的优缺点
2. 自动化测试发展历程
3. 测试成熟度模型
4. 自动化测试体系
5. 测试工具和测试工具的选择
6. 工具应用举例（Postman、禅道）

第8章 软件测试管理

8.1 软件测试管理概述

软件测试管理就是通过专门的测试组织，运用专门的软件测试知识、技能、工具和方法，对测试项目进行计划、组织、执行和控制，建立起软件测试管理体系，确保软件测试在保证软件质量中发挥关键作用。

软件测试系统主要由测试计划、测试设计、测试执行、配置管理、资源管理、测试管理6个过程组成。

其中，测试计划、测试设计、测试执行在“软件测试流程”一章中讲解。

测试配置管理作为软件配置管理的子集，作用于测试的各个阶段，其管理对象包括测试计划、测试用例、被测版本、测试工具以及测试环境和测试结果等。

资源管理包括人力资源和测试所需的相关技术等管理。

测试管理是指采用合适的方法对测试的流程和结果进行监视。

8.1.1 测试项目范围管理

测试项目范围管理就是界定项目所必须包含且只需包含的全部工作，并对其他的测试项目管理工作起指导作用，以确保测试工作顺利完成。

确定项目目标后，下一步就是确定需要执行哪些工作或者活动来完成项目的目标，需要确定包含项目所有活动在内的一览表，一般有如下两种方法：

1. 头脑风暴法 测试小组根据经验集思广益，这种方法比较适合小型测试项目。

2. WBS工作分解结构 针对复杂的项目，往往需要工作分解结构(Work BreakDown Structure,WBS).工作分解结构是将一个软件测试项目分解成易于管理的更多部分或细目，所有这些细目构成了整个软件测试项目的工作范围。

   工作分解结构是测试项目团队在项目期间要完成或生产出的最终项目的等级树，组织并定义了整个测试项目的范围。

8.1.2 测试管理主要功能

1. 测试对象管理 测试对象包括测试方案的具体测试步骤、问题报告、测试结果报告等，主要是为各测试阶段的控制对象提供一个完善的编辑和管理环境。

2. 测试流程管理 测试流程管理是基于科学的流程和具体的规范来实现的，并利用该流程和规范严称约束和控制整个产品的测试周期，以确保产品的质量。整个过程避免了测试人员和开发人员之间面对面的交流，减少了以往测试和开发之间的矛盾，提高工作效率。

3. 统计分析和决策支持 在系统建立的测试数据库的基础上进行合理的统计分析和数据挖掘，例如根据问题分布的模块、问题所属的性质、问题的解决情况等方面的统计分析使项目管理者全面了解产品开发的进度、产品开发的质量、产品开发中问题的聚集，为决策管理提供支持。

8.2 测试过程改进

软件测试技术解决了测试采用的方法问题，测试管理保证了各项测试活动的顺利开展。软件测试过程改进主要着眼于合理调整各项测试活动的时序关系，优化各项测试活动的资源配置以及实现各项测试活动效果的最优化。

8.2.1 功能

测试过程改进是一项长期的、没有重点的活动，在实施测试过程改进时，应根据公司的战略目标确定测试部门的战略，将测试过程改进与公司的战略目标相联系。

组织的规划内容通常包括以下内容：

1. 绘制远景：提升管理成熟度，提高测试生产率。
2. 战略分析：根据软件成熟度模量适时进行评估，最终目标为CMMI4。
3. 优缺点评估：以内部改进为宗旨，使过程改进更符合组织的实际情况。

测试过程的改进对象应该包括三个方面：组织、技术和人员。

1. 组织
   软件测试组织的不良架构通常表现在如下内容：
   (1) 没有恰当的角色追踪项目进展。
   (2) 没有恰当的角色进行缺陷控制、变更和版本追踪。
   (3) 项目在测试阶段效率低下、过程混乱。
   (4) 项目成了测试经理个人的项目，而不是组织的项目。
   (5) 关心进度，而忽视项目质量和成本。

   因此，组织的改进应该使得测试从开发活动中分离出来，把缺陷控制，版本管理和变更管理从项目管理中分离出来。

2. 技术 技术的改进包括对流程、方法和工具的改进，包括组织或者项目对流程进行明确的定义，应引入统一的管理方法。

3. 人员 人员的改进主要是指对企业文化的改进，建立高效率的团队和组织。

8.2.2 方法

在改进的不同时期和阶段，选择的策略也不同，组织应根据实际情况进行选择。下面给出测试过程改进的一些策略方法。

1. 实施制度化的同时建设企业文化 实施全面制度化的管理是过程改进的有效保障，制度和组织文化总是互相依存，没有良好的文化保障，制度化将困难重重；而没有制度的支撑，文化也将是无本之木。

2. 引入软件工具 推行配置、自动化测试和缺陷跟踪等工具，将有效地分解事务性工作，可以缓解人力资源不足的困难。常见的过程管理方面的工具包括Rational公司的ClearCase等。

3. 调整测试活动的时序关系 由于有些测试活动是可以并行的，有些测试活动是可以归并完成的，有些测试活动在时间上存在线性关系等，因此必须区分优化调整，控制测试进度。

4. 优化测试活动资源配置 软件测试过程必然会涉及人力、设备、场地、软件环境与经费等资源，必须合理地调配各项资源给相关的测试活动，特别是人力资源的调配。

5. 提高测试计划的指导性 测试计划确保测试大纲真正执行、用于指导测试工作，保证软件的质量。

6. 确立合理的度量模型和标准 在测试过程改进中，测试过程改进小组应根据企业与项目的实际情况制定适合自己的质量度量模型和标准。测试过程改进随着测试过程的进行不断实践、不断总结、不断改进。

8.3 软件测试文档

8.3.1 测试文档的类型

IEEE给出软件测试文档分为测试计划，测试设计规格说明、测试规程规格说明、测试日志、测试缺陷报告和测试总结报告等。

1. 软件测试计划文档 软件测试计划文档主要对软件测试项目以及所需要进行的测试工作、测试人员所应该负责的测试工作、测试过程、测试所需的时间和资源，测试风险、测试项通过/失败的标准、测试中断和恢复的规定、测试完成所提交的材料等做出预先的计划和安排。

2. 软件测试设计规格说明文档 软件测试设计规格说明文档用于每个测试等级，以制定测试集的体系结构、通过/失败准则和覆盖跟踪。

3. 软件测试用例规格说明文档 软件测试用例规格说明文档用于描述测试用例，包括测试项、输入规格说明、输出规格说明、预期要求和规程需求等。

4. 测试规程 测试规程用于指定执行一个测试用例集的步骤。

5. 测试日志 测试日志用于记录测试的执行情况不同，可根据需要选用。

6. 软件缺陷报告 软件缺陷报告用来描述出现在测试过程或软件中的异常情况，这些异常情况可能存在于需求、设计、代码、文档或测试用例中。

7. 测试总结报告 测试总结报告用于报告某个测试的完成情况，给出评价和建议。

8.3.2 测试文档的重要性

测试文档的重要性主要表现在如下几个方面：

1. 验证需求的正确性 测试文件规定了用以验证软件需求的测试条件。由于要测试的内容可能涉及软件的需求和设计，因此必须及早开始测试计划的编写工作。不应在着手测试时才开始考虑测试计划。通常，测试计划的编写从需求分析阶段开始，到软件设计阶段结束时完成。

2. 检验测试资源 测试计划不仅要用文件的形式把测试过程规定下来，还应说明测试工作必不可少的资源，进而检验这些资源是否可以得到，即它的可用性如何。

3. 明确任务的风险 测试计划文档帮助测试人员分析测试可以做什么，不能做什么。了解测试任务的风险有助于对潜伏的可能出现的问题事先作好思想上和物质上的准备。

4. 生成测试用例 测试用例的好坏决定着测试工作的效率，选择合适的测试用例是做好测试工作的关键，在测试文件编制过程中，按规定的要求精心设计测试用例有重要的意义。

5. 评价测试结果 测试文件包括测试用例，即若干测试数据及对应的预期测试结果。完成测试后，将测试结果与预期的结果进行比较，便可对已进行的测试提出评价意见。

6. 确定测试的有效性 完成测试后，把测试结果写入文件，这对分析测试的有效性甚至整个软件的可用性提供了依据。同时还可以证实有关方面的结论。

8.4 人力资源

8.4.1 测试团队框架

1. 测试主管 测试主管有权管理测试过程日常的组织，负责保证在给定的时间、资源和费用的限制下，测试项目产生满足质量标准的产品。测试主管负责与开发组联系，保证单元测试顺利进行，并与独立测试观察员联系，接收有关没有正确遵循测试过程的测试项目的报告。

2. 测试组组长 测试组组长负责为测试分析员和测试者分配任务，按照预定的计划监控他们的工作进度，建立和维护测试项目文件系统，保证产生测试项目相关材料(测试计划文档、测试规范说明文档)，测试组组长负责产生这个文档，也可以授权测试分析员来完成这个文档。

   测试组组长听取一个或多个测试分析员的测试报告，在验收测试时，测试组组长负贵和用户代表、操作代表联系，以便有一个或多个用户来执行用户和操作验收测试。

3. 测试分析员 测试分析员负责设计和实现用于完成自动化测试的一个或多个测试脚本，协助测试组组长生成测试规格说明文档。

   在调试测试用例的设计过程中，测试分析员需要分析自动化测试的需求规格说明，以便确定必须测试的特定需求，在这个过程中，测试分析员应该优先考虑测试用例，以反映被确认特性的重要性以及在正常使用自动化测试中导致失败的特性的风险。完成测试项目后，测试分析员负责备份和归档所有的测试文档和材料，这些材料将提交给测试组组长进行归档。测试分析员还负责完成一份测试总结报告。

4. 测试者 测试者主要负责执行由测试分析员建立的测试脚本，并负责解释测试用例结果，并将结果记录到文档中。

   执行测试脚本之前，测试者首先要建立和初始化测试环境，其中包括测试数据和测试硬件，以及其他支持测试所需的软件。在测试执行过程中，测试者负责填写测试结果记录表格，以便记录执行每个测试脚本观察到的结果，测试者使用测试脚本对预期结果进行描述，完成测试以后，测试者还负责备份测试数据、模拟器或测试辅助程序以及测试中使用的硬件的说明。这些材料将提交给测试组组长归档。

8.4.2 测试团队阶段性

在不同的阶段，测试团队也不尽相同，体现了测试团队的阶段性。

1. 需求分析阶段 需求分析规格说明是否完整、正确、清晰，是软件开发成败的关键。因此，为了确保需求的质量，应对其进行严格的审查。测试评审小组通常可由一名组长和若干成员组成，其成员包括系统分析员，软件开发管理者，软件设计、开发、测试人员和用户。
2. 设计阶段 软件设计是将软件需求转换成软件表示的过程，主要描绘出系统结构、详细的处理过程和数据库模式。按照需求的规格说明对系统结构的合理性、处理过程的正确性进行评价，利用关系数据库的规范化理论对数据库模式进行审查。测试评审小组由下列人员组成：组长一名，成员包括系统分析员、软件设计人员、测试负责人员。
3. 测试阶段 软件测试是软件质量保证的关键。软件测试在软件生存周期中横路两个阶段，通常，编写出每个模块之后进行单元测试，之后需要对软件系统进行各种综合测试。测试评审小组包括组长一名，负责整个测试的计划、组织工作；以及具备一定分析、设计与编程经验的测试组成员，人数可随具体情况确定，一般为3～5人。

8.5 配置管理

8.5.1 软件配置管理

软件配置管理(Software Configuration Management,SCM)是标志和确定系统中配置项的过程，在系统整个生命周期内控制这些项的投放和起动，记录并报告配置的状态和变动要求，验证配置项的完整性和正确性。

在IEEE 610.12—1990标准中，软件配置管理的描述则比较详细，包括以下内容：

1. 标志：识别产品的结构、产品的构件及其类型，为其分配唯一的标识符，并以某种形式提供对它们的存取。
2. 控制：通过建立产品基线控制软件产品的发布和在整个软件生命周期中对软件产品的修改。例如，确定哪些修改会在软件的最新版本中实现。
3. 状态统计：记录并报告构件和修改请求的状态，并收集关于产品构件的重要统计信息。例如，修改这个错误将影响多少个文件？
4. 审计和复审：确认产品的完整性并维护构件间的一致性，并确保产品是一个严格定义的构件集合。例如，确定目前发布的软件产品所用的文件的版本是否正确。
5. 生产：对产品的生产进行优化管理，它将解决最新发布的产品应由哪些版本的文件和工具来生成的问题。

从以上定义可以看出，软件配置管理贯穿整个软件生命周期，对软件产品进行标志、控制和管理，它系统地控制对配置项的修改，以维护配置项的完整性、一致性和可追踪性。软件配置管理应包括版本控制、系统集成、变更管理、配置状态统计和配置审计等功能，其中版本控制是软件配置管理的主要思想和核心内容。

8.5.2 变更管理的作用

软件开发和维护过程中，配置项的变更是无法避免的。首先要设计一个实现变更的方案，这对于那些规模比较大的变更是尤其必要的，可能会包括需求分析和设计过程，然后从配置库中检出需要修改的配置项，具体实现变更。实现的变更必须经过测试人员和质量保证人员的测试和验证，被证明正确无误后，在配置管理人员的指导下，将配置项检入到配置库中，形成新的版本。

在实现变更的整个过程中，变更执行人员、配置管理人员、QA人员都应该对变更负责，并在变更请求表上留有记录，因此该表能反映变更控制的全面情况。变更执行人员还应该在具体实现变更的模块代码或文档上留下反映变更情况的信息。

8.6 软件质量

8.6.1 软件质量与测试

软件质量框架是一个“质量特征一质量子特征-度量因子”的3层结构模型，其中第1层称为质量特性，第2层称为质量子特性，第3层称为度量，如图：

软件质量评价的目的是为了直接支持开发并获得能满足用户要求的软件。最终目标是保证产品能提供所要求的质量，即满足用户明确的和隐含的要求。软件产品的一般评价过程是确定评价需求，然后规定、设计和执行评价。

影响软件质量的因素很多：

软件测试与软件质量具有如下关系：

1. 测试不能提高质量，软件的质量是固有特性，测试人员只能通过有赖于开发人员的努力。
2. 测试人员的工作成果不能从软件的产品质量或者软件的最终成果得到科学的评估。

8.6.2 常用的软件质量度量

1. 缺陷密度 缺陷密度指单位规模的软件所包含的缺陷的数量。
   缺陷密度用以下公式计算：
   缺陷密度 = 已知缺陷的数量 / 软件规模
   上式中的软件规模可以用代码行数或功能点数等方式度量。缺陷密度还可以进一步细化为更具体的度量指标，例如：
   (1) 每千行代码中的高级设计缺陷。
   (2) 每千行代码中的编码缺陷。
   (3) 每千行代码中的用户发现的缺陷。

2. 平均失效时间(Mean Time to Failure,MTTF) MTTF指软件在失效前(两次失效之间)正常工作的平均统计时间，它常用来度量软件的可靠性。MTTF度量常用于安全性要求较高的系统，例如航班监控系统、航空电子系统以及武器系统等。

3. 平均修复时间(Mean Time to Reparation,MTTR) MTTR指软件失效后，使其恢复正常工作所需要的平均统计时间。MTTR用来度量软件的可维护性。

4. 初期故障率 指软件在初期故障期(一般以软件交付给用户后的3个月内为初期故障期)内单位时间的故障数，初期故障率用来评价交付使用的软件的质量，预测什么时候软件运行达到基本稳定。一般以每100小时的故障数为单位。

5. 偶然故障率 指软件在偶然故障期(一般以软件交付给用户后的4个月以后为偶然故障期)内单位时间的故障数。偶然故障率用来度量软件处于稳定状态下的质量，一般以每1000小时的故障数为单位。

8.7 知识点总结

1. 软件测试管理
2. 测试过程改进
3. 测试文档
4. 人力资源
5. 配置管理
6. 软件质量

附录1 测试规范

e1 概述

e1.1 目的

结合公司开发工具、平台等具体情况，主要针对系统测试制定常见的测试类型（测试策略），并对每种测试类型加以详细说明或举例，在项目测试制定测试计划或测试方案时，参考该文档中的各种测试类型，选择适合项目的测试策略，以便更系统、完整地对组织项目测试。

e1.2 范围

1. 功能测试
2. UI测试
3. 可用性测试
4. 权限及安全性测试
5. 兼容性测试
6. 性能测试
7. 文档测试

e2 测试类型描述

e2.1 功能测试

验证软件各个功能模块是否正确，测试对象一般是用户需求。功能测试在测试方案或测试用例中详细描述，此文档不再说明。

e2.2 UI测试

1. 整体界面的美观性：窗口居中，按钮、文字、输入框等大小适中、排列整齐。
2. 表格类：表头文字居中；列表中，文本类左对齐（相同字数或字数相差不大的列居中），数字类右对齐（序号列居中），日期居中。
3. 菜单名称、打开窗口的标题栏、权限名称等命名一致。
4. 必填项有特殊符号标识，如一般用红色*号表示。
5. 录入界面中，有默认的光标定位，支持鼠标和键盘操作。
6. 【确认】按钮一般放在【取消】按钮的左边。
7. 对于要求用户输入的内容，要明确。如要求用户定义某种比例，要明确是要求输入百分比（20%）还是小数的比例（0.20）。
8. 窗口一般允许最小化、最大化、移动，但提示信息等弹出窗口一般固定大小、不允许缩放。
9. 任务栏自动隐藏与不隐藏情况下的显示，整体的界面显示是否正确。

e2.3 可用性测试

e2.3.1 新增

1. 必输项检查：应该输入的内容没有输入时系统是否都做了处理，对必输项是否有提示信息，如在必输项前加“*”；对必输项提示返回后，焦点是否会自动定位到必输项。

2. 单据保存时，对于不符合项，提示应该明确、友好并且是正确的；确认提示后，光标要正确定位到需要修改的地方。可以这样测试，在新增单据时，不输入任何值，直接保存，跳出提示后，进行相应的操作，直到单据保存成功。单据不保存，退出时，也应该给出相应的提示。

3. 各种默认值是否正确，如默认的单据号、默认的日期等，默认值是否允许修改。

4. 各个数据项是否有唯一性要求，如单据ID，如果不是系统自动生成允许手工录入的，是否区分大小写。

5. 极限值测试：在各个输入项中，录入允许输入的最大值（字母数字和中文分开录入），看能否正常保存。不仅要测试保存，还要测试保存后的后续操作，查看、查询、修改以及其它单据调用等操作。

6. 不同字段类型的录入测试 (1) 字符类型测试：

   ① 在应该输入指定类型的内容的地方输入其他类型的内容(如数值或日期等输入框录入非数字或日期型字符)，看系统是否有检查字符类型。

   ② 标点符号检查：输入内容包括各种标点符号，特别是空格，各种引号，回车键等，看系统处理是否正确。

   ③ 特殊字符检查：输入特殊符号，如@、#、$、%、!等，看系统处理是否正确。 字符串长度检查: 输入超出需求所说明的字符串长度的内容， 看系统是否检查字符串长度。

   ④ 空格检查：在输入信息项中，输入一个或连串空格，查看系统如何处理。如对于要求输入整型、符点型变量的项中，输入空格，既不是空值，又不是标准输入。

   ⑤ 输入法半角全角检查：在输入信息项中，输入半角或全角的信息，查看系统如何处理。如对于要求输入符点型数据的项中，输入全角的小数点（“。”或“．”，如４．５），输入全角的空格等。

   (2) 数字类型测试

   ① 默认的0，如默认显示为“0.00”，用户输入“1”后，显示值不能为“10.00”、“0.01”，正确的应该是“1.00”。

   ② 要考虑小数位数，如一般金额小数位为2位，测试时，要注意各种单据、列表或报表中相关字段的小数位数也显示2位。要测试小数为零及全部值的情况，如“4.00”，显示不应该是“4”、“4.0”、“4.0000”，“4.55”显示不应该是“4.6”、“4.5500”。

   ③ 数字的极限值，包括单行明细的最大值和合计的最大值。要测试输入、保存、显示、修改、查询等不同操作，还要测试多行明细都是最大值时，合计值是否正常显示。

7. 信息重复：在一些需要命名，且名字应该唯一的信息域中输入已经存在的名字或ID，看系统有没有处理，是否会报错，重名包括是否区分大小写，以及在输入内容的前后输入空格，系统是否作出正确处理。

8. 中文字符处理：在可以输入中、英文的系统输入中文，看是否会出现乱码或出错。

9. 重复提交表单：一条已经成功提交的纪录，返回后再提交，看看系统是否做了处理。对于Web系统，检查多次使用返回键的情况，在有返回键的地方，返回到原来页面，重复多次，看是否会出错。

10. 下拉列表是否有滚动条。

11. 快捷键检查：是否支持常用快捷键，如Ctrl+C、 Ctrl+V、 Backspace等，对一些不允许输入信息的字段，如选人，选日期对快捷方式是否也做了限制。

12. 回车键检查：在输入结束后直接按回车键，看系统处理如何，是否会报错。

e2.3.2 修改

1. 检查新增和修改是否一致：检查新增和修改信息的要求是否一致，例如新增要求必输的内容，修改也应该必输；新增规定为整型的项，修改也必须为整型。
2. 对于新增时自动生成不需要录入的内容，在修改时应不允许修改。
3. 所有可修改的内容是否修改成功。
4. 对于有明细行信息的单据修改，明细行增加、删除是否成功。
5. 若修改后存在历史记录信息，历史变更信息是否对应并描述正确。
6. 修改变动后在列表中有相应值的，都应该即时刷新。

e2.3.3 删除

1. 一般要给出确认删除的提示，供用户选择，而不能直接删除。
2. 删除单据时是否存在约束条件，如单据被其它单据或信息引用后不能删除等。
3. 删除单据后，存在唯一性要求的要素，如单据ID等是否可以重新使用。
4. 删除单据后，相关报表或列表统计是否不包括相关数据。
5. 在一些可以一次删除多个信息的地方，不选择任何信息，按“delete”，看系统如何处理，是否会出错；然后选择一个和多个信息，进行删除，看是否正确处理。

e2.3.4 查询

1. 所有查询条件全部选择、所有条件全部清空（除必输项）、仅输入一个条件，多个条件多种组合等情况，检索出的数据是否正确。
2. 输入的查询条件为数据库中存在或不存在的数据，看是否能正确处理。
3. 是否支持模糊查询。
4. 输入的查询条件前后加上空格是否能正确查询到相关信息。
5. 是否保留查询条件，重新选择条件查询后是否保留最新的查询条件，默认保留的查询条件查询是否正确。
6. 对于耗时较长的查询操作，应提供进度条。
7. 大数据量查询是否处理正确，是否存在统计数据丢失现象。

e2.3.5 上传下载文件

1. 上传下载文件的功能是否实现，上传文件是否能打开。
2. 对上传文件的格式有何规定，系统是否有解释信息，并检查系统是否能够做到。
3. 是否能够上传一个正在编辑的文件。
4. 下载文件能否打开或者保存，下载的文件是否有格式要求，如需要特殊工具才可以打开等。
5. 上传附件的大小是否有限制。

e2.4 权限及安全性测试

e2.4.1 登录

1. 用户名、密码都正确。
2. 用户名正确、密码不正确。
3. 用户名不正确、密码正确。
4. 用户名、密码都不正确。
5. 不输入用户名和密码直接点登录是否正确处理。
6. 数据库中清除用户密码登录。
7. 输入的数据前或中间存在空格。
8. 输入正确的用户名和密码以后按[enter]能否登录。
9. 用户名是否支持中文名登录。

e2.4.2 密码修改

1. 默认密码测试。
2. 不输入旧密码，直接改密码。
3. 输入错误旧密码修改。
4. 不输入新密码或不输入确认新密码。
5. 新密码和确认新密码不一致。
6. 密码字母大小写、空格、特殊字符测试
7. 密码最小、最长位数测试。
8. 新密码是否能够修改成功。

e2.4.3 菜单、按钮及功能权限

1. 操作员无任何权限测试。
2. 操作员有所有权限测试。
3. 逐个权限测试：无相应权限应隐藏该菜单或按钮。菜单和按钮权限优先测试。

e2.4.4 其他

1. 直接URL链接检查：用户没有登录而直接输入各功能页面的URL地址，看系统如何处理。
2. Session时间测试：用户登陆后在一定时间内（例如30分钟）没有点击任何页面，是否需要重新登陆才能正常使用。
3. 回退键检查：使用浏览器的回退键，看系统处理如何，是否会报错。对于需要用户验证的系统，在退出登录后，使用回退键，看系统处理如何；多次使用回退键，多次使用前进键，看系统如何处理。
4. ActiveX控件测试：安全级别中启用（提示）或不启用ActiveX控件，相关ActiveX控件是否能够正常下载并安装。

e2.5 兼容性测试

e2.5.1 客户端操作系统测试

不同操作系统下系统是否能够正确显示与运行，如Win、Mac、Linux是否可以正常运行。

e2.5.2 浏览器测试

不同浏览器版本下系统是否能够正确显示与运行，如IE、火狐、Chrome、360浏览器等浏览器下所有功能是否可以正常运行。

e2.5.3 分辨率测试

在不同分辨率下系统是否能够正确显示，界面是否美观，如800600、1024768、1280*800等不同分辨率下系统显示是否正常和美观。

e2.6 性能测试

e2.6.1 负载测试

在给定的测试环境下如在既定的服务器配置下，通过在被测系统上不断增加压力如增加并发数，直到性能指标超过预定指标或某种资源使用已经达到饱和状态，目的是了解系统性能容量和处理能力极限。负载测试的主要用途是发现系统性能的拐点，寻找系统能够支持的最大并发或在线用户、业务等处理能力的约束。

主要关注事务响应时间、服务器资源消耗、应用服务内存使用等指标。

e2.6.2 并发测试

模拟并发访问，测试多用户同时访问或操作同一个应用、模块、数据时是否产生隐藏的并发问题。测试目的并非为了获得性能指标，而是为了发现并发引起的问题。

一般测试点包括用户同时登录、同时新增单据、同时修改同一张单据、同时删除同一张单据等操作。

1. 同时登录 正确登录，显示各自的操作员姓名。
2. 同时新增单据 正确保存，不出现主键冲突等错误提示，保存内容为各自录入的数据。
3. 同时修改同一张单据 (1) 只有一人允许修改，修改结果正确，其他人点修改就提示该单据被他人占用等提示。 (2) 允许多人同时编辑该单据，保存时只有一人保存成功，修改结果正确，其他人保存时提示该单据被他人占用等提示。
4. 同时删除同一张单据 只有一人删除成功，其他人删除时提示单据已不存在等提示。

e2.6.3 可靠性测试

通过给系统加载一定的业务压力的情况下，让应用持续运行一段时间，测试系统在这种条件下是否能够稳定运行。

如持续运行系统48个小时，看事务响应是否越来越慢，资源使用率是否逐渐增加。

e2.6.4 配置测试

通过对被测系统的软硬件环境的调整，了解各种不同环境对性能影响的程度，从而找到系统各项资源的最优分配原则。

主要用于性能调优，在经过测试获得了基准测试数据后，进行环境调整（包括硬件配置、网络、操作系统、应用服务器、数据库等），再将测试结果与基准数据进行对比，判断调整是否达到最佳状态。

此项工作一般需要数据库工程师、网络工程师等专业人员协助完成。

e2.6.5 大数据量测试

针对某些系统存储、传输、统计查询等业务进行大数据量的测试，如大数据量的保存、上传下载、导入导出、报表查询等业务，关注业务发生大数据时系统是否能够正常稳定地运行，数据是否存在丢失现象，并关注事务响应时间以及服务器资源使用情况等指标。

e2.7 文档测试

主要包括需求文档、设计文档、用户操作手册等。

需求文档和设计文档在前期需要进行项目组内评审，在评审中判断文档内容是否存在逻辑矛盾以及需求在技术上是否可以实现，是否符合全部需求以及设计是否合理，所以该类文档一般不需要专职安排测试。

主要的文档测试是针对用户操作手册，测试点包括检查文档的错别字、功能描述是否清晰、操作说明是否符号软件系统实际运行等。

附录2 研发项目常见问题

Q1 产品

1. 没有单独的角色负责产品，往往是项目经理兼任。
2. 做出来的功能不是用户真正想要的。
3. 产品不能按期交付。
4. 产品质量无法保证，后期维护成本很高。
5. 需求无休止的变更。
6. 客户的任何需求都答应下来，需求会永无止境。·版本分支很多，新增功能或者需求变动改动太高。

Q2 项目管理

1. 项目经理往往从技术骨干转岗，懂技术，不一定懂管理。
2. 缺少系统的管理理论和方法，靠经验和人治。
3. 对项目的估计偏乐观，每月30天，每天8小时。
4. 需求分析，任务分解不够细致，粗枝大叶。
5. 项目周期过长，节奏无法控制，前松后紧。

Q3 研发

1. 缺少统一的编码规范，或形同虚设。
2. 结构混乱，架构不合理，系统不灵活。
3. 滥用全局变量。
4. 没有良好的注释的习惯。
5. 变量命名随意，含义不清晰，中英文夹杂。
6. 缺少安全和性能意识。
7. 没有测试意识，代码质量无法保证。
8. 跟风选择时髦的技术或者框架，遇到问题无法解决。

Q4 测试

1. 项目前期无法展开测试，测试人员只能等。
2. 研发无法按期交付，压缩测试时间，最后只能牺牲质量。
3. 没有很好的bug管理规范和系统，口头、email和im跟踪。
4. 往往缺少压力测试，真正上线发现问题比较严重。
5. 往往缺少安全测试，一旦出现问题影响严重。
6. 不做版本控制，混乱的代码库和开发环境。

Q5 沟通

1. 项目启动后产品经理就消失了，无人解释和确认需求。
2. 遇到问题互相扯皮，强调这是其他人的责任。
3. 一个人负责一摊，知识难以传承，风险比较高。
4. 缺少团队合作，遇到问题时不愿或不能请别人帮忙。
5. 项目内部沟通不畅，每个成员只是埋头做自己的事情。

Q6 战略和组织

1. 跟风，别人做什么，自己也做什么。
2. 不专注，事情开个头就匆匆结尾。
3. 产品没有创新，模式没有创新。
4. 等级划分太严格，管理人员脱离一线研发。
5. 招人难，留人难。