软件测试流程优化及方法.pptxVIP

软件测试流程优化及方法 编写时间： 2015.02.02 编写人： EasonZhou 目前测试中存在的问题 一个故事描述测试演变 软件测试及测试方法 软件测试及测试用例 目录 Bug生命周期 软件测试实施规范 目前测试存在的问题 测试几乎没有介入到软件研发中，且测试角色不明确； 如，测试只有在集成测试时才介入；测试不了解发布版本去向；测试同时担任QC，QA职位；等 测试比较简单，测试不完全； 如，测试几乎只进行集成测试，并无其他测试；测试停留在功能测试，该做性能测试的地方做的不够；等 没有设计需求，没有测试用例，测试属于想到哪里测试哪里； 如，测试需要经常与工程开发沟通功能是否可用，功能用途，及如何使用；测试无计划，不知道什么时候开始及结束，没有节点；没有测试 用例；等 缺陷管理系统没有有效利用； 报告的提交及一些统计可以参考缺陷管理系统，对软件进行分析总结，对Bug高发生的位置进行重点测试；Bug统计困难； 版本发布频繁，没有测试计划--测试属于眉毛胡子一把抓情况； 发布安装包数量为：145，假如每次发布3天时间测试，共需要435天；等 测试能力提高缓慢； 一个故事描述测试演变 国外很多的大公司，QA的职责就是测试（主要是系统测试），比如IBM、CA- 全球最大的IT管理软件公司之一、PeopleSoft-协同合作企业软体全球领导供应商,等。其实在最初，几乎所有的公司都是这样的。后来，由于缺乏有效的项目计划和项目管理，留给系统测试的时间很少（注：我以前做的一个项目，项目经理就明确告诉我系统测试就1天，没得商量）。另外，需求变化太快，没有完整的需求文档，测试人员就只能根据自己的想象来测试。这样一来，测试就很难保障产品的质量，事先预防的QA职能就应运而生。 一个故事描述测试演变 QC兼任QA的问题： 一个Bug出现分歧，不知道是否需要修改，没有参考标准。 最终产品是否合格，没有参考标准。 … 国外很多的大公司，QA的职责就是测试（主要是系统测试） 软件测试及测试方法 软件测试是使用人工操作或者软件自动运行的方式来检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别的过程。 它是帮助识别开发完成（中间或最终的版本）的计算机软件（整体或部分）的正确度(correctness) 、完全度(completeness)和质量(quality)的软件过程；是SQA(software quality assurance)的重要子域。 无论哪种测试都需要依靠测试用例开展，下面是测试用例举例 软件测试及测试用例 以DataEngine登陆界面为例： 测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。 测试用例（Test Case）元素： 单个功能测试用例为30个，DataEngine共106个功能(不完全统计)，那么30*106至少3018条测试用例。 每个功能执行测试用例为90次(3种语言)，一个模块执行至少需要执行3018*3=9054条测试用例 软件测试及测试用例 测试用例（Test Case）当前存在问题： 编写测试用例的时间：编写测试用例的时间比较紧张； 测试用例的维护：即需求或者功能变动时，测试用例需要完成维护，维护成本问题； 测试用例的数量：按照每个人3个模块，每个人需要编写1w个测试用例，每个人需要执行的测试用例为3w(三种语言，如果加上不同系统，需要执行的测试用例数更多)，执行时间问题； 测试用例的利用率：测试用例的重复利用及效果还是未知数； 公共用例库的建设：目前没有公共用例库，增大每个测试组的无用功； 红色箭头标识为最简短的Bug生命周期 流程图其他箭头反应是实际测试中Bug的其他走向 Bug生命周期中部分地方可以提高 Bug来源 Bug分配 解决原因 产品项目分类 Bug生命周期 1. Bug来源-便于Bug统计，对于提高软件质量无影响 研发人员创建的Bug； 研发人员以外人创建的Bug(包含技术支持、用户等)； 新需求 2. Bug分配-便于Bug统计，对于提高软件质量无影响 例如提交了一个 ReModel模块发现的Bug；是2D或者底层问题，Bug会转到2D或者底层，统计Bug时无法统计 3. 解决原因-便于Bug统计，对于提高软件质量有影响 保留原样：包含 有争议的Bug，即修改还是不修改。开发认为无法修复的Bug。 无效Bug：Bug本身不是Bug。设计需求是这么设计的。 结论：在解决原因中增加 无效(invalid) Bug生命周期 4. 产品与项目分类-便于Bug统计，对于提高软件质量有影响 软件测试实施规范 过程要点 详细说明 输入条件 项目进入软件实现阶段（编码） 工作