分享---测试聊天问答记录

北京-Nightwind
需求不明+测试介入晚，这个现象挺普遍的，好像也没啥好法
北京-Nightwind
根据测试effort是不是足够，可以调整测试策略
济南--贝贝
最常用的测试工具是什么啊
北京-Nightwind
跟项目相关吧，适用或者用惯就好
济南--贝贝
哦
济南--贝贝
脚本语言一般用什么语言啊
北京-Nightwind
好像java类居多
北京-Nightwind
或者python，ruby之类
北京-Nightwind
一般通用测试工具都会考虑跨平台性
上海-子云
晚风，你们是不是每个系统都要写用例呢
北京-Nightwind
这些天生就跨平台的语言比较容易受到青睐
北京-Nightwind
原来是
北京-Nightwind
现在有时会用那种原始而且高风险但是效率高的测试方法。。。free test
上海-子云
那可不可以分享一下你们写的一些用例呢
上海-子云
这种方法我们也常用
北京-Nightwind
case都打着confidential标，发出来有问题
北京-Nightwind
free test有一些前提

济南--贝贝 :
写测试用例一般用什么方法啊
北京-Nightwind
假设测试者对产品都很了解，假设测试者的工作态度都非常端正
上海-子云
前提是什么呢
北京-Nightwind
不然结果大打折扣
上海-子云
是的
上海-子云
我遇到过这种情况
北京-Nightwind
是呀
北京-Nightwind
有些人管测试叫”标pass“，这种人就不适合去做free test
上海-子云
嗯
北京-Nightwind
写case的方法还是看测试对象
北京-Nightwind
我们主要是做功能测试
北京-Nightwind
不同类型的功能，写case的思路也不大一样
北京-Nightwind
没什么定式
济南--贝贝
哦
北京-Nightwind
比如树状遍历（典型的例子是菜单），一般用矩阵来写
北京-Nightwind
二维的UI遍历可能是个check list形式
北京-Nightwind
有明确输入输出的功能性测试，考虑DDT
上海-子云
这样写的用例比较全面
北京-Nightwind
一些入口简单，但后续操作复杂且验证点繁多的，比较容易写成Scenario
上海-子云
对于回归测试的话，有什么好的方法吗
北京-Nightwind
看回归测试的目的
北京-Nightwind
归回测试（regression test）的一个底线是”没有引入新的问题）
北京-Nightwind
如果只保证底线的话，可以考虑之前的code change
北京-Nightwind
在有change的区域选取case，比如以之前defect（fixed的）为核心展开些测试
上海-子云
但是从我遇到的情况来看，大多在回归时都会有新的问题存在
北京-Nightwind
是，当fvt（功能测试）阶段不完善，问题会留到后续阶段
深圳—茶?芷
假如，要对“单元测试、集成测试、系统测试、回归测试、验收测试”这些培训，你们会怎么讲解呢？
北京-Nightwind
这也是好多地方对regression寄予更高期望的原因
济南--贝贝
功能测试是不是用测试工具进行测试啊
北京-Nightwind
说是回归测试，其实是“xx测试的延续及回归测试”，方法也要把前一阶段的测试方法考虑进来
北京-Nightwind
功能测试挺适合用工具
上海-子云
嗯
北京-Nightwind
但是如果开发周期快，需求变化大，自动化工具和脚本的跟进速度达不到要求，也只要用手工来做了
北京-Nightwind
一般来说写case的时候留意一下，即使是写手工用例，也写成适合auto的case，为以后埋个伏笔
北京-Nightwind
auto比较适合应用在重复性高，步骤明确，产品稳定的的区域
北京-Nightwind
一般是regression test阶段