传送门汇总

Tips:

感觉自己的博客越来越乱了,所以想建个目录,这样方便大家快速定位到自己想要的东西,
当然也是方便自己,如果觉得对你有所帮助,可以加我微信:jianjiexuan520

新人能量包

  1. 软件测试术语英语单词
  2. 新人如何做好功能测试
  3. 测试类型
  4. 设计测试用例方法
  5. Bug严重程度分级
  6. 测试部新人培训计划文档

工作效率加速包

  1. 测试用例评审检查单及如何评审

功能测试升级塔

  • 业务逻辑
  • 客户端测试
  • web端测试
  • 服务端测试

自动化测试几日游 这个我是有点欠缺的,主要我的工作环境,不是经常用到,人力和维护成本都比较大,不适宜,所以相关的产出比较少。

性能测试终极试炼

  • 概念汇总
  1. 系统性能关注点
  • JMeter
  1. JMeter安装与配置
  2. JMeter初级应用-搭建基本测试环境
  3. Badboy安装和基本使用(扩展-JMeter录制)
  4. JMeter分布式测试
  5. JMeter图形监控JMeterPlugins
  6. JMeter参数化的几种方法
  7. JMeter集合点、检查点
  8. JMeter录制手机端操作
  9. JMeter元件作用域与执行顺序
  10. JMeter之获取某页面所有链接并再次请求
  11. 非GUI模式运行JMeter脚本
  12. JMeter与ant的结合使用
  • 瓶颈分析

安全测试刺探区

持续更新中。。。

测试部新人培训计划文档

以下是我给当前我们公司入职新人的一份必读文档,因为目前主要产品是app应用,所以偏向于客户端测试,大家可以参考下,某些和公司业务相关的内容隐藏了

一、公司情况的了解

熟悉公司的基本情况有助于快速融入公司,此阶段大约3天的时间。
  • 公司人员的熟悉
  • 公司组织架构的熟悉
  • 了解目前项目组有哪些在线项目,熟悉、使用、把玩,其中遇到不明白的问题可以记录下来
  • 了解部分(隐藏)专业知识

二、测试的前项准备

预先完成以下准备,能减少新人在实际测试过程中犯低级错误的几率,此阶段大约一周到两周的时间。 
  • 禅道、redmine、svn、企业邮箱等账号的申请
  • 常用软件的安装(svn、fiddler、Edit)
  • 环境配置(sdk、jdk等)
  • 禅道项目需求熟悉(过一遍大致需求),有不明白的是问题可以记录下来
  • 使用同类型的产品
两周后一般会进行一次深度谈话,可以把不明白的点一次性问清楚

三、项目的学习

  • 了解项目中的敏捷开发流程
  • 了解项目的测试切入点及测试流程
  • 掌握需求,并写出对应的测试用例,按照当前公司的模版
  • 掌握不同环境的测试方式
  • 不同方向的测试注意点
  • 独立完成所负责模块的验收测试
  • 写月总结,给组成员做月回归总结
项目的学习是最关键的阶段,最终的目的是让新人能系统的把项目需求都熟悉,
能快速的融入实际测试中,此阶段大约两周到三周的时间。针对不同方向的测试注意点需要做具体的细化。具体如下:

1. 基本功能测试(主要指app是否完成了设计的所有功能)

  • 安装/卸载时,系统正常安装/卸载成功(注意覆盖安装)
  • 安装成功后,系统图标显示正确;
  • 根据测试用例进行需求点的覆盖测试;
  • 对于中途中的一些返回或退出,应有相应的提示信息;
  • 显示的数据与接口返回的数据一致(抓包查看,如fiddler、charles);
  • 信息上传到数据库,上传的数据保持正确

2. 系统交互测试(系统正在使用一些功能时,外界给与的干扰是否会影响)

  • 电话短信干扰;
  • 低电量提醒;
  • push提醒;
  • usb数据线插拔提醒;
  • 充电提醒;
  • 音乐播放器干扰等

3. 兼容性测试(系统能够在不同的环境下都能正常运行)

  • 软件产品在软件本身的兼容性;
  • 不同平台下的兼容性;
  • 软件对运行设备的兼容性;
  • 软件互操作性(微信等)

4. 易用性测试(内容较多,可参照行业界面测试规范)

  • 路径短,用户操作简单;
  • 界面是否吸引人、容易理解;
  • 界面整洁、简单,色调统一;
  • 无错别字,字体格式统一;
  • 点击范围确定,利于用户操作等

5. 性能测试(作为了解)

  • 客户端稳定性:monkey的执行,会发现一些ANR及CRASH的问题;
  • app运行的内存消耗和cpu消耗;
  • app后台长时间运行的耗流量,耗电量;
  • 不同网络下的响应速度测试;
  • 服务端的压力测试,高并发、吞吐量;
  • 服务端稳定性,利用7*24方式去进行测试

6. 其他全局测试

  • 网络切换下的app运行情况及功能正常(wifi/4G/3G/2G)。
  • 网络信号强、弱甚至无网络情况下的app运行情况。

作为测试,你真的入门了吗?

前言:

不同的人对测试或多或少都有不同的定义,最直白的,就是找bug。我们不必纠结它的术语具体是哪些字组成,而是要知道其含义,死记硬背的做法只适合学生时代。

测试的定义:

一般我们对软件测试的专业定义如下:

(1)软件测试是在现有软件(程序+文档)中寻找缺陷的过程;

(2)软件测试是指使用人工或者自动化手段来运行或测试某个系统的过程,目的是检验系统是否满足需求规格说明书中的要求

