From 255b8cbe9a71934f11ee4e70144105ea29c405f9 Mon Sep 17 00:00:00 2001 From: Ther Date: Wed, 15 Sep 2021 08:46:32 +0000 Subject: [PATCH] =?UTF-8?q?19990116=E7=8E=8B=E6=99=93=E6=B0=91?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- README.md | 151 ++++++++++++++++++++++++++++++------------------------ 1 file changed, 83 insertions(+), 68 deletions(-) diff --git a/README.md b/README.md index dbaae73..94bf635 100644 --- a/README.md +++ b/README.md @@ -2,7 +2,7 @@ ## 写在最前面 ### 1 课程目标 * 掌握基础的软件测试理论、测试方法和策略 -* 掌握常用工具使用 +* 掌握常用工具的使用方法 * 根据需求和设计文档独立编写测试计划、测试方案、测试用例以及测试报告 ### 2 主要内容 * 软件测试基础知识 @@ -16,6 +16,10 @@ ### 3 课程安排 学时安排：72课时（理论36+实践36） 教材：清华大学出版社 《软件测试》(第2版) 周元哲 编著 +考勤：不定时间，不定形式 +作业：云班课提交 +期末：分组大作业 +成绩：考勤+平时作业+大作业 ### 4 课程资源 * 课程内容文档 [gitee 课程地址](https://gitee.com/XiaFuXiangFei/software-testing) * 课程思维导图 @@ -46,7 +50,7 @@ * 《开发计划》 ##### 管理文档 -从管理的角度规定涉及软件生存的信息： +从管理的角度规定涉及软件存在的信息： 1. 职责定义 2. 开发过程的每个阶段的进度和进度变更的记录 3. 软件变更情况的记录 @@ -71,7 +75,7 @@ 1. 程序设计阶段：个体化生产、专用软件、规模小、功能单一、开发者即使用者。（软件 = 程序） 2. 程序系统阶段：多用户人机交互，实时系统和数据库管理系统。 3. 软件工程阶段：以软件的产品化、系列化、工程化和标准化为特征的软件产业发展起来，软件开发有了可以遵循的软件工程化的设计准则、方法和标准。 -4. 多层分布结构，面向服务架构 +4. 多层分布结构，面向服务架构。 #### 1.1.4 软件项目 软件项目是一种特殊的项目，具有如下特点： @@ -166,9 +170,10 @@ The process of executing a program with the intent of finding errors. 强调将测试和开发同等重要，对于开发阶段都有与之对应的测试阶段。 **优点：** -相对于瀑布模型，V模型测试能够尽早的进入到开发阶段。 +相对于瀑布模型，V模型测试能够尽早的进入到开发阶段。 + **缺点：** -虽然测试尽早的进入到开发阶段，但是真正进行软件测试是在编码之后，这样忽视了测试对需求分析、系统设计的验证，时间效率上也大打折扣。 +虽然测试尽早地进入到开发阶段，但是真正进行软件测试是在编码之后，这样忽视了测试对需求分析、系统设计的验证，时间效率上也大打折扣。 **W模型(双V模型)** ![W模型](https://gitee.com/XiaFuXiangFei/software-testing/raw/main/images/w-model.png) @@ -183,6 +188,10 @@ W 模型是顺序性的、不可逆的，需求的变更和调整，依旧不方 ![螺旋模型](https://gitee.com/XiaFuXiangFei/software-testing/raw/main/images/lx-model.png) 大型软件项目通常有很多不确定性和风险，如果采用瀑布式线性过程模型，失败风险很大，因此需要采取一种渐进式的演化过程模型。将产品分解成增量版本，每个版本单独测试。 +**优点：** +设计的灵活性，在开发过程中能及时作出调整；以小的分段来构建大型系统,使成本计算变得简单容易；客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性；客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品。 +**缺点：** +螺旋模型每个阶段都要提出方案，进行风险分析，研发周期较长，效率较低。另一方面，它要求软件开发人员具有丰富的风险评估经验和专业知识，否则将带来真正的风险。 **敏捷模型** ![敏捷模型](https://gitee.com/XiaFuXiangFei/software-testing/raw/main/images/mj-model.png) @@ -199,13 +208,19 @@ W 模型是顺序性的、不可逆的，需求的变更和调整，依旧不方 3. 经常交付可以工作的软件，从几星期到几个月，时间尺度越短越好。 4. 业务人员和开发者应该在整个项目过程中始终朝夕在一起工作。 5. 围绕斗志高昂的人进行软件开发，给开发者提供适宜的环境，满足他们的需要，并相信他们能够完成任务。 -6. 在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。 +6. 在开发小组中最有效率也最有效果的信息传达方式是面对面地交谈。 7. 可以工作的软件是进度的主要度量标准。 8. 敏捷过程提倡可持续开发。出资人、开发人员和用户应该总是维持不变的节奏。 9. 对卓越技术与良好设计的不断追求将有助于提高敏捷性。 -10. 简单——尽可能减少工作量的艺术至关重要。 +10. 简单——尽可能减少工作量是关键。 11. 最好的架构、需求和设计都源自自我组织的团队。 -12. 每隔一定时间，团队都要总结如何更有效率，然后相应地调整自己的行为。 +12. 每隔一段时间，团队都要总结如何更有效率，然后相应地调整自己的行为。 + +敏捷宣言强调的敏捷软件开发的四个核心价值是： +• 个体和互动高于流程和工具 +• 工作的软件高于详尽的文档 +• 客户合作高于合同谈判 +• 响应变化高于遵循计划 **解读：** @@ -214,13 +229,13 @@ W 模型是顺序性的、不可逆的，需求的变更和调整，依旧不方 在工作形式上，整个团队平时坐在一起工作，从物理空间上创造了更加便捷面对面的沟通机会。在团队职责上，团队内部具备完成软件交付的角色(能力)，团队所有人对软件的质量负责，开发过程由团队内部把控，业务价值团队内部快速流动，在任何环节都能及时获得反馈。同时，每个角色都更容易从全局视角去思考软件，避免了传统部门墙模式下的视角割裂和协作障碍。 * 工作的软件高于详尽的文档 -为客户交付可工作的软件是我们的核心目标，我们应该尽早交付可进行端到端测试的代码，该目标决定了我们不应该花过多精力在面面俱到的文档上，但这不代表我们要抵制任何文档。实践证明，轻量级的文档策略有助于团队高质量交付可工作的软件。 +在软件开发方面，我们的核心目标是为客户提供可工作的软件，而我们应该尽早地发布可以进行端到端测试的代码，虽然这个目标决定了我们不应该在面面俱到的文档上花费太多的精力，但是这并不意味着我们要抵制所有文档。实践证明，轻量级的文档策略有助于团队高质量交付可工作的软件。 * 客户合作高于合同谈判 主动拥抱变化，及时响应，持续交付。 * 响应变化高于遵循计划 -通过高效的协作，获取快速的反馈，从而尽早做出调整，减少浪费 +通过高效的协作，获取快速的反馈，从而尽早做出调整，减少浪费。 **缺点:** 由于其项目周期很长，所以很难保证开发的人员不更换，而缺少文档就会造成在交接的过程中出现很大的困难。 @@ -229,16 +244,16 @@ W 模型是顺序性的、不可逆的，需求的变更和调整，依旧不方 ### 1.4 软件缺陷 #### 1.4.1 缺陷定义 -IEEE729-1983 对缺陷有一个标准的定义：从产品内部看，缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题；从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背。 +IEEE729-1983 (电气和电子工程师协会标准IEEE)对缺陷有一个标准的定义：从产品内部看，缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题；从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背。 符合下面4个条件之一就是缺陷： 1. 软件未达到规格说明书中规定的功能。 -2. 软件出现了产品说明数中指明的不会出现的错误。 +2. 软件出现了产品说明书中指明的不会出现的错误。 3. 软件功能超出了产品说明书中指明的范围。 4. 软件难于理解，不易使用，运行速度慢，或者最终用户认为软件使用效果不好。 #### 1.4.2 产生原因 -1. 软件本身复杂性，产生大量不确定因素。 +1. 软体自身的复杂性，造成许多不确定性。 2. 成本、时间限制，导致流程不够完善，文档缺失，缺乏严谨的评审。 3. 人员本身技能水平、责任心、交流沟通不顺畅。 4. 不全面或者没有复审。 @@ -246,9 +261,9 @@ IEEE729-1983 对缺陷有一个标准的定义：从产品内部看，缺陷是 #### 1.4.3 缺陷来源 | 缺陷来源 | 描述 | | ------------ | -------------------------------- | -| 需求说明书 | 需求说明书错误或描述不清 | -| 设计文档 | 设计文档描述不准确，与需求不一致 | -| 系统集成接口 | 各模块参数不匹配 | +| 需求说明书 | 需求说明书的错误或不清楚引起的问题 | +| 设计文档 | 设计文档描述不准确，与需求说明书不一致的问题 | +| 系统集成接口 | 系统各模块参数不匹配、开发组之间缺乏协调引起的缺陷 | | 数据流（库） | 数据字典、数据库中的错误 | | 程序代码 | 编码问题 | @@ -327,13 +342,13 @@ IEEE729-1983 对缺陷有一个标准的定义：从产品内部看，缺陷是 6. bug描述：bug的产生环境、详细步骤、期望结果、实际结果。 7. 附件：包括但不仅限于截图、日志、录像、所用到的示例文件以及应用；同样是方便复现解决缺陷的。 -以上是上报bug、创建bug必须的，在后续我们还会对bug进行修复、复测等工作，那在为了记录后续工作，bug还应该包含： +以上是上报bug、创建bug必须的，在后续我们还会对bug进行修复、复测等工作，那么为了记录后续工作，bug还应该包含： 1. bug状态：开始、修复中、修复完成、提测、测试中、测试通过/失败、关闭等，后续bug周期中会讲到。 2. bug修订人：bug修订人员。 3. bug复测人：通常是谁报的bug最后返回给谁测试，但是在某些情况下比如bug报告人任务积累太多/不在的情况下也会分给其他人，所以通常会记录bug复测责任人。 -4. bug修订说明：由bug修订人来写，说明bug产生原因，修改思路等。 -5. bug复测说明：由复测人员来写，说明复测过程，复测结果等。 +4. bug修订说明：由bug修订人填写，说明bug产生原因，修改思路等。 +5. bug复测说明：由复测人员填写，说明复测过程，复测结果等。 6. bug备注：备注，以便记录一些额外信息。 #### 1.4.8 缺陷预防 @@ -343,11 +358,11 @@ IEEE729-1983 对缺陷有一个标准的定义：从产品内部看，缺陷是 ### 1.5 软件测试行业 #### 1.5.1 行业现状 -软件系统越来越复杂，一个软件不能够由单独的软件工程师单独编写，而是由团队进行配合，每个人可能只负责一个模块，对于全局没有过多的了解，这时如果运行软件就会容易产生很多的错误。在行业内将这些错误叫做BUG。并且每一个软件工程师都会有思维的死角，自己不容易发现自己编写出来的错误。所以这个时候就需要专门的软件测试工程师用专业的测试方式来检查软件。检查该软件是否符合客户要求的产品设计，是否能够符合大多数用户的使用习惯，如果发现异常状态及时进行处理。软件市场虽然远远没有达到饱和但是各种各样功能的软件也层出不穷竞争激烈，对软件开发的质量要求也是日益增高。 +软件系统越来越复杂，一个软件不能够由单独的软件工程师单独编写，而是由团队进行配合，每个人可能只负责一个模块，对于全局没有过多地了解，这时如果运行软件就会容易产生很多的错误。在行业内将这些错误叫做BUG。并且每一个软件工程师都会有思维的死角，自己不容易发现自己编写出来的错误。所以这个时候就需要专门的软件测试工程师用专业的测试方式来检查软件。检查该软件是否符合客户要求的产品设计，是否能够符合大多数用户的使用习惯，如果发现异常状态及时进行处理。软件市场虽然远远没有达到饱和但是各种各样功能的软件也层出不穷竞争激烈，对软件开发的质量要求也是日益增高。 我国软件测试行业起步较晚，发展较慢，直到21世纪初期，我国才逐步开始重视软件测试行业。但近年来，软件行业的快速发展为软件测试行业的发展提供了良好的基础，随着我国软件测试行业的发展，行业内企业向规模化发展将获得规模效应，可以有效降低企业的单位成本;而软件测试技术的不断发展，也将淘汰那些技术实力较弱的企业，促使行业内企业向专业化方向发展。 -在软件业较发达的国家，软件测试产业已形成规模，比较发达，软件测试不仅早已成为软件开发的一个重要组成部分，而且在整个软件开发的系统工程中占据着相当大的比重。在微软公司内部，软件测试人员与软件开发人员的比例一般为1.5∶1到2.5∶1左右，即一个开发人员背后，有至少两位测试人员在工作，以保证软件产品的质量1。国外优秀的软件开发机构把40%的工作花在软件测试上，软件测试费用占软件开发总费用的30%至50%，对于一些要求高可靠性、高安全性的软件，测试费用甚至相当于整个软件项目开发所有费用的3至5倍。 +在软件业较发达的国家，软件测试产业已形成规模，比较发达，软件测试不仅早已成为软件开发的一个重要组成部分，而且在整个软件开发的系统工程中占据着相当大的比重。在微软公司内部，软件测试人员与软件开发人员的比例一般为1.5∶1到2.5∶1左右，也就是说，一个开发者背后至少有两个测试人员在工作，以保证软件产品的质量。国外优秀的软件开发机构把40%的工作花在软件测试上，软件测试费用占软件开发总费用的30%至50%，对于一些要求高可靠性、高安全性的软件，测试费用甚至相当于整个软件项目开发所有费用的3至5倍。 从国内软件公司软件测试部门的独立性来看，多数软件企业没有专门的测试技术部门，软件测试程序也不太规范，多数企业也不懂测试，对测试的投入资金过少。大多数是在经过简单的测试之后，就认为是没有问题了，就交于用户了，让用户去“测试”。于是，软件产品在没有经过严格测试的情况下就发布了。对国内消费类软件而言，经常出现一些已经推向市场的产品由于被发现有严重缺陷而导致大量退货的现象。定制的行业软件，常出现一再返工、无限期的修改和维护的现象。 @@ -432,7 +447,7 @@ IEEE729-1983 对缺陷有一个标准的定义：从产品内部看，缺陷是 ### 2.2 测试的目的和原则 #### 2.2.1 测试的目的 -1. 测试不仅仅是找出错误。通过分析错误产生的原因和错误的发展趋势，可以帮助项目管理者发现当前软件开发过程中的缺陷，以便即时改进。 +1. 测试不仅仅是找出错误。通过分析错误产生的原因和错误的发展趋势，可以帮助项目管理者发现当前软件开发过程中的缺陷，以便及时改进。 2. 检测产品是否符合用户要求。 3. 没有发现错误的测试也是有价值的，完整的测试是评定软件质量的一种方法。 4. 提升用户体验。 @@ -507,23 +522,23 @@ IEEE729-1983 对缺陷有一个标准的定义：从产品内部看，缺陷是 #### 2.4.4 测试用例维护 **术语** -1. 测试编号：测试用例的编号 -2. 测试项：测试的功能点说明 -3. 前置条件：该测试用例的前提条件，比如测试wangdachui／dachui12345（用户名／密码）账户是否能正确登录进去，那前提wangdachui／dachui12345已定是注册过的 -4. 测试步骤：就是测试的所有操作步骤，最好是每一个步骤应该对应一个期望结果，最少也得一个测试用例对应一个期望结果 -5. 期望结果：就是希望得到的结果（正确的结果） -6. 测试结果：实际测试的结果，可选项有：通过、不通过、暂时挂起／锁定（就是暂时不测试）； -7. 对应的bug：当期望结果与实际结果不符时测试不通过，此时需要上报bug（纪录缺陷），bug需要与测试用例对应 -8. 测试执行人：实际由谁来执行测试用例；也有任务分配人的选项，就是测试用例分配给哪个测试员来测试 -9. 备注：做一些备注或者测试的说明 -10. 合法用户：就是已经注册过的用户 -11. 非法用户：没有注册过；注册过但是用户名／密码不匹配的；本文特指未注册过的用户 +1. 测试编号：测试用例的编号。 +2. 测试项：测试的功能点说明。 +3. 前置条件：该测试用例的前提条件，比如测试wangdachui／dachui12345（用户名／密码）账户是否能正确登录进去，那前提wangdachui／dachui12345已定是注册过的。 +4. 测试步骤：就是测试的所有操作步骤，最好是每一个步骤应该对应一个期望结果，最少也得一个测试用例对应一个期望结果。 +5. 期望结果：就是希望得到的结果（正确的结果）。 +6. 测试结果：实际测试的结果，可选项有：通过、不通过、暂时挂起／锁定（就是暂时不测试）。 +7. 对应的bug：当期望结果与实际结果不符时测试不通过，此时需要上报bug（纪录缺陷），bug需要与测试用例对应。 +8. 测试执行人：实际由谁来执行测试用例；也有任务分配人的选项，就是测试用例分配给哪个测试员来测试。 +9. 备注：做一些备注或者测试的说明。 +10. 合法用户：就是已经注册过的用户。 +11. 非法用户：没有注册过；注册过但是用户名／密码不匹配的；本文特指未注册过的用户。 测试用例维护一般分为以下几种情况： -1. 产品特性没变：漏测或者环境变更，这个时候版本没变，测试用例增加和修改均可 -2. 原有特性变化：功能变化，只能新增，不能修改，还要兼容老版本 -3. 原有功能取消：测试用例在新版本上置为“空”标志或者“无效状态”，对于先前版本有效 -4. 新增功能：新增用例，对应新版本标志 +1. 产品特性没变：漏测或者环境变更，这个时候版本没变，测试用例增加和修改均可； +2. 原有特性变化：功能变化，只能新增，不能修改，还要兼容老版本； +3. 原有功能取消：测试用例在新版本上置为“空”标志或者“无效状态”，对于先前版本有效； +4. 新增功能：新增用例，对应新版本标志； #### 2.4.5 测试用例设计误区 1. 测试用例设计等同于测试输入数据设计 @@ -533,37 +548,37 @@ IEEE729-1983 对缺陷有一个标准的定义：从产品内部看，缺陷是 ### 2.5 测试停止标准 #### 2.5.1 软件测试停止总体标准 -1. 测试超过了预定时间 -2. 执行了所有的测试用例，并没有发现故障 -3. 使用特定的测试用例设计方法作为判断测试停止的基础 -4. 给出测试停止的要求 -5. 根据经单位时间内查出故障的数量决定是否停止测试 +1. 测试超过了预定时间。 +2. 执行了所有的测试用例，并没有发现故障。 +3. 使用特定的测试用例设计方法作为判断测试停止的基础。 +4. 给出测试停止的要求。 +5. 根据经单位时间内查出故障的数量决定是否停止测试。 6. 软件系统经过了单元、集成、系统测试，分别达到停止标准。通过验收测试，得出验收测试结论。 -7. 软件项目暂停以进行调整，测试应随之暂停，并备份暂停点数据。或者软件项目开发生命周期内出现重大估算、进度偏差，需暂停或终止时，测试应随之暂停或终止，并备份数据 +7. 软件项目暂停以进行调整，测试应随之暂停，并备份暂停点数据。或者软件项目开发生命周期内出现重大估算、进度偏差，需暂停或终止时，测试应随之暂停或终止，并备份数据。 #### 2.5.2 软件测试各阶段停止标准 ##### 单元测试停止标准 -1. 单元测试用例已经通过评审 -2. 按照单元测试计划完成了所有规定单元测试 -3. 达到了测试计划中关于单元测试所规定的覆盖率要求 -4. 被测试的单元每千行代码必须发现至少3个错误 -5. 软件单元功能与设计一致 -6. 单元测试中发现的错误已经得到修改，各级缺陷修复率达到标准 +1. 单元测试用例已经通过评审。 +2. 按照单元测试计划完成了所有规定单元测试。 +3. 达到了测试计划中关于单元测试所规定的覆盖率要求。 +4. 被测试的单元每千行代码必须发现至少3个错误。 +5. 软件单元功能与设计一致。 +6. 单元测试中发现的错误已经得到修改，各级缺陷修复率达到标准。 ##### 集成测试停止标准 -1. 集成测试用例已经通过评审 -2. 按照集成测试计划和增量集成策略完成了整个系统的集成测试 -3. 达到了测试计划中关于集成测试所规定的覆盖率要求 -4. 被测试的集成工作版本每千行代码必须发现至少2个错误 -5. 集成工作版本满足设计定义的各项功能、性能要求 -6. 在集成测试中发现的错误已经得到修改，各级缺陷修复率达到标准 +1. 集成测试用例已经通过评审。 +2. 按照集成测试计划和增量集成策略完成了整个系统的集成测试。 +3. 达到了测试计划中关于集成测试所规定的覆盖率要求。 +4. 被测试的集成工作版本每千行代码必须发现至少2个错误。 +5. 集成工作版本满足设计定义的各项功能、性能要求。 +6. 在集成测试中发现的错误已经得到修改，各级缺陷修复率达到标准。 ##### 系统测试停止标准 -1. 系统测试用例已经通过评审 -2. 按照系统测试计划完成了系统测试 -3. 达到了测试计划中关于系统测试所规定的覆盖率要求 -4. 被测试的系统每千行代码必须发现至少1个错误 -5. 系统测试满足设计需求规格说明书要求 -6. 在系统测试中发现的错误已经得到修改，各级缺陷修复率达到标准 +1. 系统测试用例已经通过评审。 +2. 按照系统测试计划完成了系统测试。 +3. 达到了测试计划中关于系统测试所规定的覆盖率要求。 +4. 被测试的系统每千行代码必须发现至少1个错误。 +5. 系统测试满足设计需求规格说明书要求。 +6. 在系统测试中发现的错误已经得到修改，各级缺陷修复率达到标准。 ### 2.6 知识点总结 @@ -576,11 +591,11 @@ IEEE729-1983 对缺陷有一个标准的定义：从产品内部看，缺陷是 黑盒测试从用户的角度出发，以输入数据与输出数据的对应关系进行测试，数据驱动。 黑盒测试注重测试软件的功能需求，主要视图发现下列几类错误 -1. 功能不正确或遗漏 -2. 界面错误 -3. 数据库访问错误 -4. 性能错误 -5. 初始化和终值错误 +1. 功能不正确或遗漏； +2. 界面错误； +3. 数据库访问错误； +4. 性能错误； +5. 初始化和终值错误； ### 3.2 等价类划分 等价类是指某个输入域的子集合。在该子集合中，测试某等价类的代表值就等于对这类其他值的测试，对于揭露程序的错误是等效的。 @@ -601,8 +616,8 @@ IEEE729-1983 对缺陷有一个标准的定义：从产品内部看，缺陷是 7. 在规定了输入数据必须遵守规则的情况下，可以确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。 8. 在确知已划分的等价类中各元素在程序处理中的方式不同的情况下，则应再将改等价类进一步划分为更小的等价类。 #### 3.2.2 设计测试用例步骤 -1. 形成等价类表，每一等价类规定一个唯一编号 -2. 设计测试用例，使其尽可能多的覆盖尚未覆盖的有效等价类 +1. 形成等价类表，每一等价类规定一个唯一编号。 +2. 设计测试用例，使其尽可能多的覆盖尚未覆盖的有效等价类。 3. 设计一个新的测试用例，使其只覆盖一个无效等价类，重复这一步直到所有无效等价类均被覆盖。 #### 3.2.3 等价类举例 我们要测试学习成绩这一输入框（假设总成绩都是100），那么我们就可以如下图划分，有效的成绩是>=0且<=100的，无效的是<0和>100这两部分。 -- Gitee