From 16343503021e4de16554bd3d25f0ed3e0f3b03a3 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Young=20=20ren-=E5=A5=95=E9=98=B3?= <1402186302@qq.com> Date: Sun, 3 Oct 2021 09:47:23 +0000 Subject: [PATCH] update README.md. --- README.md | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/README.md b/README.md index 4966f57..2bfa696 100644 --- a/README.md +++ b/README.md @@ -70,7 +70,7 @@ * 《软件支持手册》 #### 1.1.3 软件发展史 -1. 程序设计阶段：个体化生产、专用软件、规模小、功能单一、开发者即使用者。（软件 = 程序）； +1. 程序设计阶段：个体化生产、专用软件、规模小、功能单一、开发者即使用者。（软件 = 程序）； **3. 软件不等同于程序** 2. 程序系统阶段：多用户系统，人机交互技术，实时系统和数据库管理系统； 3. 软件工程阶段：以软件的产品化、系列化、工程化和标准化为特征的软件产业发展起来，软件开发有了可以遵循的软件工程化的设计准则、方法和标准； 4. 多层分布结构，面向服务架构。 @@ -93,7 +93,7 @@ #### 1.2.2 可行性分析 **描述：** 由项目组相关成员去研究需求是否可行，能不能做出来。 -**参与者：** 产品经理、架构师、项目经理、开发人员 +**参与者：** > 架构师、项目经理、开发人员 **1. 可行性分析参与人员没有产品经理** #### 1.2.3 需求分析 **描述：** 需求分析其实是在做需求细化，按照任务说明书中的任务内容和指标具体细化各个点，细化到每个输入框、每个按钮的样式，输入输出等各项值。 @@ -103,7 +103,7 @@ **输出：**《需求规格说明书》 #### 1.2.4 评审 -**描述：** 评审就是做审查，对这个阶段的工作进行审查，看是否偏离或者有遗漏（比如：设计和工厂的各个环节都有相关的审查，审查材料是否合格、设计是否符合规定、按照工人/设计出的材料需求是否足够或者多余等等，这些审查都是评审）；评审一般由相应工作人员来参与。 +**描述：** > 评审就是做审查，对这个阶段的工作进行审查，看是否偏离或者有遗漏（比如：设计和工厂的各个环节都有相关的审查，审查材料是否合格、设计是否符合规定、按照工人/设计出的材料需求是否足够或者多余等等，这些审查都是评审）；评审一般由相应工作人员来参与。 **2.评审和审查不一样,目的不同,参与人员不同** **参与者：** 每个阶段的评审一般都是各职能部门内部审核，也可以申请其他相关人员审核，比如需求评审，一般是产品经理、项目经理、测试人员、开发人员一起评审；系统设计一般是项目经理、开发人员评审；测试策略评审一般是测试组内部评审等等 @@ -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 测试与开发的关系 **瀑布模型** @@ -267,7 +267,7 @@ W 模型是顺序性的、不可逆的，需求的变更和调整，依旧不方 在工作形式上，整个团队平时坐在一起工作，从物理空间上创造了更加便捷面对面的沟通机会。在团队职责上，团队内部具备完成软件交付的角色(能力)，团队所有人对软件的质量负责，开发过程由团队内部把控，业务价值团队内部快速流动，在任何环节都能及时获得反馈。同时，每个角色都更容易从全局视角去思考软件，避免了传统部门墙模式下的视角割裂和协作障碍。 -* 工作的软件高于详尽的文档 +* 工作的软件高于详尽的文档 为客户交付可工作的软件是我们的核心目标，我们应该尽早交付可进行端到端测试的代码，该目标决定了我们不应该花过多精力在面面俱到的文档上，但这不代表我们要抵制任何文档。实践证明，轻量级的文档策略有助于团队高质量交付可工作的软件。 @@ -295,7 +295,7 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准 3. 软件功能超出了产品说明书中指明的范围； 4. 软件难于理解，不易使用，运行速度慢，或者最终用户认为软件使用效果不好。 -#### 1.4.2 产生原因 +#### 1.4.2 产生原因 1. 软件本身复杂性，产生大量不确定因素； 2. 成本、时间限制，导致流程不够完善，文档缺失，缺乏严谨的评审； 3. 人员本身技能水平、责任心、交流沟通不顺畅； @@ -634,7 +634,7 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准 8. 测试执行人：实际由谁来执行测试用例；也有任务分配人的选项，就是测试用例分配给哪个测试员来测试 9. 备注：做一些备注或者测试的说明 10. 合法用户：就是已经注册过的用户 -11. 非法用户：没有注册过；注册过但是用户名／密码不匹配的；本文特指未注册过的用户 +11. 非法用户：没有注册过；注册过， **10.缺少逗号** 但是用户名／密码不匹配的；本文特指未注册过的用户 测试用例维护一般分为以下几种情况： 1. 产品特性没变：漏测或者环境变更，这个时候版本没变，测试用例增加和修改均可； @@ -1032,7 +1032,7 @@ eg. 变量命名 2. 此方法得到的用例数量规模大。 ### 3.6 场景法 通过尝尽该描述的业务流程（业务逻辑），设计用例来遍历场景（路径），验证系统功能的正确性。 -场景法重点是测试流程，因此每个流程用一个用例验证即可，流程测试没问题不代表系统功能没问题，还需要单步进行测试，结合前面的方法。 +场景法的 **9.没有的** 重点是测试流程，因此每个流程用一个用例验证即可，流程测试没问题不代表系统功能没问题，还需要单步进行测试，结合前面的方法。 流程图： * 矩形：步骤 @@ -1141,7 +1141,7 @@ eg. 变量命名 ## 第4章 白盒测试 ### 4.1 概述 -白盒测试是把测试对象看做打开的盒子，允许测试人员利用程序内部的逻辑结构及有关信息设计或选择测试用例，通过在不同点检查程序状态确定实际状态是否与预期的状态一致。白盒测试测试软件产品的内部结构和处理过程，而不测试软件产品的功能，用于纠正软件系统在描述、表示和规格上的错误，是进一步测试的前提。 +白盒测试是把测试对象看作 **8.做应为作** 打开的盒子，允许测试人员利用程序内部的逻辑结构及有关信息设计或选择测试用例，通过在不同点检查程序状态确定实际状态是否与预期的状态一致。白盒测试测试软件产品的内部结构和处理过程，而不测试软件产品的功能，用于纠正软件系统在描述、表示和规格上的错误，是进一步测试的前提。 白盒测试分为静态测试和动态测试。 @@ -1281,7 +1281,7 @@ MC/DC具有如下优点: 4. 具有更高的目标码覆盖率。 #### 4.4.6 条件组合覆盖 -条件组合覆盖(Multiple Condtion Coverage,MCC)的基本思想是设计测试用例使得判断中每个条件的所有可能至少出现1次，并且每个判断本身的判定结果也至少出现1次，与条件覆盖的差别是条件组合厦盖不是简单地要求每个条件都出现“真”与“假”两种结果，而是要求这些结果的所有可能组合都至少出现1次。 +条件组合覆盖(Multiple Condtion Coverage,MCC)的基本思想是设计测试用例使得判断中每个条件的所有可能至少出现1次，并且每个判断本身的判定结果也至少出现1次，与条件覆盖的差别是条件组合覆盖 **7.覆盖不是厦盖**不是简单地要求每个条件都出现“真”与“假”两种结果，而是要求这些结果的所有可能组合都至少出现1次。 条件组合覆盖是一种相当强的覆盖准则，可以有效地检查各种可能的条件取值组合是否正确。它不但可覆盖所有条件可能取值的组合，还可覆盖所有判断的可取分支，但仍可能会遭漏掉有的路径，测试还不完全。 @@ -1481,7 +1481,7 @@ T：性能测试所用的时间。 #### 5.2.2 压力测试 压力测试(Stress Test)也称强度测试，是在强负载(大数据量、大量并发用户等)下的测试，通过查看应用系统在峰值使用情况下的状态发现系统的某项功能隐思、系统是否具有良好的容错能力和可恢复能力。压力测试涉及时间因素，用来测试那些负载不定的，或交互式的，实时的以及过程控制等程序。压力测试分为高负载下的长时间(如24小时以上)的稳定性压力测试和极限负载情况下导致系统崩溃的破坏性压力测试。 -压力测试也被看做是负载测试的一种特殊情况，即高负载下的负载测试，或者说压力测试采用负载测试技术。 +压力测试也被看作 **6.看做应为看作** 是负载测试的一种特殊情况，即高负载下的负载测试，或者说压力测试采用负载测试技术。 #### 5.2.3 可靠性测试 软件可靠性是软件质量的一个重要标志。IEEE将软件可靠性定义为系统在特定的环境下，在给定的时间内无故障地运行的概率，软件可靠性涉及软件的性能、功能性、可用性、可服务性、可安装性、可维护性等多方面特性，是对软件在设计、生产以及在它所预定环境中具有所需功能的置信度的一个度量。 @@ -1897,7 +1897,7 @@ eg. 登录功能描述 测试的进度安排需要结合项目的开发计划、产品的整体计划进行考虑，还要考虑测试本身的各项活动进行安排。把测试用例的设计、测试环境的搭建、测试报告的编写等活动列入进度安排表。 5. 估计计划风险 -般可能碰到的风险是项目计划变更、测试资源不能及时到位等问题。制定测试计划时应根据项目的实际情况进行评估，并制定出合理、有效的应对策略，对于项目计划的变更，可以考虑建立更加流畅的沟通渠道，让测试人员能及时了解到变更的情况，以及变更的影响，从而可以作出相应的改变。 +般可能碰到的风险是项目计划变更、测试资源不能及时到位等问题。制定测试计划时应根据项目的实际情况进行评估，并制定出合理、有效的应对策略，对于项目计划的变更，可以考虑建立更加流畅的沟通渠道，让测试人员能及时了解到变更的情况，以及变更的影响，从而可以作做出 **5.作出应为做出** 相应的改变。 #### 6.3.3 测试计划的5W1H 1. What - 对象 @@ -2824,7 +2824,7 @@ IEEE给出软件测试文档分为测试计划，测试设计规格说明、测 测试计划文档帮助测试人员分析测试可以做什么，不能做什么。了解测试任务的风险有助于对潜伏的可能出现的问题事先作好思想上和物质上的准备。 4. 生成测试用例 - 测试用例的好坏决定着测试工作的效率，选择合适的测试用例是做好测试工作的关健，在测试文件编制过程中，按规定的要求精心设计测试用例有重要的意义。 + 测试用例的好坏决定着测试工作的效率，选择合适的测试用例是做好测试工作的关键 **4.关健应为关键** ，在测试文件编制过程中，按规定的要求精心设计测试用例有重要的意义。 5. 评价测试结果 测试文件包括测试用例，即若干测试数据及对应的预期测试结果。完成测试后，将测试结果与预期的结果进行比较，便可对已进行的测试提出评价意见。 -- Gitee