这两句话我们只需记住3w即:who where what?who?即为人工或其他手段;where?现有软件中;what?寻找缺陷。何为缺陷?与预期不一致的实际结果即为缺陷。 这样就算你不刻意去背它的含义,你也已经很明确地知道了何为软件测试。

举例说明:

定义总是看看就明白了,看懂了不一定就真的会了。很多人就真的理解为,说到底不还是找bug么?还是跟着需求找,就像给你两份东西,让你去做校对,这多简单,有什么难度?任何人都可以从事测试这个行业。这不仅仅是外人对测试的理解,甚至很多测试工作者本身也是这么理解的。外人不明白,这么想也情有可原,作为该职位的从业人员也这么想,那说明你真的还没入门。

我们刚开始学习测试或刚出来工作面试的时候,总会遇到一个万年不变的题型,即如何测试“用户登录”。很简单的测试场景,却能完美体现出一个测试人员的根基。 很多时候一些公司是不具备完整且非常巨细的需求文档的,所以不要一上来就说,给我一份完整的需求规格说明书,那你和机器真没什么区别了。

那么不妨,我们来挑战下,用一张纸,写下你所知道的测试点,时间限制为5分钟。

下面是三个人的答案,A刚工作,B工作5年,C工作6年,由于时间有限,所以肯定是影响发挥的。

A的答案:

1. 未注册,点击登录;

2. 已注册,输入密码,点击登录;

3. 已注册,忘记密码;

4. 输入不存在的用户名,正确的密码,点击登录。

B的答案:

1.输入正确的手机号和密码可以正常登录

2.输入错误的手机号,点击登录会有对应的登录失败提示语

3.输入错误的密码,点击登录会有对应的登录失败提示语

4.输入未注册的手机号,点击登录,会头对应的提示语

5.手机号格式不正确,点击登录,会有对应提示:请输入正确手机号

6.是否支持邮箱或昵称登录,不支持也需要有对应提示

7.密码设置时若有特殊字符,登录时输入密码,能否校验通过

8.手机号和密码都为空,点击登录,会提示不能为空

9.手机号和密码输入栏,是否一键清除内容功能

C的答案:

1、输入正确的用户名和密码,登录成功

2、输入错误的用户名或密码,给与相应的提示

3、根据需求确定等价类或边界值,进行输入框测试

4、特殊字符的验证

5、文案的正确性,是否有暗文字提示

6、密码是否需要隐藏

7、忘记密码与注册的入口

8、密码框不能复制粘贴

9、是否需要图形验证码

10、界面的正确性及兼容性

11、单个用户的登录响应时间

12、多个用户并发的响应时间

13、传输过程中是否加密处理

14、对于xss的攻击处理

15、抓包无法获取密码明文

16、登录是否唯一,退登操作

17、登录后的权限角色一致

18、修改密码后仍然正确登录成功

对照下自己的答案,你属于哪种? 从上面的三份答案,我们可以看出,测试并不仅仅是表面上看的那么简单,由于时间的限制,上面的答案都是不完整且欠缺的,就算这样,出入门和有几年工作经验的差距还是蛮大的,所以,新手不要自我膨胀,测试之路也是一条漫长的路,虚心学习,脚踏实地,方是正道(哈哈,扯远了)。

这边我还想提一点题外话,很多人觉得功能测试者没什么技术含量,搞自动化或者搞性能的才是高手。但在我看来,功能测试厉害的才是真正的大师,技术什么的,只要你愿意,你总能花时间学会,但是功能测试,却要拥有很强的逻辑思维,很全的用例设计,这是花时间也不一定学得来的。所以,会点自动化,搞点小压测,就觉得自己很牛逼的,我是从来不屑的,哪怕你会的东西我都不会。

最后,感谢大家的阅读。

小作坊也可出高质量——测试流程优化

测试流程优化

适用于创业型及规模不是很大的公司,一般用于敏捷开发

需求分析

  • 需求预览
    • 关于下一阶段的需求会在群里贴出,需要提前消化,疑惑点先行列出,并且告知测试内部评审时间。
  • 评审需求
    • 测试内部需求评审,提出疑惑点,领取需求
  • 需求文档维护
    • 每一阶段都有一位成员补充该阶段需求到需求文档,以便追溯(一般小作坊是没有规范的需求文档的,有时候需要测试自己去维护)
  • 测试点提取
    • 各人领取对应需求后,分析该需求的测试点

测试用例

  • 测试用例
    • 不需要写具体的操作步骤,着重写测试点,分基本流和备选流
    • 对应需求测试用例由最终负责人编写
    • 注意测试用例的格式的统一
    • 交叉补充,保证测试点的全面性
范例:
前置条件中加入涉及的需求编号;
用例类型默认为功能测试;
试用阶段默认为系统测试阶段;
用例标题:
7.9.0】工行支持充值、提现等能力验证
步骤                                      预期
1、工行充值能力验证                        基本流:
                                          1、输入金额等正常信息充值成功,有返回信息
                                          2*****
                                          备选流:
                                          1、充值过程中,金额不足
                                          2、充值过程中,网络中断
                                          3、控件输入特殊符号容错
                                          4*****
2、工行提现能力验证                        *******

  • 冒烟测试用例
    • 主要用来给开发自测,将本版本所有用例的基本流列入即可。
    • 每一阶段都有一位成员提供冒烟测试用例
    • 注意标题格式:【V_7.9.0客户端冒烟用例】
    • 完成后链接发给对应客户端负责人
  • 封板用例
    • 每一阶段都有一位成员补充新增功能到最终封板用例中

