需求说明：页面静音功能是这样一个功能，当浏览器打开的网页中在播放声音时，通过操作状态栏的一个开关按钮，可以将网页中的声音静音。

黑盒测试能够考虑到的测试点：

1. 状态栏的图标开启/关闭时的状态显示。
2. 不同网页的静音情况。
3. 多个网页均存在声音时开启静音的情况。
4. 高速内核页面(Webkit)和兼容内核页面(Trident)分别静音的情况。

   ……

以上测试点在不了解功能实现情况下，仅通过测试人员发散性思维考虑到的测试点，测试覆盖度还是存在一定局限性。下面我们将分析功能实现过程，进一步拓展测试点。

开发实现了解

基于开发实现的过程了解，我们得到以下信息：

1. 页面静音是通过Hook机制，将发声函数截获后修改其返回值达到的。Hook的函数有：
   1. waveOutWrite
   2. DirectSound系列函数：DirectSoundCreate、CreateSoundBuffer、SetVolume
   3. Media Foundation
2. 通过对以上Hook函数的返回值进行修改进而达到了静音。
   1. waveOutWrite–>waveOutSetVolume(0)//     通过SetVolume音量为0达到静音
   2. DirectSound–>SetVolume(0) // 同样通过SetVolume音量为0达到静音

基于以上功能实现的了解，我们可以补充到的测试点有：

1. 因为了解到waveOutWrite函数，进而查资料了解到mid音乐格式是使用的这种函数播放，所以测试点补充mid音乐格式。
2. 因为了解到DirectSound函数，进而了解到网页中播放音乐的三种写法：embed，bgsound，classid
   1. <EMBED SRC=”音乐文件地址“>
   2. <BGSOUND     src=”your.mid” autostart=true loop=infinite>
   3. _T(“CLSID:6BF52A52-394A-11d3-B153-00C04F79FAA6”

      进而在测试点中补充不同的classid播放形式，如下：

      ‘/** Windows Media Player 系列(不同面板样式)  mp3格式 */

      _T(“CLSID:6BF52A52-394A-11d3-B153-00C04F79FAA6”)

       

      ‘/** Windows Media Player 系列(不同面板样式)  wma格式 */

      _T(“CLSID:22D6F312-B0F6-11D0-94AB-0080C74C7E95”)

       

      ‘ /** Windows Media Player 系列(不同面板样式)  rm avi格式 */

      _T(“CLSID:CFCDAA03-8BE4-11cf-B84B-0020AFBBCCFA”)

       

      ‘/** Windows Media Player 系列(不同面板样式)  mpg格式 */

      _T(“CLSID:05589FA1-C356-11CE-BF01-00AA0055595A”)

3. 因为了解到Media Foundation函数播放音乐，进而了解到这种函数是在win7以上系统所使用的技术，所以测试点补充不同操作系统类型。
4. 因为了解到Media Foundation函数有版权保护功能，所以测试点补充受版权保护的音乐格式测试点。

综上所述，对被测对象的功能实现了解，对于测试覆盖度的提升是有很大帮助的，所以开发实现讲解流程很有必要。

1. 编码实现前。一般有经验的开发人员在功能实现前，会将大致实现的框架结构设计出来，之后再在此框架基础上进行Coding。

   如图：搜狗浏览器通行证同步框架图

   

2. 编码实现过程中。
3. 编码实现完毕提测时。
4. 测试过程中代码重构优化。

由开发同学负责讲解。

由测试同学提出需求，由开发同学讲解。

由测试同学提出需求，由团队中有Coding能力的测试同学（一般是测试开发工程师）进行代码调研，进而进行讲解。

2.实现讲解的准备

1. 开发同学：将实现过程提取准备为电子版，以便在会议上快速讲解完成。

   例如：搜狗浏览器页面静音代码实现流程图，其中的技术细节和测试重点由开发提前准备了电子版内容，在会议上进行讲解。

   

2. 测试同学：
   1. 在沟通功能实现前，测试同学提前做一些背景知识的了解，例如上例中Hook技术、页面播放声音的常见写法。
   2. 提前准备好要沟通的问题列表，可以记在本子上或电子版，沟通时一个接一个地提问，免得现想问题浪费时间。

3.实现讲解中的注意事项。

a.测试同学提问的问题建议不要太过开放性。

在沟通实现时的第一个问题，如果是比较”大而泛”，沟通结果一般不会太理想，比如：“Cookie同步功能是怎么实现的？”

开发同学更喜欢回答一些具体的、技术性的、非开放性的问题。如果我们换个提问方式：

QA：浏览器不同进程之间是如何传递数据的？

DEV：通过发送消息的方式，使用FileMappming进行多进程传递。

QA：传递的时机是什么时候？

DEV：用户在浏览器中登录网站时，触发了Cookie的读写操作时。

QA：浏览器是怎么检测到用户产生了登录行为？

DEV：浏览器对网络返回值中的Set-Cookie字段进行了检测，一旦发现该字段，则会解析其内容并进行保存和同步操作。

……（借着以上问题继续展开沟通）

b.提问问题的方式很重要。

以前小编和一位开发大牛聊过测试和开发沟通实现的议题，开发大牛表示，他们更愿意测试同学是思考后带着一些想法来沟通的，即便这种想法是错的，也是乐意欢迎的。所以，我们可以准备一些自己对这个功能实现过程的猜测，然后用自己猜测的功能实现来进行提问。

例如：我们不知道Cookie数据如何进行多进程传递时，我们可以猜测Cookie数据是不是保存在数据库中，不同进程读取同一份数据库来进行数据的交互，然后带着这种猜测来进行发问：

QA：“多进程数据同步是不是用数据库进行数据交换的？”

DEV：“通过数据库进行数据交互可能存在这锁的问题，所以我们不是通过这种方法而是用FileMappming文件映射的方式……”

……（顺畅地交流起来）

c.纸上的交流比口头交流好。

在沟通过程中，简单的问题可以口头交流，但是复杂的问题建议在纸上画着流程图或者程序的框架图会更加容易交流沟通。所以，避免只停留在口头上的沟通。

1. 记录总结会议中的具体内容形成电子版文档。
2. 将总结内容维护至模块说明文档。如下：