本阶段项目我们一共发现了千余个bug，通过场景及用例发现的bug只有10%；造成这种情况的原因一是因为产品处在维护阶段，先前通过用例及场景发现的问题已经不再复现、二是我们提倡以已有用例、场景激发思考，却没有将思考形成可见的交付物的导向。

    我们在每个项目的关键决策点上都在找各种产品质量状态、进度以及产品存在的潜在风险等的衡量标准，却把测试人员最根本最重要的一项工作：测试用例（场景）的设计给淡化甚而忽略了。测试用例的覆盖度、执行情况、通过情况恰是产品质量、进度及潜在风险最好的衡量指标项及参考项，也是制定测试计划、做测试跟踪的关键参考项。

    测试用例是测试人员做测试的根，测试用例设计是测试执行之前的'战略部署'，忽略了这个环节无疑是在给测试一开始就做的不合格打上的胎记。

    但是，对于一个生命周期已经处于维护阶段的产品，当先前设计的用例或场景在当前版本所发挥作用更多体现在作为验收（验证正确性）测试的依据时，如果在没有对用例及场景进行维护的背景下、在项目进度要求很紧张的大背景下，测试前期安排此类测试显然是不合适的。同时，当紧张的项目安排容不得测试进行详细用例设计便需要进入测试执行的情况下，又如何做到对测试场景及用例的持续更新呢？

    1、将测试用例的设计与编写常态化，不是说在一个项目结束而另一个项目开始之前插空，而是在测试执行过程中边测试边记录。这个被业界大师称之为探索性测试时的一项必做的测试任务，除了bug，它也是探索性测试的一个重要交付物。如果把测试过程中的想法形成交付物，大家又比较担心影响进度及所耗成本的问题，其实这个也好解决：试想一个测试人员测试了一整天，她/他当天测试思路及设计可能在下班前总结下花上半个小时便可以整理出来，只是缺乏这种意识，我们也没有这种导向，从而造成好想法及点子的流失和不可复用。这里提到了测试用例的设计而不是编写，也从一个层面上说明我们不必纠结是否要长篇大论把所有数据逻辑前后关系都写明白，只要把业务流程、关键验证点以及测试思路（等价类、边界值还是错误推测？）在原有的测试场景库上完善进去即可。但这个需要业务和测试技巧均比较熟练的测试人员才可以做到，初学者前期实施会比较吃力，同时粒度、深度、重要程度均需要制定规范并审核。

    2、真正的基于用户应用测试场景/用例设计：哪些业务流程或功能是用户经常使用的，这个前期我们在设计用户场景时也划分了优先级。但随着客户的增多、应用的逐步广泛，反馈问题的逐步积累，先前的测试场景无疑会显得过时了。也许先前认为用户不常使用的场景及功能点如今已经被新的用户作为重点使用，怎么办？及时维护，获取的渠道当然很明确来源于客户：样板及客户化组即内部客户，实施或用户反馈即外部客户。在任务没有直接关联的背景下，很难做到将此工作常态化，更合适的方法可以采用确定固定人员定期每月对客户（样板组、反馈组）进行一次访谈及问题梳理，再落实为任务单独安排1-2个工日做测试场景/用例完善。

    3、如何保证测试用例设计的8/2原则：可以解读为将80%的精力投入在重点测试用例的设计上，发现80%的bug，而不是投入在非重点的测试用例设计上；也可以解读为通过系统功能、模块覆盖度为20%的测试用例，发现80%的bug，即设计合理的测试用例保证bug覆盖度。这个可以通过各种途径熟悉用户应用模式、熟悉系统整体业务，掌握测试常用技巧及经验积累，这一点没有更好的办法，只能保持持续学习的一颗心，在任务中锻炼，循序渐进，一步一个脚印，踏实积累。

    ......

    天下无难事，只怕有心人，对于理论及方法已经相对成熟的测试用例设计，如果可以引起测试人员的重视并给与正确的引导，即使系统很庞大、业务很复杂、新手很多，也总会是方法会比困难多。怕的是没有被重视，没有人去规划。

    项目数十人参与并持续了数月，虽然最终产品通过发版评审，但我仍然心有余悸。因为，我观察到我的团队成员在项目开发过程中不幸福，产品的发版伴随的不是香槟、庆祝和成就感，而是被迫、压抑、欲言又止以及无数个为什么。

    不幸福感不是来源于高强度的加班，也不是被批评被否认导致的信心缺失，而是因为，项目在进行的过程中由于一次次的变更让组员们迷失了，而我们并没有及时的把大家拉回来，没有明确的目标和方向，犹如在黑夜里无际的大海中摸索，虽然最终天亮的时候我们上了岸，但过程终究是忐忑的、不安的、不幸福的。总结一句话，产品是成功的，项目是失败的。失败的项目，或者叫失败的项目管理，引起的项目管理核心团队招来骂名理所当然。

    项目在进行系统测试阶段后，都是一直在被测试牵引的，测试兼顾了发现问题、反馈并预测风险、质量汇报及监督的众多职责，测试管理的好坏直接对项目的成败产生关联，测试主管理所当然成为风口浪尖上的关键人物，上要做好正确客观的反馈及汇报沟通、下要合理调整计划并给与团队以安抚激励指导，一招不慎就会对大家的认知产生不好的影响，尤其在关键决策点项目核心成员不能合理决策的情况下更要谨慎细致。在产品质量整体可控的大背景下，强势的测试可以打造高质量的产品，强势的质量经理可以引导项目经理做出正确的决策，强势的项目经理可以引领一个项目走向成功，项目及产品同时成功才可以提升项目成员的幸福感。需要的改进：

    1、强化项目及测试管理尤其是计划管理，将管理工作作为任务来执行

    2、项目周期较长时，制定多个里程碑阶段性总结讨论及团队活动

    3、组员面对面沟通：面谈、吃饭等

    4、强化过程鼓励及激励，奖罚分明，明确标杆

      最近领导提了一个有关‘知识窃取’的话题，很诧异，这让我想起小时候我堂弟调皮捣蛋，自己不完成作业，通过各种手段抢到小女生的作业本，在作业本的首页将小女孩的名字划掉，写上自己大名的故事。

    曾经有一个同事也提到过此类问题，大意为自己好心好意把辛辛苦苦总结出来的东东拿给别人分享，最后接受分享的人却没有任何感激之情。瞬时回心转意，倍感失落。

    我们是纯脑力劳动者，当发现自己曾经做过的东西，被另外一个人在公众场合毫不隐晦的宣讲时，可能让人惊叹的不是她/他的毫不客气，而要惊叹于她/他的学习能力如此之强、之快，我们本来处于一个高度发达的信息时代，我们的学习资源都是免费的，任何人为我们提供的知识帮助也都是无偿的，那就完全没有必要计较自己总结的东东被别人‘剽窃’。反而应该从中给自己施加压力，别人这么快速的就学到了，自己还要继续提升，另外也应该小自豪下，自己也是别人的榜样。

    ‘窃’字不可取，应该叫做‘分享’‘学习’之类更为贴切：）

    其实这点老大已经给作出的榜样，用心的人会发现，老大的书遍布于很多项目成员的书桌上，也许是有关项目管理的，也许是有关沟通的，也许是技术相关的，甚至有些是有关创业的，而且每本书都是经过标记的，不是买来当摆设的。