冒烟测试

  • 提测阶段
    • 开发完成开发后,会发送提测邮件,相关需求领取人走下冒烟测试用例,并反馈是否通过
    • 如中途有新增需求或更改需求,需开发、测试再次合理估期,可二次追加提测邮件,以保证质量的可控。
  • 冒烟测试邮件反馈
    • 拿到提测包后,一小时内给出需求冒烟测试结果反馈
    • 综合测试结果给与邮件反馈,通过则进入系统测试;不通过则打回。

系统测试

  • 测试周期

 

  • 交叉测试
    • 第一轮系统测试由领取需求的人执行
    • 最后一轮系统测试由需求负责人执行
需求编号 用例(负责人) 第一轮(领取人) 第二轮(测试环境) 第三轮(正式环境) 第四轮(负责人)
1293-工行充提能力验证 A B C D A
*** *** *** *** *** ***
  • bug规范
范例:
下图中根据禅道已经给出详细说明


  •  验收测试
    • 即根据封板用例测试一下所有功能的主流程,确保所有模块不出大的问题
    • 一般是在新增需求已经完全结束测试的情况下进行
  • 性能测试-启动/流量/响应
    • 即应用冷启动/热启动的时间(不同版本/竞品的对比)
    • 变更大的时候考虑不同版本间耗流量的对比
    • 变更大的时候考虑不同版本间响应时间的对比
  • Monkey测试-提取crash
备注:

这些只是我结合实际调整的方式,力求在最短的时间内,充分利用人力资源保证质量,每个人可以结合公司实际找出最适合的那种方式,测试本身就要灵活点,不能按部就班、死板。

测试人员的发展路线

测试人员的发展路线大概可分为两类:管理路线和技术路线。两条路线的初期阶段基本一致,如图所示:

一、管理路线

每一个阶段有不同的要求和侧重点,可以自己对照下自己处于什么阶段。

1、初级测试工程师

这条路线的初始级别,一般经过试用期后,如果基本符合测试的各项需求,则转成初级测试工程师。初级测试工程师要求具备基本的测试执行能力和测试理论知识,主要集中在手工测试和基本的功能验证性测试方面。

2、中级测试工程师

在初级测试工程师的位置锻炼了一段时间后,就可以考虑转向中级测试工程师。中级测试工程师一般要求具备一到两种完整测试项目的经验。要求具备基本的测试设计能力,对测试理论知识的进一步理解,主要集中在黑盒测试的执行及其测试用例的设计方面;还应具备一定制作测试计划和测试报告的能力。

3、高级测试工程师

从中级测试工程师到高级测试工程师之间有一个明显的界限,就是测试经验。一般要成为高级测试工程师,需要具备3~5个大小测试项目的经验。具备较强的测试用例设计能力,能把测试理论知识融入到测试工作实践中。测试类型包括黑盒测试、白盒测试、性能测试等方面。具备较好的制作测试计划和测试报告的能力。

4、测试组长

在成为高级测试工程师后,则很有可能被委任为某个测试项目的测试组长。测试组长与高级测试工程师在测试技能方面的能力相当,但是具备相对较强的制作测试计划和测试报告的能力,测试的组织能力及沟通能力。测试组长担负着测试、开发以及其他部门之间沟通的角色,负责处理很多沟通上的事情,同时,还负责测试任务的分配、测试资源的安排、测试分工等事项。需要具备一定的测试风险意识,以及与开发人员针对某些焦点问题交涉的能力。需要具备Bug评审的组织和缺陷分析的能力。

5、测试主管

在成为测试组长后,需要表现出较强的组织和沟通能力以及人员管理能力。最好能在公司的大部分项目中做过测试工作,那么就很有可能被委任为测试主管。测试主管与测试组长的主要区别在于:测试主管需要管理的是多个测试项目的资源调度、人员招聘及培训、能力评估和绩效考核。测试主管需要协调测试部门与其他部门之间的工作。测试主管一般不参与具体的测试工作,但是需要对所有测试的进度进行监控,需要关注测试部门的工作和学习氛围以及人员之间的凝聚力。

6、质量主管

如果公司的规模足够大,还可能在测试主管之上设置一位质量主管。质量主管除了管理测试工作外,可能还要管理QA的工作,负责整个公司质量方面的管理。质量主管主要关注测试的整体组织架构设置是否合理,测试工具的选型是否合理,测试人员与其他人员的沟通和交流是否存在问题。另外,质量主管还会重点关注流程的质量,负责引入ISO、CMMI等质量改进模型,并负责质量管理体系的建立和维护,负责整个公司范围内的质量问题的发现,协助管理者制定纠正预防措施,并跟踪措施的有效执行。

二、技术路线

前面的发展路线与管理路线一致,到了高级测试工程师后,就可以考虑在某方面的测试技术领域深造了。

1、单元测试工程师

单元测试是一个可以持续研究、深入研究的领域,本着尽早测试的原则,单元测试无疑是测试性价比最高的一类测试。但是,由于测试人员在编码方面不具备优势,因此,对这方面感兴趣的测试人员可以持续地研究和锻炼自己,让自己成为一名单元测试工程师。

2、白盒测试工程师

白盒测试也是一个需要深入学习和研究才能精通的领域,并且里面有很多技术有待人们进一步发展。代码检查和错误预防技术、自动错误检测等都是很新的话题,对这方面感兴趣的测试人员完全可以持续研究,让自己成为一名白盒测试工程师。白盒测试工程师同样需要具备丰富的代码设计和编写经验。

