软件测试过程-单元、集成、系统、验收测试-pub

软件测试过程：单元、集成、系统、验收测试和一个项目案例xxxxxxxxxxxxxx过程（Process）是一种手段，通过该手段可以把人、规程、方法、设备以及工具进行集成，以产生一种所期望的结果

--网络

议程测试过程回顾单元测试集成测试系统测试验收测试一个软件测试项目过程分析回顾：软件测试过程模型非常明确地表明了测试的不同级别，清晰地展示了软件测试与开发之间的关系ValidationVerification详细设计构架设计系统测试计划集成测试计划单元测试计划单元测试集成测试系统测试编码产品交付产品维护和回归测试业务需求验收测试计划系统需求用户验收测试AcceptanceTesting保证良好的客户感知保证业务完整性保证业务的设计架构可靠性保证业务功能可用性保证系统在运维时的稳定性议程测试过程回顾单元测试集成测试系统测试验收测试一个软件测试项目过程分析软件单元是什么？(IEEE)软件单元指软件设计说明中一个可独立测试的元素，是程序中一个逻辑上独立的部分，它不能再分解为其他软件成分。

(实践中)软件单元指软件源代码中单个的函数，源文件或类。单元测试是什么？单元测试，对单个的软件单元或者一组相关的软件单元所进行的测试，是代码级的测试。Unit：函数，源代码文件，类把测试比作是清洗一台机器：系统测试就是清除机器外面的尘土。集成测试就是保证机器各个部件的接头处干净。单元测试就是清洗各个零件的内部。单元测试应用输入潜在错误对象单元测试测试一个类Thatiseasy!单元测试原则应该尽早地进行软件单元测试。应该保证单元测试的可重复性。尽可能地采用测试自动化的手段来支持单元测试活动。单元测试内容单元功能测试单元接口测试单元局部数据结构测试单元中重要的执行路径测试单元的各类错误处理路径测试单元边界条件测试单元测试内容开发测试设计评审代码走查单元测试集成测试面向单元的白盒测试（单元覆盖率测试）狭义的单元测试内容面向单元的黑盒测试（单元功能测试）内存和运行错误分析（内存泄漏、越界，异常）代码运行性能profile（函数效率和瓶颈分析）单元测试（who）单元测试可以是开发者本人执行，也可以是独立的专业测试人员执行。两者各有优势。建议开发人员必须完整地做单元测试，同时测试人员针对重点模块实施独立的单元测试。单元测试过程单元测试过程包括8个活动：确定单元测试计划确定待测特性制订单元测试规程设计测试套件构建测试套件执行测试套件检查终止条件评估测试结果确定单元测试计划

确定单元测试范围尽可能争取完全地覆盖（原则上应该做到完全覆盖）参考：通常以下情况必须安排单元测试：a）新模块b）新增代码比例超过20％c）核心模块确定单元测试计划

单元测试充分性要求例如：语句行覆盖率=100%；分支覆盖率〉85%测试覆盖率要求是测试充分性的一个方面，除此之外，在单元测试中还应考虑每个软件特性的测试覆盖，如函数性能。确定单元测试计划

确定终止条件确定单元测试过程的正常终止条件。该终止条件应该包括了对测试充分性要求的满足。（100%代码行覆盖，85%分支覆盖）识别可能造成单元测试过程异常终止的条件（如发现重大的设计错误、到达进度期限等）。确定单元测试计划确定单元测试资源估算进行测试活动所需的资源。应考虑测试人员、硬件、通信或系统软件、测试工具和其它资源。识别需要进行准备或申请的资源（如定制的测试工具），并做出相应的安排。指明总体进度计划基于资源和项目计划等方面的要求，确定单元测试活动的总体进度计划。确定待测特性

研究待测特性要从研究单元的需求开始功能需求、非功能需求（如性能或设计约束等）、与待测单元相关的任何使用或操作过程单元的状态识别针对状态机测试单元的数据特性识别单元的输入输出数据分析以上研究分析对于制定单元测试方案和指导测试用例的设计很重要待测特性分析过程中还有可能发现单元需求上的缺陷。制定单元测试规程

输入单元测试计划、待测特性分析结果、项目总体进度计划识别可重用技术（待查）通过待测特性分析，可从用例库中识别出可以重用的测试用例和测试规程，以减少重复工作。资源详细列举单元测试所需资源，包括人员、设备、工具、环境等，进度计划详细的进度计划，包括风险分析和应对措施规程评审设计测试套件

