https://drive.wps.cn/view/l/stbv5rz
第一课项目<软件>
一、 项目
a) 项目经理
b) 开发
c) 测试
d) 需求
e) 客户
f) 产品经理
需求人员
开发人员 测试人员
（开发经理） （测试经理）
公司的部门:产品部、开发部、测试部、运维部、运营部
说明：产品经理负责---产品走向，需求来源
开发经理—开发技术
项目经理—对重大问题决策、沟通、协调进度、支付
a) 需求来自客户
b) 客户需求称为原始需求
c) 客户的需求一般比较模糊、简单
d) 客户的需求，需要提交给产品经理，由产品经理整理成完善的《软件需求规格说明书》的文档。
第2课 软件需求规格说明书
软件需求规格说明书
开发 测试
干吗？
需求、开发、测试三方评审
形成一个标准，统一需求规格文档
开发 测试
根据需求文档编写 根据需求文档和项目设计计划编写测试计划
形成人员需要把需求文档
转化成开发人员自己看的
懂的文字 根据需求文档编写测试的用例
a) 概要设计文档 测试用例评审
b) 详细设计文档
编码(写程序) 程序
执行用例 BUG流程 测试报告 上线、发布
说明：
a) 测试工作在需求文档一出来的时候就开始了。
b) 需求评审是我们测试人员非常重要的工作。
第3课、如何对软件规格说明书进行评审
一般情况下，我们会以几个方面进行评审、测试：
1、 正确性，对照客户的原始需求，检查我们的软件需求功能是否描述正确。
2、 明确性，指的是软件需求规格里面不能有含糊其辞的词汇（例如、应该、也许等）。
3、 完整性，指的是有没有遗漏客户所描述的功能以及必要的信息。
4、 优先性，指的是那些功能比较重要，哪些功能比较次要，且要做一个标记。
5、 可修改性和可测性，是指需求功能的结构易于修改和调整且每一点都是可以验证的。
备注：80%的缺陷都是来自于前期的需求没有评审好，确认好。另外，需求的频繁变更也是造成BUG出现的主要原因。产品经理是把握需求、方向。
第4课、软件测试的概念
1、软件质量的定义：
- 符合客户的要求。
- 针对客户的满意度，如果客户满意则质量好，反之则不好。
2、软件测试的定义：
为了寻找软件中的错误而执行的软件的过程。
3、软件错误（BUG）：
我们在运行软件的过程中实际结果跟预期结果不符（软件规格）不符，这些问题都统称为BUG
4、8/2原则：
80%的错误是集中在20%模块里，经常出错误的模块，经修复后还是容易出错。
5、 从是否针对软件的内部结构和算法可分为白盒测试和黑盒测试。
白盒测试：主要针对软件内部结构和算法的测试（针对代码）
黑盒测试：不关注软件的内部结构和算法，只关注软件外部功能特点的测试（针对功能）
6、 从软件不同阶段可分为：单元测试、集成测试、系统测试、验收测试。
1) 单元测试：开发人员测试自己开发出来的单元模块，利用白盒测试 方法由程序员自己来做。
2) 集成测试：将软件的一些物件（或单元模块）集成在一起测试，主要对接口、路径、功能、性能进行测试，通常以白盒测试为主，黑盒测试为辅。（即由程序员自己为主，测试人员为辅）
3) 系统测试：测试软件是否符合需求规格，测试工作由独立的测试人员进行，主要采用黑盒测试。
4) 验收测试：与系统测试相似，但测试工作由客户进行，主要验收软件系统是否符合要求，通常采用黑盒测试方法。
备注：单元测试和集成测试主要由开发人员进行，从测试原理来分，分为白盒测试和黑盒测试，说白了白盒测试就是软件内部的代码测试，黑盒测试就是软件所表现的功能点的测试。
系统测试主要由测试人员进行（以QQ邮箱为例）
界面测试 功能测试 性能测试 兼容性测试 易用性测试 安全性测试
采用黑盒 采用黑盒 采用黑盒 采用黑盒 采用黑盒 采用黑盒
1、 QQ邮箱是一个项目
2、 测试人员要求对这个项目进行系统测试
3、 例如我们有5个测试人员都会做不同的测试，有的做功能，有的做性能，有的做安全性
说明：所有软件测试时一般都基于以上6个方法进行测试。
问：功能测试，系统测试、黑盒测试有什么关系。
答：功能测试是系统测试的一部分，系统测试包括功能测试。功能测试和系统测试都是以黑盒测试为主。
7、 回归测试：BUG经开发人员修复后，重新由测试人员进行验证。这个测试称为回归测试。
8、 功能测试：验证功能是否符合软件的功能要求。
9、 压力测试：（负载测试）测试软件的最大极限也称为极限测试。
10、性能测试：测试软件在不用情况下的性能，其中它的一个重要的指标就是系统的响应时间。
11、易用性测试：站在用户的角度评价软件好不好用，并提出意见。
12、兼容性测试：主要测试软件与操作系统、浏览器或其他软件（例如和杀毒软件） 的兼容，有时候也会涉及到硬件兼容。例如显示像素配置，网络配置。
13、Alpha测试：系统刚开发完后给用户测试一下（体验一下）一种先期的用户测试。
14、Boca测试：一种后期的用户测试，此时系统已经通过我们的内部测试，并即将要发行的时候，给客户看一下。
测试人员具备哪些素质：1、学习能力 2、沟通能力 3、团队精神，自我督促、观察力、技术能力的信心、怀疑精神 4、不怕重复性工作 5、热爱测试工作，创新。外交能力。
|
测试名称 |
测试方法 |
测试人员 |
测试依据 |
测试内容 |
|
单元测试 |
白盒测试 |
开发人员 |
软件需求规格说明书 |
代码 |
|
集成测试 |
白盒测试为主 黑盒测试为辅 |
开发人员为主 测试人员为辅 |
软件需求规格说明书 |
测试软件之间接口、路径、性能、功能 |
|
系统测试 |
黑盒测试 |
测试人员 |
需求规格文档；概要设计文档；详细设计文档 |
测试软件功能界面、性能、兼容性、易用、安全性 |
|
验收测试 |
黑盒测试 |
客户 |
需求规格文档 |
测试软件界面、功能、性能、兼容性、易用、安全性 |
第5课软件测试计划
1、 什么叫软件测试计划《定义》
它是一份描述软件测试的目标、范围、方法和时间的进度的文档。
2、 软件测试计划文档具体包括哪些内容：
a) 测试的策略：指的是总体的测试范围，系统测试进入的标准，测试工具的选择，测试文档的选择，测试方法的选择。
b) 测试的环境：软件平台环境和硬件平台环境。
c) 测试管理：测试时间和人员的安排，沟通、协作方式以及工作量的安排。
d) 测试风险：若没有按时间完成测试，所造成的风险和对应策略。
备注：系统进入的标准是指开发人员将版本提交给我们测试的时候，我们首先要对于软件版本做基本的功能测试，如果基本的测试没有问题方能进入系统测试，反之打回给开发人员修改，这里的基本测试称为冒烟测试。
例：我们系统有200个用例，我们从中抽出40个基本功能进行测试，称为冒烟测试。
问：你之前写过测试计划么？
答：有写过，不过我们的测试计划是自己负责模块工作量、时间的测试计划，但一般总体的测试计划中测试经理来写。
第6课测试用例
邮箱登录的例子：
用户名 （1~6英文）
密码 （1~6字母）
1、测试用例的属性
|
序号 |
测试标题 |
操作步骤 |
预期结果 |
实际结果 |
是否通过 |
备注 |
|
1 |
登录邮箱 |
1、 打开QQ邮箱 2、 输入正确的用户名和密码 3、 点击登陆，查看是否登陆成功 |
1、 邮箱界面可以打开 2、 用户登陆成功 |
|
|
|
|
2 |
登录邮箱 |
1、 打开QQ邮箱 2、 用户名为空密码为空 3、 点击登陆查看是否登陆成功 |
1、 登陆成功 2、 系统给出提示用户密码不能空 |
|
|
|
备注：严格来讲不操作步骤都应该有一不预期结果，操作步骤中具体使用了什么数据一定要写清楚，测试用例一般不包括前置条件等属性。一般情况下测试用例包括测试序号、测试标题、前置条件、操作步骤、预期结果、实际结果是否通过、备注等属性，每个公司的规范可能都不一样，测试人员、时间、测试项目，功能模块（很少用）
2、测试用例的作用：它作为测试的标准，指导测试人员进行测试工作，以发现问题，并提交BUG，最终提高软件质量。
3、好的测试用例应具备哪些特征？
a) 好的测试用例应该可以发现以往发现不了的错误，其测试点分的很细。
b) 好的测试用例没有多余的，冗余的用例。
c) 测试用例必须定义一个或多个预期结果。
第十课黑盒测试用例设计方法
1、 等价类划分法:就是把所有可能输入的数据，划分为若干区域，然后从每个区域中取有代表性的数据进行测试。
1—10 1 5 10
10-100 10 50 100
100-1000 101 500 1000
例：运行输入（1~10000） 1000-10000 1001 5000 10000
输入框
2、 等价类划分可分为有效等价、无效等价。
a) 有效等价：输入的数据符合程序的要求，也就是说符合软件需求规格说明书。
b) 无效等价：输入的数据对程序来说是无效的。也就是说，不符合软件需求规格说明书。
1、＜1 6、空格 11、空的
例：运行输入（1~10000） 2、＞10000 7、标点符号
输入框 3、英文字母 8、全角/半角
4、中文字符 9、负数
5、特殊字符 10、各种字符混合
备注：我们在测试任何一个功能点的时候，我们的硬件需求规格对每一个功能点都有详细的输入输出说明，也就是规格限制。如果没有限制，开发人员将无法开发程序，测试人员将无法设计用例，也就无法开展测试工作。
说明：测试用例是根据软件需求规格说明书来写的。
3、 边界值分析法：
取稍高于和稍低于边界值的一些数据，这种方法称为边界值分析法。
例：n它的边界值 n-1 n n+1
输入框 (1~10000)边界值为0 1 2 9999 10000 10001
4、 错误推测法：
根据自己以前的测试经验和直觉未判断程序中的错误
例：输入框 （1-1000）
比方说程序在处理一些超长字符，空格字符和边界值时容易出错，那么我们可以拿这些数据来试一试。
测试用例设计案例
用户名 （1-6位数字字符）
密码 （1-6位数字字符）
登陆按钮
|
有效等价 |
无效等价 |
边界值 |
错误推测 |
异常 |
|
1、1位英文字符用户 2、2位英文字符用户 3、3位英文字符用户 4、4位英文字符用户 5、5位英文字符用户 6、6位英文字符用户 |
1、空的 2、＞6位 3、数字 4、中文 5、空格 6、标点符号 7、全角/半角 8、特殊字符 9、混合字符 10、不存在的用户 11、大于写敏感正确的用户名错误的密码 |
|
超长字符 空格 复制、粘贴 |
网络中断、数据库中断、异常 |
场景法：
用户可能只给到一个场景或简单的业务流程或一段简单的文字需求描述，此时测试人员需要根据自己的业务流程或已有的场景和需求，充分发挥对用户实际业务场景的想象。
场景法举例：
比如：ATM取款机
这个时候我们需要根据业务流程充分发挥
实际业务场景的各种操作
插卡→输入密码→查阅→取款 → 业务流程
基本流：无任何差错，从程序开始直接执行到结束只经过最简单的路径。
备选流：指在特定条件下可能发生的过程。
注明：例如有时候面试官会让你写，请设计ATM测试用例
这很明显，我们要使用场景法进行用例设计，首先我们会想ATM机包括查询功能、取款、存款功能、转账功能，随后我们一一对这些功能进行用例设计就好，以上是一个类型的使用场景法进行用例设计的过程。
因果图判定表法：
我们输入的条件可能有多种，每一种条件之间的组合都可能形成一种新的结果，我们把其中的条件和结果通过图形的方式表现出来，最后通过判定表进行展示。
例：高考加分软件，加分的政策是：如果考生是少数名族。则加5分。如果考生是体育特长生，加5分。如果考生具备前两项加分条件，则加8分。
少数名族 少数名族
加分 体育特长生 加分
体育特长生 特殊照顾
判定表
|
需要测试的情况 |
情况1 |
情况2 |
情况3 |
情况4 |
情况5 |
|
少数名族 |
是 |
是 |
否 |
否 |
|
|
体育特长生 |
是 |
否 |
是 |
否 |
|
|
其他照顾 |
|
|
|
|
|
|
加5分 |
|
加5分 |
加5分 |
|
|
|
加8分 |
加8分 |
|
|
|
|
|
加10分其他优惠 |
|
|
|
|
|
|
需要测试的情况 |
情况1 |
情况2 |
情况3 |
情况4 |
情况5 |
情况6 |
~~7 |
~~8 |
|
少数名族 |
是 |
是 |
是 |
否 |
否 |
否 |
是 |
否 |
|
体育特长 |
|
是 |
是 |
否 |
是 |
否 |
否 |
否 |
|
奥赛生 |
|
是 |
否 |
是 |
是 |
是 |
否 |
否 |
|
加5分 |
|
|
|
|
加5分 |
加5分 |
加5分 |
|
|
加8分 |
|
加8分 |
加8分 |
加8分 |
|
|
|
|
|
加10分 |
加10分 |
|
|
|
|
|
|
|
正交表法
正交表法：是一种有效减少用例个数的设计方法。
1、 如何减少用例个数，我们需要根据实际的业务情景和组合特点，进行有效设计，必要时我们需要咨询开发的意见，最终的目的是我们需要选择一些典型的用例进行测试。
2、 如果我们把所有组合，组合在一起，我们的时间是不够的，人力也不够的，况且也没必要，当中会产生很多冗余的用例。一般的做法是测试一个条件时，我们会默认其他条件都是正确的。
正交表法举例：
论坛注册的例子，比方说我们注册论坛时，需要输入多个输入框的内容，如果我们把每个输入框组合起来（假设我们）的输入框有30个呢，那么这种组合的测试用例可能高达几千个，那么这种组合太多了，对于测试和开发都是不现实的，我们只能按上面说的一个条件。一个条件的测试然后有时间的话再找出少量的有代表性的组合测试即可。
但有一点大家要注意，正交表法的核心是：有效的减少用例个数，并选取一些有代表性的典型的组合进行测试。
总结：用例设计的完整度：
任何用例写完之后不是100%完美，一方面我们需要测试内部评审，以便更加完善。另一方面，我们设计出来的用例和开发出来的功能，不可能达到高度统一，也就是说，我们在测试软件的时候也存在修改用例的可能。
备注：六种黑盒用例设计方法都要能说出概念，并且能举例子出来。
第8课用例评审
一般情况下，从以下几个方面对我们的用例进行评审：
a) 测试用例是否完全针对需求规格说明书中列出的功能
b) 有没有冗余的用例
c) 是否每个步骤都清楚的描述了预期的结果。
d) 必须测试什么功能
e) 如果一些功能不测试会导致什么样的结果。
黑盒测试用例设计方法有哪些（包括每种方法的概念和举例）
1) 等价类划分法（可分为有效等价和无效等价）
2) 边界值分析法
3) 错误推测法
4) 因果图判定表法
5) 场景法
6) 正交表法
用例设计的案例
写信模块
收件人地址：＿＿＿＿＿＿＿＿＿（1-20个邮件地址）
标题：＿＿＿＿＿＿＿＿＿（0-100个字符）
附件：＿＿＿＿＿＿＿＿＿（可发送doc、txt、ppt、tpg四种格式的附件，单个附件发送容量不能超过2G，多个附件发送时，不能超过5G
异常最多发送4个附件）
收件人地址用例：
|
有效 |
无效 |
边界 |
错误推断 |
异常 |
|
1、1个邮件地址 2/20个邮件地址 |
1、 空的 2、 空格 3、 纯数字 4、 纯中文 5、 标点符号 6、 全角/半角 7、 大小写敏感 8、 大于20个邮件 9、 不存在的邮件 10、混合字符 11、错误的格式 12、正确的邮件加错误的格式 |
|
1、 超长字符 2、 超长邮件地址 3、 空格 4、 复制粘贴大量字符 |
1、 网络中断 2、 数据库异常 3、 邮件服务器异常 |
标题用例：
|
有效 |
无效 |
边界 |
错误判断 |
异常 |
|
1、 空的 2、 100个中文 3、 100个数字 4、 100个标点符号（含特殊字符） 5、 100个中英文混合（含字符） |
大于100个字符 |
1、 空的 2、 1个字符 3、 99个字符 4、 100个字符 5、 101个字符 |
1、 复制粘贴大量字符 2、 超长混合字符 3、 空格 |
1、 网络中断 2、 数据库异常 |
附件的用例
|
有效 |
无效 |
边界 |
错误推断 |
异常 |
|
1、单个doc附件 且附件小于2G 3、 单个txt附件且附件小于2G 4、 单个PPT附件且附件小于2G 5、 单个JPG附件且附件小于2G 6、 一个附件都不变 7、 两个附件且附件小于4G 8、 三个附件且附件小于5G 9、 四个附件且附件小于5G
|
1、 单个DOC小于2G 2、 单个TXT小于2G 3、 单个PPT小于2G 4、 单个JPG小于2G 5、 二个附件大于4G 6、 二个附件大于5G 7、 三个附件大于5G 8、 四个附件大于5G 9、 附件数为5个 10、其他常用的格式（例：JIF、EXE） 11、可以上传的格式加非法格式 12、损坏的文件格式 |
1、 空的 2、 单个附件为1G 3、 单个附件为2G 4、 单个附件为3G 5、 单个附件为4G 6、 单个附件为5G 7、 多个附件为6G 8、 3个附件一起发 9、 4个附件一起发 10、5个附件一起发 |
1、 超大附件 2、 超多附件 3、 特殊格式 |
1、 网络中断 2、 数据库异常 3、 带有病毒的附件 |
测试一个纸杯
分析：外观、功能、性能易用、安全
|
外观测试 |
功能测试 |
性能测试 |
易用性测试 |
安全性测试 |
|
1、 形状是否方便使用 2、 是否美观 3、 杯子外壁的图案是否合适 4、 需要光泽么 5、 高度、直径是否符合要求 6、 杯子的材质是否符合要求 |
1、 验证杯子是否能装水 2、 验证杯子灌注的容量正确 3、 验证杯子能装冰水 4、 验证杯子能装油、水之外的液体 5、 验证杯子能装固体、沙子等 |
1、 杯子使用多少次 2、 容易摔碎么 3、 抗挤压么 |
1、 杯子容易被洗干净么 2、 是否方便用户拿着 3、 容易烫手么 4、 度过滤茶叶的附加功能么 |
1、材质是否环保 |
购票场景：
a) 一张25元的车票
b) 一张30元的车票
c) 一张35元的车票
d) 两张25元的车票
e) 两张30元的车票
f) 两张35元的车票
g) 三张25元的车票
h) 三张30元的车票
i) 三张35元的车票
j) 买两张不同时间的车票
k) 买三张不同时间的车票
l) 入一张100元面额纸币
m) 买一张25元的车票看是否会找零75元
n) 操作出错，是否会有提示
安全性：
- 向使用界面泼水
- 雷雨、高压情况下是否有保护措施或提醒、报警
- 车票打印出来的油墨是否含有有害物质
- 取票时，查看是否有警戒线
- 查看是否有裸露的电线
- 系统无法操作时，是否有叫维修人员的按钮和电话
异常场景：
a、 数据库中断异常
b、 购票时中断
c、 投入破损的钞票
d、 投入非100的钞票。如：白纸、外币、银行卡
e、 打印时没墨水
f、 投入其他面额的钞票
g、 频繁的取消、返回
h、 没有打印纸
i、 连续快速多次投入100元钞票
题目6：三角形程序的测试用例
有一个程序，能判断用户输入的三个是否能构成一个三角形。如果能构成三角形，程序还能判断三角形的类型。例如：等腰、等边、直角三角形等。
分析：这是一个很经典的问题，很多软件测试的教材中都引用了这个例子，它也多次出现在笔试的试卷中。曾经参加过微软公司的内部培训，这道题也在其中，它重点考察的是等价类划分这个知识点。下面是几点提示。
a) 把关于三角形的数学知识都考虑到，例如：只有任意两边之和大于第三边才能构成三角形。例如:三角形的种类有普通三角形、等腰三角形、等边三角形、直角三角形、等腰直角三角形（锐角、直角、钝角三角形也是另一种分法）这些类型在测试中都要考虑到的。
b) 边长不要局限在正整数、小数、零、负数等都要考虑到
c) 不要局限在功能测试上，有的题给出了题中描述的程序界面测试、兼容性测试、性能测试等。即使没有给出程序界面，我们也可以列出这些测试题，尽可能的多想一些，考虑的周到一些，是我们测试人员应当做的事情。
功能 异常
1、 取款100元（卡内含有3000元） 网络中断
2、 取款2000元（卡内含有3000元） 数据库中断异常
3、 取款60元（卡内含有3000元） 插入银行卡后或取钱突然停电
4、 选择美元查询余额 插入非银行卡（白纸、购物卡）
5、 选择港币查询余额 ATM机没钱时，连续使用取款
6、 使用语言选择英文（外文） 输入错误密码（含小于6位数密码）
7、 插入银行卡之外的卡片（公交卡） 连续输入3次密码错误
8、 把银行卡的方向（前后上下）交替插入 取款一次超过3000元
9、 取款时查看是否有操作指引 当天取款超过20000元
10、向使用界面泼水 转账时输入错误账号
11、频繁取款 取消 转账一次超过银行限额
12、取300元，并打印凭条 没有墨水
13、验证对外转账功能 没有打印纸
14、验证卡内转账功能 取款时，取小于100的金额
15、验证手机号转账 一次取超过3000外币（港币、美元）
16、验证查询养老金功能 一天取超过20000外币（港币、美元）
17、验证退卡功能
18、验证其他账号功能
19、取款时，使用“其他金额”输入600
20、验证改密码的功能
21、点击修改密码输入两次不一样的密码
22、输入错误的密码
23、输入错误的密码然后更正
24、输入三次错误的密码
25、验证紧急按钮和应急电话
26、查看取款机是否有棱角
27、一次取款6000元。
28、在同一台取款机上，多次取款，金额总数达30000元
29、转账输入错误账号
30、转账金额为0.3元
31、取款时，查看是否有警戒线
32、查询人民币余额
三角形案例
对非法输入的检查
1、 有一边为非数值的字符
2、 有两边为非数值的字符
3、 有三边为非数值的字符
4、 有一边为0
5、 有两边为0
6、 有三边为0
7、 有一边为负值
8、 有两边为负值
9、 三边皆为负值
10、考虑一些可导致错误的符号。例如：“1”、“&”、“！”等等。
不能构成三角形的情况：
1、 两边之和等于第三边的情况a+b=c、a+c=b、b+c=a。
2、 两边之和小于等于第三边的情况a+b<c、a+c<b、b+c<a。
3、
能构成三角形的情况：
1、 验证对普通三角形的判断
2、 验证对直角三角形的判断。ab是直角边、bc是直角边、ac是直角边
验证等腰直角三角形的判断
a、 b为直角边且a=b。 b、c为直角边且b=c。 a、c为直角边且a=c。
b、
界面测试
1、 验证控件是否正确
2、 验证控件的摆放是否正确
3、 验证字体，颜色是否正确
4、 验证界面在缩放的时候变化是否正确。
易用性测试
a) 验证默认焦点是否正确
b) 验证焦点顺序是否符合读者习惯
c) 验证输入a、b、c完毕后，用户能否通过回车来直接触发判断功能。
兼容性测试
1) 验证这个软件是否能运行在预期支持的各种操作系统。‘
性能测试
a、 验证程序响应速度。
BUG的概念
作为测试人员，我们一个很重要的任务就是发现问题，并提交问题单。不管是建议性的问题，还是明显的错误，我们都可以当作BUG提出来，不管需求文档有没有提到。
1、 软件错误的等级
a) 致命错误（比方说：死机、系统奔溃等）
b) 严重错误（比方说：功能有没有实现或产生错误的结果）
c) 一般错误（不影响业务功能的一些错误，比如提示性的错误）
d) 轻微错误（字体太小、颜色等）
e) 改进性错误
2、 错误软件的优先级
a、 立即解决（致命、严重的要求立即解决）
b、 高优先级（一般的，严重的可以高优先级）
c、 正常排队（提示的，一般性的选择正常排队）
d、 低优先级（改进建议的要求低优先级）
3、 一个完整的BUG包括哪些内容？（非常重要）
- 错误编号
- 软件名称及版本号
- 错误的严重程度
- 错误的概要
- 报告人（发现人）
- 错误发现的时间
- 承办人（错误处理人）
- 错误的优先级
- 错误的状态
- 错误的具体推进
- 备注
- 测试环境的描述
- 附件（图片、日志）
注明：错误的具体描述是要把整个错误的发生，从开始到结果的每一个步骤都清晰的写出来。
错误的概要：主要指的是错误的中心思想不要太简单，也不要太复杂，一句话即可。
最后，有截图和日志的我们一定要附上去。
错误的状态：open（开放）
Closed(关闭)
Keep on（重新打开）
具体描述，把使用的数据写上去。
点击139邮箱，其他页面显示，唯收件箱页面为乱码。
错误编号：01
软件名称、版本：139邮箱v202
错误的严重程度：严重错误
错误的概要：打开139邮箱，点击登陆成功，其他页面都能正常显示，只有收件箱页面显示为乱码。
报告人： 曾爱莲
错误发现的时间：2013/09/23
错误处理人：江楚
错误的状态：开发
错误的优先级：立即解决
错误的具体描述：
a) 打开139邮箱，输入正确的用户名zengailian。密码为123456。点击登陆。
b) 显示登陆成功，点击写信箱、通讯录、草稿箱等所有页面都可以正常的显示出来，只有在点击收件箱页面的时候，显示的都是乱码。
备注：无
测试环境的描述：windows xp IE6
附件：上传图片、日志等。
日志的照片上传后，我自己可以看到，但我的好友看不到，我也没有做任何的限制。
编号：0
名称、版本：腾讯QQ、V1.01
错误的概要：在QQ空间内上传照片，上传成功后，没有任何设置，但我的好友看不到。
错误报告人：伍琳
错误发现时间：2013/09/23
错误经办人：江楚
错误的优先级：高优先级
错误的妆容：（OPEN）开发
错误的具体描述：
a) 登陆账号为：123456 密码为：123456 的QQ
b) 进入QQ空间，选择001gif 容量为1GB的图片
c) 上传0.001gif至我的空间相册
d) 提示上传成功
e) 没有设置任何的限制，但只有我自己可以看到，我的好友看不到。
备注： 无
错误测试环境的描述：软件环境：Windows XP IE6 360杀毒
上传图片、日志等
BUG流程
1、 系统测试BUG的走向
|
状态 |
开放 |
|
提交人 |
自己 |
|
处理人 |
测试经理 |
|
状态 |
已修复 |
|
提交人 |
开发人员 |
|
处理人 |
测试经理 |
|
状态 |
已分配 |
|
提交人 |
测试经理 |
|
处理人 |
开发人员 |
|
状态 |
已修复 |
|
提交人 |
测试经理 |
|
处理人 |
需求人员 |
|
状态 |
关闭 |
|
提交人 |
测试人员 |
|
处理人 |
测试人员 |
注明：系统测试期间，测试人员提交的BUG时候，需要测试经理或项目经理审核。
测试人员
拒绝
忽略 测试经理 拒绝
接受 忽略
挂起 开发人员
接受 关闭
重新打开 测试人员
注意：系统测试期间，测试人员一般要将BUG提交给测试经理或项目经理进行审核，然后由他们将BUG指派给相关的开发人员。如果他们拒绝、忽略、挂起BUG的时候，一定要写明原因。当测试人员和开发人员对BUG起争议的时候，如果一方认为此BUG不重要或认为此不算是个BUG，而另一方认为这是一个BUG，而且很重要。那么作为测试人员首先要检查自己的BUG是否写清楚了，是否属实。如果属实的话，开发人员还是不承认，那就提交给测试经理去解决，如果对方还是不认、不愿意修改。则由测试经理召开BUG的评审大会，由项目组的全体人员评审定夺。
集成测试期间，我们直接提交BUG给开发人员即可，不需要提交给测试经理审核。
性能测试
一、 定义：在一定负载的情况下，系统响应时间、吞吐量、服务器占用资源等特征是否满足软件的性能需求。
二、 性能测试的指标：
1、 系统响应时间
响应时间反应完成某个业务所需要的时间。
例如：从单击登陆按钮到登陆完成，返回登陆成功页面！需要耗1秒，那么说这个操作系统的响应时间就是1秒。
例：1千万人同时登陆QQ，系统响应时间不能超过30秒。
100万人同时登陆QQ，系统响应时间不能超过10秒。
10万人同时登陆QQ，系统响应时间不能超过5秒。
1万人同时登陆QQ，系统响应时间不能超过1秒。
2、 吞吐量
吞吐量反映单位时间内能够处理的事务数量。（每秒事务数：DPS）
例如：对于系统来说，1个用户登陆需要一秒，如果系统同时有10个用户登陆，且响应时间也是1秒钟，那么就称这个系统的吞吐量为每秒10个。
吞吐量也称TPS，每秒事务数。
3、 服务器资源占用
它是反映不同负载下，系统的CPU内存占用率，占用率越低说明系统越优秀。
注明：一般的性能指标都是由产品经理，项目中的领导来定义的，测试人员根据需求的定义进行测试即可。
常用的性能工具为load runner。简称 LR
系统测试报告
1、 你之前有写过测试报告么?
答：写过，不过我们写的是我们自己负责的模块测试报告，一般整个系统的测试报告都是由测试经理来写的。
2、 系统测试报告包括哪些内容？
a) 测试过程描述
b) 测试结果的分析
c) 系统存在风险
d) 测试结论与评论
测试报告其他的要素：例如编写目的，测试环境描述，参考资料等。每个公司的格式都不一样。
3、 测试过程的描述主要指：测试时间、方法、范围、协作方式、版本等。
4、 测试结果分析：
a、 指的是发现BUG总数量、致命性、严重性的以及一般性的问题的功能模块的分布情况。（致命、严重的用附在后面）
b、 指的是用例的通过率。通过多少，没通过多少，半通过多少。一般致命错误、严重错误都要放到报告中去。
c、 覆盖率80%
5、系统风险分析：
我们发现的问题单会对我们系统和模块造成什么样的风险、影响。
6、测试结论与评论：
通俗来说就是指能否上线、发布，如果上线会有什么后果。
执行行数
需求覆盖率= ×100%
总代码行数
1、完整的测试过程包括哪些阶段：
一般情况下，它包括需求评审、测试计划、测试用例的设计、测试用例的评审、测试环境的搭建，测试执行，提交问题单，回归测试，提交测试报告。
2、软件测试的目的：
其目的是发现软件中存在的缺陷，检验软件是否符合客户需求规格要求。
3、软件测试能否发现所有的BUG？
软件测试不能发现所有的BUG，因为测试时，测试资源是有限的，而且有些BUG只有长期作用和特定的环境才会出现。
4、软件测试工作在项目的什么阶段开始的?
软件测试应该尽早的开展，最好能在需求阶段就进行测试。
1、 软件测试人员在测试时应遵循什么原则？
软件测试应遵循82原则。
2、 如果让你来我们的测试团队，你如何更快的进入工作状态？
首先，我会尽快阅读相关的项目文档和帮助手册，技术文档等。以尽快熟悉业务功能。其次，我会多参加项目的各种会议，以熟悉项目的进度和后续的计划。
最后，我会尽快熟悉项目的测试用例，以及BUG库里面的BUG，以帮助自己尽快的进入工作状态。基本上，我会从以上几个方面，让自己更快的进入工作状态。
B/S与C/S两种软件架构的区别：
1、 C/S结构软件的特点:
a) 面对业务型的系统软件
b) 要在电脑上安装应用程序（例如客户端）
c) 简单的CLS架构只有两层，就是客户端认识数据库。
d) 其前台（客户端）能处理一般性的业务，能减轻后台的负担。
2、 C/S结构软件用例的特点:
a、 易用性测试
b、 安全性测试（尤其要注意SQL注入）（跨脚本点击）
c、 性能测试（大量用户并发）
d、 功能测试
e、 安装部署测试
3、 B/S结构软件的特点:
1) 面向的是互联网用户
2) 通过浏览器访问后台
3) B/S软件前台（浏览器）只能处理为浏览器查询，数据的输入等简单功能。大部分工作由后台服务器承担
4) 采用cookies储存用户信息。
5) 以网页（表单）形式展示界面。
4、 B/S结构软件的测试重点。
a) 功能测试
b) 链接测试
c) 兼容性测试
d) Cookies测试
e) 并发访问测试（性能测试）
f) 安全性测试（注意SQL注入）（跨站脚本点击）
注明：B/S结构软件是未来的趋势
B/S＞WEB测试（网页测试）
问题：
问：你之前有搭建过测试环境么？
答：有搭建过一些。
如果对方问这么搭建。可以说，一般情况下，我们会从以下几个方面搭建：
1、 有时候我们测试需要使用大批量的数据，比如说容量测试，压力测试等。我们就可能要准备一些大容量的文件或者数据库中插入大量数据。
2、 有时候我们测试的产品，支持多种操作系统，那么要我们在做兼容性测试时，就要准备好各种操作系统的计算机或使用虚拟计算机。
3、 有时候我们在安装程序包的时候，需要配置各种参数，那我们在测试之前就要按照开发的要求设置。
4、 有时候我们还需要用到网络，比方说IP设置、路由设置等。
一般情况下，我们都是按照以上几个步骤进行的。
一、Web兼容性测试主要包括以下三个方面：
1、 系统平台的测试
最常见的系统平台有window、Unix、Linux操作系统等，同一个应用可能在某些操作系统那可以正常运行，但在另外的操作系统不能运行。因此，Web系统平台需要在各种操作系统下对Web系统进行系统平台兼容性测试。
2、 浏览器测试
浏览器是Web客户端最核心的构件，不同厂商的浏览器又打java、html规格有不同的支持框架和层次结构风格在不同的浏览器中也有不同的显示，浏览器需要测试兼容性。
3、分辨率测试
页面版本在640×400/600×800或1024×768的分辨率模式下是否显示正常，字体太小或者太大，以至于无法浏览？文件和图片是否对齐？
4、操作系统与浏览器的兼容性如何配置？
|
浏览器 操作系统 |
IE6 |
IE7 |
IE8 |
IE9 |
IE10 |
火狐 |
遨游 |
360 |
|
XP |
√ |
√ |
|
|
|
√ |
√ |
√ |
|
Vista |
|
√ |
|
|
|
|
|
√ |
|
Win7 |
|
√ |
√ |
|
|
|
|
√ |
|
Win8 |
|
|
√ |
√ |
√ |
|
|
√ |
|
Linux |
× |
|
|
|
|
√ |
|
|
注意点：我们在选择浏览器版本的时候，一定要选择正式版本的浏览器进行测试，非正式版本浏览器本身可能存在不稳定性，有可能对我们测试结果造成影响。
问题单：3000个用例在8款浏览器上进行测试，时间不够怎么测试？
a) 根据已有的业务场景和组合特点进行有效设计，必要时咨询开发的意见，选取一些典型的用例。
b) 加班，尽量测相似的用例
c) 如果一些功能点未测时，我会和我们的测试经理沟通，建议延迟上线，因为这是对客户与产品不负责任的。
d) 根据市场的调查，来对8款浏览器和操作系统有效互配，减少一些冗余的用例。
Web测试的类型
引言
同样的产品，同样的项目，让不同的测试人员来测可能效果不一样，能发现的问题并不一样多……，这是为什么？怎么能尽可能多的发现产品的问题？需要掌握更多的测试方法，需要会做多种类型的测试，需要考虑的角度更多样化，更全面。下面我们总结一些常见的测试方法和类型。
Web系统测试与传统测试的区别
基于web的系统测试与传统的软件测试既有相同之处，也有不同的地方，对软件测试提出了新的挑战。基于web的系统测试不但需要检查和验证是否按照设计的要求运行，而且还要评价系统在不同用户浏览器端的显示是否合适。重要的是，还要从最终用户的角度进行安全性和可用性测试。
Web测试类型：
一、 功能测试
1、 链接测试
链接是web应用系统的一个主要特征，它是页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先，测试所有链接是否按指示的 那样确实链接到了该链接的页面；其次，测试所链接的页面是否存在；最后，保证web应用系统上孤立的页面，所谓孤立页面是指没有链接指向该页面，只有正确的URL地址才能访问。
链接测试可以自动进行，现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成，也就是说，在整个web应用系统的所有页面开发完成之后进行链接测试。
2、 表单测试
当用户给web应用系统管理员提交信息时，就需要使用表单操作，例如用户注册、登陆、信息提交等。在这种情况下，我们必须测试提交操作的完整性，以校验交给服务器的信息的正确性。例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。如果使用了默认值，还要检验默认值的正确性。如果 表单只能接受指定的某些值，则也要进行测试。例如：只能接受某些字符，测试时可以跳过这些字符，看系统是否会报错。
3、 cookies测试
cookies通常用来存储用户信息和用户在某应用系统的操作，当一个用户使用
cookies访问了某一个应用系统时，web服务器将发送关于用户的信息，把该信息以cookies的形式存储在客户端计算机上，这可用来创建动态和自定义页面或者存储登陆等信息。
如果web应用系统使用了cookies，就必须检查cookies是否正常工作。测试的内容可包括cookies是否起作用，是否按预定时间进行保存，刷新对cookies有什么影响等。
4、数据库测试
在web应用技术中，数据库起着重要的作用，数据库为web应用系统的管理、运行、查询和实现用户对数据库存储的请求等提供空间。在web应用中，最常用的数据库类型是关系型数据库，可以使用SQL对信息进行处理。
在使用了数据库的web应用系统中，一般情况下，可能发生两张错误，分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的，而输出错误主要由于网络速度或程序设计问题等引起的，针对这两种情况，可分别进行测试。
二、 可用性测试（易用性）
1、 导航测试
导航描述了用户在一个页面内操作的方式，在不同的用户接口控制之间，例如按钮、对话框、列表和窗口等；或在不同的链接页面之间。通过考虑下列问题，可以决定一个web应用系统是否易于导航；导航是否美观？web系统的主要部分是否可通过主页存取？web系统是否需要站点地图、搜索引擎或其他的导航帮助？
在一个页面上放太多的信息往往起到与预期相反的效果。Web应用系统的用户趋向于目的驱动，很快地扫描一个web应用系统，看是否有满足自己需要的信息，如果没有，就很快地离开。很少有用户愿意花时间去熟悉web应用系统的结构。因此，web应用系统导航要尽可能地准确。
导航的另一个重要方面是web应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道web应用系统是否还有内容，内容在什么地方。
Web应用系统的层次一旦决定，就要着手测试用户导航功能，让最终用户参与这种测试，效果将更加明显。
2、 图形测试
在web应用系统中，适当的图片和动画既能起到广告宣传作用，又能起到美化页面的功能。一个web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有：
a) 要确保图形有明确的用途，图片或动画不要胡乱地堆在一起，以免浪费传输时间。Web应用系统的图片尺寸要尽量地小，并且要能清楚地说明某件事情，一般都链接到某个具体的页面。
b) 验证所有页面字体的风格是否一致。
c) 背景颜色应该与字体颜色和前景颜色相搭配。
d) 图片的大小和质量也是一个很重要的因素，一般采用JPG和DIF压缩。
3、 内容测试
内容测试用来检验web应用系统提供信息的正确性、准确性和相关性。
信息的正确性是指信息可靠的还是误传的。例如，在商品价格列表中，错误的价格可能引起财政问题甚至导致法律纠纷；信息的准确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软件来进行，例如使用Microsoft word的拼音与语法检查功能；信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口，也就是一般web站点中的所谓相关文章列表。
4、 整体界面测试
整体界面是指整个web应用系统的页面结构设计，是给用户一个整体感。例如：当用户浏览web应用系统时是否感觉舒适，是否凭直觉就知道要找的信息在什么地方？整个web应用系统的设计风格是否一致？
对整体界面的测试过程，其实是一个对最终用户进行调查的过程。一般web应用系统采取在主页上做一个调查问卷的形式，得到最终用户的反馈信息。
对所有的可用性测试来说，都需要有外部人员（与web应用系统开发没有联系或联系很少的人员）参与，最好是最终用户的参与。
三、 兼容性测试
1、 平台测试
市面上有很多不同的操作系统类型，最常见的有windows、Unix、Macintosh、Linux、等。Web应用系统的最终用户究竟使用哪一种操作系统，取决于用户系统的配置。这样，就可能会发生兼容性问题，同一个应用可能在某些系统下能正常运行，但在另外的操作系统下可能会运行失败。
因此，在web系统发布之前，需要在各种操作系统下对web系统进行兼容性测试。
2、 浏览器测试
浏览器是web客户端最核心的构件，来自不同厂商的浏览器对java、JavaScript、ActiveX、plug-ins或不同的HTML规格有不同的支持。例如，ActiveX是Microsoft的产品，是为了Internet explorer而设计的，JavaScript是Netscape的产品，Java是Sun的产品等等。另外，框架和层次结构风格在不同的浏览器中也有不同的显示，甚至根本不显示。不同的浏览器对安全性和Java的设置也不一样。
测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中，测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。
四、性能测试
1、链接速度测试
用户连接到web应用系统的速度根据上网的变化而变化，他们或许是电话拨号，或是宽带上网。当下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这样。如果web系统响应时间太长（例如超过5秒钟），用户就会因没有耐心等待而离开。
另外，有些页面有超时的限制，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。
2、负载测试
负载测试应该安排在web系统发布以后，在实际额网络环境中进行测试。因为一个企业内部员工，特别是项目组人员总是有限的，而一个web系统能同时处理的请求数量将远远超出这个限度，所以，只有放在Internet上，接受负载测试，其效果才是正确可惜的。
进行压力测试是指实际破坏一个web应用系统，测试系统的反映。压力测试时测试系统的限制和故障恢复能力，也就是测试web引用系统会不会奔溃，在什么情况下会奔溃。黑客常常提供错误的数据负载，直到web应用系统奔溃，接着当系统重新启动时获取存取权。
压力测试的区域包括表单、登陆和其他信息传输页面等。
五、安全测试
Web应用系统的安全性测试区域主要有：
a) 现在的web应用系统基本采用先注册，后登陆的方式。因此，必须测试有效和无效的用户名和密码，要注意到是否大小写敏感，可以试多少次的限制，是否可以不登陆而直接浏览某个页面等。
b) Web应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内（例如15分钟）没有点击任何页面，是否需要重新登陆才能正常使用。
c) 为了保证web应用系统的安全性，日志文件是至关重要的。需要测试相关的信息是否写进了日志文件、是否可追踪。
d) 当使用了安全套接字时，还要测试加密是否正确，，检查信息的完整性。
e) 服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。所以，还要测试没有经过授权，就不能再服务器端放置和编辑脚本的问题。
六、接口测试
1，浏览器通常指 IE Fire Fox等，客户端使用的程序
2，每台连接互联网的机器都有一个唯一的IP地址，IP地址是由4个0到256的数组成的，比如：222.131.0.229，127.0.0.1，由于每台联网的机器的IP地址都是独立的，因此可以通过IP判断一台机器。
网站所在的服务器通常有一个固定的IP地址，而我们浏览者每次上网的IP地址通常都不一样，IP地址是由ISP分配的。
域名服务器(domain name server)的简称为DNS，它存储了域名与IP地址对应的列表。
3，浏览器得到域名指向的IP后，浏览器会把我们输入的域名转化为HTTP的服务请求，例如，输入 www.dreamdu.com，可以转化为 http://www.dreamdu.com/，通过这种方式浏览器向服务器发出了请求。
由于输入的是域名，因此服务器接收到请求后，会查找域名下的默认网页(通常为default.php或default.html)，如果直接输入http://www.dreamdu.com/default.php就直接查找这个页面。
4，返回的请求通常是一些文件，包括文字信息(.html .css .asp文件等)，图片，flash等(每个文件都要有一个唯一的网址，比如 http://www.dreamdu.com/xhtml/)
5，浏览器将这些信息组织成用户可以查看的网页
Sql注入
用户在输入界面输入特殊的字符串，提交到web服务器，web服务器的程序可能会使用sql拼接的方式，导致拼接后的sql语句出现恒真条件；把不该查询出来的数据查询出来了，把不该删除的数据删除了，把不该修改的数据修改了；
select * from wp_users where user_name=''
and password =' '
select * from wp_users where user_name='zhoup'
and password =' a' or '1'='1'
zhoup
a' or '1'='1
输入的时候，限制输入特殊字符 ‘ % ? 要转义
脚本注入
在用户输入的地方，输入了一段脚本字符，保存到了数据库中；
在用户查询数据的时候，浏览器会执行脚本；
防止，对< >进行转义； < < > >
一、iOS和android的区别
Android 是谷歌公司开发的开源、免费的移动操作系统；
iOS是苹果开发的不开源、不免费的移动操作系统；
目前流行的版本 Android : 4.4 5.0 6.0 7.0
iOS : 10、9 、8
android的主要厂商三星、华为、oppo、vivo、魅族、小米、一加
移动设备：电话(phone) 平板(pad) 电视(TV) 眼睛(class) 手表（watch） 汽车（car）
系统的区别
第一、Android 基于linux内核的，android apk 是 java 虚拟机机制实现的；
iOS的app 是基于沙盒机制实现的；
第二、两者后台制度不同：IOS中任何第三方程序都不能在后台运行（地图、音乐可以在后台运行，但是必须要通过苹果公司的审核）；安卓中任何程序都能在后台运行，直到没有内存才会关闭。
第三、iOS中用于UI指令权限最高，安卓中数据处理指令权限最高。
交互的区别
1、 应用程序的返回
2、 多任务之间的切换 ios 双击home android 左边的按键
Android 存储支持sd卡扩展，iOS不支持存储扩展
二、android 测试 adb 命令
adb（android debug bridge）通过pc向 android 设备发送命令；
在开发者模式中，打开USB调试
1、 adb devices 查看连接到pc的所有的手机设备
2、 adb logcat 查看手机上面的日志命令
3、 adb的默认端口5037
4、 adb shell 然后 输入top命令 可以查看手机的cpu 内存 io 的使用情况
5、 adb install buypiao.apk
6、 adb uninstall com.gewara 卸载应用
7、 adb shell ps 查看手机里面的进行信息
8、 adb push v.txt /sdcard 把当前目录的文件v.txt上传到手机的sdcard目录
9、 adb pull /sdcard/v.txt v.txt 把sdcard目录下的v.txt下载当前目录
10.adb shell pm list packages：列出所有的包名。
11、adb shell dumpsys package：列出所有的安装应用的信息
12、dumpsys
package com.android.XXX：查看某个包的具体信息
Android中使用的是UTF-8字符，而CMD默认字符集是ANSI，中文环境下即为GBK，代码页为936。查询当前代码页的方法为在CMD下直接输入“chcp”命令，并会返回“活动的代码页：936”字样
三、monkey 命令
adb shell monkey -p com.gewara -s 500 --pct-motion 20 –appswitch 30 -v 10000 > monkey_log.txt
触摸
移动
界面切换
四、移动测试功能点(web app之间的区别)
测试业务功能；基本流
|
移动场景 |
wifi／3G／4G／GPRS 飞行模式 （无网络、弱网络app奔溃） |
|
网络切换（视频、音频、下载） |
|
|
多任务场景 |
来电 |
|
填写地址，从其他应用获取 |
|
|
打开分享 |
|
|
启动其他应用 |
|
|
视频、音频 |
|
|
避免手势冲突 |
屏幕左侧边缘向右滑动 |
|
在屏幕上向左滑动 |
|
|
从屏幕顶部向下滑动 |
|
|
从屏幕底部向上滑动 |
|
|
按住屏幕向下滑动 |
|
|
在图片上面双击 |
|
|
两根手指的捏合与分开 |
|
|
摇晃设备 |
|
|
长按屏幕 |
|
|
关注用户体验 |
横竖屏测试 |
|
通知与消息 |
app在用户使用过程中是否有合适的通知和消息提示（智能家具） |
|
测试app安装时是否明确声明在用户使用需要的权限 |
|
|
app在后台运行是否有合适的通知和消息 |
|
|
app出错是否有通知和消息显示（网络异常 网速慢） |
|
|
支持多语言 |
每一种环境都需要测试 |
|
流量和电量测试 |
下载app 在Wi-Fi情况下 app最大2G |
|
测试app占用的存储空间 |
|
|
测试app消耗的电量 |
|
|
测试app 的流量 |
|
|
升级卸载测试 |
升级前的数据 升级后可以使用 |
|
app内部购买，升级后可以使用 |
|
|
删除app 是否有缓存文件 |
|
|
删除app 再次安装 是否有影响 自动登陆 |
|
|
测试app 的数据的清除 |
|
|
调用第三方 |
app 的输入和输入法的关联 |
|
app显示外部链接 |
|
|
分享功能 |
|
|
app 的请求是否加密 |
使用fiddler 来抓手机上面的包
面试：fiddler 名称 代理原理
设置过滤器
session 和 cookie 的本质
session (会话) 是web服务器保存在内存中的对象，
cookie 是否web服务器写在客户端的小数据；
浏览器第一次访问web服务器，web 服务器会生成一个sid（唯一的）；
Web服务器把sid作为cookie返回给浏览器；
浏览器第二次访问web服务器，浏览器就会把sid作为cookie上传给web服务器；
浏览器第三次访问web服务器，浏览器就会把sid作为cookie上传给web服务器；
浏览器和web服务器之间的多次对话，都是使用的相同的sid，这多次对话，称为会话；
Sesssion 有过期，web服务器默认的过期时间是30分钟；
|
第一次 |
请求 请求没有任何cookie信息 |
|
响应中包括set-cookie: 服务器告诉浏览器，把ECS_ID数据写入本地硬盘这个数据称为cookies数据 |
|
第二次 |
请求把第一次服务器写入本地硬盘的cookies数据重新传给服务器； Cookie： |
|
第二次响应 就写过的cookie信息不用再写入了 第二 |
第三次访问和第二次一样；
Session与cookie的区别
Session是保存在服务器端的数据
Cookie 是保存在本地硬盘的小数据；
Session的有效期一般是30分钟；
Cookie的有效期，是服务器写cookie数据的时候决定的，它可以设置的很长；
Session的数据安全性更高；
Cookie的数据的安全性差，可以被其他用户窃取；
Jmeter做接口测试
1、测试计划
2、增加一个线程组，1个线程代表要给用户；
3、增加要给http取样器（sampler），填写参数
3.1、增加一个断言，判断发送的请求业务对不对；
4、增加一个聚合报告，查看性能
4、增加要给查看结果树
5、点击运行，点击查看结果树
接口的4个要是
1、请求地址
2、请求方式 POST GET
3、请求参数
4、响应数据格式