软件缺陷

十、怎样让软件更容易测试和更容易成功？（第15章） 　　当上一个项目失败，需要考虑下一个项目应该如何改善。本章介绍几种让软件更容易测试和更容易成功的方法。 　　1、软件测试变得困难的原因 　　从根本上来看，软件测试变得更困难的原因在于我们变得更有野心。我们希望有大型的软件来完成更有效率更好的事情。 　　1.软件越大，可能出现故障的地方就越多（故障数目）。 　　2.软件越大，越难查明故障的原因（查明花的时间）。 　　3.软件越大，工厂为维修而关闭，就会导致生产上更大的损失（损失的机会成本）。 　　2、让测试更容易和成功的方法 　　2.1 让系统尽可能小 　　　　让系统尽可能小（但是不要过小）。让需求受控，需要决策者或相关人来区分某件事对于产品是否真的是必需的。 　　2.2 让“系统”模型是可扩展的 　　　　应该警醒地检查你开发的简单系统是如何与更大的、及其复杂的系统纠缠在一起的。 　　2.3 增量构建有清晰接口的分立组件 　　　　例如就像“不要一次做所有事”策略所建议的，可以采用增量方式进行构建，在完成一个部分的构建、测试和修复工作后再开始下一个部分。 　　　　增量构建是测试先行的思想，即开始构建每个组件前先建立一组验收测试。 　　2.4 减少进入产品的缺陷数目 　　　　测试的难度不仅和从系统中去掉多少缺陷有关，还和他们何时被去掉有关。一般而言，越早去掉一个缺陷，它造成的损失就越小

我们需要知道的是软件BUG其实就是软件设计没有达到预期设计目标，导致在软件内存在的一种缺陷。 可以一句话概括：一切不符合需求规格说明书要求的，都可以视作软件缺陷。 定义：（1）软件未达到产品说明书标明功能 （2）软件出现了产品说明书指明不会出现的错误 （3）软件功能超出产品说明书指明范围 （4）软件未达到产品说明书未指出但应达到的目标 （5）软件测试人员认为软件难以理解.不易使用.运行缓慢或用户认为不好的问题 BUG的产生原因：1.需求不断变化 2.软件的复杂性 3.工期短，任务大 4.文档不完善 5.程序设计错误 6.软硬件支持不完善 7.沟通交流不够 缺陷报告处理流程： 缺陷报告模板： 缺陷的严重级别：致命：系统崩溃，404报错，报500，造成系统或应用程序崩溃，死机，系统悬挂，造成数据丢失，页面出现错误乱码，蓝屏等 严重：功能未实现，逻辑错误，影响用户正常操作，与需求完全不符，或因此BUG导致后续功能无法测试 一般：功能实现但不正确，功能上的错误，页面中的错误，逻辑实现但不正确 轻微：文案内容与实际不符，错别字，图片错误，建议性BUG 缺陷的优先级：可分为高，中，低，建议。当然这个根据公司和工具不同，叫法不一样。不过划分都是差不多的 高：BUG严重级别较高，需要立刻解决的，或者一般级别的但是比较棘手的 中：BUG严重级别一般的，不影响用户正常操作的 低

第七章：质量计划和缺陷估计（PPT.221-244） 1.软件质量的定义（PPT.223） 我们用已交付软件的故障密度作为软件质量的定义，即已交付软件中每个单位规模的故障数。 2.缺陷注入和清除的环节（PPT.224） 3.质量管理的主要任务（PPT.223） 质量管理的任务是规划合理的质量控制任务，然后正确地执行和控制它们，以实现项目 的质量目标。 4.质量管理的程序化方法指什么，有什么不足（PPT.225） ①建立评审和测试活动的规程和指南。 程序化方法：在定义好的点上执行一些过程以发现缺陷 ②缺少清除效率的量化描述 依赖规程的质量和规程执行的质量 5.如何制定量化质量管理计划（根据案例数据估计质量目标）（PPT.231-232） 转载请标明出处: [项目管理]-第七章：质量计划和缺陷估计 文章来源: https://blog.csdn.net/weixin_41754415/article/details/90517190