1、System:%Total process time:

系统中所有处理器都处于繁忙状态时的百分比，对于多处理器来说，该值可以反映所有处理器的平均繁忙程度。

2、Processor %Processer time：

单个进程CPU利用率

3、System:Process Queue length:

线程在等待分配CPU资源所排队列的长度，此长度不包括正在占有CPU资源的线程。一般要<=处理器个数+1

4、Process:Private Bytes:

进程无法与其他进程共享的字节数量，该计数器的值比较大时，有可能是内存泄漏的征兆；也可以理解为只被本进程所占用的虚拟地址空间，不包含其他共享的内存。包含引起和不引起Page fault和引起Page fault的内存。

5、Process:Working set:

最近处理线程使用的内存页；或者称为一个进程可以用到但不一定会使用的物理内存，这个值也包含了其他进程也可以访问的内存，所以加起来会大于系统实际内存。只包含不引起Page fault的内存。

6、Process:Virtual Bytes:

一个进程可以占用的全部虚拟地址空间，32bit操作系统一般到2G，但可以通过修改Boot.ini扩展修改到3G

Private Bytes 一般大于 Working set ，任务管理器中看到的内存使用量一般等于Working set（实际测试时不等，待纠）

另外看内存泄漏的工具推荐使用VMMap和Proxp

谨记！

最近做的项目有非常深刻的体会；

一头狼带领的一群羊 要比一只羊带领的一群狼更有效；

如果做到管理高层凡事还要亲力亲为，确实是一个悲哀；

多项目管理文摘，如下，学习之：

http://www.kuqin.com/projectmanage/20090316/40309.html

