软件测试方法

1.测试管理工具 1，TestDirector(大而全) 2，jira(简单好用) 3，Quality Center(复杂，收费) 4，禅道（简单好用） 5，bugzilla(功能简单) 6，svn(代码和文档管理工具) 7，vss类似svn 8，git，同svn，但是多分支管理比svn好 9，Note（大而全，费用太贵） 10，CQ(ClearQuest-IBM产品-大而全) 2.接口测试工具 1，Jmeter（开源） 2，postman 3，SoapUI 推荐使用 jmeter 和 postman jmeter是一款100%纯Java编写的免费开源的工具，它主要用来做性能测试，相比loadrunner来说，它内存占用小，免费开源，轻巧方便、无需安装，越来越被大众所喜爱。 Postman是谷歌的一款接口测试插件，它使用简单，支持用例管理，支持get、post、文件上传、响应验证、变量管理、环境参数管理等功能，可以批量运行，并支持用例导出、导入。 3.性能测试工具 1，loadrunner，大而全，要学精通还是有点难度，重量级工具 2，jmeter 基于java平台的性能开源测试工具，其实也很强大，而且比较好用 3，Web bench 一个简单的web基准指标测试工具 4，Load UI，一款开源的压力测试工具，支持图形化 5，httperf 一款高性能的web性能测试工具 6

本章的主要内容是软件测试 验证与确认 软件的错误 1. 软件未达到产品说明书标明的功能；2. 软件出现了产品说明书指明不会出现的错误；3. 软件功能超出了产品说明书指明的范围；4. 软件未达到产品说明书虽未指出单应达到的目标；5. 软件测试人员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户不满意。 验证与确认 验证和确认是两个相互独立但却相辅相成的活动，Boehm 对两者的关系作出如下的描述：验证：我们是否在正确地制造产品？；确认：我们是否在制造正确地产品？。EagLesone 和 Ridley 把这两个概念进行了集成，提出：我们是否在保持产品的正确性？。 V & V 的活动 验证和确认在各个阶段中制定和管理特定的任务，其活动跨越了软件的整个生命周期。IEEE Std 1012—1998 给出一个验证和确认过程。 软件测试基础 什么是软件测试 Glen Myers 对软件测试提出了以下观点：1. 测试时一个程序的执行过程，其目的在于发现错误；2. 一个好的测试用例很可能是发现至今尚未察觉的错误；3. 一个成功的测试用例是发现至今尚未察觉的错误的测试。 软件测试的基本原则 1. 应当把“尽早地和不断地进行软件测试”作为软件开发者的座右铭；2. 程序员应避免检查自己的程序；3. 在设计测试用例时，应当包括合理地输入条件和不合理的输入条件；4.

王豆豆最近一直在加班，天天都加班到九点多，项目大多是紧急上线，但其实每天的工作量并不算多，按理说应该在上班时间就能完成，但每天到了下班时间却走不了，不得不留下来继续做。 留下来加班的原因无非二种：1，项目需要上线；2，测试任务没有完成 测试任务没有完成的情况比较少，常态是每天临近下班的时候，开发要不就在这个时候转测，要不就是临时有一个小功能修改完要上线，又或者是紧急安排了一个需求会议，又或者是联测等。 什么是紧急项目呢？ 紧急项目是那类上线时间很紧急的项目，比如今天转测，就要求今天或明天就能上线的项目，这类项目就是属于紧急上线的项目，这类项目有一个特点就是需求不明确；测试时间短。 测试人员基本都是临到转测时，才知道有这样一个测试需求，但又因为从接到这个类测试任务之时到上线的时间间隔都很短。 正是因为该类项目的特点，这类项目测试结果没有保障，基本都是测试完主要流程，就匆匆上线了。还有一类项目是这类项目的加强版，是紧急项目的同时需求不断变动。 王豆豆最近做了几个这类的项目，从接到项目的同时才知道测试功能和上线时间。 接到这类项目基本不会编写测试计划，测试用例等文档，接到项目就开始理解需求，与开发沟通改动范围和测试范围，然后开始测试，如果是运气比较好的时候，还没开始测试就能发现以前的结构设计不对，需要改；运气不好的时候，基本都已经测试完成了，才发现需求设计不对，需要重新修改。

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

