软件测试心得.ppt

文档介绍：Page 1 软件测试经验与心得交流唐荣军 @ Office Phone: [phone] Page 2 经典 V模型介绍 u这是一个非常单纯、非常理想的一元线性模型,正是因为它太理想、太单纯了,以至于都无法应用于软件工程实践,几乎被业界所抛弃,只有在软件工程的教科书或培训文档上还能找到这个模型,偶尔被人们提及,也属于被批驳的对象。 u一元线性模型是人类最容易掌握并能熟练运用的一种思维方法,人们总是把一个复杂的非线性问题转化为一系列的线性问题,然后逐个求解,高等数学里的偏微分就是这样一种思想。重温这个模型有助于我们理解软件工程里最核心的东西! 需求开发验收测试系统测试高层设计集成测试详细设计单元测试编码实现 Page 3 我们所处的位置 u阿尔卡特流程把手机产品开发定义为 OR 、 DR0 、 DR1 、 DR2 、 DR3 和 DR4 等几个关键里程碑( Milestone ), DR 是英文 Delivery Review 的缩写。 u跟软件有关系的三个关键里程碑( Milestone )是 DR1 、 DR2 和 DR4 : – DR1 解决“做什么”和“不做什么”的问题,软件需求开发及功能定义要在这个阶段完成– DR2 是 full feature 全部开发结束– DR4 是软件交付生产,也就是说在 DR4 的时候要能够发布量产软件软件工程各阶段的定义 DR1 DR2 DR3 DR4 DR5 需求开发软件设计与功能开发 JRD 内部测试与改错 TMC QA 验收软件维护需求变更 Page 4 我们所采取的策略 uV模型所展现的是一种把软件工程化整为零、分而治之的战略艺术,单元测试、集成测试、系统测试和验收测试体现了“由小到大”、“由内至外”和“循序渐进”的思想!下面把单元测试称为单个功能测试。 u单个功能测试的粒度最小,由开发工程师自行完成测试,在软件工程学的定义里,属于白盒测试的范畴, 我们现在使用 simulation 加手工来完成,离这个理论定义是有差距的。 u集成测试是连接单个功能测试与系统测试的桥梁,以后将由新成立的 integration team 来完成。 u系统测试的粒度最大,由软件部的 Test Branch 采用黑盒测试方式完成,主要的测试依据是软件需求文档或者 Feature List 。 u验收测试的内容跟系统测试非常接近,主要区别是测试人员不同,在软件工程之定义里,验收测试一般由上帝(客户)来执行,对 JRD 软件部来说, TCT 的 QA 软件测试组就是我们的上帝! Page 5 测试流程规范 u测试计划( Test Plan )应该明确测试的范围,即测什么,如果说不清楚测什么,至少要说清楚不测什么,否则测试将是苦海无边,回头也找不到岸;计划还应该明确测试项目在时间上怎么安排,先测什么,后测什么; u第二步应该明确测试的方法,即怎么样测,要对在第一步中所确定的测试项目进行展开,明确测试的需求并编制测试规范( Test Specification )及测试用例( Test Case ); u第三步执行测试用例( Test Case ); u最后要撰写测试报告( Test Report ),目的是使软件缺陷能够得到迅速的修复,同时也使相关的部门或同事能够清楚地了解软件开发的进展情况,软件测试报告并无固定的格式,只要能够完整、清楚地反映当前的测试情况就可以了。–撰写测试报告时可以参考我们在学校时写的物理或者化学试验报告的格式,这些报告的格式是非常严谨的! Page 6 手机软件质量的属性 手机软件质量的要素 u市场角度:用户最关注的、能够成为买点的功能 u研发角度:对软件整体质量产生重大影响的功能性质量属性正确性( correctness ) 健壮性( robustness ) 非功能性质量属性性能( performance ) 易用性( usability ) 兼容性( compatibility ) Page 7 手机软件缺陷的判定依据 u软件需求定义文档 u相关国际标准、国家标准、行业标准 u没有在需求文档中写明的隐含的约定俗成–是表示选中,还是表示未选中?全世界人民都在用√表示肯定,用×表示否定,可是搞不懂为什么微软就是要弄出这种反人类行为–没有谁规定手机必须要支持关机闹钟,但如果你现在设计一款无关机闹钟的手机,那无疑是在给自己掘坟墓,当然,如果有人就好这一口,那另当别论– 2003 年7月我们在新疆作调研的时候,还碰到有用户拿着 5288 问我们, “可不可以给我焊个马