3、性能测试工程师

性能测试由于其涉及的知识广泛,每一个项目的性能测试都有可能出现一些很具有挑战性的内容,因此,也吸引了很多测试人员的专注,希望成为专职的性能测试工程师。性能测试工程师需要具备丰富而全面的知识,包括程序代码的架构、操作系统、数据库、网络等方面的知识。

4、功能自动化测试工程师

软件测试的自动化一直是很多测试人员心中的梦想,梦想着有一天,测试人员不需要重复地进行劳作,全部测试工作都交给工具进行,测试人员只需要设计测试用例就可以了。梦想总归是梦想,现实中,测试人员需要在自动化测试领域深入地研究,发现更多实用的自动化测试技术。功能自动化测试工程师同样具备一定的编码技巧,同时需要具备丰富的底层API知识。

5、安全测试工程师

安全是近年来软件行业的关注点,安全测试也是相对空白的一个领域。安全测试要求测试人员具备丰富的安全知识,需要了解很多安全漏洞和黑客技术的原理。

6、测试设计架构师

如果具备了多方面或多个测试领域的丰富经验和知识,就具备了成为测试架构师的条件。测试架构师负责测试方面的整体设计,包括测试类型的制定,测试技术和工具的应用,测试工具的开发,整体测试框架的设计和自动化测试框架的搭建。

 

看完这些,是不是对自己未来的发展明确了些?测试其实包含很多,我们说开发,其实都知道开发分web 端、server端、iOS端、Android端等,同理,作为测试的自己,也要清楚怎么样划分。

HTTP状态码汇总及默认端口号

一、常见HTTP状态码

100 Continue 初始的请求已经接受,客户应当继续发送请求的其余部分
101 Switching Protocols 服务器将遵从客户的请求转换到另外一种协议
200 OK 指示请求成功,且请求的信息包含在响应中。这是最常接收的状态代码
201 Created 指示请求导致在响应被发送前创建新资源
202 Accepted 指示请求已被接受做进一步处理
203 Non-Authoritative Information 指示返回的元信息来自缓存副本而不是原始服务器,因此可能不正确
204 No Content 指示已成功处理请求并且响应已被设定为无内容
205 Reset Content 指示客户端应重置(或重新加载)当前资源
206 Partial Content 指示响应是包括字节范围的 GET 请求所请求的部分响应
207 Multi-Status 多状态响应,代表之后的消息体将是一个XML消息,并且可能依照之前子请求数量的不同,包含一系列独立的响应代码。
226 IM Used  im 使用,服务器已完成对资源的 get 请求, 响应是应用于当前实例的一个或多个实例操作的结果的表示形式。
300 Multiple Choices 指示请求的信息有多种表示形式。 默认操作是将此状态视为重定向,并遵循与此响应关联的 Location 头的内容
301 Moved Permanently 指示请求的信息已移到 Location 头中指定的 URI 处。 接收到此状态时的默认操作为遵循与响应关联的 Location 头。 原始请求方法为 POST 时,重定向的请求将使用 GET 方法(重定向问题)
302 Found 指示请求的信息位于 Location 头中指定的 URI 处。 接收到此状态时的默认操作为遵循与响应关联的 Location 头。 原始请求方法为 POST 时,重定向的请求将使用 GET 方法(重定向问题)
303 See Other 类似于301/302,不同之处在于,如果原来的请求是POST,Location头指定的重定向目标文档应该通过GET提取
304 Not Modified 客户端有缓冲的文档并发出了一个条件性的请求(一般是提供If-Modified-Since头表示客户只想比指定日期更新的文档)。服务器告诉客户,原来缓冲的文档还可以继续使用
305 Use Proxy 客户请求的文档应该通过Location头所指明的代理服务器提取
306 Unused 是未完全指定的 HTTP/1.1 规范的建议扩展
307 Temporary Redirect 和302(Found)相同。许多浏览器会错误地响应302应答进行重定向,即使原来的请求是POST,即使它实际上只能在POST请求的应答是303时 才能重定向。由于这个原因,HTTP 1.1新增了307,以便更加清除地区分几个状态代码:当出现303应答时,浏览器可以跟随重定向的GET和POST请求;如果是307应答,则浏览器只 能跟随对GET请求的重定向
400 Bad Request 请求出现语法错误(无法解析此请求)
401 Unauthorized 访问被拒绝,客户试图未经授权访问受密码保护的页面。应答中会包含一个WWW-Authenticate头,浏览器据此显示用户名字/密码对话框,然后在 填写合适的Authorization头后再次发出请求。IIS 定义了许多不同的 401 错误,它们指明更为具体的错误原因。这些具体的错误代码在浏览器中显示,但不在 IIS 日志中显示:

401.1 – 登录失败。

401.2 – 服务器配置导致登录失败。

401.3 – 由于 ACL 对资源的限制而未获得授权。

401.4 – 筛选器授权失败。

401.5 – ISAPI/CGI 应用程序授权失败。

401.7 – 访问被 Web 服务器上的 URL 授权策略拒绝。这个错误代码为 IIS 6.0 所专用。

402 Payment Required 保留 PaymentRequired 以供将来使用
403 Forbidden 资源不可用(禁止访问,访问被拒绝)。服务器理解客户的请求,但拒绝处理它。通常由于服务器上文件或目录的权限设置导致。禁止访问:IIS 定义了许多不同的 403 错误,它们指明更为具体的错误原因:

403.1 – 执行访问被禁止。

