软件质量

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

软件测试基础入门知识点 一、行业前景 前言 ​ 程序员之间流传着这样一句话：有人喜欢创造世界，他们做了开发工程师，有人喜欢挑毛病，所以他们做了测试工程师。 什么是软件测试 软件测试就是利用手工或测试工具按照测试方案和流程对产品进行功能和性能测试，简单的来说就是为软件做“质检”。 软件测试的重要性 ​ bug 的经济损失： ​ 软件 bug 对我们的生活，工作都会带来毁灭性的破坏。据悉，每年的软件 bug 会让整个市场经济带来近600亿美元的损失！ 成立软件测试部门的原因 软件测试能提前发现软件存在的缺陷 社会分工越来越细 -- 要求软件测试越来越精细 专人负责，责任到位 二、测试基础 2.1、什么是软件测试 ​ 在规定的条件下对程序（App，.exe安装文件，网页等）进行操作，从而发现错误，对软件质量进行评估的一个过程。 2.2、软件测试的目的 ​ 是想以最少的人力，物力和时间找出软件中潜在的各种错误与缺陷，通过修正各种错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患以及带来的商业风险。（注意这个问题的答案，经常会与软件测试的定义混淆） 2.3、软件测试的定义 ​ 使用人工和自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。 2.4、软件测试的原则 所有的测试都应追溯到用户需求（视频网站，点击后最大化

1.你在测试中发现了一个bug，但是开发经理认为这不是一个bug，你应该怎样解决？ 　　1. 将问题提交到缺陷管理库里面进行备案 2. 要获取判断的依据和标准： 根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据； 如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷； 根据用户的一般使用习惯，来确认是否是缺陷； 　　3. 与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷； 　　4. 合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不参杂个人情绪。 　　等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并有上级做出决定。 2. 给你一个网站，你如何测试？ 　　首先查找需求说明，网站设计等相关文档，分析测试需求 　　制定测试计划，确定测试范围和测试策略，一般包括以下几个部分：功能性测试；性能测试；数据库测试；安全性测试；兼容性测试 　　测试用例设计： 功能性测试 ： 连接测试，连接是否能够正常跳转，是否存在空页面和无效页面，是否有不正确的出错信息返回 提交功能的测试 多媒体功能能否正常加载和显示 多语言支持是否能够正常的显示选择的语言等 界面测试 ： 1. 页面是否风格统一，美观 2. 页面内容是否合理，重点内容和热点内容是否突出 3.

一、什么是软件 软件是计算机程序、程序所用的数据以及相关文档资料的集合。 二、软件的定义 使用人工和自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。 本书以及百度的定义：为了发现程序中的错误而执行程序的过程。 三、软件测试的目的 1）软件测试为了发现程序存在的代码或业务逻辑错误； 2）软件测试为了检验产品是否符合用户需求； 3）软件测试为了提高用户的体验。 四、软件测试的原则 1）测试应该尽早介入； 2）所有的测试都应追溯到用户需求； 3）程序员应该避免检查自己的程序。除了单元测试。因为程序员对于自己的作品，思维具有局限性。无法保证测试质量。交给第三方或者专业测试，运用各种测试技术，利用丰富的测试经验和对bug的敏感，去提高软件的质量； 4）设计测试用例时应考虑到合法的输入和不合法的输入以及各种边界条件，特殊情况下还要制造极端状态和意外状态。 5）二八原则，测试发现的错误中80%很可能起源于20%的模块中； 6）对错误结果要进行一个确认过程； 7）制定严格的测试计划； 8）完全测试是不可能的，测试需要终止； 9）妥善保存测试过程中的所有文档。 五、软件测试的对象 1）程序； 2）数据； 3）文档。 六、软件测试的分类 1）按测试执行阶段划分： 单元测试（开发人员）； 集成测试（开发或者测试人员）； 系统测试（测试人员）；