1、导致CPU瓶颈的一般原因： （1）加密解密 （2）垃圾回收 （3）压缩解压缩 （4）运算 （5）过度编译

2、导致软件性能问题的原因 （1）外因：网络、服务器配置等 （2）内因：代码架构设计资源加载等

3、性能调优四部曲： （1）问题陈述 （2）处理计划 （3）数据收集 （4）数据分析

4、小问题引发大的性能瓶颈非常之常见

5、性能调优;耗成本的过程，性能调优的目标要明确什么时候可缓缓，什么时候可以停止 

6、提升性能做法： （1）分析用户习性 （2）内存瓶颈分析 （3）常见优化点：字符串，session,缓存，对象池 （4）DB、线程、文件，资源释放等

7、Armory:设备与IP管理工具

8、救火队员

9、ebay:最大的表，有13T！！？？没听错吧 每秒3000刀了的交易 10、20w台服务器的规模，怎么管？

.... 

1、对于一些软件比如对安全性要求较高的金融软件，宁可让一个小bug将系统搞崩溃掉也不要绕过这个bug让系统继续运行，因为一旦出现类似帐不平的问题，损失将是巨大的，所以从软件测试的角度来讲，针对不同的业务，对bug等级及优先级的定位、对bug的处理方式都是不一样的；同理，对安全性要求较高的系统，调试版本可能会比release版本更可靠。
2、他山之石、可以攻玉
3、50%的hack通过缓冲区溢出等方式获取相关地址，然后把病毒注入
4、软件开发过程中为测试提供更多的接口将可以提升软件的可测试性，为自动化测试提供基础
5、测试人员可以与开发人员亦敌亦友
6、老马识途，越是有能力的人做出来的软件质量越高
7、转储：将内存中的错误信息以文本文件等的方式输出出来，生成错误报告，因为内存中的信息是容易挥发的
8、微软的遥感技术：将用户使用微软产品过程中遇到的问题自动生成错误报告自动发送到微软相关的服务器上，这个我们的软件也可以借鉴，不过自动诊断、定位并搜集发送错误报告需要启动另外一个进程
9、一般的Log文件处理时都会有隐含锁，可能会有等待等情况导致性能问题，所以加Log、诊断、跟踪等相关功能时需要考虑对于系统性能的影响
10、PDB文件中含有调试和项目的状态信息，所以从安全的角度讲一般都不要暴露给别人
11、DFX/DFD,desigh for debug/test/....
12、Grace fot fail
13、托管代码：microsoft的中间语言，他主要的作用是在.NET FRAMEWORK的CLR执行代码前去编译源代码，也就是说托管代码充当着翻译的作用，源代码在运行时分为两个阶段：1.源代码编译为托管代码,（所以源代码可以有很多种，如VB,C#,J#) 2.托管代码编译为microsoft的平台专用语言。
14、Access violation at address <十六进制值> in module <应用程序名> Read of address <十六进制值>
Windows用户可能经常会看到类似于错误提示：“Error：Access violation at address 836556F8
（004096da）. Read of address 836556F8（00401000）”
通常的原因如下：
（1）调用一个不存在的对象
大部分Access violation的合理原因是使用了没有被创建或者已经被释放的对象。为了防止
这种类型的Access violation的发生，请确保你访问的任何对象都首先被创建了。例如，当一个Table定
位在一个没有被创建的data module（从auto-crete窗口里移走了）里，你可能在窗体的OnCreate事件里
打开这个表。
在下面的代码里，在调用一个已经被删除了的对象（b:TBitmap）事件后，一个Access violation出现了
：
var b:TBitmap;
begin
b:=TBitmap.Create;
try
//对b对象进行一些操作
finally
b.free;
end;
...
//由于b已经被释放，一个Access violation错误将会出现
b.Canvas.TextOut(0,0,’这是一个 Access Violation’);
end;
（2）不存在的API参数
如果你试图给Win API函数传递一个不存在的参数将会出现一个Access violation错误。解决此类Access
violation错误的最好方法是查阅Win API帮助，看看这个API函数调用的参数信息以及参数类型。例如，
总是保证不给一个缓冲参数传递一个无效指针。
（3）让Delphi释放
当一个对象拥有另一个对象时，让它给你做删除工作。因为默认情况下，所有的窗体（自动创建的）都
属于Application对象。当一个应用程序结束时，它释放了Application对象，也就释放了所有窗体。例
如，如果你在程序开始时自动创建了两个窗体（Form1/Unit1和Form2/Unit2），下面的代码就会导致
Access violation错误的出现：
unit Unit1;
...
uses unit2;
...
procedure TForm1.Call_Form2
begin
Form2.ShowModal;
Form2.Free;
//Access violation错误将会出现
Form2.ShowModal;
end;
（4）杀死异常
永远不要破坏临时异常对象（E），处理一个异常会自动释放异常对象。如果你自己手动释放了异常对象
，程序会试图再次释放它，那么就会出现Access violation错误：
Zero:=0;
try
dummy:= 10 / Zero;
except
on E: EZeroDivide do
MessageDlg(’不能用0做除数!’,mtError, [mbOK], 0);
E.free. ////Access violation错误将会出现
end;
（5）检索一个空字符串
一个空字符串是没有任何数据的。就是说，检索一个空字符串相当于访问一个不存在的对象，这将导致
Access violation错误：
var s: string;
begin
s:=’’;
s[1]:=’a’;
//Access violation错误将会出现
end;
（6）直接引用指针
你必须间接引用指针，否则你会改变指针地址并可能会破坏其他存储单元 ：
procedure TForm1.Button1Click(Sender: TObject);
var
p1 : pointer;
p2 : pointer;
begin
GetMem(p1, 128);
GetMem(p2, 128);
//下一行导致Access violation错误
Move(p1, p2, 128);
//下一行方法正确
Move(p1^, p2^, 128);
FreeMem(p1, 128);
FreeMem(p2, 128);