测试套件测试用例、脚本、驱动、桩、测试数据测试规程和测试用例的开发目前测试规程和测试用例是合一的。开发过程中在重用的基础上新增和修改。结合待测单元特性分析，充分考虑测试用例的覆盖率。测试工具的设计自研测试工具的设计要充分考虑可重用性，不同项目间通用性一般较小，统一项目不同版本间一定要具备通用性。测试规程/用例的评审单元测试数据单元测试设计中，测试数据的设计是很关键的，同样的测试规程，不同的测试数据，可能会达到不同的测试结果。a)正常数据：在测试中所用的正常数据的量是最大的，而且也是最关键的。少量的测试数据不能完全覆盖需求，但我们要从中提取出一些具有高度代表性的数据作为测试数据，以减少测试时间。b)边缘数据：边缘测试是界于正常数据和错误数据之间的一种数据。它可以针对某一种编程语言、编程环境或特定的数据库而专门设定。边缘数据要靠测试人员的丰富经验来制定。c)错误数据：显而易见，错误数据就是编写与程序输入规范不符的数据从而检测输入筛选、错误处理等程序的分支。构建测试套件测试数据的准备测试工具的开发/调试构建测试环境执行测试套件运行测试确定测试结果，处理测试过程中的异常对每个测试用例，确定单元是否通过测试。对异常进行分析，并根据情况处理：情况1：测试用例或测试数据的问题。修正并重新运行。情况2：测试规程执行的问题。重新运行。情况3：测试环境的问题。纠正测试环境并重新运行；或者异常终止测试，并汇报记录异常终止原因。情况4：单元实现中的故障。纠正单元的故障，并运行所有的测试；或者异常终止测试，并汇报记录异常终止原因。情况5：单元设计中的故障。纠正单元设计和实现中的故障，必要时修改测试设计和测试数据，并重新运行所有的测试。检查终止条件测试充分性检查检查是否达到覆盖率要求，包括测试用例执行/通过覆盖率和被测单元代码/分支覆盖率。以及其它测试充分性要求。异常终止条件检查补充测试套件以上条件不满足时，则需要补充测试套件，继续进行测试。评估测试结果按照单元测试报告模块出具单元测试报告如有必要对单元测试报告进行评审将所有测试相关工作产品纳入配置管理常见的单元测试的难点没有时间做单元测试单元测试责任人不清楚测试代码难以管理覆盖率难以手工统计故障报告形式驱动和桩编写困难（可测试性）对策：没有时间做单元测试单元测试计划在项目计划应该有体现。编写代码之前或同时，先设计测试用例。每个软件单元应该有什么功能？是否每个功能都有测试用例来验证它？对策：单元测试责任人不清楚强调单元测试必须由类包的设计者负责编写，因为只有这样，测试才能保证对象的运行时态行为符合需求。让测试人员或第三方人员编写测试用例，将花费更多的工作量。（20>>1）执行测试用例可以让测试人员或自动构造系统。对策：测试代码难以管理采用测试工具管理测试代码如XUnit、C++Test、RTRT配置管理中建立配置项如，不同模块的一组代码，建立相应测试代码目录和配置项对策：覆盖率难以手工统计利用各种工具PureCoverage(C/C++/Java/.Net,Windows/UNIX)RTRT(C/C++/Java/Ada,嵌入式系统)C++Test(C/C++,Windows/UNIX)Discover(Delphi,Windows)对策：故障报告形式各种工具一般都会生成测试报告XUnit测试用例执行报告RTRT、C++Test各种综合报告（测试用例执行结果、测试用例覆盖率、内存检查和性能）对策：驱动和桩编写困难通常情形下，测试驱动难以编写，测试难以进行由以下几方面原因导致：1、被测试对象需要传入的参数过多。2、内部的逻辑判断过多（内部牵扯复杂）。3、和界面显示部分交互过于频繁（耦合性太强）。4、被测对象过多的调用了其他类或方法。5、需要构造的作为参数的对象本身过于复杂解决：提高可测试性1、首先最重要的是坚持测试驱动设计（测试先于设计）的方法。优先编写测试代码。这是标准的XP方法。这不是说您应该一次性编写全部测试代码后，再一次性全部实现。对一些单元接口，编写一些测试代码，实现它们，再编写一些测试代码，再实现它们等等是个更好的办法。设计以这种方式得以进展；在实现阶段捕捉错误并在下一组测试中改正它。2、功能分解类：把功能分解到细粒度，提倡小类。方法：尽量做到每个操作对应一个方法，使方法小型化。功能分解促进：提高重用性，降低耦合度3、分层原则。对于显示部分（GUI），尽量做到显示与控制分离。把代码移到GUI视图的外面。然后各种GUI动作就能成了模型上的简单方法调用。这样，对GUI测试者来说，通过方法调用测试功能比间接地测试功能容易的多。另一个好处是它使修改程序功能而不影响视图变的更容易。解决：提高可测试性4、抽象我们可以想出各种各样的办法来降低耦合程度，但是归纳起来，不外乎增加抽象的层次来隔离不同的类，这个抽象层次可以是具体的类，也可以是接口。GOF的23种设计模式，没有一种模式的思路不是从增加抽象层次入手来解决问题的5、对于可能要作为参数的复杂类，可以做一个接口，用接口说明外部程序组件使得我们可以容易地在测试案例中模拟这些组件。当需要时可以实现按接口生成一个模拟类作为参数传入。特别是当该类还没有完全实现时，这种方法最为行之有效。解决：提高可测试性6、如果自己不负责测试工作，作为开发员在设计过程中要时刻提醒自己“我如何才能测试这些代码？我如何才能以可测试方式编写这些代码”。7、重构是提高可测试性的主要手段单元测试经验测试驱动开发，开发以测试为导向写不出测试用例，就谈不上编写单元代码开发一个单元的代码的步骤：1.设计和编写测试它的用例代码2.运行自动测试，检查是否发生错误3.编写单元的代码4.使用前面的用例回归测试它单元测试是编码的一部分！单元测试经验测试驱动开发编写单元测试用例促进解除模块之间的耦合。先编写测试用例，强迫自己从利于调用者的角度来设计单元，关注单元的接口。为了便于调用和独立测试，必须降低单元和周边环境的耦合程度，单元的可测试性得到加强，模块化程度得到提高。这样单元的可重用性也容易被考虑和提高。单元测试经验重构测试用例数量是逐步增加的，软件功能也在此过程中得到增强、更新和优化。当新的需求变化到来时，测试用例被增加或修改，难以适应测试用例的软件单元被重构。经常发生变化的测试用例和软件模块被重视和分离出来，进行重构和优化，使它们更加容易应付需求的变化。单元测试经验单元测试的执行要自动化。单元测试的工作产品纳入配置管理。议程测试过程回顾单元测试集成测试系统测试验收测试一个软件测试项目过程分析集成测试定义

