软件质量

测试六问： why:为什么测试？对功能、性能、可用性、容错性、安全性等测试，检查是否符合相关要求。 what:测试什么？测试对象包括文档、代码、图标等。 where:测试哪里？测试用例的环境，包括系统的硬件、软件和网络环境等。 when:什么时候测试？测试用例所需的前提条件是尽快开始。 which:什么数据？测试用例设计的各种数据。 how:如何执行？结果怎么样要根据测试用例设计的步骤来执行，最后进行结果比较，确定是否一致。若一致才能通过测试。 测试是为了发现错误而执行的一个程序或者系统的过程。 测试不单纯是发现错误的过程，而且包含软件质量评价的内容 测试是以评价一个程序或者系统属性为目标的任何一种活动，测试是对软件质量的度量 测试是为了度量和提高被测试软件的质量，对测试软件进行工程设计、实施和维护的整个生命周期。 软件测试只能证明软件存在错误，而不能证明软件没有错误。 测试的目的：把软件的错误控制在一个可以进行产品交付的程度，把错误控制在一个合理的范围之内。 软件测试包括：单元测试、集成测试、确认测试、系统测试、验收测试。 大量资料证明60%以上的软件错误并不是程序错误，而是分析和设计错误。 软件的质量 ： 软件满足规定或者潜在用户需求特性的总和。 包含内部质量、外部质量、使用质量 质量保证QA：质量保证的重要工作通过预防、检查与改进来保证软件质量。着眼与软件开发活动中的过程

软件的概念？ 软件是计算机系统中与硬件相互依存的一部分，包括程序、数据以及与其相关文档的完整集合。 软件测试的概念？ 使用人工或者自动的手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清楚预期的结果与实际的结果之间的差异 软件的内部质量（中间产品的静态测量） 外部质量（测试其外部属性，即代码执行时的行为） 使用质量（软件产品的使用） 外部质量:软件系统作为完整的整体运行时所表现出来的各方面的质量特征。 -测量活动:动态测试: ST 使用质量:最终用户在其真实环境中运行软件系统时,所感受到的软件各方面特性与其目标的符合程度。 测量活动:验收测试、 a、β测试 过程质量、内部质量、外部质量由软件组织内部人员评估: SQA、开发、测试。 使用质量由软件组织外部人员评估:用户。 外部和内部质量分别有6个特性： 一、功能性 1.适合性 2.准确性 3.互操作性 4.保密安全性 5.功能性的依从性 二.可靠性 1.成熟性：软件产品为避免因软件故障而导致失效的能力 2.容错性：软件产品在软件发生故障或者违反指定接口的情况下，维持规定的性能级别的能力 3.可恢复性：软件产品在失效发生的情况下，重建规定的性能级别并恢复直接影响的数据的能力 三.易用性 1.易理解 2.易操作 3.易学习 4.吸引性 5.易用性的依从性 四.效率 1.时间特性 2.资源利用率 3.效率依从性 五

速读《构建之法（第三版）》总结 花了两天的时间，终于是把这本《构建之法》粗略的阅读完毕，我在阅读的过程对于感兴趣的部分进行了仔细阅读，其中也碰到了一些问题。但我认为领悟这本书所传达的思想及思维方式是非常重要的，在此提出自己阅读时所收获的一些问题，不对的地方还望大家及时指正。 问题一 在软件的开发过程中，即便我们有了一定的软件开发能力后，为什么我们还要必须具备软件工程的工程思维？ 从以下几个主要方面进行简单分析 软件开发的变化 追溯到计算机刚起步的时候，软件设计只是为了个特定的应用而在指定的计算机上设计和编制，当时的语言使用还是机器代码或汇编语言，软件的规模也比较小，很少使用系统化的开发方法，软件设计几乎就是在个人编程。随着现在计算机整个行业的发展，软件的增多，高级语言的出现等，软件的规模越来越大，复杂程度也越来越高，软件的可靠性问题突显出来。在这个软件开发越发成熟的今天，从软件的立项到最后软件的发出，中间的开发过程慢慢的形成了各式各样固定的体系，当软件开发还处于幼年时期时，产品大多遵循[分析→设计→实现（制造）→销售→维护]，弊端是具有单向、不可逆性。后来，Winston Royce提出了具有相邻回溯的“瀑布模型”以及改进后的最终版本，后续又出现了很多“瀑布模型”的变形版。 图1.1 相邻回溯 图1.2 最终版 软件开发的模型有很多种，不同的软件可能适合不同的开发模型。