探索性测试扫盲 　　关于2477203708探索性测试，之前在群里总是听到有人提起，也搜了相关书籍，但是一直没有仔细去瞧。今日刚好妍姐发了一篇跟探索性测试有关的博客，看完之后被扫盲，另外也引发了我的一些思考。 　　探索性测试，文章里面写了很多概念和方法，其实都是在表达，可以有这么些办法，让测试人员想到更多测试场景，而且根据不同的维度，能想得更全面一些，类似于我们的移动端专项测试中某些特有的场景，只是这个更加通用了。 　　文章里面说到的一句话特别有意思： 测试人员的绩效不是通过他们找到了多少Bug来评估的，而是他们究竟提高了多少开发人员的工作效率和工作质量，从而反应在产品的质量上。 　　因为很多公司的绩效考评都参考了这么一点，形成开发和测试之间一种竞争和紧张的关系，某种程度上一方面不利于公司团结，另一方面可能会对产品质量带来负面的影响。考评测试人员绩效，这句话提出了一种新的视角。 　　 测试人员当然需要读写代码，而且最好的选择是直接从产品的错误处理代码入手，这样能一眼发现何种输入数据、输入顺序能把产品逼到极限。 　　这句话也为我学习代码提供了方向和参考的入口。 　　在此感谢原作者的总结和妍姐的分享。 　　 探索性 测试 在开始实践 敏捷 的时候，就一直谈论着探索性测试。尝试了许多方式，多角度覆盖、路径漫游、逆向思维等等，虽然取得了一定的效果

缺陷 1. 软件缺陷的概述 1.1 软件缺陷定义 软件缺陷, 通常又被叫做bug或者defect, 即为软件或程序中存在的某种破坏正常运行能力的问题、错误,其存在会导致软件产品在某种程度上不能满足用户的需求. 软件缺陷是指存在于软件(程序、数据、文档中的)那些不符合用户需求的问题. 1.2 软件缺陷的表现形式 主要表现为三种形式:“缺陷”、“故障”、 “失效” 缺陷: 存在于软件中的偏差,可被激活，以静态的形式存在于软件内部，相当于bug; 故障: 软件运行中出现的状态，可引起意外情况，若不加处理，可产生失效，是一个动态行为； 失效: 软件运行时产生的外部异常行为结果，表现与用户需求不一致，功能能力终止，用户无法完成所需要的应用。 缺陷不一定就会导致故障,只要缺陷没被触发; 同样,故障不一定就会导致失效,只要故障处理的得当. 2. 产生软件缺陷的原因 产生软件缺陷的原因很复杂,原因各种各样,: 需求有缺陷 系统架构设计阶段有缺陷 程序设计阶段有缺陷 程序研发阶段有缺陷 测试阶段有缺陷 硬件有缺陷 3.缺陷的信息 为了便于缺陷的定位、跟踪和修改,要对说发现的缺陷,按照缺陷的严重程度、优先级、发现阶段、修复阶段、缺陷的性质、所属功能模块、西庸环境等方面进行分类和统计, 3.1 状态 New:缺陷的初始状态； Open：开发人员开始修改缺陷； Fixed：开发人员修改缺陷完毕；

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，什么是软件测试？ 软件测试就是使用软件

