From 9a0ece7d84e3d28b6cc4e32cd5aefb77f3ea21e1 Mon Sep 17 00:00:00 2001 From: xiaojiajia <3073668451@qq.com> Date: Thu, 23 Sep 2021 13:30:55 +0000 Subject: [PATCH] =?UTF-8?q?19990284=E8=B5=B5=E4=BD=B3?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- README.md | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/README.md b/README.md index 2946f99..d03f48a 100644 --- a/README.md +++ b/README.md @@ -120,7 +120,7 @@ **参与者：** 开发 #### 1.2.7 提测 -**描述：** 开发人员完成一个小迭代/小功能，且完成自测(开发编码完成后，一般都会自己检测下)，于是向测试部门发起提测，一般以邮件方式或者任务管理工具的任务流方式向测试部门通知xxx模块/功能可以测试。 +**描述：** 开发人员完成一个小迭代/小功能，且完成自测(开发编码完成后，一般都会自己检测一下)，于是向测试部门发起提测，一般以邮件方式或者任务管理工具的任务流方式向测试部门通知xxx模块/功能可以测试。 **参与者：** 任务责任人（开发）、测试人员 @@ -408,7 +408,7 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准 在软件业较发达的国家，软件测试产业已形成规模，比较发达，软件测试不仅早已成为软件开发的一个重要组成部分，而且在整个软件开发的系统工程中占据着相当大的比重。在微软公司内部，软件测试人员与软件开发人员的比例一般为1.5∶1到2.5∶1左右，即一个开发人员背后，有至少两位测试人员在工作，以保证软件产品的质量。国外优秀的软件开发机构把40%的工作花在软件测试上，软件测试费用占软件开发总费用的30%至50%，对于一些要求高可靠性、高安全性的软件，测试费用甚至相当于整个软件项目开发所有费用的3至5倍。 -从国内软件公司软件测试部门的独立性来看，多数软件企业没有专门的测试技术部门，软件测试程序也不太规范，多数企业也不懂测试，对测试的投入资金过少。大多数是在经过简单地测试之后，就认为是没有问题了，就交于用户了，让用户去“测试”。于是，软件产品在没有经过严格测试的情况下就发布了。对国内消费类软件而言，经常出现一些已经推向市场的产品由于被发现有严重缺陷而导致大量退货的现象。定制的行业软件，常出现一再返工、无限期的修改和维护的现象。 +从国内软件公司软件测试部门的独立性来看，多数软件企业没有专门的测试技术部门，软件测试程序也不太规范，多数企业也不懂测试，对测试的投入资金过少。大多数是在经过简单地测试之后，就认为没有问题了，就交于用户了，让用户去“测试”。于是，软件产品在没有经过严格测试的情况下就发布了。对国内消费类软件而言，经常出现一些已经推向市场的产品由于被发现有严重缺陷而导致大量退货的现象。定制的行业软件，常出现一再返工、无限期的修改和维护的现象。 当前国内软件测试行业主要存在以下问题： 1. 软件规模越来越大，功能越来越复杂，如何进行充分而有效的测试成为难题； @@ -417,7 +417,7 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准 4. 对于实时系统缺乏有效的测试手段； 5. 随着安全问题的日益突出，信息系统的安全性如何进行有效的测试与评估，成为世界性的难题； 6. 测试的自动化程度不高，手工测试过多，自动化测试工具和手工测试人员也缺乏较好的结合； -7. 缺乏软件测试意识、对其重视不够； +7. 缺乏软件测试意识，对其重视不够； 8. 在软件开发基本完成后才进行测试，也缺乏软件测试的统一标准； 9. 高校从师资储备到专业设置再到人才培养的机制薄弱。 @@ -471,10 +471,10 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准 >这种错误的认识非常伤害软件测试人员的积极性。软件中的错误可能来自软件项目中的各个过程，软件测试只能确认软件存在错误，不能保证软件没有错误，因此从根本上讲，软件测试不可能发现全部错误。从软件开发的角度看，软件的高质量不是软件测试人员测出来的，是靠软件生命周期的各个过程中设计出来的。如果出现软件错误，不能简单地归结为某一个人的责任，有些错误可能是技术原因，也可能是混乱的管理所致。因此，应该分析软件项目的各个过程，从过程改进方面寻找产生错误的原因和改进的措施。 5. 软件测试很简单，就是点点点，是个人就能做； ->随着软件工程学的发展和软件项目管理经验的提高，软件测试已经形成了一个独立的技术学科，演变成一个具有巨大市场需求的行业。软件测试技术不断更新和完善，新工具、新流程、新方法都在不断出现，因此，软件测试需要学习很多测试知识，更需要不断的实践经验和学习精神。 +>随着软件工程学的发展和软件项目管理经验的提高，软件测试已经形成了一个独立的技术学科，演变成一个具有巨大市场需求的行业。软件测试技术不断更新和完善，新工具、新流程、新方法都在不断出现。因此，软件测试需要学习很多测试知识，更需要不断的实践经验和学习精神。 6. 软件测试没有前途，只有程序员才是软件高手； ->随着市场对软件质量要求的不断提高，软件测试将变得越来越重要，对测试人员的要求也越来越高。测试人员不仅要懂得如何测试，还要懂得被测软件的业务知识和专业知识.而开发人员往往只需要对自己开发的模块了解比较深，对算法掌握的程度要求高一些，所以，软件测试和开发人员只是工作的侧重点不同，并不存在水平差异的问题。 +>随着市场对软件质量要求的不断提高，软件测试将变得越来越重要，对测试人员的要求也越来越高。测试人员不仅要懂得如何测试，还要懂得被测软件的业务知识和专业知识。而开发人员往往只需要对自己开发的模块了解比较深，对算法掌握的程度要求高一些，所以，软件测试和开发人员只是工作的侧重点不同，并不存在水平差异的问题。 7. 软件测试是测试人员的事情和程序员无关； >开发和测试是相辅相成的过程，需要测试人员、程序员和系统分析师等保持密切的联系，需要交流和协调，以便提高测试效率。另外，对于单元测试，主要应该由程序员完成，必要时测试人员可以帮助设计测试样例。对于测试中发现的软件错误，很多都需要程序员通过修改编码才能修复。程序员通过有目的地分析软件错误的类型、数量，找出产生错误的位置和原因，以避免同样的错误发生，积累编程经验，提高软件开发能力。 @@ -506,7 +506,7 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准 |缺点|覆盖量化难
重复测试效率低
不一致性，可靠性低
人力资源依赖|机械、发现缺陷率低
一次性投入较大
对人员要求高| 14. 规范化软件测试是增加项目成本； ->大家常说“磨刀不误砍柴工”，但是真正用时又拿“能省则省”的理论来操作，殊不知此时省了相当于埋了颗雷。不仅要规范化软件测试，更要规范化整个软件过程,规避个人水平、责任心、经验的差距。 +>大家常说“磨刀不误砍柴工”，但是真正用时又拿“能省则省”的理论来操作，殊不知此时省了相当于埋了颗雷。不仅要规范化软件测试，更要规范化整个软件过程，规避个人水平、责任心、经验的差距。 15. 测出bug越多测试越有效； >测试过程中bug的数量并不能说明测试的有效性，只能说明开发人员的技术水平高低。项目上线后/产品卖出后现场反馈回来的线上bug数量才能反应测试的有效性。 @@ -654,7 +654,7 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准 2. 执行了所有的测试用例，并没有发现故障； 3. 使用特定的测试用例设计方法作为判断测试停止的基础； 4. 给出测试停止的要求； -5. 根据经单位时间内查出故障的数量决定是否停止测试； +5. 根据单位时间内查出故障的数量决定是否停止测试； 6. 软件系统经过了单元、集成、系统测试，分别达到停止标准。通过验收测试，得出验收测试结论； 7. 软件项目暂停以进行调整，测试应随之暂停，并备份暂停点数据。或者软件项目开发生命周期内出现重大估算、进度偏差，需暂停或终止时，测试应随之暂停或终止，并备份数据。ß #### 2.5.2 软件测试各阶段停止标准 @@ -692,7 +692,7 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准 ### 3.1 概述 黑盒测试也称功能测试，通过测试来检测每个功能是否都能正常使用。 -着眼于程序外部结构，不考虑内部逻辑结构，通过测试检验每个功能是否能正常使用。在程序接口进行测试，只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当的接受输入数据而产生正确的输出信息。 +着眼于程序外部结构，不考虑内部逻辑结构，通过测试检验每个功能是否能正常使用。在程序接口进行测试，只检查程序功能是否能按照需求规格说明书的规定正常使用，程序是否能适当的接受输入数据而产生正确的输出信息。 黑盒测试从用户的角度出发，以输入数据与输出数据的对应关系进行测试，数据驱动。 @@ -718,7 +718,7 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准 3. 在输入条件规定了输入值的集合的情况下，可以确立一个有效等价类和一个无效等价类； 4. 在输入条件规定了“必须如何”条件的情况下，可以确立一个有效等价类和一个无效等价类； 5. 在输入条件是一个布尔值的情况下，可以确立一个有效等价类和一个无效等价类； -6. 在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的将情况下，可以确立n个有效等价类和一个无效等价类； +6. 在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可以确立n个有效等价类和一个无效等价类； 7. 在规定了输入数据必须遵守规则的情况下，可以确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）； 8. 在确知已划分的等价类中各元素在程序处理中的方式不同的情况下，则应再将改等价类进一步划分为更小的等价类。 #### 3.2.2 设计测试用例步骤 @@ -793,7 +793,7 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准 边界值分析对布尔变量和逻辑变量没有多大意义。例如，布尔变量的极值是true和false，但是其余3个值不明确。 ### 3.4 决策表 -等价类划分法和边界值分析法只是孤立地考虑各个输人数据的测试效果，没有考虑输入数据的组合及其相互制约关系，而决策表考虑了多种条件的组合情况。决策表又称为判定表，分析多种逻辑条件(if-else、switch-case等)与执行之间的关系。 +等价类划分法和边界值分析法只是孤立地考虑各个输入数据的测试效果，没有考虑输入数据的组合及其相互制约关系，而决策表考虑了多种条件的组合情况。决策表又称为判定表，分析多种逻辑条件(if-else、switch-case等)与执行之间的关系。 决策表由4部分组成： 1. 条件桩：列出了问题的所有条件，通常认为列出的条件次序无关紧要； @@ -891,7 +891,7 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准 等价类划分法和边界值分析法可能不会测试到投入面值50的人民币，然后点击充值100这种异常情况；因此，当程序的输入条件有多个的话，就需要用到因果图法来设计测试用例了。 -因果图利用图解法分析输入的各种组合情况，适合描述多种输入条件的组合、相应产生多不动作的方法。因果图法最终生成的是判定表。 +因果图利用图解法分析输入的各种组合情况，适合描述多种输入条件的组合、相应产生多个动作的方法。因果图法最终生成的是判定表。 #### 3.5.1 基本术语 1. 原因结果图： @@ -910,7 +910,7 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准 ![约束图](https://gitee.com/XiaFuXiangFei/software-testing/raw/main/images/yueshutu.png) * E(互斥)：原因不会同时成立，最多1个成立,可以都不成立。 -* I(包含)：原因中至少一个成立,不能同时为0。 +* 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随便。 @@ -921,7 +921,7 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准 3. 由于语法或环境限制，有些原因与原因之间、原因与结果之间的组合情况不可能出现，在因果图上用一些记号表明这些特殊情况的约束或限制条件，把因果图转换为判定表； 4. 从判定表的每一列产生出测试用例。 -对于逻辑结构复杂软件，先用因果图进行图形分析，再用判定表进行统计，最后设计测试用例。当然，对于比较简单的测试对象，可以忽略因果图，直接使用决策表。 +对于逻辑结构复杂的软件，先用因果图进行图形分析，再用判定表进行统计，最后设计测试用例。当然，对于比较简单的测试对象，可以忽略因果图，直接使用决策表。 #### 3.5.3 应用举例 需求：第一列字符必须是A或者B，第二列为数字，才允许进行文件修改。如果第一列字符不正确，输出提示L，第二列不是数字，输出提示M,采用因果图设计测试用例 @@ -969,7 +969,7 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准 1. 作为输入条件的原因和输出结果之间的因果关系，很难从规格说明书得到； 2. 此方法得到的用例数量规模大。 ### 3.6 场景法 -通过尝尽该描述的业务流程（业务逻辑）,设计用例来遍历场景（路径）,验证系统功能的正确性。 +通过运用场景来描述业务流程（业务逻辑），设计用例来遍历场景（路径），验证系统功能的正确性。 场景法重点是测试流程，因此每个流程用一个用例验证即可，流程测试没问题不代表系统功能没问题，还需要单步进行测试，结合前面的方法。 流程图： -- Gitee