可能遇到的问题：sqlserver服务启不来

1、msconfig--boot.ini--高级选项--/NUMPROC（N）=1--确定
2、重启机器
3、开始安装
4、安装完毕后
5、将核数再改回来

 

sqlserver性能优化：

1、性能优化要考虑ROI,即投资回报率，因为优化无止境，切忌追求完美和不计成本的性能优化
2、CPU利用率高并不代表性能存在问题，因为很多性能很好的系统通常在CPU利用很高的情况下有很强劲的运算速度，较高的CPU使用率通常代表资源的充分利用，升级硬件往往对于性能提升会更明显
3、数据库阻塞不等于数据库死锁，两个连接陷入死锁时，其中一个连接被选作死锁牺牲品；该连接的事务回滚，同时应用程序收到错误，当一个连接控制了一个锁，而另一个连接需要冲突的锁类型时，将发生阻塞。其结果是强制第二个连接等待，或在第一个连接上阻塞；阻塞是由于锁机制，所以锁机制是一把双刃剑
4、性能优化要分阶段优化，是一个迭代过程，从软件的设计期开始
5、对于高CPU占有率的工作负载而言，其最佳并发数就是CPU（或者是CPU里的核）的数目。然而，进程不总是可以运行的，因为它们会执行阻塞式调用，比如I/O、数据库查询和网络请求等。因此，最佳并发数往往会多于CPU数目
6、日志文件通常比较耗用系统资源，所以应该对其进行一个控制
7、内存的压力可以导致I/O瓶颈
8、一些hash、排序算法等都会影响到内存的使用
9、缩短等待时间是数据库性能优化的一个很重要的点，出现等待通过代表系统资源不够用
10、导致数据库性能出现问题通常的有重编译、游标的不良使用、不好的查询机制等等

 

 

以前跟人讨论有关软件开发中业务或技术方面问题的时候，总会说技术向来不是软件开发的难点，而且一直都很认同。但现在在**，随着性能测试工作的深入、DBA新鲜血液的加入、标准版逐步暴露出来的各类问题等的进展，这种观点逐步被打破，因为在目前的**，技术难点逐步被一 一暴露了出来。不是技术出身，也不是架构师，对于**系统架构了解很浅，所以，对于这块只能谈些**系统架构对于性能测试方面的影响之类的浅薄理解。

1、 多层加密和数据压缩以及非标准协议引起的第三方性能测试工作应用困难的问题：

加密的目的为了安全，压缩的目的为了效率，B/S是为了与时俱进，很多业界ERP或其他管理类软件的的产品性能测试用的是LR等专业性能测试工具，业界此类产品应该也考虑到了安全性、效率等各方面，人家能用起来，如果我们的系统架构提供支持，也是应该可以用起来的，这个支持意味着重构或方案重新选定，挑战不小。

2、 不支持数据库升级导致分析用户数据后通过脚本来实现构库困难重重：

