小团队测试该如何进行?

小团队测试该如何进行?

1、测试流程的建立

目前的流程为：

1)参与需求讨论;

2)有一个简单的时间计划;

4)执行测试的时候先测测试点，然后测需求延伸的内容;

5)遇到问题，分析后整理写在石墨文档中，并且与相关开发一个问题一个问题分析一遍，保证问题的清晰;基本在1个工作日问题就可以修改并且回归测试;

6)对于问题没有做统计分析。

短期计划：

增加一个测试人员，分工测试。对于大需求合作完成，对于小需求单独一个人完成。其他如下几点：

1)测试计划更为详细，不只是简单的x日-y日测试什么内容，而是测试点的提取、测试执行、问题单解决及回归时间有明确的估算。

2)测试用例的编辑、管理有个初步的形状。即测试用例有个初步的模板，不仅测试人员能看懂，非研发人员都能看懂。主要为概述、优先级、步骤(每一步尽量以傻瓜式的方式写，一个用例不超过7步)。保存在石墨或其他文档上，保证共享文件每个人看到的都是一致的。

3)问题单规则化，有个基本模板使用，每个问题该怎么提，内容有什么都有个雏形，并在jira上管理。

4)有个简单的测试报告输出。简单的统计，主要有测试范围和内容，软件质量的评估，用例覆盖的需求百分比，通过用例发现的问题占总问题的百分比，非用例发现问题的百分比，非用例非测试人员发现的问题占比。什么模块发现严重问题多少个、一般问题多少个，根据这次测试下次注意的事项等。

长期计划：将流程合理化，简洁化。

1)参与需求谈论，对需求有合理的分析;

2)计划更周全详细，考虑到测试中异常情况(比如开发交付测试延期等情况);

3)对测试用例进行优化，提升测试用例质量;

4)在测试执行前有严格的测试用例依据，执行前对每天的工作量有估算根据(实际情况而定)，对与发现的问题单有要求(非用例发现的问题要占总问题的百分比，或每20条用例中要发现一个非用例问题);

5)问题单的管理和提交更为详细，规范;

6)回归测试做到问题单全覆盖以及问题延伸部分的覆盖;

7)对问题单有更详细的统计，并输出测试报告(该报告更偏重软件质量的说明)。并以邮件的形式通知相关人员。另附测试报告文档(参照笔者的另一个笔记)。

2、问题的管理

目前状况：操作中发现问题，记录问题，分析问题。不清楚的问题找产品再次了解。管理是在石墨文档中，问题按操作步骤编辑，然后找相关开发分析问题，最后回归问题及问题相关内容。

计划：对于开发、设计等一些列活动工程中出现的问题进行记录、分析、跟踪、提交、验证最后整理分析。给出问题单统计报告并以邮件的形式发送给相关人员。文末附问题单模板。

3、构建接口测试、自动化测试、性能测试、安全测试

长期计划：鉴于公司的快速成才，纯手工测试可能满足不了日后的测试工作，则需构建接口测试、自动化测试、性能测试、安全测试等

构建接口测试的必要性：可以检测外部系统与系统、系统内部模块与模块之间的交互，检查数据的传递、和控制，知道业务逻辑是否满足需求，返回字段是否达到预期。

构建自动化测试的必要性：目前项目比较多，迭代也比较频繁。时间紧。每次迭代测试只对每次迭代的需求进行测试，对整个软件没有进行测试，人工测试费时费力。进行自动化测试可以对整个系统的业务在很短的时间内进行一遍测试。保证软件质量。

构建性能、安全测试：从长远的角度考虑需要，软件使用的用户量越来越大，对于服务器的性能指标、安全指数也会有进一步的要求。所以性能、安全测试是非常必要的。

4、测试用例的完善

目前：没有测试用例。之前写过美店管理后台、美店H5、美店app的测试用例，在jira上

计划：完善现有产品的测试用例，对没有测试用例的进行增加，有已有测试用例的进行增删改查。

在以后的项目中，测试执行前编辑好测试用例，并且交给产品、开发审核，发现没有写到的或者标记容易漏测的用例。执行测试的时候按照测试用例执行，并且发散测试。迭代结束后对测试用例进行管理，增加问题单用例，并做好备注(此用例由问题单增加)提醒下次迭代中着重关注。

5、人员构成

目前需要一个功能测试(招聘ing)

长期计划：根据业务需求招功能测试。可适当的增加一个安全测试、一个性能测试

测试用例模板：

1.标题：

就是对测试用例的描述，标题应该清楚的表达测试用例的用途。

2.步骤：

提供测试执行的过程步骤。对于复杂的测试用例，应该分为多个步骤完成。??

最好不好超过七步。

3.预期结果：

提供测试执行的预期结果。预期结果应该根据需求规格说明书得到。

如果实际结果和预期结果一致，则测试通过。

如果实际结果和预期结果不一致，则测试不通过。

4.实际结果

5.用例编号

产品编号-ST-系统测试项-系统测试子项-xxx

6.预置条件

执行当前测试用例所需要的前提条件。

如果这些条件不满足则后续的测试无法执行或者无法得到想要的结果。

7.重要级别

高：保证系统基本功能、核心业务，重要特性或者实际使用频率高。

中：介于高和低之间

低：非系统基本功能、非核心业务，实际使用频率低。

8.其他的要素，所属项目、用例创建时间、作者等

问题单模板：

1.标题:在xx地方做xx操作发现xx问题

2.步骤

3.期望结果

4.实际结果

5.项目

在jira上一个项目一个文档，一个项目按照迭代分类

6.编号

系统自动生成

7.测试环境

a、使用的环境操作系统、浏览器等

b、测试的软件或系统环境，版本等

8.严重级别

a、致命问题。软件根本无法使用或导致系统问题。

b、严重问题。严重影响用户使用。

c、一般问题。影响用户使用。

d、提示性问题。非界面的字符串错误。

9.出现频率

a、必现：

b、偶发：

按照固定频率出现

不按照固定频率出现

只出现一次

10.初步定位

11.发现人

12.其他，比如问题定位分析等