对软件测试的认识

做测试的工具也有半年多了，今天就从测试的流程以及可能遇到的问题来讲讲：

什么是测试

我理解的测试定义是：通过手工操作或工具使用对项目开发过程的产品（编码、文档等）进行差错审查验证，保证其质量的一种过程。

  

测试人员要测什么

从直观上讲，我们就是对测试对象进行检查、验证；在不同的项目阶段测试人员的工作内容是不一样的：

1、需求分析阶段：

a  分析需求内容，理出自己不懂的或不明确的地方

b  在需求会议上提出自己的见解，对之前不懂得一定要多问，有助于我们在后期制定测试计划

c  对不可测或难以测试的需求要提出来，三方讨论解决方法

d  对确定的需求分配point，确定优先级

2、测试计划：

a   尽早开始，根据项目的实际情况和和团队的资源合理制定测试计划

b  执行计划的过程中，遇到任何问题，不能因故守旧，要能灵活变通

3、测试分析与设计：

a  对必要的需求需要去了解开发的设计实现思路，便于用例的设计覆盖

b  对需求进行分析后，根据分析进行用例编写

c  在用例评审过程中，清楚陈述自己的内容，修改不正确的测试用例。

4、测试执行：

a  测试负责人划分不用的测试阶段，每个阶段都建立test Runs，根据用例严格执行测试，把执行结果记录下来

b 在执行过程的对用例不清楚或遗漏的地方及时去向开发和pm求证。

c bug的提交的规范，以及之后的验证、关闭

5、测试发布和总结

a  编写测试报告：记录整个项目的执行情况

 

在整个过程的可能遇到的问题

（1）需求变更：

首先确定是否要接受：其一通过需求变更截止时间来确定，超过这个则不接受，要移到下个版本，在这之前则接受变化。其二：需求一定要变，时间不够，就只能延长发布时间。

1. 变更需求通知：需求中任何的变更都要进行通知，可以会议邀请或邮件等但一定要保证三方都知道，同时需在jira上进行记录。

2. 整理记录：及时整理并记录在jira上，在每次不论通过何种方式得到需求变更信息，都要及时记录，以

便以后测试

3. 测试计划更新：在需求变更后，同时需制定一个比较详细的测试计划，注明本次测试的侧重点【变更哪些需

求、新增了哪些需求】，更新本次测试的人员安排、时间预估、风险等。

4. 测试用例更新：在执行测试前需对本期的用例进行更新，更新后也要进行用例评审（任何小的或大的变动都要进行确认）。

 

（2）测试用例设计不合理：

我们拿到一个需求后，要怎么写用例呢，是按需求一步一步写，还是按功能、流程、场景划分？测试用例需要些写到多细才能覆盖全面又不显冗余呢？感觉我一开始就是直接写，想到哪写到哪，因此思维比较混乱，用例覆盖率不足或过度设计，总之就是比较乱。之后觉得要改进了，就目前而言大致是一下流程：

1. 需求整理和确认：需求评审过后，对需求就有了大致的了解，那么首先要理出该需求相关的功能点，对不确定的地方进行求证，确定自己的理解是否正确。

2. 用例编写：根据之前的分析把用例大致分为两类，场景设计和功能点设计。场景：根据画出的模块流程图，模拟用户实际操作的不同场景，几个功能点的组合也算是用户场景。功能点：对一些页面元素，某个逻辑规则的测试，一般都是把对这些的点的细化直接作为用例的操作步骤描述。

3. 用例补充：用例评审过程中、在执行测试的过程中，可能会有一些问题在用例中未包含的，这时就需要进行补充或修改，完善。

 

参与测试工作后的一些感知：

1. 求知欲，简单点就是对自己不懂、疑问的地方，能想尽办法去解答。比如对需求的不解，那就要敢问，只有自己敢问别人才会知道你的疑惑，才会给你解答；自己闷头思索就是在浪费时间。

2. 自信，感觉做什么都要对自己有自信。测试过程红经常会出现自己提的问题不是问题，然后可能之后就不敢什么都提了，这就是自信缺乏的表现，所以要克服这种，首先要自己先思考自己的理解对不对，觉得对了，就提，提错了也不要紧，关键是要知道自己错在了那，之后改进。

3. 描述力，能够把自己的问题、想法等描述出来，是很重要的。经常的一句话就是只可意会不可言传，没法将自己学到的词的感觉跟你想描述的事物联系起来就是自己描述力不够的体现。在个部分我还是有很长的路要走的。

4. 调节力，测试的工作大部分还是很无聊的，当自己对重复的工作感到无聊的时候，就需要自己去调节自己的心态了，可以去看下新闻、做点自己感兴趣的事。