DevOps（Development和Operations的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。从定义来看，其实devops就是为了让开发、运维和QA可以高效协作的流程 来源： https://www.cnblogs.com/levin180425/p/11722329.html

导语 ： ‘“国外，资深的软件测试人员大多是手动测试，他们厉害之处在于测试用例的设计，但在国内，很多测试人员都把自动化测试当成很厉害的资本，为什么？” ● ○ ● 背景 ● ○ ● 　　 偶然在知乎上看到一篇关注度很高的话题，标题如上。 作为一名从业8年有余的软件测试工程师，并且一直在外企做测试的我， 忍不住想发表一些自己的看法和见解。 我觉得在国内，很多公司或者个人把自动化测试当成一个了不起的资本，根本是源于国内大家对代码的无上崇拜，这也造就了国内现在IT互联网行业内一个鄙视链： 开发---> 测试开发--->自动化测试--->纯手工测试 。所以，在这个鄙视链中，纯手工测试属于底端被碾压的生物。 实际上，我觉得这是一种严重的偏见，并且体现了其对测试行业认知的极其不专业。 ●自动化测试固然重要，但是测试思路才是重中之重 ● 首先，我们不能否认自动化测试的作用，他肯定是将来软件测试发展的一个大方向。 自动化测试将QA从繁重的重复劳动中解放出来，优化测试资源，提高测试效率，对产品质量保证起到积极的作用；另外，一个有自动化测试脚本、框架、工具开发能力的QA，更有竞争力也是一件毋庸置疑的事情。 　　但是，但凡做过测试工程师的朋友都知道，一些逻辑非常复杂的场景是很难用自动化脚本实现的，就算要强行实现，也性价比很低，因为太费时费力了。　　 　

一、质量保障 　　先引用一段 百度百科 上对软件质量保障的解释：软件质量保障是建立一套有计划，系统的方法，来向管理层保证拟定出的标准、步骤、实践和方法能够正确地被项目所采用。软件质量保证的目的是使软件过程对于管理人员来说是可见的。它通过对软件产品和活动进行评审和审计来验证软件是合乎标准的。软件质量保障人员在项目开始时就一起参与建立计划、标准和过程。这些将使软件项目满足机构方针的要求。 　　从我个人对软件质量保障的理解来说，软件质量保障不能只从测试（QA）的角度来看待问题，需要把自己抽离出来从更高的角度（公司/老板）来看待问题，无论哪一个环节出了问题，都是质量问题。需要关注整个过程当中的所有环节存在的问题和风险。对于软件质量保障的思考，我们可以从测试前、测试中、测试后三个阶段来进行，重点应该关注如下五个方面： 效率问题 代码问题 流程问题 沟通问题 机制问题 　　对于软件的质量保障，更多的是一些思考，考虑要从哪些阶段、哪些方面和大概的方面去保障，而它的延申就是质量体系的建设。 二、质量体系建设 　　对于不同公司、不同团队甚至不同业务，质量体系的建设不是千篇一律的，每一个公司/团队/业务都有其自身的特点，我们需要根据这些特点来建设质量体系。但是通常我们可以将它划分为三个阶段： 测前 1、差异性分析 业务特点 团队人员组成特点 开发水平如何 整个团队的技术栈，包括测试和开发

0 1 开始前说点什么 需要说明的是，原文发表于作者的公众号中，文章篇幅虽长，但内容朴实、且能帮助读者进一步理解测试开发工作，请读者耐心品完~ 1. 自我反省 公众号开通了也有两年多了，除了刚开通的那段时间发文比较频繁之外，从去年上半年开始，几乎很少再去打理了，翻了翻历史推文，从时间频率来讲，基本上平均2~3个月才更新一篇文章，工作忙虽是一方面，但这也只是借口，归根原因还是不够坚持。 2. 养成投资自己的习惯 最近一直在思考，当初为什么要开办公众号？有些读者可能会想：“是不是就想弄个渠道引流打广告！”，上周确实也帮朋友在公众号内做过一两次专栏推荐，但我想说的是，虽然有些小部分推文有些推广的成分， 但请试想一下，推荐给大家的学习专栏，都是实实在在能帮助大家提升自己技能、打造职场竞争力的有用课程，并不是无用的。 经常有周边同事或者读者跟我说：“你怎么会懂得那么多种类的专业知识啊，而我自己啥都不会，但又不知道怎么学，怎么办呢？”，我想对这些人说， 放开畏难情节，养成持续学习的习惯 ，这样知识技能的积累才能越来越多、越积越厚。现在社会上有很多人，喜欢投资房子、投资脸蛋、投资享乐，当然这些都没有错，但真正的长期投资，应该是投资自己，知识的投资对于自己来说，才是永恒属于自己的。 3. 回归初衷 前面说了那么多，更重要的还是想呼吁大家懂得投资学习，投资自己。回想当初为什么要开办公众号

