HYHOLINE的专栏

一.功能测试　　1. 安装测试：　　1) 安装过程中对于缺省安装目录及任意指定的安装目录，是否都能正确安装；　　2) 若是选择安装，查看能否实现其相应的功能；　　3) 在所有能中途退出安装的位置退出安装程序后，验证此程序并未安装成功（没有程序组及程序项产生）；　　4) 软件安装后，对其它已经安装的软件是否有影响；　　5) 裸机安装后，各功能点是否可用

一.针对nobug的缺陷1.产品经理针对产品建议类的缺陷若本版本暂时不修改，可以将bug进行nobug处理，但需要让其将缺陷提交到jira作为产品建议记录，并且在缺陷备注说明jira id。同时测试人员将缺陷的summary前加上【jira建议】以便测试分析时筛选。2.针对系统集成类的缺陷，所谓系统集成类的缺陷是本项目无法修改，需要其他项目才能修改的缺陷。这类缺陷产品经理可以将缺陷nobu

今天部门内部讨论了在提交缺陷时在何种情况下应该注明是【需求不一致】。   提到这个问题，个人认为应该先明确注明【需求不一致】的目的和作用。个人比较认同采用在缺陷中注明【需求不一致】来达到检验在前期评审需求和评审用例的质量。   那么，需求文档评审质量差对测试方而言会引发什么大问题？   1、执行完用例后，手工测试发现一大堆缺陷。用例无法较完整覆盖主体功能点。   2、产品经理和项目

一位企业家在分享自己的成功之道时说：自己的成功在于先于他人一步。中国的软件业起步晚，相对美国晚了30年左右，而软件测试这个行业，则相对美国晚了15至20年左右的时间。坦白的讲，我们是输在起跑线了。至今，中国的软件产品还是难以走出国门，只能给老外做做外包，当外包不景气时，IT业立马出现动荡，一群IT民工在网络论坛哭爹骂娘。稍加思考，一个产品的失败，除了市场因素外，往往是质量不行，软件测试作为软件产品

前言:随着软件测试的发展,自动化测试的职能也划分得越来越细，分工越来越明晰，对于在自动化测试过程中的分工不同，做出如下角色定位：1.1. 自动化测试框架架构师1) 根据测试业务，评估自动化测试的可行性，并进行工具的选择2) 进行自动化测试框架的设计和搭建。3) 组织自动化测试用例的编写和测试脚本的开发及结果处理分析。4) 组织自动化框架和自动化用例脚本验收评审工作。

这部分主要介绍如何基于当前框架创建一个全新的自动化项目，我们约定项目路径在F盘下，项目名称为AutoProject。1.1. 目录创建在路径：“F:\自动化测试管理\框架使用说明\项目初始化模板”下双击“双击生成新项目.vbs”文件，输入【AutoProject自动化测试】点确定。 执行初始化后，可以在路径：“F:\自动化测试管理\自动化测试项目”查看到新增的项目。1.2. 报

近来了看了一些文章，主题是讨论测试流程模式，因为随着敏捷开发的思想迅速被推广，许多公司在研发上都引入的敏捷的特性，自然，引入新的模式，并不意味着就丢了原来的模式，实际生产上，往往是采用传统的开发模式和敏捷思想并行，这种新旧混搭模式会暴露出许多问题，例如：1、开发的周期变短，原来计划是三个月的开发周期，根据敏捷的方法来执行会被缩短为两个月。自然、测试的周期也会被压缩，甚至出现开发无法准时进入