软件缺陷的定义 来看一下 Ron Patton 为我们的软件缺陷所下的定义。 1、软件没有实现产品的说明书所描述的功能。（个人觉得 “ 描述 ” 比 “ 宣称 ” 更贴切） 2、软件实现了产品说明书描述不应有的功能。 3、软件执行了产品说明书没讲的操作 4、软件没有实现产品说明书没讲但应该实现的功能。 5、从软件测试员的角度来看，软件难以理解、不易使用、运行缓慢，或者最终用户认为不对。 为什么一个定义要这么多条来描述？这个 “ 缺陷 ” 的定义有这么复杂么？不，它其实并不复杂，作者只是想更加全面的来给“缺陷”下定义。下面我们来以建一栋房子为例，来说明一下每一条定义的意思。需要说明的是没有十分完美而且一成不变的产品说明说，而且在实际项目中，它可能非常简陋，模棱两可，甚至经常变动。 1、软件没有实现产品说明书的描述的功能。房子的主人希望有一个落地的大窗户，让阳光更好的照进屋子里，而且他特意在房子的设计图纸中画出来，并且还加以说明。结果，他看到的是四面全是墙壁，只有一个小门的房子。那么对于测试人员来说，他就是一个缺陷。 2、软件实现了产品说明书中描述的不应有的功能。由于房子的主人生活在南方，天气温暖，而请来的泥瓦匠是北方的，结果给主人建造的房子具然有一个大大的取暖的烟筒，而且主人特意在房子的设计图纸中说明，自己的房子不要烟筒。那么对于测试人员来说，这也是个缺陷。 3

  1.软件   是一系列按照特定顺序组织的计算机数据和指令的集合。   2.软件开发生命周期模式   2.1软件产品从最初构思到公开发行的过程。   2.2常用4种模式：大爆炸模式、边写边改模式、瀑布模式、螺旋模式。   2.3大爆炸模式：简单，计划、进度安排和正规的开发过程几乎没有，所有精力都花在开发软件和编写代码上   2.4边写边改模式：最初只有粗略的想法，接着进行一些简单的设计，然后开始漫长的来回编写、测试和修改缺陷的过程。等到觉得足够了，就发布产品。及其适合意在快速制作而且用完就扔的小项目，例如原型范例和演示程序。   2.5瀑布模式：从最初的构思到最终产品要经过一系列步骤，每一个步骤结束时，项目小组组织审查，并决定是否进入下一步，如果项目未准备好进入下一步，就停滞下来，直到准备好。   2.6瀑布模式需要强调的3点：    ①瀑布模式非常强调产品的定义。注意，开发或者代码编制阶段只是其中单独的一块；    ②瀑布模式各步骤是分立的，没有交叉的；    ③瀑布模式无法回溯，一旦进入某一个步骤，就要完成该步骤的任务，然后才能向下继续。   2.7螺旋模式：总体思想是一开始不必详细定义所有细节。从小凯斯，定义重要功能，努力实现这些功能，接受客户反馈，然后进入下一阶段。重复上述过程，直到得到最终产品。   2.8螺旋模式每一次循环包括6个步骤：    ①确定目标

