博文
软件测试---白盒测试指南（三）(2007-06-27 12:44:00)
摘要：
TT15
类命名
第一个字母大写的英文正常语序
每个功能点的主程序（通常继承系统管理框架）统一采用ClientUI类名称。
业务逻辑代码类以BO结尾，如：GeneralLedgerBO
数值对象类以VO结尾，如：EmployeeVO
数据管理对象类以DMO结尾，如：EmployeeDMO
查询对象类以QO结尾，如：EmployeeQO
非参照对话框类以Dlg结尾，如：EditEmployeeDlg
参照对话框类以Ref结尾，如：WorkCenterRef
面板类以Panel结尾，如：GeneralLedgerPanel
TT16
接口
接口名的开头加上字母‘I’前缀
从第二个字母起，用首字母大写的英文单词描述
TT17
方法
1．是否正确定义了此方法（包括修辞词、返回类型、参数、参数类型）
2．注释是否清楚
3．命名是否正确：
l 方法函数名的第一个单词小写，后面的单词第一个字母大写；
l 第一个单词必须是动词，使函数的意义清晰明了；
l 存取对象的属性使用setXXX()和getXXX()函数形式
l 访问布尔类型的属性可以使用isXXX（）函数
TT18
类属性
Ø 所有类属性全部以m_开头，同其它变量区分开。
Ø 集合类......
软件测试---白盒测试指南（二）(2007-06-27 12:44:00)
摘要：具体实施方法：
8.1). 各层公用问题：
序号
测试项
测试内容
质量保证标准
问题属性
出错频率
T1
代码与设计对照
按需求、UI,CRC设计文档与编码对照,看是否完全地实现了所有的UI设计文档和CRC卡中规定的内容？
完备性
错误
T2
代码与设计对照
按需求、UI,CRC设计文档与编码对照,看是否创建了所需的数据库或其他初始化数据文件？
完备性
错误
T3
参数
返回值
方法中被传递参数的类型、个数、顺序及返回值是否正确？以符合UI设计文档和CRC卡为准。
正确性
错误
T5
参数的传递
当方法需要调用其它方法时，调用的参数是否正确？（UI设计文档和CRC卡中有调用说明）
正确性
错误
T6
命名
是否按《命名规范》进行了类、方法、变量、属性的命名？
正确性
错误
T7
公式
代码中的公式是否使用了设计文档中的相应数学公式。
正确性
错误
T8
注释
注释是否使用简洁明了的语言对每一个方法都进行了充分必要的描述？是否对复杂的代码进行了注释？当程序的运行是受某些特殊因素限制时，是否做了限制注释？是否列出限制模块运行特性的全部特殊因素？
易理解性
缺陷
T9
冗余语句和变量
是否存在永远执行不到的语句和变量，而降低了程序的可理解性？
易理解性
缺陷
T10
程序是否冗余
对于程序中的大量重复内容，是否使用了专门的类来实现？
可验证性
缺陷
T11
代码整体规范
是否自始至终使用了《程序员开发手册》和《编码规范》中要求的格式、调用约定、结构等？
一致性
缺陷
T12
代码与书写注释
在一个函数内代码的长度不允许超过100行。建议如果一个函数的代码长度超过一个屏......
软件测试---白盒测试指南（一）(2007-06-27 12:41:00)
摘要：软件测试----白盒测试指南
（说明：此白盒测试指南主要给白盒测试人员提供一些基本的白盒测试方法和技术，由于涉及的问题广泛，测试内容中的细节不一定准确和完整，还有待于各位的共同参与和不断完善，欢迎多交流！）
目的
本方案主要实施NC产品程序代码的白盒测试。使界面符合设计规范，适用于用户；保证程序创建的类与接口的完整与正确，以及程序模块单独正常运行。保证局部模块功能完备性，运行正确性与稳定性。
测试项
所要测试的类。如：
nc.ui.bd.*
nc.bs.bd.*
nc.vo.bd.*
测试依据
1.NC产品需求报告；
需求规格说明书、用例描述清单
2.设计文档；(OOA、OOD、CRC卡)
如：AOM（Analysis Object Model）表示类间的静态关系，是多个相关的用例共用的。
ASD（Analysis Sequence Diagram)是按业务工作的顺序表示每一工作步骤执行时类间的动态关系。一个用例对应一个ASD。
CRC （Collaborators & Responsibilities Card）卡是一个类的完整表述
3.界面规范
4.编码规范
5.开发命名标准
通过的准则
1.界面测试通过的标准：界面的样式、大小、颜色、整体布局的设置；各种标签控件的使用及主题描述以及事件源控件的使用、快捷键使用都应符合《NC系统应用框架需求报告》和《设计文档的相关规范》。
2.程序代码通过的标准：创建的类、接口、方法、属性应与《设计文档》保持一致；程序的各种命名、注释、代码行的格式等应符合《程序开发命名标准》和《编码规范》；程序模块能独立稳定运行。
测试环境配置
1．测试工具：
2．软件环境：
Client端：
操作系统：中文WINNT/2000
开发环境：VA3.5 专业版
待测试的源码包
Server端：
&......
结构图的基本原则(2007-05-01 16:15:00)
摘要：结构图的基本原则
-----结构图中的每一个矩形表示程序员编写的函数,不包含标准C/C++函数
-----矩形的名称是传达函数的作用的智能名称;它是函数编码中使用的名称
-----函数图只包含函数流程.不表明代码
-----相同函数用交叉的平行线画出阴影,或是在矩形的右下角绘出阴影来表示
-----当相同的调用出现在程序中时,在结构图中显示它们,如果它们包含子函数调用,只 要 显示一次完整的结构
-----数据流和标记是可选的.在使用时,应当给它们命名
-----输入流和标记在垂直线的左边显示;输入流和标记在右边显示
......
十大热门语言汇集(2007-04-20 22:03:00)
摘要：掌握一些编程语言可让您在职场竞争中收放自如，而扎实的技巧将会让您炙手可热。但是，语言种类繁多。很多开发人员掌握多种语言，懂得在合适的地方合适的时间使用正确的语言，而大多长期从事编程的人员会告诉您周期性的学习新的语言是成为一名优秀成功的网络开发人员的重要步骤。
圣地亚哥的软件工程公司Interknowlogycom的CEO Huckaby说:“我的一位老师曾说编程语言就是一门语言。它与你是否为一个好的编程人员无关，仅仅就是语法。”
但是，Huckaby还说当他的公司运行尚未稳定时，他几乎没有时间来寻找新成员，即便是只懂得某种特定语言的入门级新成员。“我们疯狂雇人，但是那并不容易。我们只是寻找那些刚出校门的有良好天赋的新手，他们只需了解.net 或Java，因为这样我们可以对他们进行.Net的培训。”Huckaby如是说。
Grandview Systems软件开发主管Wayne Duqaine说:“不要只停留在一两种语言上。我在1969年刚入行的时候，Fortran、Cobol和S/360 Assembler是敲门砖。而10年后，一些新的语言又流行开来。就最近一次统计，在过去30年中，我学习掌握了超过24种不同语言。”
以下，我们选取了10种编程语言进行比较，为您寻找更有挑战的工作提供参考。
1. PHP
基本描述:一种开源，工作在服务器端，跨平台，使用HTML脚本的语言，因为可置入HTML页面，因此尤其适用于网页制作。
学习理由:使用十分广泛。“借助缓存高速调用脚本，并使用编译代码插件来增强效果是今后趋势所在。使用C或COBOL创建Web应用程序是不可行的。
2. C#
基本描述:一种通用编辑，面向对象的编程语言，由微软作为其.net计划的一部分开发而成，包含C和C++。
学习理由:是.Net框架的基础部分。Duquaine说:“如果您大量使用Microsoft的产品，那么学习C#是十分有必要的。”
3. AJAX (同步 JavaScript 与 XML)
基本描述:虽然从技术上来说，这并非一种编程语言，但是AJAX使用XHTML或HTML，JavaS......
软件用户界面设计规则(2007-04-15 15:22:00)
摘要：软件用户界面设计规则
--------------------------------------------------------------------------------
用户界面设计基础
不必成为创建用户界面的艺术家--大多数用户界面设计的原则，与任意一门基础艺术课中所讲授的基础设计的原则相同。构图、颜色等的基本的设计原则，就像它们应用在纸张或油画上一样，也能很好地在一台计算机的屏幕上应用。虽然Visual Basic能通过简单地将控件拖动并放置到窗体上而使得创建用户界面非常容易，但是，在设计之前稍微计划一下就能使应用程序的可用性有很大地改观。可能需先在纸上画出窗体开始设计，决定需要哪些控件，不同元素的相对重要性，以及控件之间的关系。
构图
应用程序的观感与感觉窗体的构图或布局不仅影响它的美感，而且也极大地影响应用程序的可用性。构图包括诸如控件的位置、元素的一致性、动感、空白空间的使用以及设计的简单性等因素。控件的位置在大多数界面设计中，不是所有的元素都一样重要。仔细地设计是很有必要的，以确保越是重要的元素越要很快地显现给用户。重要的或者频繁访问的元素应当放在显著的位置上，而不太重要的元素就应当降级到不太显著的位置上。在大多数语言中我们习惯于在一页之中从左到右、自上到下地阅读。对于计算机屏幕也如此，大多数用户的眼睛会首先注视屏幕的左上部位，所以最重要的元素应当放在屏幕的左上部位。例如，如果窗体上的信息与客户有关，则它的名字字段应当显示在它能最先被看到的地方。而按钮，如"确定"或"下一个"，应当放置在屏幕的右下部位；用户在未完成对窗体的操作之前，通常不会访问这些按钮。把元素与控件分成组也很重要。尽量把信息按功能或关系进行逻辑地分组。因为他们的功能彼此相关，所以定位数据库的按钮应当被形象地分成一组，而不是分散在窗体的四处。对信息也是一样，名字字段与地址通常分在一组，因为它们联系紧密。在许多情况下，可以使用框架控件来帮助加强控件之间的联系。
界面元素的一致性
在用户界面设计中，一致性是一种优点。一致的外观与感觉可以在应用程序中创造一种和谐，任何东西看上去都那么协调。如果......
界面设计与测试规则(2007-04-15 15:16:00)
摘要：界面设计与测试规则
界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。目前界面的设计引起软件设计人员的重视的程度还远远不够，直到最近网页制作的兴起，才受到专家的青睐。而且设计良好的界面由于需要具有艺术美的天赋而遭拒绝。
目前流行的界面风格有三种方式：多窗体、单窗体以及资源管理器风格，无论那种风格，以下规则是应该被重视的。
1：易用性：
按钮名称应该易懂，用词准确，屏弃没楞两可的字眼，要与同一界面上的其他按钮易于区分，能望文知意最好。理想的情况是用户不用查阅帮助就能知道该界面的功能并进行相关的正确操作。
易用性细则：
1):完成相同或相近功能的按钮用Frame框起来，常用按钮要支持快捷方式。
2):完成同一功能或任务的元素放在集中位置，减少鼠标移动的距离。
3):按功能将界面划分局域块，用Frame框括起来,并要有功能说明或标题。
4):界面要支持键盘自动浏览按钮功能，即按Tab键的自动切换功能。
5):界面上首先应输入的和重要信息的控件在Tab顺序中应当靠前,位置也应放在窗口上较醒目的位置。
6):同一界面上的控件数最好不要超过10个，多于10个时可以考虑使用分页界面显示。
7):分页界面要支持在页面间的快捷切换，常用组合快捷键Ctrl+Tab
8):默认按钮要支持Enter及选操作，即按Enter后自动执行默认按钮对应操作。
9):可写控件检测到非法输入后应给出说明并能自动获得焦点。
10):Tab键的顺序与控件排列顺序要一直，目前流行总体从上到下，同时行间从左到右的方式。
11):复选框和选项框按选择几率的高底而先后排列。
12):复选框和选项框要有默认选项，并支持Tab选择。
13):选项数相同时多用选项框而不用下拉列表框。
14):界面空间较小时使用下拉框而不......
软件界面设计规则(2007-04-15 15:15:00)
摘要：优秀界面设计规则清单：
软件的安装很容易，步骤最少；
软件的安装不要求系统重新启动；
在使用软件前，用户不需要阅读自述文件和帮助文档；
用户生成的数据默认存储在“我的文档”中；
对于用户能够看见的文件，软件没有使用意义很模糊的名称；
软件没有在program files文件夹之外创建文件夹；
软件没有向硬盘的根目录写入文件；
软件没有在“开始”菜单上包括其“帮助”、“自述文件”和“卸载”等项目；
如果没有用户的允许，那么软件不会在Windows桌面上安装图标；
如果软件在启动时运行，那么它在加载时不会显示屏幕和对话框；
软件不任务栏通知区用于状态，启动软件或实用工具或询问属性，而是只使用通知区域来警告用户有一个重要的改变；
软件应该适当地应用用户在“控制面板”的“显示”程序中指定的颜色选项；
可以通过键盘使用软件；
如果用户改变增大了默认字体的大小，那么软件也可以正常的工作；
软件适当的支持标准键盘的快捷方式；
软件的卸载过程不会留下除用户创建的文件之外的其他的文件或注册表项目；
软件没有在用户界面上的文本中使用专门的术语，而是只有在用户清楚地了解特定的工业或技术术语时才使用它们；
当用户更改显示分辨率或使用多个显示器配置时，软件可以适当地进行调整；
一般情况下各种色彩给人的感觉是：
红色：代表热情、活泼、热闹、温暖、幸福、吉祥
橙色：代表光明、华丽、兴奋、甜蜜、快乐
黄色：代表明朗、愉快、高贵、希望
绿色：代表鲜明、平静、和平、柔和、安逸、青春
蓝色：代表深远、永恒、沉静、理智、诚实、寒冷
紫色：代表优雅、高贵、魅力、自傲
白色：代表纯洁、纯真、朴素、神圣、明快
灰色：代表忧郁、消极、谦虚、平凡、沉默、中庸、寂寞
黑色：代表崇高、坚实、严肃、刚健、粗莽......
软件调试的十大重要基本准则(2007-04-14 19:31:00)
摘要：本文是在David J. Agans所著Debugging: The Nine Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems的基础之上写的。在书中，David罗列了他从实际经验中总结出来的9条debug原则。我希望大家都能读一下这本书。该书篇幅短、且通俗易懂，还穿插了一些有趣的故事。不过，还是有些开发人员不愿意花时间去看这样一本薄薄的书，所以我想对这本书的内容做一个总结还是有意义的。
我增加了第十条准则——debug数据。十个基本准则包括:
1、debug数据（Debug the data）——检查数据是否是你所期望的
2、了解系统（Understand the system）
3、制造失败（Make it fail）——重复制造问题
4、不要想、而要看（Quit thinking and look）——不要急匆匆地下结论
5、分而治之（Divide and conquer）——缩小除虫范围。
6、一次只改一个地方（Change just one thing at a time）
7、坚持做复查（Keep an audit）
8、先找明显的bug（Check the obvious first）
9、询问其他人（Ask someone else）——询问朋友或同事，因为阐明一个问题有助于你理清头绪，并集中精力找到问题所在。
10、 如果你不解决问题，问题将依然存在（If you didn't fix it then it's not fixed）——Bug不会自己消失，需要你来解决。
更多内容，请见http://www.gipsysoft.com/articles/debug-rules/......