有关非功能性的事宜，最好在应用程序的架构和设计阶段就开始研究。考虑下面的例子：
当规划一个软件项目时，需要考虑下列非功能性风险：
如果一个应用程序的用途是管理数据，那么随着应用程序中存储的数据的增加，测试组必须了解其性能的下降程度。数据库和应用程序的优化技术能极大的降低这种性能的退化。
为了把应用程序在不同规模数据集合下的新能制成图表，通常需要在不同的数据集合下进行测试，例如：在 100 条、1000 条、10000 条、100000 条····记录的情况下对其进行测试。通过此类测试，还可以获得应用程序数据处理能力的 “上限”，也就是在应用程序的性能可以接受的前提下，数据库的最大规模。
为大型的数据集合确定和填充数据的方法，可以参考第 10 条的内容。为了确定哪些数据部分最关键，以及哪些数据部分最富于变化，我们需要和开发组、产品组进行协商。了解了必要的数据元素后，就可以随机产生（通过脚本或其他程序）大量记录来增加数据库的规模。获得实际数据的一种方法是：从潜在客户或者现有客户那里拿到他们在应用程序中使用的或者计划使用的数据。
可使用性测试的首要目标是：验证对应用程序有意向的用户是否能够和应用程序正确的进行交互，同时感到使用起来明确而方便。它需要检查应用程序界面的布局，其中包括：导航路径、对话框控件、文字、以及定位和可访问性等其他元素。支持组件，例如安装程序、文档、帮助系统等，也需要进行调查。
下面几种方法可以确定目标受众的需求：
在开发易于使用的应用程序时，用户界面原型是一个有效的工具。
安全性需求应该和没跳功能性需求联系起来。除了作用于整个系统的系统级安全性需求以外，每条功能性需求都可能包含一组与安全相关的问题，这些问题将在软件实现中解决，最好能有关于安全性需求的正确文档。软件项目还有全局的安全性问题，并且这些安全性与应用程序的架构以及整体实现相关。还有利用了第三方资源来实现特殊的功能性需求，测试组需要验证这些组件的信息，是否在遵循了系统的全局安全性需求规格说明书。
处理并发性问题的若干方法：
1，保守方式。这种模型再数据上加了锁。如果一个用户已经打开了一条记录，那么在允许编辑的环境中，系统就会拒绝来自其他用户的读取数据的请求。
2，开放方式。这种模型总是允许用户读取数据，甚至可能允许更新数据。但是，当用户试图保存数据时，系统会检查自从这个用户检索数据以后是否有其他人更新过数据。如果数据发生了变化，那么更新就失败了。
3，没有并发保护，“胜利属于最后一个用户”。
应用软件处理并发性的方式会影响系统的性能、可使用性和数据完整性。
下面列举对于不同的并发性模型，测试过程应该关注的注意点：
1，保守方式。
主要关心的是验证能否正确的获得、释放加在记录上的锁，并且能正确处理应用程序中所有可能更新这条记录的部分。
2，开放方式
测试开放的并发性的最佳方式是综合使用手动和自动测试技术。在手动的方法中，两个测试人员编辑数据，然后试图同时保存数据。第一个更新成功，但是第二个用户应该得到一条消息，其内容是另一个人已经更新了数据，他需要重新装载数据并重新完成修改操作。使用自动测试技术，同时发起多条请求，应该只有一条更新成功，其他都应该收到错误消息。
3，没有并发控制。
测试方法和开放式类似，应该关注的是数据的完整性，还应该验证的就是是否正确的处理了更新错误。
由于可能的配置和潜在的兼容性问题非常多，所以应按照出现的频率高低，软件测试人员应该把目标应用程序可能的配置进行排序。此外，还必须为兼容性测试确定恰当的测试用例和测试数据。
对兼容性测试环境的管理是一项重要的工作。重建最终用户环境的方法：一种方法是综合使用活动硬盘驱动器和分区管理工具。另一种方法是使用驱动器映像程序为需要的配置建立映像文件。
安装应用程序的方式和最终用户的安装方式完全相同是非常关键的，其中包括使用相同版本的组件和相同的安装过程。
本文章援引《Effective software testing》一书内容，为个人读后笔记，特此声明