软件测试的原则： 1、所有的测试都应追溯到用户需求（视频网站，点击后最大化） 2、应当把“尽早和不断地测试”作为座右铭 3、测试工作应该由专业的软件测试机构来完成 4、Pareto原则，测试发现的错误中80%很可能起源于20%的模块中 5、设计测试用例时，应该考虑各种情况 6、对测试出的错误结果一定要有一个确认的过程（描述缺陷报告） 7、制定严格的测试计划 8、完全测试是不可能的，测试需要终止 9、注意回归测试的关联性。 10、妥善保存一切测试过程文档。 提示：回归测试指修改了旧代码后，重新进行测试以确定修改没有引入新的错误或导致其他代码产生错误。 软件产品质量模型（ISO/IEC9126） 软件产品质量模型对产品设计时需要考虑的地方进行了高度概括。 六大特性： 1、功能性：是指软件产品在指定条件下使用时，提供满足明确和隐含要求的功能的能力。 2、可靠性：是指在特定条件下使用时，软件产品维持规定的性能级别能力。第一层：设备最好不要出故障；第二层：设备出现故障了不要影响主要的功能和业务；第三层：如果影响了主要功能和业务，系统可以尽快定位并恢复。 3、易用性：是指用户在指定条件下使用产品时，产品被用户理解、学习、使用和吸引用户的能力。简单10个字：易懂、易学、易用、漂亮好看（用户体验好）。 4、效率：是指在规定条件下，相对于所有资源的数量，软件产品可提供适当的性能的能力。通常

质量很重要，毋庸置疑的。但是进入新时代-- service -based software 的大量普及，软件测试所处的环境发生变化，是值得软件测试人员思考， 认真思考一下。 “测试之死” 并不仅仅是一个噱头。 首先看看软件测试所在的环境变化： 1. "fix defect " 的成本变越来越低成本。 　　传统的软件发布是基于一个软件包（package），有时很大，需要四五张光盘才能安装。软件发布出去后，如果有严重问题，需要修复，那是个很头疼的事。想想丰田汽车如何被召回的。现在软件运行在浏览器，有问题只需要改一下服务器，甚至不需要重启就直接修复了。 比较一下二者的成本，就这到为什么传统的软件测试人员千方百计的在软件发布前找到尽可能多的缺陷。而现在，主要矛盾已经由软件质量本身的担忧转移为对软件发布的速度上面。 2. 软件持续发布。 持续发布，跟传统软件一年一发布策略有着天然的优势：反馈快速快，应对需求变化快，更好让用户参与，提高交付满意度等等。 比如现在用的chrome，3年多发布17个版本。然而这些对软件测试提出了新的挑战，测试要快，至少不能拖慢开发节奏。如果测试影响软件发布的时间，这是不可接受的。传统软件测试，耗时耗力。尽管自动化测试的呼声，以及对应的想法，工具，数不胜数，但是面对如此短的发布周期，软件测试人员已经有点吃力。 3. 软件的测试理论没有什么重大突破 。 　

<font face="微软雅黑"， size=6> 首先 软件测试之灵魂拷问三连： 1.软件测试是什么鬼？ 2.软件测试如何分类？ 3.软件测试有没有Rule要遵循？ 卧槽，软件测试这么复杂，还有这么多道道，不就是"点点点"么？ 说这话的同学，请你尊重一下软件工程这个专业，好么？软件测试好歹也是软件工程的主干课程哦。 同时，说这话的同学也暴露了自己只做了纯执行的那部分工作。 好了，接下来我们要严肃的回答四连同志们的深刻提问。 1. 软件测试是什么鬼？ 按照 Standard for Software Test Documentation(IEEE Std 829-1998) 中软件测试的定义 软件测试：分析某个软件项以发现现存和要求的条件之差别并评价此软件项的特性。 软件的测试是为了确保软件的质量以及软件开发方向的正确性。 2. 软件测试如何分类？ 黑盒测试，白盒测试，灰盒测试，单元测试，集成测试，系统测试，确认测试，验收测试，冒烟测试...傻傻分不清楚。 当各位看官看完这篇解说文档，再有童鞋将黑盒测试，单元测试，白盒测试，系统测试，冒烟测试，验收测试这些概念混为一谈时，你基本可以判定，说这话的童鞋不是一名合格的测试攻城狮。 软件测试从不同的角度有不同的分类： 从软件测试技术来划分，软件测试可以分为： 黑盒测试，白盒测试，灰盒测试 从软件开发阶段来划分，软件测试可以分为：

