From 0343dd8df86bdd594b2a6637fa7239a6be8cde58 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E6=99=8F=E7=BB=A7=E5=B7=9D?= <9730715+yan-jichuan@user.noreply.gitee.com> Date: Tue, 28 Sep 2021 10:10:25 +0000 Subject: [PATCH 1/3] 1 --- README.md | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/README.md b/README.md index 4340c9a..9cc1a6f 100644 --- a/README.md +++ b/README.md @@ -31,7 +31,7 @@ **软件 ≠ 程序（代码）** 软件包含如下内容： 1. 运行时，能够提供所要求功能和性能的指令或计算机程序集合。 -2. 程序能够处理信息的数据结构。 +2. 能够处理信息的数据结构。 3. 用于描述程序功能需求、程序如何操作和如何使用的文档。 #### 1.1.2 文档 @@ -70,7 +70,7 @@ * 《软件支持手册》 #### 1.1.3 软件发展史 -1. 程序设计阶段：个体化生产、专用软件、规模小、功能单一、开发者即使用者。（软件 = 程序）； +1. 程序设计阶段：个体化生产、专用软件、规模小、功能单一、开发者即使用者。（软件 = 程序+代码+数据）； 2. 程序系统阶段：多用户系统，人机交互技术，实时系统和数据库管理系统； 3. 软件工程阶段：以软件的产品化、系列化、工程化和标准化为特征的软件产业发展起来，软件开发有了可以遵循的软件工程化的设计准则、方法和标准； 4. 多层分布结构，面向服务架构。 @@ -517,7 +517,7 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准 ### 1.7 知识点总结 1. 软件定义与发展 2. 软件测试定义与发展 -3. 软件生命周期 +3. 软件生命周期 4. 软件测试模型 5. 缺陷定义、来源、产生原因和记录方法 6. 软件测试行业 @@ -2450,10 +2450,10 @@ postman.setGlobalVariable("username", "tester"); 3. 质量管理：包括bug、测试用例、测试任务、测试结果等功能。 4. 文档管理：包括产品文档库、项目文档库、自定义文档库等功能。 5. 事务管理：包括todo管理，我的任务、我的Bug、我的需求、我的项目等个人事务管理功能。 -6. 组织管理：包括部门、用户、分组、权限等功能。 -7. 统计功能：丰富的统计表。 -8. 搜索功能：强大的搜索，帮助您找到相应的数据。 -9. 扩展机制，几乎可以对禅道的任何地方进行扩展。 +6. 组织管理：包括部门、用户、分组、权限等功能。 +7. 统计功能：丰富的统计表。 +8. 搜索功能：强大的搜索，帮助您找到相应的数据。 +9. 扩展机制，几乎可以对禅道的任何地方进行扩展。 10. api机制，所见皆API，方便与其他系统集成。 11. #### 7.8.2 环境搭建 @@ -2526,7 +2526,7 @@ postman.setGlobalVariable("username", "tester"); #### 7.8.11 管理任务 对于项目团队的成员来讲，他要做的事情就是更新任务的进度和状态。 -1. 任务的列表： 在任务的列表页面，可以看到系统中所有的任务列表，可以通过各种标签方便的进行筛选。点击某一个任务的名称进入详情页面。 +1. 任务的列表： 在任务的列表页面，可以看到系统中所有的任务列表，可以通过各种标签方便地进行筛选。点击某一个任务的名称进入详情页面。 2. 任务的详情页面： 在任务的详情页面可以看到任务的详细信息，包括历次的修改记录等信息。同时也给出了各种操作的按钮。 3. 开始任务： 开始某一个任务的时候，可以设置已经消耗的时间和预计剩余的时间。单位都是工时。 4. 更新任务工时： 点击操作栏里的“工时”按钮，通过更新工时消耗，来管理任务执行进度。 @@ -2542,14 +2542,14 @@ postman.setGlobalVariable("username", "tester"); #### 7.8.13 缺陷管理 Bug处理流程： -1. Bug的基本处理流程：测试提交bug => 开发确认bug => 开发解决bug => 测试验证bug => 测试关闭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】，可以自动填写步骤重现，适当补充截图说明。 +2. 单独的bug，直接新建，填写描述。 +3. 执行阶段bug，勾选测试步骤，点击【转bug】，可以自动填写步骤重现，适当补充截图说明。 ### 7.9 知识点总结 1. 自动化测试对比手工测试的优缺点 -- Gitee From 201c2bd914c8ecdf9792112c43338e232b99ee22 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E6=99=8F=E7=BB=A7=E5=B7=9D?= <9730715+yan-jichuan@user.noreply.gitee.com> Date: Tue, 28 Sep 2021 10:43:09 +0000 Subject: [PATCH 2/3] 2 --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 9cc1a6f..4d4888f 100644 --- a/README.md +++ b/README.md @@ -1,4 +1,4 @@ -# 软件测试 +# 软件测试1 ## 写在最前面 ### 1 课程目标 -- Gitee From 31a845187eeb2382b5b46a7597bb6d9b5ad99b17 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E6=99=8F=E7=BB=A7=E5=B7=9D?= <9730715+yan-jichuan@user.noreply.gitee.com> Date: Sun, 3 Oct 2021 10:30:40 +0000 Subject: [PATCH 3/3] =?UTF-8?q?=E4=BF=AE=E6=94=B9=E5=86=85=E5=AE=B9?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- README.md | 31 +++++++++++++++---------------- 1 file changed, 15 insertions(+), 16 deletions(-) diff --git a/README.md b/README.md index 4d4888f..eaeb170 100644 --- a/README.md +++ b/README.md @@ -2,7 +2,7 @@ ## 写在最前面 ### 1 课程目标 -* 掌握基础的软件测试理论、测试方法和策略 +* 掌握基础的软件测试理论、测试方法和策略。 * 掌握常用工具的使用方法 * 根据需求和设计文档，独立编写测试计划、测试方案、测试用例以及测试报告 ### 2 主要内容 @@ -876,12 +876,11 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准 使用判定表设计测试用例的条件如下： 1. 规格说明以判定表形式给出，或很容易转换成判定表； 2. 条件的排列顺序不会也不影响执行哪些操作； -3. 规则的排列顺序不会也不影响执行哪些操作； -4. 每当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则； -5. 如果某一规则得到满足要执行多个操作，这些操作的执行顺序无关紧要。 +3. 每当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则； +4. 如果某一规则得到满足要执行多个操作，这些操作的执行顺序无关紧要。 -这5个必要条件使得操作的执行完全依赖于条件的组合。对于不满足条件的判定表，可增加其他的测试用例。 +这4个必要条件使得操作的执行完全依赖于条件的组合。对于不满足条件的判定表，可增加其他的测试用例。 ### 3.5 因果图 前面我们介绍的等价类划分法和边界值分析法都没有考虑到输入情况的组合。这样虽然各种输入条件可能出错的情况已经看到了，但是多个输入情况组合起来可能出错的情况却被忽视了。 @@ -894,10 +893,10 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准 因果图利用图解法分析输入的各种组合情况，适合描述多种输入条件的组合、相应产生多个动作的方法。因果图法最终生成的是判定表。 #### 3.5.1 基本术语 -1. 原因结果图： +1. 原因——结果图： 原因——结果图使用了简单的逻辑符号，以直线连接左右结点，左结点表示输入状态(原因)，右结点表示输出状态(结果)。 -![原因 - 结果图](https://gitee.com/XiaFuXiangFei/software-testing/raw/main/images/yinguotu.png) +![原因——结果图](https://gitee.com/XiaFuXiangFei/software-testing/raw/main/images/yinguotu.png) * “恒等”：若原因出现，则结果出现；若原因不出现，则结果不出现。 * “非”：若原因出现，则结果不出现；若原因不出现，则结果出现。 @@ -997,10 +996,10 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准 | 用例ID | 场景/条件 | 卡片 | 密码 | ATM内金额 | 账户余额 | 输入金额 | 预期结果 | | :----: | ------------------------------- | ------ | ------ | --------: | -------: | -------: | ------------------------ | -| TC1 | 场景1：成功提款 | 合法卡 | 123456 | 2000.00 | 5000.00 | 100 | 成功提款，账户余额400.00 | +| TC1 | 场景1：成功提款 | 合法卡 | 123456 | 2000.00 | 5000.00 | 100 | 成功提款，账户余额4900.00 | | TC2 | 场景2：非法的卡 | 非法卡 | n/a | 2000.00 | 5000.00 | n/a | 提示错误，退卡 | | TC3 | 场景3：点取消 | 合法卡 | n/a | 2000.00 | 5000.00 | n/a | 退卡 | -| TC4 | 场景4：密码错误（还有机会） | 合法卡 | 654321 | 2000.00 | 5000.00 | n/a | 提示错误，重新输入 | +| TC4 | 场景4：密码错误（还有机会） | 合法卡 | 654321 | 2000.00 | 5000.00 | n/a | 提示错误，重新输入，提示剩余输入次数 | | TC5 | 场景5：密码错误（超过限制次数） | 合法卡 | 234516 | 2000.00 | 5000.00 | n/a | 提示错误，退卡/吞卡 | | TC6 | 场景6：ATM无现金 | 合法卡 | 123456 | 0.00 | 5000.00 | n/a | 提款选项不可用，用例结束 | | TC7 | 场景7：金额错误 | 合法卡 | 123456 | 2000.00 | 5000.00 | 20 | 提示错误，重新输入 | @@ -1018,13 +1017,13 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准 1. 有关软件设计方法和实现技术； 2. 有关前期测试阶段结果的知识； 3. 测试类似或相关系统的经验，了解以前这些系统曾在哪些地方出现缺陷； -4. 典型的产生错误的知识，如被零除错误。 +4. 典型的产生错误的知识（如被零除错误）。 #### 3.7.2 优点和缺点 **优点：** 1. 不用设计等价类的测试用例，将多个等价类的测试合成一个随机测试，可以以较少代码实现测试代码的编写； 2. 当等价类设计不确切或不完全时，测试会产生遗漏，而使用错误推测法则是按照概率进行等价类覆盖。不论存在多少个等价类，只要随机数据个数足够，就能保证各个等价类被覆盖的概率足够高，能够有效弥补等价类分法设计不充分的缺陷； -3. 采用错误推测法进行测试，每次执行测试时，测试的样本数据可能都不相同，执行次数愈多，错误暴露的概率愈大。 +3. 采用错误推测法进行测试，每次执行测试时，测试的样本数据可能都不相同，执行次数越多，错误暴露的概率越大。 **缺点：** 1. 错误推测法中的随机数据很难覆盖到边界值，无法保证测试的充分性； @@ -1045,7 +1044,7 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准 3. 常见的异常测试情况 - 输入框不输入任何内容（为空）或者输入空格的情况 - 输入框输入非法字符 - - 用户注销后，是否仍然能操作；再登录是否能成功 + - 用户注销后，是否仍然能操作，再登录是否能成功 - 断电重连后是否能继续使用且信息未丢失 4. 功能相关的常见异常问题 - C++软件的内存泄漏、内存分配 @@ -1061,9 +1060,9 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准 5. 如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法。 对于功能性测试技术，可以根据如下条件进行选择： -1. 如果变量是独立的，则可以用定义域测试和等价类测试； +1. 如果变量是独立的，可以用定义域测试和等价类测试； 2. 如果变量不是独立的，可采用决策表测试； -3. 如果为单缺陷假设，则可采用边界值分析和健壮性测试； +3. 如果为单缺陷假设，可采用边界值分析和健壮性测试； 4. 如果为多缺陷假设，可采用最坏情况测试、健壮最坏情况测试和决策表测试； 5. 如果程序包含大量例外处理，可采用健壮性测试和决策表测试； 6. 如果变量引用的是逻辑量，可采用等价类测试用例和决策表测试。 @@ -1126,14 +1125,14 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准 语句覆盖测试方法仅仪针对程序逻辑中的显式语句，无法测试隐藏条件，例子中的第一个逻辑运算符And误写成or，测试用例a=2，b=2，c=4仍能达到语句覆盖的要求，但是并未发现程序中的误写错误。 -| 测试用例ID | 测试用例 | a>0 and b>0 | a>1 or c>1 | 执行路径 | +| 测试用例ID | 测试用例 | a>0 or b>0 | a>1 or c>1 | 执行路径 | | :--------: | ------------- | :---------: | :--------: | --------- | | TC1 | a=2, b=2, c=4 | T | T | Ⅰ→Ⅱ→Ⅲ→Ⅳ→Ⅴ | #### 4.4.2 判定覆盖 判定覆盖(Decision Coverage，DC)，又称为分支覆盖或所有边覆盖，测试控制结构中布示表达式分别为真和假(例如if语句和while语句)。布尔型表达式被认为是一个整你.取值为true或 false，而不考虑内部是否包含“逻辑与”或者“逻排或”等操作符。 -判定覆盖的基本思想，是指设计的测试用例使程序中每个判定至少分别取“真”分支和取“假”分支各一次，即判断真很值均被满足。 +判定覆盖的基本思想，是指设计的测试用例使程序中每个判定至少分别取“真”分支和取“假”分支各一次，即判断真假值均被满足。 | 测试用例ID | 测试用例 | a>0 and b>0 | a>1 or c>1 | 执行路径 | | :--------: | --------------- | :---------: | :--------: | ------------- | -- Gitee