软件测试项目管理.docx

软件测试项目管理课程论文内容摘要本论文讨论了Z公司系统升级中出现过的部分测试相关问题，以及应对的改进方案措施。并结合部分软件测试项目管理知识进行分析研究。关键词：开发人员测试，沟通，制度约束目录第一章绪 论31.1本论文的背景及意义31.11 Z公司管理情况31.12 Z公司软件系统现状3第二章问题与解决32.1主要问题32.11 人员方面问题32.12 沟通方面问题32.13 工作方式方面问题32.2尝试解决32.21 从沟通开始32.22 制度先行32.23 技术提升32.24 绩效考核3第三章结论3第一章 绪 论1.1本论文的背景及意义 本论文讨论了Z公司系统升级中出现过的部分测试相关问题，以及应对措施。并结合软件测试项目管理知识进行分析研究。1.11 Z公司管理情况Z公司为小型国有企业，日常运营以业务为导向，系统部门人数较少。系统部门员工每人都兼职系统开发、软件维护、网络管理、硬件维护等工作，由于不太受公司重视且人数较少，员工间交流与合作能力较弱。系统部门的直接领导由业务部门领导兼任，对计算机技术基本不了解，缺少有效的指导与管控能力。1.12 Z公司软件系统现状Z公司系统现已运行使用了10年，由BS和CS两部分组成，BS部分使用.NET平台C#语言编写，CS部分使用POWERBUILDER VB语言编写。数据库使用微弱的Sql Server，服务器系统为 Windows Server。第二章 问题与解决2.1主要问题2.11 人员方面问题 Z公司作为小型国有企业，员工一般工作比较稳定，人员流动性较弱，软件部门也同样，员工皆在此公司工作了五年以上。这一方面导致员工对现有系统熟悉度很高，解决问题能力较强，另一方面导致员工工作方式逐渐变得固定、死板，缺少变化，上进心减弱，积极性低，不适应变化，对新事物会有抗拒的想法。2.12 沟通方面问题由于公司领导和直属领导皆不通电脑技术，软件部门上下沟通不是很顺畅，领导对员工反映的问题或方案难有直接的理解，领导派发的任务到下面个人，也经常引起不同的理解。于此同时，由于人际关系、惰性等因素，具体的工作人员之间的沟通度也在下降，对不同技术方案的倾向与理解有时会引起争吵。内部沟通都使用口头沟通或电话沟通，包括一般性的复杂度低的任务布置也是如此，少有会议沟通火书面沟通，也容易造成理解不到位或者记忆不清。2.13 工作方式方面问题目前对Z公司系统的测试主要集中在对现有系统的升级补丁的测试上，测试方式以黑盒测试为主，每次更新补丁边写完后由群体一同进行测试，具体每个人用什么方式或者测哪部分并无分工。对于以开发为主要工作内容的员工来说，对测试不认真是很常见的，而测出bug后内部的相互通报也不够及时。2.2尝试解决2.21 从沟通开始初步分析，沟通的问题在于上级缺少知识；下属存在态度上的问题，以及选择性认知，并且很多人做不到从全局出法看问题。沟通第一步也是最重要的一步从公司领导开始,由于公司领导普遍不通技术但是精通风险管理，于是从风险角度入手与领导沟通，并与其他部门接触，收集对系统bug的反馈意见，期望引起领导重视。经过一番交流，终于得到领导重视，得以自上而下开始测试流程的改革。第二部，由主管领导任命一人作为测试组长，负责传达、布置、报告所有测试相关事宜，并负责对测试方法与制度的设计，此人权限等同于开发组长。尽管此人仍然兼任部分开发工作，但是逐步把工作中心向测试与管理方面过渡。这一职位的存在，极大提高了公司领导对测试工作的理解，减少沟通障碍。第三步，组长采取分发测试工程教材，聘请专家进行培训等方式，试图将测试工程的概念与其希望的测试流程逐步灌输给员工，取得了较小的效果。其后，组长改变思路，从工作流程与制度着手，通过说服领导，强制性的改变了现有工作方式，每次任务布置都采取会议的方式，并留有纸面的记录。一方面是为了明确分工与责任，引起员工重视；另一方面是为了有实际东西给领导看，让领导了解工作内容及工作量的变化，取得进一步支持。同时，提议将部分员工转入纯测试岗位或从外部招聘新的专职测试人员，不过此提议未能获得公司通过，实际结果还是由开发人员兼职进行测试。由于新方法的引入，自然增加了工作量，在加班后采取聚餐烤串等方式增进员工感情，求同存异，增进团结。2.22 制度先行在引起领导重视后，逐步从制度上规范测试分工流程，通过制度引起程序员的重视，达到提升测试质量的目的。每次布置任务尽量采取会议的形式，留下纸质文件，实际意义也是为了引起重视，明确分工。2.23 技术提升按不同分工，要求部分测试人员逐步学习自动化测试工具，引入自动化测试，并将自动化测试加入考核内容。实际上多数开发人员，对自动化测试工具的学习还是很快的，能够较快的完成脚本等的编写。要求测试人员在学习过程中，逐步把过去老模块也实现自动化测试，一方面是练习，另一方面也很有实际作用。此外，要求测试人员在在版本开发前期就开始研究测试方法（比如：单元测试、接口测试、自动化测试等），并且与开发配合提供一些支持。通过这种方式能够覆盖到比以往更多的测试点。然后再通过对该模块以及对整个系统的把握，准确的分析出那些可能还是有风险的，并且进行探索性测试和整体场景的测试。这部分要求还在逐步磨合中，员工之间的配合上还需要进一步适应。2.24 绩效考核Z公司原本完全没有把测试纳入绩效与考核，此次改革后，才将这部分工作量记入绩效。责任上采用了最简单的模式：同为一个程序中的严重错误，假如是上线后由用户发现，则是测试人员的责任（因为经过了测试人员的测试，测试人员有责任保证程序中不存在严重的错误），假如是测试过程中测试人员发现，则是开发人员的责任。这样的话，责任划分得一清二楚，对号入座，避免了责任推来推去的情况。当然这二者责任并不相同，上线后发现的bug对测试人员扣的绩效要比测试期间发现的bug对开发人员扣的绩效更多得多。总的来说，引入绩效与考核，对测试工作起到了一定的强制与激励作用，正面影响十分明显。第三章 结论 经过一年的测