首先，在这里说明的这并不是纯新手的软件测试入门指南，因为这里面并没有太多测试理念和测试手法的东西。只是对有测试技能却没有测试经验，即工作经验缺乏的新手的一点小小建议。 当你刚踏入测试团队的时候，你可能无从下手。拿来软件就是一顿乱点。其实要做一个好的测试人员。一定要有一份好的计划。所以测试计划就是测试的开始。 　　在测试计划里要对自己的软件进行了解。是说明你对整个软件的了解。以及业务处理的过程，了解软件的测试重点在哪儿。所以业务描述和测试点就显的十分的重要了。而在这里我建议测试新手要对测试点进行详细的描写，最好使用表格的形式。最后在用例中给自己列出一个大致的时候安排计划。 　　而测试计划只不过是一个开始，下面才是真正要进行测试的部份"测试用例"，在测试用例中对于新手来说。等价类和边界法是最有较的测试方法，但是有很多的时候也要注意用因果图会比这些方法好用的多。所以在这里我建议大家三种方法可以相结合的使用。效果更佳。在我看来其实功能测试用例就是记录你的动做和返回值，看看是否正确。所以可以做一张大表。分别写出序号。测试项，动作，预期结果，输入值，实际结果，说明。。。。。。可以按业务流程顺序写。可能会有好多条结果，其实这个没有关系。因为我们可能写好多次一样的业务流程，只不过输入值不同，返回的结果就一定不同。如果后台用的是大型数据库，也可以对后对数据表的流向进行一下描述

Q1：什么是软件？ 软件是计算机的灵魂，软件可分为两大类：系统软件和应用软件。 系统软件：系统软件是生成、准备和执行其他程序所需的一组文件和程序。如操作系统Windows，数据库SQL-Server，驱动程序，java语言系统编译环境等。 应用软件：计算机用户为了解决某些具体问题而购买、开发或研制的各种程序或软件包。如APP、QQ、微信等。 Q2：什么是软件测试？ 为了发现程序中的错误而执行程序的过程。 软件测试分类 1.按测试执行阶段划分： 单元测试、集成测试、系统测试、验收测试（正式验收测试、Alpha测试、Beta测试） 2.按测试技术划分：白盒测试、黑盒测试、灰盒测试 3.被测试对象是否运行划分：动态测试、静态测试（文档检查、代码走查、界面检查） 4.按不同的测试手段划分：手工测试、自动化测试 5.按测试包含的内容划分：功能测试、界面测试、安全测试、兼容性测试、易用性测试、性能测试、压力测试、负载测试、恢复测试 6.其他测试：冒烟测试、回归测试、探索性测试/自由测试（测试思维） 软件的生命周期 1.问题的定义及规划 主要确定软件的开发目的及其可行性（市场调研），指定项目总体开发计划 2.需求分析 在确定软件开发可行的情况下，对软件需要实现的各个功能进行详细分析，明确客户的需求，输出需求规格说明书初版（原型图），提交评审。 3.设计

目录 1. 什么是软件测试?...................................................................................................................................... 3 2. 软件测试的目的？................................................................................................................................... 3 3. 软件测试的原则？................................................................................................................................... 3 4. 请分别阐述目前白盒测试和黑盒测试主要的测试用例设计方法?.................................................. 4 5. 什么是测试用例，什么是测试脚本，两者的关系是什么?...............................................

测试过程中遇到的问题 不知道是否较全面的测试了所有功能 测试的覆盖率无法衡量 对新版本的重复测试很难实施 存在大量冗余测试影响测试效率 容易出现漏测，重复测试 测试人员没有明确的工作目标，工作效率低 软件测试用例的概念 测试用例（Test Case）是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。 测试用例一般可以简单划分为：场景测试用例（简称“测试用例”）和基本测试用例（或称为“公用测试用例”） 设计测试用例的方法 等价类 边界值 场景法 错误推断法 因果图 状态图 正交排列 路径覆盖 设计测试用例的优缺点 优点 有效性 完整性 组织性 缺点 测试用例的设计是费时费力的工作，往往设计测试用例所花费的时间比执行所花费的时间还多 随着测试用例的不断积累，所带来的维护成本也会越来越高，维护难度也会逐渐增加 测试用例的执行效率低 需求的变更导致写的测试用例变的一文不值 测试用例的要素 测试用例的组成元素及作用 用例编号：该用例在整个测试套件中的编号 所属模块：测试用例所对应的测试模块 用例标题：清晰表达出该测试用例是测试什么问题的（包含测试目标/测试对象） 操作步骤：执行测试时的步骤 测试数据：测试用例执行时所需要使用的数据 预期结果：根据所输入的测试数据，期望得到怎么样的结果 实际结果：根据所输入的测试数据，实际得到的测试结果