在一个软件项目的生产过程中，最关键的阶段就是需求的确定。

概要设计的依据是需求文档，详细设计的依据也将是需求文档，

测试大纲的结构级次也是依据需求文档框架结构而提炼产生的，

测试案例编写依据测试大纲的结构和功能点列表而设计出来的，

因此需求文档成了整个项目从始至终的重要的依据性文档标准，

因此其重要性自然不言而喻。下面说说需求文档的在项目中的重要性！

1、高质量的需求文档切断bug的来源

在需求文档编写过程中如果质量控制不到位，自然会产生最原始的bug

设计人员依据不明确的需求文档设计出了不准确的概要设计和物理模型

开发人员依据已经存在bug的概要设计产生程序代码，系统提交测试的

时候这些隐含的bug已经从需求一直流转到了测试人员的面前成为测试

人员的劳动成果但是这虽然给测试人员带来了工作成果和成就感但是这

对一个项目来讲却是巨大的损失，本应该在需求文档产生是就能避免的

东西尽量控制在其最原始的状态而不是放任自流下去，因此由此看来文

档测试的重要性就体现出来了，很多企业并不重视对文档的测试和检查

从而使这些问题逐渐逐步的被放大，同时放大了修复问题的代价，给项

目带来损失，因此，测试要在需求文档编写产生时介入，同步测试需求

文档中存在的遗漏和不准确的描述直接将一些输入控制，界面标准等问

题扼杀在摇篮之中，付出了最小的代价产生了最好的效果，避免了需求

变更，就避免了损失的放大，为项目和公司节约了成本，同时也能提高

产品的质量，一举多得！

2、需求文档编写的要求

为了节约成本必须加强控制，控制好需求文档编规范的高标准、高要求

编写的质量和规范性以及可读性，这对需求人员的要求就相对提高了，不

仅仅是懂业务和会用word这么简单了，要能将需求文档编写成为设计人

员和开发人员的思维角度读懂的文档，不仅仅是简单的规则描述是问题了

当需求文档编写符合规范，概要设计上就更加清晰流畅，代码编写上就能

控制的更加规范和标准，提高了代码生产效率，降低了低级bug的存活率

从而提高了系统的质量。一旦需求文档编写的不好导致了连锁反应最终到

需求变更，需求变更是一个项目最难承受的代价，当整个系统在多人合作

的情况下生产出来，此时需求文档的一点小小变化都可能会导致整个系统

发生巨大的改变和调整，由此需要付出的代价是不可估量的，损失是惨重

的，也是开发、测试、维护所最不愿意接受和面对的，控制好需求的编写

可以达到事半功倍的效果，高水平的测试团队可以从标准的需求文档中预

估出系统的缺陷率，预估出要编写的测试案例数，从而为后期的测试工作

带来了巨大的前置信息，提高了测试工作的工作效率，高质量的需求文档

编写有百利而无一害，需要得到重视！

总结：需求文档编写的高质量和测试人员介入文档测试对于一个项目来说

都是非常重要的环节，需要加强控制和规范，为公司带来效益，货真价实！

-------------------------------------------------------------

NBA总决赛结束了，我所钟爱的LAKERS夺冠了，我的偶像KOBE获得了MVP奖杯~~

23--24

幸福

 

 

好久没有来更新我的空间了，面对51感到十分的愧疚，

甚至没有太多的时间浏览，希望今后能有多点的时间来学习吧！

近期一直在做一个项目的测试工作，时间紧任务重是这个项目的特点，

经过一段时间的测试计划和组织，总结了一些经验，记录之：

1、在测试计划的制定过程中一定要充分考虑到测试环境的因素：

测试计划的编写是根据项目经验和实际的项目操作过程，

通过对项目的大小，功能点的多少，菜单的数目和页面的复杂情况，

最终估计出总体的工作量，在具体分配和计划的时候，

不能完全只考虑到工作量的100%分配和完成，

因为按开发计划出来的东西，在工期十分紧张的情况下是有偏差的

如果按照客户的最后期限为标准开展开发和测试工作的计划

那么在这个过程中就一定要考虑到测试环境的稳定性和提交代码的可测性

实际工作过程中，按开发计划出来的代码从一定程度上来讲

是存在很多bug，甚至无法在测试环境下运行，

更甚至就在代码build过程中就出现问题

因此在制定测试计划和开展工作过程中一定要充分考虑到测试环境的影响程度！

2、测试工程师的个人情况和工作稳定程度

在编制测试计划的过程中，不能不考虑测试工程师的个人情况

从业务能力，操作能力，沟通能力，工作责任心，等各个方面

对项目组测试成员进行一下整体的评估和分类

同时要针对个人的不同情况考虑到工作过程中出现的出勤问题

