项目介绍

该项目完全基于开源项目STF的源码搭建，STF项目地址：https://github.com/openstf/stf/

开发环境安装与搭建

按照官方文档即可 https://github.com/openstf/stf/blob/master/README.md；

主要需要的前置条件：

1、安装node.js（服务基于node.js开发）

2、安装rethinkdb（DB使用的是rethinkDB）

3、通过npm安装stf

注意点：

官方只提供了linux和mac的环境搭建方案，Windows并不支持。

如果要对项目进行二次开发，最好先去补一下node.js、Angular.js、webpack等相关知识再开始，会省事很多。

很多人在应用vss的简单功能，但是对于VSS的分支合并功能，却很少应用。今天正好做了下vss的分支合并功能的测试。在此共享给大家！

之前一个朋友问起我，说做了那么多年开发，谈谈有些项目为何失败。朋友说项目失败很大的原因是在合同问题，合同没有很好的列出项目范围。其实，合同的范围只是一般的范围，详细内容应该不属于合同的一部分。所以我觉得项目最大的问题还是需求没做好。需求没有做好，主要表现在以下几个方面：

一、需求采集与分析

  1、需求采集分析时，没有从完整的业务流程出发，容易关注主要业务需求，而造成次要业务需求块的遗漏。

   之前检查了我们公司一个重要项目的需求做得咋样，光看需求提问单，就发现大部分问题是关于功能需求的。而问起业务需求时，他们说都很清楚了，但问起业务上细节处理时，大家都恍然大悟：“哦，这里需要再问下客户...”。

  2、开发人员除了关注采集功能需求、外部接口需求、性能需求和一般的标准需求外，往往容易忽略系统领域的背景、操作环境需求、用户特殊需求（例如用户熟练使用的工具与方法）等。

二、需求定义与确认

   需求规格说明书是将人们思想中的概念和目标转换成正式的文档，在这个过程中，很容易产生错误，例如表达不完整，不正确的事实，不一致或模糊的需求等。因此，一定要正确详细的进行需求定义与验证，确保规格化的内容确实是用户所需求的东西。

三、需求变更

  需求变更管理有两个方面，一是与客户就怎样变更达成一致，一个是进行变更流程控制活动。在这两个方面都容易出错。

  1、与客户达成一致方面，需要让客户意识到变更对项目影响的后果，要技巧性+友好性的将变更加入到协商条款中。在评估需求变更达到一定的影响时，要试图协商控制变更，以保证在需求变更下，项目可以继续成功。

  2、变更流程控制活动，包括怎么进行变更请求，怎么进行变更批准等过程控制，还要考虑为处理变更估计留出时间等等方面的问题。这方面不遵循过程控制流程来走，很容易导致花大功夫补救的后果。

  我们公司已经对变更没有做很好的控制，就吃了很多亏。我们项目组是驻客户所在地办公，开发人员经常接到客户电话来提出一些功能性的小变更，考虑到是小变更，又受“客户是上帝、提高客户满意度”等思想的影响，也就痛快答应，甚至当场修改程序发布。客户是高兴了，短期来看，效率高，而且还与客户打好关系。可长期来看，上此以往，这种行为就变成“没有跟客户计算成本”的花费，这还是小事，更严重的问题是，这种没有经过整体评估、影响分析、风险识别与分析的行为，有可能改了东家，拆坏了西家，到最后要花费更大的财力去弥补，吃力不讨好，更甚的后果是因为这些漏洞，迟迟拖延项目验收时间，从而导致项目失败。

    之前一个朋友问起我，说做了那么多年开发，谈谈有些项目为何失败。朋友说项目失败很大的原因是在合同问题，合同没有很好的列出项目范围。其实，合同的范围只是一般的范围，详细内容应该不属于合同的一部分。所以我觉得项目最大的问题还是需求没做好。需求没有做好，主要表现在以下几个方面：

一、需求采集与分析

  1、需求采集分析时，没有从完整的业务流程出发，容易关注主要业务需求，而造成次要业务需求块的遗漏。

   之前检查了我们公司一个重要项目的需求做得咋样，光看需求提问单，就发现大部分问题是关于功能需求的。而问起业务需求时，他们说都很清楚了，但问起业务上细节处理时，大家都恍然大悟：“哦，这里需要再问下客户...”。

  2、开发人员除了关注采集功能需求、外部接口需求、性能需求和一般的标准需求外，往往容易忽略系统领域的背景、操作环境需求、用户特殊需求（例如用户熟练使用的工具与方法）等。

二、需求定义与确认

   需求规格说明书是将人们思想中的概念和目标转换成正式的文档，在这个过程中，很容易产生错误，例如表达不完整，不正确的事实，不一致或模糊的需求等。因此，一定要正确详细的进行需求定义与验证，确保规格化的内容确实是用户所需求的东西。

