我向来不齿对金融危机做任何评判，因为穷困的时候有穷困的过法，富裕的时候有富裕的过法。作为投资人来说，不能把鸡蛋都放在一个篮子里。我很庆幸自己是有信仰的人，不为贪欲所动。因此对中国的股市来说，我从来就没有做过一点“贡献”。尽管我对经济学感兴趣，特别是行为经济学，但是我不会违背自己的理性去做常人做的贪婪的事情。 因为我相信，“真理”向来掌握在少数人手中。否则，心理学中为什么叫所谓的广大群众为“乌合之众”呢。

谈及金融危机，或是中国股市，蒸发的钱到哪里去了，我也谈谈自己的看法。

首先是定性，这次经济危机的罪魁祸首不是过度消费，而是金融衍生工具。

狭义上的钱是黄金储备和流通的货币，流通的货币之所以具有价值可交换性，是因为大家都认可它，它具有信用。津巴布韦的货币因为过度膨胀，大家不认可，所以失去了价值可交换，大家都用物物交换或是使用外汇，因为它稳定，不贬值。

于是乎，我们把一切具有信用的东西都当做钱或钱的等价物来使用，我们称之为广义货币。股票，期货….等等，如此一来，就会造成市面的货币总量爆增。尽管股票、期货、贷款等不能作为钱直接买东西，但是我们通过股市或是银行可以将其进行转化为狭义货币，这样一来，通货膨胀就不可避免了。谁从中发了财？当然是发行广义货币并将其迅速转化为狭义货币的人，在中国叫做庄家。

发行的股票多了，股价涨高了，大家趁势而入，到了一定的时候，这时有个傻小孩跳出来了，说“现在的股票根本不值这个钱”，于是大家的心理防线崩溃了，单位股票的价值就跌倒了津巴布韦元的水准，于是大家这才发现身上的钱包没钱了，钱全归庄家了。原来，信用（心）这个东西海这么“值钱”。这时候，大人物这时只能跳出来，用信心喊话，要求大家恢复信心，也就是恢复广义货币的原有价值。

现在你该了解金融衍生工具是干什么的了吧，就是专门制造广义货币的机器。老美的证交所干的就是生产全世界通用广义货币的行当，最富的庄家都在那里。

接下来还有一个罪魁祸首，也是金融衍生工具的一份子，这就是“乘数效应”

经济学上有乘数效应，这个效应说明了，通过一块钱的消费可以带来超过一块钱的消费。说白了，比如房地产，你买房了，肯定要买家具，这是多出来的消费。接下来还有呢，盖个大商场，又拉着你去消费，接着你又要买车，修车，买汽油，你的房子水电煤都需要消费等等，所以知道为什么全世界的政府都要扶持房地产了吧。税收是一个因素，关键是它能创造多少就业岗位和就业机会，能够拉动内需消费，也是最为人们所认为最具有信用（保值）的一个投资。

银行呢，根据乘数效应开发了贷款，叫做“准备金（储备金）”，它在只有15元或是20元的货币储备时，就能给你贷款100元。你也许会想，它从哪里拿100元的货币给你？着你就错了，因为所有人都不会一下子从银行提100元出来，这叫资金周转。你的贷款就通过乘数效应这个金融工具给“虚拟”出来了，银行的存款和贷款间于是就可能是1：5，1：6甚至更高。当大家都不相信银行时，蜂拥去挤兑，银行于是就垮了。这同样适合于做贷款担保的保险公司，于是老美的几家银行和保险公司就这样倒了。

最后讲讲货币流量，货币流量有个公式：mv＝pq，这4个字母分别代表：

M货币需求量

V货币流通速度

P商品价格

Q商品量

在经济景气的时候，各种金融衍生工具加速了货币的流通速度。而现在银行之间不再互相借钱了，流通速度马上就慢下了。即使货币供应量增加，仍然不足以防止商品价格或者GDP的急剧下降，这就是为什么政府注资也不能马上起效的原因表达。所以说，蒸发的钱到哪里去了？一、庄家的口袋里；二、被我们的信心（用）给消耗掉了。谁是罪魁祸首：金融衍生工具。

 

本博客除特别注明的文章外，均为博主本人所作，版权所有，转载请说明出处；

   【学赛主持人】:
   聊天现在开始，先请我们的嘉宾与大家打声招呼吧。

   【学赛嘉宾/张华】:
   诸位好，非常高兴和你们在经济危机这样一个大环境下交流职业规划的问题。

   【学赛嘉宾/张华】:
   【问】: 网友[zbstar] 说: 我想请教：40岁的人如何进行职业规划？也就是说在这个年龄段，IT人如何面对转型？谢谢！
   【答】: 35岁-40岁，是一个令IT人彷徨的年龄段，是一个职业方面的瓶颈阶段。
   首先，最需要的是保持平和的心态；
   其次，要了解职业瓶颈产生的原因。首先从自己入手，在一个公司里，岗位越往上提升，对自身综合能力的要求就越高，如决策力、洞察力、业务知识、人脉、客户资源等方面等就需要再次提升一个档次。其次从公司原因入手，不管是什么企业，分工比较清晰，人员比较稳定，职位上做到某个阶段之后，便自然而然无法再有突破了。
   如果因为自身原因造成自己面临职场瓶颈期，最主要的任务是根据自身的具体情况，有意识地进行充电。当然，要把握好时间节点。如果是公司原因，你可以尝试一些新的机会。
   当然，35岁及以上的人照样能够做好IT，不过你的工作方向应该有所转变，即角色定位应该有所改变。对于希望走技术路线的人，可以总结你的技术经验和业务经验，梳理自己的技术知识。从项目参与者的角色转变为指导者的角色，我相信你公司的老板一定会喜闻乐见你的变化。对于从事项目管理的人员来说，需要更上一层楼，学习企业管理的相关知识，扩大社交范围，获取更多的社会资源。这对于你本身和公司来说，都是一个“增值”的过程。你的角色转化应该立足于“增值”这一个点上去。
   可以这样说，对于这个年龄阶段的人，你要怀着一种“增值”的目的和思路去规划你的职业，这样无论是你还是你的公司、社会，都不会介意你的年龄。

   【学赛嘉宾/张华】:
   【问】: 网友[senSSsen] 说: 最近经济下滑、行业不景气，裁员已经是很多企业目前应对过冬的“棉衣”。在这样的前提下，应该怎么办啊？如何才能安全度过这个“职场冬天”？
   【答】: 1.努力学习新知识，新技术，增强自己的竞争力。同时平时工作中应该饱含热情去工作，因为一般公司裁员，工作态度是最容易考虑的因素，其次才是个人能力；
   2.平时养成节俭、积蓄的习惯，要保证无论在什么时候手头的钱能够供自己节俭生活3-6个月；（必要时可以求助于父母和亲友，但只有万不得已才需为之）；
   3.平时养成理财的习惯，有计划的使用个人财物；
   4.学习新劳动法等知识，当被裁员时学会利用法律手段维护自己的权益；
   5.危机下也有机会，如果你有些积蓄并有创业才能，可以在经济最低迷的时候把钱拿出来投资创业，这时候所有的生产要素都是最便宜的，可以让你收到很好的效果。

   【学赛嘉宾/张华】:
   【问】: 网友[zhijie0314] 说: 我前不久被公司裁了，找工作到现在都没有着落。我是不是该利用这个机会去进修呀？等段时间再出来工作会不会好一些呢？
   【答】: 对于这个问题，我建议你列两张表：一张表写上找工作的好处和不好的地方以及为什么要找工作的原因。另外一张表写上去进修的好处，不好的地方和为什么要去进修的原因。分析一下你现在的各种条件（经济条件，技能条件，家庭因素等等），对照你自身条件对两张表进行打分。我相信你在得出分值后应该清楚自己最好去做什么。
   另外一点，不要怀有等的思想，马上去做、去准备。机会不是等来的，而是精心准备得来的。
   此外，分析一下你被裁的主、客观原因，特别是主观原因，作为下次工作的借鉴或教训，切勿在同一地方栽倒两次。

   【学赛嘉宾/张华】:
   【问】: 网友[xyz1] 说: 我马上就要毕业了，现在这情况，是继续深造，还是参加工作？
   【答】: 对于这个问题，我给你的建议是：
   你对自己的将来有没有过打算（理想）。如果有，就按理想的方向去做自己喜欢的事情。你想做个学者，就去深造。你想做企业家或是要养家糊口，就到社会上实践。不要因为环境困难而动摇你的愿望或是打算。因为没有一条路是平坦的。任何时候切勿“主观不努力，客观找原因”。客观条件不是你变更自己生活途径的唯一理由。只有自己去喜欢过、做过，才不会后悔。但无论你是选择继续深造还是参加工作，记住一点：要不断的学习，不断地实践。

   【学赛嘉宾/张华】:
   【问】: 网友[jassica_WJX] 说: 张先生，您好！我是大四的学生，现在金融危机，工作也不好找，现在有没有必要先考研呢？
   【答】: 这个问题和网友[xyz1]提的问题是一致的。问题的关键是自己的翅膀要硬。自身不过硬，就算上了研究生将来还是一样的面临就业问题。建议你分析自己的长处和短处，结合当前形势，做出抉择。但首先要你要从自己的主观能动性考虑，一些客观的原因，例如你的专业太冷门之类导致你不能正常就业或是没有机会，倒是可以考虑一下考研换专业。

   【学赛嘉宾/张华】:
   【问】: 网友[xzliuchen] 说: 请教：我是一名计算机专科大学生，明年毕业，我们应该在在校期间掌握些什么技能，才能使我们在毕业的时候更具有竞争力？目前就业形式不景气了，我们又是专科的学生，文凭不比本科，我们要怎么增强自己竞争力呢？
   【答】: 对于企业来说，技能倒是其次，态度是最关键的东西，但没有技能是万万不行的。一般来说，你们在学校中能够熟练进行某种语言程序编制或是网络维护之类的一般就够了，当然理论基础要学扎实，学透彻，这对你们将来发展很有用处。很可惜的是很多刚毕业的大学生连程序都不会写的大有其人。对于文凭问题，我想说的是，如果你能拿一个像模像样的作品和一个本科文凭去应聘，企业会选择谁？至少我会选择前者。你要学会用真才实学去表现你自己，当然这真才实学不是口头上或简历上书写的那样，或是一纸文凭，如果你怀着认真、真诚的态度，又能拿出证明你真才实学的东西，我想企业会很欢迎你的。

   【学赛嘉宾/张华】:
   【问】: 网友[shengyin] 说: 刚才张老师分析的40岁IT人员如何进行职业规划回答的非常好，那么如何去“增值”，需要在哪些方面去“增值”，才能获得好的待遇和好的地位?
   【答】: 这个问题提的很好，它可以理解为你用你的经验、才能，但不局限于你自己去利用它，而是整个公司或者团队利用它，去产生新的或更多的效益。如何去“增值”，这个你需要分析你自己目前的潜能以及公司可能存在的问题或可能的盈利点，通过你的努力挖掘你的潜能，同时为公司创造了效益或是解决问题，你就能获得好的待遇和好的地位。

   【学赛嘉宾/张华】:
   【问】: 网友[tianchengzhi] 说: 张老师，我想转型做会计行业。觉得软件更新变化太快了，年龄大了觉得很多方面都比不上刚毕业那些人了，特别是家庭和学习记忆能力，您有什么好建议吗？谢谢！
   【答】: 你的想法有些片面，年龄大了了有年龄大的优势，你在行业知识，经验积累方面比年轻人要优越得多。换句话说，年轻人是骑摩托，你是步行，但你的经验让你知道什么路是直的，什么路是弯的。所以他们未必会追得上你。软件变化是很快，但是行业知识和经验是需要积累和体验才能获取的。当然，如果你对数字有特殊偏好或是洞察细微的天赋或特质，转型做会计也是一个不错的选择。很多人，包括我有时会觉得跟不上时代，实际上跟不上时代的不是我们自己，而是我们那颗世俗的心。建议你将做会计的原因和结果与做IT的原因和结果一并列出，对比一下，你自然明白要选择哪一个。

   【学赛嘉宾/张华】:
   【问】: 网友[davada] 说: 想问下PMP考试的价值有多大，对于已经过了国内项目管理师的人而言，值得花这么多费用去考吗？该证书在业内的价值呢？对于想从事项目管理的人而言，业内哪个证书更值钱？我现在从事低层次的IT代码编写，如何向更深的层次发展，BEA和Oracle哪个会更好？
   【答】: 我举个例子，证书好比一块劳力士表，看它带在什么样的人的手上，带在乞丐和带在亿万富翁的手上大家对它的估值肯定不一样。但你如果是亿万富翁，你还需要一块表来证明吗？对于想从事项目管理的人而言，业内证书都值钱，也都不值钱，值钱的是你自己的能力和管理理念，当然你必需通过适当的表现形式表现出来。第二个问题，看你的职业期望，你如果想做资深的数据库专家，选Oracle，想做资深的技术支持工程师，选BEA。

   【学赛嘉宾/张华】:
   【问】: 网友[lizhilian] 说: 金融风暴对IT业有哪些影响啊？不知道还要持续多久?过完年后还能跳槽不？
   【答】: 金融风暴对IT业的影响可以总结为：提供数据中心和服务外包等软件公司约10%～30%的营收来自于金融领域，随着金融风暴来临，这些公司受到的影响最大。此外由于金融公司预算的削减，硬件厂商也会受到很大的冲击，特别是服务器类的。唯一例外的是开源软件，由于金融公司预算的削减，过多的CIO将把眼光放到开源软件上来。此外，IT创意创业，例如网络广告业也将收益，因为商家更希望低成本，高回报的广告投资。当然，缺少了风投的资金投入，互联网的一些目前以烧钱为主，缺乏创新方式和盈利模式的网站将会倒闭。网络游戏业和IT娱乐业将持续旺盛，因为失业人群的最大消遣方式往往是网络游戏，随着失业人数的增多，网络游戏业的收入也将增多。第二个问题取决于世界各国的经济振兴计划或消费者信息指数，至少2009年内应该不会复苏。既然是危机，就意味着危险和机会，碰到好的机会，考虑一下你的机会成本，跳不跳槽自然不言而喻，但最主要的因素还是你喜不喜你的工作的问题，强扭的瓜不甜，换工作也遵循这个道理。

   【学赛嘉宾/张华】:
   【问】: 网友[davada] 说: 金融危机下，我该如何应对自身提高需要的经济负担和家庭负担？是等几年再学习，还是现在客服一切困难学习？现在读书要钱，养家也要钱啊。
   【答】: 这个要看谁具有较高的优先级，我想你现在应该能理解很多农民砸锅卖铁供子女上大学的现象。但无论你是学习还是养家，都必须学会必要的储蓄和个人财务规划手段。

   【学赛嘉宾/张华】:
   【问】: 网友[zbstar] 说: 信息监理可能是受金融危机影响较大的，估计什么时候能振兴信息监理业啊？
   【答】: 时间没法估计，除非国家在政策和信息化方面给予较多的投入。什么时候政策有扶持，信息化方面加大投入，什么时候信息监理业就能振兴，当然，信息监理人才培养也不能漏掉。

   【学赛嘉宾/张华】:
   【问】: 网友[lizhilian] 说: 我没有什么特长，职业规划怎么搞呢，从哪开始？
   【答】: 做好职业生涯规划应该分析三个方面的情况：
   1.你适合从事哪些职业/工作；
   2.你所在公司能否提供这样的岗位以及职业道路；
   3.在你自己适合从事的职业中，哪些是社会发展迫切需要的。
   研究本人适合从事哪些职业/工作，是职业生涯规划的关键和基础；回答这个问题，要考虑以下各方面的因素：
   1.你所处的职业发展阶段
   2.你本人的职业性格特征
   3.你目前的职业技能
   4.你本人的职业定位
   5.你本人的职业兴趣
   第二个情况我想你自己应该清楚公司的职业规划情况，如果不清楚，可以去问问你公司的HR；
   第三个情况需要你有一定的经济常识，鲁迅的“物以稀为贵”可以给你启示。当然，你还得需要看社会的“需求总量”，有屠龙的本事但世上没有龙还不如杀猪的现象也是有的。
   在综合考虑上述三个方面的因素后，你就能够给自己做职业生涯规划了。

   【学赛嘉宾/张华】:
   【问】: 网友[luxiang1126] 说: 我面试了不少于8家的公司，其中有两家公司谈得还可以,就是给的薪酬一个比一个低，有一家开出居然试用期800元/月,转正后涨幅是100元，我很迷惑了，难道真的是受了金融危机的影响吗？好不容易有公司谈到薪酬这一环节了，如果我接受他们开的工资我就可以上班了，但是我心不甘，我以前刚毕业就是试用期 800元/月，难道四年以后我还有重新来过吗？至少我的资历和我的学历也是不算好差吧？所以我很苦恼甚至有点气馁，请问遇到这种情况我该怎么办？好像都失去信心了。工作啊工作啊，我想有一份1600-2000元/月的工作都很难找吗，要求并不高啊。
   【答】: 首先，你需要端正心态，不用气馁，就当作是对社会的认识，无论什么时候都不要灰心，其实社会上比这种恶劣的情况的现象比比皆是，如农民工。遇到这种情况，你要考虑下面几个问题：（1）你能给企业带来多大的利益；（2）他们给你的薪资是否能够让你维持生活；（3）除了薪金待遇外，你希望从你的新工作中获得什么东西，有什么期望，企业能够给你提供达到你未来人生期望的环境或条件么；考虑这三个问题后，我想你应该知道自己应该选择什么样的企业了。

   【学赛嘉宾/张华】:
   【问】: 网友[junemma] 说: 如今就业形势越来越严峻，再加上08年的世界经济危机，很多企业都受到影响，更是雪上加霜。经济不景气，我想问下09年找工作是否会遭遇“寒冬”？
   【答】: 从经济学“供需学说”的角度上来说，09年找工作当然会遭遇“寒冬”。加之大学明年将毕业600多万人（是我当年毕业的6倍还多，中国的经济规模和就业岗 位并没有增加6倍），就业是比较严峻的。但是如果你自身有很好的条件的话，也就是有显著的竞争力的话，你是用不着焦虑的。这就好比高考状元，无论升学率是 10%还是80%，他都有选择最高学府的优先权，你所做的就是为能够成为有“选择优先权”的就业状元而不断努力学习和实践。

