要个男盆友扭蛋

求职之测试开发技能准备

负载测试

负载测试（Load testing），通过测试系统在资源超负荷情况下的表现，以发现设计上的错误或验证系统的负载能力。在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外，负载测试还要评估性能特征。例如，响应时间、事务处理速率和其他与时间相关的方面。目的是验证要检验的系统的能力最高能达到什么程度

软件测试类型按开发阶段划分

所以软件测试类型按开发阶段分为单元测试，集成测试，确认测试，系统测试，验收测试。

（1）单元测试：

单元测试又称为模块测试，是针对软件设计的最小单位程序模块进行正确性检查的测试工作，单元测试需要从程序内部结构出发设计测试用例，多个模块可以平行地独立进行单元测试。
（2）集成测试
又称为组装测试或联合测试，在单元测试的基础上，需要将所有模块按照概要设计说明书和详细设计说明书的要求进行组装。

（3）确认测试
确认测试的目标是验证软件的功能和性能以及其他特性是否与用户的要求一致。确认测试一般包括有效性测试和软件配置复查。一般有第三方测试机构进行。
（4）系统测试

软件作为计算机系统的一部分，与硬件、网络、外设、支撑软件、数据以及人员结合在一起，在实际或模拟环境下，对计算机系统进行测试，目的在于与系统需求比较，发现问题

（5）验收测试
以用户为主的测试，软件开发人员和质量保证人员参加，由用户设计测试用例。
不是对系统进行全覆盖测试，而是对核心业务流程进行测试。

网游的测试内容

a) 性能（负载测试，压力测试，连接速度【长时间连接不上会有什么反馈】）

i.客户端性能

ii.服务器端性能

1. 服务器

2. 数据库（一致性，输出结果是否准确）

iii. 网络

b)功能

i. 从运行完 game.exe 打开游戏界面后可进行的各种操作、玩法

ii. 界面

iii. 音乐

c) 自动化

i. 测试工作组织实施中需要的工具、软件、平台的开发

ii. 自动化的回归测试作用：游戏中基础的、变动不大的、出错率高的、可进行 checklist 重复测试的功能、性能等自动化是一个好方法

iii. 任何时候自动化都取代不了人脑，它只是将一些重复性的劳动从我们测试人员身上去掉，让我们有更多的时间做更有意义的事情，如果你觉得你做一件事情是重复的，且有规律可行的，不防考虑自动化

d)兼容性

i：不同内核的浏览器，不同版本的浏览器

ii：不同版本的Windows

e)可用性测试（寻找功能缺陷、不符合人机工程学的设计失误）

1：是否每一个用户交互设计都考虑到最终用户的理解能力，教育背景？

2：程序的输出是否有意义，没有侮辱性的词语，是否含糊不清？

3：用户能否懂得显示的错误诊断信息

4：用户界面是否保持概念的一致？内部的连贯性？语法的一致性？是否符合约定的使用习惯，语句，规律格式等。

5：需要高精确性和准确度的软件系统是否提供了足够有效的输入验证？（比如登陆银行系统，登陆需要输入密码账号等）

6：系统是不是包含太不不被选择的项？现在软件的开发趋势是只提供最常用功能的菜单项。

7：对于来自用户的输入是否能及时做出反应？若不能及时做出反应则需要显示一段信息告知用户需要等待。在选定某一选项时，该条目应该高亮等。

8：程序操作是否很容易上手？如常见密码输入时是否有效提示用户需要输入大小写敏感的文本。如果程序涉及到一连串的彩蛋和选项操作，能否轻松返回主界面？能否轻易返回上一级？

9：软件的设计是否有助于用户准确输入？比如填邮箱的地方但填的手机号时，有红框圈住并在旁提示错误信息。

10：用户能否在众多功能和菜单中来回切换而不发生意外？

11：软件的功能实现是否达到设计规格要求？

12：用户按照指南操作一次后，下次操作能否顺利进行？

互联网应用测试

互联网应用不同于传统的安装在计算机上的软件

软件：可能因为付费的缘故，只要质量达到平均水平就行，只要满足基本需求就会继续使用它。

互联网应用：如果应用系统质量一般，会导致客户转向竞争者的网站。

表示层测试：

1.内容测试：风格是否一致？布局是否混乱？拼写错误，语法错误？描述内容是否准确？

11. 可用性测试：交互设计是否考虑到最终用户的理解能力，教育背景？用来错误诊断的提示信息是否直白易懂？用户能否懂得输入的内容是否会被接收，能否帮助用户准确输入？不常用功能是否存在？对于用户输入能否及时反应？若不能及时反应是否有相应的提示信息告知用户等待？用户能否轻松返回主界面，能否轻松返回上一级？

在众多菜单功能中切换会不会发生意外？。。。。

2. web站点结构：检查各个链接是否有效，能否正确跳转？图片能否正确加载出来？

3. 用户环境测试：操作系统配置，web浏览器版本。如果应用系统高度依赖客户端的脚本处理，应特别关注浏览器的兼容问题。（因为每个浏览器都有不同的脚本引擎或虚拟机在客户计算机上运行脚本和代码）

业务层的测试：

1.性能：检查应用系统是否满足书面的性能规格说明（响应时间和吞吐率）

性能规格说明通常以响应时间或吞吐率来描述：比如页面需在X秒内载入，应用服务器每秒要完成Y个信用卡事务。

强度测试是是常用的性能测试方法：当系统接收的请求过多时，系统性能常会降低到不可用的状态，会导致对时间敏感的事务部件产生失效。使程序承受高负载或强度的检验。高强度是指在很短时间间隔内达到的 数据或操作的数量峰值。

web强度测试，在弄清用户群之后，设计强度测试，体现出可能访问站点的最大人群的情况。

移动应用强度测试，大量程序保持运行状态下，所测功能是否可正常响应。

2.数据有效性：发现从客户那里采集到的数据中的错误。

3.事务：发现事务处理过程中的错误，可能包括信用卡处理，电子邮件验证，即消费税计算等。

数据层的测试：

1. 响应时间：量化结构化查询语句SQL语句的消耗时间。

2. 数据完整性：验证数据存储适当而且正确。

