搭建参考环境 熟悉需求与业务逻辑 1天
写测试计划（评审） 1天
写测试方案 １天
写测试用例 3天
执行 3天
项目总结 1天
一、你们以往做系统测试时的测试流程是怎样的？
二、测试过程中你是否搭建过测试环境？能否描述一下搭的什么环境？如何搭的？
１、环境：Linux(redhat4)、Apache、MySQL、PHP
步骤1：安装linux系统
步骤2：对linux系统做一些配置：设置IP地址，创建用户，创建文件系统
步骤3：上传安装源文件(ftp）
步骤4: 安装Apache （编绎安装）
步骤5：安装mysql(rpm安装）
步骤6: 安装php（编绎安装）
步骤7:部署sugar版本（检查环境和权限，连接数据库，安装实例sugarCRM）
Linux常用的一些操作：
１、目录操作(mkdir, rm -R, cd, pwd,mv,cp,ls,ls -al, ls -lrt)
２、权限操作(chmod, chgrp, chown)
３、系统管理(shutdown -r now, shutdown -h now, reboot，useradd, su - 用户名)
４、进程与资源管理(ps -aux, free, top, vmstat, iostat)
５、文件查看和编辑（cat,vi,tail,tail -f,more,less ）
６、压缩，安装类（rpm -ivh, rpm -e,rpm -qa查询已安装的rpm包，tar xvf，tar cvf，unzip,gunzip,gzip）
７、磁盘（du -ms(ks), df, mount/umount）
８、find, grep，linux日志结构
能否描述一下你测的项目？
BS架构，测试环境，客户，产品的作用
三、需求分析阶段主要做什么事情？有好的需求是否要做需求管理？如何做好需求管理？
需求分析阶段：分析测试需求，评审需求，可测试性需求
需要做好需求管理，怎么做：做好需求跟踪
四、如果我们项目中没有需求文档，应该怎么做好测试工作？
１、搭建一个历史版本的环境，以便了解业务流程
２、开发的概设，详设，与需求类似的讨论（会议纪要）,用户使用指南，产品介绍
３、与项目组有经验的员工交流
４、参考友商的类似的项目（文档）
5、项目内部组织业务培训
五、测试计划应该包括哪些内容？
描述被测对象，测试的范围，测试组织结构，测试通过/失败的标准，测试挂起和恢复的条件，
测试的任务安排，人员和时间规划，各个任务的输入和输出，输入输出标准，风险和规避措施
六、测试通过的标准是什么？
１、需求100%覆盖；
２、测试用例100%执行并通过；
３、所有缺陷都修改完成并回归测试通过
不严格：
１、需求100%覆盖；
２、中高级用例100%测试并通过，低优先级的用例60%以上测试并通过；
３、遗留的缺陷密度小于0.05/KLOC
七、项目中主要有哪些风险？如何规避？
１、测试过程中人员变动；
２、需求变动频繁；
３、开发延迟转测试；
４、版本上线日期提前；
５、测试人员
技能；
６、设备或工具损坏(不能及时到位)
规避：加班，从其它组抽调人员，招聘补充人员;
做好需求跟踪，前期需求分析和需求评审工作做好
提前做好开发进度跟踪，改变测试策略
做好技能培训，以老带新，做好评审
提前准备好备份的方案，测试环境最好提供备份环境，环境需要专人维护，提前约定好工具到位时间
八、如何评估工作量？
１、从测试用例规模上评估工作量
２、从软件的规模上评估工作量
九、测试方案是什么？主要包括哪些内容？
测试方案描述测试对象，测试范围，测试的软硬件环境，测试策略，测试组网结构，测试用例设计方法和标准
测试工具的需求和设计，测试代码的需求和设计；
测试方案属于技术文档，主要解决如何测试的问题
新增（快速，完整），修改，删除，查找，导入，导出
快速新增- 快速新增-快速新增功能
select子界面
十、能否举例说明你以前的项目是如何测试的？
新增：快速新增，select子界面
快速新增：等价类，边界值
查询：
单项查询：１、每个单项条件能正确搜索，模糊查找，精确查找，通配符查找
组合查询：１、正交
２、判定表
３、逐项条件填加查询(１、全空 100项；２、增加一个输入条件，使查询结果减少 80 ３、再增加一个输入条件，使查询结果在原来基础上减少
一直到所有查询条件都输入为止 ４、最后改动查询条件，使查询结果为０
修改：等价类，边界值
删除：
选中一个（第一个，最后一个）
选中多个(连续的，不连续的）
不选
全选
多页（3页以上）
删除时取消
导出：
导入：流程分析法,等价类，边界值
测试用例中应该避免的问题：
１、在写用例的输入数据和步骤描述上，应该和业务比较接近
２、在用例细分的颗粒度上要考虑业务场景，需要把握好细分的度
３、在用例中对于一些无关紧要的输入项，可以用一句话代替；
４、优先级需要分类，大致H级的在20%左右，L级的20%左右，大部分是M级的
５、尽量避免用例与用例之间的依赖性，要体现低藕合度的特点
select子页面的新增：
１、所有的项都输入，能创建成功
２、只填必填项，非必填项为空
３、必填项为空
４、创建同名的
十一、测试执行主要做哪些事情？
开发到转测试时间点，把版本包（开发的安装包，用户安装指南,用户使用指南，维护指南，版本配套表
代码规模，转测试建议）
SVN：创建转测试目录 B011
B012
B013
同时，开发经理会通知测试经理（转测试版本已经放在ＳＶＮ上面，可以取版本测试）,项目经理，ＳＱＡ都会收到类似邮件
１、测试组长：转测试版本检查该转的项目版本包和文档是否齐全？是否有问题。
在测试组内分本具体的测试任务（搭环境，各个测试工程师负责测试的模块，分配测试用例）
并给出测试时间安排，交付时间，注意事项等
２、环境管理员：到ＳＶＮ上面取版本，搭建测试环境，并将测试环境链接发给所有测试人员
在测试执行过程，维护环境
３、测试工程师：按照组长分配的任务，执行测试，记录测试结果
提交测试缺陷单
第一轮测试完成，提交测试小结（描述测试对象，测试时间，人力，测试用例执行情况，缺陷情况）
隔几天时间转第二轮测试B012版本测试
用例选择策略（１、优先级高的；２、第一轮未通过，发现缺陷的；３、由于缺陷导致第一轮无法测试，阻塞的用例
４、由于第一轮的缺陷，修改代码，会影响到的模块的用例，第一轮测试已通过的）
输出第二轮测试小结
转第三轮测试，测试执行后输出测试报告(整体三轮测试的总结）
十二、缺陷管理流程是怎样的？
１、提出缺陷单（简要描述，版本号，希望修改日期，严重等级，重现步骤，实际结果，环境，初步定位的结论，截图）NEW
２、主管统一审核缺陷（直接close，重复，非问题），确定是问题，发给开发 assign to 开发
３、开发判断是否缺陷 置为open 修改完成以后置为fixed，指定给测试经理
４、测试经理分配fixed状态的缺陷给测试工程师回归测试 主管分配给测试工程师
５、回归通过 closed，不通过 open状态
十三、如果你提交的问题，开发不认可，你会怎么处理？
１，自己先分析确认一下，是否问题，你的理由是什么，严重级别
如果是无关紧要的问题，而且开发很忙，可以暂时挂起。
如果不是无关紧要的问题，可以和开发当在沟通（把开叫到电脑前，重现问题，说明对系统的影响）j,开发可能接受该问题
如果开发当面沟通不接受，该问题必须修改，则求助测试组长来决策（邮件形式讲清楚这个问题现象，对系统的影响，发送给开发人员，抄送测试经理，开发经理）
十四、测试过程中你有没有发现缺陷，能否举例说明几个印象较深的缺陷？
１、删除的数据，在数据库中没有实际删除掉，只是将一个deleted标志字段置为1
２、新增一个商业机会记录时，会增加多个同样名称的记录(商业机会），记录数与user数量一致；
３、修改客户反馈信息时，如
果把客户反馈相关联的客户名称（很重要字段）改成不存在的客户时，可以修改成功。
４、不修改信息时，可以正常导出，但如果将要导出的信息中的assign to 的字段置空，则导出时整个记录为空
5、在创建系统中存在同名的客户信息时，应该要给出提示
６、选择不连续的几个记录删除时，会将选中的第一条和最后一条之间的所有记录都删除
十五、回归测试版本的用例选取的策略是什么？
１、未通过的，未执行，阻塞的
2、由于开发修改了问题而影响到的模块的相关测试用例（前面执行通过的）
３、把优先级高的H级的用例做回归测试
十六、测试报告主要包括哪些内容？
测试报告描述测试对象（从架构，开发语言，功能，前景等角度），测试对象的版本，测试的时间人力安排,测试软硬件环境
测试用例情况（测试用例数量，用例密度，稳定性，执行情况），测试版本质量（缺陷数，严重程度，缺陷密度）
测试结论，遗留问题列表。
十七、你们项目当中有没有做得好的地方？有没有做得不好的地方？好在哪里？不好在哪里？
好的：
测试流程比较清晰，各个阶段交付件也齐全，各个交付件会经过评审并归档；
分工明确，配合协调，组长写测试计划，做数据分析，进度，协调；老员工写方案，写用例；新员工写用例，执行
相互之间沟通很顺畅，开发，测试相互配合比较好
不好的：
用例数写得太少；
开发提供的版本质量太差，低级问题很多；
用例写得不好（数据不好构造）
需求不够明确
十八、BS与CS架构的区别，测试的侧重点分别是什么？
BS是浏览器/服务器架构，CS是客户端/服务器模式
BS：使用方便，不需要安装客户端，只需要有浏览器就可使用；安全性较ＣＳ低（用在互联网，客户端与服务器端安全协作性没有ＣＳ高
有些安全要求很高的场景需要单独安装插件 ），性能较低
测试侧重点：
浏览器兼容性测试，插件的测试（安装，功能）
服务器的性能测试
CS:安全性较BS高（适用专用网，局域网范围，客户端和服务器端安全协作性高）
性能较BS
测试侧重点：
１、客户端的安装测试，卸载，升级测试，升级回滚
２、客户端的功能测试
十九、什么是兼容性测试？兼容性测试的重点是什么？
二十、提交缺陷单时，应包括哪些内容？
标题，缺陷编号，模块，时间，严重程度，详细描述（问题重现步骤，预期结果与实际结果），附件(截图或日志)，问题初步分析
作用：１、记录缺陷，以免遗漏
２、便于测试开发之间的缺陷管理与信息传递
３、缺陷统计与缺陷管理
二十一、如何定义缺陷严重级别？
致命：直接导致软件不能正常使用（挂起，异常退出，死机,核心功能都不能使用）
严重：影响范围，主要功能受影响，（缺陷影响不严重，但是范围很广），影响范围不广，但影响了主要功能
一般：只影响非核心功能的缺陷，影响范围也不大
建议：能正常使用，提示信息，界面因素相关的问题；一些优化建议类的点，其本身不是缺陷
IEEE 国际电子电气工程师协会 International Electronic Electric Engneer
需求的来源：
１、市场调查（调查问卷、用户访谈）
２、竞争对手
３、内部讨论
４、技术的发展
项目级的需求：有固定客户（显性需求、隐性需求）
需求分析：１、通过显性需求挖掘背后的隐性需求
２、将显性需求和隐性需求规格化，并记录下来，形成SRS
规格化：１、定义它的规格和单位 ２、性能规格 ３、接口的定义 ４、可靠性（其它质量特性）
基线化：形成一个标准，给其它的工作提供参考(１、管控 权限管理；２、标识 版本号）
需求分析阶段（测试）：１、分析测试需求，提出可测试性需求给开发人员
２、根据质量模型、功能交互、继承性分析等方法分析测试的测试需求
３、参与需求评审（开发、测试、SQA、配置管理员、用户代表）
项目管理是一个模块
项目
子项：新增，修改，删除，导入，导出，查询
１、新增
编号：
测试方法：
测试要点：
１、
２、
修改：
编号
测试方法
测试要点
项目任务
sugarCRM-ST-Accounts-copy
服务器端的兼容性：
linux redhat4
windows 2008 server
客户端：
IE
ff
google
项目实际常用的评审流程：
１、作者邀请评审人员评审作品，将作品发给相应的评审人员
评审的对象，评审完成时间，各个人员评审的重点
２、在评审时间结束前跟踪评审结果，将所有的评审结果汇总；
３、召开评审会议，确认所有的问题
4、作者修改问题
５、将修改后的作品发给所有评审人员，确认问题修改完成
3:00-5:00 评审完成
a%c 可以查找包括a c开头的
ac 可以查找ac开头
%ac
１、SVN管理员到服务器上面取测试版本 F:\项目\sugar\09 项目安装包\sugar\B011
２、环境管理员到SVN上面取版本，搭测试环境（windows系统）
半年（需求分析，概设，详设，代码，自测试）
( 测试需求分析，需求评
审，测试计划，测试方案，测试用例，测试执行，UAT测试)
新增需求，更改的需求 =>需求人员，项目经理 规划版本计划（V1.0在开发阶段，V2.0开始规划，可以纳入新的需求）
需求
需求没写，但需要做（从易用性考虑）
个人： 日报 （工作计划，进展，建议，困难，需求助的地方）
周报：主管提交（测试组一周的工作计划和进展，下一周的工作计划，困难与求助）
双周报
月报
晨会，例会
敏捷开发（适合短平快的项目，需求变化快，版本周期短的项目，文档比较少，注重沟通）
大版本->小版本（迭代） 每个迭代的需求通过迭代会议确定 （设计，编码，测试）
用户故事(user story) 对用户故事进行测试
结对编程
预测试（冒烟测试）：在大规模开展测试之前，抽取一部分功能进行测试，保证大规模测试可以
顺利进行，如果测试发现版本质量较差，则将版本打回给开发组，修改问题后再测试
从优先级为Ｈ级的用例当中抽取一部分来测试
必填项：assign to
１、界面上要打上必填的标签
２、如果新增时assign to 项为空，则不能新增成功，同时界面上给出提示信息
易用性：
ＧＵＩ：按钮 （一类按钮写一个测试用例）
标题：测试account界面的按钮功能
步骤： 点击 的按钮
预期：select 按钮可以打开xx
clear按
布局：
易操作性：
测试快捷键
测试易用性，重点关注：布局，按钮功能，快捷键，尺寸，颜色
项目进度安排：
1年工作经验： 4000个用例 1000用例（写用例：1－１.５个月；执行（B011:1月 B012:15天; B013：1周 ２个月））
需求评审，写计划，方案，用例，执行，评审；
熟悉需求，了解业务流程，评审1周，计划，方案1周 1个月
4-5个月参与到第一个版本
测试升级版本（每两个月出一个新版本：１、新增加功能，优化；修改以前的BUG
出定制版本：不同的客户定制不同的功能，）
需求评审，计划，（方案）用例，执行
第二个项目：
组织架构：研发：开发组，测试组； CRM 5人， SNS：3人 其它：财务管理软件 总人数 10人
40人
50人做研发
销售团队：15 技术支持：6 后勤: 6
等价类，边界值: 不考虑组合，重点考虑输入规则，不是考虑输入和输出关系的
注册，修改，删除，
判定表，因果图，正交：考虑组合，考虑输入和输出关系的，不同的组合产生不同的动作
登陆，查询,配置测试
流程分析法，状态迁移图：
测试流程（事件流）保证每个业
务流程是正确（处理一笔业务需要很多步骤，不同的步骤之间有先后关系或依赖关系，有些步骤
有不同的选择，安装测试）
保证框架是对的，但是具体每个步骤的(创建，修改等）需要使用其它方法，如等价类
常规方法（7种）+非常规的方法(异常分析法，错误推测，探索性测试）
电子商务：
后台（卖家）：商品管理（上架，修改，删除，导入，导出）
买家:
购物蓝管理：修改购物蓝信息，删除，查看，计算费用
购买管理：流程（选货物->付款->收货->安装->售后）
订单管理
压力测试：让系统长时间，大压力的情况下运行，测试系统的性能表现（响应时间，资源耗用），以及
系统在压力卸除以后的恢复情况（恢复速度，恢复程度）
性能测试：测试系统是否满足性能需求(业界标准）
负载测试：测试系统从较小的压力开始，逐步增加系统压力（并发量），在各个压力场景下的性能表现
（响应时间，资源耗用）
容量测试：测试系统可以容许的最大容量（最大并发量，数据库最大的处理能力，上传文件最大的大小，最大的速度）