定义集成测试又称“组装测试”、“联合测试”。集成测试遵循特定的策略和步骤将已经通过单元测试的各个软件单元（或模块）逐步组合在一起进行测试，以期望通过测试发现各软件单元接口之间存在的问题。集成测试对象理论上凡是两个单元（如函数单元）的组合测试都可以叫做集成测试。实际操作中，通常集成测试的对象为模块级的集成和子系统间的集成，其中子系统集成测试称为组件测试。集成测试在单元测试和系统测试间起到承上启下的作用既能发现大量单元测试阶段不易发现的接口类错误，又可以保证在进入系统测试前及早发现错误，减少损失。对系统而言，接口错误是最常见的错误单元测试通常是单人执行，而集成测试通常是多人执行或第三方执行。集成测试通过模块间的交互作用和不同人的理解和交流，更容易发现实现上、理解上的不一致和差错。集成测试（when)在开始体系结构设计的时候开始制定测试方案；在进入详细设计之前完成集成测试方案；在进入系统测试之前结束集成测试。集成测试（who)集成测试可以在开发部进行，也可以由独立的测试部执行。开发部尽量进行集成测试，测试部有选择地进行集成测试。集成测试原则集成测试是产品研发中的重要工作，需要为其分配足够的资源和时间。集成测试需要经过严密的计划，并严格按计划执行。应采取增量式的分步集成方式，逐步进行软件部件的集成和测试。应重视测试自动化技术的引入与应用，不断提高集成测试效率。应该注意测试用例的积累和管理，方便进行回归并进行测试用例补充。集成测试内容集成测试需要关注以下问题：穿越接口的数据是否会丢失一个模块的功能是否会对另一个模块的功能产生不利影响实现子功能的模块组合起来是否能够达到预期的总体功能全局数据结构的测试共享资源访问的测试单个模块的误差经过集成的累加效应集成测试内容集成功能测试接口测试全局数据结构测试资源测试任务优先级冲突测试性能和稳定性测试集成功能测试集成单元实现的功能，集成后的功能（合一），考察多个模块间的协作，既要满足集成后实现的复杂功能，也不能衍生出不需要的多余功能（错误功能）。主要关注：被测对象的各项功能是否实现；异常情况是否有相关的错误处理；模块间的协作是否高效合理。接口测试模块间的接口包括函数接口和消息接口:对函数接口的测试，应关注函数接口参数的类型和个数的一致性、输入/输出属性的一致性、范围的一致性。对消息接口的测试，应关注收发双方对消息参数的定义是否一致、消息和消息队列长度是否满足设计要求、消息的完整性如何、消息的内存是否在发送过程中被非法释放、有无对消息队列阻塞进行处理等。全局数据结构测试全局数据结构往往存在被非法修改的隐患，因此对全局数据结构的测试主要关注以下几个角度：