目前之所以无法把**或以前**里面的数据导过来或者通过升级来实现，除了业务变更的影响外，还有就是**系统架构或者数据库以及表结构在变，导致无法处理升级；因为**比较年轻，以后的路还很长，用户的需求也会一直在变，系统架构随着业务变是不可避免的。这块对性能测试的直接影响就是数据怎么来？写脚本和构库花费大量的工作，不过这个目前倒是有方案，只是投入会比较多。以后**如果重构或新产品上线，在技术层面上这些应该都要纳入考虑范围的。

3、 **工具的继续开发维护被搁浅：

**是当初解决问题1的一个很好的东东，测试这个阶段也完善了一些对此工具的需求，如：

需求	需求描述	状态
支持命令行调用		已实现
支持结果输出		已实现
支持录不同操作		已实现
用GTF动态改录制的参数		已实现
支持在修改并发数据量（界面/命令行）	如录制100个操作，回放时可以选择性的设置回放其中的如5个、10个或50个操作，并支持逐步加压的方式，如每隔5s加10个操作等	未实现
支持记录捕获不同操作数据包的数据表名可动态命名	可以录制不同操作，如保存、查询、打开、新增的混合操作	未实现
支持捕获数据按方法取代原来的按界面按钮	基于方法的录制，比如下载附件等操作，没有按钮，通过直接回放方法进行模拟	未实现
支持在备份库上回放	每次回放没必要把数据删除后进行，而是找一个干净的备份库可以直接回放	未实现

目前这块的需求被搁浅，其实这是个很好用的工具，借用业界第三方专业的性能测试工具的功能，当易用性及相关功能完善后，可以针对这段时间发生的各类问题设计一些测试场景，快速的发现一些问题，部分问题的复现有时比**要快捷多了，浪费了就可惜了。

**系统技术架构对于性能测试的影响分析跟业务架构相同，都需要经历逐步积累的过程，不经历不知道，经历之后才能改进，测试人员会跟上产品的步伐，与时俱进。

 

 

 

软件即服务，注定软件的开发过程是围绕所服务行业、公司或部门业务来转的；无论是需求分析、编码还是测试，任何一项脱离了业务，都是没有意义的。对于测试，脱离业务的测试，无论是功能还是性能都没有徒劳无功的。测试讲究Good-Enough原则，或者叫做适用性原则，过少的测试是不负责任的表现，过多的测试也是一种资源的浪费，在**，如何做到Good-Enough，关键点仍然在基于用户业务应用模式或者叫用户应用场景的分析。

功能测试我们已经做了很多年，从**到**，我们基于用户应用场景的分析尽量想做到覆盖全且精，测试人员通过与需求、产品、实施、运维人员沟通、直接去现场或电话、远程处理用户反馈问题等各种方式了解业务，这里的业务不仅包含需求文档里面能找到的东西，更多的是对于用户究竟如何应用以及可能如何应用的思考。但当**逐步需要支撑规模化应用，需要像业界ERP/CRM系统那样支撑大、中、小型企业级应用的时候，我们又有些迷茫，因为没有人，需求？产品？实施？销售，甚至即使是现有客户能够直接告诉我们：

要做更合理的性能测试，针对不同规模的企业级应用：

（1）    如何构造合理的数据库？

（2）    如何区分大/中/小型企业？如何区分大/中/小型项目？分别是什么样规模？分别如何管理及应用？不同规模的项目如何在系统中分布？不同的应用规模，对于业务的应用有哪些不同，或不同侧重点？

（3）    一个**系统，不同应用的规模，每天甚至每小时会多少个用户同时在线？分别在做哪些操作？每天或每小时一个人最多可以干多少活？（录入多少数据）

（4）    对于现有用户还没有应用起来或不稳定的业务，如生产，数据如何构造？

（5）    集团、公司、项目同时使用系统的角色比例情况如何？

（6）    哪些业务或模块、操作会被用户会经常使用？哪些是已经熟透的需求哪些还处于探索阶段？

…..

一系列的问题，均为**业务应用的范畴，对这些问题的解答来自于对客户应用模式的真正了解，不了解的情况下所做的猜测都是徒劳的，想不到要了解这些对管理类软件的长远发展的影响是可悲的。

对于**测试，接下来对业务的理解范畴，对于用户业务场景的分析，需要加入这些，这些不仅是对性能测试场景设计有用的逻辑，对于功能测试场景设计以及版本质量标准的定义，做到Good-Enough的测试，制定版本质量标准等等也是极具有指导意义的。

**还很年轻，我们逐步从分析用户应用日志、尽量找能了解一些的人沟通，找寻业界管理类软件测试等种种方式期望能发现一些马脚，相信后续的**，**业务，**测试，均会具有极其广阔的发展空间。

**业务分析与了解，我们，任重道远。