403.2 – 读访问被禁止。

403.3 – 写访问被禁止。

403.4 – 要求 SSL。

403.5 – 要求 SSL 128。

403.6 – IP 地址被拒绝。

403.7 – 要求客户端证书。

403.8 – 站点访问被拒绝。

403.9 – 用户数过多。

403.10 – 配置无效。

403.11 – 密码更改。

403.12 – 拒绝访问映射表。

403.13 – 客户端证书被吊销。

403.14 – 拒绝目录列表。

403.15 – 超出客户端访问许可。

403.16 – 客户端证书不受信任或无效。

403.17 – 客户端证书已过期或尚未生效。

403.18 – 在当前的应用程序池中不能执行所请求的 URL。这个错误代码为 IIS 6.0 所专用。

403.19 – 不能为这个应用程序池中的客户端执行 CGI。这个错误代码为 IIS 6.0 所专用。

403.20 – Passport 登录失败。这个错误代码为 IIS 6.0 所专用。

404 Not Found 无法找到指定位置的资源。这也是一个常用的应答。 · 404.0 -(无) – 没有找到文件或目录。 · 404.1 – 无法在所请求的端口上访问 Web 站点。 · 404.2 – Web 服务扩展锁定策略阻止本请求。 · 404.3 – MIME 映射策略阻止本请求。
405 Method Not Allowed 请求方法(GET、POST、HEAD、DELETE、PUT、TRACE等)对指定的资源不适用,用来访问本页面的 HTTP 谓词不被允许(用于访问该页的HTTP动作未被许可)
406 Not Acceptable 指定的资源已经找到,但它的MIME类型和客户在Accpet头中所指定的不兼容,客户端浏览器不接受所请求页面的 MIME 类型
407 Proxy Authentication Required 要求进行代理身份验证,类似于401,表示客户必须先经过代理服务器的授权
408 Request Time-out 在服务器许可的等待时间内,客户一直没有发出任何请求。客户可以在以后重复同一请求
409 Conflict 通常和PUT请求有关。由于请求和资源的当前状态相冲突,因此请求不能成功
410 Gone 所请求的文档已经不再可用,而且服务器不知道应该重定向到哪一个地址。它和404的不同在于,返回407表示文档永久地离开了指定的位置,而404表示由于未知的原因文档不可用。(文件已删除
411 Length Required 服务器不能处理请求,除非客户发送一个Content-Length头
412 Precondition Failed 请求头中指定的一些前提条件失败
413 Request Entity Too Large 目标文档的大小超过服务器当前愿意处理的大小。如果服务器认为自己能够稍后再处理该请求,则应该提供一个Retry-After头
414 Request-URI Too Large 指示 URI 太长
415 Unsupported Media Type 不支持的媒体类型
416 Requested range not satisfiable 服务器不能满足客户在请求中指定的Range头
417 Expectation Failed 执行失败
423 Locked 锁定的错误,意味着一个方法的源或目标资源是锁着的。 这种反应应该包含一个适当的先决条件或后置条件代码
424 Failed Dependency  

失败依赖项, 状态代码意味着无法对资源执行该方法,因为请求的操作依赖于另一个操作,而该操作失败。例如,如果 PROPPATCH 方法中的命令失败,则至少其余命令也将失败。

 

425 Unordered Collection 无序集合
426 Upgrade Required  需要升级,客户端应当切换到TLS/1.0。
500 Internal Server Error 服务器遇到了意料不到的情况,不能完成客户的请求(服务器内部错误):

500.12 – 应用程序正忙于在 Web 服务器上重新启动。

500.13 – Web 服务器太忙。

500.15 – 不允许直接请求 Global.asa。

500.16 – UNC 授权凭据不正确。这个错误代码为 IIS 6.0 所专用。

500.18 – URL 授权存储不能打开。这个错误代码为 IIS 6.0 所专用。

500.100 – 内部 ASP 错误。

501 Not Implemented 服务器不支持实现请求所需要的功能,页眉值指定了未实现的配置。例如,客户发出了一个服务器不支持的PUT请求。(标题值指定的配置没有执行)
502 Bad Gateway 服务器作为网关或者代理时,为了完成请求访问下一个服务器,但该服务器返回了非法的应答。 亦说Web 服务器用作网关或代理服务器时收到了无效响应 · 502.1 – CGI 应用程序超时。 · 502.2 – CGI 应用程序出错。
503 Service Unavailable 服务不可用,服务器由于维护或者负载过重未能应答。例如,Servlet可能在数据库连接池已满的情况下返回503。服务器返回503时可以提供一个 Retry-After头。这个错误代码为 IIS 6.0 所专用
504 Gateway Time-out 网关超时,由作为代理或网关的服务器使用,表示不能及时地从远程服务器获得应答
505 HTTP Version not supported 服务器不支持请求中所指明的HTTP版本
506 Variant Also Negotiates 代表服务器存在内部配置错误:被请求的协商变元资源被配置为在透明内容协商中使用自己,因此在一个协商处理中不是一个合适的重点。
507 Insufficient Storage 存储不足,表示方法不能 在资源上执行,因为服务器无法存储,表示需要成功完成请求。
516 Not Extended 不扩展

 

二、常见协议端口号

HTTP

80

FTP

20用于数据连接, 21用于端口连接

SSH

22

Telnet

23

HTTPS

443

 

三、常见数据库端口号

MYSQL

3306

SQL Server

1433

Oracle

1521

小企业如何最大限度提高测试质量?

众所周知,小企业肯定人数不会多,很多能精简则精简。甚至很多小企业都没有测试人员,当我们有幸加入到一个不是很大的企业的测试部门,如何能更好的进行测试呢?

现在敏捷开发被炒的很热,其实,我觉得现在还没有一个完全正确的工作流程能去阐述清楚敏捷开发,基本都是每家小企业拿着个文档不全的理去美化自己是敏捷开发,1000个企业就有1000个敏捷开发流程。敏捷开发里是弱化了文档的重要性,更着重讯息的及时沟通,需求变更也平常。所以,敏捷开发里的每一环的人员自身能力都要很靠谱。而对于测试人员的挑战与压力无非是巨大的。因为没有统一的文档,我们要时时刻刻关注所有聊天群组、站立会议、邮件等探讨出的新需求,漏掉哪一个,就彻底漏掉了,没有根源可寻。但是一出现问题,你没有测到,某某这时就会站出来说,我明明在之前说过,说没说过没人知道,因为你不是对着测试说的,我们已经尽力去搜寻散落的需求,但是这种遗漏还是会存在,发生这种情况总会比较尴尬。

  但是如何能避免呢?

你需要一个记事本,新版本的所有需求,反正你知道的,无论何种途径,立马同步更新到你的记事本里,开发过程中的新增需求、修改的需求,删减的需求,都及时同步,这样就会最大化保证需求的同步,好记性不如烂笔头,这样在最后验收的时候才能确保万无一失。记事本可以考虑印象笔记、onenote,都还不错。

需求已经尽量得到了同步,接下来如何去进行高质量、高效的测试呢?

从高效的角度来说,敏捷开发完全可以摒弃测试用例。那种详细的、繁杂的描述也是就是耗费时间,没等你写完,就已经到了开测的时间。这时候的测试用例基本成了鸡肋,用也用不上。而且慢慢看测试用例的时间已经够我测完一个需求点了。但是我们又不能什么都不写,那我们和那些不懂测试,拿到手就开始随便点点点的人又有何不同?不写测试用例是节约了时间,但是如何保证质量呢?其实我们可以根据现有的需求列出checklist,这样即节约了时间成本,又给我们真正测试时提供了测试思维的提醒,不至于漏测一些常规路径,从而可以保证质量。

也许其他人会有更好的想法,我目前是这样安排的:


解释:

1、需求编号:有些录入到禅道或者excel中的需求是有编号的,为了方便我们查看,可以写出编号;有些是临时加的,我们可以直接写出需求点;另外如果有删减的,可以直接添加删除线。

2、checklist:即是需要测试的检查点,对应的A、B、C其实是测试人员。checklist由C写出后,给与A一些参考,A可继续完善补充checklist再给B参考,B测试过程中也可继续完善和补充checklist,这样最终返回到C手中的checklist已经丰富了好多。

3、系统测试:系统测试其实是很重要的一个缓解,需要测试好几轮,确保bug收敛到最低,然后交给B去交叉。

4、交叉测试:交给B交叉是为了发散出更多的路径,毕竟每个人看东西的角度都是不一样的,这样能更大限度的去保证质量。

5、验收测试:从写checklist到现在,C其实一直没有参与到测试,而这时,bug基本已经没有,C根据补充完善后的checklist进行最后的验收。

6、常规测试:这是我自己分化的功能模块,每个测试人员都有自己负责的模块功能。这样没有新增需求的模块、线上的应用、反馈的问题,都能对应到具体模块负责人,比如首页就是A一直负责的,所以最终新增需求都测试结束后,首页整个模块都需要A最后再去验收。

7、α测试:除去参与此需求从产生到结束的人员,找一些公司其他人员,充当用户,给与15分钟的快速体验,测试只需在一旁记录下体验期间提的所有建议就可以。这些建议也许不是bug,仅仅是操作上的不爽,这些也应该记录,之后汇总、讨论,哪些是必要解决,哪些是可以延期处理的,哪些是可以忽略的。

8、β测试:不一定每次的版本都需要执行,可以在重大需求,或者发布有风险的前提下实行。增加一些灰度测试,取一些真实用户去体验,及时收集用户的反馈,并可根据第三方查看日志,是否有崩溃等问题出现。

 

表格解释完了之后,明眼人都能看出,这样一层层测试下来,质量绝对是有保障的,而且能利用的资源基本都被高效利用了,已经实现了利益的最大化。针对于小型企业、测试部门人数不足的情况,我目前只能想到这样去安排工作,如果我之后发现有更好的工作方式,会及时更新的。

希望对你有作用。

如何更好的测试移动端app总结

测试移动端与测试web或者其他还是有些许差异的,为了方便大家能够快速的掌握测试移动端app的要点,下面根据自己的切身经验进行了一些总结。希望能够对大家有所帮助。

测试前的思考

我们这个产品主要是做什么的?市场上有那些同类型的产品?我们的产品所具有的优势?

测试前的准备

1、使用同类型的产品,在接触到自己产品之前,就已经对大致的主体功能有测试方向。

2、熟悉我们产品的需求设计文档,模糊的地方积极和pm交流。

3、写测试用例,资源不够的话可以不写,但是需要有checklist。

功能测试注意点

1、基本功能,主要指app是否完成了设计的所有功能。

分清模块,写一份checklist,避免漏测。

详细包括:

1)安装/卸载时,系统正常安装/卸载成功(注意覆盖安装);