数据确认测试试图发现数据收集中的错误，数据完整性测试尽力在数据存储的方式中发现问题。（数据类型和长度可能导致数据截断或失去精确性）。

3. 容错性和可恢复性：最大化平均故障间隔时间和最小化平均故障恢复时间。（设计出数据库无法恢复的场景出来）

4.安全性：系统数据是否机密（尤其是银行系统）

性能测试：（找到在特定负载和配置环境下程序的响应时间和吞吐量达不到目标说明书上的要求）

测试软件在系统中的运行性能，度量系统和预定目标的差距。

负载测试：（非常多用户）

指数据在超负荷环境中运行，程序是否能够承担。通过逐步增加系统负载，确定在满足性能指标的情况下， 系统所能承受的最大负载量。

强度测试：（大量用户，大量数据，极短时间和极少空间）

在系统资源特别低的情况下软件系统的运行情况，目的是 找到系统在哪里失效以及如何失效的地方

包括：短时间的极端负载测试，在过量用户下的负载测试，连续执行所有能做的操作。

压力测试：

通过逐步增加系统负载，确定在什么负载条件下系统处于失效状态，以此来 获得系统能提供的最大服务级别。

容量测试：（非常多数据）

确定系统可处理同时在线的最大用户数，使系统承受超额的数据容量来发现它是否能够正确处理。

证明程序不能处理目标文档中规定的数据容量。

容量测试通常和数据库有关。

容量关注的是大容量，不需要表现实际的使用。

而负载测试在大容量的情况下，还要关注性能指标。

举例：一个人背X斤

负载测试：200斤情况下能否坚持5分钟

压力测试：200,300,400....斤情况下，他的表现，什么时候失败，失败后什么表现，重新扛200斤是否正常。

容量测试：在坚持5分钟情况下，一次最多能扛多少斤。

测试一个app应用

能力测试：确保程序的目标功能实现。

容量测试：在许多人同时完这款游戏的时候，确保程序能处理目标文档中规定的数据容量。

强度测试：持续完这个游戏几个小时，程序是否出现异常。

在需要联网的游戏中，在基站切换频繁的地方，程序能否正常运行。

可用性测试：从用户的角度考虑。电源，流量，发热情况。

安全性测试：在程序登陆时抓包，看数据包是否加密。

性能测试：响应速度是否达标，每秒处理的数据是否达标。（响应时间和吞吐量）

存储测试：程序使用的内存和辅助容量是否超标

兼容性测试：不同版本，不同厂商，不同硬件配置。

安装测试：安装和卸载是否方便

可靠性测试：平均故障时间和故障恢复时间是否达标

安装卸载：确保用户可以正确的安装应用程序，可以完全卸载应用程序

网络基础设施：网络环境极端的情况下：信号差，信号不稳定（从数据流量与wifi频繁切换）程序能过正确响应。不同容量大小的SIM卡，不同运营商。。。。（测试网络中断时程序的表现）

来电和短息处理：能否在程序运行的情况下接电话和回短信；在处理完来电和短信后能否返回应用程序继续；能否在不终端程序的情况加取消来电和短信；能否在不退出游戏的情况下播带电话和发短信。

内存不足：确保程序在设备内存不足的情况下仍能正常工作。

按键：测试所有热键按照产品规格书实现，要与说明书上一致。

退出：确保程序能正常退出，确保机器在关机情况下应用程序的行为和设计规格说明书一致。

充电：请切换到充电模式可用；正在充电时正常工作；退出充电时不会发生异常。

电量：在电量不足时程序的表现行为。在手机突然断电的时候，应用程序的反应是否与说明书一致。

硬件资源：确保应用程序没有过多占用CPU和内存资源。

还有兼容性，可用性，给其他国家用户使用要本土化，还要足以符合他们国家的风土人情，风俗习惯。

可用性：符合标准规范，要直观，风格一致，放使用的功能按钮。

ui测试，可硬放到可用性里面：测试用户界面的功能模块的布局是否合理，整体风格是否一致和各个控件的放置位置是否符合客户使用习惯，更重要的是要符合操作便捷，导航简单易懂，界面中文字是否正确，命名是否统一，页面是否美观，文字、图片组合是否完美等等。图片是否正确加载，链接是否都有效。

比较看重实时性的游戏：要考虑网络延时

测试平均故障间隔时间和平均故障修复时间是否达到要求。

可用性测试？还是安全测试？

对于设置了vip账户的应用，要保证vip用户能访问到应该能访问的内容，而非vip用户不能访问到不应该访问的内容。

对于管理人员账户，与普通账户的访问权限应有明确区分。

一般测试流程

1 .需求：阅读需求，理解需求，与客户、开发、架构多方交流，深入了解需求。--testing team

2. 测试计划: 根据需求估算测试所需资源（人力、设备等）、所需时间、功能点划分、如何合理分配安排资源等。---testing leader or testing manager

3. 用例设计：根据测试计划、任务分配、功能点划分，设计合理的测试用例。---testing leader, senior tester

4. 执行测试：根据测试用例的详细步骤，执行测试用例。--every tester(主要是初级测试人员)

5. 执行结果记录和bug记录：对每个case记录测试的结果，有bug的在测试管理工具中编写bug记录。--every tester(主要是初级测试人员)

6. defect tracking：追踪leader分配给你追踪的bug.直到 bug fixed。--every tester

7. 测试报告：通过不断测试、追踪，直到被测软件达到测试需求要求，并没有重大bug.

8.用户体验、软件发布等……

测试结束准则

1.测试用例来源于因果图分析，边界值分析，错误猜测产生的所有测试用例都是不成功的。

2.预测出程序中错误的总数量，发现规定数量的bug后即结束该阶段的测试，进入下一阶段测试。

3.记录每个单位时间内发现的错误数量，通过检查统计曲线形状决定是继续测试该阶段，还是进行下一阶段测试。

负载测试，容量测试，压力测试，容量测试，性能测试

性能测试：（找到在特定负载和配置环境下程序的响应时间和吞吐量达不到目标说明书上的要求）

测试软件在系统中的运行性能，度量系统和预定目标的差距。

负载测试：（非常多用户）

指数据在超负荷环境中运行，程序是否能够承担。通过逐步增加系统负载，确定在满足性能指标的情况下， 系统所能承受的最大负载量。