软件的生命周期（prdctrm） 计划阶段（planning）-〉需求分析（requirement）-〉设计阶段（design）-〉编码（coding）->测试（testing）->运行与维护（running maintrnacne） 1 ，问：你在测试中发现了一个 bug ，但是开发经理认为这不是一个 bug ，你应该怎样解决。 答： 首先，将问题提交到缺陷管理库里面进行备案。 然后，要获取判断的依据和标准： 根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据； 如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷； 根据用户的一般使用习惯，来确认是否是缺陷； 与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷； 合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不参杂个人情绪。 等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并有上级做出决定。 2 ，问：给你一个网站，你如何测试？ 答： 首先，查找需求说明、网站设计 m 等相关文档，分析测试需求，制定测试计划，确定测试范围和测试策略，一般包括以下几个部分： 功能性测试；界面测试；性能测试；数据库测试；安全性测试；兼容性测试 设计测试用例： 功能性测试可以包括，但不限于以下几个方面：

本文已经首发于 InfoQ中文站 ，版权所有，原文为《XXX》，如需转载，请务必附带本声明，谢谢。 InfoQ中文站 是一个面向中高端技术人员的在线独立社区，为Java、.NET、Ruby、SOA、敏捷、架构等领域提供及时而有深度的资讯、高端技术大会如 QCon 、线下技术交流活动 QClub 、免费迷你书下载如 《架构师》 等。​ 在与不少测试从业人员讨论到敏捷的时候，被问得最多的大约是两个问题：“到底什么是敏捷软件测试？”，“敏捷软件开发还需要测试工程师吗？”。前一个问题是对于敏捷测试本身定义的疑问，第二个问题则是对敏捷开发将测试工程师排除在外的担心。其实，在探寻这两个问题答案的过程中，我们可以更清晰的了解敏捷软件开发中测试的工作定义，测试价值观，以及敏捷开发中开发与测试工程师的配合。鉴于这两个问题的意义，在本敏捷测试专栏的第一篇文章中，本人尝试从自己的实践出发，尽可能清楚的回答这两个问题。 确实，相对于敏捷开发红遍大江南北的状况而言，对敏捷测试的讨论则低调得多。敏捷联盟定义了敏捷的4个价值声明，以及伴随的12条支持原则，这12条原则中没有一条单独提到测试。这是不是意味着测试在敏捷开发中并不重要呢？实际上，如果仔细研读敏捷的12个原则，以及各种不同的敏捷实践，就会发现，测试在敏捷开发中占有非常重要的地位。无论是原则中的“频繁交付”，还是对“可工作的软件”的度量

软件研发流程和质量 最常见软件开发模型：瀑布模型（v、w模型） 　　　　　　　　　　快速原型模型 　　　　　　　　　　敏捷开发模型 V模型 　　 需求分析、概要设计、详细设计、编码、单元测试（独立的模块测试）、集成测试（模块联调）、系统测试（整体流程）、验收测试（验证是否满足需求） 。 v模型的优点： v模型清楚地标识出了软件开发的各个阶段； 清楚地描述了测试阶段与开发过程各阶段的对应关系与开发同步（引入检测机制，需求分析做的好不好，看验收测试）；它采用自顶向下逐步求精的方式把整个开发过程分为不同的阶段，每个阶段的工作都很明确，因此便于控制开发过程：阶段划分清晰，方便工作的整体把控。 v模型的测试既包括了底层测试（检验源代码质量的测试：单元测试），又包括了高层测试（需求级的测试：系统测试）。 v模型的缺点： 它仅仅把测试过程作为需求分析，概要设计，详细设计，编码之后的一个阶段，容易让人理解为测试是软件开发的最后一个阶段； 和瀑布模型一样，流程也是单向的。到了测试阶段，程序已完成，错误已经产生，很多前期的错误一直到测试阶段才发现，甚至无法发现，往往无从修改了。 没有明确说明早期的测试，不符合越早测试和不断地进行测试的原则（用户需求对不对要到验收测试才能发现）。 W模型-双V模型 开发一个v，测试一个v，开发和测试并行。 开发V：需求分析、概要设计、详细设计、编码、集成、实施、交付。