1.1.5 软件测试方法
软件测试方法见表1-1。
表1-1 软件测试方法
白盒 |
黑盒 |
|
动态 |
利用KDE的调试功能逐步调试程序，进行软件测试 |
通过人工或者自动方法进行软件测试 |
静态 |
代码评审 |
对需求、设计等文档进行审核 |
代码评审中有一个部分是对编码规范的检查。另外，代码评审可以通过人工的方式来实现，也可以借助代码评审工具，如在本书第二篇7.1.1节“普通软件测试工具推荐”提及的Checkstyle、Findbugs、PMD、Android Lint等工具。
扩展阅读：阿丽亚娜五型运载火箭的爆炸-代码静态测试的重要性 程序员在编程的时候必须定义程序用到的变量，以及这些变量所需的计算机内存，这些内存用比特位来定义，如int16、int32、double、float等。 一个16位的变量可以代表-32.768到32.767中间的值。而一个64位的变量可以代表-9.223.372.036.854.775.808到9.223.372.036.854.775.807中间的值。 1996年6月4日上午9时33分59秒，随着5、4、3、2、1、0的倒计时，阿丽亚娜五型运载火箭的首次发射点火后，火箭开始偏离路线，最终被逼引爆自毁，整个过程只有短短的30s。阿丽亚娜五型运载火箭是基于前一代四型火箭开发的。在四型火箭系统中，对一个水平速率的测量值使用了16位的变量及内存，因为在四型火箭系统中反复验证过，这一值不会超过16位的变量，而五型火箭的开发工程师简单复制了这部分程序，而没有对新火箭进行数值的验证，结果发生了致命的数值溢出。发射后这个64位带小数点的变量被转换成16位不带小数点的变量，引发了一系列的错误，从而影响了火箭上所有的计算机和硬件，瘫痪了整个系统，因而不得不选择自毁。 阿丽亚娜五型载火箭使用Ada语言开发，出问题的代码如下： L_M_BV_32:=TBD.T_ENTIER_32S ((1.0/C_M_LSB_BV) * (G_M_INFO_DERRIVE()); if L_M_BV_32 >32767 then P_M_DERIVE(T_ALG.E_BV) :=16#7FFF#; elseif L_M_BV_32 <-32767 then P_M_DERIVE(T_ALG.E_BV) :=16#8000#; else P_M_DERIVE(T_ALG.E_BV):=UC_16S_EN_16NS(TDB.T_ENTIER_16S(L_M_BV_32)); end if; P_M_DERIVE(T_ALG.E_BH):=UC_16S_EN_16NS(TDB.T_ENTIER_16S(1.0/C_M_LSB_BH)*G_M_INFO_DRIVER(T_ALG.E_GH))); 在这个代码中导致最终问题的是最后一句。在这一段语句中共有7个变量运算符出现了问题，仅有4个做了异常处理的保护，而其他3个没有进行。但是这也是由于运行的机器SRI计算机中设定最大负荷目标值为80%，如果要进行异常处理，计算机的CPU要处理的代码会增多。 教训：软件设计和Code Review的重要性。另外阿丽亚娜五型运载火箭在倒计时阶段、飞行阶段以及进入轨道阶段都未经过测试验证。
|
1.1.6 软件测试步骤
图1-11描述了软件测试步骤，具体如下。
图1-11 软件测试步骤
（1）软件测试计划。
（2）软件测试分析。
（3）软件测试设计。
（4）软件测试实施。
（5）软件测试执行。
（6）评估出口准则和报告。
（7）软件测试结束活动。
具体内容读者可以参见参考文献【13】第二章进行更深入的学习。
1.1.7 软件缺陷管理
1．缺陷管理流程
根据SEI TSP国际标准，缺陷管理流程可以定义如下。
研发计算机必须分为开发机、测试机和发布机。开发工作在开发机上进行，软件测试工作（系统测试）在测试机上运行，最后产品验收和运行在发布机上运行，发布机器可能在客户处。
（1）每轮测试开始，开发部门提出本次测试重点，开发机上的版本同步到软件测试机上（或通过配置管理工具实现同步）。
（2）软件测试工程师进行冒烟软件测试，如果冒烟测试没有通过，则退回给开发部门，等待开发部门重新提交软件测试任务，返回第（1）步。
（3）冒烟测试通过，测试工程师继续执行测试活动，包括传统正规测试和基于经验的测试，如探索式软件测试等。发现Bug，记录在缺陷管理工具中。
（4）开发工程师修改被确认的Bug（状态为Assigned）。
（5）当软件测试工程师认为软件测试结束，大部分Bug都发现完毕，开发机上版本再一次同步到软件测试机上。
（6）软件测试工程师对Bug进行复测，如果问题仍旧存在，则标记为Reopen，否则标记为Closed。此时还要对以前测试过的功能进行回归测试。
（7）开发工程师对于Reopen的缺陷进行修改。
（8）当一轮软件测试达到出口标准，软件测试机上的版本同步到发布机上，软件测试任务完成；否则返回第（5）步。
在本书第三篇第13.9节“软件缺陷管理流程”会给出更为详细的描述。
2．缺陷严重等级
由于采用的缺陷管理工具不同，缺陷严重等级的级别也会有差异。
Blocker：（阻碍的）
Ø 阻碍开发和/或软件测试工作，冒烟测试没有通过，不能进行正常的软件测试工作。
Critical：（紧急的）
Ø 系统无法测试，或者系统无法继续操作，应用系统异常中止。
Ø 对操作系统造成严重影响，系统死机，被测程序挂起，不响应等情况。
Ø 造成重大安全隐患情况，如：机密性数据的泄密。
Ø 功能没有实现，无法进行某一功能操作，影响系统使用。
Major：（重大的）
Ø 功能基本上能实现，但在特定情况下导致功能失败。
Ø 导致输出的数据错误，如：数据内容出错、格式错误、无法打开。
Ø 导致其他功能模块无法正常执行。
Ø 功能不完整或者功能实现不正确。
Ø 导致数据最终操作结果错误。
Normal：（普通的）
Ø 功能部分失败，对整体功能的实现基本不造成影响。
Minor：（较小的）
Ø 链接错误、系统出错提示或没有捕获系统出错信息、数据的重要操作（增删查改）没有提示、出现频率极低，会对功能实现造成非致命性的影响。
Trivial：（外观的）
Ø 产品外观上的问题或一些不影响使用的小毛病，如菜单或对话框中的文字拼写或字体问题等。
Enhancement（改进的）
Ø 对系统产品的建议或意见。
3．缺陷修改优先级
由于缺陷管理工具的差异，缺陷修改优先级别也会有差异。
P5：严重级别比较高，影响软件测试进行或者系统无法继续操作。
P4：对系统操作有影响，但不需要马上修改。
P3：页面缺陷（不属于定义的缺陷范围）或者建议。
P2：准备在下一轮软件测试前修改完毕。
P1：准备在下一版本中修改。
4．缺陷书写规则
缺陷编号：【一般缺陷管理工具自动生成】 缺陷简要描述：【一句话描述】 发现者：【一般从下拉框中选择】 修改者：【一般从下拉框中选择】 最早发现所在版本号：【一般从下拉框中选择】 最早发现日期：【一般由日期框选择】 最早修改日期：【一般由日期框选择】 缺陷当前所在模块：【一般从下拉框中选择】 缺陷当前状态：【一般系统自动生成】 缺陷发现时系统环境：【文本框输入或者下拉框选择】 缺陷重现步骤：【由缺陷发现者填写】 实际得到结果：【由缺陷发现者填写】 期望得到结果：【由缺陷发现者填写】 修复描述：【由缺陷修复者填写】 相关文件：【由缺陷发现者填写】 延迟/不修改/修复/回退原因说明：【由缺陷负责人填写】 历史信息：【由缺陷管理系统自动生成，包括状态迁移，所经过的人，各阶段描述等信息】 附件：【由缺陷发现者上传文件】
|
关于缺陷管理工具将在本书第二篇第10章“缺陷管理工具”进行详细描述。
扩展阅读：世界上第一个Bug 1947年9月9日下午3点45分，Grace Murray Hopper在她的记录本上记下了第一个计算机Bug—在Harvard Mark II计算机里找到的一只飞蛾，她把飞蛾贴在日记本上，并写道“First actual case of Bug being found”。这个发现奠定了Bug这个词在计算机世界的地位，变成无数程序员的噩梦。从那以后，Bug这个词在计算机世界表示计算机程序中的错误或者疏漏，它们会使程序计算出莫名其妙的结果，甚至引起程序的崩溃。Grace Murray Hopper是历史上最早一批程序员，而且还是个女程序员。 Hopper的记录连同那只飞蛾现在存在美国历史博物馆。
|
顾翔凡言：
在正确的道路上作自己擅于做得事，大方向把握好，不要过于纠结，就可以了。
