一、软件的生命周期

　　软件计划与可行性研究（问题定义、可行性研究）；需求分析；软件设计（概要设计、详细设计）；编码；软件测试；运行与维护。

　　生存周期划分

　　各阶段的任务彼此间尽可能相对独立，同一个阶段各项任务的性质尽可能相同，从而降低每个阶段任务的复杂性，简化不同阶段之间的联系，有利于软件开发过程的组织管理。

　　生存周期基线

• 功能基线(functional baseline)

　　功能基线是指在系统分析与软件定义阶段结束时，经过正式评审和批准的系统设计规格说明书中对待软件生命周期开发系统的规格说明；或是指经过项目委托单位和项目承办单位双方签字同意的协议书或合同中所规定的对待开发软件系统的规格说明；或是由下级申请经上级同意或直接由上级下达的项目任务书中所规定的对待开发软件系统的规格说明。功能基线是最初批准的功能配置标识。

• 指派基线(allocated baseline)

　　指派基线是指在软件需求分析阶段结束时，经过正式评审和批准的软件需求的规格说明。指派基线是最初批准的指派配置标识。

• 产品基线(product baseline)

　　产品基线是指在软件组装与系统测试阶段结束时，经过正式评审的批准的有关所开发的软件产品的全部配置项的规格说明。产品基线是最初批准的产品配置标识。

　　SDLC的六个阶段

　　1.定义及规划　 

　　此阶段是软件开发方与需求方共同讨论，主要确定软件的开发目标及其可行性。 

　　2.需求分析　 

　　在确定软件开发可行的情况下，对软件需要实现的各个功能进行详细分析。需求分析阶段是一个很重要的阶段，这一阶段做得好，将为整个软件开发项目的成功打下良好的基础。"唯一不变的是变化本身。"，同样需求也是在整个软件开发过程中不断变化和深入的，因此我们必须制定需求变更计划来应付这种变化，以保护整个项目的顺利进行。　 

　　3.软件设计　 

　　此阶段主要根据需求分析的结果，对整个软件系统进行设计，如系统框架设计，数据库设计等等。软件设计一般分为总体设计和详细设计。好的软件设计将为软件程序编写打下良好的基础。　　 

　　4.程序编码　　 

　　此阶段是将软件设计的结果转换成计算机可运行的程序代码。在程序编码中必须要制定统一，符合标准的编写规范。以保证程序的可读性，易维护性，提高程序的运行效率。　 

　　5.软件测试　 

　　在软件设计完成后要经过严密的测试，以发现软件在整个设计过程中存在的问题并加以纠正。整个测试过程分单元测试、组装测试以及系统测试三个阶段进行。测试的方法主要有白盒测试和黑盒测试两种。在测试过程中需要建立详细的测试计划并严格按照测试计划进行测试，以减少测试的随意性。　　 

　　6.运行维护

　　软件维护是软件生命周期中持续时间最长的阶段。在软件开发完成并投入使用后，由于多方面的原因，软件不能继续适应用户的要求。要延续软件的使用寿命，就必须对软件进行维护。软件软件生存周期的维护包括纠错性维护和改进性维护两个方面。 

　　周期模型

　　典型的几种生命周期模型包括瀑布模型、快速原型模型、迭代模型　 

　　二、软件测试在软件生命周期（瀑布模型）中的对应关系

　　三、软件测试过程 

　　第一步：对要执行测试的产品/项目进行分析，确定测试策略，制定测试计划。该计划被审核批准后转向第二步。测试工作启动前一定要确定正确的测试策略和指导方针，这些是后期开展工作的基础。只有将本次的测试目标和要求分析清楚，才能决定测试资源的投入。

　　第二步：设计测试用例。设计测试用例要根据测试需求和测试策略来进行，进度压力不大时，应该设计的详细，如果进度、成本压力较大，则应该保证测试用例覆盖到关键性的测试需求。该用例被批准后转向第三步。

　　第三步：如果满足“启动准则”（EntryCriteria），那么执行测试。执行测试主要是搭建测试环境，执行测试用例。执行测试时要进行进度控制、项目协调等工作。

　　第四步：提交缺陷。这里要进行缺陷审核和验证等工作。

　　第五步：消除软件缺陷。通常情况下，开发经理需要审核缺陷，并进行缺陷分配。程序员修改自己负责的缺陷。在程序员修改完成后，进入到回归测试阶段。如果满足“完成准则”（ExitCriteria），那么正常结束测试。

