软件测试题2

5. 缺陷管理

1)软件功能缺陷的种类

软件功能缺陷的种类包括如下：
①　软件未实现需求规格要求的功能
②　软件未实现需求规格未明确提及但应该实现的功能
③　软件出现了需求规格指明不该出现的错误
④　软件实现了需求规格未提及的功能
⑤　软件难以理解，不易使用，运行缓慢，或者最终用户认为不好

2)为什么会出现二八定理

①　根据软件功能模块的复杂程度有关
②　根据写代码的开发人员的水平高低有关

3)缺陷的抗药性

测试进行的越多，新缺陷就越难被发现：
①　一直使用同样的思路，同样的一套测试用例，没有新的突破
②　某些缺陷只有在很特殊或者很极端的情况下会被触发
为了抵消抗药性，进行交叉测试
手机端测试长时间使用产生特殊情况，权限问题

4)并非所有的缺陷都需要修复，不修复缺陷的原因

①　没有足够的时间
②　修复的风险很大
③　不算真正的软件缺陷或不值得修复
发布：根据缺陷等级判断，给决策人员提供建议
失控后：和领导提建议说明
银弹原理：再好的软件也会有bug

5)软件缺陷生命周期的三个阶段

①　发现缺陷，报告缺陷
测试人员找到软件缺陷并将软件缺陷提交给开发人员
②　修复缺陷、验证缺陷
开发人员再现，修复缺陷，然后提交测试人员去验证
③　关闭缺陷
测试人员验证修复过的软件，关闭已不存在的缺陷

6)缺陷的等级

缺陷严重程度 描述
致命 软件无法运行，或者软件的主要功能丧失，或者很大可能性会造成严重不良后果。
严重 软件的次要功能丧失，或者主要功能在一些特定情况下会出错，比如金额计算等等。
一般 软件在某些情况下会出错，但是造成的后果影响不大。
轻微 在某些情况下会出错，但是造成的后果影响很小。

7)缺陷跟踪和管理碰到的问题

①　若开发人员没有及时修改Bug，如何去催开发人员？
总体的处理原则：
1.跟开发人员沟通时，要站在工作的角度向开发人员叙述问题，态度要坚决，语气要柔和，不要情绪化，手段要中庸；
若开发人员工作很忙，具体处理措施，分为两种情况：
2.若Bug的等级轻微且Bug解决时间不着急，跟开发约定时间，并以非正常方式跟测试经理说明；
3.若Bug的等级致命或者严重，跟开发一起找开发经理请求分配时间；若开发经理不在场，则先跟开发人员商量好协调的处理措施，同时汇报给测试经理。
②　开发拒绝修改，认为这个Bug不需要修改，该怎么做？
1.与开发人员进行沟通，弄明白他们不愿意修改的原因，并把自己的想法跟他们说，让开发人员心服口服的承认Bug并自愿修改；
2.如果这个Bug是需求理解有分歧的情况，尽量和开发一起与需求分析师讨论；
3.如果这个Bug是开发方面的问题，不能越过开发人员直接找他的上司，这种行为是不合理的，会影响测试人员与开发人员的关系；实在说服不了开发人员修改Bug，可以和他一起请他的上司分析；
4.若需求分析师或他的领导也认为不需要修改，请自己上司加入，到时就是自己的领导与他的领导进行沟通，服从领导们的决策。
③　开发人员说Bug不能重现
测试人员上报Bug时，对于较难的Bug要截图，把截图放在附件里上传。
当Bug不能重现时：
1.与开发一起检查Jar包和环境配置；
2.请开发人员操作一遍，看两人的认识是否一致；若认识一致，则到自己的测试环境去重现Bug；
3.若此时Bug还是没有重现，尽量回想当时所做的操作，是什么情况下出现了这个Bug，是否是操作环境发生变化；
4.如果Bug还是没有重现，尽可能的跟开发沟通；
5.若Bug一直无法重现，还是要记录该Bug，标记上无法重现。

8)项目测试中，如果需求一直在变化，该怎么做？

1.尽快与项目经理或与承担该项目风险的人讨论，了解需求怎么改变，确定哪些需求需要变动，哪些需求变化不大，尽早改变测试计划和策略；
2.对于变化不大的需求尽快写测试用例；
3.对于不固定的测试需求，尽量与项目经理确定时间，尽早把新的需求纳入到测试要点；
4.在设计测试用例时要有一定的灵活性，降低测试用例的详细程度；
5.尽量把自动化测试集中在看来不会改变的部分；
6.对变更进行适当的风险分析，以减少回归测试的要求。

9)缺陷如何跟踪和管理

1.发现Bug、上报Bug：测试人员发现Bug后，填写Bug报告，系统除了在缺陷跟踪工具中提醒相关人员外，也会自动通过Email通知相关人员；
2.确认Bug：开发者收到提醒信息后，判断是否为自己的修改范围，若是，进行处理，若不是，重新分配给项目组长或应该分配的开发人员；
3.修改Bug：开发人员修改Bug后提交；
4.验证Bug：测试人员查询开发人员已修改的Bug进行重新测试，经测试验证无误后，修改状态为VERIFIED；
5.关闭Bug：测试经理 CLOSE已验证通过的Bug；
6.重新打开Bug: 测试人员验证开发人员已修改的Bug，若还有问题，Reopend，状态改变为new，并发邮件通知相关人员。