2)安装成功后,系统图标显示正确;

3)根据checklist进行需求点的覆盖测试;

4)对于中途中的一些返回或退出,应有相应的提示信息;

5)显示的数据与接口返回的数据一致(抓包查看,如fiddler、charles)

6)信息上传到数据库,上传的数据保持正确

 

2、系统交互:系统正在使用一些功能时,外界给与的干扰是否会影响当前功能。

1)电话短信干扰;

2)低电量提醒;

3)push提醒;

4)usb数据线插拔提醒;

5)充电提醒;

6)音乐播放器干扰等。

 

3、兼容性:android碎片化是个难题,bug也多,ios相对bug少。

需要针对不同系统及不同机型进行覆盖测试。Android可以选取一些代表性的机型。

 

性能测试注意点

1、稳定性:利用monkey在下班后进行一些伪随机用户事件的执行,会发现一些ANR及CRASH的问题。

2、app运行的内存消耗和cpu消耗。

3、app后台长时间运行的耗流量,耗电量。

2、3点等可以用Emmagee或GT进行Android端的测试,iOS端可以直接利用xcode自带的插件进行分析

4、不同网络下的响应速度测试(可以利用charles工具实现)。

5、服务端的压力测试(可以使用jmeter),高用户的并发都要要考虑的问题。

 