　　第六步：撰写测试报告。对测试进行分析，总结本次的经验教训，在下一次的工作中改。

　　软件测试过程管理，主要包括软件测试是什么样的过程，如何评价一个软件测试过程，如何进行配置管理和测试风险分析以及测试成本的管理。　 

　　四、软件测试流程（与第三条对应）

　　1、制定测试计划

　　2、编辑测试用例

　　3、执行测试用例

　　4、发现并提交BUG

　　5、开发组修正BUG

　　6、对已修正BUG进行返测

　　7、修正完成的BUG将状态置为已关闭，未正确修正的BUG重新激活　　 

　　五、测试用例 

　　测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。

　　测试用例的要素为：版本号、模块名称、用例编号、用例名称、用例级别、预置条件、验证步骤、期望结果（含判断标准）、测试结果、测试时间、测试人员等。（其中核心要素为预置条件、验证步骤、期望结果）

　　测试用例的设计方法：等价类划分、边界值分析、错误推测法、因果图法、场景设计法

　　一份好的测试用例所要达到以下几点要求：测试用例必须完成对需求的完整覆盖（即用例和需求的双向可追溯性）；测试用例必须是可执行的；测试用例的结果唯一性；测试用例必须简洁明了　 

　　六、缺陷报告（提交bug）

　　一份有效的缺陷报告要素通常包括：标题、前提、测试环境、操作步骤、实际结果、期望结果、出现的频率、优先级、严重等级、附件（一般是图片形式）。 另外还会有一些附加信息，如测试人员、开发负责人等。

• 标题：简明扼要，无歧义

• 优先级 Priority（4个等级）：软件被修复的紧急程度 1--立即解决：缺陷导致系统几乎不能运行使用 或 严重妨碍测试的执行（需立即修改） 2--高优先级：缺陷严重，影响到测试了（当天或第二天要及时解决的） 3--正常：一般错误 4--低优先级：可以在开发有时间的时候处理，如页面文本框对齐显示

• 严重等级 Severity（4个等级）：缺陷引起的故障对用户使用系统的影响 1--致命的：主流程不通，导致系统功能缺失、用户数据被破坏、系统崩溃、死机 2--严重的：影响流程的 比较严重的，比如系统主要功能部分未实现 3--一般：系统的次要功能没有完全实现，但不影响用户的正常使用 4--较小：操作不方便或遇到麻烦，但不影响功能的使用，如字体不美观、按钮大小不合适、文字排列对齐等（属于建议性或者美观方面的）

　　一般来说，缺陷越严重，优先级越高，但也有例外：

　　1）从用户角度看，缺陷不是很严重，但可能影响到测试执行了（优先级高严重等级低）

　　2）有些缺陷比较严重，但由于技术的限制，暂时没法修改。这时优先级就降低了

• 附件有时候，用文字很难清楚描述缺陷，此时用图片（画笔指明问题）就很直观了

　　如何有效的报告缺陷？

• 单一准确：每个报告只针对一个缺陷，如果有多个缺陷，可能开发只修正了其中一个，其他的没有得到修改，加长了缺陷的生命周期

• 可以再现：不能忽视或省略任何一项操作步骤，特别是关键性的操作，如描述的不够清楚，RD（Research and Development engineer）就会过来沟通怎么操作的，浪费了大家的时间

• 完整统一：完整的描述信息

• 短小简练：使用关键词

• 特定条件：有些问题只在特定环境下存在

　　七、测试报告

　　测试报告是指把测试的过程和结果写成文档，对发现的问题和缺陷进行分析，为纠正软件的存在的质量问题提供依据，同时为软件验收和交付打下基础。

　　一份详细的测试报告包含足够的信息，包括产品质量和测试过程的评价，测试报告基于测试中的数据采集以及对最终的测试结果分析。

　　测试报告的主体框架为：

　　1、首页

　　报告名称（软件名称+版本号+用户端类型（android，iphone，后台管理等等）+测试范围（单元，集成，系统，模块等等）+测试报告）

　　报告委托方，报告责任方，报告日期等

　　版本变化历史

　　密级

　　2、引言

　　2.1编写目的

　　本测试报告的具体编写目的，指出预期的读者范围。

　　2.2 项目背景

　　对项目目标和目的进行简要说明。必要时包括简史，这部分不需要脑力劳动，直接从需求或者招标文件中拷贝即可。

