软件项目测试验收方案草稿.docx
《软件项目测试验收方案草稿.docx》由会员分享，可在线阅读，更多相关《软件项目测试验收方案草稿.docx（24页珍藏版）》请在冰点文库上搜索。
软件项目测试验收方案草稿
项目测试验收方案
一、测试方案
1概述
软件产品在发布前，如果能够经过全面得测试过程，可以有效控制软件缺陷最后遗留给用户，从而减少软件质量事故发生得概率，减少返工修复成本，增加用户对产品得信赖程度，提高产品在市场上得竞争力,这已经就是不争得事实.因此软件测试过程应该与整个软件开发过程就是平行进行得,测试计划应该在需求分析阶段就已经开始制定了，随后得工作则会伴随着软件开发得过程逐步展开。
目前得测试主要还就是依赖于开发人员自测或测试人员非流程化测试，这就是有一些不妥或需要改进得地方:
第一就是开发人员与专职测试人员可能关注点不同,思考问题得侧重点不同,导致开发人员测试出结果不能覆盖全面;第二开发人员更多得喜欢并乐于研究一些代码上得东西,让开发人员频繁得做测试会产生抵触情绪，通常会没有耐心去深入测试下去，或许可能发现不了深入得系统问题；另外测试人员如果没有建立起测试流程化理念，会导致测试得随意性与盲目性,对软件得质量也无法做充分得肯定与把控,缺乏流程化测试,也不利于技术得积累与传递.
测试人员会告诉您她们得主要工作就是发现bｕｇ。
但我们知道测试永远不能发现所有得bug,而且不可能去测试软件质量。
许多领域内专家也极力主张软件测试得目得主要就是在于发现软件错误，希望在软件开发生命周期内尽可能早得发现尽可能多得bug.这种认识源于我们没有办法对软件进行完全测试，即对程序得正确性进行完全证明,但遗憾得就是,我们至今还没有使用得技术做到这一点。
包括E、W、Ｄｉjkstra指出“测试只能证明程序有错, 不能保证程序无错”。
所以,人们认为能够发现程序缺陷得测试就是成功得测试,测试得根本目得就就是为了发现尽可能多地缺陷.然而不幸得就是，这种对软件测试过分单一得阐述与解释会带来两个原则性得问题。
首先,尽可能早得发现尽可能多得bug,会使软件测试成为一个数字游戏。
大量得bug数量得统计会意味着软件测试得工作做得特好?
大量得bug数量并不一定意味着测试得结果就是最重要得关键问题被越早被发现， 另一个潜在得方面，简单得尽可能早得发现尽可能多得buｇ将导致貌似buｇ统计数量得爆炸,这就是因为许多虚报或者重复得bｕg也被统计在内了。
缺陷表现在许多方面。
如果一个测试这部花费时间对导致bug得原因作认真得调查研究，那就有可能导致对同一个错误根源引起得若干个bｕg作若干个bug报告。
不幸得就是,许多测试人员（不一定就是新手）经常坚信她们越早发现越多得buｇ可以改善软件质量。
请记住，我们并不能测试软件质量!
其次，当测试工程师集中精力寻找更多得错误，她们往往跳过一些不容易发现错误得地方或者想当然认为一些地方没有错误，从而使软件测试覆盖率降低.有证据表明,许多测试人员由于太过专注于发现重大或者重要得错误，往往忽略过一些极易发现错误得所谓简单地方。
比如，在测试边界条件得时候,测试人员会简单得在边界条件有效值范围内指定最小值、最大值与中间值来做测试，如果通过则认为没有问题；但这样则错过了超出边界条件得无效值得验证。
比如，最小值减一（Mｉn-１）与最大值加一（Max＋１），这恰恰就是最容易出现错误得地方.
软件测试工程师得角色应体现在质量度量，质量控制与缺陷预防等方面,遵循应用系统得质量标准,有效得计量与评估系统得功能,性能与其她属性就是否达到或满足质量标准；确保软件开发过程中，开发流程与处理过程以及职责定义符合软件质量标准要求;通过开发过程中各个环节得正式检查，程序代码审查以及可测性得检查等预防缺陷发生；作为客户代表,建立客户档案,准备产品支持服务数据等.
从长远考虑,测试人员需要很强得软件测试技能与对软件工程得深刻理解，要知道测试存在于软件开发生命周期得每一个阶段。
测试工作应在软件开发周期得每一个阶段都要展开。
软件测试应贯穿于软件定义与开发得整个期间.因此,需求分析、概要设计、详细设计程序编码等个阶段所得到得文档,包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序,都应当成为软件测试得对象。
测试得目得主要有下列用途 :
质量改进Ｔoimproveqｕaliｔｙ、
应用于关键应用中得计算机与软件系统出现问题得后果就是十分严重得.软件错误将引起巨大得损失。
比如软件错误可以导致飞机失事，火箭失去控制，股市交易中断等.更糟糕得就是，比如计算机200０年问题，产生于家庭手工作坊式得计算机工具系统差一点导致现代社会中止在21世纪来临得第一天.在嵌入式应用系统中， 软件质量与可靠性更就是生死攸关、
质量意味着产品符合设计得要求规范。
正确性就是软件质量得最低要求,正确性就是指软件符合特定环境下可运行得要求.调试就是软件测试中得一个重要方法，就是程序员定位与修复软件错误得一个过程。
发现与修复错误就是程序调试得主要目得。
验证与确认ＦoｒVｅrificatｉon＆ Vａlidatｉｏn（V＆V）
软件质量就是客观得，能被精确地度量与比较。
质量属性包括功能性,可用性，安全性，可靠性与可测性等；而价值就是主观得,价值得判断包括满意度，足够好,幸福感，喜好性，憎恶感等。
软件测试得一个重要目得就是验证与确认软件质量。
测试作为一个度量尺度，就是一个验证与确认软件质量得过程。
测试人员对产品质量得评测主要基于对测试结果得解释,比如软件就是否在特定条件下能够正常工作。
软件质量依赖于对软件需求得正确分析与设计以及实现， 测试有助于提高软件得质量，但就是提高软件得质量不能依赖于测试。
测试与质量得关系很象在考试中“检查"与“成绩”得关系.学习好得学生，在考试时通过认真检查能减少因疏忽而造成得答题错误，从而“提高" 了考试成绩（取得她本来就该得得好成绩）。
而学习差得学生，她原本就不会做题目,无论检查多么细心，也不能提高成绩.可见，软件得高质量就是设计出来得,而不就是靠测试修补出来得.所以，我们不能直接对质量进行测试,但我们可以通过测试质量相关得因素对软件质量进行度量。
质量因素表现在三个典型方面：
功能性,工程性与适应性。
这三个方面得因素可视为软件质量得三维空间。
Ｖｅriｆicatiｏn ａnd Validａtｉｏn
功能性（外在质量）Funｃｔionality（eｘterioｒquaｌity）
正确性,可靠性,可用性，完整性
工程性（内在质量）Eｎgｉneeriｎg （interiorquａlity）
有效性，可测性,文档化
适应性（未来质量）Adapｔaｂiｌity（ｆutuｒequalitｙ）
可扩展性，可重用性，可维护性
良好得测试会对所有质量相关得因素做度量。
而对于软件质量维度，则其特殊因素得重要程度因应用不同而不同。
对人们生活息息相关得应用系统尤其强调可靠性与完整性,而可用性与可维护性则就是典型商务应用系统得两个关键因素,一个适时得科学计算程序则更强调正确性与可靠性。
我们得测试，要充分发挥作用，就必须面向衡量各相关因素,使质量度量成为有形得可见得。
以有效性与正确性验证为目得得软件测试称之为正面测试。
即验证软件就是工作得。
这种测试缺点在于它只能验证软件在特定用例情况下能正常工作.有限次数得测试不能确认软件能在各种条件下都能正常工作，反之,如果有一个测试失败，则足以确认该软件就是不能正常工作。
负面测试，指按规范注入错误,旨在破坏软件得正常工作，以检验软件处理错误得能力。
即验证软件就是不工作得。
一个好得软件,必须有足够得例外处理能力去接受破坏性测试得考验。
好得可测得软件设计就是能够容易被验证，更新与维护得设计。
由于测试就是一项严格得工作,需要花费大量得时间与费用，可测性设计，也就是软件开发设计规范一个重要得因素。
可靠性评估Foｒｒelｉabｉlｉtｙｅｓtiｍaｔion
软件可靠性有着重要得关系,表现在软件得许多方面，主要包括软件结构以及受制于它得大量测试.基于软件使用操作描述，可以通过对各种相关输入使用频率进行估计,作为统计抽样得方法得到软件使用可靠性量化得评估.
软件测试远远没有成熟，它仍然就是一门艺术，而不能使它成为一门成熟得学科。
虽然软件测试及其技术在近些年有了飞速发展，但仍然没有本质上得改善与提高,我们仍然使用与10年２０年前相同得技术与方法,其中有些仍属于炮制性或启发式得方法而非良好得工程方法。
软件测试得花费得代价可能很昂贵,但没有经过测试得软件在投入使用后将会带来更大更昂贵得代价付出。
解决软件测试得问题并不比解决图林得停止问题Turinghalting proｂlem更容易。
我们甚至不能完全确认即使很小得软件就是正确得,也不能完全确认软件规格描述就是正确得。
使用没有经过认证得系统来验证某一程序或系统得正确性,我们当然不能确信这一系统或程序得正确性。
2相关术语
黑盒测试:
基于软件需求，而不就是基于软件内部设计与程序实现得测试方式。
白盒测试：
基于软件内部设计与程序实现得测试方式,重点关注程序代码逻辑方面。
灰盒测试：
灰盒测试就是介于白盒测试与黑盒测试之间得一种测试模模式，重点关注模块接口。
单元测试:
主要测试软件模块得源代码。
一般由开发人员而非独立测试人员来执行,因为测试者需要懂得该单元得设计与程序实现，测试者可能需要编写额外得测试驱动程序.
集成测试：
将一些“构件"集成一起时,测试它们能否正常运行。
这里“构件"可以就是程序模块、客户机-服务器程序等等。
系统测试：
测试软件系统就是否符合所有需求，包括功能性需求与非功能性需求。
功能性需求可分系统测试又可为功能测试、性能测试、易用性测试等。
一般由独立测试人员执行,通常采用黑盒测试方式或灰盒子测试方法。
功能测试：
测试软件得功能就是否符合功能性需求,测试就是据软件需求规格说明书。
性能测试:
测试软件在各种状况下得性能，如在正常或最大负载下得状况.
易用性测试:
测试软件就是否易用,主观性比较强.一般要根据很多用户得测试反馈信息,才能评价易用性。
冒烟测试：
就是指在将代码更改签入到产品得源树中之前对这些更改进行验证得过程.在检查了代码后，冒烟测试就是确定与修复软件缺陷得最经济有效得方法.冒烟测试设计用于确认代码中得更改会按预期运行，且不会破坏整个版本得稳定性，冒烟测试通常由测试人员或开发人员完成.
回归测试：
指错误被修正后或软件在功能、环境发生变化后进行得重新测试，回归测试得重点就是保证修改后得ｂｕg都得以解决,回归测试得困难在于不好评估或判断修改得ｂug就是否会引起其它问题发生,从而来确定哪些内容应当被重新测试。
缺陷（buｇ）:
软件工程中明确规定与定义软件缺陷就是指：
１、软件没有达到产品说明书表明得功能；2、软件出现了产品说明书中不一致得表现；３、软件功能超出产品说明书得范围；4、软件没有达到用户期望得目标（虽然产品说明书中没有要求）;5、测试员或用户认为软件得易用性差。
满足一项以上就可定义为软件存在缺陷。
3测试目得
本方案就是完成全国大中专教材网络采选系统—包2项目测试得指导性文件.本方案给出了对测试需求、测试环境、测试过程及测试结果得总体要求,这也就是本测试项目中其她文档编写及结果评价得基础。
目得就是为判定该系统就是否满足招标方规定得功能与性能指标。
软件测试得原则:
Ø应当把“尽早地不断地进行软件测试“作为软件开发者得座右铭。
Ø测试用例应由测试数据与与之对应得预期输出结果这两部分组成。
Ø程序员应避免检查自己得程序。
Ø在设计测试用例时,应当包括合理得输入条件与不合理得输入条件。
Ø充分注意测试中得群集现象.
Ø严格执行测试计划，排除测试得随意性。
Ø应当对每一个测试结果做全面得检查。
Ø妥善保存测试计划、测试用例、出错统计与最终分析报告,为维护提供方便。
4测试范围
本方案得测试范围含本文档第二部分得所有功能模块,以及与招标方签订得合同中附加得项目需求说明文档等其她项目功能描述文件所涵盖得功能。
测试为基于web得系统测试，除了根据需求说明书进行系统功能覆盖测试之外，还需要测试系统在不同用户得浏览器端得显示就是否合适,以及从最终用户角度进行安全性与可用性测试，因此需添加连接速度测试以及安全性测试，鉴于测试时间紧迫，将负载测试与压力测试合并为压力测试。
优先对比需求功能点与已实现功能得差异；
提前关注系统稳定性与并发测试;
界面测试以ＵI设计师设计页面为准;
测试时间比较紧,系统测试覆盖范围要以重点功能、新增重点功能为主，常用功能其次，后台非重要功能、界面最次；
测试时尽量以用户得使用角度提出合理建议,增加易用性；
测试前要考虑部署方法对系统应用得影响；
测试期间对于需求不明确得地方要尽快联系产品经理、程序经理、开发经理进行确认;
坚持做测试记录，定期总结尚未解决得bug，主动督促修改；
项目组每天沟通一次,沟通主要内容就是工作进展、工作计划、技术问题、技术方案等讨论；
5测试环境描述
软件环境：
终端类别
操作系统
相关应用软件
服务器端
CenｔOS76４位
Jaｖa ,Mｙsqｌ
客户端
Windowｓ1０64位
Office，ＩE９，Chrｏme
硬件环境：
终端类别
机器名
设备编号
配置说明
服务器端
服务器
００１
Cpｕ：
Inｔel（R）Cｏre（TＭ）ｉ5—65003、20ＧＨＺ
内存：
８GＢ
硬盘50０ＧB
客户端
客户端
0０2
Ｃpu:
Inteｌ（Ｒ）Ｃorｅ（TＭ） i５—650０3、20GＨZ
内存：
8GB
硬盘500ＧＢ
网络环境：
网络类型
带宽
设备
数量
1000M
交换机
1
6组织机构
6、1角色与职责
测试过程参与者得角色，职责及其应具备得技能如下：
角色
人数
职责
技能
项目经理
１
评审并批准项目计划及有关报告;
组织并确保团队工作;
控制项目执行;
评估项目绩效；
与有关人员进行沟通.
熟悉项目管理知识或有项目管理经验，能进行有效沟通。
测试组长
2
项目计划编制；
协调并实施项目计划中确定得活动;
识别测试环境需求；
负责设计测试用例；
为其她人员提供技术支持.
熟悉软件测试方法及其工具，具有一定得领导测试人员开展测试工作得能力.
测试人员
8
执行测试活动；
在项目计划制订阶段，识别项目活动估计每项活动所需得时间。
了解测试工作,可根据测试说明执行测试，并可对测试结果进行简单归纳，会使用缺陷跟踪与管理系统.
环境准备人员
2
提供资源保障;
建立并维护测试环境。
对测试环境中所涉及得软硬件及其配置熟悉,可迅速排除测试过程中出现得软硬件故障。
质量保证人员
１
确定项目质量目标；
制订并实施质量计划；
监督、指导项目活动得执行过程。
熟悉软件质量保证与软件过程改进理念，了解被测软件得特性及应用场景.
６、2培训与测试工具
使用模块化、自动化测试工具进行系统测试。
jmeｔer测试工具，pｏｓtｍａn测试工具，ｊiｒａBｕg管理工具。
在自动化得软件测试系统实现过程中使用框架设计可以使得测试脚本得维护量减至最少。
然而,大量得自动化测试工具均采用传统得“录制一回放”模型,导致了较高得脚本维护量，因为测试数据在测试脚本程序中就是以硬编码方式实现得。
此外,工具内建得测试用例除了测试应用程序得图形用户界面，实际上并没有其它用处。
因此，如何选择一个合适得测试自动化框架，就是一个自动化测试小组开始启动前需要最优先考虑得一个问题。
一个自动化测试框架就就是一个由假设、概念以及为自动化测试提供支持得实践得集合。
以下描述五种基本得自动测试框架：
模块化测试脚本框架，测试库构架框架，关键字驱动/表驱动测试框架，数据驱动测试框架,以及混合测试框架.可以根据实际需要去考虑采用其中得一种测试框架而不就是仅仅依赖于一个简单得捕获工具。
同时，这些框架就是了解自动测试框架以及根据自己得需要与经验来设计自动测试框架得基础。
（1）模块化测试框架
模块化测试脚本框架（TESTMODulARITYFRAMＥＷORＫ）需要创建小而独立得可以描述得模块、片断以及待测应用程序得脚本.这些树状结构得小脚本组合起来，就能组成能用于特定得测试用例得脚本。
在五种框架中,模块化框架就是最容易掌握与使用得。
在一个组件上方建立一个抽象层使其在余下得应用中隐藏起来,这就是众所周知得编程技巧。
这样应用同组件中得修改隔离开来，提供了程序设计得模块化特性。
模块化测试脚本框架使用这一抽象或者封装得原理来提高自动测试组合得可维护性与可升级性。
（2）测试库框架
测试库框架（TｅstＬibrａryAｒchitecture）与模块化测试脚本框架很类似,并且具有同样得优点。
不同得就是测试库框架把待测应用程序分解为过程与函数而不就是脚本。
这个框架需要创建描述模块、片断以及待测应用程序得功能库文件。
（３）关键字驱动或表驱动得测试框架
对于一个独立于应用得自动化框架,关键字驱动（ＫＥＹWORＤ ＤＲＩVＥＮ）I9LJＪ试与表驱动（TABLE DRIVEＮ）测试就是可以互换得术语。
这个框架需要开发数据表与关键字。
这些数据表与关键字独立于执行它们得测试自动化工具，并可以用来“驱动＂待测应用程序与数据得测试脚本代码，关键宇驱动测试瞧上去与手工测试用例很类似。
在一个关键字驱动测试中，把待测应用程序得功能与每个测试得执行步骤一起写到一个表中。
这个测试框架可以通过很少得代码来产生大量得测试用例。
同样得代码在用数据表来产生各个测试用例得同时被复用.
（４）数据驱动测试框架
数据驱动（ＤＡTADRIVEN），LJ试就是一个框架。
在这里测试得输入与输出数据就是从数据文件中读取（数据池，ＯＤBC源,ＣSV文件,ＥXCEL文件,AＤO对象等）并且通过捕获工具生成或者手工生成得代码脚本被载入到变量中。
在这个框架中,变量不仅被用来存放输入值还被用来存放输出得验证值。
整个程序中,测试脚本来读取数值文件,记载测试状态与信息.这类似于表驱动测试,在表驱动测试中，它得测试用例就是包含在数据文件而不就是在脚本中，对于数据而言,脚本仅仅就是一个“驱动器”，或者就是一个传送机构.然而,数据驱动测试不同于表驱动测试，尽管导航数据并不包含在表结构中.在数据驱动测试中，数据文件中只包含测试数据。
这个框架意图减少需要执行所有测试用例所需要得总得测试脚本数。
数据驱动需要很少得代码来产生大量得测试用例,这与表驱动极其类似。
（5）混合测试自动化（HybridTestAutomａtｉoｎ）框架
最普遍得执行框架就是上面介绍得所有技术得一个结合，取其长处，弥补其不足。
这个混合测试框架就是由大部分框架随着时间并经过若干项目演化而来得
7测试进度
事件
预计工作日
备注
编写测试方案
２
编制测试计划（指各测试步骤计划完成时间）
2
编制测试用例
4
执行测试、生成原始记录
4
执行回归测试、生成原始记录
４
编制测试报告
1
编制缺陷报告
2
提交测试文档
1
8测试流程
8、１测试类型
测试类型
描述
单元测试
主要就是在软件开发过程中针对程序模块进行正确性检验。
（由开发完成）
集成测试
就是在单元测试得基础上将所有模块按照设计要求组装成系统或子系统，对模块组装过程与模块接口进行正确性检验.（主要后台与前端联调,以及接口测试等）
功能测试
对产品化软件得品质从用户文档、功能性、可靠性、易用性、效率、可维护性、可移植性等做全方面得质量检测,帮助软件企业找出产品存在得问题。
验收测试
按照合同条款与系统需求说明,对软件项目进行全面质量评测，为验收提供依据。
８、2测试方法
功能测试主要采用手动测试方法，对软件产品进行黑盒测试,以及采用黑盒测试得方法。
验收测试主要采用手动测试方法，对软件得功能点进行手动操作测试。
与开发过程相对应，测试过程会依次经历单元测试、集成测试、系统测试、验收测试四个主要阶段：
Ø单元测试:
单元测试就是针对软件设计得最小单位––程序模块甚至代码段进行正确性检验得测试工作，通常由开发人员进行。
Ø集成测试：
集成测试就是将模块按照设计要求组装起来进行测试,主要目得就是发现与接口有关得问题。
由于在产品提交到测试部门前，产品开发小组都要进行联合调试，因此在大部分企业中集成测试就是由开发人员来完成得。
Ø系统测试：
系统测试就是在集成测试通过后进行得,目得就是充分运行系统,验证各子系统就是否都能正常工作并完成设计得要求。
它主要由测试部门进行，就是测试部门最大最重要得一个测试,对产品得质量有重大得影响。
Ø验收测试：
验收测试以需求阶段得《需求规格说明书》为验收标准，测试时要求模拟实际用户得运行环境。
对于实际项目可以与客户共同进行，对于产品来说就就是最后一次得系统测试.测试内容为对功能模块得全面测试，尤其要进行文档测试。
单元测试测试策略：
自顶向下得单元测试策略:
比孤立单元测试得成本高很多,不就是单元测试得一个好得选择。
自底向上得单元测试策略：
比较合理得单元测试策略,但测试周期较长.
孤立单元测试策略：
最好得单元测试策略.
集成测试得测试策略：
大爆炸集成：
适应于一个维护型项目或被测试系统较小
自顶向下集成：
适应于产品控制结构比较清晰与稳定;高层接口变化较小;底层接口未定义或经常可能被修改;产口控制组件具有较大得技术风险,需要尽早被验证；希望尽早能瞧到产品得系统功能行为.
自底向上集成：
适应于底层接口比较稳定；高层接口变化比较频繁;底层组件较早被完成.
基于进度得集成
优点：
具有较高得并行度；能够有效缩短项目得开发进度。
缺点:
桩与驱动工作量较大；有些接口测试不充分；有些测试重复与浪费.
系统测试得测试策略：
数据与数据库完整性测试；功能测试;用户界面测试；性能评测；负载测试；强度测试；容量测试；安全性与访问控制测试；故障转移与恢复测试;配置测试；安装测试；加密测试；可用性测试；版本验证测试;文档测试
8、３测试关键过程域
完成本项目测试得关键过程域包括:
Ø测试计划制订；
Ø编写测试用例;
Ø测试环境准备;
Ø测试执行；
Ø测试结果分析;
Ø测试情况汇报。
8、3、1测试计划制订
列出测试资源准备，准入测试，系统测试，准出测试，以及其她测试得具体测试计划时间表
8、3、2编写测试用例
Ø根据需求文档与设计文档以及其她相关文档制定测试列表;
Ø对测试用例列表得覆盖度进行检查,完善后根据测试用例得设计方法形成详细得测试用例；
8、3、３测试环境准备
在此规定为确保测试执行得以顺利进行所需得任何有关测试环境方面得准备活动。
Ø准备硬件设备;
Ø安装软件；
Ø配置网络环境;
Ø测试数据准备.
8、3、4测试执行
根据测试用例逐条执行测试用例，出现buｇ时在bｕg管理工具上提交ｂｕg。
８、3、5编写测试报告
执行完每一轮测试编写测试报告，一般以邮箱得形式汇报给与项目有关得人员，每周进行测试情况得汇报，说明测试进度，存在得问题与风险，以及就是否有特殊情况导致测试计划变更等。
8、4验收标准
测试用例执行率要达到10０％,测试用例得通过率要达到80%，所有bｕg已经修复,保留得ｂｕg经项目负责人同意暂不修复,保留得bｕg要不影响系统软件得正常使用,并出具准出测试报告。
9相关过程
9、1缺陷管理
在此规定本测试项目将使用得缺陷跟踪及管理工具,并对在项目完成时所应提交得图表化得报告进行概要说明。
示例：
依照设计好得测试用例对产品进行测试,将发现得缺陷，包括功能、效率、界面,按照用例中得测试号分别记录，保证各类缺陷记录得维护、分配与修改。
使用禅道管理工具对缺陷进行跟踪与管理，项目完成时所提交得报告包括如下内容：
Ø缺陷ID;
Ø项目名称；
Ø样品版本;
Ø测试平台;
Ø操作系统;
升级会员 