易用性测试注意点

1、路径短,用户操作简单

2、界面是否吸引人、容易理解。

3、界面整洁、简单,色调统一。

4、无错别字,字体格式统一。

5、点击范围确定,利于用户操作等。

这部分测试很多,可以参照易用性-界面测试规范,如果认为有不合理的地方通常会提交需求bug-设计问题。

 

自动化测试注意点

如果不是敏捷开发,可以执行自动化测试(robotium,monkeyrunner,androidjunit),这样在回归的时候会节约很多资源。但是面对经常变更UI的敏捷开发,自动化测试的维护成本就较高,这时候并不合适加入自动化测试。但可以加入monkey自动化随机测试,还可以对接口进行自动化测试。

另外,敏捷开发中,一定要有持续集成的环境,这样可以节省很多时间。

 

其他测试注意点

1、网络切换下的app运行情况及功能正常(wifi/4G/3G/2G)。

2、网络信号强、弱甚至无网络情况下的app运行情况。

 

暂时就总结这么多了,以我目前的眼界也只能囊括这么多,如果以后发现了更多的注意点,会逐步更新的。

关于软件上线后出现重大bug是谁的责任?

之所以写这篇文章,主要是大部分测试还是处于弱势地位,线上一旦出问题,大部分人想到的是:你这个没测?基于这点,这篇文章也许可以给你一个明确的答案,这到底是谁的责任。

一、先解决问题

线上爆发重大bug,这时候不是追究责任的时候,而是动员所有可调用的资源,尽快解决这一问题,将损失降到最低。而一般公司在这之前就应该制定好出现重大问题的补救流程和方案以及对应的人员分配。

二、定义bug的性质

