你好,顾总,
我对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解决等等方面提供标杆,从测试人员角度看,可以将自己当成是用户,不光要检验软件功能实现,而且从更高层次上,比如易用性方面提出自己的建议。(完)