软件质量

说实话，这些概念性的文字在实际工作中并不能用到，工作了1年以上的同学也不需要了解这些东西，那么这些概念性文字有什么作用呢？ 1.可以形成文档，比如新人入职、离职交接等。 2.培训，无论是公司内部、还是专职讲师，都需要了解这些概念的。 3.面试，笔试等。无论面试别人，还是被面试。 目录 1.软件测试的定义 2.软件测试的目的 3.软件测试的对象 4.软件质量 功能性 可靠性 易用性 效率 维护性 可移植性 5.初级测试工程师的主要工作 6.总结 1.软件测试的定义 什么是软件测试，软件测试的定义是什么。 软件测试，是通过手工、自动化等手段，来检测软件产品中的错误和缺陷的过程。 对于刚开始进入测试行业的同学们，基本上都是执行测试用例、发现Bug、提交Bug。 2.软件测试的目的 根据软件测试的定义，可以知道软件测试的目的： 寻找缺陷，寻找Bug。 工作中发现缺陷并提交，然后跟进Bug，直到被修改。 1) 以最少的人力、物力和时间，找出软件中潜在的各种错误和缺陷。 2) 通过修复各种错误和缺陷，确保软件质量。避免软件发布后，由于错误和缺陷而造成的影响。 3) 测试过程中的一些信息，要定期进行总结复盘，防止在后续项目开发和测试，重犯错误。 4) 采用更加科学高效的测试管理方法，提高软件测试效率和软件质量。 3.软件测试的对象 软件测试的对象不止是软件。 包括程序、数据和文档等等都是测试对象

第十二章：用户体验 用户对产品的第一印象是非常重要的，所以要尽量让用户在第一次使用时，少花时间在对他没有价值的部分，并且尽量花最少的时间让用户了解软件的基本功能并学会使用。需要站在用户的角度考虑问题，要为用户考虑，思考用户的角度上使用软件他会希望这个软件的使用以及各功能之间连接，界面划分是怎样的。如果用户长期使用，这个软件时越来越让用户觉得便利还是麻烦。要一直记住用户的选择。不能让用户犯简单的错误。要注重用户体验和质量不能是你觉着这样对用户好，但是用户觉着很麻烦甚至是厌恶。所以一款软件要能真正的解决用户当前的困难给用户带来便利，使用界面要符合用户的习惯，如果用户使用有错误需要能够撤销刚才的操作或者是可以退出软件，在软件中对一个事物的描述要一致且标准，并且软件能够适合各种类型的用户而不是局限的适合一小批用户，需要设置一些帮助文档解决用户使用过程中常见的错误。 第十三章：软件测试 Bug 即软件的缺陷，可以分为三种：症状、程序错误、根本原因。找出 bug 则需使用测试，按测试设计的方法分类分为黑箱测试（即行为测试设计）和白箱（玻璃箱）测试（即使用软件的内部结构和知识来选择测试数据和具体的测试方法）；按测试目的分为功能测试和非功能测试（即测试软件的服务质量）；测试方法分为单元测试、代码覆盖率测试、构建验证测试、验收测试、“探索式”测试、回归测试、场景 / 集成 / 系统测试、伙伴测试

　　用户体验： 用户对产品的第一印象是非常重要的，所以要尽量让用户在第一次使用时，少花时间在对他没有价值的部分，并且尽量花最少的时间让用户了解软件的基本功能并学会使用。需要站在用户的角度考虑问题，要为用户考虑，思考用户的角度上使用软件他会希望这个软件的使用以及各功能之间连接，界面划分是怎样的。如果用户长期使用，这个软件时越来越让用户觉得便利还是麻烦。要一直记住用户的选择。不能让用户犯简单的错误。要注重用户体验和质量不能是你觉着这样对用户好，但是用户觉着很麻烦甚至是厌恶。所以一款软件要能真正的解决用户当前的困难给用户带来便利，使用界面要符合用户的习惯，如果用户使用有错误需要能够撤销刚才的操作或者是可以退出软件，在软件中对一个事物的描述要一致且标准，并且软件能够适合各种类型的用户而不是局限的适合一小批用户，需要设置一些帮助文档解决用户使用过程中常见的错误。 　　软件测试 Bug即软件的缺陷，可以分为三种： 　　症状、程序错误、根本原因。 　　找出bug则需使用测试，按测试设计的方法分类分为两种： 　　黑箱测试（即行为测试设计）和白箱（玻璃箱）测试（即使用软件的内部结构和知识来选择测试数据和具体的测试方法）； 　　按测试目的分为两种： 　　功能测试和非功能测试（即测试软件的服务质量）； 　　测试方法分为： 　　单元测试、代码覆盖率测试、构建验证测试、验收测试、“探索式”测试、回归测试

