越来越觉得自己走测试这条路是对的，越来越觉得自己适合做测试，这么久以来兴趣一直在激发我前进，一直在寻找下一个站点，我相信测试路上我一定会走的很远，我的测试道路一定会很宽阔，努力就有收获，也希望还在测试路口迷惘的朋友，不要再犹豫了，因为你的犹豫不决，会使你错过很多~~~~~喜欢就去just do it ，因为只有尝试了才知道自己适不适合，喜不喜欢。如果一味的问别人，永远找不到最终的答案。因为每个人的感觉不一样，每个人的情况不一样，每个人的前提条件都不一样，你会得到不同的答案，这样只能会使你更迷茫~~~~

读书笔记二 ----------（测试过程）

上一篇 / 下一篇  2010-02-03 10:11:45 / 个人分类：测试相关资料

查看( 1018 ) / 评论( 0 ) / 评分( 0 / 0 )
Ø按照开发阶段划分：单元测试、集成测试、系统测试、确认测试。
Ø按照测试实施组织划分：开发方测试、用户测试（β测试）、第三方测试。
Ø按照测试技术划分：白盒测试、黑盒测试、灰盒测试。
Ø软件测试方法和技术的分类与软件开发过程相关联，它贯穿了整个软件生命周期。
Ø走查、单元测试、集成测试、系统测试用于整个开发过程中的不同阶段。
u开发文档和源程序可应用走查的方法；
u单元测试可应用白盒测试方法；
u集成测试应用近似灰盒测试方法；
u系统测试和确认测试应用黑盒测试方法。

ØV模型是最具有代表意义的测试模型。
ØV模型是软件开发瀑布模型的变种，它反映了测试活动与分析和设计的关系。
Ø从左到右，描述了基本的开发过程和测试行为，非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。
Ø箭头代表了时间方向，左边下降的是开发过程各阶段，与此相对应的是右边上升的部分，即各测试过程的各个阶段。
ØV模型存在一定的局限性，它仅仅把测试过程作为在需求分析、概要设计、详细设计及编码之后的一个阶段。容易使人理解为测试是软件开发的最后的一个阶段，主要是针对程序进行测试寻找错误，而需求分析阶段的隐藏的问题一直到后期的验收测试才被发现。
Ø在V模型中增加软件各开发阶段应同步进行的测试，被演化为一种W模型。
Ø开发是“V”，测试也是与此相重叠的“V”。
ØW模型体现了“尽早地和不断地进行软件测试”的原则。
Ø岗位及职责
u部门主管：负责审计测试报告，决定软件是否能够对外发布。
u项目组负责人：负责需求分解、讲解和澄清，评审测试方案和测试样例。负责单元和集成测试并保证提交的产品质量达到系统测试的要求。组织研究组成员根据系统测试中提交的Bug进行修改并发布新版本。
u测试负责人：负责组织测试团队，编写测试计划、测试大纲，按计划进行测试。
u测试人员：负责编写测试样例、执行测试、发布测试报告等。
u质量保证人员：负责审计系统测试过程和测试报告。
u配置管理员：负责配置审计和检入、检出控制，为缺陷管理提供支持。


Ø总体流程（参见流程图）
u需求阶段
u设计阶段
u编码阶段
u集成测试阶段
u系统测试阶段
u测试报告的确认

Ø需求阶段
在需求阶段，测试人员需要了解需求，根据需求编写测试用例。
u测试人员必须参加研究组的需求培训和参加主要的需求讨论、分析会议。需求和原型的讨论结果也应发与测试人员。
u测试人员应参加需求的评审会议，对于需求的可测性进行确认，协助确定需求的验收标准。
u如果有原型的讨论会议，测试人员也应参加。
u需求文档评审通过后研究组指定负责人编写系统测试方案。系统测试方案要经过评审后才可使用。
u测试负责人根据需求文档和项目开发进度计划编写系统测试进度计划。系统测试进度计划可以与项目进度计划写在一起，但要给出编写系统测试样例和每轮测试的时间及资源。
u测试人员根据需求说明书和业务流程图开始设计系统测试样例中的测试功能点和业务测试流程（包括正常业务测试流程和异常的业务测试流程）。
u测试人员根据SCCB的需求变更修改系统测试样例。
Ø设计阶段
在设计阶段，测试人员需要了解设计，细化测试用例。
u测试人员必须参与结构设计和详细设计的评审会议。
u测试人员根据开发组的结构设计和详细设计精化测试样例，明确出测试步骤、分类的测试数据（正常数据、异常数据和边缘数据）和具体的期望值等。
u测试人员根据设计变更修改系统测试样例。
Ø编码阶段
在编码阶段，测试人员完成系统测试样例，并提交评审。
u开发人员根据结构设计和详细设计，确定相互间接口的参数和服务是否描述清晰、匹配。对于可能出现的问题要在编码前提出避免的方法。
u开发人员在代码编写完成后进行代码自查和互查和单元测试。
u测试人员完成系统测试样例（或者大纲）并提交评审。
Ø系统测试阶段
系统测试指根据需求对最终软件进行测试，以便发现软件中的缺陷，验证软件满足预先定义的需求。一般采用黑盒测试方法。
u进入系统测试阶段的三个前提条件：
①送系统测试的产品经过了开发组内的集成测试，保证在系统测试时大体业务流程不会出现堵塞现象。
②测试人员得到开发人员的邮件通知。
③测试人员可以从静态配置库得到安装包或升级包，并确定包中的内容符合要求。
u系统测试过程
①测试人员根据测试进度计划按照测试方案中的测试类型进行测试。
② 对于功能测试，测试人员要进行自由测试和严格按照测试样例测试两种方式。
③测试人员可以根据测试进度进行回归测试。测试人员不用每轮都做完全回归测试只做部分回归测试即可，但发布现场的版本必须要进行完全回归测试。
④测试人员还必须对用户安装手册、使用手册、维护手册和升级安装手册进行测试。
自由测试：自由测试就是测试人员不按照测试样例只是根据自己对业务和系统的理解进行测试，可以走任意的测试流程和输入任意的数据进行测试。这样有可能测试出测试样例发现不了的缺陷。
完全回归测试：对以前已经测试过的工作产品全部地进行复测。回归测试主要是为了验证在添加新功能或修复功能后，工作产品是否还能够达到预期的标准。
部分回归测试：对以前已经测试过的工作产品的重要部分进行复测。
Ø质量记录
u《系统测试计划》
u《系统测试大纲》
u《系统测试报告》
Ø验证
u评审人员评审《系统测试计划》、《系统测试大纲》。
u部门主管、项目负责人、质量保证人员审计、确认《系统测试报告》。
u质量保证人员对整体测试过程进行审核。
•功能测试
•用户界面测试
•性能测试
•配置测试
•安装卸载测试
•安全性和访问控制测试
•数据和数据库完整性测试
•故障转移和恢复测试
•文档测试

收藏 举报

TAG:

 

评分：0

我来说两句