6.性能测试

1)性能需求中需要考虑的性能问题

①　网络的在线访问人数估计有多少人，并发人数有多少人
②　功能的系统响应时间可接受的范围
③　系统支持的最大吞吐量是多少
④　用户频繁使用的功能模块是什么
⑤　网站的高峰时段是何时
⑥　哪些功能覆盖了交易

2)性能测试的目的

验证软件系统是否能够达到用户提出的性能指标，或者是发现软件系统中存在的性能瓶颈并加以优化

3)性能指标主要包括以下几个方面

①　系统指标：虚拟用户数、事务响应时间、每秒点击数、吞吐量
②　资源指标：CPU、内存

4)LoadRunner组成四部分

①　录制脚本的部件
②　产生压力的部件
③　图表分析工具
④　产生虚拟用户的部件

5)LoadRunner脚本录制步骤

①　选择合适的协议
②　设置录制选项
③　开始录制
6)LoadRunner脚本调试的两种方法
①　设置断点，按F5键
②　单步跟踪，按F9键

7)LoadRunner高级功能

①　脚本语言
LoadRunner常用的开发语言是C，也支持Java
②　完善脚本
事务、集合点、参数化输入、关联技术、检查点、Run-Time Setting选项

8)性能测试过程

①　录制脚本前，首先分析系统
哪些是频繁使用的功能点、哪些是吞吐量大的、哪些覆盖交易的，按照用户使用业务的场景进行录制。
②　录制完脚本、运行并调试脚本后，编辑脚本
包括建立关联、参数化、事务、检查点。
③　进行场景设计
没有性能需求的时候使用负载测试，测试系统的瓶颈；然后进行稳定性测试，持续3天或者一周或一个月的持续运行。有性能需求，直接使用该需求进行稳定性测试。
④　分析结果
整体事务响应慢，多半是数据库/服务器或者程序本身有问题。单个事务慢，首先排除该事务对应的数据库相关SQL语句、表单及数据的问题，否则是程序本身的问题。
⑤　性能调优
把问题定位后，写在测试报告里发给开发；然后帮助开发进行性能调优。

7.测试环境搭建和管理

1）Linux基本命令

文件和文件夹命令
①　ls：显示文件和目录。
②　pwd：显示当前目录。
③　cd：切换目录。
④　find：查找。
压缩和解压缩命令
tar：压缩和解压缩。
系统命令
①　top：显示当前资源耗费最多进程信息
②　ps：显瞬间进程状态
③　kill：杀死进程，可以用ps或top查看进程的ip，然后再用kill杀死进程。
④　reboot：重启系统。
⑤　poweroff：关机。
⑥　locale：查看系统是否支持中文
⑦　df：查看磁盘分区情况
⑧　netstat 查看网络资源，包括：本机提供的网络服务被其他服务器调用，也包括本机调用其他服务器的资源

2）搭建测试环境的步骤

①　安装虚拟机
②　安装Linux系统
③　安装相应的应用程序JDK，若WebServer用Tomcat、数据库用MySQL，则搭建它们并做好配置
④　配置防火墙
⑤　若无现成的发布系统，则在Eclipse中编译并运行基本功能
⑥　发布系统
输入java-version查看jdk版本，安装软件：yum自带软件安装，rpm进行第三方软件安装，tar压缩解压缩，进行免安装
管理测试环境：分配测试环境管理员，维护好测试环境

1)设置专门的测试环境管理员角色：

1).测试环境的搭建和记录
包括软件的安装和配置，记录组成测试环境的各台机器的硬件配置，IP地址，端口配置，机器的具体用途以及当前网络环境的情况，测试环境各项变更的执行及记录
2).测试环境的使用的管理
用户名，密码及权限的备份和管理，当测试组内多名成员需要占用服务器并且相互之间存在冲突时负责对服务器时间进行分配和管理；
2)明确测试环境管理所需的各种文档
组成测试环境的各台计算机上各项软件的安装配置手册
记录历次被测应用的发布情况；记录用表格形式
3)测试环境访问权限的管理
为每个项目测试环境的测试人员和开发人员设置单独的用户名，并根据不同的工作需要设置不同的访问权限；
4)测试环境的变更管理
开发人员或测试人员提出书面申请，由测试环境管理员负责执行
对测试环境的任何变更均应该记入相应的文档；
同每次变更相关的变更申请文档，软件，脚本等，均保留原始备份，作为配置项进行管理
5)测试环境的备份和恢复：数据库备份 热备份(导出) 冷备份(导出硬盘里的数据–创建一个和之前一样的数据库)
尝试着用应用软件来构建可“复用”的测试环境
测试环境备份：应用虚拟机技术备份测试环境；
硬盘备份：往往要用到如：ghost，driver image等磁盘备份工具软件；
数据库备份：做好数据备份或准备数据恢复方案，例如通过运行sql脚本来将数据恢复到测试执行之前的状态；

Linux应用：搭建管理测试环境，发布项目，性能测试进行资源指标监控