测试经验分享。
一、测试的流程和方法：
1、一个测试活动的完整流程是：
1 项目经理通过和客户的交流，完成需求文档，由开发人员和测试人员共同完成需求文档的评审，评审的内容包括：需求描述不清楚的地方和可能有明显冲突或者无法实现的功能的地方。项目经理通过综合开发人员、测试人员以及客户的意见，完成项目计划。
2 开发人员根据需求文档完成需求分析文档，测试人员参与评审，评审的主要内容包括：是否有遗漏或者双方理解不一致的地方。测试人员完成测试计划文档。
3 测试人员根据修改好的需求分析文档开始写测试用例，同时开发人员完成概要设计文档和详细设计文档。这两份文档作为测试人员编写测试用例的补充材料。
4 测试用例编写完成后，测试和开发人员需要进行评审。
5 测试人员搭建测试环境。
6 开发人员提交第一个版本，可能存在未完成功能，但需要跟测试人员进行说明。然后测试人员进行测试，发现bug后提交到缺陷库。
7 开发提交第二个版本，包括修改的bug以及增加了的部分功能，测试人员进行第二轮测试。
8 重复上面的工作，一般情况下从3-4个版本后bug数量减少，达到出货的要求。（如果有客户反馈的问题，需要测试人员协助重现以及回归测试）
2、在这里需求分析、测试计划、测试用例编写这块暂时不进行详细说明了，我们重点来讲一下测试过程中测试的方法和注意事项：
目前，我们的测试人员在行社这边测试基本都是黑盒测试，也称为功能测试，它是通过测试来检测每个功能是否都能正常使用。是以用户的角度，从输入数据与输出数据的对应关系来进行测试的。测试方法包括：
等价划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、正交试验设计法、场景法等等，下面就常用的几种来详细讲解一下。
1、等价划分法：是把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据作为测试用例。每一类的代表性数据在测试中的作用等价于这一类的其他值。
划分等价类的原则有以下几种：
在输入条件规定了取值范围或值的个数的情况下，则可以确定一个有效等价类和两个无效等价类，如：输入值是学生成绩，范围在0~100。那么一个有效等价类是“0≤成绩≤100”，两个无效等价类是：
“成绩<0”和“成绩》100”。
在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可确定一个有效等价类和一个无效等价类。
在输入条件是一个布尔量的情况下，可确定一个有效等价类和一个无效等价类，布尔量是一个二值枚举类型，一个布尔量具有两种状态：true和false。
在规定了输入数据一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类。如：输入条件说明只能输入的字符为：
中文、英文、阿拉伯文三种中的一种，则分别取这三种这三个值作为三个有效等价类，另外把三种字符外的任何字符作为无效等价类。
在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。
在确知已划分的等价类中各元素在程序处理中方式不同的情况下，则应该再将等价类进一步的划分为更小的等价类。
2、边界值分析法：是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等类划分法的补充，一般情况下，是对等价类的边界进行测试。
根据测试经验和测试统计数据来看，很多错误都是发生在输入或输出范围的边界上，而不是发生在输入/输出的范围的中间区域。对于这种方法，首先应确定边界情况，通常输入和输出等价类的边界，就是应着重测试的边界情况。应该当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。
通常情况下，软件测试所包含的边界检验有几种类型：数字、字符、位置、重量、大小、速度、方位、尺寸、空间等，相应的，以上类型的边界值应该在：最大/最小、首位/末位、上/下、最快/最慢、最高/最低、最短/最长、空/满等情况下，利用边界值作为测试数据。
基于边界值分析法的原则有以下几种：
如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据。如，如果程序的规格说明中规定："重量在10公斤至50公斤范围内的邮件，其邮费计算公式为……"作为测试用例，我们应取10及50，还应取10.
01,49.99,9.99及50.
01等。
如果输入条件规定了值的个数，则用最大个数，最小个数，比最小个数少一，比最大个数多一的数作为测试数据。如，一个输入文件应包括1~255个记录，则测试用例可取1和255，还应取0及256等。
将①和②应用于输出条件，即使输出值达到边界值及其左右的值。如，某程序的规格说明要求计算出"每月保险金扣除额为0至1165.25元"，其测试用例可取0.
00及1165.24、还可取一0.01及1165．26等。
再如一程序属于情报检索系统，要求每次"最少显示1条、最多显示4条情报摘要"，这时我们应考虑包括1和4，还应包括0和5等。
如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素。
如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值。
分析规格说明，找出其它可能的边界条件。
3、错误推断法：基于经验和直觉推测程序中所有可能存在的各种错误， 从而有针对性的进行测试。我们可以列举出程序中所有可能有的错误和容易发生错误的特殊情况。
如：测试手机终端的通话功能，可以设计各种通话失败的情况：无手机卡插入时进行呼出（非紧急呼叫）；插入已欠费手机卡进行呼出；无信号区域插入有效手机卡呼出；网络正常，插入有效手机卡，呼出无效号码（如、不输入任何号码等）；网络正常，插入有效手机卡，使用“快速拨号”功能呼出设置为无效号码的数字等等。
二、测试技巧：
软件测试虽然辛苦，但是若掌握了一定的技巧之后就会觉得容易多了。
1、 边界测试：测试用户输入框中数值的最大数和最小数，以及为空时的情况。
2、 非法测试：例如在输入数字的地方输入字母。
3、 跟踪测试：跟踪一条数据的流程，保证数据的正确性。
4、 在开始测试时应保证数据的正确性，然后在从系统中找出各种bug。
5、 接口测试，程序往往在接口的地方很容易发生错误，这块测试的时候一定要细心。
6、 **重用测试，在开发过程中有些模块功能几乎相同，开发人员在重用**时可能忘记在原有**上修改或修改不全面，而造成的错误。
7、 突发事件测试，服务器上可能发生意外情况的测试。
8、 外界环境测试，有些系统在开发时依赖于另外一个系统，当另外一个系统发生错误时，这个系统所受到的影响情况。
9、 在开发人员刚修复bug之后的地方，再找一找，往往开发人员只修复已提出来的缺陷而不去考虑别的功能在修改时是否会重新造成错误。
10、文字测试，如果在系统中有用词不当或错别字的地方是不好的。
11、系统兼容测试，例如有些程序在ie6能运行正常，到ie8下不能运行。有些程序在win2000下能运行，而在win2000却不能运行。像一些很特别的用户去使用系统，你很有可能发现bug。
12、用户的易用性测试，往往用户的需求是不断的变化的，而其中一部分变化的原因，是有用户操作上不方便引起的。
另外，有这么几个方面我们要注意：
1、在任何情况下都必须使用边界值分析法，经验表明，用这种方法发现程序错误的能力最强；
2、必要时用等价类划分法进行补充，尽量测的全面一些；
3、用错误推测法再追加一些情况进行测试；
4、对照程序的逻辑，再考虑一些其它的测试情况。
这里，我也总结了几个提高测试质量的方法：
1、先测试程序的核心功能，再测试辅助功能；
2、先测试功能，再测试性能；
3、先测试常见情况，再测试异常情况；
4、先测试经过变更的部分，再测试没有变更的部分；
5、先测试影响大的问题，再测试影响小的问题。
6、先测试必须测试的部分，再测试可选或没有要求测试的部分。
三、总结测试经验：
1、充分理解需求，找出需求缺陷。
测试人员拿到需求、设计文档后，应积极地与需求、设计人员进行沟通确认，并及时地提出自己对相关文档的疑问，这样做的好处一方面在于帮助测试人员充分理解需求，以保证设计全面、正确的测试用例；另一方面在于帮助找出文档中不完善甚至错误的地方，以便尽早解决，这样就降低了后续过程中的风险和成本，也缩短了开发的工作进度。
2、及时有效地沟通。
测试过程中，测试人员可能对设计文档有了新的疑问，或者程序实现出现了与设计不一致的地方，即程序实现的效果可能会达不到或者超出其他人（设计人员、测试人员）的预期（这种情况比较常见，因为大家看待事情的角度、表达方式、处理方式不一定一样，所以可能导致前者描述的事情，后者误解或者漏掉了其中一部分内容）。此时测试人员应该积极地与相关开发人员和项目负责人进行沟通，保证大家对同一个需求的理解是一致的，这样才尽可能地保证了我们的产品做出来是满足用户需求的；
3、抱着怀疑的态度了解测试需求和设计相关文档。
测试人员应注重分析需求和设计相关文档，但又不只限于这些文档。当测试人员拿到需求和设计相关文档时，同样应该抱着怀疑的态度，仔细斟酌文档中的情景，在充分理解需求的前提下，检查文档中是否有不合理或者不完善之处。
4、参考业务流程，模拟实际的业务场景进行测试。
同样，测试人员在测试过程中一定要注意结合业务流程，模拟实际的业务场景去测试。在我刚开始做测试的时候，对于“模拟实际的业务场景进行测试”的概念，一直很模糊。因为我刚开始做测试时，接触的后台数据比较多，所以当时地理解是我们需要去模拟用户的数据进行测试，但实际不只于此，例如一个系统有几个业务模块，单个模块由不同的人测试完毕后，再将这几个业务模块按正常的业务流程来的时候，就会发现有很多的问题。
这说明“模拟实际的业务场景进行测试”的重要性和必要性。
5、积极主动地反馈工作。
平时工作过程中除了要多跟项目相关的开发人员沟通，还要多跟上级或者项目负责人进行沟通，及时反馈工作进度、发现的一些问题等等，尤其是一些突发事件，让所有相关人员都能及时地了解当前任务的进展情况，以便于合理安排和处理。
6、合理安排工作，正确处理冲突事件。
我们工作中不可避免地会遇到多个项目同时开展的情况，尤其是遇到某些突发事件或者紧急事件，这个时候需要调整好心态，根据任务的优先级、紧急度等具体情况合理安排工作，在保证项目进度的前提下，更要保质保量。
7、注重知识的积累与总结，多与同事之间进行交流。
平时多注重知识的学习、总结和积累，这样可以为后续的工作带来很大的便利。同时在工作过程中发现的一些好的方法或者疑惑，多与同事进行交流，大家互相学习、互相帮助，共同进步。
8、建立良好的团队合作关系，形成融洽的工作氛围。
团队合作，这是一个非常重要也非常必要的话题。测试人员与开发人员之间的有效合作保障了产品满足用户的需求；测试人员之间地有效合作保障了用户的需求在合理期限内得到实现；团队合作，从需求的收集到产品的上线以及后期产品的维护，可谓无处不在，起着至关重要的作用。
软件测试计划
产品名称。测试计划模板。目录。1 简介 3 1.1 目的 3 1.2 背景 3 1.3 范围 3 1.4 术语 3 1.5 参考文档 3 2 测试需求 3 3 测试资源 3 3.1 人力资源 3 3.2 系统资源 4 4 测试环境 4 4.1 用户环境 4 4.2 测试环境 4 5 测试策略 4 5...
软件测试技术》测试分析报告
北方民族大学。课程设计报告。系 部 中心 计算机科学与工程学院 姓名马海山学号 20091508 专业计算机科学与技术班级一班 同组人员。课程名称软件测试技术。设计题目名称 图书出借系统测试分析报告 起止时间 2012年3月1日 2012年5月25日成绩。指导教师签名任荣。北方民族大学教务处制。目录...
软件测试报告
测试分析报告。项目名称 企业一级库库存管理系统。项目负责人徐文正。编写。校对。审核。单位 092012班第9小组。2011年11月2日。目录。1引言 3 1.1编写目的 3 1.2背景 3 1.3定义 3 1.4参考资料 3 2测试概要 4 2.1测试用例设计 4 2.2测试环境与配置 4 2.3测...
软件测试心得体会
软件测试心得体会 王礼永。曾经一度认为软件测试就是使用工具测试bug，现在看来不是这么一回事情，因为还是有手工测试 执行测试 工具只是一个辅助，用工具你先要去了解测试的一些基本的东西 如 测试用例，预期结果等 不是那按两下按钮就行了，就算是录制脚本，也需要看懂脚本的 工具不是万能的。一开始接触软件测...
测试软件公司新人培训计划
2013 年度人员培训计划篇二 测试部新人培训内容和计划 测试部新人培训内容和计划 一 公司制度 1天 公司简介 企业文化 产品简介 组织结构 部门介绍 公司规章制度及员工手册的培训 二 软件研发规范 1小时 软件项目研发流程 规范 文档规范 各部门间的合作方式 工作分工及管理平台 三 软件测试基础...
软件项目用户体验性测试报告
用户体验性测试报告模板。文档编号 受控状态 受控。版本号 v1.0 年月日。修订记录。类别 a 增加 m 修改 d 删除。目录。1.测试目的 1 2.测试对象概述 1 3.测试环境 配置与辅助工具 1 4.测试内容及结果 1 5.责任者及工作量 2 6.测试结论与建议 2 6.1 测试结论 2 6....
测试计划和测试方案区别
关于测试计划和测试方案的区别，这里主要从编写目的 定义和层次 编写时间和依据 软件过程 文档内容这五方面来说明，具体内容如下 一 编写目的。制定测试计划目的 按照所制定的测试计划可以有效的计划 执行 跟踪 组织和管理测试项目。具体从一下三方面来说 1，领导能够根据测试计划做宏观调控，进行相应资源配置...
软件采购合同
软件产品采购合同。合同编号 甲方 乙方 甲乙双方经过平等协商，在真实 充分地表达各自意愿的基础上，根据 中华人民共和国合同法 的规定，就甲方购买乙方销售的产品事宜达成如下一致条款，并由双方共同恪守。当产品由乙方送达甲方指定地点时即视为交付。甲方与乙方的合作仅限于本合同及相关附件条款的规定范围，本合同...