ST测试

来外包公司也已经快半年了，一直是在维护的。老是听开发的说什么ST和UAT一直很困惑，今天百度下，还是有所收获的。

ST系统测试

定义
　　系统测试（System Test,ST）是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。系统测试（System Test,ST）的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。
　　系统测试过程域是SPP模型的重要组成部分。本规范阐述了系统测试的规程，该规程的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出”、“完成准则”和“度量”均已定义。


介绍
　　系统测试流程如图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、 如果根据系统测试结果，产品得以批准通过，系统测试工程师卸载被测软件，进行环境初始化，系统测试结束，转入验收测试阶段；否则视批示意见进行。

境初始化，系统测试结束，转入验收测试阶段；否则视批示意见进行。