1、第第1章章 软件测试基础软件测试基础 软件测试模型 软件测试原则 软件测试基本流程 软件概述 软件缺陷管理 软件测试概述1.1.1 软件生命周期软件生命周期可分为6个阶段：问题问题定义定义需求需求分析分析软件软件设计设计软件软件开发开发软件软件测试测试软件软件维护维护淘汰淘汰1.1.2 软件开发模型1、瀑布模型计划计划需求分析需求分析软件设计软件设计编码编码测试测试运行维护运行维护软件设计阶段软件设计阶段软件开发阶段软件开发阶段软件维护阶段软件维护阶段1.1.2 软件开发模型1、瀑布模型优点：检查点清晰，分工明确，有利于大型软件软件开发人员的组织管理及工具的使用与研究，可以提高开发的效率。缺点
2、：严格按照线性执行，增加了开发风险；要求必须有产出结果，增加了开发工作量。对于现代软件，各阶段之间的关系很少是线性，瀑布模型已经不适合现代软件开发。1.1.2 软件开发模型2、快速原型模型需求分析需求分析构建原型构建原型原型评价原型评价确定最终确定最终需求需求软件开发软件开发细化需求细化需求1.1.2 软件开发模型2、快速原型模型优点：克服了需求不明确带来的风险，适用于不能预先确定需求的软件项目。缺点：原型设计较难；不利于开发人员对产品的扩展。1.1.2 软件开发模型2、迭代模型需求分析需求分析软件设计软件设计编码编码测试测试迭代1组件1需求分析需求分析软件设计软件设计编码编码测试测试迭代2组
3、件2 需求分析需求分析软件设计软件设计编码编码测试测试迭代n组件n1.1.2 软件开发模型3、迭代模型优点：适应客户需求变更；降低了开发成本和风险。缺点：增加了集成失败风险；容易退化为“边做边改”模式，失去对整个项目的控制。1.1.2 软件开发模型4、螺旋模型1.1.2 软件开发模型4、螺旋模型螺旋模型包含四个象限：制定计划：确定软件目标，制定实施方案，列出项目开发的限制条件。风险分析：评价所制定的实施方案，识别风险并消除风险。实施工程：开发产品并进行验证。客户评估：客户对产品进行审核评估，提出修正建议，制定下一步计划。1.1.2 软件开发模型4、螺旋模型优点：强调了风险分析，有助于将软件质量
4、融入开发中；小分段构建大型软件，易于计算成本；客户参与，保证项目可控性。缺点：构建过程太过繁琐，不适合小型项目。1.1.2 软件开发模型5、敏捷模型敏捷模型以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。1.1.2 软件开发模型5、敏捷模型敏捷模型的特点如下：项目被拆分成多个子项目，迭代完成，每个迭代都要经过测试。快速响应需求变更，在修改过程中，软件一直处于可用状态。不断对产品进行细微、渐进式地改进，每次改进一小部分，如果可行再逐步扩大改进范围。开发未动，测试先行。注重“人”的作用。1.1.2 软件开发模型5、敏捷模型优点：及时响应客户需求变更，不断适应新的趋势。缺点：管理相对混
5、乱，不适合大型项目。多学一招多学一招：敏捷模型开发方式敏捷模型开发方式1、ScrumScrum Master（产品负责人）全面负责产品的开发过程。Scrum Master把团队划分成不同的小组，把整个项目划分成细小的可交付成果的子项目，分别由不同的小组完成，并对各小组的工作划分优先级，估算每个小组的工作量。多学一招多学一招：敏捷模型开发方式敏捷模型开发方式2、Kanban利用可视化软件将开发的软件项目细分成小任务，并分配给团队成员，每个成员都可以在“看板”上了解自己的工作任务及整个团队的工作进度。项目开始之后，从目前执行的任务和过程开始，团队会针对每个成员的工作作出持续性、增量、渐进式的改变。
6、1.1.3 软件质量概述软件质量是指软件产品满足基本需求及隐式需求的程度。软件产品满足基本需求是指其能满足软件开发时所规定需求的特性，其次是软件产品满足隐式需求的程度。1.1.3 软件质量概述从软件质量的定义，可将软件质量分为三个层次：满足需求规定：软件产品符合开发者明确定义的目标，并且能可靠运行。满足用户需求：软件产品的需求是由用户产生的，软件最终的目的就是满足用户需求，解决用户的实际问题。满足用户隐式需求：软件如果满足用户隐式需求，即潜在的可能需要在将来开发的功能。将会极大的提升用户满意度，这就意味着软件质量更高。1.1.3 软件质量概述软件质量模型多学一招多学一招：纸杯测试纸杯测试 测试
7、项目：纸杯。需求测试：查看纸杯说明书是否完整。界面测试：观察纸杯外观，表面是否光滑、手感是否舒适。功能测试：用纸杯装水，观察是否漏水。安全测试：纸杯是否有毒或细菌。多学一招多学一招：纸杯测试纸杯测试 易用性测试：用纸杯盛放开水是否烫手、纸杯是否易滑、是否方便饮用。兼容性测试：用纸杯分别盛放水、酒精、饮料、汽油等，观察是否有渗漏现象。可靠性测试：从不同高度摔下来，观察纸杯的损坏程度。可移植性测试：将纸杯放在温度、湿度等不同的环境中，查看纸杯是否还能正常使用。多学一招多学一招：纸杯测试纸杯测试 可维护性：将纸杯揉捏变形，看其是否能恢复。压力测试：用一根针扎在纸杯上不断增加力量，记录多大压强时能穿透
8、纸杯。疲劳测试：用纸杯分别盛放水、汽油放置24小时，观察其渗漏情况（时间和程度）。跌落测试：纸杯（加包装）从高处落下，查看达到破损的高度。多学一招多学一招：纸杯测试纸杯测试 震动测试：纸杯（加包装）六面震动，评估它是否能应对恶劣的公路/铁路/航空运输等。测试数据：编写具体测试数据（略），其中可能会用到场景法、等价类划分法、边界值分析法等测试方法。期望输出：期望输出需要查阅国际标准及用户的使用需求。多学一招多学一招：纸杯测试纸杯测试 用户文档：使用手册是否对纸杯的用法、使用条件、限制条件等有详细描述。说明书测试：查看纸杯说明书的正确性、准确性及完整性。1.1.3 软件质量概述影响软件质量的因素：
9、需求模糊 软件开发缺乏规范性文件指导 软件开发人员问题 缺乏软件质量控制管理1.2.1 软件缺陷产生的原因1.2.2 软件缺陷的分类划分标准划分标准缺陷缺陷类型类型测试种类测试种类界面类功能类性能类安全性类兼容性类严重程度严重程度严重一般次要建议优先级优先级立即解决高优先级正常排队低优先级发生阶段发生阶段需求阶段构架阶段设计阶段编码阶段测试阶段1.2.3 软件缺陷的处理流程每个公司的软件缺陷处理流程不尽相同，但是它们遵循的最基本流程是一样的，都要经过提交、分配、确认、处理、复测、关闭等环节。1.2.3 软件缺陷的处理流程 提交：测试人员发现缺陷之后，将缺陷提交给测试组长。分配：测试组长接收到测
10、试组员提交的缺陷之后，将其移交给开发人员。确认：开发人员接收到移交的缺陷之后，会与团队甚至测试人员一起商议，确定该缺陷是否是一个缺陷。拒绝：如果经过商议之后，缺陷不是一个真正的缺陷则拒绝处理，关闭缺陷。如果经过商议之后，确定其是一个真正的缺陷，则可以根据缺陷的严重程度或优先级等立即处理或延期处理。1.2.3 软件缺陷的处理流程 复测：开发人员修改好缺陷之后，测试人员重新进行测试（复测），检测缺陷是否确实已经修改。如果未被正确修改，则重新提交缺陷。关闭：测试人员重新测试之后，如果缺陷已经被正确修改，则将缺陷关闭，整个缺陷处理完成。多学一招多学一招：缺陷报告缺陷报告测试人员在提交软件测试时都会按照
11、公司规定的模板（Word、Excel、缺陷管理软件等）将缺陷的详细情况记录下来生成缺陷报告，每个公司的缺陷报告模板并不相同，但一般都会包括缺陷的编号、类型、严重程度、优先级、测试环境等，有时还会有测试人员的建议。注 意多学一招多学一招：缺陷报告缺陷报告编写缺陷报告要注意以下事项：每个缺陷都有一个唯一的编号。缺陷要有重现步骤。一个缺陷生成一份报告。缺陷报告要整洁、完整。1.2.4 常见的软件缺陷管理工具1、BugzillaBugzilla是Mozilla公司提供的一款免费的软件缺陷管理工具。Bugzilla能够建立一个完整的缺陷跟踪体系，包括缺陷跟踪、记录、缺陷报告、处理解决情况等。使用Bugz
12、illa管理软件缺陷时，测试人员可以在Bugzilla上提交缺陷报告，Bugzilla会将缺陷转给相应的开发者，开发者可以使用Bugzilla做一个工作表，标明要做的事情的优先级、时间安排和跟踪记录。1.2.4 常见的软件缺陷管理工具2、禅道禅道是一款优秀的国产项目管理软件，它集产品管理、项目管理、质量管理、缺陷管理、文档管理、组织管理和事务管理于一体，是一款功能完备的项目管理软件，完美地覆盖了项目管理的核心流程。禅道分为专业和开源两个版本，专业版是收费软件，开源版是免费软件，对于日常的项目管理，开源版本已经足够使用。1.2.4 常见的软件缺陷管理工具3、JIRAJIRA是Atlassian公
13、司开发的项目与实务跟踪工具，被广泛用于缺陷跟踪、客户实务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。JIRA配置灵活、功能全面、部署简单、扩展丰富、易用性好，是目前比较流行的基于Java架构的管理工具。JIRA软件有两个认可度很高的特色：第一个是Atlassian公司对该开源项目实行免费提供缺陷跟踪服务；第二个是用户在购买JIRA软件同时将源代码也购置进来，方便做二次开发。1.3.1 软件测试简介软件测试的发展也经历了一个漫长的过程，其发展过程可用下图表示：1.3.2 软件测试的目的 对于软件开发来说，软件测试通过找到的问题缺陷帮助开发人员找到开发过程中存在的问题，包括软件开
14、发的模式、工具、技术等方面存在的问题与不足，预防下次缺陷的产生。对于软件测试来说，使用最少的人力、物力、时间等找到软件中隐藏的缺陷，保证软件的质量，也为以后软件测试积累丰富的经验。对于客户需求来说，软件测试能够检验软件是否符合客户需求，对软件质量进行评估和度量，为客户评审软件提供有力的依据。1.3.3 软件测试的分类1、按照测试阶段分类 单元测试：验证软件单元是否符合软件需求与设计，开发人员自测。冒烟测试：软件构建版本建立后，对系统的基本功能进行简单的测试，这种测试重点验证的是程序的主要功能，而不会对具体功能进行深入测试。集成测试：冒烟测试之后，将已经测试过的软件单元组合在一起测试它们之间的接
15、口，用于验证软件是否满足设计需求。1.3.3 软件测试的分类1、按照测试阶段分类 系统测试：将经过测试的软件在实际环境中运行，并与其他系统的成分（如数据库、硬件和操作人员等）组合在一起进行测试。验收测试：主要是对软件产品说明进行验证，逐行逐字的按照说明书的描述对软件产品进行测试，确保其符合客户的各项要求。1.3.3 软件测试的分类2、按照测试技术分类 黑盒测试：把软件（程序）当作一个有输入与输出的黑匣子，它把程序当作一个输入域到输出域的映射，只要输入的数据能输出预期的结果即可，不必关心程序内部是怎么样实现的。1.3.3 软件测试的分类2、按照测试技术分类白盒测试：测试人员了解软件程序的逻辑结构
16、、路径与运行过程，在测试时，按照程序的执行路径得出结果。白盒测试就是把软件（程序）当作一个透明的盒子，测试人员清楚的知道从输入到输出的每一步过程。1.3.3 软件测试的分类2、按照测试技术分类总结：相对于黑盒测试来说，白盒测试对测试人员的要求会更高一点，它要求测试人员具有一定的编程能力，而且要熟悉各种脚本语言。但是在软件公司里，黑盒测试与白盒测试并不是界限分明的，在测试一款软件时往往是黑盒测试与白盒测试相结合对软件进行完整全面的测试。1.3.3 软件测试的分类3、按照软件质量特性分类 功能测试：测试软件的功能是否满足客户的需求，包括准确性、易用性、适合性、互操作性等。性能测试：测试软件的性能是
17、否满足客户的需求，性能测试包括负载测试、压力测试、兼容性测试、可移植性测试和健壮性测试等。1.3.3 软件测试的分类4、按照自动化程度分类 手工测试：测试人员一条一条的执行代码完成测试工作。费时费力且很验证保证测试效果。自动化测试：借助脚本、自动化测试工具等完成相应的测试工作，它也需要人工的参与，但是它可以将要执行的测试代码或流程写成脚本，执行脚本完成整个测试工作。1.3.3 软件测试的分类5、按照测试项目分类 界面类测试：验证软件界面是否符合客户需求。安全性测试：试软件在没有授权的内部或外部用户的攻击或恶意破坏时如何进行处理，是否能保证软件与数据的安全。文档测试：以需求分析、软件设计、用户手
18、册、安装手册为主，主要验证文档说明与实际软件之间是否存在差异。1.3.3 软件测试的分类6、其他分类 测试：软件上线之前进行的版本测试。由开发人员和测试人员或者用户协助进行测试。测试人员记录使用过程中出现的错误与问题，整个测试过程是可控的。测试：软件上线之后进行的版本测试。由用户在使用过程中发现错误与问题并进行记录，然后反馈给开发人员进行修复。1.3.3 软件测试的分类6、其他分类 回归测试：对修改后的程序重新进行测试确认原有的缺陷已经消除并且没有引入新的缺陷，这个重新测试的过程就叫作回归测试。随机测试：没有测试用例、检查列表、脚本或指令的测试，它主要是根据测试人员的经验对软件进行功能和性能抽
19、查。1.4.1 软件测试与软件开发的关系软件测试在项目各个阶段的作用如下：项目规划阶段：负责从单元测试到系统测试的整个测试阶段的监控。需求分析阶段：确定测试需求分析，即确定在项目中需要测试什么，同时制定系统测试计划。概要设计与详细设计阶段：制定单元测试计划和集成测试计划。编码阶段：开发相应的测试代码和测试脚本。测试阶段：实施测试并提交相应的测试报告。1.4.1 软件测试与软件开发的关系软件测试与软件开发的关系如右图。1.4.2 常见的软件测试模型1、V模型1.4.2 常见的软件测试模型1、V模型优点：将复杂的测试工作分成了目标明确的小阶段完成，具有阶段性、顺序性和依赖性，它既包含了对于源代码的
20、底层测试也包含了对于软件需求的高层测试。缺点：只能在编码之后才能开始测试，早期的需求分析等前期工作没有涵盖其中，因此它不能发现需求分析等早期的错误，这为后期的系统测试、验收测试埋下了隐患。1.4.2 常见的软件测试模型2、W模型1.4.2 常见的软件测试模型2、W模型优点：测试范围不仅包括程序，还包括需求分析、软件设计等前期工作，这样有利于尽早全面的发现问题。缺点：它将软件开发过程分成需求、设计、编码、集成等一系列的串行活动，无法支持迭代、自发性等需要变更调整的项目。1.4.2 常见的软件测试模型3、H模型H模型将测试活动完全独立了出来，形成一个完全独立的流程，这个流程将测试准备活动和测试执行
21、活动清晰的体现出来。测试流程和其他工作流程是并发执行的，只要某一个工作流程的条件成熟就可以开始进行测试。1.4.2 常见的软件测试模型4、X模型X模型的设计原理是将程序分成多个片段反复迭代测试，然后将多个片段集成再进行迭代测试。1.4.2 常见的软件测试模型4、X模型优点：对单独程序片段进行的相互分离的编码和测试，保证了测试效果。增加了探索测试，可以帮助测试人员发现计划之外的软件错误。缺点：频繁的集成会增加测试成本；探索测试对测试人员要求更高。1.5 软件测试原则 测试应基于客户需求。测试要尽早进行。穷尽测试是不可能的。遵循GoodEnough原则。测试缺陷要符合“二八”定理。避免缺陷免疫。测
22、试应基于客户需求所有的测试工作都应该建立在满足客户需求的基础上，从客户角度来看，最严重的错误就是软件无法满足要求。有时候，软件产品的测试结果非常完美，但却不是客户最终想要的产品，那么软件产品的开发就是失败的，而测试工作也是没有任何意义的。因此测试应依照客户的需求配置环境并且按照客户的使用习惯进行测试并评价结果。1.5 软件测试原则测试要尽早进行软件的错误存在于软件生命周期的各个阶段，因此应该尽早开展测试工作，把软件测试贯穿到软件生命周期的各个阶段中，这样测试人员能够尽早地发现和预防错误，降低错误修复的成本。尽早的开展测试工作有利于帮助测试人员了解软件产品的需求和设计，从而预测测试的难度和风险，
23、制定出完善的计划和方案，提高测试的效率。1.5 软件测试原则穷尽测试是不可能的由于时间和资源的限制，进行完全（各种输入和输出的全部组合）的测试是不可能的，测试人员可以根据测试的风险和优先级等确定测试的关注点，从而控制测试的工作量，在测试成本、风险和收益之间求得平衡。1.5 软件测试原则遵循GoodEnough原则GoodEnough原则是指测试的投入与产出要适当权衡，形成充分的质量评估过程，这个过程建立在测试花费的代价之上。测试不充分无法保证软件产品的质量，但测试投入过多会造成资源的浪费。随着测试资源投入的增加，测试的产出也是增加的，但当投入达到一定的比例后，测试的效果就不会明显增强了。因此在
24、测试时要根据实际要求和产品质量考虑测试的投入，最好使测试投入与产出达到一个GoodEnough状态。1.5 软件测试原则测试缺陷要符合“二八”定理一般情况下，软件80%的缺陷会集中在20%的模块中，缺陷并不是平均分布的。因此在测试时，要抓住主要矛盾，如果发现某些模块比其他模块具有更多的缺陷，则要投入更多的人力、精力重点测试这些模块以提高测试效率。1.5 软件测试原则避免缺陷免疫测试用例被反复使用，发现缺陷的能力就会越来越差；测试人员对软件越熟悉越会忽略一些看起来比较小的问题，发现缺陷的能力也越差，这种现象被称为软件测试的“杀虫剂”现象。它主要是由于测试人员没有及时更新测试用例或者是对测试用例和
25、测试对象过于熟悉，形成了思维定势。1.5 软件测试原则1.6.1 软件测试流程不同类型的软件产品测试的方式和重点不一样，测试流程也会不一样。同样类型的软件产品，不同的公司所制定的测试流程也会不一样。虽然不同软件的详细测试步骤不同，但它们所遵循的最基本的测试流程是一样的分析测试分析测试需求需求制定测试制定测试计划计划设计测试设计测试用例用例执行测试执行测试编写测试编写测试报告报告1.6.1 软件测试流程（1）分析测试需求测试人员在制定测试计划之前需要先对软件需求进行分析，以便对要开发的软件产品有一个清晰的认识，从而明确测试对象及测试工作的范围和测试重点。在分析需求时还可以获取一些测试数据，作为测
26、试计划的基本依据，为后续的测试打好基础。此外，分析测试需求也是对软件需求进行测试，以发现软件需求中不合理的地方。1.6.1 软件测试流程序号序号检查项检查项检查结果检查结果说明说明1 1是否覆盖了客户提出的所有需求项是【】否【】NA【】2 2用词是否清晰、语义是否存在歧义是【】否【】NA【】3 3是否清楚地描述了软件需要做什么以及不做什么是【】否【】NA【】4 4是否描述了软件的目标环境，包括软硬件环境是【】否【】NA【】5 5是否对需求项进行了合理的编号是【】否【】NA【】6 6需求项是否前后一致、彼此不冲突是【】否【】NA【】7 7是否清楚地说明了软件的每个输入、输出格式，以及输入与输出之
27、间的对应关系是【】否【】NA【】8 8是否清晰地描述了软件系统的性能要求是【】否【】NA【】9 9需求的优先级是否合理分配是【】否【】NA【】1010是否描述了各种约束条件是【】否【】NA【】1.6.1 软件测试流程被确定的测试需求必须是可核实的，测试需求必须有一个可观察、可评测的结果。无法核实的需求就不是测试需求。测试需求分析还要与客户进行交流，以澄清某些混淆，确保测试人员与客户尽早地对项目达成共识。注 意1.6.1 软件测试流程（2）制定测试计划测试计划一般要做好以下工作安排。确定测试范围：明确哪些对象是需要测试的，哪些对象不是需要测试的。制定测试策略：测试策略是测试计划中最重要的部分，它
28、将要测试的内容划分出不同的优先级，并确定测试重点。根据测试模块的特点和测试类型（如功能测试、性能测试）选定测试环境和测试方法（如人工测试、自动化测试）。1.6.1 软件测试流程 安排测试资源：通过对测试难度、时间、工作量等因素对测试资源合理安排，包括人员分配、工具配置等。安排测试进度：根据软件开发计划、产品的整体计划来安排测试工作的进度，同时还要考虑各部分工作的变化。在安排工作进度时，最好在各项测试工作之间预留一个缓冲时间以应对计划变更。预估测试风险：罗列出测试工作过程中可能会出现的不确定因素，并制定应对策略。1.6.1 软件测试流程（3）设计测试用例测试用例（Test Case）指的是一套详
29、细的测试方案，包括测试环境、测试步骤、测试数据和预期结果。不同的公司会有不同的测试用例模板，虽然它们在风格和样式上有所不同，但本质上是一样的，都包括了测试用例的基本要素。测试用例编写的原则是尽量以最少的测试用例达到最大测试覆盖率。1.6.1 软件测试流程（4）执行测试测试执行就是按照测试用例执行测试的过程，这是测试人员最主要的活动阶段。在执行测试时要根据测试用例的优先级进行。在执行测试过程中，测试人员要密切跟踪测试过程，记录缺陷、形成报告等，这一阶段是测试人员最重要的工作阶段。1.6.1 软件测试流程（5）编写测试报告一份完整的测试报告必须要包含以下几个要点。引言：测试报告编写目的、报告中出现
30、的专业术语解释及参考资料等。测试概要：介绍项目背景、测试时间、测试地点及测试人员等信息。测试内容及执行情况：描述本次测试模块的版本、测试类型，使用的测试用例设计方法及测试通过覆盖率，依据测试的通过情况提供对测试执行过程的评估结论，并给出测试执行活动的改进建议，以供后续测试执行活动借鉴参考。1.6.1 软件测试流程（5）编写测试报告 缺陷统计与分析：统计本次测试所发现的缺陷数目、类型等，分析缺陷产生的原因给出规避措施等建议，同时还要记录残留缺陷与未解决问题。测试结论与建议：从需求符合度、功能正确性、性能指标等多个维度对版本质量进行总体评价，给出具体明确的结论。测试报告的数据是真实的，每一条结论的
31、得出都要有评价依据，不能是主观臆断的。多学一招多学一招：测试的准入准出测试的准入准出测试准入标准如下：开发编码结束，开发人员在开发环境已经进行了单元测试，即开发人员完成自测。软件需求上规定的功能都已经实现。如果没有完全实现，开发人员提供测试范围。测试项目通过基本的冒烟测试，界面上的功能均已经实现，符合设计规定的功能。被测试项目的代码符合软件编码规范并已通过评审。开发人员提交了测试申请并提供了相应的文档资料。多学一招多学一招：测试的准入准出测试的准入准出 测试项目满足客户需求。所有测试用例都已经通过评审并成功执行。测试覆盖率已经达到要求。所有发现的缺陷都记录在缺陷管理系统。一二级错误修复率达到1
32、00%。三四级错误修复率达到了95%。所有遗留问题都已经有解决方案。测试项目的功能、性能、安全性等都满足要求。完成系统测试总结报告。测试准出标准如下：多学一招多学一招：测试的准入准出测试的准入准出测试中需要暂停的情况包括以下几种。测试人员进行冒烟测试时发现重大缺陷，导致测试无法正常进行，需要暂停并返回开发。测试人员进行冒烟测试时发现bug过多可以申请暂停测试，返回开发。测试项目需要更新调整而暂停，测试工作也要相应暂停。如果测试人员有其他优先级更高的任务时，可以申请暂停测试。1.6.2 摩拜单车App开锁用车功能测试流程摩拜单车业务流程图：1.6.2 摩拜单车App开锁用车功能测试流程（1）分析
33、测试需求摩拜单车的用车功能需要测试三个内容：扫描二维码开锁。输入车辆编号开锁。调取手机手电筒。1.6.2 摩拜单车App开锁用车功能测试流程（2）制定测试计划软件版本软件版本摩拜单车摩拜单车App 8.10.0App 8.10.0版本版本模块模块开锁用车负责人负责人测试组长测试人员测试人员测试员1、测试员2测试时间测试时间2019.3.12019.3.3测试用例测试用例001012回归测试回归测试2019.4.102019.4.131.6.2 摩拜单车App开锁用车功能测试流程（2）设计测试用例 白天：扫码开锁。白天：手动输入车辆编号开锁。晚上：扫码+手电筒开锁。晚上：手动输入车辆编号开锁。1
34、.6.2 摩拜单车App开锁用车功能测试流程注 意开锁用车模块与其他模块的关联，在开锁时，如果有正在运行的订单或者有未支付的订单，则无法开锁。1.6.2 摩拜单车App开锁用车功能测试流程序号序号用例说明用例说明前置操作前置操作操作操作预期结果预期结果备注备注001001开锁没有正在运行的订单，也没有未支付的订单白天扫码进入数码解锁页面 002002开锁有正在运行的订单 白天扫码无法开锁，提示正在骑行，需结束骑行并支付才能解锁 003003开锁有未支付的订单白天扫码无法开锁，提示支付未支付订单才能解锁 004004开锁没有正在运行的订单，也没有未支付的订单白天手动输入车辆编号进入数码解锁页面
35、1.6.2 摩拜单车App开锁用车功能测试流程序号序号 用例说明用例说明前置操作前置操作操作操作预期结果预期结果备注备注005005开锁有正在运行的订单白天手动输入车辆编号无法开锁，提示正在骑行，需结束骑行并支付才能解锁 006006开锁有未支付的订单白天手动输入车辆编号无法开锁，提示支付未支付订单才能解锁 007007开锁没有正在运行的订单，也没有未支付的订单晚上扫码开启手机手电筒，扫码成功，进入数码解锁页面 008008开锁有正在运行的订单 晚上扫码无法开锁，提示正在骑行，需结束骑行并支付才能解锁 1.6.2 摩拜单车App开锁用车功能测试流程序号序号用例说明用例说明前置操作前置操作操作操
36、作预期结果预期结果备注备注009009开锁有未支付的订单晚上扫码无法开启手电筒，提示支付未支付订单才能解锁 010010开锁没有正在运行的订单，也没有未支付的订单晚 上 手 动输 入 车 辆编号进入数码解锁页面 011011开锁有正在运行的订单晚 上 手 动输 入 车 辆编号无法开锁，提示正在骑行，需结束骑行并支付才能解锁 012012开锁有未支付的订单晚 上 手 动输 入 车 辆编号无法开锁，提示支付未支付订单才能解锁 1.6.2 摩拜单车App开锁用车功能测试流程（3）测试执行执行测试用例，对测试过程进行记录和跟踪。对于测试发现的缺陷整理成缺陷报告。缺陷缺陷IDID190021000619
37、00210006测试软件名称测试软件名称摩拜单车App测试软件版本测试软件版本8.10.0缺陷发现日期缺陷发现日期20190302测试人员测试人员测试员1、测试员2缺陷描述缺陷描述该版本的开锁用车功能在晚上扫码开锁时，无法启动手电筒，导致扫码不成功而无法完成开锁功能。1.6.2 摩拜单车App开锁用车功能测试流程附件（可附图）附件（可附图）附图附图1 1（链接）（链接）缺陷类型缺陷类型功能类型缺陷缺陷严重程度缺陷严重程度严重缺陷优先级缺陷优先级立即解决测试环境测试环境手机信息：华为 honor AAL-AL20内存：4.0GB系统类型：Android8.0.0操作系统重现步骤重现步骤1、进入摩
38、拜单车App页面，点击“扫码开锁”按钮。2、手电筒未打开，扫取摩拜单车二维码，扫取失败。备注备注无1.6.2 摩拜单车App开锁用车功能测试流程（5）编写测试报告测试结束之后（包括回归测试），编写一个完整的测试报告，测试报告的内容非常多，一般都是长达十几页甚至几十页的word文档，或者是在相应的软件测试管理工具中编写。在测试报告中详细描述本次测试过程及结论。1.7 本章小结本章对软件测试基础知识进行了讲解，首先介绍了软件相关的知识，包括软件生命周期、软件开发模型、软件质量等；其次讲解了软件缺陷管理，包括软件缺陷产生的原因、分类、处理流程及常用的缺陷管理工具；接着讲解了软件测试的概念、目的、分类、软件测试与软件开发的关系、软件测试的原则；最后讲解了软件测试的基本流程，并且使用摩拜单车App开锁功能的测试让读者简单认识了一下软件测试的基本流程。本章的知识细碎且独立，但却是软件测试入门的必备知识，为后续章节更深入的学习软件测试打下坚实的基础。
