作者：sluke
发布时间：July 14, 2010
分类：劳动万岁
PC客户端软件的皮肤配置方式有很多种，简单说来就是如何把图片在屏幕上贴起来，从需求上看，可能要应对多套皮肤、多种配色、异型皮肤等等。有的软件选择将所有小图片放在一张大图上，有的软件喜欢用各种小图放在一个目录下，还有的采用了混搭的方式，这里讲的是第一种。
先放出一张结构图来，方便理解（点击查看大图）：
theme处于最顶层，同一个皮肤下可以有多个style，一个style下可以有多个layout和color_schemes（实际上限制每个style只有一个layout跟color_schemes更好理解）。
layout的子节点就很清楚了，通常软件会有很多个窗体，其中有一个是主窗体，其他是附加窗体；每一个窗体里会有不同的组件，比如一个播放器窗体里可能会有滚动条组件、列表组件、按钮组件；每个组件为了美观，可以被划分为若干个碎片，比如滚动条的控制柄或是滚动条的顶部花纹等等，当一个组件为按钮的时候，碎片就要表现按钮的多种状态，如鼠标按下、弹起、悬停、按钮不可用，
图片的定位采用了选择起始坐标+长宽的方式，也就是image_x,image_y设定某个按钮贴图的左上角坐标，通过计算长宽来确定整个贴图的区域。
简单写一个配置文件如下：
<?xml version="1.0" encoding="utf-8"?>
<theme name="default">
<style name="red" transcolor="#ff00ff">
<!-- layout-->
<layout>
<windows name="main_windows" image="backgroud.bmp" backgroudcolor="#fffff" width="200" height="200" image_x="200" image_y="200" tips="主窗体">
<module name="scrollbar" image="scrollbar.bmp" image_x="15" image_y="20" width="200" height="200" type="scrollbar" tips="滚动条">
<fragment name="scrollbar_top" tips="滚动条顶部">
<area state="1" name="normal" image_x="0" image_y="0" width="9" height="12" />
<area state="2" name="hot" image_x="9" image_y="0" width="9" height="12" />
<area state="3" name="pressed" image_x="18" image_y="0" width="9" height="12" />
<area state="4" name="disable" image_x="27" image_y="0" width="9" height="12" />
</fragment>
</module>
</windows>
</layout>
<color_schemes>
<class name="media_list_view">
<color name="focus_text_color" value="#FFFFFF" />
<color name="focus_text_backgroud_color" value="#FFFFFF" />
<color name="normal_text_color" value="#FFFFFF" />
<color name="hilight_text_color" value="#FFFFFF" />
</class>
<class name="lrc_view"></class>
</color_schemes>
</style>
</theme>
作者：sluke
发布时间：March 31, 2010
分类：劳动万岁
以前写过一篇《有这样一群用户——对拼音输入法的几点思考》，里面提到了将词典整合进输入法的需求，利用谷歌拼音的扩展，可以自己动手实现一个。
个人觉得汉英词典功能的实现障碍在于交互步骤多。拼音输入法是一个从字母到中文的过程，字母->中文备选->中文，中文是输入过程的终结点，实现汉英查询，就意味着要在中文之后再加两步，输入过程变成了字母->中文备选->中文->英文备选->英文，这是对正常输入过程的干扰。流行的搜狗输入法、谷歌输入法及QQ输入法等都为用户提供了I模式、U模式等功能入口，来避免扩展功能对正常输入的干扰，所以词典功能也可依此：
启动I模式->进入汉英词典功能->输入字母->中文备选->选中中文->英文备选->选中英文
谷歌拼音的I模式只能输入字母，以上流程便不能实现，不过API里有一个特别的函数，可以返回上一次输入的内容，即是
ime.get_last_commit()
利用词函数，可以变通实现，由于需要一个庞大的词库来处理，所以代码只给出思路如下：
--录入词库table
_C2E_={
["你好"] = {"hello", "hello2"}
["世界"] = {"world", "world2"}
}
--定义函数，返回翻译
function c2e()
return _C2E_[ime.get_last_commit()] --返回下标为前面输入的中文的table值
end
ime.register_command("fy", "c2e", "汉英翻译")翻译的过程变成先输入一个中文，然后启动I模式的翻译功能：
字母->中文备选->中文->i模式->翻译->英文备选词->英文
英汉词典同理完成，因为词典需要版权，这大概是各大输入法没有做翻译的一个主要原因吧，腾讯已经做了词典软件，接下来真可以实现带翻译功能的输入法。
PS：如能实现请求web接口来翻译的功能更好，就可以整句翻译了，不过代价是速度。
作者：sluke
发布时间：March 24, 2010
分类：劳动万岁
-- encoding: UTF-8
------------------------------------------------
--谷歌拼音用例助手扩展
--版本:0.1
--作者:sluke
--作者主页: http://www.luweiqing.com/
--
--简介:写用例时省点时间
--
--此扩展遵循GPLv2发布
------------------------------------------------
-- 定义一个table，写入需要用到的用例字段
_USECASE_ = {
[1] = {"用例名称：" .. "\n" .. "用例描述：" .. "\n" .. "相关需求：" .. "\n" .. "情境目标：" .. "\n" .. "前提条件：" .. "\n" .. "成功的结束状态：" .. "\n" .. "失败的结束状态：" .. "\n" .. "基础用例：" .. "\n" .. "包含用例：" .. "\n" .. "主行为者：" .. "\n" .. "从行为者：" .. "\n" .. "触发器：" .. "\n" .. "主要流程：" .. "\n" .. "扩展流程：" .. "\n" .. "备注："},
[2] = {"Use Case Name:" .. "\n" .. "Use Case Description:" .. "\n" .. "Related Requirement:" .. "\n" .. "Goal In Context:" .. "\n" .. "Preconditions:" .. "\n" .. "Successful End Condition:" .. "\n" .. "Failed End Condition:" .. "\n" .. "Base Use Case:" .. "\n" .. "Include Use Case:" .. "\n" .. "Primary Actors:" .. "\n" .. "Secondary Actors:" .. "\n" .. "Trigger:" .. "\n" .. "Main Flow:" .. "\n" .. "Extensions:" .. "\n" .. "Comments:"},
}
function Usercase(i)
if #i<=0 then
return {
{suggest = "en", help = "English"}, -- suggest 赋值需要是小写字母，没有空格及符号
{suggest = "cns", help = "简体中文"},
}
elseif i == "en" then
return _USECASE_[2]
elseif i == "cns" then
return _USECASE_[1]
else
return _USECASE_[2]
end
end
ime.register_command("yl", "Usercase", "用例助手", "帮助输入用例模板")以上代码保存为usecase.lua，添加到google拼音的扩展里。进入i模式，输入yl即可，可以输出两个预置的用例模板，如下:
英文
Use Case Name:
Use Case Description:
Related Requirement:
Goal In Context:
Preconditions:
Successful End Condition:
Failed End Condition:
Base Use Case:
Include Use Case:
Primary Actors:
Secondary Actors:
Trigger:
Main Flow:
Extensions:
Comments:
中文
用例名称：
用例描述：
相关需求：
情境目标：
前提条件：
成功的结束状态：
失败的结束状态：
基础用例：
包含用例：
主行为者：
从行为者：
触发器：
主要流程：
扩展流程：
备注：
PS:清华大学出版社的《UML2.0学习指南》，翻译有点瑕疵
作者：sluke
发布时间：March 18, 2010
分类：劳动万岁
本文涉及windows环境中软件测试的基本点，是我在实际工作中的一些体会，有兴趣的可以往下读，欢迎补充讨论。
目的：
首先是找出软件错误，然后才是证明软件质量。
测试人员：
最好是非开发人员。
测试时间：
1、随时
2、模块完成
3、软件整体编译完成
测试文档：
1、用例文档。走流程，确认基本操作无问题。
2、纠错记录。将bug分类归档，容易发现开发人员的弱项，进而更容易找到bug。
Bug分类（简单分类）：
1、与操作系统交互的底层
2、功能处理的逻辑层
3、与用户交互的表现层
Bug定义：
1、正确输入未能正确输出
2、错误输入未能处理
3、做了多余的事和没做该做的事
4、模块之间互动有误
测试环境：
1、与大部分用户一致的环境
2、底层差别大的环境
（特别指出：需要联网的软件测试更为复杂，除考虑不同版本windows之外，还需要考虑不同版本IE、Mediaplayer、.net frame，以及不同ISP环境、是否通过代理联网、不同防火墙及杀毒软件环境、是否安装有同类软件等等等等）
测试方法：
1、按用例及功能列表走流程（从无数据的初始状态开始）。主要验证功能是否完整，是否正确处理。
2、极限值测试。输入极限值或超出极限值，验证逻辑是否完整。
3、意外中断测试。中断网络或数据输入（输出），验证软件稳定性。
4、对象缺失测试。抽离某个承载正在运行功能的对象，验证软件稳定性。
（Bug呈现集中的趋势，一处bug往往产生多处bug，该bug所属及关联模块也易出问题）
测试内容：
1、安装及卸载
2、安全测试
3、负载测试
4、性能测试
5、功能完整性测试
如果是没有配备专业测试人员的团队，项目经理或产品经理最好能了解一些技术，做到准确描述问题。
---------------------------------------------------
201008119补充来自阿里云-Murdoc的bug分级
Urgent （V级）
1.操作系统无法正常使用，死机。出现致命错误（505）。
2.数据丢失
3.被测试系统频繁Crash，程序崩溃或出错，使功能不能继续使用
4.性能与需求不一致
5.系统资源引发性能问题
6.系统配置引发错误
7.安全性问题
Very High（IV级）
1.功能与需求不一致，或未实现功能
2.功能有错误，影响使用
3.传输数据有错误
4.安装与卸载问题
High（III级）
1.功能有错误
2.不影响功能使用
3.界面错误
4.边界条件出错
Medium（II级）
1. 界面设计不规范，用户界面错误，消息，提示不够准确，人机交互不友好
需求缺陷
初级（I 级）
1.设计问题.软件设计有问题；文档不完整或不准确
2.需求UC冻结后，描述不清楚的地方
-----------------------------------分割线------------------------------------------
想到之后继续补充本文。
作者：sluke
发布时间：October 20, 2009
分类：劳动万岁
这篇日志，是为了纪念几年前一段狂热试用开源程序的日子……
想做小白鼠，试用最新版本的程序，就需要每天访问各种程序的官方网站，看是否有更新，过去我是通过订阅程序官方的博客或邮件列表来达到及时关注的效果，这是一个费时费力的过程，而且并不是所有程序都有博客或是邮件列表。于是我就构思了一个小工具网站，用于自动检测各种程序更新。
核心的机制是通过监测程序的发布网页（尤其是程序下载页的更新）是否有变化，来判断程序是否有更新（当然这样并不精确，所以在网站用语选择上，使用“可能”这样的词）。
一、监测机制
1、RSS监测，这个没什么好说明的
2、Page2RSS，利用这个工具把网页转成RSS来检测
3、监测网页的MD5值是否有变化，需要把整个网页load到服务器，消耗比较大
4、对于开源程序，最好不过的方式是检测SVN的更新，还能获取到更新日志，效果佳
5、托管在google code、sf.net上的项目，单写规则监测，能获取更优质的信息，例如监测typecho的update list
二、展示机制
首页：
将被监测的程序分为两种，在显示时略有区别
1、有SVN，能获取到详细信息的
2、只能监测到可能更新的
采用按最后一次监测到更新的时间倒序排列，同日更新的按收录顺序排列，就像是一个冒泡算法，有更新的会排到前面。用于大致如下：
“XXX日检测到XXX程序可能更新”
程序展示页：
这里还说产生一个需求，就是想进一步了解某一个程序，这就需要有一个单独程序展示页，包括程序简介以及采集网络中对该程序的评价（通过采集blogsearch.google.com的搜索结果实现，缺点在于可能会有重复信息，优点是自动更新，质量由google去保证，最大限度减少人工）。
三、程序实现
这里我实际上构思了两种实现方式：
1、单独写一个程序。优点是简单，确定是不方便编辑，需要做个后台管理部分
2、改造博客程序实现。优点是管理方便，缺点是冗余
单独程序实现包括两个部分：
1、程序
包括
1.1 index.php
功能：判断是否需要更新，并导入一个html显示，下面用伪代码写一下思路：
<?php
//导入一个记录上次更新时间的txt文件
import lastUpdateTime.txt;
//获取当前服务器时间
getNowTime();
//判断是否需要更新，7200是时间，超过2小时即可更新
if NowTime>lastUpdateTime+7200{
//导入监测更新的程序
import checkUpdate.php;
}
//不需要更新则导入一个事先生成的html，可以减少数据库查询
import display.html;1.2 last_updateTime.txt
功能：记录上次更新时间的txt文件
1.3 check_update.php
功能：根据监测类型监测程序是否更新，并写入数据库，需要分组，避免超时，以下是伪代码表明思路：
<?php
//数据库连接及操作
function updatebase(){}
//监测RSS的函数
function checkRSS(){
if 程序更新==true {
将更新时间写入数据库;
}
}
//监测网页MD5的函数
function checkPageMD5(){}
//监测SVN的函数
function checkSVN(){}
//监测google code的函数
checkGooglecode(){}
if checkType==RSS{
checkRSS();
}
elseif checkType==MD5{
checkMD5();
}1.4 update_comments.php
功能：获取以程序名为关键词的google blogsearch结果，并采集到评论表里，供程序展示页使用，需要分组，避免超时，以下是伪代码表明思路：
<?php
//数据库连接及操作
function updatebase(){}
//取出程序名称，提交搜索并获取结果
function getBlogsearch(){
//获取程序名称
getSoftTitle();
//提交搜索并获取结果
getBlogsearch(){
return $blogTitle, $blogSummary, $blogURL;
}
//取出已有评论的URL与新获取的URL比较，去重
removeRepeat();
//写入数据库
writeDatebase();
}1.5 writePage.php
功能：取出数据库内容，生成html，供首页显示，以下是伪代码表明思路：
<?php
//取出数据
getSoftDate();
//写入html
writePage();
1.6 index_content.html
功能：首页内容，供index.php调用
1.7 display_soft.php
功能：显示程序展示页
2、数据库设计（简表）
2.1 soft表
字段：
softID 标识录入程序ID 数值
softTitle 程序名称 文本
softSummary 程序简介 文本
softURL 官方地址 文本
checkURL 监测地址 文本
checkType 监测类型 数值
2.2 comment表
字段：
commentID 标识评论ID 数值
commentURL 评论来源URL 文本
content 评论内容 文本
contentBlogTitle 评论来源博客名称 文本
contentBlogURL 评论来源博客URL 文本
softID 标识从属程序ID 数值
上面就是单独写程序的构思，还有一种改造博客程序的实现方式，原理差不多，就是需要写监测程序的功能和加入评论内容的功能。
多一句嘴，已经有网站很好满足了我最初构思这个工具网站的需求。http://chkversion.com/
- 1
- 2
- 3
- 4
- ...
- 10
- »
