需求分析与架构设计:
我们做的是某一移动公司内部使用的项目,需求分析与架构全部由项目经理完成,之后由项目经理给具体某个开发人员分配任务,具体对某个功能模块的实现。这个对项目经理的经验与技术要求很高,他既然担任了需求分析师,又担任架构师的角色。
程序员编码:
因为我们开发语言用的是JAVA 语言,IDE用MyEclipse中自带的CVS版本管理工具,开发人员完成代码后,提交到版本库中。
测试:
我入职后的第一个任务是搭建缺陷管理工具,禅道项目管理,通过推广对发现的问题进行跟踪。后来正明效果并不好,因为对于一个六七人的开发团队项目,开发人员更喜欢测试人员能当面反馈,这样更能提高效率。对一个小 bug 通过当面交流的方式就可以将问题修复。
对于当时的环境,并没有测试环境。开发人员在本机上将项目进行部署运行。测试人员通过局域网访问开发人员的机子进行测试。或在测试人员本机上进行部署测试。这也是一个致命的缺点。因为开发人员测试人员使用的电脑存在太多不稳定因素,这些都会造成问题的出现,有时候难以判定是系统问题还是环境问题。
上线:
经过测试人员测试通过后,开发人员部署上线。
A程序员流程
你会发现在流程图中,A程序员是先发上线之后,再进行测试。这是我们一个面向大众用户的网站,上面给与测试人员的定位是测试兼用户体验,测试将发现的bug和体验问题提交到缺陷管理系统,由经理对问题进行分析,指派开发人员解决。定期对系统进行更新。
流程分析:
这个流程唯一的优点,就是能快速的发现并修复问题。
缺点就非常多了,相信许多小软件公司也有类似的流程。
这个流程中,项目经理是核心,项目经理也确实是有多年开发与项目经验的牛人,他喜欢不定期分享上些前沿的技术。
对于测试来说,需求很不明确,测试文档与用例也是可有可无的产物,没有需求文档,或非常简陋,根据需求文档根本无法编写用例。我只能收集一些通用的测试用例,如登录、文件上传下载、列表翻页、日期选择、输入框验证、搜索等有一些“通用型”用例,以便在测试过程中做参考。功能测试的多了,拿到一个功能,测试思路也就出来了。
对计算机软件进行测试前,首先需遵循软件测试原则,即不完全原则的遵守。
不完全原则即为若测试不完全、测试过程中涉及免疫性原则的部分较多,可对软件测试起到一定帮助。
因软件测试因此类因素具有一定程度的免疫性,测试人员能够完成的测试内容与其免疫性成正比,若想使软件测试更为流畅、测试效果更为有效,首先需遵循此类原则,将此类原则贯穿整个开发流程,不断进行测试,而并非一次性全程测试。
扩展资料:
软件测试已有了行业标准(IEEE/ANSI ),1983年IEEE提出的软件工程术语中给软件测试下的定义是:“使用人工或自动的手段来运行或测定某个软件系统的过程,其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别”。
这个定义明确指出:软件测试的目的是为了检验软件系统是否满足需求。它再也不是一个一次性的,而且只是开发后期的活动,而是与整个开发流程融合成一体。软件测试已成为一个专业,需要运用专门的方法和手段,需要专门人才和专家来承担。
参考资料 百度百科-软件测试
本回答被网友采纳