全局数据结构的值在两次被访问的间隔是可预知的；全局数据结构的各个数据段的内存不应被错误释放；多个全局数据结构间是否存在缓存越界；多个软件单元对全局数据结构的访问应采用锁保护机制。资源测试资源测试包括共享资源测试和资源极限测试。共享资源测试常应用于数据库测试和支撑的测试。共享资源测试需关注：是否存在死锁现象；是否存在过度利用情况；是否存在对共享资源的破坏性操作；公共资源访问锁机制是否完善。资源极限测试关注系统资源的极限使用情况以及软件对资源耗尽时的处理，保证软件系统在资源耗尽的情况下不会出现系统崩溃。性能测试某个部件的性能指标，及时发现性能瓶颈。多任务环境中，还需测试任务优先级的合理性，需考虑以下因素：实时性要求高的功能是否在高优先级任务中完成；任务优先级设计是否满足用户操作相应时间要求。稳定性测试稳定性关注是否存在内存泄漏而导致长期运行资源耗竭；长期运行后是否出现性能的明显下降；长期运行是否出现任务挂起集成测试方法非递增式集成测试所有软件模块单元测试后一次集成。优点：测试过程中基本不需要设计开发测试工具。不足：对于复杂系统，当出现问题时故障定位困难，和系统测试接近，难以体现和发挥集成测试的优势。递增式集成测试逐渐集成，由小到大，边集成边测试，测完一部分，再连接一部分。在复杂系统中，划分的软件单元较多，通常是不会一次集成的。软件集成的精细度取决于集成策略。通常的做法是先模块间的集成，再部件间的集成。优点：测试层次清晰，出现问题能够快速定位。缺点：需要开发测试驱动和桩。集成测试过程集成测试计划（策略、方案、进度计划）集成测试设计和开发（测试规程、测试工具开发）集成测试执行（构造环境、运行）集成测试评估集成测试计划集成测试策略制定集成方法、内容、范围、通过准则；工具考虑，复用分析；基于项目人力、设备、技术、市场要求等各方面决策。集成测试进度计划工作量估算、资源需求、进度安排、风险分析和应对措施。集成测试方案编制接口分析、测试项、测试特性分析。体现测试策略。如何确定集成的内容？考虑集成的层次考虑软件的层次考虑软件的复杂度和重要性权衡投入和产出集成测试设计和开发测试规程/测试用例的设计和开发确定的测试步骤、测试数据设计。测试工具、测试驱动和桩的开发集成测试执行搭建测试环境运行测试确定测试结果，处理测试过程中的异常执行阶段的度量集成测试对象的数量运行的用例数量通过/失败的用例数量发现的缺陷数量遗留的缺陷数量集成测试执行的工作量评估测试结果按照集成测试报告模块出具集成测试报告如有必要对集成测试报告进行评审将所有测试相关工作产品纳入配置管理集成测试经验集成测试活动必须纳入项目计划，并安排相应工作量；集成测试之前必须先做单元测试，而且单元测试对覆盖率应该有较高的要求；做好集成测试，良好的组织非常重要，需要指定一个好的集成测试组织者；集成测试需要及早考虑自动测试工具的开发。集成测试经验—每日构造NT的每日构造1994年的NT系统40，000个源文件5，600，000行代码多台机器上编译9个小时如果微软只能宣传它开发过程中的一种思想，那就是每日构造和冒烟测试。