测试用例三范式
1. 输入
2. 输出（预想）
3. 执行顺序

执行的顺序
1. 测试用例流执行
创建记录
读记录
更新记录
读记录
删除记录
读记录
2. 独立测试用例执行

测试的类型
1. 黑盒测试
2. 白盒测试
3. 灰盒测试

测试的级别
1. 单元测试
2. 集成测试
3. 系统测试
4. 接收测试

WEB测试的关注点
1. 代码质量
2. 功能性
3. 易用性
4. 性能
5. 安全

黑盒测试
1. 等价类
分类，取代表值进行测试

2. 边界值测试
越界值-边界值-界内值

总结：
等价类，代表值 （等价类取代表值进行测试）
边界值，大小1  （边界值最大最小多一少一）
超范围、非法值，要入力，不允许 （超范围和非法字符要做输入检查）
边界值一定是代表值，但代表值不一定是边界值
  
3. 决策表
条件-业务规则-Action
适用于业务规则较多，条件和Action较规则少的场合。

4. 状态机分析法
将程序的各个处理部分视为状态机的一个状态
找出从源点到结束（可能有多个结束状态）的所有有向图的可能路径（N-1）

5. PairWise分析
解决组合爆炸的途径，采用欧拉算术进行分析
PairWise矩阵
N个条件时，PairWise矩阵的任意N列均可以生成完整的条件值组合

例如，两位二进制的PairWise矩阵为
0 0 0
0 1 1
1 0 0
1 1 0

只需测试其中2组就可以认为其他组没有问题

6. 域分析（3O1I分析）
On/In/Out/Off
ON：在边界上
OFF：不在边界上
IN：在边界内
OUT：不满足任何一个边界条件
1. (≥, >, ≤, or <) 场合，选择ON和OFF
2. =场合，选择1个ON点和两个OFF点

7. 基于用例（useCase）测试

白盒测试
1.控制路径测试（Control Flow Testing）
保证所有可能的执行路径都能被测试到
2. 数据流测试
保证程序中每一个数据的生命周期得以执行（从创生或串行化到消亡或被存储）

何时停止测试（考虑因素）
1. 覆盖率
2. 缺陷发现率
3. 边际成本
4. 项目组认可度

挣值（时）涉及到三个要素：

（1）努力－成本（AC或AT）

（2）理想－预算（PV或PT）

（3）现实－实际效果（EV或ET）

 

也就是无论做什么事，我们只要记住：

 

花了多少精力做了多少事，实际花的这些精力按预想中可以做多少事情

 

（1）       一个是实际效果折算，一定要按照原来的预算的比例折算，即“这些事原来预想只花多少精力”；

（2）       实际花了多少精力；

（3）       实际花的这些精力按预想中可以做多少事情；

 

例子：一个小学生，老师命令他2小时做10道题（假设题目难度一致，每道题需要12分钟），结果他1小时20分钟结束的时候只做了4道题。

我们可以看出：

实际效果：4道题＝48分钟；

实际精力：80分钟；

理想结果（实际花的这些精力按预想中可以做多少事情）：80×10/120 = 6.67 道题

 

因此：

进度差＝实际的效果－理想的结果＝4－6.67＝－2.67道（以题为中心）

进度指标＝实际的效果/理想的结果= 0.6

 

成本差＝实际的效果－成本＝48－80＝－32分钟（以时间为中心）

成本指标＝实际的效果/成本＝0.6

 

知道为什么在这里进度指标＝成本指标，这是因为我们多了个（假设题目难度一致，每道题需要12分钟）的条件。没有这个条件的话，进度指标和成本指标是不会一致的。但是我们在计算时，依然要坚持“花了多少精力做了多少事，实际花的这些精力按预想中可以做多少事情”这样一个原则。

 

由于挣值（时）技术里（计划产出＝计划投入，如上例的1道题＝12分钟），所以EV（ET）在进度计算和成本计算中是一致，不过我们在分析问题时，最好把它拆开分析。即进度计算中我们的是EV（ET）的计划产出的一面（如上例的题目数），而成本分析里我们考虑的是EV（ET）的计划投入的一面（如上例的时间）。这样就能够完整理解令人混淆的挣值（时）技术。

 

指的注意的是，挣值和挣时计算出来的结果大部分情况下是有偏差的，这是因为，每个员工的工资，成本显不一致，通过工资率（或成本率）换算后，结果自然就有偏差了。但是挣值（时）核心的思想还是一致的。

PRINCE2 优点
  PRINCE2 提供了一个项目管理团队必须所拥有的标准角色描述；而PMBOK仅仅以项目经理一个角色一笔而过。
  PRINCE2 提供了完整的变更控制机制，PMBOK仅仅提及项目管理需要变更控制，但并未涉及其具体实现。
  PMBOK几乎未提及配置管理，亦未提及配置管理员的角色以及配置管理与变更控制间的关系；而配置管理则是PRINCE2八大组成部分之一；
  PMBOK仅仅谈及项目计划，而PRINCE2提供了项目阶段划分以及团队计划，并讨论了适时中止或修正项目计划的必要性。

  PMBOK涵盖了WBS的创建内容，很显然PMBOK的计划不能跟PRINCE2的基于产品计划技术相比拟。在产品描述方面，PRINCE2给予了较多的篇幅说明，而PMBOK仅仅只是提供了轮廓性的建议。

PMBOK优点

  PMBOK涵盖了项目对人力资源管理的需求，PRINCE2 则未提及；此外PMBOK提供了项目管理中的团队成员沟通的具体细节，PRINCE2显然在这方面没有花工夫。

  PMBOK的制定者大多来至于传统的建筑、制造企业，其项目环境显然与信息企业的环境相迥异，例如采购管理是传统行业项目管理的一个重点领域，但对于信息项目来说，除了信息系统集成等软硬件结合的项目，采购管理并不是项目管理的重点，因此PRINCE 2体系中未详细提及。

  PRINCE2的制定者基本上来自于信息企业，在商务方面有所专注，因此PRINCE2里涉及到了商业论证，更加重视项目利润率。PMBOK则是单纯地着眼于项目的达成。

    大凡有点中国古文化常识的中国人，都知道老子《道德经》里的“人法地、地法天、天法道、道法于自然，道生一、一生二、二生三、三生万物”之类的古语。可见中国人向来以三作为标榜，讲求的是三点论，对事物的变化采取正、反、和的观点。革命史亦充斥着“左倾”、“右倾”之说。这即是所谓的“大中至正”，讲求不偏不倚，综合地看待事物（我们称之为：东方人见森），这是东方人优点，不过正是因为这个优点是我们在发现自然规律时拘泥于环境影响，最终为西方所超过（当然这只是其中一个原因，西方技术强势还有其他方面的原因）。

    西方人的思维，则是运用分析之技术，抛开环境，参透万物自身（我们称之为：西方人见木），发现事物无时无刻不在变化的规律，遂提出“世界是过程的集合”这一论断。但凡过程必有“发生、发展、鼎盛、衰退、灭亡”这样的五阶段，此外通过类比和对比，西方人还发现（其实东方人也发现了）：任何事物都有这样的过程规律。哲学上称之为“五能演化”。

    五能演化有很多的具体实例，下面给出一些例子：

项目	态1	态2	态3	态4	态5
事物	发生	发展	鼎盛	衰退	结束
关系	分治态	对峙态	单极态	多极态	共存态
正反能量	能基态	能殊态	能梯态	能近态	能洽态
认知	无知	有知	定性	定量	应用

   于是乎我们的IT先哲们，基于自身的思维习惯和五能认知，遂将与成熟度有关的东西，均予以“五能化”，所以你看到了CMM有五个级别而不是四个或六个级别、软件测试成熟度模型（TMM），项目管理成熟度模型（PMMM），人力资源成熟度模型（HRMM）无一不是五级别制。 换做在座的各位，我相信你们亦能根据“五能演化”这样一个观点而推导出恋爱成熟度模型、认知成熟度模型、企业管理成熟度模型等等。

   有的人也许会问，我把它分成十个级别行不行，当然行。制度经济学上讲过：制度划分的颗粒度取决于组织的容量。此外，所谓的能态之间是连续的，不是离散的，只不过我们基于认知规律将其人为划分为五个阶段，因为这比较贴合于大家的认知，而不是划分为五个阶段就一定千真万确。此外，如果是划分为五个阶段是为了纯数字化，我问个问题，多少根头发的人才不算秃头？

   总结：五能演化是西方人和东方人认知中的一个常见的思维定势，在社会人文科学中有着广泛的应用，对科学技术领域也有着深远的影响。

   顾名思义，就是研究人们的经济行为，目的是为了预测大多数人（中国叫人民）或是特定人群在特定的环境和条件下所做出的基于价值判断的经济行为（由张华定义，非盗版哦）。
