2007年写的年终总结主题为《过程改进》，年终了，分享了

1)         问题一：非所有测试包都存在固定的测试报告与必要的数据分析

导致问题：没有对全面测试产品版本进行差异化分析，由此，难以以测试角度提出对产品研发过程的改进意见。如：

a)         产品研发过程中，研发人员常见的错误来源。

b)         产品研发过程中，配置管理出现的遗留与疏忽。

c)         产品研发过程中，测试人员理解的需求偏差。

解决办法：

a)         建议对版本测试计划进行细分，规划第几轮进行全面测试版本，哪些轮是回归测试。根据版本实际情况，决定是否需要初验，需要回归的时间与轮数，是否需要评审相关测试需求与测试用例，并在转华为测试前决定是否需要增加一轮或多轮某种类型的测试。

b)         建议对全面测试版本进行差异化分析，由质量管理部门按月公布相关统计数据，对项目内部存在疏漏或问题原因，尽快进行调查与分析，查漏补缺，进一步提升版本质量。

 

2)         问题二：项目中期，迭代周期时间过长，建议对问题单解决版本进行规划

导致问题：Bug分类是以测试人员的经验而定，而实际Bug级别应由项目本身决定。在产品发布前对存在的Bug无法做出准确判断，以条件反射为例，测试人员一般填写的Bug级别都在High以上，这并不能说明该实际属于高危险。则可能出现，开发疲于奔命但并没在第一时间解决优先级较高的问题，这样会造成问题单修改时间延长，错过最佳迭代时间。项目周期延长，工作效率降低。因为在大符合测试的情况下，测试效果较好的时机一般是在两头。项目中期，因为时间跨度较长，且问题单反复出现，挫伤了团队激情。

解决办法：

个人认为Bug的实际级别应该由开发人员与测试人员共同决定。当测试人员提出问题单后，开发经理应对其问题单进行一定评估(或与测试部商议，特别是一些暂时内部挂起的问题单，完全可以规划一个后续的版本进行解决)，对一些低优先级别较低不影响内部测试问题单进行统一规划，并非需要对每个问题单都在该轮就进行处理。按照以上的思想，如果规划合理，对于内部迭代时间将明显的提高。

 

3)         问题三：用例未进行标准的覆盖计算

标准的用例计算方式，分为两个过程：1、对产品测试需求的评估，主要是测试人员与开发人员一起评审。2、测试执行的评估，在测试规划的全面测试版本或特殊需求版本，若需要执行测试用例，需对测试结果及测试执行过程进行一定控制，如：执行覆盖率在80%以上，代码覆盖在每千行5个用例等。

导致问题：项目进行中对初始化测试用例，进行了新一轮的调整后。对于新的用例，开发人员有的进行了评估，有的可能由于项目时间紧而无暇关注。此问题最终会导致开发产品与实际需求存在较为严重的理解偏差，如果在项目成型后在对局部代码进行修改其开发量与项目风险将非常巨大。另一方面，现有的测试用例执行只能对执行结果进行控制，对用例失败原因或因部分功能问题未能执行的测试用例，很难有效的计算与统计 (特别是针对用例执行失败的原因)。此问题会造成一些功能点的漏测，增加后期版本的发布风险。

解决办法：在TD中增加对测试用例覆盖率计算，并督促研发人员对各模块功能进行测试评审。若已经达到全覆盖，可在TD中标明。（个人觉得由研发与测试人员一起在用例中注明，以金山的管理办法是双方一起签字，对个人负责的功能，开发人员有义务督促测试人员进行测试，否则

项目发布后，线网问题单与转华问题单应由双方共同负责。）

 

4)         问题四：对数据库脚本与产品申请包，缺少必要的测试验证

导致问题：在产品测试过程中有时会出现如：数据库脚本问题、数据结构问题、测试初时化数据未全部导入、版本测试包资源问题等，造成严重的资源浪费和不成比例的时间投入。

解决办法：

a)         在开展测试工作前，存在某种测试验证机制。如准备项认购表，其中可记录开展后续阶段测试工作，应该满足的详细设备及参数条件。以原东软老的开发体系而言，对测试前、中、后清单要求较为严格。测试清单可以由部门及研发中心配合完成，如建立这样对等体系可在测试开始前杜绝由测试数据、环境及其它相应因素所导致的资源浪费问题。

b)         建议增加对数据脚本的内部版本控制机制，对内的测试版本与数据脚本分开取放，此举是为了应对多项目、多版本、多分支情况。而对于发布版本也可以使用工具进行核对，对已转测内部或发布的版本也能较好的进行资源控制。

c)         建议开发团队引入测试验证服务器，既在转内部测试后，开发组部署及安装最新的内部测试版本。在测试组对其进行测试验证时，开发组能在此服务器上对该版本进行烤机操作，此举是为了提前暴露由稳定性导致的系统问题。另一方面，为了解决测试版本与各开发人员版本不一致问题，开发人员定位问题请在此服务器上进行验证，并根据版本发布时间取相应的基线版本进行修改。

 

5)         问题五：缺少以主题形式讨论模式

导致问题：部门工作主要以个人为主体，很难形成较为深入讨论机制。势必在工作中缺乏足够的热情，各自为战的工作状态，在某种程度上也会响应各员工成长空间。

