系统测试的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。
系统测试过程域是SPP模型的重要组成部分。本规范阐述了系统测试的规程，该规程的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出”、“完成准则”和“度量”均已定义。
一、介绍
系统测试流程如图1所示。由于系统测试的目的是验证最终软件系统满足产品需求并且遵循系统设计，所以当产品需求和系统设计文档完成之后，系统测试小组就可以提前开始制定测试计划和设计测试用例，而不必等到“实现与测试”阶段结束。这样可以提高系统测试的效率。
系统测试过程中发现的所有缺陷必须用统一的缺陷管理工具来管理，开发人员应当及时消除缺陷（改错）。
图1 系统测试流程图
项目经理设法组建富有成效的系统测试小组。系统测试小组的成员主要来源于：
·机构独立的测试小组（如果存在的话）。
·邀请其它项目的开发人员参与系统测试。
·本项目的部分开发人员。
·机构的质量保证人员。
系统测试小组应当根据项目的特征确定测试内容。一般地，系统测试的主要内容包括：
·功能测试。即测试软件系统的功能是否正确，其依据是需求文档，如《产品需求规格说明书》。由于正确性是软件最重要的质量因素，所以功能测试必不可少。
·健壮性测试。即测试软件系统在异常情况下能否正常运行的能力。健壮性有两层含义：一是容错能力，二是恢复能力。
·性能测试。即测试软件系统处理事务的速度，一是为了检验性能是否符合需求，二是为了得到某些性能数据供人们参考（例如用于宣传）。
·用户界面测试。重点是测试软件系统的易用性和视觉效果等。
·安全性（security）测试。是指测试软件系统防止非法入侵的能力。“安全”是相对而言的，一般地，如果黑客为非法入侵花费的代价（考虑时间、费用、危险等因素）高于得到的好处，那么这样的系统可以认为是安全的。
·安装与反安装测试。
系统测试过程域产生的主要文档有：
·《系统测试计划》，模板见 [SPP-TEMP-ST-PLAN]。
·《系统测试用例》，模板见 [SPP-TEMP-TEST-CASE]。
·《系统测试报告》，模板见 [SPP-TEMP-TEST-REPORT]。
·《缺陷管理报告》，由缺陷管理工具自动生成。
二、系统测试规程
1、目的
对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。
2、角色与职责
项目经理组建系统测试小组，并指定一名成员任测试组长。
系统测试小组各成员共同制定测试计划、设计测试用例、执行测试，并撰写相应的文档。测试组长管理上述事务。
开发人员及时消除测试人员发现的缺陷。
3、启动准则
产品需求和系统设计文档完成之后。
4、 输入
产品需求和系统设计文档
5、主要步骤
[Step1] 制定系统测试计划
系统测试小组各成员共同协商测试计划。测试组长按照指定的模板起草《系统测试计划》。该计划主要包括：
·测试范围（内容）
·测试方法
·测试环境与辅助工具
·测试完成准则
·人员与任务表
项目经理审批《系统测试计划》。该计划被批准后，转向[Step2]。
[Step2] 设计系统测试用例
·系统测试小组各成员依据《系统测试计划》和指定的模板，设计（撰写）《系统测试用例》。
·测试组长邀请开发人员和同行专家，对《系统测试用例》进行技术评审。该测试用例通过技术评审后，转向[Step3]。
[Step3] 执行系统测试
·系统测试小组各成员依据《系统测试计划》和《系统测试用例》执行系统测试。
·将测试结果记录在《系统测试报告》中，用“缺陷管理工具”来管理所发现的缺陷，并及时通报给开发人员。
[Step4] 缺陷管理与改错
·从[Step1]至[Step3]，任何人发现软件系统中的缺陷时都必须使用指定的“缺陷管理工具”。该工具将记录所有缺陷的状态信息，并可以自动产生《缺陷管理报告》。
·开发人员及时消除已经发现的缺陷。
·开发人员消除缺陷之后应当马上进行回归测试，以确保不会引入新的缺陷。
6、输出
·消除了缺陷的最终软件系统
·系统测试用例
·系统测试报告
·缺陷管理报告
7、结束准则
对于非严格系统可以采用“基于测试用例”的准则：
·功能性测试用例通过率达到100％；
·非功能性测试用例通过率达到80％时。
对于严格系统，应当补充“基于缺陷密度”的规则：
·相邻n个CPU小时内“测试期缺陷密度”全部低于某个值m。例如n大于10，m小于等于1。
本规程所有文档已经完成。
8、度量
测试人员和开发人员统计测试和改错的工作量，文档的规模，以及缺陷的个数与类型，并将此度量数据汇报给项目经理。
三、 实施建议
对系统测试人员进行必要的培训，提高他们的测试效率。
项目经理和测试小组根据项目的资源、时间等限制因素，设法合理地减少测试的工作量，例如减少“冗余或无效”的测试。
系统测试小组根据产品的特征，可以适当地修改本规范的各种文档模板。
对系统测试过程中产生的所有代码和有价值的文档进行配置管理。
为了调动测试者的积极性，建议企业或项目设立奖励机制，例如：根据缺陷的危害程度把奖金分等级，每个新缺陷对应一份奖金，把奖金发给第一个发现该缺陷的人。
四、系统测试的目标
1、 确保系统测试的活动是按计划进行的；
2、 验证软件产品是否与系统需求用例不相符合或与之矛盾；
3、 建立完善的系统测试缺陷记录跟踪库；
4、 确保软件系统测试活动及其结果及时通知相关小组和个人；
五、系统测试的方针
1、 为项目指定一个测试工程师负责贯彻和执行系统测试活动；
2、 测试组向各事业部总经理/项目经理报告系统测试的执行状况；
3、 系统测试活动遵循文档化的标准和过程；
4、 向外部用户提供经系统测试验收通过的预部署及技术支持；
5、 建立相应项目的（BUG）缺陷库，用于系统测试阶段项目不同生命周期的缺陷记录和缺陷状态跟踪；
6、 定期的对系统测试活动及结果进行评估，向各事业部经理/项目办总监/项目经理汇报/提供项目的产品质量信息及数据；
六、系统测试的过程
1、 软件项目立项，软件项目负责人将项目启动情况通报给测试组长，测试组长指定测试工程师对该项目进行系统测试跟进和执行。
2、 测试工程师首先参与前期的需求分析活动、前景评审、业务培训、SRS评审。目的是了解系统业务及范围、了解软件需求及范围，验证需求可测性。并将所有收集到的测试需求汇总并输出到《测试需求管理表》中。
3、 测试工程师根据测试需求定义测试策略，并进行工作量估计。
4、 测试工程师根据测试需求制定测试策略和方法；系统测试工程师参与项目计划和SDP评审，依据项目计划（或周计划）,编制《系统测试计划》。
5、 测试组长周期性地根据事业部项目的测试情况，进行总体测试工作量估计并进行测试任务分派。
6、 测试工程师组织《系统测试计划》评审，测试组长根据评审意见审批《系统测试计划》。
7、 测试工程师根据《系统测试计划》中的测试环境要求搭建测试环境。特别技术要求的需要项目组及其它相关职能部门的配合。
8、 测试工程师检查测试设计入口条件；根据《用例规约》、《补充规约》、《界面原型》、《词汇表》进行测试用例设计。
9、 测试工程师组织《系统测试用例》评审，测试组长根据评审意见审批《系统测试用例》。
10、 测试工程师定义系统测试用例执行过程，并更新《系统测试用例》。
11、 测试工程师检查测试执行入口条件，从受控库获取测试版本，执行系统测试并记录 测试结果。
12、 系统测试进入产品稳定期，由测试工程师召开缺陷评审会议；测试工程师对整个系统测试过程进行总结和评价，形成《软件缺陷清单》、《系统测试评估摘要》《系统测试总结报告》，并将系统测试过程的文档报送给项目组和测试组长。测试组长每月初或（事件驱动）汇总、整编上月的《产品质量简报》，报送给事业部总经理和项目办。
13、 如果根据系统测试结果，产品得以批准通过，系统测试工程师卸载被测软件，进行环境初始化，系统测试结束，转入验收测试阶段；否则视批示意见进行。
因为软件测试的工作量很大（ 40% 到 60% 的总开发时间），而又有很大部分适于自动化，因此，测试的改进会对整个开发工作的质量、成本和周期带来非常显著的效果。
首先，谈谈在测试自动化的情况下，带有图形界面的产品的测试用例的设计问题。因为图形界面的输出显示不是很容易做到测试结果自动化比较，所以一般的做法是把图形界面输出的部分单独建立测试用例，以手工运行。而所有非图形输出则可进行自动测试。
下面举出一些测试自动化的例子：
1. 测试个案（ test case ，或称为测试用例）的生成
用编程语言或更方便的剧本语言（ script language 例如 Perl 等）写出短小的程序来产生大量的测试输入（包括输入数据与操作指令）。或同时也按一定的逻辑规律产生标准输出。输入与输出的文件名字按规定进行配对，以便控制自动化测试及结果核对的程序易于操作。
这里提到测试个案的命名问题，如果在项目的文档设计中作统一规划的话，软件产品的需求与功能的命名就应该成为后继开发过程的中间产品的命名分类依据。这样，就会为文档管理和配置管理带来很大的方便，使整个产品的开发过程变得更有条理，更符合逻辑。任何新手半途加入到开发工作中也会更容易进入状态。
2. 测试的执行写控制
单元测试或集成测试可能多用单机运行。但对于系统测试或回归测试，就极有可能需要多台机在网络上同时运行。记住一个这样的原则，在开发过程中的任何时候，如果你需要等候测试的运行结果的话，那就是一个缩短开发时间的机会。
对于单个的测试运行，挖潜的机会在测试的设置及开始运行和结果的对比及显示。有时候，需要反复修改程序，重新汇编和重新测试。这样，每一个循环的各种手工键入的设置与指令所花费的时间，加起来就非常可观。如果能利用 make 或类似的软件工具来帮助，就能节省大量的时间。
对于系统测试或回归测试这类涉及大量测试个案运行的情况，挖潜的的机会除了利用软件工具来实现自动化之外，就是怎样充分利用一切硬件资源。往往，就算是在白天的工作时间内，每台计算机的负荷都没有被充分利用。能够把大量测试个案分配到各台机器上去同时运行，就能节省大量的时间。另外，把大量的系统测试及回归测试安排到夜间及周末运行，更能提高效率。
如果不购买商品化的工具的话，应当遵从正规的软件开发要求来开发出好的软件测试自动化工具。在实践中，许多企业自行开发的自动化工具都是利用一些现成的软件工具再加上自己写的程序而组成的。这些自己开发的工具完全是为本企业量身定做的，因此可用性非常强。同时，也能根据需要随时进行改进，而不必受制于人。当然，这就要求有一定的人力的投入。
在设计软件自动测试工具的时候，路径（ path ）控制是一个非常重要的功能。理想的使用情况是：这个工具可以在任何一个路径位置上运行，可以到任何路径位置去取得测试用例，同时也可以把测试的结果输出放到任何的路径位置上去。这样的设计，可以使不同的测试运行能够使用同一组测试用例而不至于互相干扰，也可以灵活使用硬盘的空间，并且使备份保存工作易于控制。
同时，软件自动测试工具必须能够有办法方便地选择测试用例库中的全部或部分来运行，也必须能够自由地选择被测试的产品或中间产品采作为测试对象。
软件测试的重要环节：Bug管理流程
什么是迭代
引入
改进——人总是要犯错误的
敏捷——迭代式开发增加了开发过程的敏捷性
节奏——将总体进度划分为一系列长度为1-3周的小的迭代过程。迭代周期固定且一致，成为项目的“心跳” 。
什么是迭代
重复——一天又一天，一年又一年
概念
在软件开发中，迭代是对一连串的软件产品的持续集成，每个过程和产品都对上一个过程和产品有所改善，在软件 开发的生命周期里，迭代成为了一组明确的活动，是对开发的基准计划和评价准则的持续改进。因此，在软件开发中迭代开发可以持续地发布在系统体系结构的可执 行的软件版本。
迭代开发的特点
回归测试
按功能计划
演进式的设计
持续集成
迭代方法的益处
与传统的瀑布式方法相比，迭代过程具有以下的优点：
减小了风险
更容易对变更进行控制
项目小组可以在开发中学习
较佳的总体质量
集成
概念
将所有模块按设计要求组装成系统
任何团队开发的系统都有集成
集成
集成噩梦
集成过程很长
集成质量很差
日/夜创建(Daily/Nightly Build)
自动创建
一般在晚上
持续集成
完全自动化的创建
从代码库的原代码到最终产品(Exe, 光盘， 发布到Web)
持续
将软件过程末期的软件集成分摊到软件的全过程
由于间隔的时间很短，集成中出现的问题可以很轻易的发现
提高软件质量
工具
版本控制工具
Subversion
CVS
…
Build工具
自动测试工具
持续集成工具
如果你想创建一个只包含一个源程序文件的简单程序，那么你只需要编译、连接那一个文件就可以了。如果是一个团队项目组，有着许多甚至上千个源程序文件，那么要创建一个可执行程序的过程就变得更复杂、更耗时。你必须用各种各样的组件将程序逐步建立起来。
在微软或其它一些软件公司中惯例是：每日构造并做“冒烟测试”。每天都对已完成的源程序进行编译，然后连接组合成可执行的程序，并做“冒烟测试”，以简单的检查该执行程序在运行时是否会“冒烟”。
带来的好处
虽然这是一个非常简单的过程，但却有非常重要的意义：
1、能最小化集成风险
项目组可能遇到的一个很大的风险是，项目组成员根据不同的系统功能各自开发不同的代码，但是当这些代码集成为一个系统的时候，也许系统完成不了预期的功能。这种风险的发生取决于项目中的这种不兼容性多久才被发现，由于程序界面已经发生了变化，或者系统的主要部分已经被重新设计和重新实现了，相应的排错工作将非常困难和耗时。极端情况下，集成的错误可能回导致项目被取消掉。每日构造和冒烟测试可以使这种集成错误变得非常小，而且便于解决，防止了很多集成问题的产生。
2、能减小产品低质量的风险
这种风险是和集成不成功、集成出错相关联的。每天对集成的代码做一些少量的冒烟测试，即可杜绝项目中那些基本的质量问题。通过这种方式，使系统达到一种周知的良好状态，维护这样的系统可以防止系统逐步恶化到耗费大量时间排查质量问题的地步。
3、能简单化错误诊断
当系统每天都进行build和测试时，系统任何一天发生的错误都能够变得十分精细，便于排查。比如在17日系统患3把滩馐浴保 约虻サ募觳楦弥葱谐绦蛟谠诵惺笔欠窕帷懊把獭薄?
进行每日构造和冒烟测试
虽然说这是一个简单枯燥的活，每天进行build，每天进行测试，但也有着一些值得注意的细节：
1、每天坚持
每日构造，最重要的就是“每日”。如Jim McCarthy所说，把每日构造看作是项目的“心跳”，没有“心跳”的话，项目也就死了(Dynamics of Software Development, Microsoft Press, 1995)。Michael Cusumano and Richard W. Selby描述了另外一种隐含的比喻，把每日构造比作项目的“同步脉冲”(Microsoft Secrets, The Free Press, 1995)。 不同开发人员写的代码在他们的“脉冲”之间肯定都会存在“同步”的差异，但是必须有这样一个“同步脉冲”，使得这些代码能够组合为一个整体。当项目组坚持每天把这些不同的“脉冲”组合到一起的时候，开发人员脱离整体的情况就会得到极大程度的杜绝。
有些项目组把这一过程简化为“每周build一次”。这样带来的问题是，某一次build失败后，可能要回溯好几周才能找到原因。如果这种情况发生的话，已经得不到经常build带来的好处了。
2、严格检查每一次build
要保证每一次build的成功，就必须保证build后的结果（也可称为build）是可以正常运行的，如果build不可运行，那么本次build被认为是不成功的，同时应该将修复此次build的工作提高到项目组最高级别来处理。
对于如何衡量一个build，每一个项目组都会定义一些自己的标准，这些标准需要设定一个严格的质量级别来处理那些特别严重的缺陷，同时也需要具有一定的伸缩性来忽略掉那些微不足道的缺陷，一些不适当的关心也许会使整个过程举步为艰。
一个好的build起码应该具备以下条件：
●能够成功编译所有的文件、库，以及其它相关组件；
●能够成功链接所有的文件、库，以及其它相关组件；
●不能存在任何使得系统无法运行或者运行出错的高级别故障；
●当然，必须通过冒烟测试
3、每天进行冒烟测试
冒烟测试应该是对整个系统流程从输入到输出的完整测试。测试不必是面面俱到的，但是应该能够发现系统中较大的问题。冒烟测试应该是足够充分的，通过了冒烟测试的build就可以认为是经过充分测试、足够稳定的。
不进行冒烟测试的build是没有太大价值的。冒烟测试就像一个哨兵，在阻止着产品质量恶化和集成问题的产生，不进行冒烟测试，每日构造可能会变成浪费时间的练习。
冒烟测试必须随着系统的扩充而扩充。最初，冒烟测试可能是非常简单的，比如验证系统是否会打印“Hello World”，随着系统功能的扩充，冒烟测试需要越来越充分。最初的冒烟测试也许只需要几秒钟来执行，逐渐地，测试可能会花费30分钟，1小时，甚至更长。
4、建立一个专门的build小组
在很多项目组，维护每日构造，并更新冒烟测试用例，会耗费一个人工作的大部分时间。因此在一些大的项目中，这项工作独立成不止一个人来完成的全职工作。比如在 Windows NT 3.0的研发中，就有一个由四个全职人员组成的专门的build小组(Pascal Zachary, Showstopper!, The Free Press, 1994)。
5、为build增加修订，如果这样做有意义的话
一般开发人员不会每天都经常向系统中快速的增加实际的代码，通常是每隔几天，他们在开发好完成某个功能的一套代码以后，然后集成到整个系统中。
6、规定一些导致build失败的惩罚措施
很多执行每日构造的项目组都会规定一些惩罚措施，来惩罚那些导致build失败的行为。从最开始，项目组成员就清楚的知道，build的正常执行是项目组的头等大事。一个失败的build是项目组的意外，无法成为项目组工作的准则。必须坚持：导致build失败的同事，必须停下手中的工作，首先来解决build失败的问题。如果一个项目组的build经常失败的话，久而久之的，再来谈build的正确性就没有意义了。
有种轻松的惩罚措施，能够突出解决问题的优先性。Some groups give out lollipops to each "sucker" who breaks the build. This developer then has to tape the sucker to his office door until he fixes the problem. 有些项目组会惩罚犯错的同事戴上山羊角，或者向一个项目基金捐献5块钱。
有些项目组对此的惩罚就有点残酷了。微软的开发人员，在一些知名度很高、很重要的产品如Windows NT，Windows 95，Excel等产品后期研发中，被要求随时带着寻呼机，如果你的代码导致build失败的话，即使是凌晨3点钟，也会要求你立即来处理这个问题。
7、即使在压力下也需坚持每日构造和冒烟测试
当项目进度的压力越来越大时，维护每日构造的工作看起来有些浪费时间，但是恰恰相反。在压力之下，开发人员丢掉一些平时的规定，会采用一些设计和实现的捷径，这在平时压力较小的环境下一般时不会用的。代码的review和单元测试也可能会比平时粗心一些，这些代码的状态变化也会比平时快很多。
为防止这种情况的出现，每日构造会坚持相关的规定，让压力下的项目保持在正轨上。代码仍然每天在不断变化，但是构造过程使得这种变化每天都可控。
谁能够从每日构造这种过程中得到好处呢？一些开发人员会抗议说，由于他们的项目太大，每天进行build是没有实际意义的。但是为什么现在最复杂的软件项目组却能够成功的执行每日构造的制度呢？本文首发时，Windows NT包括了560万行代码、分布在4万个源程序文件中，项目组仍然可以坚持每日构造。
iampole推荐[ 2005-3-4 ]
出处：来自网上
作者：不详
软件测试的主要目的在于发现软件存在的错误(Bug)，对于如何处理测试中发现的错误，
将直接影响到测试的效果。只有正确、迅速、准确地处理这些错误，才能消除软件错误，保证
要发布的软件符合需求设计的目标。在实际软件测试过程中，对于每个Bug都要经过测试、确
认、修复、验证等的管理过程，这是软件测试的重要环节。
错误跟踪管理系统
为了正确跟踪每个软件错误的处理过程，通常将软件测试发现的每个错误作为一条条记录
输入制定的错误跟踪管理系统。
目前已有的缺陷跟踪管理软件包括Compuware公司的TrackRecord软件（商业软件）、
Mozilla公司的Buzilla软件（免费软件），以及国内的微创公司的BMS软件，这些软件在功能
上各有特点，可以根据实际情况选用。当然，也可以自己开发缺陷跟踪软件，例如基于Notes
或是ClearQuese开发缺陷跟踪管理软件。
作为一个缺陷跟踪管理系统，需要正确设计每个错误的包含信息的字段内容和记录错误的
处理信息的全部内容。字段内容可能包括测试软件名称，测试版本号，测试人名称，测试事
件，测试软件和硬件配置环境，发现软件错误的类型，错误的严重等级，详细步骤，必要的附
图，测试注释。处理信息包括处理者姓名，处理时间，处理步骤，错误记录的当前状态。
正确的数据库权限管理是错误跟踪管理系统的重要考虑要素，一般要保证对于添加的错误
不能从数据库中删除。
软件错误的状态
新信息(New)：测试中新报告的软件缺陷；
打开 (Open)：被确认并分配给相关开发人员处理；
修正(Fixed)：开发人员已完成修正，等待测试人员验证；
拒绝(Declined):拒绝修改缺陷；
延期(Deferred): 不在当前版本修复的错误，下一版修复
关闭(Closed)：错误已被修复；
Bug管理的一般流程
测试人员提交新的Bug入库，错误状态为New。
高级测试人员验证错误，如果确认是错误，分配给相应的开发人员，设置状态为Open。如
果不是错误，则拒绝，设置为Declined状态。
开发人员查询状态为Open的Bug，如果不是错误，则置状态为Declined；如果是Bug则修复
并置状态为Fixed。不能解决的Bug，要留下文字说明及保持Bug为Open状态。
对于不能解决和延期解决的Bug，不能由开发人员自己决定，一般要通过某种会议（评审
会）通过才能认可。
测试人员查询状态为Fixed的Bug，然后验证Bug是否已解决，如解决置Bug的状态为
Closed，如没有解决置状态为Reopen。
软件错误流程管理要点
为了保证错误的正确性，需要有丰富测试经验的测试人员验证发现的错误是否是真正的错
误，书写的测试步骤是否准确，可以重复。
每次对错误的处理都要保留处理信息，包括处理姓名，时间，处理方法，处理意见，Bug
状态。
拒绝或延期错误不能由程序员单方面决定，应该由项目经理，测试经理和设计经理共同决
定。
错误修复后必须由报告错误的测试人员验证后，确认已经修复，才能关闭错误。
加强测试人员与程序员的交流，对于某些不能重复的错误，可以请测试人员补充详细的测
试步骤和方法，以及必要的测试用例。
2719
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