强度测试：（大量用户，大量数据，极短时间和极少空间）

在系统资源特别低的情况下软件系统的运行情况，目的是 找到系统在哪里失效以及如何失效的地方

包括：短时间的极端负载测试，在过量用户下的负载测试，连续执行所有能做的操作。

压力测试：

通过逐步增加系统负载，确定在什么负载条件下系统处于失效状态，以此来 获得系统能提供的最大服务级别。

容量测试：（非常多数据）

确定系统可处理同时在线的最大用户数，使系统承受超额的数据容量来发现它是否能够正确处理。

证明程序不能处理目标文档中规定的数据容量。

容量测试通常和数据库有关。

容量关注的是大容量，不需要表现实际的使用。

而负载测试在大容量的情况下，还要关注性能指标。

举例：一个人背X斤

负载测试：200斤情况下能否坚持5分钟

压力测试：200,300,400....斤情况下，他的表现，什么时候失败，失败后什么表现，重新扛200斤是否正常。

容量测试：在坚持5分钟情况下，一次最多能扛多少斤。

对测试的了解

软件测试种类：
手工测试、自动化测试、静态测试

软件测试方法
黑盒测试、白盒测试、灰盒测试

软件测试类型
功能测试、性能测试、可靠性测试、安全测试、配置测试、GUI测试、备份测试、文档测试、在线帮助测试、易用性测试等等

软件测试阶段

单元测试、集成测试、系统测试、Alpha测试、Beta测试、验收测试还有回归测试

模块测试：发现程序模块与其 接口规格说明不一样的地方。

功能测试：证明程序未能符合其 外部规格说明的地方。

系统测试：证明软件产品与其 初始目标（用户需求）不一样的地方。

系统测试必须依赖于一组书面的，可度量的目标。

设计功能和界面测试用例

文本框测试：

1.正常字母和数字

2.输入超长字符

3.输入默认值，空白，空格

4.若只允许输入字母，则尝试输入数字

5.利用赋值粘贴等操作强制输入程序不允许的输入数据

6.输入特殊字符集

7.输入不符合格式的数据

命令按钮测试：

1.点击按钮能正确响应操作

2.对非法输入或操作给出足够的提示说明

3. 对于可能造成数据无法恢复的操作必须给出确认信息，给用户放弃选择的机会。

单选按钮测试：

1.一组单选按钮不能同时选择，只能选中一个。

2.对于选好的内容，要把对应的信息准确填写到数据库对应的位置中。

3.在默认状态下，必须有一个被选择，不能同时为空

滚动条控件的测试：

1.滚动条长度根据显示信息的长度或宽度及时变换。

2.拖动，点击滚动条

3.滚动条的上下按钮

判定表

判定表通常由四个部分组成：

条件桩：列出问题的所有条件

动作桩：解出问题规定可能采取的操作

条件项：列出针对它左列条件的取值

动作项：列出在条件项的各种取值情况下应该采取的动作。

		1	2	3	4
条件	觉得疲倦？	Y	Y	N	N
条件	感兴趣吗？	N	Y	Y	N
动作	重读
	继续			√
	跳下一章				√
	休息	√	√

电梯测试

功能测试：上下功能，开关门功能，各个按钮，紧急通话功能，电梯厢内的灯光,指示灯（正常显示楼层和运行方向），当楼层到达时，按钮灯光是否自动消除，

性能测试：电梯的调度算法，用户等待时间，平均等待时间，上下的速度，到店量，电梯的反应时间（上下，开关门）

压力测试：超载，一直处于上下的状态

安全测试：关门时出现障碍物时，停电，来电

可用性测试：考虑不同身高的用户，是否存在人多时身体误按键的情况，是否考虑过盲人，按键图标是否友好（在紧急情况下开门关门键是否容易按错），是否连按2次取消楼层选择。

兼容性测试：考虑不同国家电压

本地化/国际化测试：使用说明书上的语言

可维护性：电梯坏了如何去修。

稳定性：平均故障发生间隔时间是否达标

测试常见面试题

1、一名优秀的测试工程师需要哪些素质;

　　2、说说你常用的定位bug的方法，都是用刀哪些工具。比如程序崩溃，请描述常用的步骤。

　　3、你都使用过哪些测试工具?他们各有什么优缺点?

　　4、谈谈你对自动化测试的看法。

　　5、做好测试用例设计工作关键的是什么?

　　白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果. 黑盒测试用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试，以最少的用例在合理的时间内发现最多的问题

6.、你所熟悉的测试类型有哪些?试着分析这些不同的测试类型的区别和联系?

　　测试类型有：功能测试，性能测试，界面测试。

　　功能测试在测试工作中占的比例最大，功能测试也叫黑盒测试。是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时，需要测试软件产品的功能，不需测试软件产品的内部结构和处理过程。采用黑盒技术设计测试用例的方法有：等价类划分、边界值分析、错误推测、因果图和综合策略。

　　性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。

　　界面测试，界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。

　　区别在于，功能测试关注产品的所有功能上，要考虑到每个细节功能，每个可能存在的功能问题。性能测试主要关注于产品整体的多用户并发下的稳定性和健壮性。界面测试更关注于用户体验上，用户使用该产品的时候是否易用，是否易懂，是否规范(快捷键之类的)，是否美观(能否吸引用户的注意力)，是否安全(尽量在前台避免用户无意输入无效的数据，当然考虑到体验性，不能太粗鲁的弹出警告)?做某个性能测试的时候，首先它可能是个功能点，首先要保证它的功能是没问题的，然后再考虑该功能点的性能测试。