第十三章：软件测试 　　 Bug即软件的缺陷，可以分为三种：症状、程序错误、根本原因。 　　找出bug则需使用测试，按测试设计的方法分类分为黑箱测试（即行为测试设计）和白箱（玻璃箱）测试（即使用软件的内部结构和知识来选择测试数据和具体的测试方法）； 　　按测试目的分为功能测试和非功能测试（即测试软件的服务质量）； 　　测试方法分为单元测试、代码覆盖率测试、构建验证测试、验收测试、“探索式”测试、回归测试、场景/集成/系统测试、伙伴测试、效能测试、压力测试、内部/外部测试、易用性测试、“小强”大扫荡。其中使用最多的是单元测试，既每次做完软件，并进行过自我复审，然后进行单元测试。 第十四章：质量保障 　　软件质量=程序质量+软件工程质量 　　软件工程的质量体现在：软件开发过程的可见性、风险控制、软件内部模块，项目中间阶段的交付质量，项目管理工具的因素、开发成本的控制、内部质量指标的完成。软件的质量不能仅仅依靠测试人员去保证，编程人员在进行编程时要尽力保证自己代码的质量以及各模块连接之间的稳定性。 第十五章：稳定和发布阶段 　　在软件发布后，软件可能会发有各种各样的bug，所以软件团队中就需要以各个角色为基础成立一个会诊小组，可以对bug进行修复，也可以不修复或者推迟修复。 第十六章：IT行业的创新 　　每个人都可以创新

0.软件缺陷的产生 软件缺陷 - Software Defect - Bug； 缺陷 的存在会导致软件产品在 某种程度上不能满足用户的需要 。 IEEE729-1983 对缺陷的标准定义： 从 产品内部 看，缺陷是软件产品开发或维护过程中 存在的错误、毛病等各种问题 ； 从 产品外部 看，缺陷是系统所需要实现的 某种功能的失效或违背 。 在软件的开发测试过程中项目组会特别关注软件缺陷的状况，这是因为一方面软件缺陷状况是项目质量和状态的重要指示数据，另一方面越到软件生命周期的后期修复软件缺陷的成本越高。 1.常见的缺陷 功能没有实现或与需求规格说明不一致； 界面、消息、提示、帮助不够准确或误导用户； 屏幕显示、打印结果不正确； 软件无故退出或没有反应; 边界条件未做处理，输入错误数据没有提示和说明； 运行速度慢或占用资源过多； 与常用的交互软件不兼容； 有时把尚未完成的小 功能 也归属于 软件缺陷 2.产生原因 在软件开发的过程中，软件缺陷的产生是不可避免的， ” 零缺陷 ” 是软件产品很难达到 一个 状态。 导致 软件缺陷产生的原因也是多种多样的，软件工程过程中的人、过程、工具都有可能导致产生软件缺陷，过程中的每一个环节都有可能产生缺陷，概括来说这些原因可以归结为四大类。 软件本身的复杂性 和抽象性： 在产品真正完成之前，每个人对软件的理解都不完全相同

0.认识需求 1. 业务需求：组织或客户的高层次目标、 描述为什么要开发系统 (Why)，希望达到什么样的目标、 一般 2-5 条，记录在 《 软件愿景和范围 》 文档中。 2. 用户需求： 从 用户角度 ，描述 用户使用产品必须要完成什么任务； 用户能使用系统来做什么(What)；通过用户访谈、调查、对用户使用场景进行整理等方法获取。 3. 功能需求： 描述 开发 人员 在产品中实现的软件功能， 描述开发 人员如何设计具体的解决方案来实现这些 需求 ( how )， 数量 往往比用户需求高一个数量级， 属于 《 软件需求规格说明书 》 的一部分。 <0>软件需求规格说明书 其包括： 功能需求： 1. 用户需求 2. 系统需求： 用于描述包含多个子系统的产品 ( 即系统 ) 的顶级需求，它是从系统实现的角度描述的需求，有时还需要考虑相关的硬件、环境方面的需求。 3. 业务规则： 业务规划本身并非软件需求，因为它们不属于任何特定软件系统的范围。然而，业务规则常常会限制谁能够执行某些特定用例，或者规定系统为符合相关规则必须实现某些特定功能。它包括企业方针、政府条例、工业标准、会计准则和计算方法等。有时，功能中特定的质量属性（通过功能实现）也源于业务规则。所以，对某些功能需求进行追溯时，会发现其来源正是一条特定的业务规则。 非功能需求： 1. 质量属性：产品 必须具备的属性或品质

