当前位置 博文首页 > 小码哥说测试的博客：软件测试面经那么多，看这一篇就够了（持续
用例设计（电梯，登录，微信，点赞，抢红包，发红包，视频电话，余额宝中的转入和转出。）
a）功能
b）UI界面：排版布局尺寸大小
c）易用性：客户的使用习惯，电梯按钮的位置高低
d）兼容性:
e）可移植性：
f） 安全性：发送数据数据是否加密（页面的一个有效时间），日志前台和后台是否有密文加密，电梯断电被夹到能不能
g）性能：发朋友圈的速度，页面的响应时间，电梯长时间的一个稳定性。
迭代周期
1.敏捷项目（ 一周）
2.迭代开发（半个月或者一个月）
测试流程
1.测试经理给需求文档
2.看需求文档（深入了解）
3.产品召开需求澄清会议（更加熟悉了解需求）
4.需求反讲
5.测试计划（任务分配）
a）测试人员
b) 任务分配（重要）
c）测试周期
d）软硬环境
e）项目背景，测试环境，测试目的
f）预防风险
6.写用例
7.用例评审
8.环境搭建 开发在写HHL，LLD编码
9.转测，提测（把项目版本包给到测试）
10.冒烟测试，回归测试，系统集成测试
11.达到测试准出，项目上线，输出测试报告，缺陷报告
a） 用例的执行情况(主要)
b） 测试人员
c ）缺陷统计情况
d） 软硬环境
e） 项目背景，测试环境，测试目的
f） 风险分析
g）总结能否上线
a） 所属产品
b） 所属模块
c） 所属项目
d） 影响版本
e） 当前指派
f） bug的类型：代码问题，设计缺陷，环境配置，文字描述
g） bug的标题
h） bug的等级
致命性bug：系统死机，无法访问使用
严重性bug: 影响到很多主体功能无法使用
一般性bug：比如查询的小功能无法使用,页面显示不正确。
建议性bug：没有提示，或者他提示描述的不清楚，排版不美观
l） bug的重现步骤
a)用例编号
b)用例标题
c)前置条件
d)用例的优先级
e)用例测试步骤
f)预期结果
g)所属产品
h)关联需求
i)测试人员
每个版本进行冒烟测试
我们主要筛选涉及到主要业务流程相关的测试用例，作为冒烟测试用例的
也会自己去写一些重要场景的场景用例作为测试用例
冒烟测试
SIT1
全量测试:对所有用例进行测试
增量测试:
回归测试
a）先进行一次冒烟测试
b）bug修复后要进行验证
c）和bug相关的的用例进行回归测试
d）bug新增到模块的用例进行回归测试
SIT2
3.如何保证需求所有测试点的覆盖率？
1.取决于设计用例的人员是否深入了解需求
2.站在用户，测试，开发的角度去挖掘隐形需求
3.通过用例评审的方式让别人
1.0bug
2.用例执行完毕
3.缺陷全部修复，并且验证关闭
4.缺陷呈收敛趋势
5.通过验收测试
有输出相关的测试文档（测试用例，测试计划，缺陷报告，操作手册）
1.分析新添加的需求进行评估能否按时测完（安排人员协助），反馈问题
2.增加的需求影响的范围有多大（影响已经测试完的功能），没有足够的时间(潜在的风险)，影响客户的使用
3.如果需求一定要增加的，先挑选重要的执行
4.确实影响比较大的建议放在下个版本进行增加
1.发个文档个运维（版本，版本包是第几个版本包，项目包放在哪里，配置文件修改修改哪些内容）
2.测试留人员协助项目上线
1.找相关人员（客户）了解情况（怎么发现的）
2.在预发布环境去重现线上bug
3.如果真的存在，反馈给测试领导（经理）做决定，如果bug比较严重
提交的bug管理工具
找开发解决，回归测试，重现上线或者打补丁，针对问题增加一些新的代码
不是特别严重（延期处理）提交到指定的项目中，下个项目进行测试修复。
用例设计方法：
等价类：转账金额输入框
边界值:账号长度，根据账号的长度
因果图（条件与条件组合）：最终转化为判定表
判定表：登录，考虑组合关系，账号和密码的组合，结果只有成功或者失败（2N次方条）
最后感谢每一个认真阅读我文章的人，看着粉丝一路的上涨和关注，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：
这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!
在我的QQ技术交流群里（技术交流和资源共享，广告勿扰）
可以自助拿走，群号：175317069 群里的免费资料都是笔者十多年测试生涯的精华。还有同行大神一起交流技术哦
敲字不易，如果此文章对你有帮助的话，点个赞收个藏，给作者一个鼓励。也方便你下次能够快速查找。
?
cs