三、需求变更

  需求变更管理有两个方面，一是与客户就怎样变更达成一致，一个是进行变更流程控制活动。在这两个方面都容易出错。

  1、与客户达成一致方面，需要让客户意识到变更对项目影响的后果，要技巧性+友好性的将变更加入到协商条款中。在评估需求变更达到一定的影响时，要试图协商控制变更，以保证在需求变更下，项目可以继续成功。

  2、变更流程控制活动，包括怎么进行变更请求，怎么进行变更批准等过程控制，还要考虑为处理变更估计留出时间等等方面的问题。这方面不遵循过程控制流程来走，很容易导致花大功夫补救的后果。

  我们公司已经对变更没有做很好的控制，就吃了很多亏。我们项目组是驻客户所在地办公，开发人员经常接到客户电话来提出一些功能性的小变更，考虑到是小变更，又受“客户是上帝、提高客户满意度”等思想的影响，也就痛快答应，甚至当场修改程序发布。客户是高兴了，短期来看，效率高，而且还与客户打好关系。可长期来看，上此以往，这种行为就变成“没有跟客户计算成本”的花费，这还是小事，更严重的问题是，这种没有经过整体评估、影响分析、风险识别与分析的行为，有可能改了东家，拆坏了西家，到最后要花费更大的财力去弥补，吃力不讨好，更甚的后果是因为这些漏洞，迟迟拖延项目验收时间，从而导致项目失败。

 

   今天在整理ppqa检查项，是关于测试计划与设计、测试执行这部分的。好不容易整理完，也不知道是否完整与实用。在此分享给大家，请大家提出宝贵意见！

测试计划与设计的检查项：

测试计划	未见记录
	是否说明了测试范围
	是否说明了测试整体策略
	是否说明了类型和测试阶段
	是否说明了测试环境及工具
	是否进行了测试用例、测试包、测试不同阶段的内容设计
	是否说明了测试过程与管理说明
	是否说明了测试产物
	测试工作是否在mpp中安排并落实？
测试用例	操作步骤是否与描述相一致
	操作步骤是否仅包含与被测项相关的内容，即没有多余的或不相关的内容
	测试用例的期望结果是否是确定的、唯一的
	测试用例是否可重用（对被测项的当前版本和后续版本）
	测试用例是否可跟踪（与测试需求相对应）
	测试用例执行后是否应将测试环境恢复到执行前的状态
	测试用例是否有正确的名称和编号
	测试用例是否标注有执行优先级
	测试用例目的的描述是否包含该用例用于测试什么内容
	是否包含了所采用的测试方法的描述
	是否包含相关的配置信息：环境、数据、前置测试用例、用户授权等
	操作步骤和期望结果应完整、一致、清晰
	是否指明：系统返回的任何错误信息或屏幕快照需保存
	用词规范、准确、一致
	每个测试用例的操作步骤<=15
	自动化测试脚本是否带有注释
	自动化测试脚本的注释是否包含：目的、输入、期望结果等
	场景测试用例的执行顺序是否符合实际的业务流程
	场景测试用例是否覆盖最复杂的业务流程
	对于由系统自动生成的输出项是否注明生成规则
	对于查询和表格，是否设计了产生数据的用例
	测试用例是否包含对中间和后台数据的检查
	场景测试用例中是否包含每个业务流程环节的中止和回退相关的设计和组合
	如果存在不可测需求，是否列出并进行说明
	测试用例是否覆盖所有的测试需求

测试执行的检查项：

测试准备	每轮测试开始时测试环境是否准备好（包括软件硬件、测试基本数据等）
	每轮测试的测试产物是否准备好
	测试环境（数据和程序）是否与开发分离，除了测试组之外其他人不能更新测试环境的数据和程序
	是否每轮测试根据上一轮的情况和总体测试计划做分工调整
测试实施	是否对每一个测试包进行了测试，并保存结果
	是否对每个测试用例进行了测试，并完整地记录了测试执行情况与结果
缺陷管理	测试管理表中缺陷数是否与与缺陷记录与汇总表中一致
	对于每个BUG是否完整填写了缺陷信息
	是否对每一个安排的缺陷进行了缺陷分析
测试总结	是否每轮测试结束后填写测试小结
	对于每轮测试，是否完整填写了阶段及次数、测试物及测试要求、测试情况与结论等信息
需求跟踪	是否在跟踪矩阵中跟踪了测试的需求

  个人觉得，采用TD管理缺陷，确实为不错的方法。但是TD中缺陷的状态还是不够，若增加FIXING和RENEW两个状态，那就不错了。

NEW        ： 被首次发现的缺陷；

RENEW      ： 对于被拒绝的缺陷或者已修复的缺陷进行验 证后确定仍然为缺陷的缺陷；

OPEN       ： 对于NEW状态的缺陷，分析后发布并已安排等待修复的缺陷；

REOPEN     :  对于RENEW状态的缺陷，分析后发布并已安排等待修复的缺陷；

REJECTED   ： 经分析后拒绝的缺陷；

FIXING     ： 正在修复中的缺陷；

FIXED      ： 已修复等待验证的缺陷；

CLOSED     ： 已被关闭，该缺陷验证已修复的缺陷或者经识别后同意否决的缺陷。