为什么要搞出这个很玄的东西来呢？这是因为现实当中有很多事情是不能用现代主流的经济学去解释的，比如彩票和赌博。
   传统的经济学假设大家都是“理性”的，如果现实真如此的话，这个世界至少应该没有收藏家、球迷，粉丝，吸毒者等等（递减效应的存在），可是现实并非如此。
行为经济学假设大多数人是“有限理性”的，当然精神病员的病人和医生除外。不过至少站在我这个角度上，考虑东方人和西方人的认知差异，我宁肯假设大多数中国人是“愚昧”的，因为大多数国人的经济行为极其容易受到外因的诱惑而不是出于自身的内因的驱动。为此，我不太相信中国人的行为经济和国外有着相似的类比性，至少它们之间应该是大差异的类比性。
   下面谈行为经济学的参照系问题。联想曼昆经济学税收的横向平等，让我想到公司在管理、薪酬方面的平等，每个公司的不和谐因素在于水平差别不大，工作差异不大的人拿着差异较大的工资，特别是当这几个人出于相同的教育背景情况。所以管理学中说员工更看重对比差异而不是绝对基数，这是所谓的“劣根性”所在。所以，我对一些国人恶毒的评价还是有根有据的。吹嘘自己聪明的人定是傻瓜，其实也就是这些人自卑心理的体现。
   参照依赖就是大家按某个参照点来衡量自己的“损失”或“获得”，而不考虑其绝对量。上面说得很清楚，我不再说继续说了。
   损失厌恶：”期望越大，失望越大”，说的就是这个道理。预定得到的东西后来被取消比事先知道取消在感觉上更痛苦。学到这一点使我对上次某小姐不能一同外出深感愧疚，当时我应该站出来强烈反对外界的扰动，看来只能下次努力补救了。
   敏感度递减：“狐狸吃不到葡萄就说葡萄酸”，说的就是这个道理，与期望值相差甚远的东西不会对它有偏好的，虽然有时是违心的，这个时候我们称之为“无奈”，“无奈”另外一种诠释叫做“放弃”。这时候再谈主观能动性就变成了马后炮（马后炮的意思就是说在伟大革命导师马克思先生死后放鞭炮）。
   接下来谈锚定心理，“IT人生女孩”就是这种心理的体现，这是一种偏见，要不然国家计划生育委员会的标语早改为“做IT人士好”。锚定心理指的是不同的参照物使行为者对价值判断出现差异化的表现。“近朱者赤，近墨者黑”或是“疑邻盗斧”就是这种心理的极佳诠释。
   最后框架效应，我叫它“心理暗示”，实际上就是“朝三暮四”的经济学术语抽象。由于大多数人基于“正义”的价值观，“50％可能生还”比“50%可能死亡”要更有积极的意义。除非你心理阴暗才不会这样想。这就是框架效应，同样的选择采用不同的选择方式呈现出来的时候，人们的行为会发生改变，这是因为我们的参照点变了的缘故。所以呀，跟人攀比不如跟自己比。只有自己才是自己最好的参照点。

   说了这么多，口干了，休息一下，下次继续茶话。

   去年的中国软件技术大会上有公司向我咨询过这个问题，这次再次有公司咨询这个问题，遂作一番书面答复。
   判断一个互联网商务模式是否有盈利的可能，首先是人气。人人都要吃饭，从理论上看存在人气的可能性。
   其次从用户的使用成本来看。用户只有在低使用成本，高收益情况下才会蜂拥而至，这是人趋避风险的本性所决定的。大凡吃饭之类的小事，都是随性而起。你总不会在大街上、车上拿着个电脑去找吃饭的地方吧。但是你会使用手机去做这个事情。很可惜，我们的3G时代还没有到来，笔记本电脑还没做到手机那样的大小，就算做到了，使用起来肯定不如手机方便。所以从使用成本上来看，网上订饭没有什么优势。
   再次从用户接受的服务质量来看，互联网订饭不如人与人直接电话沟通来的方便，口味、推荐菜谱、订座位、时间方面都可以快速响应，至少可以得到服务人员的及时反馈吧。但互联网订饭由于涉及的饭庄、酒家之类太多，就算订饭网公司出专职人员也未必能够及时准确的反馈。对于饭庄、酒家来说，自身的营业员文化水平都比较低，你如何保证他们及时在后台上更新菜肴数据？
   最后从资金流向来说，有的用户看了订饭网，打电话直接去找饭庄、酒家，因为他可以得到直接服务。这就意味着客户流失。此外，订饭网自身是不具现金流功能的，既然你不具有现金流功能，你如何保证饭庄，酒家给你支付佣金？再则，在订饭网上订饭，用户失约，饭庄，酒家那头怎么处理违约责任？这都是需要考虑的地方。
    那有没有其他的方法，有。但不是那么完美。考虑到用户的使用成本，你可以开通服务专线，如上海这边的57575777。改变只靠互联网单一营销的模式，加入电话销售模式。如果接线生对很细节的东西不熟，可以再转至具体的饭庄、酒家。服务方面质量虽然有些下降，但还不至于过不去。
电话营销与互联网结合虽然一样面临佣金问题，但是采用这种方式后，由于使用成本和服务质量的原因，用户人数自然增多，饭庄，酒家自然甜头大增，会形成一定的利益依赖性。在利益关联度大增的基础上谈佣金问题自然好谈。这是中国人办事的特点，先有实绩再谈预算和原则（这是销售的做法，与做市场的路径刚好相反，实际上中国绝大部分做市场的实际就是做销售）。
    以上是一点个人愚见。当然分析一个问题时有各种各样的角度，限于个人经验和学识，不再阐述。

   哲学研究的对象是物质的存在、联系和运动。
　　软件工程研究的对象是软件技术、方法、过程和工具。
　　近三十年来软件方法层出不穷，被实际开发所运用的软件方法曾达两三百种之巨。但我们通过对哲学研究的角度进行相关的类比，我们不难发现，这些软件方法归根结底不外乎下面三种角度。
　　1. 基于物质运动角度：着眼于物质本身，强调物质作为一个整体对外界作用的动态交互，在软件开发方法中体现为基于功能角度的观点。著名的方法有结构化分析方法，强调软件系统（或子系统）的输入和输出，内部对外不可见，处理时宜至上向下，逐层分解，如医学之解剖一般，化整为零。
　　2. 基于物质联系角度：着眼物质的存在与物质间的恒定关系，强调物质间的层次性和主体地位性，在软件开发方法中体现为基于实体（Entity）角度的观点，分析的重心为对实体的静态描述和恒定联系的界定，这种角度无视实体之间的运动交互，数据库设计的E-R方法即是该观点的典型方法。例如学生的选课系统，我们关心的是学生选的是哪门课程，而不是选课的过程如何进行的。
　　3. 基于物质存在状态角度：着眼物质系统的自身的存在状态，分析各种存在状态间的变迁缘由和变迁途径。在软件开发方法中常为实时领域所独领风骚，体现为状态迁移分析。常见的例子有十字路口的交通灯模型，我们通过分析灯组的状态变化来对其进行分析和仿真。

　　近来风靡一时的面向对象方法，兼具上述的物质运动角度与联系角度的特色，诸如对象（Object），类（Class），继承（Inherence）之类的概念，基于的是物质联系的角度；函数（Function）和方法（Method）之概念，基于的是物质运动的角度。我们随便举一个基于存在角度的例子，UML的状态图，它反映了单一对象的各种存在状态，因此广泛应用于实时系统的设计之中。

　　接下来谈谈体系的问题。
　　凡方法、体系，皆如哲学的内涵与外延。外延宽广则内涵浅，外延狭窄则内涵丰富。翻译成行业用语即：高效的体系适应范围比较窄，低效的体系适应范围广。由此断定，软件行业无一包治百病，立竿见影，药到病除的狗皮膏药体系和方法。诸多企业、项目应当考虑自身实际，借以标准，适当增删修正，以合自身病症，而不是一味照单全收。君不见如今中国的软件行业，利火攻心，ISO9000做烂了，CMM/CMMI也开始泛滥成灾。暗地高兴的只有那些兜售标准的认证企业，因为他们更关心的腰包里的钱袋。

　　最后要谈软件过程的问题，过程离不开环境。软件开发更像是一个生态进化，我们应该把软件开发作为一个不断进化的生态体系来看待，强调各方面的和谐有序。一味追求软件过程而忽视相关的环境（行业环境，企业环境）最后的结果只能是侏罗纪的恐龙，在开发生态被破坏的同时自己亦随之消亡。所以我们常常会提到：软件过程和开发方法要结合企业自身的实际。过度的追求标准、规范最终的结果是从体力上和脑力上压倒了整个团队，继而压垮整个企业。在这里我们的意思并不是说标准和规范不重要，但不要让标准和规范成为一张白纸或是开发团队、企业的沉重负担。因此每个企业和项目团队有必要根据自身的环境、规模和资源配置选择合适的软件开发方法和过程。

前期准备
    1    概念层次的ER图和数据库定义书准备齐全           
    2    ER图关联简洁           
    3    ER图结构清晰           
    4    ER图实体个数适中           
    5    ER图无重复冗余           
    6    存在原有系统的情况下，对旧系统的数据库进行了整理，本次设计中保留原有数据库的设计优点           
    7    存在原有系统的情况下，注意原有数据库系统中一些忽略的问题           
    8    存在原有系统的情况下，进行了数据库方面的设计对比           
    9    设计采用了CASE工具           
    10    数据字典完备           
    11    设计时考虑了将来哪些数据字段可能会发生变更           
    12    设计时考虑了不同国家，地区可能存在的字段和字段格式           
    13    设计时考虑了数据库的版本标识           
    14    设计时考虑了将来的数据挖掘和分析需求           
    15    使用英文而不是其它语言，编码来作为设计语言           
    16    存在一数据库标识机制来反映数据库的当前版本和相关配置信息           
    17    数据库设计时考虑到了备份的安全机制           
    18    数据库设计时尽量不考虑取值CHECK，有关CHECK的东西通过页面输入检查来解决   
表设计   
    19    实体有主键或有外键，或二者兼备           
    20    多对多关系被映射为三张基本表           
    21    基本表的字段不能再分解           
    22    基本表的数据均来自于用户人工输入或系统设定           
    23    基本表结构稳定，短期之内不再变化           
    24    基本表尽量满足3范式，符合2范式           
    25    根据用户统计，时间统计等统计需求建立中间表           
    26    临时表是临时的           
    27    表个数足够精简（多字段分表情况例外）           
    28    对于多值字段采用了创建子表的做法或预留了足够的字段来存储不同的值           
    29    表中存在合理的派生性冗余字段或无冗余字段           
    30    表中字段足够精简，不存在重复性冗余字段           
    31    有多种权限设计的时候采用用户－权限设计方式           
    32    表设计包括了管理员(用户)的账号管理设计   
数据库   
    33    数据库命名使用小写英语字母， 数字和下划线，无其他字符       
    34    数据库命名长度小于20位       
    35    数据库命名采用项目名或产品名称命名       
    36    数据库中的所有表字符集统一       
    37    数据库中对象命名见名知意       
    38    数据库对象的命名不使用保留关键字       
    39    数据库设计考虑到了事务机制       
    40    数据库设计考虑到将来可能存在的异种数据库迁移       
    41    数据库设计时考虑到了审计追踪机制（警告等）
表   
        42    组合主键的字段数量不超过3个   
    43    采用了系统自增字段作为主键   
    44    不同表的同一意义的字段名称和类型一致（特别是外键场合）   
    45    为关联字段创建外键   
    46    所有键取值唯一   
    47    外键是关联唯一的字段   
    48    使用商务规则约束数据完整性   
    49    表的id字段和name字段命名时采用表名_id（name）的形式   
    50    不存在只有写入没有读取的表   
    51    不用可能被更新或经常更新的字段作为主键   
    52    表设计不存在级联性删除   
