专注软件开发过程改进，质量管理、项目管理方面的研究，希望多多认识这方面的朋友，多多交流，共同进步！
我的最新日志
-
2008-3-20
很多人在应用vss的简单功能，但是对于VSS的分支合并功能，却很少应用。今天正好做了下vss的分支合并功能的测试。在此共享给大家！
一、测试步骤：1、建立两个vss目录，QA目录和Jessie目录（假设QA为公共源代码目录，Jessie为个人工作目录）
2、检入5种文件进QA目录：
.ini
.cpp
.h
.txt
.doc
3、然后再把五个文件托进“Jessie”目录，点击菜单上“branch...”确定后，进入分支开发状态；
4、修改“Jessie”下面的文件，将5个文件都chenck out进行修改，在最后一行新增或插入修改，然后check in；
5、进入“QA”目录下，分别选择每个文件，点击菜单上“merge branches... ”，出现提出框，此时vss匹配两目录下的文件，有3种情况：
if 文件类型是Vss不支持文件 then
提示不能合并
else 进行匹配，匹配结果有两种：
a.如果同名的两处文件不存在冲突，提示确认后，即可按照“Jessie”目录下的文件更新；
b.如果同名的两处文件存在冲突，系统弹出显示框，显示文件中的每处冲突位置和内容，这是需要人干预决定。
6、合并完毕，查看各文件内容，发现测试的ini、cpp、h、txt文件都能进行分支合并，但是doc这种binary类型的文件不能进行分支合并操作。
二、 vss分支合并操作的优缺点分析：
1、优点：分支合并操作简单，方便控制好权限，且能及时得到的工作产物；
2、缺点：分支合并操作支持的类型有限制，对binary类型的文件不支持；
多人修改同一文件的同一处，合并时，需要人工手工合并；
查看(130)
评论(0)
-
2007-12-28
老实说，以前做开发的时候，老是混淆集成测试和系统测试，两者概念总是不清不楚。不知道是否有人和我一样？
现在，看看下面简短两段话，就知道区别了：
集成测试：要确定集成的关键模块及其集成顺序，主要依据设计说明书来测试模块间的接口功能。
系统测试：要确定系统要执行的主要业务过程、用户接口、硬件接口、软件接口、通信接口等，主要依据需求规格说明书来验证产品功能。
查看(118)
评论(0)
-
2007-12-28
单元测试是测试过程中的最小粒度。如果单元测试做不好，使得集成测试或者后面系统测试的压力很大，而且可能需要发费更多的财力。
主要活动如下：
1、准备测试数据库
2、准备独立的单元测试代码
3、进行独立的单元测试
4、记录所有缺陷
5、关闭独立的单元测试
测试主要从如下几个方面考虑：
1、代码是否规范
2、代码是否注释
3、创建对象是否初始化，对象不用后是否释放
4、变量是否声明，声明是否按照要求进行，变量是否初始化
5、函数被调用时需要满足的条件是否注明
6、函数、过程是否正确，输出结果是否正确
查看(331)
评论(1)
-
2007-12-21
最近公司的所有开发人员回公司总部上班了，因此决定由质量部派人统一管理配置服务器用户及配置库用户。为此也需要制定一套流程。以下是我的草稿篇，在此共享，希望大家多提意见。
为了更安全、更方便的管理各项目配置库，公司决定由质量部统一负责各项目配置库的用户及权限设置。详见如下：
一、本流程适用人员：所有需要用到公司统一管理的配置服务器的员工；
二、本流程生效日期：从2008-1-1日正式生效；
三、本流程分以下四种情况介绍：
1、 项目新成员进入时：
a. 服务器开户：如果该员工在配置库服务器上没有用户，则由员工本人提出开户申请，经项目经理审核签字后，由配置管理员为该员工在配置库服务器上开户；
b. 配置库开户：由项目经理为新进员工填写《配置库用户变更申请表》，提出“开户”申请后，由配置管理员为该员工在该项目配置库上开户；
2、 项目离岗人员：
a. 配置库销户：由项目经理为离岗员工填写《配置库用户变更申请表》提出“销户”申请，由配置管理员删除该员工在该项目配置库上的用户；
b. 服务器销户：如果该员工离开公司，则由员工本人提出销户申请，经项目经理签字后，由配置管理员删除该员工在配置库服务器上的用户；
3、 项目内部角色变化人员
权限变更：由项目经理为担任角色发生变化的员工填写《配置库用户变更申请表》提出“配置库用户权限变化”的申请，交由配置库管理员按照要求重新设置该员工权限；
4、 项目里程碑变化时全体人员
在项目进入下一个阶段之前，由项目经理为项目内部的每个员工填写《配置库用户变更申请表》，由配置库管理员按照要求一一重新设置该项目内各员工的配置库用户及权限；
查看(77)
评论(0)
-
2007-12-21
之前一个朋友问起我，说做了那么多年开发，谈谈有些项目为何失败。朋友说
项目失败很大的原因是在合同问题，合同没有很好的列出项目范围。其实，合同的范围只是一般的范围，详细内容应该不属于合同的一部分。所以我觉得项目最大的问题还是
需求没做好。需求没有做好，主要表现在以下几个方面：
一、需求采集与分析
1、需求采集分析时，没有从完整的业务流程出发，容易关注主要业务需求，而造成次要业务需求块的遗漏。
之前检查了我们公司一个重要项目的需求做得咋样，光看需求提问单，就发现大部分问题是关于功能需求的。而问起业务需求时，他们说都很清楚了，但问起业务上细节处理时，大家都恍然大悟：“哦，这里需要再问下客户...”。
2、开发人员除了关注采集功能需求、外部接口需求、性能需求和一般的标准需求外，往往容易忽略系统领域的背景、操作环境需求、用户特殊需求（例如用户熟练使用的工具与方法）等。
二、需求定义与确认
需求规格说明书是将人们思想中的概念和目标转换成正式的文档，在这个过程中，很容易产生错误，例如表达不完整，不正确的事实，不一致或模糊的需求等。因此，一定要正确详细的进行需求定义与验证，确保规格化的内容确实是用户所需求的东西。
三、需求变更
需求变更管理有两个方面，一是与客户就怎样变更达成一致，一个是进行变更流程控制活动。在这两个方面都容易出错。
1、与客户达成一致方面，需要让客户意识到变更对项目影响的后果，要技巧性+友好性的将变更加入到协商条款中。在评估需求变更达到一定的影响时，要试图协商控制变更，以保证在需求变更下，项目可以继续成功。
2、变更流程控制活动，包括怎么进行变更请求，怎么进行变更批准等过程控制，还要考虑为处理变更估计留出时间等等方面的问题。这方面不遵循过程控制流程来走，很容易导致花大功夫补救的后果。
我们公司已经对变更没有做很好的控制，就吃了很多亏。我们项目组是驻客户所在地办公，开发人员经常接到客户电话来提出一些功能性的小变更，考虑到是小变更，又受“客户是上帝、提高客户满意度”等思想的影响，也就痛快答应，甚至当场修改程序发布。客户是高兴了，短期来看，效率高，而且还与客户打好关系。可长期来看，上此以往，这种行为就变成“没有跟客户计算成本”的花费，这还是小事，更严重的问题是，这种没有经过整体评估、影响分析、风险识别与分析的行为，有可能改了东家，拆坏了西家，到最后要花费更大的财力去弥补，吃力不讨好，更甚的后果是因为这些漏洞，迟迟拖延项目验收时间，从而导致项目失败。
查看(55)
评论(0)
-
2007-12-21
之前一个朋友问起我，说做了那么多年开发，谈谈有些项目为何失败。朋友说项目失败很大的原因是在合同问题，合同没有很好的列出项目范围。其实，合同的范围只是一般的范围，详细内容应该不属于合同的一部分。所以我觉得项目最大的问题还是需求没做好。需求没有做好，主要表现在以下几个方面：
一、需求采集与分析
1、需求采集分析时，没有从完整的业务流程出发，容易关注主要业务需求，而造成次要业务需求块的遗漏。
之前检查了我们公司一个重要项目的需求做得咋样，光看需求提问单，就发现大部分问题是关于功能需求的。而问起业务需求时，他们说都很清楚了，但问起业务上细节处理时，大家都恍然大悟：“哦，这里需要再问下客户...”。
2、开发人员除了关注采集功能需求、外部接口需求、性能需求和一般的标准需求外，往往容易忽略系统领域的背景、操作环境需求、用户特殊需求（例如用户熟练使用的工具与方法）等。
二、需求定义与确认
需求规格说明书是将人们思想中的概念和目标转换成正式的文档，在这个过程中，很容易产生错误，例如表达不完整，不正确的事实，不一致或模糊的需求等。因此，一定要正确详细的进行需求定义与验证，确保规格化的内容确实是用户所需求的东西。
三、需求变更
需求变更管理有两个方面，一是与客户就怎样变更达成一致，一个是进行变更流程控制活动。在这两个方面都容易出错。
1、与客户达成一致方面，需要让客户意识到变更对项目影响的后果，要技巧性+友好性的将变更加入到协商条款中。在评估需求变更达到一定的影响时，要试图协商控制变更，以保证在需求变更下，项目可以继续成功。
2、变更流程控制活动，包括怎么进行变更请求，怎么进行变更批准等过程控制，还要考虑为处理变更估计留出时间等等方面的问题。这方面不遵循过程控制流程来走，很容易导致花大功夫补救的后果。
我们公司已经对变更没有做很好的控制，就吃了很多亏。我们项目组是驻客户所在地办公，开发人员经常接到客户电话来提出一些功能性的小变更，考虑到是小变更，又受“客户是上帝、提高客户满意度”等思想的影响，也就痛快答应，甚至当场修改程序发布。客户是高兴了，短期来看，效率高，而且还与客户打好关系。可长期来看，上此以往，这种行为就变成“没有跟客户计算成本”的花费，这还是小事，更严重的问题是，这种没有经过整体评估、影响分析、风险识别与分析的行为，有可能改了东家，拆坏了西家，到最后要花费更大的财力去弥补，吃力不讨好，更甚的后果是因为这些漏洞，迟迟拖延项目验收时间，从而导致项目失败。
查看(49)
评论(0)
-
2007-12-14
I am free today, even it's my workingday. my boss is off duty for her sickness, and the work on my hand is oblidged to stop now. then, I have the time to write something and improve my english.
I'm try my best to define the work process about the user management of configuation database. and, I have finished two edition of it. but my boss is not satistied, and she said, she will give me a sample for me to follow. so,......I have to wait with patience...
anyway, it's saturday tomorrow, so happy,because I can enjoy three moives which being borrowed from one of my colleague. she is so kind to share it with me. i am so grateful.
so much for today ! happy weekend
查看(19)
评论(0)
-
2007-11-28
思考是人类最根本的资源，思考最大的障碍在于混乱。在Edward De Bono的《六顶思考帽》中强调的概念是，在同一个时间内只考虑一面事情。这样简化思考，才能有条理的思维。
蓝色思考帽blue thinking hat：象征着思维中的控制与组织。思考的控制、集中、程序设计、概要与结论、控制与监督。戴蓝色思考冒者，站在高处，总览所有意见。
红色思考帽red thinking hat:从感情、直觉感性地看问题。情绪和感觉、情绪在思考中的地位、直觉与预感、一时一刻之间、利用情感、情感的语言。戴红色思考帽者，只要说出自己的感觉，不需要为自己的感觉做辩解。
黑色思考帽black thinking hat：从事物的缺点、危险、隐患来看待问题。谨慎与小心、融合过程、过去和未来、过度使用的问题。戴黑色思考帽者，要谨慎的考虑风险、危险、障碍和潜在的问题，以及任何一项建立的负面因素。
白色思考帽White thinking hat:客观、全面地收集信息。事实与数据、谁的事实、日本式输入、事实、真理与哲学家。戴白色思考帽者，要客观中立的提出一级事实（已经验证的事实）和次级事实（待验证的事实）。
黄色思考帽yellow thinking hat:寻找食物的优点及光明面。正面思考，建设性思考、远见、 理由和逻辑证明。戴黄色思考帽者，会探寻事物的价值与利益，努力地为他们寻找合理的证明，并提出建设性和启发性建议。
绿色思考帽green thinking hat:用创新思维考虑问题。创造性思考、水平思考法、发展一个“种子”创意，细心灌溉，直至它形成一个成熟的计划，诱因起关键作用。戴绿色思考帽者，必须提出创造性意见，不要害怕被否决。
查看(32)
评论(0)
-
2007-10-19
今天在整理ppqa检查项，是关于测试计划与设计、测试执行这部分的。
好不容易整理完，也不知道是否完整与实用。在此分享给大家，请大家提出宝贵意见！
测试计划与设计的检查项：
| 测试计划 |
未见记录 |
| 是否说明了测试范围 |
| 是否说明了测试整体策略 |
| 是否说明了类型和测试阶段 |
| 是否说明了测试环境及工具 |
| 是否进行了测试用例、测试包、测试不同阶段的内容设计 |
| 是否说明了测试过程与管理说明 |
| 是否说明了测试产物 |
| 测试工作是否在mpp中安排并落实？ |
| 测试用例 |
操作步骤是否与描述相一致 |
| 操作步骤是否仅包含与被测项相关的内容，即没有多余的或不相关的内容 |
| 测试用例的期望结果是否是确定的、唯一的 |
| 测试用例是否可重用（对被测项的当前版本和后续版本） |
| 测试用例是否可跟踪（与测试需求相对应） |
| 测试用例执行后是否应将测试环境恢复到执行前的状态 |
| 测试用例是否有正确的名称和编号 |
| 测试用例是否标注有执行优先级 |
| 测试用例目的的描述是否包含该用例用于测试什么内容 |
| 是否包含了所采用的测试方法的描述 |
| 是否包含相关的配置信息：环境、数据、前置测试用例、用户授权等 |
| 操作步骤和期望结果应完整、一致、清晰 |
| 是否指明：系统返回的任何错误信息或屏幕快照需保存 |
| 用词规范、准确、一致 |
| 每个测试用例的操作步骤<=15 |
| 自动化测试脚本是否带有注释 |
| 自动化测试脚本的注释是否包含：目的、输入、期望结果等 |
| 场景测试用例的执行顺序是否符合实际的业务流程 |
| 场景测试用例是否覆盖最复杂的业务流程 |
| 对于由系统自动生成的输出项是否注明生成规则 |
| 对于查询和表格，是否设计了产生数据的用例 |
| 测试用例是否包含对中间和后台数据的检查 |
| 场景测试用例中是否包含每个业务流程环节的中止和回退相关的设计和组合 |
| 如果存在不可测需求，是否列出并进行说明 |
| 测试用例是否覆盖所有的测试需求 |
测试执行的检查项：
| 测试准备 |
每轮测试开始时测试环境是否准备好（包括软件硬件、测试基本数据等） |
| 每轮测试的测试产物是否准备好 |
| 测试环境（数据和程序）是否与开发分离，除了测试组之外其他人不能更新测试环境的数据和程序 |
| 是否每轮测试根据上一轮的情况和总体测试计划做分工调整 |
| 测试实施 |
是否对每一个测试包进行了测试，并保存结果 |
| 是否对每个测试用例进行了测试，并完整地记录了测试执行情况与结果 |
| 缺陷管理 |
测试管理表中缺陷数是否与与缺陷记录与汇总表中一致 |
| 对于每个BUG是否完整填写了缺陷信息 |
| 是否对每一个安排的缺陷进行了缺陷分析 |
| 测试总结 |
是否每轮测试结束后填写测试小结 |
| 对于每轮测试，是否完整填写了阶段及次数、测试物及测试要求、测试情况与结论等信息 |
| 需求跟踪 |
是否在跟踪矩阵中跟踪了测试的需求 |
查看(82)
评论(0)
-
2007-10-18
个人觉得，采用TD管理缺陷，确实为不错的方法。但是TD中缺陷的状态还是不够，若增加FIXING和RENEW两个状态，那就不错了。
NEW ： 被首次发现的缺陷；
RENEW ： 对于被拒绝的缺陷或者已修复的缺陷进行验 证后确定仍然为缺陷的缺陷；
OPEN ： 对于NEW状态的缺陷，分析后发布并已安排等待修复的缺陷；
REOPEN : 对于RENEW状态的缺陷，分析后发布并已安排等待修复的缺陷；
REJECTED ： 经分析后拒绝的缺陷；
FIXING ： 正在修复中的缺陷；
FIXED ： 已修复等待验证的缺陷；
CLOSED ： 已被关闭，该缺陷验证已修复的缺陷或者经识别后同意否决的缺陷。
查看(175)
评论(3)