解决办法：在测试过程中，把个人的想法及后期的解决思路以邮件的形式向部门及研发中心同事进行征询，以求更多解决思路。再把整合的思路与各产品经理与项目人员进行沟通最终确定后续的解决方案，保证测试工作的顺利进行。另一方面，针对每个人员的不同特点，应保持每个测试人员至少存在一个研究方向。在项目时间中合理分配定期对这些研究成果进行展示，由部门经理打分并计入考核部分。

 

1.1.1    项目问题：

1)         问题一：缺乏有效的自测机制

导致问题：从整体内部测试的问题单来看，我们分析了几个比较大的版本，其中发现有20%bug都应该是在单元测试阶段就可以进行控制的，例如系统管理中一些边界值的输入、行为分析模型0级1级、模块启动或停止出错，诸如此类。

解决方法：

a)         建议开发人员能在代码提交前，对基础功能及流程进行一些验证，这些问题完全是可以避免的，这样可以省去很多后期回归、修改bug的过程，大大提高我们的工作效率。

b)         增加对内部Reopen问题单的跟踪机制，与华为问题单相同，增加对开发人员自测用例的填写，并填写相应测试建议。即便开发组人员没有时间对问题逐个验证，也应该提供相应的测试风险评估意见，便于测试人员能尽早的预知风险，对修改功能及优化部分及时规划测试时间与详细计划。

 

2)         问题二：打包资源混乱

导致问题：纵观整个内部测试版本，我们对比最近的几个内部测试版本，发现打包缺失及打包错误的不占少数。而此类问题，绝大多数是在涉到相关模块的具体问题时才被暴露出来。此类问题将造成严重的资源浪费。

解决方法：

a)         建议在开发组增加公用测试机，任意PC，验证问题。

b)         对即将打包转测的内测版本，先在公用机上进行部署与安装，项目组人成员每人花30分钟时间对发布版本进行简单验证至少保证资源正确。

c)         建议增加对数据脚本的控制，建立对内部版本可控机制。测试组负责人从配置库上取得相关版本数据库脚本变更说明后，对每个变更内容进行确认，把所有变更内容依附在缺陷管理工具测试计划项中，便于项目组成员逐一进行核对。

 

3)         问题三：版本质量无法控制

导致问题：早期问题在后续版本中持续出现，且每轮问题单数量无法预计，版本修改及方案调整不可控制。转测试过程中，导致一些基础功能出现问题。

解决办法：

a)         定期对产品问题单进行回访验证。

b)         按照华为相关标准，对内部转测版本功能变更进行更佳严格控制。

 

4)         问题四：文档追溯力度需要加强

导致问题：在进两次转测的华为问题单中，包含大量对文档检视的问题单报告。当局部需求变更后，操作文档及相关手册没有即时更新，致使一些功能修改后无法追溯到现有的转测文档。在内部测试过程中，我们也发现一些相同现象，由于测试人员不熟悉变更需求，导致无效问题增加，加重了开发组对内沟通时间。另一方面，由于开发组方面没有即时更新需求文档或数据库说明书，所导致的功能问题在总问题单中也不占少数。

解决办法：

a)         加强每个功能点对文档追溯的力度，使每个功能点均有据可依。

b)         加强对文档修改的管理，在内部转测后需要对所有新增需求进行测试必要的测试分析，尽可能在项目开始前期，就能较早的发现相关问题。

 

5)         问题五：部分测试用例没有即时更新

导致问题：通过产品的测试可以看出对于功能方面测试用例的准确性显得尤为重要，因为测试的全过程基本是依据测试用例的框架而展开的，但是由于在产品开发过程中的一些需求的变动，在项目测试间部分测试用例没有随之及时的更新。此问题造成一些功能测试方面疏漏，为后期产品发布增加项目成本与发布风险。

解决办法：

a)         在项目测试过程中，对新增功能规划必要的测试用例修改时间，便于测试人员掌握最新需求变更，对每个功能点变更流程及处理方式都有一定了解与认知。

b)         加强测试用例的阶段性维护，针对项目需要规划特殊的测试用例，如：异常测试用例、接口测试用例等。

 

6)         问题六：产品规划与优化方案

导致问题：对于后续产品的规划把握不够，以至测试团队无法对后续产品提出必要的修改建议。对于各个模型的业务理解不够，对模型实际用法与监控方式没有收集相关的数据资料。与华为接触时，很难反驳对方观点，造成我方整体开发显得比较被动。

解决办法：

a)         对现场数据进行收集整理与归档，为后续产品的稳定性测试和大数据量测试提供理论依据。

b)         在项目运作的各个阶段，收集项目组内部持续改进意见，建立内部需求树，为新的优化方案规划解决版本。

 

7)         问题七：稳定性测试与性能优化需要控制

导致问题：80%二转华为测试问题单来自于系统稳定性，致命问题几乎都在系统运行2-3天左右后出现，且单位时间内数据量均较大。比如2G的话单文件，上千万BOSS回传数据等等。另外，在我们内部所使用的测试环境太过干净，已华为测试环境相差甚远。包括系统磁盘空间的问题，二转过程几乎没有重新装过任何系统，实际这些操作机器上不只我们一家公司的产品。从磁盘空间上来看平均C盘空间大概只有4-5G左右，由此，此类环境很容易出现系统资源不足的情况。

解决办法：

a)         增加对转测或发布版本稳定性测试时间的控制

b)         增加对稳定性测试环境中异常情况的验证与规划，模拟如：网络时断时续、内存不足、CPU峰值运行、磁盘IO能力较低、磁盘空间不足等。