字段   
    53    字段与画面项目能够一一对应（部分标识符字段和系统设定字段除外）           
    54    索引是多值字段           
    55    索引是单一字段           
    56    字段取值符合域定义           
    57    字段名称见名知意           
    58    多个表中出现同一类型字段用表前缀来标识           
    59    字段的类型和长度能够满足字段的值的最大限量           
    60    文本字段有充足的余量对应可能的长度变更           
    61    数字字段考虑了充足的余量和精度对应可能的长度或精度变更           
    62    不给MEMO（Mysql TEXT类型）之类的大字段建索引           
    63    为每种查询都建立索引           
    64    加一个标识更新时间的Datetime字段update_time，不使用mySQL 的timestamp类型。           
    65    加入一个表示记录插入时间的时间字段create_time, datetime           
    66    布尔值一律为INTERGER类型           
    67    有小数的字段使用Integer， 而不用float 等字段           
    68     普通时间字段使用Integer 或者Datetime           
    69     如果报表中可能分别按年，月，日进行排序和分组。则把时间字段分成不同的年月日字段           
    70    支持多国， 则数据库中必须存格林威治时间           
    71    不需要区别NULL和空字符串的地方，数据表设计时标上NOT NUL           
    72    用程序逻辑控制Default值， 而不是让数据库控制默认值           
    73    表中采用了DEL_FLAG字段标明删除           
    74    表中采用了IS_VALID(CANCEL_FLAG)标明有效性           
    75    采用了存放路径而不是存放图片（文件）本身的方式来保存图片数据或文件数据           
    76    Password只存单向加密过的密码， 而不是密码本身
"存储过程-视图-触发器"
        77    针对客户的特定应用采用了视图机制           
    78    采用了常规的存储过程来替代和简化客户程序代码的开发           
    79    少用触发器，多用存储过程           
    80    缺乏约束的数据库系统中，采用了触发器用来加强参照和数据完整性
优化   
    81    计算复杂时，以文件形式处理后才追加至数据库中而不是在数据库中直接计算           
    82    表记录字段太多时，采用垂直分割（超过80个以上）           
    83    表记录太多时，采用水平分割（分表）           
    84    SQL语句符合“先投影后连接再更新”的优化规则           
    85    所有SQL语句都充分地得到优化           
    86    数据库管理系统参数均得以优化           
    87    支持数据库的硬件指标符合项目需求           
    88    优化设计过程中考虑了“程序优化”，“数据库优化”和“系统优化”三个层次的优化           
    89    分布式数据库设计时充分考虑了80－20规则           
    90    XXXX数据库时使用XXXXX作为数据库引擎       

走查前准备
1    得到一份解释代码的最新的设计文档       
2    代码解释时使用了严格的警告和错误检查参数并被解释通过       
3    代码使用带ISO标准的xxxx编译器进行解释   
程序结构   
4    所有代码的结构清晰，具有良好的结构外观和整齐
5    所有的模块（函数和外部接口）定义清晰，模块分解清楚       
6    所有的功能需求都明显的覆盖        
7    高层设计独立于OS/环境        
8    结构设计能够满足机能变更        
9    代码体系结构描述了如何把代码重用到其他体系结构中        
10    整个代码体系结构组合合理        
11    所有主要的数据构造描述清楚，合理       
12    模块中所有的数据结构都定义为局部的，并且通过定义好的函数进行访问        
13    为外部定义了良好的函数接口        
14    所有的接口模块化，因此修改时不影响其他代码模块        
15    内存使用方法和内存管理策略描述清楚和正确        
16    代码体系构架对空间和速度都已经进行考虑        
17    提供了处理数据的策略        
18    具有同一的错误处理策略        
19    通过一套清晰的函数接口提供错误信息
目录文件组织       
20    所有的文件名符合文件命名规范，见名知意        
21    文件和模块分组清晰        
22    每个文件有文件头和标准的习惯一致（描述文件的用途，作者，对外提供的函数）23    每个文件都组织的有序 － 文件头，类型定义，原型，函数        
24    所有的代码行在80字符以内        
25    每个程序文件都小于2000行        
26    每个文件只包含一个完整功能模块的代码
函数组织       
27    每个函数都有一个标准的函数头声明        
28    函数组织：头，函数名，参数，函数体        
29    函数定义符合ANSI或者用标准PERL的编译开关        
30    每个函数都能够在最多2页纸可以打印       
31    所有的变量声明每行只声明一个        
32    所有的函数名都小于64个字符        
33    每个函数之间都用2空行进行分开
代码组织       
34    每行代码都小于80字符        
35    所有的变量名都小于32字符        
36    所有的行每行最多只有一句代码或一个表达式        
37    复杂的表达式具备可读性        
38    续行缩进        
39    括号在合适的位置        
40    每个顺序的小块用空行隔开        
41    注解和代码对齐或接续在代码之后    
移植性   
42    代码与操作系统无关，不需要任何假设条件
函数       
43    函数头清楚地描述函数和它的功能        
44    代码中有相关注解        
45    函数的名字清晰的定义了它的目标以及函数所做的事情       
46    函数的功能清晰定义       
47    函数中所有的部分都合理的组成函数，相关独立的语句组组成函数        
48    函数高内聚 只做一件事情，并做好        
49    函数和其他代码松耦合       
50    参数遵循一个明显的顺序；        
51    所有的参数都被使用       
52    函数的参数接口关系清晰        
53    如果一个函数有返回值，在所有的出口都有返回值        
54    函数使用了最少数目的return语句        
55    函数的参数个数小于7个       
56    所有的假设和接口清楚        
57    使用的算法说明清楚       
58    函数检查了输入数据的合法性        
59    函数异常处理清楚       
60    函数设计已经考虑了将来的变化        
61    调试信息存在于代码中并容易激活        
62    代码检查调用函数的返回值，参数和调用匹配       
63    函数确保了没有影响函数外代码       
64    递归定义了出口        
65    递归局限于一个函数        
66    堆栈大小支持递归调用的深度
数据类型与变量       
67    数据类型存在数据类型解释        
68    代码为每种可能改变数据类型的数据使用一个不同的类型        
69    代码避免了重新定义预先定义的数据类型        
70    数据结构简单以便降低复杂性       
71    每一种变量分配了正确的长度、类型和存储空间        
72    静态变量明确区分        
73    所有的声明与编译器或具体的机器长度无关        
74    每一个变量都初始化了        
75    每一个变量都在接近使用它的地方才初始化        
76    每一个变量都在将要使用它的时候才初始化       
77    变量的命名完全、明确的描述了该变量代表什么        
78    命名和现实生活中的事务接近而不仅仅是一个程序类型        
79    同一种类型或指针命名的前缀指出类型或指针        
80    命名不与标准库中的命名相冲突        
81    程序没有使用特别的、易误解的、发音相似的命名        
82    所有的变量都有最小的活动范围        
83    所有的全局变量都描述清楚        
84    使用函数访问取代全局数据的访问        
85    所有的变量都用到了       
86    存取数据的程序与全局数据的用法是兼容的        
87    变量按照它的命名用途进行使用    
特殊   
88    所有的数组访问在它们的边界内        
89    代码已经处理了-1错误        
90    代码处理了指针异常        
91    所有常量定义和使用替代代码中的数字        
92    类型转换明确指明
其他注意项       
93    代码与比较，计算变量的大小无关        
94    代码与操作符的优先级无关        
95    所有的表达式使用了正确的操作符   
条件判断   
96    条件检查和结果在代码中清晰        
97    If/else 使用正确       
98    普通的情况在if下处理而不是else        
99    判断的次数降到最小        
100    判断的次数不大于6次，无嵌套的if链        
101    数字，字符，指针和0/NULL/FLSE 判断明确        
102    boolen表达式表示清楚       
103    最常用的情况最先判断        
104    所有的情况都考虑       
105    判断体足够短，以使得一次可以看清楚        
106    嵌套层次小于3次
循环       
107    循环体不为空        
108    循环之前做好初始化代码        
109    循环体能够一次看清楚        
110    当有明确的多次循环操作，使用For循环       
111    当有不明确的多次循环操作，while循环被使用        
112    代码中不存在无穷次循环        
113    循环的头部进行循环控制        
114    循环索引具有有意义的命名        
115    循环设计得很好它，只干一件事情        
116    循环终止的条件清晰        
117    循环体内的循环变量起到指示作用        
118    循环嵌套的次数小于3次    
输入输出   
119    所有文件的属性描述清楚        
120    所有OPEN/CREATE调用描述清楚        
121    文件结束的条件进行检查        
122    显示的文本无拼写和语法错误
注释       
123    有一个简单的说明，用于描述代码的结构        
124    每个文件和模块均以给予解释        
125    源代码能够自我解释        
126    每个人看到代码就能很快理解        
127    解释说明代码功能，准确描述代码意义       
128    解释不过于简单        
129    注解清楚正确        
130    注解为用户服务        
131    所有的假设和限制进行注解        
132    长的控制体结束，进行注解
总括       
133    代码直观        
134    代码中的用语符合广告用语，而不是技术化的描述        
135    代码和设计文档对应        
136    无用的代码已经删除       
137    无用的注解已经删除 

一、单元测试环境配置测试
1. 网络连接是否正常
2. 网络流量负担是否过重
3. 软件测试平台是否可选
4. 如果（3），是否在不同的软件测试平台进行软件测试
5. 所选软件测试平台的版本（包括Service Pack）是否正确
6. 所选软件测试平台的参数设置是否正确
7. 所选软件测试平台上正在运行的其它程序是否会影响测试结果
8. 画面的分辨率和色彩设定是否正确
9. 对硬件测试平台的要求和支持程度

二、代码测试
A 静态测试
1. 同一程序内的代码书写是否为同一风格
2. 代码布局是否合理、美观
3. 程序中函数、子程序块分界是否明显
4. 注释是否符合既定格式
5. 注释是否正确反映代码的功能
6. 变量定义是否正确（长度、类型、存储类型）
7. 子程序（函数和方法）接受的参数类型、大小、次序是否和调用模块相匹配合
8. 函数的返回值类型是否正确
9. 程序中是否引用了未初始化变量
10. 数组和字符串的下标是否为整数
11. 数组和字符串的下标是否在范围内（不“越界”）
12. 进行数组的检索及其它操作中，是否会出现“漏掉一个这种情况”
13. 是否在应该使用常量的地方使用了变量（例：数组范围检查）
14. 是否为变量赋予不同类型的值
15. （14）的情况下，赋值是否符合数据类型的转换规则
16. 变量的命名是否相似
17. 是否存在声明过，但从未引用或者只引用过一次的变量
18. 在特定模块中所有的变量是否都显式声明过
19. 非（18）的情况下，是否可以理解为该变量具有更高的共享级别
20. 是否为引用的指针分配内存
21. 数据结构在函数和子程序中的引用是否明确定义了其结构
22. 计算中是否使用了不同数据类型的变量
23. 计算中是否使用了不同的数据类型相同但长度不同的变量
24. 赋值的目的变量是否小于赋值表达式的值
25. 数值计算是否会出现溢出（向上）的情况
26. 数值计算是否会出现溢出（向下）的情况
27. 除数是否可能为零
28. 某些计算是否会丢失计算精度
29. 变量的值是否超过有意义的值
30. 计算式的求值的顺序是否容易让人感到混乱
31. 比较是否正确
32. 是否存在分数和浮点数的比较
33. 如果（32），精度问题是否会影响比较
34. 每一个逻辑表达式是否都得到了正确表达
35. 逻辑表达式的操作数是否均为逻辑值
36. 程序中的Begin…End和Do…While等语句中，End是否对应
37. 程序、模块、子程序和循环是否能够终止
38. 是否存在永不执行的循环
39. 是否存在多循环一次或少循环一次的情况
40. 循环变量是否在循环内被错误地修改
41. 多分支选择中，索引变量是否能超过可能的分支数
42. 如果（41）,该情况是否能够得到正确处理
43. 全局变量定义和用法在各个模块中是否一致
44. 是否修改了只作为输入用的参数
45. 常量是否被作为形式参数进行传递

B 动态测试
1. 测试数据是否具有一定的代表性
2. 测试数据是否包含测试所用的各个等价类（边界条件、次边界条件、空白、无效）
3. 是否可能从客户那边得到测试数据
4. 非（3）的情况下，所用的测试数据是否具有实际的意义（客户业务上的）
5. 是否每一组测试数据都得到了执行
6. 每一组测试数据的测试结果是否与预期结果一致
7. 文件的属性是否正确
8. 打开文件语句是否正确
9. 输入/输出语句是否与格式说明书所记述的一致
10. 缓冲区大小与记录长度是否匹配
11. 使用文件前是否已打开了文件
12. 文件结束条件是否存在
13. 产生输入/输出错误时，系统是否进行检测并处理
14. 输出信息中是否存在文字书写错误和语法错误
15. 数字输入框是否接受数字输入
16. （15）的情况下、数字是否按既定格式显示
17. 数字输入框是否拒绝字符串和“非法”数字的输入
18. 组合框是否的能够进行下拉选择
19. 组合框是否能够进行下拉多项选择
20. 对于可添加数据组合框，添加数据后数据是否能够得到正确显示和进行选择
21. 列表框是否能够进行选择
22. 多项列表框是否能够进行多数据项选择
23. 日期输入框是否接受正确的日期输入
24. 日期输入框是否拒绝错误的日期输入
25. 日期输入框在日期输入后是否按既定的日期格式显示日期
26. 单选组内是否有且只有一个单选钮可选
27. 如果单选组内无单选钮可选，这种情况是否允许存在
28. 复选框组内是否允许多个复选框（包括全部可选）可选
29. 如果复选框组内无复选框可选，这种情况是否允许存在
30. 文本框及某些控件拒绝输入和选择时显示区域是否变灰或按既定规约处理
31. 文本框中数据格式（大小、对齐方向、颜色、背景）是否符合规范
32. 密码输入框是否按掩码的方式显示
33. 控件是否存在默认输入值，若存在，默认值是否得到显示和提交
34. Cancel之类的按钮按下后，控件中的数据是否清空复原或按既定规约处理
35. Submit之类的按钮按下后，数据是否得到提交或按既定规约处理
36. 异常信息表述是否正确
37. 软件是否按预期方式处理错误
38. 文件或外设不存在的情况下是否存在相应的错误处理
39. 软件是否严格的遵循外设的读写格式
40. 产生的文件和数据表的格式是否正确
41. 产生的文件和数据表的计算结果是否正确
42. 打印的报表是否符合既定的格式
43. 错误日志的表述是否正确
44. 错误日志的格式是否正确

