diff --git a/README.md b/README.md index 4340c9a931d36d33f3af17acf0efc0a5cb8c4e2e..0f23330a466bd6f89fe1d9f3642644d3267bcabd 100644 --- a/README.md +++ b/README.md @@ -103,19 +103,19 @@ **输出：**《需求规格说明书》 #### 1.2.4 评审 -**描述：** 评审就是做审查，对这个阶段的工作进行审查，看是否偏离或者有遗漏（比如：设计和工厂的各个环节都有相关的审查，审查材料是否合格、设计是否符合规定、按照工人/设计出的材料需求是否足够或者多余等等，这些审查都是评审）；评审一般由相应工作人员来参与。 +**描述：** 评审就是做审查，对这个阶段的工作进行审查，看是否偏离主题或者有无遗漏内容（如：设计和工厂的各个环节都有相关的审查，审查材料是否合格、设计是否符合规定、按照工人设计出的材料需求是否足够或者多余等等），评审一般由相应工作人员来参与。 **参与者：** 每个阶段的评审一般都是各职能部门内部审核，也可以申请其他相关人员审核，比如需求评审，一般是产品经理、项目经理、测试人员、开发人员一起评审；系统设计一般是项目经理、开发人员评审；测试策略评审一般是测试组内部评审等等 #### 1.2.5 设计 -**描述：** 架构师根据需求确定产品或者项目的场景、特点，选择合适的框架，技术使项目实现最优化。在此基础上将系统进行概要设计，包括系统总体数据结构、数据库结构、模块结构以及它们之间的关系等。开发人员根据概要设计对具体模块进行详细设计，包括接口、参数等。此处设计会形成概要设计文档和详细设计文档。 +**描述：** 架构师根据需求确定产品或者项目的场景、特点，选择合适的框架，利用相关技术使项目实现最优化。在此基础上将系统进行概要设计，包括系统总体数据结构、数据库结构、模块结构以及各个结构之间的关系等。开发人员根据概要设计对具体模块进行详细设计，包括接口、参数等。此处设计会形成概要设计文档和详细设计文档。 **参与者：** 项目经理、架构师、开发人员、测试人员 #### 1.2.6 编码 -**描述：** 开发人员根据详细设计文档对系统进行模块化开发，在确定参数和接口的情况下，根据需求对模块内部进行方法级别的设计和编码以及自测，对产品功能进行一一实现。 +**描述：** 开发人员根据详细设计文档对系统进行模块化开发，在确定参数和接口的情况下，根据需求对模块内部进行方法级别的设计、编码以及自测，对产品功能进行一一实现。 -**参与者：** 开发 +**参与者：** 开发人员 #### 1.2.7 提测 **描述：** 开发人员完成一个小迭代/小功能，且完成自测(开发编码完成后，一般都会自己检测下)，然后向测试部门发起提测，一般以邮件方式或者任务管理工具的任务流方式向测试部门通知xxx模块/功能可以测试。 @@ -131,20 +131,20 @@ - 测试评估 #### 1.2.9 部署/发版 -**描述：** 经过前面的各个阶段，产品已经可以出售或者面向大众了。配置管理人员进行封版、版本制作（针对产品来说）/部署上线（针对项目应用来说）。 +**描述：** 经过前面的各个阶段，产品已经可以出售或者面向大众了。配置管理人员对产品进行封版、版本制作（针对产品来说）、部署上线（针对项目应用来说）。 **参与人：** 配置管理人员、测试人员 #### 1.2.10 支持维护 -**描述：** 支持维护类似于我们日常中的售后，主要是对已卖出的产品/已上线的项目进行日常维护。包括纠错性维护和改进性维护两个方面。 +**描述：** 支持维护类似于我们日常中的售后，主要是对已卖出的产品、已上线的项目进行日常维护。主要方面包括纠错性维护和改进性维护。 -**参与人：** 支持维护人员/售后工程师 +**参与人：** 支持维护人员、售后工程师 ### 1.3 软件测试概述 #### 1.3.1 软件测试定义 软件测试的经典定义是：在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。 -IEEE（电气与电子工程师协会）：使用人工或自动手段来运行或测定某个软件系统的过程，其目的在于检测他是否满足规定的需求或弄清预期结果和实际结果的差别。 +IEEE（电气与电子工程师协会）：使用人工或自动手段来运行或测定某个软件系统的过程，其目的在于检测该软件系统是否满足规定的需求、弄清预期结果和实际结果的差别。 #### 1.3.2 测试发展历程 1. 1957年之前－调试为主(Debugging Oriented) @@ -172,7 +172,7 @@ The process of executing a program with the intent of finding errors. 5. 1988–至今－预防为主(Prevention Oriented) - 尽量早地介入并发现这些明显的或隐藏的bug，发现得越早，修复起来的成本越低，产生的风险也越小。 + 尽量早地介入并发现这些明显的或隐藏的bug，发现得越早，修复成本越低，风险也越小。 #### 1.3.3 测试与开发的关系 **瀑布模型** @@ -183,7 +183,7 @@ The process of executing a program with the intent of finding errors. 强调开发工作（计划、设计、开发、测试、维护等）各阶段之间的先后顺序，不可以并行操作。 -瀑布模型认为，测试是指代码完成后，处于运行维护阶段之前。如果需求和设计上存在缺陷，就会造成大量返工，增加成本。 +瀑布模型认为，测试是指代码完成后，处于运行维护阶段之前，如果需求和设计上存在缺陷，就会造成大量返工，增加成本。 为了更早的发现问题，测试应延伸需求评审，设计审查活动中，软件生命周期的每个阶段都应包含测试。 @@ -197,7 +197,8 @@ The process of executing a program with the intent of finding errors. 1. 单一流程，不可逆； 2. 风险显露得晚，纠正机会少； -3. 测试只是其中一个阶段，缺乏全过程测试思想。 +3. 测试只是其中一个阶段，缺乏全过程测试思想； +4.开发人员“阻塞状态”严重。 **V模型** @@ -211,7 +212,7 @@ The process of executing a program with the intent of finding errors. **缺点：** -虽然测试尽早的进入到开发阶段，但是真正进行软件测试是在编码之后，这样忽视了测试对需求分析、系统设计的验证，时间效率上也大打折扣。 +虽然测试尽早的进入到开发阶段，但是真正进行软件测试是在编码之后，这样忽视了测试对需求分析、系统设计的验证，时间效率低。 **W模型(双V模型)** @@ -235,6 +236,14 @@ W 模型是顺序性的、不可逆的，需求的变更和调整，依旧不方 螺旋模型是一种演化软件开发过程模型，它兼顾了快速原型的迭代的特征以及瀑布模型的系统化与严格监控。螺旋模型最大的特点在于引入了其他模型不具备的风险分析，使软件在无法排除重大风险时有机会停止，以减小损失。同时，在每个迭代阶段构建原型是螺旋模型用以减小风险的途径。螺旋模型更适合大型的昂贵的系统级的软件应用。 +**优点：** + +螺旋模型将风险分析扩展到各个阶段中，大幅度降低了软件开发的风险。 + +**缺点：** + +螺旋模型的控制和管理较为复杂，可操作性不强，对项目管理人员的要求较高。 + **敏捷模型** ![敏捷模型](https://gitee.com/XiaFuXiangFei/software-testing/raw/main/images/mj-model.png) @@ -245,6 +254,14 @@ W 模型是顺序性的、不可逆的，需求的变更和调整，依旧不方 在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。 +**优点：** + +敏捷模型持续关注卓越的技术和良好的设计，定期适应变化的环境，即使是最新的需求变化也受到欢迎。 + +**缺点：** + +敏捷模型缺乏对必要的设计和文件的重视，由于其项目周期很长，所以很难保证开发的人员不更换，而缺少文档就会造成在交接的过程中出现很大的困难。只有高级程序员才能在开发过程中做出所需的决策，因此，除非与经验丰富的资源相结合，否则对于新手程序员来说，他没有立足之地。 + **《联盟敏捷宣言》** 1. 最重要的是通过尽早和不断交付有价值的软件满足客户需要； 2. 我们欢迎需求的变化，即使在开发后期；敏捷过程能够驾驭变化，保持客户的竞争优势； @@ -279,9 +296,6 @@ W 模型是顺序性的、不可逆的，需求的变更和调整，依旧不方 通过高效的协作，获取快速的反馈，从而尽早做出调整，减少浪费。 -**缺点:** - -由于其项目周期很长，所以很难保证开发的人员不更换，而缺少文档就会造成在交接的过程中出现很大的困难。 ![敏捷开发流程](https://gitee.com/XiaFuXiangFei/software-testing/raw/main/images/mj-process.png) @@ -296,8 +310,8 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准 4. 软件难于理解，不易使用，运行速度慢，或者最终用户认为软件使用效果不好。 #### 1.4.2 产生原因 -1. 软件本身复杂性，产生大量不确定因素； -2. 成本、时间限制，导致流程不够完善，文档缺失，缺乏严谨的评审； +1. 软件本身的复杂性，会产生大量不确定因素； +2. 成本、时间的限制，导致流程不够完善，文档缺失，缺乏严谨的评审； 3. 人员本身技能水平、责任心、交流沟通不顺畅； 4. 不全面或者没有复审。 @@ -402,23 +416,23 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准 ### 1.5 软件测试行业 #### 1.5.1 行业现状 -软件系统越来越复杂，一个软件不能够由单独的软件工程师单独编写，而是由团队进行配合，每个人可能只负责一个模块，对于全局没有过多的了解，这时如果运行软件就会容易产生很多的错误。在行业内将这些错误叫做BUG。并且每一个软件工程师都会有思维的死角，自己不容易发现自己编写出来的错误。所以这个时候就需要专门的软件测试工程师用专业的测试方式来检查软件。检查该软件是否符合客户要求的产品设计，是否能够符合大多数用户的使用习惯，如果发现异常状态及时进行处理。软件市场虽然远远没有达到饱和但是各种各样功能的软件也层出不穷竞争激烈，对软件开发的质量要求也是日益增高。 +软件系统越来越复杂，一个软件不能够由单独的软件工程师单独编写，而是由团队进行配合，每个人可能只负责一个模块，对于全局没有过多的了解，这时如果运行软件就会容易产生很多的错误。在行业内将这些错误叫做BUG。并且每一个软件工程师都会有思维的死角，自己不容易发现自己编写出来的错误。所以这个时候就需要专门的软件测试工程师用专业的测试方式来检查软件。检查该软件是否符合客户要求的产品设计，是否能够符合大多数用户的使用习惯，如果发现异常状态需要及时进行处理。软件市场虽然远远没有达到饱和，但是各种各样功能的软件也层出不穷，竞争激烈，对软件开发的质量要求也是日益增高。 我国软件测试行业起步较晚，发展较慢，直到21世纪初期，我国才逐步开始重视软件测试行业。但近年来，软件行业的快速发展为软件测试行业的发展提供了良好的基础，随着我国软件测试行业的发展，行业内企业向规模化发展将获得规模效应，可以有效降低企业的单位成本;而软件测试技术的不断发展，也将淘汰那些技术实力较弱的企业，促使行业内企业向专业化方向发展。 在软件业较发达的国家，软件测试产业已形成规模，比较发达，软件测试不仅早已成为软件开发的一个重要组成部分，而且在整个软件开发的系统工程中占据着相当大的比重。在微软公司内部，软件测试人员与软件开发人员的比例一般为1.5∶1到2.5∶1左右，即一个开发人员背后，有至少两位测试人员在工作，以保证软件产品的质量。国外优秀的软件开发机构把40%的工作花在软件测试上，软件测试费用占软件开发总费用的30%至50%，对于一些要求高可靠性、高安全性的软件，测试费用甚至相当于整个软件项目开发所有费用的3至5倍。 -从国内软件公司软件测试部门的独立性来看，多数软件企业没有专门的测试技术部门，软件测试程序也不太规范，多数企业也不懂测试，对测试的投入资金过少。大多数是在经过简单地测试之后，就认为没有问题了，就交于用户了，让用户去“测试”。于是，软件产品在没有经过严格测试的情况下就发布了。对国内消费类软件而言，经常出现一些已经推向市场的产品由于被发现有严重缺陷而导致大量退货的现象。定制的行业软件，常出现一再返工、无限期的修改和维护的现象。 +从国内软件公司软件测试部门的独立性来看，多数软件企业没有专门的测试技术部门，软件测试程序也不太规范，多数企业也不懂测试，对测试的投入资金过少。大多数企业是在经过简单的测试之后，就认为没有问题了，就交于用户了，让用户去“测试”。于是，软件产品在没有经过严格测试的情况下就发布了。对国内消费类软件而言，经常出现一些已经推向市场的产品，由于被用户发现有严重缺陷而导致大量退货的现象。定制的行业软件，常出现一再返工、无限期的修改和维护的现象。 当前国内软件测试行业主要存在以下问题： 1. 软件规模越来越大，功能越来越复杂，如何进行充分而有效的测试成为难题； 2. 面向对象的开发技术越来越普及，但是面向对象的测试技术却刚刚起步； 3. 对于分布式系统整体性能还难以进行很好的测试； 4. 对于实时系统缺乏有效的测试手段； -5. 随着安全问题的日益突出，信息系统的安全性如何进行有效的测试与评估，成为世界性的难题； -6. 测试的自动化程度不高，手工测试过多，自动化测试工具和手工测试人员也缺乏较好的结合； -7. 缺乏软件测试意识、对其重视不够； -8. 在软件开发基本完成后才进行测试，也缺乏软件测试的统一标准； +5. 随着安全问题的日益突出，信息系统的安全性即如何进行有效的测试与评估，成为世界性的难题； +6. 测试的自动化程度不高，手工测试过多，自动化测试工具和手工测试人员缺乏较好的结合； +7. 缺乏软件测试意识、重视度不够； +8. 在软件开发基本完成后才进行测试，缺乏软件测试的统一标准； 9. 高校从师资储备到专业设置再到人才培养的机制薄弱。 国内外软件测试差距： @@ -462,19 +476,19 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准 > 有效的测试首先是指该软件具有可测试性。可测试性反映了软件质量的内在属性，是一个强内聚、弱耦合、接口明确的软件，它不会因为使用了某种测试工具，就证明被测试的软件具有可测试性。 2. 存在太多无法测试的东西； -> 在软件开发领域，确实存在一些看起来比另外一些东西难测试的东西，但是远非无法测试。在大多数情况下，发生这种情况还是由于被测试软件本身在设计时没有考虑到可测试性的问题。只不过这种不可测试性不是由于被测试软件内部的过紧耦合造成的，而是和外部某些很难测试的部分耦合过紧，从而表现出被测试软件本身很难测试的特征。这些很难测试的部分，比较常见的有图形界面、硬件、数据库等。 +> 在软件开发领域，确实存在一些看起来比另外一些东西难测试的东西，但是远非无法测试。在大多数情况下，发生这种情况还是由于被测试软件本身在设计时没有考虑到可测试性的问题。只不过这种不可测试性不是由于被测试软件内部的过紧耦合造成的，而是和外部某些很难测试的部分耦合过紧所造成的，从而表现出被测试软件本身很难测试的特征。这些很难测试的部分，比较常见的有图形界面、硬件、数据库等。 3. 软件开发完成后才进行测试； > 软件测试是一个系列过程活动，包括软件测试需求分析、测试计划设计、测试用例设计、执行测试，软件测试贯穿软件项目的整个生命过程，每一个阶段都要进行不同目的和内容的测试活动，以保证各个阶段的正确性。软件测试的对象不仅仅包括软件代码，还包括软件需求文档和设计等各类文档。软件开发与软件测试是交互进行的，例如，单元编码需要单元测试，模块组合阶段需要集成测试。如果等到软件编码结束后才进行测试，测试的时间将会很短，测试的覆盖面将很不全面，测试的效果也将很差。更严重的是，如果发现了软件需求阶段或概要设计阶段的错误，要修复该类错误，将会耗费大量的时间和人力。 4. 软件发布后发现质量问题，是测试人员的问题； -> 这种错误的认识非常伤害软件测试人员的积极性。软件中的错误可能来自软件项目中的各个过程，软件测试只能确认软件存在错误，不能保证软件没有错误，因此从根本上讲，软件测试不可能发现全部错误。从软件开发的角度看，软件的高质量不是软件测试人员测出来的，是靠软件生命周期的各个过程中设计出来的。如果出现软件错误，不能简单地归结为某一个人的责任，有些错误可能是技术原因，也可能是混乱的管理所致。因此，应该分析软件项目的各个过程，从过程改进方面寻找产生错误的原因和改进的措施。 +> 这种错误的认识非常伤害软件测试人员的积极性。软件中的错误可能来自软件项目中的各个过程，软件测试只能确认软件存在错误，不能保证软件没有错误。因此，从根本上讲，软件测试不可能发现全部错误。从软件开发的角度看，软件的高质量不是软件测试人员测出来的，是靠软件生命周期的各个过程中设计出来的。如果出现软件错误，不能简单地归结为某一个人的责任，有些错误可能是技术原因，也可能是混乱的管理所致。因此，应该分析软件项目的各个过程，从过程改进方面寻找产生错误的原因和改进的措施。 5. 软件测试很简单，就是点点点，是个人就能做； -> 随着软件工程学的发展和软件项目管理经验的提高，软件测试已经形成了一个独立的技术学科，演变成一个具有巨大市场需求的行业。软件测试技术不断更新和完善，新工具、新流程、新方法都在不断出现，因此，软件测试需要学习很多测试知识，更需要不断的实践经验和学习精神。 +> 随着软件工程学的发展和软件项目管理经验的提高，软件测试已经形成了一个独立的技术学科，演变成一个具有巨大市场需求的行业。软件测试技术不断更新和完善，新工具、新流程、新方法都在不断出现。因此，软件测试需要学习很多测试知识，更需要不断的学习精神和大量的实践经验。 6. 软件测试没有前途，只有程序员才是软件高手； -> 随着市场对软件质量要求的不断提高，软件测试将变得越来越重要，对测试人员的要求也越来越高。测试人员不仅要懂得如何测试，还要懂得被测软件的业务知识和专业知识.而开发人员往往只需要对自己开发的模块了解比较深，对算法掌握的程度要求高一些，所以，软件测试和开发人员只是工作的侧重点不同，并不存在水平差异的问题。 +> 随着市场对软件质量要求的不断提高，软件测试将变得越来越重要，对测试人员的要求也越来越高。测试人员不仅要懂得如何测试，还要懂得被测软件的业务知识和专业知识。而开发人员往往只需要对自己开发的模块了解比较深，对算法掌握的程度要求高一些，所以，软件测试和开发人员只是工作的侧重点不同，并不存在水平差异的问题。 7. 软件测试是测试人员的事情和程序员无关； > 开发和测试是相辅相成的过程，需要测试人员、程序员和系统分析师等保持密切的联系，需要交流和协调，以便提高测试效率。另外，对于单元测试，主要应该由程序员完成，必要时测试人员可以帮助设计测试样例。对于测试中发现的软件错误，很多都需要程序员通过修改编码才能修复。程序员通过有目的地分析软件错误的类型、数量，找出产生错误的位置和原因，以避免同样的错误发生，积累编程经验，提高软件开发能力。 @@ -492,10 +506,10 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准 > 开发和测试是合作伙伴的关系，在日常生活中要注意沟通技巧和方式，如意见不一致且不能说服对方的问题，上报给负责人去决定。 12. 测试少报bug开发就会高兴点，报告也会好看点； -> 遇到缺陷一定要上报，即使他不能稳定复现（当然测试要尽可能的再现缺陷，并且找出再现问题的具体步骤）。但是一定不要不负责任的乱报。 +> 遇到缺陷一定要上报，即使他不能稳定复现（当然测试要尽可能的再现缺陷，并且找出再现问题的具体步骤），也不能不负责任地乱报缺陷。 13. 自动化测试终会取代手工测试； -> 我们在选择用哪种方法的测试的时候，坚持“效率最高化，利益最大化”的原则来选择用最适合的方法。我们工作的目的是为了利益，而不是显得高端。 +> 我们在选择用哪种方法测试的时候，坚持“效率最高化，利益最大化”的原则来选择用最适合的方法。我们工作的目的是为了提高利益，而不是显得高端。 > > 自动化测试的初衷是将测试从繁重的、重复的回归工作中解放出来，从而提高测试效率的。并不是为了取代手工测试的，当然以目前的情况来看也取代不了手工测试。另外自动化测试需要在前期投入大量的人力资源和时间，且维护成本很高，故不能盲目推崇测试自动化。