解决问题后,定义线上发生的问题的性质,是第三方引起的,不可抗拒的问题,还是自身疏忽导致的错误?且爆发的问题的严重程度,关于bug严重程度的区分,可以参看我的另一篇文章。(传送门:http://blog.jianjiexuan.com/testdocument/42.html

三、分析产生bug的根源

1、需求未涉及,或需求当初定义的不够详细造成。

 这个一般由需求、设计、测试都承担责任,需求的责任最重。之所以说设计和测试也有连带责任,是因为需求评审的时候也参与进去了,而需求都是通过大家一致确认可行通过才执行的。当然,有些公司对于需求评审也不是很重视,也没有专门写需求文档的人,甚至一些小公司直接都是口头表达,这样的需求连记录都没有,实在没办法追责。不过,一般这样的公司也不会追责,如果追责的话,建议设计(产品)、测试一句:你可以刷新简历了。

2、设计过程、开发过程未实现造成。

 这种问题是需求检查到了有未完成的需求,但是设计和开发并没有进行弥补。则为设计与开发的责任,而设计的责任最大。

3、测试过程中的疏漏造成。

 测试过程中的疏漏有2种情况,一种是测试用例没有覆盖,一种是测试用例覆盖了没有执行。第一种参与过测试用例评审的都有责任,但是设计测试用例的人承担最大责任。第二种则完全是测试责任。当然,很多公司根本就不具备评审测试用例或者有专门写测试用例的人,本来管理流程就乱,一人做多种职位的事情,这时候如果硬要追责,建议测试一句:你可以刷新简历了。

4、交付部署中出现问题造成。

 比如版本错误、发布错误、部署错误,一般在设计(产品)、配置、测试经理共同承担责任。

5、私自改动代码造成。

 只能开发哥哥完全承担了。

四、分析总结

 对于这次的事件进行分析与总结,确定是谁的问题后,应该吸取教训,并给出措施,给下次的版本一个参考。

 

其实这套方案肯定是基于自身的流程和管理都非常明确的公司执行。并不适合小团队去执行,小团队建议还是大家一起承担,否则,只会让员工提前离开。如果你不是领导者,愿你不需要看到这篇文章。

 

高级软件测试工程师需具备的能力

enlightened每个测试在工作一段时间后,都会迷茫,其实不仅仅是测试,很多工种都会这样,不知道下一步往哪个方向发展,觉得自己在虚度岁月,没有任何进步,开始慢慢的适应了现在的一成不变,这是很危险的,你能看到这篇文章,说明你想改变,恭喜你,你会有收获的。 测试或其他技术工种的发展方向大致是相同的:1、继续专研技术,成为中级测试、高级测试、测试专家等;2、管理方向,这就不仅仅是测试技术了,你得懂得很多团队的东西,最好能有几个证书;3、转相关行业,比如产品、开发什么的。大部分人会选择第一点,而第一点又能细分很多种,白盒的、性能的、数据库的,而我主要讲的是综合的,慢慢的提升以下能力,不管你去互联网哪家公司,你都能如鱼得水。

一、品德心态好

  为什么把这个放在第一位呢?很多人不在乎,认为有技术就行,其实这个不管在测试还是其他方面都很重要,你平易近人,凡事有理有据,不歇斯底里,大家就都愿意和你共事,这样的你也会在这样的工作氛围内更加得心应手,而且测试是需要吵架的,如何把握这个吵架的分寸就很重要,不影响彼此的关系还能把工作做好。

1、首先,我们自己要语气平缓,有些人真的是天生语气就很冲(我身边有这样的人,基本没朋友),如果你是,一定要尽力去更改。虽然也许你本意只是阐述一个bug,但是别人听起来就是责怪,所以这是很头疼的。我之前也有,我明明是在讲bug,开发说你别这么激动,感觉我要吵架,其实真没有(宝宝好委屈(┬_┬)),因为不仅仅一个人这样说,我知道这肯定是我的问题,我肯定是要改的,所以就经常听些舒缓的音乐,看些心理或者周易之类的书,说话的时候每次注意点,形成习惯后,就会彻底改变。

2、讲问题要有理有据,对事不对人,测试很多时候对需求的理解和开发或者产需求的人有偏差,还有描述问题的时候和开发理解的有偏差,这时候难免会起争执。首先,有争执是好事,证明你有自己的想法,你去思考了,你在乎这个需求了,而争执的目的我们要清楚,就是希望产品更好,千万不要带着个人色彩,这样以后的工作大家都会尴尬。但是有争执不能歇斯底里,我们要讲事实摆道理,最重要的一点,一定要倾听别人的想法,坚持己见固然不错,前提是你真的是对的。如果别人说的有道理,你也可以称赞认同,记住,我们争执的目的。

3、对于同是测试的同事,要互相帮助,不要吝啬自己所会的,因为你一直在前进就不怕别人赶超,你帮助别人的同时,也能巩固自己的知识。我经常遇到这样的测试,自己偷偷的学习些技术,为什么说偷偷的呢,因为别的测试走过去的时候,她会迅速关掉正在看的东西(技术类的),首先你学习是好事,但是被看到又怎么了,别人有心也去学,这不是激励你么,再说别人真有心去学,肯定也能搜到,如果无心,看到就看到呗,反正不思进取。还有很多时候新手问问题,很多人会说,就这样啊,点一下写几个东西就好了,很简单的。拜托,你不想说就直说,想说就说清楚。如果你有这些问题,你一定要更改,你的突出不是阻止别人前进,而是加快自己前进的步伐,而且,好的心态,对你整个人生都是有帮助的。相信我。

二、业务熟悉

  作为一个合格的测试,不管你要测什么,你都要了解清楚你所要涉及的业务的所有需求,不能说了解,应该叫掌握、熟记于心。这是一个很庞大的事情,但是你必须这样,因为只有这样,任何一个改动你都能了如指掌,及时进行跟踪,别其他人问起,你却不知道,这样真的很尴尬。

1、熟悉你所测试的系统

  必须非常熟悉你所测试的系统,知道哪些需求是重要的,哪些的次要的,这样才能更好的合理分配你的测试资源。对于需求文档不全的公司,你可以自己编写需求文档,作为自己的参考红本书,有任何改动实时更新,并及时记到脑子里,这样的你,就像上战场打仗的将军,已经清楚敌人的排兵布阵,你怎么能不赢呢?

2、熟悉跟本系统有关的上下游系统业务

  有些系统会涉及到其他系统,虽然我们不需要测试,但是一些需求以及其他系统业务也是要掌握的,这样也可以给自己提供更广的测试思路。也用打仗来比喻的话,这就是需要知道整个国家之间的状态、彼此错综复杂的关系,才能纵横捭阖,在战场上给与一些意想不到的战术。

3、熟悉数据的交互

  熟悉后台与前台的数据交互,这样可以在你提问题的时候,更加有技术性,不仅仅是描述表面的。

三、掌控Deadline

  如果一个版本需求过多,那么开发的任务就多,测试人员要测试的点也就非常的多。这个时候,如果版本封板的时间都是由项目经理或者PM来定,那测试人员就会很被动。而通过测试自己评估需求需要测试的时间及优先级,就能给出一个合理的时间给项目经理或PM,而这个时间最终点就是Deadline。测试要在这个时间点前各种督促开发,根据优先级安排测试,这样可以掌控整个测试的节奏,不需要拼命的加班,也能高效率的完成工作。

四、测试技术

这一点估计才是大家真正想看的,也是对自己镀金很重要的部分,这决定你将处于什么位置。

1、懂得用jmeter、LoadRunner进行性能测试;

2、懂得搭建性能测试需要的环境,例如服务器、redis、memcache等等;

3、懂得一些抓包工具的使用,fidder、charles、Wireshark等等;

4、懂得一些基本命令(数据库、linux)的使用;

5、懂得一些自动化测试,会写一些基础脚本(java、python)进行接口自动化;

6、懂得如何编写性能测试报告并能够进行分析; 

7、懂得一些安全性能测试。

如果你能慢慢掌握以上四大点,基本你走到哪里都不愁高薪了。看看自己缺少哪点,再根据自己的实际情况去学习,祝愿大家都能学有所成!yes