C GUI测试
1. 窗体是否能够基于相关的输入或菜单命令适当的打开
2. 窗体是否能够改变大小、移动和滚动
3. 窗体的数据是否能够利用鼠标、功能键、方向箭头和键盘操作
4. 当窗体被覆盖并重新调用后，窗体是否能够正确再生
5. 窗体相关的功能是否可以操作
6. 是否显示相关的下拉菜单、工具条、滚动条、对话框、按钮、图标和其他控制，既能正确显示又能调用
7. 显示多窗体时，窗体名称是否能够正确表示
8. 活动窗体是否能够被反显加亮
9. 多用户联机时所有窗体是否能够实时更新
10. 鼠标无规则点击时是否会产生无法预料的结果
11. 窗体声音及提示是否符合既定编程规则
12. 窗体是否能够被关闭
13. 窗体控件的大小、对齐方向、颜色、背景等属性的设置值是否和程序设计规约相一致
14. 窗体控件布局是否合理、美观
15. 窗体控件TAB顺序是否从左到右，从上到下
16. 窗体焦点是否按照编程规范落在既定的控件上
17. 窗体画面文字（全、半角、格式、拼写）是否正确
18. 鼠标有多个形状时是否能够被窗体识别（如漏斗状时窗体不接受输入）

1.  信息系统审计的准备－审计部门
　　为了实施信息系统审计，需要在事前进行充足的准备，以获得良好的审计效果。
为了导入信息系统审计，事先需要进行下列的活动：
　　·信息系统审计的环境构建、文化导入；
　　· IT审计师的培养；
　　·各种审计相关规章的整备；
　　信息系统审计的宗旨在于提高作为企业中枢神经的信息系统的可靠性、安全性和开发、运营效率，使企业能够健康地运营和发展。要使信息系统审计能够达成既定目标，上级主管的完全授权是最重要的一环。

2.  信息系统审计的准备－被审计部门
　　IT审计师在实施信息系统审计的时候，常常要求被审计部门提供诸如文档之类相应的资料作为审计依据。
　　被审计部门为此事先应该对文档、操作说明书等进行整理和准备。还要准备好计算机安全措施、个人信息保密措施等实施情况的说明。这些资料要尽可能让IT审计师一目了然。通常，被审计部门（信息化部门，用户部门）需要准备的东西如下面所示。当然，有关的系统设计书、程序设计说明书之类的必须保持最新的更新状态。

　　信息化部门：
　　·系统开发计划书
　　·系统设计书
　　·系统构成图
　　·程序一览表
　　·信息管理相关规章
　　·操作指南
　　·故障对应指南
　　·计算机安全对策现状说明

　　用户部门：

　　·终端设备操作手册
　　·系统输出列表
　　·系统输入式样
　　·系统使用指南

3.  信息系统审计的实施步骤
　　信息系统审计的实施步骤如下所示：

　　审计计划

　　·基本计划（每年一度的审计计划，属于年度计划，概要性的计划）
　　·个别计划（个别，具体的审计实施计划，有实施细则）

　　审计实施

　　·审计通知（实施前1－3周通知被审计部门）
　　·预备调查（审计实施前准备）
　　·审计实施（实际的审计活动）
　　·审计意见整备（基于审计结果的记录和文档）
　　·评议会（基于审计结果，与被审计部门交换本次审计意见）

　　审计报告

　　·审计报告制作（完成信息系统审计报告）
　　·报告书提交（向上级主管提交信息系统审计报告）
　　·报告会（召集相应的干系人进行会议）
　　·改良指示（上级主管根据审计意见责令被审计部门进行相关的改良活动）
　　·审计追踪（IT审计师对改良情况进行检查）

4.  信息系统审计的留意点
　　在实施信息系统审计的时候为了确保审计高效的得以实施，必须制作相应的审计计划。
　　IT审计师在审计计划中必须明确审计的对象、审计目的、审计主题。
　　审计对象、审计主题的选定、优先度确定之类留意点可参照下面所述。

　　·企业经营方针、上级主管的需求
　　·信息化部门的问题、要求
　　·用户部门的问题、要求
　　·审计对象的业务特征
　　·信息系统的重要度
　　·审计对象业务的问题点及其解决紧迫度
　　·IT审计师自身的知识、经验

5.  信息系统审计的着眼点
　　下面是进行信息系统审计应该重点注意的地方：
　　安全：信息系统的物理安全性，防止非法使用
　　可靠：硬件、软件的正确运行
　　机密：基于数据访问权限的保密
　　合法：法律、法规、规章之类
　　适时：是否符合开发、导入、运营等的时间限制
　　成本：成本节约方面的效率
　　资源：资源利用方面的效率
　　有效：信息系统目标的达成度

6.  信息系统审计技术
　　可以通过很多方法来实施信息审计，下面给出常见的几种方法，每种方法各有利弊，对这些方法进行组合使用，可以使信息系统审计得以更有效地得以实施。
　　商谈法：与信息化部门、用户及相关人员进行会谈
　　资料查阅法：对与信息系统相关的文档、程序进行查阅，核查
　　实地考察法：对机房、考勤以及业务终端、器材（例如POS）等进行实地考核
　　计算机审计法：利用计算机技术进行信息系统审计，常见一些利用计算机的方法有：
　　·测试数据法
　　·程序审计
　　·审计模块
　　·ITF方法
　　·并行仿真
　　·快照
　　·追踪（Tracing）
　　·代码比较

7. 信息审计报告
　　根据信息系统审计实施的结果，IT审计师将之汇编成《信息系统审计报告》，向上级部门出示的同时，也要传送给相关的干系人。
　　信息系统审计报告由IT审计师独立编写，内容主要涵盖信息系统的可靠性，安全性和效率的现状以及问题点。同时给出改良建议。
　　《信息系统审计报告》的样式如下所示：

　　信息系统审计报告书

　　[题头]
　　报告日期；
　　上级主管部门名称；
　　上级主管姓名；
　　审计说明（概要）；

　　[正文]
　　审计对象；
　　重点审计主题；
　　审计目的；
　　审计范围和审计实施步骤（概要）；
　　实施期间；
　　被审计对象部门；
　　被审计人员及其工作职能；
　　审计结果（概要）
 　　 1 可靠性
    　　可靠性概要
    　　可靠性评价
  　　2 安全性
   　　 安全性概要
    　　安全性评价
 　　 3 效率
   　　 效率概要
    　　效率评价
　　主要存在的问题
　　改良建议
  　　1 一般改良建议
  　　2 紧急改良建议

8. 改良指示和改良追踪
　　信息系统审计的实施结果以审计报告的方式提交给上级主管，上级主管根据审计报告，向被审计部门提出改良的指示，被审计部门依照审计报告中的改良建议进行改良。
　　IT审计师需要对被审计部门的反馈（改良活动）进行复查和评价，该活动称为审计追踪；
　　通过审计追踪，能够确保审计效果的达成，同时还可以确保改良措施得到妥当地执行。
　　改良追踪的步骤如下所示：
　　信息系统审计的实施（审计部门）→　信息系统审计报告书制作（审计部门）→　对被审计部门提出改良指示（上级主管）→　改良活动实施（被审计部门）→　改良状况检查（审计部门）→　改良状况再评价（审计部门）

　　以上是对信息系统审计（IT审计）一个概括性的讲述。

　　备注：有关IT审计师考试的情况
　　ISACA和日本通产省信息推进和处理机构。
　　前者于1969年成立并取名叫EDPAA（Electronic Data Processing Auditors Association，电子数据处理审计协会），后来于1994年改名为ISACA（Information System Audit and Control Association，信息系统审计和控制协会），号称全世界唯一的专业信息系统审计协会。CISA考试诞生于1978年，所有通过ISACA的CISA考试的学员皆称CISA（Certified Information Systems Auditor），学员来源大部分来自企业审计人员；ISACA全世界多个国家内设立考点，相对来说，培训费用较高，过级率比较高；
　　日本通产省信息推进和处理机构则是于1969年推出了系统监查员考试，是专门针对计算机专业人员的信息系统审计考试，由于对计算机专业知识要求极高，对参考学员的信息系统规划和开发经验有比较严格的要求，难度和声誉与系统分析员考试旗鼓相当，合格率平均在4％－6％左右。属于日本信息处理考试中的高级，同等级的系统分析员考试与中国的系统分析员考试互相承认，是难度极高的信息水平考试；
　　从双方机构的审计准则来看，CISA基于《IS Standards, Guidelines and Procedures for Auditing and Control Professionals》，CISA将信息当资产来看待，主要为提高信息资产的安全性着眼，知识范围包括信息系统的管理、计划、组织、开发，信息系统的基础环境、信息资产相关保护措施、灾难恢复计划和企业业务流程等。
　　系统监查员基于《IT审计准则》，将信息系统视为机器系统，着眼于提高信息系统的可靠性、安全性和有效性而战，与软件开发的质量控制，求得信息整体质量与投资的最佳组合，主要工作为信息系统的规划、开发和运行三段进行评价和建议。涉及的技术大部分属于计算机专业技术而非普通的管理方面的技术。

1.  企业信息化与信息系统审计
　　随着企业实施信息化进程的不断深入。从信息系统安全性方面我们看到硬件故障、程序故障、操作系统错误、计算机犯罪，设备灾害以及保密数据泄漏等现象发生的可能性愈来愈高。此外，从投资的角度上看，我们看到随着信息化投资成本的不断增加，投资效果反而不明显。还有还会出现信息系统用户不满以及信息化产品落后于竞争对手、无法在市场上立足等问题。
　　信息系统审计（又称IT审计）正是为了解决上述问题，提高信息系统的安全性、可靠性和开发、运营效率，使企业信息化得到健康、全面的发展而引入的预防机制。

2.  信息系统审计是什么
　　对信息系统进行审计的人员称为IT审计师，信息系统审计便是IT审计师对信息系统生命周期进行审计的一系列的活动。这些活动包括：
   （1）对信息系统的可靠性、安全性、开发和运营效率进行检查和评估；
   （2）将检查和评估结果向上级主管报告；
   （3）上级主管根据评估报告，指示信息化担当人员对信息系统进行相应的改善、IT审计师对改善情况进行追踪；

3. 信息系统审计的对象
　　信息系统审计的对象包括：由计算机硬件和软件结合而成的信息系统以及与信息系统的输入、输出相关的活动。广义的讲，即信息系统以及信息系统生命周期的所有活动；
　　因此，信息系统审计并不局限于业务运营时期，与信息系统相关的开发活动，包括企业信息化战略企划、信息系统计划、开发、实施和维护等相关的开发方面的活动也是信息系统审计的内容之一。

4.  IT审计部门的位置
　　为了保证信息系统审计能够客观、公正并有效的得以执行。IT审计部门在企业内是独立的，不隶属于信息化部门和用户部门。
　　有些公司可能因为规模、人才等原因没有IT审计师，在这样的情况下，信息系统审计可以雇用专门从事信息系统审计的审计公司来实施企业内部的IT审计。

5.  IT审计师的知识和能力要求
　　为了有效地实施信息系统审计，作为一个IT审计师，应具备待审计对象所要求的业务知识和丰富的信息系统开发经验。
　　知识方面的要求如下：

　　信息系统计划、开发和运营相关的知识：

　　·信息系统构成相关的知识；
　　·信息化战略、构想、提案、立项等相关的知识；
　　·系统设计、程序设计、软件测试等相关知识；
　　·系统操作、数据管理等相关知识；

　　信息系统审计实施相关的知识：

　　·信息安全相关的知识；
　　·经营管理方面的相关知识；
　　·业务对象相关知识；
　　·相关法律和法规；

　　能力方面的要求如下：

　　·系统审计的相关能力；
　　·审计的立项、分析、评价相关的能力；
　　·信息收集、审核、审计方法掌握、技巧运用方面的能力；
　　·审计报告制作能力；

6.  信息系统审计效果之一 —— 信息系统可靠性的提高
　　实施信息系统审计，可以从如下几方面着手提高信息系统的可靠性
　　对信息系统的计划、开发、实施和运营各方面进行审计、可以提高信息系统的品质；
　　通过信息系统审计，能在早期发现信息系统的设计缺陷、程序错误等、最终防止系统当机或是用户误操作现象的发生；
　　万一信息出现故障，通过信息系统审计可以使故障影响控制到最小，还能迅速地进行系统恢复；

