2012年进入SP给领导的邮件,现在看，貌似哪时候很厉害的样子

 

你好，顾总，

      我对9个文档都看了一篇，我从下几个方面给出自己的一些反馈：

一、测试类型分工：

u  目前

在文档中，看到有单元测试用例、接口测试、平台测试、性能等等，整体显的测试文档分类比较细但又略显凌乱，而且有些测试超出系统测试人员的职责范畴。

u  想法

测试的分类纬度很多，仅针对上面的给出自己的想法，不管是项目或者是产品，我们可以从两个大方面去分代码测试（白盒子）和系统测试（黑盒子）：代码测试主导由开发人员负责，主要关注代码逻辑实现，又分为单元测试，BVT，集成测试等，开发人员应该注重测试自己的代码，并由项目经理督促，最后提交单元测试报告，作为单元测试是否通过依据。系统测试由专职测试人员去负责，主要关注系统功能是否已经按显式需求或隐式需求实现，又分为功能测试、性能测试、文档测试、UI测试、易用性测试、接口测试等，测试完成后应该提交测试报告，作为软件发布的内部重要参考依据。

二、规范测试文档：

u  目前

在文档中，有的用EXCEL,有的用Word，在文档版面中有的有页眉页角，有的没有，在文字描述中在字体大小，段落格式不太统一。

u  想法

测试需要输出的文档包括测试计划、测试方案、测试用例、测试报告、测试总结等，不管是EXCEL或是Word，形式不重要，重要的是文档能保持一致，这样有利于规范测试人员的做事方式，提高效率，积累经验。另外，也提倡在在软件的立项、需求阶段，项目设计文档直到项目发布都形成统一规范的文档，便于查找和管理。

三、缺陷描述细化：

u  目前

缺陷（bug）的描述很少或没有描述。

u  想法

测试人员的重要工作成果就是“bug”，对提交的bug应该做恰当的描述，一方面有利于开

发人员看到bug描述后就可以快速定位到问题，从而提高解决问题的效率，减少沟通成本，另一方面，描述bug也是对测试人员自我提出要求，我们不但要发现bug，而且能定位出bug，再高一个级别是可以协助开发解决bug，这是对自我技术能力逐步提升和完善的过程，我们测试人员应该努力做好的工作。

四、测试报告提交：

u  目前

测试报告描述比较简单或不太规范，缺少必要的参看信息。

u  想法

测试报告作为软件可发布的重要参考，不光给项目经理、团队人员看，可能还会给更高一级的领导提供参看信息，所有测试报告有必要在写的规范、细致，必要的信息不能少，比如测试的终结版本、测试资源、测试轮数、bug遗留等，所有测试报告应该讲究实事求是、严谨细致。

五、测试总结积累：

u  目前

在测试方法、测试流程方面积累，有利于软件质量的提高。

u  想法

测试不光是基本的测试理论，基础操作知识，还包括业务知识的积累，应该通过测试用例和测试总结作为载体、逐步积累这方面的知识并在团队内分享。

六、测试体系建立：

u  目前

测试的号角已经吹响。

u  想法

我个人一直觉得，测试并不是可有可无的事情，软件代码是由人来完成的，是人都会犯错误，只是多少、轻重的区别，所以测试很有实质意义，而测试体系的建立，在开发人员角度上看可以规范人员的开发方式，提高编写代码人员的警惕性，比如bug ，通过跟踪bug给开发人员的潜意识中激发自我控制力，在编写规范、单元测试、bug解决等等方面提供标杆，从测试人员角度看，可以将自己当成是用户，不光要检验软件功能实现，而且从更高层次上，比如易用性方面提出自己的建议。（完）