讨论几道题的测试方向
在收集整理面试题过程中，看到这几道题（好像是微软的），觉得还有点意思，想发出来大家讨论下。。。1.你如何在packet pc上test你的程序，你考虑了哪些方面？
2.如果将你的程序的语言扩展到非英语，例如中文，你如何测试？
3.给你一罐可口可乐，你如何测试？
4.你如何isolation你程序里的bug？
发散思维，HOHO~~~ 呃。。。我先自己说一下大概的想法。。也许还不成熟与不成型：
1.测试程序在上面的运行速度，响应时间，屏幕显示，读取资料速度等。
2.将程序放在不同的系统下看能否支持运行（中文是否有可能变乱码），输入同音不同意，同意不同音或者相近字体等中文，是否会发生错误及其错误提示。
3.外观上进行一系列测试，如LOGO是否清晰等，然后重量上测试，是否满足要求的升数。。。。
4.这个。。。还没想到。。。
粗略的想法。。。希望大家讨论一下~ 我也说说自己的想法吧。
首先，凡是发散性思维的题目，都没有标准答案的。所以，如何将自己的思维方式传达给对方才是重点。
因为很多东西，即使你平时知道，但临时整理的时候，也不可能全部想得起来::qiguai:::
那么针对具体的问题，我比较喜欢从提出问题的重点和原因入手，再发散到与之相关的信息。
1.你如何在packet pc上test你的程序，你考虑了哪些方面？
这道题的重点在于了解嵌入式与非嵌入式设备的区别。
那么问题的入手点也是先考虑这两者有什么区别呢？存储空间、电源、体积、硬件、操作方式等等
针对存储空间：嵌入式空间小，那么对申请/释放内存资源会有更严格的要求。不及时释放内存资源是相当严重的问题，所以，实时内存检测会是一个重点测试点。
针对电源：嵌入式设备大多使用的内置电池。所以，对各个器件的功耗有严格要求。如何在有限的电量中，保持更长的正常使用就成为一个关键需求。随之而来的就是：省电模式的测试、器件额定功率测试、电池容量测试等等
针对体积：嵌入式多为手持设备，体积自然不能过大。
针对操作方式：嵌入式设备通常没有外置的键盘和鼠标，所以特殊的键盘和触屏操作也是测试点。
……
2.如果将你的程序的语言扩展到非英语，例如中文，你如何测试？
这个问题的重点在于本地化的测试要点。
所以可以考虑不同的字库、不同的编码方式对程序的影响。再发散一些，甚至可以考虑当地风俗和语言习惯。比如NOKIA的手机中，很多中文翻译我们看着都别扭，就是因为老外不清楚中国人的语言习惯。
3.给你一罐可口可乐，你如何测试？
这个问题的重点在于，针对一个完整的产品，如何搭建测试框架，拆解各个测试点，最终形成一个完整的测试体系的过程。
所以，这道题最好不要一上来就说：我们需要测试Log、需要检查形状等等。
先思考，我们可以把这罐可乐分为几个部分（可以参考一般的测试产品）：UI（外观）、功能（提供的用户操作）、硬件（材质）、特殊需求（保质期）
然后针对每类来描述其中可能存在的测试点。
UI：颜色、风格、图标、产品说明……
功能：用户操作、密封性……
硬件：大小、材质、形状、性能指标（比如抗压/挤）……
特殊需求：保质期、实际容量/重量……
这样描述的话，虽然不能列举出所有的测试点，但是可以让对方清晰了解自己分解产品测试点的过程和思维方式。
4.你如何isolation你程序里的bug？
这个题主要还是考察如何更有效的提高BUG的初步定位能力。
清楚考察点后就可以结合实际情况有的放矢了：
1、减少不必要的重现步骤
2、增加测试次数检查BUG的重现率
3、使用辅助工具增强对位。比如C程序的内存泄露，可以使用C的反编译工具检查New函数后是否释放。
4、其他方法，也许每个人在实际工作中还有各自的特有小技巧呢::daxiao::: 楼上的分析挺不错的~~ 不过可乐还要测试成份是否超标吧……
[ 本帖最后由 楠族开心果 于 2010-7-15 18:15 编辑 ]
第4题错了
第4题的分析错了，正确理解应该为：隔离BUG也就是减少BUG对项目其他资源的影响，如用例执行、功能的研发等等。
页:
[1]