-JimMcCarthy每日构造每日构造的意义使平行编码的众多程序员定期同步到产品发布的主线上来是开发过程健康状况的脉搏，是进度监控的基础是连接开发、测试和程序经理的重要纽带将彼此依赖的产品组件和部门连接到产品发布的主线上来提供理论上随时可以发布的版本，为重大产品决策提供宝贵的灵活性每日构造每日构造对于特大型项目是极大的挑战如果今天不可能装配成功，那么我们可能永远也无法装配成功Windows产品部门由一位副总裁级的工程师亲自指导一个小组构建每日构造环境程序员一次不小心的Check-in就可能导致每日装配的失败构造失败作为绝对最高优先级任务，必须立即予以修复对于百万行代码的中型项目，每日构造很容易操作每个程序员在Check-in之前保证编译成功在Check-in之前保证本机代码与代码库严格同步在生成代码集装配快照（snapshot）时保证没有Check-in发生每日构造的关键每天进行创建每天进行冒烟测试冒烟测试随着产品的增长而增长每日构造发现的问题作为最高优先级的任务在压力下不要放弃这个过程每日构造的过程开发人员提交代码编码规范检查自动编译和链接冒烟测试Break!系统泛指由一群有关连的个体组成，根据预先编排好的规则工作，能完成个别元件不能单独完成的工作的群体。

--源于网络议程测试过程回顾单元测试集成测试系统测试验收测试一个软件测试项目过程分析系统测试——验证还是确认？系统测试使用人工或自动手段来运行或测定某个系统的过程，其目的在于检验它是否满足规定的系统需求或是弄清预期结果与实际结果之间的差别。验证（Verification）验证确定工作产品正确反映了它们的规定需求。换言之，验证保证“你正确地构建了它”。确认（Validation）确认确定提供的产品将满足其预期使用。换言之，确认保证“你构建了正确的产品”。