　　2.3 系统简介

　　如果设计说明书有此部分，照抄。注意必要的框架图和网络拓扑图能吸引眼球。

　　2.4 术语和缩略语

　　列出设计本系统/项目的专用术语和缩写语约定。对于技术相关的名词和与多义词一定要注明清楚，以便阅读时不会产生歧义。

　　2.5 参考资料

　　3、测试概要

　　测试的概要介绍，包括测试的一些声明、测试范围、测试目的等等，主要是测试情况简介。（其他测试经理和质量人员关注部分）

　　3.1测试方法(和工具)

　　简要介绍测试中采用的方法(和工具)。

　　3.2测试范围

　　介绍本次所测试的软件功能

　　3.3测试环境与配置

　　简要介绍测试环境及其配置。

　　4、测试结果与缺陷分析

　　整个测试报告中这是最激动人心的部分，这部分主要汇总各种数据并进行度量，度量包括对测试过程的度量和能力评估、对软件产品的质量度量和产品评估。对于不需要过程度量或者相对较小的项目，例如用于验收时提交用户的测试报告、小型项目的测试报告，可省略过程方面的度量部分；而采用了CMM/ISO或者其他工程标准过程的，需要提供过程改进建议和参考的测试报告－主要用于公司内部测试改进和缺陷预防机制－则过程度量需要列出。

　　4.1测试执行情况与记录

　　描述测试资源消耗情况，记录实际数据。（测试、项目经理关注部分）

　　4.1.1测试组织

　　可列出简单的测试组架构图

　　4.1.2测试时间

　　列出测试的跨度和工作量，最好区分测试文档和活动的时间。数据可供过程度量使用。

　　4.1.3测试版本

　　4.2覆盖分析

　　4.2.1需求覆盖

　　需求覆盖率是指经过测试的需求/功能和需求规格说明书中所有需求/功能的比值，通常情况下要达到100%的目标。

　　4.2.2测试覆盖

　　需求/功能（或编号） 用例个数 执行总数 未执行 未/漏测分析和原因

　　测试覆盖率计算 执行数/用例总数 ×100%

　　4.3缺陷的统计与分析

　　缺陷统计主要涉及到被测系统的质量，因此，这部分成为开发人员、质量人员重点关注的部分。

　　4.3.1缺陷汇总

　　被测系统 系统测试 回归测试 总计

　　合计

　　按严重程度

　　严重 一般 微小

　　按缺陷类型

　　用户界面 一致性 功能 算法 接口 文档 用户界面 其他

　　按功能分布

　　功能一 功能二 功能三 功能四 功能五 功能六 功能七

　　最好给出缺陷的饼状图和柱状图以便直观查看。俗话说一图胜千言，图标能够使阅读者迅速获得信息，尤其是各层面管理人员没有时间去逐项阅读文章。

　　4.3.2缺陷分析

　　本部分对上述缺陷和其他收集数据进行综合分析

　　缺陷综合分析

　　缺陷发现效率 = 缺陷总数/执行测试用时

　　可到具体人员得出平均指标

　　用例质量 = 缺陷总数/测试用例总数 ×100%

　　缺陷密度 = 缺陷总数/功能点总数

　　缺陷密度可以得出系统各功能或各需求的缺陷分布情况，开发人员可以在此分析基础上得出那部分功能/需求缺陷最多，从而在今后开发注意避免并注意在实施时予以关注，测试经验表明，测试缺陷越多的部分，其隐藏的缺陷也越多。

　　4.3.3残留缺陷与未解决问题

　　残留缺陷

　　评价：对这些问题的看法，也就是这些问题如果发出去了会造成什么样的影响

　　5、测试结论与建议

　　5.1 测试结论

　　1．测试执行是否充分（可以增加对安全性、可靠性、可维护性和功能性描述）

　　2．对测试风险的控制措施和成效

　　3．测试目标是否完成

　　4．测试是否通过

　　5．是否可以进入下一阶段项目目标

　　5.2 建议

　　1．对系统存在问题的说明，描述测试所揭露的软件缺陷和不足，以及可能给软件实施和运行带来的影响

　　2．可能存在的潜在缺陷和后续工作

　　3．对缺陷修改和产品设计的建议

　　4．对过程改进方面的建议

　　6、附录

• 缺陷列表

• 缺陷等级定义标准

• 测试通过标准

作者：yy19890521

原文链接：http://www.51testing.com/html/21/n-4474721.html