1 多个开源产品可以拿来分析其架构，如eclipse，万维网， 2 需求并不能决定架构，架构是一种高层设计，最重要的是，架构的设计受到很多方面的影响，这些带来影响的因素（技术，商业，社会，涉众的需求，开发组织的结构或者本质—例如开发组织的商业目标和技术特点等，设计师的经验水平，等）也是我们进行架构设计时需要考虑的，同时也可以帮助我们很好的分析一个（商业产品的）架构。 要注意到，完成一个架构的设计会带给前面所提到的因素一定的反馈，得到一定的收获。 3 架构商业周期Architecture Business Cycle：软件架构是技术，商业和社会等诸多因素作用的结果，而软件架构的存在又反过来会影响技术，商业和社会环境，从而影响到未来的架构，这种互相影响的周期—从环境到架构又返回到环境—就叫做架构商业周期 4 架构活动： 1）为系统构建一个商业案例（商业目标） 2）理解系统需求（最重要的是涉众的需求，可以使用面向对象的方法-即用例分析来获取，也可以通过捕获质量属性需求，再者，参考相似系统也可以获得需求） 3）创建或选择架构 4）将架构编成文档，并与有关各方进行交流（编档要面向不同的涉众给予不同文档，便于交流） 5）对此架构进行分析和评价（ATAM或CBAM，注意一点是评估过程不能脱离实际环境） 6）根据此架构实现系统 7）保证系统实现符合架构的要求 5

软件体系结构2 软件体系结构概述 软件体系结构包括构件(Component)、连接件(Connector)和约束(Constraint)或配置(Configuration)三大要素。 软件需求与架构 需求是指明必须实现什么规格说明。它描述了系统的行为、特性或属性，是在开发过程中对系统的约束。 与客户打交道的主要目的是：一是获取需求，而是签订合同 软件需求流程 需求的分类：业务需求，用户需求，系统需求，功能需求，非功能需求，设计约束 质量属性： 开发期质量:可扩展性，可复用性，可维护性等； 运行期质量：正确性，健壮性，性能，可靠性，容错性，易用性，安全性，可移植性，兼容性。 需求工程结构图 开发者对待需求工程的态度可分"被动型"、"主动型"和"领先型"三种。 获取需求 需求从哪里来:人，物，系统 获取需求的方法：面谈，问卷，会议… 面谈问题基本上可以分为两种类型:开放式问题和封闭式问题 面谈结构：金子塔型，漏斗型，菱形 用例描述了 用户 和 系统 之间的交互 用例模型描述全部的系统功能性行为 二维需求矩阵 约束需求：业务环境因素+使用环境因素+构建环境因素+技术环境因素 ER图中包含三个图形符号：实体，属性，联系 需求分析的主要成果：软件需求规格说明书（Software Requirement Specification, SRS） 需求确认包含两个重要工作："需求评审"和"需求承若

当日学习内容：阅读《梦断代码》、视频学习jQuery基础 1. 《梦断代码》阅读近况 今天，我阅读了第11章“通往狗食版之路”和尾声“长赌”。吃自己的狗粮，这种思路确实有助于提升软件质量和用户体验，想想连自己都不屑一用的软件凭什么去折磨用户呢？ 2. 视频学习近况 在结束HTML基础的学习之后，我开始了jQuery基础的学习。 来源： https://www.cnblogs.com/xiangyu721/p/12271545.html

大家好，我是来自SAP成都研究院Revenue Cloud 团队的质量工程师 , yoyo。很高兴可以和大家分享我个人的工作体会。每个团队都有QE（Quality Engineer）, 相信大家对QE 的工作并不陌生，我也就不唠叨QE 的具体工作啦。作为从事软件质量保证工作十年的“老人”，我想就我个人的工作经历和大家探讨下软件质量保证工作的变迁。 当我们谈论软件产品的质量保证工作时，必然是基于某种软件开发模式上的。皮之不存，毛将焉附？脱离了软件开发模式，质量保证工作就是空中楼阁。相信大家都感受到，近十几年，软件开发模式不断涌现新的概念和词汇，Agile, Continuous Integration , Continuous Delivery, DevOps ，令人应接不暇。我们首先要理解软件开发模式的变迁，然后才能进行与开发模式匹配的质量保证活动。 1. 瀑布开发 传统的瀑布模式如下图： 在这种模式下，测试活动仅仅是线性开发活动的后期活动。质量保证严格依赖于各个文档（需求文档，设计文档，测试计划和测试报告）以及评审会议，自动化测试可有可无。 2.增量开发 团队把产品的需求，设计，实现以及测试放在若干迭代周期里完成，每个迭代结束的交付物视为产品的增量，不要求增量达到能交付的要求，但需要能够基本可以工作。产品的交付仍然发生在最后，如下图所示： 增量开发的核心就是持续测试和持续集成