　　(接口测试也叫业务流程测试(包括功能模块之间、模块与模块之间、子系统之间)如果某些数据的主键是由数据库本身而实现的，可以不用删除，如果有些主从表是由程序员写的代码而实现，则要进行数据完整性的测试。

　　软件测试主要从以下16种类型进行测试：

　　一：功能测试(10个方面)

　　菜单、工具栏、快捷键、下拉框、按钮、单选按钮、复选按钮、切换、链接、触发键

　　二：界面测试

　　登陆界面、总界面、输入界面(增、删、改、查)、处理界面、输出界面、报表界面、提示界面

　　三：容错测试

　　数据长度、数据类型、非法此操作

　　四：接口测试

　　接口测试也叫业务流程测试(包括功能模块之间、模块与模块之间、子系统之间)

　　内部接口：例如：导入、导出(通俗的讲是接口就是调用)

　　外部接口：

　　五：性能测试(TPS吞吐量、响应速度、cpu占用率、内存占用率)

　　平均吞吐量：单位时间内处理事务的个数

　　平均响应速度：做一个事务处理所用时间

　　例如：界面操作效率测试;报表输出及查询效率测试

　　4、测试类型有哪些?

　　答：黑盒测试、白盒测试、单元测试、集成测试、功能测试、系统测试、负载测试、性能测试、兼容测试、可用性测试、安装|卸载测试、恢复测试、安全测试、比较测试、Alpha测试、Beta测试、端到端测试、健全测试、衰竭测试、接受测试、累积综合测试

　　5、黑盒测试和白盒测试的定义与区别?测试分哪几个阶段?这几个阶段之间的区别和联系?

　　答：黑盒测试：不关心软件内部结构，只关心输入输出，主要测试依据是需求文档;

　　白盒测试：关注软件的内部结构和程序的设计实现，主要测试依据是设计文档;

　　区别：

　　白盒测试只考虑测试软件产品，他不保证完整的需求规格是否被满足;

　　黑盒测试只考虑测试需求规格，它不保证实现的所有部分是否被测试到;

　　黑盒测试会发现遗漏的缺陷，指出规格的哪些部分没有被完成;

　　白盒测试会发现代理方面缺陷，指出哪些实现部分是错误的。

　　测试分：单元测试、集成测试、系统测试、验收测试。

　　单元测试：一般由开发小组采用白盒方式来测试，主要测试单元是否符合详细设计规格说明书的要求。

　　集成测试：界于单元测试和系统测试之间，起到“桥梁作用”，一般由测试小组或开发小组采用白盒+黑盒的方式来测试，主要测试模块接口及集成后的整体功能，验证与概要设计规格说明书的符合度。

　　系统测试：一般由独立测试小组采用黑盒方式来测试，主要测试系统是否符合需求规格说明书的要求。

　　验收测试：与系统测试非常相似，主要区别是测试人员不同，验收测试由用户代表或最终用户执行。

　　6、测试用例设计方法有哪些?

　　黑盒测试的测试用例设计方法有：等价类划分、边界值划分、因果图分析和错误猜测;

　　白盒测试的测试用例设计方法有：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、多重条件覆盖

　　7、测试用例设计方法有哪些?

　　黑盒测试的测试用例设计方法有：等价类划分、边界值划分、因果图分析和错误猜测;

　　白盒测试的测试用例设计方法有：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、多重条件覆盖。

　　8、性能测试的流程?

　　1.测试需求分析2.测试计划制定与评审3.测试用例设计与开发4.测试执行与监控5.分析测试结果6.编写性能测试报告7.测试经验总结

　　9、a测试,B测试定义?

　　a测试是软件开发公司组织内部人员，模拟各类用户，对即将上市的软件产品进行测试，试图发现错误并修复的过程。

　　β测试是由软件的多个用户在实际使用环境中进行的测试，这些用户返回有关错误信息给开发者。

　　10、测试用例要素?

　　用例编号、测试名称、重要级别、前置条件、测试输入、操作步骤、预期结果

　　11、压力测试与负载测试?

　　负载测试：通常运行时间比较短，在系统上逐渐加压，直到性能指标达到饱和状态(比如相应时间超出预期要求、系统资源占用率居高不下等)，从而验证系统预期的性能目标、相应时间等。

　　压力测试：长时间运行，逐渐增加超负荷(并发、循环、多用户等)，直到系统产生异常以及对异常的处理能力，从而验证系统可靠性、找到系统的瓶颈。 **微软压力测试的经验值为72小时。**

　　12、什么是回归测试?

　　回归测试：缺陷修正后，执行符合一定条件的测试用例来确保缺陷的修正没有在软件中引入新的缺陷,这些缺陷可能存在于被测试的软件模块中，也可能在与之相关或不相关的其他软件模块中。当软件发生变更或者使用软件的环境发生变化时，需要进行回归测试

　　13、简述bug的生命周期?

　　1，有效地记录BUG

　　2，使用BUG模板

　　3，评价BUG优先级和严重性

　　4， BUG的生命

　　5，维护BUG数据库

　　14、缺陷记录应包含的内容?

　　缺陷标识、缺陷类型、缺陷严重程度、缺陷产生可能性、缺陷优先级、缺陷状态、缺陷起源、缺陷来源、缺陷原因;

软件安全测试

程序，网络，数据库安全性测试

用户程序安全的测试：

1.明确区分系统中不同用户权限

2.系统不会因为用户权限的改变造成混乱

3.用户登录密码是否可见，可复制

4.系统中会不会出现用户冲突？（一个账号一次只能允许一个人在线）

5.能否经过绝对途径登陆系统（即直接拷贝用户登陆后的链接直接进入系统）

6.用户退出系统后，能否通过后退键而不容再次输入密码而进入系统中

系统网络安全的测试：

1.测试采取的防护措施是否都配置好，有关系统的补丁是否打上（防火墙，入侵检测系统）

2.采用成熟的网络漏洞检查工具检查系统相关漏洞（IBM security AppScan ,Nmap）

3.模拟非授权攻击，查看防护系统是否坚固

4.采用各种木马检查工具检查系统木马情况

5.采用各种防外挂工具检查系统各组程序的外挂漏洞。

6.模仿恶意攻击者进行尝试sql注入，跨站脚本，跨站伪造请求等攻击

数据库安全问题：

1.系统数据是否机密（尤其是银行系统）

2.系统数据的完整性，可管理性，独立性

3.系统数据可备份和恢复能力（数据备份是否完整，可否恢复，恢复是否可以完整）

黑客入侵的普遍手段

1.信息收集

whois信息：注册人，电话，邮箱，DNS，地址

googleheck：敏感目录，敏感文件，更多信息收集

服务器IP：Nmap扫描，端口对应的服务

收集操作系统、服务器，编程语言，数据库，组件等各类信息

2.漏洞挖掘

探测web应用是否使用了开源系统：wordpress,discuz

尝试xss,csrf，sql注入，权限绕过，上传可执行脚本。。。

有无验证码--暴力破解

3.漏洞利用

目的：要达到扫描效果？

根据漏洞选择合适的攻击载荷

开始漏洞攻击，触发漏洞，运行攻击载荷，获取相应权限

4.权限提升

一般是通过运行攻击载荷提升权限（在系统上新建一个特权账户）

如果不嫩运行攻击载荷，则根据收集到的资料开始密码猜解

5.植入后门

隐蔽性，定期检查并更新，保持周期性，免杀

6.日志清理

为了更好的伪装

常用的渗透测试工具

常用密码/网络破解工具：John The Ripper

网络扫描工具：Nmap

嗅探工具：wireshark ，ettercap

无线测试工具：Aircrack-ng

web应用/网站专业扫描工具：burp suite,IBM security AppScan

安全测试 vs 渗透测试

渗透测试是模仿攻击者的技术和方法，挫败目标系统的安全防护措施，获取访问控制权限，并发现具备业务影响后果安全隐含的一种安全测试与评估方法。

安全测试告诉系统可能会来自哪个方面的威胁，正在遭受哪些威胁，以及系统以及可以抵御什么样的威胁。

渗透测试是从单点上找到利用途径。

安全测试手下你会对系统做系统分析：架构，软件体系，程序部署等，然后再对系统做安全性分析。

如果想要你的程序是安全的，请记住如下原则：

　　● 不要信任用户的输入信息!

　　● 验证所有来自非信任源的输入信息，是使用白名单，不是黑名单。

　　● 从一开始就要策划安全。安全并不是可以在最后来做的。

　　● 保持简单。复杂性会增加安全漏洞的可能性。

　　● 最低限度保持你程序的攻击面(attack surface)。

　　● 确保程序有“自动防故障装置”(Fail-safe)

　　● 采用深度防御(defence in depth)

　　● 坚持最小特权原则(least privilege)

　　● 采用威胁建模(threat modelling)(Web程序更应如此)

　　● 权限分离(Compartmentalize)

　　● 没有不透风的墙，在代码中隐藏秘密都无法长久。

　　● Don’t write your own crypto / 不要自己编写一种加密方法

　　● 采用加密(crypto)，并不意味着你就安全了(攻击者会寻找弱点)

　　● 注意 缓冲区溢出，并了解如何防范

常见的软件开发模型

1.瀑布模型

1.必须等前一阶段的工作完成之后，才能开始后一阶段的工作；

2.前一阶段的输出文档就是后一阶段的输入文档，因此，只有前一阶段的输出文档正确，后一阶段的工作才能获得正确的结果。

2.快速原型模型

所谓快速原型是快速建立起来的可以在计算机上运行的程序，它所能完成的功能往往是最终产品能完成的功能的一个子集。快速原型的本质是“快速”，开发人员应该尽可能快地建造出原型系统，以加速软件开发过程，节约软件开发成本。原型的用作是获知用户的真正需求，一旦需求确定了，原型系统将被抛弃。

3.增量模型

增量模型也称为渐增模型，使用增量模型开发软件时，把软件产品作为一系列的增量构件来设计、编码、集成和测试。每个构件由多个相互作用的模块构成，并且能够完成特定的功能。使用增量模型时，第一个增量构件往往实现软件的基本需求，提供最核心的功能。

4.螺旋模型

螺旋模型的基本思想就是，使用原型及其他方法来尽量降低风险。理解这种模型的一个简便方法，是把它看作每个阶段之前都增加了风险分析过程的快速原型模型。

螺旋模型主要适用于内部开发的大规模软件项目。如果进行风险分析的费用接近整个项目的经费预算，则风险分析是不可行的。事实上项目越大，风险也越大，因此进行风险分析的必要性也越大。此外只有内部开发的项目，才能在风险过大时方便中止项目。

5.喷泉模型

喷泉模型对软件复用和生存周期中多项开发活动的集成提供了支持，以面向对象的软件开发方法为基础，它适合面向对象的开发方法。它克服了瀑布模型不支持软件重用和多项开发活动集成的局限性。喷泉模型使开发过程具有迭代性和无间隙性。系统某个部分常常重复工作多次，相关功能在每次迭代中随之加入演化的系统。无间隙是指在分析、设计和实现等开发活动之间不存在明显的边界。

功能测试（黑盒测试）详解

黑盒测试试图发下以下问题：

1. 功能错误或者功能遗漏

2.界面错误

3.数据结构或外部数据库访问错误

4.性能错误

5.初始化和终止错误。

黑盒测试方法：

·等价类划分方法

　·边界值分析方法

　·错误推测方法

　·因果图方法

　·判定表驱动分析方法

　·正交实验设计方法

　·功能图分析方法

等价类划分

等价类:某个输入域的子集合，在该集合内，各个输入数据对于揭露程序中的错误是等效的。

把全部输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件，就可以用少量代表性的测试数据，取得较好的测试结果。

确定等价类的原则

①在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类.

②在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下,可确立一个有效等价类和一个无效等价类.

③在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类.

④在规定了输入数据的一组值（假定n个）,并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类.

⑤在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）.

⑥在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类.

《软件测试》读书笔记 part1

测试的目的是尽可能早的找出软件缺陷，并确保其得以修复。

1.大爆炸模式

计划，进度安排，正规开发过程几乎没有，所有精力都放在开发软件和编写代码上。

几乎没什么测试

2.边写边改模式

适合意在快速制作而且用完就扔的小项目

开头几乎没有计划和文档编制。漫长的来回编码、测试和修改缺陷的过程。

3.瀑布模式

构思——>分析——> 设计——> 开发——> 测试——> 最终产品

强调产品的定义。

无法回溯。一旦净入摸个步骤，就要完成该步骤的任务，然后才能向下继续。

每一步都是跟着上一步的独立、离散的过程。

4.螺旋模式

一开始不必详细定义所有细节。

每次循环包括6个步骤：

1>确定目标、可选方案和限制条件。

2>明确并化解风险。

3>评估可选方案。

4>当前节点开发和测试。

5>计划下一阶段。

6>确定进入下一阶段的方法。

测试人员喜欢螺旋模式的原因：很早就参与开发过程，有机会尽早发现问题，为项目节省时间和金钱。

质量：满足客户要求

测试软件的两种基本方法：

1.通过性测试：确认软件至少能做什么

2.失效性测试：破坏软件而设计和执行测试用例

等价类划分

一个等价类划分是指测试相同目标或者暴露相同软件缺陷的一组测试用例。

数据测试

对数据进行软件测试，就是在检查用户输入的信息、返回的结果以及中间计算结果是否正确。

根据一些关键的原则进行等价类划分，以合理减少测试用例： 边界条件，次边界条件，空值和无效数据。

边界条件：软件运行在计划操作界限的边界的情况。 测试临近边界的有效数据，测试最后一个可能有效的数据，测试岗超过边界的无效数据。

缓冲区溢出是由边界条件缺陷引起的。

次边界条件：2的幂，ASCII表

默认、空白、空值、零值和无：一定考虑这些条件的等价类划分。

非法、错误、不正确和垃圾数据：考虑用户千奇百怪的使用方法。

状态测试

软件状态是指软件当前所处的条件或者模式。

必须测试程序的状态及其转换。

1>建立状态转换图：软件可能进入的每一种独立状态；从一种状态转入另一种状态所需的输入和条件；进入或者退出某种状态时的设置条件及输出结果。

2>测试用例需要保证：每种状态至少访问一次；测试最常见和普通的状态转换；测试状态之间最不常用的分支；测试所有错误状态及其返回值；测试随机状态转换。

失败状态测试：

竞争条件：类似交叉事件测试（电话or短信）处理随时被中断的情况。

重复：不断执行同样的操作。不停启动、关闭程序、还有反复读写数据或者反复选择同一个操作。-----》主要是 检查是否存在内存泄漏。

压迫：使软件在不够理想的条件下运行----》内存下，磁盘空间少，CPU速度慢等情况下运行。-----》 观察软件对外部资源的要求和依赖的程度。类似边界条件测试：尽可能限制软件的必要条件。

重负：尽量提供条件任其发挥，让软件处理尽可能大数据文件。 最大限度的发掘软件的能力，让它不堪重负。（时间也是一种重负测试，检查能否长期稳定工作）。

其他黑盒测试方法：

1.设法像笨拙的用户那样想问题。

2.在已经找到缺点的地方再找找

3.像黑客一样考虑问题

4.凭借经验、直觉和预感

静态白盒测试：

在不执行软件的条件下有条理的仔细审查软件设计、体系结构和代码，从而找出软件缺陷的过程。也称为结构化分析。

静态百合测试的目的：尽早发现软件缺陷，发现动态黑盒测试难以发现或隔离的软件缺陷。

正式审查：

1.确定问题：找出软件的问题，出错的和遗漏的。针对代码而不是针对个人。

2.遵守规则：参与者了解自己的角色，目标是什么

3.准备：积极

4.编写报告

编码标准和规范：

1.可靠性

2.可读性/维护性：易于阅读、理解和维护

3.移植性：不同硬件、不同编译器

动态白盒测试

利用查看代码功能（做什么）和实现方式（怎么做）得到的信息来确定哪些需要测试，哪些不要测试，如何开展测试。

动态白盒测试包括4个部分：

1.直接测试底层函数，过程，子程序和库。（单元测试的那种感觉）

2.类似黑盒测试，但是测试案例是根据内部结构得到。

3.将测试结果与预期结果比对，强制软件以正常测试难以实现的方式运行。

4.实时根据反馈，调整测试，去掉重复的，加入新的，

分段测试：

单元测试：对程序中的单个子程序、子程序或过程进行测试的过程。将注意力放在构成程序的较小模块的测试上。

集成测试：模块是组合进行集成测试

系统测试：加入越来越多的软件分段，直至整个产品，至少是产品的主要部分。

非增量测试（大爆炸测试）：先独立测试完每个模块，然后再将这些模块组装成完整的程序。

增量测试（集成测试）：先将下一步要测试的模块组装到测试完成的模块集合中，然后再进行测试。分为自底向上和自顶向下。

测试驱动模块：用来调用正在测试的模块。

桩模块：被测试模块的输入来源于某个模块，编写一个桩模块来模拟被调用的模块，给被测试模块提供数据输入。

在白盒测试之前，一定要根据说明书建立黑盒测试用例，这样可以真正测试模块的功能和作用，否则会偏向于以模块工作方式建立测试用例。

数据覆盖

数据流：

在软件中完全跟踪一批数据。（可用于单元测试和集成测试模块）

观察变量在程序能运行时的数据，获得变量开始和结束的值，还有运行期间检查变量的中间值，以此决定更改一些测试用例，保证扁郎取得具有风险的中间值。

次边界：

公式和等式：

检查是否出现除0这样的操作。

错误强制：

在合理的情况下，强制改变变量的值，检查是否会触发错误。

代码覆盖

测试程序的状态及流程。

设法进入和退出每一个模块，执行每一行代码，进入软件每一条逻辑和决策分支。

代码覆盖率的作用：

1.测试用例没有覆盖软件的哪些部分

2.哪些测试用例是多余的

3.为了使覆盖率更好，需要建立什么新的测试用例。

语句覆盖

保证每条语句至少执行一次。不等于走遍了软件的所有路径。

判定覆盖

覆盖软件中的多有路径。

条件覆盖

将分支语句的条件考虑在内。

静态黑盒测试：检查产品说明书，在软件编写前找出问题。

动态黑盒测试：不了解软件如何工作的情况下进行测试。

静态白盒测试：代码审查，检查代码细节。

动态白盒测试：基于对软件工作方式的了解，根据获得的信息，编写测试案例测试。

测试桩和测试驱动：

测试桩用于自顶向下测试，它用自己替换低级模块，其对于要测试的高级代码，外表和行为就像低级模块一样。

测试驱动用于自底向上的测试，它代替高级软件，更有效的运行低级模块的测试代码。

《软件测试》读书笔记 part2

配置测试

是指使用各种硬件来测试软件运行的过程。（与兼容性测试有什么区别？兼容性测试主要针对软件系统兼容？）

考虑哪些配置与程序关系最密切。

如何辨别是发现的软件缺陷是普通问题还是特定的配置问题？

在几个不同配置中重新运行暴露软件缺陷的步骤。软件缺陷不出现---》配置缺陷；都出现----》通用的问题。

兼容性测试

检查 软件之间是否能够正确地交互和共享信息。

平台兼容，与其他软件兼容，向前和向后兼容，把用于测试软件的高级/低级标准和规范当做铲平说明书的补充内容（比如一些操作要符合平台的标准，导出的文件要符合该文件类型的标准等）。还有数据共享兼容。

测试对象是新操作系统：检查与常用软件的兼容性

测试对象是应用程序：要求在多个不同平台上进行兼容性测试。

手机app的各种兼容性：

手机硬件方面：屏幕大小，屏幕分辨率，处理器速度，内存大小，不同手机厂商（何种基于手机的深度定制的操作系统版本），不同的os。一些图片应用还需考虑摄像头像素等问题。有声音的应用还需考虑播放器音质等。

软件方面：交叉事件影响（用应用的过程中有电话，短信，或其他应用弹出提示等），还有数据共享兼容（把一个应用的内容通过其他应用分享出去，比如通过微博晒出游戏战果）

外国语言测试

测试可能受到变长了的文本影响的软件部分。

找出没有正确换行，截断和连字符位置不正确文本。

变长了的文本可能导致主程序失败，甚至系统崩溃。

在软件的本地化版本中，需要测试所有热键和快捷键工作是否正常。

对扩展字符的测试：找到所有接受字符输入和输出的地方，每一处都尝试使用扩展字符，看能否与常规字符一样处理。

字符计算：分类和排序，知道测试语言的排序规则是怎样的。

本地化问题：本地文化风俗，不同地方计量单位也不同

软件本地化的测试：

白盒：检查代码中的文本字符串，度量单位处理，扩展字符以及其他代码问题。

黑盒：图形，文本，配置等本地化问题

易用性测试

用户界面测试：符合标准和规范，直观，一致，灵活，舒适，正确，实用

标准规范：比如window关闭窗口砸右，而mac关闭窗口在左边。

直观：

功能和响应出现在预期的地方；

布局是否合理？用户能否快速返回主菜单或去上一级和下一级？

是否有多余不用功能？太复杂？

一致：

尽量确保一些操作方式与其他应用中一致。在同一个应用中相同操作更要一致。

灵活：

根据用户的选择，展现用户想看的。

舒适：

软件外观与功能相符，对于一些敏感操作有警告，响应时间过长应该有提示信息。

正确：

测试UI是否做了该做的事。

软件定位偏差，功能与宣传材料不符；语言和拼写；图标，图像，声音，视频的一致性；UI删显示做了的，要确保是否真的完成了？

实用：

软件具体特性是否实用。

文档测试

这个文档应该是指软件的使用说明。

重要性包括提高易用性，提高可靠性，降低支持费用。（后面两者指在软件开发初期，早点找打bug）

软件安全性测试

威胁模式分析的目的：查找产品特性设置方面可能会引起安全漏洞的地方。

任何软件产品都有一个安全问题----》缓冲区溢出。主要是由字符串不正确使用引起的。

网站测试

测试网站时，先建立状态表：把每个网页当做不同的状态，超级链接当做状态之间的连接线。

文本：内容语法是否正确，描述是否准确。通过大幅缩放浏览器窗口来检查文字布局问题（比如换行在某些布局中显得正常，而在其他布局中不正常）。

超级链接：

确保它跳转到正确的目的地，并且在正确的窗口中打开。

要明显，鼠标经过时要有变化。

查找孤页，即没有超链接指向的页。

图片：

所有图片被正确加载和显示了吗？否则是否有对应的错误提示信息？

图片与文字交织时，改变窗口大小，检查环绕是否有问题。

网站载入速度如何？

表单：

指网页中用于输入和选择信息的文本框、列表框和其他域。

功能：

网站的功能特性是否都实现了

灰盒测试

仍把软件当做黑盒来测试，但通过简单查看软件内部工作机制作为补充。

HTML不是编程语言，它只是文字和图片的标记系统。HTML不能执行或者运行。

配置和兼容性测试：

考虑可能影响网站运行和外观的硬件和软件配置。

硬件平台：操作系统，屏幕布局。。。

浏览器软件和版本：各种内核，各种版本

还要考虑浏览器插件（接收插件来获得附加功能），浏览器选项（是否启用插件），视频分辨率和色深，文字大小。。。。

易用性测试：

不要使用不成熟的新技术，

不要不停运行的图片或者文字

连接颜色是否标准：蓝色是没点的，紫色或红色是点过的

过期信息及时撤出

用户是否能快速返回主菜单，上一级和下一级

每个网页是否都与主页链接

自动测试和测试工具

回归测试：重复执行测试，检查确认修改过的代码没有引入新的bug

自动化测试优点：

速度快

提升测试员效率：有更多时间进行测试计划，考虑新的测试用例。

准确度和精确度：机器自动测试，不会相认一样疲劳

节省资源：可模拟真实场景，大大减少测试需要的物力资源

仿真和模拟：代替真实情况下与产品连接的硬件或软件

坚持不懈：一直测试测试。。。

测试工具有两种：

非入侵工具：仅监视和检查代码，而不对齐进行修改

入侵工具：以任何方式修改了程序代码或者控制了操作环境

大多数代码覆盖率分析器是入侵式工具。需要编译链接到源程序中才能获得所需信息。

驱动程序：控制和操作被测试软件的工具。（ 控制和操纵被测软件）

桩：不控制或者操作被测试软件，相反，它 接收或者响应软件发送的数据。当软件需要与外部设备进行通信时，经常要用到桩。

桩比仿真器更好的点在于：桩还给测试程序提供手段来查看和解释发送给它的数据。

压力和负载工具

为软件创造了用其他方式难以创造的环境条件。

有了这些工具，可以方便的设置到该级别，执行测试，查看结果。

软件测试自动化

1.宏录制和回放

录制第一次执行测试用例时的键盘和鼠标操作，然后在需要重新执行这些测试时回放一次。

是一种驱动程序---》用于控制和操作被测试软件的工具。

缺点：没有验证，无法检验软件是否以预期方式进行。

2.可编程宏

在创建时编写回放系统遵循的简单指令。

虽然无法验证测试结果，但它可暂停执行，向测试员提示预期的结果，并询问测试通过还是失败。

仅限于直接执行命令行---》只能循环和重复。

3.完全可编程的自动测试工具

屏幕捕获，控件值，文件和其他输出。

测试自动化工具的主要目标是帮助测试员执行测试用例，----》有更多时间计划新的测试

另一个目标是模拟用户的可能操作。---》测试猴子

笨拙的猴子

1.随机输入，说不定会碰到测试员没想到的奇怪测试用例

2.重复操作，可能会暴露内存泄漏等软件缺陷。

半聪明猴子

在测试猴子中正阿基日志，将猴子操作记录到文件中。当猴子发现故障时，秩序查看日志，找出做了什么。

增加识别崩溃功能，泵哭哦吼，重启计算机，重新开始测试，可以多找一些缺陷。

聪明的猴子

在查找崩溃缺陷的同时，查看数据，检查操作结果，找出与预期结果的差别。可以随机执行，查找软件缺陷，记录结果。

缺陷轰炸

选择软件某一区域，所有测试员集中测试这个区域或者这组特性。

该区域可以是缺陷聚集区，也可以是快意不存在缺陷的区域。

alpha测试和beta测试

一般alpha测试先于beta测试。

alpha测试是把用户请到开发方的场所来测试，beta测试时指在一个或多个用户的场所进行测试。

alpha测试是在用户组织模拟软件系统的运行环境下的一种验收测试,由用户或第三方测试公司进行的测试,模拟各类用户行为对即将面市的软件产品进行测试,试图发现并修改错误.

Beta测试是用户公司组织各方面的典型终端用户在日常工作中实际使用beta版本,并要求用户报告异常情况,提出批评意见.

手机软件系统测试分类总结

1、功能模块测试：首先应分析功能模块的功能项，测试每个功能项是否能够实现对应的功能。一般根据测试用例（Test Case）或软件本身的流程就可以完成基本功能测试（相对简单，故障也较容易发现、解决）。

　　2、交叉事件测试：又叫事件或冲突测试，是指一个功能正在执行过程中，同时另外一个事件或操作对该过程进行干扰的测试。例如通话过程中接收到短信或闹铃触发，应用软件运行过程中插拔充电器等。执行干扰的冲突事件不能导致应用软件异常、手机死机或花屏等严重问题。另外，还需要注意各交叉事件的优先级别，检验系统是否能依据各事件的优先级别依次进行处理。不能因执行优先级别高的事件而导致优先级较低的事件吊死。

　　交叉事件测试非常重要，一般能发现应用软件中一些潜在的问题。另外有中英文模式切换的手机要注意中英文模式切换后的功能实现存在的问题（这个主要针对手机应用软件支持语言自适应功能），这一点通常会被测试人员忽略。

　　3、压力测试：又叫边界值容错测试或极限负载测试。即测试过程中，已经达到某一软件功能的最大容量、边界值或最大的承载极限，仍然对其进行相关操作。例如连续进行短信的接收和发送，超过收件箱和SIM卡所能存储的最大条数，仍然进行短消息的接收或发送，以此来检测软件在超常态条件下的表现，进而评估用户能否接受。

　　对手机可以施加的压力测试类型主要有：

　　● 存储压力：由于手机采用的是栈式存储，所以当一个存储块满了之后，如果程序员不做相应处理或者处理不好的话，很容易造成其他存储区被擦除，从而在UI上出现问题（比如其他功能无法正常使用，出现异常）。

　　● 边界压力：边界处理一直是程序员最容易忽略的地方。

　　● 响应能力压力：有时候某个操作可能处理的时间很长，在处理期间如果测试者再不断地进行其他操作的话，很容易出现问题。

　　● 网络流量压力：执行较大数据流量的功能的同时，再进行其他功能操作，使得网络流量始终处于很高的状态（如视频通话时再进行短信等其他功能操作），验证各功能是否依然能正常工作，是否存在因网络流量瓶颈而引起某功能异常。

　　压力测试用手工测试可能很繁锁，可以考虑自动化测试。遗憾的是，目前还没有较为大量使用的工具，一般都是由开发人员配合开发出的工具，或者高级的测试人员编写出的脚本。

　　4、容量测试：即存储空间已满时的测试，包括手机用户可用内存和SIM卡的所有空间被完全使用的测试。此时再对可编辑的模块进行和存储空间有关的任何操作测试，如果软件在极限容量状态下处理不好，有可能导致死机或严重的花屏等问题的出现。

　　5、兼容性测试：也就是不同品牌、款型的手机（针对目前我们产品来说，主要是针对不同品牌、款型的手机上的测试），不同网络，不同品牌和不同容量大小的SIM卡之间的互相兼容的测试。以短消息为例：中国电信的小灵通接收到从中国移动或中国联通GSM发来的短消息，需要验证显示和回复功能是否正常等。再比如，应用软件分别在Nokia N80、N93手机上运行，各功能是否均能正常使用，界面是否均显示正常等。

　　6、易用性/用户体验测试：易用性（Useability）/用户体验是指在指定条件下使用时，软件产品被理解、学习、使用和吸引用户的能力，是交互的适应性、功能性和有效性的集中体现。

软件测试流程

1.需求：阅读需求，理解需求，与客户、开发、架构多方交流，深入了解需求。--testing team
2.测试计划: 根据需求估算测试所需资源（人力、设备等）、所需时间、功能点划分、如何合理分配安排资源等。---testing leader or testing manager
3.用例设计：根据测试计划、任务分配、功能点划分，设计合理的测试用例。---testing leader, senior tester
4.执行测试：根据测试用例的详细步骤，执行测试用例。--every tester(主要是初级测试人员)
5.执行结果记录和bug记录：对每个case记录测试的结果，有bug的在测试管理工具中编写bug记录。--every tester(主要是初级测试人员)
6.defect tracking：追踪leader分配给你追踪的bug.直到 bug fixed。--every tester
7.测试报告：通过不断测试、追踪，直到被测软件达到测试需求要求，并没有重大bug.