7.  信息系统审计效果之二 —— 信息系统安全性的提高
　　实施信息系统审计，可以从如下几方面着手提高信息系统的安全性
　　对自然灾害及不可抗拒灾害的应对措施进行审核和评价、一旦发生时能使损失和影响降至最低；
　　从安全方面对信息系统进行审核和评价、防止数据的外泄、破坏或修改、非法入侵等情况发生，保证企业机密不外泄；

8.  信息系统审计效果之三 —— 信息系统效率的提高
　　实施信息系统审计，可以从如下几方面着手提高信息系统的效率
　　从信息系统的资源是否最大限度地被利用为落脚点进行核查、评价，实现信息系统在业务和负载方面的均衡；
　　对信息系统的计划、开发、实施和运营各阶段的（费用/效果）指标进行定性或定量的核查、评价，确保信息系统利益最大化；

   多项目管理是站在企业层面对现行组织中所有的项目进行筛选、评估、计划、执行与控制的项目管理方式。与单个项目管理不同的是，单项目管理是在假定项目的资源得到保障的前提下进行的项目管理，思考角度采取"由因索果"的综合法方式。多项目管理则是在假定存在多个项目的前提下，如何协调和分配现有项目资源、获取最佳项目实施组合的管理过程，其思考角度一般采取"由果索因"的分析方式。

　　作为一个软件企业来说，实施多项目管理具有非常重要的意义。首先作为一个软件企业来说，同时可能有多个软件项目在实施，这些项目之间在资金、时间、人力资源方面往往存在争夺关系，项目之间的这种关系往往导致公司资源的调配方面出现激烈地争执，恶化企业的政治环境，造成员工大量流失，所造成的间接损失更加突出。其次多项目管理的实施成功与否，直接影响企业的经济利益。企业的最终目的在于盈利，良好的多项目管理可以降低项目成本，

　　优化企业资源配置，从而提高的企业的利润率。

　　在实施多项目管理之前，我们有必要在众多项目中进行筛选，根据项目的成本、范围大小、项目利润率并结合公司自身的技术能力、专长筛选项目，切忌贪多求全，出现"一颗老鼠屎搅怀一锅汤"的情形。有关这方面的决策知识，可以参看管理会计方面的书籍。

　　软件复用与管理组织变革(MOC)是达成多项目管理的一个有利途径，能够缓解多项目管理对资源的争夺，解决多项目在时间、资源方面的过载问题，同时亦能解决多项目沟通的效率。不过对于没有技术积累的软件公司来说，很难做到这一点。

　　其次是利用时间差，在进行多项目管理中，尽量错开项目间在同一时间对资源和开发人员的争夺。让关键资源（多项目资源集合的交集）保持非过载状态。如果无法解决时间差问题时我们一般采取增加资源或确定项目资源优先使用级（短平快的项目具有较高优先使用权，但不能一直在整个项目阶段中独占资源）的途径来解决。不过对于大多数软件公司来说，前者一般不太可能，因为它增加了项目成本。后者作为下策虽然保证了成本，但不可避免地影响到项目的工期。实际场合中应在成本和时间中进行权衡。

　　企业的多个软件项目间根据其相关程度，常常分为两种类型（更为详细的分类需要用到聚类分析）：多个项目均与实施某一目标直接相关，这样的项目集合我们称之为"计划"（Program），其对应的管理方式成为计划管理（Program Management），计划管理的任务在于通过实现一些相互关联的目标来促成某一战略的达成。如果多个项目之间互不关联，这样的项目集合管理我们称为分组项目管理（Grouping Project For Management），分组项目不针对某一战略（目的）。

　　对于计划型项目，我们可以采取类似单项目的管理方式，建立计划与项目的映射，计划中的各个子项目对应于单项目管理中的任务。通过映射方式来促成计划型项目的解决。

　　分组项目管理的解决并无定法可言，一般我们通过遵循一些原则和管理决策来达成分组管理目标的实现。

　　针对分组项目管理来说，在对项目进行分组时应遵循"相似性"原则，以减少和优化资源配置，这体现在：
同组的项目所需的软件技术相似。技术相似有利于减少同组开发人员的培训成本，提高相关技术复用率，对多项目管理的效率具有很大的提高。例如，将.Net项目与Java项目分开管理。

　　项目业务领域相似。仿上，相似的业务领域有利于经验的复用和管理效率的提高，比如将ERP、MRPII项目分在一组，而OA项目分在另外一组。

　　优先级相同，同组的项目应该具有相同的重要度（重视程度），否则会导致重要度较低的项目无法得到必要资源得以完成（这与利用时间差中的确定项目资源优先使用级并不矛盾）。

　　在实际的多项目管理活动中，更多的情况是项目经理（部门经理）根据项目的实际情况进行相应的项目资源占用取舍，这往往需要项目经理（部门经理）综合各种因素，确定这些因素的重要度来作出相应的决断。但是需要指出的是，解决资源（人、材、时间）问题才是解决多项目管理问题的关键。

1 信息化的社会

　　近年来，随着信息技术的不断发展，信息系统日渐成为现代社会中不可缺少的"基础设施"。就在信息系统为人们提供便利，满足社会服务需求的同时，信息系统自身的结构、功能复杂度越来越高，使得信息系统本身由于复杂度增大导致的系统脆弱性隐患变得越发严重。对信息系统进行错误操作、滥用、不正当使用导致的社会问题屡见不鲜，给社会带来了巨大的经济损失，重者伤及人命。特别是近些年来的网络化趋势使得这种影响波及范围更为扩大，造成了极为恶劣的影响。因此，信息系统的安全性愈来愈为社会所关注。

　　信息系统给社会带来的危害主要体现在以下几方面：

（1） 致命的功能停止

　　● 由于1993年纽约世界贸易大厦爆炸事件，使得当时入住的多数企业的商业数据如数丧失，导致在企业这一年内的很多商业活动无法进行。（AIXCELLENCE 1995年秋冬号IBM社）

　　在现实生活中，这样的例子比比皆是。由于停电使医院信息系统的停止导致手术的病人致死这样的现象也时有发生。为此，如何给信息系统提供一个安全环境，如何使一个信息系统环境内信息流处处畅通，成为了一个新的课题。

（2） 错误操作、不正当使用和滥用信息技术

　　● 某都市银行支店副店长利用联机终端盗取3亿日币（折合2千多万人民币）（1998.1.14 日本经济新闻）

　　● 1998年发生的CIH病毒，导致全球数百万台计算机硬件损坏，导致近百亿美元的经济损失。

　　● 1997.8.1发生在东京证券交易所的系统当机造成了巨大的社会影响和经济损失。经调查，原因是处理程序在设计时出的一个小问题。（1997.8.15日经BUSINESS）

　　任何技术都是"双刃剑"，信息系统给社会带来巨大便利的同时，也往往会被"不法分子"所利用，如何杜绝这类现象，如何防止信息系统因为自身的缺陷给社会蒙受巨大损失，这又是我们面临的另外一个新课题。

　　此外如何对待信息系统投资也引起人们的逐步关注。不少信息系统建设项目劳民伤财，耗资巨大却无法为社会提供实际的服务价值，甚至还危害及社会。对于企业来说何尝不是一笔重大的经济损失。有例证：1994年，Standish Group对IT行业8400个项目（投资250亿美元）的研究结果表明有34％的项目彻底失败，50％的项目在补救后完成，预算平均超出90％，进度平均超出120％。这些失败和补救的项目中、不少未经过投资风险评估便匆匆上马，超成了极大的社会资源浪费，对信息系统投资方面起到了极其恶劣的影响。

　　从上面的事例我们可以看出：应对信息系统的建设我们需要引入一种新的管理机制来对信息系统的安全性、投资效果、实施进程和实施效果等进行评估、指导和改进。这种机制就是我们今天所提到的IT审计（System Audit，又称IT监查）。

2 IT审计的历史和发展

　　IT审计的出处源自60年代IBM出版的《Audit encounters Electronic Data Processing》等有关在EDI环境下进行审核和组织的论述。不久后有关该方面的研究结果不断涌现， IT审计的雏形初步形成。但是由于信息系统在社会上尚未得到较为广泛的应用，因此IT审计并未在社会上形成意识。

　　七十年代中后期到八十年代初由于计算机在发达国家的企业初步普及，利用计算机犯罪和计算机系统失效的事件频频出现，使得IT审计日益得到社会重视，美国、日本先后成立了IT审计方面的协会组织。从事对IT审计规则的制定和实施指导。值得注意的是1985年日本政府出台了《IT审计标准》并根据美国劳工部的《Skill Start》和Northwest Center for Emerging Technologies（NCET）对IT信息人员的从业技能的要求制订了IT审计师（系统监查员）的技能标准并以之作为新的"IT审计师（系统监查员）"级考试的参考标准。

　　九十年代是IT审计的普及期，这主要归功于互联网的普及。互联网的普及是利用计算机犯罪的人员温床，此外日益严重的软件项目失败问题引发了是否要对信息系统的投资和开发进行审计的深思。IT审计得到了前所未有的重视。

3 IT审计的对象、范围和意义

　　IT审计是独立于信息系统本身、信息系统相关开发、使用人员的第三方－IT审计师采用客观的标准对信息系统的策划、开发、使用维护等相关活动和产物进行完整地、有效地检查和评估。

　　由上面的定义我们可以看出，IT审计设计整个信息系统的生命周期，IT审计不是单纯强调对软硬件的审计。它的审计对象涵盖整个信息系统所有活动和中间产物，并包括信息系统实施相关的外部环境。

　　IT审计按照信息系统的生命周期分为业务计划审计，业务开发审计、业务执行审计和业务维护审计以及涵盖整个信息系统周期的共通业务审计。

　　业务计划审计主要面向信息系统的企划，对信息系统的投资可行性，系统规划与公司战略的相关性，系统开发计划的可行性以及系统需求的完整性和正确性进行审核和验证。

　　业务开发审计对信息系统开发的各个阶段的相关人员的活动、信息、中间产物进行审核，确认这些活动、信息和中间产物的规范性、有效性和对于信息系统目标的针对性。

　　业务执行审计确认与信息系统运行相关的数据、软硬件、安装环境等是否符合信息系统的运营要求，同时对信息系统的功能、性能、易用度、可操作性等进行评估。

　　业务维护审计对信息系统的维护活动和维护结果实施审核和评价。发现在维护中可能出现的各种漏洞和信息系统维护中急待改善的问题。

　　共通业务审计涉及文档管理、进度管理、人员管理、采购管理、风险管理等，检查这些过程的规范性和有效性，并提出改良建议。

　　IT审计的任务在于站在客观公正的角度上，收集审计信息，生成审计报告，通过审计报告促成信息系统生命周期活动和成果物的改善。

　　实施IT审计能够强化IT投资效果，提高信息系统的安全性，能够客观评价信息系统及信息系统开发，从社会经济和企业、国家信息化投资、安全等方面都具有极大的意义。

4 IT审计制度

　　一般来说，对企业实施IT审计的对象有：本企业内的IT审计师、外部IT审计事务所委托审计师和国家审计机构。
作为企业，建立一个完善的IT审计制度需要做到以下几点：

　　（1）IT审计师是跨信息技术和审计技术的复合型人才，要实施企业的IT审计制度，必须重视和培养合格的IT审计师；

　　（2）企业应该建立相应的IT审计部门或审计岗位，确定其部门和岗位职责，并将之置于企业经营者的直接管理之内；

　　（3）企业应该制定相应的IT审计准则、实施报表、报告等进行IT审计所必须的凭据；

　　只得一提的是，企业在建立IT审计制度时应当遵循国家相关IT审计的法规并结合本企业的业务实际进行。企业的IT审计制度不是一成不变的，根据具体企业的营运情况可以在每个审计年度终结后新的审计年度开始前做相应的修改和增删。

5 IT审计计划

　　IT审计的实施需要制定相应的计划，明确IT审计的任务、采用的方法和预期应当达到的效果。该计划在提交经营层确认后得以实施。

　　IT审计的审计计划分为两种类型：基本计划和详细计划（又称分期计划）。

　　基本计划是一个审计年度内相关IT审计活动的计划，确认年度内IT审计的各项任务及其大致时间安排。基本计划需要提交经营层批准。它是对整个IT审计年度的活动指引方针。内容包括：审计对象、审计场所、审计原则、日程安排等。

