diff --git a/README.md b/README.md index 4340c9a931d36d33f3af17acf0efc0a5cb8c4e2e..2dd31d028130df6c7e08206f327f0ade71bb4903 100644 --- a/README.md +++ b/README.md @@ -108,7 +108,7 @@ **参与者：** 每个阶段的评审一般都是各职能部门内部审核，也可以申请其他相关人员审核，比如需求评审，一般是产品经理、项目经理、测试人员、开发人员一起评审；系统设计一般是项目经理、开发人员评审；测试策略评审一般是测试组内部评审等等 #### 1.2.5 设计 -**描述：** 架构师根据需求确定产品或者项目的场景、特点，选择合适的框架，技术使项目实现最优化。在此基础上将系统进行概要设计，包括系统总体数据结构、数据库结构、模块结构以及它们之间的关系等。开发人员根据概要设计对具体模块进行详细设计，包括接口、参数等。此处设计会形成概要设计文档和详细设计文档。 +**描述：** 架构师根据需求确定产品或者项目的场景、特点，选择合适的框架，技术使项目实现设计最优化。在此基础上将系统进行概要设计，包括系统总体数据结构、数据库结构、模块结构以及它们之间的关系等。开发人员根据概要设计对具体模块进行详细设计，包括接口、参数等。此处设计会形成概要设计文档和详细设计文档。 **参与者：** 项目经理、架构师、开发人员、测试人员 @@ -243,7 +243,7 @@ W 模型是顺序性的、不可逆的，需求的变更和调整，依旧不方 强调以人为核心，程序员团队和业务专家之间的紧密联系，频繁交付新的软件版本，紧凑的自我组织型团队，更注重软件开发中人的作用。 -在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。 +在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视化、可集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。 **《联盟敏捷宣言》** 1. 最重要的是通过尽早和不断交付有价值的软件满足客户需要； @@ -321,7 +321,7 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准 | 接口 | 与其他模块参数不匹配 | #### 1.4.5 缺陷级别 -**严重性：** 表示软件缺陷的恶劣程度，当用户碰到该缺陷时影响的可能性和程度。 +**严重性：** 表示软件缺陷的恶劣程度，当用户碰到该缺陷时影响的可能性和程度大小。 **优先级：** 表示修复缺陷的重要程度和紧迫程度。 @@ -345,7 +345,7 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准 严重性和优先级对于审查缺陷报告并决定哪些软件缺陷应该修复，以何种顺序修复的人员极为重要。如果一个程序员受命修复10个缺陷，他就应该先从严重性为1 、优先级为4这样的缺陷着手，而不是优先修复简单的，由简到难。 -综合使用重要性等级和严重性双标准的优先顺序: +综合使用重要性等级和严重性等级双标准的优先顺序: | | S1. 致命错误 | S2. 严重缺陷 | S3. 主要错误 | S4. 次要错误 | S5. 轻微缺陷 | | :----: | ------------------- | ------------------- | -------------------- | ------------------- | ------------------- | @@ -396,13 +396,13 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准 6. bug备注：备注，以便记录一些额外信息。 #### 1.4.8 缺陷预防 -**差错：**人在理解和解决问题的思维和行为过程中出现的问题，沟通不当，理解错误；（产生根源） +**差错：**人在解决问题的思维和行为过程中出现的问题，沟通不当，理解错误；（产生根源） **错误：**软件内部问题，设计错误、编码错误；（内部原因） **失效：**软件系统运行时偏离了用户需求。（外部表现） ### 1.5 软件测试行业 #### 1.5.1 行业现状 -软件系统越来越复杂，一个软件不能够由单独的软件工程师单独编写，而是由团队进行配合，每个人可能只负责一个模块，对于全局没有过多的了解，这时如果运行软件就会容易产生很多的错误。在行业内将这些错误叫做BUG。并且每一个软件工程师都会有思维的死角，自己不容易发现自己编写出来的错误。所以这个时候就需要专门的软件测试工程师用专业的测试方式来检查软件。检查该软件是否符合客户要求的产品设计，是否能够符合大多数用户的使用习惯，如果发现异常状态及时进行处理。软件市场虽然远远没有达到饱和但是各种各样功能的软件也层出不穷竞争激烈，对软件开发的质量要求也是日益增高。 +软件系统越来越复杂，一个软件不能够由软件工程师单独编写，而是由团队进行配合，每个人可能只负责一个模块，对于全局没有过多的了解，这时运行软件就会容易产生很多的错误。在行业内将这些错误叫做BUG。并且每一个软件工程师都会有思维的死角，自己不容易发现自己编写出来的错误。所以这个时候就需要专门的软件测试工程师用专业的测试方式来检查软件。检查该软件是否符合客户要求的产品设计，是否能够符合大多数用户的使用习惯，如果发现异常状态及时进行处理。软件市场虽然远远没有达到饱和但是各种各样功能的软件也层出不穷竞争激烈，对软件开发的质量要求也是日益增高。 我国软件测试行业起步较晚，发展较慢，直到21世纪初期，我国才逐步开始重视软件测试行业。但近年来，软件行业的快速发展为软件测试行业的发展提供了良好的基础，随着我国软件测试行业的发展，行业内企业向规模化发展将获得规模效应，可以有效降低企业的单位成本;而软件测试技术的不断发展，也将淘汰那些技术实力较弱的企业，促使行业内企业向专业化方向发展。 @@ -549,7 +549,7 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准 ### 2.2 测试的目的和原则 #### 2.2.1 测试的目的 -1. 测试不仅仅是找出错误。通过分析错误产生的原因和错误的发展趋势，可以帮助项目管理者发现当前软件开发过程中的缺陷，以便即时改进； +1. 测试不仅仅是找出错误。通过分析错误产生的原因和错误的发展趋势，可以帮助项目管理者发现当前软件开发过程中的缺陷，以便及时改进； 2. 检测产品是否符合用户要求； 3. 没有发现错误的测试也是有价值的，完整的测试是评定软件质量的一种方法； 4. 提升用户体验。 @@ -561,8 +561,8 @@ IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准 4. 应当对每一个测试结果做全面的检查； 5. 测试现场保护和资料归档； 6. 程序员应避免检查自己的程序； -7. 充分注意测试中的集群现象； -8. 用例要定期评审，适时补充修改用例。 +7. 尤其注意测试中的集群现象； +8. 用例要定期评审，适时修改补充用例。 ### 2.3 测试分类 #### 2.3.1 按照测试阶段划分