一个项目的项目总结.pdfVIP

因为需求写的十分详细，所以方案也十分详细。在这期间还专门写了一个针对脚本名称、

事物名称、场景名称、结果名称的命名规范。事实证明这个命名规范对后来的测试数据整

理起到了巨大的作用。在书写方案的过程中体现了模板的重要性，我建立了一个模板，然

后大家都按照我的模板来写，这个阶段虽然漫长但也倒还算是轻松。只是对几个专有名词

的概念做了一下统一，其中比较明显的就是“并发”这个词。为了给用户系统负载比较大的

感觉，我们将并发的单位变成了每分钟多少用户，这样做实际是不正确的，给后期测试带

来的了很大麻烦，经常要考虑实际并发用户到底是多少，应该如何换算。其实“并发”这个

词并不是一个时间段的概念，而是瞬间的概念，衡量一个时间点上用户数的多少。另外，

在整合的时候还出现了一些小问题，在文档写作的细节习惯上并不能完全的统一，造成我

在把所有别人的方案拿过来的时候还要花很多时间调整格式和内容以达到文档的统一和美

观。进行两次方案的评审，评审进行的还算顺利。

2)经验

命名文档十分重要，对后边的数据整理起到了巨大的作用。在比较大的工程里，最好几个

人要经过研究共同制订一个命名规则，这样大家都遵循这个规则去命名，可以在同伴不在

的时候很容易明白他的某一个脚本或者结果的用途。

测试方案可以写的尽量详细，当然要在用户或者领导不检查是否完全按照方案执行的情况

下。本次测试中方案写的十分详细，脚本详细到每一个操作，需要监控的事务都标注的很

清楚，场景详细到多少用户、执行时间、并发用户数和集合点，有些还加上备注说明，写

清楚为什么添加这个场景，在何种情况下会出现此场景的情况。这使我们在后边做执行的

时候很容易了解到当时写这方案时的思想，有些东西可以直接拿来用而不用再思考一遍。

在书写方案的时候，如果几个人一起书写的话，一定要事先尽量统一书写的格式和方式，

不然在整合的时候会十分的麻烦，要调整很多的格式。另外整合的人要十分认真，按照我

的经验至少要来回看文档三遍。第一遍看整合的格式是否一致，是否有漏掉的不一致的地

方，包括各个标题的格式、内容的格式、字体、字号等。第二遍看错别字，在自己的能力

范围之内尽量找出文档中的错别字，这种低级错误有时候会影响看文档人对写文档人的印

象。第三遍看标点符号，要统一文中各个位置的标点，尤其是表格等，填写的时候是否有

标点。三遍都看完之后，还要叫来大家一起来重新看文档，提意见，然后进行修改，互相

之间看文档的时候还会发现一些问题或者突然提出不同的建议，可以使文档更完美。这样

的过程再进行两遍，我认为这样的文档才具备可以提交给相关部门的条件。大家不要怕麻

烦，文档是一个测试人员入手的项目的第一件工作，是脸面，一定要做好。

如果有能力的话，最好在书写测试方案时同步进行脚本可行性分析和数据需求的整理。脚

本可行性分析可以不用录制脚本，不过尽量操作几次录制脚本的流程，观察是否还存在功

能问题影响脚本录制，看是否存在技术瓶颈或测试困难，提早进行技术的补充或者想想绕

过困难的方法，是否有可替代的方案。这里面尤其注意到很多宏观的问题，比如当前所拥

有的测试资源，测试机的数量，是否可以运行如此多的用户，是否有带宽瓶颈，如果有如

何处理等等。还有对可以预见的数据尽早提给开发让开发准备，对后期的工作会有很大的

帮助，不用到录制脚本时再提数据准备，开发再准备几天，这样会影响测试进度，给开发

短时间制作数据的压力，也会影响和开发的关系。

在做方案的同时，同步制定可行的测试计划，如果时间充裕最好准备两份，一份是充分测

试所需要的时间，一份是在项目紧急的情况下所需要的时间。这里可以不要写出具体执行

的时间段，因为这是测试人员自己不可控的，只要写出所哪一项工作具体需要的时间就可

以。这样做的目的是便于后边工作量的计算。计算出工作量，就可以更好的控制项目的进

度不至于因为某一个困难耽误了整个项目的进度。

在测试执行开始之前，测试方案最好根据需求的更新进行同步更新，在执行开始之后，如

果没有时间可以暂时放下。因为本人有记日记的习惯，所以一般一项目下来哪里是如何做

的都有记录，如果最后要一个真实的方案也能拿出来。用户一般在评审后就不会要求文档

同步更新，而且一直维护一个或者多个文档会耗费大量的工作量，不建议在测试执行时还

进行文档的维护。方案是对测试起到指导的作用，如果执行时还要对方案进行更改就有点

形式主义的意思了，不是吗？不过在有重大变故的时候，比如某一个大的模块都进行了更

改或者删减增加，最好做好记录或者简单的更改方案，方便以后查阅。

4.测试执行

测试执行分四个阶段大概用了两个半月的时间，四个阶段为三个阶段对三种优先级的测试

点