　　详细计划（分期计划）针对具体项目（系统）或任务，得到IT审计部门领导的许可即可，详细计划需要告知被审计对象。详细计划的内容包括：审计对象、目的、审计流程、审计要点、审计时间、相关人员、审计报告提交事项等内容。

    软件开发的残酷的现实告诉我们：没有规则的软件开发过程带来的只可能是无法预料的结果。我们中的大多数项目管理人员在其个人简历中纷纷写到：“拥有多年的丰富的项目管理经验”，但在实际开发中，“丰富的”管理经验变成了软件开发人员可怕的梦魇。一次次的失败、一次次的返工，她所谓的项目管理经验只不过是再一次的游戏于“无间”（十八层地狱）。一次，在与不少项目管理者的交流中，大家纷纷提到的软件变更带来的可怕影响。但是正如完整的法律体制不能制止犯罪，但没有完整的法律体制犯罪会更加猖獗一样，频繁的软件变更固然可怕，但是没有一个完整的项目管理对应机制，我们无法相像项目最终会是一个什么样子。此外还有一次，笔者在求职时，招聘公司的技术主管（40-50岁左右），向我吹嘘公司按CMM4的过程规则来进行软件的开发和管理。殊不知，我一问下面开发人员，她们在经历无数的加班后正在给已经完成的软件项目添加软件概要设计书，这让我大吃一惊。如此这样形式主义的公司，不呆也罢。
   记得一个格言曾经说过“人类最愚蠢的行为在于忘记常识”。另外一句较为相仿的格言则是“不知道历史的人必然会重蹈覆辙”。作为项目管理来说亦为同样的道理。很可惜，我们中的大多数管理者口口声声“软件工程”，工作时“用程序代替用户需求”，极具政客的嘴脸。其结果必然如目前媒体“程序员生存状况”所言，以开发人员在时间的牺牲为代价来换取项目的结束，这是再为普遍不过的现象，在此不再妄加评论。
   如何改善我们的软件开发管理，一条便捷之道便是“尊重常识，尊重历史经验教训”。在软件项目管理中，有许多的原则和经验可以供我们借鉴。
  一、 计划原则
    没有计划，你无从知道什么时候控制和变更。制定一个详尽的计划，以详细到开发人员可以理解的程度为宜。计划能够告诉你什么时候应该做什么。没有计划，你无从知道自己需要做什么。不少项目经理告诉组员需要做什么东西后扬长而去，丝毫没有一个相关任务（活动）之间的说明。由于没有计划或是计划太粗糙、不切实际，很多项目1/3甚至1/2的时间花在返工上面。因为计划中遗漏了某一项关键任务，项目就有可能宣告失败。试想一下，制定一个周密合理的计划需要耗费这么多的时间吗？需要付出项目失败的代价吗？还有很多项目管理人员常常错误认为“变化比计划快”，但实际的情况是，由于没有计划，你无法预测和估量变化给你的项目所带来影响，你所面临的将会是比面条还难以理清的“混沌”状态。此外，对于开发人员来说，“目标导向（Objective Oriented）”是充分调动其工作积极性的最佳方法，每一个任务阶段的成果能够将员工的工作效率维持在一个较高的水平。因为近期目标总是比远期目标来说更容易看到和达到。为此，制定一个计划吧，让它符合目标导向（通过各个具体任务计划促使项目总计划的达成）。
  二、 Brooks原则
   向一个已经滞后的项目添加人员，可能会使项目更加滞后。因为作为新加入的员工来说，相关培训、环境熟悉和人员之间的沟通通路的增加，迫使项目的工作效率急剧下跌。工作效率下降需要加班来进行弥补，但加班造成的疲劳会再次使工作效率降低。同时工作成本却不断的向上攀升。不过就目前来说，项目管理人员丝毫不会理会这一点，“人多力量大”也许更能引人入胜。不少项目管理人员抱怨到时间的急迫性，须知很多项目内时间的急迫性来自于项目管理人员不假思索和不基于常理的邀功表现，没有充分考虑的开发人员能力的多样性所致。为此，正规的企业不得不耗费大量的加班费用于加班人员的津贴，同时亦要承担违反《劳动法》的潜在法律危险。现在一种万不得已的做法是，假设项目开发人员之间的任务的关联性不是太大的情况下，采取两班倒或是三班倒的方法来保证时间的延续性和相关开发人员的工作高效性。
  三、 验收标准原则
   我们在进行某项任务，往往会为以何种结果为宜而感到困惑。不求质量的开发人员往往凭据经验草草了事，追求完美的开发人员则在该项任务上耗费太多的精力，但此番耗费未必针对该项任务，因而常常吃力不讨好。这是由于没有验收标准而导致的情景。因为没有验收标准，你无法知道你要进行的任务需要一个什么样的结果，需要达到什么样的质量标准。在很多情况下，你的活动会与期望结果背道而驰，而此时的你还在沉醉于自己的辛勤耕耘之中。作为项目经理来说，只有制定好每个任务的验收标准，才能够严格把好每一个质量关、同时了解项目的进度情况。
  四、 默认无效原则
   你的项目成员理解和赞成项目的范围、目标和你所制定的项目策略吗？不少项目管理人员认为“沉默意味着同意”。实际上我们或多或少都会陷入这样的一个思维误区。试想一下，你作为职员或项目开发人员时的沉默完全代表你赞成你的领导的意见吗？不见得，这就是答案。这一点在项目沟通中极为重要，项目管理者切不可为沉默认为是同意，沉默在很大的程度上说明项目开发人员还尚未弄清楚项目的范围、任务和目标。为此项目管理者还需要同开发人员进行充分沟通，了解开发人员的想法。在对项目没有一个共同的一致的理解的前提下，一个团队是不可能成功的。
  五、 80-20原则
    80-20原则在软件开发和项目管理方面有许多“实例”。其一便是我们在20％的项目要求上耗费了80％的时间。仔细分析一下，这些项目要求分为必须的非必须的，因此我们建议是压缩非必须的部分或是暂时将其放在一边不必太重视。软件项目开发事实告诉我们，开发人员在非必须的项目要求上耗费了太多的精力，用户的需求变更的大部分出现在“最好有”这一部分，实际上用户并不看重这些需求（即使去除这些需求），而我们所做的，往往是舍本求末。
    80-20原则的另外一个实例是我们项目中的20％的人员担当了80％的项目任务（这样讲在实际实施中一点都不过分）。考虑到开发人员能力的多样性，聪明的项目管理人员决不会采取任务均分的愚蠢做法，因为就系统论的观点来看，互补结构比对等结构要更稳定一些。此外作为项目管理人员来说，了解属下员工的能力特点，将其放在合适的位置上，会更有利于项目的顺利进行。很多管理人员常常抱怨属下能力问题，究其实质，往往是这些项目管理人员未能发现开发人员潜能所在之处。她们看待问题往往以“经验”这样的思维定势来做决定。导致的结果如系统论所言：由于“抱怨”的作用和反作用循环，结果是大家都不欢而散。
  六、 帕金森原则
   帕金森原则原是用于反映政府部门机构臃肿，效率低下的代名词。不过它在软件开发中一样适用。没有时限限制的话，工作可能无限延期。在软件开发中，如果没有严格的时间限制，开发人员往往比较懈怠。这是人的天性所决定的。千万不要指望奇迹的发生――“所有员工的思想觉悟异常崇高”。作为项目管理者而言，此时应充分考虑到员工的工作效率和项目变更带来的负面影响，制定合理的项目工期并鼓动开发人员尽快完成。
  七、时间分配原则
    在项目计划编制过程中，我们常常将资源可用率（人、设备）等设置为100％，殊不知你曾想过，由于开发人员需要休息、吃饭、开会等，根本不可能把所有的时间放在项目开发工作上，而且这还不考虑到开发人员的工作效率是否保持在一恒定水平上。所谓一天8小时工时制实际上是徒有虚名。由于项目管理人员的“无知”，不少开发人员被迫拼命加班。结果依旧出现Brooks原则所出现问题。在实际开发中，开发员工的时间利用率能够达到80％就已经时很不错的了，我个人比较倾向于60％左右（黄金分割点）。一个常用的经验是如果项目人员不懂技术的话，项目时间可能是原计划（该计划没有考虑到资源可用率）的4/3－5/3。如果项目人员不懂技术、管理人员不懂管理的话，这个数字可能是2倍到3倍。现实就是这么严酷。这很大范围内“归功于项目管理人员。是的，我们的确没有必要责备开发人员，因为我们对资源可用率的判断完全违反常识。
  八、变化原则
    也许有人问过你，在项目管理中唯一不变的东西是什么？我可以告诉你，项目中唯一不变的就是“变化”。在项目中不考虑可能发生的变化是不可思议的。不过在面对项目可能发生变化而带来的项目风险时，我们的项目管理人员往往会怀有逃避的态度。经济学里大名鼎鼎的风险规避原则便是项目管理人员心理的有效描述。作为项目管理人员来说，应该及早预测可能出现的风险，做好风险储备。虽然风险储备不能解决所有的问题，但是“预防胜于治疗”。可惜的是我们绝大多数人没有这方面的意识，否则医院的生意未必如此红火，项目开发之途未必如此坎坷。
  九、作业标准原则
       一个团队要完成项目的开发需要有一定的章法。很可惜，在国内目前仍然以“作坊式”为主，高举“我们符合国际CMM X规范（ISO某某规范）”的环境下，未必有多少项目团队注意到这一点。我们曾经惊叹印度的高中生都能编程序，而国内却非本科、硕士不收眼帘。究其原因，在于没有开发章法或是章法粗糙，犹如牛皮圣旨一般。一个好的代码模板和代码规范能够解决大多数人编写程序随心所欲的问题，很可惜，没有多少项目管理人员有此意识，也没有多少人愿意去做这项基础任务。业务软件开发需要高超的开发技巧吗？不需要，那是故弄玄虚的开发人员的伎俩。软件开发的美在于其简洁性和规范性，不在于奇技淫巧。因为缺乏作业标准，我们付出的代价是客户的抱怨和无休止的返工。此外，对于那些以形式主意蒙人的项目团队来说，如果你实质如同你口头所说那样，也许你就不会是今天的这副狼狈相。
  十、 复用和组织变革原则－解决项目问题的未来之路
   如何解决日益突出的项目工期、成本、质量等问题，这是大多数项目管理者最为关心的问题。从实践来看加强复用的力度，建立项目复用体系和实施组织变革是效果较好的途径之一。复用能够提高项目的生产率，降低项目风险。通过复用，项目管理者能够快速的进入项目问题定义之中，减少项目开发人员的工作量，从而尽可能的解决项目在时间、资源方面的过载问题。另外一条途径是实施项目团队的组织变革（Moc），精简项目管理机构、重新定义工作职责，制定柔性的项目工作流程，改善项目开发人员的沟通状况，提高项目人员的开发效率，努力营造一个良好的项目开发环境。这样才能从根本上解决项目开发的种种棘手问题。 
  
   结论：作为一个项目管理者来说，了解和运用上述原则是不够的，若要深入的掌握项目管理知识和技巧，还必须深入学习项目管理（建议参看PMI《PMBOK》）、管理心理学、质量管理学、组织变革、系统论等方面的知识，并在工作中不断的总结和实践。唯有如此，我们的项目管理人员看自己个人简历时方不会觉得脸红，才能在公司中树立自己的管理权威性，同样也才会有一个良好的职业经理生涯的开端。 

   在一次由软件项目管理者组成的交流会上，看到过我所写的《软件项目管理原则谈》的朋友向我发问，如何在所学的项目管理理论和实际项目实践中找到一条连接的纽带；软件项目管理的度如何把握；为什么项目协调中更多的是貌合神离；为什么自己觉得自己所管理的项目老是失败等等。这一连串的问题引起了与会的项目管理者的同感，笔者本人也曾经在项目管理中屡遭挫折，目前的项目管理中依然麻烦不断。但是，作为一名软件项目管理者来说，在实施项目管理的过程中，笔者觉得在项目管理中，我们的大多数人常常在管理思维中留下一些空白，而这些空白正是我们公正、客观地评判和成功执行软件项目管理的必要途径。

　　空白1： 为效益而实施项目管理

　　为什么我们要实施项目管理，是为了提高项目的效益。这里所指的项目的效益是一个综合性的指标，包括低风险、高产出等。为此我们不难得出我们在实施项目管理应该掌握的度。即：引入项目管理后所产生的效益减去项目管理的成本后必须大于未引入项目管理时的效益。由于引入项目管理后所产生的效益与项目管理的复杂度（项目管理的成本）并非线性相关的，因此项目管理的复杂度必然存在一个最优值，这就是我们应该把握的度。也许上面的说法比较抽象。一个实际行之可效的判断项目管理的度规则就是：大家认可并且能够准确地理解和实施。拿美国项目管理专家James P Lewis的话说就是 KISS原则（Keep it simple and stupid），拿物理学家爱因斯坦的话说就是：Keep it simple but not too simple.

　　空白2： 考虑所处环境

　　任何系统都是建立在一个具体的系统环境中的，一般情况下受上一级系统影响最为显著，这是系统论的观点。项目管理是企业管理的下属层次，因此在很大程度上项目管理的成功与否常常受企业管理的制度制约（比如说设备采购的批复等待会延误工期），这就是为什么常常会出现计划不如变化来的快的原因。因为我们在制定计划时根本就没有考虑自身和客户双方的企业管理的环境，所以我们的计划在实施过程中会受到企业管理环境因素的影响。我敢跟你打赌：在没有人事激励机制常常拖欠或故意克扣员工工资但获得CMM5认证的公司开发效率不会比一个没有实施项目管理的开发团队的效率高多少。因为恶劣的公司人事制度扼杀了开发人员的天才和积极性。因此，作为一个项目管理者，审视自身的项目所处的企业环境并做出准确的判断是非常有必要的。缺少良好的项目环境，项目管理者的心血常常白费。这往往是我们中的一些项目经理在不同的公司里项目管理表现大相径庭的原因。

　　此外，正是基于企业环境这样一个观点，目前美国PMI，日本ENAA等提出了项目管理成熟度模型（OPM3和P2M），改变了传统PMBOK的缺陷（忽略外部因素和自身的灵活性）。有兴趣的项目管理者可以参看有关项目管理成熟度和企业管理方面（建议参看职业经理人方面）的资料。