1，B/S和C/S架构的区别？ 从测试的角度来讲。B/S架构需要重点考虑系统在不同的浏览器中的兼容性问题；C/S 架构需要考虑系统在不同平台的安装、卸载、升级 B/S 即Browser/Server(浏览器/服务器)结构,指浏览器和服务端，在客户机端不用装专门的软件，只要一个浏览器即可。 C/S 即Client/Server(客户机/服务器)结构,指客户机和服务端，在客户机端必须装客户端软件后才能访问服务器。 2，对HTTP协议怎么理解的？ http协议是应用层的一个数据传输协议，由请求和响应构成， 主要的请求方式有get和post两种，get请求的请求数据在请求头，post请求的请求数据在请求体 响应的数据也包含响应头和响应体。 3，常见的http状态码？ 200 请求成功 用于get/post请求 301 永久移动 302 临时移动 404 服务器无法找到资源，网页丢失 500 服务器内部错误 4，http请求头包含哪些信息？ content-type （作用：定义网络文件的类型和网页的编码 ） accept （作用：发送端（客户端）希望接受的数据类型） 5，get和post的区别？ get 请求数据参数放在请求头传送，请求地址长度有限制，一般用在获取数据。 post请求数据参数放在请求体传送，请求地址没有长度限制，一般用在提交数据。 6，什么是软件测试？ 软件测试就是使用软件

一、软件开发过程模型： 需求分析、详细设计、编码、测试、运行维护 瀑布模型：需求分析、系统设计、软件编程、软件测试、软件维护 快速原型模型：快速分析、构造、运行、评价 增量模型：规格说明、设计、实现与集成、交付客户 螺旋模型：制定计划、风险分析、实施工程、客户评估 ************************************************************************************************************************************** 二、测试模型： 需求分析、详细设计、编码、测试、运行维护 V模型：需求分析、概要设计、详细设计、编码、单元测试、集成测试、系统测试、验收测试 W(双V)模型： 需求分析　　　　、概要设计　　 、详细设计　　、编码　　、集成　　、实施　　、交付　　 验收/系统测试设计、集成测试设计、单元测试设计、单元测试、集成测试、系统测试、验收测试 H模型：测试准备-----就绪点-------测试执行 　　 01、单元测试： 是模块测试，验证软件的基本组成单位的正确性，是白盒测试 　　 02、集成测试： 是模块间的测试，测试接口（软件各模块之间的接口和软件与硬件之间的接口）是否正确，是灰盒测试（白盒和黑盒结合) 　　 03、系统测试： 系统测试包括：冒烟测试 系统测试

软件测试分类 1. 按照阶段进行划分 1.1 单元测试(Unit Testing) 单元测试是对软件组成单元进行测试。其目的是检验软件基本组成单位的正确性。测试的对象是软件设计的最小单位：模块。 测试阶段：编码后 测试对象：最小模块 测试人员：白盒测试工程师或开发工程师 测试依据：代码和注释+详细设计文档 测试方法：白盒测试 测试内容：模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试 1.2 集成测试(Integration Testing) 集成测试也称联合测试、组装测试，将程序模块采用适当的集成策略组装起来，对系统的接口及集成后的功能进行正确性检测的测试工作。主要目的是检查软件单位之间的接口是否正确。 测试阶段：一般单元测试之后进行 测试对象：模块间的接口 测试人员：白盒测试工程师或开发工程师 测试依据：单元测试的模块+概要设计文档 测试方法：黑盒测试与白盒测试相结合 测试内容：模块之间数据传输、模块之间功能冲突、模块组装功能正确性、全局数据结构、单模块缺陷对系统的影响 补充说明： 单元测试是一个模块内部的测试，集成测试是在模块之间进行测试（至少两个） 1.3 系统测试(System Testing) 将软件系统看成是一个系统的测试。包括对功能、性能以及软件所运行的软硬件环境进行测试。时间大部分在系统测试执行阶段,包括回归测试和冒烟测试 测试阶段