新员工入门 - for测试

23456人员介绍

XXX

测试工作

【软件】

Chrome 浏览器、jsonviewer、Firefox、FireBug
HTTP协议与抓包 - fildder、wireshirk等
DB查询工具 - navicat mysql、phpmyadmin
git工具
IDE工具
Linux远程连接工具 - xshell，cecurecrt等
接口测试工具：Gesen（google 浏览器的插件）Gesen's Bow、postman等
JDK1.7以上
Maven3.0以上

【系统】

OMS（订单系统测试环境）：http://omstest.huaxianbang.com/console/LogisticsPlanAct.do?getSummaryList#

BBD（邦帮代系统测试环境）：http://112.124.4.19:8989/login

物流系统：http://120.26.133.80:8787/login

CRM（客户关系管理系统）：http://crm-uat.huaxianbang.com/login

SAAS系统：http://112.124.4.19:8980/index

纺投系统：http://120.26.133.80:8484/index

【测试用例】

用例编写方法：

等价类划分
边界值
错误推测法
因果图方法
正交表分析法
场景分析方法
目前网上资料很多，自行搜索

根据软件产品质量模型，软件产品质量有六大属性，分别是功能性、可靠性、易用性、效率、可维护性、可移植性。我们在测试过程中也可以从这几个方面进行入手考虑。

需求、测试点、测试方法

需求 ==（使用各种测试方法进行分析）==> 测试点
在实际工作过程中，一般从几个维度去考虑：

流程
数据（入参、出参）（这些内容的等级类分析）
组合

用例
将上面的测试点中，入参操作，以及出参现象补充完整就成了一份用例

比如，登录模块

需求：输入正确的用户名和密码可以登录成功

测试点：

入参：用户名、密码
信息做一个简单分析：
规则，长度、类型等 ==> 测试点（为空，纯数字、字符串、长度超长，特殊字符等，密码是否必须为数字；大小写是否区分了）
前端做了限制的是否可以通过复制粘贴的方式来规避 ==> 比如长度
合法用户 ==> 已注册用户 （已注册的合法用户，各种规格是否都可以登录。比如有些系统密码允许中文注册，但是不能用中文进行登录）
非法用户 ==> 未注册用户
登录错误次数有没有限制
是否可以通过抓包等方式来直接获取用户信息
是否可以多点登录
是否可以通过URL的方式跳过登录模块
。。。

从需求角度分析，测试点：

是否需要添加忘记密码操作
是否需要添加密码显示功能
是否需要验证码
。。。

用例：
以4为例：
输入合法用户测试：

输入用户名“15158123456”、密码“123456”
点击登录，跳转成功，跳转目标正确
输入用户名“陈斌翔”、密码“123456”
点击登录，跳转成功，跳转目标正确
输入用户名“abcdefg”、密码“123456”
点击登录，跳转成功，跳转目标正确
。。。

【bug处理】

发现问题，提交到相应项目的Issues库中
bug标题：【版本】操作+影响（10-20个字）

bug描述：影响环境、重现步骤、期望结果（需要有产或者需求的确认）、实际结果
截图、日志（UI问题必须有截图，截图有标记，对内系统一个项目可以统一提成一个）
Bug级别：文案等非功能bug统一为“低”，数据流程等功能性bug统一为“中”，出现线上整块功能不可用等情况统一为“高”
线上bug：需要提供详细数据，以及影响
指给对应模块开发人员

开发解决bug之后，指回给对应测试人员

需求问题：比如PRD考虑不周全，有逻辑业务的遗漏或者错误，需要确认之后进行处理
不是bug：误操作、环境问题、版本合并的原因、不合法的测试数据都需要标记出来，并备注清楚
遗留bug：需要评估确认，并备注清楚遗留原因

测试人员验收

根据Bug现象进行验收，验收通过，需要把Bug close掉
Bug未修复，填写当前的现象，然后将bug维持在open状态，assign指回给开发，以及close的bug要reopen

测试跟踪

测试人员需要定期（每天下班前，或每天上班根据个人习惯）去跟踪提交的bug进度，定期及时处理自己名下的bug
如果有长期未处理bug，需要及时跟进
每周线上bug，需要整理并在周报中反馈出来

【测试周报内容】

1、这周做了什么？进度怎么样？有没有延期风险
2、下周做什么？目前进度怎么样
3、问题包括两个方面：
1）这周有哪些问题（线上的，不要把测试过程中发现的问题发给我），出现原因
2）进度是不是跟计划有不同，原因是什么

【测试报告】

把原先是测试点，在测试过程中补充成完整的用例；
然后把测试的过程反应在上面，哪些测试通过，哪些测试失败（目前bug的状态）；
测试完成之后，把这份用例作为交付件发给产品，进行验收