七、测试评估方法和测试误区（第8章和第9章） 　　良好的测试是无法确认的。但是我们可以通过很多方法，知道或估算出不好的测试是什么样的。识别出有关测试的主要误区，可以更好的进行测试。　　 　　测试的评估方法　 　　1、永远无法确切地知道良好的测试 　　完美的测试具有如下特点：a)它会检测出一个系统中的所有缺陷；b)它永远不会将不是缺陷的情况判断为缺陷；3)它能让我们完全确信它完成了a和b；d)针对我们的需要，它可以足够迅速和廉价地实现a、b和c。你会发现完美的测试和很糟糕的测试具有惊人的相似性，一个很糟糕的测试也可能会满足a、b、c和d。 　　良好的测试是描述测试与某个实现之间的特定关系的属性。我们是无法知道测试是良好的，但是我们我们可以根据一些元信息知道测试是否糟糕。 　　2、根据事实来评估良好性 　　1）根据系统中缺陷的多少，来评估一组测试的良好性。 　　　　对这些缺陷进行追踪，分析他们的具体使用情况，可以得到一些信息。比如，测试有多好，以及好在哪些方面；将来可以如何对测试加以改进；测试会经常遗漏哪种缺陷。 　　2）根据长时间积累的缺陷，进行评估 　　3）其他评估方法 　　　　将测试覆盖范围和故障理论进行比较；随机改变测试来了解问题如何出现；对不同类型测试进行比较。 　　3、植入缺陷进行评估 　　　　插入已知的缺陷而不告诉测试人员

四、测试和修改软件BUG有什么分别？（第4章） 　　不能正确定义测试，就可能会产生无休止的争论。让测试人员或开发人员不知道自己的本质工作是什么，同时也会导致项目的失败。 　　1、大机构和小机构对任务的分工 　　在小机构或者小公司，一个人可以同时分饰多种角色，可以发现问题，查明问题，定位，确定重要性，修改和解决问题。 　　在大型机构或公司，必须要定义测试和开发的具体职责和分工，这样才能避免项目冲突和失败。 当个人的职权范围覆盖测试团队、开发团队和支持团队，就需要明确谁负责哪项工作。只有对工作进行明确分工，才能对整个项目加以改善，提高项目成功的可能性。 　　2、时间试探法的管理法则 　　项目中没人可以随意浪费任何人的时间。 　　通过这一原则，有两种应用： 　　1）测试人员在通知开发人员之前，对单个缺陷进行研究的时间限制在10分钟以内 　　　　10分钟后，如果对缺陷或缺陷所导致的问题还是不了解，可以请求他人帮助。 　　2）不要浪费时间来做细微的区分 　　　　发现和查明缺陷之间没有一个很清晰的界限，不要浪费时间争论特定的活动是否属于查明问题，而让测试人员和开发人员都投入进来共同完成工作。例如建立讨论组，或者测试人员和开发人员一起定位问题。 　　3、相关常识 　　1）定位缺陷需要花费时间，不要估算定位错误的时间。 　　2）每次任务切换都会损失一些时间，如果要切换的任务数目达到了五项

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

基础题（65分） 1、什么是需求？需求有哪些来源？（3分） 答：需求的分类：直接需求（用户直接需求告知要求）和间接需求（行业需求要求）；需求的定义：准确的描述用户需求； 来源：行业、用户、团队、运营、客服、自己（调研反馈、数据分析、竞品分析）；数据分析：产品功能使用情况，如行业报告、产品后台数据等挖掘用户需求；调研反馈：通过市场调研或用户调研等方式挖掘用户真实需求；竞品分析：确立竞品分析的目的，然后分析竞品的功能和内容都有什么，通过与竞品的对比得出自身产品的需求； 直白点说：01：来源客户要求；02行业要求；03公司内部分析的需求； 2、为什么说需求需要测试，如何测试？（4分） 答：需求是标准，贯穿整个项目，是项目中最重要的标准，必须经过多方面（技术、角色：用户、产品、测试、开发）测试，才能合理安排项目进度和技术分析设计，确保需求符合用户要求和课实现。 测试方法：01评审，参加人员（用户、产品、测试、开发）；02场景和技术模拟，确保可实现；03行业调研； 3、单元测试的定义？测试意义是什么？（3分） 答：指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。总的来说，单元就是人为规定的最小的被测功能模块