软件测试心得(副本).pptVIP

软件测试经验与心得交流 唐荣军 rongjun.tang@ Office Phone: +86-7551.软件测试概述 1.1经典V模型介绍 这是一个非常单纯、非常理想的一元线性模型，正是因为它太理想、太单纯了，以至于都无法应用于软件工程实践，几乎被业界所抛弃，只有在软件工程的教科书或培训文档上还能找到这个模型，偶尔被人们提及，也属于被批驳的对象。 一元线性模型是人类最容易掌握并能熟练运用的一种思维方法，人们总是把一个复杂的非线性问题转化为一系列的线性问题，然后逐个求解，高等数学里的偏微分就是这样一种思想。重温这个模型有助于我们理解软件工程里最核心的东西！ 1.软件测试概述 1.2我们所处的位置 阿尔卡特流程把手机产品开发定义为OR、DR0、DR1、DR2、DR3和DR4等几个关键里程碑（Milestone），DR是英文Delivery Review的缩写。 跟软件有关系的三个关键里程碑（Milestone）是DR1、DR2和DR4： DR1解决“做什么”和“不做什么”的问题，软件需求开发及功能定义要在这个阶段完成 DR2是full feature全部开发结束 DR4是软件交付生产，也就是说在DR4的时候要能够发布量产软件 1.软件测试概述 1.3我们所采取的策略 V模型所展现的是一种把软件工程化整为零、分而治之的战略艺术，单元测试、集成测试、系统测试和验收测试体现了“由小到大”、“由内至外”和“循序渐进”的思想！下面把单元测试称为单个功能测试。 单个功能测试的粒度最小，由开发工程师自行完成测试，在软件工程学的定义里，属于白盒测试的范畴，我们现在使用simulation加手工来完成，离这个理论定义是有差距的。 集成测试是连接单个功能测试与系统测试的桥梁，以后将由新成立的integration team来完成。 系统测试的粒度最大，由软件部的Test Branch采用黑盒测试方式完成，主要的测试依据是软件需求文档或者Feature List。 验收测试的内容跟系统测试非常接近，主要区别是测试人员不同，在软件工程之定义里，验收测试一般由上帝（客户）来执行，对JRD软件部来说，TCT的QA软件测试组就是我们的上帝！ 1.软件测试概述 1.4测试流程规范 测试计划（Test Plan）应该明确测试的范围，即测什么，如果说不清楚测什么，至少要说清楚不测什么，否则测试将是苦海无边，回头也找不到岸；计划还应该明确测试项目在时间上怎么安排，先测什么，后测什么； 第二步应该明确测试的方法，即怎么样测，要对在第一步中所确定的测试项目进行展开，明确测试的需求并编制测试规范（Test Specification）及测试用例（Test Case）； 第三步执行测试用例（Test Case）； 最后要撰写测试报告（Test Report），目的是使软件缺陷能够得到迅速的修复，同时也使相关的部门或同事能够清楚地了解软件开发的进展情况，软件测试报告并无固定的格式，只要能够完整、清楚地反映当前的测试情况就可以了。 撰写测试报告时可以参考我们在学校时写的物理或者化学试验报告的格式，这些报告的格式是非常严谨的！ 1.软件测试概述 1.5手机软件质量的属性 1.6手机软件质量的要素 市场角度：用户最关注的、能够成为买点的功能 研发角度：对软件整体质量产生重大影响的 1.软件测试概述 1.5手机软件缺陷的判定依据 软件需求定义文档 相关国际标准、国家标准、行业标准 没有在需求文档中写明的隐含的约定俗成 是表示选中，还是表示未选中？全世界人民都在用√表示肯定，用×表示否定，可是搞不懂为什么微软就是要弄出这种反人类行为 没有谁规定手机必须要支持关机闹钟，但如果你现在设计一款无关机闹钟的手机，那无疑是在给自己掘坟墓，当然，如果有人就好这一口，那另当别论 2003年7月我们在新疆作调研的时候，还碰到有用户拿着5288问我们，“可不可以给我焊个马达？”看着他那望穿秋水的眼神，我却只能残酷地告诉他：曾经有一个马达摆在我们面前，可是我们认为不重要，就把它去掉了，直到你来投诉的时候，我们才后悔莫及，如果你以后能再买我们的手机，我们一定设计一个马达，如果要给这个马达加上一个期限，我希望它能振动一万年！ 后面的这两个案例已经超出了软件测试的范畴，我把它们写在这里是期望能够给大家提供一个更为广阔的思路！ 1.软件测试概述 1.7手机软件测试理念 手机开发的三个关键要素是：质量（Quality）、成本（Cost）和上市时间（Time to Market），这三个要素相互制约和影响，一款成功的手机开发，往往是这三个要素的完美折衷。 测试只能证明软件存在缺陷（Defect），却不能证明不存在缺陷（Defe