　　空白3： 合理评判软件项目管理

　　我们总是把过多的项目失败归罪到项目经理的名头上。他们的角色常常是替罪羊而不是领导者，他们拥有的更多的是责任而绝非职权。实际上项目失败并非完全决定于项目管理，比如说信息系统过低的报价。一个项目按时在预算范围内完成了而另外一个则没有按时完成，这不意味着第一个项目管理得比较好。因为前者可能是项目时间和成本宽松的项目而后者根本就是不可能完成的项目。前者项目管理的意义在于获得较高的项目效益而后者的意义在于避免更大的项目损失。很可惜，充满了浮躁的软件企业没有诸如此类的意识，一些项目在未开始前注定就是失败的，项目经理们一上手便被扣以一责任人的镣铐。因此，项目管理有无具体效果，需要合理地进行评判，单纯以出效益为上的观点未必有失偏颇。

　　空白4： 心理学的必要性

　　没有一个领域像软件项目管理中人的因素更为重要，在软件领域没有实现自动化之前，一切试图取代人的主要作用的机制都是收效甚微的。人的行为是心智活动的表现。开发人员的心理活动决定了其在开发的表现。合适的压力能够勾起开发人员的成功欲望但是过大的压力却直接影响着项目参与者的身心健康。特别是后者一直以来都未能引起软件开发界的重视。很多人曾经有过不明不白的辞职经历，在没有学习《管理心理学》之前，笔者对这些人的"过激"行为有时想想都觉得奇怪。作为一个软件项目管理者，不了解和掌握管理心理学，很难针对复杂多变的人的因素采取合理的应对措施，同时自身的心理健康也未必能够得到保证。为此笔者建议有条件的软件企业，可以通过聘用心理顾问来处理员工的心理问题，以此缓和由于工作压力而导致的员工之间矛盾冲突和项目坍塌。

　　空白5： 尊重常识，系统性考虑问题

　　这个观点笔者在《软件项目管理原则谈》已经重申过。就像不要指望人一秒钟跑二十米一样指望项目中有过多的奇迹出现。可惜我们中的大多项目管理者在进行项目管理时依然实施"大跃进"。我们的管理者都知道自然规律不可违抗性，但是却很少有人意识到一些社会规律的不可违抗性。他们总以为唯物的主观能动性能够替代实际，产生奇迹。加班被认为是解决资源匮乏的唯一途径，通过开发人员"无上"的生产力来达成项目的成功。很少有人会意识到加班造成的疲劳会再次使工作效率降低这一事实。这是一种缺乏常识和系统性思考问题的表现。诸如此类的表现还有"唯工具论"和"唯方法论"。

　　实际上，项目管理涉及各个方方面面，一味提高某一方面作用而忽略该方面对其它方面的影响，并不能提高项目管理的层次和最终产出，这是制止我们的项目管理者走偏激（极端）立场的一剂良药，希望项目管理者们能有所意识。

　　空白6： 学会思考

　　项目管理不是拿来主义，需要项目管理者进行认真的思考。这就是为什么我们项目管理者中不乏PMP和IPMP但是项目却未能如愿以偿的原因。理论和实践的差距极大地挫伤项目管理者的积极性。"证书无用论"所持的观点其依据也在于此。理论是一种完美的抽象，而现实是各种条件的集合。我们的项目管理者在实践上往往生搬硬套而忽略其依存条件，这就是招聘项目经理"唯经验论"的来源。一位项目管理者跟我交流的时候提到无法使用挣值（Earned Value）的概念，原因是公司人事部和财务部不愿意出示员工的收入清单。我建议他将挣值换为挣时（Earned Time），以时间替代成本。从项目进度的意义上来看这两者其实是一致的，问题马上得到了解决。可惜的是我们的项目管理者往往未学会思考具体概念的真正含义之前并匆匆上驴，提着长枪去和风车做斗争去了（注：唐吉诃德）。

　　空白7： 学会计划

　　现实中我们往往用补救措施代替计划，其效果便如软件缺陷的放大效应。在项目经理的招聘中，你听到的只是几个项目管理白痴问你项目出了什么问题应该怎样解决的提问，这些项目管理白痴在不断地做各种问题假设，而你必须根据假设采取各种符合这些项目管理白痴口味的回答。但是，作为项目管理的来说，项目管理的真正意义在于事先预防各种偏离项目目标的问题出现而不是在于解决问题。古话说得好"磨刀不误砍柴工"。你不能期望癌症有100％的治愈率，但是你可以通过合理的生活习惯和锻炼来防止癌症的出现。我们在进行项目管理时，首先应该考虑如何防止问题的出现，虽然它不能保证所有的问题（风险）都可以避免，但是通过计划，你将拥有更多问题（风险）应对储备，能够在问题出现时有备无患。一个只会在问题出现时考虑应对措施的项目经理只是一个失败的项目经理。其项目结果无异是把健康交给医生而不是自己。作为项目管理的定位来说，项目管理应该是"管理会计"的角色而不是"成本会计"的角色。

　　最后，以某电影的台词来结束本文，人为什么犯病？简单的东西想复杂了，复杂的东西想简单了，人就会犯病"。拿这句台词来形容我们目前的项目管理状况一点也不为过。软件项目管理是一个从"自发"走向"自觉"的过程，也是一个从经验主义走向理性主义的过程。软件项目管理是一个主动的管理，而这一切，需要广大项目管理者的项目管理思维和积极实践。

软件开发和使用的历史已经留给了我们很多由于软件缺陷而导致的巨大财力、物力损失的经验教训。这些经验教训迫使我们这些测试工程师们必须采取强有力的检测措施来检测未发现的隐藏的软件缺陷。

    生产软件的最终目的是为了满足客户需求，我们以客户需求作为评判软件质量的标准，认为软件缺陷（ Software Bug ）的具体含义包括下面几个因素：

      1、软件未达到客户需求的功能和性能；

      2、软件超出客户需求的范围；

      3、软件出现客户需求不能容忍的错误；

      4、软件的使用未能符合客户的习惯和工作环境。

    考虑到设计等方面的因素，我们还可以认为软件缺陷还可以包括软件设计不符合规范，未能在特定的条件（资金、范围等）达到最佳等。可惜的是，我们中的很多人更倾向于把软件缺陷看成运行时出现问题上来，认为软件测试仅限于程序提交之后。

    在目前的国内环境下，我们几乎看不到完整准确的客户需求说明书，加以客户的需求时时在变，追求完美的测试变得不太可能。因此作为一个优异的测试人员，追求软件质量的完美固然是我们的宗旨，但是明确软件测试现实与理想的差距，在软件测试中学会取舍和让步，对软件测试是有百益而无一弊的。

    下面是一些软件测试的常识，对这些常识的理解和运用将有助于我们在进行软件测试时能够更好的把握软件测试的尺度。

测试是不完全的（测试不完全）

    很显然，由于软件需求的不完整性、软件逻辑路径的组合性、输入数据的大量性及结果多样性等因素，哪怕是一个极其简单的程序，要想穷尽所有逻辑路径，所有输入数据和验证所有结果是非常困难的一件事情。我们举一个简单的例子，比如说求两个整数的最大公约数。其输入信息为两个正整数。但是如果我们将整个正整数域的数字进行一番测试的话，从其数目的无限性我们便可证明是这样的测试在实际生活中是行不通的，即便某一天我们能够穷尽该程序，只怕我们乃至我们的子孙都早已作古了。为此作为软件测试，我们一般采用等价类和边界值分析等措施来进行实际的软件测试，寻找最小用例集合成为我们精简测试复杂性的一条必经之道。

测试具有免疫性（软件缺陷免疫性）

    软件缺陷与病毒一样具有可怕的 “ 免疫性 ” ，测试人员对其采用的测试越多，其免疫能力就越强，寻找更多软件缺陷就更加困难。由数学上的概率论我们可以推出这一结论。假设一个 50000 行的程序中有 500 个软件缺陷并且这些软件错误分布时均匀的，则每 100 行可以找到一个软件缺陷。我们假设测试人员用某种方法花在查找软件缺陷的精力为 X 小时 /100 行。照此推算，软件存在 500 个缺陷时，我们查找一个软件缺陷需要 X 小时，当软件只存在 5 个错误时，我们每查找一个软件缺陷需要 100X 小时。实践证明，实际的测试过程比上面的假设更为苛刻，为此我们必须更换不同的测试方式和测试数据。该例子还说明了在软件测试中采用单一的方法不能高效和完全的针对所有软件缺陷，因此软件测试应该尽可能的多采用多种途径进行测试。

测试是 “ 泛型概念 ” （全程测试）

    我一直反对软件测试仅存在于程序完成之后。如果单纯的只将程序设计阶段后的阶段称之为软件测试的话，需求阶段和设计阶段的缺陷产生的放大效应会加大。这非常不利于保证软件质量。需求缺陷、设计缺陷也是软件缺陷，记住 “ 软件缺陷具有生育能力 ” 。软件测试应该跨越整个软件开发流程。需求验证（自检）和设计验证（自检）也可以算作软件测试（建议称为：需求测试和设计测试）的一种。软件测试应该是一个泛型概念，涵盖整个软件生命周期，这样才能确保周期的每个阶段禁得起考验。同时测试本身也需要有第三者进行评估（信息系统审计和软件工程监理），即测试本身也应当被测试，从而确保测试自身的可靠性和高效性。否则自身不正，难以服人。

    另外还需指出的是软件测试是提高软件产品质量的必要条件而非充分条件，软件测试是提高产品质量最直接、最快捷的手段，但决不是一个根本手段。

80-20 原则

    80% 的软件缺陷常常生存在软件 20% 的空间里。这个原则告诉我们，如果你想使软件测试有效地话，记住常常光临其高危多发 “ 地段 ” 。在那里发现软件缺陷的可能性会大的多。这一原则对于软件测试人员提高测试效率及缺陷发现率有着重大的意义。聪明的测试人员会根据这个原则很快找出较多的缺陷而愚蠢的测试人员却仍在漫无目的地到处搜寻。

    80-20 原则的另外一种情况是，我们在系统分析、系统设计、系统实现阶段的复审，测试工作中能够发现和避免 80% 的软件缺陷，此后的系统测试能够帮助我们找出剩余缺陷中的 80% ，最后的 5% 的软件缺陷可能只有在系统交付使用后用户经过大范围、长时间使用后才会曝露出来。因为软件测试只能够保证尽可能多地发现软件缺陷，却无法保证能够发现所有的软件缺陷。

    80-20 原则还能反映到软件测试的自动化方面上来，实践证明 80% 的软件缺陷可以借助人工测试而发现， 20% 的软件缺陷可以借助自动化测试能够得以发现。由于这二者间具有交叉的部分，因此尚有 5% 左右的软件缺陷需要通过其他方式进行发现和修正。

为效益而测试

    为什么我们要实施软件测试，是为了提高项目的质量效益最终以提高项目的总体效益。为此我们不难得出我们在实施软件测试应该掌握的度。软件测试应该在软件测试成本和软件质量效益两者间找到一个平衡点。这个平衡点就是我们在实施软件测试时应该遵守的度。单方面的追求都必然损害软件测试存在的价值和意义。一般说来，在软件测试中我们应该尽量地保持软件测试简单性，切勿将软件测试过度复杂化，拿物理学家爱因斯坦的话说就是： Keep it simple but not too simple 。

缺陷的必然性

    软件测试中，由于错误的关联性，并不是所有的软件缺陷都能够得以修复。某些软件缺陷虽然能够得以修复但在修复的过程中我们会难免引入新的软件缺陷。很多软件缺陷之间是相互矛盾的，一个矛盾的消失必然会引发另外一个矛盾的产生。比如我们在解决通用性的缺陷后往往会带来执行效率上的缺陷。更何况在缺陷的修复过程中，我们常常还会受时间、成本等方面的限制因此无法有效、完整地修复所有的软件缺陷。因此评估软件缺陷的重要度、影响范围，选择一个折中的方案或是从非软件的因素（比如提升硬件性能）考虑软件缺陷成为我们在面对软件缺陷时一个必须直面的事实。

软件测试必须有预期结果

    没有预期结果的测试是不可理喻的。软件缺陷是经过对比而得出来的。这正如没有标准无法进行度量一样。如果我们事先不知道或是无法肯定预期的结果，我们必然无法了解测试正确性。这很容易然人感觉如盲人摸象一般，不少测试人员常常凭借自身的感觉去评判软件缺陷的发生，其结果往往是把似是而非的东西作为正确的结果来判断，因此常常出现误测的现象。

软件测试的意义 - 事后分析

    软件测试的目的单单是发现缺陷这么简单吗？如果是 “ 是 ” 的话，我敢保证，类似的软件缺陷在下一次新项目的软件测试中还会发生。古语说得好， “ 不知道历史的人必然会重蹈覆辙 ” 。没有对软件测试结果进行认真的分析，我们就无法了解缺陷发生的原因和应对措施，结果是我们不得不耗费的大量的人力和物力来再次查找软件缺陷。很可惜，目前大多测试团队都没有意识到这一点，测试报告中缺乏测试结果分析这一环节。