机能测试式样书

见过不少机能测试式样书，自己也做过一些。
通常都是由SE在机能理解或PG实装阶段完成。

比如一个页面的机能单体测试书，通常最典型的是由以下几个部分组成
1）画面layout正确与否
    详细列出所有的layout名称
2）画面静态显示文字正确与否
    详细列出所有的文字
3）画面动作正确与否
    详细列出包括初始化，正常系和异常系的所有动作执行后的画面显示
要求高些的还要排列整齐。

◆好处
听说，测试人员不需要理解式样，”给本式样书猴都能测。。。”     
真的是这样的吗？就我个人来说，测试并不是简单的体力劳动，怎么也不相信不理解式样就能做好测试。

◆弊端
1）是否是在做无用功？
    内容稍微多一点的功能，测试式样书的量可不是一点点，而作成过程中大部分的动作仅仅是机械地拷贝粘贴。
    有次在网上跟人确认一些内容，问对方在干什么，回答是"忙着呢，一边聊一边在做测试式样书"。。。
    因为绝大部分内容都是机能式样书上有的，只要整理成测试式样书的格式就可以了，是可以同时干点别的了。
2）舍本求末
    在有限的时间内，由于花费了大量时间精力做拷贝粘贴，真正关键的测试点反而没有时间去做了。
3）功能变更时测试式样书也需要同步
    最惨的莫过于这个了。机能变更是很频繁的。
    于是牵一发动全身，机能式样书=>测试式样书=>程序。。。
    一路改过去，而测试式样书的修改往往是最容易被遗忘的一环。然后。。。

----------------------------------------------------------------------------------------------------------------------------------
★★★推荐做法　：　机能式样书流用　＋　需要补充的case

测试时在机能式样书每行固定位置打上测试是否通过的标记，补充的case也一样。

不久前曾分担过一个机能的测试，对方提供了超级详细的一本（猴用）测试式样书。
于是借机验证了一下。
首先
①机能式样书好好看了一遍，理解了一下。
②追加了几个式样里没有的，但是可能出错的case。
③对关键部分的实装做了一下代码review。   《----如果测试人员有技术基础的话，推荐代码review，是个很高效的测试手段。
④按照机能式样书测试了一遍，在每行的功能描述的最右边打上了○或×。
⑤按照追加case做了测试。
然后
⑥充当了一下猴，按照到手的规范测试式样书测试了一遍。

结果
④和⑥发现的BUG基本相同，
③和⑤发现的BUG也基本相同，但是却是比较严重的。
④＋⑤＞⑥

事实证明，花大时间做的测试式样书并没有得到相应的回报。