——CMMI模型第3章系统测试主要内容功能测试恢复性测试（灾难测试、容错测试）敏感性测试安全性测试接口测试用户界面测试安装/升级测试配置测试/兼容性测试国际化（语言）测试用户文档测试性能测试强度测试容量测试可靠性测试边界测试冒烟测试回归测试随机测试硬件系统专有测试可靠性试验可生产性测试可维护性测试压力测试常称为强度测试，通常还包括极限性测试和敏感性测试等，用于测试系统对异常工作强度（包括过大的工作量、不充足的内存、不可用的服务/硬件或过低的共享资源等）情况下的处理能力。极限测试侧重于测试系统在内部和外部达到最大额定指标时能否正常工作敏感性测试侧重于测试系统在一些临界点条件下功能结果和性能表现是否产生突变。压力测试常用工具SmartBits等数据流量模拟发生器RationalTestManager、LoadRunner的VU(VirtualUsers)模拟测试脚本工具话音模拟呼叫器，等。常见故障在异常资源配置下容易产生系统崩溃或处理能力急剧下降、出错率急剧上升的现象达不到需求所要求的最高容量指标在允许的资源配置范围内存在某些临界点（特定输入或配置），在这些临界点系统的功能性能表现产生突变甚至系统发生崩溃。配置（兼容性）测试主要包括组网测试和软硬件平台配置测试组网测试的目的是测试系统是否满足其需求中所支持的所有组网类型和组网规模软硬件平台配置测试的目的是测试系统是否满足其需求中所支持的不同软硬件平台配置。兼容性测试是指系统的适应能力测试，可分为环境兼容测试和版本兼容测试。常见故障系统在采用需求中支持的某些组网方式时的功能或性能出现问题；系统在采用需求中支持的某些平台、软件配置方式时的功能或性能出现问题。安全测试安全测试就是检查系统对于外部的非法侵入的抵御能力。系统安全测试的准则是，测试非法侵入的代价是否超过被保护信息的价值。信息安全与保密（Security）不同于人身安全和重大财产损失（Safety）。在公司的产品研发中，需要重点考虑的是信息安全方面随着ISO14000/18000的实施，Safety方面的内容会增多主要方法：想方设法截取或破译口令；专门定做软件破坏系统的保护机制；故意导致系统失败，企图趁恢复之机非法进入；试图通过浏览非保密数据，推导所需信息，等。主要工具：协议分析仪、系统漏洞扫描软件，黑客工具等。常见故障系统缓冲区溢出、堆栈溢出错误。系统存在密码安全、权限管理、数据安全方面的漏洞，可被轻易的进入并进行非法获取和破坏。安全测试恢复性测试检查系统的容错能力，测试系统在遇到系统崩溃、硬件损坏或其他灾难性问题后能否很好地恢复，测试的具体内容包括创建各种可能的灾难状况，测试系统从异常状态恢复到正常状态所需的时间、花费的代价、对周边设备和系统造成的影响，系统恢复的完整性和一致性等。常用工具：主要是制造系统异常，按系统恢复功能进行恢复操作，直至系统继续正常运行为了测试系统恢复之后是否运行正常，也可以采用一些自化测试工具进行回归测试，以提高测试的效率。常见故障系统发生异常后无法恢复，造成系统数据被破坏，即重启系统、恢复备份数据也不可行，严重的可能造成系统硬件故障；系统恢复时间过长、代价过高；系统不能完全恢复到原来的正常状态，造成一定损失；系统恢复过程对周边设备和环境造成较大影响，无法消除，等。恢复性测试用户界面测试以用户的角度来对软件界面的易用性、风格、合理性等面进行评估和测试。通常包括软件的“界面显示测试”和“界面功能测试”，而界面功能测试主要结合系统功能进行测试。常用工具：Winrunner、Robot等录制回放工具测试要点和常见故障：易用性与合理性：步骤繁琐的操作，比例不协调、摆放凌乱的窗口和控件，层次过多的子窗口和菜单规范性：不符合Windows规范的控件设计，与常规Windows操作不符的流程与操作等容错性：编辑控件对非法字符、超出边界值的输入处理不当或没有提示，容易造成系统重启、数据删除丢失等的操作没有提示等帮助：无帮助信息提供，或者不提供获取帮助的快捷操作美观与风格：界面颜色不协调、界面风格与公司相关产品风格不符、与业界通用风格不符，图片、图标等不符合公司CI规范。资源：界面长时间运行操作造成系统内存耗尽、界面对系统资源独占使用等用户界面测试安装升级测试安装升级测试是以最终用户的角度测试系统的可安装性以及系统是否具有升级或卸载功能。安装升级测试，需要重点测试系统的软硬件平台的兼容性。主要内容：安装升级基本功能测试卸载测试(可选)平台兼容性易用性与合理性测试健壮性测试常用工具：通常手工进行。可借助录制回放工具进行反复的软件安装测试。常见故障：系统的软硬件不能兼容。系统软件在不同的平台下安装后不能正常工作。系统版本升级后，无法正常工作，系统无法回退到升级前的版本。系统的硬件安装不符合用户习惯。系统的软硬件安装升级过程和用户文档上的叙述不一致，甚至错误，误导最终用户。安装升级测试文档/帮助测试各种用户文档和联机帮助系统是软件产品的重要组成部分，保证其正确性也是软件测试工程师的职责。文档/帮助测试的目的在于：提高易用性，使软件用户更容易地学习和使用软件产品。提高可靠性，如果用户阅读文档，然后使用软件，最终得不到预期结果，这就是可靠性差。降低支持费用，好的文档/帮助通过恰当的解释和引导可以在用户有麻烦或者遇到意外情况时减少请求公司帮助。从用户的角度来测试软件文档是非常有效的方法。仔细阅读，跟随每个步骤，检查每个图形，尝试每个示例。利用这个现实的简单方法，可以找出软件和文档中的缺陷。常用的方法有：评审和审查，检查文档的编辑清晰性。动态测试，结合实际程序的使用而使用文档。让独立的第三方（如用户）或其他人员(如以前没有接触或使用过本系统的新手)在程序的使用语境测试文档也是十分有效的方法。文档/帮助测试文档/帮助测试的检查单示例文档是否精确描述了各种使用模式？每个交互顺序的描述是否精确？例子是否精确？术语、菜单描述和系统响应是否与实际应用程序一致？是否能够很方便地使用文档定位和排除错误？文档的内容和索引是否精确完整？文档的设计（布局、缩入和图形）是否便于信息的理解？显示给用户的错误信息是否有更详细的文档解释？如果使用超级链接，超级链接是否精确完整？如果使用超级链接，导航设计是否适合于所需要的信息？冒烟测试也称为构建验证测试（BVT，BuildVerificationTest）测试被测系统是否具有基本运行功能，如启动、加载、执行基本操作等。常与每日构建相结合，作为集成测试的一个重要部分在系统测试中用作入口检查通常需要自动化工具常见故障被测系统无法启动和加载；基本功能出现故障；自动化测试无法正确执行。回归（Regressive）测试对系统的新增功能和以前测试中已经测试过无故障的相关功能进行验证，以保证新增功能和/或对旧有故障的修改不会在被测系统中引入新的故障，其测试范围和规模介于完整测试和简单的故障验证测试之间。需要根据新增/修改功能的波及范围精心选择和设计测试范围与测试用例尽量采用自动化测试工具随机（Ad-hoc）测试俗称“猴子”测试最好由用户代表进行公司内部可结合新员工/工程/客服人员培训进行应该有适当的组织和计划项目周期中的系统测试阶段系统测试计划阶段系统测试设计和开发阶段系统测试执行和评估阶段系统测试计划阶段主要活动制定系统测试总体计划简述项目，明确测试的范围定义测试策略（阶段、类型、技术、标准等）编制测试需求工作分解和估算资源分配进度表风险识别与应对系统测试总体计划评审批准系统测试总体计划系统测试总体计划纳入配置管理系统测试设计和开发阶段系统测试方案设计测试方案评审系统测试规程设计建立需求跟踪矩阵系统测试规程评审系统测试用例细化和再开发系统测试用例评审测试工具的设计和研制系统测试设计和开发阶段常见风险不做测试设计，或测试过程并未系统测试总体计划的要求来做。测试设计不详细，不是基于可量度的测试策略，例如测试计划覆盖一个集合或者测试需求的一个子集。测试过程没有检验测试需求。测试开发没有依据，测试规程和用例与测试方案或系统测试总体计划中测试策略没有对应性。测试过程不可重复或不可重用。系统测试设计和开发阶段常用度量需求覆盖率（百分比）＝测试覆盖的需求/所有的需求×100%；测试用例的数量（条）；自动化测试在系统测试中的比例（百分比）＝采用自动化测试的系统测试用例数目/全部的测试用例总数×100%；测试用例设计和开发的工作量（人时）；测试工具研制的工作量（人时）；系统测试文档评审的工作量（人时）；系统测试执行和评估阶段系统测试申请系统测试申请审批制定系统测试详细计划执行系统测试准备系统测试执行系统测试总结和评估系统测试执行和评估阶段常见风险没有制定系统测试详细计划，测试开始之前测试人员不能明确本次系统测试活动应测试的测试用例。测试执行不按照系统测试详细计划的要求来做，不能确保计划要求的测试用例都能得到执行。未对测试的原始数据进行纪录。本次系统测试新的有效测试规程和测试用例并未及时给予纪录并管理。项目组和产品线的压力有可能导致测试人员的测试评估不够客观准确。没有有效利用各种自动化测试手段，手工测试太多。系统测试执行和评估阶段常用度量测试用例通过率（百分比）＝本次测试中通过的用例数/实际执行的用例数；测试用例覆盖率（百分比）＝本次测试中实际执行的用例数/计划执行的用例数；本次测试中测试通过的系统测试用例数目（条）；本次测试中测试不通过的系统测试用例数目（条）；发现的缺陷数目及缺陷等级（个数、级别）；已经解决的缺陷数目及缺陷等级（个数、级别）；遗留的缺陷数目及缺陷等级（个数、级别）；缺陷密度（分布图）；测试的工时（人时）；系统测试的需求覆盖率；系统测试经验应尽早地开始系统测试工作。充分注意测试中的缺陷密集现象，即对缺陷比较密集的部分进行重点测试；严格执行测试计划，排除测试的随意性。对测试过程和测试结果应进行评价，确保测试过程的有效性。妥善保存测试计划、测试用例、故障统计和最终分析报告，为维护提供方便。对于被测试系统要进行正常和异常两方面的测试。在系统测试计划中，要按照资源和项目的要求清晰地定义一个完整的退出准则，这是一