《QA的基本知识》由会员分享，可在线阅读，更多相关《QA的基本知识（7页珍藏版）》请在金锄头文库上搜索。
1、. QA的基本知识修订历史记录日期版本说明作者2006-6-8V1.0初稿谢中才什么是QA QA (Quality Assurance), 就是质量保证，是公司产品质量保证的重要环节，也是最后一个环节。QA，不等同于测试，测试仅仅是QA工作的一部分。QA工作还包括对产品质量的生产过程控制、问题跟踪和产品分析等。QA，站在用户的角度去测试、分析产品，最终对公司负责。一、QA的主要任务： 完整地保证产品的质量. 帮助开发人员提高程序代码质量. 监控整个项目工作流程. 对用户的意见迅速反应. 不仅促进公司产品的功能更完善、更强大，还要考虑产品的易用性.二、质量保证体系 QA 实验室和测试环境的模拟，
2、各种用户的应用环境（硬件平台、操作系统、浏览器和应用程序）在实验室中能得到模拟、实现。 基于Bug跟踪讨论体系的数据库，能很好地掌握Bug状态、进行必要的查询、统计和分析。 建立和发布跟踪讨论体系，能对产品设计和开发中的一些问题进行有效的讨论和交流。 测试案例(test case)和测试套件(test Suits)管理体系，保证测试的顺利进行和提高测试的效率，测试案例不断完善和建立。 了解和掌握一些测试工具软件，自动实现实时的、不断重复的测试过程 为关键模块测试和改善而开发必要的工具软件 和竞争对手进行产品比较分析,指出自己产品的缺点和学习对手的优点三、宗旨QA要对产品负责，对用户负责，也就是
3、对我们凯捷公司负责。QA 工作基本知识QA工作涉及面比较广，要了解许多基本知识，但必要的基本知识得有一些，它会让我们更好地理解QA和工作流程等。一、基本概念1BUG : 是产品设计、开发中所带来的各种缺陷、问题等，主要指： 功能、特性没有实现 设计不合理，存在缺陷。 实际结果和预期结果不一致 运行出错，包括运行中断、系统崩溃、界面混乱 用户不能接受的其他问题，如时间过长、界面不美观BUG一般有六种级别 Fatal：致命错误，造成系统或应用程序崩溃(Crash) 、死机。 Critical：严重错误，指功能或特性(Feature)没有实现 Major：较大的问题，虽然不影响系统的使用，但没有很好
4、地实现功能，没有达到预期效果，或用户界面差、操作时间长等一些问题 Minor：不对齐、字母拼错等一些小问题 Suggestion：建议程序做适当的修改，来改善程序。 Question Design：对设计不合理、不明白的地方提出质疑BUG一般有四种状态： Open：问题没有解决，QA人员新报的Bug, 或验证后Bug仍然存在； Fixed：开发人员修改程序后，认为问题已解决 Close：QA人员验证Fixed Bug后, 确认Bug不存在 Hold：所报的Bug，目前不需要解决或无法解决。2Case Table:Case就是为了测试产品某项功能或特性而设计的测试案例。 Case Table就是
5、一系列Case的集合，具有单一的目标或要求。Case Table包括对测试环境要求，指明测试对象和数据准备、系统初始化、操作等整个测试过程，清楚说明每项Case要求实现的具体指标。3FeatureFeature是产品要实现的功能和特性，它表现为良好的界面、合理的计算结果等。用户的要求正是各种各样的Feature集合构成。4单元测试（Unit Test）单元测试是对软件系统的各个模块（可以分解到最小单位）进行测试。单元测试在开发人员写代码时就可以进行。5整体测试 (Integration Test)由各个模块组合成完整的系统或产品，然后进行测试。整体测试要等开发人员完成全部代码后才可以进行。二、
6、测试方法测试的基本方法有两种：白盒子和黑盒子测试方法1 白盒子白盒子测试就是一种透明测试方法，测试者必须完全了解功能或特性实现的内部结构和细节。针对软件测试，白盒子测试就是通过阅读所测试软件的原代码，掌握程序所要求的参数、初始数据，设计CASE, 使测试能遍历所有路径（分支）和满足各种条件。白盒子测试的要点是：v 确定代码测试的控制点v 要求了解主要变量、每个函数和类、对象的作用v 逻辑驱动能力v 编写手工测试程序2 黑盒子黑盒子测试就是不要了解功能或特性实现的内部结构和细节，把程序、模块或产品看成一个黑盒子，要清楚系统或模块要达到的目的或期望值（输入/输出结果）。测试者只关心系统应该做些什么
7、，而不管它是怎样实现的。这种方法要点是：v 自动创建v 类、对象和函数知识的限制v 规范所特定的Case Tablev 数据驱动单元测试一般采用白盒子方法，整体测试一般采用黑盒子方法。 QA工作流程一、测试前的准备工作 1. 准备好测试环境，包括硬件平台(PC/UNIX/MAC)、操作系统、浏览器等软硬件环境。 测试服务器的安装由QA相关人员和信息中心相关人负责，保证测试服务器能够及时的搭建好，不影响测试任务； 测试服务器的密码只有相关人员(QA Manager、网管人员和Release Engineer/Project lead )知道,不允许将密码告知开发人员，更不允许开发人员在测试服务器
8、上直接修改代码. 测试前要充分的了解要测试的对象(系统或产品),要有整体认识，了解其功能、特性、输入/输出和结构。 准备好要用的软件工具、文档,测试套件等。二、测试工作1 接受任务，不同的产品或测试阶段，选定不同的测试方法，包括：1）单元测试(Unit Test)和集成测试(Integral Test)，2)服务器测试：基本功能测试稳定性、可靠性的测试系统强度、承受能力的测试系统性能的测试系统非正常测试3) 理解任务和分派任务，标准的任务书(Build)。2单元测试阶段在开发人员写代码阶段，QA人员就要介入，这一阶段主要工作有： 研读市场需求文档 ( MRD),理解产品特性 跟踪开发人员进度,
9、了解产品功能实现情况,测试哪些特性/功能已实现，哪些没有实现。 从测试的角度向开发人员提出改进意见,完善产品性能. 理解产品特性, 建立、改进和完善CASE表 在这一阶段，QA人员只要将报告提交合肥公司内部有关人员就可以。对所发现的问题不作为BUG报，只作为问题在报告中实现。在这一阶段主要有两项关键任务是： 在开发人员交代码日期，要清楚知道是否所有的功能和特性全部地、完整地得到实现； v 完成该项目（或产品）的CASE表。3.根据测试的内容，建立或指定已有的测试案例表（Case Table）。Case Table的内容主要有：1) 测试环境要求（操作系统、浏览器和测试工具软件等）2) 测试的目
10、标：Function, Feature , Usable 和Stable等3) 测试的类型：Basic, Primary 和 Full4) 测试的项目：针对所采取的测试方法对各项目测试的数据、参数确定；包括Case ID号、Case名称、Case描述(含Criteria)和目标（Objective）5) Case Table要充分体现系统或产品的Feature，满足MRD文件，力求覆盖所有的功能和操作路径。5准确理解CASE表中的描述，认真按要求去测试。根据Case Table测试，力求所有功能路径都能覆盖，找出所有的Bug。不要漏报、错报，特别是一些严重Bug，更是不能放过。正确判断Bug的
11、错误级别（Fatal , Critical，Major, Minor 和Suggestion）一般情况下要求对Bug进行交叉验证(Verify)，力求再现。对严重的Bug要考虑多种情况 ：v 测试人员交叉验证v 测试的机器交叉（同一个操作系统和浏览器）验证v 测试的平台交叉 ( Windows 9x, Windows NT 和 Windows 2000等) 验证v 不同的浏览器 （IE , NS）验证对得到验证、确实存在的Bug：1) 及时报到TD中；2) 标题、测试步骤应描述准确；3) 应附的各项信息应完整准确，即及时记录Bug发生的具体环境( 通过图片、系统信息来描述)、操作步骤等。4)
12、尽力在报告中分析出错误产生的原因。4每天首先要做的工作就是验证前一天开发人员所Fixed的Bug,将情况回馈给项目负责人。对Bug进行验证，以确认是否被修正。如没有改好，则重新将Bug状态置于”Open”状态，否则置于”Closed”状态。1) 原有的bug状态的改变：同系列版本以前存在的Bug如在最新版本中改变状态时，应及时更新Bug库中该Bug的状态。对不同系列版本的原Bug不需更新Bug库中该Bug的状态。2) 开发人员没有将Bug置于”Fixed”状态，测试者一般不能直接将”Open”变为”Closed”。特殊情况下，要有充分的理由填入Comments，否则视为误报。3) 对开发人员在
13、Bug的Comment中只注上”It is not bug”类似的信息，QA人员有权将这Bug重新打开。4) 对一个Bug一时不能解决、或暂时不需要解决或其它特殊原因，需要Hold时，需报QA Manager和有关负责人，经分析后得到有关人员许可，才能Hold。任何人不得擅自Hold一个Bug.5Bug验证完后，才走Case Table. 测试中遇到自己无法解决的问题时，应及时上报组长，由组长协同有关人员解决6. 结束一天的测试工作后,填写规范的CASE表,发给项目负责人，并反映出在测试工作中遇到的问题。项目负责人统计一天的测试情况,完成测试报告和发送。注：每个项目均应留出一天时间做最后REA
14、LEASE工作。由开发和测试共同合作，对产品做最后测试，及时处理出现的问题，保证产品按时发布.三、测试报告根据测试结果和各测试工程师所报的CASE表汇总，填报日报：a. 清楚描述测试的任务、目标、版本和环境b. 对各模块的测试情况进行统计，总Case数、已测和失败的情况c. 对Bug的分类，New与Old、Open与Close, Fatal、Critical与Majord. 不清楚的问题，它可能不是Bug, 是设计上的不足e. 特别的其它说明。在一个版本测试完成后，应相应完成该版本的质量测试报告。将结果发给有关的开发人员。四、测试分析一个项目测试结束后，要及时分析整个产品的开发和测试阶段，找出一些存在的问题。特别是我们没有发现的Bug, 客户发现了，应认真对待，确定解决问题的对策，避免今后出现类似的情况。一般情况下，要做一下分析工作：v 测试工作自身需要改进的地方v 对测试的软件下一版本的改进意见v 测试的分类统计，按模块、错误级别、应用环境（如浏览器）v 找出开发人员的容易犯的错误。.
