软件测试用例相关资料.docx
《软件测试用例相关资料.docx》由会员分享，可在线阅读，更多相关《软件测试用例相关资料.docx（38页珍藏版）》请在冰豆网上搜索。
软件测试用例相关资料
一般测试流程：
1.需求分析阶段：
只要就是对业务的学习，分析需求点。
2.测试计划阶段：
测试组长就要根据SOW开始编写《测试计划》，其中包括人员，软件硬件资源，测试点，集成顺序，进度安排和风险识别等内容。
3.测试设计阶段：
测试方案一般由对需求很熟的高资深的测试工程师设计，测试方案要求根据《SRS》上的每个需求点设计出包括需求点简介，测试思路和详细测试方法三部分的方案。
《测试方案》编写完成后也需要进行评审。
4.测试方案阶段：
主要是对测试用例和规程的设计。
测试用例是根据《测试方案》来编写的，通过《测试方案》阶段，测试人员对整个系统需求有了详细的理解。
这时开始编写用例才能保证用例的可执行和对需求的覆盖。
测试用例需要包括测试项，用例级别，预置条件，操作步骤和预期结果。
其中操作步骤和预期结果需要编写详细和明确。
测试用例应该覆盖测试方案，而测试方案又覆盖了测试需求点，这样才能保证客户需求不遗漏。
同样，测试用例也需要评审。
5.测试执行阶段：
执行测试用例，及时提交有质量的Bug和测试日报，测试报告等相关文档。
1、流程的意义
从一个软件企业的长远发展来看，如果要提高产品的质量首先应当从流程抓起，规范软件产品的开发过程。
这是一个软件企业从小作坊的生产方式向集成化规范化的大公司迈进的必经之路，也是从根本上解决质量问题，提高工作效率的一个关键手段。
软件产品的开发同其它产品（如汽车）的生产有着共同特性，即需要按一定的过程来进行生产。
在工业界，流水线生产方式被证明是一种高效的，且能够比较稳定的保证产品质量的一种方式。
通过这种方式，不同的人员被安排在流程的不同位置，最终为着一个目标共同努力，这样可以防止人员工作间的内耗，极大的提供工作效率。
并且由于其过程来源于成功的实例，因此其最终的产品质量能够满足过程所设定的范围。
软件工程在软件的发展过程中吸取了这个经验并把它应用到了软件开发中，这就形成了软件工程过程，简单的说就是开发流程。
不管我们做哪件事情，都有一个循序渐进的过程，从计划到策略到实现。
软件流程就是按照这种思维来定义我们的开发过程，它根据不同的产品特点和以往的成功经验，定义了从需求到最终产品交付的一整套流程。
流程告诉我们该怎么一步一步去实现产品，可能会有那些风险，如何去避免风险等等。
由于流程来源于成功的经验，因此，按照流程进行开发可以使得我们少走弯路，并有效的提高产品质量，提高用户的满意度。
目前流行的流程方法有很多种，如瀑布模型、螺旋模型、RUP模型、IPD流程等，不同的过程模型适合于不同类型的项目。
2、测试工作流程图
2.1测试工作总体流程图
说明：
集成测试和系统测试的反馈意见可能导致设计文档（需求或数据库）的修改。
2.2需求阶段流程图
2.3单元/集成测试阶段流程图
2.4系统测试阶段流程图
2.5压力测试流程图
说明：
压力测试为模拟用户正常使用时，系统正常工作的最小时间。
2.6性能测试流程图
说明：
测试系统的崩溃极限（最多使用人数和数据库的极限容量）。
测试计划
做任何事情都会有输入输出，对于测试过程我们可以把输入理解为测试计划、测试环境准备、测试工具的选择等等，输出可以理解为测试结果。
测试用例设计即可以理解为以测试计划为输入的输出，也可以理解为以测试结果为输出的输入，在这里咬文嚼字没有任何意义。
所有的这些书籍和过程文档无外乎告诉我们一个道理，做测试需要做好准备工作，把做一件事需要做的准备工作做好，明确做这件事的目的，最终达成目的并验证结果是我们要做的事情。
这要求我们有一个完善的“测试计划书”。
输入：
测试目的，测试计划，测试用例设计书，测试环境
输出：
测试结果报告书，BUG票，BUG分析，追加测试用例
测试计划的编写工作应该从以下几个方面考虑问题：
1、要充分考虑测试计划的实用性，即，测试计划与实际之间的接近程度和可操作性。
编写测试计划的目的在于充分考虑执行测试时的各种资源，包括测试内容、测试标准、时间资源、人力资源等等，准确地说是要分析执行时所能够调用的一切资源以及受各种条件限制，可能受到的各种影响。
说的再明确一点就是要“计划”“如何”去做“测试工作”，而不是“如何编写测试计划”。
2、要坚持“5W1H”的原则，明确测试内容与过程。
◇明确测试的范围和内容（WHAT）；
◇明确测试的目的（WHY）；
◇明确测试的开始和结束日期（WHEN）；
◇明确给出测试文档和软件册存放位置（WHERE）；
◇明确测试人员的任务分配（WHO）；
◇明确指出测试的方法和测试工具（HOW）。
测试用例
为什么说测试用例重要？
测试用例的重要性是毋庸置疑的，它是软件测试全部过程的核心，是测试执行环节的基本依据。
测试用例主要设计方法
●错误推测法
●场景法
●等价类划分法
●边界值分析法
●判定表法
●因果图法
●状态迁徙图法
●流程分析法
●正交分析法
●正交实验法
如果是自己做的设计，自己PG，其实错误推测法，场景法，流程分析法收效会明显得多。
因为熟悉流程，所以对可能存在问题的地方也是一目了然，不过这些对经验的要求又太高。
改进测试用例执行过程
●项目的测试负责人和测试工程师参与软件需求调研，以测试角度分析需求的可测性，可构思将来对其测试的方法、原则等；更重要的是，对不可测或难以测试性问题要及时与客户或项目经理协调解决。
●全面了解系统需求，从客户角度考虑软件测试需要达到的验证状态，即何些功能点需重点测试、何些无需，以便将来制定测试计划。
●有健全且严格的体制保证测试执行者严格按照测试用例执行测试。
●如有对测试用例认识模糊或内容遗漏的地方，可暂做记录待后期解决，或经测试负责人与项目其他管理人员同意方可更新用例库。
●测试负责人每日负责跟踪本测试子周期或阶段的测试用例执行情况，以及每日提交的缺陷报告，根据执行进展状态以及缺陷数量或严重等级与项目高层或其他人员展开交流，商议解决途径，并确定或调整未来时间的测试任务。
●测试执行者负责执行自己区域的测试用例，还要负责跟踪该区域软件缺陷的修改进展，根据其状态不断验证软件功能点。
●通过缺陷管理工具来管理软件缺陷；这样的集成工具都提供了清晰的报告模版及强大的追踪功能，测试团队的每一成员按照自己的角色和权限访问缺陷管理工具，并不断跟踪软件缺陷的状态。
测试过程
测试的过程应该为五个阶段，分别是发现问题、问题解析、解决方案、执行、验收。
发现问题
这个步骤最重要的就是发现（Discover）问题，详述（Discribe）问题，并且正确而详细地记录（Document）下来。
在进入下一步骤前，我们测试人员应该问问自已以下这些问题：
对于问题是否已经有简明的描述。
这一部分我们经常会犯的错误有2点：
●过分熟悉流程的测试人员，这是由于目前我们的测试人员和开发人员没有独立，会直接把问题解析写在问题描述中，虽然当时方便了问题解析对问题的解决节约了时间，但是当日后发生类似问题时由于没有恰当的问题描述导致问题解析无法比对，反而浪费了人力。
●是问题描述过于含糊。
如“XXXX-XX-XX发现系统死机”，这样的描述对问题解析者来说无疑大海捞针，问题记录者应详尽的描述问题发生的背景，场合，以用记录描述可以再现为要求描述问题，根据问题描述可以在实验室环境再现问题。
严格比对测试输出，避免错过问题。
经常会有问题明明PT甚至MT阶段就能发现却遗留到了ST阶段。
这是由于我们在测试过程中没有认真比对结果造成的，协议栈测试最重要的测试成果物就是LOG，是否对LOG中每一个接口，每一个参数进行了确认。
如果时间紧迫不可能对每一个参数进行检查，最起码是否对我们关心的参数，对关键流程进行了检查。
有时候很多问题时仔细看LOG就能发现的。
所以，
●严格比对测试结果是否为测试用例的期望。
●对关键流程和关键参数进行检查。
●测试一定要经过回归验证。
问题解析
Exploretheconditions：
探究原因，为问题提供明确的定义与定位。
这个步骤的主要任务：
是广泛搜集相关数据，尽量了解系统的每一个方面，避免深入分析时，漏了某个关键的现象而误入歧途；重点：
是探索（Explore），寻找证据（Evidence），建立（Establish）整个问题的来龙去脉的假设。
有2点特别重要：
●分析问题的时候一定要全面，进行水平展开，将类似问题一网打尽。
●一定要分析问题的影响。
因为一个很小的改动会系统都可能造成难以估量的影响。
解决方案
Trackdownpossibleapproaches：
提供可能的解决方案。
这个步骤的主要任务：
深入分析数据间的关联性，并对整个问题的前因后果提出假设，最后拟定出相应的策略（计划）。
如果前一个步骤做得不够详实，在这个步骤我们可能就会误判，导致努力了半天，但就是找不到瓶颈点。
对于一个问题可能有多个解决方案，有的实施简单，有的影响小，有的准确性高。
这时就有选择和取舍。
在问题解决时一定要把所有可能的方案都找出来，不要图简单，因为最简单的不见得是最合适的方案。
取舍的原则：
1.正确性。
不管哪种方案一定是要能解决问题的。
如果不能将问题彻底解决不管多简单都不是好的方案。
2.影响性。
一定要选择影响最小的方案。
3.实施性。
当测试紧张时也可选择用临时方案替代，然后再仔细研究应对。
因为有些问题的解决并不是一天两天能对应完的，这时就需要一个临时的替代方案。
当然做好版本管理非常重要。
4.及时修正。
执行方案时，仍然要注意系统的反应。
因为新的证据可能证明你先前的判断错误，因而要修正策略，甚至是退回到上一步以重新拟定计划。
验收
●确认解决方案成功与否。
●解决的方式是否有边际效应，造成其他的问题。
●是否真正根除了问题，还是仅表象地头痛医头，脚痛医脚建立问题的假设时，很容易将问题特殊化，仅局部地解决该现象。
●建立持续跟踪的计划。
当无法确定已经根除问题，那可能就要拟定持续跟踪的计划。
决定是否要持续观查某些计数器，跟踪某些现象是否还会发生，若发生了要如何解决等等。
测试用例检查单
1.是否涵盖了需求文档上的每个功能点
2.是否涵盖了需求文档上的每条业务规则说明
3.是否覆盖了输入条件的各种有意义组合
4.是否覆盖了业务操作的基本路径和异常路径
5.是否考虑了重要表单字段的数据合法性检查
6.是否考虑了其他的测试类型（对某个功能很重要，但未在需求文档中提及的，如安全测试、周期性测试和故障恢复等方面）
7.是否考虑了对其他模块/功能的影响
8.是否使用了项目组的标准用例模板
9.用例是否覆盖了测试设计中定义的所有场景
10.用例编号是否统一、规范
11.用例名称是否简洁、明了
12.目的字段是否准确地描述了对应场景的测试输入的特征（不同数据，操作，配置等）
13.前提条件字段的条目是否充分、准确，操作上是否不依赖于同组之外的其他用例
14.对应的需求编号字段是否填写正确
15.用例粒度、预估出的执行时间是否适当
16.同组用例中，仅数据不同的，是否实现了测试步骤的重用
17.某个功能点的第一个用例是否是基本流的
18.操作步骤的描述，是否清晰、易懂
19.操作步骤是否充分和必要，并具有可操作性
20.测试用例的检查点是否明确、充分和可操作
21.单个用例步骤或检查点中是否不再存在分支
22.测试数据的特征描述是否准确，有条件的情况下，是否给出了一个当前环境下的可用参考值
23.文字、语法是否准确；布局、格式是否统一
软件测试在公司的组织保障是基础
1.1 研发部组织结构介绍
以华友公司研发部的组织结构为例，测试部门属于研发部副总裁直接管理，见如下结构图
公司研发部的组织结构图
对于从事软件研发的组织来说，工作类型至少包括项目管理、产品设计、编码、测试、质量保证和软件配置管理，以及其它人员，如文档编制人员和美工人员/系统硬件管理人员等。
根据职能需要，可以以半独立方式进行部门和项目的矩阵管理，即职员要对项目经理/组长负责，也要对部门经理/总监负责，工作考核由双方共同完成，标准的组织应包括技术开发部/组（主要是编码和设计人员），产品开发部/组（产品需求和项目管理），测试部/组，配置管理部/组（因为配置管理人员基本上是按20个技术人员配一个配置管理人员，所以一般部门规模较小，或者只是配置管理组），软件质量保障部/组，其它部/组（如系统/文档/美工等）。
华友公司组织结构中，研发部是公司软件研发的核心部门
产品研发Ⅰ部、Ⅱ部、和应用研发部主要负责：
与软件产品部或内容产品部配合，协助完成内容产品的可行性、合理性分析；
平台、网关、应用产品的研发项目的立项和方案评审；
研发项目的概要设计、详细设计工作；
研发项目的编码、单元测试工作；
组织公司相关部门进行研发产品的培训；
协助相关部门做好产品的售前技术支持工作；
协助相关部门进行软件的安装与调试；
根据相关部门的要求做好产品的售后服务工作，保障软件的运行正常。
测试部隶属研发部，主要职责如下：
与内容产品部和软件产品部配合完成软件需求分析讨论，并根据需求说明书制订《项目测试方案》，编写《测试用例》，建立测试环境；
负责完成研发部各开发组研发的软件产品开发过程和投入运营之前的新增软件和修改升级软件的模块测试和系统测试；
建立、推广并维护实施软件版本管理系统CVS和VSS；
使用并维护软件缺陷管理系统Bugzilla，负责软件问题解决过程跟踪记录；
负责推广实施软件开发文档规范化工作，管理研发产品相关文档；
负责配合软件运维部门等对于新业务软件或修改升级业务软件的上线测试工作，并提供上线测试报告；
负责监督软件开发流程的执行，并负责提出软件开发过程改进建议，提高软件产品质量。
1.2 软件产品研发各部门的组织结构分解
1）华友公司从2003年10月开始，对项目组制订明确指标的独立考核，各开发部门是技术总监带队，再细分各项目经理具体负责项目计划和执行，对项目具体开发成员进行分工。
对于测试部门制订年度测试部门任务计划/考核表，如SMS业务销售额指标完成：
目标1：
9900万（奖金提取比例为0.01％）；目标2：
16800万（奖金提取比例为0.02％）；目标3：
23200万（奖金提取比例为0.03％）
详细给出财务目标和业务运营目标。
在每周的开发经理工作会议上交流报告任务进展情况，并提出最近测试需求，测试部门经理负责制订测试计划、测试用例和测试实施方案，安排测试工程师与对应的开发人员交流完成测试执行工作。
测试部经理负责开发流程管理和人力资源、测试用软硬件资源调配，需要与研发之外的部门定期交流掌握下周或近期可能测试任务，所有其他外部接口都由测试部经理负责完成，与其他项目组和产品部门协调项目进度。
2） 工作汇报关系为:
开发部门：
Team Member->Team Leader->研发总监->研发部副总裁->总裁。
测试部门：
测试工程师->测试小组经理->测试部经理/总监->研发部副总裁->总裁。
3）项目成员结构：
公司通常的开发项目组为6到8个开发人员，最多不超过10人。
华友公司的经过三次改造后的组织结构和项目组结构，各个业务部门分类非常细，任务明确，软件开发的每一个步骤都有专门的部门、专门的人员负责，从最基础的开发人员到负责统领全局的总监和副总裁，层层管理，沟通渠道畅通。
而在软件测试上，由于有限的测试资源，首先体现在公司的组织结构上，集中表现为测试部门不得不面对公司级管理部门的缺失和管理的交叉上，没有质量管理部门，部门质量管理工作测试部门兼做。
公司从成本角度考虑，测试部门规模较小，测试人员总数不超过10人，几乎每个测试人员接收处理10个开发人员的测试任务需求。
从实际情况出发，首先明确测试部门和软件开发部门相对独立的组织关系，保证测试人员的工作不受开发小组的控制，实现测试客观、公证。
华友公司要想有效地保障产品质量，首先就要在构架合理的组织结构和测试流程上下功夫，这就如同盖高楼首先要打好地基一样，地基不打牢，结构和流程不合理，其他方面再下功夫也是徒劳。
从实践经验看，一年前首先成立测试部，把属于开发部门的测试工程师归口到独立的测试部门管理，其次建立规范的测试流程，与开发部门交流，要求每周提出测试需求，再根据现有的资源制订每周测试计划，同时向人力资源部门提出招聘计划，随着测试工作的成绩不断被开发部门和上级领导认可，再推广实施软件开发过程规范化的管理，通过测试实践的优良成绩来确立测试部门在公司的地位和作用，经过一年的奋斗测试部门从无到有，从最初两人到现在十人，软件配置管理和缺陷跟踪系统已经被60%的开发人员自愿使用和接收。
总结本人在华友一年多测试工作经验，深深体会到在国内从事软件项目开发难、从事软件测试和质量保证工作更难，需要具备扎实的技术功底同时，不断提高测试项目管理能力，寻找工作的突破口。
世上无难事，只怕有心人，但是只要你努力献身于软件测试工作，打出一片天地是有可能的。
收集软件测试流程
【摘要】软件测试从哪里开始到哪里结束？
中间要经过哪些环节以及各环节要注意哪些事项。
本文就有关问题结合个人实际工作经验进行阐述，鉴于每个环节都可以做为一个专题来进行探讨，所以受篇幅和时间限制，本文对有关问题未做深入剖析，只做一个宏观上的介绍。
【关键词】测试流程、需求分析、测试用例、测试计划、缺陷管理
一、概述
一般而言，软件测试从项目确立时就开始了，前后要经过以下一些主要环节：
需求分析→测试计划→测试设计→测试环境搭建→测试执行→测试记录→缺陷管理→软件评估→RTM.
在进行有关问题阐述前，我们先明确下分工，一般而言，需求分析、测试用例编写、测试环境搭建、测试执行等属于测试开发人员工作范畴，而测试执行以及缺陷提交等属于普通测试人员的工作范畴，测试负责人负责整个测试各个环节的跟踪、实施、管理等。
说明：
1．以上流程各环节并未包含软件测试过程的全部，如根据实际情况还可以实施一些测试计划评审、用例评审，测试培训等。
在软件正式发行后，当遇到一些严重问题时，还需要进行一些后续维护测试等。
2．以上各环节并不是独立没联系的，实际工作千变万化，各环节一些交织、重叠在所难免，比如编写测试用例的同时就可以进行测试环境的搭建工作，当然也可能由于一些需求不清楚而重新进行需求分析等。
这就和我们国家提出建设有中国特色的社会主义国家一样，只所以有中国特色，那是因为国情不一样。
所以在实际测试过程中也要做到具体问题具体分析，具体解决。
二、测试流程
需求分析
需求分析（RequirmentAnalyzing）应该说是软件测试的一个重要环节，测试开发人员对这一环节的理解程度如何将直接影响到接下来有关测试工作的开展。
可能有些人认为测试需求分析无关紧要，这种想法是很不对的。
需求分析不但重要，而且至关重要！
一般而言，需求分析包括软件功能需求分析、测试环境需求分析、测试资源需求分析等。
其中最基本的是软件功能需求分析，测一款软件首先要知道软件能实现哪些功能以及是怎样实现的。
比如一款Smartphone包括VoIP、Wi-Fi以及Bluetooth等功能。
那我们就应该知道软件是怎样来实现这些功能的，为了实现这些功能需要哪些测试设备以及如何搭建相应测试环境等，否则测试就无从谈起！
既然谈了需求分析，那么我们根据什么来分析呢？
总不能凭空设想吧。
总得说来，做测试需求分析的依据有软件需求文档、软件规格书以及开发人员的设计文档等，相信管理一些规范的公司在软件开发过程中都有这些文档。
测试计划
测试计划（TestPlan）一般由测试负责人来编写。
测试计划的依据主要是项目开发计划和测试需求分析结果而制定。
测试计划一般包括以下一些方面：
1． 测试背景
a. 软件项目介绍；
b. 项目涉及人员（如软硬件项目负责人等）介绍以及相应联系方式等。
2． 测试依据
a. 软件需求文档；
b. 软件规格书；
c. 软件设计文档；
d. 其他，如参考产品等。
3． 测试资源
a. 测试设备需求；
b. 测试人员需求；
c. 测试环境需求；
d. 其他。
4． 测试策略
a. 采取测试方法；
b. 搭建哪些测试环境；
c. 采取哪些测试工具以测试管理工具；
d. 对测试人员进行培训等。
5． 测试日程
a. 测试需求分析；
b. 测试用例编写；
c. 测试实施，根据项目计划，测试分成哪些测试阶段（如单元测试、集成测试、系统测试阶段，α、β测试阶段等），每个阶段的工作重点以及投入资源等。
6． 其他。
测试计划还要包括测试计划编写的日期、作者等信息，计划越详细越好了。
计划赶不上变化，一份计划做的再好，当实际实施的时候就会发现往往很难按照原有计划开展。
如在软件开发过程中资源匮乏、人员流动等都会对测试造成一定的影响。
所以，这些就要求测试负责人能够从宏观上来调控了。
在变化面前能够做到应对自如、处乱不惊那是最好不过了。
测试设计
测试设计主要包括测试用例编写和测试场景设计两方面。
一份好的测试用例对测试有很好的指导作用，能够发现很多软件问题。
关于测试用例编写，请参见前面写的《也谈测试用例》一文，里面有详细阐述。
测试场景设计主要也就是测试环境问题了。
测试环境搭建
不同软件产品对测试环境有着不同的要求。
如C/S及B/S架构相关的软件产品，那么对不同操作系统，如Windows系列、unix、linux甚至苹果OS等，这些测试环境都是必须的。
而对于一些嵌入式软件，如手机软件，如果我们想测试一下有关功能模块的耗电情况，手机待机时间等，那么我们可能就需要搭建相应的电流测试环境了。
当然测试中对于如手机网络等环境都有所要求。
测试环境很重要，符合要求的测试环境能够帮助我们准确的测出软件问题，并且做出正确的判断。
为了测试一款软件，我们可能根据不同的需求点要使用很多不同的测试环境。
有些测试环境我们是可以搭建的，有些环境我们无法搭建或者搭建成本很高。
不管如何，我们的目标是测试软件问题，保证软件质量。
测试环境问题，还是根据具体产品以及开发者的实际情况而采取最经济的方式吧。
测试执行
测试执行过程又可以分为以下阶段：
单元测试→集成测试→系统测试→出厂测试，其中每个阶段还有回归测试等。
从测试的角度而言，测试执行包括一个量和度的问题。
也就是测试范围和测试程度的问题。
比如一个版本需要测试哪些方面？
每个方面要测试到什么程度？
从管理的角度而言，在有限的时间内，在人员有限甚至短缺的情况下，要考虑如何分工，如何合理地利用资源来开展测试。
当然还要考虑以下问题：
1
升级会员 