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