比如员工中存在婚假对象，产假对象等等，在编制计划时要增加预估百分比

以弥补测试周期中出现的人员异动，从而控制好风险的程度。

3、测试计划的制定要有开发计划的按期完成作为前提：

测试计划制定的再好，如果没有开发计划的按期完成做为保证

一切都将变为空谈，没有任何的实际意义，估计出来的工作量没有任何价值

就像不同环境下测试来的性能指标一样，几乎完全没有参考价值

开发计划的保障成为测试工作开展的前提，否则将导致测试工作的延期

最终导致风险的扩大化，对整个项目产生不可预计的影响。

4、测试过程中要预留出修改bug的时间：

在测试过程中，由于项目的性质和客户的要求不同

最终提供测试的程序可能由于工期的保障最终出现大量bug

严重的情况就是bug直接导致系统无法继续测试下去

为了继续测试只能等待bug的修复，而此时开发人员甚至没有时间关注bug

大部分时间都在赶时间编写代码

一旦出现此类情况，必须及时提出对策解决

避免开发忙的不可开交，测试闲的无所事事

5、测试案例的编写到位和后期维护工作的重要性

测试初期，从测试计划开始，到测试任务具体执行

主要时间不是在测试系统，而是在花费大量时间编写高质量的用例

如果初期没有对测试用例的编写规则进行详细的规划和约束

最终不同测试人员编写出来的案例千奇百怪，千差万别

在测试执行过程中影响了测试质量的控制

初期一定要对案例质量进行控制，花费大量的人力物力去评审和返工

否则前面准备不好，后期必然出现测试工作忙，案例编写质量差

执行人员执行起来发现不了问题，但是又没有更多的资源去补充和修改

好的猎手一定要有好的打猎工具，正如我的同学在打算考研之后

第一件事就是准备好一切考研期间需要的东西，包括很高级的钢笔和墨水！

暂时先总结到这吧，有时间继续~~

这几天NBA的总决赛打的如火如荼，还是和大家分享一下我喜爱的湖人队吧~~

 

在日常的测试案例评审过程中应该注意的事项简单总结

软件质量检查措施：

（1）事先把检查的主要内容制成一张表，使检查活动集中在主要问题上。

（2）只评审工作，不评审开发者。评审的气氛应该是融洽的。存在的错误应该被有礼貌地指出来，任何人的意见都不应被阻挠或小看。

（3）建立一个议事日程并遵循它。检查过程不能放任自由，必须排照既定的方向和日程进行。

（4）不要化太多的时间争论和辩驳。

（5）说清楚问题所在，但不要企图当场解决所有问题。

（6）对检查人员进行适当的培训。

 

软件测试的主要工作过程是通过项目小组来分工的，在带领一个工作小组开展

工作的过程中对组员的管理是有一定的技巧和哲学的，因为对于项目经理或者

产品经理来讲，测试经理是管理整个测试过程的控制者和协调者，对于测试工

程师来讲，测试经理是任务的分配者和资源的提供和协调者，在这个过程中就

有很多的矛盾存在，任务重，时间紧，压力大，加班多，测试工作的进度控制

困难，资源的协调，测试环境的保障等等因素都会给测试工作带来不小的困难

和阻力，在这个过程中就要求我们测试经理做好这个协调者的工作，在我个人

的工作过程中总结了一部分经验和大家分享：

 

确保测试环境等资源的保障，协调好各个部门的配合，技术支持，数

据库，环境维护等等各个相关部门的全力合作，保证测试工程师的工

作环境稳定运行。

 

任务计划明确，分工明确，确保各个测试工程师的工作量，使各个工

程师的工作保持在一个同等的水平上，不产生分歧和不满

 

定时组织开会总结各个测试工程师的工作所得，分享大家在不同的工

作过程中的体会和经验，有助于拓宽思路，对今后的测试工作有很大

的帮助

 

定期带领测试工程师出去组织一些问题活动，使测试工程师在枯燥频

繁的工作之余得到身心的放松，这样有助于增加上下级感情，提高测

试工作效率

 

为下属谋取更多的福利，作为一个中层领导者，必须维护下属的利益

让下属意识到在你的带领下干活是有安全感的，至少是能得到一些福

利的，避免怨声载道，抱怨声此起彼伏，不仅不利于组织工作的开展

也影响了测试工作的效率和质量，测试工作经常出现赶进度加班的轻

卡情况，在这种情况下要尽量能争取到一些福利，比如加班食品，带

领团队共同进餐，下班后打车等等一系列的福利措施都是有助于测试

工作的开展。

 

以上是我的个人的一些工作经验总结，希望对大家有所帮助，总结的

不全面，仅供参考。