软件问题分析
转自http://www.cnitblog.com/Lily/archive/2006/05/25/11022.html
-- 摘自《软件评测师考试考点分析与真题详解》
通用术语：
l 软件错误（software error）
l 软件缺陷（software defect）
l 软件故障（software fault）
l 软件失效（software failure）
(1) 软件错误（software error）
软件错误是指在软件生存期内的不希望或不可接受的人为错误，其结果将导致软件缺陷的产生。“错误”还可广义定义为：“不正确的事务和行为”。软件错误是一种人为的过程，对软件本身是一种外部行为。
(2) 软件缺陷（software defect）
软件缺陷是存在于软件（文档、数据、程序）之中的那些不希望或不可接受的偏差，其结果是软件运行于某一特定条件时将出现软件故障，这时称软件缺陷被激活。
“缺陷”被认为是“欠缺和不够完备的地方”。软件的欠缺和不完备主要是针对产品说明书而言的。按一般定义，只要软件出现的问题符合下列5种情况的任何一种，就叫做软件缺陷。
1. 软件未达到产品说明书中标明的功能；
2. 软件出现了产品说明书中指明的不会出现的错误；
3. 软件功能超出了产品说明书指明的范围；
4. 软件未达到产品说明书虽未指出但应达到的目标；
5. 软件测试人员认为软件难以理解、不易使用、运行速度慢、和最终用户认为不好使用。
(3) 软件故障（software fault）
软件故障是指在软件运行过程中出现的一种不希望或不可接受的内部状态。软件故障是一种状态行为，是指一个实体发生障碍和毛病。软件故障在ISO14598软件产品评价标准中的定义是：计算机程序中不正确的步骤、过程和数据定义。
(4) 软件失效（software failure）
软件失效是指在软件运行时产生的一种不希望或不可接受的外部行为结果。软件失效是系统行为对用户要求的偏离，是一种面向用户的概念。这就是说，失效意味着系统是在运行，而且只有在执行程序过程中才会发出软件失效。
要发现潜在的失效，可以通过设计审查、代码阅读和其他复审等测试方法进行检查。
综合软件问题分类的定义和分析，我们可以得出：软件错误是一种人为的错误，一个软件错误必定产生一个或多个软件缺陷。当一个软件缺陷被激活时，便产生一个软件故障；同一个软件缺陷在不同条件下被激活，可能产生不同的软件故障。软件故障若没有及时地使用容错措施加以处理，便不可避免地导致软件失效；同一个软件故障在不同条件下可能产生不同的软件失效。这就是软件失效的现象和机理。
软件失效机理可描述为：软件错误à 软件缺陷à 软件故障à 软件失效
软件自动化测试
转自http://www.cnitblog.com/Lily/archive/2006/09/18/16982.html
软件工程的测试阶段是软件开发过程中工作量最大的阶段之一，随着软件测试工作日益得到重视，测试工具的应用已经成为普遍趋势。测试工具一般可分为白盒测试工具、黑盒测试工具、性能测试工具，别外还有用于测试管理（测试流程管理、缺陷跟踪管理、测试用例管理）的工具。其他测试工具（专用测试测试，如针对数据库测试的工具，对应用性能进行优化的工具等）。
表格 1 测试工具
|
工具类型 |
描述 |
|
测试过程生成器 |
根据需求/设计/对象模型生成测试过程 |
|
代码（测试）覆盖率分析器和代码测量器 |
确定未经测试的代码和支持动态测试 |
|
内存泄漏检测 |
用来确认应用程序是否正确地管理了它的内存资源 |
|
度量报告工具 |
读取源代码并显示度量信息，例如数据流、数据结构和控制流的复杂度。能够根据模块、操作数、操作符和代码行的数量提供代码规模的度量 |
|
可使用性测量工具 |
用户配置、任务分析、制作原型和用户走查 |
|
测试数据生成器 |
产生测试数据 |
|
测试管理工具 |
提供某些测试管理功能，例如：测试过程的文档化和存储，以及测试过程的可追踪性 |
|
网络测试工具 |
监视、测量、测试和诊断整个网络的性能 |
|
GUI测试工具（记录/回放工具） |
通过记录用户与在线系统这间的交互，使GUI测试自动化，这样它们可以被自动回放 |
|
负载、性能和强度测试工具 |
用于负载/性能/强度测试 |
|
专用工具 |
针对特殊的构架或技术进行专门测试的测试工具，例如：嵌入式系统 |
测试工具的选择
建议从以下几个方面来权衡和选择
1.功能
除了测试工具所提供的基本功能外，还可参考其它的功能需求，如报表功能、测试工具的集成能力、操作系统和开发工具的兼容性。
2.价格
自主制作一个工具
有些情况下，我们需要自己制作测试工具：
l 操作系统不兼容：市场上没有现成的工具与正在使用的各种操作系统兼容，所以需要考虑制作一个在专门的测试环境下运行的定制工具。例如：Linux下的消耗CPU的工具。
l 应用程序不兼容：正在测试的应用程序包含一个特殊元素，如一个自定义的控件或第三方插件，它和市场上存在的任何记录/回放工具都不兼容。例如：公司产品：录像播放器。
l 专项测试的需要：为了取得最佳的测试效果，以便对不能使用GUI测试工具的，复杂的和关键的组件进行自动测试。例如：agent报文捕获率的测试。
自动测试：选择最好的实践
不要过分依赖记录/回放工具。
功能性测试工具（也称为记录/回放工具），只是无数可供利用的测试工具中的一种。记录/回放机制能够增强测试工作的效果，但是我们不应该只使用这一种自动测试方法。即使使用最好的记录/回放自动测试技术，它们还是有局限性。
1）硬编码的数值。
2）非模块化的、不易维护的脚本。
3）缺乏可重用性的标准。
尽量使回归测试自动化
回归测试确定的是：在修改先前的错误或者向应用程序添加新功能时，是否引放了新的错误，这些错误影响以前运行正常的功能。回归测试应该发现这些新引入的缺陷。
了解自动测试工具对测试工作的影响
自动测试工具只是解决方案的一部分，它们不能解决所有测试工作中的问题。自动测试工具决不能代替指导测试工作的分析技能，也不能替代手工测试。我们必须把自动测试看作是对手工测试过程的补充。
自动化测试可以帮助测试人员做到：
（1）提高测试执行的速度；
（2）提高运行效率；
（3）保证测试结果的准确性；
（4）连续运行测试脚本；
（5）模拟现实环境下受约束的情况。
自动化测试不能做到的是：
（1）所有测试活动都可以自动完成；
（2）减少人力成本；
（3）毫无成本的得到；
（4）降低测试的工作量。
Windows 脚本
脚本试用与演示.vbs
'创建新文件夹
'描述:使用Shell 对象创建名为C:Archive 的新文件夹。
ParentFolder = "C:"
set objShell = CreateObject("Shell.Application")
set objFolder = objShell.NameSpace(ParentFolder)
objFolder.NewFolder "Archive"
'创建文本文件
'描述:演示脚本创建一个新的空文本文件。此脚本必须运行在本地计算机上。
Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objFile = objFSO.CreateTextFile("C:ArchiveScriptLog.txt")
'检验文件是否存在
'描述:演示脚本使用FileSystemObject 检验文件是否存在。此脚本必须运行在本地计算机上。
Set objFSO = CreateObject("Scripting.FileSystemObject")
If objFSO.FileExists("C:ArchiveScriptLog.txt") Then
'Set objFolder = objFSO.GetFile("C:ArchiveScriptLog.txt")
Wscript.Echo "File C:ArchiveScriptLog.txt 存在."
Else
Wscript.Echo "File does not exist."
End If
附：测试工具介绍
IBM rational 测试工具：
测试缺陷管理工具ClearQuest
性能测试工具：Rational Performance Tester（TestManager、Robot）
功能测试工具：Functional Tester（Test XDE）
单元测试工具：IBM/Rational PurifyPlus
–Purify：白盒测试工具，自动定位内存相关错误
–Quantify：白盒测试工具，用于性能瓶颈分析
–Pure Coverage：白盒测试工具，记录代码覆盖率。发现未被测试的代码
–TestFactory：可靠性测试
–Robot 自动测试工具，类似WINRUNNDER，加上VT可以做并发测试
–TestManager 测试计划制定及执行工具
Mercury测试工具
功能测试：WinRunner ，LoadRunner，TestDirector
开源工具
测试框架：Junit 、NUnit、HttpUnit、CppUnit
性能测试：JMeter
测试覆盖率工具：clover.NET
参考文献：
《软件评测师考试考点分析与真题详解》—电子工业出版社
《有效软件测试—提高软件测试的50条建议》—清华大学出版社
《系统分析师常用工具》—清华大学出版社
QA与TEST（相同点与不同点）
转自http://www.cnitblog.com/Lily/archive/2006/08/29/16124.html
|
相同点 |
不同点 |
||
|
QA |
TEST |
QA |
TEST |
|
保证和提高产品质量 |
关注过程 SQA 重点是对软件开发过程进行监督管理、控制 |
关注产品 TESTER 重点是对软件开发的成果进行检查、控制 |
|
|
以组织标准过程和项目已定义过程为依据 |
以产品需求为依据 |
||
|
以评审和审计为主要手段 |
以模拟各种场景的实际使用为手段 |
||
|
重在发现和提出过程存在的问题 |
重在发现产品存在的缺陷 |
||
|
重在预防 |
重在发现和纠正 |
||
人机测试界面
转自http://www.cnitblog.com/Lily/archive/2006/08/29/16122.html
软件界面的设计讲究规矩、简洁、一致、易用。规范的设计，美观、规整的软件人机界面有利于破除新用户对软件的生疏感，使老用户更易于上手、充分重用已有的使用经验，并尽量少犯错误。因此我们在对软件人机界面进行测试时（设计评审阶段和系统测试阶段结合进行），可以参照下列提示，测试软件的人机界面。
一致性测试
|
1. |
提示的格式是否一致 ? |
|
|
2. |
菜单的格式是否一致 |
|
|
3. |
帮助的格式是否一致 |
|
|
4. |
提示、菜单、帮助中的术语是否一致 |
|
|
5. |
各个控件之间的对齐方式是否一致 ( 如标签右对齐，输入框左对齐 ) |
|
|
6. |
输入界面和输出界面在外观、布局、交互方式上是否一致 |
|
|
7. |
命令语言的语法是否一致 |
|
|
8. |
功能类似的相关界面是否在在外观、布局、交互方式上是否一致 |
|
|
9. |
存在同一产品族的时候，是否与其他产品在外观、布局、交互方式上是否一致 |
|
|
10. |
同一层次的文字在同一种提示场合（一般情况、突显、警告等）在文字大小、字体、颜色、对齐方式方面是否一致 |
|
|
11. |
多个连续界面依次出现的情况下，界面的外观、操作方式是否一致 |
|
信息反馈测试
|
12. |
系统是否接受客户的正确输入并做出提示（例：鼠标焦点跳转）； |
|
|
13. |
系统是否拒绝客户的错误输入并做出提示（例：弹出警告框，声响）； |
|
|
14. |
系统显示用户的错误输入的提示是否正确，浅显易懂 |
|
|
15. |
系统是否在用户输入前给出用户具体输入方式的提示 |
|
|
16. |
系统提示所用的图标或图形是否具有代表性和警示性 |
|
|
17. |
系统提示用语是否按警告级别和完成程度进行分级（若非某些破坏性操作，请对用户温和一些）； |
|
|
18. |
系统在界面（主要是菜单、工具条）上是否提供突显功能（比如鼠标移动到控件时，控件图标变大或颜色变化至与背景有较大反差，当移动开后恢复原状）； |
|
|
19. |
系统是否在用户完成操作时给出操作成功的提示。 |
|
界面简洁性测试
|
20. |
用户界面是否存在空白空间（没有空白空间的界面是杂乱无章的，易用性极差）； |
|
|
21. |
各个控件之间的间隔是否一致； |
|
|
22. |
各个控件在垂直和水平方向上是否对齐； |
|
|
23. |
菜单深度是否在三层以内（建议不要超出三层） |
|
|
24. |
界面控件分布是否按照功能分组（菜单、工具栏、单选框组、复选框组、 Frame 等）； |
|
|
25. |
界面控件本身是否需要通过滑动条的滑动来显示数据（建议采用分页显示并提供数据排序显示功能）； |
|
界面美观度测试
|
26. |
前景与背景色搭配是否反差过大 |
|
|
27. |
前景与背景色是否采用较为清淡的色调而不是深色（比如用天蓝色而不用深蓝色和墨绿色）； |
|
|
28. |
系统界面是否采用了超过三种的基本色（一般情况下不要超过三种）； |
|
|
29. |
字体大小是否与界面的大小比例协调 |
|
|
30. |
按钮较多的界面是否禁止缩放（一般情况下不宜缩放，最好禁止最大、最小化按钮）； |
|
|
31. |
系统是否提供用户界面风格自定义功能，满足用户个人偏好 |
|
用户动作性测试
|
32. |
用户频繁操作的功能是否有快捷键； |
|
|
33. |
是否允许动作的可逆性（ Undo ， Redo ）； |
|
|
34. |
界面是否有对用户的记忆要求； |
|
|
35. |
系统的反应速度是否符合用户的期望值； |
|
|
36. |
是否存在更便捷、直观的方式来取代当前的界面的显示方式；（比如用菜单界面代替命令语言界面） |
|
|
37. |
用户在使用时是否能在任何时候开启帮助文档（ F1 ）； |
|
|
38. |
系统是否提供模糊查询机制和关键字提示机制减少用户的记忆负担 |
|
|
39. |
是否对可能造成长时间等待的操作提供操作取消功能； |
|
|
40. |
是否支持对错误操作进行可逆性处理，返回原有状态 |
|
|
41. |
是否采用相关控件（如：日历，计算器等）替代用户手工键盘输入； |
|
|
42. |
选项过多的情况下是否采用下拉列表或者关键字检索的方式共用户选择； |
|
|
43. |
系统出错时是否存在恢复机制使用户返回出错前状态 |
|
|
44. |
在用户输入数据之前，用户输入数据后才能执行的操作是否被禁止（如特定的按钮变灰）； |
|
|
45. |
系统是否提供 “ 所见即所得 ”( 如报表打印 ) 或 “ 下一步提示 ” 的功能（比如预览）； |
|
行业标准测试
|
46. |
界面使用的图符、声音是否符合软件所面向领域的行业符号体系标准； |
|
|
47. |
界面所使用的术语是否符合软件所面向领域的行业命名标准 |
|
|
48. |
界面的颜色是否与行业代表色彩较为相近； |
|
|
49. |
界面的背景是否能够反映行业相关主题 |
|
|
50. |
界面的设计是否反映行业最新的理念和大众趋势； |
|
|
51. |
软件的安装界面是否有单位介绍或产品介绍，并拥有自己的图标； |
|
|
52. |
软件的安装界面是否在界面上不同于通用的安装工具生成的界面 |
|
|
53. |
主界面的图标是否为制作商的图标； |
|
|
54. |
系统启动需要长时间等待时，是否存在 Splash 界面，它是否包含或反映制作者信息； |
|
|
55. |
软件是否有版本查看机制，版本说明上是否有制作者或是用户的标识； |
|
|
56. |
软件的界面的色彩、背景、布置是否与同类产品有不同之处，如果有，是否更为简洁、美观； |
|
|
57. |
软件界面操作与同类产品相比，是否能够减少用户输入的频繁度； |
|
|
58. |
软件界面操作与同类产品相比，是否在出错预防机制和提示上更为直观、醒目； |
|
|
59. |
软件界面是否为特殊群体或是特殊的应用提供相应的操作机制（比如 Windows 的放大镜）； |
|
|
60. |
|
|
|
61. |
|
|
测试通例
转自http://www.cnitblog.com/Lily/archive/2006/08/29/16118.html
这个测试通例是针对某一系列产品而写的,针对性比较强,但也可以给大家一个参考吧。
|
序号 |
要 求 |
处 理 |
原 因 |
|
T1 |
界面基本信息 |
|
|
|
T1-1 |
界面标题是否正确？ |
是[ ] 否[ ] |
|
|
T1-2 |
界面主体文字是否正确？ |
是[ ] 否[ ] |
|
|
T1-3 |
界面主体文字大小是否合适？ |
是[ ] 否[ ] |
|
|
T1-4 |
界面主体文字颜色是否合适？ |
是[ ] 否[ ] |
|
|
T1-5 |
界面工具框按钮状态是否合适？ |
是[ ] 否[ ] |
|
|
T1-6 |
框架工具栏各种按钮的状态及有效性？ |
是[ ] 否[ ] |
|
|
T1-7 |
界面符合“界面设计规范”所要求的内容? |
是[ ] 否[ ] |
|
|
T1-8 |
在表单登记界面，工具栏新增、删除、刷新、打印、导出按钮是否有效。 |
是[ ] 否[ ] |
|
|
T1-9 |
在查询统计结果界面，工具栏打印、导出按钮是否有效。 |
是[ ] 否[ ] |
|
|
|
|
|
|
|
T2 |
Message(消息框) |
|
|
|
T2-1 |
各种弹出的Message的文字内容是否正确？ |
是[ ] 否[ ] |
|
|
T2-2 |
各种弹出的Message的类型是否正确？ |
是[ ] 否[ ] |
|
|
T2-3 |
各种弹出的Message的按钮是否合适？ |
是[ ] 否[ ] |
|
|
T2-4 |
各种弹出的Message的默认按钮是否正确？ |
是[ ] 否[ ] |
|
|
T2-5 |
各种弹出的Message的标题是否正确？ |
是[ ] 否[ ] |
|
|
T2-5 |
各种弹出的Message的标题是否正确？ |
是[ ] 否[ ] |
|
|
T2-6 |
各新产生之对话框、窗口等图标是否合适？ |
是[ ] 否[ ] |
|
|
|
|
|
|
|
T3 |
数据输入 |
|
|
|
T3-1 |
当界面要求用户输入数据时，进入界面时，是否聚焦到位于左上角位置的第一个输入框？ |
是[ ] 否[ ] |
|
|
T3-2 |
当任何一个输入框或输入表单中输入内容不正确并出Message时，点击Message的确认或其它相关Button时，是否Message框关闭并聚集到刚刚输入不正确的输入位置？ |
是[ ] 否[ ] |
|
|
T3-3 |
输入项是否对齐？ |
是[ ] 否[ ] |
|
|
T3-4 |
是TAB键决定焦点的跳转次序？ |
是[ ] 否[ ] |
|
|
T3-5 |
是ENTER键决定焦点的跳转次序？ |
是[ ] 否[ ] |
|
|
T3-6 |
焦点跳转次序是否从界面的左上角到界面的右下角，并一一合理跳转？ |
是[ ] 否[ ] |
|
|
T3-7 |
不能输入的地方，是否不能接受焦点？ |
是[ ] 否[ ] |
|
|
T3-8 |
所有规定的可以输入的地方是否都可以输入？ |
是[ ] 否[ ] |
|
|
T3-9 |
所有数据输入框能够输入数据的长度是否与数据库定义的长度一致？ |
是[ ] 否[ ] |
|
|
T3-10 |
必填数据项是否有标记？ |
是[ ] 否[ ] |
|
|
T3-11 |
数据输入框的长度是否基本能完整显示规定长度的数据？ |
是[ ] 否[ ] |
|
|
T3-12 |
必须输入数字的输入框，是否确认只能输入数字？ |
是[ ] 否[ ] |
|
|
T3-13 |
必须输入字母的输入框，是否确认只能输入字母？ |
是[ ] 否[ ] |
|
|
T3-14 |
必须输入时间的输入框，是否确认只能输入时间？ |
是[ ] 否[ ] |
|
|
T3-15 |
用户输入日期的格式是否一致？ |
是[ ] 否[ ] |
|
|
T3-16 |
当输入的时间不正确时，是否有出错Message或直接禁止这种错误输入？ |
是[ ] 否[ ] |
|
|
T3-17 |
当有数据对开始日期和结束日期时，当结束日期小于开始日期时，是否有出错Message或直接禁止这种错误的输入？ |
是[ ] 否[ ] |
|
|
T3-18 |
界面上的输入框的缺省值是否为最常用数据并符合逻辑要求？ |
是[ ] 否[ ] |
|
|
T3-19 |
界面上的输入框或输入表单的可输入值是否为常见的合理数据并符合逻辑要求？ |
是[ ] 否[ ] |
|
|
T3-20 |
当以表格方式输入时，各输入项的左、中、右对齐格式是否一致？ |
是[ ] 否[ ] |
|
|
T3-21 |
当以表格方式输入时，是以Tab还是Enter决定光标移动？ |
T [ ] E [ ] |
|
|
T3-22 |
当以表格方式输入时，光标移动次序是否合适？ |
是[ ] 否[ ] |
|
|
|
|
|
|
|
T4 |
数据检索 |
|
|
|
T4-1 |
单个条件检索出的结果是否符合检索条件？ |
是[ ] 否[ ] |
|
|
T4-2 |
多个条件检索出的结果是否符合检索条件？ |
是[ ] 否[ ] |
|
|
T4-3 |
数据列表时，缺省的排序是是否符合规定和业务逻辑？ |
是[ ] 否[ ] |
|
|
|
|
|
|
|
T5 |
数据维护 |
|
|
|
T5-1 |
当对数据库作增加记录操作时，数据库有关表中是否正确增加了记录？ |
是[ ] 否[ ] |
|
|
T5-2 |
当对数据库的重要数据作修改记录操作前，是否先给予有关提示信息让用户确认？ |
是[ ] 否[ ] |
|
|
T5-3 |
当对数据库作修改记录操作时，数据库有关表中的记录是否被正确修改？ |
是[ ] 否[ ] |
|
|
T5-4 |
当对数据库作删除记录操作前，是否先给予有关提示信息让用户确认？ |
是[ ] 否[ ] |
|
|
T5-5 |
如果删除数据时，会引起关联数据被删除，是否在Message中告知用户，提醒用户注意并加以选择？ |
是[ ] 否[ ] |
|
|
T5-6 |
当对数据库作删除记录操作时，数据库有关表中的记录是否正确删除？ |
是[ ] 否[ ] |
|
|
|
|
|
|
|
T6 |
功能Button |
|
|
|
T6-1 |
界面中的Button，是否能正确实现规定的功能？ |
是[ ] 否[ ] |
|
|
T6-2 |
Button上是否有快捷方式？ |
是[ ] 否[ ] |
|
|
|
|
|
|
|
T7 |
报表 |
|
|
|
T7-1 |
报表中，被打印出的数据是否正确？ |
是[ ] 否[ ] |
|
|
T7-2 |
报表中，被打印出的数据是否完整，有没有被截断的数据？ |
是[ ] 否[ ] |
|
|
T7-3 |
报表中，数据与表头左、中、右对齐是否一致？（一般数字右对齐，其它左对齐） |
是[ ] 否[ ] |
|
|
T7-4 |
报表中，被打印出的数据格式是否一致？（如日期是否全为YYYY-MM-DD） |
是[ ] 否[ ] |
|
|
T7-5 |
报表中，报表标题是否居中？ |
是[ ] 否[ ] |
|
|
|
|
|
|
|
T8 |
安装 |
|
|
|
T8-1 |
界面要求是否用本表“界面基本信息”部分检查过？ |
是[ ] 否[ ] |
|
|
T8-2 |
Message部分是否用本表“Message”部分检查过？ |
是[ ] 否[ ] |
|
|
T8-3 |
数据输入部分是否用本表“数据输入”部分检查过？ |
是[ ] 否[ ] |
|
|
T8-4 |
是否能成功安装？ |
是[ ] 否[ ] |
|
|
T8-5 |
安装是否方便简洁？ |
是[ ] 否[ ] |
|
|
T8-6 |
当安装人员处于较长时间等待时，安装程序是否给予正在处理的信息？ |
是[ ] 否[ ] |
|
|
T8-7 |
当需要安装人员选项时，选项内容说明是否明确？ |
是[ ] 否[ ] |
|
|
T8-8 |
当安装人员操作错误后，是否可以方便地借助Back按钮返回到上一步？ |
是[ ] 否[ ] |
|
|
|
|
|
|
|
T9 |
其它功能 |
|
|
|
T9-1 |
当多用户并行运行时，数据库操作是否正确？ |
是[ ] 否[ ] |
|
|
T9-2 |
进行单元测试时，测试用例不仅使用用一般的常规的用例，还要包括极端的测试例子？ |
是[ ] 否[ ] |
|
|
T9-3 |
不仅包括单侧极端用例（边界条件用例）还包括双侧极端用例（边界条件用例）？ |
是[ ] 否[ ] |
|
|
T9-4 |
对模块操作的权限设置是否符合要求？ |
是[ ] 否[ ] |
|
|
T9-5 |
是否用各种用户登录过，以便对模块中数据查询和数据操作权限进行测试并能实现权限要求？ |
是[ ] 否[ ] |
|
|
|
|
|
|
软件测评师考试（软件测试应用技术）
转自http://www.cnitblog.com/Lily/archive/2006/05/19/10812.html
测试项目管理
软件配置管理的作用：
通过软件配置管理，严格执行软件开发过程控制，使软件开发的各个过程阶段（）置于软件配置管理控制之下，真实地记录软件生命周期内的全部过程活动，使软件开发从无形变成有形，从无法管理变成有章可循。
通过软件配置管理，严格执行软件版本控制（），做到完整保存各种历史软件，有利于验证和比较测试、联试中出现的问题；严格执行软件更改控制，严格审批更动过程。
配置管理内容：确立基线；建立3库（开发库、受控库、产品库）；出入库管理和审计；状态报告和查询。
测试管理组包括评审小组、测试小组和支持小组。
软件测试过程分成4个阶段：单元测试、集成测试、系统测试和验收测试。
软件测试文档描述要执行的软件测试及测试的结果。
测试文件的类型：测试计划和测试分析报告。
测试文件的重要性表现在：
（1）验证需求的正确性；
（2）检验测试资源；
（3）明确任务的风险；
（4）生成测试用例；
（5）评价测试结果；
（6）再测试；
（7）决定测试的有效性。
软件工程领域要考虑的风险类型：（1）项目风险；（2）技术风险；（3）商业风险。
风险条目检查表：
（1）产品规模风险；
（2）商业影响风险；
（3）客户相关风险；
（4）过程风险；
（5）技术风险；
（6）开发环境风险；
（7）与人员数目及经验相关的风险。
易用性测试
在2003年颁布的GB/T16260-2003(ISO 9126-2001)《软件工程产品质量》质量模型中，提出易用性包含易理解性、易学习性和易操作性；即易用性是指在指定条件下使用时，软件产品被理解、学习、使用和吸引用户的能力。
（1）易理解性；（2）易学习性；（3）易操作性；（4）吸引性；（5）依从性。
易用性测试包括针对应用程序的测试，同时还包括对用户手册系统文档的测试。通常采用质量外部模型来评价易用性。包括如下方面的测试：
（1）易理解性测试；
（2）易学性测试；
（3）易操作性测试；
（4）吸引性测试；
（5）易用的依从性测试。
易用性测试方法有：静态测试；动态测试；动态和静态结合测试。
软件质量模型将质量属性划分为6种特性：功能性、可靠性、易用性、效率、维护性和可移植性。
易用性与可靠性是正相关的；易用性与安全性（功能性的子特性）的某些方面是负相关的。
安装测试的主要工作（安装的易用性）：
（1）安装手册的评估；
（2）安装的自动化程度测试；
（3）安装选项和设置的测试；
（4）安装过程的中断测试；
（5）安装顺序测试；
（6）多环境安装测试；
（7）安装的正确性测试；
（8）修复安装测试和卸载测试。
功能易用性测试：
（1）业务符合性；
（2）功能定制性；
（3）业务模块的集成度；
（4）约束性；
（5）交互性；
（6）系统信息与错误提示。
界面整体测试指对界面的规范性、一致性、合理性等进行测试和评估。
文档测试
国家有关计算机软件产品开发文件编制指南（）中共有14种文件，可分为3大类。
1． 开发文件：可行性研究报告、软件需求说明书、数据要求说明书、概要设计说明书、详细设计说明书、数据库设计说明书、模块开发卷宗。
2． 用户文件：用户手册、操作手册。
3． 管理文件：项目开发计划、测试计划、测试分析报告、开发进度月报、项目开发总结报告。
用户文档分类：联机帮助；样例、示例和模板；包装；宣传与广告；其他。
用户文档的作用：改善易安装性；改善软件的易学性与易用性；改善软件可靠性；降低技术支持成本。
用户文档测试方法：技术校对；功能测试；其他辅助方式。
用户文档测试要点：文档的读者群；文档的术语；文档的正确性；文档的完整性；文档的一致性；文档的易用性；样例与示例；文档的语言；印刷与包装质量。
用户手册、操作手册的测试：“严格”地使用系统；“随心所欲”地使用系统；尝试文档中的每个建议和注意事项；描述的准确性；从用户角度看手册。
联机帮助的测试：准确性、用户的查询；帮助主题的完整性；帮助的风格。
安全测试
软件安全性是与防止对程序和数据的非授权的故意或意外访问的能力相关的软件产品属性。软件安全性的测试包括程序和数据安全性的测试。
安全测试内容：用户认证机制、加密机制、安全防护策略、数据备份与恢复、防病毒系统。
安全测试策略：
（1）安全防护体系：实体安全、平台安全、数据安全、应用安全、通信安全、运行安全、组织安全、管理安全。
（2）安全保护国家标准：用户自主保护级、系统审计保护级、安全标记保护级、结构化保护级、安全域级保护级。
为保证实体、数据、平台、应用、运行等的安全，主要采用以下几种安全防护技术：防火墙、入侵检测系统、漏洞扫描、安全审计、病毒防治、Web信息防篡改。
安全测试方法：
主动发现方法：功能验证、漏洞扫描、模拟功能、侦听技术。